On August 2 The EU Can Start Fining AI Model Providers, And Your Vendor Choice Just Became A Compliance Control

There is a difference between a rule that exists and a rule that can be enforced, and for the last year the general-purpose AI provisions of the EU AI Act have lived in that gap. The obligations on providers of general-purpose AI models, the large foundation models behind products like ChatGPT, Claude and Gemini, formally applied from August 2, 2025. What did not exist yet was the machinery to punish anyone for ignoring them. That machinery switches on this coming August 2, 2026. From that date the European AI Office and the Commission can request documentation, run their own technical evaluations of a model, order compliance and risk-mitigation measures, restrict or withdraw a model from the EU market, and levy fines of up to 3 percent of global annual turnover or 15 million euros, whichever is higher, under Article 101 of the Act. A voluntary-feeling regime becomes a real one in a single week, and most teams we speak to have not registered that the date is a Sunday now only days away.

It helps to be precise about what the obligations actually require, because the headlines make them sound heavier than they read. Every provider of a general-purpose model must maintain up-to-date technical documentation of the model and make a defined subset available to downstream businesses that build on it, must publish a sufficiently detailed summary of the data used for training, and must put in place a policy to respect EU copyright law including honouring machine-readable reservations of rights. Providers whose models are judged to carry systemic risk, the frontier tier defined by a training-compute threshold, carry a heavier load: model evaluation and adversarial testing, systemic-risk assessment and mitigation, serious-incident reporting to the AI Office, and cybersecurity protection for the model weights. Transparency, copyright discipline and, for the largest models, safety engineering. None of it is exotic to anyone who has run a security programme, but all of it now has a regulator who can ask to see it.

The reason this matters far beyond a handful of labs is that the Act draws a sharp line between a provider and a deployer, and almost everyone reading this is a deployer. If your company uses ChatGPT to draft support replies, Claude to write code, or an open-weight model fine-tuned on your own data, you are not the party the Article 101 fines are aimed at. But the obligations do not stop at the provider boundary, they flow down it. The provider documentation exists specifically so that you, the downstream business, can understand the model well enough to meet your own duties under the Act and under any AI management system you run. When your enterprise agreement with OpenAI or Anthropic gives you a data summary, an acceptable-use boundary and a statement of the model capabilities and limitations, that is the upstream obligation arriving on your desk as an input you are now expected to hold and act on.

There is also a trap in the word provider that catches more organisations than people expect. If you take an open model and fine-tune it substantially, or you modify a general-purpose model in a way that changes its capabilities meaningfully, the Act can treat you as the provider of that modified model, with the provider obligations attached. A startup that quietly assumed it was a pure consumer of AI can find, on reading the definitions, that its fine-tuned model has moved it across the line. This is exactly the kind of classification question that does not surface in a product roadmap and does surface in a procurement questionnaire or a customer security review, which is increasingly where these obligations get tested in practice long before any regulator is involved.

The mechanism the Commission expects most providers to use to show compliance is the General-Purpose AI Code of Practice, the voluntary framework the AI Office finalised in July 2025 with its three chapters on transparency, copyright, and safety and security. Signing it is not a legal requirement, but it is the path of least resistance: a provider who adheres to the Code gets a presumption of conformity and a lighter documentary burden, while one who declines has to demonstrate compliance some other way and can expect closer scrutiny. For a downstream buyer this turns into a concrete diligence question. When you evaluate a foundation-model vendor now, whether they are a signatory to the Code, and what their published model documentation and training-data summary actually contain, is legitimate procurement information in the same way a SOC 2 report or an ISO 27001 certificate is, and it belongs in the same vendor file.

This is where the story connects to the compliance frameworks we cover constantly, because the AI Act does not ask you to build governance from nothing. If you are already running an ISO 42001 AI management system, most of what the Act expects of a deployer already has a home: an inventory of the AI systems you use, a risk assessment for each, a record of the provider documentation you rely on, human-oversight and incident-handling processes, and a defined owner. ISO 42001 was designed as the operational scaffolding for exactly this regulatory moment, and the overlap with the Act is deliberate rather than coincidental. The efficient move is not to treat EU AI Act readiness as a separate project but to fold it into the management system you may already be certifying, so that one set of controls answers to both the standard and the statute.

The GRC platforms have moved to meet this, and it is worth knowing what they do and do not solve. Vanta, Drata, Secureframe and Sprinto have all added ISO 42001 framework support that cross-maps to ISO 27001 and SOC 2, and several now ship AI-flavoured agents that inventory the AI tools in use across a company, draft governance policies, and pre-fill the AI sections of security questionnaires. That automation genuinely helps with the paperwork and the evidence cadence, and if you run one of these platforms you should turn the ISO 42001 module on and let it map your existing controls across. What no platform can do for you is the judgement calls: whether your fine-tuning makes you a provider, whether a given use of a model is an acceptable risk for your context, and whether the vendor documentation you were handed is actually adequate. The tool holds the evidence and enforces the cadence, a human still has to make the decisions the Act cares about.

The practical posture for the next week and the months after is unglamorous and achievable. Build or refresh a register of every general-purpose AI model and AI-powered tool your organisation uses, from the obvious ChatGPT and Claude seats to the models embedded inside other software you have bought. For each one, record who the provider is, whether they adhere to the Code of Practice, and where their model documentation and data summary live. Separate the systems where you are plainly a deployer from any where fine-tuning might make you a provider, and get advice on the latter. Fold all of it into your ISO 42001 or wider GRC programme rather than standing up a parallel one. The AI Act enforcement date is not a cliff that most deployers fall off on August 2, but it is the moment the whole regime stops being theoretical, and the organisations that treated their model providers as a compliance input rather than a black box will be the ones with nothing to scramble over.