ISO/IEC FDIS 24970

• Abstract:

  This document describes common capabilities, requirements and a supporting information model for logging of events in AI systems. This document is designed to be used with a risk management system.

• Status: Not Published
• ICS: 35.240.01 - Application of information technology in general
• Technical Committee: ISO/IEC JTC 1/SC 42 - Artificial intelligence
• Drafting Committee: ISO/IEC JTC 1/SC 42/WG 1 - Foundational standards
• Current Stage: 5020 - FDIS ballot initiated: 2 months. Proof sent to secretariat
• Start Date: 28-Aug-2026
• Completion Date: 28-Aug-2026

• Consolidates: FprEN ISO/IEC 24970 - Artificial intelligence - AI system logging (ISO/IEC FDIS 24970:2026)
• Effective Date: 12-Feb-2026
• Consolidates: ISO 15091:2019 - Paints and varnishes — Determination of electrical conductivity and resistance
• Effective Date: 01-Oct-2024

Overview

ISO/IEC FDIS 24970: Artificial Intelligence - AI System Logging is an international standard developed by ISO/IEC JTC 1/SC 42. This document defines common capabilities, requirements, and an information model for logging events in artificial intelligence (AI) systems. The purpose of AI system logging is to support risk management, traceability, transparency, and continual improvement throughout the AI system life cycle. By following the guidelines outlined in this standard, organizations can strengthen accountability, demonstrate compliance, and enable effective oversight of their AI deployments.

Key Topics

Common Logging Capabilities

• Event capture: Specifies how systems capture significant events during AI operation, including decisions made by models, user interactions, errors, and system states.
• Log structure: Defines elements such as timestamps, source identifiers, event types, metadata, and contextual information for each log entry.
• Security and privacy: Requires organizations to protect the integrity, confidentiality, and authenticity of logs, including compliance with regulatory and organizational policies around data protection.
• Traceability: Enables linking of log entries for effective auditability and monitoring over time.

Requirements and Processes

• Consistency: Logging processes should be structured to support both automated and manual event reporting, as relevant.
• Risk-based design: The design and implementation of logging should follow risk management principles to capture events that may indicate risk, anomalies, or failures.
• Triggering mechanisms: Logging should be responsive to triggers such as operational events, automated monitoring outcomes, system modifications, and human oversight activities.

Information Model

• Log entries: Should encapsulate all necessary event information for traceability, performance analysis, and compliance auditing.
• Storage and access: Logs must be securely stored with controlled access for different stakeholders, including AI providers, users, auditors, and regulators.

Applications

The ISO/IEC FDIS 24970 standard has broad applicability for organizations using, providing, or developing AI systems. Its practical uses include:

• Operational Monitoring: Supports real-time system monitoring by capturing operational events and behaviors for anomaly detection and rapid troubleshooting.
• Audit and Compliance: Facilitates external and internal audits through well-structured, accessible logs aligned with legal and regulatory requirements.
• Continuous Improvement: Allows organizations to analyze logs for identifying trends, improving AI model performance, and enhancing decision-making processes.
• Risk Management: Empowers stakeholders to track risk-related events, evaluate the effectiveness of risk controls, and adapt logging practices as new risks emerge.
• Transparency & Accountability: Builds trust by enabling clear documentation of AI system decisions, user interactions, and override events.

Organizations deploying AI in sectors like finance, healthcare, manufacturing, or public services can leverage this standard to support responsible AI governance, increase oversight, and meet sector-specific compliance demands.

Related Standards

ISO/IEC FDIS 24970 is designed to complement other international AI and risk management standards, including:

• ISO/IEC 22989 - Terminology and concepts for AI
• ISO/IEC 42001 - AI management system requirements
• ISO/IEC 22123 - Cloud computing and related auditing requirements
• ISO 9000 - Quality management systems, relevant for system audit processes
• ISO 37301 - Compliance management systems, relevant for aligning logging practices with compliance needs

Adopting ISO/IEC FDIS 24970 helps organizations integrate AI system event logging within their comprehensive risk management and compliance frameworks, supporting AI governance, transparency, and ongoing system improvement.

