The EU AI Act for deployers. A complete operator orientation.

This guide is addressed to deployers: organisations that use AI systems built or supplied by someone else. It covers every obligation in Regulation (EU) 2024/1689 that applies to deployers in their own right, in the sequence those obligations arise across the deployer journey. The liability chain, enforcement architecture, and insurance market are covered at the end.

Who is a deployer under Regulation (EU) 2024/1689?

Article 3(4) 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 system is used in the course of a personal non-professional activity. The definition is broad by design. A hospital using a third-party diagnostic AI tool is a deployer. A bank integrating a credit-scoring model into its loan origination workflow is a deployer. A recruitment platform feeding CVs into an AI ranking system is a deployer. The provider who built the underlying model and the distributor who resells access to it occupy different positions in the chain, with different obligations.

Where a deployer substantially modifies an AI system after it leaves the provider, that deployer may be reclassified as a provider under Article 25(1)(d). The threshold for "substantial modification" is not a bright line in the regulation, but the AI Office's guidance treats changes to the intended purpose, changes to training data, and architectural changes as the clearest indicators. A deployer who fine-tunes a foundation model on proprietary data and deploys the result for a purpose outside the original provider's intended scope has likely crossed the threshold. For a detailed analysis of the liability chain, see the provider-deployer liability chain analysis.

Layer one: obligations that apply to all deployers from 2 February 2025

Article 4: AI literacy

Article 4 requires deployers to take measures to ensure a sufficient level of AI literacy among their staff and other persons who operate AI systems on their behalf. The article does not prescribe a specific curriculum or examination. It requires proportionate measures, meaning the literacy standard must match the complexity and risk level of the AI systems the organisation deploys.

In practice, Article 4 compliance requires a training inventory that maps each AI system in use to the staff roles that operate it, plus a training programme matched to those roles, plus records showing who completed what and when. For organisations deploying high-risk systems, the literacy baseline for oversight staff feeds directly into the Article 26(2) requirement that oversight persons have the necessary competence and training. The two obligations are complementary and should be built as one programme rather than two separate workstreams. See the detailed analysis at Article 4: AI literacy deployer obligations.

Article 5: Prohibited practices

Article 5 is the most consequential provision in the regulation for any deployer who is considering or currently using AI for purposes that the legislature deemed incompatible with fundamental rights. The prohibited practices include: AI systems that deploy subliminal techniques to manipulate behaviour without the person's awareness; AI that exploits vulnerabilities of specific groups; social scoring by public authorities; real-time remote biometric identification in publicly accessible spaces by law enforcement (with narrow exceptions); biometric categorisation inferring sensitive characteristics from biometric data; and retrospective remote biometric identification for law enforcement except in the most serious defined circumstances.

These prohibitions carry the highest penalty tier in Article 99: up to EUR 35 million or 7 per cent of worldwide annual turnover. They apply to deployers as well as providers. A deployer who uses a system that meets any Article 5 definition, regardless of whether the provider disclosed this or the deployer realised it, is in violation of Article 5. The prohibition check is therefore the first obligation any deployer must complete before any other step in the compliance programme. The full catalogue of prohibited uses with sector examples is in the Article 5 prohibited practices guide.

Layer two: classification and the high-risk threshold

Article 6 and Annex III: is the system high-risk?

Classification is the pivot on which the entire compliance burden turns. Article 6 establishes two routes to high-risk status. The first route, Article 6(1), covers AI systems that are safety components of products already regulated under specific EU product safety legislation listed in Annex I, or that are themselves such products and subject to conformity assessment by a third party. The second route, Article 6(2), covers AI systems whose intended purpose corresponds to one of the use cases listed in Annex III.

Annex III contains eight categories: biometric identification and categorisation; critical infrastructure management and operation; education and vocational training; employment, workers management, and access to self-employment; access to and enjoyment of essential private services and public services and benefits; law enforcement; migration, asylum, and border control management; and administration of justice and democratic processes.

