AI Act compliance documentation: what regulators ask for

Which documents does a high-risk AI system actually need?

Five work products: the technical documentation under Article 11 and Annex IV, the risk management records under Article 9, the data governance description under Article 10, the logging plan under Article 12, and the instructions for use together with the human oversight description under Articles 13 and 14. All five sit with the provider, and all five have to exist by 2 December 2027.

The list misleads if you picture five separate binders. Annex IV point 5 pulls in the description of the risk management system, point 2 pulls in data governance and the assessment of human oversight measures, and point 9 pulls in the post-market monitoring plan. What works in practice is one versioned document tree, not five parallel Word files that contradict each other six months later.

When does this have to be ready? The 2026 deadline moved

The documentation duties for high-risk systems did not start applying on 2 August 2026. Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026 and postponed Chapter III Sections 1 to 3, meaning Articles 8 to 27, to 2 December 2027. Systems embedded in Annex I products moved to 2 August 2028.

Sixteen extra months sound generous. Most of this documentation cannot be manufactured retroactively. Annex IV point 2 asks for dated test logs signed by a responsible person, for the rationale behind design choices, and for the trade-offs you accepted. Start that in autumn 2027 and what you produce is a reconstruction, which is hard to defend in an audit.

National implementing law is the loose end. In Hungary, Act LXXV of 2025 and Government Decree 344/2025 (X. 31.) are still built on the 2 August 2026 application logic, and we found no public source showing they have been realigned since the omnibus. The postponement landed six days before the original deadline, so any national text drafted during 2025 predates it. Worth checking for your own member state. It grants no exemption either way.

What goes into the technical documentation under Article 11 and Annex IV?

Annex IV has nine points: a general description of the system, the details of the development process, how the system operates and is controlled, the justification of the performance metrics, the risk management system, changes over the lifecycle, the standards applied, a copy of the EU declaration of conformity, and the post-market monitoring plan. Article 11(1) requires all of it before the system goes to market, and kept up to date afterwards.

1. General description of the system

Intended purpose, the name of the provider, the version and how it relates to previous versions. Also how the system interacts with external hardware, software or other AI systems, the software and firmware versions, the forms in which it is placed on the market (embedded software, download, API), the hardware it runs on, and a basic description of the user interface.

In a live project this is the chapter that goes stale fastest. If you ship every two weeks, the version history cannot be a hand-maintained table; it has to be generated from the release process. The product owner writes the chapter, engineering supplies the version data.

2. Development process and system elements

The longest section and the one least likely to exist. Its eight sub-points cover the development methods and any use of pre-trained models or third-party tools, the design specification with the general logic of the algorithm, the rationale for the main design choices, what the system is optimised for, the architecture and the compute used for training, datasheets for the datasets, the assessment of the Article 14 human oversight measures, any pre-determined changes, the validation and testing procedures including the examination for discriminatory impact, and finally the cybersecurity measures.

The regulation asks for the test logs to be dated and signed by the responsible person. That single requirement is why this chapter cannot be written at the end of the project. If the model sits on a pre-trained model behind a closed API, this is where you state what you use, in which version, and how you modified it. Teams that would rather run a model on their own infrastructure for exactly this reason will find the technical boundaries in our guide to local AI deployment.

The engineering lead and the ML engineer write this chapter, the test logs are signed by whoever ran the tests, and legal reviews the licence terms of third-party components.

3. Operation, monitoring and control

The capabilities and performance limitations of the system, the degree of accuracy broken down for the persons and groups the system is intended for, foreseeable unintended outputs, and the sources of risk to health, safety, fundamental rights and non-discrimination. The technical implementation of Article 14 human oversight belongs here, along with the specification for the input data.

Accuracy broken down by group is the requirement that makes a single global metric insufficient. You need a segmented evaluation set, and you need an attribute to segment on. That opens a data protection question, for which Article 10(5) provides an exceptional legal basis. Written by the ML engineer, approved by the product owner.

4. Justification of the performance metrics

