Most enterprise AI teams think of themselves as customers. They license a model or platform from a vendor, build something useful on top of it, and assume the heavier compliance obligations under the EU AI Act belong to whoever built the underlying model. That assumption holds most of the time. It does not always hold, and the moments it breaks down are exactly the moments most governance programs are not watching for.
The EU AI Act does not only regulate the companies that build AI systems from scratch. Under Article 25, a distributor, importer, deployer, or other third party can, under specific conditions, be treated as the provider of a high risk AI system, taking on the full set of provider obligations that come with that label. That is a meaningfully heavier compliance load: conformity assessment, technical documentation, a quality management system, and post-market monitoring, among other requirements that a deployer alone does not carry.
If your organization is building agents, fine-tuning models, or layering custom logic on top of vendor AI, this is worth understanding precisely, because the line between deployer and provider is not about how much code you wrote. It is about three specific triggers.
Trigger One: Putting Your Name On It
The most straightforward trigger is branding. If your organization places its own name or trademark on a high risk AI system, the Act treats that as taking on provider status for that system, regardless of who built the underlying model. This is the trigger most teams already have some intuition for. White-labeling a vendor’s AI capability under your own product name is a decision someone in legal or product marketing is usually already aware carries weight. It is worth confirming that awareness extends to the AI governance function specifically, not just brand and legal review.
Trigger Two: Substantial Modification
The second trigger is less intuitive and easier to trip without noticing. If your organization makes a substantial modification to a high risk AI system, one significant enough that the system’s compliance with the Act’s requirements could be affected, that modification can shift provider obligations onto whoever made it, even without any rebranding involved.
This is where a lot of everyday AI engineering work becomes a governance question rather than a purely technical one. Fine-tuning a vendor’s model on your own data, adding a retrieval layer that changes what information the system can access and surface, building an orchestration layer that changes how a model’s outputs get used downstream, all of these are common, reasonable things to do with vendor AI, and all of them are the kind of change that can qualify as substantial modification depending on scope and effect. The determining question is not how much custom code was written. It is whether the change is significant enough to affect the system’s compliance with the Act’s requirements for a high risk system.
Trigger Three: Changing the Intended Purpose
The third trigger applies even to AI systems that were not originally high risk. If your organization changes the intended purpose of an AI system in a way that makes it a high risk system under the Act, that change can also result in taking on provider obligations, again independent of any rebranding.
This is the trigger most likely to catch a team by surprise, because it does not require touching a system that was already flagged as high risk. A general purpose model licensed for one use case, say, drafting internal documentation, carries a very different risk profile than the same model repurposed to support a use case that falls under one of the Act’s high risk categories, such as a role in employment decisions or access to essential services. The model has not changed. What it is used for has, and under the Act, that is enough to matter.
What This Means for a Governance Program
None of this means every AI customization project is secretly a regulatory event. Most are not. What it means is that a governance program built only around “which vendors do we use” is watching the wrong layer. The actual compliance-relevant activity is happening inside individual projects: what’s being fine-tuned, what’s being connected to what, and what a system originally built for one purpose is quietly being asked to do for another.
A governance program that can answer those questions as they happen, rather than reconstructing them after the fact during an audit, is in a fundamentally different position than one that only tracks vendor contracts. That means visibility into what models are actually deployed, what modifications have been made to them, and what each one is currently being used for, kept current as those things change rather than documented once at launch and left to go stale.
Five questions worth putting directly to any team building on top of vendor AI capture most of what matters here. Has this system, or any component of it, been fine-tuned or retrained on our own data. Has our name or branding been applied to it in a customer-facing way. Has its intended use case changed since it was first approved. Would a reasonable person say our modifications could affect whether the system still meets its original compliance basis. And critically, does anyone outside the engineering team building it actually know the answers to the first four questions.
That last question is usually where the gap actually lives. The technical answers to whether a system was fine-tuned or repurposed are usually knowable. Whether that information reaches the people responsible for regulatory obligations, before a modification ships rather than during a post-incident review, is a governance question, not a technical one.
The EU AI Act does not ban enterprises from customizing AI. It asks them to know, continuously, what they are actually running and what obligations that running system carries. For most organizations, that is less about a single compliance checklist and more about building a governance program with real-time visibility into what is deployed, how it has been modified, and what it is currently being used for, so that a shift from deployer to provider gets caught by design rather than discovered by an auditor.
Regulatory interpretation of the EU AI Act continues to develop, and this article reflects publicly available information as of the article’s publish date. It is not legal advice. Confirm how these provisions apply to your specific systems with qualified counsel.
The organizations that stay ahead of this are the ones that treat governance as continuous, not a one time classification exercise done at launch and forgotten.
Put these ideas to work.
Schedule a 30-minute walkthrough with our team.