Within each category, the specific use cases that qualify as high-risk are defined by function. Under the employment category, Annex III(4) covers AI used for recruitment or selection, evaluation during the lifetime of an employment relationship, and promotion decisions. A deployer using AI to rank job applicants falls within this category. A deployer using AI to draft a job posting, with no AI involvement in the selection decision, does not. Classification requires careful mapping of the system's actual function against the Annex III definitions, not a surface-level category match. The sector-by-sector classification guide is at the Annex III high-risk categories guide, and the Article 6 classification rules are analysed in detail at the Article 6 classification guide.

Layer three: the high-risk compliance requirements (Articles 9 to 15)

Articles 9 to 15 set out the technical and organisational requirements that high-risk AI systems must meet. These requirements are primarily addressed to providers, but deployers engage with them through the duty to verify that the provider has satisfied them before deploying the system, and through the deployer-specific obligations in Article 26 that build on the provider's work.

Article 9: Risk management system

Article 9 requires a continuous, iterative risk management system throughout the lifecycle of a high-risk AI system. The system must identify and analyse known and foreseeable risks; estimate and evaluate risks that may emerge in actual use conditions; and evaluate risks in the context of the specific use population, including groups that may be disproportionately affected. Risk management under Article 9 is not a one-time assessment. It must be updated in response to operational data generated during deployment.

For deployers, the Article 9 obligation translates into two concrete requirements. First, the deployer must verify that the provider has a documented risk management system that covers the deployer's intended use. A risk management system calibrated for a different use case or deployment population does not satisfy Article 9 for the deployer's context. Second, the deployer must maintain its own operational risk monitoring that feeds back into the provider's system where possible, and informs the deployer's own FRIA where the Article 26(9) obligation applies. See the Article 9 risk management system guide for the operational translation.

Article 10: Data governance

Article 10 sets governance requirements for the training, validation, and testing data used in high-risk AI systems. Deployers who provide their own data to a provider for system training, or who fine-tune a system on proprietary data, take on data governance responsibilities that can push them toward provider-equivalent status under Article 25. Even deployers who use a system without modifying its training data must understand the data governance practices of their provider, because the Article 26(1) duty to use the system in accordance with the instructions for use requires knowing the conditions under which the system was tested and validated. See the Article 10 data governance analysis for the deployer-facing implications.

Articles 11 and 17: Technical documentation

Article 11 requires providers to prepare technical documentation as set out in Annex IV before putting a high-risk AI system on the market. Article 17 requires providers to maintain a quality management system that includes technical documentation maintenance. For deployers, these articles matter because the deployer's right to verify the provider's compliance depends on access to this documentation. The supply contract should include a right to request and inspect the technical documentation relevant to the deployer's use case. See the Article 11 analysis at technical documentation for high-risk AI and the Article 17 analysis at Article 17 deployer-facing obligations.

Article 12: Logging and recordkeeping

Article 12 requires high-risk AI systems to have automatic logging capabilities that record events relevant to identifying risks and to any modification of the system throughout its lifecycle. The Article 12 requirement operates at the design level: providers must build logging in. Article 26(7) then requires deployers to retain those logs. The two obligations are complementary but distinct. A deployer whose provider supplies a system without adequate logging is in a difficult position: the deployer may not be able to satisfy Article 26(7) for records that were never generated. Supply contracts should include explicit representations from providers about logging capability and the format, retention, and access rights for those logs. The practical recordkeeping obligations are mapped at the Article 12 logging analysis.

Article 13: Transparency and instructions for use

Article 13 requires high-risk AI systems to be transparent enough that deployers can understand the system's capabilities and limitations and use it appropriately. The practical output of Article 13 is the instructions for use, a statutory document that providers must supply and deployers must act on. The instructions define the deployment conditions, the expected performance, the known limitations, the oversight requirements, and the maintenance obligations. They are the legal baseline against which Article 26(1) compliance is measured. The full transparency obligation is examined at the Article 13 transparency analysis.

Article 14: Human oversight

