Provider or Deployer? Reading the Responsibility Split

Most conversations about AI obligations run for several minutes before anyone establishes which side of the table the firm is sitting on, and the answer changes almost everything that follows. The EU AI Act draws a line between the organization that develops and places an AI system on the market and the organization that uses one in the course of its work. Different duties attach to each, and a professional services firm is usually, though not always, on the second side.

This gets muddled because the vocabulary in general use does not match the vocabulary in the regulation. Teams describe themselves as “using AI” or “building with AI” interchangeably, and both phrases can describe either role. A firm that configures a tool, writes prompts, and connects it to client data can reasonably feel like it is building something, while occupying the deployer position throughout.

The rough shape of the split

Providers carry the heavier construction burden: what the system is, how it was built and tested, what documentation accompanies it, and what information is passed downstream so that the people using it can meet their own obligations. Deployers carry the operational burden: using the system as intended, applying human oversight, keeping the records their use generates, and acting on what they observe when something goes wrong.

Which category any given organization falls into is a legal question rather than a preference, and it turns on specifics that a blog post cannot settle: what the system does, how it is put on the market, whether it has been substantially modified, and whether it is presented under your own name. Firms that white-label, heavily adapt, or resell can find themselves holding provider duties they did not anticipate, which is one of several reasons this is a question for counsel rather than for an internal guess.

Why deployers underestimate their side

There is a natural assumption that the lighter list is the easy list, and in practice the deployer obligations are the ones that touch daily work most directly. Provider duties are largely discharged in documents and processes that get built once and maintained. Deployer duties are discharged every time a person uses the system, which means they are only ever as good as the habits of the team, and habits are considerably harder to retrofit than paperwork.

Human oversight is the clearest example. It is not satisfied by having a person available in principle, or by an internal policy stating that outputs are checked. It is satisfied by review actually happening, by someone with the standing and the information to disagree with the output, in a way that can be seen afterward. A firm can hold every provider document its vendor supplies and still have no oversight worth the name.

What to ask a vendor

The useful test of a supplier is not whether they claim compliance, since that claim is close to meaningless on its own and no vendor can confer compliance on a customer anyway. The test is whether they can tell you plainly which duties they consider theirs and which they consider yours, and whether their product actually produces the artifacts your side of that split requires.

Concretely: can you get a record of what the system did on your behalf, in a form you could hand to somebody else? Does the tool make human review a step in the workflow, or an assumption about your discipline? When something is flagged, is there a path to record and escalate it? A vendor who has thought seriously about the split will have answers ready. One who has not will redirect to a certification roadmap.

Getting the answer in writing

We publish our own view of that division rather than leaving customers to infer it, because a split that lives only in a sales conversation is not much use during an audit. The responsibility matrix sets out which obligations sit with us and which sit with the organization using the platform, and the conformity assessment covers how we approach our own side of it.

Qonera is the AI governance platform for professional teams, and the review and approval workflow is designed around the deployer position specifically: oversight is a gate rather than an expectation, sign-off carries a name, and the record of what was checked is produced by the work rather than assembled afterward. Knowing which side of the line your firm stands on is the first question worth answering, because everything else in your governance plan depends on that answer being right rather than assumed.

This article is for general information only and does not provide legal advice. Organisations should consult qualified legal counsel about how the EU AI Act applies to their specific systems, workflows, and obligations, including whether they act as a provider or a deployer.