FINAL DRAFT
International
Standard
ISO/IEC FDIS
ISO/IEC JTC 1/SC 42
Artificial intelligence — AI system
Secretariat: ANSI
logging
Voting begins on:
Intelligence artificielle — Journalisation d'événements des 2026-08-28
systèmes d'IA
Voting terminates on:
2026-10-23
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 SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
ISO/CEN PARALLEL PROCESSING LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
FINAL DRAFT
International
Standard
ISO/IEC FDIS
ISO/IEC JTC 1/SC 42
Artificial intelligence — AI system
Secretariat: ANSI
logging
Voting begins on:
Intelligence artificielle — Journalisation d'événements des
systèmes d'IA
Voting terminates on:
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 SUPPOR TING DOCUMENTATION.
© ISO/IEC 2026
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
ISO/CEN PARALLEL PROCESSING
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland Reference number
© ISO/IEC 2026 – All rights reserved
ii
Contents Page
Foreword .v
Introduction .vi
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 .6
5.4 Log entries .8
5.5 AI system logging .8
5.6 Events .9
5.7 General requirements .9
5.7.1 General .9
5.7.2 Security and privacy .10
5.7.3 Recording of events .10
6 Design of the logging system .10
6.1 General .10
6.2 Traceability .11
6.3 Additional functions .11
6.4 Anomaly monitoring of the logging component .11
6.5 Technical documentation . 12
7 Implementation and testing .12
8 Triggers for logging .13
8.1 General . 13
8.2 Triggers from operation . 13
8.2.1 Errors . 13
8.2.2 Outlier input . 13
8.2.3 Potential attack . . 13
8.2.4 User requests .14
8.2.5 Request from an affected person .14
8.3 Triggers from automated monitoring .14
8.3.1 Operation outside of predefined limits .14
8.3.2 Safety events . 15
8.3.3 Performance events . 15
8.3.4 Use outside of the intended purpose . 15
8.3.5 Adversarial attack . 15
8.3.6 Unwanted bias detection . 15
8.3.7 Out-of-domain inputs . 15
8.3.8 Model drift .16
8.3.9 Logging for machine learning model development for auditability purposes .16
8.3.10 Data quality issues .17
8.3.11 Invalid data . . .17
8.4 Triggers indicating substantial modification.17
8.4.1 System version and configuration changes .17
8.4.2 Learning after deployment .18
8.4.3 Deployer initiated changes .19
8.5 Triggers from human oversight.19
9 Information to log . 19
9.1 Required information .19

© ISO/IEC 2026 – All rights reserved
iii
9.2 Recommended information . 20
10 AI system log storage and access .21
10.1 General .21
10.2 Requirements for third party access .21
10.3 Access for AI users .21
10.4 Access for AI providers . 22
10.5 Storage infrastructure implementation . 22
10.6 Access control and access mechanisms. 22
11 Continual improvement . .22
Annex A (informative) Information model .23
Bibliography .26

© ISO/IEC 2026 – All rights reserved
iv
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).
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
v
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 5 outlines logging and the use of logs, and provides general requirements for logging;
— Clause 6 provides requirements and guidance for design, including traceability;
— Clause 7 provides requirements for implementation and testing;
— Clause 8 details the triggers for logging in four categories: operation, automated monitoring, detecting
substantial modification and human oversight.
— Clause 9 contains requirements and guidance for information to include in the logs;
— Clause 10 contains requirements for storing and access to logs;
— Clause 11 contains requirements for continual improvement;
— Annex 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
vi
FINAL DRAFT International Standard ISO/IEC FDIS 24970:2026(en)
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.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.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.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.1) maintained to support traceability,
accountability, and governance.

© ISO/IEC 2026 – All rights reserved
3.3
logging
process of generating, capturing, recording and storing a log entry (3.2) in a log (3.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.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.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.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.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.

© ISO/IEC 2026 – All rights reserved
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.2)
Note 1 to entry: A logging component can contain one or more subcomponents for generating log entries (3.2) based on
different purposes.
Note 2 to entry: A logging component can forward information to other systems.
3.10
log user
organization (3.13) or entity (3.28) that accesses, reviews or analyzes logs (3.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.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.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.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.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.13) or entity (3.28) that deploys AI products or services
3.15
interested party
stakeholder
any individual, group, or organization (3.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.13) or entity (3.28) that is involved in the development of AI services and products

© ISO/IEC 2026 – All rights reserved
3.17
memory capacity
maximum number of items that can be held in a given logging component (3.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.20
control (verb)
in engineering, the monitoring (3.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.21
control (noun)
action of controlling (3.20)
3.22
controller
authorized human or another external agent that performs a control (3.21)
Note 1 to entry: A controller interacts with the control points (3.23) of an AI system.
[SOURCE: ISO/IEC TS 8200:2024, 3.6]
3.23
control point
part of the interface of a system where control (3.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.24
disengagement of control
control disengagement
process where a controller (3.22) releases a set of control points (3.23)
[SOURCE: ISO/IEC TS 8200:2024, 3.7]
3.25
engagement of control
control engagement
process where a controller (3.22) takes over a set of control points (3.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]

© ISO/IEC 2026 – All rights reserved
3.26
transfer of control
control transfer
process of the change of the controller (3.22) that performs a control (3.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.27
AI provider
organization (3.13) or entity (3.28) that provides products or services that uses one or more AI systems
3.28
entity
object
item
anything perceivable or conceivable
EXAMPLE Product, service, process, person, organization (3.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: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;

© ISO/IEC 2026 – All rights reserved
— 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.

© ISO/IEC 2026 – All rights reserved
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 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 .
The logging component logs behaviours of the AI system, as discussed in Clauses 6 and 7.
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, 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

© ISO/IEC 2026 – All rights reserved
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;
© ISO/IEC 2026 – All rights reserved
— 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.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 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.

© ISO/IEC 2026 – All rights reserved
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.
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
[10]
as those that an organization voluntarily chooses to comply with. For additional guidance see ISO 37301 .
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 servic
...

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: [e-mail]
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
...