Appendix A: EU AI Act Obligation Mapping
This appendix maps the obligations of Regulation (EU) 2024/1689 (the AI Act) (1, European Union, 2024) to the architectural controls that satisfy them, the evidence that demonstrates satisfaction, the owning roles and the pipeline gates at which evidence is checked. The mapping is an architectural instrument, not legal advice.
How to read the mapping
Each row names the article, a short paraphrase of the obligation (the legal text governs), the control, the evidence produced in the evidence-as-code manner of Chapter 11 and Architecture as Code (66, Nordqvist, 2025), the accountable role, and the gate: design (decision record review), build (continuous integration), evaluate, release (promotion to production), operate (scheduled checks) or change (triggered by a change of model, data or purpose). Chapter 8 explains the classification that selects the applicable rows.
Providers of high-risk AI systems
Article 16 makes the provider responsible for the properties in Articles 9 to 15 and for the obligations that follow.
| Article | Obligation | Architectural control | Evidence artefact | Owning role | Gate |
|---|---|---|---|---|---|
| 9 | Continuous, iterative risk management over the lifecycle. | Risk register as code, re-evaluated on change (Chapter 8); classification policy. | risks/<system>.yaml with history; classification.json. |
Model risk manager | design, change |
| 10 | Data governance for training, validation and testing data. | Data contracts with lawful-basis blocks; datasheets; lineage; bias slices. | Contracts; datasheets; lineage export; slice results. | Data steward | build, evaluate |
| 11, Annex IV | Technical documentation, kept current. | Documentation pipeline assembling Annex IV from the architecture repository. | Generated documentation with its manifest. | AI architect | release |
| 12 | Automatic recording of events over the lifetime. | Structured logging at gateway and agent runtime; immutable store; retention as configuration. | Logging configuration; log schema; integrity attestation. | Platform team | build, operate |
| 13 | Transparency for deployers; instructions for use. | Model and system cards generated from the repository; confidence and provenance fields in the API. | Model card; system card; instructions for use. | AI architect | release |
| 14 | Human oversight: persons can understand, monitor, interpret and stop the system. | Oversight pattern in the decision record; interruption path as configuration; oversight roster. | humanOversight block of the AIDR; roster; interface tests. |
AI architect; business owner | design, release |
| 15 | Accuracy, robustness and cybersecurity. | Evaluation suite with adversarial scenarios; threat model; ML-BOM in CycloneDX format (43, OWASP, n.d.) and signing. | evaluation.json; threat model; mlbom.json; signatures. |
Security architect | evaluate, release |
| 17 | Quality management system. | AI management system aligned with ISO/IEC 42001 (32, ISO/IEC, 2023) as policies and pipelines. | Governance repository; clause mapping; audit reports. | Head of AI governance | design, operate |
| 43 | Conformity assessment; repeated on substantial modification. | Assessment checklist reading the evidence manifest; substantial-modification detection. | Assessment record; evidence manifest; certificate. | Head of AI governance | release, change |
| 47, 48 | EU declaration of conformity; CE marking. | Declaration generated and signed in the release pipeline; promotion refused without it. | Signed declaration; marking record. | Head of AI governance | release |
| 49 | Registration in the EU database before the system is placed on the market or put into service. | AI inventory as registration source with change detection. | Inventory entry; registration receipt. | Head of AI governance | release, change |
| 72 | Post-market monitoring throughout the lifetime. | Quality monitoring and drift detection; sampled human review. | Monitoring plan; drift evidence; review logs. | Platform team | operate |
| 73 | Serious incidents reported within the article's time limits. | Incident process with Article 3(49) categories; deadlines as configuration. | Incident records; notification receipts. | Incident manager | operate |
Articles 9, 11 and 43 each require review, updating or repetition as a system changes (regular review and updating, documentation kept up to date, a new conformity assessment on substantial modification), so a new model version, data contract or intended purpose re-runs classification.
Deployers of high-risk AI systems
Most large organisations deploy far more high-risk systems than they provide, so Article 26, with the Article 27 FRIA, is the article they live under.
| Article | Obligation | Architectural control | Evidence artefact | Owning role | Gate |
|---|---|---|---|---|---|
| 26(1) | Use per the provider's instructions. | Instructions stored with the vendor assessment; configuration checked against them. | Acknowledged instructions; conformance check. | Business owner | design, release |
| 26(2) | Assign oversight to competent, authorised persons. | Oversight roster linked to the identity provider; competence as access precondition. | Roster export; training records. | Business owner | release, operate |
| 26(4) | Relevant, representative input data. | Input data contracts; gateway validation; representativeness slices. | Contracts; validation logs. | Data steward | build, operate |
| 26(5) | Monitor; inform provider; suspend where a risk is identified; report serious incidents. | Monitoring plan; alerts; suspension path; incident process with provider notification. | Alert history; suspension and incident records. | Business owner | operate |
| 26(6) | Keep logs at least six months. | Retention as configuration with a six-month floor; scheduled verification. | Retention policy; verification output. | Platform team | build, operate |
| 26(7) | Inform workers' representatives before workplace use. | Consultation as a readiness gate (Chapter 15). | Consultation minutes. | Programme owner | release |
| 26(8) | Public authorities register under Article 49(3). | Registration status as release precondition. | Registration receipt. | Head of AI governance | release |
| 26(9) | Use Article 13 information for a GDPR Article 35 DPIA. | DPIA template consuming the model card; reference required in the record. | DPIA linked from the AIDR. | Data protection officer | design |
| 26(11) | Inform persons subject to decisions. | Disclosure in the user journey, tested end to end; public register entry. | Interface tests; register entry. | Business owner | release |
| 27 | Fundamental rights impact assessment before first use by the deployers named in Article 27(1), notified to the market surveillance authority and updated on change. | FRIA as a structured record required by the classification policy; change re-opens it. | FRIA record; notification receipt. | Data protection officer | design, change |
For a public authority, the register entry, the FRIA and log retention are what a citizen or an ombudsman asks about first.
Providers of general-purpose AI models
Chapter V places obligations on all providers of general-purpose AI models (Article 53) and adds further obligations where systemic risk is presumed or designated under Article 51 (Article 55); an organisation that fine-tunes and releases an open-weight model can become a provider.
| Article | Obligation | Architectural control | Evidence artefact | Owning role | Gate |
|---|---|---|---|---|---|
| 53(1)(a), Annex XI | Technical documentation for authorities. | Documentation generated from the training pipeline. | Annex XI package per version. | Model owner | release |
| 53(1)(b), Annex XII | Documentation for downstream providers. | Model card with Annex XII fields per version. | Published model card. | Model owner | release |
| 53(1)(c), 53(1)(d) | Copyright policy; public summary of training content. | Ingestion honouring machine-readable opt-outs; summary from the data catalogue. | Copyright policy; opt-out logs; summary. | Head of data; legal | build, release |
| 53(2), 54 | Open-source exemption; authorised representative for non-EU providers. | Licence metadata and exemption decision in the registry; representative mandate. | Licence record; mandate record. | Legal; procurement | design |
| 55(1)(a) | Model evaluation including adversarial testing. | Model-level evaluation suite with red teaming. | Evaluation results; red-team reports. | Model owner | evaluate |
| 55(1)(b), 55(1)(c) | Mitigate systemic risks; report serious incidents to the AI Office. | Systemic risk register; incident process covering downstream reports. | Risk register; incident records. | Model risk manager | design, operate |
| 55(1)(d) | Adequate cybersecurity for model and infrastructure. | Supply-chain controls, weight protection, access control. | Security assessment; access logs. | Security architect | build, operate |
Providers may rely on the Article 56 code of practice until harmonised standards exist; record adherence in the decision record.
Transparency obligations under Article 50
Article 50 applies regardless of risk class. The classification policy derives art50-transparency from the interactsWithNaturalPersons and generatesSyntheticContent fields of the decision record.
| Article | Obligation | Architectural control | Evidence artefact | Owning role | Gate |
|---|---|---|---|---|---|
| 50(1), 50(5) | Inform persons that they interact with AI, at first interaction and accessibly. | Disclosure component not disableable without a recorded waiver. | Disclosure tests; accessibility audit. | Product owner | release |
| 50(2) | Machine-readable marking of synthetic content. | Provenance and watermarking at generation; verified in evaluation. | Marking configuration; verification results. | AI architect | build, evaluate |
| 50(3), 50(4) | Disclose emotion recognition, biometric categorisation, deepfakes and AI-generated public-interest text. | Disclosure flow linked to the DPIA; publication workflow with disclosure field. | Disclosure and publication records. | Business owner | release, operate |
The mapping as YAML
The YAML is what the repository holds and the pipelines consume; the excerpt shows one obligation.
# governance/aiact/obligation-mapping.yaml
apiVersion: ai-architecture.example.eu/v1
kind: ObligationMapping
metadata:
regulation: Regulation (EU) 2024/1689
eli: http://data.europa.eu/eli/reg/2024/1689/oj
mappingVersion: 2026.1
owner: head-of-ai-governance
spec:
gates: [design, build, evaluate, release, operate, change]
obligations:
- id: art26-deployer-obligations
article: "26"
appliesTo: [deployer-high-risk]
controls:
- id: log-retention-six-months
implementation: platform/logging/retention.yaml
parameters:
minimumRetentionDays: 183
evidence:
- pattern: evidence/{aidr}/{system}/{version}/log-retention-policy.json
owningRole: business-owner
gates: [design, release, operate]
iso42001Clauses: ["8.4", "9.1"]
Maintaining the mapping as code
A mapping with tests stays accurate because the pipeline fails when it is not.
- Version against the regulation. Record the ELI identifier and bump
mappingVersionwhenever a delegated act, guideline or harmonised standard changes an article's practical meaning. - Reuse identifiers everywhere. The mapping, the classification policy and the evidence manifest use the same strings; a test fails on any mismatch.
- Test that every gate exists and that evidence resolves. One test confirms a pipeline job exists for each obligation's gate; another fails, on schedule, if a mandatory artefact is missing for a production version.
- Generate the tables from the YAML and map each obligation to ISO/IEC 42001 clauses (32, ISO/IEC, 2023) as a second axis for the management-system auditor.
- Change through pull requests, so that the history records how the organisation's reading of the law evolved.
The obligation mapping thus becomes a component of the architecture, checked continuously against what the platform produces, as Architecture as Code (66, Nordqvist, 2025) prescribes for every architectural intent.
Sources
- European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union. (1, European Union, 2024)
- International Organization for Standardization and International Electrotechnical Commission (2023). ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. ISO. (32, ISO/IEC, 2023)
- Nordqvist, G. (2025). Architecture as Code. The Transformed Architecture, Book 1. aac.geon.se. (66, Nordqvist, 2025)
- OWASP Foundation. CycloneDX Machine Learning Bill of Materials (AI/ML-BOM). (43, OWASP, n.d.)