What AI Act technical documentation is
Technical documentation is the structured body of information describing a high-risk AI system and demonstrating how it meets applicable requirements.
It is not one isolated document or a user manual. It may combine specifications, records, reports, diagrams, assessments, test results, data documentation, control evidence, procedures and change records.
What it is for
Demonstrating conformity
It should show how applicable requirements are met.
Supporting assessment
It must give competent authorities, notified bodies, auditors and internal owners clear and complete information.
Maintaining traceability
It should explain how the system evolved and connect requirement → control → test → result → evidence.
When it must be created and updated
Article 11 requires technical documentation before the system is placed on the market or put into service, and requires it to remain up to date.
It should accompany development rather than be reconstructed at the end. Version, model, data, purpose, supplier, architecture and control changes may require an update through AI system change management.
General description of the system
Annex IV begins with a general description, which may include intended purpose, provider, version, previous versions, market route, interfaces, hardware, software and dependencies.
It should answer: which system exactly is being assessed? This matters where multiple models, APIs, suppliers, components and versions are involved.
Intended purpose and scope
Document what the system does, for whom, in what context, for which purpose and within which limits.
Intended purpose shapes risk, AI Act classification, performance, oversight and obligations.
Architecture, software, hardware and integrations
The file may describe architecture, components, software, firmware, hardware, APIs, integrations, interfaces and external systems.
It need not reproduce the code repository, but it should explain operation, external dependencies, third-party services, reused components and foundation models clearly enough for effective assessment.
Development, data and training
Where training is involved, document data origin, preparation, cleaning, labelling, selection, quality, representativeness, training, validation and testing.
Known limitations, bias, assumptions and exclusions may also be needed so that data influence on system behaviour can be understood.
Risks and mitigation measures
Connect the technical file to AI risk management: identified risks, likelihood, impact, treatment, controls, residual risk and acceptance.
Reasonably foreseeable misuse, fundamental rights, security and health may also be relevant. Risks should be visibly translated into measures.
Testing, metrics and validation
Include testing, validation, metrics, acceptance criteria and results. Depending on the system, accuracy, robustness, security, stability, bias, performance and resilience may matter.
The file should state what was tested, how, against which criteria and with what result.
Human oversight
Where applicable, describe human oversight: roles, responsibilities, available information, intervention, override, escalation, stopping and training.
Saying “a person reviews it” is not enough; their authority and practical options should be clear.
Logs, traceability and monitoring
High-risk systems must technically enable automatic event logging. The documentation may describe events, timestamps, decisions, versions, users, errors, interventions and incidents.
Logs support monitoring, audit and investigation. They connect to technical documentation but are not the same thing, and neither replaces instructions for use.
What technical documentation should contain
Annex IV minimum elements can be organised as:
1. General description
Purpose, provider, version, interfaces, hardware and software.
2. Development and architecture
Method, design, components and dependencies.
3. Data
Origin, quality, preparation, validation and representativeness.
4. Risk and mitigation
Identified risks, measures and residual risk.
5. Testing and validation
Metrics, criteria and results.
6. Human oversight
Measures, roles and intervention.
7. Security and robustness
Controls, tests and results.
8. Logging and traceability
Events, records and monitoring.
9. Lifecycle management
Changes, versions, incidents and updates.
10. Conformity evidence
Assessments, declarations, results and supporting evidence.
This structure must reflect the actual system; Annex IV is not an identical closed checklist for every system.
How to organise the technical file
A practical file may combine a structured main document, annexes for architecture, data, tests, risks and controls, stable references to evidence, version control and named owners.
Avoid both one unmaintainable document and hundreds of unstructured files. A certificate or product sheet does not replace the technical file.
What changes during the lifecycle
Documentation does not end at production. Model, data, purpose, supplier, version, integration, control, performance or risk changes may trigger review.
A substantial modification may require renewed classification, risk, conformity and conformity assessment. AI vendor management should also provide evidence of supplier changes.
Common mistakes
Creating documentation at the end
Traceability is lost.
Confusing it with instructions for use
They are related but distinct.
Documenting only the model
The system includes data, architecture, people, controls and integrations.
Weak version control or generic templates
The real system and its history cannot be reconstructed.
Failing to connect risk, controls and evidence
The file becomes fragmented and does not demonstrate effectiveness within the AI governance framework.
Failing to update
An outdated technical file quickly loses value.
Technical documentation makes the system assessable
A high-risk system should not be a documentary black box. It should be explainable, reviewable and auditable, showing the path from design → data → risk → testing → controls → decision.
Technical documentation connects these elements so the organisation can demonstrate that it understands and controls the system.
References
- Regulation (EU) 2024/1689 — Artificial Intelligence Act.
- Article 11 — Technical documentation.
- Annex IV — Technical documentation.
- Article 12 — Record-keeping.
- Article 13 — Transparency and provision of information to deployers.
- Article 15 — Accuracy, robustness and cybersecurity.
- Article 43 — Conformity assessment.
Could you demonstrate today how your high-risk AI system works?
Technical documentation should connect design, data, risk, testing, controls and evidence in a coherent and up-to-date structure.
Start the diagnostic →
Céntrika’s diagnostic can help identify what is already in place and where documentation gaps remain.