A short chapter that almost everyone skips. Reporting an F1 of 0.91 is not enough. You have to justify why F1 is the right metric for this intended purpose, and why not recall, precision or calibration. In a credit scoring model the difference usually comes down to who is hurt more by a false positive and who by a false negative. Written by the ML engineer, reviewed by an independent pair of eyes inside the company.

5. The risk management system

Point 5 asks for a detailed description of the Article 9 risk management system. That is the subject of the next section, because it is worth keeping as a standalone record and referencing it from here.

6. Changes over the lifecycle

A change log of what the provider modified over the system lifecycle. This chapter has a legal edge: under Article 25 a substantial modification can flip roles, and a party that was a deployer can become a provider. Engineering maintains the log, but whether a given change counts as substantial is a call for legal.

7. List of harmonised standards applied

List the harmonised standards you applied whose references have been published in the Official Journal of the European Union. Where no harmonised standard was applied, you have to describe in detail the other solutions used to meet the requirements of Chapter III Section 2. A missing standard is not an exemption; it is more writing. Check the current Official Journal list for what has actually been harmonised, because that list moves.

8. Copy of the EU declaration of conformity

The declaration under Article 47 is written, machine-readable, and issued under the provider’s own responsibility. For most Annex III systems the conformity assessment route under Article 43 is internal control, so the provider issues the declaration itself, without a notified body. It is signed by the managing director or an authorised executive, because this is an act of accountability rather than paperwork.

9. Post-market monitoring plan

The plan required by Article 72, covering how you collect and analyse data from the system in live operation and how you feed that back into risk management. Article 72(3) requires the Commission to adopt a template for this plan by implementing act; the deadline in the text of the regulation was 2 February 2026. Whether the final template has been published we could not confirm from a public source at the time of writing, so structure the plan so it can be ported into a template later.

What does the Article 9 risk management record contain?

Article 9(2) describes risk management as a continuous, iterative process across the whole system lifecycle, with regular review. It has four steps: identifying known and reasonably foreseeable risks, estimating them under intended use and under reasonably foreseeable misuse, evaluating further risks that emerge from post-market monitoring data, and adopting targeted mitigation measures.

A row in the register is useful only if an outside reader can tell what happened from it. That needs the risk identifier and description, the protected interest affected (health, safety or a fundamental right), the estimated likelihood and impact, the mitigation measure, the residual risk and its acceptance, a reference to the test that evidences the mitigation, the name of the person responsible, and the date of the next review.

Article 9(5) requires the residual risk to be judged acceptable both per individual risk and overall, reduced first through design and development, then through control measures, and finally through information and training under Article 13. Article 9(9) calls out the impact on people under 18 and on other vulnerable groups as a separate consideration.

Incident handling ties the register from the other side. Under Article 73 a serious incident has to be reported immediately after the causal link is established, and no later than 15 days; within 2 days for a widespread infringement or an incident under Article 3(49)(b). If an incident produces no new row in the risk register, the register is not alive.

How do you write the data governance description under Article 10?

Article 10(2) lists eight things to document about training, validation and testing datasets: the design choices, the data collection process and the origin of the data, the original collection purpose where personal data is involved, the preparation operations (annotation, labelling, cleaning, updating, enrichment, aggregation), the assumptions made, an assessment of the availability and quantity of the datasets, the examination for bias, the measures against bias, and the identification of data gaps.

Article 10(3) requires datasets to be relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose. Article 10(4) asks you to account for geographical, contextual, behavioural and functional characteristics. Where the system is not developed with training of models, Article 10(6) limits these paragraphs to the testing dataset.

The most common gap is not the bias examination; it is evidence of data provenance. In a mid-sized company the training data usually comes out of the company’s own ERP or CRM, where the original collection purpose was invoicing or customer administration. Article 10(2)(b) requires you to write that down, and it has to be reconciled with purpose limitation under the GDPR.

What the omnibus changed about bias detection

