Compliance for AI Systems and the EU AI Act

The EU AI Act does not care what your compliance binder looked like on the day of the audit — it cares what your model was doing at 3 a.m. last Tuesday when a drifted feature pipeline silently changed a credit decision. Point-in-time attestations were already a weak fit for cloud infrastructure; for AI systems that retrain, drift, and reason probabilistically, they are close to meaningless. This is a practitioner’s guide to building always-on assurance — compliance-as-code, continuous control monitoring, and automated evidence generation — so that "audit-ready" becomes a permanent system state rather than a quarterly fire drill.

Why point-in-time audits fail for AI systems

Traditional IT compliance programs are built around a rhythm: policies are written, controls are implemented, auditors sample evidence once or twice a year, and a report is issued that certifies the state of the environment as of a specific date. That rhythm assumes the system under review is relatively static between audit cycles — the same servers, the same access control lists, the same batch jobs running the same code. AI systems break that assumption in three specific ways that every engineer who has shipped a model to production already knows intuitively but that compliance functions have been slow to internalize.

First, the artifact being governed is not the code, it is the code plus the weights plus the training data plus the prompt templates plus the retrieval index plus the guardrail configuration — and any one of those can change independently of a deployment event. A retrieval-augmented generation system can produce materially different outputs on Monday and Friday without a single line of code changing, simply because the underlying document index was re-embedded. A fraud-detection model can silently degrade because the population of transactions it sees has shifted (covariate drift), even though the model artifact hash is identical to the one an auditor signed off on in March.

Second, AI systems fail in ways that are statistical rather than binary. A traditional control either passed or failed — a firewall rule either blocked the port or it did not. An AI system’s compliance posture is a distribution: 99.2% of outputs conform to a fairness constraint, but the tail is where regulatory and reputational risk concentrates. You cannot sample your way to confidence about a tail with a quarterly audit; you need continuous statistical monitoring over the full production traffic.

Third, and most importantly for the EU AI Act specifically, the regulation itself is not a one-time gate. Articles 9 through 15 describe a risk management system that must be "a continuous iterative process run throughout the entire lifecycle of a high-risk AI system," Article 72 requires a formal post-market monitoring plan, and Article 73 imposes serious-incident reporting obligations with strict clocks (15 days for most serious incidents, 10 days when death has occurred, and 2 days for incidents involving widespread infringement or critical infrastructure disruption). The law is written as an ongoing obligation. Treating it as an annual audit checkbox is not just operationally weak, it is a misreading of the statute.

The consequence for engineering teams is that compliance stops being something Legal hands you as a document and becomes something you build as a system: instrumented, versioned, tested in CI, and observable in the same dashboards your SRE team already watches for latency and error budgets. That is the shift this article works through in detail.

The EU AI Act risk-tiering model, translated for engineers

Regulation (EU) 2024/1689 entered into force on August 1, 2024, and its obligations phase in on a staggered timeline: prohibited-practice bans became applicable February 2, 2025; obligations on general-purpose AI (GPAI) model providers began August 2, 2025; the bulk of high-risk system obligations apply from August 2, 2026; and high-risk obligations tied to products already covered by EU harmonization legislation (machinery, medical devices, toys, and similar) extend to August 2, 2027. Engineering teams need to know exactly which bucket their system falls into, because the bucket determines the entire control set.

The four tiers

• Unacceptable risk (Article 5): prohibited outright — social scoring by public authorities, untargeted scraping of facial images to build recognition databases, emotion inference in workplaces and schools (with narrow medical/safety exceptions), real-time remote biometric identification in public spaces for law enforcement (with narrow exceptions), and manipulative or exploitative AI that causes significant harm.
• High-risk (Article 6, Annex III): the category that carries the heaviest engineering burden. It covers AI used in: biometric identification and categorization; critical infrastructure management (energy, water, digital infrastructure); education and vocational training (admissions, scoring); employment (recruitment, performance evaluation, termination); access to essential private and public services (credit scoring, insurance pricing, emergency dispatch); law enforcement; migration and border control; and administration of justice and democratic processes.
• Limited risk (Article 50): transparency obligations only — chatbots must disclose they are AI, synthetic media must be labeled as AI-generated (deepfake watermarking), and emotion-recognition or biometric-categorization systems must notify the exposed individual.
• Minimal risk: the large majority of AI applications (spam filters, inventory optimization, recommendation engines in non-high-risk contexts) — no mandatory obligations beyond existing law, though voluntary codes of conduct are encouraged.

