The EU AI Act requires 8 specific documentation elements under Annex IV. Most SMEs haven't started. A minority have a folder of PDFs that won't survive a regulator's review. Here's the template — and the gaps — so you can build documentation that actually holds up. After completing it, check the evidence gaps auditors most often find in SMEs to validate your records.
Not sure which of your AI tools needs documentation? Run a free Attestia scan →
Why Technical Documentation Matters More Than You Think
Technical documentation is not box-ticking. It is the legal evidence layer that determines whether your company survives an audit.
When a regulator investigates an AI-related incident — a biased hiring decision, a wrongful credit rejection, a safety failure — the first thing they ask for is your technical documentation. If it does not exist, is incomplete, or cannot be produced quickly, you are presumptively non-compliant. The fines for deploying undocumented high-risk AI systems run up to €15 million or 3% of global annual turnover, whichever is higher.
But documentation matters beyond enforcement. It forces the clarity that most organisations skip: what exactly does this system do, what are its known failure modes, who is responsible for oversight, and what do we do when it goes wrong. Companies that build complete documentation discover risks they did not know they had. That is documentation working as intended.
Who Needs This Documentation
If you are a provider (you developed or significantly modified an AI system), you are legally required to produce and maintain Annex IV technical documentation before placing the system on the market or putting it into service.
If you are a deployer (you use someone else's high-risk AI system), you are not required to produce Annex IV documentation — but you are required to verify that your provider has produced it and to maintain your own operational records covering your specific use case. The distinction matters: deployers cannot simply say "it's the vendor's problem." If the vendor has not produced compliant documentation, your deployment is still non-compliant.
In practice, most SMEs are deployers, not providers. If you have not yet confirmed which of your tools are high-risk under Annex III, do that first — your documentation obligations depend on it. The obligations differ, but the need to understand what documentation exists and whether it is adequate is the same.
The 8 Required Documentation Elements (Annex IV Breakdown)
Annex IV of the EU AI Act defines exactly what technical documentation must contain for high-risk AI systems. Here is what each element requires and what adequate documentation looks like in practice.
1. System Description and Intended Purpose
This is the foundation document. It must cover:
- General description: What the system does, in plain language, without technical jargon that obscures what is actually happening
- Intended purpose: The specific use case for which the system is deployed — not a broad capability description, but the precise operational context
- Persons or groups of persons it is intended to be used on: Who are the subjects of the AI's decisions or outputs
- Changes and versions: Version history, what changed between versions, and when changes were made
- Provider and deployer information: Who built it, who is deploying it, and the division of responsibility between them
The common failure: Intended purpose statements that are too vague to be legally useful. "AI-powered hiring assistance" is not a compliant intended purpose. "AI system that ranks job applications by keyword match against role-specific criteria, producing a candidate score used by HR to determine shortlist inclusion" is closer. The purpose statement needs to be specific enough that a regulator can determine whether the actual use matches the documented use.
2. Training Data Quality and Characteristics
For AI systems trained on data (rather than rule-based systems), documentation must cover:
- Data sources: Where the training data came from, including any third-party datasets used
- Data scope and governance: How the training data was selected, filtered, and cleaned
- Known limitations and biases: What groups or scenarios may be underrepresented, overrepresented, or systematically skewed in the training data
- Data provenance: Whether the data was lawfully obtained and whether it included personal data subject to GDPR controls
- Data versioning: What dataset was used for which model version
The common failure: Deployers who purchase AI systems often receive no data documentation from their vendor. "Trained on proprietary dataset" is not compliant documentation. If your vendor cannot tell you what their model was trained on, the data quality characteristics of that training data, or what bias testing was performed, they are not providing compliant high-risk AI systems — and your deployment inherits that risk.
3. Testing and Validation Methodology
How was the system tested, and what did testing reveal? This element requires:
- Validation datasets: What data was used for validation (separate from training data), and how it was selected
- Accuracy and performance metrics: The system's measured performance on key metrics relevant to its purpose
- Performance across subgroups: How the system performs on different demographic groups — this is the fairness documentation that regulators scrutinise most closely in employment and credit contexts
- Pre-deployment testing: The testing performed before the system went live in the specific deployment context
- Known failure modes: Scenarios where the system has been observed to perform poorly or fail
The common failure: Documentation that shows aggregate accuracy without subgroup breakdown. A CV screening tool that correctly ranks candidates 85% of the time may have 75% accuracy for candidates from certain demographic backgrounds. Aggregate performance metrics hide discriminatory patterns — which is precisely why the Act requires subgroup analysis. If you cannot show subgroup performance data, assume the regulator will.
4. Human Oversight Procedures
High-risk AI systems must have human oversight that is real, not nominal. Documentation must describe:
- The oversight mechanism: How qualified humans monitor system outputs before they produce consequential effects
- Role definition: Who is responsible for oversight, what qualifications they need, and how they are trained
- Override procedures: How a human can intervene, override, or halt the system's operation
- Decision authority: Who has authority to make the final decision and how the AI's output relates to that decision
- Escalation procedures: What happens when the human overseer has doubts, identifies an error, or wants the decision reviewed
The common failure: Human oversight that exists on paper but not in practice. Documenting "outputs reviewed by HR manager" without specifying how long the review takes, what the reviewer has access to, and whether they have meaningful capacity to override the system creates a paper trail that will not survive scrutiny. If a reviewer is processing 500 applications in two hours, the "human oversight" is not real. Document the actual process — including time allocation, reviewer access to underlying data, and override rates.
5. Accuracy, Robustness, and Cybersecurity Measures
This element covers the technical quality and security properties of the system:
- Accuracy metrics: The defined accuracy thresholds and how they are measured in production
- Robustness against errors: How the system behaves when inputs are incomplete, corrupted, or adversarial
- Resilience: How the system handles edge cases, out-of-distribution inputs, and operational degradation
- Cybersecurity measures: How the system is protected against adversarial attacks, model inversion, and data poisoning
- Error monitoring: How errors and accuracy degradation in production are detected and addressed
The common failure: Documentation that covers initial deployment performance but not ongoing monitoring. AI systems degrade. Models trained on 2023 data making decisions in 2026 may perform significantly worse than their original validation metrics suggested. Documentation must describe how you detect this — not just what your accuracy was at launch.
6. Risk Management System
Article 9 of the Act requires a risk management system for each high-risk AI system throughout its lifecycle. Documentation must include:
- Risk identification: All foreseeable risks associated with the system in its intended use and reasonably foreseeable misuse
- Risk assessment: The severity and probability of each identified risk
- Risk mitigation measures: The specific controls implemented to address each risk
- Residual risk evaluation: The risks that remain after mitigation, and the determination that they are acceptable
- Risk management updates: How the risk assessment is reviewed and updated as new information emerges
The common failure: Generic risk assessments not specific to the AI system. A risk document that lists "data breach," "system outage," and "user error" without addressing the specific ways this particular AI system can produce harmful outputs — discriminatory decisions, false positives that trigger serious consequences, failure modes specific to the training data — is not a risk management system under the Act. The risk identification must be specific to what the AI does and who it affects.
7. Post-Market Monitoring Plan
Compliance does not end at deployment. The Act requires ongoing monitoring, and that monitoring must be documented in advance:
- Monitoring metrics: What you measure, how often, and what thresholds trigger review
- Incident reporting: How serious incidents are identified, documented, and reported to the relevant national authority
- User feedback integration: How complaints, errors, and concerns from users and affected individuals are collected and addressed
- Performance drift detection: How you detect when the system's performance is degrading from its validated baseline
- Update procedures: How significant updates or changes to the system trigger re-documentation and re-assessment
The common failure: No monitoring plan at all. Most SME deployers have no formal mechanism for tracking whether their high-risk AI system continues to perform as it did at deployment, whether it is producing disparate outcomes across groups in production, or whether users are experiencing systematic issues. Post-market monitoring is legally required — and it is also how you find out about problems before a regulator or affected individual does.
8. Instructions for Use (For Deployers Downstream)
This element is specifically required from providers and must be passed to deployers. It covers:
- Intended use constraints: The specific purposes and contexts for which the system is designed, and the uses that are out of scope
- Setup and deployment requirements: The technical and operational conditions required for the system to function as documented
- Human oversight requirements: What oversight the deployer must implement, and what qualifications that oversight requires
- Performance limitations: Known constraints on accuracy, reliability, or performance in specific conditions
- Maintenance and update instructions: How to keep the system current and what changes require re-assessment
The common failure: Treating vendor documentation as sufficient. A vendor's instructions for use describe the system generically. Your deployer documentation must address your specific use case — who specifically uses the system in your organisation, what training they have received, how your oversight procedures implement the vendor's minimum requirements, and whether your use case matches the vendor's intended purpose. The gap between vendor instructions and your deployment context is your compliance gap.
What SMEs Get Wrong: The Three Most Common Documentation Gaps
Gap 1: Incomplete AI Inventory
You cannot document what you have not listed. The most fundamental documentation failure is not knowing which AI systems in your organisation are high-risk. Most SMEs have three to twelve AI-enabled tools in active use. Of those, two to four are typically in Annex III domains. Of those, most deployers do not know it.
Documentation begins with inventory. Every AI tool: what it does, who uses it, what decisions it informs or makes, what data it processes. The inventory is the prerequisite for everything else.
Gap 2: Missing Classification Rationale
Many SMEs who have started compliance work have classified their systems — but cannot show their work. Classification is not just a conclusion ("we determined this is limited risk"). It is a documented analysis: which Annex III domains were considered, why each was determined to apply or not apply, what the intended purpose scope covers, and when the classification was made.
Classification rationale matters for two reasons. First, it protects you: if a regulator disagrees with your classification, documented reasoning that is legally sound is a defence. Second, it enforces rigour: organisations that document their classification logic discover edge cases they would otherwise miss. A system classified as "limited risk" because it "only provides information" that happens to influence employment decisions is a misclassification — and working through the documentation forces that scrutiny.
Gap 3: No Oversight Records
Human oversight is required. Records of that oversight are required. Most deployers have the first (nominally, at least) and none of the second. If a regulator asks you to demonstrate that human oversight of your high-risk AI system has been operating as required, what do you show them?
Oversight records need not be elaborate. They require: evidence that reviews occurred, who performed them, what the AI's output was, what the human determined, and whether the human's determination matched or overrode the AI. Decision logs, review timestamps, and override records collectively constitute an oversight trail. Without them, human oversight is undocumentable — which, legally, means it did not happen.
A Free Technical Documentation Template
The following template addresses all eight Annex IV elements. It is a starting point, not a finished compliance document — your specific system, use case, and risk profile require adaptation. But it gives you a structure that covers the required scope.
Section 1: System Identification
| System name | [Name of the AI system] |
| Version | [Version number and date] |
| Provider | [Company that developed the system] |
| Deployer | [Your company name] |
| Date of deployment | [Date first put into service] |
| Risk classification | [High-risk — Annex III, category: X] |
| Classification date | [When classification was determined] |
| Classification rationale | [Summary of Annex III domain analysis and conclusion] |
Section 2: Intended Purpose
System description (what it does, mechanically): [Describe the AI's mechanism — what inputs it takes, what processing it applies, what outputs it produces]
Intended purpose (specific use case): [Precise operational context — not "hiring assistance" but "ranking inbound job applications for Role X based on criteria Y, producing a score used by HR for shortlisting"]
Intended users: [Who operates the system]
Persons affected: [Who is subject to the system's decisions or outputs]
Known out-of-scope uses: [Uses the system is not designed for and must not be applied to]
Section 3: Training Data Summary
(For providers — deployers complete from vendor documentation)
Data sources: [Origin of training data]
Dataset size and scope: [Volume, time period, geographic coverage]
Known limitations: [Underrepresented groups, geographic gaps, temporal limitations]
Bias assessment: [What bias testing was performed and key findings]
Data governance: [How personal data was handled, GDPR basis if applicable]
Section 4: Performance Metrics
| Metric | Overall | Subgroup A | Subgroup B | Date measured |
|---|---|---|---|---|
| Accuracy | — | — | — | — |
| False positive rate | — | — | — | — |
| False negative rate | — | — | — | — |
| [Domain-specific metric] | — | — | — | — |
Performance thresholds: [Minimum acceptable performance levels — what triggers a review or halt]
Known failure modes: [Conditions under which the system performs poorly]
Section 5: Human Oversight Procedure
Oversight role: [Job title responsible for oversight]
Required qualifications: [What knowledge or training the overseer must have]
Oversight process: [Step-by-step description of how the overseer reviews AI outputs]
Time allocation: [How much time per decision or batch the overseer has]
Override authority: [Who can override the AI's output and how]
Override record-keeping: [Where overrides are logged and by whom]
Escalation path: [What happens when the overseer has concerns]
Section 6: Risk Register
| Risk | Severity (1–5) | Probability (1–5) | Mitigation measure | Residual risk |
|---|---|---|---|---|
| [Discriminatory output] | — | — | — | — |
| [False positive harm] | — | — | — | — |
| [Data breach] | — | — | — | — |
| [Performance degradation] | — | — | — | — |
| [Misuse outside intended purpose] | — | — | — | — |
Section 7: Post-Market Monitoring Plan
Monitoring frequency: [How often performance is reviewed — weekly, monthly, quarterly]
Monitored metrics: [Which performance metrics are tracked in production]
Drift threshold: [Performance degradation level that triggers formal review]
Incident definition: [What constitutes a serious incident requiring reporting]
Reporting procedure: [Who reports, to whom, within what timeframe]
User feedback mechanism: [How affected individuals can raise concerns]
Review schedule: [Formal documentation review dates]
Section 8: Instructions for Use (Deployer Responsibilities)
Deployment constraints: [Uses that are within scope and outside scope]
Operational prerequisites: [Technical or operational conditions required for compliant use]
Required training: [Training that users and overseers must complete]
Maintenance requirements: [Update cadence, re-validation triggers]
Change management: [Changes that require re-documentation]
How to Actually Complete This
The template looks substantial. In practice, completing it for a single AI system takes two to four hours if you have the vendor documentation and four to eight hours if you need to chase the vendor for it. The work breaks down into three steps.
Step 1: Inventory first. Before you open the template, list every AI tool your organisation uses. For each one: what it does, who uses it, what domain it operates in. This takes an hour and is the prerequisite for everything else. Attestia's scanner accelerates this — you describe each tool and receive a risk classification with Annex III domain analysis.
Step 2: High-risk systems only. Complete Annex IV documentation only for high-risk AI systems. Limited and minimal risk systems need transparency disclosures, not full technical documentation. Prioritise your highest-risk, highest-impact systems first.
Step 3: Start with what you know. Sections 1, 2, 4, 5, and 7 can be completed by your team without waiting for vendor responses. Complete those first. Section 3 (training data) requires vendor input — send the request in parallel so it arrives before you need it. Section 6 (risk register) benefits from having performance metrics in hand but can be drafted in parallel.
Start your AI inventory with a free Attestia scan →
The August 2026 Deadline
August 2, 2026 is the enforcement date for high-risk AI systems under Annex III. That is when national market surveillance authorities can begin investigating non-compliant deployers and issuing fines.
Documentation takes time to complete correctly. A rushed documentation exercise produces paper compliance — documents that exist but would not survive a serious audit. The goal is documentation that is accurate, specific, and evidenced: that means gathering real performance data, establishing real oversight processes, and running real post-market monitoring before you document it.
If you have not started: start this week. Complete your inventory first. Identify your high-risk systems. Request vendor documentation. The template above gives you the structure; what takes time is gathering the content to fill it correctly.
This article provides general educational information about the EU AI Act and does not constitute legal advice. For advice specific to your situation, consult a qualified legal professional.