Human oversight and logging: designing the Article 14 and Article 12 evidence

What it is#

Two AI Act articles carry the proof that a person, not a system, stayed in charge. A high-risk AI system is designed and developed, including with appropriate human-machine interface tools, so natural persons can effectively oversee it in use ¹. The same system technically allows automatic recording of events over its lifetime ².

Oversight is a design duty on the provider before an operating duty on the deployer. The deployer assigns oversight to natural persons with the necessary competence, training, authority and support. It keeps the automatically generated logs under its control for at least six months ³.

One loop, not three silos. Naming the overseer and settling what that person may do is governance. Setting the autonomy level, and the line past which an action cannot be undone, is risk. The assignment, the logs and the retention are what compliance shows.

Who is in scope (decision test)#

Five questions in order. The written answer is the record.

1. High-risk? Articles 12, 13 and 14 sit in Chapter III, Section 2, the high-risk requirements ⁴. Run the scope test first; AI literacy is owed either way ⁵.
2. Provider or deployer? The provider designs the oversight measures and the logging capability, and writes both into the instructions for use, the log mechanisms where relevant ⁶. The deployer runs them; the role belongs in the AI system register.
3. Does it act, or only advise? An agent holding tools and permissions changes the question, as Governing AI and agents sets out.
4. Which measures, and who holds them? Article 14(3) allows either or both: measures built in by the provider where technically feasible, and measures it identifies for the deployer to implement ⁷.
5. What do the logs allow, and for how long? Article 12(2) fixes the purposes, Articles 19(1) and 26(6) the floor ⁸.

Outcome	What it means	Next step
In scope	Oversight and logging are obligations	Assign the overseer; test the log
Out of scope	Article 4 literacy still binds	Record the reason, dated
Needs legal input	Class, role or two-person rule unclear	Written question, use case attached

Designing the oversight#

Oversight aims to prevent or minimise risks to health, safety or fundamental rights. Article 14(3) sizes the measures against the risks, the level of autonomy and the context of use ⁹. Autonomy is a risk decision; who holds the stop is a governance decision; the dated assignment and the exercised stop are what compliance produces.

Article 14(4) says what the assigned persons must be enabled to do, as appropriate and proportionate. Understand the system's capacities and limitations, and monitor it closely enough to catch anomalies, dysfunctions and unexpected performance. Stay aware of the tendency to over-rely on output, which the paragraph names automation bias. Interpret output correctly. Decide, in a given situation, not to use the system, or to disregard, override or reverse its output. Intervene or interrupt through a stop button, or a similar procedure that halts the system in a safe state ¹⁰.

Competence is a test, not a title, though Article 26(3) leaves the deployer free to organise its own resources ¹¹.

One class carries more. Remote biometric identification sits at Annex III, point 1(a). There the measures must also ensure the deployer takes no action or decision until at least two natural persons have separately verified and confirmed the identification. Those persons hold the necessary competence, training and authority. That falls away for law enforcement, migration, border control and asylum where Union or national law treats it as disproportionate ¹².

An agent is the hard case. OWASP gives excessive functionality, permissions and autonomy as the usual root causes of excessive agency ¹³. Its hidden context entry covers recovery of an assistant's instructions and tool schemas from outside ¹⁴. A person watching a dashboard is not the point (e) power to halt. It is built, held by a named role, and exercised.

Designing the logs#

Article 12(2) states what the logging capability must make possible. It records events relevant to spotting a situation that may result in an Article 79(1) risk, or a substantial modification. It serves post-market monitoring under Article 72 and deployer monitoring under Article 26(5) ¹⁵.

For Annex III, point 1(a) systems the minimum is printed. It covers the start and end date and time of each use, and the reference database checked against. It covers the input data whose search matched, and the persons identified as verifying the results ¹⁶.

Retention has two owners. The provider keeps the Article 12(1) logs under its control for a period appropriate to the intended purpose, at least six months ¹⁷. The deployer owes the same floor. Each yields only to other applicable Union or national law, data protection law above all.

ISO/IEC 27002:2022 control 8.15 Logging covers making event records, holding them safely and reading them, with generating evidence among its purposes ¹⁸. Control 8.16 Monitoring activities adds watching the estate for behaviour outside a baseline, and holding monitoring records for a defined period ¹⁹. Neither carries a statutory floor; Article 26(6) supplies one.

