prEN 18229-3

• Abstract:

  This document provides terminology, concepts, requirements, and guidance for humanoversight of AI systems. It is primarily intended for organizations placing on the market or putting into service AI systems and is not specific to any particular sector;

• Status: Not Published
• Publication Date: 02-Jan-2028
• ICS: 01.040.35 - Information technology (Vocabularies)
• Technical Committee: CEN/CLC/JTC 21 - Artificial Intelligence
• Drafting Committee: CEN/CLC/JTC 21/WG 4 - Foundational and societal aspects
• Current Stage: 4020 - Submission to enquiry - Enquiry
• Start Date: 30-Jul-2026
• Due Date: 30-Nov-2026
• Completion Date: 30-Jul-2026
• Directive: Not Harmonized2024/1689 - EU AI Act
• Mandate: M/613 - Artificial Intelligence_Amd 1 to M/593
• Ref Project: oSIST prEN 18229-3:2026 - AI trustworthiness framework - Part 3: Human oversight

Overview

prEN 18229-3: AI Trustworthiness Framework – Part 3: Human Oversight is a draft European Standard developed by CEN, providing structured terminology, concepts, requirements, and guidance for human oversight in artificial intelligence (AI) systems. Focused on supporting compliance with Regulation (EU) 2024/1689 (EU AI Act), this standard is aimed primarily at organizations placing on the market or putting into service AI systems across any sector. Its goal is to help ensure the reliability, accountability, and safety of AI by specifying how human supervision can be integrated throughout the AI system’s lifecycle.

Key Topics

• Terminology and Definitions
  The document sets out shared terms related to AI, human oversight, and risk management, reflecting both EU legislative requirements and established international standards.

• Human Oversight Objectives
  Human oversight is defined as the technical and procedural conditions enabling designated persons to understand, monitor, supervise, and, when necessary, intervene in AI system operations. This helps in:

  • Monitoring for hazardous situations and preventing incidents
  • Identifying and addressing system misuse
  • Detecting bias or performance drift over time

• Integration with Risk Management
  Human oversight measures are designed based on risk management processes as described in prEN 18228. For every identified risk scenario, organizations must determine:

  • The possible consequences and hazards from AI system outputs
  • The reaction timeframe within which human intervention must occur
  • Appropriate technical and procedural controls, including specifying when real-time human intervention is feasible or not

• Oversight Measure Categories
  The framework distinguishes several types of oversight measures, including:

  • Retrospective review (post-hoc analysis)
  • Alert-triggered intervention (response to warnings or flags)
  • Continuous monitoring (ongoing supervision)

• Human Factors and Automation Bias
  Requirements include provisions to mitigate automation bias, ensuring individuals overseeing AI systems remain critical of automated recommendations and receive proper training.

• Documentation and Information Provision
  The standard prescribes documentation requirements-both technical and user-facing-to support transparency, oversight efficacy, and regulatory compliance.

Applications

This standard is essential for:

• AI System Providers: Organizations developing, marketing, or placing AI systems into service must implement and document adequate human oversight controls, allocating responsibilities between themselves and deployers.
• Deployers and Operators: Entities responsible for day-to-day system operation need actionable instructions and tools to fulfill their oversight obligations, as well as resources to train staff and monitor real-world AI system behavior.
• Compliance and Risk Officers: Ensuring processes align with the EU AI Act, particularly with reference to Article 14 on human oversight, and that records, procedures, and accountability measures can be demonstrated.
• Quality Management: Organizations can embed these oversight processes into their quality and risk management systems to facilitate ongoing safety, performance, and compliance monitoring.

Common sectors of application include, but are not limited to, healthcare, finance, industrial automation, security, and biometric identification-anywhere AI systems have potential impact on health, safety, or fundamental rights.

Related Standards

• prEN 18228 - AI Risk Management: Provides the risk management procedures that underpin the selection and implementation of human oversight measures.
• prEN 18229-1 - Logging: Addresses record-keeping requirements essential for retrospective oversight.
• prEN 18229-2 - Transparency: Specifies the information to be made available to deployers, supporting human oversight with necessary context and guidance.
• prEN 18229-4 - Accuracy & prEN 18229-5 - Robustness: Address related aspects of trustworthy AI system operation.
• ISO/IEC Standards: Including ISO/IEC 22989 (AI Definitions), and ISO/IEC TR 24027 (Bias in AI systems) for broader context on terminology and risk.

