Annex IV technical documentation
An Annex IV documentation pack for describing one AI system: its intended use, design, controls, evaluation, and supporting evidence.
Contents and evidence map
Use the template to assign the documentation, locate supporting records, and identify gaps before review.
Section 1
General description
- Supporting material
- A plain-language overview of what the system does, who it's for, how it's delivered, and what version is in service.; System overview docs and release notes; Deployment topology / environment docs; Deployer instructions and UI description
Section 2
System elements & development process
- Supporting material
- How you built it: methods, tools, architecture, data governance, testing/validation, cybersecurity, and human oversight measures.; Architecture diagrams and component inventories; Datasheets, model cards, and evaluation reports; CI/CD logs, signed test artifacts, security reports
Section 3
Monitoring, functioning, control
- Supporting material
- Capabilities, limitations, expected performance (including relevant subgroups), and the operational controls that keep the system safe.; Quality monitoring and drift reports; Alerting rules and escalation runbooks; Human oversight decision records
Section 4
Appropriateness of performance metrics
- Supporting material
- Which metrics you use, why they match the intended purpose, and what thresholds define acceptable performance.; Metric definitions and evaluation methodology; Baseline and ongoing evaluation reports; Approval records for threshold changes
Section 5
Risk management system
- Supporting material
- Your risk process end-to-end: identification, evaluation, mitigation, residual risk acceptance, and verification loops.; Risk register entries and mitigations; Policy-as-code controls and enforcement logs; Incident reports and remediation records
Section 6
Relevant lifecycle changes
- Supporting material
- What changed, when, why, and what you validated: model swaps, data pipeline changes, policy changes, UI changes, retraining events.; Release notes and change logs; Approval workflows and validation reports; Policy bundle diffs and effective dates
Section 7
Standards/technical specs used
- Supporting material
- Which harmonised standards (or alternative technical specs) you used, and how they map to the requirements you must meet.; Standards mappings; Control framework mappings; Audit-ready policy pack references
Section 8
EU declaration of conformity
- Supporting material
- A reference to (or attachment of) the declaration of conformity, including issuance details and signatory.; QMS-controlled declaration document; Issuance and approval records
Section 9
Post-market monitoring plan
- Supporting material
- A plan for monitoring performance and risks after deployment: signals, thresholds, escalation, remediation, and continuous improvement.; Monitoring plan docs; Drift/bias reports; Incident and corrective action records
| Section | Subject | Supporting material |
|---|---|---|
| 1 | General description | A plain-language overview of what the system does, who it's for, how it's delivered, and what version is in service.; System overview docs and release notes; Deployment topology / environment docs; Deployer instructions and UI description |
| 2 | System elements & development process | How you built it: methods, tools, architecture, data governance, testing/validation, cybersecurity, and human oversight measures.; Architecture diagrams and component inventories; Datasheets, model cards, and evaluation reports; CI/CD logs, signed test artifacts, security reports |
| 3 | Monitoring, functioning, control | Capabilities, limitations, expected performance (including relevant subgroups), and the operational controls that keep the system safe.; Quality monitoring and drift reports; Alerting rules and escalation runbooks; Human oversight decision records |
| 4 | Appropriateness of performance metrics | Which metrics you use, why they match the intended purpose, and what thresholds define acceptable performance.; Metric definitions and evaluation methodology; Baseline and ongoing evaluation reports; Approval records for threshold changes |
| 5 | Risk management system | Your risk process end-to-end: identification, evaluation, mitigation, residual risk acceptance, and verification loops.; Risk register entries and mitigations; Policy-as-code controls and enforcement logs; Incident reports and remediation records |
| 6 | Relevant lifecycle changes | What changed, when, why, and what you validated: model swaps, data pipeline changes, policy changes, UI changes, retraining events.; Release notes and change logs; Approval workflows and validation reports; Policy bundle diffs and effective dates |
| 7 | Standards/technical specs used | Which harmonised standards (or alternative technical specs) you used, and how they map to the requirements you must meet.; Standards mappings; Control framework mappings; Audit-ready policy pack references |
| 8 | EU declaration of conformity | A reference to (or attachment of) the declaration of conformity, including issuance details and signatory.; QMS-controlled declaration document; Issuance and approval records |
| 9 | Post-market monitoring plan | A plan for monitoring performance and risks after deployment: signals, thresholds, escalation, remediation, and continuous improvement.; Monitoring plan docs; Drift/bias reports; Incident and corrective action records |
Describe the system as deployed. Connect each section to the version, test result, approval, or operating record that supports it. Update the dossier when the system changes.
Human oversight
- System
- Claims triage assistant
- Boundary
- A reviewer approves each customer-impacting action
- Owner
- Claims operations lead
- Evidence
- Policy version, Decision Request, reviewer decision, execution result
Source: Regulation (EU) 2024/1689. Review the requirements applicable to your system with the people responsible for its legal and operational assessment.
Questions and details
Is Annex IV required for all AI systems?
No. Annex IV technical documentation applies to high-risk AI systems under the EU AI Act. Whether your system is high-risk depends on its intended use and category.
What counts as "high-risk"?
"High-risk" is defined by the EU AI Act's categories and conditions (for example, certain uses in employment, education, critical infrastructure, and essential services). Confirm your category with counsel and your risk function.
Can SMEs or startups provide simplified documentation?
Some obligations and expectations may differ by context, but auditors still need clear evidence: system description, controls, testing, change history, and monitoring. The template is designed to be right-sized while remaining defensible.
What's the difference between Annex IV technical documentation and an EU declaration of conformity?
Annex IV is the technical documentation package describing the system, process, controls, and evidence. The EU declaration of conformity is a formal statement that requirements are met, typically referenced from (or attached to) the technical file.
How often should we update Annex IV documentation?
Treat it as living documentation: update on releases, model swaps, policy/guardrail changes, material incidents, or monitoring findings. Many teams align updates to change control and post-market monitoring cadence.
Does this cover post-market monitoring?
Yes. The template includes a post-market monitoring section and prompts for signals, thresholds, escalation, and remediation, plus evidence pointers for reports and decision records.
Does this apply to general-purpose AI models too?
General-purpose AI models can have separate obligations and documentation expectations. This page focuses on Annex IV technical documentation for high-risk AI systems; confirm additional duties for GPAI with your compliance team.