Article 10(5) originally gave providers of high-risk systems an exceptional legal basis for processing special categories of personal data for bias detection and correction, subject to six strict conditions: no other effective way to do it, technical limitations preventing re-use, strict access control and confidentiality, no transfer to third parties, deletion after correction, and a documented justification. The Digital Omnibus extended that basis to all AI systems rather than high-risk ones only, and restored the strict necessity test (Freshfields, 10 July 2026).

Good news if you have avoided measuring bias because you had no legal basis to process protected attributes. Bad news if you now read this as a free pass: the six conditions survived, and the documented justification is one of them.

What has to be logged, and how long do you keep the logs?

Article 12(1) requires a high-risk system to technically allow the automatic recording of events over its lifetime. Article 12(2) names three purposes: identifying situations that create risk and substantial modifications, supporting Article 72 post-market monitoring, and supporting the Article 26(5) monitoring of operation by the deployer. The retention floor is six months.

For remote biometric identification, Article 12(3) sets a concrete minimum: the start and end time of each use, the reference database against which the input was checked, the input data for which the search produced a match, and the identification of the natural persons involved in verifying the results under Article 14(5).

Here is a mistake we see in a lot of engineering teams. A trace recorded in an LLM observability tool is not an Article 12 log. The trace is built for developers, usually sampled, kept for a few weeks, and it contains the prompt. The Article 12 log serves auditability, lives beyond six months, and should carry personal data only to the extent necessary. The two systems can feed each other; neither replaces the other. On the technical side, our LangFuse and LangSmith comparison shows what an observability layer actually gives you, and our comparison of Power Automate against a Python stack shows how much harder it is to extract the evidence required by Articles 11, 12 and 13 from a low-code platform.

The logging plan itself is a short document. It lists the event types, the fields recorded, the legal basis for and minimisation of any personal data, the retention period, access rights, and how the log can be handed to an authority under Article 21(2).

What must the instructions for use and the human oversight description contain?

Article 13(3) sets out six items for the instructions for use: the identity and contact details of the provider, the capabilities and performance limitations of the system, any pre-determined changes, the human oversight measures under Article 14, the computational and hardware resources needed together with expected lifetime and maintenance, and a description of the mechanisms that allow deployers to collect and interpret the logs.

Capabilities and limitations is the heavy one. It covers the intended purpose, the tested level of accuracy, robustness and cybersecurity with the metrics, any known circumstance that may affect those levels, the risks under reasonably foreseeable misuse, the technical capabilities that help explain the output, the performance for specific persons or groups, and the specifications for the input data.

Human oversight: Article 14 is a design requirement

Article 14(1) requires the system to be designed so that natural persons can effectively oversee it, including through appropriate human-machine interface tools. Article 14(4) lists five capabilities the oversight person has to be enabled to exercise: understand the capacities and limitations and detect anomalies, stay aware of automation bias, correctly interpret the output, decide not to use the system or to override its output, and intervene to stop it.

This chapter cannot be discharged with one sentence. If the description says the user may override the decision but the interface has no button that does so with an audit trail, the document and the system contradict each other. In an audit, the system wins.

For biometric identification, Article 14(5) adds a four-eyes rule: no action may be taken on the basis of an identification unless it has been separately verified and confirmed by at least two natural persons with the necessary competence, training and authority.

The deployer side connects here. Article 26 requires oversight to be assigned to competent, trained and authorised persons, input data under the deployer’s control to be relevant, workers’ representatives and affected workers to be informed before the system is put into use at the workplace, and the information received from the provider to be used for the data protection impact assessment under Article 35 GDPR.

Who writes which document, and when does it get updated?

Documentation stays current only when every work product has a named owner and a trigger event. The regulation prescribes no organisational structure, only an outcome: Article 11(1) requires the technical documentation to be kept up to date, and Article 9(2) requires the risk management system to be reviewed regularly.

The biggest risk to keeping documentation current is not laziness. It is that nobody notices an update is due. Build a checkpoint into the release process: if a change touches the model, the training data, the intended purpose or the user interface, the release does not ship until the affected chapter has been updated.

What does a regulator ask for, and how fast do you have to produce it?

