What the EU AI Act Actually Requires
The EU AI Act became enforceable in stages from August 2024. The provisions that matter most for software teams deploying AI in Annex III high-risk domains (credit scoring, biometrics, employment, critical infrastructure, healthcare, education, law enforcement, migration, justice) take effect from August 2026.
The three most important technical requirements for high-risk AI systems:
Article 9 — Risk management system A documented, continuous process for identifying, estimating, evaluating, and mitigating risks. This is not a one-off document — it must be updated throughout the system's lifecycle and include testing evidence.
Article 11 + Annex IV — Technical documentation Before deployment, you must produce a specific technical file containing: system description and purpose, design specifications, data governance measures, performance metrics, monitoring and post-market plan, and the risk management record from Article 9. Annex IV lists 9 required sections.
Article 13 — Transparency and information provision High-risk AI systems must be accompanied by instructions for use that allow deploying organisations to understand the system's purpose, capabilities, limitations, and appropriate use context.
What is NOT sufficient: a GDPR-style notice, a blog post about responsible AI, or a README.md. Annex IV Section 2 alone requires algorithmic logic description, data specifications, training data characteristics and provenance, and performance metrics across demographic groups.
The Failure Mode: Build First, Compliance After
Most teams build the AI system, then discover the compliance documentation requirement during due diligence or a procurement process. Retrofitting is expensive:
- The architecture was not designed to be documented — reverse-engineering it is slow
- Training data provenance was not tracked — reconstructing it is often impossible
- Performance metrics were not collected across required sub-groups — rerunning evaluations takes months
- The system has already been deployed — changes to meet requirements risk breaking production
The cost of retrofit is typically 3–5× the cost of building compliance in from the start. And for some requirements (training data provenance), retrofit is impossible.
Architecture-First Approach
When you define your AI system in Archiet before building it, the compliance documentation is generated from the same model as the code. The process:
- Model your AI system's scope — what decisions it makes, what data it processes, which Annex III category it falls into (if any)
- Flag the AI governance overlay — Archiet marks the system as subject to EU AI Act requirements
- Generate — the pipeline produces your codebase AND the compliance documentation simultaneously
The documentation is accurate because it is generated from the actual architecture model, not written by hand about a hypothetical system.
Step 1: Define Your AI System's Scope in Archiet
When describing your system in the Blueprint Wizard, be specific about the AI component:
- What decision does the AI make or recommend? ("Predicts probability of loan default" is more useful than "uses AI for credit scoring")
- What inputs does the AI consume? (credit history, transaction data, demographic data — flag any special category data)
- What is the output? (a score, a binary decision, a recommendation to a human approver)
- Who is affected by the decision? (applicants, employees, patients — whoever the output affects)
- Is there human oversight? (human in the loop, human on the loop, or fully automated)
Archiet uses this to determine the applicable risk tier and the documentation requirements.
Step 2: Flag the AI Governance Overlay
In the Blueprint editor, under Compliance overlays, check EU AI Act — High-Risk AI System.
This adds to your architecture model:
- An
AIGovernancecapability with documented scope, intended purpose, and affected persons - A
ModelCardentity that tracks model version, training data characteristics, and performance metrics - A
DataLineageentity that records data provenance per training dataset - An
RiskManagementRecordentity for the Article 9 continuous risk assessment
These entities generate database models, API endpoints, and migration files in the codebase — the compliance framework is structural, not documentary.
Step 3: Generated Outputs
After generation, your ZIP contains:
In docs/compliance/:
eu_ai_act_technical_documentation.md— the Annex IV skeleton, pre-populated from your architecture model. Section 2 (system description) is generated from your entity model. Section 4 (data governance) references your actual data entities.risk_management_plan.md— Article 9 template with your system's identified risk categories pre-filled based on the Annex III category and data types.model_card.md— structured model documentation following the EU AI Act's transparency requirements.
In your codebase:
app/models/ai_governance.py—ModelCard,DataLineage,RiskManagementRecordmodels with full Alembic migrationsapp/blueprints/governance_bp.py— endpoints for logging model versions, recording performance metrics, and producing the Article 9 audit trailapp/services/ai_governance_service.py— service layer for risk assessment updates and compliance record keeping
What an Auditor Sees
When a notified body (the EU AI Act's designated conformity assessment body) audits your high-risk AI system, they will ask for the Annex IV technical documentation.
With the architecture-first approach:
- Section 2 (system description) is accurate — it was generated from the model, not written from memory
- Section 3 (development process) references the ADRs in
docs/decisions/— documented design choices - Section 5 (monitoring and post-market) is wired into
governance_bp.py— there is a live API producing the monitoring data the documentation describes
Without the architecture-first approach: Section 2 is written after the fact and may not match what was actually built. Section 5 describes a monitoring process that exists on paper only.
The Governed Agent Connection
If your AI system makes or recommends individual decisions — credit scoring, job screening, benefit allocation, risk assessment — the governed agent architecture (BPMN + DMN + bounded LLM) is the technical implementation that makes Article 13 transparency tractable.
The DMN policy table is the "algorithmic logic description" that Article 13 requires to be documented and understandable. When your AI system uses a DMN table to make decisions, you can show an auditor exactly what rules fire for any given input. A neural network cannot offer the same.
The EU AI Act compliance documentation for Archiet itself is generated from the Archiet architecture model — including the governed agent components. We eat our own cooking.