Article 14 requires high-risk AI systems to be designed and developed with built-in human oversight capabilities: the ability to understand outputs, detect anomalies, override or halt the system, and intervene before the system acts. Article 14 is a design requirement addressed to providers. But it creates the technical floor on which the Article 26(2) staffing requirement rests. A deployer cannot satisfy Article 26(2) by assigning oversight persons if the system itself lacks the Article 14 capabilities those persons need to exercise oversight. Deployers should verify Article 14 compliance as part of procurement due diligence. See the Article 14 human oversight analysis.

Article 15: Accuracy, robustness, and cybersecurity

Article 15 sets performance baselines for high-risk AI systems: levels of accuracy, robustness to error, and resilience to adversarial attack that must be specified by providers in technical documentation. Deployers engage with Article 15 through three channels: verifying provider compliance before deployment; monitoring for accuracy and robustness degradation during operation under Article 26(3); and notifying providers when operational performance deviates materially from the documented baselines under Article 26(4). The Article 15 obligations are analysed at the Article 15 accuracy and robustness guide.

Layer four: Article 26, the deployer duty-set

Article 26 is the article addressed directly and exclusively to deployers. It consolidates eight categories of obligation that no provider can satisfy on the deployer's behalf. A detailed provision-by-provision reading is at the complete Article 26 deployer obligations guide. The summary below maps each paragraph to the document it requires.

Article 26(1): Instructions compliance

Deployers must take appropriate technical and organisational measures to ensure they use high-risk AI systems strictly in accordance with the provider's instructions for use. Document required: an instructions compliance record confirming receipt, review, and operational implementation of the instructions, covering access controls, use-case constraints, and any further requirements the instructions specify.

Article 26(2): Human oversight staffing

Deployers must assign oversight of the high-risk AI system to natural persons with the necessary competence, training, authority, and support to exercise the Article 14 oversight capabilities. Document required: an oversight register naming the assigned persons, their qualifications, their access rights to the oversight interface, and the escalation path to a person authorised to halt the system.

Article 26(3): Monitoring operation

Deployers must monitor the operation of the system on the basis of the instructions for use, checking whether performance in actual deployment remains consistent with documented specifications. Document required: a monitoring procedure specifying indicators tracked, monitoring frequency, escalation thresholds, and the log of monitoring results.

Article 26(4) and (5): Notification obligations

Article 26(4) requires deployers to notify providers when they have reason to believe the system presents a risk. Article 26(5) requires deployers to report serious incidents to the relevant national market surveillance authority without undue delay. Document required: an incident log and a defined escalation and notification procedure with named contact points at the provider and the relevant authority. Failure to notify a serious incident falls within the second penalty tier: up to EUR 15 million or 3 per cent of turnover.

Article 26(7): Log retention

Deployers must retain automatically generated logs for the period specified by applicable law, or a minimum of six months where no specific law applies. Where a cloud provider retains logs, the deployer must have contractual confirmation of retention obligations and access rights. Document required: a log retention policy and written confirmation from the provider of their retention practices.

Article 26(8): Informing affected persons

Deployers must inform natural persons who are subject to a high-risk AI system's output that they are interacting with such a system where the decision is consequential for them. This provision operates in parallel with Article 50 transparency requirements and GDPR Article 22 obligations. Document required: a person-notification procedure integrated into the relevant operational workflows, such as hiring, credit decisioning, or benefits assessment.

Article 26(9): Fundamental rights impact assessment

Public-body deployers and private deployers operating in credit, insurance, employment, or essential services must conduct a fundamental rights impact assessment before first use of a high-risk AI system. The FRIA must be updated on any material change to the system, use case, or affected population. Document required: a completed FRIA meeting the Article 27 content requirements. See the full FRIA procedural guide at the Article 27 FRIA guide, and the countdown checklist at the 90-day FRIA countdown.

Article 26(10): Database registration

Deployers of remote biometric identification systems and public-authority deployers of other Annex III systems must register their deployment in the EU database managed by the AI Office under Article 71 before first use. Registration information is defined in Annex VIII. Document required: a database registration confirmation with the assigned reference number.

