The EU AI Act Moved and Did Not: Why GPAI Enforcement in August Has Teeth and the High-Risk Delay Does Not Help You

A behavioral-health network running an intake summarizer on a frontier model, a property-management firm using a chatbot trained on tenant correspondence, a PE portfolio SaaS company embedding a foundation model into its product, none of these organizations build the model. They deploy someone else's. And on May 7, 2026, the EU made a regulatory move that most of them have already misfiled as "we have until 2027." That is the trap. The Digital Omnibus did defer the heavy Annex III high-risk obligations to December 2027. But the obligations attached to general-purpose AI models, the foundation models nearly every regulated mid-market buyer now deploys through a vendor, were not deferred. The European Commission's GPAI enforcement powers activate on August 2, 2026, with the AI Office empowered to levy fines up to 3% of global annual turnover. The headline said delay. The calendar says six weeks. What actually changed on May 7 Two things happened at once, and conflating them is the expensive mistake. The first: the Digital Omnibus package pushed the high-risk system rules, the conformity assessments, the registration in the EU database, the fundamental-rights impact assessments that apply to AI used in employment, credit, essential services, and the rest of Annex III, out to December 2027. That is real relief for organizations building or deploying systems that fall into those categories. If you are scoring tenant applications or screening job candidates with a purpose-built model, the date you were dreading moved. The second, which did not move: the obligations on general-purpose AI models and the enforcement machinery behind them. The August 2, 2026 activation of the AI Office's supervisory and penalty powers stands. GPAI providers, the labs shipping the foundation models, carry transparency, documentation, and copyright-compliance duties. And those duties cascade. A downstream deployer cannot meet its own obligations, or defend its risk posture, without the documentation the provider is now required to produce. So the net effect for a mid-market deployer is the opposite of relief on the part that affects you most. The model layer you actually consume got an enforcement date. The system layer you might have built got a reprieve. If your AI footprint is "we call OpenAI, Anthropic, and Google through a vendor," the August date is your date. Why the old vendor-risk model misses this The instinct in a regulated shop is to treat AI like any other SaaS line item: get the SOC 2, get the DPA, file the security questionnaire, move on. That model breaks here for a structural reason. The AI Act draws a line between the provider of a GPAI model and the deployer of it, and it assigns documentation duties to the provider that the deployer must be able to obtain and rely on. Your standard vendor questionnaire does not ask for any of it. It does not ask whether the model your vendor wraps is itself a GPAI model with systemic-risk classification. It does not ask for the provider's technical documentation, the training-data summary, or the copyright-compliance policy. It does not ask which model version is actually in production, and in 2026 that question is sharper than ever, because providers float aliases. GPT-5.5 Instant became the ChatGPT default on May 5, and was exposed as a floating "chat-latest" pointer; the model under your contract can change without a version bump. When an auditor asks "which GPAI model processed this EU data subject's information in March," "the latest one" is not an answer. The control gap is not technical. It is documentary. You are being asked to hold paper you have never collected from a party two layers up your supply chain. What the audit will ask When the AI Office, a data-protection authority, or your own board's risk committee tests your readiness after August 2, the questions are concrete and they are about evidence, not intent: Which GPAI models do we deploy, directly or through vendors, and is any of them classified as carrying systemic risk? Do we hold the provider's technical documentation and instructions for use for each one? Do we have the provider's summary of training content and its copyright-compliance policy on file? Can we identify the exact model version that processed EU-resident data on a given date, and can we evidence that the version is pinned, not floating? Do we have a designated EU representative or accountable owner for AI Act obligations, and is the deployer-versus-provider boundary documented for each system? When a vendor swaps the underlying model, what is our notification and re-assessment trigger? None of these can be answered the week after a request lands. They are answered by paper collected in advance. The documentation a deployer must gather before August The artifact that closes the gap is unglamorous: a GPAI provider documentation register, one row per model in production, columns that map to what the regulation expects a deployer to be able to produce. At minimum: Model and version: the exact stable identifier in production (for example, a pinned rather than a floating alias), and whether the contract permits silent version changes. Provider and legal role: who is the GPAI provider of record, and are you the deployer, or have you modified the model enough to inherit provider obligations yourself. Systemic-risk classification: whether the provider has designated the model as carrying systemic risk, which raises the documentation bar. Provider technical documentation: held on file, dated, with the instructions for use a deployer relies on. Training-content summary and copyright policy: the provider's published summary and its copyright-compliance statement. Data path and EU nexus: whether EU-resident data reaches the model, through which region and subprocessor, and whether a self-hosted path exists for data that cannot leave the perimeter. The open-weight releases this spring, Gemma 4 on May 1 among them, make an in-perimeter alternative real for the most sensitive workloads, and that decision belongs in the register, not in an architecture diagram no auditor will read. Change trigger: the contractual and operational signal that fires when the provider alters the model, and who re-assesses. This register is the same control discipline we apply with regulated mid-market clients, and it slots directly into the model-and-vendor layers of the five-layer stack we wrote up in The Five-Layer AI Compliance Stack for Regulated Mid-Market. The point of the register is not the document. It is that the answer to "show me" already exists before the question is asked. What we recommend Four moves, all completable before August 2. First, inventory every GPAI model you deploy, including the ones buried inside SaaS vendors. The volatility this spring should make the urgency obvious: two major US-lab flagship models launched on June 9 and were pulled offline on June 12 under an export-control directive. If your production path depends on a model that can vanish in days, you need to know that today, not in an incident review. Second, send provider-documentation requests to every vendor with a GPAI model in your stack, asking specifically for technical documentation, the training-content summary, and the copyright-compliance policy. Treat silence as a finding. Third, pin your model versions in contract and configuration, and write a change trigger that forces re-assessment when a provider swaps the underlying model. Floating aliases are a compliance liability, not a convenience. Fourth, name an accountable owner for AI Act obligations and document the provider-versus-deployer boundary for each system, so the December 2027 high-risk work has a foundation rather than a scramble. The delay was real. It was also not yours. Collect the paper before August.