# EU AI Act Annex IV Template — Technical Documentation for High‑Risk AI Fictional sample template. Not legal advice. This template is aligned to Annex IV items (1)–(9) and designed to be “living documentation”: fill v1 once, then keep it current via change control, monitoring, and review records. --- ## Document control (front matter) ### Document metadata - **Document title:** EU AI Act Annex IV — Technical Documentation - **AI system name:** - **AI system version:** - **Provider / responsible entity:** - **Document owner (role + name):** - **Approvers (roles + names):** - **Confidentiality level:** Public / Internal / Confidential / Restricted - **Effective date:** ### Revision history | Date | Version | Author | Summary of change | Approved by | | --- | --- | --- | --- | --- | | | v0.1 | | Initial draft | | ### Scope statement - **Intended purpose (1–2 sentences):** - **Boundaries / exclusions:** - **Target users / deployers:** ### Disclaimer This template is provided for informational purposes only and does not constitute legal advice. You are responsible for determining applicable obligations and for producing complete and accurate technical documentation. --- ## Annex IV conformance map (quick index) This table helps reviewers jump to the right section in this document. | Annex IV item | Title | Where in this document | | --- | --- | --- | | (1) | General description of the AI system | Section 1 | | (2) | System elements and development process | Section 2 | | (3) | Monitoring, functioning and control | Section 3 | | (4) | Appropriateness of performance metrics | Section 4 | | (5) | Risk management system | Section 5 | | (6) | Relevant changes through lifecycle | Section 6 | | (7) | Standards and technical specifications used | Section 7 | | (8) | EU declaration of conformity | Section 8 | | (9) | Post-market monitoring system and plan | Section 9 | --- ## Section 1 — General description of the AI system (Annex IV item 1) ### 1.1 Intended purpose - Intended purpose (what the system does): - Intended users / deployers: - Intended populations / environments (if applicable): - Foreseeable misuse (high-level): ### 1.2 Provider and versioning - Provider name: - System versioning scheme: - Relationship to prior versions (what changed, why): ### 1.3 System context and integrations - Interaction with hardware/software and other AI systems (if applicable): - External services, dependencies, and critical integrations: ### 1.4 Software/firmware versions and updates - Relevant software/firmware versions: - Update requirements (how updates are delivered and validated): ### 1.5 Forms of placing on the market / putting into service - Delivery models: API / SaaS / embedded / downloadable / on-prem / hybrid - Packaging details (endpoints, regions, deployment topology): ### 1.6 Intended hardware environment - Compute/runtime environment (if relevant): - Hardware constraints / dependencies: ### 1.7 User interface and instructions for use - Basic user interface description for deployers: - Instructions for use (deployer-facing): ### Evidence pointers (optional, for provability) For each artifact, add: (a) evidence artifact name, (b) where it is generated, (c) integrity proof reference (hash/manifest entry). | Evidence artifact name | Where it is generated | Integrity proof reference | | --- | --- | --- | | System overview | Product documentation | Manifest entry: | | Release manifest / build info | CI/CD pipeline | Manifest entry: | | Deployment topology | IaC repository | Manifest entry: | | Deployer instructions | Docs / runbooks | Manifest entry: | --- ## Section 2 — System elements & development process (Annex IV item 2) ### 2.1 Development methods, steps, and tools - Development lifecycle (phases): - Third-party tools and services used (and how integrated/modified): - Roles and responsibilities (RACI summary): ### 2.2 Design specifications and key choices - System logic (high-level): - Key design choices and assumptions: - What is optimized (objectives): - Output quality expectations and trade-offs (including compliance trade-offs): ### 2.3 Architecture and components - Architecture diagram reference: - Components and interactions (data flow): - Compute resources used to develop/train/test/validate (if applicable): ### 2.4 Data requirements and dataset documentation - Data requirements (types, sources, constraints): - Dataset documentation (“datasheets”) references: - Provenance, selection, labeling, cleaning methods (where relevant): ### 2.5 Human oversight assessment (Article 14) - Oversight goals (what humans must be able to do): - Measures that help deployers interpret outputs: - Escalation and override mechanisms: ### 2.6 Pre-determined changes and continuous compliance - Pre-determined changes (if applicable): - How changes are evaluated and approved: - How continuous compliance is ensured: ### 2.7 Validation and testing - Validation/testing procedures: - Test datasets used (references): - Metrics used (accuracy, robustness, compliance): - Discriminatory impact assessment (where relevant): - Signed reports/logs references: ### 2.8 Cybersecurity measures - Security controls relevant to this system: - Threat model reference (if available): - Access control, secrets, and key management: ### Evidence pointers (optional, for provability) | Evidence artifact name | Where it is generated | Integrity proof reference | | --- | --- | --- | | Architecture diagram | Design repo / docs | Manifest entry: | | Training data sheet excerpts | Data governance | Manifest entry: | | Model card excerpts | Model registry | Manifest entry: | | Validation & testing excerpts | CI/CD / evaluation harness | Manifest entry: | | Policy pack excerpts (policy-as-code) | Policy engine | Manifest entry: | --- ## Section 3 — Monitoring, functioning, and control (Annex IV item 3) ### 3.1 Capabilities and limitations - Capabilities (what it can do reliably): - Limitations and known failure modes: - Assumptions required for safe operation: ### 3.2 Expected accuracy and performance (overall and subgroups) - Overall performance summary (high-level): - Subgroup / intended population performance (where relevant): ### 3.3 Foreseeable unintended outcomes and risk sources - Foreseeable unintended outcomes: - Risk sources (safety, fundamental rights, discrimination, privacy): ### 3.4 Human oversight measures (operationalized) - Oversight checkpoints (what triggers review): - Decision records and accountability: ### 3.5 Input data specifications - Input data types and constraints: - Data quality expectations: - Handling of missing/invalid inputs: ### Evidence pointers (optional, for provability) | Evidence artifact name | Where it is generated | Integrity proof reference | | --- | --- | --- | | Dynamic sampling & quality monitoring report | Runtime telemetry | Manifest entry: | | Human oversight decision records | Review queue | Manifest entry: | | Monitoring dashboards / alert rules | Observability stack | Manifest entry: | --- ## Section 4 — Appropriateness of performance metrics (Annex IV item 4) ### 4.1 Metrics selection rationale - Metrics used and why they fit intended purpose: - Known metric limitations and mitigations: ### 4.2 Thresholds and acceptance criteria - Thresholds that constitute acceptable performance: - Why the thresholds are appropriate: - Who approved the thresholds and when: ### Evidence pointers (optional, for provability) | Evidence artifact name | Where it is generated | Integrity proof reference | | --- | --- | --- | | Metric definitions | Engineering / governance docs | Manifest entry: | | Baseline evaluation report | CI/CD / evaluation harness | Manifest entry: | | Threshold approval record | Review queue / change control | Manifest entry: | --- ## Section 5 — Risk management system (Annex IV item 5) ### 5.1 Risk management process - Risk identification approach: - Risk evaluation and prioritization: - Mitigation measures: - Residual risk assessment and acceptance: - Verification loops (how mitigations are tested): ### 5.2 Linkages to operational processes - Risk register reference: - Incident management process reference: - Escalation contacts and SLAs: ### Evidence pointers (optional, for provability) | Evidence artifact name | Where it is generated | Integrity proof reference | | --- | --- | --- | | Risk register export | GRC tooling | Manifest entry: | | Control tests / policy checks | Policy engine / CI | Manifest entry: | | Incident runbook excerpts | Operations docs | Manifest entry: | --- ## Section 6 — Relevant changes through lifecycle (Annex IV item 6) ### 6.1 Change categories - Model updates (weights, prompts, tools): - Data pipeline changes: - Policy/guardrail changes: - UI/UX changes (deployer-facing): - Retraining events and triggers: ### 6.2 Approval and validation requirements - Change approval matrix (what requires review/approval): - Validation requirements per change type: - Rollback procedures: ### Evidence pointers (optional, for provability) | Evidence artifact name | Where it is generated | Integrity proof reference | | --- | --- | --- | | Change log / release notes | CI/CD / product ops | Manifest entry: | | Policy bundle diffs | Policy engine | Manifest entry: | | Validation reports (per release) | CI/CD | Manifest entry: | --- ## Section 7 — Standards and technical specifications (Annex IV item 7) ### 7.1 Harmonised standards applied - List harmonised standards applied (full/partial): - Scope and applicability notes: ### 7.2 If no harmonised standards applied - Solutions adopted to meet requirements: - Other standards/specs used: ### Evidence pointers (optional, for provability) | Evidence artifact name | Where it is generated | Integrity proof reference | | --- | --- | --- | | Standards mapping | Governance docs | Manifest entry: | | Control framework mapping | Policy pack | Manifest entry: | --- ## Section 8 — EU declaration of conformity (Annex IV item 8) ### 8.1 Declaration reference (stub) - Declaration document reference: - Date of issue: - Signatory: > Public versions of this template may include a stub only. ### Evidence pointers (optional, for provability) | Evidence artifact name | Where it is generated | Integrity proof reference | | --- | --- | --- | | EU declaration of conformity | Quality management system | Manifest entry: | --- ## Section 9 — Post-market monitoring system + plan (Annex IV item 9) ### 9.1 Monitoring objectives and signals - Monitoring objectives: - Signals tracked (safety, performance, drift, bias, misuse): - Thresholds and alerting rules: ### 9.2 Post-market monitoring plan - Plan owner and cadence: - Data sources and sampling approach: - Escalation and remediation workflow: ### 9.3 Continuous improvement loop - Incident reporting linkage: - Retrospective process: - Feedback into risk management and change control: ### Evidence pointers (optional, for provability) | Evidence artifact name | Where it is generated | Integrity proof reference | | --- | --- | --- | | Post-market monitoring plan | Ops / governance | Manifest entry: | | Drift/bias monitoring report | Runtime telemetry | Manifest entry: | | Incident records (sanitized) | Ticketing / IR | Manifest entry: | --- ## Appendix A — Evidence integrity model (example) Use this appendix to document how your evidence bundle can be verified. - Per-artifact SHA‑256 digests in a manifest - A bundle root hash computed from the manifest - Recording the root hash in an append-only audit ledger - A verification procedure that re-computes and checks the hashes ### Verification steps (template) 1. Obtain the exported bundle and the manifest. 2. Re-compute SHA‑256 digests for each file; compare with manifest entries. 3. Re-compute the bundle root hash from the manifest; compare with the recorded root hash. 4. Verify the root hash exists in the audit ledger and matches the expected entry.