The Article 25 Trap: When Using AI Quietly Makes You the Provider

Two weeks ago, in a partner meeting at a top-three European law firm, the senior associate leading their AI Act practice told me she's now opening every advisory engagement with a single question: "Have you white-labelled the vendor system?" Her clients keep answering no, and then she walks them through the marketing assets, the customer-facing portals, the help documentation — and the answer changes to yes about 60% of the time. That's Article 25(1)(a) tripping silently in the background of every enterprise AI portfolio I see. The most quoted simplification of the EU AI Act among enterprise legal teams is still "we're just deployers, not providers — our obligations are lighter." It's also among the most operationally dangerous. Article 25 establishes three specific circumstances under which a deployer transitions to provider status — automatically, by operation of law, regardless of contractual intent. The full Articles 9–15 obligations attach in that moment, retroactively if the activity preceded the realisation. Across the AI Act readiness assessments MindMap has run in BFSI, healthcare and pharma since Q4 2025, the Article 25 finding shows up in roughly 70% of portfolios. Most enterprises don't know they've crossed any of the three triggers.

Trigger one: putting your name or trademark on a high-risk AI system

Article 25(1)(a) is the cleanest of the three. If you take a vendor's high-risk AI system, brand it as your own — under your name, trademark, or even consistent product identity in customer-facing contexts — you become a provider of that system. Common patterns that trip this: white-labelling a vendor credit-scoring engine under the bank's own product name; integrating a vendor HR-screening tool into the company's branded careers portal so candidates experience it as the company's system; embedding a vendor clinical decision support system into the hospital's own electronic health record under the hospital's brand. Every one of these is widespread; few of them have been recognised as Article 25 triggers in the legal documentation we've seen.

Trigger two: substantially modifying the system

Article 25(1)(b) catches enterprises that substantially modify a high-risk AI system after it's been placed on the market. "Substantially modifying" is defined in Article 3(23) as a change that affects the system's intended purpose, or its compliance with the Act, or that's not foreseen in the provider's risk assessment. In practice the threshold is lower than most legal teams assume. Examples we've seen treated as not-a-modification but that probably are: fine-tuning the vendor's base model on the bank's own data; adding a custom guardrails layer that changes refusal behaviour; integrating new data sources that materially shift the population the model sees; deploying the system into a use case the vendor didn't validate for.

Trigger three: changing the intended purpose

Article 25(1)(c) catches enterprises that modify the intended purpose of a high-risk AI system. "Intended purpose" is a defined term referring to what the provider declared the system was for. If you take a vendor system designed for one use case and deploy it for a different use case in your business, you've changed its intended purpose. We see this most often in document-intelligence and conversational AI: a vendor IDP system intended for invoice processing gets repurposed for claims processing; a vendor chatbot platform intended for customer support gets repurposed for employee onboarding. Each repurposing converts the deployer into a provider for the new use case.

What the trigger actually changes

The legal effect of crossing any of the three triggers is dramatic. The deployer's obligations under Article 26 (human oversight, instructions for use, input data control, monitoring) get supplemented by — not replaced by — the full provider stack: Article 9 risk management, Article 10 data governance, Article 11 technical documentation, Article 12 record-keeping, Article 13 transparency, Article 14 human oversight in the provider's sense, Article 15 accuracy / robustness / cybersecurity, Article 17 QMS, Article 43 conformity assessment, Article 47 EU declaration of conformity, Article 48 CE marking, Article 49 database registration, Article 72 post-market monitoring, Article 73 incident reporting. The contractual reasoning that "the vendor is the provider, we just use it" doesn't survive Article 25.

The audit findings we keep producing

Across the AI Act readiness assessments we've run in BFSI, healthcare and pharma since Q4 2025, the Article 25 finding shows up in roughly 70% of portfolios. The most common pattern: a deployer believes its vendor relationship covers all provider obligations, on the strength of the vendor's CE-marked declaration; in fact, the deployer has white-labelled the system, customised it materially, or repurposed it — sometimes all three — and now bears provider obligations the supervisor will look for evidence of. The remediation isn't usually catastrophic, but it's measurable engineering work: produce the deployer's own Annex IV documentation; stand up the provider's monitoring and incident-reporting workflows; complete a conformity-assessment workstream. None of this is achievable in 30 days.

Three actions for general counsel

Action one: inventory every high-risk AI system in the enterprise and classify the deployer-vs-provider posture per system, with explicit consideration of Article 25 triggers. Action two: for any system where Article 25 has been or is likely to be triggered, accept provider obligations and plan the engineering accordingly. Action three: rewrite the standard AI procurement template to require providers to flag any deployer customisation that would trigger Article 25, and to provide the conformity-assessment evidence the deployer needs to satisfy its own supplemental provider obligations cleanly. The deployer-becomes-provider problem isn't a contract problem; it's an architecture and documentation problem. The MindMap Digital EU AI Act whitepaper covers the Article 25 mapping in more depth — see /eu-ai-act for the public summary.