To survive an EU AI Act assessment, keep an evidence pack per high-risk system: the risk management file, technical documentation, data governance records, logs, test results, oversight records, quality management records and incident reports, all versioned and dated. Know whether your route is internal control or a notified body, and who answers authorities.
Who assesses what
The Act uses conformity assessment before a high-risk system is placed on the market. Article 43 offers, for certain Annex III systems such as biometrics where harmonised standards were applied, a choice between internal control (Annex VI) and an assessment of the quality management system and technical documentation with a notified body (Annex VII). For other Annex III areas, internal control is the route described. Systems under Annex I follow the product legislation's procedure. Which applies to you is a legal question, so confirm it in Article 43 with your adviser.
After launch, market surveillance authorities can request documentation and logs, and providers must report serious incidents. High-risk duties apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems under Regulation (EU) 2026/1744, so the evidence you collect now becomes your baseline.
The evidence pack, in order of what is asked first
- System description and intended purpose. Authorities start here. Keep it consistent across documents.
- Risk management file (Article 9). Hazard analysis, risk ratings, mitigations, residual risk decisions, test plans and results.
- Technical documentation (Article 11, Annex IV). The whole set, current, with change history.
- Data governance (Article 10). Data sources, preparation steps, bias checks and findings.
- Test and validation records (Article 15). Accuracy and robustness metrics against declared levels, security testing and fixes.
- Logs (Article 12). Evidence the system records events, plus samples that show traceability. Deployers keep logs under their control for at least six months under Article 26.
- Human oversight (Article 14 and 26). Design of oversight measures, named overseers and their training.
- Quality management (Article 17). Procedures, audits, corrective actions and management review.
- Post-market monitoring (Article 72). Plan and collected data.
- Incident records (Article 73). Reports sent, timeline, root cause and fixes.
- Registration (Article 49). Proof of registration in the EU database where required.
Make it retrievable
An authority request is a deadline exercise. Build a single index mapping each article to the document, its owner, version and location. Keep read-only archives of each released model or system version with the documentation that applied then. Record who approved what and when.
Traps
Documentation written after the fact and backdated. Test metrics that do not match what the instructions for use declare. Logs that exist but cannot be linked to a specific system version. A substantial modification with no new risk review. Vendors who will not supply the information you need as a deployer; get it contractually before you rely on the system.
Handling a request or inspection
Route requests to a single owner. Acknowledge quickly. Provide what is asked, no more, with a log of what you sent. Involve counsel. Capture follow up actions and fix them with dated records.
What to do
- Decide your conformity route per system and note the legal basis.
- Build the evidence index and assign owners.
- Version-control every document and the system release it describes.
- Run a mock assessment: pick a system and have someone outside the team ask for items 1 to 11.
- Test your serious incident process with a tabletop and keep notes.
- Check supplier contracts for information and cooperation duties.
- Review the pack at each substantial change and at least yearly.
Quick check
Do I need a notified body?
It depends on the system category and the route in Article 43. Some Annex III systems use internal control. Confirm with your adviser.
What does a serious incident report need?
Article 73 says report to the market surveillance authority where it occurred immediately after establishing a causal link or likelihood, and no later than 15 days after becoming aware. Read the full article for content.
How Safeguard helps automate this
Authorities will want proof that cybersecurity and robustness claims hold up. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between assessments, saving your team time for other work. Technical evidence comes from your real code and dependencies: scans, SBOMs and reachability. Autonomous remediation can open tested fix pull requests for vulnerable dependencies and other findings; it is off by default, every category starts on Manual, and you choose which categories run automatically and at what approval level. Safeguard does not replace your notified body, assessor or counsel, and it does not guarantee a result. Book a call.
Sources
Last reviewed: 18 October 2026.
