Human oversight: Art. 14 measures and the deployer's Art. 26(2) duties
Record who can intervene in each high-risk system, how the stop mechanism works, and how automation bias is countered — the provider designs the measures, the deployer assigns and equips the people.
Operations → Human Oversight is the portfolio view of Article 14 (providers: design the system so humans can oversee it) and Article 26(2) (deployers: actually assign competent people and give them authority and support).
What good looks like
For each high-risk system, the oversight record answers four questions:
- Who — named roles (not just "the team") with the competence, training and authority to oversee the system.
- What they can see — the information surface that lets an overseer understand what the system is doing: confidence signals, logs, the instructions for use.
- What they can do — intervene, override a decision, or stop the system. The stop mechanism has to be real and reachable, not theoretical.
- Automation bias — the measures that keep humans from rubber-stamping the machine: sampling reviews, second-opinion thresholds, deliberate friction on high-impact decisions.
Provider vs deployer
The engine gives each side its own obligations. As a provider, the oversight measures are a design deliverable — they go into the technical documentation and the instructions for use (see Supply chain: instructions for use). As a deployer, your Art. 26 duties are operational: assign the people, train them, and keep the assignment current when staff change.
Click through from the rollup to the system's Oversight tab to work the checklists, attach evidence (the oversight procedure, training records, the runbook for the stop mechanism) and assign an owner.
Related
- The six-phase compliance journey — oversight work lands in the Implement phase.
- AI literacy — Art. 4 training is what makes "competent people" defensible.