ISO/IEC FDIS 24970

ISO/IEC JTC 1/SC 42/WG 1
Secretariat: ANSI
Date: 2026-04-2708-03
Artificial intelligence — AI system logging

Intelligence artificielle — Journalisation d'événements des systèmes d'IA
FDIS stage
Warning for WDs and CDs
TThis drhis drafaft is t is submitted tsubmitted too a a p paraarallllel el votvote e in in ISO,ISO, CEN. CEN.
This document is not an ISO International Standard. It is distributed for review and comment. It is subject to
change without notice and may not be referred to as an International Standard.
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.
© ISO/IEC 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication
may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying,
or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO
at the address below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
EmailE-mail: copyright@iso.org
Website: www.iso.orgwww.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
Contents
Foreword . iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 5
5 Logging and use of logs . 5
5.1 AI system logs . 5
5.2 Logging components . 6
5.3 Logging in context . 7
5.4 Log entries . 8
5.5 AI system logging . 9
5.6 Events . 109
5.7 General requirements . 1110
6 Design of the logging system . 1211
6.1 General . 1211
6.2 Traceability . 1312
6.3 Additional functions . 1312
6.4 Anomaly monitoring of the logging component . 1312
6.5 Technical documentation . 13
7 Implementation and testing. 1413
8 Triggers for logging . 1514
8.1 General . 1514
8.2 Triggers from operation . 1514
8.3 Triggers from automated monitoring . 16
8.4 Triggers indicating substantial modification . 2019
8.5 Triggers from human oversight . 2120
9 Information to log . 2221
9.1 Required information . 2221
9.2 Recommended information . 2322
10 AI system log storage and access . 2322
10.1 General . 2322
10.2 Requirements for third party access . 23
10.3 Access for AI users . 2423
10.4 Access for AI providers . 2423
10.5 Storage infrastructure implementation . 2423
10.6 Access control and access mechanisms . 2524
11 Continual improvement . 2524
Annex A (informative) Information model . 2625
Bibliography . 3129

