Article 26, line by line.

Who is a deployer.

Two definitions sit next to each other in Article 3 and the gap between them runs all the way through the regulation. Article 3(3) names the provider as the person who develops a high-risk AI system, or has it developed, and places it on the Union market or puts it into service under their own name or trademark. Article 3(4) names the deployer as the person using the system under their authority, in any setting other than personal non-professional use.

Most banks, insurers, hospitals, employers and public authorities running AI in 2026 are deployers, not providers. They buy the system from a third-party vendor or use a managed service hosted by that vendor. They configure it for their use case. They feed it customer data. They make decisions off its outputs. They are the operative party at the moment a natural person is affected.

The article between them, Article 25, governs the boundary. Article 25(1) lists three situations in which a person becomes a provider of an existing high-risk AI system. Putting their name or trademark on it. Modifying it substantially under Article 3(23). Modifying its intended purpose so that an AI system not previously classified as high-risk becomes high-risk. The deployer who fine-tunes a vendor's foundation model on their own customer data, ships it under their own brand and routes it at customers can find themselves on the provider side of Article 16, with the full Article 12 logging duty and the full Article 11 technical documentation duty bolted on overnight.

Most regulated deployers will not cross that line. The mass case is the bank that buys a vendor credit-scoring system and uses it under contract. That bank carries Article 26.

Use the system per the instructions for use.

The opening paragraph does not invent a new artefact. It binds the deployer to one the provider already produced. The instructions for use are the document Article 13 obliges the provider to draw up and ship with every high-risk AI system. Article 13(3) lists what that document contains, from the system's intended purpose to its known limitations to the human oversight measures the provider has built in. Article 26(1) closes the loop. The deployer must use the system within the envelope the provider drew.

The phrase appropriate technical and organisational measures is borrowed from GDPR Article 32 and carries the same risk-based register. The measures scale with the gravity of the use case. A hospital deploying a high-risk diagnostic-support system must put deeper measures in place than a small employer deploying a high-risk recruitment-screening tool, even though both sit under Article 26(1). The measures are the deployer's own. The benchmark is the IFU.

What this looks like in practice. A bank deploying a vendor credit-scoring system pulls the IFU into its model risk policy. It tags every production decision with the IFU version at run time. It blocks any prompt template, threshold or cohort the IFU does not authorise. When the vendor ships a new IFU version, the bank's deployment pipeline refuses to advance until the new IFU has been re-acknowledged at the model risk committee. The audit trail at the end of all that is what an Article 26(1) inspection asks for.

Competent natural persons for human oversight.

Article 14 binds the provider to build the oversight architecture into the system. Article 14(3) names the kinds of measures the provider must identify, including those the deployer is to implement under Article 14(3)(b). Article 26(2) is the staffing duty. The provider supplies the design. The deployer puts named, qualified humans into the seats.

Four words load every audit. Competence. Training. Authority. Support. Each is independently testable. A reviewer who has the authority to override but not the training to read the system's outputs fails the test. A reviewer with the training but no real authority to halt a decision fails it too. A reviewer with both but no operational support, no relief schedule, no second-line escalation, no time budget per case, fails on support.

Paragraph 3 is the safe-harbour clause. The obligations set out in paragraphs 1 and 2, are without prejudice to other deployer obligations under Union or national law and to the deployer's freedom to organise its own resources and activities for the purpose of implementing the human oversight measures indicated by the provider. The deployer chooses how to staff. The deployer does not choose whether to.

Where the deployer controls the input data, the deployer owns the input.

Article 10 binds the provider on training, validation and testing data. Article 26(4) binds the deployer on production input data, where the deployer is the party that controls it. Most of the time, the deployer is. The bank chooses which customer attributes to feed the credit-scoring system. The hospital chooses which patient features to surface to the diagnostic-support system. The employer chooses which CV fields enter the recruitment-screening system.

Two adjectives carry the weight. Relevant. The input must connect to the intended purpose the IFU declared. Sufficiently representative. The input must reflect the population the system will decide on. A deployer that pipes in a feature the IFU did not contemplate has broken Article 26(1) and Article 26(4) at the same time. A deployer that runs a system trained on Western European mortgage applicants against an Eastern European or rural cohort, without confirming representativeness, has broken Article 26(4) even if the IFU permitted the input.

The boundary is the phrase to the extent the deployer exercises control. Where the system is fully managed and the deployer cannot change the input pipeline, the duty narrows. Where the deployer assembles the input from internal systems, the duty is full.

Monitor the run. Report the harms.

One paragraph carries three distinct duties. The first sentence is steady-state monitoring against the IFU and a feedback channel into the provider's Article 72 post-market monitoring system. The second sentence is the risk-detection escalation, with three obligations bound together: notify the provider or distributor, notify the market surveillance authority, suspend the use. The third sentence is the serious-incident reporting trail. The order matters. First the provider, and then the importer or distributor and the relevant market surveillance authorities.