Article 27: Fundamental rights impact assessment procedure

Article 27 specifies the content and procedure for the FRIA required under Article 26(9). The assessment must include: a description of the system and its intended purpose; the categories of natural persons and groups affected; the specific fundamental rights at risk; the data used and its sources; a description of the deployer's implementation in the specific organisational context; the foreseeable risks to fundamental rights; and the measures taken to mitigate those risks. The FRIA must be submitted to the relevant market surveillance authority if requested. For deployers in the financial services or insurance sectors, EIOPA's opinion on AI governance published in August 2025 signals supervisory expectations that align closely with the Article 27 content requirements. See the Article 27 FRIA guide and the EIOPA opinion analysis.

Article 50: Transparency and labelling obligations

Article 50 creates transparency obligations that apply to deployers regardless of whether their system is high-risk. The key obligations for deployers are: systems that interact with natural persons as chatbots or conversational agents must be disclosed as AI systems unless the human is aware and has consented to the interaction; deepfake content must be labelled; emotion recognition and biometric categorisation systems must disclose their function to persons subjected to them.

Article 50 obligations became enforceable on 2 August 2025 and are not affected by the Digital Omnibus deferral. Deployers who have not yet implemented chatbot disclosure and deepfake labelling are in violation of Article 50 now. The full analysis of Article 50 obligations and the practical implementation requirements is at the Article 50 transparency and labelling guide.

Articles 72 and 73: Post-market monitoring and incident reporting

Article 72: Post-market monitoring

Article 72 requires providers to establish post-market monitoring systems that collect and analyse data from deployers about performance in real-world conditions. For deployers, Article 72 creates an obligation to cooperate with the provider's monitoring system by sharing operational data as required. A deployer who does not have a contractual or technical mechanism for this data-sharing has a gap in their Article 26(3) monitoring architecture as well as a potential obstruction of the provider's Article 72 system. See the Article 72 post-market monitoring guide.

Article 73: Serious incident reporting to authorities

Article 73 establishes the obligation for deployers to report serious incidents to the relevant market surveillance authority. A serious incident is defined in Article 3(49) as any incident or malfunction that leads or may lead to death, serious injury, or serious adverse effects on health, safety, or fundamental rights. The "may lead to" formulation means the reporting obligation is triggered by credible risk of these outcomes, not only by realised harm. Failure to report is a second-tier Article 99 violation. The practical implementation of an incident detection, triage, and reporting procedure is at the Article 73 incident reporting guide.

Article 86: Right to explanation

Article 86 gives natural persons the right to obtain an explanation from the deployer when a high-risk AI system has been used to make or substantially influence a decision that affects them significantly. The deployer must be able to provide a meaningful explanation of the role the AI system played in the decision. This obligation runs alongside, but is not identical to, the GDPR Article 22 right not to be subject to solely automated decisions and the right to meaningful information about the logic involved. Deployers need a procedure for responding to Article 86 requests that distinguishes them from GDPR subject access requests while satisfying both. The scope and limits of Article 86 are examined at the Article 86 right to explanation guide.

General-purpose AI models: Articles 51 to 56

Where a deployer builds an application on top of a general-purpose AI model (GPAI model), the deployer is exposed to obligations that flow from the model provider's classification under Articles 51 to 56. GPAI models with systemic risk carry enhanced obligations for their providers. For deployers, the key exposure is that a GPAI model may be repurposed into a high-risk application by the deployer's integration choices, triggering Article 25(1) provider-equivalent obligations. The deployer exposure arising from GPAI models is examined at the GPAI models deployer exposure analysis.

Conformity assessment under Article 43

