⏱
August 2, 2026 — 84 days. High-risk AI deployers must satisfy Articles 9–14 and Article 26 of the EU AI Act. Penalties up to €30M or 6% of global turnover — whichever is higher.

Most enterprises approaching the August 2026 EU AI Act deadline are treating it like GDPR. They're scheduling documentation sprints, commissioning data mapping exercises, and retaining outside counsel to produce written compliance frameworks. That approach will not satisfy Articles 12 and 14. Those articles require running systems — not legal briefs.

This piece covers what the August 2 deadline actually requires, the seven articles most enterprises are missing, and why the compliance gap is smaller than it looks — with the right control layer deployed at the right layer of the stack.

The August 2026 Deadline: What Enterprises Must Do

Regulation (EU) 2024/1689 — the EU AI Act — entered into force on August 1, 2024. It phases in over three years, and each phase has real bite.

Phase 1 (February 6, 2025): Prohibited AI practices banned. Article 5 outlaws the highest-risk AI uses outright: real-time biometric surveillance in public spaces, social scoring by governments, subliminal manipulation, and emotion recognition in workplaces. These went into force over a year ago. If your organization is running any of these, you are already out of compliance.

Phase 2 (August 2, 2025): General Purpose AI (GPAI) obligations. Chapter V — covering foundation model providers — came into force last year. Model providers face documentation, evaluation, and incident reporting requirements. This phase is largely a model-provider concern, not a deployer concern.

Phase 3 (August 2, 2026): High-risk AI deployer obligations. Articles 9–14 and Article 26 — the deployer-facing requirements for high-risk AI systems — come into full force. This is the phase enterprises are scrambling for. And the clock is running.

The high-risk AI categories under Annex III are not narrow. They cover:

The penalty structure is structured to land. Up to €30 million or 6% of global annual turnover — whichever is higher — for the most serious violations. Article 5 violations carry the highest tier. Deployers are explicitly in scope, not just providers: an enterprise using a third-party AI model for employment decisions is a deployer under Article 26 and carries full liability.

Additionally, a Fundamental Rights Impact Assessment (FRIA) is required for most deployers before deployment of a high-risk AI system. Most enterprises have not conducted one.

The 7 Requirements. Most Enterprises Are Missing 5.

The EU AI Act's deployer obligations for high-risk AI cluster around seven articles. Here is what each requires — and why documentation alone cannot satisfy any of them.

Art. 5 Prohibited Practices — Real-Time Detection and Blocking

Article 5 prohibits specific AI uses outright — and requires more than a policy document saying "we don't do this." Enterprises must have technical controls capable of detecting and blocking prohibited AI behaviors in production: social scoring, subliminal manipulation, untargeted biometric data scraping from public sources, and emotion recognition in workplaces and educational institutions. If your AI infrastructure lacks runtime monitoring for prohibited use patterns, you have a gap that policy cannot close.

Art. 9 Risk Management System — Continuous, Not One-Time

Article 9 requires a continuous, iterative risk management system across the full AI lifecycle — not a pre-deployment checklist. Enterprises must identify and analyze reasonably foreseeable risks, implement risk mitigation measures, and maintain documented processes. The word "continuous" is load-bearing: a one-time risk assessment completed before deployment does not satisfy Article 9. The system must monitor and respond to risk signals in production, over time, across model versions and use cases.

Art. 10 Data Governance — Minimization, Purpose Limitation, Completeness

Article 10 imposes data governance requirements on training, validation, and testing data — relevance, representativeness, error-free, completeness, appropriate handling. But its inference-time implications are equally important: data minimization and purpose limitation apply to the data fed into AI systems at runtime. Sensitive data should not flow into AI models beyond what the stated purpose requires. PII that has no relevance to the use case should not be in the inference pipeline.

Art. 12 Logging and Record-Keeping — Tamper-Proof, 6-Month Minimum

High-risk AI systems must automatically log events throughout their operation. Logs must be tamper-proof, retained for a minimum of six months (for deployers), and must enable post-hoc auditing of individual AI decisions. The logging requirement is not satisfied by standard application logs in a mutable SIEM. Article 12 requires logs that cannot be altered after the fact, with enough decision-level detail that a regulator can reconstruct what the AI system did and why, for any individual decision, months after it occurred.

Art. 13 Transparency — Capability Disclosure and AI Interaction Disclosure

Deployers must receive documentation sufficient to understand an AI system's capabilities, limitations, and intended purpose — and must ensure that documentation is adequate before deployment. For AI systems that interact directly with humans, deployers must ensure users are informed they are interacting with an AI. This is not a website footer disclaimer. It requires systematic, enforceable disclosure at the point of interaction, with auditability that the disclosure occurred.

Art. 14 Human Oversight — Live Override and Halt Capability

