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

By Micky Irons

On 2 August 2026, a switch flips inside the European Commission. From that date its supervision and enforcement powers over providers of general-purpose AI models become active, and the Commission can start imposing fines of up to 15 million euros or 3 percent of a provider's total worldwide annual turnover, whichever is higher. The obligations themselves have been live since 2 August 2025. What changes this August is that the Commission can finally act on them.

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 on 2 August 2026 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 enforcement date does not create your exposure. It illuminates it.

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 2 August 2026 date turns the abstract question of AI supply-chain risk into a dated, fineable, board-level one. 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 August 2026 is not the day the model-makers get regulated. It is the day their 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, and let 2 August come.

Frequently asked questions

What exactly happens on 2 August 2026?

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.