For a SOC, NOC, or platform engineering team, the practical exercise is a system inventory and classification pass: enumerate every model, agent, and automated decision pipeline in production, map each to an Annex III use case (or confirm it falls outside), and tag the result in your asset management system alongside existing CMDB and data-classification tags. This is not a one-time spreadsheet exercise either — a general-purpose LLM deployed for internal ticket triage today can become an Annex III "employment" system tomorrow if someone wires it into a performance-review workflow. Classification has to be a gate in your deployment pipeline, not a document that ages the moment it is signed.

Obligations that scale with the tier

High-risk systems inherit the full weight of Articles 9–15: a documented risk management system, data and data governance controls (Article 10), technical documentation (Article 11, Annex IV), automatic logging capable of ensuring traceability (Article 12), transparency and instructions for use (Article 13), human oversight measures (Article 14), and accuracy, robustness, and cybersecurity requirements (Article 15). Providers must also complete a conformity assessment, affix a CE marking, and register the system in the EU database before placing it on the market (Article 71). GPAI model providers face a separate, lighter-but-still-substantial regime under Articles 51–56: technical documentation, copyright-compliant training data summaries, and — for models classified as carrying "systemic risk" (currently keyed to a compute threshold of 10^25 FLOPs) — adversarial testing, incident reporting to the EU AI Office, and cybersecurity safeguards for the model and its infrastructure.

Compliance-as-code: turning legal text into executable policy

The core architectural move is to stop treating "compliance requirements" as prose in a PDF that a GRC analyst manually cross-references against screenshots, and start treating them as a set of machine-checkable assertions that run against live systems the same way unit tests run against a code change. This is not a metaphor borrowed loosely from DevOps — it is a direct, literal application of policy-as-code tooling to regulatory obligations.

Concretely, this means decomposing each article of the Act into discrete, testable control statements, then encoding those statements as policies in a language like Open Policy Agent’s Rego, or as custom validators embedded in your CI/CD and model-registry tooling. Article 12’s logging requirement, for instance, decomposes into testable assertions such as: "every inference request against a high-risk model must produce a log record containing model version, input hash, output, confidence score, and timestamp," and "log retention must meet or exceed the period defined in the system’s technical documentation." Each of those can be a policy that runs automatically against the logging pipeline’s schema and retention configuration, failing a build if violated.

A worked example: encoding Article 10 (data governance) as policy

Article 10 requires that training, validation, and testing datasets be subject to appropriate data governance: examination for possible biases, identification of gaps or shortcomings, and measures to detect, prevent, and mitigate those biases. As executable policy, a data engineering team can implement this as a pipeline gate that runs whenever a new training dataset version is registered:

1. A schema and lineage check confirms the dataset is registered in the data catalog with a documented source, collection method, and consent basis — failing the build if lineage metadata is missing.
2. An automated bias-scan job computes representation statistics across protected and quasi-protected attributes (where legally permissible to hold them for this purpose) and compares them against a documented acceptable-variance threshold, flagging the dataset for human review if the threshold is breached.
3. A gap-analysis job checks label coverage and class balance against the system’s intended operational design domain, again gating the promotion of the dataset to "approved for training" status if coverage falls below a defined floor.
4. Every gate outcome — pass, fail, or override-with-justification — is written as an immutable evidence record with the dataset version hash, the policy version that evaluated it, the result, and the identity of any human who approved an override.