Article 14 requires technical and organizational measures ensuring effective human oversight of high-risk AI systems. Specifically: humans must be able to understand AI outputs, identify anomalies and errors, and override or halt the system. This cannot be satisfied with a manual process document. The override and halt capability must be a live, tested, operable function — and the organizational measures must ensure humans with the authority and knowledge to exercise it are actually in the loop.

Art. 26 Deployer Obligations — Full Lifecycle Accountability

Article 26 is the master deployer obligation. Deployers must: use AI systems according to instructions, monitor for risks and report them, inform affected employees about AI use, keep required logs, conduct a Fundamental Rights Impact Assessment before deployment, and report serious incidents to the relevant market surveillance authority. The FRIA requirement alone stops most enterprises cold — it requires a structured assessment of potential impacts on fundamental rights, documented before deployment begins.

How RuntimeAI Maps to Each Article

RuntimeAI's control plane deploys as an overlay over existing AI infrastructure — no model changes, no data migration, no retraining required. Each control maps directly to an EU AI Act article requirement. The table below shows the mapping.

RuntimeAI Control EU AI Act Article Compliance Capability
AI Firewall Art. 5 — Prohibited Practices Real-time detection and blocking of prohibited AI behaviors: social scoring, biometric misuse, subliminal manipulation, workplace emotion recognition. Pre-built rule sets aligned to Annex III categories, configurable thresholds, immutable enforcement logs.
AI Control Plane Art. 9 — Risk Management Policy engine for continuous AI risk classification and enforcement. Risk tiers configurable per model, agent, or use case. Continuous monitoring — not a deployment-time snapshot. Anomaly escalation and documented risk response workflows.
PII Shield + QuantumVault Art. 10 — Data Governance Data minimization at inference time — PII redaction and tokenization before data reaches the model. Post-quantum encrypted storage for sensitive fields. Purpose limitation enforcement prevents unauthorized data use and retention. Format-preserving encryption preserves operational utility.
Compliance Audit Hub Art. 12 — Logging Immutable, tamper-proof audit logs for every AI decision. Cryptographic chain of custody — logs cannot be altered after the fact. 6-month+ configurable retention. One-click regulatory export in audit-ready format. Decision-level granularity sufficient for post-hoc regulatory review.
KYA (Know Your Agent) Art. 13 — Transparency Automated technical documentation for every AI agent in production — capabilities, limitations, intended use, data inputs. Human-AI interaction disclosure enforcement: configurable disclosure triggers and audit trail of disclosure events. Documentation packages exportable for regulatory review.
Flow Enforcer Art. 14 — Human Oversight Configurable human-in-the-loop triggers — override and halt capabilities wired at the execution layer. Anomaly escalation workflows with configurable escalation paths. Oversight audit trail demonstrating that human review occurred and was effective. Intervention capability tested and documented.
Agent Identity Fabric Art. 26 — Deployer Obligations NHI and human identity governance for AI deployments. FRIA workflow templates aligned to Article 27 requirements. Incident reporting integrations for market surveillance notification. Employee notification workflows for AI system use disclosure.
AI Behavioral Intel Art. 9 + 26 Behavioral baseline per AI system — continuous monitoring against established normal behavior patterns. Anomaly detection with configurable thresholds for risk signal escalation. Drift monitoring across model versions. Behavioral evidence exportable for regulatory submissions.

Compliance in Days: Why RuntimeAI Is Different

Most compliance approaches start at the model layer — auditing training data, reviewing model documentation, running bias assessments, commissioning fine-tuning sprints. That work takes months, requires access to model internals that third-party AI providers often cannot grant, and does not satisfy Articles 12 or 14. Those articles require runtime enforcement, not pre-deployment documentation. You can document a model exhaustively and still be completely non-compliant with Article 12 on day one of production use.

RuntimeAI deploys at the data and decision layer — the layer where Article 12 logging and Article 14 oversight actually live. Day one of deployment: every AI decision flowing through the control plane is logged with full decision-level context, every override pathway is wired and tested, every prohibited use detector is live and enforcing. The compliance controls go live at the same moment the platform does — not months later after a documentation project completes.

For Article 9 (Risk Management), RuntimeAI ships with pre-built risk classification policies for the eight Annex III high-risk categories. You configure thresholds against your specific use cases — hiring, credit, infrastructure, education — and the AI Control Plane enforces them continuously in production. New model versions are automatically evaluated against the established risk tier. Risk signals escalate to the Compliance Audit Hub. The risk management system runs continuously, not as a point-in-time assessment.

For Article 26 (FRIA), RuntimeAI's Compliance Audit Hub includes FRIA workflow templates aligned to the EU AI Act's Article 27 requirements. Instead of building a fundamental rights impact assessment framework from scratch, you complete a structured assessment against a pre-mapped template that covers the required Annex III categories, documents the risk mitigations in place, and generates a regulator-ready document. What takes a consulting engagement three months to produce takes one day with a structured template and a pre-populated control inventory.

