Which AI Act obligations apply to high-risk AI systems?

education

Logging in admission and assessment: what the institution keeps in its own hands

A university of applied sciences uses a purchased AI system that ranks student admissions and also raises flags during digital assessment. The logs sit in the supplier environment, which hands them over on request. The teaching organisation wonders whether that settles the matter or whether the school retains a duty of its own.

Provenance: Article 12(1) requires a high-risk AI system to technically allow for the automatic recording of events (logs) over the lifetime of the system, and Article 12(2) ties that recording to a level of traceability appropriate to the intended purpose of the system. Article 26(6) provides that deployers keep the automatically generated logs to the extent those logs are under their control, for a period appropriate to the intended purpose, of at least six months, unless applicable Union or national law provides otherwise, in particular Union law on the protection of personal data. Article 19(1) places a corresponding retention duty on providers for the logs generated by their systems that are under their control, likewise for at least six months.

On our reading, the fact that the supplier hosts the logs does not by itself place the school outside Article 26(6): what matters is whether the logs are under its control. The Regulation does not define that notion, and on our reading server location is not decisive in itself; the question is whether you can actually and contractually dispose of those logs, and it has to be answered for each procurement. So agree at procurement that the institution can request, export and itself retain the logs for the chosen period, and record which admission and assessment events that covers. Take data protection into account at the same time, because the same provision allows other Union or national law to cap the retention period.

Editorial example. The rule above is in the Regulation. The situation was written by us to show how that rule plays out in this sector, and is not taken from a worked case in official guidance.

Article 12(1) and (2), Article 19(1) and Article 26(6)

manufacturing and industry

Logging on the production line: which logs the manufacturer keeps and which the factory keeps

A manufacturer supplies an AI system that runs as a safety component inside the machinery of a production line and also drives quality control. The factory operating the line keeps only the alerts visible in the local controller; the rest of the recording flows to the supplier environment. The question is who has to keep which logs when it later has to be reconstructed why the line was halted.

Provenance: Article 12(1) requires high-risk AI systems to technically allow for the automatic recording of events (logs) over the lifetime of the system. Under Article 12(2), those logging capabilities must enable the recording of events relevant for identifying situations that may result in the system presenting a risk within the meaning of Article 79(1) or in a substantial modification, for facilitating the post-market monitoring referred to in Article 72, and for monitoring the operation of the high-risk AI systems referred to in Article 26(5). Article 19(1) obliges providers to keep those automatically generated logs to the extent they are under their control, for a period appropriate to the intended purpose of the system, of at least six months, unless applicable Union or national law provides otherwise. Article 26(6) places a corresponding retention duty on deployers for the logs under their control, with the same six-month floor.

We read Article 19 together with Article 26(6) as leaving the manufacturer, acting here as the provider, and the factory, acting as the deployer, each with a retention duty of its own for the logs under its control. The Regulation does not say when logs count as being under your control, and on our reading the place where the recording physically lands does not settle that by itself; the question has to be answered system by system. For a production line that means recording which events stay in the machinery controller and which travel to the supplier, and securing access to that second set contractually before you need it. Leave that unarranged and you risk being unable to trace a line stoppage or a quality control rejection back to the behaviour of the system.

Editorial example. The rule above is in the Regulation. The situation was written by us to show how that rule plays out in this sector, and is not taken from a worked case in official guidance.

Article 12(1) and (2), Article 19(1) and Article 26(6)

workplace and staff

Logging in task allocation at work: evidence about the system or a file on the employee

An employer deploys an AI system that handles task allocation among staff and summarises their performance for the performance review. HR wants to know what record of those outcomes has to be retained when an employee objects months later to a promotion decision.

Provenance: Article 12(1) requires high-risk AI systems to technically allow for the automatic recording of events (logs) over the lifetime of the system. Article 12(2)(c) names, as one of the purposes of those logging capabilities, monitoring the operation of the systems referred to in Article 26(5), and that paragraph obliges deployers to monitor operation on the basis of the instructions for use and, where relevant, to inform the provider in accordance with Article 72. Article 26(6) obliges deployers to keep the automatically generated logs to the extent they are under their control, for a period appropriate to the intended purpose, of at least six months, unless applicable Union or national law provides otherwise. Article 19(1) sets out a corresponding retention duty for providers, with the same six-month floor.

We read Article 12(2) as putting the logging capabilities there first of all to follow risks, substantial modifications and the operation of the system, not to sharpen judgements about individual staff. Whether that statement of purpose also limits what the retained logs may later be used for is something Article 12 does not say: on our reading that limit has to come from data protection law, to which Article 26(6) itself refers. For HR a practical line follows: keep what is needed to trace an outcome and to carry out the monitoring under Article 26(5), and settle in writing beforehand whether those same files may double as a performance record. Bear in mind that the six-month floor can be shorter than the period within which an employee challenges a promotion decision; the Regulation does not govern that evidential position.

Editorial example. The rule above is in the Regulation. The situation was written by us to show how that rule plays out in this sector, and is not taken from a worked case in official guidance.

Article 12(1) and (2)(c), Article 19(1) and Article 26(5) and (6)

retail and consumer

Webshop builds its own consumer credit check: what belongs in the file

