EU AI Act — Annex IV Technical Documentation
Provider: {{PROVIDER_NAME}} · System: {{SYSTEM_NAME}} · Version: {{VERSION}} · Date: {{ISO_DATE}}
This template implements the structure required by Article 11 + Annex IV of Regulation (EU) 2024/1689. Populated by the provider before the AI system is placed on the EU market. Retained ≥10 years after market placement.
Template by WaveAccess Compliance Check — free reuse, attribution appreciated. For implementation help: compliance.waveaccess.global.
1. General description of the AI system
1.1 Intended purpose
- What the system does (2-3 sentences):
- Primary use cases / Annex III categories:
- End users:
- Geographical scope (EU member states, US, RoW):
- Languages supported:
1.2 Provider information
- Provider name:
- Provider address (EU establishment OR authorised representative):
- Contact for authorities (single point):
- EU declaration of conformity issued by:
1.3 System identification
- System name / commercial name:
- Internal version / build hash:
- Hardware on which it operates:
- Deployment form (cloud SaaS, on-prem, embedded, hybrid):
- Software ecosystem / OS / runtime:
- Description of any user interfaces:
1.4 Date placed on market
- Initial placing on EU market:
- Most recent substantial modification:
2. Detailed description of elements and development process
2.1 Methods used in development
- General methodology (e.g., supervised learning, RAG, fine-tuning of pretrained model X):
- Training approach:
- Hyperparameter tuning approach:
- Hardware used for training:
- Training compute (FLOPs estimate):
2.2 Key design choices and rationale
| Choice | Alternatives considered | Rationale |
|---|
| | | |
| | | |
2.3 System architecture
- High-level architecture diagram (insert):
- Component inventory (model layers, retrieval, pre/post-processing, business logic):
- Third-party components + their versions:
- Data flows between components:
2.4 Data — training / validation / testing
For each dataset, document:
- Source(s):
- Origin (collected, purchased, public, synthetic):
- Provenance + licensing:
- Date(s) of collection:
- Selection methodology:
- Pre-processing applied (cleaning, augmentation, balancing):
- Bias mitigation steps:
- Statistical properties (size, distribution, representativeness, completeness):
- Special-category data presence + Art. 10(5) justification:
- Data-labelling methodology + labeller characteristics:
2.5 Computational resources used during development
- GPU/TPU hours:
- Cloud provider:
- Estimated CO2 footprint (optional but valued):
2.6 Documentation of pre-determined changes (continuous learning)
- What can change without re-conformity-assessment:
- What changes trigger re-assessment:
- Monitoring of model drift:
- Performance bounds outside which the system must stop:
3. Monitoring, functioning and control of the system
3.1 Capabilities and limitations
- Documented performance metrics (link to §4):
- Known limitations:
- Foreseeable unintended outcomes:
- Foreseeable misuse:
3.2 Risks for health, safety, fundamental rights
Comprehensive list from the Art. 9 risk-management process. For each: description, severity (low/medium/high/critical), probability, mitigation, residual-risk acceptance rationale.
3.3 Human oversight measures (Art. 14)
- How natural-person oversight is enabled:
- Whose responsibility (deployer side):
- 'Stop' / interrupt mechanism:
- Override capability:
- Interpretability tools provided:
3.4 Specifications for input data
- Required format:
- Required quality:
- Pre-conditions for safe use:
4. Performance metrics
4.1 Chosen metrics + rationale
For each metric: name, why this metric (link to obligation under Art. 15), acceptance threshold, achieved value, measurement methodology, confidence interval / variance.
4.2 Sub-population performance (Art. 10 + 15 fairness chain)
| Sub-population | Metric | Achieved | Threshold |
|---|
| | | | |
5. Risk management system (Art. 9)
5.1 Process
- Documented procedure (link to internal procedure doc):
- Cadence of risk re-assessment:
- Responsibility (RACI):
5.2 Identified risks across lifecycle
| Stage | Risk | Mitigation | Owner | Status |
|---|
| | | | | |
5.3 Foreseeable risks from interaction with other systems
Especially if your AI plugs into another regulated system.
5.4 Testing strategy
- Test plan:
- Test datasets used:
- Test results:
- Re-test triggers:
6. Changes to the system during its lifetime
6.1 Substantial modifications (re-conformity-assessment triggers)
- Definition you use for "substantial" in your context:
- Documented modification log:
6.2 Pre-determined parameter changes (no re-assessment needed)
- Boundaries / safe envelope:
- Monitoring on boundary breach:
7. Standards and specifications applied
7.1 Harmonised standards
- ISO/IEC 42001 — AI management systems
- ISO/IEC 23894 — AI risk management
- ISO/IEC 23053 — AI lifecycle
- IEC 62304 — medical software (if applicable)
- ISO 13485 — medical device QMS (if applicable)
For each applied: version, date of application, specific clauses that map to AI Act obligations.
7.2 Other technical specifications
- Common Specifications from the Commission (when published):
- State-of-the-art benchmarks:
7.3 Detailed justification when a standard is partially applied
8. EU Declaration of Conformity (Art. 47)
Attach the signed declaration. Required elements:
- AI system name, type, identifier
- Provider name + address (or authorised representative)
- Statement of compliance with the AI Act
- References to harmonised standards / common specifications applied
- Notified body details + certificate (where third-party assessment required)
- Place and date of issue
- Signatory name + position
9. Detailed description of the post-market monitoring plan (Art. 72)
9.1 Plan ownership + cadence
- Plan owner:
- Frequency of plan review:
9.2 Data collection from deployers
- What is collected (logs, performance metrics, incidents):
- How collected (telemetry, deployer reports, audit endpoints):
- Retention:
9.3 Analysis methodology
- How data is analysed:
- Triggers for corrective action:
9.4 Serious incident reporting (Art. 73)
- Internal escalation chain:
- Authority reporting workflow (15 days; 2 days for widespread / irreversible):
Appendices
- Appendix A — Diagrams (architecture, data flow, training pipeline)
- Appendix B — Test reports
- Appendix C — Risk register full export
- Appendix D — Glossary
- Appendix E — Change log