Article 21(1) requires the provider, upon a reasoned request from a competent authority, to hand over all information and documentation necessary to demonstrate conformity with Chapter III Section 2, in a language easily understood by that authority. Article 21(2) adds access to the logs under Article 12(1). What the authority receives is protected by the confidentiality rules in Article 78.

Article 21 sets no deadline counted in days. The time you get comes from national administrative procedure law and from the request itself. In Hungary the market surveillance authority is the Artificial Intelligence Authority (Mesterséges Intelligencia Hivatal), the notifying authority is the National Accreditation Authority, and in the financial sector the central bank acts as sectoral market surveillance. Government Decree 344/2025 excludes summary proceedings and sets a 30-day payment deadline for any fine imposed.

If your buyer sits in Germany or Austria

A German customer will usually ask about data protection before it asks about the AI Act. Where personal data is processed on their behalf, a data processing agreement under Article 28 GDPR is mandatory, with ten prescribed contents in Article 28(3), and a missing or defective agreement carries its own exposure of EUR 10 million or 2% of worldwide annual turnover. In the Bitkom survey of 604 companies with 20 or more employees, published on 11 March 2026, data protection requirements were the single largest external barrier to AI adoption at 77%.

The second thread is NIS2. Germany’s implementing act (NIS2UmsuCG, amending the BSIG) appeared in the Federal Law Gazette on 5 December 2025 and entered into force the following day, covering roughly 30,000 companies, with management accountability written into section 38. Because NIS2 reaches into the supply chain, an in-scope German customer will push its security requirements onto you as a supplier, and will want the evidence in writing. That evidence overlaps with the AI Act package but is not the same set; we map both in our NIS2 compliance service.

Record retention under Article 18 is ten years from placing on the market or putting into service: the technical documentation, the quality management system documentation, any changes and decisions approved by a notified body, and the EU declaration of conformity. The penalty side is the second tier of Article 99: EUR 15 million or 3% of total worldwide annual turnover, whichever is higher, with Article 99(6) making the lower of the two the cap for SMEs and start-ups.

Where the documentation touches legal professional privilege or heightened confidentiality, separate it from day one. We wrote up that pattern in our solutions for law firms. If what you want is the minimum package an Annex III system can launch with, that is our high-risk AI compliance checklist, and the classification work plus audit preparation sits inside our EU AI Act compliance service.

What if your system is not high-risk?

If the system falls under one of the Annex III points but you rely on the Article 6(3) derogation to treat it as not high-risk, Article 6(4) requires you to document that assessment before placing it on the market or putting it into service, and to register the system under Article 49(2). The documentation has to be produced on request. The derogation is never available where the system performs profiling of natural persons.

There are four derogation cases: the system performs a narrow procedural task, it improves the result of a previously completed human activity, it detects decision patterns or deviations from prior decision patterns without replacing or influencing the human assessment without proper human review, or it performs a preparatory task. Each comes with the condition that the system does not pose a significant risk of harm to health, safety or fundamental rights.

The derogation memo is a short document, but it is worth structuring strictly: the intended purpose of the system, which Annex III point could apply, which derogation case applies and why, why there is no profiling, what risk analysis supports the absence of significant risk, who signed it and when, and when it has to be reassessed. That is our recommended structure, not a statutory form.

Article 6(5) requires the Commission to issue guidelines on the practical distinction between high-risk and non-high-risk systems. The Digital Omnibus moved that deadline to 2 August 2027. Until then, classification rests on your own responsibility and your own reasoning, which in our reading argues for caution: in a borderline case, treating a system as high-risk is more expensive but defensible, while a wrong derogation lands under Article 99.

The omnibus kept the registration duty for Annex III systems self-assessed as not high-risk, with a lighter administrative footprint. The obligation did not disappear; there are simply fewer fields to fill in.

What to take away

This article is written for information on the basis of the sources cited, and it does not replace a legal opinion on a specific system. Classification and the content of the documentation differ from system to system, and national implementing rules are still moving.