Notice what has happened: a paragraph of legal text has become four automated checks with pass/fail outcomes and an audit trail that is generated as a byproduct of normal engineering work, not as a separate activity performed to satisfy an auditor. This is the essence of compliance-as-code — the evidence is exhaust from the pipeline, not a deliverable produced on demand.

Architecture of an always-on assurance system

Building this in practice means assembling five layers that most organizations already have pieces of, but rarely wired together with compliance as the explicit design goal. Think of it as a layered stack sitting alongside your existing observability and security tooling rather than a bolt-on GRC product that lives in a silo only the compliance team logs into.

Layer 1: instrumentation at the model and data boundary

Every inference call, every training run, every retrieval query against a vector index, and every human-in-the-loop override needs to emit a structured event. This is not optional telemetry you add later — for high-risk systems, Article 12 makes logging a hard legal requirement, and Article 11’s technical documentation (Annex IV) requires you to describe the logging capabilities in the system’s documentation itself. Minimum fields per inference event: model artifact hash, model card version, input feature hash (not necessarily raw input, for privacy reasons), output, confidence or uncertainty estimate, latency, the identity or role of any human reviewer, and a correlation ID linking the event to the business transaction it supported.

Layer 2: policy-as-code evaluation

This is the OPA/Rego (or equivalent) layer described above, sitting in the model registry, the CI/CD pipeline, and — critically — in the runtime path for high-stakes decisions where a policy check needs to run synchronously before an output is released (for example, blocking release of a hiring recommendation until a bias-drift check on the current model version has run within the last 24 hours).

Layer 3: the evidence ledger

Every gate evaluation, monitoring alert, override, and incident report is written to an append-only, hash-chained evidence store. This does not need to be a blockchain — a well-designed write-once object store with cryptographic hash-chaining between records (each record includes the hash of the previous record) gives you tamper-evidence at a fraction of the operational cost, and it is exactly the pattern mature security teams already use for SIEM log integrity. The ledger is what turns "we believe we were compliant" into "here is the cryptographically verifiable record of every control evaluation for the last 36 months," which is the actual deliverable a notified body or market surveillance authority wants to see during an Article 74 investigation.

Layer 4: continuous control monitoring

A dedicated monitoring layer runs statistical checks on a schedule (hourly, daily, or streaming) rather than only at deployment time: population stability index and feature drift against the training baseline, fairness metrics (demographic parity difference, equalized odds gap) recomputed on rolling production windows, model performance decay against ground truth as it becomes available, and adversarial-robustness spot checks using a rotating battery of perturbation and prompt-injection probes for generative systems. Each monitor has a defined threshold, an owner, and an escalation path — structurally identical to an SRE error-budget policy, and this is deliberate: the same on-call rotations, paging tools, and runbook discipline that keep production infrastructure healthy should keep AI systems compliant.

Layer 5: reporting and regulator-facing export

The top layer is a reporting service that can, on demand, generate the specific artifacts regulators and auditors ask for: the technical documentation package (Annex IV), the EU database registration record (Article 71), the post-market monitoring report (Article 72), and — when triggered — the serious-incident report (Article 73) within its statutory deadline. Because everything below this layer is already structured and evidenced, generating these documents becomes a query against the evidence ledger rather than a multi-week scramble involving five teams reconstructing what happened from Slack threads and spreadsheets.

Continuous monitoring: what to instrument and how

The single most common failure mode in AI compliance programs is monitoring the wrong thing — typically infrastructure uptime and API latency, which SREs already track well, while ignoring the statistical health of the model itself, which is where regulatory risk actually lives. A model can have 99.99% availability and zero deployment incidents while quietly discriminating against a protected class or hallucinating fabricated citations in a customer-facing chatbot. Compliance monitoring needs its own metric taxonomy, distinct from but complementary to standard SRE golden signals.

Data and drift monitoring