Article 73 governs serious-incident reporting in detail and binds the provider on the timeline. The deployer's duty under Article 26(5) is to feed the chain. The chain breaks if the deployer cannot identify a serious incident. The chain breaks if the deployer cannot route the report. The chain breaks if the deployer cannot prove either step happened.

The verb suspend is operationally severe. A bank that has reason to consider its credit-scoring system is producing a risk under Article 79(1) cannot continue to underwrite while the conversation with the vendor is ongoing. The system stops. The deployer's continuity arrangements take over. The audit trail must show the timestamp of the suspension and the timestamp of the notification.

Logs at least six months.

This is the deployer-side mirror of the provider's Article 19(1) retention duty. The logs are the artefacts Article 12 obliges the system to generate automatically over its lifetime. The provider is responsible for the system being able to produce them. The deployer is responsible for retaining the ones that come into the deployer's hands.

Three constraints. Under their control. The deployer keeps what it can address. Appropriate to the intended purpose. Six months is a floor, not a ceiling. Unless provided otherwise. Sectoral law often is. MiFID II Article 16(7) runs five years. The Medical Device Regulation Article 10(8) runs ten years and fifteen for implantable devices. The Capital Requirements Regulation and the EBA outsourcing guidelines push five years for risk-relevant records. Six months is the regulatory minimum the deployer must beat. It is rarely the actual retention horizon.

The phrase in particular in Union law on the protection of personal data is the GDPR carve-back. Where logs contain personal data, GDPR Article 5(1)(e) storage limitation applies. The deployer cannot retain longer than the GDPR purpose-specific period, even if Article 26(6) would tolerate longer retention. The two regimes are read together. The deployer settles on a per-use-case retention number that satisfies both.

Workers' representatives before service.

The trigger is Annex III(4) employment, workers management and access to self-employment. Recruitment screening at Annex III(4)(a). Performance, promotion and termination decisions at Annex III(4)(b). Both attach Article 26 in full and pull Article 26(7) on top.

The obligation is procedural and timing-sensitive. The notice runs before putting into service or using. A deployer that rolls out a recruitment-screening AI in May and notifies the works council in June has not satisfied the article. The notice runs to two audiences. Workers' representatives, which is the works council in Germany, the CSE in France, the RSU in Italy, the equivalent statutory or recognised body in each Member State. Affected workers, the people the system will decide on or assist deciding on.

The phrase where applicable, in accordance with the rules and procedures laid down in Union and national law and practice picks up the existing labour-information regimes. Information-and-consultation directives. Collective agreements. National works council statutes. Article 26(7) sits on top of those and adds a substantive trigger but defers to them on procedure.

Public-authority registration under Article 49.

Two duties stack here. The first is the registration duty under Article 49 and the EU database under Article 71. Public-authority deployers register themselves and their use against entries the provider has already lodged. The Annex VIII(C) information set names the deployer, the use case, the legal basis, the system in use and the contact point. The database is public, in part. The deployer's registration creates a discoverable trail of every Annex III system any public authority anywhere in the Union is running.

The second is the conformity check. If the deployer cannot find the system in the database, the deployer cannot use it. The article inverts the usual permission stance. Use is conditioned on prior provider registration. The deployer's positive duty is to look. The deployer's negative duty is to refuse to operate the system and notify the provider or distributor of the gap.

Private deployers do not carry Article 26(8) directly. They carry the underlying Article 26 duties and the FRIA trigger under Article 27 if it applies, but the registration duty is the public-authority track.

The DPIA cross-reference.

This is not a new DPIA obligation. It is a routing instruction. Where the deployer's use of a high-risk AI system already triggers a DPIA under GDPR Article 35 or, in the law-enforcement context, Article 27 of the Law Enforcement Directive, the deployer must use the Article 13 instructions for use as an input to that DPIA. The information the provider supplied about the system's intended purpose, known limitations, oversight measures, performance metrics, training data characteristics flows into the deployer's DPIA narrative.

The practical implication is that a deployer cannot run a credible AI DPIA without the IFU. If the provider's IFU is thin, the deployer's DPIA will be thin and the deployer wears it. The article shifts a documentation burden upstream by making the provider's quality of disclosure load-bearing for the deployer's own GDPR compliance.

The fundamental rights impact assessment under Article 27.

The fundamental rights impact assessment lives in Article 27, not in Article 26. The two articles are read together. Article 26 is the operational stack. Article 27 is the upstream impact assessment that must be done before the operational stack starts running, where the trigger fires.

The trigger has three limbs. Bodies governed by public law. Hospitals operating under public-law statutes. Public broadcasters. Government departments and their agencies. Private entities providing public services. The recital text and 2025 Member State guidance treat this as covering schools, hospitals and welfare administrators that operate under public-service mandates even when constituted as private entities. Deployers of Annex III(5)(b) creditworthiness systems and Annex III(5)(c) life-and-health insurance risk-pricing systems. Two specific Annex III categories where the FRIA bites every deployer regardless of public or private status. Annex III(2) critical infrastructure is excluded.

