On 2 August 2026 the high-risk-system provisions of the EU AI Act become enforceable. National competent authorities will be designated, market surveillance will begin, and the penalty regime — up to €35 million or 7% of global annual turnover for the most serious violations — becomes operative. The general-purpose AI model provisions for systems placed on the market after 2 August 2025 are already enforceable; the high-risk obligations have been the slower-burning compliance challenge because the technical standards underneath them are still settling.
The compliance industry has produced a small library of readiness products. Most of them are reading the wrong sections of the regulation. This piece is the operational read — what actually changes on the day, the four obligations that will produce the first enforcement actions, where Article 14 human oversight is being misread, and the audit-trail pattern that survives a national-authority inspection.
Key takeaways
- On 2 August 2026 every high-risk AI system in production must meet Articles 8-15, have completed conformity assessment per Article 43, be registered in the EU database, run post-market monitoring per Article 72, and have incident reporting wired to the national authority per Article 73 — no grace periods, no carve-outs.
- Penalties run up to €35 million or 7% of global turnover for Article 5 prohibited practices, €15 million or 3% for high-risk obligation violations, and €7.5 million or 1% for misleading authorities — the GDPR enforcement template is the operational reference.
- Four obligations will produce the first enforcement actions: Article 9 risk management (must be continuous, not one-shot), Article 10 data governance (representativeness and bias evaluation must be demonstrable), Article 12 record-keeping (the audit-trail problem), and Article 14 human oversight (where most programmes misread the obligation).
- Article 14 does not require a human in the loop — it requires meaningful, contemporaneous oversight with information, time, and authority to intervene. Rubber-stamp approval, post-hoc audit, and delegated oversight to the model itself all fail inspection.
- The audit-trail pattern that survives inspection has six elements: end-to-end traceability, version-pinned policy, drift evidence, incident-reporting capability, human-oversight events as first-class data, and tamper-evident integrity — and most production systems have none of these wired correctly.
What 2 August 2026 actually means in practice
The framing that gets repeated is "the AI Act becomes enforceable on 2 August 2026." This is approximately right and operationally wrong. The Act entered into force on 1 August 2024. Different parts have been enforceable on different dates since.
The prohibited-practice provisions of Article 5 became enforceable on 2 February 2025 — these are the outright bans on practices like social scoring and emotion recognition in workplaces. Penalties for violation of Article 5 are at the top of the scale: up to €35 million or 7% of global turnover. The GPAI model provisions (Chapter V) became enforceable on 2 August 2025 — these create obligations on the provider side for any general-purpose AI model placed on the market after that date.
The 2 August 2026 milestone is the rest of the substantive obligations. Most importantly: Article 6 onwards on high-risk AI systems. Articles 8 through 15 are the conformity requirements — risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy/robustness/cybersecurity. Articles 16 through 28 are the obligations on providers, importers, distributors, and deployers. Articles 49 through 54 set up the EU database for high-risk systems and the conformity assessment regime. The penalty regime in Article 99 becomes fully operative.
What this means for an organisation deploying high-risk AI in the EU on 2 August 2026: every high-risk system in production must meet Articles 8-15, must have completed conformity assessment per Article 43, must be registered in the EU database, must have post-market monitoring in place per Article 72, and must have incident reporting wired to the national authority per Article 73. None of these are optional, none of these have grace periods beyond the date, and the highest tier of penalties applies to the most serious violations.
Which systems are actually "high-risk"
This is where most compliance programmes get scoping wrong. High-risk is defined in two places: Article 6(1) covers AI systems used as a safety component of a product covered by the Union harmonisation legislation listed in Annex I (toys, machinery, medical devices, lifts, radio equipment, etc.). Article 6(2) covers AI systems falling within the use cases enumerated in Annex III — biometric categorisation, critical infrastructure operation, education and vocational training (admission and assessment), employment (recruitment and HR), access to essential services (credit scoring, insurance pricing, public benefits), law enforcement, migration and border control, administration of justice.
The list looks specific. The scoping is broad. A recruitment screening tool that triages CVs is high-risk. A credit scoring model is high-risk. An education-admissions classifier is high-risk. An AI-assisted clinical decision support system is high-risk. A workforce productivity monitoring system can be high-risk depending on the specific use. An identity-verification system for government services is high-risk. Most regulated-enterprise AI deployments touch at least one of the Annex III categories.
The Article 6(3) derogation (added to reduce regulatory burden) allows providers to self-classify a system as not-high-risk if they can demonstrate it does not pose significant risk of harm — but this self-classification must be documented, submitted to the national authority on request, and survive scrutiny. Most organisations are over-using this derogation as an escape hatch. It is not. A national authority that disagrees with a self-classification can require reclassification, retrospective compliance, and impose penalties for the gap.
The four obligations that will produce the first enforcement actions
Across the conversations with EU regulators in the run-up to enforcement, four obligations are repeatedly named as the focus of initial market surveillance. The compliance programmes that address these four are in materially different shape from the ones that have produced a policy document without operationalising it.
One — Article 9: Risk Management System. A continuous, iterative risk management process running across the system's entire lifecycle. Not a one-shot risk assessment at deployment. The obligation is structural — risk identification, evaluation, mitigation, monitoring, and revision must be ongoing operational practice with documented evidence. The failure mode regulators are looking for: a risk register from the initial conformity assessment with no updates eighteen months later. That is non-compliance with Article 9 directly.
Two — Article 10: Data Governance. Training, validation, and test datasets must meet specified quality criteria — relevance, representativeness, freedom from errors and biases, statistical properties. For systems making decisions about EU natural persons, data governance must address bias detection and correction explicitly. The failure mode regulators are looking for: a model deployed against EU populations using training data the provider cannot demonstrably show represents those populations, with no bias evaluation across protected categories. The data governance obligation is one of the four that auditors find easiest to evaluate (the documentation exists or it does not), and one of the four most likely to produce enforcement findings on day one.
Three — Article 12: Record-Keeping. Automatic logging of events relevant to the system's risk assessment and post-market monitoring. The logs must enable identification of situations that may result in the system being a risk, support post-market monitoring per Article 72, and enable the system to be retraced (input, output, intermediate state) over its lifecycle. The failure mode: logging that captures inputs and outputs but not the decision logic, the model version in use, the prompt or context fed to a generative system, or the human-oversight events. This is the audit-trail problem and it is the failure most production AI systems will have when first inspected.
Four — Article 14: Human Oversight. The system must be designed and developed to allow meaningful human oversight, with measures appropriate to the risks, level of autonomy, and context of use. Oversight must enable humans to understand the system's capabilities and limitations, monitor its operation, detect anomalies, intervene or override outputs, and stop the system. The failure mode regulators are looking for, and the one most often misread: a "human-in-the-loop" approval workflow that the human cannot meaningfully evaluate because they have no information about how the system reached its output, no time to review properly, and no actual authority to override in practice. Article 14 oversight is meaningful or it does not satisfy the article. Theatre oversight is the easiest finding to make.
Where Article 14 is being misread
The most common mis-reading of Article 14 in the compliance programmes we see is that it requires a human in the loop. This is approximately right and operationally wrong. Article 14 requires "effective oversight by natural persons during the period in which the AI system is in use." The oversight must enable specified outcomes — understanding limitations, detecting anomalies, intervening, stopping the system. Whether that oversight is achieved by a human approving each output, a human reviewing samples, a human monitoring real-time dashboards with override authority, or a layered combination of these is a design choice. Article 14(3) specifically allows the measures to be commensurate with the risks.
What Article 14 does not allow is theatre oversight. Three patterns that will fail inspection:
The "rubber-stamp approval" where a human is presented with a model output and a button, with no information sufficient to evaluate the output, and is metric-evaluated on throughput. The European Data Protection Board has been explicit in its recent guidance: this pattern does not constitute meaningful oversight.
The "post-hoc audit" where outputs are reviewed weeks after the fact, with no ability to prevent harm before it occurs. This satisfies record-keeping but not Article 14, which requires oversight "during the period in which the AI system is in use" — meaning contemporaneous, not retrospective.
The "delegated oversight" where the system itself is presented as providing its own oversight via guardrails, monitoring, or self-checking. Article 14 requires natural persons. A safety surface inside the model is not Article 14 compliance, even if it is technically excellent.
The pattern that does satisfy Article 14 is layered. Automated monitoring detects anomalies in real time. A human oversight team is staffed with the information, the time, and the authority to evaluate flagged outputs and intervene. Sample-based human review on representative output distributions catches drift and bias the automated monitoring misses. Override authority is genuinely held by the humans, not by the model owners. And — critically — the design must make oversight possible, not merely permit it. A system that emits a probability score without context is harder to oversee than one that emits the score with the top three retrieved evidence chunks, the model's confidence calibration, and the comparable historical decisions. Article 14 requires the latter design discipline, not just the appointment of an oversight team.
The audit-trail pattern that survives inspection
Article 12 record-keeping intersects with Articles 9, 14, and 72 (post-market monitoring) into what is, operationally, a single audit-trail design problem. The pattern that survives a national-authority inspection has six elements.
End-to-end traceability. Every output produced by the system is traceable to the input, the model version, the system prompt, the retrieved context (for RAG-style systems), the reasoning intermediate state (where the model emits one), the human-oversight event if any, and the policy in force at the time. Reconstructable from the audit store in a single query against a trace ID. The trace ID is generated at the input and carried through every component (the same pattern described for IAM for AI agents).
Version-pinned policy. The Article 9 risk management state at the time of each output is queryable historically. If a risk control was added in March, the audit trail can show whether it was in force on 12 February.
Drift evidence. Article 72 post-market monitoring requires the provider to monitor for drift, accuracy degradation, and bias regression after deployment. The audit trail must support this monitoring — sufficient sample data, distribution metrics, and bias measurements over time.
Incident reporting capability. Article 73 requires reporting of serious incidents to the national authority within specified deadlines (15 days for serious incidents, 2 days for widespread infringement or critical infrastructure disruption). The audit trail must support rapid reconstruction of incident context within those deadlines.
Human-oversight events as first-class data. Every human review, approval, override, and stop must be recorded with the reviewer's identity, the information presented to them, the decision they made, and the timing. This is the evidence that Article 14 oversight was meaningful.
Provenance and integrity. The audit trail itself must be tamper-evident. Standard cryptographic hashing or write-once storage at the regulatory-evidence layer.
Most production AI systems have none of these six wired correctly. The ones built on the agent platforms with structural principal-of-record discipline have a head start on traceability. The ones that bolted observability on after launch are likely to find that the existing logs do not satisfy Article 12 without significant retrofitting.
Penalties and the inspection regime
Article 99 sets the penalty regime. Three tiers:
Up to €35 million or 7% of global annual turnover (whichever is higher) for violations of Article 5 prohibited practices.
Up to €15 million or 3% of global annual turnover for violations of provider, importer, distributor, deployer, notified body, or authorised representative obligations — including the Article 8-15 high-risk system requirements.
Up to €7.5 million or 1% for incorrect, incomplete, or misleading information supplied to authorities. This is the tier that will catch organisations that respond to a market-surveillance request with hastily-assembled documentation that does not match the actual system.
National competent authorities have market surveillance powers under the EU Market Surveillance Regulation 2019/1020, which include the right to demand access to systems, documentation, technical specifications, training datasets, source code where necessary, and personnel for interviews. The inspection regime is not theoretical — the GDPR enforcement regime that has produced multi-hundred-million-euro penalties against major technology providers is the operational template for what AI Act enforcement will look like.
What this teaches us about enterprise scaling
The AI Act is the most comprehensive AI regulation any major jurisdiction has produced. It is also the leading edge of what the next decade of AI compliance is going to look like — the United States, UK, and Asia-Pacific regulators are watching the EU enforcement closely and adopting variants of the same obligations.
The organisations that will scale AI across the EU without enforcement findings are the ones that internalised the four obligations above as engineering work, not as policy work. The audit trail is a technical artefact. The Article 14 oversight pattern is a UX-and-systems-design pattern. The Article 10 data governance is an MLOps pattern. The Article 9 risk management is an SRE pattern with a compliance overlay.
The organisations that produced compliance frameworks without operationalising them — the policy documents, the gap assessments, the readiness checklists that are not wired into the production pipeline — will produce the first wave of enforcement findings starting 2 August 2026. The work that survives inspection is not the work that produced the policy. It is the work that produced the audit trail, the oversight pattern, the data governance pipeline, and the post-market monitoring evidence.
The deadline is real. The penalty regime is operational. The inspection authority is staffed. The grace period ends in less than two months.
FAQs
What exactly becomes enforceable on 2 August 2026?
Articles 8 through 15 — the conformity requirements for high-risk AI systems (risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy/robustness/cybersecurity). Articles 16-28 obligations on providers, importers, distributors, and deployers. Articles 49-54 establishing the EU database for high-risk systems and the conformity assessment regime. And the Article 99 penalty regime in full operation.
How do I know if my AI system is "high-risk"?
Two routes. Article 6(1) — AI used as a safety component of a product covered by Annex I harmonisation legislation (toys, machinery, medical devices, lifts, radio equipment). Article 6(2) — AI falling within Annex III use cases (biometric categorisation, critical infrastructure, education admission, employment recruitment, credit scoring, insurance pricing, public benefits, law enforcement, migration, justice). Most regulated-enterprise AI touches at least one Annex III category. The Article 6(3) self-derogation is being over-used; a national authority can require reclassification with retrospective compliance and penalties.
Does Article 14 require a human in the loop on every decision?
No. Article 14 requires effective oversight by natural persons during the period the system is in use, with measures commensurate to the risks under Article 14(3). Whether oversight is achieved by per-output approval, sample review, real-time monitoring with override authority, or a layered combination is a design choice. What Article 14 does not allow is rubber-stamp approval without information, post-hoc audit weeks later, or delegation to the model's own guardrails.
What does the audit trail need to capture for Article 12?
End-to-end traceability from input through model version, system prompt, retrieved context, reasoning state, human-oversight events, and policy in force at the time — reconstructable from a single trace ID. Plus version-pinned policy state (queryable historically), drift evidence to support Article 72 post-market monitoring, incident-reporting capability inside the Article 73 deadlines (15 days serious, 2 days critical), human-oversight events as first-class data, and tamper-evident integrity at the regulatory-evidence layer.
What are the maximum penalties and who enforces them?
National competent authorities enforce, using market-surveillance powers under EU Market Surveillance Regulation 2019/1020 — they can demand access to systems, documentation, training data, source code where necessary, and personnel for interviews. Three penalty tiers under Article 99: up to €35M or 7% global turnover for Article 5 prohibited practices, up to €15M or 3% for high-risk obligation violations, up to €7.5M or 1% for misleading authorities. The GDPR enforcement regime is the operational template.
Companion content
- SOC 2 for AI Deployments
- DSPM Meets RAG
- IAM for AI Agents
- AI Workload Posture Management
- AI Red-Teaming as a Discipline
- NDPA + GAID Compliance Guide
How to engage
If your AI deployment is in scope for the 2 August 2026 enforcement deadline and your compliance programme is closer to policy than to engineering, we can help operationalise the four obligations into the systems that will be inspected. Talk to us at creativeminds.dev/contact.