The Provider-Deployer Distinction and Boundary Cases

Article 25(1) defines three circumstances in which a deployer's status escalates to that of a provider, and the consequences are severe. The organisation must prepare a full aisdp, conduct a conformity assessment, sign a Declaration of Conformity, affix CE marking, and register in the EU database. Failing to recognise the escalation is itself a compliance violation under Article 99.

The first trigger is rebranding. If a deployer rebrands a third-party AI system and offers it to others under its own commercial identity, it becomes the provider. The test is whether end users or downstream deployers would reasonably understand the organisation to be the entity responsible for the system. This catches white-labelling arrangements, reseller models, and platform integrations where the procured system is presented to customers as the organisation's own product.

The second trigger is substantial modification. Article 25(1)(b) treats a deployer who makes a substantial modification to a high-risk system as its provider. A substantial modification under Article 3(23) is a change that affects the system's compliance with the Act's requirements or modifies the intended purpose. The most common trigger in practice is fine-tuning a general-purpose AI model for a specific high-risk use case. Adapting a general-purpose language model for recruitment screening or credit assessment almost always changes the model's intended purpose, crossing the provider boundary.

Not every configuration change constitutes a substantial modification. Adjusting decision thresholds within ranges specified in the Instructions for Use, selecting from pre-defined configuration options, or applying the system to a new dataset within its documented intended purpose are generally deployer-level activities that do not trigger provider status.

The third trigger is changing the intended purpose. If a deployer uses the system for a purpose that differs from the one documented by the provider, and the new purpose causes the system to become high-risk, the deployer becomes the provider for that new use. The provider's conformity assessment and Declaration of Conformity do not cover uses outside the documented intended purpose. This trigger is particularly relevant for organisations that procure general-purpose tools and adapt them to specific regulatory domains.

The Legal and Regulatory Advisor reassesses the organisation's relationship with each AI system against the three escalation criteria at five defined points: when the system is first put into service, annually as a routine compliance review, whenever the deployment context changes, whenever the provider updates the system, and whenever the organisation modifies its own use of the system. Each assessment is documented with the reasoning and conclusion, creating an audit trail that demonstrates ongoing awareness of the boundary.

The assessment follows a decision tree. Does the organisation develop the system or have it developed? If yes, it is a provider. Is the system placed on the market under the organisation's own name or trademark? If yes, it is a provider. Has the organisation made a substantial modification? If yes, it is a provider. Is the system used for a purpose outside the provider's documented intended purpose? If yes, and the new purpose causes the system to be high-risk, it is a provider. If none of these apply, the organisation is a deployer and prepares the deployer compliance record.

The practical configurations illustrate how this analysis applies. When a bank develops its own credit scoring model, it holds both provider and deployer roles simultaneously, requiring a full AISDP and a deployer FRIA. When a hospital procures a diagnostic imaging tool from an EU vendor, the hospital is deployer only. When a recruitment agency licenses a US-built CV screening tool through a UK importer, the US developer is the provider, the UK importer verifies compliance, and the agency as deployer directs information requests to the authorised representative. When an insurer fine-tunes a foundation model for claims fraud detection, the fine-tuning triggers provider status.

The deployer's compliance depends on information only the provider can supply. Eight items should be requested before the system is put into service and made contractual conditions of procurement.

The Declaration of Conformity under Article 47 confirms the conformity assessment is complete. CE marking confirmation under Article 48 provides visual confirmation of conformity. The Instructions for Use under Article 13 define the intended purpose, limitations, oversight requirements, and monitoring guidance. For these three items, if the provider refuses to supply them, the deployer should not put the system into service, as deployment without them creates immediate non-compliance exposure.

The EU database registration reference under Article 49 verifies registration status; if the provider refuses, the deployer can search the database directly. A performance and fairness evaluation summary under Articles 9 and 10 is required for an informed FRIA; if refused, the deployer commissions an independent evaluation and documents the gap. Serious incident reporting procedures under Article 73 ensure the deployer knows how to report incidents; if refused, the deployer establishes a direct channel to the market surveillance authority.

An update and version management policy under Articles 12 and 18 ensures the deployer knows when changes occur and their compliance impact; the contract should require advance notification with a minimum notice period. An end-of-life policy under Article 18 enables transition planning; the contract should require twelve-month minimum notice of discontinuation.

The procurement contract should address six key areas to protect the deployer's ability to maintain compliance throughout the system's operational life. The provider's obligation to supply and maintain current Instructions for Use must be explicit, as the IFU is the foundation of the deployer's monitoring and oversight activities.

Notification of updates and changes ensures the deployer is not surprised by system modifications that could affect its compliance posture or trigger a new FRIA. Cooperation with the deployer's FRIA, including supply of disaggregated performance and fairness data broken down by protected characteristic subgroups, is essential because the deployer cannot conduct a meaningful impact assessment without information about how the system performs for different populations.

Participation in serious incident investigations ensures the provider supports the deployer when incidents occur, providing technical analysis and evidence that the deployer cannot produce independently. Allocation of liability for non-compliance addresses who bears responsibility when the system fails to meet the Act's requirements, particularly in situations where the failure arises from the provider's component rather than the deployer's use.

Consequences of provider insolvency or acquisition, including documentation escrow arrangements, protect the deployer against the scenario where the provider ceases to exist. Without escrow, the deployer may lose access to the technical documentation, the Instructions for Use, and the support infrastructure on which its compliance depends.

Where the provider refuses or is unable to supply any listed item, the deployer records the gap in Module D8 of the deployer compliance record and assesses whether the gap prevents it from fulfilling its own obligations. The decision and its reasoning are documented as evidence of the deployer's good faith compliance effort.