Track population stability index (PSI) and Kullback-Leibler divergence between the current production input distribution and the training baseline, computed per feature and rolled up to a system-level drift score. Set two thresholds: a warning threshold that opens a ticket for data science review, and a hard threshold that automatically suspends autonomous decisioning and routes all outputs through mandatory human review until the drift is investigated. This directly operationalizes Article 15’s accuracy and robustness requirement and gives you a defensible, quantitative answer when an auditor asks how you detect degradation between retraining cycles.

Fairness and non-discrimination monitoring

For any Annex III use case touching employment, credit, education, or essential services, compute standard fairness metrics — demographic parity difference, equal opportunity difference, disparate impact ratio — on a rolling window of production decisions, segmented by every protected and legally relevant attribute available to you under applicable data protection law. Store the results in the evidence ledger with the computation methodology versioned alongside the numbers, because a fairness metric without a documented methodology is not evidence, it is an assertion.

Robustness and security monitoring

Generative and agentic systems need continuous adversarial probing: automated red-team suites that run prompt-injection, jailbreak, and data-exfiltration attempts against production or shadow-production endpoints on a recurring schedule, with results tracked over time to detect regression. This overlaps heavily with the AI-specific threat surface covered under AI security programs, and organizations running mature exposure-management practice under a continuous threat exposure management program should extend that same cadence and tooling to model endpoints rather than standing up a parallel process.

Human oversight and override monitoring

Article 14 requires that high-risk systems be designed so humans can effectively oversee them, including the ability to intervene or stop the system. That means tracking override rate (how often humans reverse or reject a model recommendation), override latency (how long it takes a human to act when required), and dismissal-without-review rate (how often a human accepts a recommendation without evidence of substantive review, which is a compliance red flag masquerading as operational efficiency). A high dismissal-without-review rate is one of the most reliable early indicators that "human in the loop" has degraded into "human rubber-stamping the loop," and it is exactly the kind of pattern a regulator will look for.

Evidence automation and the audit trail

Evidence automation is the practical discipline of ensuring that every control described above produces its own proof of execution without a human having to manually assemble it later. This matters enormously in a market-surveillance context: under Article 74, a national market surveillance authority can request access to the technical documentation, logs, and evidence of conformity, and providers are legally obligated to cooperate. An organization that has to spend three weeks reconstructing evidence from disparate systems when that request lands has already lost the argument that its risk management system is "continuous" as the Act requires.

Designing the evidence schema

Every evidence record should carry a minimum common envelope regardless of which control produced it: a unique record ID, the control identifier it maps to (ideally referencing the specific article and paragraph), the system and model version under evaluation, a timestamp, the evaluation result, the identity of the actor (automated policy engine or named human) that produced the result, and a hash linking to the previous record in the chain for that system. This uniformity is what lets you build a single query interface across dozens of distinct controls rather than maintaining bespoke evidence formats per team, which is the single biggest reason evidence automation projects stall — every team invents its own format and nothing composes.

Automated technical documentation generation

Annex IV specifies a lengthy list of required technical documentation contents: a general description of the system and its intended purpose, design specifications, the data used and its provenance, the risk management measures applied, performance metrics, human oversight measures, and lifecycle changes. Rather than authoring this as a static Word document that goes stale the day after a model retrain, mature teams generate it as a templated report pulled live from the model registry, the evidence ledger, and the monitoring dashboards — regenerated automatically on every version bump and diffed against the prior version so reviewers can see exactly what changed and why. This turns technical documentation from a compliance tax into a genuinely useful engineering artifact, because it is the same information a new engineer needs when onboarding onto the system.

Chain of custody for training data

A defensible answer to "where did this training data come from and what gives you the right to use it" requires lineage tracking that survives multiple hops of transformation — raw collection, labeling, augmentation, filtering, and feature engineering — each hop tagged with its own provenance record. This is precisely the kind of structured, governed data foundation that a platform like MoxDB is built to provide: a single system of record for data lineage, retention, and access policy that both AI training pipelines and compliance evidence generation can query against, rather than compliance teams reverse-engineering lineage from scattered ETL scripts after the fact.

