The EU AI Act obliges providers of high-risk AI systems to produce and maintain technical documentation before placing a system on the market or putting it into service. Article 13 sets out what deployers must be told about the system. Annex IV defines what goes into the underlying technical file. Together they form the documentation backbone of EU AI Act compliance — and they map closely to what the industry calls model cards.
Key takeaways
- Article 13 requires high-risk AI systems to ship with instructions for use that enable deployers to understand, interpret, and oversee the system's outputs. This is an obligation on the provider, not the deployer.
- Annex IV (referenced by Article 11) specifies nine categories of technical documentation that must be prepared and maintained for the duration of the system's lifecycle, not just at initial placement.
- High-risk AI systems include those listed in Annex III: biometric identification, critical infrastructure management, education and vocational training systems, employment and worker management tools, essential private and public service access systems, law enforcement, migration and asylum processing, and administration of justice. General-purpose AI models can also fall in scope under certain conditions.
- The full high-risk obligations under Chapter III — including Articles 9–15 and Annex IV — were originally set to apply from August 2, 2026, but the EU's Digital Omnibus initiative (agreed May 7, 2026, formally endorsed by the European Parliament June 16, 2026) delayed the Annex III compliance deadline to December 2, 2027. The delay is not yet formally in force pending Council adoption, but organizations can plan to that date. Systems in products such as lifts or toys have until August 2, 2028.
- Model cards — structured documents describing an AI model's purpose, training data, performance, limitations, and bias testing — are the practical tool for satisfying much of what Article 13 and Annex IV require. Organizations that already produce model cards are well-positioned to adapt them into compliant technical documentation.
Who Article 13 applies to
Article 13 places the obligation on providers — the organizations that develop or commission a high-risk AI system and place it on the market or put it into service. Deployers (organizations that use a high-risk AI system in a professional context) have their own obligations under Article 26, but the Article 13 documentation obligation is the provider's to fulfill.
If you are a SaaS vendor selling an AI-powered hiring screening tool to enterprise customers, you are the provider. Your enterprise customer using that tool is the deployer. You must produce the documentation; they must receive it and implement the human oversight it describes.
If you are an enterprise organization that builds an AI system internally for your own use, you are simultaneously the provider and the deployer under the Act — both sets of obligations apply.
What counts as a high-risk AI system? The Act uses two tests:
- Is the system listed in Annex I (AI techniques) or covered by Annex III (application areas)?
- Does the system pose a significant risk to health, safety, or fundamental rights?
Annex III lists eight domains where AI use is presumptively high-risk, including:
- Biometric identification and categorization of natural persons
- Management and operation of critical infrastructure (energy, water, transport)
- Education and vocational training (access decisions, assessment)
- Employment and worker management (recruitment, performance evaluation, task allocation)
- Access to essential private and public services (credit scoring, insurance risk)
- Law enforcement (risk assessment of individuals, evidence evaluation)
- Migration, asylum, and border control
- Administration of justice and democratic processes
What Article 13 requires in the instructions for use
Article 13 requires that the instructions for use be "in an appropriate digital format" and contain at minimum:
Provider identification: Name and registered address of the provider (and, where applicable, of their authorized representative in the EU).
System characteristics and capabilities: What the system is designed to do, its intended purpose as defined by the provider, the level of autonomy of the system, and the hardware and software environment it requires.
Performance specifications: The level of accuracy, robustness, and cybersecurity against which the system has been tested and validated, including the specific metrics used. This is not a vague claim — it must be the actual figures from validation testing.
Known limitations: Any known or foreseeable circumstances where the system may underperform, fail, or produce unreliable outputs. This includes edge cases, distribution shifts, or categories of input data for which the system was not trained.
Disaggregated performance: Where applicable, the system's performance regarding specific persons or groups — particularly where demographic or other characteristics are relevant to system outputs. A hiring screening tool must document performance differences across protected groups.
Input specifications: Requirements for input data quality, format, and characteristics. If the system performs poorly on low-resolution images or on text in languages other than those in its training data, this must be documented and communicated to deployers.
Human oversight measures: A description of the technical measures built into the system to support human oversight and intervention. This includes how outputs are presented to facilitate review, what intervention mechanisms exist, and what the system's overridable decisions look like.
Expected operational lifetime and maintenance: Information about post-market monitoring requirements and the expected update cadence.
What Annex IV requires in the technical documentation file
Annex IV (the full technical documentation, separate from the instructions for use) is the comprehensive record maintained by the provider. It has nine sections:
1. General description
A general description of the system covering its intended purpose, the categories of persons affected, how it interacts with hardware or software, versions, update mechanisms, hardware specifications, and a description of the user interface elements visible to deployers.
2. Development process
The most substantial section. Must include:
- Design specifications: what the system is meant to do and the key design choices made
- System architecture: the overall architecture including algorithms, model type, and computational resources
- Training data: description of datasets used, their sources, how data was collected, selected, labeled, and pre-processed; data provenance and any third-party datasets used
- Validation and testing procedures: what was tested, against which metrics, with what test data; test logs signed by responsible persons; validation and testing data characteristics
- Pre-trained components: documentation of any third-party models or components incorporated, including their known limitations
- Cybersecurity measures: measures implemented to protect against adversarial attacks, data poisoning, and model theft
3. Monitoring, functioning, and control
Description of the system's capabilities and limitations including expected performance, foreseeable unintended outcomes, technical measures for human oversight, and input data specifications.
4. Description of changes
For systems that undergo changes throughout their lifecycle — including updates, retraining, or architectural modifications — documentation of each change and how it was assessed for compliance impact.
5. Standards and specifications
Which harmonized EU standards were applied, and where standards were not applied or not available, what alternative technical specifications or methods were used instead.
6. EU Declaration of Conformity
A copy of the Article 47 Declaration of Conformity, once issued.
7. Post-market monitoring
The post-market monitoring plan as required under Article 72: how the system's real-world performance will be tracked, what metrics will be monitored, how incidents will be reported, and at what intervals the documentation will be updated.
How model cards map to Article 13 and Annex IV
Model cards — structured documentation artifacts introduced by Google researchers in 2018 and now widely adopted across the ML industry — were designed to surface exactly the information Article 13 and Annex IV require. The mapping is close enough that a well-structured model card covering the sections below can directly satisfy most of both obligations:
| Model card section | Article 13 / Annex IV coverage |
|---|---|
| Model details (architecture, version, release date, authors) | Annex IV §1 general description |
| Intended use (primary uses, out-of-scope uses) | Article 13 characteristics and capabilities; Annex IV §1 |
| Training data (sources, preprocessing, known limitations of training data) | Annex IV §2 development process |
| Evaluation metrics (accuracy, F1, AUC, etc.) | Article 13 performance specifications |
| Disaggregated evaluation (performance by demographic subgroup) | Article 13 disaggregated performance |
| Known limitations and biases | Article 13 known limitations; Annex IV §3 |
| Human oversight recommendations | Article 13 human oversight measures |
| Recommendations for use (input data requirements, operational constraints) | Article 13 input specifications |
What model cards typically do not cover — but Annex IV requires — includes the EU Declaration of Conformity, post-market monitoring plan, and the signed test logs. These must be added as formal appendices to the documentation package even if the model card itself is comprehensive.
Specific content requirements: training data documentation
Training data documentation is where many organizations face the largest gap. Annex IV requires documentation of:
- The datasets used in training, with their sources (internal, commercial, open data, synthetic)
- How data was collected — the process, geographic scope, time period
- How data was selected from the collected pool — filtering criteria, exclusion rules
- How data was labeled — whether by humans, automatically, or a combination; the labeling instructions used; inter-annotator agreement rates
- Any known issues with data quality, gaps, or biases — including geographic or demographic underrepresentation
- How training data was preprocessed, augmented, or transformed
For organizations using third-party datasets (licensed datasets, open benchmarks, web-scraped data), the documentation must account for what is known about those datasets' origins and known issues, including referencing the source dataset's own documentation where available.
Organizations that trained on proprietary historical data — a common pattern in financial services, healthcare, and HR — must document the representativeness of that data. If a credit scoring model was trained on seven years of loan applications from a specific region, that geographic constraint belongs in the technical file.
Specific content requirements: disaggregated performance evaluation
Article 13 requires performance data regarding specific persons or groups where relevant to the system's function. For most high-risk AI applications this is not optional — demographic performance disparities are material to deployer decisions about appropriate use and human oversight intensity.
What this means in practice:
- Evaluate your model's accuracy, false positive rate, and false negative rate across protected categories: gender, age group, ethnic background (where legally permissible to test), disability status where relevant to the use case
- Document the results by subgroup — not just an aggregate accuracy figure
- Where performance differs meaningfully across groups, the instructions for use must state this explicitly and recommend the human oversight steps appropriate for higher-error subgroups
- Where insufficient data existed to evaluate performance for a particular group, document that gap rather than omitting the group from the evaluation section
The EDPB and EU AI Office have signaled that audit and enforcement of high-risk AI systems will focus on exactly this: whether providers documented what they actually know about differential performance, or whether they omitted known disparities from the technical file.
Maintaining technical documentation as a living record
Annex IV requires documentation to be maintained for ten years after the AI system is placed on the market or put into service (Article 18). It must also be updated when the system changes in a way that could affect its compliance with the Act — a new version, a retraining run, a change to the training data pipeline, or a change to the system's intended purpose all trigger a documentation update obligation.
In practice this means:
- Version-controlling the technical documentation in parallel with model versions
- Establishing a trigger list: the set of change types that require documentation update review
- Assigning ownership — someone in the organization must be responsible for keeping the file current
- Maintaining audit trails of changes to both the system and the documentation
For organizations using continuous training pipelines, where the model updates frequently on new data, the documentation regime must be able to track which training run produced which deployed version and what data was used in each run. This is a change management and MLOps concern as much as a legal documentation concern.
Practical steps to build compliant documentation
Step 1 — Classify the system
Determine whether your system falls within Annex III categories. If uncertain, seek qualified legal advice — the boundary cases (e.g., does a performance monitoring tool count as "worker management"?) require legal interpretation, not just a technical reading of the Act.
Step 2 — Inventory what documentation already exists
Most ML projects generate some documentation by default: training data descriptions, model evaluation reports, architecture diagrams, testing logs. Audit what exists before building from scratch. The gap is usually in disaggregated evaluation, formal test log sign-off, and the human oversight section.
Step 3 — Adopt a model card template that maps to Annex IV
Structure the template around the nine Annex IV sections, not around general ML reporting conventions. Each section of your model card should map to a specific Annex IV requirement. Use the AI governance framework to establish the governance layer around the documentation process.
Step 4 — Conduct and document disaggregated evaluation
Run your model's evaluation suite against demographic subgroups relevant to the application. If test data does not include sufficient subgroup representation, document that gap and plan how to close it before the compliance deadline.
Step 5 — Draft the instructions for use
Translate the technical file into a deployer-facing document that covers all Article 13 requirements. This is not the full Annex IV file — it is a digest that deployers can act on. Include concrete guidance on when human review is required before acting on system output.
Step 6 — Establish the update and retention process
Assign a document owner, define what triggers a documentation update, and implement version control for the technical file. Ensure the ten-year retention obligation is operationalized — not just stored in someone's laptop folder.
Step 7 — Keep the documentation in sync with the AI governance policy and any DPIA
High-risk AI systems that process personal data also require a DPIA under GDPR Article 35. The technical documentation and DPIA overlap significantly in their data provenance and risk sections — coordinate them so they remain consistent.
Frequently asked questions
Does Article 13 apply to general-purpose AI models like large language models?
GPAI models have their own obligations under Articles 51–56, separate from the high-risk AI system rules in Chapter III. Article 13 as written applies to high-risk AI systems. However, if a GPAI model is used as a component within a high-risk AI system, the system as a whole must satisfy the Chapter III obligations — including Article 13 documentation. The provider of the high-risk system bears this obligation even if they did not develop the underlying model.
We use a third-party AI model from a vendor. Are we the provider or the deployer?
If you integrate a third-party model into a system and place that system on the market or put it into service in your own name, you are the provider under Article 3(3) and carry the provider obligations — including Article 13. Your vendor is responsible for providing you with sufficient information about their model to support your documentation, but the Annex IV technical file for the final system is your obligation. This is why procurement contracts for AI components should now include documentation and transparency clauses.
How specific do performance figures need to be in the instructions for use?
The Act says the accuracy level "against which the high-risk AI system has been tested and validated" must be stated — it must reflect the actual validation testing, not a general claim. The specific metrics depend on the task type: accuracy and F1 are typical for classification; RMSE or MAE for regression; fairness-specific metrics (demographic parity, equalized odds) for systems with protected-attribute relevance. The metrics must be meaningful for the specific use case, not the easiest metrics to report.
Our AI system will be updated frequently. Does documentation need to be updated every time the model is retrained?
Not necessarily every retrain, but any change that could affect the system's compliance with the Act triggers a review — and likely a documentation update. A retrain on substantially the same data pipeline with stable performance metrics may not require a full update; a retrain that changes training data sources, shifts accuracy by a meaningful margin, or alters the system's behavior for protected groups does. Define the materiality threshold in your internal process and document why specific retrains were assessed as non-material.
What is the relationship between the Annex IV technical file and the EU Declaration of Conformity?
The Declaration of Conformity (Article 47) is a formal statement that the system complies with the Act, signed by the provider. It references the technical file but is a separate document. The technical file is the evidence base; the Declaration is the formal attestation. Notified body involvement (for certain Annex III categories like biometric identification) is required before the Declaration can be issued. The Declaration is also included as a section within the Annex IV technical file once issued.
We are a non-EU company with no EU presence. Does this apply to us?
Yes, if your high-risk AI system is placed on the EU market or put into service in the EU — regardless of where your company is established. In this case, you must appoint an authorized representative established in the EU (Article 22) who holds the technical documentation and can interact with EU supervisory authorities on your behalf.
