The EU AI Act’s High-Risk Rules Arrive in August: What Changes on Day One

Where we are in the timeline

The AI Act entered into force on August 1, 2024, with obligations phased in over three years. The prohibitions on unacceptable-risk practices took effect in February 2025. The general-purpose AI model obligations followed in August 2025. August 2, 2026 is the big one: the general applicability date, when the requirements for high-risk AI systems under Annex III — the Articles 9–15 obligations we walked through in our earlier technical reading — apply to providers and deployers. This is the tranche that moves the Act from the AI industry’s problem to every regulated enterprise’s problem.

Who is caught: Annex III classifies systems as high-risk by use case, and the list reads like a bank’s and insurer’s product catalog — creditworthiness evaluation of natural persons, risk assessment and pricing in life and health insurance, employment and worker management, access to essential private and public services, education, and more. If an LLM-assisted workflow influences one of those decisions for EU persons, the classification question is live regardless of where your company sits. And the penalty ceiling for non-compliance with high-risk obligations is substantial — up to the higher of tens of millions of euros or a percentage of global turnover, with the exact bands depending on the violation.

What must exist on August 2

Strip away the recitals and the day-one requirements come down to five artifacts that either exist or don’t.

A risk management system that runs continuously (Article 9). Not a risk assessment PDF from procurement season — an iterative process, maintained across the lifecycle, that identifies foreseeable risks, evaluates them against the intended purpose, and feeds mitigations back into the system. For LLM-based systems, this includes risks from the model’s known failure modes: hallucination, prompt sensitivity, distributional drift.

Technical documentation sufficient to assess compliance (Article 11, Annex IV). The documentation must let a competent authority understand how the system works and reaches its outputs — design specifications, development choices, validation results, and crucially the logic of the system. “We call a foundation model with this prompt” describes an integration, not a logic. Documentation of reasoning requires the reasoning to have documentable structure.

Automatic logging and record-keeping (Article 12). High-risk systems must automatically record events across their lifetime, sufficient to trace how outputs were produced and to support post-market monitoring. Note the standard: traceability of the functioning of the system — not merely which API calls were made, but the basis on which a consequential result was reached.

Human oversight that is architecturally real (Article 14). A person must be able to understand the system’s output, interpret it correctly, decide not to use it, and intervene or halt it. That set of verbs is an architecture requirement in disguise. A human cannot meaningfully overrule a conclusion whose basis is invisible; oversight of an opaque process is a signature, not a control.

Registration and conformity (Articles 43, 49). High-risk systems go through conformity assessment and into the EU database before being placed on the market or put into service. Deployers have their own obligations — using systems per instructions, monitoring, and in some cases fundamental-rights impact assessments.

The property that matters: none of this backfills

Most compliance regimes tolerate reconstruction. A missing policy can be written; a missing attestation can be signed. The AI Act’s high-risk core is different because the artifacts it demands are byproducts of how the system runs. You cannot retroactively generate the log of how a decision was reached if the system never recorded its reasoning. You cannot document the logic of a system whose logic was never externalized. You cannot demonstrate human oversight capability for a system whose outputs arrive as unstructured prose with no inspectable basis. Teams that treat August as a documentation sprint will produce documentation about the system. The Act, read carefully, keeps asking for artifacts from the system.

This is where the architecture argument stops being abstract. A system whose reasoning is an explicit, persistent graph — what was considered, what was checked, where uncertainty was flagged, how convergence happened — produces the record-keeping and traceability evidence as a side effect of operating. Its Article 11 documentation has something real to describe. Its Article 14 oversight has substance because a reviewer can see the basis of an output and reject a specific step rather than vetoing a black box on instinct. Whether any given system satisfies those articles is a conformity determination no vendor can make for you. We built IRG for exactly this shape of demand, but the point holds regardless of vendor: on our reading, the Act regulates the reasoning process — and a system with an inspectable reasoning process can produce its evidence by construction rather than by narrative.

If you have four weeks

Triage in this order. First, classification: inventory which of your AI-assisted workflows plausibly fall under Annex III — the honest answer is usually more than the official register says. Second, the logging gap: for each high-risk candidate, ask whether you could trace a specific consequential output back through its basis today. If not, that is the deepest hole, because every day it stays open is a day of undocumentable decisions. Third, oversight design: identify who the Article 14 human is for each workflow and what they can actually see. If the answer is “the output,” the oversight is decorative. Documentation and registration follow from those three; they do not substitute for them.