Wiki · Concept · Last reviewed June 25, 2026

AI Act Deployer Obligations

AI Act deployer obligations are the Article 26 duties that turn a high-risk AI system from a vendor product into a governed institutional workflow.

Category: AI governance Updated: June 25, 2026 Tags: EU AI Act, deployers, high-risk AI, human oversight, logs, worker notice

Definition

Under the EU AI Act, a deployer is the actor using an AI system under its authority, except where the use is personal and non-professional. Article 26 sets the core obligations for deployers of high-risk AI systems.

The point is operational accountability. A provider can design, document, and sell a system, but the deployer decides where it enters a workplace, school, bank, agency, hospital, insurer, border process, or other real decision environment. Article 26 makes that use an evidence-bearing duty rather than a passive purchase.

The obligations include use according to instructions, competent oversight, controlled input-data checks, monitoring, log retention, risk and incident escalation, workplace notice, public-authority registration checks, DPIA support, and special limits for post-remote biometric identification.

Scope

The scope is not every AI tool. Article 26 applies to deployers of high-risk AI systems under the AI Act. That classification depends on the legal category, intended purpose, role of the actor, and use context.

The practical question is whether an organization is merely buying access or putting a high-risk AI system into service. Hiring, benefits, credit, worker management, education, biometrics, and essential-service systems can create deployer duties when they fall inside the high-risk framework.

Article 26 also contains special cases. Employers deploying high-risk AI at work must inform workers' representatives and affected workers before use. Public authorities and EU bodies must comply with registration duties and may not use an unregistered high-risk system where registration is required. Post-remote biometric identification for targeted law-enforcement searches has additional authorisation, documentation, deletion, and reporting limits.

How It Works

A deployer-obligations workflow starts with classification and role mapping. What system is being used? Is it high-risk? Who is the provider? Who is the deployer? Which internal unit controls input data, oversight staff, logs, notices, procurement terms, monitoring, and incident escalation?

The deployer then has to translate the provider's instructions into a local operating record. That means assigning trained human overseers with authority and support, defining when humans may disregard or override outputs, checking that controlled input data is relevant and sufficiently representative for the intended purpose, and monitoring operation against the instructions for use.

When logs are under the deployer's control, Article 26 requires retention for an appropriate period of at least six months unless another Union or national law provides otherwise. When use according to instructions may create a risk under Article 79, the deployer must inform the provider or distributor and the market surveillance authority without undue delay and suspend use. Serious incidents trigger a further reporting chain.

Governance and Safety

The governance value is that accountability follows the system into the room where it is used. Article 26 prevents a deployer from treating high-risk AI as a sealed vendor artifact. The local workflow, input data, staff training, monitoring, logs, notices, and incident decisions all become part of the compliance story.

The safety limit is that Article 26 does not prove the system is accurate, fair, necessary, accessible, or socially legitimate. It creates deployer-side duties for a defined legal category. It should connect to EU AI Act, Human Oversight of AI Systems, AI Audit Trails, AI Procurement, AI Post-Market Monitoring, and Algorithmic Recourse.

Evidence Record

Preserve the system classification, provider identity, instructions for use, procurement file, deployment date, intended purpose, local workflow, input-data controls, oversight assignment, training records, authority to override or suspend, monitoring metrics, generated logs, registration checks, workplace notices, DPIA links, incident reports, and communications with providers, distributors, importers, or authorities.

For systems used on people, preserve notices, review outcomes, complaint paths, appeal results, and evidence that staff could actually see and change the relevant decision.

Source Discipline

Do not collapse provider duties, deployer duties, importer duties, distributor duties, and product-manufacturer duties. Article 26 is about deployers. A procurement checklist that only asks whether the vendor is compliant leaves out the local obligations created by use.

Use the Official Journal text for binding claims. The European Commission AI Act Service Desk is useful for navigation and summaries, but the page itself says summaries are explanatory rather than legally binding. For live compliance work, cite the exact article, actor role, system version, intended purpose, jurisdiction, and evidence record.

Spiralist Reading

Article 26 is where the institution runs out of excuses.

The vendor made the system. The model produced the output. The dashboard looked objective. But the deployer chose the workflow, the data, the staff, the notice, the override path, the log retention, and the moment of use.

For Spiralism, deployer obligations are a record of responsibility crossing the threshold from product into practice. The machine may speak, but the institution still decides where that speech becomes power.

Open Questions

Sources

Return to Wiki