Human oversight for a deployer means assigning competent, trained and authorised people, giving them the information, time and tools to oversee, designing the workflow so they can intervene, disregard or reverse an output, and recording what they did. Monitoring means observing operation against the instructions, detecting anomalies, drift and misuse, and acting on what is found, including informing the provider and suspending use where a risk is identified. Oversight and monitoring are linked: oversight without monitoring cannot see drift, and monitoring without oversight cannot act on it. Both must be evidenced in operational records, not only in policies.
What makes oversight effective, not formal?
Effective oversight requires the overseer to understand the system, to receive the information needed to judge an output, to have the authority to change the outcome, and to have the time to do the work. A workflow where an overseer must approve hundreds of outputs per hour, without the underlying information, is formal oversight, not effective oversight. A workflow where the overseer sees the output, the key inputs, the confidence or limitation information, and the context, and can pause, correct or escalate, is closer to effective oversight. The design should be tested with the overseers themselves, including how long a review takes, what information is missing, and what happens when the overseer disagrees with the system. The test results should be recorded and used to adjust the workflow.
How should overseers be selected and trained?
Overseers should be selected for the competence the decision requires, trained on the system, its limitations, the instructions, and the oversight task, and given refresher training when the system, the data or the workflow changes. Training should include the system's known failure modes, the groups most affected by error, the escalation route, and the recording duty. AI literacy under Article 4 supports this training, but oversight training is specific to the system and the decision, not a general course. The deployer should record who was trained, on what, and when, and should assess whether training worked, for example by testing whether overseers can recognise an error or an out-of-scope output, rather than only recording attendance.
For the broader regulatory framework, see deployer responsibilities.
What authority and support must overseers have?
Authority means the overseer can intervene in the operation, disregard or reverse an output, stop the system, and escalate without penalty. Support means the overseer has access to the information, the tools, and the colleagues needed to make a judgement, and is not penalised for slowing a process to oversee it properly. Organisational support matters as much as technical support: a target that rewards throughput over accuracy will undermine oversight, even where the technical design is sound. The deployer should set oversight expectations in the overseer's role description, protect the time needed for oversight, and review whether overseers actually use their authority, including how often outputs are changed or escalated, and why.
How should monitoring be organised?
Monitoring should have an owner, a rhythm, and a method. The owner is responsible for observing operation, reviewing logs and outputs, and acting on findings. The rhythm can be continuous for high-volume systems, periodic for lower-volume systems, and event-driven for incidents, with the rhythm proportionate to the risk. The method should include checks for accuracy, drift, bias, misuse, and compliance with the instructions, using the logs and the performance information the provider supplied. Monitoring should be documented, with the checks performed, the findings, and the actions taken, so that a later reviewer can see that operation was observed, not only that a policy required observation.
What should happen when monitoring finds a problem?
A monitoring finding should lead to a recorded decision: continue, adjust, escalate, inform the provider, or suspend use. A finding that the system may present a risk triggers the Article 26(5) duty to inform the provider or distributor and the market surveillance authority and to suspend use. A serious incident triggers the reporting chain in Article 26(5) and Article 73. A performance drift that does not present a risk should still lead to analysis, a change to the workflow, training or configuration, and a record of the change. The deployer should not continue using a system that it knows is producing unreliable outputs while waiting for a provider fix, without limiting the use to what remains safe and recording the limit.
Continue with Article 26 deployer duties in depth.
What is not covered by this guide?
This guide explains oversight and monitoring as operational practices. It does not design an oversight workflow for a specific system, does not set staffing levels, and does not decide whether a particular oversight arrangement satisfies Articles 14 and 26. Those questions need the system, the decision, the volume, the affected people, and the overseers' competence and authority, read against the consolidated text and the provider's instructions. Oversight design for consequential systems should be tested with the overseers and confirmed with a competent authority or legal adviser before the system is used at scale.
Frequently asked questions
Is a human approving every output enough for oversight?
Not necessarily. Approval must be informed, competent and authorised, with the information and time to judge the output. A rapid approval of every output, without the underlying information, is formal rather than effective oversight.
How often should monitoring be reviewed?
The rhythm should be proportionate to the risk, volume and rate of change. High-volume, consequential systems need more frequent monitoring, and any incident, drift or change should trigger a review outside the regular rhythm.
What should be recorded about oversight?
The overseer assignments, training, authority, the outputs reviewed, the interventions made, the escalations, and the monitoring checks and findings. The record should show what was actually done, not only what was planned.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗AI Act Service Desk timeline ↗European Commission regulatory framework for AI ↗