Deployers of high-risk systems

The situation

A deployer bought or licensed a high-risk AI system, for example a recruitment tool under Annex III point 4(a) or a creditworthiness model under Annex III point 5(b), and uses it in its own decisions. The provider's instructions for use state that the system is high-risk, and the contract places the operational duties on the deployer. Under Art. 26(1) the deployer's duty is to use the system within the intended purpose and the conditions of use that the instructions state, and under Art. 26(2) the deployer assigns human oversight to natural persons with the competence, training, authority and support to act.

Human oversight can exist as a role on an organisation chart while nobody has tested whether the assigned person can stop or override a decision. Art. 26(2) read with Art. 14(4) asks for an observable capability: the assigned person can disregard, override or reverse the output and can halt the system in a safe state, and a test shows that a stop instruction from that person takes effect. Logs are produced by the provider's platform, and the deployer's duty under Art. 26(6) covers the logs under its control: the deployer keeps them for a period appropriate to the intended purpose, of at least six months unless other Union or national law sets a different period, so the deployer needs to know what the platform retains and for how long.

A data protection impact assessment under Art. 35 of Regulation (EU) 2016/679 does not replace the fundamental rights impact assessment. Art. 27(4) lets the deployer cross-reference the sections of the data protection impact assessment that already meet an Art. 27(1) element, and the fundamental rights impact assessment complements it. Workers and affected persons have their own paragraphs: Art. 26(7) requires an employer to inform workers' representatives and affected workers before use at the workplace, and Art. 26(11) requires the deployer of an Annex III system to inform natural persons that they are subject to its use. The questions this hub answers:

• The provider's documentation says the system is high-risk, and the contract puts the operational duties on the deployer
• Human oversight exists on an org chart but nobody has tested whether the overseer can stop or override a decision
• The DPIA under the GDPR exists and the relationship to a FRIA is unclear
• Logs are produced by the provider's platform and the deployer does not know what it retains or for how long
• The affected people, workers or customers, may ask for the explanation Article 26 refers to

Obligations and dates

The table holds the two deployer articles and the two provider articles whose outputs the deployer relies on, the oversight measures identified under Art. 14(3) and the logs generated under Art. 12.

Regulation (EU) 2024/1689 sets two periods for a deployer and no performance threshold: Art. 26(6) sets a log retention of at least six months unless applicable Union or national law sets a different period, and Art. 26(10) sets a limit of 48 hours for the authorisation request of a post-remote biometric identification system. Oversight competence, monitoring frequency, input data representativeness and the harm scale of a fundamental rights impact assessment carry no number in the Act. No harmonised standard is cited in the Official Journal as of the anchor date, so no presumption of conformity is available to a deployer. The categories of oversight measures come from prEN 18229-3Draft, a JTC 21 draft at drafting stage with no public text, and the structure of the assessment record comes from ISO/IEC 42005:2025Published, a published standard that sets no acceptance value. The deployer sets its own targets against the context of use and records the justification; the acceptance-criterion step of PR-14-OVR v1.0 and the scale-justification step of PR-27-FRIA v1.0 hold that record.

What an assessor or authority will ask for

A market surveillance authority acting under Art. 74 or an internal audit function asks a deployer for evidence that oversight is real, that logs are retained, and that the impact on affected people has been examined.

1. Structured FRIA record aligned to ISO/IEC 42005 with the affected rights and groups mapped
2. Human oversight verification: override and stop functions, information sufficiency for the overseer, automation-bias measures
3. Log retention and integrity evidence for the logs under the deployer's control
4. Instructions-for-use conformance check: the system is used within the provider's declared scope
5. Worker and affected-person information records under Article 26
6. Market surveillance authority notification checklist for the FRIA

