← Blog

EU AI Act August 2, 2026 Readiness Checklist: The 32-Day Operational Sweep

On August 2, 2026, the EU AI Act high-risk system obligations take effect. Providers and deployers operating in the EU have 32 days from today to close the gap between the regulation as written and the operational evidence the supervisory authorities will ask for. This checklist walks the eight artifacts a high-risk deployer needs in production before August 2: the inventory, the classification, the Article 11 documentation, the Article 12 logging architecture, the Article 14 human oversight record, the Article 19 retention plan, the Article 26 deployer obligations, and the Article 73 incident reporting workflow.

ByParminder Singh· Founder & CEO, DeepInspect Inc.
Compliance & Regulationeu-ai-actcompliancehigh-risk-airegulationauditai-governance
EU AI Act August 2, 2026 Readiness Checklist: The 32-Day Operational Sweep

The EU AI Act high-risk system obligations take effect on August 2, 2026. Today is June 30, 2026, which leaves 32 days. The gap most enterprises face is operational rather than legal. The regulation has been on the books since August 2024; what is missing in late June 2026 is the architecture that produces the evidence the supervisory authorities will ask for. The penalties under Article 99 reach EUR 15 million or 3 percent of global annual turnover for high-risk non-compliance.

I want to walk through the eight readiness artifacts a high-risk deployer needs in production before August 2, in operational sequence, with the regulatory anchor for each and the architectural decision that satisfies it.

Artifact 1: The AI system inventory

The inventory is the prerequisite to every other obligation. The supervisory authority will ask which AI systems the organization operates, which are high-risk under Annex III, and which are general-purpose AI in scope. An inventory that misses systems is the audit finding that opens every other obligation to challenge.

The minimum fields per system are the system name, the model or models behind it, the provider, the purpose, the Annex III category if applicable, the deployer role under the regulation, the data classes the system processes, and the integration endpoints. The inventory needs to be live rather than static. Shadow AI sits outside any inventory built by a Confluence page. The discovery layer has to run at the network or gateway boundary where the AI traffic actually flows.

Artifact 2: The high-risk classification record

Annex III lists the eight categories that make an AI system high-risk: biometric identification, critical infrastructure management, education and vocational training, employment and worker management, access to essential services, law enforcement, migration and border control, and administration of justice and democratic processes. The Commission's May 19, 2026 high-risk classification guidelines added concrete signals on what triggers the obligations.

The classification record per system documents the assessment. Three fields are operationally important. The Annex III category and sub-category. The factual basis for the classification (what the system does, what data it consumes, what decisions it affects). The Article 6(3) determination if the deployer concludes the system does not pose a significant risk despite falling within an Annex III area, with the rationale and the documentation that supports it.

Artifact 3: Article 11 technical documentation

Article 11 requires the provider to draw up technical documentation before placing the system on the market. The documentation must be sufficient to demonstrate that the system complies with the requirements of Chapter III, Section 2 of the regulation. Annex IV lists the content: general description, design specifications, data and data governance, monitoring, validation and testing, risk management, accuracy and resilience metrics, cybersecurity measures, and the post-market monitoring plan.

The documentation has to be kept up to date for ten years after the system is placed on the market under Article 18. For deployers that have inherited provider status under Article 25, the Article 11 documentation obligation transfers. The practical implication is that an enterprise that fine-tuned a foundation model and put it into service under its own name is on the hook for Annex IV documentation as if it were the original model provider.

Artifact 4: Article 12 logging architecture

Article 12 requires that high-risk AI systems automatically record events over the lifetime of the system. The logs must enable identification of risk-creating situations, facilitate post-market monitoring, and enable monitoring of the system's operation. Article 19 specifies what goes in the log and sets the retention floor at six months.

The architectural decision is where the logs live. Application-controlled logs fail under three conditions: selective omission, post-incident suppression, and loss on crash. The supervisory authority's question is whether the log can be relied on as evidence. A log written by the application that is the subject of the audit is the application's word against itself. The log has to live at a layer the application cannot rewrite. The natural location is the gateway between the authenticated caller and the model.

Artifact 5: Article 14 human oversight record

Article 14 requires that high-risk AI systems be designed to be effectively overseen by natural persons during their use. The deployer has to assign oversight responsibility to a competent natural person and document the oversight arrangement. The record per system identifies the named oversight role, the training the role has received, the intervention capability (the technical means by which the overseer can interrupt or override the system), and the escalation path.

The intervention capability is the operationally important field. The supervisory authority's question reduces to whether the overseer can actually stop a system that is going wrong. A system that runs autonomously with no kill switch fails Article 14 regardless of the policy document on file.

Artifact 6: Article 19 retention plan

Article 19 requires deployers to retain the automatically generated logs from Article 12 for at least six months, subject to longer retention requirements in other Union or national law. The retention plan documents the retention period per system, the storage location, the access controls, the integrity controls, the deletion schedule for records that fall out of the retention window, and the legal hold procedure for records subject to active proceedings.

