The conventional wisdom says you need to know whether your AI modifications make you a "provider" under the EU AI Act. Map your changes to the definitions, calculate your compute thresholds, and slot yourself into the right compliance bucket. Simple, right?
Not quite. This binary framing misses what's actually happening in most organizations.
The Conventional Wisdom
The compliance conversation around AI modifications follows a predictable pattern: Did you substantially modify the system? Yes or no. Are you now a provider? Yes or no. Do the full provider obligations apply? Yes or no.
This makes sense on paper. The EU AI Act defines substantial modification in Article 3(23), sets compute thresholds (one-third of original training FLOPs for General-Purpose AI Models), and maps modifications to provider status in Article 25. The recent GPAI guidelines from the AI Office reinforce this framework: measure your changes, compare to thresholds, determine your role.
Most legal teams and compliance functions approach modifications this way. They build decision trees, create classification matrices, and try to draw bright lines between "we're fine" and "we're now a provider."
Why This Approach Is Incomplete
This binary approach creates three problems you're probably already seeing.
First, it treats modification assessment as a one-time classification exercise rather than an ongoing risk management question. Your team fine-tunes a model today using 15% of the original training compute. Not a provider, right? Then you add another fine-tuning pass next month. Still under threshold? What about the cumulative effect on model behavior, capabilities, or risk profile?
The Act's language points to something more nuanced: modifications that "substantially change generality, capabilities, or systemic risk" (per the GPAI guidelines, paragraph 62). That's not a binary state. It's a spectrum of technical and risk changes that evolves as you iterate.
Second, the binary framing obscures where your actual compliance exposure sits. Consider a team that integrates a third-party General-Purpose AI Model into a customer-facing application, adds retrieval-augmented generation with proprietary data, implements custom safety filters, and wraps it all in domain-specific prompting. Are they a provider? Maybe not under the compute threshold. But they've materially changed what the model does, how it fails, and what risks it introduces to end users.
The compliance question isn't just "did we cross the provider threshold?" It's "do we understand and control the risks we've introduced, and can we demonstrate that control to a regulator?"
Third, this approach makes you dependent on upstream transparency you often don't have. The compute threshold sounds objective until you realize the foundation model provider hasn't disclosed their training FLOPs, architecture details, or baseline risk assessments. You're making a classification decision with incomplete information, then building your compliance posture on that shaky foundation.
The Evidence
Look at what the GPAI guidelines actually say. The one-third compute threshold is described as "merely an indicative criterion" (paragraph 62). The overarching rule comes back to whether modifications result in substantially modified generality, capabilities, or systemic risk.
That's not a measurement problem. It's a judgment problem.
The Act's definition of substantial modification for high-risk AI systems reinforces this: changes "which affect the compliance with requirements" or "which affect the intended purpose" (Article 3(23)). Both are functional tests, not computational ones.
Even the grandfathering provisions reveal the tension. If you substantially modify an existing General-Purpose AI Model after 2 August 2025, you face provider obligations even though the upstream provider may not need to comply until August 2027. That's not a technical distinction. It's a policy choice about who owns the risk when behavior changes.
What to Do Instead
Treat modification assessment as risk-based governance, not binary classification.
Start with a modification impact log. Every time your team changes a model or system, document what changed (architecture, data, fine-tuning, integration), why it changed, and what risks or capabilities shifted as a result. Don't try to calculate a final "provider yes/no" score. Build a cumulative record of how your deployed AI differs from what you started with.
This log becomes your evidence base for two separate questions: First, do we meet the legal definition of a provider under Article 25 or the GPAI provisions? Second, regardless of legal classification, what controls do we need given the risks we've introduced?
Implement modification thresholds tied to model behavior, not just compute. If fine-tuning changes your model's accuracy on protected attributes by more than X%, that triggers a review. If your retrieval-augmented generation pipeline introduces failure modes the base model didn't have, that triggers updated Technical Documentation (Annex IV). If your prompt engineering shifts the model's intended purpose, that triggers a fresh conformity assessment.
These thresholds won't tell you if you're legally a provider. They'll tell you when your risk profile has materially changed and you need to update your controls.
Build vendor transparency requirements into your procurement process now. Your contract with a foundation model provider should specify what technical details they'll share, how they'll notify you of upstream changes, and what documentation they'll provide to support your downstream assessments. If they can't commit to that transparency, factor the compliance uncertainty into your vendor risk evaluation.
Finally, document your classification rationale even when you conclude you're not a provider. If a regulator questions your role in 2026, "we didn't think we qualified" won't hold up. "Here's our modification log, here's our risk analysis, here's why we concluded the changes didn't substantially affect capabilities or systemic risk" might.
When the Conventional Wisdom Is Right
The binary classification approach makes sense in exactly one scenario: you're making a discrete, one-time modification that clearly crosses or clearly doesn't cross the substantial modification threshold, and you have full transparency into the upstream model.
If you're taking an open-weight model, conducting a full fine-tuning run that uses 50% of the original training compute, and deploying it as a new product, yes, you're a provider. The classification is straightforward and the compliance path is clear.
But most organizations aren't in that scenario. You're making incremental changes, integrating third-party models into complex systems, and operating with partial information about upstream risks. For you, the binary question is the wrong question. The right question is: what risks am I introducing, and how do I demonstrate control over them?
The EU AI Act's General-Purpose AI Model provider obligations took effect on 2 August 2025. If you're still trying to answer "are we a provider?" as a yes/no question, you're asking it wrong. Start asking "what have we changed, and what does that mean for our risk posture?" The compliance answer will follow.
