The GPAI Enforcement Switch Flips On 2 August 2026: What Regulated Buyers Should Actually Do

By Micky Irons

On 2 August 2026, a switch was once meant to flip inside the European Commission. On that date its supervision and enforcement powers over providers of general-purpose AI models were due to become fully active, with the Commission able to start imposing fines of up to 15 million euros or 3 percent of a provider's total worldwide annual turnover, whichever is higher. The Digital Omnibus on AI, agreed provisionally on 7 May 2026, endorsed by the European Parliament on 16 June 2026 and given the final green light by the Council on 29 June 2026, has now deferred the stand-alone Annex III high-risk obligations to 2 December 2027. We read that move as a build window and not a reprieve: the proof requirements survive the deferral untouched, so the sensible response is to build now.

Most of the coverage frames this as a model-maker problem. The big foundation-model shops now have teeth pointed at them: technical documentation, training-data summaries, copyright compliance, information sharing with downstream users. That framing is correct, and it is also the least interesting thing about the date if you run a bank, an insurer or a hospital.

Because you are the downstream user. And the enforcement switch does not stop at the model provider's door.

Why this is your problem, not just theirs

Here is the mechanic that gets lost in the headlines. Under the EU AI Act, using a compliant GPAI model does not discharge your own obligations. The moment you integrate a general-purpose model into a system you deploy, you inherit system-level duties: intended purpose, input-data controls, the documentation chain around the AI system you built. If your upstream provider has not handed you a clean information package, you cannot fulfil your side. You have a problem that is structurally yours, not theirs.

Layer the sector rules on top and the picture sharpens. If you are a financial entity, the Digital Operational Resilience Act has been in force since 17 January 2025. DORA makes you keep a Register of Information mapping every ICT third-party arrangement, classify which ones support critical or important functions, and manage the concentration risk of leaning on a handful of hyperscalers. On 18 November 2025 the European Supervisory Authorities designated the first Critical ICT Third-Party Providers under direct EU oversight. AWS, Microsoft, Google Cloud and IBM are among them. Your model very likely runs on one of them.

So you are holding two things at once. A model provider newly exposed to Commission fines, and a supply chain that regulators already expect you to have mapped, classified and controlled. The high-risk Annex III obligations were once due on 2 August 2026, and after the Digital Omnibus deferral they now apply from 2 December 2027. The proof requirements do not change with the date. It moves. They do not. So the deferral does not create your exposure, and it does not erase it either. It illuminates it, and it hands you a window to build now.

The honest version of the constraint

I will not tell you the law bars you from the cloud. It does not. The EU AI Act, DORA, the FCA and PRA regimes, the EBA guidelines, GDPR: nearly all of them permit cloud with the right controls in place. The genuine no-cloud bar is workload-specific. Classified or SECRET-tier material, ITAR-controlled data, isolated OT and SCADA environments, cases where a data protection impact assessment comes back negative. For most of what a regulated buyer does, cloud is legally available.

What is not available for free is provenance. When your model sits on someone else's infrastructure, behind someone else's abstraction, your evidence chain is a stack of vendor attestations. You are trusting that the documentation is accurate, that the model you were promised is the model you are served, that the audit trail your regulator asks for actually exists in a form you can produce. That is a preference problem, not a prohibition problem. But it is a preference that gets very sharp the day enforcement becomes real and your examiner starts asking who verified what, and when.

What changes when the model lives inside your walls

This is the reason I built Mickai the way I did. Mickai is a Sovereign Intelligence Operating System. Regulated organisations own it and run it inside their own perimeter, air-gapped if the workload demands it, with a cryptographically-signed audit record written on every action the system takes. It is built and it is live, running today inside the walls of the people who deploy it.

The difference is not a slogan about sovereignty. It is where the evidence comes from.

When the model runs on your own hardware, inside your own controls, the provenance is not a vendor promise you file and hope holds up. It is a signed record you generated and can produce on demand. Every inference, every retrieval, every action carries its own tamper-evident signature. When your regulator asks what the system did on a given date, with what inputs, under whose authority, you do not open a support ticket with a hyperscaler. You query your own log. You inherit provenance instead of promises.