Immutability and access control on the ledger itself

The evidence ledger is only as credible as its own tamper-resistance. Write access should be restricted to the automated systems producing evidence (no human should be able to directly edit a written record), read access should be broadly available to compliance, audit, and engineering stakeholders on a need-to-know basis, and any correction to a prior record must be implemented as a new record referencing and superseding the old one — never an in-place edit. This is standard practice for financial audit logs and security event logs alike, and AI compliance evidence deserves the same rigor.

Mapping EU AI Act obligations to SOC, SRE, and platform engineering workflows

One of the most useful things a compliance-as-code program can do is stop treating "AI Act compliance" as a new department’s problem and instead map each obligation onto the team that already owns the relevant operational muscle. This avoids the common anti-pattern of standing up a parallel AI-governance function that duplicates security and reliability tooling under a different name.

SOC and threat-detection teams

SOC analysts already triage anomalies, correlate signals across systems, and escalate through defined severity tiers. Extending that muscle to AI-specific signals — a spike in adversarial probe detections against an LLM endpoint, an unusual pattern of prompt-injection attempts, or a sudden divergence in model output distribution consistent with a poisoning attack — is a natural extension of an agentic SOC practice rather than a new discipline. Feed AI-specific telemetry into the same detection and response pipeline used for the rest of the security estate, and route confirmed AI incidents through the existing alert triage workflow with an added classification step that flags whether the incident meets the Article 73 "serious incident" bar (death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of fundamental rights obligations, or serious harm to property or the environment).

SRE and platform engineering teams

Model drift and performance decay are, structurally, reliability problems: something that used to work within acceptable bounds now does not. Treating fairness and accuracy thresholds as error-budget-style SLOs lets SRE teams apply the same on-call, runbook, and postmortem discipline they already use for latency and availability. A model that breaches its drift SLO should page the on-call engineer exactly the way a service breaching its error-rate SLO does, and the resulting postmortem should feed back into both the reliability program and the compliance evidence ledger simultaneously — one incident, two consumers of the record, not two separate incident-management processes that drift out of sync with each other.

Identity and access teams

Article 14’s human oversight requirement and Article 15’s cybersecurity requirement both depend on knowing precisely who can influence, retrain, or override a high-risk model, and on ensuring that access is least-privileged and strongly authenticated. This is a direct extension of existing identity and privileged access management practice: model registries, feature stores, and training pipelines should sit behind the same PAM controls, session recording, and just-in-time elevation used for other sensitive production systems, with every privileged action against a model artifact captured as an evidence-ledger event.

NOC and integrated operations teams

For organizations running high-risk AI in critical infrastructure contexts (energy grid optimization, water treatment control, telecom network management), post-market monitoring effectively merges with existing network and infrastructure operations. An integrated NOC/SOC model, where infrastructure health and security signals are correlated in one operational view, is the natural home for the continuous monitoring layer described earlier, because the personnel already on shift are the ones best positioned to recognize when an AI-driven control action is behaving anomalously in the context of the broader system it is managing.

Incident response and post-market monitoring in practice

Article 72 requires providers of high-risk AI systems to establish and document a post-market monitoring system proportionate to the nature of the AI technology and the risks of the system, actively and systematically collecting, documenting, and analyzing relevant data on the performance of the system throughout its lifetime. Article 73 layers a hard reporting obligation on top: providers must report serious incidents to the relevant market surveillance authority without undue delay, and no later than 15 days after becoming aware of the incident (10 days for incidents involving death, 2 days for incidents involving widespread infringement of obligations or serious and irreversible disruption of critical infrastructure management, with an initial report allowed to be incomplete and followed by a full report).

Defining the trigger conditions in advance

