--- title: "EU AI Act: A CISO's Runtime Controls Checklist" description: "A CISO's checklist mapping EU AI Act high-risk obligations to the runtime controls production AI needs: logging, oversight, and evidence. Not legal advice." canonical: https://www.norcaster.com/article/eu-ai-act-runtime-controls --- # EU AI Act: A CISO's Runtime Controls Checklist 2026-06-13 · Jesper Jensen, Norcaster Not legal advice. Consult counsel for your specific jurisdiction. The EU AI Act's obligations phase in through 2027–28: general-purpose AI duties already apply, and the high-risk obligations land on 2 December 2027 (Annex III stand-alone systems) and 2 August 2028 (AI embedded in regulated products) under the Digital Omnibus timeline. If your company runs AI in production and it touches EU users, employees, or operations, the window looks longer than it is — runtime evidence can't be backfilled, so an audit in 2027 needs traces that started accumulating today. Most articles you've read about the Act focus on what the regulation says. This one maps the text to the controls you actually need to deploy — not legal interpretation, but platform requirements. **Who this is for:** CISOs, Heads of GRC, AI Governance leads, and Heads of Platform Engineering at companies running AI in production with EU exposure. **The stakes:** €35M or 7% of global turnover for prohibited AI practices. €15M or 3% for non-compliance with key obligations including record-keeping and risk management. The Act is not aspirational guidance — it has teeth. ## A 90-second primer on the Act The EU AI Act categorizes AI systems by risk and imposes obligations proportional to that risk. There are four tiers. **Unacceptable risk** — banned outright. AI systems for social scoring, subliminal manipulation, real-time biometric surveillance in public spaces (with narrow exceptions). Prohibited as of 2 February 2025. **High risk** — the most regulated tier, and the one this piece focuses on. High-risk AI includes systems used in critical infrastructure, education, employment decisions, access to essential services, law enforcement, migration, justice, and any AI that functions as a safety component of a regulated product. **Limited risk** — transparency obligations only. Chatbots must disclose they're AI. Minimal compliance burden. **Minimal risk** — spam filters, AI-enabled games, most consumer recommendations. Essentially unregulated. **Compliance timeline:** - 2 February 2025: Prohibited practices ban — live - 2 August 2025: GPAI obligations for foundation model providers — live - 2 December 2027: High-risk AI obligations for Annex III stand-alone systems — this piece's focus - 2 August 2028: Embedded high-risk AI obligations (AI baked into regulated products, Annex I) Dates reflect the Digital Omnibus amendments to the original 2026–27 schedule; confirm the current timeline with counsel. ## The six articles that determine your runtime obligations Out of 113 articles in the Act, six are where runtime controls actually matter. Legal conformity assessment remains separate. | Article | What it requires | Primary runtime control | | --- | --- | --- | | Art. 9 | Continuous risk identification, mitigation, and evidence | Policy enforcement + enforcement logs | | Art. 10 | Data governance, bias monitoring, drift detection | Eval runs + data lineage | | Art. 12 | Automatic logging, multi-year retention, regulatory access | Audit-ready trace store | | Art. 13 | Output traceability, source provenance, deployer transparency | Trace summaries + citation tracking | | Art. 14 | Human oversight: interpret, override, stop | Approval gates + RBAC | | Art. 15 | Accuracy, robustness, adversarial resilience | Eval runs + request-boundary defenses | These six are not independent. An approval gate (Art. 14) without a log of the decision (Art. 12) satisfies neither. Policy enforcement (Art. 9) without multi-year retention (Art. 12) creates a control you can't prove existed. The architecture that satisfies all six is a layered runtime. ## Article-by-article: what each requires and what runtime controls satisfy it ### Article 9 — Risk management system **What it requires:** A documented risk management system that identifies, evaluates, and mitigates risks throughout the AI system's lifecycle. Continuous, not point-in-time, and must produce evidence of actual mitigation. **Runtime controls that satisfy it:** - Policy enforcement at the request boundary — catches identified risks (PII leakage, prompt injection, output category violations) before execution. Each policy maps to an identified risk. - Continuous enforcement logging tied to specific risk categories. The log must record which policy, which risk category, which rule triggered. - A documented mapping from identified risk to mitigation control to trace evidence. **What most teams get wrong:** Treating risk management as a quarterly document review. The Act expects evidence of actual mitigation running in production. Your audit package needs specific traces showing the controls fired on real requests — not a control description, but control execution history. ### Article 10 — Data and data governance **What it requires:** Training, validation, and test datasets must be relevant, representative, and complete. For deployers, this extends to monitoring for data quality degradation in production. **Runtime controls that satisfy it:** - Eval runs against a versioned reference dataset, repeated after each model or prompt change, so a drop in quality is recorded against the version that caused it. When what your model sees diverges from what it was trained on, Article 10 expects you to catch it and respond. - Trace evidence linking inputs to data lineage for retrieval-augmented systems — which sources, from which knowledge base, with what freshness. - Redaction evidence for PII detection at the request boundary. **What most teams get wrong:** Treating Article 10 as entirely owned by the MLOps team. The runtime side — detecting production data drift and producing evidence — is a CISO-level concern under most enterprise risk frameworks. ### Article 12 — Record-keeping **What it requires:** Automatic logging of events for the lifecycle of high-risk AI systems. Logs must capture what happened in a form regulators can access. For most high-risk categories: multi-year retention. Logs must remain accessible to national competent authorities. **Runtime controls that satisfy it:** - Every request, model call, tool invocation, policy decision, and output captured in a single timeline per request. - Tamper-evident storage. Hash-chaining or cryptographic anchoring (such as Sigstore/Rekor) lets you prove a log wasn't modified after the fact. - Multi-year retention with regulatory access controls. Standard operational observability tools (Datadog, New Relic) retain 30-90 days. That is not Article 12. - Standardized export format that a regulator or auditor can read without access to your systems. **What most teams get wrong:** Underscoping Article 12. Teams implement logging and discover only when facing an audit that their logs are 30 days old and in a format no auditor can parse. Article 12 is not about having logs — it's about logs that survive an audit. ### Article 13 — Transparency and provision of information **What it requires:** Users and deployers must have enough information to understand what the system does, its capabilities and limitations, and enough traceability to interpret and act on its outputs responsibly. **Runtime controls that satisfy it:** - Citation and source tracking for retrieval-augmented outputs: which documents were retrieved, in what relevance order, from which knowledge source, at what timestamp. - Provenance metadata on every output: model version, inputs, policy configuration, latency. - Human-readable trace summaries surfaced to deployers — not raw engineering telemetry, but evidence readable by a compliance lead. **What most teams get wrong:** Treating transparency as a UI label. Article 13 expects technical traceability — an output's provenance chain must be reconstructable and surfaceable. ### Article 14 — Human oversight **What it requires:** High-risk AI systems must be designed so natural persons can effectively oversee them during runtime operation — not just before deployment. The design must enable interpretation, override, and stopping. **Runtime controls that satisfy it:** - **Approval gates** — runtime checkpoints where an authorized human reviews a decision before it executes downstream. The gate records who approved, when, and on what basis. - **Override paths** — the ability to interrupt or modify a model's decision, with the override recorded as evidence. - **Stop capability** — the ability to disable a deployment immediately when oversight identifies a problem. - **Role-based access** governing who can approve, override, or stop — and audit logs proving who did what and when. **What most teams get wrong:** Building human oversight only into pre-deployment review. The Act expects runtime affordances in production, not organizational commitments in a governance document. ### Article 15 — Accuracy, robustness, and cybersecurity **What it requires:** Appropriate accuracy. Resilience against errors, faults, and inconsistencies. Resilience against adversarial inputs, data poisoning, and prompt injection. **Runtime controls that satisfy it:** - **Adversarial input detection at the request boundary** — prompt injection defenses, jailbreak detection, input sanitization. Detection events must be logged. - **Output validation** against expected schemas and content category constraints. - **Eval suites** run against deployment candidates and workflows before a promotion; the eval run result (pass/fail, suite version, scores), linked to its run and trace, is evidence. - **Provider redundancy and failover** — a single provider failure shouldn't cascade into system unavailability. **What most teams get wrong:** Treating accuracy as a property you measure once during training and then inherit. The Act expects continuous monitoring and evidence that you respond when accuracy degrades. ## The CISO compliance checklist For each item, the article it satisfies is noted. 1. Every AI request flows through a policy enforcement layer before reaching the model. (Art. 9, 15) 2. Policy decisions are logged with the request — which policy, which rule, which verdict — in a tamper-evident store. (Art. 9, 12) 3. PII is detected and redacted at the request boundary, with the redaction event recorded per request. (Art. 9, 10, 15) 4. Enforcement logs are retained for an appropriate period (plan for multi-year) in a system separate from operational observability. (Art. 12) 5. You can produce, on demand, a complete trace for any production AI request from the last 24+ months. (Art. 12) 6. Trace logs are exportable in a format a regulator or auditor can read without access to your systems. (Art. 12) 7. Logs are tamper-evident — you can prove a given log entry hasn't been altered since it was written. (Art. 12) 8. Output provenance metadata (model version, inputs, policy config, timestamp, sources cited) is captured per request. (Art. 13) 9. For retrieval-augmented systems: source citation and relevance ranking are recorded per output. (Art. 13) 10. Approval gates exist for high-risk operations, with a record of who approved, when, and on what basis. (Art. 14) 11. Authorized users can pause or stop a specific deployment in production within minutes — and the stop event is logged. (Art. 14) 12. Role-based access governs who can approve, override, or stop AI runtime decisions, with audit logs of those actions. (Art. 14) 13. Adversarial input detection (prompt injection, jailbreak) runs at the request boundary, with detection events logged. (Art. 15) 14. Eval suites run before deployment promotions, and a regression in accuracy or robustness metrics is recorded against the candidate version before it ships. (Art. 15) 15. Each high-risk AI use case has been evaluated against Annex III, with a documented risk-classification decision. (Art. 6) **How to score this:** If you can't tick 12 or more today, you have material work to do before the high-risk obligations land — and less runway than the 2027 date suggests, because the evidence an auditor samples has to have been accumulating for the whole period they examine. ## Three implementation patterns — and what to avoid ### Pattern A — Bolt-on at the model provider layer Teams add the safety classifiers their model provider ships — OpenAI Moderation, AWS Bedrock Guardrails, Azure Content Safety. Fast to turn on. But this ties your compliance infrastructure to a single vendor and doesn't satisfy Article 12: provider-layer guardrails don't give you a multi-year, tamper-evident, auditor-readable trace of every policy decision. They're operational safety features, not audit evidence. ### Pattern B — Build it yourself with a homegrown gateway Teams build their own policy and logging layer. This works if built to spec, but failures concentrate in the audit pipeline — the part nobody wants to build but Article 12 requires most rigorously. Teams that go this route tend to underscope multi-year retention and tamper-evidence until an auditor asks for them. ### Pattern C — Adopt a runtime control plane Teams deploy a layer that sits between their application and AI providers, enforcing policies and capturing audit-ready traces by design. Implementation is typically 2-6 weeks. The audit trail is a first-class artifact rather than a retrofit. **Common mistakes across all patterns:** - Underestimating Article 12 — the record-keeping requirement is more demanding than most teams initially scope - Treating Article 14 (human oversight) as documentation rather than runtime affordances - Confusing operational observability (for your SRE team) with audit evidence (for regulators) — different retention, access, format, and integrity requirements - Building once — the regulation evolves through delegated acts, harmonized standards, and enforcement guidance through 2028 ## What changes after December 2027 2 December 2027 is a start, not a finish line. **2 August 2028** brings obligations for high-risk AI embedded in regulated products — medical devices, machinery, vehicles. If your AI is a safety component of any regulated product, that date is on your calendar now. **Harmonized standards** from CEN and CENELEC are being developed through 2026-2028. These will define what "appropriate technical measures" means in operational detail. Compliance with harmonized standards creates a presumption of conformity. **Enforcement** will accelerate once the high-risk deadline passes. The first significant enforcement actions from national market surveillance authorities are likely to follow within months, and they will sample evidence from the period before the deadline, not after it. The teams that navigate this comfortably are the ones whose runtime architecture treats compliance evidence as a first-class output — not something assembled under time pressure before an audit, but something the system produces continuously as a side effect of running correctly. ## About Norcaster Norcaster is the AI Runtime Control Plane for production AI systems. We build the runtime layer that sits between your application and AI models — enforcing policies, capturing audit-ready traces, and giving compliance teams the evidence they need. The platform's governance module maps directly to the six articles above: policy enforcement (Art. 9), tamper-evident trace store with multi-year retention (Art. 12), output provenance and citation tracking (Art. 13), approval gates and RBAC (Art. 14), and eval runs linked to the candidate version (Art. 15). Try the sandbox at norcaster.com/boundary/sandbox, or book time to discuss your specific high-risk AI use case at norcaster.com/contact. --- This piece reflects the author's technical interpretation of the EU AI Act as of September 2026. It is not legal advice. ### New posts by email Technical posts on runtime policy enforcement and AI evidence. A few a month at most.