Article 43 sets out the conformity assessment procedures that high-risk AI systems must undergo before being placed on the market. For most Annex III systems, this is a self-assessment by the provider with the support of a notified body for specified categories. Deployers do not conduct conformity assessments, but they must verify that the system carries a CE mark and an EU declaration of conformity before deployment, and must request the relevant documentation. The deployer who uses a high-risk system that has not completed conformity assessment is deploying a non-compliant system, which is itself a regulatory violation regardless of the system's actual performance. See the Article 43 conformity assessment guide for the verification procedure.

Enforcement architecture: national supervisors and the AI Office

The enforcement architecture for the EU AI Act distributes supervisory authority across two levels. At the European level, the AI Office, established within the European Commission under Article 64, supervises GPAI models and co-ordinates enforcement across member states. At the national level, each member state must designate one or more national competent authorities to serve as market surveillance authorities for AI systems used in their territory.

The major national supervisors relevant to deployers in the largest EU markets include: a German federal authority for artificial intelligence, under formation as of 2026; the Dutch Authority for Digital Infrastructure (Rijksinspectie Digitale Infrastructuur) for AI market surveillance in the Netherlands; the French national authority being designated under the ACPR and CNIL frameworks; and the UK's AI Safety Institute (AISI), which covers the UK market under UK regulations transposing elements of the AI framework rather than the EU regulation itself. For the national supervisor landscape, see the national supervisors analysis and the enforcement architecture overview at the enforcement architecture guide.

Member state transposition progress varies. Several member states had not yet published their national implementing measures as of June 2026. The current transposition status across EU member states is tracked at the member state transposition tracker.

Article 99: Penalties

Article 99 establishes administrative fines applicable to violations of the EU AI Act. Three tiers apply.

The first and highest tier, up to EUR 35 million or 7 per cent of worldwide annual turnover (whichever is higher), applies to violations of Article 5 prohibited practices and to placing non-compliant AI systems on the market in breach of Article 5. This is the tier that captures deployers who use AI for social scoring, prohibited biometric identification, or manipulation practices.

The second tier, up to EUR 15 million or 3 per cent of worldwide annual turnover, applies to most other regulatory violations by deployers: failure to maintain required documentation, failure to report serious incidents, failure to conduct a FRIA where required, failure to implement human oversight as required, and failure to cooperate with supervisory authorities.

The third tier, up to EUR 7.5 million or 1 per cent of worldwide annual turnover, applies to providing incorrect, incomplete, or misleading information to notified bodies or national competent authorities.

All three thresholds are halved for SMEs and start-ups. The supervisory authority has discretion to calibrate fines proportionately to the severity, duration, and intent of the violation, the degree of cooperation, and the size of the organisation. A well-documented compliance programme that demonstrates good-faith effort will be a material factor in enforcement proceedings.

The Product Liability Directive and double exposure

Directive (EU) 2024/2853, the revised Product Liability Directive, came into force in December 2024 and must be transposed by member states by December 2026. It extends strict product liability to software and AI systems, treating them as products for the purposes of liability for damage caused by defects. For deployers, the Directive creates exposure in two circumstances.

The first is where the deployer substantially modifies an AI system after it left the provider's control. In this case, the deployer may be treated as a manufacturer under the Directive and bear strict liability for defects introduced by or resulting from that modification. This is the same threshold that may trigger Article 25(1)(d) provider-equivalent status under the EU AI Act.

The second is where the deployer distributes a service that integrates a defective AI system and the deployer's integration is causally linked to the damage. The Directive uses a rebuttable presumption approach: certain failures in the documentation or traceability chain create a presumption of defect, which the defendant must rebut. A deployer who cannot produce the Article 26 compliance documentation is poorly positioned to rebut this presumption.

The Directive and the EU AI Act can apply to the same incident simultaneously. An AI system that causes bodily harm may trigger strict liability under the Directive and supervisory penalty proceedings under Article 99 of the AI Act, plus regulatory action under any sector-specific law. For the interaction between these instruments, see the double-exposure analysis and the standalone Product Liability Directive guide for AI software deployers.

The Digital Omnibus deferral

