EU AI Act: A CISO's Runtime Controls Checklist

Not legal advice. Consult counsel for your specific jurisdiction.

On 2 August 2026, the EU AI Act's obligations for high-risk AI systems take full effect. If your company runs AI in production and it touches EU users, employees, or operations, you have a narrow window to put the runtime controls in place that satisfy them. 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 August 2026: High-risk AI obligations — this piece's focus
• 2 August 2027: Embedded high-risk AI obligations (AI baked into regulated products)

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.

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 gates that detect data distribution shift in production. 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 gates that run before deployment promotions and block when accuracy or robustness metrics regress. The eval run result 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 block promotion when accuracy or robustness metrics regress. (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 2 August 2026.

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 August 2026

August 2 is a start, not a finish line.

2 August 2027 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 deadline passes. The first significant enforcement actions from national market surveillance authorities are likely in late 2026 or early 2027.

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 Quantlix

Quantlix 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-gated deployment promotion (Art. 15).

Try the sandbox at quantlix.ai/boundary/sandbox, or book time to discuss your specific high-risk AI use case at quantlix.ai/contact.

This piece reflects the author's technical interpretation of the EU AI Act as of June 2026. It is not legal advice.