Deployer Liability Under the EU AI Act: When You Become the Provider

Most enterprises reading the EU AI Act place themselves in the deployer column and stop there. Deployers have a list of operational duties under Article 26, the vendor holds the heavy compliance burden, and the arrangement looks manageable.

‍

Article 25 is the provision that undoes that assumption. Three ordinary commercial acts convert a deployer into a provider, the reclassification happens automatically with no notification or registration step, and the third trigger catches something a large number of organizations are already doing.

‍

What Article 26 Asks of a Deployer

‍

The operational obligations are the part most guidance covers, and they are genuinely substantial.

‍

A deployer of a high-risk system must use it according to the provider's instructions, assign human oversight to people with the competence, training and authority to exercise it, ensure input data is relevant and sufficiently representative where it controls that data, monitor operation and report serious incidents, and retain automatically generated logs for at least six months. Workers must be informed before a high-risk system is put into service in the workplace, and individuals subject to decisions made with such a system have a right to know.

‍

Vendor Documentation Describes the Software, Yours Proves the Operation

‍

The division is worth stating plainly because it is where most programs are thin. A provider's technical documentation describes capabilities, architecture and tested bounds. A deployer's records have to demonstrate safe daily operation, covering who exercised oversight, what inputs were supplied, when a human overrode an output and what happened next. A CE mark on the vendor's product evidences the first and none of the second, which is why an operational audit trail does work no certificate can.

‍

Three Ways a Deployer Becomes a Provider

‍

Article 25 states that a distributor, importer, deployer or other third party shall be considered a provider, and subject to the full provider obligations under Article 16, in three circumstances.

‍

Putting Your Name on It

‍

Placing your own name or trademark on a high-risk system already on the market makes you its provider. The branding trigger carries a qualification the other two do not, since the text preserves contractual arrangements that allocate the obligations otherwise. White-labeling a third-party system without addressing this in the contract is the avoidable version of the problem.

‍

Substantially Modifying It

‍

A substantial modification to a high-risk system already on the market, where it remains high-risk, transfers provider status. The Act defines substantial modification separately, and changes to core functionality, training data or intended use are the ones most likely to qualify. Fine-tuning a vendor model on your own data sits uncomfortably close to this line, and what an audit examines will test the distinction.

‍

Changing What It Is For

‍

The third trigger is the one that will catch the most organizations. Modifying the intended purpose of a system that was not classified as high-risk, including a general-purpose system, so that it becomes high-risk under Article 6, makes you the provider. Pointing a general-purpose model at applicant screening, creditworthiness assessment or another Annex III use is exactly this. The model vendor never classified it as high-risk because they did not deploy it into that context, and you did.

‍

Reclassification Is Automatic

‍

Nothing announces it. There is no registration step, no notification from an authority and no moment where somebody confirms your new status. If the conditions are met you hold provider obligations from that point, whatever your internal documentation says your role is.

‍

The practical consequence is that role classification cannot be a one-time exercise recorded at procurement. It has to be re-tested whenever a system is modified, rebranded or pointed at a new use case, and the third of those is a decision a business team can make without involving anyone in compliance. Recording intended purpose as an inventory attribute is what makes the re-test possible at all, since a register organized by tool rather than by purpose cannot see the change.

‍

What You Inherit When It Happens

‍

Provider obligations under Article 16 are an order of magnitude heavier than deployer duties. The list includes a quality management system, technical documentation to the standard set out in the Act, a conformity assessment, CE marking, registration in the EU database, post-market monitoring and corrective action duties.

‍

None of that is assembled quickly. A conformity assessment rests on documentation covering the system's design, development, testing and risk management, and much of that evidence describes work the original vendor did rather than work you did. The absence of cited standards makes assembling it harder still. An organization discovering it became a provider after deployment is trying to document a development process it did not run, which is the position to avoid rather than to manage.

‍

The Contract Helps in One Case Out of Three

‍

Commercial teams reasonably assume this is a contracting problem. The text supports that reading for the branding trigger and not for the other two.

‍

Where you put your name on a system, contractual arrangements allocating the obligations otherwise are preserved. Where you substantially modify a system or change its intended purpose, no equivalent language appears, so an indemnity from your vendor may allocate cost between the parties and does not change who the regulator considers the provider. Vendor terms are still worth negotiating, and third-party terms agreed before signature are considerably easier to obtain than after, though they should not be relied on to prevent reclassification.

‍

Ask the Vendor What They Classified

‍

A useful and rarely asked question during procurement is which intended purpose the provider declared, and whether their conformity assessment covers the use you have in mind. A system assessed for one purpose and deployed for another leaves you exposed on trigger three regardless of how complete the vendor's documentation looks.

‍

Check the Dates Against Current Text

‍

A practical warning about sources. A considerable amount of published guidance on these articles, including material updated during 2026, still works from the original timeline and tells readers to resolve their position before August 2026.

‍

Following the Digital Omnibus, high-risk obligations for Annex III stand-alone systems apply from 2 December 2027, with embedded systems under Annex I following in August 2028, and those dates operate as backstops tied to standards completion. The transparency obligations that did apply from August 2026 are a separate matter under Article 50. Anyone planning against a date found in an article should verify it against the current text, and the revised timeline sets out what falls where.

‍

What to Do Now

‍

Three checks resolve most of the exposure and none requires waiting for standards.

‍

• Test Role Per Use Case: Classify by intended purpose rather than by system, since one tool can leave you a deployer for one use and a provider for another.
• Flag Purpose Changes: Treat pointing an existing system at a new decision as a governance event requiring re-classification, not a configuration change.
• Record What the Vendor Declared: Capture the provider's stated intended purpose and the scope of their conformity assessment at procurement.

‍

Building the deployer evidence base runs alongside these. Oversight records, input data decisions, override logs and the six-month log retention are all obligations that exist regardless of role, and records that survive an audit covers what that documentation has to contain to be usable later.

‍

Role Is a Property of Use, Not of Purchase

‍

Deployer status is not a category an organization occupies permanently by virtue of having bought rather than built. It is contingent on what you put your name on, what you modify and what you point the system at, and the third of those changes hands inside business teams without a compliance review. The reclassification is automatic and the obligations it brings are the heavy ones. Kovrr's AI compliance readiness assesses obligations per system and per intended purpose, which is the granularity the question requires.

‍

To see which of your AI systems would make you a provider rather than a deployer under current use, book a demo mapped to your own estate.