© ISO /IEC 2026 – All rights reserved
iiiiii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent rights
in respect thereof. As of the date of publication of this document, ISO had not received notice of a patent which
may be required to implement this document. However, implementers are cautioned that this may not
represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee
SC 42, Artificial intelligence, in collaboration with the European Committee for Standardization (CEN)
Technical Committee CEN/CLC/JTC 21, Artificial Intelligence, in accordance with the Agreement on technical
cooperation between ISO and CEN (Vienna Agreement).
Formatted: Font: (Asian) Japanese
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
© ISO/IEC 2026 – All rights reserved
iv
Introduction
AI systems can log a wide range of events during various phases of the life cycle. While some aspects of logging
can be defined in advance — based on the system’s known purpose and operating context — real-world needs
often emerge only after deployment. In practice, AI developers and AI stakeholders cannot fully know what is
important to log until the system is running. Additionally, the relevance of logged events is not fixed. Relevance
can shift over time due to changing AI user needs, operational conditions or even interactions with other AI
systems. However, it is often unclear whether AI systems can adapt their logging practices themselves, or
whether human intervention is required to reconfigure logging as contexts evolve. This raises important
considerations for auditability, transparency and long-term AI system oversight.
AI system logs have the potential to support both operational tasks, such as system monitoring or
troubleshooting, and management system-level functions, provided the logs are accessible, well-structured
and aligned with the specific needs of AI stakeholders. When logs are properly collected, maintained and
analyzed, they can inform activities such as alignment with the strategic direction of the organization, real-
time monitoring, decision-making and continual improvement. However, the effectiveness of those activities
depends on the quality of the logged data, appropriate access controls, the organization’s analytical
capabilities, and ability to understand how logged events relate to objectives, risks or opportunities.
Leveraging logs can contribute to cost reduction, risk mitigation and compliance, if organizations have the
appropriate tools and processes in place to interpret and act on the data and if logs are designed to consider
compliance obligations, including statutory, regulatory and contractual obligations, as well as other
organizational requirements.
When logs are systematically collected, structured and analyzed, they can provide valuable insights that help
organizations and AI stakeholders better understand and respond to unexpected events or changing
conditions. The effectiveness of such response can require real-time or near-real-time access to logs or
warrant asynchronous access depending on the context. Logs can also support the iterative development and
refinement of AI systems by highlighting effectiveness and efficiency issues or emerging patterns not
noticeable during initial training or deployment. To contribute meaningfully to continuous improvement
throughout the AI system life cycle, logs can be contextually rich, validated, securely stored and reviewed
considering the needs and expectations of AI stakeholders and of the organization.
Logging activities present their own complexity and costs, and can reduce the performance and increase the
footprint of the AI system, so there are considerations on the effectiveness and efficiency of logging to answer
oversight and management needs.
This document content is structured as follows:
— Clause 55Clause 5 outlines logging and the use of logs, and provides general requirements for logging;
— Clause 66Clause 6 provides requirements and guidance for design, including traceability;
— Clause 77Clause 7 provides requirements for implementation and testing;
— Clause 88Clause 8 details the triggers for logging in four categories: operation, automated monitoring,
detecting substantial modification and human oversight.
— Clause 99Clause 9 contains requirements and guidance for information to include in the logs;
— Clause 1010Clause 10 contains requirements for storing and access to logs;
— Clause 1111Clause 11 contains requirements for continual improvement;
— Annex AAnnex AAnnex A gives an example of an information model and data structure that can be used
for AI system logging.
© ISO /IEC 2026 – All rights reserved
vv
Artificial intelligence — AI system logging
1 Scope
This document describes common capabilities and provides requirements for logging of events in AI systems.
2 Normative references
There are no normative references in this document.
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
log
management object that is organized by log entries (3.23.2)
Note 1 to entry: A log is a formally controlled record maintained to ensure traceability, accountability, and governance of
AI system operations.
Note 2 to entry: In the context of Al system, logs can consist of structured, semi-structured, or unstructured data, and can
originate from the Al system under consideration, its internal components, interacting Al systems, AI users or interested
parties (3.153.15), whether human or automated, operating outside the AI system boundary.
Note 3 to entry: In the context of AI system, logs can be generated continuously, periodically or in response to specific
conditions, and can serve a range of purposes including system monitoring (3.83.8), debugging, auditing, compliance,
human oversight, iterative system improvement or accountability.
3.2
log entry
discrete unit of information that captures a specific event, condition, state, input, output, decision or
contextual data related to functioning or environment
Note 1 to entry: A log entry can include, but is not limited to, information related to event, state, or other data associated
with system operation.
Note 2 to entry: Log entries are composed of a combination of metadata, including timestamps, source identifiers, and
severity levels and content-specific data relevant to the purpose of a log.
Note 3 to entry: Log entries are structured (e.g. a JSON object), semi-structured (e.g. textual annotations) or free-form
(e.g. screenshots).
Note 4 to entry: Log entries vary in structure and content depending on the type of information being recorded and the
intended use of the log.
Note 5 to entry: A log entry forms part of a formally controlled log (3.13.1) maintained to support traceability,
accountability, and governance.
3.3
logging
process of generating, capturing, recording and storing a log entry (3.23.2) in a log (3.13.1) related to the
operation, behaviour, decisions or context of an AI system
Note 1 to entry: Logging is performed automatically by AI system components, manually by AI users (3.143.14), or
through hybrid methods.
Note 2 to entry: Logging occurs during all phases of the AI system life cycle.
3.4
model
physical, mathematical or otherwise logical representation of a system, entity (3.273.28), phenomenon,
process or data
[SOURCE: ISO/IEC 22989:2022, 3.1.23]
3.5
audit
systematic, independent and documented process for obtaining objective evidence and evaluating it
objectively to determine the extent to which the audit criteria are fulfilled
Note 1 to entry: Internal audits, sometimes called first party audits, are conducted by, or on behalf of, the organization
(3.133.13) itself.
Note 2 to entry: External audits include those generally called second and third party audits. Second party audits are
conducted by parties having an interest in the organization, such as customers, or by other individuals on their behalf.
Third party audits are conducted by independent auditing organizations, such as those providing
certification/registration of conformity or governmental agencies.
[SOURCE: ISO 9000:2015, 3.13.1, modified to remove notes 3, 4 and 5]
3.6
auditability
capability of collecting and making available necessary evidential information related to the operation and use
of an AI system, for the purpose of conducting an audit (3.53.5)
[SOURCE: ISO/IEC 22123-1:2023, 3.13.11, modified to replace cloud service with AI system]
3.7
error
discrepancy between a computed, observed or measured value or condition and the true, specified or
theoretically correct value or condition
Note 1 to entry: An error within a system can be caused by failure of one or more of its components, or by the activation
of a systematic fault.
[SOURCE: IEC 60050-192:2015, 192-03-02]
3.8
monitoring
ongoing observation and assessment of an AI system's behaviour, outputs and context by automated tools or
human operators, to detect relevant events from expected operation
Note 1 to entry: Situations that warrant monitoring can include failure, malfunction, cyberattack, out of the intended
domain of use, out of the operational design domain and abnormal usage.
3.9
logging component
functional part of an AI system, or another system interacting with it, that supports generation, capture,
formatting, storage or management of log entries (3.23.2)
Note 1 to entry: A logging component can contain one or more subcomponents for generating log entries (3.23.2) based
on different purposes.
Note 2 to entry: A logging component can forward information to other systems.
3.10
log user
organization (3.133.13) or entity (3.273.28) that accesses, reviews or analyzes logs (3.13.1) produced for an
AI system
3.11
de-identification process
process of removing the association between a set of identifying attributes and the data principal (3.123.12)
Note 1 to entry: De-identification includes the process of altering the data, via modifying or removing data, so that
individuals or entities cannot be as far as technically feasible identified directly or indirectly.
[SOURCE: ISO/IEC 20889:2018, 3.6, modified to add the note]
3.12
data principal
entity (3.273.28) to which data relates
Note 1 to entry: The term “data principal” is broader than “PII principal” (or “data subject” as used elsewhere), and is
able to denote any entity such as a person, an organization (3.133.13), a device, or a software application.
[SOURCE: ISO/IEC 20889:2018, 3.4]
3.13
organization
person or group of people that has its own functions with responsibilities, authorities and relationships to
achieve its objectives
Note 1 to entry: The concept of organization includes, but is not limited to, sole-trader, company, corporation, firm,
enterprise, authority, partnership, charity or institution or part or combination thereof, whether incorporated or not,
public or private.
Note 2 to entry: If the organization is part of a larger entity (3.273.28), the term “organization” refers only to the part of
the larger entity that is within the scope of the AI management system.
[SOURCE: ISO/IEC 42001:2023, 3.1]
3.14
AI user
organization (3.133.13) or entity (3.273.28) that deploys AI products or services
3.15
interested party
stakeholder
any individual, group, or organization (3.133.13) that can affect, be affected by, or perceive itself to be affected
by a decision or activity
[SOURCE: ISO/IEC 42001:2023, 3.2, modified to add admitted term]
3.16
AI developer
organization (3.133.13) or entity (3.273.28) that is involved in the development of AI services and products
3.17
memory capacity
maximum number of items that can be held in a given logging component (3.93.9) memory; usually measured
in words or bytes
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.2411, modified computer to logging component and removed note]
3.18
storage capacity
maximum number of items that can be held in a given storage device; usually measured in bytes
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.3994, modified to remove note and reference to words]
3.19
control (verb)
in engineering, the monitoring (3.83.8) of system output to compare with expected output
and taking corrective action when the actual output does not match the expected output
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.846]
3.20
control (noun)
action of controlling (3.193.20)
3.21
controller
authorized human or another external agent that performs a control (3.203.21)
Note 1 to entry: A controller interacts with the control points (3.223.23) of an AI system.
[SOURCE: ISO/IEC TS 8200:2024, 3.6]
3.22
control point
part of the interface of a system where control (3.203.21) can be applied
Note 1 to entry: A control point can be a function, physical facility (such as a switch) or a signal receiving subsystem.
[SOURCE: ISO/IEC TS 8200:2024, 3.16, modified to make control singular]
3.23
disengagement of control
control disengagement
process where a controller (3.213.22) releases a set of control points (3.223.23)
[SOURCE: ISO/IEC TS 8200:2024, 3.7]
3.24
engagement of control
control engagement
process where a controller (3.213.22) takes over a set of control points (3.223.23)
Note 1 to entry: Besides taking over a set of control points, an engagement of control can also include a confirmation
about the transfer of control to a controller.
[SOURCE: ISO/IEC TS 8200:2024, 3.8]
3.25
transfer of control
control transfer
process of the change of the controller (3.213.22) that performs a control (3.203.21) over a system
Note 1 to entry: Transfer of control does not entail application of a control, but it is a handover of control points of the
system interface between agents.
Note 2 to entry: Engagement of control and disengagement of control are two fundamental complementary parts of
control transfer.
[SOURCE: ISO/IEC TS 8200:2024, 3.19]
3.26
AI provider
organization (3.133.13) or entity (3.273.28) that provides products or services that uses one or more AI
systems
3.27
entity
object
item
anything perceivable or conceivable
EXAMPLE Product, service, process, person, organization (3.133.13), system , resource.
Note 1 to entry: Objects can be material (e.g. ‘engine’, ‘sheet of paper’, ‘diamond’), immaterial (e.g. ‘conversion ratio’,
‘project plan’) or imagined (e.g. ‘unicorn’, ‘scientific hypothesis’).
[SOURCE: ISO 1087-1:2019, 3.1.1], modified — "entity" and "item" have been added as terms.]
4 Abbreviated terms
AI artificial intelligence
ML machine learning
5 Logging and use of logs
5.1 AI system logs
An AI system log can represent information related to the AI system life cycle, including its operation,
behaviour, inputs, outputs or context of development and use, collected to support decisions related to the
various stages of the AI system life cycle, including but not limited to retrieval of events, analysis, monitoring
and control or decision review.
AI system logs can include:
— time-stamped events, including recorded occurrences linked to a specific moment in time, such as when a
model generates a prediction, an error occurs or a user interaction takes place;
— status snapshots, including point-in-time captures of system conditions, such as memory usage, model
state or active component;
— sensor or input data, including information received by the AI system from external sources, such as
camera images, user inputs, location data or telemetry from connected devices;
— outputs, including results produced by the AI system, such as classifications, recommendations,
predictions or generated content;
— decisions, including discrete choices or actions taken by the AI system, either autonomously or through
human oversight mechanisms, such as approving a transaction or triggering an alert;
— error messages, including alerts or diagnostic records indicating failures, exceptions or issues in the
system’s operation;
— environmental context, including external conditions that can influence system behaviour, such as
network status, sensor readings, user load or surrounding events;
— annotations, including supplementary notes or metadata added manually or automatically, which can
describe system behaviour, flag anomalies or provide interpretive context.
AI system logs can be:
— stored persistently, including saved to durable storage such as databases or filesystems for long-term
retention, inspection or compliance purposes;
— processed in real time, including being analyzed immediately or near-instantaneously to support live
monitoring, alerting or adaptive system behaviour;
— managed under data minimization or privacy constraints, including limitations on log content or retention
to avoid collecting unnecessary personal data, ensure user consent, compliance or reduce risk of harm;
— machine-readable, including formats for automated processing and using standardized structures such as
JSON, XML, or protocol buffers;
— human-interpretable, including being presented or organized to allow developers, auditors or analysts, to
understand their content without requiring complex tools or transformatio.
5.2 Logging components
A logging component is a part of or used in conjunction with an AI system and can consist of one or more
subcomponents responsible for tasks such as detecting events, recording log entries, applying data policies,
including filtering or redaction or ensuring secure and reliable handling of logs.
Logging components can be:
— internal to the AI system, including components integrated into model-serving infrastructure or runtime
environments;
— external systems or services, including systems such as observability platforms, audit modules or
compliance loggers.
Logging components can operate independently or in coordination with other parts of an AI system or a more
general system, and can vary in complexity from a simple event logger to a distributed, multi-service logging
pipeline.
A logging component may not assume a fixed structure, automation level, or deployment location. It can be
implemented in software, hardware, or hybrid configurations, and designed to meet different objectives
including operational, analytical and compliance.
Logging components can support a circular logging concept to overwrite the oldest log entries in a log once
memory storage limits are reached, subject to retention requirements.
5.3 Logging in context
In the operation and monitoring phase of the AI system life cycle, the management of an AI system can be
integrated with its use, as management and this phase of the AI system life cycle share the objective of
navigating uncertainty to fulfil a given purpose. This involves the consideration of risks and opportunities
through various activities including planning, monitoring, decision-making and learning.