On 7 May 2026, the European Parliament and the Council reached a provisional political agreement on the Digital Omnibus on AI, a package that proposes to defer the application of the high-risk AI obligations in the EU AI Act from 2 August 2026 to 2 December 2027. The Omnibus covers Articles 9 to 15 and Article 26, the FRIA obligation under Article 26(9), and the conformity assessment requirements under Article 43.

The deferral is not yet formally adopted. Until the Omnibus text is published in the Official Journal of the European Union, the original 2 August 2026 date remains the legally operative deadline. Deployers who have built compliance programmes around the August date should not stand those programmes down on the basis of a provisional political agreement. The legal risk of assuming the deferral will occur before it is formally confirmed is higher than the cost of maintaining a programme that turns out to have a longer runway than initially expected.

The prohibitions in Article 5 and the transparency obligations in Article 50, already in force, are not affected by the Omnibus. The detailed Omnibus analysis, including which articles are and are not affected, is at the Digital Omnibus Master Brief.

The liability chain from provider to deployer

The EU AI Act distributes obligations across the supply chain. The provider is responsible for design, training, conformity assessment, and technical documentation. The deployer is responsible for implementation, oversight, monitoring, and incident reporting. Where the two overlap, the regulation specifies which party bears the primary obligation and which has a derivative role. Where a deployer acts outside the provider's instructions, the deployer assumes responsibility for the consequences of that deviation.

The chain is not a clean handoff. A provider who supplies inadequate instructions shifts some practical risk onto the deployer who cannot satisfy Article 26(1) despite acting in good faith. A deployer who uses a system in a context not covered by the provider's conformity assessment may be operating a non-conforming system. These overlaps require that the supply relationship, including the contract, the technical documentation, and the operational procedures, is designed as a shared compliance architecture rather than a liability-transfer mechanism.

For the complete analysis of where responsibility lies at each link in the chain, see the provider-deployer liability chain analysis and who is liable when an AI agent makes a mistake.

Insurance and the compliance documentation connection

The specialist AI liability insurance market has developed products that respond to the gap between the compliance obligations in the EU AI Act and the coverage available under standard professional indemnity or technology E&O policies. Products from Munich Re (aiSure), Armilla AI, Lloyd's market syndicates, Counterpart, and the AI Underwriting Consortium (AIUC) each address different segments of the risk. Coverage terms, exclusions, and underwriting criteria vary significantly across carriers and are evolving as loss experience accumulates, and current product availability, terms, and carrier participation should be confirmed with underwriters directly before purchase.

The structural insight is that the documentation required by Article 26, and the documentation an underwriter needs to assess an AI liability risk, are substantially the same records. A risk management system under Article 9, an incident log under Article 26(5), a FRIA under Article 26(9), and a monitoring procedure under Article 26(3) are exactly the records an underwriter uses to evaluate the deployer's governance posture. Deployers who build the compliance file are simultaneously building the underwriting submission. For the insurance market's AI-specific exclusions and what coverage actually includes, see what AI policy exclusions actually cover and AI exclusions in professional liability and E&O cover.

For the cross-site risk index covering AI agent liability categories across jurisdictions, see the Agent Liability Risk Index at agentliability.co.

Documenting the deployer compliance programme

The complete Article 26 compliance file for a deployer of a high-risk AI system contains at minimum: a classification record under Article 6 and Annex III; a prohibition check record under Article 5; an AI literacy training inventory and completion records under Article 4; an instructions compliance record under Article 26(1); an oversight register under Article 26(2); a monitoring procedure and log under Article 26(3); an incident log under Article 26(5) and (6); a log retention policy and provider confirmation under Article 26(7); a person-notification procedure under Article 26(8); a FRIA under Article 26(9) where applicable; a database registration confirmation under Article 26(10); and a conformity assessment verification record under Article 43.

None of these documents needs to be long. Each must be accurate, current, and available to a supervisory authority on request. The operational guide for building this file, with templates and documentation standards, is at documenting AI agent risk management for compliance and the operator obligations guide at the operator obligations compliance guide. For a sequenced action checklist, see the 100-day deployer checklist.