EU AI Act obligations for deployers (not just providers)

The EU AI Act defines a deployer as any natural or legal person, public authority, agency, or other body that uses an AI system under its authority, except where the AI system is used in the course of a personal, non-professional activity.

In practical terms, this covers the vast majority of enterprise uses of AI:

• An HR department using an AI-powered recruitment screening tool purchased from a vendor
• A financial services firm using a credit scoring model from an external provider
• A hospital using an AI diagnostic support tool supplied by a medical technology company
• A logistics company using an AI route optimisation system
• A government agency using an AI benefits eligibility assessment tool

The deployer is not the organisation that built the AI system. The deployer is the organisation that uses it — typically in its own operational context, with its own users, to make or influence decisions affecting its own employees, customers, or service recipients.

The EU AI Act creates a clear structural distinction between providers and deployers with different obligation profiles for each. A provider is the organisation that develops an AI system, places it on the market, or puts it into service under its own name or trademark. A deployer is the organisation that uses a system developed and placed on the market by a provider.

This distinction is clearest when an organisation buys a software product from a vendor. The vendor is the provider; the buying organisation is the deployer. The vendor must satisfy the high-risk provider obligations (Articles 9–15, Annex IV). The buying organisation must satisfy the deployer obligations (Article 26).

The provider/deployer distinction is clean in theory and messy in practice. The key question is: who is responsible for the design decisions that determine the system's risk profile? That organisation bears provider obligations, regardless of how the commercial relationship is structured.

Article 26 of the EU AI Act defines the obligations of deployers of high-risk AI systems. These obligations are narrower than the provider obligations in Articles 9–15, but they are substantive and require documented evidence.

The deployer/provider boundary shifts when a deployer makes a substantial modification to a high-risk AI system. Under Article 25(1), a natural or legal person that modifies a high-risk AI system already placed on the market or put into service in a way that constitutes a substantial modification shall be considered a provider for that modification.

A substantial modification is defined as a change that affects the system's compliance with the high-risk obligations — changes that alter the system's intended purpose, performance level, or risk profile in a way that would require re-assessment of conformity if it were a new system.

The scenarios most likely to trigger this are:

• Fine-tuning on proprietary data— taking a foundation model and fine-tuning it on the organisation's own data for a high-risk use case. The fine-tuned model has a different risk profile from the base model.
• Expanding intended purpose— using a system for a purpose different from what the provider's instructions for use specify, particularly if the new purpose falls within a different Annex III category.
• Integrating into a new pipeline — embedding the system into an agentic pipeline or combining it with other systems in a way that changes the risk profile of the combined output.

Even without making a substantial modification, deployers of high-risk systems must assess whether their specific use case falls within the intended purpose of the system as defined by the provider. This is a more substantive exercise than reading the vendor documentation — it requires actively comparing the provider's intended purpose definition against the deployer's actual use.

The use-case assessment for a deployer covers:

1. Intended purpose alignment— does the way the organisation uses the system match the intended purpose as stated in the provider's instructions for use?
2. Scope creep check — has the system been used beyond its documented intended purpose by business units or individual users? Scope creep is one of the most common deployer compliance failures.
3. Substantial modification threshold — have any modifications been made to the system (configuration, fine-tuning, integration) that could constitute a substantial modification requiring reclassification?
4. Population exposure— are the populations affected by the system's outputs the same as those anticipated by the provider, or has the deployer extended the system to affect different or additional groups?

Article 26(1) requires deployers to implement appropriate technical and organisational measures to ensure the system is used as intended. The regulation does not specify what those measures must look like — they must be proportionate to the system's risk profile and the deployer's operational context.

Practical technical and organisational measures for deployers of high-risk AI systems typically include:

• User training on the system's capabilities and limitations, including known failure modes
• Access controls that restrict who can operate the system to those who have completed training
• Operational procedures defining how outputs are reviewed before decisions are made
• A mechanism for users to flag system outputs that appear incorrect or anomalous
• A review process for decisions made using system outputs, including a clear override pathway
• A record of decisions made using system outputs, sufficient to reconstruct the basis for each decision

These measures must be documented and must demonstrably exist in practice — not only in a policy document. The evidence requirement is that the measures are implemented and that there is a way to verify that they work.

Article 26(5) requires deployers to notify the provider and the relevant market surveillance authority when a serious incident is identified or when the system malfunctions. A serious incident is defined as an incident that results in or may result in death, serious injury, serious damage to property, or a significant disruption to critical infrastructure.

The reporting obligation has a practical implication: deployers must have an incident identification and reporting process that connects AI system operation to incident management. AI-related incidents must be identifiable as AI-related in the incident management system, and there must be a defined pathway for escalation to the provider and the relevant authority.

This connects to the broader AI incident response question — see our AI incident response playbook guide for the specific elements that AI incident playbooks require that standard IT playbooks miss.

Deployers of high-risk AI systems must be able to produce documentary evidence of their Article 26 obligations on request from a market surveillance authority. The minimum evidence set is:

• Use-case assessment— the documented rationale for why the system's deployment aligns with the provider's intended purpose and does not constitute a substantial modification.
• Technical and organisational measures — the documented TOMs, with evidence that they are implemented and operational.
• Human oversight assignment — the names and roles of individuals assigned human oversight responsibility, with their documented authority and access.
• Monitoring plan — the documented plan for monitoring the system for adverse effects, with the review cadence and escalation procedure.
• Incident log — the record of any incidents identified, with the steps taken and whether the provider was notified.

For systems where the organisation is both provider and deployer — internally developed high-risk AI — the full provider evidence set (Articles 9–15, Annex IV) must also exist, in addition to the deployer evidence described above.