oSIST prEN 18229-1:2026

• Abstract:

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

• Status: Not Published
• Public Enquiry End Date: 13-Aug-2026
• ICS: 35.030 - IT Security
• ICS: 35.240.01 - Application of information technology in general
• Technical Committee: UMI - Artificial intelligence
• Current Stage: 4020 - Public enquire (PE) (Adopted Project)
• Start Date: 27-May-2026
• Due Date: 14-Oct-2026
• Completion Date: 11-Jun-2026
• Directive: 2024/1689 - EU AI Act
• Mandate: M/593 - COMMISSION IMPLEMENTING DECISION of 22.5.2023 on a standardisation request to the European Committee for Standardisation and the European Committee for Electrotechnical Standardisation in support of Union policy on artificial intelligence
• Mandate: M/593 - COMMISSION IMPLEMENTING DECISION of 22.5.2023 on a standardisation request to the European Committee for Standardisation and the European Committee for Electrotechnical Standardisation in support of Union policy on artificial intelligence
• Mandate: M/613 - Artificial Intelligence_Amd 1 to M/593
• Mandate: M/XXX AI - Artificial Intelligence
• Mandate: M/XXX AI - Artificial Intelligence
• Ref Project: prEN 18229-1 - AI trustworthiness framework - Part 1: Logging

oSIST prEN 18229-1:2026 is the Slovenian adoption of draft European Standard prEN 18229-1 from CEN and CENELEC. It specifies terminology, concepts, requirements and guidance for logging of AI systems, mainly for organizations that place AI systems on the market or put them into service. The document is not sector-specific, so it can be applied across different AI uses, including remote biometric identification (RBI).

What does oSIST prEN 18229-1:2026 specify?

oSIST prEN 18229-1:2026 sets the framework for how AI system logs are planned, generated, protected, retained and documented. Its main technical content is in Clause 5 on record-keeping and Clause 6 on documentation, with Annex ZA giving the link to Regulation 2024/1689.

The document is organized into scope, normative references, terms and definitions, abbreviations, record-keeping, documentation, and an informative annex on the relationship with EU law. In practice, that structure matters because the standard first defines the language, then explains how to choose what to log, how to implement the logging, and what to tell deployers in the instructions for use.

What are the key requirements of oSIST prEN 18229-1:2026?

Logging capability and traceability

Clause 5.2 requires the AI system to be designed and implemented so that it can automatically record events throughout its life cycle. The provider must choose a traceability level that matches the intended purpose and the characteristics of any hazardous situation.

Table 1 links those characteristics to extra logging expectations. In practice, this means the provider has to think about whether harm can be irreversible, fast-moving, widespread, hard for the affected person to notice, or related to fundamental rights, and then set the logging depth, retention and query capability accordingly.

Clause 5.2.3 adds supply-chain traceability. The logs must make it possible to identify both the version affected by a problem and the version that was conformity assessed, either by including the two unique identifiers from FprEN 18286 or by using an equivalent linkable mechanism. This matters when corrective actions, investigations or market surveillance need to connect a log entry to a specific released version.

Identifying what to log

Clause 5.3 requires the provider to determine relevant events from risk scenarios, risk control measures, the AI system functions, interactions with other systems, human oversight functions, and the context and conditions of use. That means the logging design is not a generic checklist - it must follow the way the AI system actually behaves and is used.

Clause 5.3.2 requires the list of events to be updated during post-market phases using pre-market and post-market information review. In practice, logging is expected to evolve as the provider learns more about how the system performs in the field.

Implementing logging and protecting the logs

Clause 5.4 ties the logged information to FprEN ISO/IEC 24970 and requires the provider to define storage infrastructure and retention. Logs must be kept for at least six months, or longer where regulatory requirements or the traceability conditions in 5.2.2 apply.

Clause 5.4.3 requires log protection across the full life cycle and asks the provider to minimize personal data in logs where possible without reducing traceability, hazardous-situation analysis, post-market monitoring or deployer monitoring. In practice, the provider should design for privacy from the start, for example by using de-identification or metadata analysis where that still preserves the needed evidence.

Events that must be considered for logging

