EU AI Act Enforcement Starts August 2: Your GPAI and High-Risk AI Readiness Checklist

The Clock Is Running

EU AI Act enforcement is no longer a compliance planning topic. On August 2, 2026, the EU AI Office acquires formal fining authority over general-purpose AI model providers, and national market surveillance authorities sharpen their teeth on high-risk AI systems. Fines for non-compliance with GPAI obligations can reach 3% of total worldwide annual turnover, or EUR 15 million, whichever is higher. For systemic risk models, that ceiling climbs to 3% of global turnover with additional supervisory powers attached.

If your organisation is still treating EU AI Act readiness as a legal drafting exercise, this is the moment to recalibrate. Regulators assess evidence. Evidence comes from testing, evaluation, and documented controls — not from policy PDFs.

Who This Affects Most

Regulated enterprises in BFSI, healthcare, and insurance face disproportionate exposure for two reasons. First, their AI use cases — credit scoring, insurance underwriting, clinical decision support, fraud detection — sit squarely within Annex III of the Act, which enumerates high-risk AI system categories. Second, many of these organisations also procure or integrate GPAI models from foundation model providers, making them downstream deployers with obligations of their own.

This dual exposure — deployer obligations for high-risk AI, and due diligence obligations when integrating GPAI models — is where most enterprises have gaps.

GPAI Readiness Checklist

For organisations that develop, fine-tune, or integrate general-purpose AI models into their products or internal systems, the following areas require documented evidence before August 2.

Technical documentation: Maintain detailed records of model architecture, training data sources, data governance practices, and intended use scope. The AI Office can request this documentation during an inquiry. Assembling it retrospectively is both slow and legally precarious.

Copyright compliance policy: GPAI providers must have a policy in place addressing compliance with EU copyright law, particularly regarding training data. This is not optional for models made commercially available in the EU market.

Capabilities and limitations disclosure: Published summaries of what the model can and cannot do, including known limitations, failure modes, and performance characteristics across relevant domains, must be maintained and kept current.

Adversarial testing records for systemic risk models: If your GPAI model qualifies as posing systemic risk — broadly, models trained with compute above a defined threshold — you are required to conduct adversarial testing and maintain evaluation results. Red-teaming logs, benchmark results, and mitigation records are the evidence base here.

Incident reporting readiness: A defined process for identifying, recording, and reporting serious incidents or misuse to the AI Office must exist and be operational, not hypothetical.

High-Risk AI System Readiness Checklist

For AI systems classified as high-risk under Annex III, conformity obligations apply to both providers and deployers, with meaningful obligations falling on both sides.

Conformity assessment: High-risk AI systems must undergo conformity assessment before being placed on the market or put into service. This assessment must be documented and, depending on the system type, may require a notified body. The assessment is not a one-time event — it must be reviewed when the system is substantially modified.

Risk management system documentation: A continuous risk management process, covering identification of risks, estimation and evaluation of those risks, and implementation of risk mitigation measures, must be documented throughout the system lifecycle. Testing at each stage is the mechanism that generates this evidence.

Data governance records: Training, validation, and test data must meet quality criteria. Your data governance process must be documented and demonstrable. For organisations using synthetic test data as part of evaluation pipelines, that process itself should be documented to show it is fit for purpose.

Accuracy, robustness, and cybersecurity benchmarks: The Act requires high-risk AI systems to achieve appropriate levels of accuracy and be resilient against errors, faults, and inconsistencies. Published internal benchmarks, regression testing logs, and adversarial evaluation results constitute the evidence a regulator will look for.

Human oversight mechanisms: Technical and procedural controls ensuring that humans can effectively oversee AI system outputs must be in place and testable. The word testable matters — you should be able to demonstrate that override and intervention mechanisms function as designed.

Logging and audit trail: Automatic logging of operations must be enabled for high-risk AI systems, sufficient to reconstruct events leading to any incident. Your monitoring and observability infrastructure needs to be active, not configured post-deployment.

Post-market monitoring: A plan for continuously monitoring system performance once deployed — covering data drift, output quality degradation, and emerging risk — must be documented and operational.

The Evidence Problem Most Teams Overlook

The most common readiness gap is not missing policies. It is the absence of testing and evaluation evidence that substantiates those policies. An AI governance framework that says a system is regularly evaluated for bias does not satisfy an auditor who asks to see the evaluation results, the methodology, the datasets used, and the actions taken in response to findings.

This distinction — between documented intent and documented evidence — is where enforcement creates real exposure. The AI Act and its accompanying standards are explicit that conformity must be demonstrable. That requires an evaluation infrastructure capable of generating, storing, and retrieving structured evidence across the AI system lifecycle.

Why Continuous Assurance Matters After August 2

Passing an initial conformity assessment is not the finish line. The Act creates ongoing obligations that require continuous monitoring, periodic re-evaluation when systems change, and active incident response processes. Organisations that treat EU AI Act enforcement compliance as a point-in-time project rather than a sustained practice will find themselves exposed when their models drift, their data distributions shift, or a downstream incident triggers regulatory scrutiny.

Building evaluation and testing into the operating model of AI systems — not as a pre-launch gate but as continuous quality assurance — is what transforms a compliance posture from fragile to defensible. That is the practical case for AI assurance: not as a regulatory necessity alone, but as the operational foundation that keeps high-stakes AI systems performing as intended under real-world conditions.