Wrap the Model, or Fine-Tune It?
The build decision that decides what you owe under the EU AI Act.
RAG and fine-tuning look like two ways to build the same tool. Under the EU AI Act, one of them hands you a second regulatory role the other never would.
And the choice almost always gets made before anyone decides to consult Legal.
You usually find it three weeks after the tool ships, scrolling back through the project board for something else entirely.
It’s a card from the planning sprint. The title is some internal codename people outside the team would not recognize. The description is one line, written by an engineer who has long since moved on to the next thing:
Approach: fine-tune the base model on our contract corpus.
You read it once and it means nothing. A technical note about how the contract-review tool got built, the kind of sentence you’ve trained yourself to skim, because ninety percent of what crosses the engineering channel isn’t yours to worry about.
You read it a second time and you stop, because you’ve spent the last month building the company’s EU AI Act position for this exact tool. You decided it was a deployer situation, then talked yourself into provider, then wrote three pages explaining why. And you did all of that without knowing this one line existed.
The word is fine-tune. Not the word you’d been assuming, which was something closer to plugged the model in.
And it occurs to you, sitting there with a cold coffee and a project board you opened for an unrelated reason, that you may have been answering the wrong question for a month.
The Question You Were Being Asked
The instinct, when someone hands you a tool built on a model like GPT or Claude, is to ask what kind of system it is. Is it high-risk? Is it a chatbot under Article 50? Where does it sit in Annex III? Reasonable questions, all of them. And there’s time for all of them later.
There’s a prior question, and it’s the one the engineer’s card answered for you without asking. Not what is this tool, but how was it built on the model underneath it. Because under the EU AI Act, that single design choice decides whether your company holds one regulatory role or two.
The framing usually goes wrong from the start. People ask whether a “RAG system” is something different from “an AI system,” as though those were two products you could choose between. They aren’t the same kind of thing.
“AI system for contract review” describes what the tool does.
“RAG system” (retrieval-augmented generation) describes how it’s wired together.
Your contract tool is almost certainly a RAG system underneath. One word is about function. The other is about plumbing.
And the plumbing words barely appear in the regulation.
“RAG” is nowhere in the AI Act.
Neither is “prompting” or “tool use”.
“Fine-tuning” surfaces once, in a recital, but never as a defined operative term with obligations hung on it.
These are engineering terms, and the EU AI Act doesn’t regulate engineering patterns. It regulates two things, and names them precisely: the AI system (Article 3(1)) and the general-purpose AI model (Article 3(63)). The line that decides your obligations runs between those two definitions. It does not run between RAG and not-RAG, which is the comparison that feels natural and leads nowhere.
Start with the Model, Continue with the System
Start with the model, because that’s the foundational part.
A general-purpose AI model is the engine. GPT, Claude, Llama, Gemini. It displays, in the regulation’s words, “significant generality” and can “competently perform a wide range of distinct tasks” (Article 3(63)). On its own, it is not an AI system, and on its own it puts no AI-system obligations on you at all.
Recital 97 says this in a sentence worth keeping somewhere you can find it:
AI models “do not constitute AI systems on their own”, and they “require the addition of further components, such as for example a user interface, to become AI systems”.
The model is the engine. It is not the car. You cannot drive it until someone builds the rest of the vehicle around it.
So the moment your team builds the contract tool, the interface, the inputs, the defined purpose of reading agreements and flagging clauses, they have built an AI system. And your company is its provider under Article 3(3): you developed it, or had it developed, and put it into service under your own name. That last part catches people, so it’s worth saying plainly.
“Putting into service” includes building something purely for your own use, inside your own walls, never sold to anyone. Provider does not mean seller. If your firm built this tool to run over its own contracts and never licenses it to a soul, your firm is still the provider.
Hold onto that, because it is the part the engineer’s card did not change. Whether the team wrapped the model or fine-tuned it, your company is the provider of the AI system. That was true before you found the card and it’s true after.
The card changed something else.
The Real Deal: Did Anyone Touch the Weights?
What the card changed is whether your company also reached into the model and altered it.
This is the fork, and it’s cleaner than almost any other line the AI Act draws.
On one side, you wrap the model. On the other, you modify it.
Wrapping leaves the model exactly as the provider shipped it. RAG is the clearest example: you connect the model to your clause library and a decade of your old contracts, and at the moment someone asks a question, the system retrieves the relevant material and hands it to the model as context. The model answers from your documents instead of from its training data. But its weights, the actual numbers that make the model what it is, never change. The same is true of prompting, of giving the model tools it can call, of wrapping it in guardrails that check its output. All of that sits around the model. None of it gets inside.
Fine-tuning gets inside. You take the model and keep training it, on your own data, until the weights shift and it starts reasoning in your patterns. That is a different act in kind, not in degree. And past a certain point, the regulation stops treating the result as “the provider’s model, configured by you” and starts treating it as a new model, with your company as its provider.
The dividing question, the one to carry into every build conversation, is not “are we doing RAG”.
It’s whether anyone is touching the model’s weights.
The Number That Decides It Isn’t in the EU AI Act
The threshold that separates “you modified the provider’s model” from “you built a new model” does not appear in the AI Act. It lives in the European Commission’s Guidelines for providers of general-purpose AI models, published 18 July 2025. Guidelines, not regulation. Non-binding guidance interpreting the text. A lawyer who reads the whole EU AI Act cover to cover and stops there will never find this number, which is a strange thing to be able to say about the single line that decides whether you’ve taken on an entire chapter of obligations.
The legal trigger is a significant change in the model’s generality, capabilities, or systemic risk. That phrase is hard to measure, so the guidance offers a number you can actually work with:
if the compute used to fine-tune the model exceeds one-third of the compute used to train the original, treat the result as a significant change, the modified version as a new model, and the entity that fine-tuned it as a provider that may become responsible for it.
An indicative proxy, not a bright line in the text. Where you don’t know the original training compute, which is most of the time, the guidance gives a fallback:
one-third of 10²³ floating-point operations, the same threshold that brings a model into scope as a general-purpose model in the first place.
Now the reassuring part, before anyone panics. Almost no downstream fine-tuning comes anywhere near one-third of the compute that trained a frontier model. Training GPT-class models costs sums the majority of companies will never spend on anything, let alone on adjusting one. So the realistic outcome for the vast majority of teams fine-tuning a commercial or open model is that they do not become model providers. The threshold matters less as a trap people are constantly springing, and more as proof of where the real boundary sits: at the model, not at the technique. Fine-tuning is simply the most common way to walk up to that boundary.
And if you do cross it, Recital 109 softens the landing in a way that rarely survives into the law-firm summaries. Your obligations as the modifier are limited to the modification. You complement the existing technical documentation with information about what you changed. Your training-data summary and your copyright policy cover only the data and compute you added. You do not inherit the documentation burden for the entire original model, which you couldn’t produce anyway, because you didn’t train it.
That’s my reading of how 109 operates, and it’s the reading the guidance supports, though I’d want to see how the AI Office applies it before treating it as settled.
Roles Stack. They Don’t Swap.
One thing I’d want a product team to understand even if they understood nothing else.
The fine-tune decision did not move your company out of one box and into another. It added a box.
Wrap the model, and you hold one role: provider of an AI system. Fine-tune past the threshold, and you hold two: provider of that same AI system, and, on top of it, provider of a general-purpose AI model. Not instead of. As well as. You were always the system provider the moment you built the tool, and nothing about modifying the model relieves you of that. It just stacks a second regulatory identity on top of the first.
And the second identity is its own job, with its own chapter. Chapter V brings obligations that have nothing to do with the contract tool sitting on top and everything to do with the model itself: technical documentation drawn up to the standard of Annex XI, a duty to give downstream builders the information they need to comply with their own obligations (Article 53(1)(b)), a policy for complying with EU copyright law including the text-and-data-mining opt-out, and a publicly available summary of what the model was trained on, using the template the AI Office provides.
Push the modified model past 10²⁵ floating-point operations, into systemic-risk territory under Article 51, and the Article 55 obligations follow: model evaluations, adversarial testing, serious-incident reporting, cybersecurity measures. Downstream fine-tuners will essentially never hit that ceiling. But the first set of obligations lands the day you become a model provider, and it lands in addition to everything you already carried as the provider of the system.
One regulatory role, or two. Decided by a line on a sprint card, by people who were choosing, as far as they knew, between two equally good ways to make the tool work better.
Where This Gets Murky
The wrap-versus-modify line is clean.
The threshold sitting on it is not, and honesty about that is the difference between guidance you can trust and guidance that gets you in trouble.
The one-third figure is indicative. It’s a compute ratio offered in non-binding guidance, and the fallback (one-third of 10²³ FLOP, when you don’t know the base model’s training compute) was never meant to be a precise instrument.
A team fine-tuning close to the line, or building on a model whose training compute the provider has never disclosed, is working with an approximation. The direction is reliable: wrapping is safe, heavy modification is not. The exact boundary is soft, and the guidance may be revised. If you’re near it, that’s a “document your reasoning and watch for updates” situation, not a “we did the math, we’re fine” situation.
Two more things that get conflated and shouldn’t.
RAG keeps you out of model-provider territory, but it does not keep you out of trouble generally. Point a retrieval system at personal data, privileged material, or confidential client contracts, and you’ve created a GDPR and confidentiality problem that has nothing to do with the EU AI Act and everything to do with whether you should be shipping the thing at all.
“We only did RAG, not fine-tuning” answers the question about your role under the EU AI Act. It does not answer the question about data protection, and the second question is often the one that bites first.
And fine-tuning below the threshold, while it doesn’t make you a model provider, still changes the system you provide. If that behavioral shift affects accuracy or bias in a deployment that is high-risk, it’s squarely relevant to your obligations as the system provider, under the data-governance and accuracy requirements in Articles 10 and 15.
The threshold answers one question. It doesn’t answer all of them.
One Caveat About the Contract Tool Itself
So the example doesn’t mislead anyone: plain commercial contract review, a tool a company runs over its own agreements, is not high-risk under the EU AI Act. It isn’t listed in Annex III. The provider obligations that attach to it are light: transparency where Article 50 applies, AI literacy under Article 4, not a great deal beyond that.
That picture changes the moment the tool starts feeding decisions the AI Act cares about. Use it to screen job candidates and it falls into employment. Use it on behalf of a court to interpret and apply the law and it falls into the administration of justice (The trigger there is use by or for a judicial authority. The same tool run purely inside your own business isn’t caught). Use it to inform creditworthiness or insurance pricing and it falls into access to essential services.
All three are Annex III, all three are high-risk, and all three pull the full Chapter III provider regime down on top of everything else. And if the tool profiles individuals, the off-ramp in Article 6(3), the one that lets you argue an Annex III system isn’t really high-risk, closes on you.
The risk question and the role question are separate, and both worth running. But the build point holds at every risk level: wrapping keeps you a system provider, and fine-tuning past the line makes you a model provider too.
High-risk or not, that’s still true.
The Question to Ask Before Anyone Writes Code
It isn’t “is this high-risk”.
That one comes later, and someone will eventually ask it, probably loudly, probably close to a deadline.
The question that gets skipped is the one the sprint card answered while you weren’t looking:
Are we touching the model, or wrapping it?
That single answer routes everything downstream of it. Wrap, and your compliance work tracks the system you built, and only that. Modify past the threshold, and you’ve acquired a second regulatory identity that needs its own documentation, on a clock that starts the day you ship, not the day you notice.
The question costs nothing to ask in a design review. It costs a great deal to answer in an audit, when the honest answer turns out to be “we touched it”, and the follow-up is “and who wrote that down”.
Put it in the AI inventory you should already be keeping. For every system built on someone else’s model, record one more field next to the role and the risk level: wrapped, or modified. Then set the trigger that matters, because this is the field most likely to change without anyone telling you.
The day someone decides to retrain, you reassess. Not the day you find the card. The card is still there, one line, an engineer’s shorthand for a decision that felt purely technical to everyone who touched it.
Approach: fine-tune the base model on our contract corpus.
You’d written three pages on what your company was under the EU AI Act. You’re now fairly sure it was a different number of pages than the company actually needed. And the thing that decided that wasn’t a lawyer, or a regulator, or a clause buried on page four hundred of the AI Act.
It was a sprint card. And no one thought of sending it to you.