By implementing prEN 18229-3, organizations demonstrate commitment to AI trustworthiness, regulatory alignment, and responsible innovation-ensuring AI systems remain subject to effective, well-documented human oversight at every stage.

SLOVENSKI STANDARD
01-september-2026
Okvir zaupanja v umetno inteligenco - 3. del: Človeški nadzor
AI trustworthiness framework - Part 3: Human oversight
Framework für Vertrauenswürdigkeit von Künstlicher Intelligenz - Teil 3: Transparenz
und menschliche Aufsicht
Ta slovenski standard je istoveten z: prEN 18229-3
ICS:
01.040.35 Informacijska tehnologija. Information technology
(Slovarji) (Vocabularies)
35.020 Informacijska tehnika in Information technology (IT) in
tehnologija na splošno general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD DRAFT
NORME EUROPÉENNE
EUROPÄISCHE NORM
July 2026
ICS 35.240.01
English version
AI trustworthiness framework - Part 3: Human oversight
Framework für Vertrauenswürdigkeit von Künstlicher
Intelligenz - Teil 3: Transparenz und menschliche
Aufsicht
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/CLC/JTC 21.
If this draft becomes a European Standard, CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal
Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any
alteration.
This draft European Standard was established by CEN and CENELEC in three official versions (English, French, German). A
version in any other language made by translation under the responsibility of a CEN and CENELEC member into its own language
and notified to the CEN-CENELEC Management Centre has the same status as the official versions.

CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and United Kingdom.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.Recipients of this draft are invited to submit, with their comments, notification
of any relevant patent rights of which they are aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.

CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2026 CEN/CENELEC All rights of exploitation in any form and by any means
Ref. No. prEN 18229-3:2026 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Contents Page
European foreword . 4
Introduction . 5
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 7
3.1 Terms relating to the EU AI Act . 7
3.2 Terms relating to AI systems . 8
3.3 Terms related to risk management and quality management . 10
3.4 Terms related to human oversight . 11
4 Abbreviations . 13
5 Human oversight . 13
5.1 Objectives . 13
5.2 Risk-management integration . 13
5.2.1 Identification of risk scenarios . 13
5.2.2 Reaction timeframe . 14
5.2.3 Selection and documentation of measures. 14
5.2.4 Technical infeasibility of real-time human intervention . 14
5.2.5 Overload and conflict . 15
5.2.6 Review of oversight assignments . 15
5.3 Human oversight measure categories . 15
5.3.1 General. 15
5.3.2 Retrospective review measures . 15
5.3.3 Alert-triggered intervention measures . 17
5.3.4 Continuous monitoring measures . 18
5.4 Specification of deployer-implemented oversight measures . 20
5.4.1 Conditions for deployer-implemented measures and documentation . 20
5.4.2 Limitations on residual risk . 21
5.4.3 Specifications for deployer-implemented notifications . 21
5.5 Automation bias and human factors . 21
5.5.1 Awareness of automation bias . 21
5.5.2 Testing for automation bias . 21
5.6 Interpretation of outputs and interpretation tools . 22
5.6.1 Output interpretation support for designated persons . 22
5.6.2 Training material for designated persons . 22
5.7 Functional requirements for designated person intervention functions . 22
5.7.1 General. 22
5.7.2 Disregard . 23
5.7.3 Override . 23
5.7.4 Reverse . 23
5.7.5 Safe state transition . 23
5.8 RBI systems - human oversight requirements . 24
5.8.1 Technical prevention of unreviewed identification outputs . 24
5.8.2 Review process and interface requirements . 25
5.8.3 Manual reviewer independence mechanisms . 26
5.8.4 Documentation requirements . 26
5.8.5 Manual reviewer competency requirements . 26
6 Documentation . 27
6.1 Instructions for use . 27
6.2 Technical documentation . 27
Annex ZA (informative) Relationship between this European Standard and the essential
requirements of Regulation (EU) 2024/1689 aimed to be covered . 28
Bibliography . 29
European foreword
This document (prEN 18229-3:2026) has been prepared by Technical Committee JTC 21 “Artificial
Intelligence”, the secretariat of which is held by DS.
This document is currently submitted to the CEN Enquiry.
This document has been prepared under a Standardization request addressed to CEN-CENELEC by the
European Commission. The Standing Committee of the EFTA States subsequently approves these
requests for its Member States.
For relationship with EU Legislation, see informative Annex ZA, which is an integral part of this
document.
Introduction
0.1 General
This document specifies requirements for human oversight of AI systems, in support of compliance with
Regulation (EU) 2024/1689 (the EU AI Act). Annex ZA shows how the document supports Article 14 of
the Regulation (EU) 2024/1689.
This document is part of the AI trustworthiness framework series: prEN 18229-1:— addresses record-
keeping (Article 12), prEN 18229-2:— transparency and the provision of information to deployers
(Article 13), prEN 18229-4:— accuracy and prEN 18229-5:— robustness (Article 15 except
cybersecurity).
The risks that human oversight addresses are identified, estimated and evaluated through the risk
management process specified in prEN 18228:— for each risk scenario identified through the risk
management process, the provider determines a reaction timeframe, and that timeframe drives the
selection of the human oversight measure categories and of the intervention functions made available
to designated persons. The requirements of this document address the provider of the AI system;
obligations that depend on the deployment context are conveyed to the deployer through the
instructions for use specified in prEN 18229-2:—. The information addressed in this document is the
subset necessary to enable and support human oversight; the general transparency information
provided to deployers is specified in prEN 18229-2:— in support of the Regulation (EU) 2024/1689.
Record keeping supporting oversight relies on prEN 18229-1:—. The human oversight measure
categories specified in 5.3 address the information conditions of oversight (monitoring and the
interpretation of outputs); the intervention functions specified in 5.7 address the control conditions
(disregard, override, reverse and the transition to the safe state).
The evidence generated in designing and verifying those measures is recorded in the technical
documentation of this document (Clause 6), while the risk management file (prEN 18228:—, 4.6)
remains the home of the risk determinations on which those measures are calibrated. The design,
verification and modification of the human oversight measures, and the monitoring of their
effectiveness after the AI system is placed on the market, are governed by the provider’s quality
management system in accordance with EN 18286:2026 (Article 17); the risk management process of
prEN 18228:— (Article 9) calibrates the measures through the reaction timeframe; this document
specifies the measures themselves.
The allocation of responsibilities in this document is intended to reflect the distinction between
provider and deployer obligations set out in Regulation (EU) 2024/1689, under Article 14. The
requirements upon the provider in this document relate to the design and development of the AI
system, including the design of human oversight measures and the provision of information to
deployers. Where provisions in this document refer to outcomes that depend on deployer
implementation, such provisions can be understood as requiring the provider to design and provide for
those outcomes within the scope of the provider’s control at the time of placing on the market, and
based on the assumptions documented for the intended purpose and use.
Subclause 5.1 establishes the objectives of human oversight and identifies the parties to whom they are
addressed.
Subclause 5.2 specifies the procedure by which the provider integrates human oversight into the risk
management process: the identification of risk scenarios, the determination of the reaction timeframe,
the selection and documentation of measures, the treatment of technical infeasibility, and the review of
oversight assignments.
Subclause 5.3 specifies the requirements for each human oversight measure category: retrospective
review measures (5.3.2), alert-triggered intervention measures (5.3.3) and continuous monitoring
measures (5.3.4).
Subclause 5.4 specifies the deployer-implemented human oversight measures and the information on
those measures to be provided in the instructions for use in accordance with prEN 18229-2:—, 6.1.
Subclause 5.5 specifies the requirements and recommendations addressing automation bias and human
factors.
Subclause 5.6 specifies the requirements enabling designated persons to interpret the outputs of the AI
system, in connection with the transparency mechanisms selected in accordance with prEN 18229-2:—,
5.2.
Subclause 5.7 specifies the functional requirements for the designated person intervention functions,
including the stop procedure implemented through the safe state.
Subclause 5.8 specifies the human oversight requirements for remote biometric identification systems.
Clause 6 specifies the recording of evidence produced under Clause 5 in the instructions for use and the
technical documentation.
0.2 Verbal forms
In this document, the following verbal forms are used:
— “shall” indicates a requirement;
— “should” indicates a recommendation;
— “may” indicates a permission;
— “can” indicates a possibility or a capability.
1 Scope
This document provides terminology, concepts, requirements, and guidance for human oversight of AI
systems.
It is primarily intended for organizations placing on the market or putting into service AI systems and is
not specific to any particular sector.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
prEN 18228:—, AI Risk Management
prEN 18229-1:—, AI trustworthiness framework – Part 1: Logging
prEN 18229-2:—, AI trustworthiness framework – Part 2: Transparency
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp/
— IEC Electropedia: available at https://www.electropedia.org/
3.1 Terms relating to the EU AI Act
3.1.1
provider
natural or legal person, public authority, agency or other body that develops an AI system (3.2.1) or a
general-purpose AI model or that has an AI system (3.2.1) or a general-purpose AI model developed and
places it on the market or puts the AI system (3.2.1) into service under its own name or trademark,
whether for payment or free of charge
[SOURCE: EU AI Act 2024/1689, (Article 3(3)), modified – removed “a”]
3.1.2
deployer
natural or legal person, public authority, agency or other body using an AI system (3.2.1) under its
authority except where the AI system (3.2.1) is used in the course of a personal non-professional activity
[SOURCE: EU AI Act 2024/1689, (Article 3(4)), modified – removed “a”]

