EU AI Act: fines up to 15 million euros for providers of GPAI models from 2 August 2026

From 2 August 2026, you must know which general-purpose AI models your organisation uses, what data they process, and whether your supplier faces investigation or enforcement action by the European Commission's AI Office. Supplier risk is now an explicit compliance layer.

The prompt is an analysis of 2 September 2026 of enforcement powers against general-purpose AI model providers under the EU AI Act, which argues that the Commission can fine GPAI providers up to 3% of global annual turnover or 15 million euros for breaches of their obligations, failure to provide documentation, non-compliance with imposed measures, or refusal of access for model evaluations. The enforcement date is concrete: 2 August 2026, when the AI Office's powers become applicable. In our assessment, this represents a shift in the enforcement architecture itself—large general-purpose models are now monitored directly by a central EU body with its own investigative and sanctioning powers, not primarily by national supervisors. That centralised enforcement creates a direct risk channel for any organisation that builds workflows on these models.

Which models does your organisation depend on?

Large language models such as ChatGPT, Claude and Gemini fall under the GPAI category and are subject to these obligations. If your organisation uses any of them, your supplier can become the subject of investigation, orders or fines. That risk carries through into your own continuity and accountability, even though the sanction lies with the provider. The first step is visibility: you must be able to name which model performs which task and which data goes to the supplier in the process. Without that overview, it is difficult to demonstrate how a provider's obligations translate into your own logging, privacy and oversight policy.

What triggers enforcement action?

The AI Office can impose fines for intentional or negligent breaches. The concrete situations that activate enforcement are:

• Breach of GPAI obligations — failure to meet the transparency, documentation or risk management requirements that apply to general-purpose models.
• Failure to provide documentation — refusal or inability to supply the technical documentation, model cards or other records the Commission requests.
• Non-compliance with imposed measures — ignoring an order to adjust, mitigate risk or withdraw a model.
• Refusal of access for evaluation — blocking the Commission's ability to test or audit the model.
• Negligent conduct — breaches that arise from failure to exercise reasonable care, not only intentional misconduct.

What controls do you need to demonstrate?

To establish that your organisation has translated upstream supplier obligations into your own accountability, you should be able to show:

1. Record the model and its purpose — document which model each workflow uses, the lawful basis for the data it processes, and the date the workflow was put into use.
2. Log data flows to the supplier — maintain records of what information leaves your infrastructure, when, and in what form, so you can trace exposure if the supplier is investigated.
3. Verify outputs before use — implement a step that checks model outputs for accuracy, hallucination or drift before they are used in decisions or stored as records.
4. Monitor supplier status — establish a process to track whether your supplier is under investigation, has received a compliance order, or has been fined, and have a contingency plan if the model becomes unavailable.
5. Document your verification method — record how you check outputs and what criteria you use to accept or reject them, so you can demonstrate independent professional judgement.

How does supplier risk change your own obligations?

The fines target the providers of the models, not directly the buyers. Yet there is a knock-on effect. If a core supplier comes under investigation, receives an order to adjust or withdraw a model, or is fined, this affects the continuity and accountability of the organisations that build on that model. In our assessment this is the practical point for teams working with confidential or regulated information: supplier risk becomes an explicit layer in their own risk picture. You cannot assume that because you use a model responsibly, your supplier's obligations are met. Centralised enforcement means you must treat supplier compliance as a separate, active risk that you monitor and plan for.

What tooling can help, and what remains your responsibility?

A verification layer can help concretely by routing tasks through selected models and exposing verification steps, corrections and disagreements for inspection. This supports control but does not remove the need to check for hallucinations; the professional final judgement remains with you. On the data side, privacy-focused architectures can replace sensitive values with synthetic equivalents before AI processing, analyse the synthesised version, and restore the original values locally. The workflow is fail-closed: if the privacy check fails, the document is not sent onward. These tools can carry the mechanics of logging, routing and verification. What they cannot carry is your own assessment of whether a model is fit for the task, whether the output is accurate enough for your use case, or whether the risk of supplier enforcement justifies continued reliance on that model. That judgement stays yours.

From August 2026, EU enforcement targets the GPAI layer directly. Organisations that rely on large models would be wise to translate those upstream obligations into their own visibility, accountability and verification.