The EU AI Act is not implemented by adding a legal document to a release ticket. Its requirements become system inventory, role and risk classification, data lineage, versioned technical evidence, automatic logs, human authority, quality gates, conformity workflows, post-market monitoring, and incident response. That is a software architecture.
Before choosing controls, identify whether the product is an AI system under the Act, which markets and people it affects, its intended purpose, foreseeable misuse, and each actor's role. Provider, deployer, importer, distributor, authorised representative, product manufacturer, and GPAI model provider have different obligations. A company can be a deployer in one workflow and become a provider after placing a substantially modified or rebranded system on the market.
As of June 22, 2026, the Regulation entered into force on August 1, 2024; prohibitions, definitions, and AI-literacy provisions have applied since February 2, 2025; governance and GPAI obligations have applied since August 2, 2025; and many other provisions are scheduled from August 2, 2026. A political agreement on the AI Omnibus was announced on May 7, 2026, with later high-risk dates: December 2, 2027 for Annex III systems and August 2, 2028 for product-embedded systems. Teams should distinguish the official Regulation text from agreed amendments still moving through formal adoption and keep the applicable timeline under legal review.
The registry should not be a spreadsheet detached from production. Every deployed endpoint, model version, prompt bundle, decision policy, dataset snapshot, and human workflow should resolve to the same system record. The control plane evaluates required evidence, blocks incompatible releases, publishes approved runtime configuration, and receives monitoring and incident outcomes.
| Regulatory requirement | Architecture capability | Release evidence | Runtime signal | Blocking condition |
|---|---|---|---|---|
| Risk management, Article 9 | Hazard/risk register linked to purpose, misuse, affected groups, controls, tests, residual risk, and post-market findings. | Approved risk version and predefined acceptance metrics. | New hazard, misuse, complaint, context or control failure. | Unaccepted residual risk or expired assessment. |
| Data governance, Article 10 | Dataset registry with origin, purpose, processing, labels, geography, population, quality, bias analysis, gaps, access, and retention. | Immutable train/validation/test manifests and signed checks. | Input drift, missing groups, label changes, feedback loops. | Unknown lineage, failed quality gate, or prohibited access. |
| Technical documentation, Article 11 | Docs-as-code generated from system registry, architecture, model/data versions, performance, interfaces, limitations, and change history. | Versioned Annex IV-aligned documentation bundle. | Runtime differs from documented configuration. | Missing, stale, or inconsistent documentation. |
| Record keeping, Article 12 | Automatic event logging with system/model/policy version, input reference, output, operator action, time, and trace IDs. | Schema, retention, integrity, access, and replay tests. | Log loss, schema break, clock drift, or untraceable decision. | Required events cannot be reconstructed. |
| Information to deployers, Article 13 | Versioned instructions, intended purpose, limits, metrics, input requirements, oversight, maintenance, logs, and known circumstances. | Approved instruction package tied to artifact version. | Use outside instructions or unsupported environment. | Deployer cannot operate safely or interpret output. |
| Human oversight, Article 14 | Review queues, authority model, competence/training, context display, override/stop controls, automation-bias safeguards, and escalation. | Scenario tests proving intervention is timely and effective. | Override rate, ignored warnings, queue delay, operator error. | No qualified human can understand, intervene, or stop. |
| Accuracy, robustness, cybersecurity, Article 15 | Eval service, declared metrics, reliability tests, adversarial/security suite, fail-safe behavior, redundancy, and feedback-loop controls. | Threshold report by intended context and affected group. | Metric drift, attack signal, outage, fallback, or feedback amplification. | Declared level is missed or safe fallback fails. |
A release should resolve to one immutable graph: AI system version → model and prompt versions → code commit and container → data manifests → eval runs → risk controls → technical documentation → instructions → human-oversight workflow → security review → conformity/registration status → production deployment. Evidence carries author, reviewer, timestamp, tool version, source, signature, expiry, and supersession. A PDF can be an export; it should not be the source of truth.
Providers own design compliance, quality management, documentation, conformity work, corrective action, and system-level post-market monitoring. Deployers must follow instructions, assign competent oversight, monitor operation, retain logs under their control, and handle input data appropriately; public bodies and certain essential-service deployers may also need a fundamental-rights impact assessment. Contracts and APIs must let each party exchange the evidence needed without exposing unrelated personal, security, or proprietary data.
An “approve” button does not prove oversight. Define what the human sees, what competence is required, when review occurs, whether action is advisory or mandatory, how long is available, what stops automatically, and whether the operator can reverse consequences. Measure queue age, intervention success, override patterns, automation bias, disagreement, escalation, and outcomes after intervention.
Record enough to reconstruct system operation and support monitoring while applying purpose limitation, minimisation, retention, access control, integrity, and security. Prefer references, hashes, structured features, and decision context over indiscriminate raw prompts or personal data. Separate product analytics, security logs, regulatory evidence, and sensitive case records with explicit access and retention policies.
A model upgrade is not the only material change. New purpose, customer segment, country, decision authority, automation level, data source, threshold, UI, tool permission, integration, or vendor can alter risk and role. Pull requests and deployment pipelines should calculate change impact, invalidate affected evidence, request reviewers, rerun required evals, and block production until the new system version is approved.
For systems subject to high-risk requirements, conformity assessment, EU declaration, CE marking where applicable, registration, document retention, and value-chain responsibilities become release states. The deployment controller should know whether the exact artifact is development-only, sandboxed, assessment-pending, approved for limited markets, registered, suspended, recalled, or retired. It should prevent an artifact approved for one purpose from being silently reused for another.
Article 72 requires active, systematic collection and analysis over the lifecycle. Define expected metrics and data sources before launch: performance, drift, subgroup outcomes, human overrides, misuse, complaints, appeals, incident precursors, context changes, provider notices, and interactions with other systems. Link every signal to a threshold, owner, investigation playbook, corrective action, and evidence update.
Do not bury AI incidents inside generic bug queues. Preserve the affected version, timeline, outputs, logs, operator actions, data conditions, impact, containment, and communication. The workflow evaluates reportability under Article 73, coordinates provider/deployer and authorities, prevents evidence deletion, and tracks corrective action to verified effectiveness. Security, privacy, safety, discrimination, and fundamental-rights teams may all participate.
For each general-purpose model, track provider, model/version, release date, intended integration, technical documentation received, acceptable-use and copyright information, evaluation/safety material, systemic-risk status where relevant, hosting region, change notices, and downstream controls. A vendor alias that silently points to a new model should be treated as a supply-chain change and trigger re-evaluation.
Article 50 obligations can require people to know when they interact with AI and require machine-readable marking or disclosure for certain generated or manipulated content. Put notices, provenance metadata, detection support, deepfake/public-interest disclosure, language, accessibility, and evidence of delivery into the product design. A policy page hidden in the footer is not equivalent to timely disclosure.
An AI system registry and actor graph; legal-baseline service; risk/classification engine; dataset and model BOM; evidence graph; evaluation service; documentation generator; policy-as-code release gateway; deployment allow-list; runtime logging schema; human-oversight console; transparency/provenance service; post-market signal bus; incident workflow; conformity/registration state machine; vendor-change monitor; and auditable exports for counsel, customers, notified bodies, and authorities.
The AI Act becomes manageable when compliance state is derived from the exact software, model, data, purpose, market, and runtime evidence in production. Architecture cannot replace legal judgment, but it can ensure that every judgment is connected to enforceable controls and reconstructable facts.
Legal note: this is an engineering interpretation, not legal advice. The implementation schedule is changing; verify the formally applicable text, guidance, standards, and national requirements for each system and deployment.
Article about the EU AI Act as a software architecture problem: system registry, role and risk classification, data governance, technical documentation, logging, human oversight, release gates, conformity, monitoring, incidents, GPAI, and transparency.