Article 26 Deployer Duties: Oversight, Input Data and Logs

Your organisation has licensed a CV-screening tool or a credit-scoring model. The vendor holds the technical documentation, ran the conformity assessment and affixed the CE marking, so a reasonable compliance officer concludes the regulatory weight sits with the vendor. Article 26 of the EU AI Act makes that conclusion wrong — not by moving the provider's duties to you, but by creating a separate set of obligations only you can discharge, because only you control how the system is actually used.

These duties are unglamorous: read the instructions, name the humans, watch the inputs, keep the logs, tell people. They are also what an authority can test fastest. Auditing a technical file takes months; asking who held oversight duty last Tuesday takes an afternoon.

Who the duty falls on

A deployer is any natural or legal person, public authority or body using an AI system under its authority, other than in a personal, non-professional capacity. If your staff use it in your business, you are the deployer — whether you built it, bought it, or subscribe to it.

Article 26 does not make you a provider: technical documentation, conformity assessment, CE marking and a quality management system remain the provider's. The confusion arises because a deployer can become a provider for a given system. Under Article 25 that happens if you put your own name or trade mark on a high-risk system already on the market, substantially modify one so that it remains high-risk, or change the intended purpose of a system that was not high-risk — including a general-purpose AI system — so that it becomes high-risk under Article 6. The full provider obligation set then attaches to you, and the original provider must cooperate and supply what you need.

White-labelling is the commonest trap: your brand on a vendor's model. In group structures, also identify which entity uses the system under its authority.

Using the system the way the provider intended

Article 26(1) requires appropriate technical and organisational measures to ensure use accords with the instructions for use — which presupposes you hold them. The provider owes them under Article 13; if procurement accepted a marketing datasheet instead, compliance is impossible. Read them for the four things that become your controls: the declared intended purpose, the stated limitations, the input characteristics expected, and the oversight measures specified. Uses outside the declared purpose should be technically blocked or contractually prohibited, not discouraged in a policy. Article 26(3) preserves your freedom to organise your own resources in implementing those measures: you choose how, not whether.

Human oversight is a staffing decision

Article 26(2) requires you to assign oversight to natural persons with the necessary competence, training and authority, and to give them the necessary support.

• Competence: they understand what the system does, where it degrades, and the pull of automation bias — deferring to an output because it is numeric and arrives quickly.
• Authority: they can override or halt use without permission from someone whose targets depend on throughput. If overriding the model is a career risk, the oversight is decorative.
• Support: realistic time per case, tooling that shows the inputs behind an output, a defined escalation route.
• Continuity: named deputies, so oversight survives leave and turnover.

Article 14 obliges the provider to build a system that can be overseen; Article 26(2) obliges you to staff it. An override control nobody is empowered to press satisfies neither.

Input data, to the extent you control it

Article 26(4) is deliberately bounded: to the extent you exercise control over input data, you must ensure it is relevant and sufficiently representative in view of the intended purpose. This is not the full Article 10 data governance regime — training, validation and testing data remain the provider's responsibility — but do write down where your control boundary sits. A model validated on a national population but fed one region's records degrades silently: the provider cannot see your pipeline.

Logs, and the retention tension

Article 26(6) requires you to keep the logs the system generates automatically, to the extent they are under your control, for a period appropriate to the intended purpose and in any event at least six months, unless other Union or national law provides otherwise — data protection law in particular.

Three traps. Logs in a vendor's cloud may not be under your control at all, so export rights and access on demand belong in the contract. Six months is a floor, not a target: a lending or employment decision may be contested long afterwards, and an expired log is an evidential gap you created. And GDPR storage limitation pulls the other way, so you need a documented retention rationale per system, not a platform default.

Article 26(5) sits alongside: monitor operation against the instructions, inform the provider under Article 72 where relevant, and where you have reason to consider that compliant use nonetheless presents a risk, tell the provider or distributor and the market surveillance authority without undue delay and suspend use. Serious incidents go first to the provider. Agree in advance who holds that decision.

Telling people

Two duties, often conflated. Under Article 26(7), an employer must inform workers' representatives and affected workers before putting a high-risk system into service in the workplace, in accordance with applicable national rules on informing workers. In several member states that engages an existing works council procedure with its own statutory timetable — and that timetable, not the AI Act's, will be your critical path.

Under Article 26(11), where an Annex III high-risk system makes or assists in making decisions about natural persons, you must inform those persons. This is separate from Article 50 transparency and GDPR Articles 13 and 14, though one well-drafted notice can carry all three. Public authority deployers must also check EU database registration (Article 26(8)).

Evidence that satisfies each duty

Duty	What an auditor asks for
Use per instructions (26(1))	Article 13 instructions on file, mapped to your procedures
Oversight (26(2))	Named individuals, training records, written authority to override
Input data (26(4))	Data flow showing your control boundary; representativeness checks
Monitoring (26(5))	Escalation criteria, suspension rights, provider notifications
Logging (26(6))	Log location and access evidence; retention rationale
Information (26(7), 26(11))	Dated worker notifications; the notice served on individuals

Where it meets data protection

Article 26(9) directs you to use the provider's Article 13 information in any data protection impact assessment required under GDPR Article 35. Article 27 separately requires a fundamental rights impact assessment from public law bodies, private entities providing public services, and deployers of the Annex III creditworthiness and life and health insurance pricing systems, before first use and notified to the market surveillance authority. The AI Office is to develop a template; check whether it is published. Deployer breaches carry fines of up to 3% of total worldwide annual turnover, with GDPR exposure of up to 4% in parallel.

The limits of this guidance

This is general information, not legal advice on your systems. Several inputs a deployer needs are still settling: harmonised standards supporting the high-risk requirements were not all finalised at the time of writing, and the application dates for the high-risk regime have been the subject of proposed legislative amendment — verify the position as currently adopted rather than relying on a date quoted in any article, including this one. National implementation also differs on competent authorities and worker consultation.

UK organisations have no domestic equivalent regime; exposure arises where systems are placed on the EU market or where their output is used in the Union, alongside UK GDPR and sector obligations. Take specialist advice where the provider or deployer characterisation is genuinely uncertain, where you intend to white-label or substantially modify a vendor system, or where biometric uses are involved.