Deployers of high-risk AI systems face eleven distinct obligations under the EU AI Act, including fundamental rights impact assessments, human oversight, monitoring, incident reporting, and log retention. While lighter than provider obligations, deployer non-compliance carries penalties of up to EUR 15 million or 3% of global turnover. Three circumstances can escalate a deployer to full provider status, triggering the complete AISDP requirement.
The guide is written primarily from the provider's perspective because the provider bears the principal AISDP obligation under Article 11.
The guide is written primarily from the provider's perspective because the provider bears the principal aisdp obligation under Article 11. Deployers face a different, lighter, but still consequential set of obligations. Article 3 defines the provider as the entity that develops an AI system or has one developed and places it on the market under its own name or trademark. The deployer is the entity that uses the system under its authority. Many organisations occupy both roles simultaneously: a bank that develops its own credit scoring AI is both provider and deployer. An employer that purchases a third-party recruitment screening tool is deployer only.
Article 26 imposes twelve distinct obligations on deployers.
Article 26 imposes twelve distinct obligations on deployers. The deployer must use the system in accordance with the Instructions for Use under Article 26(1), maintaining a record of IFU receipt and internal operating procedures aligned to the IFU. Human oversight must be assigned to competent persons under Article 26(2) and Article 14, with documented training records and override procedures. The system's operation must be monitored using provider guidance under Article 26(4), and use must be suspended if the system presents a risk under Article 26(5).
Deployers must inform the provider of serious incidents under Article 26(5) and report to the market surveillance authority under Article 73 where the provider is unreachable. A Fundamental Rights Impact Assessment must be conducted under Article 27 before putting the system into service, with results notified to the authority. Public authority deployers must register in the EU database under Article 49(3). AI literacy must be ensured for all staff involved in operation under Article 4. A DPIA must be conducted where required under GDPR Article 35. Automatically generated logs must be retained for at least six months under Article 26(6). The deployer must cooperate with competent authorities under Article 26(7).
Article 25(1) defines three circumstances in which a deployer's status escalates to that of a provider.
Article 25(1) defines three circumstances in which a deployer's status escalates to that of a provider. Rebranding occurs when a deployer offers a third-party system under its own commercial identity. Substantial modification occurs when a deployer makes a change affecting compliance or intended purpose, most commonly fine-tuning a GPAI model for a high-risk use case. Changing the intended purpose occurs when the deployer uses the system for a purpose outside the provider's documentation that makes it high-risk.
The escalation carries the full weight of provider obligations: full AISDP preparation, , Declaration of Conformity, CE marking, and EU database registration. Failing to recognise the escalation is itself a compliance violation. The Legal and Regulatory Advisor reassesses the organisation's status when the system is first put into service, annually, on deployment context changes, on provider updates, and on any modification to the organisation's own use.
The deployer compliance record follows an eight-module structure.
The deployer compliance record follows an eight-module structure. Module D1 covers system identification and provider reference. Module D2 documents intended purpose and deployment context. Module D3 contains the full FRIA under Article 27. Module D4 documents human oversight arrangements including training, override procedures, and break-glass procedures. Module D5 covers monitoring and incident response including log retention under Article 26(6). Module D6 addresses data protection including DPIA and data subject rights. Module D7 covers EU database registration for public authority deployers. Module D8 documents compliance review and maintenance with quarterly reviews.
Dual-role organisations that are both provider and deployer must satisfy both documentation sets. The AISDP addresses the provider's Article 11 obligations, and the deployer compliance record addresses the Article 26 obligations. In practice, the FRIA (Module D3) often reveals deployer-specific risks that the provider's risk assessment did not anticipate, because the deployer's operational context differs from the provider's documented intended purpose.
Eight items should be requested before putting the system into service and made contractual conditions of procurement.
Eight items should be requested before putting the system into service and made contractual conditions of procurement. The Declaration of Conformity, CE marking confirmation, and Instructions for Use are mandatory prerequisites; the system should not be deployed without them. The EU database registration reference, performance and fairness evaluation summary, serious incident reporting procedures, update and version management policy, and end-of-life policy complete the information requirements.
The procurement contract should address the provider's obligation to maintain current Instructions for Use, notification of updates, cooperation with the deployer's FRIA including disaggregated performance and fairness data, participation in serious incident investigations, allocation of liability, and consequences of provider insolvency. Where the provider refuses any item, the deployer records the gap in Module D8, assesses whether it prevents fulfilment of obligations, and documents the decision.
Deployer readers who require a self-contained reference should consult the Deployer and Operator Handbook directly.
Deployer readers who require a self-contained reference should consult the Deployer and Operator Handbook directly. For deployers who want to understand the broader compliance context, the cross-reference map traces each deployer obligation to the guide sections providing detailed guidance. Risk assessment covers the classification framework and FRIA methodology. Data governance covers GDPR alignment and special category data handling. Post-market monitoring covers deployer monitoring responsibilities, serious incident reporting, and data retention. Operational oversight covers the deployer oversight pyramid, operator training, and break-glass procedures.
No. The provider's Article 9 risk assessment addresses engineering risks; the deployer's FRIA under Article 27 assesses impact on affected persons' fundamental rights in the deployer's particular deployment context. Both are required and serve different purposes.
Commission an independent evaluation of the system's outputs using the deployer's own operational data. Document the provider's refusal and the independent evaluation methodology in the FRIA module. Consider whether the gap prevents a meaningful FRIA and whether the deployment decision should be reconsidered.
Generally no. Adjustments within ranges specified in the Instructions for Use, selecting pre-defined configuration options, or applying the system to a new dataset within its documented intended purpose are deployer-level activities. The distinction turns on whether the change affects compliance or modifies the intended purpose.
At initial deployment, annually, whenever the deployment context changes, whenever the provider updates the system, and whenever the organisation modifies its own use. Each reassessment should be documented with reasoning and conclusions.
Activate contractual escrow arrangements for technical documentation. If unavailable, document the system's last known configuration, assess whether continued use is lawful without provider support, begin transition planning, and notify the market surveillance authority if the system remains in service.
The provider develops the AI system and places it on the market; the deployer uses it under its authority. Providers prepare the full AISDP; deployers prepare a lighter compliance record.
Article 25 defines three circumstances that escalate a deployer to full provider status: rebranding, substantial modification, or changing the intended purpose.
A deployer who only uses a system supplied by a separate provider does not prepare a full AISDP. The provider prepares the AISDP; the deployer prepares a separate, smaller set of deployer-side documentation in the deployer compliance record. Where the organisation is both provider and deployer, it must satisfy both sets of obligations, and the AISDP must address both perspectives.
Deployers do not always procure AI systems directly from the provider. Importers under Article 23 are entities established in the EU placing a third-country provider's system on the EU market, verifying that the provider has completed the conformity assessment and affixed CE marking. Distributors under Article 24 make the system available without modification, verifying CE marking and the Declaration of Conformity. Third-country providers must appoint an authorised representative under Article 22 who maintains the technical documentation and cooperates with competent authorities.
The Deployer and Operator Handbook provides a comprehensive standalone guide covering every deployer obligation, the compliance record structure, FRIA methodology, the deployer oversight pyramid, break-glass procedures, monitoring, incident reporting, and portfolio management.
Each obligation carries penalty exposure reaching EUR 15 million or 3 per cent of global annual turnover. The most likely enforcement triggers in practice are failure to conduct the FRIA before deployment, inadequate human oversight, failure to report serious incidents, and use outside the documented intended purpose.
The guide's domain sections are written from the provider's perspective but include deployer-specific guidance at each relevant point, ensuring that deployers can find the guidance they need within the broader compliance framework while the handbook provides the standalone reference.
CTO of Standard Intelligence. Leads platform engineering and contributes to the PIG series technical content.
Eleven obligations including FRIA, human oversight, monitoring, incident reporting, AI literacy, log retention, and cooperation with authorities under Articles 26, 27, and 4.
When they place the system on the market under their own name, make a substantial modification, or use it for a purpose outside the documented intended purpose that makes it high-risk.
An eight-module deployer compliance record covering system identification, intended purpose, FRIA, human oversight, monitoring, data protection, registration (public authorities), and compliance review.
Up to EUR 15 million or 3% of global turnover for obligation failures, and EUR 7.5 million or 1% for providing incorrect information to authorities.
Declaration of Conformity, CE marking, Instructions for Use, performance and fairness data, incident reporting procedures, update policy, and end-of-life policy, ideally as contractual conditions.
Deployer obligations are addressed within the provider AISDP, with the FRIA as the most significant additional requirement requiring genuine separation from the Article 9 engineering risk assessment.
Almost always yes. Fine-tuning a GPAI model for a high-risk use case typically changes the intended purpose, constituting a substantial modification that triggers provider status under Article 25(1)(b).