That is the whole argument. The high-risk obligations, once due on 2 August 2026, now apply from 2 December 2027 after the Digital Omnibus deferral, and that shift turns the abstract question of AI supply-chain risk into a dated, fineable, board-level one. The proof requirements are unchanged, so the sensible response is to build now. The buyers who come out ahead are the ones who stop consuming trust and start owning evidence.

What to actually do before August

You do not need to rip anything out this quarter. You need to know your exposure and close the evidence gap.

- Map your GPAI dependencies. For every system that touches a general-purpose model, know the provider, the model, the version and where it runs. If you are under DORA, this belongs in your Register of Information already. - Demand the information package. Ask each upstream provider for the downstream documentation the Act entitles you to: capabilities, limitations, known biases, acceptable use, integration constraints. If they cannot provide it, that is your finding, not a footnote. - Test your audit story. Pick one AI-driven decision and try to reconstruct it end to end from your own records. If you cannot, no vendor attestation will save you when an examiner asks. - Decide which workloads need sovereignty, not preference. Be honest about which of your use cases are genuinely no-cloud and which are simply better served by provenance you control. Both are valid reasons to bring the model in-house. Only one is a legal bar.

For a deeper treatment of the upstream exposure, see my writing on GPAI supply-chain risk for regulated buyers. For how the evidence layer works in practice, see signed audit records on every action. And if you are weighing the wider case for owning your stack, see why regulated firms run a Sovereign Intelligence Operating System inside their own walls.

The takeaway

2 December 2027 is not the day the model-makers get regulated. The high-risk Annex III obligations were once due on 2 August 2026, but the Digital Omnibus deferred them, and they now apply from 2 December 2027. The proof requirements survived the move untouched, so the extra time is a build window and not a reprieve. 2 December 2027 is the day the model-makers' exposure becomes your exposure, on a calendar your board can read. You cannot fine your way out of a supply chain you do not control, and you cannot audit your way out of records you never held. The move is to bring the model close enough that its provenance is yours. Own the system, own the evidence, build now, and let 2 December come.

Frequently asked questions

What exactly happens on 2 December 2027? That obligation was once due on 2 August 2026, but the Digital Omnibus, agreed in May 2026 and given its final green light by the Council on 29 June 2026, deferred the stand-alone Annex III high-risk obligations to 2 December 2027. The date moved, and the substance did not. Every proof requirement we would have owed in 2026 still lands in 2027: the same conformity assessments, the same technical documentation, the same evidence that our systems behave as claimed across the Annex III domains. So we treat this as a build window, not a reprieve. The controls that make us defensible under the AI Act are the same controls we already need for DORA, NIS2, ISO/IEC 42001 and the UK Sovereign AI programme, and none of those wait for December 2027. The sensible response to a later deadline is not to slow down. It is to build now, while we have the room to do it properly.

The European Commission's supervision and enforcement powers over providers of general-purpose AI models become active. From that date the Commission can request documentation, order model evaluations and risk mitigations, and impose fines of up to 15 million euros or 3 percent of global annual turnover, whichever is higher. The underlying obligations have applied since 2 August 2025; this date makes them enforceable.

I only use models, I do not build them. Am I affected?

Yes. When you integrate a general-purpose model into a system you deploy, you take on your own obligations under the EU AI Act at the system level. Using a compliant model does not discharge them. You need the upstream documentation to meet your own intended-purpose and input-data duties, and for high-risk uses that documentation becomes part of your evidence chain.

Does this mean regulated firms are barred from cloud AI?

No. The EU AI Act, DORA and the FCA, PRA, EBA and GDPR regimes all permit cloud with appropriate controls. A genuine no-cloud bar exists only at the workload level, for cases like classified data, ITAR, isolated OT and SCADA, or a negative data protection impact assessment. For most workloads the driver is a preference for provenance you control, not a legal prohibition.

How does running the model in-house change my audit position?

When the model runs inside your own perimeter with a signed record on every action, your provenance is evidence you generated rather than a vendor attestation you filed. You can reconstruct what the system did, with what inputs and under whose authority, from your own tamper-evident logs, without depending on a third party to produce it for you.