We'd like to set analytics cookies to measure which pages are useful. They are not needed to run the site, and declining changes nothing about what you can do here. Privacy Policy.
The technical file is the evidentiary backbone of high-risk compliance: it is the document that demonstrates the system meets the Chapter III requirements, and the first thing a market-surveillance authority asks for.
Every template on this page is readable in full right here, copyable as Markdown, and downloadable as a PDF. No sign-up, no e-mail address, no click-to-reveal.
Not an official document. This is a working draft built from the text of Regulation (EU) 2024/1689 — it is not issued or endorsed by the European Commission, any national authority or any notified body, and it is not legal advice. Fill it in with your own facts and have it reviewed by counsel before you rely on it.
The provider — whoever develops the high-risk system, or has it developed, and places it on the market under their own name. Under Article 25 a deployer who rebrands or substantially modifies a high-risk system becomes the provider and inherits this duty.
Before the system is placed on the market or put into service, and kept current for as long as it is on the market.
Annex III high-risk obligations apply from 2 December 2027. Systems that are safety components of Annex I products follow the timeline of their product legislation.
Article 11 — Article 11, Annex IV
Article 11 requires the provider of a high-risk AI system to draw up the technical documentation before the system is placed on the market or put into service, and to keep it up to date. Annex IV sets out what the file must contain.
Writing the file once, at launch, and never touching it again. Article 11 requires it to be kept up to date, and section 6 exists precisely so lifecycle changes are recorded — an undated file with no change history is a finding on its own.
9 sections. Each one carries what to write and — the part templates normally leave out — what an assessor is looking for when they read it.
Intended purpose, provider, versions, how it interacts with hardware/software, deployment forms, and the market it is placed on.
That the intended purpose written here matches the one in your marketing, your instructions for use and your Annex VIII registration entry. Divergence between those four is the fastest way an assessor finds a problem.
Design specifications, system architecture, computational resources, data requirements, training methodologies, and the human oversight assessment.
Traceability: that design choices, architecture and training methodology are described concretely enough that a third party could follow how the system was built, and that the human-oversight design is a decision with reasons, not a sentence.
Capabilities and limitations, expected accuracy for specific persons/groups, foreseeable unintended outcomes, and the human oversight measures in place.
Named limitations. A file that lists capabilities but no foreseeable failure modes, and no accuracy figure broken down by the groups the system affects, reads as untested.
Why the chosen performance metrics are appropriate for this system.
Why these metrics and not others. Accuracy alone on an imbalanced population is the classic finding — expect to justify the choice against the harm the system can cause.
Description of the risk management system per Article 9: identified risks and the mitigation measures adopted.
Evidence that Article 9 is a running process: dated risk entries, the mitigations adopted, and the residual risk someone accepted by name.
Relevant changes made to the system through its lifecycle and their justification.
A dated change log, and a judgement recorded for each entry on whether the change was a substantial modification — because that triggers a fresh conformity assessment under Article 43.
Standards applied in full or in part; where none apply, the technical solutions adopted to meet the requirements.
Which standards, in full or in part. Where none were applied, the technical solution adopted instead has to be described — 'none' on its own is an unanswered question.
A copy of, or reference to, the EU declaration of conformity.
That the declaration exists, is signed, and identifies the same system version this file describes.
The system in place to evaluate performance in the post-market phase.
That the plan names data sources, thresholds and an owner, and that it connects to the Article 73 incident route rather than stopping at 'we monitor performance'.
The same document in two portable forms. The Markdown pastes into Notion, Confluence, Google Docs or a repository; the PDF is laid out to be printed and written on, with ruled fill-in areas and a sign-off block.
# Annex IV technical documentation
**Legal basis:** Article 11, Annex IV — Regulation (EU) 2024/1689 (EU AI Act).
> Not an official document. This is a working draft built from the text of Regulation (EU) 2024/1689 — it is not issued or endorsed by the European Commission, any national authority or any notified body, and it is not legal advice. Fill it in with your own facts and have it reviewed by counsel before you rely on it.
**Who fills this in:** The provider — whoever develops the high-risk system, or has it developed, and places it on the market under their own name. Under Article 25 a deployer who rebrands or substantially modifies a high-risk system becomes the provider and inherits this duty.
**When:** Before the system is placed on the market or put into service, and kept current for as long as it is on the market.
| Field | Value |
| --- | --- |
| Organisation | |
| AI system | |
| Version / reference | |
| Document owner | |
| Date | |
| Version of this document | |
## 1. General description of the AI system
*What to write:* Intended purpose, provider, versions, how it interacts with hardware/software, deployment forms, and the market it is placed on.
*What an auditor looks for:* That the intended purpose written here matches the one in your marketing, your instructions for use and your Annex VIII registration entry. Divergence between those four is the fastest way an assessor finds a problem.
_[Your text here]_
## 2. Elements and development process
*What to write:* Design specifications, system architecture, computational resources, data requirements, training methodologies, and the human oversight assessment.
*What an auditor looks for:* Traceability: that design choices, architecture and training methodology are described concretely enough that a third party could follow how the system was built, and that the human-oversight design is a decision with reasons, not a sentence.
_[Your text here]_
## 3. Monitoring, functioning and control
*What to write:* Capabilities and limitations, expected accuracy for specific persons/groups, foreseeable unintended outcomes, and the human oversight measures in place.
*What an auditor looks for:* Named limitations. A file that lists capabilities but no foreseeable failure modes, and no accuracy figure broken down by the groups the system affects, reads as untested.
_[Your text here]_
## 4. Appropriateness of performance metrics
*What to write:* Why the chosen performance metrics are appropriate for this system.
*What an auditor looks for:* Why these metrics and not others. Accuracy alone on an imbalanced population is the classic finding — expect to justify the choice against the harm the system can cause.
_[Your text here]_
## 5. Risk management system
*What to write:* Description of the risk management system per Article 9: identified risks and the mitigation measures adopted.
*What an auditor looks for:* Evidence that Article 9 is a running process: dated risk entries, the mitigations adopted, and the residual risk someone accepted by name.
_[Your text here]_
## 6. Changes through the lifecycle
*What to write:* Relevant changes made to the system through its lifecycle and their justification.
*What an auditor looks for:* A dated change log, and a judgement recorded for each entry on whether the change was a substantial modification — because that triggers a fresh conformity assessment under Article 43.
_[Your text here]_
## 7. Harmonised standards applied
*What to write:* Standards applied in full or in part; where none apply, the technical solutions adopted to meet the requirements.
*What an auditor looks for:* Which standards, in full or in part. Where none were applied, the technical solution adopted instead has to be described — 'none' on its own is an unanswered question.
_[Your text here]_
## 8. EU declaration of conformity
*What to write:* A copy of, or reference to, the EU declaration of conformity.
*What an auditor looks for:* That the declaration exists, is signed, and identifies the same system version this file describes.
_[Your text here]_
## 9. Post-market monitoring plan
*What to write:* The system in place to evaluate performance in the post-market phase.
*What an auditor looks for:* That the plan names data sources, thresholds and an owner, and that it connects to the Article 73 incident route rather than stopping at 'we monitor performance'.
_[Your text here]_
---
Template by Conformly — getconformly.com/templates/annex-iv-technical-documentation. Free to copy and adapt. Not an official document. This is a working draft built from the text of Regulation (EU) 2024/1689 — it is not issued or endorsed by the European Commission, any national authority or any notified body, and it is not legal advice. Fill it in with your own facts and have it reviewed by counsel before you rely on it.
The provider's signed statement that a high-risk AI system conforms — one page, kept for ten years, produced on request.
One row per AI system, with the columns the EU database will ask for — so the register you keep internally is the register you can file from.
How you will know the system is still behaving after launch — sources, thresholds, owners, and the route to an incident report.
Not sure this document is yours to write? Classify the system first — or browse all 7 templates.