Key
data access
other process
data flow to logging
control flow
Figure 1 — General architecture of an AI system focusing on utilization of data including logs.
Figure 1 Figure 1Key
data access
other process
data flow to logging
control flow
Figure 1 shows an AI system's functional architecture from the perspective of logging. The log user in this
context is directly interacting with the AI system, including, for example, an organization providing services
to other organizations through the AI system, the manager of the AI system or an AI user of it.
The AI system and its components, including monitoring systems, can utilize logs to fulfil the intended purpose
of the AI system and achieve their objectives, including the management of risks. A log user can collect and
analyse logs from multiple AI systems to create and improve an AI system.
NOTE The logging components are not necessarily directly part of the AI system.
[1]
For an example of a functional architecture of an AI system, see also ISO/IEC 22989:2022, Figure 5 [1]. 5[1] .
The logging component logs behaviours of the AI system, as discussed in Clauses 66Clauses 6 and 7.77.
AI stakeholders can utilize the logs to assess potential benefits and harms of AI systems.
Logs can be used to assess the continuous fulfilment of various requirements (e.g. accuracy, robustness,
security, privacy, safety and data quality) of the AI system.
AI stakeholders can collect and analyse logs from similar AI systems or similar AI systems components on the
market to support the creation, maintenance, and continuous improvement of the data, AI systems and
components they provide, as illustrated in Figure 1,Figure 1 Figure 1, and the analysis results can include
improved data, systems and components. Third-party organizations other than AI producers and AI providers
can provide AI users, in particular non-professional end users, with components for risk management while
improving those components by analysing logs collected from the users
5.4 Log entries
Components of a log entry can include:
— timestamp, the date and time at which an event occurred;
— source identifier, a label or address indicating which component, system, user or external observer
generated the entry;
— event or message code, a categorization or classification of the type of event;
EXAMPLE 1 The event is an error event, inference event or user override event.
— payload or data content, the data being collected, stored and made accessible, including input features,
output values, error traces or contextual metadata;
— severity or priority indicator, a label indicating the importance or criticality of an event, useful for filtering
or alerting.
AI system log entries can be:
— generated automatically by an AI system component or instrumentation;
— manually created by AI users, AI stakeholders that operate the AI system or auditors;
EXAMPLE 2 Annotations or overrides can be manually created and then become log entries.
— derived from external systems, including monitoring tools or interacting AI system components.
To be useful throughout the AI system life cycle, log entries shall be collected, stored and made accessible to
ensure traceability, interpretability and data integrity over time.
5.5 AI system logging
Logging can involve the collection of information from a variety of sources, including:
— system components, including model execution, middleware, or infrastructure;
— user interactions, including input submissions and AI user overrides;
— external systems, including monitoring tools and compliance systems;
— interacting systems, including decision handoffs and multi-model coordination.
Logging activities can be continuous or scheduled.
EXAMPLE 1 Telemetry data is a continuous logging activity.
EXAMPLE 2 Periodic health checks are scheduled logging activities.
NOTE 1 Conditional logging can be categorized as event-driven logging activities triggered by crossing a threshold for
example.
Logging can include one or more of the following activities:
— instrumentation includes the implementation of tools or code or mechanisms to monitor and extract and
capture data from software or hardware components during execution;
— serialization includes converting data structures or objects into a standardized format (such as JSON, XML
or binary) for logging, storage or transmission;
— storage and retention is saving logs to appropriate storage systems with defined retention policies;
— de-identification processes, according to applicable legal, regulatory, statutory and compliance
obligations;
— validation and integrity checking is ensuring that log data is accurate, complete and has not been tampered
with.
Logging should be aligned on defined objectives, and the management of logs should allow for the
consideration of various elements, depending on the context of use, including effectiveness, monitoring, safety,
validation, auditability, transparency, compliance, AI user redress or support for AI system improvement.
NOTE 2 AI logging can support AI user redress, but does not in itself constitute decision accountability or remediation
mechanisms.
5.6 Events
Events are at the centre of certain processes within or around the AI system, including automated monitoring
and human oversight. The underlying goal of logging is to keep records of relevant events occurring in relation
to the AI system.
Events can pertain to the inputs, the outputs, the state of the AI system or a combination of two or more of
these. Relevant events can consist of a pattern of information, for instance, a change or a particular balance
over a period of time, or they can correspond to a property of those inputs, outputs and state, such as the
presence of a particular feature. They can occur across multiple inputs or within a single input.
Detection of relevant events (see 6.16.16.1 a) and b)) can occur through human oversight or automated
monitoring and can involve processing of past inputs and outputs, and other information pertaining to the
event.
Detected relevant events can be logged, including various information pertaining to the event, and
corresponding inputs and outputs. Human oversight or automated monitoring can change the outputs of the
AI system.
Figure 2Figure 2 Figure 2 illustrates the relationship between these concepts.

