For high-risk AI, the EU AI Act expects providers to keep a risk management file, data governance records, technical documentation, logging capability, instructions for use, a quality management system and post-market monitoring. Deployers need oversight assignments, log retention and, in some cases, a fundamental rights impact assessment. Everyone needs an AI literacy measure.
Check your timing first
The original application date for these duties was 2 August 2026. Regulation (EU) 2026/1744 moved it to 2 December 2027 for Annex III high-risk systems and 2 August 2028 for systems under Article 6(1). Use that time to build documents properly, not to skip them. The AI literacy duty in Article 4 and the prohibitions already apply.
Provider documents (high-risk systems)
Risk management file (Article 9). A continuous, iterative process across the lifecycle: identify and analyse known and foreseeable risks to health, safety and fundamental rights, estimate and evaluate them, adopt measures, and test. Keep versions and test results.
Data governance record (Article 10). For systems trained on data: design choices, collection processes and origin, preparation, assumptions, assessment of suitability, bias examination and gap handling.
Technical documentation (Article 11, Annex IV). Drawn up before the system is placed on the market and kept up to date, demonstrating compliance in a form authorities can assess. SMEs, including start-ups, may provide the Annex IV elements in a simplified manner.
Logging design (Article 12). The system must technically allow automatic recording of events over its lifetime, enabling traceability for risk identification, post-market monitoring and deployer oversight.
Instructions for use (Article 13). Concise, complete, correct and clear information for deployers, so they can interpret outputs and use the system appropriately.
Human oversight design (Article 14). Measures built in so natural persons can effectively oversee the system.
Accuracy, robustness and cybersecurity (Article 15). Declared metrics and test records.
Quality management system (Article 17). Documented policies, procedures and instructions covering compliance strategy, design control, testing, data management, post-market monitoring, incident reporting and more.
Conformity and registration records (Articles 43 and 49). Conformity assessment records via the procedure that applies, and registration in the EU database before placing an Annex III system on the market. If you conclude an Annex III system is not high-risk under Article 6(3), document the assessment and register it too.
Post-market monitoring plan (Article 72). A documented system to collect and analyse performance data through the system's life.
Serious incident procedure (Article 73). Report to market surveillance authorities immediately after establishing a causal link or reasonable likelihood of one, and in any event within 15 days of awareness, with the period shaped by severity.
Deployer documents
Use in line with instructions (Article 26). A procedure showing how the system is used according to its instructions.
Oversight assignment. Named people with competence, training, authority and support.
Log retention. Article 26 sets at least six months for logs under the deployer's control, unless other law says otherwise.
Fundamental rights impact assessment (Article 27). Required before deploying certain high-risk systems, for example by public bodies and private entities providing public services, and for some credit and insurance uses listed in Annex III.
Worker and affected person information. Inform people when they are subject to a high-risk system where the Act requires it.
Everyone
AI literacy measures (Article 4). Training records and a statement of measures taken for staff and others operating AI on your behalf.
Transparency notices (Article 50). Wording that tells people when they are interacting with AI.
AI system register. The inventory every other document points to.
What to do
- Create the AI system register and classify each entry.
- For each high-risk entry, create a folder per article above.
- Draft the risk management file and technical documentation early; keep them versioned.
- Write deployer procedures for oversight and logs.
- Run AI literacy training and keep attendance and content.
- Review documents when a system changes substantially.
- Track dates, because the schedule has already moved once.
Quick check
Do deployers need technical documentation?
Technical documentation under Article 11 is a provider duty. Deployers need their own use, oversight and log records.
Are there templates?
Annex IV sets the minimum technical documentation contents. We did not review official templates, so check the Commission's current guidance.
How Safeguard helps automate this
Several of these documents need evidence about how the software is built and monitored. 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, saving your team time for other work. Technical evidence for cybersecurity and robustness records comes from your real code and dependencies: scans, SBOMs and reachability. Autonomous remediation can open tested fix pull requests; it is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. Conformity decisions rest with you, and notified bodies or authorities assess; Safeguard helps you prepare and keep evidence ready.
Open the framework mapping demo or book a call.
Sources
Last reviewed: 18 October 2026.
