A general counsel sent me a one-line email last quarter: "We need a copyright policy and a training data summary by the end of the month or we are in breach of Article 53." The company builds a workflow product on top of a commercially licensed large language model. It trains nothing. It fine-tunes nothing. It is not in breach of Article 53, because Article 53 does not apply to it.
The panic was entirely reasonable. Article 53 reads as though it applies to anyone doing anything with a general purpose AI model, until you read the definitions it depends on. Once you have, the scope collapses to a small population of organisations, almost none of which are ordinary enterprise software companies.
This matters commercially as well as legally, because organisations spending effort on obligations they do not carry are not spending it on the ones they do.
What Article 53 requires, and of whom
Article 53 sits in the chapter of the EU AI Act dealing with general purpose AI models. Its obligations attach to providers of those models.
A provider of a general purpose AI model that is placed on the Union market must draw up and keep current technical documentation of the model, including its training and testing process and the results of its evaluation. It must make information and documentation available to downstream providers who integrate the model into their own AI systems, so that those parties can understand the model's capabilities and limitations and meet their own obligations. It must put in place a policy to comply with Union law on copyright and related rights, including respecting reservations of rights expressed under the text and data mining exception. And it must draw up and make publicly available a sufficiently detailed summary of the content used for training the model, according to a template provided by the AI Office.
These obligations applied from 2 August 2025 and are in force now. This is the point where the timeline commentary most often goes wrong. The Digital Omnibus on AI deferred elements of the high-risk regime, moving Annex III high-risk obligations to 2 December 2027 and Annex I high-risk obligations to 2 August 2028. It did not defer the general purpose AI model obligations. Article 53 is live and has been since summer 2025.
The definition that decides everything
Everything turns on whether you are a provider or a deployer, and the Act defines both.
A provider is a natural or legal person that develops an AI system or a general purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trade mark, whether for payment or free of charge.
A deployer is a natural or legal person using an AI system under its authority, other than where the system is used in a personal non-professional activity.
The distinguishing acts are development and placing on the market under your own name. Buying an API and calling it is neither. An organisation that licenses a foundation model from a model developer and builds a product on top of it is, in relation to that model, downstream. The model provider carries the Article 53 obligations for the model. You do not inherit them by consuming the output.
This is the most consequential definition in the regulation, and it is consequential in both directions. It is the reason most organisations carry far less GPAI obligation than they fear. It is also the reason a minority carry considerably more than they realise, which is the point I return to below.
What deployers actually carry instead
Not nothing. The obligations are simply different ones, and they attach to the system rather than to the model.
Where the AI system a deployer uses is classified as high-risk, Article 26 applies. In broad terms it requires the deployer to use the system in accordance with the provider's instructions for use, to assign human oversight to people with the necessary competence, authority and support, to exercise control over input data to the extent the deployer controls it, to monitor operation and to inform the provider and the relevant authorities where a serious incident or a risk to health, safety or fundamental rights is identified, and to keep automatically generated logs where these are under the deployer's control. Where the deployment affects workers, there are also information obligations toward workers and their representatives.
Separately, Article 50 imposes transparency obligations that are not tied to the high-risk classification. People interacting with an AI system must be informed that they are, unless it is obvious. Synthetic content must be marked in a machine-readable format. Emotion recognition and biometric categorisation use must be disclosed to the people exposed to it. Deep fake content must be disclosed as artificially generated or manipulated. Several of these obligations fall on deployers directly.
And where the deployer is a body governed by public law, or a private entity providing public services, or is deploying certain high-risk systems in credit or insurance, Article 27 adds a fundamental rights impact assessment. That is a deployer obligation with no provider equivalent.
The practical instruction is to stop reading Article 53 and start reading the deployer obligations, because those are the ones that will apply to you.
Where an organisation becomes a provider without realising
Two routes catch organisations that were confident they were deployers.
The first is substantial modification. An organisation that takes a general purpose AI model and modifies it substantially may take on provider obligations in respect of the modified model. What counts as substantial rather than incidental is the live question. Light prompt engineering and retrieval augmentation sit comfortably at the incidental end. Continued pre-training, or fine-tuning at a scale that meaningfully changes the model's capabilities, sits closer to the other. The guidance in this area is still developing and I would treat confident assertions about the exact boundary with caution, including from advisers. If your work sits near the line, take the question seriously and document the reasoning.
The second is white labelling. An organisation that places an AI system or a model on the market under its own name or trade mark is a provider of it, regardless of who built it. This catches resellers, platform operators bundling third-party AI as their own capability, and organisations that have quietly rebranded an underlying model in their product surface. If your customers reasonably believe the AI is yours, expect to be treated as a provider of it.
Neither of these is exotic. The second in particular catches a meaningful number of organisations that describe themselves without hesitation as users of AI.
The commercial reality, which is separate from the legal one
Here is the part that trips up the organisations that get the legal analysis right.
Establishing that Article 53 does not bind you does not stop buyers asking the provenance question. It arrives in the AI domain of enterprise vendor assessments regardless of your regulatory role. Where did the training data come from. Was it lawfully obtained. Is there copyright exposure. Does your model provider disclose enough for you to answer.
Answering "we are a deployer, not a provider, and Article 53 does not apply to us" is legally accurate and commercially useless. The buyer is not conducting a regulatory audit. They are managing their own supply chain risk, and your model provider's practices are part of their exposure whether or not the regulation routes the obligation through you.
The workable answer has three parts, and none of them requires you to be a provider. Name the model and provider you use. State what the provider has published about training data and evaluation, and reference their published summary where one exists. State plainly what you cannot verify, and what contractual assurances you hold from the provider instead. Then set out what you do control: your own data handling, whether customer data reaches the model, whether anything is used for training, and how you monitor outputs.
That answer is honest, it is defensible, and it takes an hour to write once and is then reusable. It is also, in my experience, more persuasive than an overreaching claim, because a buyer's security analyst who has read a dozen of these can tell the difference between a supplier who understands their position and one who is asserting comfort.
Get the role classification right first, then answer the commercial question separately. Most organisations do it the other way round and spend the effort in the wrong place.
The systemic risk tier, and why it almost certainly does not apply to you
Article 55 adds a further set of obligations for providers of general purpose AI models with systemic risk: model evaluation including adversarial testing, assessment and mitigation of systemic risks at Union level, serious incident tracking and reporting to the AI Office, and adequate cybersecurity protection for the model and its physical infrastructure.
The threshold for that classification is set by reference to high impact capabilities, with a presumption tied to the cumulative amount of compute used in training. The population it captures is a handful of frontier model developers.
I mention it only because it appears in summaries alongside Article 53 and adds to the impression that the GPAI chapter is broadly applicable. It is not. If you are not training frontier models, Article 55 is context rather than obligation.
Getting the role classification into writing
The practical output of this analysis should be a short, dated document that records, for each AI system your organisation operates or supplies, what role you hold in respect of it and why.
Record the system, the underlying model and its provider, whether you modify the model and how, whether the system is placed on the market under your name, the resulting role classification, the reasoning, and the date and author. Where the position is arguable, say so and record the alternative reading rather than presenting a conclusion as settled.
Two reasons this matters more than it looks. The first is that the boundary cases will be revisited as guidance develops, and a documented reasoning chain can be updated in an hour whereas an undocumented conclusion has to be rebuilt from memory. The second is that buyers and, eventually, authorities will ask. An organisation that can produce a reasoned role classification on request is in a materially better position than one asserting a conclusion it cannot show its working for.
This is also, incidentally, the sort of record an ISO 42001 management system produces as a by-product of maintaining an AI system inventory. If you are building one anyway, add the role classification field and the regulatory analysis comes largely for free.
If you need to establish which of your AI systems put you in a provider role and which do not, an AI governance readiness assessment produces the inventory, the role classification, and the obligation map. Book a scoping call.
Last reviewed: August 2026.