Figure 2 — The relationship of logging concepts
5.7 General requirements
5.7.1 General
AI system logging shall provide the capabilities described in 5.7.5.75.7.
Logging shall enable traceability between multiple log entries if necessary to meet AI system requirements or
manage risk, relevant to the intended purpose and technical feasibility given the inputs and outputs.
NOTE For additional guidance see 6.2.6.26.2.
5.7.2 Security and privacy
5.7.2.1
The organization:
a) shall identify the security, data protection and privacy requirements for logging, including prevention of
unauthorized modification or deletion;
b) shall protect all data collected by the logging;
c) shall consider applicable legal, regulatory, statutory and compliance obligations to ensure the integrity of
logs, and as relevant, their confidentiality, and any additional organizational policy requirements.
Compliance obligations include requirements that an organization mandatorily has to comply with as well as
those that an organization voluntarily chooses to comply with. For additional guidance see ISO 37301
[10]
[10].[10] .
5.7.2.2
The organization should consider the needs of the AI system interested parties (e.g. AI developers, AI testers,
AI providers and AI users).
EXAMPLE An AI developer who implements, an AI tester who tests the system and an AI service provider who
monitors service during the operation have different purposes.
5.7.3 Recording of events
Logging shall enable the automated recording of events, throughout the AI system’s lifecycle, without
requiring manual intervention for each event:
a) as required by AI system requirements;
b) relevant for identifying situations that can result in the AI system presenting a risk according to the risk
management process;
c) as required for applicable legal, regulatory, statutory and compliance obligations or sector-specific
standards;
d) relevant for the AI system-specific characteristics and operational context;
e) relevant for identifying substantial modifications;
f) for collection, documentation, and analyzing performance data from the initial development to the end of
the retirement stage.
6 Design of the logging system
6.1 General
Risk is the primary driver for monitoring and controlling AI systems. Therefore, risk shall be considered when
a) determining which events are to be detected;
b) determining which events are relevant;
c) determining which relevant events are to be logged.
[11]
Examples of risk management standards that can be applied are ISO/IEC 23894 [11],[11] , or prENEN
1) [12]
18228:— [12]. [12] .
Events shall be logged in relation to inputs or outputs and when caused or observed by the controllers or
components of the AI system. Relevant events to be logged shall be selected based on risk, including
determining the most effective and efficient way to manage the risk
Inputs or outputs relevant to event detection shall be logged at a frequency that is technically feasible and
enables risk to be managed and AI system requirements to be met in the context of the intended purpose.
Inputs or outputs relevant to event detection shall be logged at a frequency that is technically feasible and
allows risk to be managed in the context of the intended purpose.
EXAMPLE Events from streaming inputs or outputs can be logged at different frequencies based on the time-
resolution of the input, or can be logged at a frequency that is appropriate for monitoring a situation, for example, at a
higher frequency during a cyberattack.

Under development. Stage at time of writing, drafting.
1)
Under development. Stage at time of publication: prEN 18228:2026.

Logging shall be designed and configured to generate logs accurately representing such events.
Sources of information to be logged can include:
— communication between end users and the AI system;
— communication between the AI system and its components;
— acquisition and utilization of stored or external data.
6.2 Traceability
Log entries about events should be timestamped, as technically feasible. The timestamp shall record the time
of the event to an accuracy and precision as appropriate for the type of the event and its role with respect to
the intended purpose of the AI system. Where technically feasible, the order of log entries should correspond
to the order of the events logged.
[13]
Timestamps should be formatted according to ISO 8601-1 [13].[13] . If the time zone is not included within
the timestamp, a mechanism to determine the time zone for the timestamp should be specified in the technical
documentation.
Log entries should include an information element that enables connection between the logged information
and the AI system or its components, where appropriate.
6.3 Additional functions
Additional logging can be provided based on the nature of the system, the organization or entity role and based
on applicable legal, regulatory, statutory and compliance obligations:
a) recording the period of each system use (e.g. start and end timestamp);
b) reference to external data source or database against which input data is checked, if applicable;
c) logging the relevant input data;
d) traceability at the level that enables identification of individuals involved in result verification.
6.4 Anomaly monitoring of the logging component
Logging shall issue alerts when:
a) integrity of log processing is violated;
b) confidentiality of log storage has been compromised;
c) integrity of stored logs are either violated or foreseeably can no longer be ensured for the full operational
life time;
d) log memory capacity being reached or exceeded.
Alerts shall be monitored at planned intervals. The rationale for this activity shall be available as documented
information.
6.5 Technical documentation
The technical documentation for the AI system shall, as applicable:
a) explain and justify the specific criteria for determining relevant events;
b) explain and justify the specific criteria for logging relevant events;
c) specify the event types logged by the AI system, organized by purpose, and the mechanisms by which the
events are detected;
d) specify the criteria for logging interaction with human controllers;
e) specify the criteria for logging interaction with automated monitoring systems;
f) recommend a frequency and scope of logging relevant events;
g) explain and justify the accuracy and precision of timestamps, where used. For AI systems without reliable
time sources, include a description of temporal ordering mechanisms and limitations;
h) explain resource constraints (e.g. memory capacity, storage capacity, processing power);
i) explain and justify constraints related to privacy;
j) include appropriate information for security, privacy, and data governance considerations and data
retention policies;
k) include appropriate information security considerations, including access control, identification of
authorized parties and data retention policies;
l) include information about storage infrastructure and capacity, retention capabilities and storage
limitations
m) include specification of f
...

PROJET FINAL
Norme
internationale
ISO/IEC FDIS
ISO/IEC JTC 1/SC 42
Intelligence artificielle —
Secrétariat: ANSI
Journalisation d'événements des
Début de vote:
systèmes d'IA
2026-08-28
Artificial intelligence — AI system logging
Vote clos le:
2026-10-23
LES DESTINATAIRES DU PRÉSENT PROJET SONT
INVITÉS À PRÉSENTER, AVEC LEURS OBSERVATIONS,
NOTIFICATION DES DROITS DE PROPRIÉTÉ DONT ILS
AURAIENT ÉVENTUELLEMENT CONNAISSANCE ET À
FOURNIR UNE DOCUMENTATION EXPLICATIVE.
OUTRE LE FAIT D’ÊTRE EXAMINÉS POUR
ÉTABLIR S’ILS SONT ACCEPTABLES À DES FINS
INDUSTRIELLES, TECHNOLOGIQUES ET COM-MERCIALES,
AINSI QUE DU POINT DE VUE DES UTILISATEURS, LES
PROJETS DE NORMES
TRAITEMENT PARALLÈLE ISO/CEN
INTERNATIONALES DOIVENT PARFOIS ÊTRE CONSIDÉRÉS
DU POINT DE VUE DE LEUR POSSI BILITÉ DE DEVENIR DES
NORMES POUVANT
SERVIR DE RÉFÉRENCE DANS LA RÉGLEMENTATION
NATIONALE.
Numéro de référence
PROJET FINAL
Norme
internationale
ISO/IEC FDIS
ISO/IEC JTC 1/SC 42
Intelligence artificielle —
Secrétariat: ANSI
Journalisation d'événements des
Début de vote:
systèmes d'IA
2026-08-28
Artificial intelligence — AI system logging
Vote clos le:
2026-10-23
LES DESTINATAIRES DU PRÉSENT PROJET SONT
INVITÉS À PRÉSENTER, AVEC LEURS OBSERVATIONS,
NOTIFICATION DES DROITS DE PROPRIÉTÉ DONT ILS
AURAIENT ÉVENTUELLEMENT CONNAISSANCE ET À
FOURNIR UNE DOCUMENTATION EXPLICATIVE.
DOCUMENT PROTÉGÉ PAR COPYRIGHT
OUTRE LE FAIT D’ÊTRE EXAMINÉS POUR
ÉTABLIR S’ILS SONT ACCEPTABLES À DES FINS
© ISO/IEC 2026
INDUSTRIELLES, TECHNOLOGIQUES ET COM-MERCIALES,
AINSI QUE DU POINT DE VUE DES UTILISATEURS, LES
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
PROJETS DE NORMES
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, TRAITEMENT PARALLÈLE ISO/CEN
INTERNATIONALES DOIVENT PARFOIS ÊTRE CONSIDÉRÉS
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut DU POINT DE VUE DE LEUR POSSI BILITÉ DE DEVENIR DES
NORMES POUVANT
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
SERVIR DE RÉFÉRENCE DANS LA RÉGLEMENTATION
NATIONALE.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
Numéro de référence
© ISO/IEC 2026 – Tous droits réservés
ii
Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Abréviations . 5
5 Journalisation d'événements et utilisation des journaux d'événements . 5
5.1 Journaux d'événements des systèmes d'IA .5
5.2 Composants de journalisation d'événements .6
5.3 Journalisation d'événements en contexte .7
5.4 Entrées de journal d'événements .8
5.5 Journalisation d'événements des systèmes d'IA .9
5.6 Événements .10
5.7 Exigences générales .10
5.7.1 Généralités .10
5.7.2 Sécurité et protection de la vie privée .11
5.7.3 Enregistrement des événements.11
6 Conception du système de journalisation d'événements.11
6.1 Généralités .11
6.2 Traçabilité . 12
6.3 Fonctions supplémentaires . 12
6.4 Surveillance des anomalies du composant de journalisation d'événements . 13
6.5 Documentation technique . 13
7 Mise en œuvre et soumission à l'essai. 14
8 Déclencheurs de la journalisation d'événements . 14
8.1 Généralités .14
8.2 Déclencheurs opérationnels .14
8.2.1 Erreurs .14
8.2.2 Entrée aberrante .14
8.2.3 Attaque potentielle . 15
8.2.4 Requêtes d'utilisateur . 15
8.2.5 Demande émise par une personne influencée .16
8.3 Déclencheurs dus à une surveillance automatisée .16
8.3.1 Fonctionnement hors des limites prédéfinies .16
8.3.2 Événements relatifs à la sécurité .16
8.3.3 Événements relatifs à la performance.16
8.3.4 Utilisation en dehors de l'intention recherchée .17
8.3.5 Attaque adverse .17
8.3.6 Détection d'un biais indésirable .17
8.3.7 Entrées hors domaine .17
8.3.8 Dérive du modèle .17
8.3.9 Journalisation d'événements pour le développement de modèles d'apprentissage
automatique à des fins d'auditabilité .18
8.3.10 Problèmes de qualité des données .18
8.3.11 Données non valides .19
8.4 Déclencheurs indiquant une modification substantielle .19
8.4.1 Modifications de la version et de la configuration du système .19
8.4.2 Apprentissage après le déploiement . 20
8.4.3 Modifications initiées par le déployeur .21
8.5 Déclencheurs dus à une supervision humaine .21
9 Informations à enregistrer .21