The 15/10/2-day clocks only work in an organization’s favor if the detection-to-classification step is fast and largely automated. That means defining, before an incident ever happens, the specific monitoring signals that constitute presumptive evidence of a serious incident: a fairness-metric breach affecting a protected class at a magnitude the organization has pre-classified as a fundamental-rights infringement, a safety-critical system producing an output associated with a confirmed adverse health or safety event, or a critical-infrastructure control system executing an anomalous action correlated with a service disruption. Pre-classifying these triggers, with legal and compliance sign-off obtained in advance rather than negotiated in the moment, is what makes a same-day or next-day report achievable instead of an emergency scramble that blows through the statutory clock.

The incident workflow

1. Detection: a monitoring threshold breach, a customer complaint, or an internal report triggers an incident ticket, automatically tagged with the system, model version, and relevant AI Act obligation.
2. Triage and classification: an on-call reviewer (SOC or SRE, per the mapping above) confirms whether the event meets the pre-defined serious-incident criteria within a target of hours, not days — this triage step is the one place human judgment is essential and should not be fully automated away.
3. Containment: depending on severity, containment can mean routing all further decisions through mandatory human review, rolling back to a prior model version, or disabling the feature entirely — each action logged to the evidence ledger with a timestamp that starts the regulatory reporting clock.
4. Regulatory notification: the reporting service (Layer 5 of the architecture above) generates the initial report from the evidence already captured, submitted to the relevant market surveillance authority within the applicable window, followed by a complete report once the investigation concludes.
5. Root cause and remediation: a postmortem is conducted jointly by the owning engineering team and compliance, feeding both a reliability improvement (as an SRE would expect) and an update to the risk management system and technical documentation (as Article 9 requires).

The organizations that struggle most with this workflow are the ones where compliance, security, and engineering maintain separate incident-tracking systems that require manual reconciliation. The fix is not a new tool, it is a shared incident taxonomy and a single system of record, with different teams subscribing to the fields relevant to them.

Governance, roles, and working with notified bodies

The Act creates specific organizational roles that need to be assigned to actual people, not left as an abstraction in a policy document. Providers of high-risk AI systems must establish a quality management system (Article 17) covering strategy for regulatory compliance, techniques for design and development, testing and validation procedures, and post-market monitoring procedures. For certain high-risk categories, a conformity assessment must be carried out either through internal control or, where the harmonized standard requires it or none exists, by an accredited third-party notified body — comparable in spirit to how medical device and machinery certification already works in the EU.

Who owns what

A workable RACI splits responsibility roughly as follows: a designated AI compliance officer (who may sit within legal, risk, or a dedicated AI governance function) owns the overall risk management system and is the accountable party for regulatory reporting; the engineering lead for each high-risk system owns the technical documentation and the day-to-day operation of the monitoring and evidence pipeline for that system; the SOC owns detection and initial triage of AI-specific security and safety incidents; and an executive sponsor (increasingly a Chief AI Officer or equivalent) owns the budget and cross-functional prioritization needed to keep the always-on assurance architecture funded as a permanent capability rather than a one-off project.

Working with the EU AI Office and national authorities

The EU AI Office, established within the European Commission, has primary responsibility for GPAI model oversight, while national market surveillance authorities handle high-risk system enforcement within their jurisdictions, coordinated through the European Artificial Intelligence Board. Practically, this means an organization deploying high-risk AI across multiple member states needs to track which national authority is the lead contact for each deployment and maintain a single, coherent evidence package that can be presented consistently regardless of which authority requests it — another argument for a unified evidence ledger rather than country-specific documentation silos that inevitably drift out of alignment with each other.

Penalties as a forcing function

The Act’s penalty structure is tiered specifically to create pressure proportional to severity: violations of prohibited practices (Article 5) can draw fines up to €35 million or 7% of global annual turnover, whichever is higher; violations of most other obligations (including the high-risk requirements in Articles 9–15) can draw fines up to €15 million or 3% of global turnover; and supplying incorrect, incomplete, or misleading information to authorities or notified bodies can draw fines up to €7.5 million or 1% of turnover. For SMEs and startups, fines are capped at the lower of the fixed amount or the percentage, which softens but does not eliminate the exposure. These numbers matter operationally because they are the business case that justifies funding an always-on assurance architecture as infrastructure rather than as a discretionary compliance project that gets cut when budgets tighten.

