The provider and deployer line breaks under autonomy

This is part of the Agentic AI element of the GovCompass-7.

How the Act allocates responsibility

The EU AI Act builds its obligations on a role distinction. The providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name — carrying manufacturer-style duties: design controls, documentation, conformity.Open full entry → develops an AI systemAI systemA machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs — predictions, content, recommendations or decisions — that can influence physical or virtual environments. The OECD-style definition followed by the EU AI Act.Open full entry → or has it developed and places it on the market under its own name. The deployerdeployerAn organization using an AI system under its own authority in its activities — carrying operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry → uses an AI system under its authority. Providers carry the heavier obligations: conformity assessmentconformity assessmentThe pre-market process demonstrating a high-risk AI system meets the EU AI Act's requirements, leading to CE marking and registration.Open full entry →, technical documentation, the quality management system. Deployers carry a lighter but real set: ensuring human oversighthuman oversightDesigned-in human ability to monitor, intervene in, override or shut down an AI system — meaningful only when the human has authority, information and time to act.Open full entry →, monitoring operation, using the system in accordance with instructions.

The Act also has a rule for when a deployer becomes a provider. A deployer that makes a substantial modificationsubstantial modificationA change to a deployed AI system that materially alters its function or purpose — capable of shifting provider obligations onto the modifier.Open full entry → to a high-risk system, or that puts its name on the system, or that changes the intended purpose, takes on provider obligations. In classic deployments this rule is rarely triggered, because deployers use systems roughly as delivered.

Why agentic configuration changes this

Agentic systems are configured, not just used. The deployer of an agent platform decides which tools the agent can call, how much autonomy it has, what decision scope it operates within, whether it can spawn sub-agents, and what actions it can take without human approval. These are not peripheral settings. They are the choices that determine what the system does in the world.

This is where the line breaks. A deployer who grants an agent broad tool-calling rights and autonomous scope over a high-risk decision may have changed the system's behaviour and risk profile substantially enough that they are, in functional terms, shaping a new high-risk system. The Act's text was written for a world where the deployer received a finished product. Agentic configuration hands the deployer a set of dials that can alter the system's purpose and risk, and altering purpose and risk is precisely what tips a deployer into provider territory.

The Commission has been explicit that its position on AI agents is preliminary and that more specific guidance is likely. The structural problem it has identified is that the Act assumes roles are stable, and in agentic systems they are not. An entity that designs and operates a system in which AI systems direct, invoke, or constrain other AI systems does not fit cleanly into either the provider or the deployer box.

What an AI Officer should do now

The practical response is to treat agentic configuration as a governance decision with classification consequences, not as a technical setting. For each agent your organisation deploys, document the configuration choices that bear on autonomy: tool access, decision scope, sub-agentsub-agentAn agent invoked by another agent or an orchestrator to carry out part of a task. Its actions still inherit the obligations of the stack it belongs to.Open full entry → spawning, and the actions permitted without human approval. Then assess, against the Act's substantial-modification and intended-purpose tests, whether those choices push your organisation toward provider obligations.

Where the assessment is close, the conservative position is to assume provider-level responsibility and build the corresponding documentation, because the cost of being wrong is carrying provider obligations you have not met. Where you procure an agent platform from a vendor, the contract should make explicit which party bears provider obligations under which configurations, because the default allocation written for non-agentic systems will not map cleanly onto what you are actually deploying.

The deeper point

AccountabilityaccountabilityThe principle that a named human or organization answers for an AI system's outcomes, through ownership, documentation, audit trails and redress — never the system itself.Open full entry → is one of the seven GovCompass elements, and agentic AIagentic AISystems where a model takes actions — calling tools, executing multi-step plans — amplifying both capability and every failure mode; governed with action allowlists, approvals and full logging.Open full entry → is where it is most severely tested. The Act's role model is a proxy for a simpler question: when this system takes an action that harms someone, who is answerable? In a configured, autonomous, multi-agent systemmulti-agent systemA system in which several agents interact, delegate, and pass outputs to one another to reach a goal, with no human checkpoint between each step.Open full entry →, the honest answer cannot be deferred to a contract clause written for a different kind of technology. It has to be established deliberately, before deployment, by the organisation that decided how much the agent is allowed to do.