© ISO/IEC 2026 – Tous droits réservés
iii
9.1 Informations exigées.21
9.2 Informations recommandées . 23
10 Stockage du journal d'événements du système d'IA et accès à celui-ci .23
10.1 Généralités . 23
10.2 Exigences relatives à l'accès des tierces parties . 23
10.3 Accès pour les utilisateurs de l'IA .24
10.4 Accès pour les fournisseurs d'IA .24
10.5 Mise en œuvre de l'infrastructure de stockage .24
10.6 Contrôle d'accès et mécanismes d'accès .24
11 Amélioration continue .25
Annexe A (informative) Modèle d'information .26
Bibliographie .30

© ISO/IEC 2026 – Tous droits réservés
iv
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux
de normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général
confiée aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire
partie du comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec
la Commission électrotechnique internationale (IEC) en ce qui concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier, de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document
a été rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2
(voir www.iso.org/directives).
L'ISO attire l'attention sur le fait que la mise en application du présent document peut entraîner l'utilisation
d'un ou de plusieurs brevets. L'ISO ne prend pas position quant à la preuve, à la validité et à l'applicabilité
de tout droit de propriété revendiqué à cet égard. À la date de publication du présent document, l'ISO
n'avait pas reçu notification qu'un ou plusieurs brevets pouvaient être nécessaires à sa mise en application.
Toutefois, il y a lieu d'avertir les responsables de la mise en application du présent document que des
informations plus récentes sont susceptibles de figurer dans la base de données de brevets, disponible à
l'adresse www.iso.org/brevets. L'ISO ne saurait être tenue pour responsable de ne pas avoir identifié tout ou
partie de tels droits de brevet.
Les appellations commerciales éventuellement mentionnées dans le présent document sont données pour
information, par souci de commodité, à l'intention des utilisateurs et ne sauraient constituer un engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion de
l'ISO aux principes de l'Organisation mondiale du commerce (OMC) concernant les obstacles techniques au
commerce (OTC), voir www.iso.org/avant-propos.
Le présent document a été élaboré par le comité technique ISO/IEC JTC 1, Technologies de l'information, sous-
comité SC 42, Intelligence artificielle, en collaboration avec le comité technique CEN/CLC/JTC 21, Intelligence
artificielle, du Comité européen de normalisation (CEN), conformément à l'Accord de coopération technique
entre l'ISO et le CEN (Accord de Vienne).
Il convient que l'utilisateur adresse tout retour d'information ou toute question concernant le présent
document à l'organisme national de normalisation de son pays. Une liste exhaustive desdits organismes se
trouve à l'adresse www.iso.org/fr/members.html.

© ISO/IEC 2026 – Tous droits réservés
v
Introduction
Les systèmes d'IA peuvent enregistrer un large éventail d'événements au cours des différentes phases
du cycle de vie. Si certains aspects de la journalisation d'événements peuvent être définis à l'avance, sur
la base de l'objectif connu du système et de son contexte opérationnel, les besoins réels n'apparaissent
souvent qu'après le déploiement. Dans la pratique, les développeurs d'IA et les parties prenantes de l'IA ne
peuvent pas savoir exactement ce qu'il est important d'enregistrer tant que le système ne fonctionne pas.
En outre, la pertinence des événements enregistrés n'est pas fixe. Elle peut varier au fil du temps en raison
de l'évolution des besoins des utilisateurs de l'IA, des conditions opérationnelles ou même des interactions
avec d'autres systèmes d'IA. Toutefois, il est souvent difficile de savoir si les systèmes d'IA peuvent adapter
eux-mêmes leurs pratiques de journalisation d'événements ou si une intervention humaine est nécessaire
pour reconfigurer la journalisation d'événements en fonction de l'évolution des contextes. Cela soulève
d'importantes questions en matière d'auditabilité, de transparence et de supervision à long terme des
systèmes d'IA.
Les journaux d'événements des systèmes d'IA peuvent servir à la fois à des tâches opérationnelles, telles que la
surveillance du système ou le dépannage, et à des fonctions de gestion au niveau du système, à condition que
les journaux d'événements soient accessibles, bien structurés et adaptés aux besoins spécifiques des parties
prenantes de l'IA. Lorsque les journaux d'événements sont correctement collectés, conservés et analysés, ils
peuvent servir de base à des activités telles que l'alignement sur l'orientation stratégique de l'organisation,
la surveillance en temps réel, la prise de décision et l'amélioration continue. Toutefois, l'efficacité de ces
activités dépend de la qualité des données enregistrées, des commandes d'accès appropriées, des capacités
d'analyse de l'organisation et de la capacité de compréhension de la manière dont les événements enregistrés
sont liés à des objectifs, des risques ou des opportunités. L'exploitation des journaux d'événements peut
contribuer à la réduction des coûts, à l'atténuation des risques et à la conformité, si les organisations
disposent des outils et des processus appropriés pour interpréter les données et agir en conséquence et si
les journaux d'événements sont conçus pour prendre en compte les obligations de conformité, y compris les
obligations statutaires, réglementaires et contractuelles, ainsi que d'autres exigences organisationnelles.
Lorsque les journaux d'événements sont systématiquement collectés, structurés et analysés, ils peuvent
fournir des informations précieuses qui aident les organisations et les parties prenantes de l'IA à mieux
comprendre et à réagir à des événements inattendus ou à des conditions changeantes. L'efficacité d'une
telle réponse peut nécessiter un accès en temps réel ou quasi réel aux journaux d'événements ou justifier
un accès asynchrone, en fonction du contexte. Les journaux d'événements peuvent également contribuer
au développement et à l'amélioration itératifs des systèmes d'IA en mettant en évidence des problèmes
d'efficacité et d'efficience ou des schémas émergents qui n'étaient pas détectables lors de l'entraînement
initial du modèle ou du déploiement. Pour contribuer de manière significative à l'amélioration continue tout
au long du cycle de vie du système d'IA, les journaux d'événements peuvent être riches en contexte, validés,
stockés en toute sécurité et examinés en tenant compte des besoins et attentes des parties prenantes de l'IA
et de l'organisation.
Les activités de journalisation d'événements présentent leur propre complexité et leurs propres coûts et
peuvent réduire les performances et augmenter l'empreinte du système d'IA; il convient donc de s'interroger
sur l'efficacité et l'efficience de la journalisation d'événements pour répondre aux besoins de gestion et de
supervision.
Le contenu du présent document est structuré comme suit:
— l'Article 5 décrit la journalisation d'événements et l'utilisation de ces journaux d'événements, et fournit
des exigences générales pour la journalisation d'événements;
— l'Article 6 fournit des exigences et des recommandations pour la conception et le développement, y
compris la traçabilité;
— l'Article 7 fournit des exigences pour la mise en œuvre et les essais;
— l’Article 8 détaille les éléments déclencheurs de la journalisation d'événements selon quatre catégories:
fonctionnement, surveillance automatisée, détection de modifications substantielles et supervision
humaine;
© ISO/IEC 2026 – Tous droits réservés
vi
— l’Article 9 contient des exigences et des recommandations pour les informations à inclure dans les
journaux d'événements;
— l’Article 10 contient des exigences pour le stockage des journaux d'événements et à l'accès aux journaux
d'événements;
— l’Article 11 contient des exigences pour l'amélioration continue;
— l’Annexe A donne un exemple de modèle d'information et de structure de données pouvant être utilisés
pour la journalisation des événements des systèmes d'IA.