Harmonizing the EU AI Act with NIST AI RMF, ISO/IEC 42001, and existing security programs

Very few organizations are building an AI compliance program from a blank slate against a single regulation. Most already have some combination of the NIST AI Risk Management Framework, ISO/IEC 42001 (the AI management system standard), SOC 2, and sector-specific frameworks in place, and the practical engineering challenge is harmonizing controls rather than running parallel, duplicative programs for each.

The good news is that the underlying control objectives overlap heavily. NIST AI RMF’s four functions — Govern, Map, Measure, Manage — correspond closely to the Act’s risk management system, technical documentation, monitoring, and mitigation obligations respectively. ISO/IEC 42001’s management-system structure (policy, objectives, risk assessment, internal audit, management review) maps cleanly onto the governance layer described earlier, and organizations that are already ISO/IEC 42001 certified have a substantial head start on demonstrating the "quality management system" the Act requires under Article 17. The right architectural approach is to build the evidence schema and control taxonomy once, tag each control with every framework it satisfies (a single fairness-monitoring control might satisfy an EU AI Act Article 15 obligation, a NIST RMF "Measure" function requirement, and an internal responsible-AI policy simultaneously), and generate framework-specific reports as views over that shared control set rather than maintaining separate control implementations per framework.

This is precisely the design principle behind treating compliance as part of the broader AI-native technology stack rather than a bolt-on function: the same telemetry, policy engine, and evidence ledger that support security operations, reliability engineering, and responsible-AI governance should be the substrate for regulatory compliance too. Duplication across these programs is not just wasteful, it is a source of the exact inconsistency that erodes credibility with regulators — if your ISO 42001 audit and your AI Act evidence package disagree about a model’s fairness metrics because they were computed by two different, unsynchronized pipelines, you have created a problem regulators are specifically trained to notice.

A practical rollout roadmap

Organizations rarely have the luxury of building the full five-layer architecture at once. A phased rollout that delivers defensible value at each stage looks like this in practice.

Phase 1 (0–90 days): inventory and classification

Build the system inventory, classify every AI system against the Act’s risk tiers, and identify which systems are Annex III high-risk. This phase is pure discovery and typically surfaces more shadow-AI deployments (internal tools built on top of a GPAI API without formal review) than most organizations expect. Deliverable: a living register, not a static spreadsheet, ideally integrated with existing CMDB tooling.

Phase 2 (90–180 days): instrumentation and evidence schema

Stand up structured logging for the highest-risk systems first, define the common evidence-record schema, and stand up the append-only ledger. Resist the temptation to build custom logging per team — the schema discipline established here determines whether phases 3 and 4 are tractable or become a permanent integration project.

Phase 3 (180–270 days): policy-as-code gates

Encode the highest-value Article 9–15 obligations as automated gates in the model registry and CI/CD pipeline, starting with data governance (Article 10) and logging (Article 12), which are the most straightforwardly automatable, before moving to the more judgment-dependent human oversight (Article 14) controls.

Phase 4 (270–365 days): continuous monitoring and reporting

Deploy drift, fairness, and robustness monitors against production traffic with defined SLOs and paging, and build the automated technical-documentation and incident-reporting generators against the now-populated evidence ledger. At this point the organization can, for the first time, answer a market-surveillance request within days rather than weeks, and that responsiveness is itself a compliance signal regulators weigh favorably.

Ongoing: expand coverage and harmonize frameworks

Extend the architecture to lower-risk systems opportunistically, and layer in NIST AI RMF and ISO/IEC 42001 mappings so the same control set serves multiple audiences. Treat the assurance architecture itself as a product with a backlog, an owner, and a maintenance budget — because the Act’s obligations do not sunset, and neither should the system built to satisfy them.

Frequently asked questions