The list maps onto the artifact families specified with synthetic samples on the deliverables page. The FRIA record is the output of PR-27-FRIA v1.0. The test report is the output of PR-14-OVR v1.0 for oversight verification, of PR-12-LOG v1.0 for log retention and decision reconstruction, and of PR-10-BIAS v1.0 for input data representativeness. The protocol run record sits behind each test. The assessment memo holds the instructions-for-use conformance check. The register or checklist covers the notification to the market surveillance authority under Art. 27(3). The worker information record under Art. 26(7) and the notice to affected persons under Art. 26(11) are the deployer's own documents; a review checks that each exists with the content the paragraph names.

Scenarios

Each scenario page tagged for deployers states the sequence of events, the evidence list and the consequence of inaction with its article reference.

• We bought a high-risk system: our AI Act Article 26 duties
• FRIA vs DPIA: which assessment a deployer owes
• What does the EU AI Act require of human oversight: proving it is real, not symbolic
• EU AI Act and recruitment: an HR screening tool as an Annex III system

Guides

Each guide tagged for deployers holds a real command, configuration or synthetic example and a threshold or pitfall with its source.

• Proving AI literacy under the AI Act: the Article 4 evidence file
• AI bias testing for fairness under the EU AI Act: subgroup disaggregation
• EU AI Act vs GDPR: differences and overlap
• Fundamental rights impact assessment under the AI Act: conducting one step by step
• EU AI Act Article 12 logging: verifying log completeness
• Override testing: what AI human oversight under Article 14 looks like in a test
• Provider vs deployer under the AI Act

Services

Four services test the deployer's evidence; the scope limits are stated on what we cannot do, and the compliance decision remains with the deployer, its counsel and, where relevant, the market surveillance authority.

• FRIA facilitation and evidence structuringtiming under verification2027-12-02Working reading
• Logging and human-oversight verificationtoward the Annex III date2027-12-02Deferred
• Bias and fairness testing under the Omnibus sensitive-data provisiontoward the Annex III date2027-12-02Deferred
• Classification and readiness assessmentnow2026-07-27In force

Protocols

Each protocol is versioned and published in full on the methodology index with the derivation from the standards it cites and the limits of what it shows.

• PR-27-FRIA v1.0FRIA facilitation protocol
• PR-14-OVR v1.0Human oversight verification protocol
• PR-12-LOG v1.0Logging completeness and reconstruction protocol
• PR-10-BIAS v1.0Bias and subgroup performance protocol

Tools and templates

The classifier, the obligation tracker and the checklist run in the browser, nothing is sent to a server, and their rules are published on the tool logic page; the fundamental rights impact assessment outline and the other templates are on the templates page.

• Risk and role classifier
• Obligation tracker
• Test checklist generator

Questions

+−What are the EU AI Act obligations for deployers of high-risk AI systems?

Art. 26 requires the deployer to use the system in accordance with the instructions for use, to assign human oversight to persons with competence, training, authority and support, to keep the input data it controls representative, to monitor operation and report risks and serious incidents, to keep the logs under its control for at least six months under Art. 26(6), to inform workers and affected persons, and to cooperate with authorities. Art. 27 adds a fundamental rights impact assessment for public bodies and certain private deployers.

+−What is the difference between a provider and a deployer under the EU AI Act?

Art. 3(3) defines the provider as the entity that develops a system, or has it developed, and places it on the market under its own name. Art. 3(4) defines the deployer as the entity that uses a system under its own authority outside a personal non-professional activity. The provider carries Art. 9 to 17; the deployer carries Art. 26 and, in scope, Art. 27. Under Art. 25(1) a deployer that puts its name on the system, substantially modifies it or changes its intended purpose becomes a provider.

+−Who needs to conduct a FRIA?

Art. 27(1) places the duty on three kinds of deployer of a high-risk AI system under Art. 6(2): a body governed by public law, a private entity providing public services, and a deployer of a creditworthiness or insurance pricing system under Annex III point 5(b) or (c). Annex III point 2 systems are excepted from Art. 27(1). The provider carries no duty under Art. 27. The Art. 27 application date is unsettled: the working reading is the Annex III application date; the alternative reading is the general application date.

Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.

Ask about scopehello@aiassurancelabs.com