What a request will ask for. On a reasoned request from a competent authority, the provider supplies documentation showing conformity with Section 2. It also gives access to the Article 12(1) logs under its control ²⁰. GRCIDE's working view: a narrower test comes first. For one named use on one date, can the officer show who oversaw it, what it output, what the person did, and where that is written down.

Obligations table#

Paragraphs read as consolidated ²¹.

Duty	Article	Owed by	The record
Design for oversight; size measures to risk, autonomy, context	14(1), 14(3)	Provider	Oversight design, documented
Enable the five overseer powers	14(4)	Provider	Interface and stop, tested
Two-person verification before acting on an identification	14(5)	Provider, then deployer	Named verifiers per identification
State the oversight measures; log mechanisms where relevant	13(3)(d), (f)	Provider	Instructions for use
Record events automatically, for the three stated purposes	12(1), 12(2)	Provider	Logging design; event catalogue
Give an authority access to the logs	21(2)	Provider	Extract, on request
Use per the instructions; assign competent overseers	26(1), 26(2)	Deployer	Procedure; dated assignment
Monitor, inform and suspend on an Article 79(1) risk	26(5)	Deployer	Suspension record; notification
Keep the automatic logs, six months at least	19(1), 26(6)	Each, for its own	Retention tested

Dates (verified)#

The rest of the timetable is in the AI Act briefing.

Date	What happens	Source
2026-08-02	General application	22
2027-12-02	Chapter III Sections 1 to 3 for Article 6(2) systems, less Article 6(5)	23
2028-08-02	The same for Article 6(1) systems	24

Mapping to NIST AI RMF, ISO/IEC 42001 and 27002#

Identifiers as published ²⁵. Annex A numbers and titles come from the English text ²⁶. The method is in the ISO/IEC 42001 playbook.

Duty	NIST AI RMF 1.0	ISO/IEC 42001:2023	ISO/IEC 27002:2022	Gap
Assign the overseer	GOVERN 3.2 human-AI configurations	A.3.2 AI roles and responsibilities	5.2 Information security roles and responsibilities 27	Competence as a test
Define the oversight process	MAP 3.5 oversight processes	A.9.2 Processes for responsible use of AI systems	—	No statutory powers
Set what the overseer may do	MANAGE 2.4 supersede or deactivate	Annex B, B.9.3 oversight objectives 28	—	No halt in a safe state
Record and retain events	MANAGE 4.1 post-deployment monitoring	A.6.2.8 AI system recording of event logs	8.15 Logging	No lifetime scope or floor
Monitor the running system	MANAGE 4.1, above	A.6.2.6 AI system operation and monitoring	8.16 Monitoring activities	No Article 79(1) trigger
Hand the logs to an authority	—	A.6.2.7 AI system technical documentation	—	Documentation, not logs

Annex A wants event-log keeping on for named life-cycle phases, at least while the system runs ²⁹.

Next 90 days#

Week	Action	Owner	Output
1-2	List the high-risk rows; settle provider or deployer per row	AI governance owner	Triage rows closed
2-4	Name an overseer per system; extract the measures the deployer runs	AI governance owner	Dated assignments; measure list
4-6	Map each Article 14(4) power to a control; classify agent actions by reversibility	Risk owner	Powers map; action classes
6-8	Set the event catalogue against Article 12(2); set retention	Platform engineering	Retention evidenced
8-10	Rehearse the stop and the Article 26(5) suspension route	Incident manager	Exercise report, timed
10-12	Produce one authority-ready extract for a named use	Compliance owner	Extract, reviewed

Weeks 4 to 6 rest on Agent governance is a permissions problem; week 10 on GRC automation patterns.

References#

ISO/IEC material is paraphrased from licensed copies.

1. European Parliament and Council. Regulation (EU) 2024/1689, consolidated text of 27 July 2026. CELEX 02024R1689-20260727. Read 2026-09-05. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02024R1689-20260727
2. NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
3. OWASP GenAI Security Project. OWASP Top 10 for LLM Applications 2026. https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
4. ISO/IEC 42001:2023. https://www.iso.org/standard/42001
5. ISO/IEC 27002:2022. https://www.iso.org/standard/75652.html

Standards and certification names are the property of their respective owners. GRCIDE is an independent publication, not affiliated with, authorized, sponsored or endorsed by ISO, IEC, NIST, OWASP or any other standards body.