Under preparation. Stage at time of publication, Enquiry
Under preparation. Stage at time of publication, Enquiry
Under preparation. Stage at time of publication, Working Draft
3.1.3
post-market monitoring system
all activities carried out by providers of AI systems to collect and review experience gained from the use
of AI systems they place on the market or put into service for the purpose of identifying any need to
immediately apply any necessary corrective or preventive actions
[SOURCE: EU AI Act 2024/1689, (Article 3(25)), modified – removed “means”]
3.1.4
instructions for use
information provided by the provider (3.1.1) to inform the deployer (3.1.2) of, in particular, an AI system
(3.2.1) ’s intended purpose (3.2.2) and proper use
[SOURCE: EU AI Act 2024/1689, (Article 3(15)), modified – removed “means the”]
3.2 Terms relating to AI systems
3.2.1
AI system
machine-based system that is designed to operate with varying levels of autonomy and that can exhibit
adaptiveness after deployment and that, for explicit or implicit objectives, infers, from the input it
receives, how to generate outputs such as predictions, content, recommendations, or decisions that can
influence physical or virtual environments
Note 1 to entry: The verb “can” represents a possibility, not all AI systems that fit the above definition have this
ability to adapt after deployment.
[SOURCE: EU AI Act (Article 3(1)), modified – “a” has been removed, “may” replaced with “can” based
on the use of verbs in standards; Note 1 to entry added.]
3.2.2
intended purpose
use for which an AI system (3.2.1) is intended by the provider (3.1.1), including the specific context and
conditions of use, as specified in the information supplied by the provider (3.1.1) in the instructions for
use (3.1.4) promotional or sales materials and statements, as well as in the technical documentation
[SOURCE: EU AI Act 2024/1689, (Article 3(12)), modified – removed “means the”]
3.2.3
performance
ability of an AI system (3.2.1) to achieve its intended purpose (3.2.2)
[SOURCE: EU AI Act 2024/1689, (Article 3(18)), modified – removed “the”]
3.2.4
training data
data used for training an AI system (3.2.1) through fitting its learnable parameters
[SOURCE: EU AI Act 2024/1689, (Article 3(29)), modified – removed “means”]
3.2.5
input data
data provided to or directly acquired by an AI system (3.2.1) on the basis of which the system produces
an output
[SOURCE: EU AI Act 2024/1689, (Article 3(33)), modified – removed “means”]
3.2.6
personal data
information relating to an identified or identifiable natural person (‘data subject’); an identifiable
natural person is one who can be identified, directly or indirectly, in particular by reference to an
identifier such as a name, an identification number, location data, an online identifier or to one or more
factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of
that natural person
[SOURCE: Regulation (EU) 2016/679, Article 4(1), modified – removed “any”]
3.2.7
biometric data
personal data (3.2.6) resulting from specific technical processing relating to the physical, physiological
or behavioural characteristics of a natural person, such as facial images or dactyloscopic data
[SOURCE: EU AI Act 2024/1689, (Article 3(34)), modified – removed “means”]
3.2.8
biometric probe
biometric sample or biometric feature set input to an algorithm for comparison to a biometric
reference(s)
Note 1 to entry: In some comparisons a biometric reference can potentially be used as the subject of the
comparison with other biometric references or incoming biometric samples used as the objects of the
comparisons.
Note 2 to entry: Typically, in a comparison process, incoming biometric samples serve as the subject of
comparisons against objects stored as biometric references in a database.
[SOURCE: ISO/IEC 2382-37:2022, 37.03.14]
3.2.9
remote biometric identification system
AI system (3.2.1) for the purpose of identifying natural persons, without their active involvement,
typically at a distance through the comparison of a person’s biometric data (3.2.7) with the biometric
data (3.2.7) contained in a reference database
[SOURCE: EU AI Act 2024/1689, (Article 3(41)), modified – removed “means an”]
3.2.10
critical infrastructure
asset, facility, equipment, network or system, or part of an asset, facility, equipment, network or system,
which is necessary for the provision of an essential service (3.2.11)
[SOURCE: EU AI Act 2024/1689, (Article 3(62)), and Directive (EU) 2022/2557, (Article 2(4)), modified
– removed “means an” and the indefinite articles]
3.2.11
essential service
service which is crucial for the maintenance of vital societal functions, economic activities, public health
and safety, or the environment
[SOURCE: Directive (EU) 2022/2557, Article 2(4)]
3.2.12
safe state
predefined state that can be triggered either by the designated person or automatically by the AI system
(3.2.1), based on the AI system (3.2.1), hazard (3.3.2), level of risk and intended use
Note 1 to entry: The purpose of the safe state is to mitigate risks to health, safety and fundamental rights.
3.3 Terms related to risk management and quality management
3.3.1
harm
injury or damage to health of a person or groups of persons, or interference with fundamental rights
Note 1 to entry: For the purpose of this document, damage to property or the environment, and the disruption or
destruction of critical infrastructure (3.2.10), are considered harms when they directly result in injury or damage
to the health of a natural person or groups of persons or infringement of obligations under Union law intended to
protect fundamental rights.
Note 2 to entry: Failure to meet fundamental rights obligations can result in tangible or intangible, physical,
psychological, societal or economic harm, irrespective of the rightsholder’s awareness
Note 3 to entry: Safety in product safety risk management standards is understood as the absence of
unacceptable risk. In the context of this document, safety refers to the protection from harm from the use of the AI
system (3.2.1).
[SOURCE: prEN 18228:—, 3.6.3]
3.3.2
hazard
potential source of harm (3.3.1)
Note 1 to entry: Threats and vulnerabilities to the AI system (3.2.1) itself are hazards only if they are themselves a
source of harm (3.3.1).
[SOURCE: ISO/IEC Guide 51:2014, 3.2]
3.3.3
hazardous situation
circumstance in which people, property or the environment is/are exposed to one or more hazard
(3.3.2)
[SOURCE: ISO/IEC Guide 51:2014, 3.4]
3.3.4
reasonably foreseeable misuse
use of an AI system (3.2.1) in a way that is not in accordance with its intended purpose (3.2.2) but which
can result from readily predictable human behaviour or interaction with other systems, including other
AI systems
Note 1 to entry: Readily predictable human behaviour includes the behaviour of all types of users, e.g. lay and
professional users, consumers, older adults, children, and persons with disabilities. For more information, see
ISO 10377:2013.
Note 2 to entry: Reasonably foreseeable misuse can be intentional or unintentional.
[SOURCE: EU AI Act 2024/1689, (Article 3(13)), and Directive (EU) 2022/2557, (Article 2(4)), modified
– removed “means the”]
3.3.5
AI system presenting a risk
product presenting a risk
product having the potential to affect adversely health and safety of persons in general, health and
safety in the workplace, protection of consumers, the environment, public security and other public
interests, protected by the applicable Union harmonisation legislation, to a degree which goes beyond
that considered reasonable and acceptable in relation to its intended purpose (3.2.2) or under the
normal or reasonably foreseeable conditions of use of the product concerned, including the duration of
use and, where applicable, its putting into service, installation and maintenance requirements
Note 1 to entry: For the purposes of this document, AI systems presenting a risk shall only be insofar as they
present risks to the health or safety, or to fundamental rights, of persons.
[SOURCE: Regulation 2019/1020, Article 3(19)]
3.4 Terms related to human oversight
3.4.1
usability
characteristic of the user interface that facilitates use and thereby establishes use effectiveness, use
efficiency and user satisfaction in the intended use environment
Note 1 to entry: All aspects of usability, including use effectiveness, use efficiency and user satisfaction, can either
increase or decrease safety.
[SOURCE: EN ISO 20417:2021, 3.45]
3.4.2
usability test
method for exploring or evaluating a user interface with intended users within a specified intended use
environment
[SOURCE: IEC 62366-1:2015, 3.19]
3.4.3
designated persons
natural persons who have been ascribed the role, responsibility, function or delegated authority on
behalf of the deployer (3.1.2) to conduct human oversight of an AI system (3.2.1)
Note 1 to entry: The designated persons correspond to the natural persons to whom human oversight is assigned
under Article 14(1) of Regulation (EU) 2024/1689.
3.4.4
automation bias
propensity for humans to favour suggestions from automated decision-making systems and to ignore
contradictory information made without automation, even if it is correct
Note 1 to entry: Automation bias can have a significant effect on decisions impacting health, safety, or the
obligations under Union law intended to protect fundamental rights.
[SOURCE: ISO/IEC TR 24027:2021, 3.2.1 modified – Note to entry added]
3.4.5
cognitive workload
physical and cognitive demands placed on the system user(s) or staff
[SOURCE: EN ISO 11064-7:2006, 3.9]
3.4.6
user interface
UI
set of all the components of an interactive system that provide information and controls for the user to
accomplish specific tasks with the interactive system
Note 1 to entry: In this document the user interface includes the human-machine interface tools referred to in
Article 14(1) of Regulation (EU) 2024/1689.
[SOURCE: ISO 9241-110:2020, 3.10]
3.4.7
risk scenario
combination of an AI system output, the associated hazardous situation and the causal chain leading to
harm, identified at the logical or functional level
[SOURCE: prEN 18228:—, 6.2.4]
3.4.8
reaction timeframe
maximum time available for a designated person to react after the AI system produces an output
associated with the identified hazardous situation and before the harm occurs, with measures to
prevent or mitigate that harm
3.4.9
retrospective oversight
oversight exercised after the output is produced, by examination of recorded outputs and associated
data
Note 1 to entry: Term defined in this document; the real-time and retrospective distinction is discussed in
ISO/IEC FDIS 42105:—, 8.1
3.4.10
minimum human intervention time
minimum time within which a human intervention in response to a given hazardous situation can be
both initiated under operational conditions, such that the measures to prevent or mitigate the harm
take effect
Note 1 to entry: The minimum human intervention time and the reaction timeframe (5.2.2) share the same
terminal event, i.e. the point at which the measures to prevent or mitigate the harm take effect. Where the reaction
timeframe is shorter than the minimum human intervention time, real-time human intervention is technically
infeasible and 5.2.4 applies.
Note 2 to entry: The minimum human intervention time is the capability floor for a given risk scenario and
operational context. The reaction timeframe is the available window. The two are commensurable only because
both are measured to mitigation taking effect and not to the initiation of a response.
Note 3 to entry: The minimum human intervention time is distinct from the time-to-intervention metric (5.3.4.5
b), which measures the interval to the designated person initiating a response, and from intervention response
latency (5.7.1), which is a system property, i.e. the latency of the intervention function once triggered.
4 Abbreviations
HMI human-machine interface
5 Human oversight
5.1 Objectives
Human oversight refers to the technical and procedural conditions under which a designated person
can understand, supervise, and, where necessary, intervene in the functioning of an AI system.
NOTE 1 Human oversight can be designed to achieve the following objectives: monitoring of hazardous
situations that can potentially lead to unacceptable risk, as identified in the risk management process conducted
in accordance with prEN 18228:—, 6.2.4; identification of situations that can potentially lead to the AI system
presenting a risk (3.3.5) during operation; prevention of incidents through timely intervention by a designated
person.
NOTE 2 Human oversight can additionally support monitoring of normal system performance over time,
including detection of emerging bias or performance drift not captured at the level of individual inferences. See
5.3.4 for retrospective review requirements relevant to this function.
NOTE 3 Human oversight can also be a key task for the deployer who operates the AI system within the
conditions of its intended purpose set out in the instructions for use. Where the provider identifies reasonably
foreseeable misuse, human oversight measures can be designed to detect and respond to such patterns.
NOTE 4 Human oversight complements inherently safe design and protective measures as a risk control
measure within the hierarchy established by prEN 18228:—, 9.1. It does not substitute for technical risk controls
where those are feasible and sufficient.
NOTE 5 ISO/IEC FDIS 42105:— also addresses human oversight of AI systems and can inform the
implementation of the measures of this document; pointers are given at 5.2.4, 5.3.4.2, 5.5.1 and 5.7.1.
ISO/IEC FDIS 42105:— is not a harmonized standard and is referred to informatively only. It uses the terminology
of EN ISO/IEC 22989 and ISO/IEC TS 8200 and a different stakeholder taxonomy (for example AI customer, AI
developer, human oversight supervisor), and it frames human oversight as the protection of business objectives
and as a risk-mitigation activity that renders risk tolerable. This document is anchored in Regulation (EU)
2024/1689, whose objective is the prevention or minimization of risks to health, safety and fundamental rights;
that conception of risk, and the provider and deployer roles of the Regulation, prevail.
5.2 Risk-management integration
5.2.1 Identification of risk scenarios
The provider shall, in accordance with prEN 18228:—, 6.2.4, identify the risk scenarios at the logical or
functional level where the output of the AI system can lead to harm and where human oversight
measures are required to prevent or mitigate that harm.
NOTE 1 Risk scenarios are identified at the logical or functional level, that is, in terms of the type of AI output,
the associated hazardous situation, and the causal chain leading to harm, rather than at the level of individual
concrete deployment instances.
NOTE 2 Collaboration with the type of deployer for which the AI system is intended, as fixed by the intended
purpose (3.2.2) and receiving input from the deployer can be important for the identification of risk scenarios for
human oversight, as reported in prEN 18228:—, 6.2.1.
5.2.2 Reaction timeframe
For each risk scenario identified in accordance with 5.2.1, the provider shall determine the reaction
timeframe (3.4.8), taking into account risk acceptability criteria in accordance with prEN 18228:—, 4.4.
NOTE 1 The reaction timeframe is determined by the provider from the characteristics of the risk scenario,
namely the output type, the hazardous situation, the causal chain to harm and the estimated severity and
exposure, as described in the risk scenario analysis conducted in accordance with prEN 18228:—, 6.2.4. The
reaction timeframe is expressed as a duration. Where risk estimation under prEN 18228:—, 6.3 is qualitative, the
timeframe can be given as a bounded range or ordinal band (e.g. seconds, minutes, hours).
NOTE 2 Reaction timeframes vary widely across AI system types and deployment contexts. For some AI
systems the reaction timeframe is measured in milliseconds; for others, in hours or days. The reaction timeframe
is the primary criterion for selecting the type of oversight measures adequate for each risk scenario.
5.2.3 Selection and documentation of measures
For each risk scenario identified in accordance with 5.2.1, the provider shall select human oversight
measures that enable the designated person to perform the required intervention within the reaction
timeframe defined in accordance with 5.2.2, and shall document in the risk management file
(prEN 18228:—, 4.6) the risk scenario, the reaction timeframe, the measures selected, and the
justification for the adequacy of those measures given the reaction timeframe.
The provider shall select at least one measure per risk scenario, and the measures selected shall be
collectively sufficient to enable the required intervention within the reaction timeframe; where no
single category achieves this, measures from more than one category shall be combined, and where
none can, 5.2.4 applies.
NOTE The adequacy of measures is assessed against the reaction timeframe. The selection draws from the
measure categories described in 5.3. A provider can combine measures from multiple categories for a single risk
scenario where the reaction timeframe and the nature of the hazardous situation warrant it.
5.2.4 Technical infeasibility of real-time human intervention
Where the reaction timeframe for a risk scenario is shorter than the minimum time within which any
human intervention could be initiated and completed under realistic operational conditions, the
provider shall record in the risk management file the minimum human intervention time, the reaction
timeframe, the basis for finding the former exceeds the latter, and the resulting automated protective
and retrospective measures, shall apply automated protective measures in accordance with
prEN 18228:—, 9.1, and shall apply retrospective oversight measures in accordance with 5.3.2.
NOTE 1 Contexts in which real-time human intervention can be technically infeasible include AI systems
operating at millisecond-range decision speeds, AI systems embedded in physical processes that continue to act
without waiting for human input (e.g. motion control, robotic actuation, closed-loop industrial control), and AI
systems where the designated person is not continuously co-located with the operational process. In all such
cases, retrospective oversight under 5.3.2 applies.
NOTE 2 The IEC 62366 model of the human-AI interaction loop identifies three distinct failure modes in the
oversight chain: error in perception, error in cognition, and use error at the action stage. Where the reaction
timeframe is shorter than the minimum time for any human loop completion, no measure addressing these failure
modes can prevent the hazardous situation before it materialises. Automated protective measures and
retrospective oversight are then the only coherent residual path.
NOTE 3 An oversight assignment that confers responsibility on a designated person without the information
and intervention capability needed to discharge it does not constitute a risk control measure. The determination
under this subclause, together with 5.2.5, excludes such configurations: where real-time intervention is technically
infeasible, the risk is treated through other measure categories or through the risk management process, not
through nominal oversight.
NOTE 4 ISO/IEC FDIS 42105:—, Annex A, describes factors that can limit the feasibility of human oversight,
grouped into AI system design, human factors, and systemic and societal factors. The determination of technical
infeasibility under this subclause remains governed by the reaction timeframe of 5.2.2 and by Article 14 of
Regulation (EU) 2024/1689.
5.2.5 Overload and conflict
When a single designated person is responsible for overseeing outputs from multiple AI system risk
scenarios, the provider shall demonstrate and justify in the technical documentation (6.2) that the
designated person is able to monitor without cognitive overload or conflict.
NOTE 1  Hazards introduced by assigning humans to oversight roles can include physiological factors such as
fatigue and decreased vigilance, and cognitive factors such as attention deficit, variability in assessment
consistency, reaction time limitations, and automation bias. These hazards are identified as part of the risk
management process in accordance with prEN 18228:—, 6.2.4.
5.2.6 Review of oversight assignments
The provider shall review the risk scenarios, reaction timeframes, and selected measures when analysis
under the post-market monitoring system (see EN 18286:2026, 9.5) or design modifications alter the
identified risks or their required human oversight measures, in accordance with prEN 18228:—,
Clause 11.
5.3 Human oversight measure categories
5.3.1 General
The measures identified in accordance with 5.2 shall be selected from, or designed to satisfy the criteria
of, the measure categories described in 5.3.2, 5.3.3, and 5.3.4. The adequacy criterion in all cases is
whether the selected measures enable the designated person to perform the required intervention
within the reaction timeframe determined in accordance with 5.2.2. For each risk scenario, the provider
shall select the category or categories whose combined effect enables the required intervention within
the reaction timeframe. Where the measure that meets the reaction timeframe is a retrospective one, it
is selected in accordance with 5.3.2. Where no combination of measures can meet the reaction
timeframe, the automated protective measures of 5.2.4 apply.
The three categories differ in when oversight acts in relation to the output of the AI system:
retrospective review measures (5.3.2) provide for the examination of outputs after they are produced;
alert-triggered intervention measures (5.3.3) prompt the designated person to act at defined points
during operation; and continuous monitoring measures (5.3.4) provide for oversight throughout
operation.
NOTE 1 The measure categories describe configurations of oversight measures available to the provider. They
are not mutually exclusive classifications to which the AI system as a whole is assigned. A single AI system can
carry different measure configurations for different risk scenarios.
NOTE 2 For short reaction timeframes, continuous monitoring measures or alert-triggered measures with pre-
configured intervention capability are typically required. For long reaction timeframes, retrospective review
measures can be sufficient. Where the reaction timeframe is shorter than any human intervention window, 5.2.4
applies.
5.3.2 Retrospective review measures
5.3.2.1 Interface requirements
Where the provider selects retrospective review measures in accordance with 5.3.1, or where 5.2.4
applies, the AI system shall be designed with a review interface containing all relevant data for
retrospective evaluation and risk mitigation, taking into account the intended purpose, including at
minimum the following:
a) a log of the outputs of the AI system, with timestamps, in accordance with the logging requirements
of prEN 18229-1:—, 5.5;
b) the input data associated with each output of the AI system;
c) any associated confidence or scoring values;
d) any alarms, warnings, or anomaly detections related to that output;
e) the version of the AI system used at the time of the output.
The provider shall design and embed a functionality that enables designated persons to add any
information to the retrospective review interface logs.
NOTE The designated person can record information about the operating environment at the time an output
was generated that is not directly captured by the system logs.
The interface shall provide the contextual information to enable the designated person to evaluate
whether system behaviour was within expected operational bounds and to understand the output
context.
5.3.2.2 Design parameters
The provider shall determine, based on the foreseeable hazards and level of risk identified in the risk
management process conducted in accordance with prEN 18228:—, 6.2.4 and 6.3, and taking into
account technical feasibility, the following design parameters:
a) retention duration and accessibility of decision records and logs, cons
...