Clause 5.5 groups the main event types the provider must evaluate and, in several cases, log. These include potential attacks, adversarial attacks, outlier inputs, user requests, requests from affected persons, operation outside predefined limits, use outside the intended purpose, model drift, unwanted bias detection, human oversight events, data quality issues, invalid data, performance events and system version or configuration changes.

The important practical point is that the standard does not treat logging as mere storage. The provider must systematically decide which events reveal hazardous situations, weak risk controls, substantial modifications or post-market performance issues, and then record those events. For post-market monitoring and deployer monitoring, the plan or procedures must also include the queries needed to make the logs usable.

Special record-keeping for RBI systems

Clause 5.6 adds minimum logging requirements for RBI systems, especially high-risk RBI systems. The logs must support integrity and automatic recording of operational use, reference database information, input data and natural persons involved in review.

For one-to-many biometric identification, the provider must preserve the complete reference database state used for the check, or a documented metadata-based alternative when full storage is impractical. For many-to-one biometric identification, the log must capture candidate matches, match scores, relevant database metadata and the reference data that supports the result. Manual review actions must also be recorded with a traceable reviewer identifier, the decision and a timestamp.

Documentation and instructions for use

Clause 6 requires technical documentation for the logging capabilities and specifies what the instructions for use must tell the deployer. The instructions must describe what is logged, how the deployer can access the logs, and the retention period, including minimum and maximum retention and any conditions for overwriting, archiving or deletion.

If the technical architecture prevents direct provider access to logs, the instructions for use must set out alternative arrangements such as user-retained logs, aggregate statistics or incident-triggered log provision. That is important for embedded, stand-alone or edge deployments where log access has to fit the product architecture.

What terms does oSIST prEN 18229-1:2026 define?

• Provider - the person or organization that develops an AI system or has it developed and places it on the market or puts it into service.
• Deployer - the person or organization using an AI system under its authority, except for personal non-professional use.
• AI system - a machine-based system that operates with varying autonomy and infers outputs from input data to influence physical or virtual environments.
• Intended purpose - the use intended by the provider, including the context and conditions of use stated in the instructions for use, technical documentation and promotional or sales materials.
• Substantial modification - a post-market change that was not foreseen in the original conformity assessment and that affects compliance or changes the intended purpose.
• Event - a change of state or circumstances, including expected changes that do not occur, used as the basis for logging throughout the AI system life cycle.
• Traceability - the ability to trace the AI system and its history, including enough log-based evidence to reconstruct how it functioned.
• RBI - remote biometric identification.

Who uses oSIST prEN 18229-1:2026?

Providers use oSIST prEN 18229-1:2026 to design the logging capability, choose events to log, set retention, and prepare the technical documentation and instructions for use. Deployers use it to understand what data they can access and how logs support their monitoring duties.

It is also relevant to compliance, quality management, product safety, security, post-market monitoring and biometric system teams. Because the standard is not tied to one sector, it can be used wherever AI systems are placed on the market or put into service, especially where traceability, incident analysis, regulatory review or RBI logging are needed.

Which standards are used with oSIST prEN 18229-1:2026?

• FprEN 18286 - provides the quality management system context for EU AI Act regulatory purposes and supports the unique identifiers used for traceability in Clause 5.2.3.
• FprEN ISO/IEC 24970 - provides the logging framework used for log content, storage, protection, development logging and many of the event categories named in Clause 5.
• prEN 18228 - provides the AI Risk Management framework used for risk scenarios, risk control measures, residual risk and post-market information review.

What does the oSIST prEN 18229-1:2026 document contain?

Clause 5 contains the main operational material, including the traceability logic in Table 1, the summary of event categories in Table 2, and the detailed event types to consider for hazardous situations, substantial modifications, post-market monitoring and deployer monitoring. It also includes the RBI-specific record-keeping requirements and worked examples for biometric identification, database preservation, input data archiving and manual review logging.

Clause 6 contains the documentation requirements for technical documentation and instructions for use. Annex ZA contains the correspondence table between this European Standard and Regulation 2024/1689, which is used for conformity work and for understanding which clauses support which AI Act requirements.

SLOVENSKI STANDARD
01-julij-2026
Okvir zaupanja v umetno inteligenco - 1. del: Logiranje
AI trustworthiness framework - Part 1: Logging
Rahmenwerk für Vertrauenswürdigkeit von Künstlicher Intelligenz
Cadre de confiance pour l’IA
Ta slovenski standard je istoveten z: prEN 18229-1
ICS:
35.030 Informacijska varnost IT Security
35.240.01 Uporabniške rešitve Application of information
informacijske tehnike in technology in general
tehnologije na splošno
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

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

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

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

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

CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2026 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. prEN 18229-1:2026 E
reserved worldwide for CEN national Members and for
CENELEC Members.
prEN 18226-1:2026 (E)
9 Contents Page
10 European foreword . 3
11 Introduction . 4
12 1 Scope . 5
13 2 Normative references . 5
14 3 Terms and definitions . 5
15 3.1 Terms related to the EU AI Act . 5
16 3.2 Other terms . 7
17 3.3 Terms related to risk . 9
18 4 Abbreviations . 10
19 5 Record-keeping . 10
20 5.1 Concept of event . 10
21 5.2 General principles for logging capabilities. 10
22 5.3 Requirements for identifying events to log . 12
23 5.3.1 General. 12
24 5.3.2 Continual reassessment of events to log . 12
25 5.4 Requirements for logging implementation . 13
26 5.4.1 General. 13
27 5.4.2 Storage and retention requirements . 13
28 5.4.3 Log protection, life cycle coverage and privacy . 13
29 5.5 Events to log . 13
30 5.5.1 General. 13
31 5.5.2 Events supporting analysis of hazardous situations that can be relevant to AI systems
32 presenting a risk . 14
33 5.5.3 Other events supporting analysis of hazardous situations that can present risks to health,
34 safety or fundamental rights or that can be relevant to AI systems presenting a risk . 15
35 5.5.4 Events indicating potential substantial modifications. 15
36 5.5.5 Events for post-market monitoring . 15
37 5.5.6 Events for supporting deployer in monitoring system operation . 16
38 5.6 Record keeping for RBI systems . 16
39 5.6.1 General. 16
40 5.6.2 Period of operational use . 17
41 5.6.3 Reference database . 17
42 5.6.4 Input data. 18
43 5.6.5 Natural persons involved in review . 18
44 6 Documentation . 19
45 6.1 Technical documentation . 19
46 6.2 Instructions for use . 19
47 Annex ZA (informative) Relationship between this European Standard and the essential
48 requirements of Regulation 2024/1689 aimed to be covered . 20
49 Bibliography . 21
prEN 18226-1:2026 (E)
50 European foreword
51 This document (prEN 18229-1:2026) has been prepared by the Joint Technical Committee CEN-
52 CENELEC/JTC 21 “Artificial Intelligence”, the secretariat of which is held by DS.
53 This document is currently submitted to the CEN Enquiry.
54 This document has been prepared under a standardization request addressed to CEN-CENELEC by the
55 European Commission. The Standing Committee of the EFTA States subsequently approves these
56 requests for its Member States.
57 For the relationship with EU Legislation, see informative Annex ZA, which is an integral part of this
58 document.
prEN 18226-1:2026 (E)
59 Introduction
60 5.1 introduces the concept of an event, and 5.2 provides general requirements and links these general
61 requirements to levels of traceability. 5.3 provides general requirements for events to log and 5.4 provides
62 requirements on the implementation of logging.
63 5.5 links the specific events to the objectives of logging, with requirements for how to determine exactly
64 which events are logged.
65 5.6 provides additional requirements for RBI systems.
prEN 18226-1:2026 (E)
66 1 Scope
67 This document provides terminology, concepts, requirements, and guidance for logging of AI systems.
68 It is primarily intended for organizations placing on the market or putting into service AI systems and is
69 not specific to any particular sector.
70 2 Normative references
71 The following documents are referred to in the text in such a way that some or all of their content
72 constitutes requirements of this document. For dated references, only the edition cited applies. For
73 undated references, the latest edition of the referenced document (including any amendments) applies.
74 FprEN 18286:—, Artificial intelligence — Quality management system for EU AI Act regulatory purposes
75 FprEN ISO/IEC 24970:—, Artificial intelligence — AI system logging
76 prEN 18228:—, AI Risk Management
77 3 Terms and definitions
78 For the purposes of this document, the following terms and definitions apply.
79 ISO and IEC maintain terminology databases for use in standardization at the following addresses:
80 — ISO Online browsing platform: available at https://www.iso.org/obp/
81 — IEC Electropedia: available at https://www.electropedia.org/
82 3.1 Terms related to the EU AI Act
83 3.1.1
84 provider
85 natural or legal person, public authority, agency or other body that develops an AI system (3.1.5) or a
86 general-purpose AI model or that has an AI system (3.1.5) or a general-purpose AI model developed and
87 places it on the market or puts the AI system (3.1.5) into service under its own name or trademark,
88 whether for payment or free of charge
89 Note 1 to entry: A distributor, importer, deployer (3.1.2) or other third party can be considered a provider (3.1.1)
90 of an AI system (3.1.5) in certain circumstances.
91 [SOURCE: EU AI Act 2024/1689, (Article 3(3)), modified – removed “a”]
92 3.1.2
93 deployer
94 natural or legal person, public authority, agency or other body using an AI system (3.1.5) under its
95 authority except where the AI system (3.1.5) is used in the course of a personal non-professional activity
96 [SOURCE: EU AI Act 2024/1689, (Article 3(4)), modified – removed “a”]
97 3.1.3
98 life cycle
99 evolution of a system, product, service, project or other human-made entity, from inception through
100 retirement
101 [SOURCE: ISO/IEC/IEEE 15288:2023, 3.21, modified – replaced “conception” with “inception”]
prEN 18226-1:2026 (E)
102 3.1.4
103 instructions for use
104 information provided by the provider (3.1.1) to inform the deployer (3.1.2) of, in particular, an AI system
105 (3.1.5) ’s intended purpose (3.1.6) and proper use
106 [SOURCE: EU AI Act 2024/1689, (Article 3(15)), modified – removed “means the”]
107 3.1.5
108 AI system
109 machine-based system that is designed to operate with varying levels of autonomy and that can exhibit
110 adaptiveness after deployment and that, for explicit or implicit objectives, infers, from the input it
111 receives, how to generate outputs such as predictions, content, recommendations, or decisions that can
112 influence physical or virtual environments
113 Note 1 to entry: The verb “can” represents a possibility, not all AI systems that fit the above definition have this
114 ability to adapt after deployment.
115 [SOURCE: EU AI Act (Article 3(1)), modified - removed “a” , replaced “may” with “can” based on the use
116 of verbs in standards. Added Note 1 to entry.]
117 3.1.6
118 intended purpose
119 use for which an AI system (3.1.5) is intended by the provider (3.1.1), including the specific context and
120 conditions of use, as specified in the information supplied by the provider (3.1.1) in the instructions for
121 use (3.1.4) promotional or sales materials and statements, as well as in the technical documentation
122 [SOURCE: EU AI Act 2024/1689, (Article 3(12)), modified – removed “means the”]
123 3.1.7
124 performance
125 ability of an AI system (3.1.5) to achieve its intended purpose (3.1.6)
126 [SOURCE: EU AI Act 2024/1689, (Article 3(18)), modified – removed “the”]
127 3.1.8
128 substantial modification
129 change to an AI system (3.1.5) after its placing on the market or putting into service which is not foreseen
130 or planned in the initial conformity assessment carried out by the provider (3.1.1) and as a result of which
131 the compliance of the AI system (3.1.5) with the applicable regulatory requirements is affected or results
132 in a modification to the intended purpose (3.1.6) for which the AI system (3.1.5) has been assessed
133 Note 1 to entry: Rephrased from the AI Act Article (3)(23) to reference applicable regulatory requirements instead
134 of a specific reference to the AI Act Chapter III, Section 2.
135 [SOURCE: EU AI Act 2024/1689, (Article 3(23)), modified – as described in Note 1]
136 3.1.9
137 input data
138 data provided to or directly acquired by an AI system (3.1.5) on the basis of which the system produces
139 an output
140 [SOURCE: EU AI Act 2024/1689, (Article 3(33)), modified – removed “means”]
prEN 18226-1:2026 (E)
141 3.1.10
142 personal data
143 information relating to an identified or identifiable natural person (also data subject)
144 3.1.11
145 biometric data
146 personal data (3.1.10) resulting from specific technical processing relating to the physical, physiological
147 or behavioural characteristics of a natural person, such as facial images or dactyloscopic data
148 [SOURCE: EU AI Act 2024/1689, (Article 3(34)), modified – removed “means”]
149 3.1.12
150 AI system presenting a risk
151 product presenting a risk
152 product having the potential to affect adversely health and safety of persons in general, health and safety
153 in the workplace, protection of consumers, the environment, public security and other public interests,
154 protected by the applicable Union harmonization legislation, to a degree which goes beyond that
155 considered reasonable and acceptable in relation to its intended purpose (3.1.6) or under the normal or
156 reasonably foreseeable conditions of use of the product concerned, including the duration of use and,
157 where applicable, its putting into service, installation and maintenance requirements
158 Note 1 to entry: For the purposes of this document, AI systems presenting a risk shall only be in so far as they
159 present risks to the health or safety, or to fundamental rights, of persons.
160 Note 2 to entry: These risks are not necessarily identified by the provider (3.1.1) before placing the AI system (3.1.5)
161 on the market or into service.
162 [SOURCE: EU Regulation 2019/1020, (Article 3(19)), modified – removed “means a” and added Note 1]
163 3.2 Other terms
164 3.2.1
165 biometric probe
166 biometric sample or biometric feature set input to an algorithm for comparison to a biometric
167 reference(s)
168 Note 1 to entry: In some comparisons a biometric reference can potentially be used as the subject of the comparison
169 with other biometric references or incoming biometric samples used as the objects of the comparisons.
170 Note 2 to entry: Typically, in a comparison process, incoming biometric samples serve as the subject of comparisons
171 against objects stored as biometric references in a database.
172 [SOURCE: ISO/IEC 2382-37:2022, 37.03.14]
173 3.2.2
174 biometric identification
175 automated recognition of physical, physiological, behavioural, or psychological human features for the
176 purpose of establishing the identity of a natural person by comparing biometric data (3.1.11) of that
177 individual to biometric data (3.1.11) of individuals stored in a database
178 [SOURCE: EU AI Act 2024/1689, (Article 3(35)), modified – removed “means the”]
prEN 18226-1:2026 (E)
179 3.2.3
180 remote biometric identification system
181 AI system (3.1.5) for the purpose of identifying natural persons, without their active involvement,
182 typically at a distance through the comparison of a person’s biometric data (3.1.11) with the biometric
183 data (3.1.11) contained in a reference database
184 [SOURCE: EU AI Act 2024/1689, (Article 3(41)), modified – removed “means an”]
185 3.2.4
186 one-to-many biometric identification
187 checking whether a specific known individual (probe subject) appears in a reference database
188 EXAMPLE Law enforcement checks a suspect’s photograph against a database of known criminals to verify
189 presence or absence in the database.
190 3.2.5
191 many-to-one biometric identification
192 identifying which individuals in a stream of probe subjects match entries in a reference database
193 EXAMPLE Post event (3.2.8) investigation where the AI system (3.1.5) compares faces of people passing by
194 against a watchlist of wanted individuals.
195 3.2.6
196 operational use
197 continuous period during which the system is active and performing biometric identification (3.2.2)
198 3.2.7
199 event
200 change of states of any type or a change of a particular set of circumstances, within a time continuum
201 Note 1 to entry: An event can have a single occurrence or multiple occurrences or a set of related occurrences. When
202 discussing multiple events, they can form a specific sequence or causal chain. It is important to note that an event
203 can have one or more causes and can lead to one or more consequences.
204 Note 2 to entry: This also includes an expected change of circumstances or of states which does not occur.
205 Note 3 to entry: Events are detected throughout the AI system life cycle (3.1.3): from inception based on the intended
206 purpose (3.1.6), through product development and field tests, to conformity assessment, to post-market surveillance
207 and user feedback loops.
208 Note 4 to entry: An event can be part of a set of events useful for different analyses such as co-occurrence analysis,
209 causal chain analysis, sequence analysis, or other time series analysis.
210 3.2.8
211 automatic
212 automation
213 automated
214 pertaining to a process or system that, under specified conditions, functions without human intervention
215 [SOURCE: ISO/IEC 2382:2015, 2121282]
prEN 18226-1:2026 (E)
216 3.2.9
217 integrity
218 property of accuracy and completeness
219 [SOURCE: ISO/IEC 27000:2018, 3.36]
220 3.2.10
221 traceability
222 ability to trace the AI system (3.1.5) and its history
223 Note 1 to entry: Traceability includes information on how AI systems have been specified, developed, verified,
224 validated, operated, monitored and retired.
225 Note 2 to entry: in the context of Article 12 of the EU AI Act [1] traceability means the ability to reconstruct, from
226 the logs automatically generated by an AI system, a sufficient account of how the system was functioning to allow a
227 competent authority or provider (3.1.1) to verify that the AI system was operating in conformity with the version
228 placed on the market and within the boundaries of its intended purpose (3.1.6).
229 [SOURCE: FprEN 18286:—, 3.3.2, modified – added Note 2]
230 3.2.11
231 de-identification process
232 process of removing the association between a set of identifying attributes and the data principal
233 Note 1 to entry: De-identification includes the process of altering data, via modifying or removing data, so that
234 individuals or entities cannot be identified, directly or indirectly.
235 [SOURCE: FprEN ISO/IEC 24970:—, 3.11]
236 3.3 Terms related to risk
237 3.3.1
238 harm
239 injury or damage to the health of a person or groups of persons, or interference with fundamental rights
240 Note 1 to entry: For the purpose of this document, damage to property or the environment, and the disruption or
241 destruction of critical infrastructure, are considered harms when they can result in injury or damage to the health
242 of a natural person or groups of persons or interference with fundamental rights.
243 Note 2 to entry: Interference with fundamental rights can be tangible or intangible, physical, psychological, societal
244 or economic, irrespective of the rightsholder’s awareness, in accordance with EU law, including the EU Charter on
245 Fundamental Rights.
246 Note 3 to entry: Safety in product safety risk management standards is understood as the absence of unacceptable
247 risk. In the context of this document, safety refers to the protection from harm from the use of the AI system (3.2.1).
248 [SOURCE: prEN 18228:—, 3.6.3]
249 3.3.2
250 hazard
251 potential source of harm (3.3.1)
252 Note 1 to entry: Threats and vulnerabilities to the AI system (3.1.5) itself are hazards only if they are themselves a
253 source of harm (3.3.1).
254 [SOURCE: prEN 18228:—, 3.6.1]
prEN 18226-1:2026 (E)
255 3.3.3
256 hazardous situation
257 circumstance in which people, property or the environment is/are exposed to one or more hazard (3.3.2)
258 [SOURCE: prEN 18228:—, 3.6.2]
259 4 Abbreviations
260 RBI remote biometric identification
261 5 Record-keeping
262 5.1 Concept of event
263 Logs of an AI system record events throughout the life cycle of the system according to pre-defined criteria.
264 Events can include changes of states of the AI system and changes to the data (digital and analog) the AI
265 system is processing such as changes in:
266 a) changes of input sensor measurement values (e.g. temperature values in degree Celsius), changes of
267 digital input states (e.g. a device changing from “on” state to “off” state), changes in IoT data streams
268 or changes in inputs (e.g. alarm state, or any continuous measurement value converted into digital)
269 from connected systems or devices;
270 b) changes in performances of the AI system, changes in resource utilization (e.g. CPU, bandwidth) or
271 changes in accuracy of AI predictions;
272 c) changes in security status;
273 d) changes in data storage and management measurements, changes in data quality and integrity
274 metrics.
275 5.2 General principles for logging capabilities
276 5.2.1 The AI system shall be designed and implemented with the technical capability to automatically
277 record events throughout its life cycle.
278 The logging capabilities shall be designed to enable these purposes:
279 a) identifying situations that can result in the AI system presenting a risk or in a substantial
280 modification;
281 b) facilitating post-market monitoring;
282 c) monitoring the operation of the AI system by deployers;
283 d) for AI systems performing RBI, the specific requirements.
prEN 18226-1:2026 (E)
284 5.2.2 The provider shall:
285 a) determine the level (extent/degree) of traceability of the functioning of the AI system appropriate to
286 its intended purpose and evaluate the characteristics of identified hazardous situations in accordance
287 with Table 1 to determine which corresponding requirements apply:
288 Table 1 — Traceability levels
Characteristics of the hazardous situation Specific additional requirements
1) Is harm associated with any identified Log retention shall cover the period until the
hazardous situation irreversible? harm can be identified and attributed to th
...