Does the August 2, 2026 deadline apply to existing AI systems already in production?

Yes. The Article 12 record-keeping and Article 19 log content requirements apply to high-risk systems in production on or after August 2, 2026. Systems that went live before August 2 are not grandfathered out of the obligation. The Commission's transitional provisions in Article 111 specify the cases where existing systems get additional time, and most high-risk operational AI does not benefit from that timing.

How does the August 2 deadline interact with the GPAI obligations?

The General-Purpose AI obligations under Article 53 bound earlier (August 2, 2025) for providers of GPAI models. The high-risk system obligations under Title III bind on August 2, 2026 for deployers and providers of high-risk systems. A program that uses a GPAI model inside a high-risk system has to comply with both obligation sets on the respective dates.

What happens after August 2 if the conformity assessment is not complete?

The high-risk system cannot be placed on the market or put into service in the EU without the conformity assessment evidence and the EU declaration of conformity. The competent authority can require the operator to suspend the system, recall it, or take corrective measures. Article 99 penalties apply for serious non-compliance, including operating a high-risk system without the assessment.

Can a single per-decision record series cover all high-risk systems in the program?

Yes, when the record series is structured to carry the system identifier on every record. The Article 12 obligation is per-system, but the record series can be operationally a single store with the per-system field on each record. Programs with multiple high-risk systems typically operate one canonical series across the whole AI program and filter by system identifier during audit sampling.

EU AI Act August 2, 2026 Deadline: The Operational Cutover for High-Risk AI Systems

Q: What counts as a "high-risk AI system" under Annex III?

The eight categories in Annex III cover biometric identification, critical infrastructure, education and vocational training, employment and worker management, access to essential services (including credit scoring), law enforcement, migration and border control, and administration of justice. The category lists specific use cases inside each. An AI system that performs credit scoring for natural persons falls inside category 5(b). An AI system that screens job applications falls inside category 4(a).

The European Commission's digital strategy fixes August 2, 2026 as the effective date for the high-risk system obligations in the EU AI Act. The date is 55 days from today. For organizations running AI inside the Annex III high-risk categories (credit scoring, employment screening, education access, biometric identification, critical infrastructure, law enforcement, justice administration, migration), the deadline is the operational cutover for logging, identity binding, conformity assessment evidence, and the per-decision record series the auditor will sample.

I want to walk through what the August 2 deadline binds, what the operational stack has to produce on day one, and where most programs I talk to are landing as they approach the date.

What the deadline binds

The August 2, 2026 date is the moment the high-risk system obligations in Title III bind. The obligations include risk management system (Article 9), data governance (Article 10), technical documentation (Article 11), record-keeping (Article 12), transparency (Article 13), human oversight (Article 14), accuracy, resilience, and cybersecurity (Article 15), quality management system (Article 17), automatically generated logs (Article 19), and conformity assessment (Articles 43 through 49).

The penalty tier for non-compliance reaches €15 million or 3% of global annual turnover under Article 99, whichever is higher. The enforcement is national: each Member State designates competent authorities and the European AI Office coordinates cross-border cases.

The high-risk categories live in Annex III. The list covers biometric identification systems, critical infrastructure AI, education and vocational training, employment and worker management, access to essential private and public services (including credit scoring), law enforcement, migration and border control, and administration of justice.

What "operational cutover" means on August 2

On August 2, 2026, the program has to demonstrate that the obligations are bound to the production AI systems. That demonstration is evidence, not a self-attestation. The competent authority can request:

The piece that most often surprises programs is Article 12 plus Article 19: the records have to exist from day one. The auditor's sample reaches back across the operational history. A program that turns on the record series on August 2 carries one day of evidence on August 2. A program that turned on the record series in May carries three months. The earlier the cutover, the larger the evidence base.

Article 12 record requirements at the request path

Article 12 requires automatic recording of events over the lifetime of the system sufficient to ensure traceability. Article 19 specifies what the record carries:

For AI systems whose interaction surface is an LLM API, the input data field maps to the prompt content, and the identification of natural persons field maps to the user behind the application session. The record series has to carry both fields together, which means the inspection layer that captures the prompt has to see the verified identity at the same moment.

The placement that supports this is the HTTP request boundary between authenticated users or agents and the LLM endpoint. The proxy terminates TLS, authenticates against the corporate IdP, captures the prompt content, and commits the record with both fields on the same series.

Conformity assessment evidence

Articles 43 through 49 describe the conformity assessment process. For most high-risk systems, the provider runs an internal control conformity assessment against the harmonized standards (Article 40) and produces an EU declaration of conformity (Article 47). The declaration references the technical documentation and the record-keeping evidence.

The record-keeping evidence is the Article 12 + Article 19 series. A declaration of conformity that points at a record series that has been running for three months presents a stronger evidence base than one that points at a series that started on the same day as the declaration. The August 2 deadline is the latest reasonable date for the cutover; the smart programs target a cutover in May or June to give the record series time to accumulate.

What programs are doing this month

Most programs I talk to who are inside Annex III are landing on three workstreams between now and August 2:

The first workstream is the AI inventory: what AI systems are in production, which ones fall inside Annex III, and which of those need the high-risk obligation set bound to them. The inventory work was supposed to happen in Q4 2025 for most programs. The ones running behind are doing it now.

The second workstream is the record-keeping cutover: turning on the per-decision audit record series at the AI request path, with identity binding, classification, policy version, and decision on every record. This is where most of the engineering work concentrates because the record has to be defensible under audit, not just present.

The third workstream is the conformity assessment evidence package: the technical documentation, the data governance documentation, the risk management system documentation, and the references into the record series. Most programs are running this on a five-week timeline against the deadline, with internal sign-off targeted at mid-July.

Common failure modes I see

The first failure mode is records without identity. The program turned on a log series at the application level but the records do not carry the natural-person identity because the application calls the LLM with a service credential. The Article 19 field is missing on every record. The fix is identity binding at the request boundary.

The second failure mode is records without integrity. The records exist in an unprotected log store the application can write and delete. The auditor's question (can you prove these records have not been tampered with) does not have an answer. The fix is the tamper-evident series with chained signatures.

The third failure mode is multi-provider drift. The program operates against OpenAI, Anthropic, and Bedrock with different log surfaces and different schemas. The auditor receives three different evidence shapes. The fix is the proxy placement that produces a single canonical series across providers.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits inline between authenticated users or agents and any LLM, terminates TLS at the proxy, authenticates against the corporate IdP, classifies the prompt content, evaluates policy against identity and classification, and commits a per-decision audit record before the response returns. The records carry the fields Article 12 and Article 19 expect on a tamper-evident series the conformity assessment evidence package references.

For organizations facing the August 2, 2026 cutover, the record series is the field that has to exist and the field that has to carry weight under audit. The placement at the request boundary is what produces it.

If you are facing the August deadline, let's talk.