Provider and Deployer Roles for the Same AI System Under the EU AI Act

How the definitions allow one organization to hold both roles

The Act's role definitions are functional. Recital 13 describes a deployer as any natural or legal person, including a public authority, agency or other body, using an AI system under its authority, except where the system is used in the course of a personal non-professional activity. Recital 79 says a specific natural or legal person, defined as the provider, takes responsibility for placing a high-risk AI system on the market or putting it into service, regardless of whether that person designed or developed the system.

Neither test excludes the other. Provider status turns on responsibility for placing on the market or putting into service. Deployer status turns on use under one's authority. An organization that builds a system and then puts it into service for its own staff performs both acts. Recital 83 reinforces the consequence: operators along the AI value chain could act in more than one role at the same time and should fulfil cumulatively all relevant obligations associated with those roles. The recital's own example is an operator acting as both distributor and importer, so its application to provider and deployer is a reading of the general wording and should be confirmed against the Article 3 definitions.

The practical conclusion for compliance leaders is that role is determined per AI system and per act, not per organization. The same company can be only a deployer for a vendor's tool, and both provider and deployer for a system it built and runs. Holding both roles adds obligations without removing either set.

Scenarios that create a dual role

Article 25(1) sets out when a distributor, importer, deployer or other third party is considered a provider of a high-risk AI system and becomes subject to the provider obligations under Article 16. These triggers apply to systems already on the market or in service. Together with in-house development and use, they cover the cases that most often surprise regulated enterprises.

The third-party triggers matter because the organization usually starts as a deployer. It does not stop being one when the trigger occurs. It continues to use the system under its authority, and it now also carries provider obligations for that system.

• In-house development and use: The organization develops a system, puts it into service under its own responsibility and uses it internally. Both provider and deployer acts are present.
• Rebranding (Article 25(1)(a)): Putting its name or trademark on a high-risk system already on the market or in service. This is without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated.
• Substantial modification (Article 25(1)(b)): A substantial modification to a high-risk system already on the market or in service, made so that it remains high-risk under Article 6.
• Change of intended purpose (Article 25(1)(c)): Modifying the intended purpose of an AI system, including a general-purpose AI system, that was not classified as high-risk, so that it becomes high-risk under Article 6.

Mapping obligations to each role for high-risk systems

The table groups the duties that the Act's recitals and the European Commission's AI Act page attribute to each role. It is a mapping aid, not a full list of Article 16 or Article 26 duties. Where one organization holds both roles, every row applies and the two columns should be owned and evidenced separately.

• Before market or service: Provider: high-risk systems are subject to strict obligations before being put on the market, including adequate risk assessment and mitigation systems. Deployer: no equivalent pre-market duty, but use must follow the instructions of use.
• Use in line with instructions: Provider: supplies the instructions of use. Deployer: takes appropriate technical and organisational measures to use the system in accordance with those instructions. For a dual-role organization, the same document anchors both sides.
• Human oversight: Provider: not attributed as a runtime duty in this mapping. Deployer: ensures human oversight once the system is on the market.
• Monitoring: Provider: operates a post-market monitoring system. Deployer: monitors the functioning of the system in use.
• Record-keeping: Provider and deployer: record-keeping obligations apply as appropriate to each role, so use records and provider records should be kept distinguishable.
• Serious incidents and malfunctioning: Provider and deployer: both report serious incidents and malfunctioning. A dual-role organization needs one internal path that serves both reporting duties.

Operating model for dual-role systems

Start with an inventory of AI systems. For each one, record who developed it, who puts it into service, who uses it and whether it is high-risk. Without these four fields, role determination is guesswork, and the gaps usually appear as duplicated controls in one team and missing controls in another.

Add a change-control check for third-party systems that tests the three Article 25(1) triggers: rebranding, substantial modification of a high-risk system, and a change of intended purpose that makes a system high-risk. Define an internal test for what counts as a substantial modification and record each decision. Role changes should require approval, because a deployer that crosses a trigger becomes subject to Article 16 provider obligations.

Review upstream contracts. Article 25(1)(a) preserves contractual allocation of obligations for the rebranding trigger. Do not assume that a contract which allocates duties to a vendor still holds after you modify or repurpose the system.

For systems built and used in-house, assign named owners for provider-side and deployer-side obligations. Because recital 83 makes the obligations cumulative, one owner covering both sets without a documented split tends to leave the deployer side, such as oversight and use records, underserved. Record the legal basis for each role determination, and set a review trigger for changes in modification, branding or intended purpose.

Plan against 2 December 2027 for high-risk obligations, which is the date given on the European Commission's AI Act page as of November 2026, and recheck it as part of regular regulatory review.

Runtime enforcement and evidence on the deployer side

Deployer duties are exercised while the system is in use: following instructions of use, human oversight, monitoring and record-keeping. These are the duties that produce evidence continuously rather than at a single point in time. A design consideration, not a stated requirement of the Act, is to tie oversight and record-keeping controls to the system's documented instructions of use, since the Act frames deployer measures around those instructions.

For a dual-role system, keep two evidence sets. Provider-side records, such as post-market monitoring and incident reporting, should be separable from deployer-side records, such as use logs and oversight actions. A regulator or auditor can then be shown each role's evidence without reconstructing it from shared files.

Provider conformity duties, including the pre-market obligations, are not something a runtime control layer can evidence. They need their own documentation process. Runtime evidence addresses what the system was permitted to do and what it did while deployed.

Where Trussed fits

Trussed enforces policy in the execution path of AI interactions and tool calls, across models, agents, tools and MCP servers. Each action can be allowed, redacted, blocked, or escalated for human approval, and this is enforced at runtime, not reviewed after the fact. The escalation step gives deployers a concrete point at which human oversight is exercised and recorded.

That enforcement generates continuous, audit-ready evidence mapped to the EU AI Act, among other frameworks. For a dual-role organization, this supports the deployer-side obligations around use, oversight and record-keeping, and gives compliance teams per-system evidence of what the AI was allowed to do and what it did.

Trussed does not fulfil provider conformity duties, and it does not provide model or dataset provenance. Those remain with the organization acting as provider. Trussed can be self-managed in the customer cloud, with configurable retention and data residency.