A non-food retail chain lets customers pay later in its webshop and decides at checkout whether a consumer qualifies. The team builds that assessment system in house, on top of a pre-trained model supplied by a vendor. The question is what has to be on record before the feature goes live, and who has to put it there.

Provenance: Article 11(1) requires the technical documentation of a high-risk AI system to be drawn up before that system is placed on the market or put into service, and to be kept up to date. It must be drawn up so as to demonstrate compliance with the requirements of that Section and to give national competent authorities and notified bodies the necessary information, in a clear and comprehensive form, to assess that compliance; it contains at a minimum the elements set out in Annex IV. Annex IV lists those elements as applicable to the AI system concerned, and asks among other things for the methods and steps performed for development, including, where relevant, recourse to pre-trained systems or tools provided by third parties and how those were used, integrated or modified by the provider, for the validation and testing procedures used, and for a description of relevant changes made by the provider to the system through its lifecycle. SMEs, including start-ups, may supply those elements in a simplified manner; where they take that route, they must use the simplified form the Commission is to establish for that purpose.

Article 11 puts the documentation duty on the provider, so the first open question here is who that provider is. If the creditworthiness assessment of consumers counts as high-risk in your situation, then in our reading there is a strong case that a webshop assembling the system itself and putting it into service under its own name is no longer merely a deployer but ends up on the provider side, carrying the documentation duty that comes with it. Article 11 does not settle that allocation of roles, so test it against the definitions and against Article 25 before assuming the file is your vendor's problem. In our reading the hard part in retail is not the first version of the file but the pace afterwards, because a webshop often ships changes per release while the file stays frozen at the state it had when the feature went into service. So contract for the provenance, training and testing information that Annex IV expects from you when you buy the pre-trained model, and assign per release who updates the file.

Editorial example. The rule above is in the Regulation. The situation was written by us to show how that rule plays out in this sector, and is not taken from a worked case in official guidance.

Article 11(1) and Annex IV

Integrating AI Act requirements into existing risk and quality systems

According to the draft guidelines of 19 May 2026, which are expressly published as a draft for stakeholder feedback and have no binding force, the AI Act provides mechanisms to reduce the compliance burden for economic operators. The draft guidelines cite Article 8(2) AI Act on the interplay with sectoral legislation, Article 9(10) AI Act on risk management and Article 17(3) AI Act on quality management, which allow economic operators to add, where necessary and appropriate, an assessment of AI-specific risks to already existing risk and quality management systems. Article 40 AI Act further requires that harmonised standards under the AI Act be consistent with standards developed under the Annex I harmonisation legislation. The draft guidelines state that these mechanisms enable economic operators to meet both the AI Act and the harmonisation legislation within a single compliance framework, thereby avoiding duplication of effort while maintaining a high level of protection of health, safety and fundamental rights.

Draft guidelines Annex I, points (61) and (62)

ISO/IEC 5259 series: data quality for analytics and machine learning

The ISO/IEC 5259 series (Artificial intelligence: Data quality for analytics and machine learning) comprises five parts: part 1 (overview, terminology and examples), part 2 (data quality measures), part 3 (data quality management requirements and guidelines) and part 4 (data quality process framework), all published in 2024, plus part 5 (data quality governance framework), published in February 2025. CEN-CENELEC has adopted parts as European standards, including EN ISO/IEC 5259-4:2025 and EN ISO/IEC 5259-3:2025. No part is cited in the Official Journal, so no presumption of conformity under Article 40 arises. The deliverable intended to do so for Article 10 is prEN 18284.

prEN 18284: quality and governance of datasets in AI

prEN 18284 (Artificial intelligence: Quality and governance of datasets in AI) is the JTC 21 deliverable under M/613 for Article 10 of the AI Act, which sets requirements for the training, validation and testing datasets of high-risk AI systems. As at June 2026 the deliverable was at the drafting stage. It has not yet been published as an EN and is not cited in the Official Journal.

EN 18286:2026: quality management system for EU AI Act regulatory purposes

EN 18286:2026 (Artificial intelligence: Quality management system for EU AI Act regulatory purposes) was drafted by CEN/CLC/JTC 21 under standardisation request M/613 and approved by CEN-CENELEC on 12 July 2026. It is the first JTC 21 deliverable to reach publication. According to a published coverage statement accompanying the standard, not yet confirmed by a second independent source, it addresses Article 17(1) points (a) to (m) and Article 11(1) first sentence, and expressly not Article 17(2) to (4) or Article 72. The standard is NOT currently cited in the Official Journal. The Article 40 presumption of conformity only attaches after that citation.

EN ISO/IEC 42001: artificial intelligence management system

ISO/IEC 42001:2023 is the first certifiable international standard for an AI management system, published on 18 December 2023 and structured on the plan-do-check-act cycle. The text was adopted unchanged as EN ISO/IEC 42001:2026, approved by CEN on 13 March 2026, with national implementation by the member standards bodies. This adoption is not a deliverable under standardisation request M/613: the standard is not cited in the Official Journal and therefore confers no presumption of conformity under Article 40. For Article 17, the designated deliverable under M/613 is EN 18286:2026; that standard is likewise not cited in the Official Journal.