Compliance as Code for the EU AI Act: An Engineering Framework
Compliance as code does not decide whether the EU AI Act applies. Legal and compliance owners make that determination. Engineering turns the resulting obligations into versioned controls and reproducible evidence.
This article is engineering guidance, not legal advice. It was checked on 28 July 2026, one day after the EU AI Omnibus entered into force. Re-check the official sources and obtain qualified advice for your role, system, sector, and Member State.
Current application timeline
The European Commission's implementation timeline and 27 July 2026 Omnibus notice now describe these key dates:
| Date | What applies | Engineering implication |
|---|---|---|
| 2 Feb 2025 | Prohibited-practice rules began applying; the Omnibus later simplified the company-side AI-literacy requirement and strengthened the role of the Commission and Member States | Maintain prohibited-use gates and competence evidence required by your governance program |
| 2 Aug 2025 | Governance rules and obligations for general-purpose AI models began applying | GPAI providers need role-specific documentation and downstream information flows |
| 2 Aug 2026 | Most remaining provisions apply, including Article 50 transparency duties; Commission GPAI enforcement powers begin | Interaction notices, content marking, and deployer disclosures need tested release controls where applicable |
| 2 Dec 2027 | Rules for Annex III high-risk use areas apply under the Omnibus timeline | Providers and deployers need evidence programs ready before the date, not started on it |
| 2 Aug 2028 | Rules for AI embedded in regulated physical products apply | Integrate AI evidence with the applicable product-conformity process |
The official Article 50 FAQ confirms the 2 August 2026 transparency start and describes a limited transition for certain marking obligations on systems already on the market. Do not copy this table into policy and forget it; store source, retrieval date, legal owner, and review trigger.
Step 1: make applicability an owned decision
Before implementing a control matrix, record:
- system and intended purpose;
- territorial and sector scope;
- your role: provider, deployer, importer, distributor, authorised representative, product manufacturer, or GPAI provider;
- classification: prohibited, high-risk, transparency case, GPAI, or another category;
- affected people, data, and fundamental-rights context;
- legal interpretation, source provisions, decision owner, date, and next review trigger.
Code may detect that a use case resembles an Annex III category. It should open a review; it should not make the binding classification. Intended purpose, contractual role, substantial modification, exceptions, and sector law require accountable interpretation.
Step 2: map obligations to controls and evidence
For a high-risk provider, the original Regulation's requirements include risk management (Article 9), data and data governance (Article 10), technical documentation (Article 11), record keeping (Article 12), information to deployers (Article 13), human oversight (Article 14), and accuracy, robustness, and cybersecurity (Article 15). Provider duties and the quality-management system sit in Articles 16 and 17. The current legal text and Omnibus amendments—not this summary—control.
| Obligation area | Engineering control | Evidence artifact |
|---|---|---|
| Risk management | Versioned hazard register linked to tests and post-market signals | Risk decision, test result, residual-risk approval |
| Data governance | Dataset lineage, permitted use, quality checks, bias evaluation, change approval | Dataset manifest and evaluation report |
| Technical documentation | Build documentation from versioned system, model, data, and control manifests | Release-specific technical file |
| Record keeping | Structured event logs with retention, access, integrity, and clock controls | Trace samples plus retention and integrity proof |
| Transparency to deployers | Versioned instructions, limitations, metrics, input assumptions, oversight interface | Published information bundle tied to release |
| Human oversight | Named authority, review UI, escalation, stop/override, competence requirements | Approval and override tests; training/role record |
| Accuracy, robustness, cybersecurity | Pre-registered metrics, adversarial tests, monitoring, incident response | Evaluation report and unresolved-gap register |
The downloadable matrix includes source links and additional deployer, transparency, conformity, and post-market rows.
The evidence architecture
Legal applicability decision
│
▼
Versioned obligation-control matrix
│
├──▶ CI change-impact analysis
├──▶ release gates and approvals
├──▶ runtime policy enforcement
└──▶ telemetry and incident intake
│
▼
immutable evidence index
│
▼
release-specific audit packageThe evidence index should reference artifacts rather than copy sensitive inputs into a compliance warehouse. Each record needs the system release, model and data versions, control version, owner, timestamp, result, source artifact digest, retention, and access class.
Step 3: treat every material change as an impact question
A model version is not the only change that matters. Trigger analysis when any of these change:
- intended purpose, users, geography, or affected population;
- model, prompt, system policy, retrieval corpus, tool, or fallback;
- training, fine-tuning, or evaluation data;
- decision threshold, ranking logic, or human-oversight workflow;
- interface, disclosure, content marking, logging, or retention;
- supplier terms, declared limitations, or security posture;
- incident, drift signal, complaint, or new legal guidance.
The pipeline should calculate affected controls and block release until required evidence is refreshed. It should not declare “compliant.” A useful output is: “controls C-09, C-14, and C-15 require new evidence; legal applicability decision A-17 requires review.”
Step 4: bind evidence to the exact release
A model card in a wiki can drift away from production. Bind the release manifest to:
- source and build digest;
- model/provider identifier and immutable version where available;
- prompt and policy hashes;
- dataset and evaluation-set versions;
- tool and supplier versions;
- test and review results;
- approved intended purpose and limitations;
- deployment environment and rollback target.
The runtime should emit a verifiable execution record that points back to that manifest. My execution-attestation design specifies a vendor-neutral envelope for this connection.
Step 5: make runtime controls observable
Written human oversight is not enough. Test whether the designated person can understand the decision context, stop or override the system, and see when the system is outside its operating boundary. Record overrides and do not punish operators for using them.
Likewise, transparency is a user-interface and content-pipeline property. For applicable Article 50 cases, test that notices appear at the correct time, machine-readable marks survive supported transformations, deployer disclosures render, and exceptions are owned—not inferred by a prompt.
Step 6: generate an audit package, not an evidence dump
A release package should answer:
- What system and release is this?
- What is its intended purpose, scope, role, and current legal classification?
- Which obligations and internal policies were mapped?
- Which controls operated, with what results and exceptions?
- What changed from the prior release?
- Which risks remain and who accepted them?
- How is deployed performance monitored and incidents escalated?
- Can every artifact be verified against its digest and retention rule?
Generate this view from the evidence index, but preserve signed human judgments. Automation should eliminate transcription, not accountability.
What must remain human-owned
- legal scope, role, classification, and interpretation;
- intended purpose and acceptable residual risk;
- fundamental-rights and sector-specific judgment;
- whether evidence is sufficient for the actual context;
- approval of exceptions, conformity decisions, and regulatory communication;
- response to conflicting obligations or unclear guidance.
A compliance bot that auto-approves its own evidence is a control failure.
Download the engineering control matrix
The CSV maps selected AI Act provisions to roles, controls, evidence, triggers, owners, status, official sources, and review dates. It is a starting template, not a complete legal analysis.
Download the EU AI Act engineering control matrix
Use the risk-based quality-gate framework to route releases and the agent reliability SLO framework to connect operational signals with governance.