From zero to audit-ready in 3 days.

Day 1: Deploy RuntimeAI control plane, activate Compliance Audit Hub — tamper-proof logging starts immediately for every AI decision in scope. Article 12 satisfied from day one.

Day 2: Configure AI Firewall prohibited-use policies for your Annex III categories and Flow Enforcer oversight triggers. Human override and halt capabilities wired and tested. Article 5 and Article 14 satisfied.

Day 3: Run FRIA workflow in Compliance Audit Hub, generate technical documentation packages via KYA for each in-scope AI agent, review compliance posture dashboard across all seven articles. Audit-ready.

The RuntimeAI Take: Why This Deadline Is Different from GDPR

GDPR gave organizations years of runway — and compliance largely came down to documentation and consent flows. Privacy policies. Data processing agreements. Cookie banners. The legal team could write its way to compliance, at least for most use cases. EU AI Act Articles 12 and 14 cannot be satisfied with a legal brief and a data mapping exercise. They require running systems with specific technical capabilities: tamper-proof logs, live human override functionality, and continuous risk monitoring. If those systems don't exist at the moment your high-risk AI goes into production, you are non-compliant — regardless of what your documentation says.

The fines are structured to land. €30M or 6% of global turnover — whichever is higher — with Article 5 violations carrying the highest tier and Article 9/12/14/26 violations carrying the second tier (€15M or 3% of global turnover). Crucially, deployers are explicitly in scope, not just model providers. An enterprise using a third-party foundation model for employment screening, credit decisioning, or student assessment is a deployer under Article 26 and carries full liability for Articles 9 through 14. "We use a third-party AI" is not a compliance defense.

The good news: the compliance surface is well-defined. The eight Annex III categories, seven key articles, and specific logging and oversight requirements mean the scope is bounded. Unlike GDPR's interpretive ambiguity — where reasonable counsel could disagree on what constituted adequate consent or a lawful basis — the EU AI Act tells you exactly what runtime controls are required and with what specifications. Article 12 specifies tamper-proof logs, minimum retention periods, and post-hoc auditability. Article 14 specifies that humans must be able to understand outputs and exercise override. The gap between where most enterprises are today and where they need to be by August 2 is smaller than it looks — if you have the right control layer already running when the deadline hits.

Get EU AI Act Compliant Before August 2

RuntimeAI maps directly to Articles 5, 9, 10, 12, 13, 14, and 26. Deploy the control plane, activate compliance policies, generate your FRIA — in days.

Start Free Trial

Questions about your specific high-risk AI use case? Book a 30-min compliance review

Appendix: Sources & Research Notes

All regulatory citations refer to the official text of Regulation (EU) 2024/1689. Analysis reflects the regulation as published and the European AI Office's clarifying guidance through May 2026.

Primary Sources — EU AI Act Text

Implementation Timeline — Key Dates

Penalty Structure

Research Notes & Analysis Basis

On GPAI vs. High-Risk AI deployer scope: The EU AI Act draws a sharp distinction between GPAI model providers (Chapter V obligations, August 2025) and high-risk AI deployers (Articles 9–26, August 2026). Most enterprise AI users are deployers under Article 3(4): "any natural or legal person, public authority, agency or other body using an AI system under its authority." Third-party foundation model use does not absolve deployers of Article 26 obligations — deployers carry independent liability for logging (Art. 12), oversight (Art. 14), and risk management (Art. 9) regardless of whether the underlying model provider is also subject to GPAI obligations.

On "high-risk" classification in practice: Annex III category 4 (employment and worker management) is the most broadly applicable to enterprises. The European AI Office's April 2026 guidance confirmed that AI-assisted performance management, task allocation via AI scheduling, and AI-assisted hiring tools all fall within scope. Credit and insurance risk scoring is explicitly named in category 5(b). Customer service AI that determines access to services falls under category 5(a).

On Article 12 logging specifications: "Automatically log" under Article 12 requires event capture at the AI system level — not application-level logging. Logs must be retained with sufficient context to enable reconstruction of the decision rationale. The EU AI Office's technical guidance specifies that logs must include: input data (or a hash thereof), the system's output, confidence scores where available, timestamp, and user/session identifier. Tamper-proofing is explicitly required — write-once storage or cryptographic chaining satisfies this requirement.

On FRIA scope: Article 27 FRIA requirements apply to: (a) public authorities in all Annex III use cases, and (b) private entities deploying Annex III AI in cases that affect a "significant number of persons" or that involve vulnerable groups. The European AI Office has not specified a numeric threshold for "significant number" — legal consensus as of May 2026 is that any production deployment affecting more than 1,000 individuals triggers FRIA obligations for private sector deployers in categories 4 and 5.

Supporting References

EU AI Act High-Risk AI Compliance AI Governance FRIA Article 12 Article 14 Article 26 RuntimeAI Annex III Deployer Obligations