Module 6 — Oversight and Logging That Survive a Review

Module 6 of AI Risk Management Pro: designing for the Art. 14(4) oversight measures, automation bias, the competence and authority the overseer actually needs under Art. 26(2), and logs that answer a question (Art. 12, Art. 19, Art. 26(6)).

Human oversight is the measure organisations most often write into a risk register, and the measure they least often build. The gap matters because once "human review" appears as the mitigation for a residual risk under Art. 9(5), the credibility of that acceptance depends entirely on whether the oversight is real. This module is about making it real, and about the logging that is the only way to show it afterwards.

Art. 14 is a design obligation on the provider

Art. 14(1): high-risk systems shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use.

The word doing the work is designed. Oversight is not a procedure bolted on at deployment; it is a property of the system's interface and behaviour. Art. 14(3) makes that concrete: the measures shall be commensurate with the risks, and shall consist of measures identified and built into the system by the provider before it is placed on the market and/or measures identified by the provider that are appropriate to be implemented by the deployer.

So there are two lists, and the handover between them is where real programmes lose the thread. The provider must state which oversight measures it built in and which it expects the deployer to implement — that statement travels in the Art. 13 instructions and in Annex IV element 2(e). A deployer that never received the split is implementing oversight blind.

The five capabilities in Art. 14(4)

Art. 14(4) requires that the deployer's assigned natural persons be enabled, as appropriate and proportionate, to:

(a) Understand the relevant capacities and limitations of the system and monitor its operation, including to detect and address anomalies, dysfunctions and unexpected performance.

(b) Remain aware of the possible tendency to automatically rely or over-rely on the output — automation bias, named in the Regulation. Particularly for systems providing information or recommendations for decisions taken by humans.

(c) Correctly interpret the output, taking into account the characteristics of the system and the interpretation tools and methods available.

(d) Decide, in any particular situation, not to use the system or otherwise to disregard, override or reverse the output.

(e) Intervene in the operation or interrupt the system through a stop button or a similar procedure allowing it to come to a halt in a safe state.

Turn each into a testable design question, and the gap between a sign-off button and oversight becomes obvious:

Capability (b) deserves its own note because it is the one the Regulation singles out and the one organisations treat as a training topic. Training helps marginally; design helps more. Measures that work: no pre-selected recommendation; requiring the reviewer to record a reason before seeing the score on a sample of cases; surfacing the model's confidence and its known weak segments; and — most effective — measuring override rate as a health signal rather than as deviance. An override rate of zero is not compliance, it is evidence that (d) does not exist in practice.

Art. 14(5): the biometric two-person rule

For Annex III point 1 systems, Art. 14(5) adds that no action or decision may be taken by the deployer on the basis of the identification resulting from the system unless it has been separately verified and confirmed by at least two natural persons with the necessary competence, training and authority — with a carve-out where Union or national law considers that requirement disproportionate for law enforcement, migration, border control or asylum purposes. If you run remote biometric identification, this is a staffing design constraint, not a policy sentence.

Art. 26(2) is the deployer's half, and it has teeth

Art. 26(2): deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support.

Three words, three obligations, and this is where the Art. 4 literacy work from Module 1 earns its keep:

• Competence — can this person understand this system's outputs? Evidenced by role-specific training, not a general awareness module.
• Training — dated, named, system-specific. The literacy register from Module 1 is the artefact.
• Authority — can they actually overturn the output without seeking permission? This is organisational and is the one most often missing.

Art. 26(2) sits in the Art. 99(4) penalty band. It is also the route by which the Art. 4 literacy duty — which has no dedicated fine — acquires real exposure. An oversight arrangement staffed by people without evidenced competence is the clearest, cheapest finding a supervisor can make.

Logging: Art. 12, Art. 19, Art. 26(6)

Art. 12(1): high-risk systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system. Art. 12(2): the logging shall enable the identification of situations that may result in the system presenting a risk within the meaning of Art. 79(1), or in a substantial modification, and shall facilitate post-market monitoring under Art. 72 and the deployer's monitoring under Art. 26(5).

Art. 12(3) adds minimum content for Annex III point 1 systems specifically: the recording period of each use, the reference database against which input data has been checked, the input data for which the search led to a match, and the identification of the natural persons involved in verifying the results under Art. 14(5).

Retention: Art. 19 for providers, Art. 26(6) for deployers — in both cases a period appropriate to the intended purpose, of at least six months, unless other law provides otherwise. Sector law frequently does, and longer.

The operational test is reconstruction. Take one decision from three months ago and try to answer: what inputs did the system receive, what did it output, which version of the model was it, who reviewed it, what did they decide, and how long did they take? If any of those cannot be answered, the logging satisfies the letter and fails the purpose — and it will fail it at exactly the wrong moment, because the moment you need it is a complaint under Art. 85 or a request for an explanation under Art. 86.

A log design that passes the reconstruction test records, per decision: a decision id, a timestamp, the model version and configuration, a reference to the inputs (or the inputs, subject to minimisation), the output and any score, the oversight event with the reviewer's identity and action, and the outcome. Seven fields. Most systems record two of them.

Art. 86, and why the trail is not optional

Art. 86 gives any person subject to a decision taken by a deployer on the basis of the output of an Annex III high-risk system — other than those listed in point 2 — and which produces legal effects or similarly significantly affects them adversely in a manner they consider to have an adverse impact on their health, safety or fundamental rights, the right to obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken.

You cannot produce that explanation from a log that records only "scored". The right to explanation is, in practice, a logging requirement.

Check yourself

1. A human approves every output, so Art. 14 is satisfied. — Which of the five Art. 14(4) capabilities does the approval step actually enable? A sign-off button enables none of them by itself.
2. Our override rate is zero, which shows the model is accurate. — Or that capability (d) does not exist. Zero override is a signal to investigate, not to celebrate.
3. We keep logs for six months. — Check sector law, which frequently requires longer, and check whether the six months of logs can reconstruct one decision end to end.
4. Oversight is assigned to the operations team. — Do they have the authority to overturn without escalation? Art. 26(2) requires competence, training and authority, in the Art. 99(4) band.

Next: Module 7 — Assurance: QMS, internal audit, conformity readiness →