The Spanish Agency for the Supervision of Artificial Intelligence (AESIA) has published its sixth guideline under the Spanish AI regulatory sandbox, dedicated to Article 14 of the AI Act, Human Oversight. Guide No. 6 follows directly from Guide No. 5 on risk management: human oversight is presented as one of the mechanisms through which risks to health, safety and fundamental rights, identified under Article 9, are actually kept under control once the system is in use. The Guide is non-binding and has been updated to reflect the amendments introduced by the Digital Omnibus.

Article 14 requires that high-risk AI systems be designed and developed, including through appropriate human-machine interface tools, so that they can be effectively overseen by natural persons for as long as they are in use.

Oversight is aimed at preventing or minimising risks to health, safety or fundamental rights, in particular where those risks persist despite compliance with the system's other requirements. The oversight measures adopted must be commensurate with the system's risk, level of autonomy and context of use, and can take two forms: measures built into the system itself by the provider before it is placed on the market, or measures identified by the provider and left for the deployer to implement. Providers therefore carry the technical responsibility for building oversight capability into the system; deployers carry the operational responsibility for exercising it.

The core of Article 14 sets out what the persons assigned to oversight must actually be able to do. They must properly understand the system's capabilities and limitations well enough to detect anomalies, dysfunctions and unexpected performance. They must remain aware of automation bias — the tendency to rely, or over-rely, on a system's output without exercising independent judgement, which is a particular concern for systems that produce recommendations for human decision-makers. They must be able to correctly interpret the system's output, using available interpretation tools and methods. They must be able to decide, in a given situation, not to use the system, or to disregard, override or reverse its output. And they must be able to intervene in its operation or interrupt it through a stop button or equivalent procedure that brings the system to a safe halt.

A stricter regime applies to remote biometric identification systems falling under point 1(a) of Annex III. For these, no action or decision may be taken on the basis of the system's identification unless that identification has been separately verified and confirmed by at least two natural persons with the necessary competence, training and authority — a safeguard that does not apply to systems used for law enforcement, migration, border control or asylum where Union or national law considers it disproportionate. The Guide is careful to distinguish biometric identification, a one-to-many search comparing a person's data against a database to establish who they are, from biometric verification, a one-to-one check confirming that a person is who they claim to be, such as comparing a selfie against a passport photo during digital onboarding; the two-person rule applies specifically to the former.

On the design side, effective oversight is treated as inseparable from two other requirements addressed in separate guides: transparency, because a system can only be overseen if it can be understood, and risk management, because oversight is only meaningful if the person exercising it has real control over the risks the system can generate. Providers are expected to supply a human-machine interface through which deployers can actually exercise oversight — a capability the Guide notes is still relatively immature for AI systems compared with traditional software, which is precisely why Article 14 insists on it.

A governance model sits at the centre of the practical measures proposed. It should bring together a multidisciplinary structure spanning business, technical, legal and audit profiles; procedures covering the system from conception through use, including the two-person verification procedure for remote biometric identification where relevant; a risk management framework integrated with the one required under Article 9; and training and evaluation plans covering the design measures adopted, the monitoring interface, and the governance and risk framework itself. In the smart-insulin-pump example the Guide uses throughout, this translates into a team spanning clinical, technical and risk profiles, procedures for receiving patient indicators, managing alerts and validating each proposed dose before it reaches the patient, and a training programme covering both clinical staff and the patients who ultimately self-administer the dose.

To counter automation bias specifically, the Guide proposes a forced-error mode: a testing feature, activated only in test environments, that deliberately generates erroneous outputs so that an organisation can observe whether the people meant to be overseeing the system actually catch the mistake or simply defer to it. In the insulin-pump example, this might mean deliberately proposing an inappropriate dose based on abnormal blood readings to see whether the supervising doctor identifies and corrects it before it reaches the patient; in the financial-assistance example, it might mean proposing an aid amount inconsistent with a family's income to see whether the responsible official flags it.

The level of autonomy granted to the system is treated as a deliberate governance choice between two models. Human-in-the-loop (HITL) requires a person to validate the system's output before it takes effect — an ex ante form of oversight — and is the level the Guide recommends for high-risk use cases such as the insulin pump and the aid-granting system, precisely because the impact of an uncorrected error is significant and hard to reverse. Human-on-the-loop (HOTL) allows the action to be fully automated, with a person able to intervene and reverse it only after the fact — an ex post form of oversight — which the Guide considers unsuitable for the high-risk cases it addresses, given the risk of irreversible harm to fundamental rights. Overarching both is the concept of human-in-command, the principle that ultimate responsibility for critical decisions rests with a person regardless of which of the two operational models is chosen. Whichever level is used, both the system's proposed action and the human's final action must be recorded, in line with the record-keeping requirements addressed in the Guide on Article 12.

Technical documentation for human oversight is not a stand-alone dossier but a by-product of the measures adopted for each related requirement: deployer-side documents setting out what the system must support in terms of risk management, data governance, technical documentation, record-keeping, transparency, accuracy, robustness and cybersecurity, paired with provider-side user and technical manuals explaining how the system meets each of those requirements and how the human-machine interface allows the deployer to monitor them, plus documents specific to human oversight itself: the governance model applied during development and during use, the procedure for remote biometric identification where relevant, the forced-error testing functionality, and the chosen HITL or HOTL level together with its associated governance procedure.

For providers and deployers working through Article 14, the practical sequence is therefore: build the system so its capabilities, limitations and outputs can genuinely be understood and interpreted, and equip it with a monitoring interface and a stop mechanism; decide, case by case, whether human-in-the-loop or human-on-the-loop oversight fits the risk involved, defaulting to human-in-the-loop wherever an error would be serious or hard to reverse; put a governance structure, risk framework and training and evaluation plan in place around the system, with a forced-error test built in to check that automation bias has not silently taken over; apply the two-person verification rule where remote biometric identification is involved; and document each of these measures as they are produced, rather than assembling the file at the end. Because human oversight draws directly on risk management, data governance, transparency, record-keeping, accuracy, robustness, cybersecurity and technical documentation, providers and deployers are advised to consult the corresponding guides for those requirements — Guides No. 5, 7, 8, 9, 10, 11, 12 and 15 — alongside this one, rather than treating Article 14 as a self-contained obligation.

‍