AI Act Technical Documentation
Annex IV of the EU AI Act translated point by point into engineering deliverables, plus the logging and retention duties in Article 12, Article 19 and Article 26 and the unconfirmed SME simplified-documentation route.
Updated
13 min read
114 views
Key takeaways: AI Act technical documentation 5
How the nine points in Annex IV map to engineering artifacts, the two points that break ordinary documentation habits and the retention duties around them.
- Nine points, nine artifacts The nine legal points in Annex IV each map to a specific engineering artifact, from architecture decision records to a training-run manifest, turning a legal list into a backlog.
- Two points break normal documentation habits Signed test reports under point 2(g) and training-compute disclosure under point 2(c) both break documentation habits an ordinary software team already has.
- The SME shortcut is not confirmed yet Point (10) of the Omnibus added an SME simplified-documentation route, but whether the Commission has actually published the required form is unconfirmed, so do not plan a filing around it yet.
- One retention floor, two duty-holders Providers under Article 19 and deployers under Article 26(6) both owe an independent six-month log-retention floor, so compliance on one side never covers the other side.
- Annex IV will change under you Article 11(3) lets the Commission amend Annex IV by delegated act at any time, so a documentation pipeline needs to absorb a new point rather than assume the current nine are final.
In short: EU AI Act technical documentation runs on Annex IV, which lists nine documentation points, untouched by the Digital Omnibus. Article 11(1) requires the file to exist before the system reaches the market and to stay current after that. Assembling it only once a notified body asks for it does not satisfy the duty. Point (10) of the Omnibus adds an SME shortcut, a simplified form notified bodies must accept, though whether the Commission has actually published that form is unconfirmed. Two of the nine points, signed test reports and training-compute accounting, have no real equivalent in ordinary software documentation.
What Article 11 requires, and when
Article 11(1) sets one duty for a high-risk system's provider: draw up the technical documentation before the system reaches the market or is put into service, and keep it current afterward. The Annex IV chapeau frames the nine points that follow as a floor, not a checklist to close out once. The technical documentation, in the statute's own words, "shall contain at least the following information, as applicable to the relevant AI system" under Annex IV. "At least" is doing real work there: a system with more relevant risk surface than Annex IV anticipates does not get to stop at entry nine.
The file must exist before the system reaches the market
Timing is the substantive requirement here, not a formality attached to one. A team that builds a system first and writes the Annex IV file afterward, once legal or a customer's procurement team asks for it, has already missed the duty regardless of how complete the eventual file turns out to be. Article 11(1) ties the file to the moment of market placement or entry into service, not to the moment a notified body or market surveillance authority requests it.
Staying current is a separate duty from writing the file once
A file that was accurate on release day and untouched since is not compliant on day two of a model update. Annex IV point 6 asks for a description of relevant changes made through the system's lifecycle, which only stays true if someone updates it every time a change lands. Article 11(1) frames the whole file as something to keep current, not something filed away once conformity assessment closes. The practical consequence is a documentation pipeline wired into the same release process that ships the system, not a separate task confined to audit season.
Annex IV point by point - the artifact that satisfies it
Legal counsel hands engineering a nine-point list, and nobody on the delivery team maps it into work items by default, because none of the nine points names a file format, a tool or a role. The table below does that translation once, point by point, so a delivery team can turn Annex IV into a backlog rather than a legal reading exercise.
| Annex IV point | What it requires | Engineering artifact | Owner |
|---|---|---|---|
| 1 | General system description: purpose, versions, interfaces, deployment forms, hardware and the user interface | Product overview document plus an architecture decision record index tied to release notes | Product or engineering lead |
| 2 | Development process in detail: architecture, design rationale, training data, human oversight, dated and signed test logs and cybersecurity | C4 diagrams, ADRs, dataset datasheets, a human-oversight design note, signed CI test reports, a threat model and an SBOM | Architects, data engineers, QA and security engineering |
| 3 | Monitoring detail: capabilities, limitations, accuracy by group and foreseeable risks | A model card covering subgroup performance, known limitations and failure modes | ML engineering or a responsible-AI lead |
| 4 | Why the chosen performance metrics fit this system | Evaluation harness documentation defining each metric and its justification | ML engineering |
| 5 | The Article 9 risk management system, in detail | A live risk register tied to the Article 9 process, not a one-time memo | Risk or compliance lead with engineering input |
| 6 | Changes made through the system's lifecycle | A version-tagged change log and release notes | Release management |
| 7 | Harmonized standards applied, or the alternative solutions adopted | A requirement-to-control mapping against Chapter III, Section 2 | Compliance engineering or the system architect |
| 8 | A copy of the EU declaration of conformity | The signed declaration itself, filed once conformity assessment closes | Compliance or legal, with provider sign-off |
| 9 | The post-market monitoring system and plan | A monitoring dashboard plus the written plan Article 72(3) requires | SRE or MLOps with product |
Point 2 carries eight sub-points of its own and is the heaviest single row in the table for a reason: it is where architecture, training data and testing all live together, where two artifacts that ordinary software documentation skips, signed test reports and compute accounting, first appear, and where a third point most teams currently satisfy by having nothing to cite also sits.
Three points that break ordinary engineering practice
Most of Annex IV maps onto documentation habits an engineering team already has in some form: architecture notes, release notes, a risk log. Three points do not, and treating them as ordinary paperwork is why they get skipped.
Point 2(g), test reports dated and signed by name
Annex IV point 2(g) requires "test logs and all test reports dated and signed by the responsible persons." Ordinary CI output carries a timestamp and a pass or fail status, not a named signature attached to a specific person taking responsibility for the result. Satisfying point 2(g) means a pipeline that captures who reviewed and accepted a test run, not only that the run happened, and a process for "the responsible persons" to mean something specific inside the team rather than a generic service account.
Accounting for the compute spent training the model, point 2(c)
Point 2(c) requires disclosure of "the computational resources used to develop, train, test and validate the AI system" alongside the architecture description. Few teams track training compute as a deliverable the way they track cost in a cloud bill. A training run manifest recording hardware, run duration and total compute for every version that shipped is the artifact this point actually asks for, kept per version rather than as a one-time estimate. Our LLM fine-tuning guide covers the training-run side of that manifest in more depth, including what a run actually needs to log.
When no standard exists to name, point 7
Point 7 asks for "a list of the harmonised standards applied in full or in part the references of which have been published in the Official Journal of the European Union." Where no such standard has been applied, it asks instead for "a detailed description of the solutions adopted to meet the requirements set out in Chapter III, Section 2." Harmonized standards written specifically for the AI Act are still emerging, so the second branch is the live path for most teams today: no standard exists yet to name, and skipping the description for that reason inverts what the point actually asks for.
Why retrospective assembly fails
Some Annex IV points survive being written after the fact. A current system's architecture can be reconstructed slowly and imperfectly from the code. Others cannot. Design rationale and trade-offs, point 2(b)'s territory, exist only in the heads of whoever made the decision, and six months later nobody remembers why option B lost to option A. Dataset provenance under point 2(d) is the same problem one layer down: once a dataset has been merged and filtered twice more, its row-level origin is not recoverable. Training-run compute under point 2(c) is measurable only while the run is happening, not after the cluster has been torn down. Test logs tied to a specific version disappear the moment CI retention expires or a pipeline gets rebuilt without preserving history. None of these four is hard to capture at the time. All four are close to impossible to reconstruct months later, which is the real case for continuous documentation over a pre-audit scramble.
The SME simplified-documentation route
What point (10) actually added to Article 11(1)
Point (10) of the amending act replaces the second subparagraph of Article 11(1). The new wording keeps the same nine-point content of Annex IV in place and adds a delivery option on top of it for small and medium enterprises (SMEs), start-ups and small mid-cap companies (SMCs): "SMEs, including start-ups, and SMCs, may provide the elements of the technical documentation specified in Annex IV in a simplified manner. To that end, the Commission shall establish a simplified technical documentation form targeted at the needs of SMEs, including start-ups, and SMCs. Where an SME, including a start-up, or an SMC, opts to provide the information required in Annex IV in a simplified manner, it shall use the form referred to in this paragraph. Notified bodies shall accept the form for the purposes of the conformity assessment." Annex IV itself is not shortened, only the format a provider may use to present it.
Whether the Commission's simplified form exists yet
The duty on the Commission to produce that form is real. Whether the form has actually been published is a separate question, and this article does not confirm an answer either way. Do not plan a documentation build around a form that may or may not exist yet, and verify its current status against the Commission's own AI Act page before relying on the SME route for a real filing.
Logging, retention and who owes what
Article 12, automatic logging over the system's lifetime
A high-risk system must technically allow the automatic recording of events over its lifetime under Article 12, a capability built into the system rather than bolted on with an external log shipper after deployment. Treating logging as an observability feature a platform team adds later, rather than a compliance-relevant capability the system must support from its first version, is the most common gap here. Our state of production AI engineering coverage looks at the same logging surface from the operations side, including what a production AI system needs to emit before anyone asks for Annex IV evidence.
Article 12(3), the minimum log schema for remote biometric identification
Remote biometric identification systems under Annex III point 1(a) carry a minimum log schema written directly into the statute. Each use needs a logged period covering the start and end date and time, the reference database checked against, the input data that produced a match and the identification of the natural persons involved in verifying the results. A generic application log rarely captures all four fields together, which makes this a schema design decision, not a logging-level toggle.
Article 19, the provider's six-month retention floor
Article 19(1) sets the provider's duty plainly. Providers "shall keep the logs referred to in Article 12(1), automatically generated by their high-risk AI systems, to the extent such logs are under their control," and "the logs shall be kept for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in the applicable Union or national law." Six months is a floor rather than a target. "A period appropriate to the intended purpose" can push the real number well past it for a system with a longer risk tail.
Article 26(6), the deployer's matching floor
Article 26(6) sets the same six-month minimum on the deployer side of the relationship, independently of what the provider does. That independence is the point worth engineering around: a provider retaining logs for six months and a deployer assuming the provider already covers it are both compliant on paper and both wrong about who actually holds the data a market surveillance authority might ask for. Retention needs its own owner on each side, not an assumption that the other party has it handled.
The fixed 10-year floor for the file itself, under Article 18
Under Article 18(1), the provider must "keep at the disposal of the national competent authorities" a list of five items "for a period ending 10 years after the high-risk AI system has been placed on the market or put into service." The first item on that list is "the technical documentation referred to in Article 11," and the EU declaration of conformity referred to in Article 47 is item (e), so the two files share one retention clock. Bankruptcy or ceasing activity does not shorten the clock either: Article 18(2) puts the burden on each Member State to determine how the documentation "remains at the disposal of the national competent authorities for the period indicated in that paragraph" if a provider or its authorized representative "goes bankrupt or ceases its activity prior to the end of that period."
Two different retention models in one regime
Logs and documentation do not share a retention model, and treating them as one clock is an easy way to under-plan a data-retention budget. The logging floor covered above under Article 19 is a variable minimum keyed to what the high-risk system is for, at least six months and often longer depending on intended purpose. File retention under Article 18 runs on a fixed 10 years instead, keyed to a different event entirely: when the system was placed on the market or put into service, not what the system does. Article 47(1) repeats the same fixed period for the declaration of conformity by name, "for 10 years after the high-risk AI system has been placed on the market or put into service." One regime, two clocks: a purpose-keyed floor for logs and a placement-keyed decade for the paperwork.
Annex IV is a moving target under Article 11(3)
The nine points are not fixed the way a stable file format would be. Article 11(3) gives the Commission the power to amend Annex IV by delegated act, which means a documentation pipeline hardcoded to today's nine points is building against a snapshot rather than a floor. The Omnibus did not touch Annex IV this round, but the delegation power that could touch it next round was never repealed. A pipeline built as nine fixed template sections needs a rewrite the day a tenth point appears. One built as a mapping from named requirements to artifacts, the same shape as the table above, absorbs a new point by adding a row.
A documentation build checklist by system lifecycle stage
Assembling Annex IV evidence at the stage it is actually produced, rather than backfilling it before a conformity assessment, is what makes the six-month retention floor and the signed-test-report requirement both achievable in practice.
- Design: capture architecture decisions and trade-offs as ADRs the day they are made.
- Data collection: log provenance, scope, labeling procedure and cleaning steps for every dataset the moment it enters the pipeline, before a third reprocessing pass makes the origin unrecoverable.
- Training: record hardware, run duration and total compute per run.
- Testing: generate signed, dated test reports as a CI output, with a named responsible person attached to each run rather than added weeks later once someone remembers to ask for a signature.
- Pre-market: confirm every Annex IV point has a current artifact behind it.
- Post-market: keep the monitoring plan running and the six-month retention floor live on both sides of the provider-deployer relationship.
How Pharos Production builds Annex IV-ready documentation pipelines
Signed test reports and training-run compute figures are only capturable while the work is happening, so a documentation pipeline for Annex IV has to sit inside the same release process that ships the system, not assembled separately before an assessment.
Our custom software development practice wires ADR capture, dataset datasheets, signed test reporting and compute accounting into that release process. Our AI governance practice takes the resulting artifacts and turns them into a file a notified body can assess against Annex IV, point by point.
Sources: Regulation (EU) 2024/1689 (the EU AI Act), Articles 11, 12, 18, 19, 26 and 47, plus Annex IV, via EUR-Lex; Regulation (EU) 2026/1744 of 8 July 2026 (the Digital Omnibus on AI), point (10), via EUR-Lex, ELI data.europa.eu/eli/reg/2026/1744/oj; and the European Commission's AI Act regulatory framework page, observed 28 July 2026. This article is engineering guidance, not legal advice. Confirm every requirement against the primary text with qualified counsel before you rely on it.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 7
No matches
Try a different keyword, change the topic or clear filters
-
Annex IV is the nine-point technical documentation list the EU AI Act sets for high-risk systems, covering everything from a general system description to the post-market monitoring plan. The Digital Omnibus did not amend Annex IV at all, so all nine points remain exactly as originally published.
Article 11(1) is the provision that actually requires the file, with Annex IV setting what it must contain.
-
The Annex IV file must exist before the high-risk system is placed on the market or put into service, under Article 11(1). Writing it afterward, once a customer or a notified body asks for it, already misses the duty regardless of how complete the eventual file turns out to be.
Article 11(1) also requires the file to stay current, so a version that was accurate on release day and untouched since is not compliant once the system changes.
-
Annex IV point 2(c) requires disclosure of the computational resources used to develop, train, test and validate the AI system. Few engineering teams track training compute as a deliverable the way they track cost in a cloud bill, which makes this point unusual against ordinary software documentation practice.
The practical artifact is a training-run manifest recording hardware, run duration and total compute for every version shipped, since compute is measurable only while the run is happening and close to impossible to reconstruct afterward.
-
Yes, Annex IV point 2(g) requires test logs and test reports to be dated and signed by the responsible persons. Ordinary continuous-integration output carries a timestamp and a pass or fail status, not a named signature attached to a specific person taking responsibility for the result, which is why this point breaks a habit most engineering teams already have.
Satisfying it means building a pipeline that captures who reviewed and accepted each test run, not only that the run happened.
-
Point (10) of the Digital Omnibus added a route letting small and medium enterprises, start-ups and small mid-cap companies supply Annex IV elements in a simplified manner, using a form the Commission is required to establish and that notified bodies must accept. Whether the Commission has actually published that form yet is unconfirmed, and this answer does not assert either way.
The nine points in Annex IV are not shortened by this route, only the format a qualifying provider may use to present them, so verify the current status of the form before planning a filing around it.
-
AI system logs must be retained for at least six months, a floor set independently on both sides of the relationship. Article 19 sets that six-month minimum for the provider, and Article 26(6) sets the identical six-month minimum for the deployer, so retention on one side never excuses the other side.
Six months is a floor rather than a target, since the appropriate period can run longer depending on what the system is intended for.
-
Yes, Article 11(3) gives the Commission the power to amend Annex IV by delegated act, so the nine current points are not fixed the way a stable file format would be. The Omnibus did not use that power this round, but the power itself was never repealed.
A documentation pipeline built as a mapping from named requirements to artifacts absorbs a new point by adding a row, while one hardcoded to nine fixed template sections needs a rewrite the day a tenth point appears.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