© ISO/IEC 2026 – Tous droits réservés
vii
PROJET FINAL Norme internationale ISO/IEC FDIS 24970:2026(fr)
Intelligence artificielle — Journalisation d'événements des
systèmes d'IA
1 Domaine d'application
Le présent document décrit les capacités communes et fournit les exigences relatives à la journalisation des
événements dans les systèmes d'IA.
2 Références normatives
Le présent document ne contient aucune référence normative.
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent.
L'ISO et l'IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en normalisation,
consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l'adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l'adresse https:// www .electropedia .org/
3.1
journal d'événements
objet de gestion qui est organisé par entrées de journal d'événements (3.2)
Note 1 à l'article: Un journal d'événements est un enregistrement contrôlé de manière formelle, conservé pour assurer
la traçabilité, la redevabilité et la gouvernance des opérations du système d'IA.
Note 2 à l'article: Dans le contexte d'un système d'IA, les journaux d'événements peuvent être constitués de données
structurées, semi-structurées ou non structurées et peuvent provenir du système d'IA considéré, de ses composants
internes, de systèmes d'IA en interaction, d'utilisateurs de l'IA ou de parties intéressées (3.15), qu'ils soient humains ou
automatisés, opérant en dehors des limites du système d'IA.
Note 3 à l'article: Dans le contexte d'un système d'IA, les journaux d'événements peuvent être générés en continu,
périodiquement ou en réponse à des conditions spécifiques, et peuvent servir à diverses fins, notamment la surveillance
(3.8) du système, le débogage, l'audit, la conformité, la supervision humaine, l'amélioration itérative du système ou la
redevabilité.
3.2
entrée de journal d'événements
unité d'information discrète qui capture un événement, une condition, un état, une entrée, une sortie, une
décision ou des données contextuelles spécifique(s) lié(es) au fonctionnement ou à l'environnement
Note 1 à l'article: Une entrée de journal d'événements peut comprendre notamment des informations relatives à un
événement, un état ou à d'autres données associés au fonctionnement du système.
Note 2 à l'article: Les entrées de journal d'événements sont composées d'une combinaison de métadonnées, notamment
les horodatages, les identifiants de source et les niveaux de gravité, et de données spécifiques au contenu en rapport
avec l'objectif d'un journal d'événements.
Note 3 à l'article: Les entrées de journal d'événements sont structurées (par exemple, un objet JSON), semi-structurées
(par exemple, des annotations textuelles) ou non structurées (par exemple, des captures d'écran).

© ISO/IEC 2026 – Tous droits réservés
Note 4 à l'article: La structure et le contenu des entrées du journal d'événements varient en fonction du type
d'informations enregistrées et de l'utilisation prévue du journal d'événements.
Note 5 à l'article: Une entrée de journal d'événements fait partie d'un journal d'événements (3.1) contrôlé de manière
formelle, conservé de sorte à prendre en charge la traçabilité, la redevabilité et la gouvernance.
3.3
journalisation d'événements
processus de génération, de capture, d'enregistrement et de stockage d'une entrée de journal d'événements
(3.2) dans un journal d'événements (3.1) lié au fonctionnement, au comportement, aux décisions ou au
contexte d'un système d'IA
Note 1 à l'article: La journalisation d'événements est effectuée automatiquement par les composants du système d'IA,
manuellement par des utilisateurs de l'IA (3.14), ou par des méthodes hybrides.
Note 2 à l'article: La journalisation d'événements a lieu pendant toutes les phases du cycle de vie du système d'IA.
3.4
modèle
représentation physique, mathématique ou logique d'un système, d'une entité (3.27), d'un phénomène, d'un
processus ou de données
[SOURCE: ISO/IEC 22989:2022, 3.1.23]
3.5
audit
processus méthodique, indépendant et documenté, permettant d'obtenir des preuves objectives et de les
évaluer de manière objective pour déterminer dans quelle mesure les critères d'audit sont satisfaits
Note 1 à l'article: Les audits internes, parfois appelés audits de première partie, sont réalisés par, ou pour le compte de,
l'organisation (3.13) elle-même.
Note 2 à l'article: Les audits externes comprennent les audits appelés généralement audits de seconde et de tierce
partie. Les audits de seconde partie sont réalisés par des parties ayant un intérêt à l'égard de l'organisation, comme les
clients, ou d'autres personnes agissant en leur nom. Les audits de tierce partie sont réalisés par des organismes d'audit
indépendants, tels que ceux qui octroient l'enregistrement ou la certification de conformité ou des organismes publics.
[SOURCE: ISO 9000:2015, 3.13.1, modifié. Suppression des Notes 3, 4 et 5]
3.6
auditabilité
capacité de recueillir et de mettre à disposition les informations probantes nécessaires relatives au
fonctionnement et à l'utilisation d'un système d'IA, dans le but de permettre la réalisation d’un audit (3.5)
[SOURCE: ISO/IEC 22123‑1:2023, 3.13.11, modifié. Remplacement de service en nuage par système d'IA]
3.7
erreur
écart entre une valeur ou condition calculée, observée ou mesurée et la valeur ou condition vraie, spécifiée
ou théoriquement correcte
Note 1 à l'article: Une erreur dans un système peut être causée par une défaillance d'un ou de plusieurs de ses
composants ou par l'activation d'une panne systématique.
[SOURCE: IEC 60050-192:2015, 192-03-02]

© ISO/IEC 2026 – Tous droits réservés
3.8
surveillance
observation et évaluation continues du comportement, des résultats et du contexte d'un système d'IA par
des outils automatisés ou des opérateurs humains, afin de détecter les événements pertinents par rapport
au fonctionnement prévu
Note 1 à l'article: Les situations justifiant une surveillance peuvent inclure une défaillance, un dysfonctionnement,
une cyberattaque, un dépassement du domaine d'utilisation prévu, un dépassement du domaine de conception
fonctionnelle et une utilisation anormale.
3.9
composant de journalisation d'événements
partie fonctionnelle d'un système d'IA, ou d'un autre système interagissant avec lui, qui prend en charge la
génération, la capture, le formatage, le stockage ou la gestion des entrées de journal d'événements (3.2)
Note 1 à l'article: Un composant de journalisation d'événements peut contenir un ou plusieurs sous-composants
permettant de générer des entrées de journal d'événements (3.2) en fonction d'objectifs différents.
Note 2 à l'article: Un composant de journalisation d'événements peut transmettre des informations à d'autres systèmes.
3.10
utilisateur du journal d'événements
organisation (3.13), organisme ou entité (3.27) qui accède aux journaux d'événements (3.1) produits pour un
système d'IA, les examine ou les analyse
3.11
processus de désidentification
processus consistant à supprimer l'association entre un ensemble d'attributs d'identification et l'entité
principale (3.12)
Note 1 à l'article: La désidentification (aussi appelée dépersonnalisation) comprend le processus d'altération des
données, par la modification ou la suppression des données, de sorte que des personnes ou des entités ne puissent pas,
dans la mesure de ce qui est techniquement réalisable, être identifiées, directement ou indirectement.
[SOURCE: ISO/IEC 20889:2018, 3.6, modifié pour ajouter la note]
3.12
entité principale
entité (3.27) à laquelle les données se rapportent
Note 1 à l'article: Le terme “entité principale” est plus large que le terme “sujet ayant des DCP (données à caractère
personnel)” (ou “entité concernée” utilisé ailleurs) et peut désigner toute entité telle qu'une personne, une organisation
(3.13), un dispositif ou une application logicielle.
[SOURCE: ISO/IEC 20889:2018, 3.4, modifié]
3.13
organisation
personne ou groupe de personnes qui exerce ses propres fonctions associées aux responsabilités, pouvoirs
et relations nécessaires pour atteindre ses objectifs
Note 1 à l'article: Le concept d'organisation comprend, sans s'y limiter, l'entreprise individuelle, la société, la firme,
l'entreprise, l'organisme de contrôle, le partenariat, l'organisation de bienfaisance ou l'organisme public ou une partie
ou une combinaison de ceux-ci, qu'ils soient constitués en société ou non.
Note 2 à l'article: Si l'organisation fait partie d'une entité (3.27) plus grande, le terme “organisation” fait uniquement
référence à la partie de l'entité qui est comprise dans le champ d'application du système de management de l'IA.
[SOURCE: ISO/IEC 42001:2023, 3.1, modifié]
3.14
utilisateur de l'IA
organisation (3.13) ou entité (3.27) qui déploie des produits ou des services d'IA

© ISO/IEC 2026 – Tous droits réservés
3.15
partie intéressée
partie prenante
toute personne, tout groupe ou toute organisation (3.13) qui peut soit influer sur une décision ou une activité,
soit être influencé(e) ou se sentir influencé(e) par une décision ou une activité
[SOURCE: ISO/IEC 42001:2023, 3.2, modifié. Ajout du terme admis]
3.16
développeur d'IA
organisation (3.13) ou entité (3.27) qui participe au développement de services et de produits d'IA
3.17
capacité de mémoire
nombre maximal d'éléments pouvant être conservés dans une mémoire de composant de journalisation
d'événements (3.9) donnée; généralement mesurée en mots ou en octets
[SOURCE: ISO/IEC IEEE 24765:2017, 3.2411, modification d'ordinateur en composant de journalisation
d'événements et suppression de la note]
3.18
capacité de stockage
nombre maximal d'éléments pouvant être conservés dans un dispositif de stockage donné; généralement
mesurée en octets
[SOURCE: ISO/IEC IEEE 24765:2017, 3.3994, modifié pour supprimer la note et la référence aux termes]
3.19
contrôler (verbe)
en ingénierie, la surveillance (3.8) de la sortie du système pour la comparer à la sortie
attendue et prendre des mesures correctives lorsque la sortie réelle ne correspond pas à la sortie attendue
[SOURCE: ISO/IEC IEEE 24765:2017, 3.846]
3.20
contrôle (nom)
action de contrôler (3.20)
3.21
contrôleur
personne autorisée ou autre agent externe qui effectue un contrôle (3.21)
Note 1 à l'article: Un contrôleur interagit avec les points de contrôle (3.23) d'un système d'IA.
[SOURCE: ISO/IEC TS 8200:2024, 3.6]
3.22
point de contrôle
partie de l'interface d'un système où le contrôle (3.21) peut être appliqué
Note 1 à l'article: Un point de contrôle peut être une fonction, une installation physique (telle qu'un commutateur) ou
un sous-système de réception de signaux.
[SOURCE: ISO/IEC TS 8200:2024, 3.16, modifié pour mettre contrôle au singulier]
3.23
désengagement de contrôle
désengagement de contrôle
processus par lequel un contrôleur (3.22) libère un ensemble de points de contrôle (3.23)
[SOURCE: ISO/IEC TS 8200:2024, 3.7]

© ISO/IEC 2026 – Tous droits réservés
3.24
engagement de contrôle
engagement de contrôle
processus par lequel un contrôleur (3.22) prend en charge un ensemble de points de contrôle (3.23)
Note 1 à l'article: Outre la prise en charge d'un ensemble de points de contrôle, un engagement de contrôle peut
également inclure une confirmation du transfert de contrôle à un contrôleur.
[SOURCE: ISO/IEC TS 8200:2024, 3.8]
3.25
transfert de contrôle
transfert de contrôle
processus de changement du contrôleur (3.22) qui effectue un contrôle (3.21) sur un système
Note 1 à l'article: Le transfert de contrôle n'implique pas l'application d'un contrôle, mais il s'agit d'un transfert des
points de contrôle de l'interface du système entre les agents.
Note 2 à l'article: L'engagement de contrôle et le désengagement de contrôle sont deux parties complémentaires
fondamentales du transfert de contrôle.
[SOURCE: ISO/IEC TS 8200:2024, 3.19]
3.26
fournisseur d'IA
organisation (3.13) ou entité (3.27) qui fournit des produits ou des services utilisant un ou plusieurs systèmes
d'IA
3.27
entité
objet
élément
tout ce qui est perceptible ou concevable
EXEMPLE Produit, service, processus, personne, organisation (3.13), système, ressource.
Note 1 à l'article: Les objets peuvent être matériels (par exemple, “moteur”, “feuille de papier”, “diamant”), immatériels
(par exemple, “rapport de conversion”, “plan de projet”) ou imaginaires (par exemple, “licorne”, “hypothèse
scientifique”).
[SOURCE: ISO 1087:2019, 3.1.1, modifiée — “entité” et “élément” ont été ajoutés en tant que termes.]
4 Abréviations
IA intelligence artificielle
ML apprentissage automatique
5 Journalisation d'événements et utilisation des journaux d'événements
5.1 Journaux d'événements des systèmes d'IA
Un journal d'événements d'un système d'IA peut représenter des informations relatives au cycle de vie du
système d'IA, y compris son fonctionnement, son comportement, ses entrées, ses sorties ou son contexte de
développement et d'utilisation, collectées pour étayer les décisions relatives aux différentes étapes du cycle
de vie du système d'IA, notamment la recherche d'événements, l'analyse, la surveillance et le contrôle ou
l'examen des décisions.
© ISO/IEC 2026 – Tous droits réservés
Les journaux d'événements des systèmes d'IA peuvent comprendre:
— des événements horodatés, y compris des événements enregistrés liés à un moment précis dans le temps,
par exemple lorsqu'un modèle génère une prédiction, qu'une erreur se produit ou qu'une interaction avec
l'utilisateur a lieu;
— des instantanés d'état, y compris des captures ponctuelles des conditions du système, telles que
l'utilisation de la mémoire, l'état du modèle ou le composant actif;
— des données de capteur ou d'entrée, y compris des informations reçues par le système d'IA à partir
de sources externes, telles que les images d'une caméra, les entrées de l'utilisateur, les données de
localisation ou la télémétrie des appareils connectés;
— des sorties, y compris des résultats produits par le système d'IA, tels que les classifications, les
recommandations, les prédictions ou le contenu généré;
— des décisions, y compris des choix discrets ou des actions prises par le système d'IA, soit de manière
autonome, soit par le biais de mécanismes de supervision humaine, comme l'approbation d'une
transaction ou le déclenchement d'une alerte;
— des messages d'erreur, y compris des alertes ou des enregistrements de diagnostic indiquant des
défaillances, des exceptions ou des problèmes dans le fonctionnement du système;
— le contexte environnemental, y compris les conditions externes qui peuvent influencer le comportement
du système, telles que l'état du réseau, les relevés des capteurs, l'état de charge du système ou les
événements environnants;
— des annotations, y compris des notes supplémentaires ou métadonnées ajoutées manuellement ou
automatiquement, qui peuvent décrire le comportement du système, signaler des anomalies ou fournir
un contexte d'interprétation.
Les journaux d'événements des systèmes d'IA peuvent être:
— stockés de manière persistante, y compris leur enregistrement sur un support durable, comme des bases
de données ou des systèmes de fichiers, en vue d'une conservation à long terme, d'une inspection ou à
des fins de conformité;
— traités en temps réel, y compris être analysés immédiatement ou presque instantanément pour soutenir
la surveillance en temps réel, l'alerte ou le comportement adaptatif du système;
— gérés selon des contraintes de minimisation des données ou de protection de la vie privée, y compris
des limitations s'appliquant au contenu ou à la conservation des journaux d'événement pour éviter de
collecter des données personnelles inutiles, garantir le consentement de l'utilisateur, la conformité ou
réduire le risque de préjudice;
— lisibles par machine, y compris les formats de traitement automatisé et utilisant des structures
normalisées telles que JSON, XML ou des tampons de protocole;
— interprétables par l'homme, y compris en étant présentés ou organisés afin de permettre aux
développeurs, aux auditeurs ou aux analystes de comprendre leur contenu sans nécessiter d'outils ou de
transformations complexes.
5.2 Composants de journalisation d'événements
Un composant de journalisation d'événements fait partie d'un système d'IA ou est utilisé conjointement
avec un système d'IA et peut se composer d'un ou plusieurs sous-composants chargés de tâches telles que la
détection d'événements, l'enregistrement d'entrées de journal d'événements, l'application de politiques de
données, y compris le filtrage ou le masquage, ou garantissant le traitement sécurisé et fiable des journaux
d'événements.
© ISO/IEC 2026 – Tous droits réservés
Les composants de journalisation d'événements peuvent être:
— internes au système d'IA, y compris les composants intégrés à l'infrastructure de services de modèles ou
aux environnements d'exécution;
— des systèmes ou services externes, y compris les systèmes tels que des plateformes d'observabilité, des
modules d'audit ou des enregistreurs de conformité.
Les composants de journalisation d'événements peuvent fonctionner indépendamment ou en coordination
avec d'autres parties d'un système d'IA ou d'un système plus général, et leur complexité peut varier d'un
simple enregistreur d'événements à une chaîne de journalisation d'événements distribuée et multiservice.
Un composant de journalisation d'événements peut ne pas avoir de structure fixe, de niveau d'automatisation
ou de lieu de déploiement. Il peut être mis en œuvre dans des configurations logicielles, matérielles ou
hybrides, et conçu pour répondre à différents objectifs, y compris des objectifs opérationnels, analytiques et
de conformité.
Les composants de journalisation d'événements peuvent prendre en charge un concept de journalisation
d'événements circulaire pour écraser les entrées les plus anciennes d'un journal d'événements une fois que
les limites de stockage de la mémoire sont atteintes, sous réserve des exigences de conservation.
5.3 Journalisation d'événements en contexte
Pendant la phase du cycle de vie, de fonctionnement et de surveillance d'un système d'IA, la gestion d'un
système d'IA peut être intégrée à son utilisation, car la gestion et cette phase du cycle de vie du système d'IA
partagent l'objectif de naviguer dans l'incertitude pour atteindre un objectif donné. Cela implique la prise en
compte des risques et des opportunités par l'intermédiaire de diverses activités, notamment la planification,
la surveillance, la prise de décision et l'apprentissage.
Légende
accès aux données
autre processus
flux de données vers la journalisation d'événements
flux de contrôle
Figure 1 — Architecture générale d'un système d'IA axé sur l'utilisation des données, y compris
les journaux d'événements.
© ISO/IEC 2026 – Tous droits réservés
La Figure 1 illustre l'architecture fonctionnelle d'un système d'IA du point de vue de la journalisation
d'événements. Dans ce contexte, l'utilisateur de journaux d'événements interagit directement avec le
système d'IA, y compris, par exemple, une organisation fournissant des services à d'autres organisations par
l'intermédiaire du système d'IA, le gestionnaire du système d'IA ou un utilisateur de l'IA de celui-ci.
Le système d'IA et ses composants, y compris les systèmes de surveillance, peuvent utiliser des journaux
d'événements pour atteindre l'intention recherchée pour le système d'IA, et pour atteindre leurs objectifs,
y compris la gestion des risques. Un utilisateur de journaux d'événements peut collecter et analyser des
journaux d'événements provenant de plusieurs systèmes d'IA afin de créer et d'améliorer un système d'IA.
NOTE Les composants de journalisation d'événements ne font pas nécessairement partie directement du système
d'IA.
Pour un exemple d'architecture fonctionnelle d'un système d'IA, voir également l'ISO/IEC 22989:2022,
[1]
Figure 5 .
Le composant de journalisation d'événements enregistre les comportements du système d'IA, comme
indiqué aux Articles 6 et 7.
Les parties prenantes de l'IA peuvent utiliser les journaux d'événements pour évaluer les avantages et les
inconvénients potentiels des systèmes d'IA.
Les journaux d'événements peuvent être utilisés pour évaluer le respect continu de diverses exigences
(par exemple, l'exactitude, la robustesse, la sécurité, la protection de la vie privée, la sûreté et la qualité des
données) par le système d'IA.
Les parties prenantes de l'IA peuvent collecter et analyser des journaux d'événements provenant de
systèmes d'IA similaires ou de composants similaires de systèmes d'IA sur le marché afin de soutenir la
création, la maintenance et l'amélioration continue des données, des systèmes d'IA et des composants qu'ils
fournissent, comme l'illustre la Figure 1, et les résultats de cette analyse peuvent comprendre des données,
des systèmes et des composants qui
...