What the FRIA contains, per Article 27(1) sub-paragraphs. A description of the deployer's processes in which the high-risk AI system will be used. The intended purpose and the period and frequency of use. The categories of natural persons and groups likely to be affected. The specific risks of harm. The implementation of human oversight measures. The measures to be taken in case of materialisation of risks, including governance, complaint mechanisms, internal arrangements.

Article 27(2) confirms the obligation applies to the first use. The deployer may, in similar cases, rely on a previously conducted FRIA or on existing impact assessments carried out by the provider. Article 27(3) requires the deployer to notify the market surveillance authority of the FRIA results, on a template the AI Office develops under Article 27(5). Article 27(4) integrates the FRIA with any DPIA already in hand, so that a deployer running a single AI system across both regimes is not made to repeat itself.

The interaction with Article 26 is sequential. Run the FRIA. File the result. Then start running the system, with Article 26(1) through Article 26(12) attaching the moment use begins.

Post-remote biometric ID. Notice to the affected.

Article 26(10) is the law-enforcement carve-out attached to Annex III(1)(a) post-remote biometric identification. Three conditions stack. The use must sit within a criminal investigation for a specific suspect or convict. The deployer must obtain authorisation, ex ante where practicable and no later than 48 hours otherwise, from a judicial or binding administrative authority whose decision is subject to judicial review. Each use is limited to what is strictly necessary for the investigation of a specific criminal offence. The carve-out from prior authorisation is narrow and applies only to initial identification based on objective and verifiable facts directly linked to the offence.

The same paragraph sits inside a wider law-enforcement architecture under Articles 5 and 79, the prohibitions on real-time biometric ID in publicly accessible spaces, and the data-protection limits under the Law Enforcement Directive. Article 26(10) does not loosen those. It tightens the post-remote use case the regulation does permit.

Article 26(11) is the data-subject notification duty. It runs against every Annex III system that decides about, or assists in deciding about, a natural person. The duty is informational. The natural person must know they are subject to use of the system. The notice does not need to disclose the model. It does need to surface the existence of the system, the purpose, the role in the decision.

The interaction with GDPR Article 13 and Article 14, the data-controller transparency duties, is direct. A deployer that already complies with GDPR Article 13 by notifying the data subject of automated processing under Article 22 will usually satisfy Article 26(11) at the same time, provided the notice names the AI system specifically. A boilerplate privacy policy reference to "automated decisions" no longer suffices once the system is high-risk.

Article 26(12) closes the article. Deployers shall cooperate with the relevant competent authorities in any action those authorities take in relation to the high-risk AI system in order to implement this Regulation. Cooperation is the catch-all. It includes producing logs under Article 26(6), surfacing the FRIA under Article 27, supplying the IFU acknowledgements under Article 26(1), naming the oversight staff under Article 26(2), demonstrating monitoring under Article 26(5).

The articles Article 26 reads against.

Article 26 does not stand alone. It reads against six other articles in the regulation, and a deployer audit ends up touching all of them.

Where Warrant maps Article 26.

The deployer-side evidence package built under Warrant carries one field per Article 26 paragraph that an inspection asks for. The mapping is below. Each row is a clause, what an inspection expects the evidence to show, and the field on the Warrant evidence record that holds the proof.

One property of this stack is easy to miss and hard to delegate. The deployer-side record-and-retention duty under Article 26(6), read with the per-decision evidence each clause above expects, does not move to the model vendor. The vendor can ship a system that produces logs. The vendor cannot discharge the deployer's duty that the records of what the system did exist, are kept for the appropriate period, and are legible to a regulator who asks. The obligation lands on the named accountable deployer, per action, and stays there.

That leaves one open question a deployer should put to any evidence arrangement before relying on it. When the regulator asks to see what the agent did and which Article 26 clause each action met, is the record independently verifiable without contacting the vendor that produced it, and by whom. A record only the producer can vouch for is a weaker answer to Article 26(12) cooperation than a record a regulator, an auditor, or a counterparty can check on its own.

Questions a deployer's compliance officer asks first.

Read the source directly.

• Regulation (EU) 2024/1689 · EUR-Lex CELEX:32024R1689
• Article 26 obligations of deployers · annotated text
• Article 27 fundamental rights impact assessment
• Article 3 definitions · provider and deployer
• Article 49 EU database registration
• Article 72 post-market monitoring
• Article 73 serious-incident reporting
• Per-obligation Warrant evidence field mapping

Authored by Warrant Compliance, the regulatory-analysis function at Warrant. [email protected]. Editorial commentary on regulatory text. Not legal advice. The verbatim quotation of Article 26 paragraphs (1) through (12), Article 27(1), and Article 3(3) and (4) reflects the official English-language text of Regulation (EU) 2024/1689 as published in the Official Journal of the European Union on 12 July 2024.