EU AI Act Article 26 Worker Notification: Scope, Applicability, and Implementation Controls

What Article 26 requires of deployers

Article 26 of the EU AI Act sets obligations for deployers of high-risk AI systems. A deployer is a natural or legal person, public authority, agency, or other body that uses an AI system under its authority, except for personal non-professional activity. Core duties include assigning human oversight to competent persons with authority, ensuring input data relevance to the extent the deployer controls inputs, monitoring operation, retaining automatically generated logs under the deployer’s control for at least six months unless other law requires otherwise, and suspending use if risks to health, safety, or fundamental rights emerge.

Article 26(7) adds a workplace-specific information duty. Deployers that are employers must inform workers’ representatives and the affected workers that they will be subject to the use of a high-risk AI system. Information must be provided, where applicable, in accordance with Union and national law and practice on informing workers and their representatives. This is an information duty under the AI Act itself. Depth of consultation, timing mechanics, and works-council process are largely shaped by existing labour law and national practice, which vary by Member State.

High-risk classification is a precondition. Systems that are not high-risk do not trigger Article 26 worker notification merely because they are used at work. Annex III employment-related uses are the main workplace pathway into high-risk status. That includes systems intended for recruitment and selection; decisions affecting terms of work-related relationships, promotion, or termination; task allocation based on individual behaviour or personal traits or characteristics; and monitoring and evaluating performance and behaviour of persons in such relationships, unless a narrow Article 6 exception applies.

When Article 26(7) applies, and when it does not

Applicability depends on three concurrent conditions: the organisation is the deployer using the system under its authority; the deployer is an employer; and the system is high-risk for the intended workplace purpose. Vendor-hosted SaaS does not remove deployer status if the enterprise uses the system under its authority. Multi-entity groups, outsourcing, and shared platforms can create borderline deployer maps that need legal designation per deployment, not a single corporate assumption.

Out of Article 26(7) scope are systems that are not high-risk, purely personal non-professional use, and uses where the organisation is not the deployer. Exclusion from Article 26(7) does not clear other duties. GDPR transparency and DPIA expectations, sector rules, collective agreements, and national information or consultation laws may still apply to lower-risk or adjacent workplace AI. Article 27 fundamental-rights impact assessment duties, where they apply to certain public-law bodies, public-service providers, or specified banking and insurance Annex III systems, are complementary to worker information and should not be conflated with it.

Operationalise applicability, ownership, and notification

Treat Article 26(7) as a scoped deployer-employer control, not a blanket workplace AI ethics programme. Start with use-case mapping, then bind each live or planned system to inventory attributes, owners, and pre-use gates.

What to put in the system register and notice workflow

A controlled AI system register is the backbone of Article 26 readiness. Link each system to provider, intended purpose, risk class, deployer entity, oversight owners, worker cohorts in scope, notification status, log and retention locations, and version or configuration bindings. Encode approval gates in procurement and deployment so high-risk workplace systems cannot go live without recorded worker and representative notification and oversight assignment.

Notification content should be accurate to the system’s intended purpose and the populations actually subject to use. Group templates help, but they must allow Member State localisation because national labour law and works-council regimes may require stricter process or genuine consultation rather than one-way information. Preserve immutable records of notice content version, recipient categories, date, and legal basis reference alongside system change history. Those records support internal audit, labour authority review, and market surveillance follow-up.

Ownership should be explicit. Legal and compliance own applicability determinations. HR and labour relations own representative engagement and localisation. System owners keep inventory and purpose bindings accurate. Oversight personnel own runtime monitoring and suspension paths. Procurement should secure provider deliverables deployers need, including instructions for use, log access, transparency information, and change or incident cooperation, without attempting to shift non-delegable deployer legal duties by contract.

Runtime and audit controls that support deployer evidence

Technical controls do not replace legal determination of high-risk status or the information duty, but they make compliance demonstrable across the lifecycle. Separate runtime usage telemetry and audit logs from model training stores. Record who enabled a system, on which populations, under which approval, and which oversight path is active. Bind purpose and configuration so purpose creep into Annex III employment uses opens a governance workflow instead of silent expansion.

Human oversight depends on provider instructions for use and system capabilities such as stop or intervene functions. Deployers must ensure assigned persons can interpret outputs and decide not to use or to override the system where appropriate. Input-data expectations apply only to the extent the deployer controls inputs. Log retention must cover automatically generated logs under deployer control for a period appropriate to intended purpose, of at least six months unless Union or national law provides otherwise.

Runtime governance platforms, including capabilities in areas such as policy enforcement, tool approval workflows, monitoring, and audit logging, can help document approved AI use, affected populations, and change events. They do not by themselves satisfy Article 26(7) if notices were never issued, the risk class was never assessed, or the wrong entity was treated as deployer.

Governance practices that keep programmes proportionate

Article 26(7) is narrower than general workplace AI ethics statements or voluntary acceptable-use policies. Over-notifying every assistant or productivity tool dilutes attention and confuses risk ownership. Under-scoping employment decisioning, performance monitoring, or task allocation tools creates enforcement and labour-relations exposure.