# 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** (concise — 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
List each material design choice + the trade-off it represents:
| 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
For training, validation and test datasets, document each:
- **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)
If the model continues to learn post-deployment:
- **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** (edge cases, unsupported scenarios):
- **Foreseeable unintended outcomes**:
- **Foreseeable misuse**:

### 3.2 Risks for health, safety, fundamental rights
Comprehensive list from the Art. 9 risk-management process. For each:
- **Risk description**:
- **Severity (low / medium / high / critical)**:
- **Probability**:
- **Mitigation measure(s)**:
- **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:
- **Metric name** (accuracy, precision, recall, F1, AUC, fairness gap by group, …):
- **Why this metric** (link to the obligation under Art. 15):
- **Acceptance threshold**:
- **Achieved value**:
- **Measurement methodology**:
- **Confidence interval / variance**:

### 4.2 Sub-population performance (Art. 10 + 15 fairness chain)
Performance broken down by demographic / use-case sub-population:
| 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
For each lifecycle stage (design, development, validation, deployment, post-market):
| 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, document the version, the date of application, the
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:
1. AI system name, type, identifier
2. Provider name + address (or authorised representative)
3. Statement of compliance with the AI Act
4. References to harmonised standards / common specifications applied
5. Notified body details + certificate (where third-party assessment required)
6. Place and date of issue
7. 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

---

> **Implementation note:** Annex IV is described in the Regulation as a
> minimum. Notified bodies have observed that providers who present *only*
> the minimum fail conformity assessment more often than those who add the
> following: (a) a one-page executive summary; (b) a traceability matrix
> mapping each Art. 9-15 obligation to a section in this document;
> (c) evidence artefacts (test logs, audit screenshots, incident reports)
> as appendices. Build the document around evidence, not declarations.
>
> Free 15-min scoping call: https://compliance.waveaccess.global/