Article 11 · Annex IV · Word template
As of 3 October 2026 · after the Digital Omnibus
EU AI Act Documentation: Annex IV Explained – with a Word Template
If you provide a high-risk AI system, you must draw up technical documentation under Annex IV before it is placed on the market and keep it up to date afterwards. This page covers all nine points of Annex IV with guiding questions, typical gaps and example wording – plus a Word template to fill in, free and without an email address.
391 days until the obligations for high-risk AI under Annex III apply (2 December 2027).
- All 9 points of Annex IV
- Fill-in guidance and tables
- Providers, deployers, GPAI
- SME simplification explained
Technical documentation
Annex IV · Article 11 AI Act
- 1General description100%
- 2Development and data80%
- 3Performance and limits65%
- 4Metrics100%
- 5Risk management70%
- 6Changes40%
- 7Standards55%
- 8Declaration of conformity0%
- 9Post-market monitoring30%
Export as PDF or DOCX · with audit history
Short answer
Technical documentation under Article 11 of the AI Act is mandatory for providers of high-risk AI systems. It is drawn up before the system is placed on the market or put into service, kept up to date across the lifecycle and must cover at least the nine points of Annex IV: system description, development and data, performance and limitations, metrics, risk management, changes, standards applied, the declaration of conformity and post-market monitoring. It is kept for ten years. SMEs and start-ups may use a simplified form. Deployers do not draw up technical documentation, but have their own record-keeping duties.
- points in Annex IV
- 9
- points in Annex IV
- retention by the provider (Art. 18)
- 10 yrs
- retention by the provider (Art. 18)
- minimum log retention by deployers (Art. 26)
- 6 mo.
- minimum log retention by deployers (Art. 26)
- Annex III high-risk rules apply
- 2 Dec 2027
- Annex III high-risk rules apply
Roles
Who has to document what?
Technical documentation under Annex IV is a provider obligation. Other roles document too – but something else, less, or under a different annex.
Scroll the table sideways →
| Role | What to document | Scope | Basis |
|---|---|---|---|
| Provider of a high-risk AI system | Technical documentation covering all nine points of Annex IV, drawn up before placing on the market or putting into service and kept up to date. Includes risk management, test reports, the declaration of conformity and the post-market monitoring plan. | FullFull, SMEs in simplified form | Art. 11, Annex IV, Art. 18 |
| Deployer of a high-risk AI system | No technical documentation. Instead keep traceable records of: use according to the instructions, the people assigned to human oversight, relevance of input data, monitoring of operation, information given to workers, retained logs. Certain deployers also carry out a fundamental rights impact assessment. | Own recordsOwn operational records | Art. 26, Art. 27 |
| Provider of a general-purpose AI model | Technical documentation of the model under Annex XI, including its training, testing and evaluation results – not Annex IV. Plus information for providers who integrate the model into their own systems. | FullSeparate annex (XI) | Art. 53(1)(a) |
| Provider relying on the Article 6(3) exemption | If a system falls under Annex III but in your assessment poses no significant risk, document that assessment before placing it on the market and provide it to the authority on request. Annex IV documentation is then not required. | LightAssessment in writing | Art. 6(3) and (4) |
| Providers and deployers with transparency duties | No technical documentation. A short record of how you inform people that they are interacting with AI, and how AI-generated or manipulated content is labelled, is still useful. | LightInternal record recommended | Art. 50 |
Anyone who puts their name on someone else’s high-risk system, substantially modifies it or changes its intended purpose so that it becomes high-risk may become a provider themselves (Article 25) – with all documentation duties.
So the role comes first, then the risk class. Many organisations are both: deployers of purchased tools and providers of their own product. Then both rows apply, but to different systems.
Where a high-risk system is also part of a product covered by the Union harmonisation legislation in Annex I (for example machinery or medical devices), a single set of technical documentation is kept, containing the Annex IV information and what the product legislation requires. Those systems are covered from 2 August 2028; Annex III systems from 2 December 2027.
Annex IV
The 9 points of Annex IV – what goes into each
Each card paraphrases one point and adds what is asked in practice, where documentation usually falls short and what usable wording looks like.
Annex IV point 1
What goes in
- Intended purpose, provider name and a version that shows its relation to earlier versions
- Interaction with hardware, software and other AI systems that are not part of the system
- Relevant software and firmware versions and requirements for updates
- Forms of placing on the market (SaaS, API, software package, embedded) and target hardware
- Illustrations where the system is part of a product; a description of the user interface
- Instructions for use for deployers
Guiding questions
- Could a non-specialist reviewer explain after one page what the system is for – and what it is not for?
- Which external models or services does the system call, in which version?
- How do deployers learn about updates, and which updates change behaviour?
Typical gap
The intended purpose stays vague ("supports HR processes"). Yet the risk class, tests and limitations all depend on it. A fuzzy intended purpose weakens every later section.
Example wording "The system ranks incoming applications for advertised positions by fit with the job profile. It supports pre-screening by recruiters; rejections without human review are not intended. Use for internal promotions is not intended."
Section in the template: 1
Annex IV point 2
What goes in
- Development methods and steps, including the use of pre-trained systems or third-party tools
- Design specifications: logic, algorithms, key design choices with rationale and assumptions, optimisation goal, trade-offs
- System architecture and computational resources used
- Data requirements and datasheets: provenance, scope, selection, labelling, cleaning
- Assessment of the human oversight measures under Article 14
- Pre-determined changes, validation and testing procedures with metrics, dated and signed test reports, cybersecurity
Guiding questions
- Which design choice would you make differently today – and is the original rationale documented?
- Where do the training data come from, who labelled them and what was filtered out?
- Which metrics measure potentially discriminatory impacts?
- Are the test reports dated and signed by the responsible persons?
Typical gap
Datasheets are missing or only state the size ("2m records"), not provenance, selection and cleaning. Just as common: test results live in notebooks, without a date, version or approval.
Example wording "Training dataset T-2026-03: 412,000 anonymised applications from 2021–2025 from three customers with consent to use. Labelled by two trained recruiters per record, disagreements decided by a third person. Removed: duplicates (3.1%) and applications without a vacancy reference (0.8%)."
Section in the template: 2
Annex IV point 3
What goes in
- Capabilities and limitations in performance, expected overall accuracy
- Accuracy for the specific persons or groups of persons the system is intended to be used on
- Foreseeable unintended outcomes and sources of risk to health, safety, fundamental rights and of discrimination
- Human oversight measures and technical aids for interpreting the outputs
- Input data specifications
Guiding questions
- For which groups is the system measurably worse – and what follows for its use?
- What happens with inputs outside the specification?
- How does the deployer recognise an output it should not trust?
Typical gap
Only one overall accuracy figure is given. Annex IV explicitly asks for accuracy for the groups affected – and that is exactly where bias shows.
Example wording "Top-10 hit rate overall 87%. For applications with CV gaps over 12 months 79%. The interface therefore flags these applications and never ranks them below position 50."
Section in the template: 3
Annex IV point 4
What goes in
- Chosen performance metrics with target values
- Rationale for why the metrics fit the intended purpose
- Limits of the metrics and complementary measures
Guiding questions
- Would a good metric still look good if the system failed in use?
- Do the metrics match the cost of an error – false positive or false negative?
Typical gap
Metrics are listed but not justified. With imbalanced classes in particular, high accuracy says little.
Example wording "We measure recall@10 rather than accuracy, because missing a suitable candidate weighs more than an unsuitable one in the shortlist. We also measure the recall@10 difference between genders and age groups; threshold: at most 5 percentage points."
Section in the template: 4
Annex IV point 5 · Art. 9
What goes in
- Process: identifying, assessing, treating and reviewing risks
- Responsibilities, review cadence and triggers for updates
- Risk register with measures and residual risks (extract or reference)
- Tests showing the measures are effective
Guiding questions
- When was the risk register last changed – and why?
- Who decides whether a residual risk is acceptable?
- Do lessons from operation flow back into the register?
Typical gap
Risk management is a one-off spreadsheet from the development phase. Article 9 requires a continuous, iterative process.
Example wording "The risk register is reviewed for every model version, every reported incident and at least quarterly. Residual risks rated 'high' require sign-off by the head of product."
Section in the template: 5
Annex IV point 6
What goes in
- Change log with date, version and description
- Assessment of whether a change is substantial
- Consequences: reassessment, new tests, possibly a new conformity assessment
Guiding questions
- When does a model update count as a substantial modification for you?
- Can you tell for each shipped version which documentation version applied?
Typical gap
The change log lives in the ticket system or Git, but the documentation does not refer to it. Then the assessment of which change was substantial is missing.
Example wording "Version 2.3 (14/09/2026): retrained with Q2/2026 data, architecture unchanged. Assessment: not a substantial modification, as intended purpose and metrics remain within the set thresholds. Tests T-31 to T-34 repeated."
Section in the template: 6
Annex IV point 7
What goes in
- List of harmonised standards applied, with their reference in the Official Journal
- Where none were applied: a detailed description of the solutions adopted for the requirements of Chapter III, Section 2
- Other relevant standards and technical specifications
Guiding questions
- Which requirement (Articles 8–15) is not covered by a standard – and how do you meet it?
- Who tracks newly published harmonised standards?
Typical gap
The section stays empty because "there are no standards yet". That is exactly when Annex IV asks for a detailed description of your own solutions.
Example wording "No harmonised standard was applied for accuracy and robustness (Article 15). Solution: defined metrics (section 4), robustness tests against changed input formats (T-20 to T-24) and monitoring under section 9."
Section in the template: 7
Annex IV point 8 · Art. 47
What goes in
- Copy of the EU declaration of conformity under Article 47 (content per Annex V)
- Link to system version and date
- Update when a new version is issued
Guiding questions
- Does the declaration match the version currently shipped?
- Where is the signed original kept?
Typical gap
The declaration is naturally the last document. If it is not updated later, the documentation points to an outdated version.
Example wording "EU declaration of conformity no. DC-2027-01 dated 15/11/2027 for version 3.0, signed by the managing director; original in the contract archive, copy as annex A6."
Section in the template: 8
Annex IV point 9 · Art. 72
What goes in
- Description of the post-market monitoring system
- The plan under Article 72(3) with signals, sources, frequency, thresholds and actions
- Link to serious incident reporting under Article 73
Guiding questions
- Which operational data do you receive – and which only if deployers supply them?
- What happens when a metric breaches its threshold in operation?
Typical gap
There is a monitoring dashboard but no plan: thresholds, owners and responses are not written down anywhere.
Example wording "Monthly: recall@10 on a sample of 500 cases rated by recruiters; threshold 82%. If breached: analysis within 10 working days by the ML team, deployers informed, reporting duty checked."
Section in the template: 9
Paraphrased summary. Only the wording of Annex IV to Regulation (EU) 2024/1689 is authoritative. The examples are invented and only show the level of detail.
Word template
The Annex IV template to fill in
There is plenty of legal text and guidance on Annex IV – but hardly a file you can type into. Our template follows Annex IV point by point and works in Word, LibreOffice or Google Docs.
Template · Regulation (EU) 2024/1689
Technical documentation · Annex IV
DOCX · 24 KB · English · status 3 October 2026
- 1General description of the AI system
- 2Elements and development process
- 3Monitoring, functioning and control
- 4Appropriateness of the performance metrics
- 5Risk management system
- 6Changes through the lifecycle
- 7Harmonised standards applied and other solutions
- 8Copy of the EU declaration of conformity
- 9Post-market monitoring
What is in the file
- Cover page with system, version, provider, date and owners
- Notice box: working aid, not legal advice – Annex IV of Regulation (EU) 2024/1689 is authoritative
- Change history table
- Table of contents as a Word field
- All 9 sections of Annex IV with 30 sub-points as headings
- Fill-in guidance in grey italics to delete before release
- Tables for datasets, tests, metrics, risks, standards and the monitoring plan
- Annex index for instructions for use, datasheets, test reports and the declaration of conformity
Prefer paper?
The print version sums up the structure as a PDF checklist – handy for workshops with engineering and the business side.
Working with the template
- 01One file per AI system and per major version. Record small changes in the change history.
- 02Do not delete points that do not apply – give the reason.
- 03Keep large documents as annexes and reference them with version and location.
- 04Before release, remove all grey guidance and update the table of contents.
Open-Source Framework
simpleact-ai-act-documentation-template
Open-source documentation template per Annex IV of the EU AI Act: all 9 mandatory sections as fillable templates.
Self-assessment
How complete is your documentation?
Rate each of the nine points of Annex IV. You see at once how far you are and get a gap list with the next step for each. Nothing is stored or sent.
- 1General descriptionNot rated yet
- 2Development and dataNot rated yet
- 3Performance and limitsNot rated yet
- 4MetricsNot rated yet
- 5Risk managementNot rated yet
- 6ChangesNot rated yet
- 7StandardsNot rated yet
- 8Declaration of conformityNot rated yet
- 9Post-market monitoringNot rated yet
Documentation status
Annex IV · self-assessment
Completeness
0 %
Getting started
The foundations are still missing. Start with the intended purpose (point 1) and data (point 2) – every other section builds on them.
Gap list
Rate the nine points on the left – your gap list appears here.
The self-assessment is for orientation and is not a conformity check. It replaces neither a conformity assessment nor legal advice.
SMEs and start-ups
Simplified documentation for small companies
Article 11(1) allows SMEs, including start-ups, to provide the Annex IV information in a simplified form. The Commission provides a simplified form for this purpose.
Simplified does not mean less content: the questions of Annex IV stay the same, the presentation may be leaner. A small team describes architecture and processes more briefly and refers to existing documents more often.
The Digital Omnibus (Regulation (EU) 2026/1744, in force since 27 July 2026) extends relief previously reserved for SMEs to small mid-caps. Whether your company qualifies and which relief applies in detail should be checked against the text of the regulation.
Our template follows the full structure. That is deliberate: a complete structure can be shortened to a simplified form, while the reverse often leaves something out. Check whether the Commission’s form is available in its current version, and transfer your content there if you want to use it.
- 01
Same questions
All nine points of Annex IV must be answered – in simplified form too.
- 02
Leaner form
Shorter descriptions, more references to existing documents, less prose.
- 03
Dedicated form
The Commission provides a simplified form for SMEs.
- 04
Small mid-caps
The Digital Omnibus extends relief to small mid-caps; check the scope.
Retention
How long to keep what?
Periods differ by role and document. The longest applies to the provider’s technical documentation.
Scroll the table sideways →
| Document | Who | Period | Basis |
|---|---|---|---|
| Technical documentation | Provider | 10 years after placing on the market or putting into service | Art. 18 |
| Quality management system documentation | Provider | 10 years after placing on the market or putting into service | Art. 18 |
| EU declaration of conformity | Provider | 10 years after placing on the market or putting into service | Art. 18 |
| Automatically generated logs | Provider | to the extent under its control; period per Art. 19 | Art. 19 |
| Automatically generated logs | Deployer | at least 6 months, unless other law provides otherwise | Art. 26(6) |
| Assessment under Art. 6(3) | Provider | provide on request; recommended: same as technical documentation | Art. 6(4) |
The ten years run from placing on the market or putting into service. In practice, every shipped version of the documentation must remain retrievable for that period – not just the current one.
Deployers
What deployers should document
Deployers do not draw up technical documentation. But they carry their own duties under Article 26 – and can only show they meet them with records.
- Art. 26(1)
Use according to instructions
Which instructions for use apply in which version and how you ensure the system is used as intended.
- Art. 26(2)
Human oversight
Who has oversight, with what competence and authority – names, roles, training records.
- Art. 26(4)
Input data
To the extent you control the input data: how you ensure they are relevant and sufficiently representative for the purpose.
- Art. 26(5)
Monitoring of operation
How you monitor operation, report issues to the provider and suspend use where there is a risk.
- Art. 26(6)
Logs
Keep the automatically generated logs, to the extent under your control, for at least six months.
- Art. 26(7)
Informing workers
Inform workers’ representatives and affected workers before use in the workplace – with date and content.
- Art. 27
Fundamental rights impact assessment
For certain deployers, such as bodies governed by public law or private entities providing public services, before first use.
Ask the provider for at least the instructions for use, the information on human oversight, the known performance limits and the information on the declaration of conformity. You need these documents for your data protection impact assessment anyway.
For your own records, an entry per system in your AI register plus a short operations file is often enough: owners, training, monitoring cadence, where the logs are stored.
GDPR
Link to the GDPR: DPIA and records of processing
If a high-risk AI system processes personal data, the AI Act and the GDPR apply side by side. A lot of content can be reused – but not replaced.
Data protection impact assessment
Deployers use the provider’s information under Article 13 AI Act to carry out their DPIA under Article 35 GDPR (Article 26(9)). The description, risks and oversight measures from the technical documentation are the best source for it.
About DPIAsRecords of processing activities
Every processing of personal data by the AI system belongs in the records under Article 30 GDPR – at the provider for training data, at the deployer for its use. Reference the records entry in the datasheets.
About records of processingData provenance and legal basis
Annex IV asks about the provenance and selection of training data. The GDPR additionally asks for the legal basis. Record both in the same datasheet and the documents will not contradict each other.
FRIA and DPIA
Where deployers need a fundamental rights impact assessment under Article 27, it complements a DPIA already carried out. Avoid duplicate work by using the same system description.
Maintenance
Keeping the documentation up to date
Article 11 requires the documentation to stay current. In practice this rarely fails for lack of will – it fails for lack of triggers.
- 01
New model version
Retraining, new architecture or a different base model: review sections 2, 3, 4 and 6, repeat tests.
- 02
New data source
New datasheet, check provenance and legal basis, effect on performance per group.
- 03
Changed intended purpose
New area of use or new user group: check the classification, possibly a substantial modification.
- 04
Incident or complaint
Update the risk register, adjust the monitoring plan, check the reporting duty under Article 73.
- 05
New harmonised standard
Update section 7 and check whether the standard replaces your own solutions.
- 06
Scheduled review
Regardless of triggers, read all sections against the live system at least once a year.
Versioning that survives an audit
- Every version gets a number and a date and is tied to a system version.
- Old versions are archived, not overwritten – retrievable for ten years.
- The change history names section, change, trigger and approval.
- Substantial modifications are flagged as such and linked to the follow-up decision.
Tools
Word template or software?
For a single system and a manageable team, a well-kept Word file is a solid start. With several systems and versions, the balance tips.
| Aspect | Word / Excel | Compliance software |
|---|---|---|
| Getting started | Immediately, no cost | Setup needed |
| Versions | Manual, file names and folders | Every version tracked automatically |
| Link to inventory and risk | References maintained by hand | Directly on the captured system |
| Change triggers | Someone has to remember | Reminders and tasks |
| Export for review | Hand over the file | Export as PDF/DOCX with history |
If you document several systems, SimpleAct keeps the Annex IV structure right on the system in the AI inventory – with owners, audit history and export.
See documentation in SimpleActFAQ
Frequently asked questions about technical documentation
More questions? We're happy to help. Send email · Try 7 days (credit card required)
Sources and status
Last reviewed on · SimpleAct editorial team
- Regulation (EU) 2024/1689 (AI Act), EUR-Lex
- Regulation (EU) 2026/1744 (Digital Omnibus on AI), EUR-Lex
This page and the template are for orientation and are not legal advice. Annex IV is paraphrased; the wording in the Official Journal of the EU is authoritative.
Changes to this page
- 3 October 2026 – Merged with /ai-documentation. New: free Word template, all 9 points of Annex IV with guiding questions and examples, roles table, self-assessment, SME simplification and deadlines after the Digital Omnibus.
- 23 May 2026 – Guide with PDF template.
Further reading
- Annex III: high-risk areas
- EU AI Act overview
- Determine risk classes
- EU AI Act deadlines after the Digital Omnibus
- AI register template (Excel)
- AI register: duties & setup
- High-risk AI checklist
- Deployer obligations under Article 26
- Fundamental rights impact assessment (Art. 27)
- AI policy: Word template for internal use
- AI literacy: training matrix and attendance record
Documentation that grows with the system
SimpleAct keeps the Annex IV structure right on the captured AI system – with risk classification, owners, audit history and export for review.