Sector-specific overlays extend the floor. Financial-services records under DORA and the existing prudential framework typically require longer retention. Health-sector records under national implementations of the Patient Rights Directive run longer in most member states. The retention configuration at the system level has to default to the longest applicable obligation.

Artifact 7: Article 26 deployer obligations

Article 26 lists the obligations of deployers of high-risk AI systems. The deployer must use the system in accordance with the instructions for use, assign human oversight to natural persons with the necessary competence and authority, ensure that input data is relevant and sufficiently representative, monitor the operation of the system, and inform the provider and the market surveillance authority of any serious incident.

For deployers that process personal data through a high-risk AI system, Article 27 requires a fundamental rights impact assessment before the first use. The FRIA documents the intended purpose, the categories of natural persons likely to be affected, the specific risks of harm to those persons, the human oversight measures, and the measures to be taken in case the risks materialize.

Artifact 8: Article 73 incident reporting workflow

Article 73 requires providers of high-risk AI systems to report serious incidents to the market surveillance authority within 15 days of establishing the causal link, with a 72-hour window for widespread infringements and a 2-day window for incidents resulting in death. The deployer has a parallel obligation under Article 26(5) to inform the provider and the authority of any serious incident.

The workflow has three roles. Detection sits with whoever first observes the anomaly, usually the deployer. Triage applies the Article 3(49) serious-incident criteria. Reporting goes to the market surveillance authority of the member state where the incident occurred, with the operational evidence drawn from the Article 12 logs.

DeepInspect

DeepInspect is a stateless policy gateway that sits between authenticated users or agents and any LLM. Every AI request and response passes through the gateway. Identity is verified at the request boundary. Policy evaluates the request against the rules defined for the deployer, the data class, and the destination model. Every decision produces a signed, tamper-evident audit record with the identity, the policy version, the model version, the data classes detected, and the timestamps.

For an EU AI Act readiness program, DeepInspect closes four of the eight artifacts directly. The inventory comes from the gateway's view of every AI call. The Article 12 logging architecture is the gateway. The Article 19 retention is configured at the gateway with the appropriate retention period per system. The Article 73 incident-reporting evidence is the gateway record. The other four artifacts (classification, Article 11 documentation, human oversight, FRIA) sit at the deployer's governance layer, but the gateway record is the evidence that supports each.

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

Frequently asked questions

What is the August 2, 2026 deadline?

August 2, 2026 is the date the EU AI Act's high-risk system obligations take effect. The regulation entered into force on August 1, 2024, with a staggered application schedule. Prohibited practices applied from February 2, 2025. General-purpose AI obligations applied from August 2, 2025. The high-risk obligations under Chapter III apply from August 2, 2026, which covers Annex III systems and the relevant Annex I product safety legislation systems.

What happens if a high-risk system is not compliant by August 2?

Under Article 99, the penalty tier for high-risk non-compliance is EUR 15 million or 3 percent of global annual turnover, whichever is higher. The supervisory authority of the member state where the non-compliance occurs has the enforcement power. In practice, the enforcement pattern in the first months of application is expected to focus on systems that present clear consumer harm and on providers that have not made a credible compliance effort.

Who counts as a deployer under the regulation?

A deployer is a natural or legal person using an AI system under its own authority, except where the system is used in the course of a personal non-professional activity. The deployer is the enterprise that puts the AI to work in its operations. The deployer is distinct from the provider, which is the entity that develops the system or has it developed and puts it on the market. An enterprise can become a provider under Article 25 if it puts a high-risk system on the market or into service under its own name, makes a substantial modification to a high-risk system, or changes the intended purpose in a way that makes a non-high-risk system high-risk.

What is the difference between a serious incident and a malfunction?

Article 3(49) defines a serious incident as an incident or malfunctioning of an AI system that, directly or indirectly, leads to death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of fundamental-rights obligations under Union law, or serious harm to property or the environment. A malfunction that does not lead to one of those outcomes is not a serious incident under Article 73, although it may still need to be addressed under the deployer's internal incident management.

What evidence does the supervisory authority actually ask for?

The supervisory authority asks for evidence that ties the obligation to the operational record. For the Article 12 logging obligation, the authority asks for log samples that demonstrate the required fields are recorded automatically. For Article 14 human oversight, the authority asks for the oversight role document and evidence of intervention. For Article 26 deployer obligations, the authority asks for the use record, the monitoring record, and any incident reports. The evidence has to be operationally produced, not retrospectively assembled.

Can a stateless proxy satisfy Article 12 logging?

A stateless proxy that records every request, every response, the identity behind the request, the policy evaluated, and the model called produces the records Article 12 requires. The proxy's record is independent of the application, which addresses the self-attestation failure mode of application-controlled logs. The retention configuration at the proxy satisfies the Article 19 floor. The records form the evidence chain that supports Article 73 incident reporting.