Source-traceable links from AI Act changes and obligations to actors, actions, evidence, controls and public tools.
EU Artificial Intelligence Act 2024/1689
Fingerprint of our source record (URL, edition version, verification date). Not an archive copy or content hash of the external document.
Draft guidelines on the classification of high-risk AI systems
CEN-CENELEC JTC 21: European standards under standardisation request M/613
Guidelines on prohibited AI practices, C(2025) 5052 final
Guidelines on the definition of an AI system, C(2025) 5053 final
Living repository of AI literacy practices
Code of Practice on transparency of AI-generated content
ISO/IEC JTC 1/SC 42: international standards for artificial intelligence
Justify the Article 6(3) exception against each individual condition
Name which of the four Article 6(3) conditions you invoke, with facts, and separately justify why the system poses no significant risk of harm to health, safety or fundamental rights and does not materially influence the outcome of decision making.
The intended purpose of the system falls within a use case listed in Annex III.
Notwithstanding the first subparagraph of Article 6(3), an AI system referred to in Annex III shall always be considered high-risk where it performs profiling of natural persons.
Classify the use case and document the outcome
Assess Article 5, Article 6 and Annex III in that order and document purpose, context and any Article 6(3) exception.
Run the profiling test before invoking the Article 6(3) exception
Establish as the first question whether the system performs profiling of natural persons; if yes, the Article 6(3) route falls away and the system remains high-risk, regardless of the four conditions.
You are considering relying on Article 6(3) for a system falling under Annex III.
Assign human oversight and give those people a mandate
Name, per high-risk system, who exercises oversight, and ensure that person has the competence, training, authority and support to actually set the output aside.
To be carried out before putting into service and again on every change to the intended purpose or to the provider's instructions for use.
Assess origin, representativeness, errors and completeness and examine possible bias with appropriate mitigation.
Document system description, development process, data, oversight measures, performance and risk management before market placement.
Ensure the system automatically records events relevant to risk identification and post-market monitoring.
Describe capabilities, limitations, accuracy, oversight measures and expected lifetime in comprehensible form.
Design and assign effective human oversight
Determine oversight measures per system, appoint competent persons and give them the mandate to intervene or stop.
Set and test performance and security levels
Determine appropriate accuracy, test robustness against errors and misuse, and take AI-specific security measures.
Describe strategies, procedures and responsibilities for compliance, from design and data to post-market monitoring.
Take role- and context-specific AI literacy measures
Determine for each role, system and context which combination of instruction, guidance, practice or training is appropriate.
Determine per role which knowledge is needed to use the specific system responsibly
Map roles against the AI systems they use and record per combination what a person must be able to judge: what the system does, where it fails, who it is applied to, and when to intervene or escalate.
Your organisation is a provider or deployer of at least one AI system within scope.
Article 4 prescribes no specific course format, exam or certificate and does not require a guaranteed individual level.
Deliver instruction at the moment a new tool or a new employee arrives
Attach the literacy measure to two fixed moments in existing processes: the rollout of a new AI tool and the onboarding of anyone gaining access to an existing tool.
A new AI tool is put into use or a person gains access to an existing AI tool.
Screen every use case against Article 5 first
Before procurement, build or deployment, check whether the use case falls under a prohibited practice and stop or redesign early rather than after the fact.
Implement the applicable disclosure, marking or label
First determine which paragraph of Article 50 applies, then implement the specific transparency measure.
Record per publication channel when AI text carries a disclosure and who holds editorial responsibility
Determine per channel whether the text is published to inform the public on matters of public interest, who performs the human review, who holds editorial responsibility, and which standard wording you use when the disclosure is required.
You are a deployer and publish content generated or manipulated, wholly or partly, by an AI system.
The Article 50(4) duty does not apply where the use is authorised by law to detect, prevent, investigate or prosecute criminal offences.
Test every system in your AI register against the five Article 50 scenarios
For each AI system, walk through the distinct Article 50 scenarios (direct interaction, synthetic output, emotion recognition or biometric categorisation, deep fake, published text on matters of public interest) and record per paragraph whether it applies, does not apply or falls under an exception, with the reason.
The system is in your AI register and is placed on the market, put into service or used in the Union.
Article 50(1) does not apply where it is obvious, from the point of view of a reasonably well-informed, observant and circumspect natural person and taking into account the circumstances and the context of use, that the person is interacting with an AI system. In addition, paragraphs 1 to 4 each contain an exception for AI systems authorised by law to detect, prevent, investigate or prosecute criminal offences, subject to appropriate safeguards for the rights and freedoms of third parties. In paragraph 1 that latter exception does not apply to systems available for the public to report a criminal offence.
Perform model evaluations and risk mitigation
Evaluate the model including adversarial testing, assess and mitigate systemic risks, report serious incidents and secure the model.
Apply to a sandbox and agree the sandbox plan
Apply to the competent authority, agree a specific sandbox plan, and record which uncertainty about the Regulation you want resolved inside the sandbox.
Applies as soon as you decide to enter an AI regulatory sandbox as a provider or prospective provider, possibly in partnership with a deployer or another third party.
Article 58(2), point (d), requires the implementing acts to ensure access free of charge for SMEs and start-ups, subject to exceptional costs that the authority may recover in a fair and proportionate manner. The Regulation does not extend that free access to larger undertakings. Check with the authority concerned which cost regime it applies for as long as the implementing acts have not been adopted.
Submit the testing plan, obtain approval and register the test
Draw up a real-world testing plan, submit it to the market surveillance authority, obtain approval, register the test with a Union-wide unique single identification number, and record the division of roles with your deployer.
Applies before you start testing in real world conditions outside a sandbox. All conditions in Article 60(4) must be met cumulatively; it is not a menu.
Tacit approval after 30 days applies only where national law provides for it. Where national law does not, express authorisation remains required. For the systems referred to in Annex III, points 1, 6 and 7, in law enforcement, migration, asylum and border control, registration runs through the secure non-public section of the EU database under Article 49(4), point (d). For the systems referred to in Annex III, point 2, critical infrastructure, a different route applies: Article 49(5) requires registration at national level.
Systematically collect and analyse real-world data on the system’s performance and compliance throughout its lifetime.
Set up an incident process with reporting routes
Define what a serious incident is, assign the reporting route to the supervisor and rehearse the process.
Set up an iterative risk management process
Identify and analyse known and reasonably foreseeable risks, evaluate them and take measures, repeating the cycle on every change.
Assign an internal owner and a date to each point of Article 16
Translate the twelve points (a) to (l) into twelve named owners with a start date, so that no point falls between product management, quality and legal.
To be carried out as soon as it is established that you are the provider of a system classified as high-risk under Article 6, well before the intended date of placing on the market.
Complete the conformity route before market placement
Select the correct assessment procedure, draw up the EU declaration of conformity, affix the CE marking and register in the EU database.
Map the affected groups and their specific risks of harm
Name the categories of natural persons and groups likely to be affected by the use in this specific context, and work out the specific risks of harm per category, using the information the provider supplied under Article 13.
You are a body governed by public law, a private entity providing public services, or a deployer of a system under Annex III point 5(b) or 5(c), and you deploy a high-risk system under Article 6(2).
High-risk AI systems intended for the area listed in Annex III point 2 fall outside the Article 27(1) FRIA duty.
Assess process, duration, affected persons, risks, oversight, mitigation and complaint mechanisms and notify results where required.
Set up the complaint mechanism and internal governance before the system runs
Describe the measures taken if a risk materialises, who decides internally, through which route an affected person can complain, within which deadline you respond, and who is authorised to stop the use.
The Article 27(1) FRIA duty applies to the system.
Maintain GPAI documentation and transparency information
Maintain technical documentation, information for downstream providers, a copyright policy and a public summary of training content.
Assemble the downstream information package under Annex XII
Build one package for providers integrating your model, covering the intended tasks and integration options, acceptable use policies, release date and distribution methods, interaction with external hardware or software, software versions, architecture and parameter count, modality and format of inputs and outputs including maximum size, licence, required technical means, and information on the training, testing and validation data used.
You are a provider of a general-purpose AI model placed on the Union market.
Article 53(2) exempts providers of models released under a free and open-source licence whose parameters and related information are publicly available from points (a) and (b) of paragraph 1. That exception does not apply to GPAI models with systemic risk.
Implement rights-reservation detection inside your copyright policy
Record which techniques you use to identify a reservation of rights within the meaning of Article 4(3) of Directive (EU) 2019/790 when collecting training data, how often you recheck, and how you then comply with that reservation.
The open-source exemption in Article 53(2) covers only points (a) and (b) of paragraph 1 and therefore leaves the point (c) copyright policy intact.
Set up how you handle a request for an explanation
Ensure your complaints or objections desk recognises a request for an explanation of an AI-supported decision, that it can be traced per decision which system in which version contributed to it, and that someone is designated to give the explanation.
To be set up before an Annex III system contributes to decisions about natural persons, and to be revisited on every change to that decision process.
Make sure you can answer a complaint with documents
Record per AI system which assessment was carried out, by whom, on what date and against which system version, and agree who receives a question from the authority and within what period.
Perform the Article 24(1) check before making available
Verify the CE marking, the presence of the EU declaration of conformity and the instructions for use, and whether the provider and importer complied with Article 16, points (b) and (c), and Article 23(3).
To be carried out before every making available on the market, including where you supply the system free of charge or as part of a service bundle (Article 3(10)).
Run the four verifications of Article 23(1) before importing
Check and record: the conformity assessment has been carried out, the technical documentation exists, the CE marking plus declaration and instructions for use are present, and an authorised representative has been appointed.
To be carried out before every first placing on the market of a high-risk AI system from a third-country provider.
Assess the value-chain role per system and change
On white-labelling, substantial modification or purpose change, assess whether your organisation becomes the provider, and arrange the representative for non-EU supply.
The Commission office that supervises providers of general-purpose AI models. AI Office enforcement is active since 2 August 2026.
The authorised representative is the party located in the Union that, on the basis of a written mandate, performs and carries out the obligations and procedures of the Regulation on behalf of a provider established outside the EU. The definition in Article 3(5) already applies today, so the role can be determined now. The appointment duty itself starts on 2 December 2027 for the standalone Annex III route and on 2 August 2028 for the embedded Annex I route. From those dates, a third-country provider may not place a high-risk AI system on the Union market without an appointed representative.
Mandatory for providers of high-risk AI systems established in a third country, before they place those systems on the Union market (Article 22(1)). This duty starts on 2 December 2027 for the standalone Annex III route (Article 6(2)) and on 2 August 2028 for the embedded Annex I route (Article 6(1)). The definition and role determination in Article 3(5) already apply today.
Article 22 covers the high-risk AI system route. The definition in Article 3(5) also mentions general-purpose AI models; that route has its own regime, which is not elaborated here.
A deployer of the relevant creditworthiness or life and health insurance systems in Annex III point 5(b) or 5(c).
An organisation using an AI system under its authority, excluding personal non-professional use.
You are a distributor if you make an AI system available on the Union market without being the provider or the importer. This catches resellers, systems integrators and managed service providers that pass on someone else's AI.
Applies where you sit in the supply chain, are neither provider nor importer, and supply the system in the course of a commercial activity. Supply free of charge expressly counts.
If you put your own name or trade mark on a high-risk system already placed on the market, or make a substantial modification, or change its intended purpose, Article 25(1) treats you as a provider. Point (a) applies without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated. The role switch can be determined today; the duties of Article 16 start to apply on 2 December 2027 for the standalone Annex III route and on 2 August 2028 for the embedded Annex I route.
A party that places a general-purpose AI model on the Union market.
You are an importer as soon as you, from within the EU, first place an AI system on the Union market that bears the name or trade mark of a party established outside the EU. What counts is not your purchasing role but whose brand is on the system and who first brings it to market.
Applies where you are located or established in the Union and are the first to place an AI system from a third-country provider on the Union market under that provider's name or trade mark.
You are not an importer but a provider as soon as you put your own name or trade mark on the system, make a substantial modification, or change the intended purpose so that the system becomes high-risk (Article 25(1)(a), (b) and (c)). Point (a) expressly applies without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated. The role switch can be determined today; the twelve duties of Article 16 start to apply on 2 December 2027 for the standalone Annex III route and on 2 August 2028 for the embedded Annex I route.
The national authority that supervises compliance with the Regulation and receives serious incident and risk notifications. Which body fills this role per Member State is not recorded in the graph.
A party that develops or has an AI system developed and places it on the market under its own name.
A deployer that is a body governed by public law.
A private deployer providing public services.
The regulation entered into force on 1 August 2024, after which the obligations followed in phases.
Regulation (EU) 2024/1689 appeared in the Official Journal on 12 July 2024 and entered into force on 1 August 2024. Article 113 sets out that most provisions only become applicable later.
Prohibited practices and AI literacy apply
Since 2 February 2025 the Article 5 prohibition and the Article 4 AI literacy duty apply.
Chapter I and Chapter II became applicable on 2 February 2025. That makes the prohibited practices the first category with enforceable duties.
Article 113, second paragraph, point (a)
General-Purpose AI Code of Practice published
The voluntary code of practice gives GPAI model providers a route to demonstrate compliance.
The Commission published the General-Purpose AI Code of Practice on 10 July 2025. Signing is voluntary; signatories can rely on it to demonstrate compliance with the GPAI obligations.
Code of Practice for General-Purpose AI, 10 July 2025
Guidelines on the scope of the GPAI obligations
The Commission explains when someone becomes the provider of a GPAI model, including through fine-tuning.
Guidelines C(2025) 5045 final of 18 July 2025 describe the scope of the obligations for providers of GPAI models, including when a party modifying a model becomes a provider itself.
Commission Guidelines C(2025) 5045 final, 18.7.2025
Guidelines on the definition of an AI system
The Commission draws the line between software that does and does not fall under the regulation.
Guidelines C(2025) 5053 final of 29 July 2025 explain Article 3(1) through borderline cases, such as classical optimisation, statistical estimation and expert systems.
Commission Guidelines C(2025) 5053 final, 29.7.2025
Worked examples for each Article 5 prohibition, with the line between permitted and prohibited.
Guidelines C(2025) 5052 final of 29 July 2025 work out each Article 5 prohibition with examples. The guidelines are non-binding: authoritative interpretation rests with the Court of Justice.
Commission Guidelines C(2025) 5052 final, 29.7.2025
Since 2 August 2025 the obligations for providers of general-purpose AI models apply.
Chapter V became applicable on 2 August 2025. Models placed on the market before that date must comply by 2 August 2027 at the latest.
Draft guidelines on high-risk classification
The Commission explains in consultation when a system falls under Annex I or Annex III.
On 19 May 2026 the Commission published draft guidelines on the classification of high-risk AI systems for stakeholder consultation, with separate annexes on Annex I and Annex III. The text is non-binding and not yet final.
Draft guidelines of 19 May 2026, annexes on Annex I and Annex III
A voluntary route to comply with parts of Article 50, in two separately signable sections.
The Code of Practice on transparency of AI-generated content appeared on 10 June 2026. After a positive adequacy assessment, signatories can rely on it for Article 50(2), (3) and (5). Section 1 addresses providers, section 2 deployers.
Code of Practice on Transparency of AI-generated Content, 10 June 2026
EN 18286:2026 on the quality management system is the first completed standard under the standardisation request.
CEN-CENELEC approved EN 18286:2026 on 12 July 2026. It is the first JTC 21 deliverable under standardisation request M/613 to reach the publication stage.
EN 18286:2026, CEN/CLC/JTC 21 under standardisation request M/613
The Commission works out the transparency duties and confirms they apply from 2 August 2026.
Guidelines C(2026) 5054 final of 20 July 2026 work out the notification and marking duties of Article 50, with worked examples for chatbots, deep fakes and AI texts of public interest.
Commission Guidelines C(2026) 5054 final, 20.7.2026
Annex III core rules moved to 2 December 2027
The amended application date has been binding law since 27 July 2026.
Regulation (EU) 2026/1744 sets application for Article 6(2) and Annex III on 2 December 2027.
Article 4 amended to a duty to take measures
Since 27 July 2026 the organisational duty supports the development of AI literacy without guaranteeing an individual level.
Regulation (EU) 2026/1744 amended Article 4 with effect from 27 July 2026.
Article 4 amendment and entry into force
FRIA follows new date and may cross-reference a DPIA
The FRIA for the relevant Annex III route follows 2 December 2027 and may include or cross-reference relevant DPIA elements.
The amending regulation links the relevant FRIA route to the new application calendar and expressly enables reuse through a DPIA.
Article 27 amendment and amended Article 113
The transparency duties apply since 2 August 2026.
Article 50 became applicable on 2 August 2026 and was not postponed by the Digital Omnibus.
Since 2 August 2026 the Commission can request GPAI information, conduct evaluations and require measures.
Commission enforcement powers for GPAI and the Article 101 fine regime have been active since 2 August 2026.
Grace period for machine-readable marking ends
Systems placed on the market before 2 August 2026 must comply with Article 50(2) by 2 December 2026.
Article 50 has applied to all systems in scope since 2 August 2026. For the machine-readable marking and detectability of paragraph 2 a transition period runs to 2 December 2026, and only for systems placed on the market before 2 August 2026.
Commission Guidelines C(2026) 5054 final, transitional regime under Article 50(2)
New prohibitions require technical safeguards
The Digital Omnibus prohibits AI for child sexual abuse material and non-consensual intimate imagery.
Regulation (EU) 2026/1744 adds a prohibition on AI intended to generate child sexual abuse material or non-consensual intimate imagery. The required technical safeguards must be in place by 2 December 2026.
Regulation (EU) 2026/1744, amendment of Article 5
Models placed on the market before 2 August 2025 have until 2 August 2027.
Article 111(3) gives providers of GPAI models placed on the market before 2 August 2025 until 2 August 2027 to comply with Chapter V.
High-risk AI embedded in regulated products
AI as a safety component of products under Annex I follows on 2 August 2028.
For AI systems under Article 6(1) and Annex I, that is AI as a safety component of products already covered by EU product legislation, the high-risk requirements apply from 2 August 2028.
Regulation (EU) 2026/1744, amended application dates under Article 113
Reclassification on purpose or context change
Reopen classification when intended purpose, use context or system functionality changes materially.
Procurement gate: no signature without a completed classification answer
Block signature of an AI contract until the supplier has answered in writing which Annex III point the intended purpose falls under, whether it relies on Article 6(3), and whether the system profiles natural persons.
You purchase, renew or extend a contract for an AI system or an AI component.
Repeat the data quality assessment before every retraining or dataset change.
Update the file before every release and retain earlier versions traceably.
Periodically verify that logging works, is complete and is retained according to the regime.
At every deployment and update, verify instructions are present, current and internally translated.
Before go-live, test that intervening, stopping and disregarding output actually works and is assigned.
Monitor whether the system stays within declared levels in production and escalate on deviation.
Release gate before placing on the market
A hard block in your release or delivery process: no delivery without a completed conformity assessment, a signed EU declaration of conformity, an affixed CE marking and a completed registration.
Applies at every first supply to the market and again after a substantial modification within the meaning of Article 3(23), that is, a change after placing on the market or putting into service which was not foreseen in the initial conformity assessment and which affects compliance with Chapter III, Section 2, or results in a modification of the assessed intended purpose. Article 43(4) requires a new conformity assessment procedure in that case.
Periodically audit whether practice follows the described system and record deviations and improvements.
Coverage reconciliation: every person with AI access appears in the register
Periodically reconcile the list of accounts and licences with access to AI systems against the participation and instruction register, and clear the gap list with an owner and a deadline.
There are persons outside the standing payroll dealing with AI systems on your behalf.
Article 4 prescribes no coverage percentage, record format or frequency. The reconciliation is a means of showing that the measures reach the persons referred to in Article 4(1); it is not itself a legal obligation.
Check when systems, roles or risks change whether the selected measures remain appropriate.
Repeat the screening for every new system, procurement and material change of purpose or context; an earlier clearance does not cover a new use.
Quarterly sampling of live disclosures and markings in production
Each quarter, sample the systems carrying an Article 50 scenario and verify in the production environment that the disclosure still appears and the marking is still present in the actual output, recording finding, owner and remediation deadline.
Your AI register contains at least one system to which an Article 50 scenario applies.
Before release, test that the applicable disclosure, marking or label is timely, clear and technically effective.
Monitor cumulative training compute and notify the Commission when the threshold is reached.
Supervision inside the sandbox and the conditional fine shield
The authority retains its supervisory and corrective powers and can suspend your testing or participation. If you stay within the plan and follow the guidance in good faith, authorities impose no administrative fines for infringements of this Regulation.
Applies throughout your participation in an AI regulatory sandbox, from entry to exit or termination.
The fine shield is conditional and lapses as soon as you depart from the specific plan or from the terms and conditions of participation, or fail to follow the guidance in good faith. For other Union or national law it applies only where the authorities responsible for that law were actively involved in supervision inside the sandbox and provided guidance. Article 57(12) refers only to participating providers and prospective providers. If you take part as a deployer in partnership under Article 58(2), point (b), do not assume the protection automatically covers your own obligations.
Oversight during the test, incident reporting and recall procedure
The market surveillance authority may inspect unannounced. On a serious incident you report, take immediate mitigation or suspend, and you must have a procedure in place in advance for prompt recall of the system.
Applies throughout the entire duration of the testing in real world conditions, and on its completion, suspension or termination.
The Regulation provides no exception to the duty to report a serious incident or to the inspection powers. The reporting route itself runs through Article 73, which governs the deadlines and the manner of reporting.
Ensure real-world signals (deviations, complaints, incidents) demonstrably lead to analysis and, where needed, measures.
Periodically test whether an incident can be reported within the legal deadlines, including the deployer-to-provider chain.
Reopen the risk management process on changes in purpose, data, model or use context and before every release.
Reassessment on substantial modification
Rerun the conformity route whenever the system is substantially modified.
Suspension and incident notification control
A fixed rule that suspends use and notifies in the correct order as soon as you have reason to consider the system presents a risk or as soon as you identify a serious incident.
Triggered at the threshold of having reason to consider that use may result in a risk, and separately upon identifying a serious incident. For financial institutions the monitoring obligation is deemed fulfilled through the internal governance rules under Union financial services law.
Distributor corrective action, withdrawal and recall control
A pre-arranged capability to bring an already supplied system into conformity, withdraw it or recall it, and to immediately notify the provider or importer and the competent authorities.
Triggered as soon as, on the basis of the information in your possession, you have reason to consider that the system does not comply with Section 2, including where that information comes from a customer rather than the provider.
Routing and deadline tracking of a request for an explanation
The control that ensures an incoming request reaches an identifiable person within a set period and is answered, instead of sitting in a general inbox.
Currency check on the FRIA elements during use
Periodically and on every change in process, duration of use, affected groups, risks or oversight measures, check whether the recorded elements still hold, and update the information as soon as they do not.
The system is in use and an assessment under Article 27(1) has been performed or relied upon.
Block deployment until applicability, assessment, mitigation and notification have been completed.
Half-yearly review of whether your chosen compliance route still covers you
Establish every six months whether you demonstrate compliance through a code of practice, through a published harmonised standard, or through alternative adequate means, and whether the underlying file matches that choice.
Update documentation and downstream information when the model, capabilities or risks change.
Stop rule and notification route on doubts about conformity
As soon as you have sufficient reason to consider a system non-conforming or falsified, it does not go to market, and where there is a risk you notify the provider, the authorised representative and the market surveillance authorities.
Triggered at the threshold of sufficient reason to consider, meaning on a well-founded signal and not only upon certainty or third-party confirmation.
Repeat the role assessment on every rebranding, modification or new use of an existing system.
The role carrying the heaviest obligations, and the role organisations most often end up in by accident.
Article 3(3) defines a provider as a natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge.
Many organisations believe they are a provider because they use a model. Use alone is not the test: the dividing line is placing on the market or putting into service under your own name or trademark. Someone who modifies or fine-tunes a general-purpose AI model and places the result on the market does, however, become a provider of that modified model; recital 109 then limits the obligations to that modification or fine-tuning. Conversely, organisations wrongly assume they can never be a provider because they sell nothing: having a system developed counts, free of charge counts, and an internally built tool that you put into service under your own name for your own use makes you a provider alongside being a deployer. Article 25(1) also moves a distributor, importer, deployer or third party into the provider role for a high-risk system when it puts its name or trademark on it, makes a substantial modification, or changes the intended purpose so that the system becomes high risk.
Assess the role question per system, not per organisation, and record the answer with its reasoning. Include three fields in the register: under whose name or trademark the system is offered or put into service, who developed it or had it developed, and whether the intended purpose or configuration has changed since deployment. Reassess those fields on every substantial modification.
A conformity assessment body notified in accordance with this regulation and other relevant Union harmonisation legislation. Only notified bodies may carry out the external assessments under the AI Act.
Article 3(22) defines a notified body as a conformity assessment body notified in accordance with this Regulation and other relevant Union harmonisation legislation.
The biggest misconception is that every high-risk system must pass through a notified body. That is wrong: for most Annex III systems, internal control by the provider itself suffices. External involvement mainly arises for biometrics and for products already covered by the Annex I harmonisation legislation, where existing product certification absorbs the AI requirements. Anyone who routinely demands a notified body certificate in a tender is often demanding something that does not exist for that system, and thereby excludes suitable suppliers.
For each high-risk system, determine whether external assessment is legally required before writing that requirement into a contract or tender, and record the analysis. If you do require notified body involvement, note the body's identification number and scope and verify them in the official Union database.
The national authority responsible for setting up and carrying out the procedures for assessing, designating and notifying conformity assessment bodies, and for monitoring them.
Article 3(19) defines notifying authority as the national authority responsible for setting up and carrying out the necessary procedures for the assessment, designation and notification of conformity assessment bodies and for their monitoring.
The notifying authority is not your point of contact and does not supervise you. It approves the assessors. That distinction is often missed in the market: companies approach the notifying authority when they should be dealing with the market surveillance authority. For most organisations the practical significance is indirect but real: as long as Member States have designated few bodies, capacity is limited for the systems that do require external assessment.
Record in your dossier which national bodies are relevant for your sector and what role each has, so that a notification or question does not go to the wrong party. Explicitly distinguish the notifying authority, the market surveillance authority and any notified body used by your supplier.
Not a standalone authority but a function within the European Commission. For general-purpose AI models the AI Office is your supervisor; for ordinary AI systems it is not.
Article 3(47) defines the AI Office as the Commission's function of contributing to the implementation, monitoring and supervision of AI systems and general-purpose AI models, and AI governance, provided for in the Commission Decision of 24 January 2024. References in the Regulation to the AI Office are to be construed as references to the Commission.
The final sentence matters most: in law the AI Office is the Commission. There is no separate agency to appeal to, and the powers are the Commission's powers. In practice, for providers of general-purpose AI models the AI Office is the enforcer. The Article 53 obligations have applied since 2 August 2025 and have been enforceable since 2 August 2026. For ordinary AI systems your contact is not the AI Office but the national market surveillance authority. Organisations routinely send questions to the wrong desk and lose time doing so.
Set out in your escalation and contact map who approaches whom: questions and notifications about general-purpose AI models go to the AI Office, questions about AI systems go to the national market surveillance authority. Assign one internal owner per route.
Skills, knowledge and understanding that enable providers, deployers and affected persons to deploy AI systems in an informed way and to become aware of the opportunities, risks and possible harm of AI.
Article 3(56) defines AI literacy as skills, knowledge and understanding that allow providers, deployers and affected persons, taking into account their respective rights and obligations under this Regulation, to make an informed deployment of AI systems and to gain awareness of the opportunities and risks of AI and the possible harm it can cause.
The definition is role-bound: literacy must match the rights and obligations of the person concerned, so it means something different for a recruiter than for a developer or a compliance lead. That is where practice goes wrong. Organisations buy one generic e-learning for everyone and consider themselves done, whereas the definition asks for understanding that matches what a person actually does with AI. Article 4 has applied since 2 February 2025 and, following the Digital Omnibus, Regulation (EU) 2026/1744 which entered into force on 27 July 2026, has become an obligation to take measures without a guaranteed individual level. That lowers the bar for the outcome, not for the evidence: you must still show which measures you took and why they are appropriate.
Record which roles in your organisation work with AI, what level of knowledge and understanding each role requires, which measure you put in place for it and when. Retain participation and dates per person, and repeat the measure when someone changes role or a new AI system is taken into use, so you can show at any moment who is demonstrably prepared.
The model is not the system, and that distinction determines which chapter of obligations applies to you.
AI models used for research, development or prototyping activities before they are placed on the market fall outside the definition.
Article 3(63) defines a general-purpose AI model as an AI model, including where such a model is trained with a large amount of data using self-supervision at scale, that displays significant generality and is capable of competently performing a wide range of distinct tasks regardless of the way the model is placed on the market and that can be integrated into a variety of downstream systems or applications, except AI models used for research, development or prototyping activities before they are placed on the market. Point 66 separately defines a general-purpose AI system as an AI system which is based on a general-purpose AI model and which has the capability to serve a variety of purposes, both for direct use as well as for integration in other AI systems.
Model and system are used interchangeably in practice, and that is the heart of the confusion. Point 63 concerns the model, point 66 the system built on top of it. Obligations for GPAI models rest on the model provider; an organisation embedding that model in its own application is in principle dealing with the regime for AI systems. Two further things are missed. The definition expressly excludes models used for research, development or prototyping before they are placed on the market, so the exception lapses at the moment of placing on the market. And the phrase regardless of the way the model is placed on the market means that openly released models can fall within the definition too. On timing: Article 53 has applied since 2 August 2025, the enforcement powers of the Commission and the AI Office and the fines of Article 101 have been active since 2 August 2026, and for models placed on the market before 2 August 2025 the period runs until 2 August 2027.
Distinguish the model layer and the system layer explicitly in your register, and record per application which underlying model is used, from which provider, and whether your organisation itself places that model on the market. When developing your own models, record the moment the research or prototyping stage ends, because that is where the regime begins.
The gateway definition of the Regulation's system track: if your application falls outside it, the obligations for AI systems do not apply. General-purpose AI models run on a separate track under Article 3(63), with their own obligations in Article 53.
Article 3(1) defines an AI system as a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments.
Two mirror-image errors. First, treating only generative AI and language models as AI systems, which leaves classic scoring models, matching algorithms and predictive models out of the register even though they clearly infer how to generate outputs. Second, calling every piece of software AI, which makes the register useless. The hinge is the word infers: a system that merely executes a rule written by a human infers nothing. Note also the word may in may exhibit adaptiveness: adaptiveness after deployment is a possibility, not a condition. A model frozen after training is still an AI system.
For every application, record three answers in your AI register with a date and the name of the assessor: does it operate with some degree of autonomy, does it infer from input how to generate output, and what is that output. When the outcome is negative, keep the reasoning, because that is the document with which you later explain why the system is out of scope.
A controlled framework set up by a competent authority in which you may temporarily develop, train, validate and test an innovative AI system under regulatory supervision, following a sandbox plan.
Article 3(55) defines an AI regulatory sandbox as a controlled framework set up by a competent authority which offers providers or prospective providers of AI systems the possibility to develop, train, validate and test, where appropriate in real-world conditions, an innovative AI system, pursuant to a sandbox plan for a limited time under regulatory supervision.
The biggest misconception is that a sandbox grants an exemption from the Regulation. It does not. The framework is controlled and time-limited and operates under regulatory supervision; it does not suspend obligations. The definition also expressly names prospective providers, so parties that have not yet placed anything on the market can take part. Anyone using the term as marketing language without admission by a competent authority is using it incorrectly.
Record whether your participation has been formally admitted by a competent authority, which period applies, which sandbox plan governs it and which obligations continue to apply during participation. Include the sandbox outcomes in your technical documentation.
The use set by the provider on which the entire risk classification and assessment rest.
Article 3(12) defines intended purpose as the use for which an AI system is intended by the provider, including the specific context and conditions of use, as specified in the information supplied by the provider in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation.
Two things are structurally missed. First, the intended purpose is set by the provider, not by what you as a deployer do with the system. Second, and this hits providers hard: the intended purpose is derived not only from the manual but also from promotional and sales materials and from statements. A marketing claim that the system is also suitable for recruitment or for creditworthiness assessment therefore widens the intended purpose and can shift the risk classification. For deployers the mirror-image warning applies: use outside the intended purpose is not free. It can amount to reasonably foreseeable misuse, and under Article 25(1)(c) it can amount to a change of intended purpose that makes you the provider yourself, but only where the system thereby becomes a high-risk AI system in accordance with Article 6.
Have marketing and product management align claims about application areas explicitly with the instructions for use and the technical documentation, and record that those three sources carry the same scope. As a deployer, record per system the intended purpose as described by the supplier alongside your actual use, and flag every difference as a decision point.
The sensitive data categories from the GDPR and related European rules, imported here because the AI Act attaches both a prohibition and a narrow exception to them.
Article 3(37) defines special categories of personal data as the categories of personal data referred to in Article 9(1) of Regulation (EU) 2016/679, Article 10 of Directive (EU) 2016/680 and Article 10(1) of Regulation (EU) 2018/1725.
The definition cross-refers, but the AI Act gives it two independent consequences. First, it touches Article 5, enforceable since 2 February 2025: biometric categorisation that infers individually sensitive attributes such as race, political opinions, trade union membership, religion, sex life or sexual orientation is prohibited. Second, Article 10(5) contains an exception permitting processing of special category data where strictly necessary to detect and correct bias in high-risk systems. That exception is consistently read too broadly. It applies only to high-risk systems, only where other means demonstrably do not suffice, with technical limits on reuse and transmission, and with deletion once the bias has been addressed. It is not a general basis for starting to collect sensitive attributes because you want to run fairness measurements.
Record whether you rely on Article 10(5), for which high-risk system, why synthetic or anonymised data do not suffice, which technical and organisational safeguards apply, who has access, and at what point the data are deleted. Align this with your data protection officer and cross-reference from your AI dossier to the corresponding data protection impact assessment.
The AI Act uses its own, broader wording than the GDPR, and that difference decides whether you land in Annex III or Article 5.
Article 3(34) defines biometric data as personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, such as facial images or dactyloscopic data.
Almost everyone reads the GDPR definition into this one. That goes wrong on a point that is legally decisive: Article 4(14) GDPR requires that the processing allows or confirms unique identification, and that requirement does not appear in point 34 of the AI Act. Data on behavioural characteristics such as keystroke rhythm, gait or voice features can therefore be biometric data under the AI Act even where identification is not the aim. Anyone basing their AI inventory on the GDPR qualification risks missing systems falling under Article 5 or Annex III. For the GDPR side of the same processing, that Regulation continues to apply in full.
Assess biometrics in your AI register separately from the GDPR assessment and record both outcomes side by side. Include systems that process behavioural characteristics without an identification purpose, such as fraud detection on typing behaviour or voice analysis in the customer contact chain.
A one-to-many comparison against a database, to be distinguished from the one-to-one verification of point 36.
Article 3(35) defines biometric identification as the automated recognition of physical, physiological, behavioural, or psychological human features for the purpose of establishing the identity of a natural person by comparing biometric data of that individual to biometric data of individuals stored in a database. Point 36 separately defines biometric verification as the automated, one-to-one verification, including authentication, of the identity of natural persons by comparing their biometric data to previously provided biometric data.
Identification and verification are used interchangeably in conversations with suppliers, while the difference determines the regime. Identification is one-to-many: the system searches for who someone is by comparing against a database holding data on individuals. Verification is one-to-one: the system confirms whether someone is who they claim to be. Access control with a face scan against the employee's own badge record is verification; a camera running faces past a watchlist is identification. A detail that is rarely noticed: point 35 also mentions psychological features, while the definition of biometric data in point 34 does not.
Record in writing for each biometric application whether the comparison is one-to-one or one-to-many, which database is compared against and who controls that database. Ask for this as a hard requirement during procurement, because vendor material rarely speaks in these terms and the answer determines whether you end up in Article 5 or in Annex III.
Post-remote biometric identification system
The residual category: any remote identification that is not real-time. Not prohibited, but high-risk, and subject to its own authorisation regime in law enforcement.
Article 3(43) defines this as a remote biometric identification system other than a real-time remote biometric identification system.
A residual category is not a free zone. Searching recorded footage for individuals after the fact does not fall under the Article 5 prohibition, but it is high-risk under Annex III, point 1(a) from 2 December 2027. For law enforcement, Article 26(10) applies as well: use requires, in principle, prior authorisation, or authorisation requested without undue delay, from a judicial or independent administrative authority, tied to a specific criminal offence. Organisations that offer "we only look back afterwards" as reassurance are confusing the absence of a prohibition with the absence of obligations.
For each search, record who authorised it, which offence or legal basis it rests on, which period and which footage were searched, and what the outcome was.
Real-time remote biometric identification system
Remote identification where capture, comparison and identification happen without significant delay. The legislator explicitly closed the escape route of an artificial delay.
Article 3(42) defines this as a remote biometric identification system whereby the capturing of biometric data, the comparison and the identification all occur without a significant delay, comprising not only instant identification but also limited short delays, in order to avoid circumvention.
The reference to limited short delays is deliberate. It shuts down the design in which a buffer of seconds or minutes is added so the operator can claim the system is not real-time. The distinction matters enormously: the use of real-time remote identification in publicly accessible spaces for law enforcement has been prohibited in principle since 2 February 2025 under Article 5(1)(h), with narrow exceptions requiring prior authorisation and a national legal basis.
Document the processing architecture and the measured latency of the system, including test results. A statement that you "buffer" is not a defence if identification becomes actionable within seconds or minutes in practice.
The marking by which a provider indicates that an AI system conforms to the requirements of Chapter III, Section 2 and to other applicable Union harmonisation legislation providing for its affixing.
Article 3(24) defines CE marking as a marking by which a provider indicates that an AI system is in conformity with the requirements set out in Chapter III, Section 2 and other applicable Union harmonisation legislation providing for its affixing.
The CE marking is a declaration by the provider itself, not a regulator's seal and not a quality label. It belongs solely to high-risk AI systems, so a supplier presenting CE marking as a selling point for an ordinary chatbot is telling you the wrong story. Conversely, the absence of CE marking is not a shortcoming for a system that is not high-risk. For high-risk systems this becomes relevant from 2 December 2027 for Annex III and 2 August 2028 for Annex I.
For every high-risk AI system, request the EU declaration of conformity that must sit behind the CE marking and keep it in your dossier, together with the system version it relates to. Do not accept a reference to CE marking without the underlying declaration as evidence.
The process of demonstrating that a high-risk AI system meets the requirements of Chapter III, Section 2. It is the evidence step for high-risk systems, not for all AI.
Article 3(20) defines conformity assessment as the process of demonstrating whether the requirements set out in Chapter III, Section 2 relating to a high-risk AI system have been fulfilled.
Two misconceptions dominate. The first is that every AI application needs a conformity assessment: the definition expressly limits it to high-risk systems. The second is that conformity assessment equals an external audit: for most Annex III systems the internal control route of Article 43 suffices, with the provider itself demonstrating that the requirements are met. If you conclude you are not high-risk, substantiate that conclusion in writing rather than assuming it silently. The obligations apply to Annex III systems from 2 December 2027 and to Annex I products from 2 August 2028.
Record your risk classification in writing for each AI system, including the reasoning, even where the outcome is that it is not high-risk. Where it is high-risk, also record which route you follow, internal control or involvement of a notified body, and which evidence per requirement of Chapter III, Section 2 sits in the technical documentation.
A body that performs third-party conformity assessment activities, including testing, certification and inspection.
Article 3(21) defines a conformity assessment body as a body that performs third-party conformity assessment activities, including testing, certification and inspection.
The key phrase is third party. An internal audit function, a consultancy or your own quality team is not a conformity assessment body, however thorough the work. Note also the difference from a notified body in point 22: every notified body is a conformity assessment body, but not the reverse. Only after notification may a body carry out the statutory assessments under this regulation. Certificates from bodies that are not notified have commercial value but no legal status under the AI Act.
Before purchasing an external assessment, verify that the body is in fact notified for the relevant scope and record the evidence in your dossier. For every external report, note the role the party had, adviser or notified body, so it never later appears that an advisory report was a statutory assessment.
Far broader than fake videos of famous people: objects, places, entities and events are covered too.
Article 3(60) defines a deep fake as AI-generated or manipulated image, audio or video content that resembles existing persons, objects, places, entities or events and would falsely appear to a person to be authentic or truthful.
The name pushes the reading in the wrong direction. Under this Regulation a deep fake is not limited to fake footage of famous people: the definition expressly also names objects, places, entities and events. An AI-generated photo of an existing building, a demonstration that never happened, or a product image that reads as a real photograph can therefore be a deep fake. Two boundaries matter. The definition names image, audio and video; pure text is not covered, although Article 50 has its own rule for certain publications. And content resembling a non-existent person falls outside point 60, while it may still fall under the marking duty for synthetic output. Article 50 has applied since 2 August 2026; the only transition concerns the machine-readable marking of Article 50(2) for systems already on the market before 2 August 2026, running until 2 December 2026.
Map which departments publish AI-generated image, audio or video content, including marketing, communications, training and customer contact, and record per channel how the artificial origin is disclosed. Include generated images of existing locations and products, because those are precisely the ones rarely recognised as deep fakes.
Any link in the supply chain that makes an AI system available on the Union market and is neither provider nor importer.
Applies only to a party in the supply chain that is neither the provider nor the importer.
Article 3(7) defines a distributor as a natural or legal person in the supply chain, other than the provider or the importer, that makes an AI system available on the Union market.
Resellers, systems integrators, marketplaces and staffing firms that ship software along with their service often assume they fall outside the Regulation because they build nothing. The definition is a residual category: if you are neither provider nor importer in the chain, and you make the system available on the Union market, you are a distributor. Note point 10: making available on the market means supply in the course of a commercial activity, whether for payment or free of charge. Passing something on free or offering a trial version is covered too. Put your own name or trademark on it and the role shifts to provider.
Map which AI systems your organisation passes on to third parties, including free of charge and as a by-product of a service, and record per system whose name or trademark it carries. Set out in your resale contracts who holds which role, so that it is not disputed later who the provider was.
A provider of an AI system, including a general-purpose AI system, which integrates an AI model, regardless of whether that model is provided by themselves and vertically integrated or obtained from another entity on a contractual basis.
Article 3(68) defines a downstream provider as a provider of an AI system, including a general-purpose AI system, which integrates an AI model, regardless of whether the AI model is provided by themselves and vertically integrated or provided by another entity based on contractual relations.
This is the definition organisations most often get wrong about their own role. Anyone integrating a third party model into their own product or service and offering it under their own name is a downstream provider and therefore a provider, not merely a deployer. The words regardless of whether make clear that it does not matter whether you built the model yourself. Your position determines what information you must be able to obtain from the model provider: providers of general-purpose AI models must under Article 53 make documentation available to downstream providers, an obligation applying since 2 August 2025 and enforceable since 2 August 2026.
For each AI system, record which underlying model is integrated, from which party, and whether that makes you a downstream provider. Include in the contract with the model provider which Article 53 documentation you receive, and keep that documentation in your own file.
Prohibited in the workplace and in education since 2 February 2025; elsewhere an information duty under Article 50 applies since 2 August 2026.
The Article 5(1)(f) prohibition does not apply where the use of the AI system is intended to be put in place or into the market for medical or safety reasons.
Article 3(39) defines an emotion recognition system as an AI system for the purpose of identifying or inferring emotions or intentions of natural persons on the basis of their biometric data. Article 5(1)(f) prohibits placing on the market, putting into service for this specific purpose, or using AI systems to infer emotions of a natural person in the areas of workplace and education institutions, except where the use of the AI system is intended to be put in place or into the market for medical or safety reasons.
Two scoping errors. First, assuming that every form of sentiment analysis is covered. The definition requires the inference to be made on the basis of biometric data. Sentiment analysis on written text, without biometrics, falls outside point 39 even though it feels comparable. Second, thinking only of facial expressions, while voice analysis in a call centre and posture analysis from camera footage are equally covered. Note also the word intentions alongside emotions: systems predicting purchase readiness or aggression from biometrics fall within the definition. Outside the workplace and education, emotion recognition is not prohibited, but it is listed in Annex III, point 1(c) and therefore counts as a high-risk AI system there once Article 6(2) becomes applicable on 2 December 2027. In addition, since 2 August 2026 the deployer carries the Article 50(3) duty to inform the exposed persons, except for systems permitted by law to detect, prevent, investigate or prosecute criminal offences.
Map where voice, facial or posture analysis runs in your organisation, including as part of a larger package such as quality monitoring in customer contact, access control or proctoring. Assess per application whether biometric data forms the basis and whether the context is workplace or education; record that assessment, because this is the category carrying a fine of up to EUR 35 million or 7 percent of worldwide turnover.
Four categories of consequence, one of which is an infringement of fundamental rights protection. No physical harm is needed before a notification duty arises.
Article 3(49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to: (a) the death of a person or serious harm to a person's health, (b) a serious and irreversible disruption of the management or operation of critical infrastructure, (c) the infringement of obligations under Union law intended to protect fundamental rights, or (d) serious harm to property or the environment.
Point (c) is the provision organisations miss most often. An infringement of Union law protecting fundamental rights counts as a serious incident, even with no one physically injured. Systematic discrimination in a candidate screening system, in credit scoring or in the allocation of benefits can therefore be notifiable. "Indirectly" counts too: what matters is not only the direct output but the consequence further down the process. Providers of high-risk systems report to the market surveillance authority under Article 73, on short deadlines: in principle within 15 days of becoming aware, 2 days for a widespread infringement or serious disruption of critical infrastructure and 10 days in the event of death. That duty bites from the high-risk dates, Annex III on 2 December 2027 and Annex I on 2 August 2028, but incident logging should start now.
Set up an incident register now that captures the four categories of point 49 separately, with a timestamp at the moment of awareness. Run one drill to confirm you can file a complete notification within two days; that is the tightest deadline and an ad hoc process will not meet it.
The information the provider supplies to inform the deployer about, in particular, the intended purpose and proper use of an AI system. It is the hinge between the provider's obligations and the deployer's.
Article 3(15) defines instructions for use as the information provided by the provider to inform the deployer of, in particular, an AI system's intended purpose and proper use.
In practice this goes wrong in two directions. Providers deliver marketing material or a technical manual instead of instructions that state the intended purpose and the limits of correct use. And deployers file those instructions without reading them, even though Article 26 requires them to use the system in accordance with them. A deployer operating outside the instructions for use can be treated as a provider under Article 25 and thereby take on the full set of provider obligations.
Keep the current instructions for use for each AI system in your dossier, with version number and date of receipt. Also record who in your organisation has read them, which uses you derive as permitted, and which uses you have explicitly prohibited in your own internal work instruction.
The role that virtually every organisation buying and using AI ends up in.
Use in the course of a personal non-professional activity falls outside the definition.
Article 3(4) defines a deployer as a natural or legal person, public authority, agency or other body using an AI system under its authority, except where the AI system is used in the course of a personal non-professional activity.
The role is routinely reduced to user, and that is where it goes wrong. The individual employee operating the tool is not the deployer; the legal entity using the system under its authority is. The second trap is the exception: it covers only personal non-professional use. An employee who takes up an AI tool on their own initiative for work does not fall under that exception, and the organisation remains the deployer even without a procurement contract. Shadow AI is therefore not a grey area but simply an unregistered system.
Record per system which legal entity uses it under its authority, including tools a department procured itself or switched on within an existing licence. Add a periodic inventory of AI features that vendors have activated inside existing software, because those rarely arrive through procurement.
A European standard published in the Official Journal which, if you apply it, produces a presumption of conformity. This is the fastest route to demonstrability, but the AI Act standards are not finished yet.
Article 3(27) defines a harmonised standard as a harmonised standard as defined in Article 2(1), point (c), of Regulation (EU) No 1025/2012.
Textually this is a cross-reference, but the practical weight sits in Article 40: if you apply a harmonised standard whose reference has been published in the Official Journal, you are presumed to comply with the corresponding requirement. That removes a great deal of evidentiary burden. The problem as of the reference date is that the standardisation work at CEN and CENELEC is not yet fully completed and published, so organisations cannot currently lean on a ready-made presumption of conformity. Waiting for the standards is not viable, because the Annex III obligations arrive on 2 December 2027 and the Annex I ones on 2 August 2028. You therefore have to build demonstrability yourself and align later.
Maintain a register recording, per requirement from Chapter III, which standard, framework or internal control you rely on and why that choice covers the requirement. Structure that register so you can replace a row once the harmonised standard is published, without having to rewrite your entire dossier.
A subject's freely given, specific, unambiguous and voluntary expression of willingness to take part in a particular real-world test, after having been informed of all aspects relevant to that decision.
Article 3(59) defines informed consent as a subject's freely given, specific, unambiguous and voluntary expression of his or her willingness to participate in a particular testing in real-world conditions, after having been informed of all aspects of the testing that are relevant to the subject's decision to participate.
Note the word particular: consent applies to one specific test, not to your testing programme as a whole and not to a next version of the system. A general clause in terms of use or an employment contract does not meet this. It is also a concept of its own under the AI Act and not the same as consent as a legal basis under the GDPR, so you cannot cover both with a single form. If the design of the test changes materially, you need fresh consent.
Use a separate consent form for each test containing the information relevant to the decision, and record when and how consent was given and how it can be withdrawn. Document separately that consent was voluntary, particularly for employees.
The European point of contact for a provider from outside the Union, valid only on the basis of a written mandate.
The authorised representative is located or established in the Union and has received and accepted a written mandate.
Article 3(5) defines an authorised representative as a natural or legal person located or established in the Union who has received and accepted a written mandate from a provider of an AI system or a general-purpose AI model to, respectively, perform and carry out on its behalf the obligations and procedures established by this Regulation.
The common error is that a European sales partner, reseller or subsidiary assumes it is automatically the authorised representative. That does not follow from the commercial relationship. The definition sets two cumulative requirements: the mandate is written, and it is not only given but also accepted. Without that document there is no authorised representative and the supervisory authority in the Union has no formal point of contact for that provider. A second misconception is that appointing an authorised representative transfers the provider role. It does not: the representative acts on behalf of the provider, and the provider remains the provider.
Ask every supplier from outside the Union for the name, registered address and contact details of the authorised representative and for a copy or confirmation of the accepted written mandate. Store it with the system file, because it is the first thing you need once a supervisory authority requests information about a system you source from outside the Union.
Technical specifications the Commission can adopt itself when harmonised standards are missing or fall short. The fallback that prevents the AI Act from stalling because standardisation is delayed.
Article 3(28) defines a common specification as a set of technical specifications as defined in Article 2, point (4), of Regulation (EU) No 1025/2012, providing means to comply with certain requirements established under this Regulation.
This definition exists because the legislator anticipated that standardisation would not be ready in time. Article 41 allows the Commission to adopt common specifications through implementing acts, with the same effect: applying them creates a presumption of conformity. The misunderstanding is that a common specification would be optional in practice. It is not: anyone deviating must show that their own technical solution is at least equivalent to the intended level of protection, and that reasoning must sit in the technical documentation. Deviating is allowed, but it costs more documentation than following.
Track the Commission's implementing acts and record which common specifications apply to your system. If you choose your own solution, explicitly document which element you do not follow, which alternative measure you take, and on the basis of which analysis you conclude the level of protection is equivalent.
Operational data around detection and prosecution whose disclosure could harm criminal proceedings. The concept on which the law enforcement exceptions to transparency rest.
Article 3(38) defines sensitive operational data as operational data related to activities of prevention, detection, investigation or prosecution of criminal offences, the disclosure of which could jeopardise the integrity of criminal proceedings.
This is the key with which the AI Act softens transparency obligations for law enforcement without removing them. Registration of high-risk systems used by law enforcement authorities takes place in a secure, non-public section of the EU database, and certain information need not be made public where it concerns sensitive operational data. Where it goes wrong: the concept is sometimes stretched to cover anything a public body would rather not share. That does not hold, because the definition is doubly bounded, namely by the criminal law context and by a concrete risk to the integrity of criminal proceedings. Outside that context it is no basis for withholding documentation; commercially confidential information follows a separate route. Equally important: it limits publication, not the access of the competent market surveillance authority.
Record per system which parts of your registration and documentation you designate as sensitive operational data, on what concrete ground disclosure could harm the integrity of criminal proceedings, who makes that assessment and when it is reviewed. Keep a non-sensitive summary available, so you can still account for the system without touching ongoing proceedings.
Whoever places on the Union market a system bearing the name or trademark of a party established in a third country.
Article 3(6) defines an importer as a natural or legal person located or established in the Union that places on the market an AI system that bears the name or trademark of a natural or legal person established in a third country.
The practical trap is the assumption that importer has to do with customs or with the invoice flow. The test is different: do you place on the Union market for the first time a system bearing the name or trademark of a party from a third country. Someone who only takes a US service for their own use is not an importer but a deployer. Someone who passes on that same system under their own name or trademark is not an importer but a provider. The importer role sits exactly in between: passing it on with the third party's mark still on it.
Record three data points per AI system in your supplier register: the country of establishment of the party whose name or trademark the system bears, whether your organisation is the first to make the system available on the Union market, and under which name that happens. Those three fields together determine whether you are an importer, a distributor or a provider.
The first moment a system or model is made available on the Union market, and therefore the trigger for many obligations.
Article 3(9) defines placing on the market as the first making available of an AI system or a general-purpose AI model on the Union market. Point 10 adds that making available on the market means the supply of an AI system or a general-purpose AI model for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge.
The most persistent error is assuming that a sale or a price must be involved. Point 10 explicitly says whether in return for payment or free of charge. A free trial, an openly available model or a no-cost pilot at a customer can amount to placing on the market. The second error is confusing this concept with putting into service. Placing on the market concerns the market; a system you build and use purely internally is not placed on the market, but it is put into service, and that is an independent trigger in its own right.
Record for each system and model the date of first making available in the Union, together with its form: sale, free trial, open release or pilot. That date determines which regime and which transitional period apply, and it is the first thing a supervisory authority will put next to your file.
The concept that brings internally built systems which are never sold within the scope of the Regulation.
Article 3(11) defines putting into service as the supply of an AI system for first use directly to the deployer or for own use in the Union for its intended purpose.
This is the trap for organisations that build their own systems. The reasoning runs: we sell nothing, so we place nothing on the market, so provider obligations do not apply. The words or for own use close off that route. As soon as you start using a self-built system in the Union for its intended purpose, you have put it into service, and under point 3 you are a provider as well as a deployer. Note also for first use: a system still running in a test environment and not used for its intended purpose has not yet been put into service.
Register for every internally developed AI system the date on which it went into production for its intended purpose, and note explicitly that your organisation is both provider and deployer. Tie the start of your file-building to that date, and assess immediately whether the system is high risk, because the technical documentation of Article 11 and the logging of Article 12 then apply from that moment and the file need not be reconstructed after the fact.
The data entering the system or acquired by it, on the basis of which it produces its output. This is the data definition that touches the deployer, not just the provider.
Article 3(33) defines input data as data provided to or directly acquired by an AI system on the basis of which the system produces an output.
This is where responsibility moves to your side of the table. Article 26(4) requires the deployer to ensure that input data are relevant and sufficiently representative in view of the intended purpose, to the extent it exercises control over them. The most persistent misconception is that data quality is the supplier's problem. Prompts, uploaded CVs, sensor readings, customer files and connected source systems are all input data, and an excellently built system produces unusable outcomes when you feed it outdated or skewed data. Note the second half of the definition as well: data the system acquires itself, for instance through a camera or an API, are equally input data and therefore fall within your duty of care.
Record per AI system which input data are used, which source systems they come from, who owns their quality and representativeness, how often that is checked, and how long the input is retained in the logs. Explicitly name the input sources you do not control, since that marks the boundary of your duty of care.
Critical infrastructure as defined in Article 2, point (4), of Directive (EU) 2022/2557, the CER Directive. The AI Act gives no definition of its own here but aligns with that framework.
Article 3(62) provides that critical infrastructure means critical infrastructure as defined in Article 2, point (4), of Directive (EU) 2022/2557.
This cross-reference looks like a formality but has direct consequences for the risk class. Annex III, point 2, classifies AI systems as high risk where they are intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity. Anyone wanting to know whether they fall within that scope must consult the CER Directive and the national designation of critical entities rather than invent a definition of their own. Organisations get this wrong because designation differs per Member State.
Record whether your organisation or your customer has been designated as a critical entity under the national transposition of Directive (EU) 2022/2557, and link that determination to your risk classification under Annex III, point 2, with date and source.
The national supervisor that enforces the AI Act on the market, with the powers from the general market surveillance regulation. This is the party that comes knocking and requests your documentation.
Article 3(26) defines the market surveillance authority as the national authority carrying out the activities and taking the measures pursuant to Regulation (EU) 2019/1020.
The confusion lies in distinguishing it from two other players. The notifying authority designates notified bodies and does no enforcement towards you; the Commission's AI Office supervises general-purpose AI models under Article 53, which has applied since 2 August 2025 and has been enforceable since 2 August 2026. The market surveillance authority is your actual enforcement contact point for AI systems: it can request technical documentation and logs, demand access to training and testing data sets, and restrict, withdraw or recall a system. The reference to Regulation (EU) 2019/1020 is not a formality, because through it the supervisor inherits a substantial toolkit of powers that did not need restating in the AI Act.
Record per AI system which market surveillance authority is competent (this differs per sector and per Member State where you offer it), who inside your organisation is the point of contact, and within how many working days you can supply the technical documentation, the logs and the data set descriptions. Rehearse that delivery once, because the deadline the supervisor sets is short.
An umbrella term for two very different roles: the notifying authority and the market surveillance authority. For EU institutions the European Data Protection Supervisor takes their place.
Article 3(48) defines a national competent authority as a notifying authority or a market surveillance authority. As regards AI systems put into service or used by Union institutions, agencies, offices and bodies, references to national competent authorities or market surveillance authorities are to be construed as references to the European Data Protection Supervisor.
The definition bundles two roles that should not be confused. The notifying authority designates and supervises conformity assessment bodies; as a deploying organisation you will rarely deal with it. The market surveillance authority supervises you, requests documentation, receives serious incident reports and imposes measures. Member States were required to designate and publish these authorities by 2 August 2025. The fact that designation is not fully settled in some Member States changes nothing about your obligations: the duties rest on you, not on the supervisor.
For every market in which you operate, track which market surveillance authority is competent for your sector, who inside your organisation handles contact and who is authorised to file notifications. State that contact point in your technical documentation.
Everything that is not personal data. The category exists to make clear that the AI Act applies even when no personal data is involved.
Article 3(51) defines non-personal data as data other than personal data as defined in Article 4, point (1), of Regulation (EU) 2016/679.
This residual category is the proof that the AI Act is not a privacy law. The data and data governance requirements in Article 10, the technical documentation in Article 11 and the logging in Article 12 apply equally where you work only with machine data, sensor data or synthetic data. "There is no personal data in it" is at most a GDPR argument and never an AI Act exemption. In practice, technical teams use this argument to avoid documentation duties in industrial and infrastructure applications, which are exactly the applications that can fall under Annex I and Annex III.
Record for each dataset whether it contains personal data, but never let that answer determine whether you produce the AI Act documentation. Assess documentation duties on the system's risk classification, not on the nature of the data.
Any physical place, publicly or privately owned, accessible to an undetermined number of people. Access conditions and capacity limits are irrelevant.
Article 3(44) defines a publicly accessible space as any publicly or privately owned physical place accessible to an undetermined number of natural persons, regardless of whether certain conditions for access may apply and regardless of potential capacity restrictions.
The familiar argument "it is our own premises, so not a public space" does not hold. Shops, stations, airports, stadiums, cinemas, hospital waiting rooms and shopping centres are publicly accessible spaces, even where ticketing, house rules or a capacity cap apply. What matters is whether the circle of visitors is undetermined. An office floor open only to your own staff normally falls outside, because that circle is determined. This concept switches the Article 5 prohibition on real-time remote identification on or off, and feeds through into Annex III classification.
In your camera and biometrics register, mark for each location whether it is a publicly accessible space within the meaning of point 44, with a short justification. Do this before you procure a system, not after.
The umbrella term for all six roles in the chain, and not the person operating the controls.
Article 3(8) defines an operator as a provider, product manufacturer, deployer, authorised representative, importer or distributor.
Operator is read as the person who operates the system day to day. That is precisely what it does not mean. It is an umbrella term: where a provision addresses operators, it addresses all six listed roles at once. Anyone who skips operator obligations in a gap analysis because they believe they are only a deployer misses provisions that do apply to them. Note also that product manufacturer appears in this list as a role but is not separately defined in Article 3.
Add an operator column to your compliance overview that spells out the six roles explicitly, so that for each provision it is visible which roles are affected. Record per AI system every role your organisation holds for that specific system, because there is usually more than one.
The AI Act deliberately creates no separate concept here and refers to the GDPR. Your GDPR records and your AI Act file must therefore cover the same data.
Article 3(50) defines personal data as personal data as defined in Article 4, point (1), of Regulation (EU) 2016/679.
The cross-reference looks dull but has a practical effect: there is no room for a separate AI Act reading of what constitutes personal data. Where the AI Act does open space, such as Article 10(5) permitting processing of special categories to detect and correct bias in high-risk systems, GDPR safeguards apply in full and additional conditions attach. Organisations that keep AI governance and privacy in separate files end up with conflicting descriptions of the same processing, precisely when a supervisor asks for both.
Link every AI system in your AI register to the corresponding processing activity in your GDPR record, using one shared identifier, so that a single change updates both files.
The document in which you set out in advance how you will test an AI system outside the lab: objective, methodology, scope, who takes part, for how long and how you monitor it. Without this plan, testing in real-world conditions is not permitted.
Article 3(53) defines a real-world testing plan as a document that describes the objectives, methodology, geographical, population and temporal scope, monitoring, organisation and conduct of testing in real-world conditions.
In practice this goes wrong because organisations keep calling a pilot with real users a pilot and assume nothing applies. As soon as you trial an AI system with real people in a real environment, you fall under the regime of Article 57 or 60, and that requires a plan drawn up in advance that can be reviewed. A test plan written after the fact to fill a file does not meet the definition, because the essence of the concept is that the design is fixed beforehand.
For every real-world test, record a single document containing the eight elements from the definition: objective, methodology, geographical scope, the population involved, duration, monitoring, organisation and conduct. Link that document to the registration of the test and retain it with the date of approval.
The ability of an AI system to achieve its intended purpose. Performance is therefore measured against the intended purpose, not against a standalone technical score.
Article 3(18) defines performance of an AI system as the ability of an AI system to achieve its intended purpose.
The definition ties performance firmly to the intended purpose in point 12. An accuracy of 94 percent is therefore no answer to whether the system performs, as long as it is not established what it is meant for and for which group of people that score holds. A model that scores well on average but performs structurally worse for a subgroup does not achieve the intended purpose for that group. That is exactly what Article 15 on accuracy and robustness and Article 10 on data quality target.
For each AI system, record which performance metrics you use, which threshold is acceptable for the intended purpose, and how those metrics break down per relevant subgroup. Repeat the measurement periodically and retain the results, so you can demonstrate performance drift before a supervisory authority asks.
For the purpose of real-world testing, a subject is a natural person who participates in such a test. The term comes from the testing regime, not from data protection law.
Article 3(58) defines subject, for the purpose of real-world testing, as a natural person who participates in testing in real-world conditions.
The definition looks trivial but determines who is protected. Whoever is a subject is entitled to informed consent under point 59 and to the safeguards of Articles 57 and 60. The misunderstanding lies in assuming that only external test participants are subjects. Employees who work with a test system during their job can also be subjects, and precisely for them the voluntariness of consent is a sensitive point given the hierarchical relationship.
For each test, keep a record of the subjects or of the clearly delimited group they come from, with the date of their consent and how they were informed. Assess separately whether employees participate as subjects and how you safeguard voluntariness.
Taken from the GDPR, but decisive in the AI Act: an Annex III system that profiles always remains high-risk.
Article 3(52) defines profiling as profiling as defined in Article 4, point (4), of Regulation (EU) 2016/679.
This is the most important of the three GDPR cross-references. Article 6(3) offers an exception under which an Annex III system is nonetheless not treated as high-risk, for instance because it performs a narrow procedural task or only preparatory work. That exception falls away entirely once the system profiles within the meaning of the GDPR: automated processing to evaluate personal aspects such as performance, reliability, behaviour, health or preferences. In practice most recruitment, credit scoring and fraud detection applications do profile, so the exception many organisations invoke rarely holds.
For each Annex III system, record explicitly whether it profiles within the meaning of Article 4(4) GDPR, with the reasoning and the date. Keep that reasoning with your Article 6(3) assessment; it is the first document a supervisor will ask for.
The activity, not the authority. Work carried out on behalf of a law enforcement authority is covered as well, including where a private party performs it.
Article 3(46) defines law enforcement as activities carried out by law enforcement authorities or on their behalf for the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, including safeguarding against and preventing threats to public security.
The words "on their behalf" are decisive. A vendor, forensic analysis firm or contracted data specialist working for the police operates inside the law enforcement regime, with the corresponding safeguards and registration duties. Conversely, fraud investigation by an insurer, internal integrity investigations and private security are not law enforcement. Those organisations cannot use the exceptions and fall squarely under the ordinary regime, including the prohibition on real-time remote identification as it applies to them.
For each deployment, record whether it falls inside or outside law enforcement, naming the commissioning authority and the contractual documents. Put that qualification in the contract so vendor and client apply the same regime.
Not just the police and prosecution service. Also any other body entrusted under national law with public authority for detection, prosecution or public security.
Article 3(45) covers (a) any public authority competent for the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, including safeguarding against and preventing threats to public security, and (b) any other body or entity entrusted by Member State law to exercise public authority and public powers for those same purposes.
Point (b) draws the circle far wider than people expect. Special enforcement officers, specialised investigation services, parts of municipal enforcement and private bodies with a statutory public task can all fall within it. This is not a label without consequences: the status changes the regime. Law enforcement authorities may rely, under strict conditions, on exceptions in Article 5, register their high-risk use in a non-public section of the EU database under Article 49(4), and are subject to their own safeguards in Article 26. An organisation that wrongly treats itself as a law enforcement authority builds its compliance file on the wrong footing.
For each team and each AI system, record the statutory basis on which you enforce and whether that makes you a law enforcement authority. Have that qualification reviewed legally before you rely on any exception.
Use outside the intended purpose that the provider could have seen coming, and must therefore anticipate.
Article 3(13) defines reasonably foreseeable misuse as the use of an AI system in a way that is not in accordance with its intended purpose, but which may result from reasonably foreseeable human behaviour or interaction with other systems, including other AI systems.
The word misuse suggests bad intent, or a user error. That is the wrong reading. It concerns behaviour that is simply predictable: an employee who also uses a summarisation tool for decision-making, a chatbot receiving questions it was not built for, a model fed input by another system through an integration. The second error is the belief that excluding a use in the manual removes the risk. Not being mentioned in the manual is not the same as not being foreseeable. Note also the explicit mention of interaction with other systems, including other AI systems: chained and agentic set-ups fall squarely within it.
Keep a short list per system of foreseeable deviating use, fed by incidents, helpdesk questions and end-user signals, and note for each entry which measure was taken. Include the integrations with other systems explicitly in that list, because that is where use nobody designed emerges.
Risk is the combination of the probability of harm occurring and the severity of that harm. It is the unit of measurement underpinning the entire regulation, from prohibited practices to the Article 9 risk management system.
Article 3(2) defines risk as the combination of the probability of an occurrence of harm and the severity of that harm.
This definition looks trivial but decides who is right in a dispute. Many organisations assess AI risk as the chance of a technical failure, whereas the regulation looks at harm to people's health, safety and fundamental rights. A model that rarely fails but that, when it does, wrongly excludes someone from a job or a benefit scores high in AI Act terms, not low. Without separately substantiating probability and severity, you have an opinion rather than a risk assessment.
For each AI application, record in your register what harm you foresee, to whom, how likely you consider it, how severe the consequence is, and the source of that estimate. Use one fixed scale for probability and severity across all applications so scores are comparable and you can show the classification was not ad hoc.
A change to an AI system after it has been placed on the market or put into service that the provider did not foresee in the initial conformity assessment, and that affects compliance with Chapter III, Section 2 or changes the intended purpose.
Article 3(23) defines substantial modification as a change to an AI system after its placing on the market or putting into service which was not foreseen or planned by the provider in the initial conformity assessment and as a result of which compliance with the requirements set out in Chapter III, Section 2 is affected, or which results in a modification of the intended purpose for which the AI system was assessed.
This definition decides when you must reassess, and it contains an escape route that is often missed: changes the provider foresaw and planned in the conformity assessment are not substantial modifications. A system that keeps learning within predefined boundaries therefore falls outside it in principle, while a model you retrain on a new population or repurpose does not. Note also the link with Article 25: if you change the intended purpose, you as deployer can become the provider. The legal term is substantial modification, not material change.
Keep a change log per AI system with the date, nature of the change, the reason, and the assessment of whether it is a substantial modification, including who determined that. Agree with your provider in advance which changes were already foreseen in the conformity assessment, so you do not have to argue afterwards about whether reassessment was required.
An AI system that assigns people to categories on the basis of their biometric data. The carve-out for functions ancillary to another commercial service is narrow and is routinely read far too broadly in practice.
Article 3(40) defines a biometric categorisation system as an AI system for the purpose of assigning natural persons to specific categories on the basis of their biometric data, unless it is ancillary to another commercial service and strictly necessary for objective technical reasons.
Categorising is not the same as identifying: you are not establishing who someone is, you are attaching a label. That does not make it harmless. Sorting people by sensitive attributes such as race, political opinion, trade union membership, religion or sexual orientation has been prohibited under Article 5 since 2 February 2025, and since 2 August 2026 Article 50(3) requires you to inform the people the system is applied to. The carve-out only applies where the categorisation is strictly necessary on technical grounds for another service, for example an image filter that has to locate facial features. Commercial convenience is not technical necessity.
Record for each system which categories it assigns, which biometric features it uses and for what purpose. If you rely on the carve-out, document the technical necessity in the system description, and build the Article 50(3) information duty into your user-facing notices.
An AI system that identifies people without their active involvement, typically at a distance, by comparing them against a reference database. The decisive words are "active involvement".
Article 3(41) defines a remote biometric identification system as an AI system for the purpose of identifying natural persons, without their active involvement, typically at a distance, through the comparison of a person's biometric data with the biometric data contained in a reference database.
The hinge is whether the person actively participates. An employee placing a finger on a reader or presenting their face to gain entry is actively involved: that is biometric verification within the meaning of point 36, not remote identification. A camera that silently matches passers-by against a database does fall within scope, and such systems are high-risk under Annex III, point 1 in any event, with all attendant obligations from 2 December 2027. Vendors often sell this as "smart access control", while the reference database and the absence of cooperation are what actually decide the classification.
For every camera or biometric system, establish and document two things: is there a reference database behind it, and does the person actively cooperate. Those two answers determine whether you land in Annex III and whether the Article 5 prohibition comes into play.
The set of activities through which a provider keeps following how its AI system behaves in practice after launch, so it can intervene in time. Conformity is a starting point, not an end point.
Article 3(25) defines this as all activities carried out by providers of AI systems to collect and review experience gained from the use of AI systems they place on the market or put into service, for the purpose of identifying any need to immediately apply necessary corrective or preventive actions.
This is where organisations consistently slip: they treat the conformity assessment as the finish line and organise nothing afterwards. The definition instead establishes a continuous obligation covering the entire lifetime of the system, elaborated in Article 72 into a mandatory monitoring plan. It is not about waiting passively for a complaint, but about actively collecting and reviewing. For high-risk systems this bites from 2 December 2027 (Annex III) and 2 August 2028 (Annex I), but the monitoring system must be designed in from the start, since otherwise you have no historical data to demonstrate drift or degradation.
Record per AI system which signals you collect (complaints, support tickets, anomalous outcomes, performance measurements over time), who reviews them, at what frequency, and which threshold triggers a corrective action or a serious incident report. Keep the review records with date and model version, so you can later show that you did not start measuring only after an incident.
A concept that applies exclusively to GPAI models, and that is unrelated to the high-risk classification of AI systems.
Article 3(65) defines systemic risk as a risk specific to the high-impact capabilities of general-purpose AI models, having a significant impact on the Union market due to their reach, or due to actual or reasonably foreseeable negative effects on public health, safety, public security, fundamental rights, or society as a whole, that can be propagated at scale across the value chain. Point 64 defines high-impact capabilities as capabilities that match or exceed the capabilities recorded in the most advanced general-purpose AI models. Article 51(2) provides that a model is presumed to have such capabilities when the cumulative amount of computation used for its training, measured in floating point operations, is greater than 10 to the power of 25.
Systemic risk is often used in conversation as a synonym for high risk, and sometimes, borrowed from the financial sector, as a synonym for systemic importance. Both are wrong. Under this Regulation systemic risk is exclusively a qualification of a general-purpose AI model, never of an AI system and never of an organisation. A second misconception is that the threshold of 10 to the power of 25 floating point operations is the definition. It is not: that threshold sits in Article 51(2) and operates as a presumption, while under Article 51(1)(b) the Commission may also classify a model, on its own initiative or following a qualified alert from the scientific panel, where it has capabilities or an impact equivalent to those in point (a), having regard to the criteria in Annex XIII. For virtually every organisation this concept concerns their supplier rather than themselves; the relevant question is then which model you use and what the provider documents about it.
Record per AI application which underlying GPAI model is used and whether the provider designates that model as one with systemic risk, and keep the documentation or model card on which you base that. Use this information in supplier conversations rather than as your own classification, because the qualification belongs to the model provider.
A measure aimed at returning an AI system to the provider, taking it out of service, or disabling its use, where that system has already been made available to deployers. A recall reaches systems already in use.
Article 3(16) defines recall of an AI system as any measure aiming to achieve the return to the provider, the taking out of service, or the disabling of the use of an AI system made available to deployers.
The difference from withdrawal is the point in the chain. A recall reaches the customer already running the system, while withdrawal only stops what has not yet been delivered. For software a recall is rarely physical: it is a disabled feature, a revoked licence key or a blocked API. Organisations underestimate that a provider may be required under Article 20 to recall a system you depend on operationally, so you need to know today what you will do if a core system is switched off tomorrow.
For each AI system, record who at the provider can announce a recall, through which channel you will receive that notice, and what fallback you have if the system becomes unusable immediately. Put these arrangements in the contract and test at least annually that the notification channel works.
Data for an independent evaluation confirming expected performance, which must take place beforehand: before the system is placed on the market or put into service.
Article 3(32) defines testing data as data used for providing an independent evaluation of the AI system in order to confirm the expected performance of that system before its placing on the market or putting into service.
Two words carry this definition: independent and before. Independent means the testing data must not have been used in training or tuning; the moment you go back and adjust the model based on the test results, your test set is contaminated and you need a new one. Before means the confirmation happens in advance, not as a reconstruction after a supervisor asks. In practice this fails most often with continuously updated systems: every substantial modification calls for a fresh independent confirmation, not a reference to last year's measurement. For high-risk systems this bites from 2 December 2027 (Annex III) and 2 August 2028 (Annex I).
Keep the test set sealed off and separated from the development team, and record the measurement results per relevant subgroup, with date, model version and the metric used. Tie every substantial modification to a fresh testing round and note who performed the evaluation.
Temporarily testing an AI system for its intended purpose outside the lab, in order to gather reliable data and assess conformity. It does not count as placing on the market or putting into service, provided you meet all conditions of Article 57 or 60.
Article 3(57) defines testing in real-world conditions as the temporary testing of an AI system for its intended purpose in real-world conditions outside a laboratory or otherwise simulated environment, with a view to gathering reliable and robust data and to assessing and verifying the conformity of the AI system with the requirements of this Regulation; it does not qualify as placing the AI system on the market or putting it into service within the meaning of this Regulation, provided that all the conditions laid down in Article 57 or 60 are fulfilled.
The exception stands or falls on the word provided. If you do not meet all conditions of Article 57 or 60, your test is no longer a test but a putting into service, with all the obligations that entails and an enforcement exposure you did not see coming. In practice this shows up in pilots that quietly continue, tests that are extended to more users or sites, and systems that simply stay in production after the pilot period. Temporary means temporary.
For each test, record the start and end dates, the intended purpose being tested, the legal basis in Article 57 or 60, and an explicit decision point at the end: stop, extend under the same conditions, or move to putting into service with the full set of obligations.
The agreement between you and the supervisory authority about what you will do in an AI regulatory sandbox: objectives, conditions, timeframe, methodology and requirements. It is a two-sided document, not an internal plan.
Article 3(54) defines a sandbox plan as a document agreed between the participating provider and the competent authority describing the objectives, conditions, timeframe, methodology and requirements for the activities carried out within the sandbox.
The distinction from point 53 is often missed. The real-world testing plan is your own test design; the sandbox plan is a document agreed with the competent authority. That means you cannot change it unilaterally, and departing from the agreed conditions affects your participation in the sandbox. It is also the document with which you can later demonstrate that the supervisor knew what you were doing.
Keep the signed or confirmed sandbox plan under version control and record every change together with the competent authority's agreement. Record in your file which activities fell within the agreed scope and which were kept outside it.
Data used to fit the learnable parameters of an AI system. Narrowly defined, and precisely for that reason decisive for who carries which data governance obligation.
Article 3(29) defines training data as data used for training an AI system through fitting its learnable parameters.
The definition is deliberately technical: it covers only data that actually fit the learnable parameters. Data you pass in a prompt or place in a retrieval index are not training data, and that distinction determines whether Article 10 on data governance applies to you. Where it goes wrong: organisations that fine-tune an existing model with their own data assume they remain mere users, while they are fitting learnable parameters and quickly become a downstream provider with documentation obligations of their own. For general-purpose AI models there is additionally the public summary of training content under Article 53, applicable since 2 August 2025 and enforceable since 2 August 2026.
Record per data set its origin, the basis on which you may use it, the period over which it was collected, which processing steps were applied, and which known limitations or skews it contains. Keep training data administratively separate from validation and testing data, and explicitly log every occasion on which you fine-tune an external model.
A measure aimed at preventing an AI system that is in the supply chain from being made available on the market. It stops distribution, not use by existing customers.
Article 3(17) defines withdrawal of an AI system as any measure aiming to prevent an AI system in the supply chain being made available on the market.
This is the lighter counterpart to a recall and is frequently confused with it, including in contracts. Withdrawal only affects units still in the chain at importers and distributors. Anyone already using the system notices nothing until a recall follows. For your own procurement the practical question is whether a supplier that withdraws its product still delivers updates, patches and support, or whether you are left with a system that is commercially dead but operationally live.
Include in procurement contracts that the provider informs you as soon as it withdraws an AI system, even if you already use it, and record which maintenance and security updates you will still receive afterwards and for how long.
Data with which you evaluate and tune the trained system, including its non-learnable parameters, to prevent underfitting and overfitting. Meant for tuning, not for producing the final score.
Article 3(30) defines validation data as data used for providing an evaluation of the trained AI system and for tuning its non-learnable parameters and its learning process in order, inter alia, to prevent underfitting or overfitting.
The legislator deliberately separated validation from testing, because the classic error is using the same data both for tuning hyperparameters and for reporting final performance. You then measure your own choices back and overstate accuracy, while Article 15 requires a realistic level of accuracy that is stated in the instructions for use. In supervisory conversations this is one of the first things that stands out: an impressive accuracy figure without a separate, untouched test set.
Record which tuning decisions were made on validation data, how many evaluation rounds took place and which configuration was ultimately chosen. Ensure the validation data are never used for the figure you cite in the instructions for use and the technical documentation.
The form validation data may take: a separate data set or part of the training data set, as a fixed or variable split. The law leaves the method open, but not the explainability.
Article 3(31) defines a validation data set as a separate data set or part of the training data set, either as a fixed or variable split.
This definition looks redundant but settles a concrete argument: may you use cross-validation instead of a fixed holdout. The answer is yes, because a variable split is expressly allowed. The flip side is that the burden shifts to reproducibility. If your split changes per run and you do not record the splitting rule, you cannot afterwards show that your reported performance is not the result of a lucky split. For data sets with a time ordering or with heavily represented subgroups, a random split is moreover misleading, while Article 10 specifically demands representativeness.
Record in the technical documentation which split you use, whether it is fixed or variable, which splitting rule or seed applies, and why that split suits the nature of the data. Keep this per model version, so a later retest is reproducible.
One of the two routes into the high-risk classification of Article 6(1), and often overlooked outside manufacturing.
Article 3(14) defines a safety component as a component of a product or of an AI system which fulfils a safety function for that product or AI system, or the failure or malfunctioning of which endangers the health and safety of persons or property.
The definition contains two independent tests joined by an or, and the second is almost always forgotten. A component need not have an identifiable safety function: it is enough that its failure or malfunctioning endangers the health and safety of persons or property. Property counts too, not only injury. The second misconception is that this concept only matters for machinery and medical devices. It is the gateway to Article 6(1), and therefore to the high-risk route via Annex I, which becomes applicable on 2 August 2028 for AI embedded in regulated products. Being a safety component is not sufficient in itself. Article 6(1) sets two cumulative conditions: alongside point (a), point (b) requires that the product, or the AI system as a product, must undergo third-party conformity assessment under the Annex I Union harmonisation legislation.
Run both tests separately for each AI system and record both answers: does it fulfil a safety function, and what happens on failure or malfunctioning. Involve the product safety specialist or the product manufacturer, because that assessment belongs alongside the existing product conformity assessment and not in a separate AI track.
An act or omission contrary to Union law protecting the interests of individuals that harms the collective interests of persons in at least two other Member States, or that, with common features, occurs concurrently and is committed by the same operator in at least three Member States.
Article 3(61) defines a widespread infringement as any act or omission contrary to Union law protecting the interest of individuals which: (a) has harmed or is likely to harm the collective interests of individuals residing in at least two Member States other than the Member State in which (i) the act or omission originated or took place, (ii) the provider concerned or, where applicable, its authorised representative is located or established, or (iii) the deployer is established, where the infringement is committed by the deployer; or (b) has caused, causes or is likely to cause harm to the collective interests of individuals and has common features, including the same unlawful practice or the same interest being infringed, and is occurring concurrently, committed by the same operator, in at least three Member States.
This concept does not determine what is prohibited but how supervision is organised. Once a shortcoming in your AI system plays out the same way in several Member States, it stops being a series of separate national files and becomes one coordinated enforcement track. That is exactly the exposure of standardised software: one setting, one model or one flaw in the logic hits everywhere at once and therefore almost automatically meets the common features criterion. Note that the second limb expressly refers to the same operator, which brings deployers into scope and not only providers.
Map the Member States in which the same AI system or configuration is used and track which incidents and complaints share the same root cause across borders. Ensure that a correction made in one country is demonstrably rolled out in the others as well.
Any mathematical operation or assignment involving floating-point numbers. This is the unit of computation with which the Regulation measures the scale of training of a general-purpose AI model.
Article 3(67) defines a floating-point operation as any mathematical operation or assignment involving floating-point numbers, which are a subset of the real numbers typically represented on computers by an integer of fixed precision scaled by an integer exponent of a fixed base.
A technical definition with legal bite: FLOP is the yardstick for determining whether a general-purpose AI model is presumed to have high-impact capabilities and therefore systemic risk, using the cumulative training compute threshold in Article 51. That turns an engineering number into a compliance fact. In practice the problem is record keeping: many organisations can no longer establish afterwards how much compute went into training, while that very figure determines which regime applies and whether notification to the Commission is required.
For every model you train or significantly further train, record the cumulative amount of compute in FLOP, the measurement method and the hardware used, and keep that record with the model's technical documentation.
Article 49(2) registration record for the system assessed as not high-risk
Proof that the system for which you invoke the Article 6(3) exception is registered as Article 49(2) requires, with the registration number linked to the underlying assessment.
You invoke the Article 6(3) exception for an Annex III system.
Dated Article 6(3) assessment made before market placement
The written assessment with date, author and rationale, drawn up before the system is placed on the market or put into service, ready to be provided to the national competent authority on request.
You are the provider and conclude that an Annex III system is not high-risk via Article 6(3).
Article 6 and Annex III classification record
Traceable rationale covering intended purpose, Annex III category, Article 6(3) assessment and registration decision.
Record per dataset of origin, choices, assumptions, bias examination and mitigations.
Technical documentation kept current per system version, ready for a supervisor’s request.
Log files with a retention period appropriate to the purpose and at least six months for deployers (Articles 19 and 26).
The received instructions for use plus their internal translation into work instructions per role.
Record of oversight measures, appointed persons, their training and the moments of intervention.
Declared accuracy levels, test results, and measures against data poisoning and adversarial attacks among others.
Provider dossier per high-risk AI system
One dossier per system holding the documentation, the logs, the EU declaration of conformity and the registration record, in the version that applied at the moment of placing on the market.
To be maintained per individual high-risk AI system, not per product line or per supplier.
The documented quality system with procedures, role assignment and references to the underlying files.
Versioned record of roles, context, measures, participation or instruction and review moments.
Register of participation and instruction per person, system and date
Internal register showing who received which instruction, working session, training or guidance, for which system, on which date and on what basis, including new joiners, contractors and external staff.
Measures have been carried out under Article 4(1).
Role-system matrix with the established literacy need
The recorded matrix of roles against AI systems, with the context of use, affected persons, risk and selected measure per combination, dated and with an owner per row.
There is no prescribed format and no mandatory AI officer; the form may match the size of the organisation.
A record per system that the Article 5 screening was performed, with outcome and reasoning. The conclusion "no prohibited practice" is evidence too.
Test report per touchpoint: disclosure visible, timely and accessible
Dated record per interface and channel showing that the disclosure appears at the latest at first interaction or exposure, is clear and distinguishable, and passed the accessibility check, with screenshot, version number and tester identity.
One of the duties in Article 50(1) to (4) applies to the system.
Record of scenario, actor, disclosure or marking, technical implementation, test and owner.
Supplier statement on machine-readable marking of output
Written statement from the supplier describing which marking is applied to the output, in which machine-readable format, how robust and interoperable the solution is, and whether the marking survives editing or export.
The system generates synthetic audio, image, video or text content.
The duty does not apply to the extent the AI system performs an assistive function for standard editing or does not substantially alter the input data provided by the deployer or its semantics, or where authorised by law to detect, prevent, investigate or prosecute criminal offences. Under the amended application calendar in Regulation (EU) 2026/1744, systems placed on the market before 2 August 2026 have a transition until 2 December 2026 for this machine-readable marking.
Evaluation results, risk assessments, mitigations, incident reports and security measures per model version.
Written proof of participation and the exit report
On request, the competent authority provides written proof of the activities successfully carried out, plus an exit report with results and learning outcomes. You can use that documentation in conformity assessment and in market surveillance.
Applies where you participate in or exit an AI regulatory sandbox as a provider or prospective provider. The written proof is provided only upon request; the exit report is provided by the authority on its own initiative. If you participate as a deployer in partnership under Article 58(2), point (b), the written proof remains a right of the provider or prospective provider; agree contractually that you receive a copy.
Publication of the exit report through the single information platform only occurs where you and the national competent authority both explicitly agree. Access by the Commission and the Board likewise requires your agreement and remains subject to the confidentiality provisions in Article 78.
Dated and documented informed consent of test subjects
For every test subject you record freely given informed consent, covering five prescribed information elements, dated, documented, with a copy provided to the subject.
Applies to every natural person who is a subject of testing in real world conditions under Article 60, prior to their participation.
Article 60(4), point (i), contains a law enforcement carve-out: where seeking informed consent would prevent the AI system from being tested, testing may proceed without consent, provided that the testing and its outcome have no negative effect on the subjects and that their personal data are deleted after the test is performed. Outside that specific context there is no exception to consent.
The plan as part of the technical documentation plus the periodic analyses and follow-up actions.
Record of incidents, analyses, reports to supervisors and corrective measures.
Versioned record of risk analyses, chosen measures, residual risks and test results per system version.
The assessment, EU declaration of conformity, CE marking and registration proof, per system version.
Deployment dossier: logs, worker information and information to affected persons
The dossier that shows you retain the logs, that you informed workers and their representatives in time, and that the people about whom decisions are made are aware of it.
To be maintained per high-risk AI system. Log retention applies only to the extent the logs are under your control; the information under paragraph 7 applies only where you are an employer and the system is used at the workplace.
Distributor log of checks and corrective actions
A running record of what you checked, when, with what outcome and which action followed, because the supervisor asks about your conduct rather than about the system.
To be maintained per system made available and per customer, for as long as the system is on the market through you and you may still have to take corrective action.
Per request: who made it, about which decision, which system and which version contributed to it, what explanation was given and when. This is also the file that shows you did not silently ignore the right.
Notification to the market surveillance authority with the completed template
The sent notification through which you report the assessment results to the market surveillance authority, with the completed template attached, plus date of dispatch and acknowledgement of receipt.
The assessment under Article 27(1) has been performed.
In the case referred to in Article 46(1), deployers may be exempt from the notification duty; the assessment itself does not fall away.
Crosswalk showing the FRIA complements rather than repeats the DPIA
An overview indicating per Article 27(1) element whether it is already covered in the data protection impact assessment and where, so it is visible which elements exist only in the FRIA.
A data protection impact assessment has been carried out or is required for the same deployment.
Dated impact assessment, measures, residual risks and, where required, notification to the market surveillance authority.
Current technical documentation, downstream information, copyright policy and public training summary.
Model version register listing the changed Annex XI and XII elements per version
A register with one row per model version: release date, distribution method, architecture and parameter count, compute used, and a note of which Annex XI and Annex XII elements changed relative to the previous version.
You place or make available more than one version of the same GPAI model on the Union market.
Public summary of training content following the AI Office template
The published, sufficiently detailed summary of the content used to train the model, drawn up according to the template provided by the AI Office, with publication date and the corresponding model version.
The open-source exemption in Article 53(2) covers only points (a) and (b) of paragraph 1 and therefore leaves the public training summary intact.
Importer dossier with ten-year retention
Your own archive of the notified body certificate, the instructions for use and the EU declaration of conformity, available for ten years and in a language the authority easily understands.
The ten-year term runs from placing on the market or putting into service, and therefore per system and per version, not per supplier relationship.
Record per system of role, contractual arrangements on information and cooperation, and the appointment of a representative where required.
Candidate recommendation that automatically becomes a decision
An employer uses a system that ranks applicants and recommends a candidate to hire. In one setup a recruiter weighs that recommendation in their own assessment; in the other the outcome is applied automatically and a candidate is rejected without anyone looking at it.
The Commission draft guidelines of 19 May 2026 address this case when determining whether an application falls under Annex III. The document is a consultation version: non-binding and not yet final.
Draft guidelines on high-risk AI classification, 19 May 2026, annex on Annex III
Assess a recruitment system on its intended purpose rather than on whether a recruiter reviews the output, because adding or removing human involvement does not change its high-risk classification.
AI articles on EU policy without substantive review
A website automatically publishes AI-generated articles about European policy. There is an editorial charter on paper, but nobody reviews the substance. Before publication only a spell check runs, and a second AI model reviews the text.
The final Commission guidelines on Article 50 treat this case as a worked example under the transparency obligations. The document is non-binding.
Commission Guidelines C(2026) 5054 final, 20.7.2026, worked examples under Article 50
An editorial charter on paper, a spell check and a second AI model do not count as human review, so without substantive fact checking by a person you must label the publication.
AI summary of a council decision under editorial control
A news site places an AI-generated summary beneath a journalist's article about a recent town council decision. The editor in chief reads the summary on substance, checks the facts and signs off for publication.
Do not rely on the editorial exception without substantive review by a competent person and a publicly identifiable holder of editorial responsibility, and note that any AI intervention after sign-off voids it.
AI toy rewards children for dangerous challenges
A manufacturer markets an AI-powered toy that keeps children engaged by encouraging increasingly risky challenges, such as climbing furniture, exploring high shelves or handling sharp objects, in exchange for digital rewards and virtual praise.
The Commission guidelines on prohibited AI practices treat this case as a worked example under Article 5. The document is non-binding: authoritative interpretation rests with the Court of Justice.
Commission Guidelines C(2025) 5052 final, 29.7.2025, worked examples under Article 5
If children are among your users, assess every engagement and reward mechanism separately, because what counts as acceptable stimulation for adults can already be exploitation of children's curiosity and desire for rewards.
Facial recognition at access control: the guard behind the camera counts too
An organisation secures the entrances to its buildings with facial recognition and uses that biometric access control to register visitors as well. When the system returns no match, a security officer reviews the camera images and decides personally whether someone may enter. The question is whose measures have to reach that officer: those of the supplier of the model, those of the department that deploys the system, or both.
Article 4(1) provides that providers and deployers of AI systems shall take measures to support the development of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf. In doing so they must take into account technical knowledge, experience, education and training and the context the AI systems are to be used in, and consider the persons or groups of persons on whom the AI systems are to be used. The same provision states that this obligation does not require providers or deployers to guarantee any specific level of AI literacy of any individual.
We read the phrase about the persons on whom the system is used as the centre of gravity for biometrics: whoever stands in front of the camera is subject to the outcome and has little to set against it. That argues for equipping the officer who decides for himself when no match comes back more substantively than the colleague who merely switches the system on and off. The article itself names no sufficient level and expressly states that you need not guarantee one, so where the floor lies for each role stays open. In our assessment a record kept per role, stating the choice made and the reason for it, is easier to defend than one organisation-wide session backed only by an attendance list.
Police using AI in investigations: context sets how deep the training goes
A police force uses AI to search large volumes of investigation files and surface connections a detective would otherwise miss. The outputs feed into the choice of which suspect is pursued further and end up in documents that enter the criminal process. The question is whether one and the same basic instruction is enough for the analyst operating the model and for the detective who acts on its output.
Article 4(1) requires providers and deployers of AI systems to take measures supporting the development of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf. The provision prescribes that they take into account technical knowledge, experience, education and training and the context the AI systems are to be used in, as well as the persons or groups of persons on whom the AI systems are to be used. It also states that this obligation does not require any specific level of AI literacy of any individual to be guaranteed.
Article 4 requires you to weigh the context of use and the people the system is applied to, and in law enforcement both factors run high on our reading. Whether a general introduction to what AI can do is then enough for someone carrying an output into a file that affects a person's position as a suspect, we doubt, but the provision expressly names no level you must guarantee, so that floor is yours to justify. We would record for each role what someone must be able to recognise, for instance that a discovered connection is not yet evidence, and revisit that choice periodically.
Newsroom with generative AI: do freelancers count within your measures?
A newsroom uses generative AI to prepare summaries, headlines and imagery, after which an editor finishes the piece and the desk decides to publish. Part of that work sits with freelancers, and an outside agency produces marketing content with the same tools. The question is whether your AI literacy measures must reach those freelancers and that agency, or only the people on the payroll.
Article 4(1) is addressed to providers and deployers of AI systems and requires them to take measures supporting the development of AI literacy of their staff and of other persons dealing with the operation and use of AI systems on their behalf. The provision requires them to take into account technical knowledge, experience, education and training and the context the AI systems are to be used in, as well as the persons or groups of persons on whom the AI systems are to be used. It does not require any specific level of AI literacy of any individual to be guaranteed.
Alongside staff, the text expressly names other persons dealing with the operation and use of AI systems on your behalf, and we read that as a functional boundary rather than a contractual one. On that reading a freelance editor using your tool inside your workflow and on your instruction sits within your measures, employment contract or not. The outside agency is a harder case: if it works in your environment and on your instruction, the argument that it acts on your behalf holds up, but if it runs its own tools on its own account it is a deployer in its own right, and Article 4 does not say your measures must cover that work. In practice, in our assessment, that means recording in your agreements who works in which role and what instruction you give, rather than trusting the other side to arrange it.
AI chat in recruitment and selection: what the applicant must be told
A recruiter deploys an AI chat that puts candidates through a first screening conversation after they respond to a job posting, and adds their answers to their CV. The chat introduces itself with a first name and writes in a casual conversational tone. The question is whether these applicants reasonably realise that they are talking to an AI system.
Article 50(1) requires providers to ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use. Article 50(5) provides that this information must be given to the natural persons concerned in a clear and distinguishable manner at the latest at the time of the first interaction, and must conform to the applicable accessibility requirements.
We read the obviousness test as a question about the audience the system actually meets, and in recruitment and selection that audience is not a trained professional group but a broad set of applicants under pressure who do not yet know the organisation. A human first name and a casual tone push that assessment the wrong way in our view, however well they convert. If you buy the chat rather than build it, Article 50(1) is by its wording addressed to the provider, while you are the one choosing the persona and the entry point; whether putting your own name on such a chat moves you into the provider role is a question Article 50 does not answer. So make the disclosure in the first message a procurement requirement and verify at delivery that it is genuinely there.
Camera at the entrance: access control versus biometric categorisation
An organisation admits staff through facial recognition at its access control gate and additionally runs a camera in the visitor area that sorts faces into age groups. Both applications run on the same biometric infrastructure and the same images. The question is which of the two requires the people involved to be actively informed.
The Commission guidelines of 20 July 2026 count automated facial-recognition access controls among the systems that merely collect data passively and are not capable of an exchange with natural persons, and therefore do not interact within the meaning of Article 50(1). For Article 50(3) they state that, unless the use is prohibited under Article 5(1)(g), the information duty applies to any biometric categorisation system, including outside the high-risk scope, and they give classification by age or gender on the basis of biometric data as an example. Article 50(3) itself carries a further exception for systems permitted by law to detect, prevent or investigate criminal offences. As a way of informing people the guidelines describe a visible notice at each possible entrance to an exhibition room stating that facial images are captured to assign visitors to an age group, provided at the latest at the moment of first exposure.
Commission Guidelines C(2026) 5054 final, 20.7.2026, point (30) and points (104) to (108)
Our reading is that you should map this per processing purpose rather than per camera: the same lens that stays outside Article 50(1) at the access control gate moves inside Article 50(3) as soon as those images place people in a category. Record for each setup what happens to the capture and who the deployer is, because that decides whether a notice belongs at the entrance. The guidelines prescribe no fixed form, but they do fix the moment: the notice has to be there before someone walks into frame, and a line in the privacy statement rarely makes that moment, in our reading.
Code assistant for developers: an exception, until it faces outward
A software company uses an AI assistant for code suggestions and code review, available only to professional developers. The same company also runs a helpdesk chatbot for customers.
The Commission guidelines of 20 July 2026 list code assistance and code review chatbots available only to professional developers as an example where the obviousness exception applies. Chatbots embedded in online platforms or helpdesks, where users may perceive outputs as human-generated, they list as an example where the disclosure duty does apply.
Commission Guidelines C(2026) 5054 final, 20.7.2026, paragraph (45), lists with and without the obviousness exception
Two AI assistants at the same company, two outcomes. Assess per application who the user is and what they reasonably expect, rather than taking one organisation-wide position on chatbots.
Fraud reporting portal at a bank: why the law enforcement exception drops out
A bank opens an AI-driven reporting portal where customers can flag suspected fraud around their payment account or loan. The system asks follow-up questions, categorises the report and routes it to fraud detection and, where money laundering signals appear, to the internal reporting team. Because the portal concerns criminal offences, the bank assumes the disclosure duty for direct AI interaction does not apply.
The Commission guidelines of 20 July 2026 expressly list AI-assisted fraud reporting hotlines and digital portals operated by financial institutions or public authorities, where users can report suspected financial crimes, as an example that is not exempted and falls within the scope of Article 50(1). They explain that the exception does not apply where the system is available to the public and offers individuals the functionality to report a criminal offence. The fact that the system only gathers details, categorises and prioritises the report while human investigators validate the information before any action is taken does not change that in the guidelines.
Commission Guidelines C(2026) 5054 final, 20.7.2026, points (48) and (49), list of examples under the law enforcement exception
In our reading this is where banks most often take the wrong turn: the reporting portal sits organisationally under fraud and compliance, which makes the law enforcement exception feel natural, while it is precisely the public reporting channel that is carved out of that exception. On top of that, the exception is written for use authorised by law for law enforcement purposes, and the guidelines stretch it no further than to other public authorities holding such a legal basis, so in our reading a private bank rarely stands in it at all, before the public reporting channel even comes up. Treat the portal as an ordinary public-facing chat and put the disclosure in the first screen of the conversation. A line in the terms and conditions or a product leaflet is a weak choice for this channel, because by then the person is already telling their story.
AI text from a municipality: when a final check counts as editorial control
A municipality has an AI system write the web pages about a changed scheme for social assistance and allowances, meant to explain to citizens what they are entitled to. A communications officer reads the text for style and spelling and publishes it. The question is whether this public service thereby falls under the exception to the labelling duty.
The Commission guidelines of 20 July 2026 count public administration and public services among the matters of public interest covered by the disclosure duty for published AI text in Article 50(4). For the exception, the guidelines require two cumulative conditions: the AI-generated or manipulated text has undergone human review or editorial control, and a natural or legal person holds editorial responsibility for the publication. They add that human review means a deliberate examination of the substance with fact-checking as a minimum requirement, and that superficial, purely formal or procedural checks such as spell-checking or grammatical correction do not meet it. For the second condition they expect the identity or the function carrying editorial responsibility to be publicly available in an easily findable place.
Commission Guidelines C(2026) 5054 final, 20.7.2026, point (131), points (133) to (136) and point (138)
Our reading is that many municipalities do have a publication process but no identifiable person carrying substantive final responsibility, and that is exactly the hinge of this exception. Assign that role explicitly, make it findable who holds it, and record per page who checked the facts, or otherwise take the simpler route and label the text. Watch the order of steps in your workflow, because an AI tool that substantively rewrites the text after human sign-off removes the ground from under that sign-off.
Internal assistant for HR and compliance: an exception with a condition
An organisation gives staff an internal AI assistant for HR, legal, procurement, compliance and IT questions. Must that assistant disclose at every turn that it is AI?
The Commission guidelines of 20 July 2026 list an internal employee-facing assistant for properly trained, AI-literate staff who are aware they are using AI systems for internal organisational purposes as an example where the obviousness exception in Article 50(1) applies.
The guidelines tie this exception explicitly to properly trained, AI-literate staff. Relying on it therefore stands or falls with what you have arranged and can demonstrate on literacy under Article 4: without that record you are leaning on an assumption about your own people.
Diagnostic support for clinicians: no disclosure duty, still due care
A hospital deploys an interactive AI system used exclusively by properly trained health professionals to support medical diagnosis and suggest treatments. The question is whether the patient or the clinician must be told it is AI.
The Commission guidelines of 20 July 2026 list interactive AI systems intended only for properly trained health professionals to support medical diagnosis and suggest treatments as an example where the obviousness exception in Article 50(1) applies: for that user the AI nature is clear.
The exception attaches to the user, not to the system. The moment the same model also speaks to patients, that ground falls away and the disclosure duty applies as normal. And an exception to Article 50 says nothing about the rest: where it is a medical device or a high-risk application, those regimes continue to apply in full.
Law enforcement: exempt from the disclosure duty, with safeguards
An authority empowered by law to detect criminal offences wants to deploy an interactive AI system without telling those involved that they are communicating with AI.
Article 50(1) exempts providers of interactive AI systems from the disclosure duty where they are authorised by law to detect, prevent, investigate or prosecute criminal offences, subject to appropriate safeguards for the rights and freedoms of third parties. The Commission guidelines of 20 July 2026 elaborate that exception.
Commission Guidelines C(2026) 5054 final, 20.7.2026, paragraph (46), law-enforcement exception
The exception is narrow and conditional: it requires a legal basis for the law-enforcement task and appropriate safeguards for third parties. A public task by itself is not enough, and the safeguards are not a footnote but part of the ground you are relying on.
An induction call with the customer at the moment of go-live
Asimov AI is a micro organisation of at most fifteen people that supplies AI services for legislative work to government institutions and companies. With every new contract it holds one or more induction calls with the team leads and officials who will use the platform, explaining how the platform and the underlying models work and how hallucinations arise in this domain and can be mitigated.
This practice was submitted by the organisation itself to the Commission living repository. The repository collects and shares practices; it does not approve them or set them as a standard.
Living repository of AI literacy practices, practice submitted by the organisation concerned
This practice puts literacy where the risk arises: with the people who will operate the system, at the moment they start. For a small provider that is also the only workable moment, because there is no training department to redo it later. Anyone adopting it should record who attended and what was explained, because otherwise the effort survives only in the participants memory a year on.
Performance scoring for staff goes wrong: report or not
An employer uses an AI system that scores employee performance and lets that score weigh in promotion and dismissal. After a change to the model it turns out that a group of staff was scored too low for months, and decisions have already been taken on those scores. HR wonders whether this is a serious incident and who would have to report it.
Article 3, point (49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to, among other things, the infringement of obligations under Union law intended to protect fundamental rights. Article 73(1) places the duty to report serious incidents on the provider of the high-risk AI system placed on the Union market, towards the market surveillance authorities of the Member State where the incident occurred. Article 73(2) requires the report to be made immediately after the provider has established a causal link between the AI system and the serious incident, or the reasonable likelihood of such a link, and in any event no later than 15 days after the provider or, where applicable, the deployer becomes aware of the serious incident, with the period taking account of the severity of the incident. Article 73(6) obliges the provider, after reporting, to perform the necessary investigations without delay in relation to the serious incident and the AI system concerned, including a risk assessment and corrective action, cooperating with the competent authorities and, where relevant, with the notified body concerned. Article 26(5) requires a deployer that has identified a serious incident to inform, immediately, first the provider and then the importer or distributor and the relevant market surveillance authorities.
Article 3(49), Article 26(5) and Article 73(1), (2) and (6)
In the workplace the hard part is the awareness trigger in Article 73(2): harm spread thinly across many employees does not arrive as an alarm but trickles in through complaints, a performance review or the works council. Whether systematically low scores that feed into promotion and dismissal amount to a serious incident depends, on our reading, on whether obligations protecting fundamental rights have thereby been infringed within the meaning of Article 3, point (49)(c); Article 73 does not make that assessment for you. Decide in advance which HR signal counts as an incident signal and who puts it in front of the provider that same week, rather than reconstructing that afterwards; Article 26(5) also requires you as deployer, once you have identified a serious incident, to inform the provider immediately and then the importer or distributor and the market surveillance authority. Note finally that the corrective action in Article 73(6) concerns the system; what should happen to promotion or dismissal decisions already taken is, on our reading, not answered by this article and runs through other rules, employment law among them.
Inferring political opinions from uploaded photos
A platform analyses the biometric data in photos users have uploaded to infer their assumed political orientation and serve them targeted political messages. A comparable system infers assumed sexual orientation in order to serve advertisements.
Relying on the ancillary feature exception requires that the feature is also strictly necessary for objective technical reasons alongside the main service, since both conditions apply cumulatively and advertising purposes do not meet that bar.
Face comparison at the border gate: verification or identification
An automated border gate uses biometric facial recognition to compare a traveller’s face with the photo in the passport chip. The same camera could technically also compare against a law-enforcement database, and exactly that difference decides whether this biometrics is high-risk.
The Commission draft guidelines of 19 May 2026 state that biometric verification falls outside the high-risk classification: one-to-one comparison of presented biometrics with previously stored biometrics, for the sole purpose of confirming that a person is who they claim to be. Where the same capture is additionally compared against a law-enforcement database, it does become remote biometric identification. The document is a consultation version: non-binding and not yet final.
Draft guidelines on high-risk AI classification, 19 May 2026, annex on Annex III, paragraph (136)
Test your biometric application on purpose rather than technology: the same camera and the same model stay outside the high-risk route as long as the comparison is one-to-one and only confirms identity, and fall inside it as soon as that same capture is also held against a database. Record per application what the comparison runs against, because that single design choice moves the entire regime.
A three-part training for legal and public affairs staff
Booking.com built a three-part training for its legal and public affairs teams: first basic terminology and the difference between classic machine learning and language models, then how AI works inside the company, then the regulatory landscape and where it meets the law they already practise. The material was also released as a video and podcast series with subtitles and written handouts.
The sequence is the interesting part: first the technology, then the organisation itself, and only then the law. Lawyers who reverse that order memorise the Regulation without being able to judge where their own systems land. That the training exists in several formats also helps to show it was genuinely reachable for everyone who needed it.
A call centre uses webcams and voice recognition to track employees' emotions, such as anger. The same company also uses voice analysis to detect when a customer becomes irritated.
The prohibition follows the relationship of authority rather than the technique: the same voice analysis is prohibited on employees but not on customers, and workplace also covers applicants and probation periods.
An employer has an external recruitment system score and rank every incoming application, after which recruiters only review the top twenty percent by hand. The vendor puts the system on the market under its own name, and the employer uses it in its own selection process.
Recruiters keeping the final say does not help you, because once the system scores or ranks applicants and thereby shapes the shortlist it stays high-risk and no exemption applies.
Database query and standard spreadsheet without AI features
A customer service department runs a database query to find all customers who purchased a specific product last month, and calculates the average from a satisfaction survey in a standard spreadsheet. Every step follows predefined instructions.
The Commission guidelines on the definition of an AI system use this case to draw the line between software that does and does not fall under the regulation. The document is non-binding.
Commission Guidelines C(2025) 5053 final, 29.7.2025, borderline cases under the definition in Article 3(1)
If you rely on the basic data processing category, look at the whole lifecycle rather than the use phase alone, because that category assumes no learning, reasoning or modelling at any stage.
Lawyers learn the technology, developers learn the law
Dedalus Healthcare, which among other things supplies AI that predicts complications for hospital patients, trains its legal staff, data protection officer, compliance function and quality and regulatory affairs department on the technical side. Developers and engineers conversely receive training focused on the legal and compliance aspects of the AI Act. The executive committee received its own session tailored to its role.
Look for knowledge deliberately outside a single discipline, because the repository names collaboration between industry and academia as one of the ways organisations build AI literacy.
Deep fake on a Christmas card: the provider marks, the private person does not
A private individual uses a generative AI service to create a deep fake of themselves and their household for their own Christmas card, purely personal and with no business purpose.
The personal-use exclusion touches only the user duties, so if you supply the generative service you still mark outputs machine-readably, and any professional purpose brings the labelling duty back.
A real car against an AI background is not a deep fake
A car company photographs an existing model and places it in an advertisement against a fully AI-generated background with an invented landscape. The car itself is untouched.
The leeway hangs on the product itself, so an AI background is fine as long as appearance, characteristics and use stay unchanged, but once the editing touches the product, labelling returns.
Medical exception: accessibility yes, burnout detection no
An employer wants to deploy emotion recognition. In one scenario the system assists employees with autism and improves accessibility for blind and deaf colleagues. In the other it measures stress levels to flag burnout, boredom or loss of motivation.
The medical exception is narrow: supporting a specific impairment qualifies, general monitoring of wellbeing, stress or motivation does not, and data gathered under a permitted use may not be reused for other purposes.
Serious incident on the production line: who reports and within what deadline
A manufacturer supplies an AI system that runs as a safety component in a machine on the production line and at the same time drives quality control. At a customer's factory an operator is seriously injured after the machine failed to stop on an anomaly. The question is who reports, to whom, and which clock is already running at that moment.
Article 73(1) places the reporting of serious incidents on the provider of the high-risk AI system placed on the Union market, addressed to the market surveillance authorities of the Member State where the incident occurred. Article 73(2) requires that report to be made immediately after the provider has established a causal link between the AI system and the serious incident, or the reasonable likelihood of such a link, and in any event no later than 15 days after the provider or, where applicable, the deployer becomes aware of the incident, with the reporting period taking account of the severity of the incident. Article 73(4) shortens that to no later than 10 days in the event of the death of a person. Article 73(6) obliges the provider, following the report, to perform the necessary investigations without delay, including a risk assessment and corrective action, and not to perform any investigation involving alteration of the AI system in a way that may affect the subsequent evaluation of the causes of the incident without first informing the competent authorities. Article 26(5) requires a deployer that has identified a serious incident to inform, immediately, first the provider and then the importer or distributor and the relevant market surveillance authorities, and makes Article 73 apply mutatis mutandis where the deployer cannot reach the provider.
We read Article 73(2) as meaning that the clock can already start at the deployer on the factory floor, while the report under Article 73(1) sits with you as the provider of the AI system. That does not leave your customer free to sit still: Article 26(5) gives the deployer a notification route of its own, running past you, the importer or distributor and the market surveillance authority, and makes Article 73 apply mutatis mutandis if you cannot be reached. Fix that route in the contract and in the service line before anything happens. Where an operator is seriously injured but does not die, we read the outer limit of Article 73(2) as the one in play rather than the 10 days of Article 73(4); how much sooner than that outer limit you must report is left open by the text and turns on severity. Bear in mind as well that the reflex to repair the machine immediately and resume production can collide with Article 73(6), because an investigation that alters the system first requires notice to the competent authority. Working that out only during the incident costs days that these deadlines do not allow.
Expert system that draws a conclusion from encoded knowledge
A hospital uses an older diagnostic support expert system in which physicians encoded knowledge, facts and rules. Based on the symptoms a doctor enters, the system independently draws a conclusion about possible conditions.
Machine learning is not a requirement, so you cannot argue that your system merely applies rules encoded by experts; logic and knowledge based systems that draw conclusions on their own are covered too.
A trained AI contact person in every department at a telecom company
Fastweb operates more than ninety AI systems and formally appoints an AI-SPOC in every department, a trained point of contact for AI questions from that team. These people receive separate instruction on prohibited practices and high-risk systems and are allowed to run their department's AI risk assessment themselves.
Do not copy a practice from this repository as is, since the Commission states that replication grants no automatic presumption of compliance; first test whether the setup fits your own systems and roles.
Heavy fine-tuning makes you the model provider
A European scale-up fine-tunes an existing general-purpose AI model for its own product, using more compute than one third of the compute used to train the original model.
The Commission guidelines on the scope of the GPAI obligations address this case when determining when someone becomes a model provider themselves. The document is non-binding.
Commission Guidelines C(2025) 5045 final, 18.7.2025, scope of the obligations for GPAI model providers
Estimate your fine-tuning compute against the original model before you start, because exceeding one third of it makes you the provider, with documentation, copyright and training-content duties limited to your modification.
Screening tax returns for criminal offences on a profile alone
A tax authority runs a predictive AI tool over all tax returns to flag potential criminal tax offences. This is done solely on the profile built by the system, using personality traits such as dual nationality, place of birth and number of children, together with inferred variables that are hard to verify.
To stay outside this prohibition a system must rest on real, verifiable facts directly linked to a specific criminal activity, since simply adding further variables to a profile is not enough.
A tax authority uses an AI system to detect childcare benefit fraud by profiling beneficiaries and assigning them to categories such as deliberate intent or gross negligence, using criteria such as low income, dual nationality and social behaviour. Based on the risk score, files are inspected, benefits are stopped and repayment is demanded.
Fraud detection remains legitimate, but check for each variable whether it genuinely belongs to the purpose and whether the consequence is proportionate, since unrelated personal characteristics plus severe consequences turn a control into social scoring.
Awarding social assistance in a municipality: the FRIA and the notification
A municipality wants to deploy an AI system that sorts applications for social assistance benefits and indicates which files merit extra scrutiny before a case worker decides. The application is already listed in the public algorithm register. The question is what has to be in place before the first citizen passes through this system.
Article 27(1) requires deployers which are bodies governed by public law, or private entities providing public services, to perform an assessment of the impact on fundamental rights that the use of a high-risk AI system referred to in Article 6(2) may produce, prior to deploying it, with the exception of systems intended to be used in the area listed in point 2 of Annex III. That assessment covers, among other elements, the categories of natural persons and groups likely to be affected, the specific risks of harm to those categories, the implementation of human oversight measures, and the measures to be taken if those risks materialise, including the arrangements for internal governance and complaint mechanisms. Article 27(3) provides that once the assessment has been performed, the deployer shall notify the market surveillance authority of its results and submit the filled-out template referred to in paragraph 5 as part of that notification, and that in the case referred to in Article 46(1) deployers may be exempt from that obligation to notify. Article 27(5) provides that the AI Office shall develop a template for a questionnaire, including through an automated tool, to facilitate deployers in complying with their obligations under this Article in a simplified manner.
We read Article 27 as making the municipality the most obvious deployer here, and as requiring the assessment to be complete before the first application runs through the system, not as an account rendered afterwards. That duty does depend first on whether this system is high-risk at all: does it help decide entitlement to social assistance, or does it stay within a preparatory or narrowly procedural task under Article 6(3), which closes its own exception again once the system profiles citizens? Answer that question before you start on paragraph 1. An entry in the public algorithm register is on our reading something different from the assessment under paragraph 1, and it does not replace notifying the market surveillance authority of the results. In practice it pays to record the citizen's complaint route and the case worker's room to depart from the signal in the same file, because paragraph 1 asks for precisely those two elements.
Recidivism scoring in police work: when the assessment must be redone
A police service deploys an AI system that estimates the recidivism risk of a suspect, as an aid to the judgements later made by the prosecution service and the court. The model is subsequently retrained on newer investigative data and use is extended to a second region. The question is whether the assessment made for first use remains adequate.
Article 27(1) requires deployers which are bodies governed by public law to perform, prior to deploying a high-risk AI system referred to in Article 6(2), an assessment of the impact on fundamental rights that its use may produce, with the exception of systems intended to be used in the area listed in point 2 of Annex III. That assessment consists of a description of the processes in which the system will be used, of the period and frequency of use, of the categories of natural persons and groups likely to be affected, of the specific risks of harm taking into account the information given by the provider pursuant to Article 13, of the implementation of human oversight measures according to the instructions for use, and of the measures to be taken if those risks materialise. Article 27(2) provides that the obligation applies to the first use, that previously conducted impact assessments or existing assessments carried out by the provider may be relied on in similar cases, and that a deployer who considers during use that any element listed in paragraph 1 has changed or is no longer up to date shall take the necessary steps to update the information. Article 27(3) provides that the results are notified to the market surveillance authority together with the filled-out template, and that in the case referred to in Article 46(1) an exemption from that notification duty may apply.
We read Article 27 as covering a police service as a body governed by public law under paragraph 1, and as an assessment that does not stop at first use: retraining on newer investigative data or extending use to a second region touches the elements of paragraph 1 and, on our reading, calls for updating the record. That retraining also raises a question Article 27 itself does not answer, namely whether the change goes far enough to count as a substantial modification, which would make you a provider in your own right under Article 25. Bear in mind as well that the exception in paragraph 3 concerns, on our reading, the notification and not the assessment itself. Finally, start that assessment only after establishing that the deployment as such is permitted, because Article 5 rules out certain predictive applications in criminal investigation.
Selection at student admission: a DPIA is not yet a FRIA
A university of applied sciences has an AI system rank applications for a vocational programme, using the exam results of earlier students to calibrate that ranking. A data protection impact assessment already exists for this processing. The question the school asks is whether that also covers the fundamental rights side of admission.
Article 27(1) provides that deployers which are bodies governed by public law, or private entities providing public services, and deployers of high-risk AI systems referred to in points 5(b) and (c) of Annex III, shall perform an assessment of the impact on fundamental rights prior to deploying a high-risk AI system referred to in Article 6(2), with the exception of systems intended to be used in the area listed in point 2 of Annex III. That assessment consists of a description of the deployer's processes in which the system will be used in line with its intended purpose, of the period and frequency of use, of the categories of natural persons and groups likely to be affected, of the specific risks of harm to those categories, of the implementation of human oversight measures, and of the measures to be taken if those risks materialise, including the arrangements for internal governance and complaint mechanisms. Article 27(2) provides that the obligation applies to the first use, that the deployer may in similar cases rely on previously conducted impact assessments or existing assessments carried out by the provider, and that a deployer who considers during use that any element listed in paragraph 1 has changed or is no longer up to date shall take the necessary steps to update the information. Article 27(4) provides that where an obligation under this Article is already met through the data protection impact assessment conducted pursuant to Article 35 of Regulation (EU) 2016/679 or Article 27 of Directive (EU) 2016/680, the assessment under paragraph 1 complements that data protection impact assessment.
We read Article 27 as placing the education institution that runs this selection itself in the deployer role, but that alone does not settle the duty. Paragraph 1 names bodies governed by public law and private entities providing public services, and whether a state-funded or a private university of applied sciences answers to either description is the question you have to settle first. If it does, an existing data protection impact assessment is on our reading the starting point rather than the last word: paragraph 4 has the fundamental rights assessment sit alongside it, and since Regulation (EU) 2026/1744 that assessment may incorporate or cross-refer to relevant parts of it, so the real question is which elements of paragraph 1 are still missing. For you that means recording which groups of students may be affected, how the admissions committee or the teacher can correct an outcome, and where a rejected applicant can lodge a complaint. If the selection rule or the assessment component underpinning the ranking changes, that is on our reading the moment to update the record, rather than the start of the next academic year.
Health insurer using AI for risk assessment: public or private makes no difference
A health insurer uses AI for risk assessment and pricing of health and life insurance. The question is whether this falls under point 5(c) of Annex III, and with that whether the Article 27 FRIA duty comes into play.
The Commission draft guidelines of 19 May 2026 state that the health and life insurance in point 5(c) may be offered on a private or a public basis: a health insurer governed by public law also falls within it, so long as the system is intended for risk assessment or pricing with regard to natural persons. Privately serviced health insurance counts as an essential private service, even in a Member State with a public healthcare system. Unlike point 5(b), point 5(c) provides no exception for fraud detection. The document is a consultation version: non-binding and not yet final.
Draft guidelines on high-risk AI classification, 19 May 2026, annex on Annex III, paragraphs (319) to (321)
For the FRIA question point 5(c) counts twice: it makes the system high-risk and it makes you, as deployer, one of the parties Article 27 names. A public-law form or a public healthcare system in your Member State changes nothing there. Do not count on the fraud-detection exception from point 5(b) either: it does not apply here, and a fraud feature alongside risk assessment does not take the system out.
Weather simulation where machine learning approximates physical processes
A meteorological institute runs physics based weather models and uses machine learning to approximate complex atmospheric processes such as cloud microphysics and turbulence. The estimated values are then fed into the established physics model, which produces the actual forecast.
That your model can infer from input does not by itself bring it within the definition, since the guidelines justify excluding such accelerating systems precisely because they do not transcend basic data processing.
The historical average used as a prediction
An asset manager builds a simple baseline model that predicts future prices by always taking the historical average, in order to test whether a more advanced model genuinely adds value. A weather service does the same by predicting tomorrow's temperature using last week's average.
A simple baseline you place alongside a more advanced model falls outside the definition on its performance, but that verdict says nothing about the advanced model, which you must assess separately.
Three knowledge levels and internal role academies at an insurer
Generali offers all staff basic courses on what AI is and how the group uses it, intermediate modules for people who use AI systems daily, and advanced sessions with external experts for those who build or maintain them. On top of that it runs internal role academies for data scientists, actuaries and accountants, set up with universities and research institutes.
Attach layered AI training to an existing upskilling programme and learning platform, so you can extend levels and audiences without having to build a new learning infrastructure first.
Personalised advertising is not automatically prohibited manipulation
An advertiser uses AI to tailor ads to user preferences. The question is whether that touches the manipulation prohibition.
Personalisation stays outside the prohibition as long as it is transparent and respects free choice, so test your advertising technique against the GDPR, consumer law and the DSA rather than assuming advertising is always allowed.
Facial recognition company builds a database from social media
A software company runs an automated image scraper across the internet to detect images containing human faces on social media, stores them with source URL, geolocation and sometimes names, and converts the facial features into mathematical representations against which an uploaded photo can be matched.
Images published publicly on social media do not amount to consent, and the decisive point is targeting: untargeted collection for a database capable of matching faces stays prohibited even when done step by step.
AI literacy in recruitment and onboarding at an insurer
Gjensidige Forsikring gives all employees a mandatory e-learning as a baseline and builds role-based depth on top: analysts get model risk and data governance, claims handlers get training on the systems they operate themselves. Where relevant, AI literacy is checked during recruitment and training on AI systems is part of onboarding.
Decide whom you train using the wording the document quotes: Article 4 names your own staff as well as anyone using the systems on your behalf.
A webshop helpdesk chatbot must announce itself
A webshop runs an AI chatbot for questions about orders, delivery and returns. The bot writes fluent prose, carries a staff profile picture, and nowhere does it say that no human is reading along.
Do not count on the obviousness exception, because the more human your customer-facing bot looks, the more you must disclose its artificial nature at the first turn rather than only in the terms.
Application file handling at an educational institution
An educational institution uses AI for application file handling: indexing, searching, text and speech processing, translation of documents submitted with applications, and extracting, transforming and organising the collected data into a usable format.
Indexing, searching, translating and reorganising application files remains preparatory work, as long as the system leaves the substantive judgment on the application entirely to the institution.
Agriculture: AI system targeting land areas for chemical spraying
An AI system determines which areas of agricultural land are sprayed with chemicals. The intended purpose given to it by the provider is optimising the use of chemicals.
The Commission draft guidelines of 19 May 2026 address this case when determining whether AI as a safety component falls under the Annex I product legislation. The document is a consultation version: non-binding and not yet final.
Draft guidelines on high-risk AI classification, 19 May 2026, annex on Annex I and product legislation
Do not limit your failure analysis to the product itself but include the environment in which it operates, because people nearby help determine whether a malfunction creates danger.
Agriculture: AI for yield forecasting and irrigation optimisation
An AI system is integrated into a drone or robot and used for agronomic purposes such as yield forecasting or irrigation optimisation.
Record per application why a malfunction in your setup creates no danger, because the same agronomic function can become a safety component in a different product design.
System that checks a human decision or design and provides a substantially different solution
An AI system checks a decision, plan or construction made by a human and then provides a substantially different solution.
Ask whether your system refines or replaces the human work, because delivering a substantially different solution is not an improvement and rules out reliance on Article 6(3)(b).
Money laundering detection by an accounting firm under its own legal duty
An accounting firm deploys an AI system that detects money laundering, in order to comply with its own obligations under EU anti-money laundering legislation.
Check whether you are meeting your own legal duty or taking over a task from a public authority, because only in the second case do you act on its behalf and enter the law enforcement regime.
ATEX: AI system monitoring gas concentrations and commanding shutdown
Equipment for potentially explosive atmospheres contains an AI system intended to monitor gas concentrations and command shutdown when thresholds are exceeded.
Once you offer a system that monitors a dangerous value and itself commands an intervention, the safety function follows from your stated intended purpose, not from how reliably the system performs.
Chatbot answering factual questions from a benefits case handler
A chatbot answers a case handler's factual questions relating to the evaluation of a natural person's application for healthcare benefits, for instance the applicant's age. The case handler can grant or deny the benefits based on those answers.
A chatbot that only returns existing facts in structured form falls under the exemption, but once it answers case-specific legal questions it steers the decision and is high-risk.
Company creditworthiness based on corporate financials
A provider develops a system assessing the creditworthiness of companies by evaluating their company data, balance sheets and financial statements. In a variant, the owner of a legal entity is assessed to back a company loan.
Decide in advance whether natural persons form part of your intended purpose, because a system that also evaluates their personal finances falls within point 5(b) as a whole, regardless of its corporate focus.
Corporate creditworthiness based on balance sheets and financial statements
A provider develops an AI system that assesses the creditworthiness of companies using company data, balance sheets and financial statements. The situation where the owner of a legal entity is assessed as backing for a company loan is also addressed.
An assessment remains corporate as long as the credit accrues to the company, so even an owner backing a company loan does not turn your system into an evaluation of a natural person.
Credit score of a business owner based solely on business data
A provider develops an AI system that establishes the credit score of the owner of a small business or of a company that is not a legal entity. The system uses only business or company data.
Limit your system demonstrably to business data if you want to stay outside point 5(b), because the moment it also draws on the owner personal finances you are evaluating a natural person.
Customs risk assessment of goods at the external border
An AI system is used by customs authorities to assess the risk that goods entering the EU do not comply with legislation applicable at the border, based on information about the economic operators concerned, such as container number, description of goods, routing, transport and payment method.
Determine what your risk model actually targets, because if it concerns consignments and goods flows rather than personal aspects of individuals, there is no profiling to block the exemption.
AI helping candidates tailor their CV to a vacancy
The system analyses the candidate's CV together with the job description supplied by the candidate and recommends changes to increase the likelihood of being selected for an interview. Those recommendations are shared exclusively with the candidate.
Who initiates the tool decides the outcome here, because an aid started by the candidate whose results reach only the candidate falls outside the recruitment use case.
Flagging incomplete forms and returning them to the applicant
An AI system detects and flags incompletely filled-in forms so that they can be returned to the applicant to be completed correctly.
A flagging function that merely notes missing data and returns the form can be treated as a narrow procedural task, as long as it says nothing about the substance or quality of the application.
Gas appliances: AI optimising combustion efficiency
An AI system optimises combustion efficiency in a household gas appliance. The intended purpose is energy efficiency.
Whether an efficiency system is a safety component depends on the product design: if a malfunction can cause fire, explosion or carbon monoxide it counts, if it only raises the energy bill it does not.
Retrospective audit of hiring patterns on anonymised data
A system audits completed hiring decisions by analysing anonymised recruitment data, including CV scores, interview notes and hiring outcomes, using statistical modelling to detect potential bias or inconsistencies. It plays no role in ongoing recruitment and does not assess identified or identifiable recruiters or applicants.
Anonymise the data and keep the analysis entirely retrospective, and you can examine hiring patterns for bias without the system being treated as high-risk.
The system coordinates appointments with applicants by combining calendars and stated availability, proposes time slots based on logistical constraints such as time zones and maximum daily meetings, sends reminders, and processes accessibility needs such as sign language interpretation, extended interview duration or alternative communication formats.
Purely logistical support stays clear of the heavy obligations, provided your scheduling tool initiates or influences no assessment and merely processes accessibility needs in practical terms.
System that surfaces legal provisions and internal guidance for benefits decisions
An AI system is used in assessing data relevant to a decision, for example on public benefits, and provides the human operator with references to the relevant legal provisions, information on jurisdiction and possibly existing internal guidelines relevant to the decision-making process.
General references to legislation and internal guidance remain preparatory, but the moment your system analyses the concrete file or gives a case-specific recommendation you lose that qualification.
Lifts: AI system managing door closing timing and obstacle detection
An AI system in a lift manages door closing timing and obstacle detection. The intended purpose given to it by the provider is efficient lift operation, not safety.
Naming efficiency as the purpose leaves the second route open: if a malfunction could injure someone, the system still qualifies as a safety component, so your stated purpose is not the final answer.
Machinery: vision system detecting humans in a robot cell
An AI-based computer vision system detects human presence in a robot cell and triggers a safe stop or speed reduction. The intended purpose given to it by the provider is to prevent injury.
If your instructions for use, technical documentation or sales materials state that a system exists to prevent injury, you have yourself established that it performs a safety function.
Pattern analysis on completed eligibility checks in the public sector
An AI system analyses previously completed eligibility checks by public administrators to detect decision-making patterns or deviations, for quality assurance and reporting. It does not propose outcomes on live cases and does not evaluate the performance of staff members, for example in the annual appraisal.
Pattern analysis stays within the exemption as long as it runs afterwards, proposes no outcome in live cases and does not evaluate the performance of your own staff.
Pressure equipment: AI system predicting runaway pressure and actuating protection
An AI system in pressure equipment is intended to predict runaway pressure and actuate protective measures, for instance by triggering a shutdown linked to safety accessories.
A model that merely predicts still performs a safety function once that prediction actuates a protective measure, so assess what happens with the output and not only what the model calculates.
Writing assistant refining completed promotion evaluations
A consultancy firm uses an AI writing assistant to refine managers' promotion reports after evaluations are fully completed. Managers have already recorded the recommendation, justification and ratings; the system improves clarity of language, ensures consistency with corporate style and flags potentially biased wording, after which the manager is required to double-check the revised text.
Have the manager fully record the recommendation, justification and ratings first and restrict the system to wording and consistency, and it remains an after-the-fact improvement.
Quality assurance on finalised human work without replacing the judgment
Three kinds of auxiliary systems: systems that flag errors or contradictions in finalised human work as a quality-assurance function, systems that map conclusions to evidentiary records to strengthen the traceability of a decision without substituting human judgment, and systems that convert human-validated content for interoperability or accessibility purposes.
Keep your auxiliary system strictly after the human decision and without a view of its own on the outcome, and it remains an improvement that leaves the rights and position of those affected untouched.
Rail: AI system in a train monitoring speed limits
An AI system in a train is intended to monitor speed limits and to prevent collisions and derailments.
If you work in a sector with its own safety regime, note that only the definition in Article 3(14) of the AI Act counts, not the sectoral notion of safety component.
Deviation detection in recruitment that assesses the recruiters themselves
A system identifies deviations from previous recruitment decision-making patterns before recruitment is completed, to detect inconsistencies with corporate recruitment policy, while evaluating the personal characteristics of the recruiters conducting the interviews.
To keep the exemption, aim the deviation analysis solely at the decisions themselves rather than at the people who made them, and run it only after recruitment has been completed.
AI background checks producing applicant risk scores
The system aggregates official records, employment history, social network history and, where legally permissible, financial data, plus open-source information, and returns composite risk scores or categories such as low, medium and high risk with alerts such as unexplained employment gaps. In high-volume hiring, candidates flagged as high risk are deprioritised before a caseworker reviews the file.
Background checking with composite risk scores is profiling, and that rules out every exemption, even where you have formally built a human review into the process.
Deviation detection in recruitment that also evaluates the recruiters themselves
An AI system is used in the recruitment of employees. It identifies deviations from previous recruitment decision-making patterns to detect potential inconsistencies with corporate recruitment policies, and in doing so also evaluates the personal characteristics of the recruiters conducting the job interviews. The system runs before recruitment is completed.
A system detecting deviations in decision-making can fall under the exemption, but once it also weighs personal characteristics of your own staff there is profiling and that route closes.
Automated school assignment by municipalities
Municipalities or regional authorities automatically assign pupils to public schools based on structured data such as home address, school catchment boundaries and available capacity, also factoring in sibling attendance and parental status to keep families together or minimise commuting distance.
Even an assignment on seemingly objective data such as address and capacity counts as profiling here, so as a public body you cannot rely on the Article 6(3) exemption.
AI scoring and ranking applicant answers
A system evaluates written or oral responses given by job applicants in an online assessment, assigns a numerical score based on linguistic and substantive criteria, and generates a ranking used to determine who is invited to the interview stage.
Once your assessment turns answers into a score that decides who is invited to interview, the system performs a core evaluation and no exemption gets you out.
Smart thermostat optimising comfort and energy use
A smart thermostat covered by the radio equipment rules learns household routines and optimises temperature settings. The intended purpose is greater comfort and lower energy use.
Being a consumer or household product excludes nothing; substantiate that a malfunction leads at most to discomfort or a higher energy bill, and pay particular attention to children and vulnerable users.
Sorting school or university admission applications by level
An AI system sorts incoming applications for admission to a school or university by the grade or educational level applied for, placing them into predefined categories such as primary, secondary or specific grades, based on information supplied in the application.
Sorting on a datum the applicant supplied stays a narrow procedural task, provided your system passes no judgment on suitability and prepares no admission decision.
Toys: AI recommending music in a connected toy
An AI system in a connected toy makes music recommendations to the child playing with it.
Not every AI component inside a regulated product counts; where both a safety purpose and a hazardous failure consequence are absent, the component falls outside the notion of safety component and outside Article 6(1).
Toys: manufacturer opts for internal control based on standards
A toy manufacturer whose product contains an AI system as a safety component applies harmonised standards and thereby opts for a conformity assessment procedure without third-party involvement.
Opting for internal control based on harmonised standards without a third party changes your procedure but not the classification: the system remains high-risk and the accompanying obligations still apply.
An AI system for lane assistance in a vehicle. The intended purpose given to it by the provider is enhancement of the user experience.
On the failure route your own stated purpose carries little weight; support the assessment with system architecture, failure modes and their effects, because that is what will be examined.
Scanning visa files, filing them and marking duplicate attachments
A system in migration and border management scans each submitted visa file, converts scanned documents into text for indexing, automatically files items into fixed, predefined folders such as identity documents, travel itinerary, supporting evidence and translations, and detects exact duplicate attachments and marks them as duplicates.
Even where your file processing qualifies for the exemption, you must document the assessment beforehand and register the system, so the supervisory authority can check your choice at any time.
Scanning, indexing visa files and marking duplicate attachments
An AI system in the migration and border management context scans each submitted visa file, converts scanned documents into text for indexing, automatically files items into fixed predefined folders such as identity documents, travel itinerary, supporting evidence and translations, and detects exact duplicate attachments and marks them as duplicates.
Fix the boundaries of your file processing tightly, because the exemption falls away as soon as the system ranks items, labels them useful or less useful, hides them or suggests a next step.
Awareness that turns into a hard usage rule
INECO, a large Spanish engineering firm working for public authorities on rail, airports and digitalisation, ran over twenty AI trainings with more than four hundred participants in 2024 and set up an AI Master Classroom on the intranet with short modules, audio and subtitles. After making staff aware of data leakage risk, the organisation limited the use of public language models and moved to a secured chatbot solution.
Combine short online modules with real sessions, because the Commission describes the collected initiatives as a mix of e-learning platforms and in person trainings rather than one fixed format.
Internal AI assistant for trained staff needs no notice
An organisation makes an internal AI assistant available for HR, procurement, IT and compliance questions. It sits behind the company login only, and staff have been trained in using AI.
The exception rests on a closed and trained audience, so record who has access and what AI training they received, because once the assistant reaches beyond that circle the exemption falls away.
Credit advertising targeted at low-income postcodes
A financial services provider uses a predictive AI model to target advertising for predatory financial products at people living in low-income postcodes who are in dire financial straits.
Deliberately targeting proxy variables such as postcodes that coincide with a vulnerable socio-economic group counts as exploitation, while unintended bias only becomes exploitation once you know about it and fail to correct it.
Credit scoring and fraud detection at the same bank
A lender uses a model that gives individual applicants a score on which the acceptance decision rests. The same institution also runs a separate model that flags suspicious transactions for fraud investigation.
Assess each model separately against its own intended purpose, since a model scoring a natural person creditworthiness is high-risk while a model whose main intended use is fraud detection falls outside.
Credit scoring and telematics premiums remain permitted
A lender assesses creditworthiness on the basis of income, expenses and other financial and economic circumstances. An insurer raises the premium of a driver whose telematics data show persistent speeding.
Scoring is allowed where you use only data relevant to the purpose and the consequence stays proportionate, and sectoral rules prescribing which data count as relevant provide your strongest justification.
Light fine-tuning does not make you a model provider
A bank fine-tunes an existing general-purpose AI model on its own product documentation and customer questions, using a fraction of the original compute, and builds a customer chatbot around it that it offers under its own name.
If your fine-tuning stays well below one third of the original compute you do not become the model provider, but the obligations for the AI system you offer under your own name still apply.
Place-based predictive policing falls outside the prohibition
A police force uses an AI system that scores the likelihood of crime in different areas of a city, based on past crime rates per area, street maps and supporting information, to decide where to deploy more patrols.
Place-based prediction falls outside the prohibition, but only as long as the area score does not become an element in the profile of an individual, because that turns the assessment person-based.
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.
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.
Article 12(1) and (2), Article 19(1) and Article 26(6)
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.
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.
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.
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.
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.
Article 12(1) and (2)(c), Article 19(1) and Article 26(5) and (6)
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.
Model that stops learning after deployment
An insurer deploys a trained model that ranks claims by complexity. After deployment the model learns nothing new; the supplier retrains only periodically in a controlled release, so its behaviour is entirely stable between releases.
Self learning behaviour after deployment is optional and not a ground for exclusion, so a frozen model that stays entirely stable between releases does not escape the definition on that basis.
Modifying a systemic-risk model pulls the heaviest duties to you
A downstream actor modifies an existing systemic-risk model so substantially that the change exceeds the threshold, and publishes the result as its own model.
Where a modification of a systemic-risk model crosses the threshold, the result is presumed to have high-impact capabilities, so estimate the compute in advance and notify the Commission within two weeks.
A dedicated session on prohibited practices for the development team
In 2024 Mural ran a mandatory AI training for all staff with a 93 percent completion rate, and additionally organised a live interactive session for the AI team specifically on prohibited practices and high-risk categories. For that team the legal function built a visual mind map on a digital whiteboard, with templates and direct references to the provisions.
Two layers side by side: a baseline for everyone and a deeper session for the team that makes the choices. That second layer is where Article 4 earns its keep, because prohibited practices and high-risk categories are design questions rather than awareness questions. The completion rate is not a goal in itself, but it is the kind of figure that later lets you show the measure actually reached the organisation.
In-car navigation: lighter marking is enough
A car manufacturer builds a generative AI system into the navigation unit that composes spoken and written route instructions. The output stays inside the vehicle and technical measures prevent it from being exported or shared.
The lighter marking is conditional, because it holds only while technical measures demonstrably prevent the output from leaving the product, so document those measures before relying on this route.
Eye tracking in online exams versus emotion detection
An education institution uses eye tracking software during online exams to follow students' gaze point and eye movement, to detect whether unauthorised material is being used.
Measuring where someone looks is not emotion recognition, but the moment the same system infers a state such as arousal or anxiety it becomes prohibited, so bound the functionality explicitly.
Open source in name, but not within the meaning of the Regulation
Three providers call their model open source. The first licence allows non-commercial research only. The second requires a separate commercial licence once monthly active users pass a threshold. The third gives the model away for free but hosts it exclusively on its own platform where visitors are served paid advertisements.
A usage restriction is not automatically fatal: you may include specific, proportionate and non-discriminatory safety terms, whereas a monthly active user threshold or a separate commercial licence disqualifies the licence.
What the open-source exemption does and does not cover
A research group publishes a general-purpose AI model under a free and open-source licence and makes the weights, architecture and usage information publicly available. The model carries no systemic risk.
A free and open-source release without systemic risk lifts the technical documentation duties and the authorised representative, but the copyright policy and the public training-content summary continue to apply in full.
Machine learning that only speeds up an existing optimisation calculation
A grid operator uses a machine learning model to approximate parameters inside a classical optimisation calculation built on linear and logistic regression. The model changes nothing about the decision rules themselves, it only makes a long established calculation method faster and cheaper.
If your model only makes a long established calculation method faster and leaves the decision rules untouched, record both points, because they are what carries the conclusion that you fall outside the definition.
Police fine-tuning a model for investigations: settle the role question first
A police service fine-tunes an open general-purpose model on its own files from ongoing criminal investigations, so that detectives can see links between suspects and cases sooner. The fine-tuned model stays inside the service and is not made available to anyone else. The question is whether the service thereby becomes a provider of a general-purpose AI model itself, and so falls under Article 53.
Article 53(1) requires providers of general-purpose AI models to do four things: draw up and keep up-to-date the technical documentation of the model, including its training and testing process and the results of its evaluation, containing at a minimum the information set out in Annex XI so that it can be provided on request to the AI Office and the national competent authorities; draw up, keep up-to-date and make available information and documentation to providers of AI systems who intend to integrate the model, containing at a minimum the elements set out in Annex XII; put in place a policy to comply with Union law on copyright and related rights; and draw up and make publicly available a sufficiently detailed summary about the content used for training, according to a template provided by the AI Office. Article 53(2) provides that the obligations under points (a) and (b) do not apply to providers of models released under a free and open-source licence that allows for the access, usage, modification and distribution of the model, and whose parameters, including the weights, the information on the model architecture and the information on model usage, are made publicly available, and that this exception does not apply to general-purpose AI models with systemic risks.
Start with your role, because merely using someone else's model does not by itself make you a model provider; Article 53 does not say at what point a service that fine-tunes crosses that line, and the point deserves an explicit answer rather than an assumption. A further question comes before Article 53: whether your fine-tuned investigation model has been placed on the market within the meaning of the Regulation. That it never leaves the service does not settle this on its own, since the Commission's guidelines on the scope of the obligations for providers of general-purpose AI models also treat internal use affecting the rights of natural persons as placing on the market. We read paragraph 2 as attaching the open-source exception to your own model rather than carrying it over automatically from the model you started out with: if you do not publish the weights and architecture of the fine-tuned model, which is the obvious course in criminal matters, then on that reading the exception is not open to you, and the duties under points (c) and (d) remain in place in any event, since paragraph 2 lifts only points (a) and (b). So record, version by version, exactly what you changed, on which data and to what end, because that record is what decides whether you stand here as a user or as a provider.
Assessing staff: signals from the workplace flowing back to the provider
A provider supplies a system that summarises employee performance data and supports HR in promotion decisions. After a year in use, departments turn out to apply it differently than intended, and managers factor the outputs into the performance review. The question is what the provider is supposed to know about that.
Article 72(1) requires providers to establish and document a post-market monitoring system in a manner proportionate to the nature of the AI technologies and the risks of the high-risk AI system. Article 72(2) requires that system to actively and systematically collect, document and analyse relevant data, which may be provided by deployers or collected through other sources, on performance throughout the system's lifetime, allowing the provider to evaluate continuous compliance with the requirements set out in Chapter III, Section 2. Article 72(3) provides that the system is based on a plan forming part of the technical documentation referred to in Annex IV, and instructs the Commission to adopt an implementing act laying down detailed provisions establishing a template for that plan and the list of elements to be included in it; the Regulation sets 2 February 2026 as the date for that act.
Our reading is that use which departs from what was intended is exactly the kind of real-world data paragraph 2 has in mind, because it bears on the human oversight and the intended purpose laid down in Section 2. Paragraph 3 points to a Commission template for which the Regulation sets 2 February 2026 as the date; check whether that template has since been adopted and align with it if so, since paragraph 4 refers to it as well. In the meantime we would not put the design of your monitoring on hold for it: which data you need already follows from the requirements the system must continue to meet. Agree with the organisations using the system on the route by which employee complaints and deviations in assessments reach you.
Proctoring during exams: which real-world data the institution reports back
A vendor offers proctoring software that flags possible cheating during exams. Several universities of applied sciences use the system, each with its own assessment formats and its own student populations. The vendor wants to know which real-world data it must keep collecting after roll-out, and from whom.
Article 72(1) requires providers to establish and document a post-market monitoring system, proportionate to the nature of the AI technologies and the risks of the system. Article 72(2) provides that this system actively and systematically collects, documents and analyses relevant data which may be provided by deployers or collected through other sources on the performance of high-risk AI systems throughout their lifetime, and which allow the provider to evaluate the continuous compliance of those systems with the requirements set out in Chapter III, Section 2. Where relevant, monitoring includes an analysis of the interaction with other AI systems. Article 72(3) provides that the system is based on a plan forming part of the technical documentation referred to in Annex IV.
The duty sits with the provider, but the useful signals arise in education itself: unfounded suspicions, student complaints, differences between programmes and assessment formats. Our reading is that paragraph 2 allows deployers to supply that data while leaving the duty to collect and analyse it with the provider. What the article does not settle is the route by which the data reaches you, or whether the institutions are bound to supply it; that is something you have to arrange with them and cannot read out of Article 72. We would therefore fix that route before the system goes live, and would also set out in the plan how you break performance down by assessment format and by group, since an average across all schools hides precisely the pattern you are looking for.
Safety component on the production line: the manufacturer keeps watching after delivery
A manufacturer supplies an AI safety component that halts machinery on a production line as soon as someone comes too close to the robot. The component already falls under product legislation for machinery, and the manufacturer runs quality control and incident follow-up for it. The question is what Article 72 adds on top of that.
Article 72(1) requires providers to establish and document a post-market monitoring system in a manner proportionate to the nature of the AI technologies and the risks of the high-risk AI system. Article 72(3) provides that this system is based on a post-market monitoring plan, and that the plan forms part of the technical documentation referred to in Annex IV. Article 72(4) gives providers of high-risk AI systems covered by the Union harmonisation legislation listed in Section A of Annex I, where a post-market monitoring system and plan are already established under that legislation, the choice of integrating the necessary elements described in paragraphs 1, 2 and 3 into those systems and plans, using the template referred to in paragraph 3, provided this achieves an equivalent level of protection.
Our reading is that Article 72 does not force a second, separate monitoring structure here: paragraph 4 gives you the choice of housing the elements in the system and plan you already run under product legislation, using the template from paragraph 3 and as long as the level of protection remains equivalent. That route stands or falls on a question the article does not answer for you: does the applicable product legislation genuinely have an established post-market monitoring system and plan, or do you run quality control and incident follow-up that were never established as such. Beyond that, you need to be able to show that the signals coming off the factory floor genuinely speak to continued compliance with the high-risk AI requirements, and not only to the mechanical safety of the machine. We would therefore record, for each production signal, which requirement it touches, so that integration does not become dilution.
Proctoring software during an online exam
A university of applied sciences uses software during online exams that flags possible cheating from webcam images and mouse movement. A flag triggers an automatic notification to the exam board.
With proctoring software the timing decides: live monitoring during a graded test falls under point 3(d), while checking submitted work afterwards stays outside that use case.
Proctoring during an exam overshoots: from signal to reporting duty
A university of applied sciences uses proctoring software during an online exam and finds that a group of students is systematically and wrongly flagged as suspicious, after which grades were withdrawn. Teaching staff and the examination board want to know whether this pattern is a serious incident and, if so, who has to report it and within what time.
Article 3, point (49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to, among other things, the infringement of obligations under Union law intended to protect fundamental rights. Article 73(1) obliges the provider of a high-risk AI system placed on the Union market to report serious incidents to the market surveillance authorities of the Member State where the incident occurred. Article 73(2) requires the report to be made immediately after the provider has established the causal link or the reasonable likelihood of such a link, and in any event no later than 15 days after the provider or, where applicable, the deployer becomes aware of the serious incident. Article 73(5) allows an initial, incomplete report followed by a complete report where this is necessary to ensure timely reporting. Article 73(7) provides that upon receiving a report concerning a serious incident as referred to in Article 3, point (49)(c), the market surveillance authority informs the national public authorities or bodies referred to in Article 77(1). Article 26(5) requires a deployer that has identified a serious incident to inform, immediately, first the provider and then the importer or distributor and the relevant market surveillance authorities.
Article 3(49), Article 26(5) and Article 73(1), (2), (5) and (7)
We read Article 73 as meaning that an incident in education is rarely a single dramatic moment: the signal sits in the pattern in exam results, and the institution sees that pattern before the software supplier does. Whether that pattern amounts to a serious incident is a separate question: it turns on whether the wrongful flagging and the withdrawal of grades count as an infringement of obligations protecting fundamental rights within the meaning of Article 3, point (49)(c), and Article 73 does not make that assessment for you. Leaving the question open until your own investigation is finished carries a risk, because the Article 73(2) period runs from awareness. Set up your examination and complaints process so that such a pattern reaches the provider within days; Article 26(5) also puts a notification duty on the institution itself as deployer, towards the provider, the importer or distributor and the market surveillance authority. The initial, incomplete report of Article 73(5) is the pressure valve here; waiting for a finished investigation report is not.
Live facial recognition at a football stadium
Police install a van with mobile cameras and live facial recognition at the main entrance of a stadium during a European Championship match. The watchlist covers people suspected of offences ranging from serious crime to fraud and burglary, plus people of possible intelligence interest and vulnerable persons with mental health issues. There is no information linking a specific person to this event.
A watchlist that mixes different kinds of suspicion and is not tied to the specific event is too unspecific, and the presence of one person for whom deployment would be allowed does not legitimise the whole operation.
Reoffending risk assessment at a police force
A police force uses a model that estimates, per suspect, the likelihood of committing another offence, based on the case file and previously established behaviour. That outcome feeds into the prioritisation of ongoing investigations.
Record which verifiable facts your risk assessment rests on, because an assessment tied to established involvement in a criminal offence is high-risk, whereas one resting solely on profiling is prohibited.
Satellite network allocating bandwidth with a predictive model
A satellite operator allocates power and bandwidth across transponders using a machine learning model that predicts network traffic, because classical optimisation struggles with demand that varies sharply by region and by moment. Performance is comparable to established methods in the field.
Automatic self-adjustment need not bring your system within the definition where it mainly improves computational performance, although the guidelines say only that such systems may be excluded under those conditions.
Satirical deep fake of a politician: lighter, not exempt
A satirical outlet publishes an AI-manipulated image of an existing politician, placed in a scene that humorously criticises a policy decision. Style and context make it immediately clear that this is satire.
Satire only lightens the form of the disclosure and not the duty itself, so make sure the satirical character is evident to your audience and respect the rights of the person depicted.
Chess program using minimax and heuristic evaluation
A software company releases a chess program that assesses board positions using a minimax algorithm with heuristic evaluation functions. The program has never learned from game data; it applies pre-programmed rules and search strategies to find a strong move.
That your system never learned from data does not settle the question, because the guidelines also count logic and knowledge based approaches as AI techniques and do not tie the definition to a chosen technique.
Security monitoring by a SaaS company: cybersecurity alone is not a safety component
A software company supplies a SaaS platform that monitors network traffic at an operator of critical digital infrastructure and reports anomalous patterns to that customer's security team. Its developers see that use at such an operator may fall under point 2 of Annex III and wonder whether their own product therefore becomes a high-risk AI system.
The Commission draft guidelines of 19 May 2026 state that point 2 of Annex III lists AI systems intended to be used as safety components in the management and operation of, among other things, critical digital infrastructure, and that Recital 55 draws a clear distinction between a safety component and a cybersecurity component. To fall within point 2, an AI system must not be used solely for cybersecurity purposes; without a direct safety role it cannot be a safety component in critical infrastructure and therefore cannot be classified as high-risk under Article 6(2). As examples of systems used solely for cybersecurity and thus falling outside point 2, they list an AI honeypot that identifies and neutralises cyber threats in real time, technology that actively engages with potential attackers to learn new attack patterns, a system supporting the detection of unauthorised access, and a system that detects suspicious email addresses and identifies stolen data. They add that an AI system is classified as a safety component in critical infrastructure only where it is used by an entity identified as a critical entity by a Member State under the CER Directive, and that this interpretation does not require that status to be disclosed to a third-party provider. The document is a consultation version: non-binding and not yet final.
Draft guidelines on the classification of high-risk AI systems, 19 May 2026, annex on Annex III, paragraphs (187), (188), (190) and (191)
We read this passage as a line drawn function by function rather than customer by customer: the fact that your client operates critical digital infrastructure does not by itself turn your monitoring product into a safety component. What we cannot settle from the text is where mere flagging ends and a safety function begins, because the same guidelines also count monitoring and detecting situations that may directly lead to physical harm among the safety functions. The open question is therefore whether your SaaS platform stands apart from the systems that drive physical control, or in practice becomes part of them. So record, per product function, what the system performs and what it expressly leaves to the operator, because that distinction carries your entire classification and is hard to reconstruct after the fact.
Role profiles and a kick-off session per AI project at a public sector IT provider
Smals, which supplies IT to Belgian public administrations, describes the knowledge each role needs: all staff know capabilities, limits and internal guidelines, AI ambassadors spot and prioritise use cases, AI experts know governance and technique, and legal staff and the data protection officer get separate deep dives. Before every new AI project there is also a session for all stakeholders on the capabilities, limits, risks and governance of that specific system.
In the repository, first look for practices from organisations that resemble yours in sector, size and role as provider or deployer, before choosing a setup for your own staff.
An organisation adopts an email filter that was trained during its building phase on a set of messages humans labelled as spam or not spam. Once in use, the filter independently assesses new incoming email and classifies it based on the patterns it learned.
A recognisable learning pattern in your system yields no ready made qualification, because the guidelines ask you to assess the specific architecture and functionality against all seven elements of Article 3(1).
Spell checking needs no marking, an AI summary does
A publisher uses the same AI tool for two things: correcting spelling and cleaning up formatting in submitted pieces, and producing summaries and rewrites of those same pieces.
The exception attaches to the function and not to the tool, so assess per use whether meaning, style or structure changes and mark only the outputs where it does.
Static estimation of resolution time and daily sales
A service desk shows customers an expected resolution time calculated as the mean from historical tickets. A retail chain uses a trivial predictor to estimate how many units of a product it will sell each day, as a starting point for purchasing planning.
Keep testing whether your estimate really does no more than return an average, because as soon as you build in more complex relationships you lose the basis for this exception.
A synthetic avatar of your own CEO is a deep fake
A company has a realistic synthetic avatar of its own CEO deliver a new year message thanking employees for last year's results. The video goes to the intranet and to the company's social media channels.
Consent from the executive depicted and a benign purpose are irrelevant because the test is objective, so apply a visible or audible label to the video before it is distributed.
Admission system at a higher education institution: who registers in the EU database
A higher education institution procures an AI system that organises student applications and enrolment and produces an admission recommendation for each candidate in its vocational programmes. The supplier says it handles the conformity assessment itself and affixes the CE marking. What is left unresolved is whether the institution still has a step of its own to take before the system goes into use in its teaching.
Article 43(2) provides that for high-risk AI systems referred to in points 2 to 8 of Annex III, providers follow the conformity assessment procedure based on internal control set out in Annex VI, which does not provide for the involvement of a notified body. Article 47(1) requires the provider to draw up, for each high-risk AI system, a written machine-readable, physical or electronically signed EU declaration of conformity and to keep it at the disposal of the national competent authorities for ten years after the system has been placed on the market or put into service. Article 49(1) requires the provider or, where applicable, the authorised representative to register themselves and their system in the EU database referred to in Article 71 before an Annex III high-risk system is placed on the market or put into service, with the exception of the systems listed in point 2 of Annex III. Article 49(3) provides that deployers that are public authorities or Union institutions, bodies, offices or agencies, or persons acting on their behalf, register themselves, select the system and register its use in that same database before putting such a system into service or using it, again with the exception of the systems listed in point 2 of Annex III.
Article 43(2), Article 47(1) and Article 49(1) and (3)
We read Article 49 as two separate registrations: paragraph 1 covers the provider and its system, paragraph 3 covers your own use, and on that reading the first does not relieve you of the second. The hinge question for the institution is therefore not whether the supplier does its job, but whether it is a public authority within the meaning of paragraph 3. The Regulation does not define that term, and until that is settled it remains open whether the institution must itself appear in the EU database. In practice we would move the request for the EU declaration of conformity and the registration number into the procurement stage, so that the question does not turn into a blocker just before an application period opens.
Emergency triage system: two routes to high risk
A hospital uses AI to prioritise incoming patients at the emergency department. The question is not whether the system is high-risk but by which route: as a medical device under product legislation, or directly under Annex III.
The Commission draft guidelines of 19 May 2026 state that an emergency healthcare patient triage system may qualify as a medical device; where it then meets Article 6(1), it is high-risk via Annex I and sectoral rules apply. A triage system that is not a medical device is high-risk via Article 6(2) and point 5(d) of Annex III. The document is a consultation version: non-binding and not yet final.
Draft guidelines on high-risk AI classification, 19 May 2026, annex on Annex III, paragraphs (334) and (335)
First establish whether your triage system is a medical device, because that question decides the whole route: via Annex I the assessment travels with the medical conformity assessment and its date, via Annex III the separate timeline of Article 6(2) applies. Either way the outcome is high-risk, so postponing that determination only creates uncertainty about which regime to set up.
Two AI systems at one grid operator, two regimes
A grid operator uses an AI model that automatically balances load and disconnects parts of the electricity network to prevent outages. The same organisation also runs a chatbot that helps customers with billing questions.
Map your AI function by function rather than organisation-wide, because only systems that directly protect the physical integrity of the infrastructure are safety components, while supportive and customer-facing tools fall outside.
Sales dashboard that summarises but recommends nothing
A commercial team uses reporting software that applies statistical methods to calculate total sales, average sales per region and trends over time, and displays them in charts. The dashboard makes no suggestion about how to improve sales or which products to promote.
If your dashboard did start making suggestions, that alone would not turn it into an AI system, since the guidelines state that non-AI systems can generate recommendations as well.
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.
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.
Well-being chatbot pushes users toward dangerous behaviour
A provider markets an AI chatbot meant to help users maintain a healthy lifestyle, with tailored advice on exercise and mental rest. In practice the chatbot exploits individual vulnerabilities and pushes people into dangerous habits, such as excessive sport without rest or water.
Good intentions offer no protection: once a system can foreseeably push users toward serious harm and no preventive or mitigating measures were taken, the prohibition applies even without intent.
No mandatory course format, no certificate, no exam and no AI officer
Article 4 prescribes no form. The Commission confirms that no certificate is required, no obligation to measure knowledge exists, no training is mandatory and no governance structure is prescribed.
Applies to providers and deployers of AI systems, who take measures to support AI literacy among their staff and other persons dealing with the operation and use of AI systems on their behalf.
For deployers of high-risk AI systems, a separate obligation under Article 26 will apply in addition, requiring them to ensure that staff working with the system are sufficiently trained to handle it and ensure human oversight. That duty goes beyond Article 4, but it does not apply yet: it becomes applicable on 2 December 2027 for standalone high-risk systems under Annex III and on 2 August 2028 for high-risk systems embedded in products under Annex I.
The Commission Q&A on AI literacy states that there is no one size fits all when it comes to AI literacy and that no strict requirements or mandatory trainings are imposed. On certification, the Q&A states literally that there is no need for a certificate and that organisations can keep an internal record of trainings or other guiding initiatives. On assessment, it states that Article 4 of the AI Act does not entail an obligation to measure the AI knowledge of employees. On governance, it states that no specific governance structure is mandated to comply with Article 4, so that unlike the data protection officer under the GDPR, no AI officer needs to be appointed. On the level, the Q&A states that following the Digital Omnibus amendment AI literacy remains an obligation for providers and deployers of AI systems, but that no specific or sufficient level is mandated and that the Regulation does not require guaranteeing any specific level of AI literacy of any individual. Against that, the Q&A states that simply relying on the AI systems' instructions for use or asking staff to read them might be ineffective, and that organisations should take into account general AI understanding within the organisation, whether they are a provider or a deployer, the risks associated with the systems deployed, staff knowledge gaps considering technical knowledge, experience, education and training, and contextual factors such as sector, purpose and affected populations. The Q&A further states that organisations may implement different levels of training or learning approaches depending on knowledge, experience, education and role, and that staff with a degree or experience in AI development are normally considered AI literate, while the organisation must still verify that those persons understand the specific AI systems of the organisation, know how to deal with them and are aware of all risks.
Commission Q&A on AI literacy, sections on required level, training formats, certificates, assessment of knowledge and governance structures (consulted 9 August 2026)
This guidance cuts both ways and both are abused. The supply side of the market sells certificates and exams as a legal requirement: that is demonstrably wrong, because the Commission states literally that no certificate is needed and that there is no obligation to measure knowledge. The other side is the organisation that concludes from the same answer that nothing is required. That is equally wrong. In the same Q&A the Commission says that merely forwarding the instructions for use might be ineffective, and it expects a reasoned choice based on your role, your risks and your people's knowledge gaps. The correct reading is therefore: no prescribed format, but a demonstrable measure. That makes the internal record named in the Q&A the practical heart of your file. And note the nuance about technical staff: a data scientist is not automatically done, because the organisation must still verify that this person knows its own systems and the associated risks.
Stop steering on certificates and steer on a demonstrable, reasoned measure. Record what you did, for which groups, why that format fits their role and the risks of the systems they use, and keep a simple internal record as the Q&A suggests. Differentiate by role rather than giving everyone the same module, and include your technical staff with a specific component on your own systems and risks. Replace the mere forwarding of instructions for use with something that is demonstrably read and understood.
Article 4 reaches beyond your own staff, and the national supervisor enforces it
The duty to take measures also covers contractors, service providers and sometimes clients. Supervision lies not with the AI Office but with national market surveillance authorities, enforcing since 2 August 2026.
Applies regardless of place of establishment, as long as the AI system is placed on the Union market, used in the Union, or its use has an impact on people located in the Union.
The Commission Q&A on AI literacy states that Article 4 applies to providers and deployers of AI systems and in addition to other persons dealing with the operation and use of AI systems on their behalf, covering persons broadly within the organisational remit, with a contractor, a service provider and a client given as examples. On clients, the Q&A states that they may need AI literacy depending on the specific risk, reasoning that affected persons should understand how decisions taken with the assistance of AI will have an impact on them. On geographic scope, the Q&A states that the AI Act's legal framework applies to both public and private actors inside and outside the EU as long as the AI system is placed on the Union market, used in the Union, or its use has an impact on people located in the EU. On supervision, the Q&A states that the supervision and enforcement of Article 4 is not with the AI Office but under the remit of national market surveillance authorities, and that supervision and enforcement began on 2 August 2026, while Article 4 itself entered into application on 2 February 2025. On sanctions, the Q&A states that national market surveillance authorities could impose penalties and other enforcement measures for infringements of Article 4, that this will be based on national laws that Member States were due to adopt by 2 August 2025, that any sanction must be proportionate and based on the individual case taking into account factors such as the nature and gravity of the infringement and its intentional or negligent character, and that sanctions are more likely if there is proof of an incident due to a lack of appropriate training and guidance. Article 4 is not listed in the enumeration in Article 99(4) of the AI Act, which covers only Articles 16, 22, 23, 24, 26, 31, 33(1), (3) and (4), 34 and 50, so the level of any penalty for Article 4 follows from national law rather than from the Regulation's own ceilings. The Q&A further states that Article 4 reinforces the transparency provisions of Article 13 and the human oversight provisions of Article 14 and indirectly contributes to the protection of affected persons, and that for deployers of high-risk systems the Article 26 obligation to ensure staff are trained to ensure human oversight is a distinct requirement; that requirement becomes applicable on 2 December 2027 for standalone Annex III systems and on 2 August 2028 for Annex I systems.
Commission Q&A on AI literacy, sections on target groups, geographic scope, supervision and enforcement, and sanctions (consulted 9 August 2026)
Two things are consistently underestimated here. The first is the circle of people. Many organisations translate Article 4 into a staff programme and forget the seconded workers, the call centre, the implementation agency and the freelancers who use the same systems daily. The Q&A expressly widens that circle to everyone within the organisational remit, and even leaves the door open to clients where the risk calls for it. The second is who will come knocking. Because the AI Office gets all the attention, organisations assume Article 4 is a Brussels file. It is not: this runs through the national market surveillance authority. The most useful sentence for your own prioritisation is that a sanction is more likely where there is proof of an incident caused by a lack of appropriate training and guidance. Enforcement will therefore rarely start with a spot check on your training plan, and far more often with an incident after which the question becomes whether the person involved was prepared. That makes the file reactively useful, and therefore worth having in order now.
Extend your target list from permanent staff to everyone working with your AI systems under your direction, including contingent workers, contractors and implementation partners, and write that expectation into your procurement and hiring terms. Assess per system whether clients or affected persons also need an explanation of how AI-assisted decisions affect them. Structure your records so that after an incident you can show within a day which measures the person involved had received and when. Finally, establish which national market surveillance authority is competent for you, because that is your counterpart, not the AI Office.
AI agents must disclose both their AI nature and on whose behalf they act
An AI agent that makes bookings, handles correspondence or concludes contracts must identify itself as AI and state on whose behalf it is acting, including towards the person instructing it.
Applies as soon as the agent is capable of interacting with the person instructing it or with other natural persons in the execution of the task.
Purely machine-to-machine communication between agents whose outputs are not intended to reach a natural person falls outside the disclosure duty of Article 50(1), and intermediate reasoning steps and non-perceptible actions fall outside the marking duty of Article 50(2).
Point (31) of the guidelines of 20 July 2026 states that AI agents are covered by Article 50(1) if they are capable of interacting with the persons instructing them or with other natural persons in the execution of their tasks, citing as examples making bookings, managing correspondence, negotiating or concluding contracts and executing purchases. That same point requires AI agents to be designed and developed so that they disclose both their artificial nature and the person on whose behalf they are acting, given the need for transparency of the origin and of the delegation of authority and accountability for the consequences of their actions. This also applies in complex multi-agent architectures in which other agents interact directly with natural persons. Where the provider cannot reliably determine before placing on the market or putting into service whether the agent will directly interact with a natural person, the agent should be designed at the architecture level and instructed to disclose itself in every situation where it is reasonably likely to interact with a natural person, including where that person represents a legal entity. Agents should also disclose themselves to the persons instructing them at key steps such as authorisation, reporting and validation, including where the agent receives, processes or relies upon outputs generated by other AI systems rather than by a natural person, and at every new interaction. Point (63) adds that Article 50(2) may apply to AI agents where the agent takes an action whose output is AI-generated or manipulated content perceptible by natural persons, while intermediate processing steps such as reasoning and chain of thought and non-perceptible actions such as a web request or browser action fall outside that scope.
Commission Guidelines C(2026) 5054 final, Section 3.1.1 point (31) and Section 4.1.2 point (63)
Here the guidelines go further than most organisations expect. The obligation is twofold: not only 'I am AI', but also 'I act on behalf of this party'. That turns agentic email, procurement and negotiation into a design question rather than a line in a footer. Two things are systematically missed. First, the disclosure duty also runs towards your own instructing party, at key steps such as authorisation and validation, and particularly where the agent builds on outputs from other AI systems rather than on human input. Second, the provider's uncertainty resolves nothing: if the provider cannot determine in advance whether the agent will reach a human, the answer is not 'then it does not apply' but 'then you build the disclosure into the architecture by default'. An agent that stays quiet until it is certain a human is reading is not what is intended.
Treat your agent's disclosure as an architecture requirement, not a prompt instruction that can be overridden per task. Ensure every outbound channel of the agent, meaning email, chat, telephony and forms, carries both the AI origin and the instructing organisation by default. Also build confirmation moments towards your own user at authorisation, reporting and validation, and flag explicitly there when the agent is building on output from another AI system. Finally, mark the perceptible content the agent produces in line with Article 50(2), but not the internal reasoning steps.
Artistic or satirical work is not exempt but attenuated, and the informative character always prevails
For deep fakes in evidently artistic, creative, satirical or fictional work, the disclosure must not hamper the work, but it remains mandatory. Where the content mixes in an informative or commercial character, the standard label applies.
The deep fake must evidently form part of an artistic, creative, satirical, fictional or analogous work or programme, assessed case by case by the deployer.
Where content combines multiple characters, the informative character always prevails and the standard labelling requirements apply; content that is exclusively informative or commercial and recognisable as such, such as news reporting, falls outside the lighter regime.
Point (119) of the guidelines of 20 July 2026 describes an attenuated transparency obligation for deep fakes forming part of evidently artistic, creative, satirical, fictional or analogous works or programmes, where the obligation is limited to disclosure in an appropriate manner that does not hamper the display or enjoyment of the work. Point (120) describes the categories: artistic works are created for the purpose of art, including music, cinematographic works and visual arts; creative works involve creative choices, while works mainly motivated by functional or technical considerations cannot be regarded as creative; satirical works are intended to criticise society, politics, business or public figures through humoristic techniques; fictional works involve persons, objects, places, entities or events in an imaginary but verisimilitude setting; analogous works share core traits with those categories without fitting neatly into one. Point (122) states that it must be evident to the natural persons exposed to it that the content falls within one of those categories, that the categories must therefore be interpreted strictly given the lighter disclosure regime and the interests of freedom of expression and freedom of the arts and sciences, and that content whose nature is potentially unclear or ambiguous to the audience falls outside this lighter regime. Relevant factors, per that same point, are whether the content displays formats or styles characteristic of the category, the context in which it is presented, and audience expectations. That same point excludes content whose nature is exclusively informative or commercial and recognisable as such, citing news reporting, notes that advertisements or documentaries may be regarded as evidently creative or fictional in certain specific situations but not in others because the assessment is case-specific, and states that where the deep fake combines multiple characters, for example informative and creative, the informative character should always prevail and the standard labelling requirements apply. Point (123) stresses that these deep fakes are not excluded from the obligation: the deployer must still disclose the AI origin or manipulation, but may do so in an appropriate manner, and must in any case comply with Article 50(5). Point (124) states that reliance on the attenuated obligation cannot justify failing to respect the fundamental rights of individuals or the rights of rightsholders under Union intellectual property or data protection law. As examples within the categories the document cites movies featuring AI de-aged existing actors or digital replicas of deceased actors, AI-generated music in the style of existing artists, and an AI-manipulated image of an existing politician in a scene clearly meant as humorous criticism. Outside the categories the document places among others an AI-manipulated video in the style of a teleshopping channel, AI-generated images of celebrities implying involvement in activities that never happened, and an AI-manipulated video featuring a realistic synthetic influencer focused solely on displaying a sponsored product's functionalities.
Commission Guidelines C(2026) 5054 final, Section 6.1.3, points (119) to (124) and the accompanying example lists
Two misconceptions dominate here. The first is that 'creative work' is an exemption. It is not: you must still disclose, only in a way that does not ruin the work, for example in the credits, in an accompanying notice, or at the start of the video rather than as a permanent block across the image. The second misconception is more serious and hits marketing directly. Advertising is not automatically creative work. The guidelines cite teleshopping-style videos and synthetic influencers demonstrating a product precisely as examples falling outside the category, and further state that where characters mix, the informative one always prevails. So anyone making a funny, clearly stylised campaign that also carries a product claim falls back on the standard label. Finally, note the evidence requirement: if the audience could doubt whether it is seeing satire or real news, it is by definition not evident and the lighter regime does not apply.
Assess per production whether the work is unmistakably artistic, satirical or fictional for your audience, and briefly record that assessment against the three factors in point (122): stylistic features, publication context and audience expectation. For campaigns and commercial video, default to the standard label and rely on the lighter regime only in rare cases. For evidently creative work, choose a disclosure that leaves the work intact, for example at the start or in the credits, bearing in mind that the information must be clear and distinguishable and that people joining later must also be able to perceive it.
Signing the code of practice is voluntary, but not signing means proving it yourself
Signing the code of practice on transparency of AI-generated content is voluntary and not signing is not in itself non-compliance. Those who do not sign must demonstrate compliance by other means, including a gap analysis against the code.
Applies to providers and deployers of generative AI systems within the scope of Article 50(2) and (4).
The Commission Q&A on signing the Code of Practice on Transparency of AI-generated Content states that signing is voluntary and that not signing does not constitute non-compliance with the AI Act. That same Q&A states that the code has two sections, one for providers on marking AI-generated or manipulated content in machine-readable formats and the related detection mechanisms, and one for deployers on the disclosure and labelling of deep fakes and of certain AI-generated or manipulated text on matters of public interest. It further states that signatories may, subject to a positive assessment by the Commission and the AI Board, rely on the code to demonstrate compliance with their obligations under Article 50 regardless of their place of establishment, and that the deadline for inclusion in the initial list of signatories was 27 July 2026 at 18:00 CEST, with later signature remaining possible but not appearing on that initial list. The Commission guidelines of 20 July 2026 state in point (146) that providers and deployers within the scope of Article 50(2) and (4) may demonstrate compliance by adhering to a code of practice assessed as adequate under Article 50(7), and that such a code does not replace the Regulation or the guidelines but complements them as the only Union-wide recognised practical framework for that purpose. Point (147) states that compliance may also be demonstrated through other adequate means, that for signatories supervisory activities will focus on whether they have adhered to the code and implemented the measures it contains, and that opting out of sections results in losing the benefit of facilitated demonstration of compliance for that part. Point (148) states that non-signatories are expected to demonstrate through other adequate means how they comply with Article 50(2), (4) and (5) and to explain how their measures ensure compliance, for instance by carrying out a gap analysis comparing their measures with those set out in a code assessed as adequate, and that they will likely face more requests for information and for access. Point (149) states that competent authorities may take commitments implemented in line with a code assessed as adequate into account as a mitigating factor when setting the amount of fines. Point (150) states that if a code is not deemed adequate, the Commission may adopt an implementing act specifying common rules for the implementation of Article 50(2), (4) and (5).
Commission Guidelines C(2026) 5054 final, Section 8.1, points (146) to (150); Commission Q&A on signing the Code of Practice on Transparency of AI-generated Content (consulted 9 August 2026)
The voluntariness is real, but it is not free. The guidelines shift the burden of proof: signatories are assessed on whether they do what the code says, non-signatories must explain why their own approach suffices. That difference translates into work. Point (148) expects non-signatories to run a gap analysis against the code, which means you have to read the code and benchmark your measures against it either way. Not signing therefore saves you the signature, not the substance. On the other side, point (149) explicitly names adherence in line with the code as a mitigating factor for fines, which makes the code commercially interesting for parties producing large volumes of generated content. Finally, note the opt-out rule: partial signature is possible, but for the sections you skip you fall back into the heavier evidential position. For anyone who missed the initial list, signature remains open; only the listing on that first list has passed.
Decide deliberately whether to sign and record the reasoning. If you do not sign, still carry out the gap analysis named in point (148) and keep it as the core of your file, together with a description of how your own measures cover Article 50(2), (4) and (5). Account for the fact that as a non-signatory you may receive more information and access requests, and structure your documentation accordingly. If you sign but opt out of sections, treat those sections as a non-signatory would and document them separately.
The deployer cannot rely on the provider's machine-readable marking
Whoever publishes a deepfake must apply a label perceivable by humans. The watermark or metadata supplied by the provider does not discharge that duty.
Applies to deployers of AI systems that generate or manipulate deep fakes in the form of image, audio or video content.
An attenuated form of disclosure applies to deep fakes forming part of evidently artistic, creative, satirical, fictional or analogous works, and an exception applies to use authorised by law to detect, prevent, investigate or prosecute criminal offences.
Point (117) of the guidelines of 20 July 2026 states that deployers of AI systems generating or manipulating deep fake content must clearly and distinguishably disclose that the content has been artificially created or manipulated, by labelling the output accordingly and disclosing its artificial origin. According to that same point, the labelling or disclosure methods used must be understandable and perceivable by natural persons, for example with visible or audible labels, without those persons needing to rely on any specific technical tools or performing dedicated actions. The point closes expressly by stating that deployers cannot rely on the machine-readable marking embedded in the content by the provider under Article 50(2), since those markings are not immediately clear and distinguishable for the natural persons exposed to the deep fake content. Point (12) adds that deployers involved in complex content production and distribution value chains must take proportionate measures to ensure that the labelling they have implemented under Article 50(4) is actually displayed in a clear and distinguishable manner to the targeted and foreseeable audience at the point of first exposure, for example via contractual conditions with distributing partners and via user experience settings and interfaces. Point (14) states that a legal person remains the deployer even where it involves third parties such as contractors or freelancers in the operation of the system on its behalf and under its authority, and that individual employees acting under its instructions and control are not considered separate deployers.
Commission Guidelines C(2026) 5054 final, 20.7.2026, Section 6.1.2 point (117) and Section 2.3 points (12) and (14)
This is the sharpest role confusion in the whole transparency chain. Provider and deployer carry two different duties aimed at two different audiences: the provider marks machine-readably for systems and supervisors, the deployer labels perceptibly for humans. The common error is that a marketing department or agency assumes the generated image is 'already marked' by the tool and that nothing further is needed at publication. That is wrong. Equally important is how the duty travels down the chain: it does not end with applying the label, but with whether the audience actually sees the label at first exposure. If your label disappears because a platform re-encodes, crops or auto-plays the video without the opening title, the label formally exists but functionally does not. That is why the guidelines expressly name contractual arrangements with distribution partners as a means. And note the last sentence of point (14): you do not pass the deployer role on to the agency or freelancer producing the content for you.
Add a separate step to your publication process in which a label visible or audible to humans is applied to deep fake content, independent of whatever the generation tool writes into the files. Verify per distribution channel that the label is still visible at first contact after uploading, re-encoding and auto-play. Write the labelling requirement into your terms with agencies, production partners and distribution platforms, and do not assume that engaging an external agency moves the deployer role.
Disclosure at the latest at first interaction, and again for every new person
The notice that a person is dealing with an AI system must be given at the latest at the time of the first interaction. That moment applies per natural person, not once per system.
Applies to providers of AI systems intended to interact directly with natural persons, and through the horizontal requirements of Article 50(5) to all notices under Article 50(1) to (4).
The information obligation falls away if the interaction is obvious to a reasonably well-informed, observant and circumspect person, or if the system is authorised by law to detect, prevent, investigate or prosecute criminal offences, unless the system is available to the public to report a criminal offence.
The final Commission guidelines of 20 July 2026 (C(2026) 5054 final) state in point (33) that the notification mechanism must be embedded in the design of the system and that the notice must be provided during operation of the system and at the latest at the time of the first interaction with the natural person, as required by Article 50(5). Point (143) clarifies that 'first interaction or exposure' refers not only to the first person who encounters the system, but also to any subsequent first interaction with or exposure to the system by any other natural person. For an interactive system, the information must be provided at least once at the start of an interactive session. For content under Article 50(2) and (4), the information obligation applies to each output with respect to any natural person exposed to it. Point (40) adds that a single prominent notification before the first interaction is likely to suffice in most instances, but that in riskier contexts periodic reminders and context-aware disclosures are likely to be necessary, in particular for vulnerable persons, sustained or immersive interactions, financial, insurance, legal or health advice and complaints handling, and AI companions. That same point requires the system to be designed so that it always discloses where it is asked about its nature or the origin of the interaction, or where it can reasonably be assumed from the exchange that the person is likely to be misled or confused about the AI origin.
Commission Guidelines C(2026) 5054 final, 20.7.2026, Section 3.1.2 points (33) and (40), and Section 7.2 point (143)
The trap is the word 'first'. Many organisations read it as a one-off announcement when the chatbot launches, or as a line in a welcome email that every visitor is assumed to have seen. The guidelines read it as an obligation that arises anew for each natural person who encounters the system or its output for the first time. A second common error is assuming that a notice at the start of the session covers the whole customer journey. If the role of the system changes mid-session, or the interaction is long and concerns money, health or law, the Commission expects repetition. The third trap is letting the system dodge the question when a user directly asks whether they are speaking to a human. That is not permitted: the question must always be answered honestly, whatever notice was given earlier.
Document for each customer contact channel at what moment the notice appears, and test it with a fresh session from a new device so you see what a first-time visitor sees rather than what a logged-in employee sees. Also build a hard rule into the system prompt or conversation logic that forces the system to confirm its AI origin as soon as it is asked or as soon as the user addresses it as a human. Finally, decide for your higher-risk channels, such as financial advice, claims handling, care and complaints, whether a single opening notice suffices or whether you need a persistent label or periodic reminders, and record that assessment in writing.
The editorial exception: substantive review plus an identifiable responsible person
No label is needed where the AI text has been substantively reviewed by a human and someone holds editorial responsibility. A spellcheck or a written editorial policy is not enough, and any AI intervention after sign-off voids the exception.
Both conditions must be met together: substantive human review or editorial control, and an identifiable natural or legal person holding editorial responsibility for the publication.
Point (133) of the guidelines of 20 July 2026 sets two cumulative conditions: the AI-generated or manipulated text must have undergone human review or editorial control, and a natural or legal person must hold editorial responsibility for the publication. Point (134) describes human review as the deliberate examination of the substance of the content by one or more natural persons possessing relevant knowledge and professional judgement on the subject matter, citing academic peer review and professional validation chains as examples, and states that fact-checking the accuracy of the content is a minimum requirement that must form part of that review. Editorial control is described in that same point as the control exercised in practice by a responsible editorial entity, for example an editor-in-chief, with the authority to approve, alter or reject the substance of the text on substantive grounds, including fact-checking and ensuring the trustworthiness of sources. Point (135) states that superficial, solely formal or procedural checks such as spell-checking or grammatical correction, the mere existence of an editorial policy, automated review processes, and cursory editorial approval without substantive engagement by the human reviewer or the editorial entity cannot fulfil the conditions. Point (136) states that where AI systems are used to modify, supplement or reformulate content following editorial sign-off, the resulting content must be treated as AI-generated or manipulated, and that any substantive AI intervention occurring after the human review or editorial control will cause the exception to become void. Point (138) states that the person holding editorial responsibility must hold the ultimate responsibility over the publication, including the human review or editorial control, and that the identity and contact details of that legal person, natural person or function should be made publicly available in an easily findable location, online for example through a website's terms and conditions or other user-facing legal information, offline for example in a colophon. As examples meeting the conditions the document cites among others an AI-manipulated newspaper article or AI-generated summary subject to the editorial control of the editor-in-chief, an AI-manipulated academic blog that has undergone internal peer review, AI-generated public safety warnings approved by a public official, and AI-generated sustainability reports reviewed by professionals in relevant functions. As examples failing the conditions the document cites a website where AI-generated articles on Union policy are posted without any deliberate human review, and AI-generated articles reviewed and edited by another AI system where a human editor performs a mere superficial grammatical check before publication.
Commission Guidelines C(2026) 5054 final, Section 6.2.3, points (133) to (138) and the accompanying example lists
This exception is why most newsrooms and communications departments do not have to label, but it is narrower than it looks. Three pitfalls. First, sequence: many organisations have the text approved and then let an AI tool 'polish it a bit' for SEO, length or tone. Point (136) states literally that any substantive AI intervention after sign-off voids the exception. The AI step must therefore come before the human review, not after it. Second, depth: it must be deliberate examination of the substance with fact-checking as a minimum. An editor who only reads for flow does not qualify, and an AI reviewing another AI certainly does not. Third, visibility: it must be publicly findable who holds editorial responsibility. A colophon or a clear statement in the site's legal information is not a formality but a condition of the exception. Notably, the guidelines expressly place this exception outside the media as well, citing sustainability reports and government warnings. Your compliance or communications function can therefore act as the reviewer, provided the review is genuinely substantive.
Always place your AI step before human approval in the workflow, and technically block any AI edit running after sign-off, including automatic SEO optimisation or shortening. Record per publication stream who performs the substantive review, that fact-checking forms part of it, and who holds editorial responsibility. Publish that responsible function or person with contact details in an easily findable location, for example in the colophon or with the site's legal information. Keep a short record per publication of who reviewed the substance and when, so you can substantiate reliance on the exception.
What does not suffice on its own as an AI disclosure
A line in the terms and conditions, a hidden metadata mark or a vague word like 'assistant' will not do. The guidelines name five methods that are insufficient when used alone.
Applies to every disclosure under Article 50, because Article 50(5) requires information to be provided in a clear and distinguishable manner and to conform to applicable accessibility requirements.
Point (38) of the guidelines of 20 July 2026 lists techniques that are not necessary and that, when used alone, are insufficient to satisfy Article 50(1) and (5). These are: disclosures contained only in terms and conditions, URLs or documentation, with the document adding that such disclosures may complement but not replace in-context disclosure; machine-readable markings such as metadata or watermarks that are not perceivable by users at the point of interaction, which does not affect their appropriateness for Article 50(2); unclear or ambiguous signals, with the document expressly naming a generic reference to 'assistant', and human-like representations that may mislead users; generalised disclosures that are not sufficiently specific to the system's outputs and interactions, with the document citing as inadequate a statement on a platform offering a variety of services that 'Services on this website use AI'; and technical or capability-based descriptions referring solely to the underlying technology, such as 'this system uses LLMs', without explaining the function or the implications for the user and the artificial origin. Point (142) adds that information is not clear and distinguishable where it can be easily overlooked or missed under normal exposure or interaction conditions, for example where it is included only in a manual, hidden under layers of menu options in an online interface, or part of terms of use that users often do not read.
Commission Guidelines C(2026) 5054 final, Section 3.1.2 point (38) and Section 7.1 point (142)
This is the list that topples most existing implementations. Three patterns occur structurally and all three fail. First, the legal cover: a line in the terms and conditions or privacy statement saying the organisation uses AI. Second, the technical cover: the argument that the output carries a C2PA mark or watermark and that the user is therefore informed. The guidelines keep those two tracks strictly separate, because a machine-readable mark counts for Article 50(2) but not as a disclosure to the human. Third, the brand-driven cover: giving the chatbot a friendly name and calling it 'your digital assistant'. That precise formulation is named as an example of an ambiguous signal. The popular generic site-wide banner stating that the site uses AI is likewise explicitly labelled insufficient, because it is not specific enough to the actual output.
Inventory where your current AI disclosure sits. If it lives only in the terms and conditions, the privacy statement, a cookie banner or a help page, it does not comply and must move into the interaction itself, close to the input and output field. Replace phrasings such as 'digital assistant' or 'virtual colleague' with an explicit statement that this is an AI system. Keep the machine-readable marking in place for Article 50(2), but do not count it towards the disclosure to the user.
Existing systems and legacy content: what does and does not apply retroactively
Only the machine-readable marking under Article 50(2) has a transitional period for systems already on the market. Legacy content need not be labelled retroactively, but legacy text you publish now must be.
The transitional period to 2 December 2026 applies only to the marking and detection obligation of Article 50(2) and only to generative systems placed on the market or put into service before 2 August 2026.
Content generated or manipulated before 2 August 2026, and text on matters of public interest generated and published before that date, need not be marked or labelled retroactively.
Point (153) of the guidelines of 20 July 2026 states that under Article 113, Article 50 applies from 2 August 2026 and that all in-scope AI systems placed on the market or put into service in the Union must comply on that date, regardless of their date of placing on the market or putting into service. That same point describes that the regulation amending the AI Act provides a targeted transitional rule concerning only the marking and detection obligations under Article 50(2) for generative AI systems placed on the market or put into service before 2 August 2026, giving providers of those existing systems a transitional period to bring them into conformity by 2 December 2026. Point (153) states expressly that systems that are partly interactive and partly generative may benefit from that transitional period only with regard to the marking obligation under Article 50(2), while compliance with the disclosure obligation for AI systems directly interacting with natural persons must be ensured as of 2 August 2026. Point (154) states that AI-generated or manipulated outputs within the scope of Article 50(2) and deep fakes within the scope of Article 50(4), first subparagraph, generated or manipulated before 2 August 2026 do not need to be marked or labelled retroactively, and that the same applies to texts on matters of public interest that were AI-generated or manipulated and published before that date. That same point states conversely that texts generated or manipulated before 2 August 2026 but published on or after that date must be labelled. Point (154) adds that deployers and other actors in possession of or disseminating pre-existing unlabelled deep fakes are nonetheless encouraged to label them, without being expected to engage in disproportionate efforts such as auditing pre-existing content databases or modifying already printed product packaging. A footnote to point (153) clarifies that the special grandfathering rule of Article 111(2) for high-risk AI systems does not extend to Article 50, because the high-risk obligations and the transparency obligations apply cumulatively.
Commission Guidelines C(2026) 5054 final, Section 8.4, points (153) and (154)
Two things get conflated here. The first is the assumption that the transitional period to 2 December 2026 is a general postponement of Article 50. It is not: it covers only the machine-readable marking and detection of Article 50(2). If your system also runs a chat interface, the disclosure to the user had to be in place on 2 August 2026, even though marking of the output may wait until December. The second is the assumption that legacy content is safe. That holds for already published content, but not for your stock. If you had a batch of AI texts produced last year and are only publishing them now, the labelling duty does apply. The same goes for a campaign visual that has been sitting on the shelf for months. Practically, the distinction is not old versus new, but the moment of publication. The encouragement to label pre-existing deep fakes is not a duty, but it is where a supervisor can look at the reasonableness of your choices.
Split your inventory into three: systems interacting directly with people, which have had to disclose since 2 August 2026; generative systems relying on the transitional period to 2 December 2026 for machine-readable marking; and systems doing both, which therefore carry a different date per obligation. Also walk through your content stock: anything still to be published that was AI-generated or substantially edited gets a label at publication, regardless of when it was generated. Record why you are not retroactively labelling already published legacy content, so you can explain that choice.
When is AI obvious? The exception applies only where almost no doubt remains
The exception for obvious AI interaction must be interpreted restrictively. It applies only where almost no doubt remains for an average member of the intended and reasonably foreseeable audience.
Assessment per system and per context of use, to be carried out and documented by the provider.
This exception does not release you from the information obligations under EU consumer protection law: the guidelines state that those obligations apply irrespective of whether the interaction is considered obvious under Article 50(1).
The Commission guidelines of 20 July 2026 place on the provider, in point (42), the burden of assessing and demonstrating the obvious artificial nature of the interaction to a person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use. Point (43) anchors that standard in the notion of the 'average consumer' in EU consumer protection law. Point (44) prescribes a two-step assessment: first the provider considers the audience with whom the system is intended and reasonably likely to interact, then how well-informed, observant and circumspect an average member of that audience is. That same point states that the exposed audience does not always equal the target audience, that expected levels are lower where persons with disabilities, elderly people or minors are likely to be part of the audience, and that levels may be higher for an exclusively professional or specialised audience. Point (45) states that the exception should be interpreted restrictively because it deprives natural persons of the right to clear and distinguishable disclosure, that general awareness that AI systems exist does not imply that people recognise them in interactions, and that the exception should be limited to cases where there is almost no doubt left about the nature of the interaction. As examples where the exception does apply, the document lists among others code assistance chatbots available only to professional developers, an internal employee-facing assistant for properly trained and AI-literate staff, systems used only by properly trained health professionals, ambient AI embedded in home appliances, and non-playable characters in a single-player video game. As examples where the exception does not apply, the document lists a robotic companion pet closely resembling its natural equivalent, AI in immersive environments using realistic avatars or voices, and chatbots on online platforms or helpdesks whose outputs users may perceive as human-generated.
Commission Guidelines C(2026) 5054 final, Section 3.2.1, points (42) to (45) and the accompanying example lists
This is the most frequently over-claimed exception. The reasoning 'everyone knows this is a chatbot' is explicitly rejected by the guidelines: general awareness that AI exists is not the same as recognition in the actual conversation. What matters is not what your average customer knows, but who could reasonably end up at your system. As soon as your system is publicly accessible, the broader audience of elderly people, children and people with lower digital literacy is by definition included, and the exception falls away. The mirror image matters just as much and is often missed: for a strictly internal assistant used by trained staff, the Commission does expressly recognise the exception. Note the condition embedded in that example, namely that the staff are actually trained and AI-literate. That ties this exception directly to your Article 4 measures: without demonstrably AI-literate staff, the foundation for relying on the exception falls away.
Rely on this exception only for systems with a closed, professional user base, and record the two-step assessment in writing: who is the target audience, who else could reach it, and why almost no doubt remains for an average member of that audience. For anything publicly accessible, assume you must disclose. Link any internal reliance on the exception to your Article 4 file, so you can show that the staff concerned were genuinely prepared for the use of that system.
Standard editing versus semantic change under the marking obligation
Spellchecking, formatting and minor image corrections fall outside the marking obligation. An AI summary, rewrite or face replacement falls inside it.
Applies to providers of AI systems generating or manipulating synthetic audio, image, video or text content, in the context of the machine-readable marking and detection obligation of Article 50(2).
Alongside standard editing and non-substantial alteration, a third exception applies to generative systems authorised by law to generate or manipulate synthetic content to detect, prevent, investigate or prosecute criminal offences.
Point (90) of the guidelines of 20 July 2026 describes standard editing as the process of preparing existing content for publication or distribution, such as small edits to improve readability, grammar, quality and format, without generating new content. According to that same point, editing goes beyond standard editing where the content is changed in a material way through substantive or structural modifications that affect its meaning, style or intent. Point (91) addresses the second exception, for systems that do not substantially alter the input data provided by the deployer or the semantics thereof, and states that an alteration is substantial where the input data or its semantics have been manipulated significantly during output generation, to be assessed against factors including format, media content type, style and changes affecting meaning, style or intent. Point (92) provides that where a system can be used both for generation or manipulation and for minor non-substantial alterations, the obligation does not apply to the content altered in a minor non-substantial manner. As examples falling under the exception the document lists among others grammar correction and spellchecking, minor stylistic polishing that does not change substance or messaging, AI-generated translations, formatting and format conversion, noise reduction, minor cropping and colour corrections, removal of dust spots and red-eye, blurring of faces, rescaling of video clips and transcriptions of conversations. As examples of semantic changes that do require marking the document lists among others AI-generated summaries of text, paraphrasing or rewriting that changes style, structure and meaning, removal, replacement or insertion of objects or persons, face replacement, synthesis of realistic speech in a specific person's voice and the creation of composite images.
Commission Guidelines C(2026) 5054 final, Section 4.3, points (90) to (92) and the accompanying example lists
The dividing line is meaning, not effort and not whether a human was involved. That produces two outcomes that surprise many organisations. The first: an AI-generated summary sits explicitly on the marking side. Summarising feels like editing, but the guidelines classify it as semantic change. Anyone auto-generating summaries of articles, reports or case files is therefore inside the marking obligation. The second, mirror-image: an AI-generated translation sits on the exempt side, as does transcription. That is the opposite of what many editorial teams assume. Finally, note point (92): the question is not what your tool can do, but what actually happened to the content in the specific case. The same tool can fall outside the obligation in one use and inside it in another.
Sort your AI applications into two buckets: editing without semantic change, and producing or changing meaning. Put summarising, rewriting, image editing where persons or objects disappear or appear, and voice cloning explicitly into the second bucket, and spellchecking, formatting, translation and transcription into the first. Record the classification per application with a short justification, because the guidelines require a case-by-case assessment rather than a per-tool one.
Which AI text needs a label: published, informing the public, on a matter of public interest
The labelling duty for AI text applies only where three elements coincide: the text is published, is intended to inform the public, and concerns a matter of public interest.
The three elements are cumulative: only where the text is published, seeks to inform the public and concerns a matter of public interest does the disclosure duty arise.
The duty falls away where the AI-generated or manipulated text has undergone human review or editorial control and a natural or legal person holds editorial responsibility for the publication, and where use is authorised by law to detect, prevent, investigate or prosecute criminal offences.
Point (131) of the guidelines of 20 July 2026 splits the scope of Article 50(4), second subparagraph, into three elements. Published text means the text is accessible by an indeterminate, fairly large number of unrelated potential readers simultaneously or successively, whether or not against payment such as a subscription. Text is not considered published where access is restricted to specific individuals within a closed, private group, for example a small closed group on an instant messaging app or a group that is too small or insignificant; the document cites as examples of unpublished text private interpersonal correspondence for professional purposes and organisation-internal texts or communications such as publications on internal corporate networks. Informing the public means the text intends to communicate knowledge, opinions or facts; short texts that do not materially communicate knowledge, opinions or facts cannot be deemed to inform the public. Matters of public interest are, according to that same point, generally those relevant to society at large, at local, national, Union or international level, and meriting public debate or scrutiny; the document includes texts on politics and democratic processes, public administration and services, the administration of justice and law enforcement, the protection of fundamental rights, public security, public health, environmental protection, consumer safety, and any economic, financial, political, scientific or cultural development that may be a relevant subject of public debate, noting that what counts as public interest can evolve over time and across contexts. As examples within scope the document cites an AI-generated summary of a human-authored article on a newspaper's website discussing a recent town council decision, AI-manipulated parts of a lifestyle-website article comparing the effects of various diets on a particular disease, AI-manipulated corporate reports containing investor information published on a listed company's website, and an AI-generated message on a meteorological institute's social media profile warning citizens about stormy weather and precautionary measures. Outside scope the document places among others AI-generated fantasy novels, AI-manipulated text that is part of a company's advertisement or product descriptions without claims relating to for example health, consumer safety or sustainability, a news summary generated by a chatbot that is only available to the user who prompted it, and AI-manipulated text by a consultant advising a client on measures for regulatory compliance.
Commission Guidelines C(2026) 5054 final, Section 6.2.1 point (131) and the accompanying example lists
The reflex is to read this as a media rule that only concerns newsrooms. The examples show otherwise. A listed company with AI-edited investor information on its own website is inside. A meteorological institute posting a storm warning on social media is inside. A lifestyle site with health claims is inside. What binds those cases is not that they are journalism, but that a broad audience draws information from them about something that affects society. The second nuance sits on the other side: an advertisement or product description falls outside, but only as long as it carries no claims about health, consumer safety or sustainability. Sustainability claims in commercial copy therefore move into scope. The third nuance is the split between internal and published: your intranet and your one-to-one correspondence fall outside, even where the content is socially relevant. And note: the presence of the AI-generated summary of a human-authored article in the example list means the automatic summary feature under a news article can by itself trigger the labelling duty.
Walk through your publication channels and flag where AI generates or substantially edits text: news items, knowledge articles, annual reports and investor information, public information and citizen warnings, and sustainability or health claims. Assess per channel whether the text is published in the sense of the guidelines, meaning accessible to an indeterminate and fairly large audience. Treat automatic summary features on articles as a separate, standalone assessment rather than as part of the underlying article.
When a downstream party that fine-tunes becomes a GPAI provider itself
Not every modification makes you a provider. The indicative threshold is a modification using more than a third of the original model's training compute, and your obligations are then limited to the modification.
Applies to downstream actors distinct from the original provider and not acting on its behalf, who modify or fine-tune a general-purpose AI model, with or without integrating it into an AI system.
If you become the provider of the modified model, obligations remain limited to the modification itself: the technical documentation covers the change, and the copyright policy and training-content summary cover only the data used in the modification.
The Commission guidelines of 18 July 2025 (C(2025) 5045 final) on the scope of the obligations for providers of general-purpose AI models state in point (61) that it is not necessary for every modification of such a model to lead to the downstream modifier being considered the provider of the modified model, in line with the Blue Guide, which states that a product subject to important changes or overhauls aiming to modify its original performance, purpose or type may be considered a new product. Point (62) states that the Commission considers a downstream modifier to become the provider of the modified model only if the modification leads to a significant change in the model's generality, capabilities or systemic risk. Point (63) sets the indicative criterion: a downstream modifier is considered to be the provider where the training compute used for the modification is greater than a third of the training compute of the original model. Point (64) states that where the downstream modifier cannot be expected to know that value, for example because it has not been communicated by the provider of the original model, and cannot estimate it, the threshold is replaced by a third of 10 to the power of 25 FLOP where the original model is a model with systemic risk, and otherwise by a third of 10 to the power of 23 FLOP. Point (65) explains that a modification of that size is expected to display a significant change justifying the transparency obligations of Article 53(1)(a) and (b), that such a modification can be expected to have used a significant amount of data relevant to the copyright policy and the public summary of training content under Article 53(1)(c) and (d), and that where the original model has systemic risk the modified model can be expected to present significantly different systemic risk. Point (67) notes that currently few modifications meet this criterion, that the number of downstream modifiers becoming providers may increase over time, and that the criterion is thus primarily forward-looking. Point (68) states that in the case of a modification the obligations are limited to that modification: the documentation under Article 53(1)(a) and (b) is limited to information on the modification, and the copyright policy under point (c) and the summary of training content under point (d) are limited to the data used as part of the modification. Point (69) states that a downstream modifier who becomes a provider must also comply with Article 54, which means appointing an authorised representative established in the Union to the extent that the modifier is itself established outside the Union. Point (70) states that where a downstream actor modifies a model classified as having systemic risk in such a way that they become the provider of the modified model, the resulting model is presumed to have high-impact capabilities and is therefore considered a model with systemic risk, and point (71) states that the modifier must then comply with the obligations for providers of models with systemic risk and notify the Commission in line with Article 52(1).
Commission Guidelines C(2025) 5045 final, 18.7.2025, Section 3.2 points (60) to (67) and Sections 3.2.1 and 3.2.2, points (68) to (71)
The practical message is more reassuring than most organisations expect, with one catch. Ordinary fine-tuning on your own documents, RAG, prompt engineering or a LoRA adapter comes nowhere near a third of the training compute of a large base model. The Commission itself says that few modifications currently meet the criterion. Anyone adapting a model for their own use therefore generally does not become a GPAI provider. The catch sits in point (64): if you do not know the original model's training compute and cannot estimate it, you fall back on an absolute threshold of a third of 10 to the power of 23 FLOP. That is a considerably lower bar than a third of a large model, and with closed models whose compute is not published, that is exactly the scenario you are in. The second trap is the systemic-risk chain: if you modify a model already designated as having systemic risk and thereby become a provider, you inherit that label and the duty to notify the Commission. On the positive side, obligations in that case remain limited to your own modification: you do not have to reproduce the original model's documentation or training-content summary.
Record per modified model which base model you use, which modification method you apply and how much compute that modification consumed, so you can test the criterion rather than speculate about it. Ask the base model's provider for the training compute and document the answer, because if you cannot know that value you fall back on the considerably lower absolute threshold. Also check whether the base model is designated as having systemic risk, because that changes both the threshold and the consequences of crossing it. Reassess this judgement at every substantial retraining, since the Commission itself indicates that the number of downstream modifiers becoming providers is expected to grow.
Annex I contains no list of high-risk products but an exhaustive list of harmonisation legislation. The AI Act does not extend the scope of that product legislation and does not change a product's risk profile.
The draft guidelines of 19 May 2026, published for consultation and expressly non-binding, clarify that Annex I AI Act does not list individual products to be classified as high-risk, but Union harmonisation legislation regulating the safety aspects of certain products. Whether an AI system falls within the scope of Annex I therefore depends on whether the system, or the product of which it is a safety component, falls within the material scope of one of the listed legislative acts. According to the draft guidelines the list in Annex I is exhaustive; products can only be added or removed by amending the scope of the harmonisation legislation itself or by adding new harmonisation legislation to Annex I. The draft guidelines also state that through Article 6(1) the AI Act does not itself extend the scope of harmonisation legislation to new or additional products, and that the AI Act does not determine or change the risk profile of a product but builds on the sectoral risk classification. Products mentioned include machinery, toys, lifts, equipment and protective systems for potentially explosive atmospheres, radio equipment, pressure equipment, recreational craft, cableway installations, appliances burning gaseous fuels, medical devices, in vitro diagnostic medical devices, and products in the automotive and aviation sectors.
Draft guidelines Annex I, points (23) to (26)
Your starting point is therefore not the AI Act but your existing product file. The question is not whether your product appears on an AI list, because no such list exists. The question is whether your product already fell under one of the listed regulations or directives before AI was added to it. If not, this route does not bring you into the high-risk regime, however advanced the AI system is. The draft guidelines do note that for this classification the concept of safety component may be read as excluding public interests in the sectoral legislation that go beyond health, safety and fundamental rights, such as risks relating to radio spectrum use or electromagnetic compatibility. Those interests therefore do not contribute to the qualification.
Start your classification with an inventory of the product legislation that already applies to your portfolio today, and record per product line which regulation or directive covers you. That overview is reusable and prevents you from redoing the entire analysis for each AI feature.
Section A and Section B of Annex I trigger different requirement sets
For products under Section A of Annex I the full set of high-risk requirements applies. For Section B only Article 6(1), Articles 102 to 109 and Article 112 apply.
The Commission draft guidelines of 19 May 2026, which are non-binding as long as the final version has not been adopted, draw a distinction that is often missed in practice. AI systems classified as high-risk under Article 6(1) in respect of products covered by the harmonisation legislation in Section A of Annex I are subject to the requirements for high-risk systems in Section 2 of Chapter III AI Act. By contrast, for AI systems classified as high-risk under Article 6(1) in respect of products covered by the harmonisation legislation in Section B of Annex I, only Article 6(1), Articles 102 to 109 and Article 112 AI Act apply. The draft guidelines refer to Article 2(2) AI Act for this. Section A contains harmonisation legislation based on the New Legislative Framework, Section B the other Union harmonisation legislation.
Draft guidelines Annex I, point (60), referring to Article 2(2) AI Act
This distinction determines the size of your project. Two organisations can both correctly conclude they have a high-risk AI system and still face a completely different work package. If you are in Section A, the full set applies: risk management system, data quality, technical documentation, logging, transparency towards deployers, human oversight, accuracy and robustness. If you are in Section B, the requirement set is materially narrower. So check first which section your legislation sits in, before you set budget and planning.
In your classification note, record not only that you fall under Annex I but also under which section. Attach the corresponding requirement set immediately, so that your project plan is correctly sized from the outset.
Two cumulative conditions for high-risk under Annex I
An AI system only becomes high-risk under Article 6(1) when two conditions are met at the same time: the system is itself a regulated product or a safety component of one, and that product must undergo third-party conformity assessment.
The European Commission draft guidelines of 19 May 2026, which are expressly non-binding and not final, read Article 6(1) as two cumulative conditions. First, the AI system must be intended to be used as a safety component of a product, or the AI system must itself be a product, covered by the Union harmonisation legislation listed in Annex I. Second, that product, or the AI system itself where it is the product, must be required to undergo a third-party conformity assessment. The draft guidelines state explicitly that not all AI systems that are components of regulated products are high-risk, but only the subset that satisfies both criteria.
Draft guidelines Annex I, points (27) and (21)
This is a filter with two screens, and both must be passed. In practice organisations stop at the first screen and conclude their product is high-risk simply because sectoral product legislation applies to it. That is premature. The second screen, mandatory third-party involvement, removes a substantial share. The reverse also holds: anyone who looks only at the CE route and skips the safety component question will miss systems that only enter through the failure route. You must therefore ask both questions separately and record both answers.
For every AI system in a regulated product, record a two-part classification note: first whether the system is a product or a safety component, then whether a third party must be involved for that product. Keep both answers with their reasoning in your technical documentation, so that during an audit you do not have to reconstruct after the fact why you reached your conclusion.
The Article 6(3) filter: four exhaustive grounds, to be read narrowly
A system falling within Annex III can still stay outside high-risk if one of four grounds is met and the system does not perform profiling. The provider makes that call itself, must document the assessment before placing the system on the market, and must register the system in the EU database.
According to the non-binding draft guidelines of 19 May 2026 on the classification of high-risk AI, Article 6(3) sets out four grounds on which a provider may exempt a system from high-risk classification: performing a narrow procedural task, improving the result of a previously completed human activity, detecting decision-making patterns or deviations from prior patterns without replacing or influencing the previously completed human assessment absent proper human review, and performing a preparatory task. Paragraph (88) of this draft states these grounds are exhaustive but alternative, that there is no separate independent risk test, and that they must be interpreted narrowly because Article 6(3) is an exception to rules that among other things protect fundamental rights. Paragraph (87) states the filter applies only to systems under Article 6(2) and not to systems under Article 6(1). Paragraph (89) states a system always remains high-risk where it performs profiling. Paragraph (90) adds that the filter does not apply where the system forms part of a complex system whose combined intended purpose or joint outputs materially influence an individual decision, including agentic AI. Paragraphs (113) to (116) of this draft describe that this is a self-assessment by the provider, that Article 6(4) requires documenting the assessment before placing on the market and registering in the Article 71 EU database, and that the assessment must contain at least the intended purpose, why the system falls under Article 6(2), which Article 6(3) condition applies and why, and why the system does not perform profiling. Paragraph (117) of these draft guidelines points to Articles 80 and 99 where an authority finds a system was misclassified as non high-risk to circumvent the rules.
Draft guidelines on high-risk AI classification (19 May 2026), Annex III chapter, sections 2.7, 2.7.1, 2.7.3 and 2.7.4, paragraphs (84) to (90) and (113) to (117)
The filter is not a soft way out but a documented and visible decision. You leave the Chapter III high-risk obligations, but in exchange you appear in the public EU database and your reasoning must be available to the regulator at any time. For buyers that is a gift: the draft guidelines expressly encourage deployers to check that database to see whether a vendor relies on the exception.
Write the filter file in four fixed blocks: intended purpose, why it falls under Annex III, which ground you invoke with reasoning, and why there is no profiling. Never rely on the filter because the risk feels low, since that free-standing test does not exist. When procuring, always check the EU database before believing a vendor who says its system is not high-risk.
Article 6 has two separate routes to high-risk
An AI system can be high-risk in two ways. Either it is itself a product, or a safety component of a product, covered by the Annex I product legislation and that product must undergo third-party conformity assessment (Article 6(1)). Or it falls within one of the use cases listed in Annex III (Article 6(2)). The two routes have their own criteria and their own application dates.
The European Commission's draft guidelines on the classification of high-risk AI of 19 May 2026, which are expressly non-binding, state in paragraph (7) that an AI system is high-risk in two scenarios: first, where it is intended to be used as a safety component of a product, or is itself a product, covered by the Union harmonisation legislation listed in Annex I and required to undergo third-party conformity assessment; and second, where it falls within one of the use cases in the areas listed in Annex III. Paragraph (448) of those same draft guidelines notes that the Article 113 application dates have been postponed by the AI Omnibus to 2 December 2027 for the Article 6(2) route and 2 August 2028 for the Article 6(1) route.
Draft guidelines on high-risk AI classification (19 May 2026), General principles chapter, section II, paragraph (7); section V, paragraph (448)
The two routes are not interchangeable. The Annex I route turns on product legislation and on whether a third party must assess conformity, not on whether the system assesses people. The Annex III route turns on intended purpose and use case. A system can in theory touch both routes, but you must work through them separately. The exemption mechanism also differs: under the draft guidelines the Article 6(3) filter applies only to the Annex III route and not to the Annex I route.
For each AI system, record in your register which route you assessed and with what outcome. Start with the Annex I question where hardware, machinery, medical devices or toys are involved, and with the Annex III question where the system touches people or access to services. Plan your programme against the earlier of the two dates that applies to you.
Broadly positioned and general purpose AI systems: a disclaimer is not enough
If you market a system broadly without consistently limiting its application, high-risk use cases will be read into its intended purpose. Merely stating in the terms of service that high-risk uses are excluded is insufficient where the rest of your presentation in fact enables or promotes such uses.
According to the non-binding draft guidelines of 19 May 2026 on the classification of high-risk AI, paragraph (12) provides that where the instructions for use, contractual arrangements, terms of service, usage policy, promotional and sales materials or technical documentation present the AI system as broadly applicable across a generality of contexts and functions, and do not consistently limit its application or exclude high-risk uses, the system's intended purpose will be deemed to also encompass high-risk use cases and therefore qualify as high-risk. Under these draft guidelines this applies in particular where such uses are feasible and reasonably foreseeable given the system's functionalities and capabilities. The same paragraph states that merely asserting, for example in the terms of service, that high-risk uses are excluded is insufficient where the provider's overall presentation, examples or product positioning effectively provides for or promotes such uses, and that any limitations of use must be described clearly, concretely and coherently across all materials.
Draft guidelines on high-risk AI classification (19 May 2026), General principles chapter, section II.2, paragraph (12)
This mainly affects providers of broad assistants, agents and platforms who say the product is not meant for HR, education or credit assessment, but show demos, templates or customer stories in exactly those contexts. The draft guidelines look at the whole of your communications, not at the strictest sentence in the small print. For buyers it means a vendor hiding behind a clause does not relieve you of your own assessment.
If you genuinely want to exclude high-risk use, make that real in the product and not only on paper. Remove demos and examples in excluded domains, build technical or contractual blocks, and make sure sales, website and documentation draw the same line. If you cannot sustain that, assume high-risk and build your evidence file accordingly.
High-risk does not mean prohibited, and not high-risk does not mean permitted
Classification answers one question: which Chapter III obligations apply. It says nothing about whether the use itself is lawful. Prohibited practices, data protection, consumer law, product safety and national law continue to apply in full.
The draft guidelines of 19 May 2026 on the classification of high-risk AI, which are not binding, state in paragraph (3) that the fact an AI system is listed as an example in these guidelines does not mean its use should automatically be considered lawful, since such use would still need to comply with other applicable legislation, and in paragraph (4) that the scope of these guidelines is limited to whether an AI system is high-risk or not. In the Annex III chapter of this draft, paragraph (68) states that classifying systems as high-risk under Article 6(2) does not mean their use is prohibited, but that those systems are subject to appropriate requirements. Paragraphs (82) and (83) of this draft explain the wording in so far as their use is permitted under relevant Union or national law and state that falling within a use case does not necessarily mean the system may lawfully be used in those cases, that in addition to the prohibitions other provisions of Union or national law may restrict use, and that under Article 2(9) the AI Act applies without prejudice to rules on consumer protection, product safety and data protection.
Draft guidelines on high-risk AI classification (19 May 2026), General principles chapter, paragraphs (3) and (4); Annex III chapter, paragraph (68) and section 2.6, paragraphs (82) and (83)
This removes two errors of reasoning. The first is that a high-risk label equals a ban, which stops projects unnecessarily. The second, and the more dangerous one, is that an outcome of not high-risk means you have a free hand. A system can fall outside high-risk and at the same time be a prohibited practice, or fail on data protection or sector rules.
Run the classification test and the lawfulness test as two separate steps and record both outcomes separately. Always test first against the Article 5 prohibited practices, enforceable since 2 February 2025, and only then against Article 6. Finish with a short check on data protection and sector-specific law, even where the system turns out not to be high-risk.
Split and agentic architectures are assessed as a whole
You cannot avoid classification by splitting a high-risk function into separate modules. The draft assesses the combined configuration.
The non-binding draft guidelines of 19 May 2026 provide in paragraphs 75, 76 and 90 that where several AI systems form part of a more complex whole and their combined intended purpose or joint outputs materially influence an individual decision, that configuration is treated as a single AI system for classification. The draft expressly states that split architectures are assessed as a whole to prevent circumvention by system design, that exemptions for individual modules do not apply where the overall configuration influences key aspects of the decision, and that this also extends to complex interconnected setups such as agentic AI systems whose linked actions jointly serve a high-risk purpose. Under the same draft, strictly procedural or preparatory functions do remain eligible for exemption where they are genuinely separable from the system and do not structure or feed outputs that materially influence the examination of an individual case.
Section IV.2.3, paragraphs 75 and 76, and section IV.2.7.1 paragraph 90
This hits modern architecture head-on: a chain of agents, tools and model calls. Four subsystems that are each neatly preparatory on their own still form a high-risk system once the chain in practice drives the decision.
Assess at chain level, not component level. Record where separability genuinely lies, and show the exempted module can be put into service independently without contributing to the high-risk purpose.
Relying on the exception requires documentation and registration
The exception is a provider self-assessment, but not a free pass. The draft sets out four mandatory components of the assessment and links registration and supervision to it.
The draft guidelines of 19 May 2026 are not binding and describe in paragraphs 113 to 117 that applying the filter mechanism depends on a provider self-assessment, that the assessment must be documented before the system is placed on the market or put into service, and that the system must be registered in the EU database under Article 71 to ensure traceability of exempted systems. Under the draft, the assessment must contain four components: a description of the intended purpose, a description of why the system would qualify as high-risk under Article 6(2), a description of which condition or conditions of Article 6(3) are considered to apply and why, and a description of why the system does not perform profiling. The record must be available at any time on request of the market surveillance authority, and the draft encourages deployers to verify use of the exception in the Article 71 database as part of their due diligence. The draft further notes that market surveillance authorities may under Article 80 evaluate the classification, require the system to be brought into compliance and demand corrective action, and may impose penalties under Article 99 where a system was misclassified to circumvent the high-risk requirements.
Sections IV.2.7.3 and 2.7.4, paragraphs 113 to 117
The exemption shifts the work, it does not remove it. You trade the full Chapter III regime for a documented and publicly traceable justification that a supervisor can request and challenge. For deployers, the database is conversely a procurement check.
Build one fixed template covering the four mandatory components and date the assessment before market introduction. In procurement, always ask whether the supplier relies on Article 6(3) and whether that appears in the Article 71 database.
The Article 6(3) filter: four alternative conditions, to be read narrowly
A system that falls within an Annex III use case can still escape high-risk classification if it meets one of four conditions. The draft guidelines make clear this is not a broad escape route.
According to the European Commission's draft guidelines of 19 May 2026, which are not binding and were published for stakeholder consultation, the following applies (paragraphs 84 to 90): the filter mechanism only works for systems that would be high-risk under Article 6(2) and Annex III, not for systems that are high-risk under Article 6(1) and Annex I; the four conditions (narrow procedural task, improving the result of a previously completed human activity, detecting decision-making patterns or deviations without replacing or influencing the previously completed human assessment without proper human review, and preparatory task) are exhaustive but alternative; there is no separate, independent risk test alongside those conditions; and because Article 6(3) is an exception to rules that also protect fundamental rights, the conditions must be interpreted narrowly and always read in light of the requirement that the system does not materially influence the outcome of decision-making.
Sections IV.2.7 and 2.7.1, paragraphs 84 to 90
The practical question is not whether your system feels low risk, but whether it demonstrably fits one of the four described task types. The absence of a separate risk test cuts both ways: you do not need to make a general risk assessment, but you also cannot invoke one when none of the four conditions fits.
For each system, set out which of the four conditions you rely on and why, in the document's own vocabulary. If you rely on more than one, name each separately. If the reasoning feels strained, assume the narrow reading works against you and treat the system as high-risk.
A human in the loop does not make a system low-risk
Human involvement does not change the intended purpose and therefore has no effect on classification under Article 6(2). Human oversight is a compliance requirement for high-risk systems, not an escape from the classification.
The draft guidelines of 19 May 2026 on the classification of high-risk AI, which are not binding, state in paragraph (70) that the only relevant determinant for qualification under Article 6(2) is whether the intended purpose of the system includes one of the use cases listed in Annex III, that human involvement cannot change the purpose and area in which a system is intended to be used, and that human involvement therefore has no effect on classification. The same paragraph states that human oversight is instead a prerequisite for compliance with the rules for high-risk systems under Article 14. Paragraph (71) of this draft adds that the type and degree of human involvement may play a role for the Article 6(3) filter, but only to demonstrate that the tasks are narrow procedural or preparatory in nature or that the system only improves a previously completed human activity, and that a provider cannot categorise a system as low risk simply by adding a requirement of human involvement.
Draft guidelines on high-risk AI classification (19 May 2026), Annex III chapter, section 2.1, paragraphs (70) and (71)
This defeats the most common defence in practice, namely that a human always looks at it anyway. That sentence changes nothing about the classification. Human involvement only becomes relevant when you can show that the system itself plays no more than a narrow procedural or preparatory role, and that is a far heavier test than an approval button.
Delete the sentence that a human is in the loop from your classification reasoning. Instead describe exactly what the system does in the decision process and at what moment. Use the degree of human involvement only as support within one of the four Article 6(3) grounds, and keep evidence that the review is genuinely substantive.
Human oversight is a compliance requirement for high-risk systems, not a way to escape classification. Human involvement only counts when determining what task the system performs.
In the non-binding draft guidelines of 19 May 2026, the Commission states in paragraphs 70 and 71 that classification under Article 6(2) depends solely on whether the system's intended purpose falls within an Annex III use case. Human involvement cannot change the purpose and area of intended use and therefore has no effect on that classification; human oversight is instead a condition for compliance under Article 14. Under the draft, the type and degree of human involvement can play a role in the filter mechanism, but only to demonstrate that the system's tasks are narrow procedural or preparatory in nature, or merely improve a previously completed human activity. The draft expressly adds that a provider cannot label a system as low-risk simply by adding a human involvement requirement to it.
The common reassurance that a human always reviews the output changes nothing about classification. In fact, the document's examples dismiss formal human review precisely where the output in practice weighs heavily on the outcome.
Base your classification on the intended purpose, not on your workflow. If you want to use human involvement in the argument, tie it to the system's task type and show the human assessment is substantive and complete, not a formality.
Improving is deliberately different from reviewing
The second condition requires a completed human activity with a result that the system only refines. A materially different outcome does not qualify.
The draft guidelines of 19 May 2026 are a non-binding draft and state in paragraphs 94 to 96 that Article 6(3)(b) requires three cumulative elements: a human activity that has been completed, a result flowing from it, and improvement of that result by the AI system. The system may therefore not replace or autonomously perform the human activity. The draft notes the EU legislature deliberately chose the word improve rather than review, so the system must not be intended to provide a materially different result but to verify or refine the activity, and that any improvement must not change the rights, protection, legal or economic position of the persons affected. As an example that does not qualify, the draft cites a system that checks a human-made decision, plan or construction and provides a substantially different solution. As examples serving an auxiliary improvement function, the draft cites systems that flag errors or contradictions in finalised human work as quality assurance, systems that map conclusions to evidentiary records to strengthen traceability of a decision without substituting human judgment, and systems that convert human-validated content for interoperability or accessibility purposes.
Section IV.2.7.1(b), paragraphs 94 to 96
This condition is narrower than it sounds. A writing assistant that sharpens the wording of a completed judgment fits; a second-opinion model that redoes the judgment does not, however useful it may be substantively.
Make the sequence in your process demonstrable: the human judgment is recorded first, only then does the system act. Record that scores, conclusions and outcomes are not altered by the system.
Intended purpose is the anchor of classification
Intended purpose determines whether a system is high-risk. That purpose is set not only by the technical documentation but also by the instructions for use, promotional materials, sales materials and statements by the provider. Reasonably foreseeable misuse falls by definition outside the intended purpose.
The draft guidelines of 19 May 2026 on the classification of high-risk AI, which are not binding, state in paragraph (10) that the intended purpose of an AI system plays an important role in its classification as high-risk, and that under Article 3(12) intended purpose is the use for which the provider intends the system, including the specific context and conditions of use, as specified in the instructions for use, promotional or sales materials, statements and technical documentation. Paragraph (11) of that draft adds that providers must clearly describe the envisaged use, including the system's functionalities, leaving no ambiguity as to scope and intended use. Paragraph (13) of these draft guidelines places the assessment with the provider, supervised by the competent market surveillance authorities.
Draft guidelines on high-risk AI classification (19 May 2026), General principles chapter, section II.2, paragraphs (10), (11) and (13)
Marketing is legal material here. What your website, sales deck or demo promises counts towards establishing the intended purpose, even if the technical documentation is more cautious. A gap between what the system does in practice and how its purpose is described will not protect you.
Have one owner for the intended-purpose description and review the instructions for use, technical documentation, website, sales material and demo scripts against each other annually. Also describe explicitly which contexts and applications are and are not intended, and keep that wording identical across all channels.
First the definition question: is it an AI system at all?
Before classification comes into play, the system must meet the definition of an AI system in Article 3(1). Not every software application and not every automated decision-making system falls within the AI Act.
According to the non-binding draft guidelines of 19 May 2026 on the classification of high-risk AI, before a system can be classified as high-risk it must first qualify as an AI system within the meaning of Article 3(1) of the AI Act (paragraph 8). Paragraph (9) of that draft states expressly that not every software application or automated decision-making system falls within the scope of the regulation, and refers for the interpretation of the definition to the separate guidelines on the definition of an AI system (C(2025) 5053).
Draft guidelines on high-risk AI classification (19 May 2026), General principles chapter, section II.1, paragraphs (8) and (9)
This is a genuine preliminary question, not a formality. Classic rule-based software, fixed calculation rules and simple automation that does not infer from input how to generate output never reach the classification question. At the same time this is not an escape route: the definition guidelines are broad and in practice the burden of showing that something falls outside the definition rests on you.
Include an explicit definition-test field in your AI register, with the reasoning why a system is or is not an AI system. Run that test before you invest time in the Annex I or Annex III analysis, and record the result so you can show it during an inspection.
Only the assessment of natural persons falls within these use cases
Systems assessing only legal persons fall outside the relevant Annex III use cases. Self-employed people and sole traders do count as natural persons, however.
The draft guidelines of 19 May 2026, published as a non-binding draft, clarify in paragraphs 72 to 74 that a natural person is distinct from a legal person and that the notion is not limited to consumers: sole traders, independent professions and other self-employed persons also count as natural persons in relation to their commercial activity, including persons acting in a professional capacity such as consultants, designers and journalists. A system that assesses natural persons falls within the use case regardless of whether it also assesses legal persons; systems intended only to assess legal persons or companies fall outside it. The draft gives as an example that a system assessing the creditworthiness of companies based on company data, balance sheets and financial statements does not qualify as evaluating a natural person, and that an owner assessed to back a company loan also falls outside point 5(b) because the company, not the individual, is the primary beneficiary of the credit.
The boundary does not run along sector or sensitivity, but along who is being assessed. Watch the trap on the other side: as soon as your B2B system also assesses freelancers and sole traders, you are back inside the use case.
State unambiguously in the intended purpose whether natural persons are part of the assessed population. Exclude that use contractually and technically if you want to stay outside the use case, because mixed use pulls the whole system in.
Preparatory or decisive: general input is allowed, a specific recommendation is not
The preparatory task under Article 6(3)(d) precedes the assessment. Once the system evaluates the specific case or makes a recommendation, the exception is gone.
According to the non-binding draft guidelines of 19 May 2026, the notion of preparatory in Article 6(3)(d) refers to tasks occurring prior to the actual assessment process, which distinguishes it from the narrow procedural task in point (a) that may also occur during the assessment as long as it is clearly delimited (paragraphs 103 and 104). The draft cites as examples from Recital 53 indexing, searching, processing and linking: tasks that add structure to the input but do not themselves provide an assessment leading to an outcome (paragraph 106). Under paragraph 107, the decisive factor is the task's role in the decision-making process and its proximity to the final human decision. Paragraph 108 adds that output feeding a human operator's assessment can only be preparatory if it is a general input or supplementary information, and that a system producing a specific recommendation or evaluation of the case plays a decisive role and is therefore not preparatory.
Section IV.2.7.1(d), paragraphs 103 to 108
The dividing line is workable in practice: laying out information is allowed, interpreting the case is not. A system that surfaces legal provisions, jurisdiction and internal guidance stays preparatory; the same system drawing a conclusion for this file no longer is.
Test your system on one question: does the output produce anything specific to this case that points towards an outcome? If so, assume high-risk. Where possible, build a hard separation between information retrieval and assessment logic.
Profiling always blocks the exception, even when a condition would otherwise fit
As soon as the system profiles, the Article 6(3) exemption is ruled out. The draft guidelines give three cumulative elements against which you test this.
The draft guidelines of 19 May 2026, which are a non-binding draft document, explain in paragraphs 89 and 109 to 112 that a system listed in Annex III always remains high-risk where it performs profiling within the meaning of Article 4(4) GDPR, Article 3(4) of Directive (EU) 2016/680 or Article 3(5) of Regulation (EU) 2018/1725. Under the draft, profiling consists of three cumulative elements: automated processing, carried out on personal data, with the objective of evaluating personal aspects relating to a natural person. The draft states the first element is always satisfied for AI systems, so the provider must mainly establish whether personal data form the input and whether personal aspects are being evaluated. The draft adds that a simple classification on characteristics such as age, sex or height does not automatically amount to profiling, because a form of prediction, assessment or inference must be present.
Section IV.2.7.1 paragraph 89 and section IV.2.7.2, paragraphs 109 to 112
The profiling bar is the sharpest brake on the filter mechanism. Many systems that at first sight perform a tidy preparatory or procedural task still fail here because along the way they predict or judge something about a person. Note that this may be a person other than the subject of the decision, for example the assessor themselves.
State explicitly in your file which data the system ingests, whether those are personal data, and whether a prediction, score or inference about a person arises anywhere. Consider anonymisation or aggregation at source if you want to preserve the exception.
Safety component is an autonomous AI Act concept
For classification purposes only the definition of safety component in Article 3(14) AI Act counts. Definitions of the same term in sectoral product legislation are not relevant here.
According to the draft guidelines of 19 May 2026, which are non-binding and may still change, the definition of safety component in Article 3(14) AI Act is an autonomous definition with its own meaning, independent of definitions of safety component in other Union harmonisation legislation. The draft guidelines state that this definition ensures uniform interpretation of the concept across all sectors covered by Annex I, and that in assessing whether an AI system is a safety component only Article 3(14) AI Act is relevant, not the definition in any legislation listed in Annex I. Article 3(14) describes a safety component as a component of a product or of an AI system which fulfils a safety function for that product or AI system, or the failure or malfunctioning of which endangers the health and safety of persons or property.
Draft guidelines Annex I, points (32) and (33)
This is the most underestimated pitfall in the entire chapter. Many technical teams have worked for years with the notion of safety component as defined by their own sectoral standard, for instance in the machinery tradition or the medical devices world. That reflex produces the wrong outcome. The AI Act concept is broader than many sectoral definitions, precisely because it includes the failure route. A component that has never been designated a safety component in your sectoral file may well be one under the AI Act.
Run the safety component test again using only the text of Article 3(14), even if your product has had a sectoral safety file for years. Have a second reviewer who is not steeped in the sectoral tradition read along, because that person will more readily spot where the AI Act is broader than your habit.
Two routes to safety component: intent or consequence
An AI system is a safety component via two alternative routes. Either it is intended to fulfil a safety function, or its failure or malfunctioning endangers health, safety or property.
The draft guidelines of 19 May 2026 are a draft document without binding force and read Article 3(14) as two alternative scenarios. In the first scenario the AI system fulfils a safety function, meaning that its intended purpose, as determined by the provider, is to prevent or mitigate risks to the health and safety of persons or property. The draft guidelines note that the mere fact that an AI system is integrated into or operates within a product subject to safety regulation does not in itself mean it fulfils a safety function. In the second scenario the system is a safety component because its failure or malfunctioning could endanger the health and safety of persons or property. The draft guidelines summarise this in a table: the safety function is intent-based and strongly provider-controlled, evidenced by instructions of use, technical documentation and promotional materials, while the failure route is consequence-based and risk-based with lower provider control, evidenced by system architecture, failure modes and effects.
Draft guidelines Annex I, points (34) to (44), including table 1
You can steer the first route, not the second. That is the whole point. A provider determines the intended purpose and can therefore choose not to claim a safety function in the documentation. The draft guidelines close that exit with the failure route, which looks at what happens when things go wrong, regardless of what you wrote down. The guidelines list forms of failure including incorrect outputs such as false positives and false negatives, loss of function or availability, performance instability or drift, timing or latency errors, and misclassification leading to hazardous control decisions. Note the lower bound as well: the likelihood of failure must not be a merely theoretical possibility, and reputational harm, purely financial loss, minor service degradation or inconvenience without a safety hazard do not count.
Document the two routes separately. For the safety function, record what you communicate as intended purpose in the instructions of use, technical documentation and sales materials, and keep those three consistent. For the failure route, produce a failure mode analysis noting for each failure form whether there is a path to injury or damage to property. That analysis is also your evidence towards a market surveillance authority.
Integrating AI Act requirements into existing risk and quality systems
The AI Act allows you to add AI-specific risks to your existing risk management and quality management systems, so that you can work within a single compliance framework.
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)
This is the most reassuring point in the entire chapter, and at the same time the most underused. Manufacturers who already have a mature quality management system, for instance under a sectoral standard, do not need to set up a second system alongside it. You extend what is already there. That saves not only cost but above all the fragmentation in which your AI file becomes detached from your product file and the two start contradicting each other during an audit. The practical gain lies in a shared risk register in which AI risks are included as a category, not as a separate document.
Extend your existing risk register and quality manual with an AI chapter instead of building a parallel AI management system. Appoint an owner who manages both the sectoral file and the AI file, so that changes to the product automatically touch the AI assessment.
Standalone software, updates and remote services can also be high-risk
Article 6(1) applies regardless of whether the AI system is embedded in the product or placed on the market independently. A software update, add-on or remote service can therefore be high-risk in its own right.
The draft guidelines of 19 May 2026 are non-binding and still under consultation, and clarify that Article 6(1) AI Act applies irrespective of whether the AI system is embedded within the product or placed on the market or put into service independently. An AI system supplied for example as a software update, an add-on or a remote service may therefore be classified as high-risk under Article 6(1), provided all conditions of that provision are met. The draft guidelines also distinguish the case where the AI system is the product itself: that is so where it is independently placed on the market, has its own intended purpose, and is directly regulated by the harmonisation legislation listed in Annex I. As an example the draft guidelines cite Regulation (EU) 2023/1230, the Machinery Regulation, whose definition of machinery-related products explicitly includes certain software, which may therefore itself be a regulated product and be classified as high-risk provided third-party conformity assessment is required. The draft guidelines further state that an AI system which is a safety component of a regulated product should be evaluated as part of that product's overall safety assessment, even where it is also placed on the market independently of that product.
Draft guidelines Annex I, points (22), (30) and (31)
This affects a growing group of suppliers who believe they are outside the regime because they do not make a physical product. Anyone supplying an AI module that is later loaded into a machine, lift or vehicle may well be a provider of a high-risk AI system. The same holds for over-the-air updates that change or add an existing safety function. The flip side is that your assessment is not detached from the product: the draft guidelines require your component to be weighed in the overall safety assessment of the product it lands in. That requires coordination with the manufacturer and clear arrangements on information exchange.
Map which regulated products your software ends up in and which safety-relevant functions your updates touch. Set out contractually what information you supply to the product manufacturer for their safety assessment, and treat an update that changes a safety function as a trigger to re-test the classification.
When a customer or distributor itself becomes the provider
Distributors, importers, deployers and other third parties can take on provider obligations. That happens when you put your own name or trademark on a system, when you make a substantial modification to a high-risk system, and when you change the intended purpose of a non high-risk system so that it becomes high-risk.
The draft guidelines of 19 May 2026 on the classification of high-risk AI, which are not binding, note in paragraph (14) that distributors, importers, deployers or other third parties may become subject to provider obligations under Article 25(1) where they, first, put their name or trademark on a high-risk AI system already placed on the market or put into service; second, make a substantial modification to a high-risk AI system already placed on the market or put into service in such a way that it remains a high-risk AI system; or third, modify the intended purpose of an AI system, including a general-purpose AI system, which had not been classified as high-risk, in such a way that the system becomes a high-risk AI system under Article 6. A footnote to that paragraph announces that the Commission is preparing separate guidelines on responsibilities along the AI value chain under Article 25.
Draft guidelines on high-risk AI classification (19 May 2026), General principles chapter, section II.2, paragraph (14) and its footnote 6
The third situation is the most underestimated. An organisation that buys a broadly deployable model or assistant and then aims it at recruitment, employee evaluation or access to services changes the intended purpose and can thereby become the provider of a high-risk system, with the full set of obligations. White labelling under your own brand is also enough, without changing a single line of code.
Introduce a standing check before you rebrand, modify or repurpose a procured AI system. Assess for each change whether you land in one of the three Article 25(1) situations and record that assessment. Make this part of your procurement and change process, not a one-off project check.
Module choice does not change the classification
The fact that a manufacturer may opt for internal control based on harmonised standards does not affect the high-risk classification. Classification follows the level of enhanced scrutiny required by the product legislation, not the procedure chosen.
The draft guidelines of 19 May 2026 have the status of a non-binding draft and clarify the second condition as follows. The AI Act does not itself determine the applicable conformity assessment procedures but relies on the choice of procedures established under the Annex I harmonisation legislation. Decision 768/2008/EC sets out eight main modules A to H. For all modules except module A the involvement of a notified body is required; module C does not require such involvement but is always combined with modules that do; for modules A1 and A2 a notified body or accredited in-house body is required only in the production phase. The draft guidelines then state explicitly that the fact that harmonisation legislation may allow a manufacturer to rely on internal control based on harmonised standards, as one procedural option, does not affect the classification of an AI system as high-risk under Article 6(1). The choice of module gives the manufacturer procedural flexibility to demonstrate compliance but confers no discretion to determine the risk classification under the AI Act. The decisive factor is that the product, under the Annex I legislation, is subject to enhanced regulatory scrutiny before it may lawfully be placed on the market, scrutiny ensured through the requirement of third-party conformity assessment or equivalent mechanisms, including internal control subject to mandatory application of harmonised standards published in the Official Journal. The draft guidelines point out that the Union legislature expressly confirmed this logic in recital 15 of Regulation (EU) 2025/2509 on the safety of toys.
Draft guidelines Annex I, points (50) to (59)
Here the draft guidelines close the most obvious escape route. The reasoning many manufacturers hoped to use ran: we apply harmonised standards, therefore we use module A, therefore no third party is involved, therefore we are not high-risk. The Commission reverses that. What matters is not the chosen procedure but the level of protection the legislature considered necessary for that product type. Anyone who has built the module A route into their compliance planning must now revisit that assumption. The toys and machinery regulations are explicitly named as sectors where this plays out.
Test your classification not against the module you actually use, but against whether the legislature prescribed enhanced scrutiny for your product type. If your sectoral legislation permits internal control only subject to mandatory application of harmonised standards, assume you fall within the high-risk regime and plan your AI Act track accordingly.
Classification route for standalone high-risk AI systems under Article 6(2) and Annex III.
The intended purpose falls within a use case listed in Annex III.
A listed Annex III system may fall outside high-risk under the strict conditions in Article 6(3), except where it profiles. The assessment and registration must be documented.
The core rules in Chapter III, Sections 1 to 3, for systems under Article 6(2) and Annex III become applicable on 2 December 2027.
Amended Article 113, Article 6(2) and Annex III application date
The later application date does not remove the classification question. An early classification record avoids design and procurement decisions without evidence.
Document now the intended purpose, Annex III point, Article 6(3) assessment, profiling and selected registration path.
Article 6(2)-(4), Article 49 and Annex III
Quality and governance requirements for training, validation and test data of high-risk AI.
The high-risk system is trained with data; the provider composes the datasets, the deployer controls relevant input data.
For special categories of personal data the strict exception of Article 10(5) applies (bias detection and correction under conditions).
Article 10 requires datasets appropriate to the intended purpose, with governance over origin and composition, attention to representativeness, errors and completeness, and examination of possible bias with appropriate measures.
For the Annex III route this requirement applies from 2 December 2027; for high-risk AI in regulated products (Annex I) from 2 August 2028.
Today’s dataset choices determine whether compliance is feasible later: data bought or collected today without provenance records cannot be repaired in 2027.
Record origin and assumptions per dataset and include data quality as a requirement in every AI or data procurement contract.
The technical file demonstrating before market placement that a high-risk system meets the requirements.
The provider places a high-risk AI system on the market or puts it into service.
Small providers (SMEs) may provide the documentation in the simplified form established by the Commission.
Article 11 requires technical documentation drawn up before market placement, kept up to date and containing the Annex IV elements, so that compliance with Section 2 is demonstrable to supervisors.
For buying organisations, Annex IV is the checklist of what you must be able to request contractually from your supplier; without that file you cannot meet your own Article 26 duties.
Include the right to access the technical documentation in AI procurement and supplier contracts now.
Automatic recording of events over the lifetime of a high-risk AI system.
The system is high-risk; the provider designs the logging, provider and deployer retain the logs under their control.
The retention period may be limited by Union or national law, including data protection.
Article 12 requires high-risk AI systems to be technically capable of automatically recording events over their lifetime, for traceability, risk signalling and post-market monitoring; Article 19 and Article 26(6) govern log retention.
Article 12, Article 19 and Article 26(6)
Logging is the backbone of all other evidence: without logs an incident cannot be reconstructed and a monitoring duty cannot be fulfilled. Buyers should already test whether a system is technically capable of this.
Include logging capability and log access as a requirement in every AI purchase and assign the retention regime (who, where, how long) per system.
Article 13: transparency towards deployers
Comprehensible instructions for use and system information so deployers can operate the system correctly.
The provider supplies a high-risk system; the deployer uses it according to the instructions.
The level of detail may match the intended deployer’s knowledge; trade secrets need not be disclosed.
Article 13 requires high-risk systems to be designed transparently enough for deployers to interpret and use the output, with instructions covering purpose, accuracy, limitations, human oversight and maintenance.
The instructions are the hinge between provider and deployer duties: what the provider fails to supply here, the deployer cannot deliver under Article 26. Ask for it explicitly at procurement.
Translate received instructions per system into internal work instructions per role and record who received them.
High-risk AI must be designed so that humans can effectively oversee it and intervene.
The system is high-risk; the provider builds in oversight measures, the deployer assigns oversight to competent persons.
For remote biometric identification the reinforced requirement of verification by at least two authorised persons applies (Article 14(5)), with the exceptions listed there.
Article 14 requires high-risk systems to be effectively overseeable by natural persons, with measures enabling them to understand the system, correctly interpret output, remain aware of automation bias, and decide not to use, to disregard or to stop the system.
Oversight on paper is not oversight: the law names automation bias explicitly, so a human who may only click through does not count. Effective oversight requires understanding, time and mandate, which ties directly into the Article 4 literacy measures.
Appoint the overseeing persons per (upcoming) high-risk system now, train them specifically and record their mandate to intervene in writing.
Article 15: accuracy, robustness and cybersecurity
Appropriate levels of performance, robustness and security across the lifecycle of high-risk AI.
Systems that continue learning after deployment carry additional requirements to control feedback loops and drift.
Article 15 requires high-risk systems to achieve and maintain appropriate levels of accuracy, robustness and cybersecurity throughout the lifecycle, including resilience against errors and AI-specific attacks such as data poisoning and adversarial examples.
Accuracy here is not a marketing number but a declared, testable value stated in the instructions for use and held against you in production.
Ask suppliers now for declared accuracy levels and test reports, and set up production monitoring against those levels.
Article 16: the twelve duties of a provider of a high-risk AI system
Article 16 is the summary list of duties for providers: twelve points that route onward to the quality management system, the documentation, the logs, the conformity assessment, the EU declaration of conformity, the CE marking, the registration, corrective actions and accessibility requirements.
Applies to providers of high-risk AI systems. For the standalone Annex III route (Article 6(2)) the date is 2 December 2027. For systems embedded as a safety component in products covered by the Annex I harmonisation legislation (Article 6(1)) the date is 2 August 2028.
A provider that considers an Annex III system not to be high-risk must document that assessment before placing it on the market and remains subject to the registration obligation of Article 49(2) (Article 6(4)). Where an AI system referred to in Annex III performs profiling of natural persons it is always considered high-risk (Article 6(3), final subparagraph).
Article 16 requires providers of high-risk AI systems to do twelve things. They must ensure their systems comply with the requirements of Chapter III, Section 2 (point (a)); indicate on the system or, where that is not possible, on its packaging or accompanying documentation, their name, registered trade name or registered trade mark and the address at which they can be contacted (point (b)); have a quality management system in place complying with Article 17 (point (c)); keep the documentation referred to in Article 18 (point (d)); keep the automatically generated logs referred to in Article 19 when under their control (point (e)); ensure the system undergoes the conformity assessment procedure referred to in Article 43 prior to being placed on the market or put into service (point (f)); draw up an EU declaration of conformity in accordance with Article 47 (point (g)); affix the CE marking in accordance with Article 48 (point (h)); comply with the registration obligations referred to in Article 49(1) (point (i)); take the necessary corrective actions and provide the information required under Article 20 (point (j)); upon a reasoned request of a national competent authority, demonstrate conformity with the requirements of Section 2 (point (k)); and ensure the system complies with the accessibility requirements of Directives (EU) 2016/2102 and (EU) 2019/882 (point (l)).
Article 16 reads like a table of contents and is therefore often planned as a single roadmap line. It is twelve separate duties with widely differing lead times: building a quality management system takes months, affixing a CE marking takes a day. The bigger trap sits in Article 25(1): anyone who puts their own brand on an existing high-risk system, substantially modifies it, or changes the intended purpose of a non-high-risk system so that it becomes high-risk counts as a provider and inherits all twelve points without ever having built anything. In the branding scenario of point (a) this applies without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated, but you must have made and be able to show those arrangements in advance. In practice this catches parties that white-label AI or apply a general-purpose model to an Annex III use case.
First determine whether you are a provider or whether Article 25 makes you one, then work out the twelve points as twelve separate work packages with an owner and a date. Start with points (c) and (f), because they set the lead time of the whole track.
The documented quality system through which a high-risk AI provider structurally assures compliance.
The provider places high-risk AI systems on the market or puts them into service.
Providers already under sectoral quality regimes may integrate the AI elements into that existing system; SMEs may implement elements in simplified form.
Article 17 requires a documented quality management system covering a compliance strategy, design and development procedures, data management, risk management, post-market monitoring, incident reporting and an accountability structure.
The QMS is the umbrella over all other provider duties: those with the separate files but no system connecting them fail exactly this article in an audit.
Build the QMS not as a separate document but as an index on top of the existing files (risk, data, documentation, monitoring) with owners per procedure.
Before placing a system on the market the importer verifies four things about the provider, and afterwards carries its own retention, information and notification package with a ten-year term.
Applies to importers of high-risk AI systems. For the standalone Annex III route (Article 6(2)) the date is 2 December 2027; for the embedded Annex I route (Article 6(1)) the date is 2 August 2028.
If you put your own name or trade mark on the system, substantially modify it, or change the intended purpose so that it becomes high-risk, Article 25(1) treats you as a provider and the duties of Article 16 apply instead of those of Article 23.
Article 23(1) requires importers, before placing a high-risk AI system on the market, to verify that the relevant conformity assessment procedure referred to in Article 43 has been carried out by the provider (point (a)), that the provider has drawn up the technical documentation in accordance with Article 11 and Annex IV (point (b)), that the system bears the required CE marking and is accompanied by the EU declaration of conformity referred to in Article 47 and instructions for use (point (c)), and that the provider has appointed an authorised representative in accordance with Article 22(1) (point (d)). Article 23(2) provides that an importer with sufficient reason to consider that the system is not in conformity, is falsified or is accompanied by falsified documentation shall not place it on the market until it has been brought into conformity, and that where the system presents a risk within the meaning of Article 79(1) the importer shall inform the provider, the authorised representative and the market surveillance authorities. Paragraph 3 requires indication of name, registered trade name or registered trade mark and contact address. Paragraph 4 requires storage and transport conditions that do not jeopardise compliance with Section 2. Paragraph 5 requires keeping, for 10 years, a copy of the certificate issued by the notified body and, where applicable, of the instructions for use and of the EU declaration of conformity referred to in Article 47. Paragraph 6 requires providing all necessary information and documentation upon a reasoned request in a language easily understood by the authority, and ensuring the technical documentation can be made available. Paragraph 7 requires cooperation with the competent authorities.
Article 23 gets underestimated because it looks like document control, and largely it is: you do not have to revalidate the model, you have to be able to show that you checked the four points. The pain sits elsewhere. Point (d) is the one that most often fails in practice: many providers outside the EU have not appointed an authorised representative, and then you simply may not place the system on the market, however far along the deal is. And paragraph 5 puts the ten-year term on you, not on the supplier: if that supplier no longer exists in five years, you still have to produce the documents.
Move the four verifications of Article 23(1) to the moment before contract signature instead of before delivery. Request the declaration of conformity, the technical documentation, proof of the Article 43 procedure and the authorised representative's details as a condition precedent in the purchase contract.
Before making a system available on the market the distributor verifies the marking, the declaration and the instructions for use plus compliance by provider and importer, and must afterwards be able to correct, withdraw or recall.
Applies to distributors of high-risk AI systems. For the standalone Annex III route (Article 6(2)) the date is 2 December 2027; for the embedded Annex I route (Article 6(1)) the date is 2 August 2028.
If you put your own name or trade mark on the system, substantially modify it, or change the intended purpose so that it becomes high-risk, Article 25(1) treats you as a provider and the duties of Article 16 apply instead of those of Article 24.
Article 24(1) requires distributors, before making a high-risk AI system available on the market, to verify that it bears the required CE marking, that it is accompanied by a copy of the EU declaration of conformity referred to in Article 47 and instructions for use, and that the provider and the importer of that system, as applicable, have complied with their obligations laid down in Article 16, points (b) and (c), and Article 23(3). Paragraph 2 prohibits making the system available while the distributor considers or has reason to consider, on the basis of the information in its possession, that it does not comply with the requirements of Section 2, and requires notification of the provider or the importer where the system presents a risk within the meaning of Article 79(1). Paragraph 3 requires storage and transport conditions that do not jeopardise compliance. Paragraph 4 requires a distributor that considers or has reason to consider that a system already made available does not comply with Section 2 to take the corrective actions necessary to bring it into conformity, to withdraw it or recall it, or to ensure that the provider, the importer or any relevant operator takes those actions; where the system presents a risk within the meaning of Article 79(1) it shall immediately inform the provider or importer and the competent authorities, giving details of the non-compliance and of any corrective actions taken. Paragraph 5 requires providing, upon a reasoned request, all information and documentation regarding actions taken under paragraphs 1 to 4. Paragraph 6 requires cooperation with the competent authorities.
The check in paragraph 1 looks light but contains an awkward element: you must also verify that the provider has complied with Article 16, point (c), which is having a quality management system in place under Article 17. You cannot see that on the packaging. In practice you anchor it in supplier terms with a statement from the provider and record what you checked. The centre of gravity of Article 24 sits in paragraph 4 though: many resellers assume recall is the manufacturer's business, while the provision also places that action on you, with the option of ensuring another party carries it out. That ensuring requires contractual grip arranged in advance, not during an incident.
Include the three checks of paragraph 1 in your resell or delivery process and keep a record per contract of what you saw. Also make sure you can tell within a day which customer uses which system in which version, because without that overview you cannot execute paragraph 4.
Article 26: obligations of deployers of high-risk AI systems
Twelve paragraphs governing day-to-day use: use in line with the instructions, human oversight by competent people, input data, monitoring and notification, log retention, informing workers before deployment, registration by public authorities and informing the people about whom decisions are made.
Applies as soon as you use a high-risk AI system under your own authority (Article 3(4)), whether you built it yourself or procured it. For the standalone Annex III route (Article 6(2)) the date is 2 December 2027; for the embedded Annex I route (Article 6(1)) the date is 2 August 2028.
Article 2(10) excludes natural persons using an AI system in the course of a purely personal, non-professional activity. For deployers that are financial institutions subject to internal governance requirements under Union financial services law, the monitoring obligation in paragraph 5 is deemed fulfilled by complying with those rules, and the logs under paragraph 6 are maintained as part of the documentation kept under that law.
Article 26 imposes twelve paragraphs on deployers of high-risk AI systems. Paragraph 1 requires appropriate technical and organisational measures to ensure use in accordance with the accompanying instructions for use. Paragraph 2 requires assigning human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support. Paragraph 3 leaves other obligations and the freedom to organise one's own resources unaffected. Paragraph 4 requires, to the extent the deployer exercises control over the input data, that such data is relevant and sufficiently representative in view of the intended purpose. Paragraph 5 requires monitoring on the basis of the instructions for use and informing the provider in accordance with Article 72; where there is reason to consider that use may result in a risk within the meaning of Article 79(1), the deployer shall without undue delay inform the provider or distributor and the relevant market surveillance authority and suspend use, and upon identifying a serious incident shall immediately inform first the provider and then the importer or distributor and the market surveillance authorities. Paragraph 6 requires keeping the automatically generated logs under the deployer's control for a period appropriate to the intended purpose and of at least six months, unless Union or national law provides otherwise. Paragraph 7 requires deployers who are employers to inform workers' representatives and the affected workers, before putting into service or using the system at the workplace, that they will be subject to its use. Paragraph 8 imposes the registration obligations of Article 49 on public authorities and Union institutions, bodies, offices and agencies and prohibits use of a system not registered in the EU database referred to in Article 71. Paragraph 9 links the information provided under Article 13 to the data protection impact assessment under Article 35 of Regulation (EU) 2016/679. Paragraph 10 sets additional conditions for post-remote biometric identification in law enforcement. Paragraph 11 opens with the words without prejudice to Article 50 of this Regulation and requires deployers of Annex III systems that make or assist in making decisions related to natural persons to inform those persons that they are subject to the use of the system; for high-risk AI systems used for law enforcement purposes Article 13 of Directive (EU) 2016/680 applies. The transparency obligations of Article 50 have applied since 2 August 2026 and are separate from the date on which paragraph 11 starts to apply. Paragraph 12 requires cooperation with the competent authorities.
The 2 December 2027 date invites postponement, but two elements are preparation work today. Paragraph 7 requires you to inform workers' representatives and the affected workers before the system is put into service at the workplace, and that information is provided, where applicable, in line with existing rules and practice on informing workers. That touches employee participation, and such a process takes months rather than weeks in practice, so a system that must go live in 2027 is discussed in 2026. Paragraph 2 also connects to the human oversight that Article 14 imposes on system design: you must designate natural persons with competence, training, authority and support. That is emphatically not the same as the measures obligation in Article 4. Article 4 requires measures supporting AI literacy and does not require you to guarantee a particular level for individuals; Article 26(2) requires identifiable overseers with a mandate. Conflating the two leaves you believing a generic e-learning is enough while still having no overseer with room to decide. A third underestimated element is paragraph 11: informing the people about whom an Annex III system makes or helps make decisions is visible customer or candidate communication that you have to design across your own organisation.
Draw up now a list of the systems likely to qualify as high-risk from 2 December 2027 and add three columns: who exercises human oversight and with what mandate, when you will inform the works council and the affected workers, and how the persons concerned will receive the notice under paragraph 11. Plan the employee participation process a year ahead.
Fundamental rights impact assessment before deploying certain high-risk AI systems.
The system is high-risk under Article 6(2) and Annex III, excluding Annex III point 2.
The deployer is a body governed by public law, a private provider of public services or uses a relevant system in Annex III point 5(b) or 5(c).
In the situation covered by Article 46(1), an exemption from notification may apply. This does not generally remove the assessment itself.
The listed deployers must perform a FRIA before deployment. For this Annex III route, the obligation follows the application date of 2 December 2027.
Amended application schedule and Article 27 DPIA cross-reference
A FRIA is not a generic risk assessment for every AI system. First establish the system route, Annex III category and type of deployer.
Link the FRIA to the AI inventory and, where relevant, the DPIA. Keep scope, affected groups, mitigations, residual risks and notification in one versioned record.
Article 27 amendment on DPIA inclusion or cross-reference
Providers and deployers take measures that support the development of AI literacy.
The organisation is a provider or deployer of an AI system within scope.
The provision does not require a specific individual level to be guaranteed.
Since 27 July 2026, providers and deployers must take measures supporting the development of AI literacy. The provision does not require a guaranteed individual level.
Amendment of Article 4; entry into force 27 July 2026
Evidence is primarily a proportionate record of measures by role and context, not one prescribed course or certificate.
Questions on measures, formats, certificates and records
Inventory roles and AI systems, select appropriate measures and record the choice, implementation and periodic review.
Implementation examples and evidence guidance
The prohibition of AI practices carrying unacceptable risk, such as manipulation, social scoring and certain biometric applications.
Placing on the market, putting into service or using AI falls under one of the practices in Article 5(1), including harmful manipulation or exploitation of vulnerabilities, social scoring, predicting criminal offences based on profiling, untargeted scraping of facial images, emotion recognition in the workplace or education, biometric categorisation by sensitive characteristics and real-time remote biometric identification in publicly accessible spaces for law enforcement.
The exceptions are narrow: among others, emotion recognition for medical or safety reasons, and the exhaustively defined law-enforcement situations with authorisation for real-time remote biometric identification in Article 5(2) to (7). The exception must be established and documented in advance.
The prohibited practices of Article 5 apply since 2 February 2025 and are the only AI Act category enforceable for that entire period. Violations carry the highest fine ceiling in the regulation: up to 35 million euro or 7 percent of worldwide annual turnover.
Article 5, Article 99(3) and Article 113(a)
The Digital Omnibus adds a prohibition on AI for child sexual abuse material and non-consensual intimate synthetic content; the accompanying technical safeguards are required by 2 December 2026.
Amendment to Article 5 and transition to 2 December 2026
The line often sits in the definitional details: the same technique can be prohibited in the workplace and permitted in another context. Screen per concrete use and context, not per technology, and do so before procurement or go-live.
Make the Article 5 screening the first step of every classification and record the outcome per system in the register, including the reasoning why a practice does not fall under the prohibition.
Article 5 read with Article 6 classification order
Specific disclosure, marking and labelling duties for certain AI systems and synthetic content.
An AI system is intended to interact directly with natural persons.
The system generates or manipulates synthetic audio, image, video or text, or the use concerns a specifically listed deployer scenario.
The direct-interaction disclosure is not required where this is obvious to a reasonably well-informed, observant and circumspect person, considering circumstances and context.
Only Article 50(2) has a transition until 2 December 2026 for systems placed on the market before 2 August 2026.
Article 50 applies since 2 August 2026. The precise duty differs by scenario: direct AI interaction, machine-readable marking, emotion recognition or biometric categorisation, deepfakes and certain public-interest text.
A generic rule that all AI content must always carry a visible label is too broad. First classify the specific Article 50 scenario.
Final guidelines, scope by Article 50 paragraph
For each system, record the applicable paragraph, responsible actor, implemented disclosure or marking and how it was tested.
Implementation guidance for providers and deployers
Documentation, information, copyright and transparency duties for providers of general-purpose AI models.
The party is a provider of a GPAI model placed on the Union market.
For models placed on the market from 2 August 2025, the duties apply from that time. Models placed on the market before 2 August 2025 must comply by 2 August 2027.
The open-source exception is limited and retains, among other things, the copyright policy and public training-content summary. Additional duties apply to models with systemic risk.
Article 53 applies since 2 August 2025 to new GPAI models. Providers maintain technical documentation, provide information to downstream providers, operate a Union copyright policy and publish a sufficiently detailed summary of training content.
Providers of GPAI models placed on the market before 2 August 2025 must comply with the applicable obligations by 2 August 2027.
An organisation merely using an external GPAI model does not thereby automatically become a GPAI model provider. First determine its role in the value chain.
Scope and provider qualification guidance
Record model versions, role qualification, documentation owners, downstream information, copyright policy and training summary in one change-controlled file.
Article 55: GPAI models with systemic risk
Additional duties for the most capable general-purpose AI models, on top of Article 53.
The GPAI model has high-impact capabilities, presumed above 10^25 FLOPs of cumulative training compute, or is designated by the Commission.
The GPAI Code of Practice can, following the adequacy assessment, serve as a means to demonstrate compliance.
Article 55 obliges providers of GPAI models with systemic risk to perform model evaluations including adversarial testing, assess and mitigate systemic risks at Union level, track and report serious incidents, and ensure adequate cybersecurity of model and infrastructure. The duties apply since 2 August 2025; AI Office enforcement is active since 2 August 2026.
Article 55(1)-(2) with Article 51 and Article 52
The 10^25 FLOPs threshold is a presumption, not a shield: the Commission can also designate models on capabilities, and fine-tuning on top of an existing model can in some circumstances trigger a qualification of its own.
Model providers near the threshold: set up compute monitoring now and join the Code of Practice to carry the burden of proof.
Member States must provide at least one national AI regulatory sandbox. For you this is a voluntary route: you develop, train, test and validate an innovative AI system in a controlled, supervised environment under a plan agreed with the competent authority, before placing it on the market or putting it into service.
Relevant where you are a provider or prospective provider of an innovative AI system that you want to develop, train, test or validate before placing it on the market or putting it into service, and you want up-front certainty about classification or about how you meet the requirements of this Regulation.
Participation is voluntary. Article 57 places the duty on the Member State to provide a sandbox, not on you to join one. A Member State may also fulfil that duty by participating in an existing sandbox with equivalent national coverage. Article 57(4) leaves other regulatory sandboxes established under Union or national law unaffected.
Article 57(1) requires Member States to ensure that their competent authorities establish at least one AI regulatory sandbox at national level. The text of Regulation (EU) 2024/1689 as published in the Official Journal provides that the sandbox shall be operational by 2 August 2026, and that wording still stands unchanged on 9 August 2026 in the article text published by the European Commission. The timeline the European Commission publishes after the Digital Omnibus, Regulation (EU) 2026/1744, entered into force on 27 July 2026 places the milestone at 2 August 2027 instead, stating "Member States should have at least one AI regulatory sandbox per country operational". The consolidated text of Article 57(1) after the Omnibus has not been verified at article level; rely on the consolidated version on EUR-Lex for the exact date. Chapter VI, which contains Article 57, is not among the exceptions in Article 113 and therefore applies since 2 August 2026. Article 57(1) further provides that the obligation may also be fulfilled by participating in an existing sandbox, in so far as that participation provides an equivalent level of national coverage. Article 57(5) defines the sandbox as a controlled environment that fosters innovation and facilitates the development, training, testing and validation of innovative AI systems for a limited time, pursuant to a specific sandbox plan agreed between the provider or prospective provider and the competent authority, before the system is placed on the market or put into service. Such sandboxes may include testing in real world conditions supervised therein. Article 57(15) requires the AI Office to make publicly available, and keep up to date, a list of planned and existing sandboxes.
Article 57(1)-(17), Article 58, Article 113; as amended by Regulation (EU) 2026/1744
The common mistake is to read the sandbox as a delay or an exemption. It is neither. Article 57(11) leaves the competent authority's supervisory and corrective powers fully intact and expressly empowers it to suspend your testing or your participation, temporarily or permanently, where risks cannot be effectively mitigated. A sandbox is useful for exactly one profile: you are building an AI system that is likely to fall under Annex III, you are uncertain about its classification or about how to meet Chapter III, Section 2, and you want that uncertainty resolved before you go to market. If you are purely a deployer buying a system, the sandbox is not your route: at most you can join as a partner of the provider under Article 58(2), point (b). Second trap: 2 August 2027 is a duty on the Member State, not on you. The date on this item is therefore 2 August 2026: from that moment Chapter VI applies and the route is open to you. You cannot hang your own preparation on that date, and the date says nothing about whether your national sandbox will actually have capacity by then. Third trap: people confuse the Article 57 sandbox with Article 60 real-world testing. These are two distinct routes with different conditions. Real-world testing can take place inside the sandbox (Article 57(5) and Article 58(4)) or outside it under Article 60, and the safeguards differ.
First establish your role: only providers and prospective providers can enter on their own. Then use the AI Office's published list of planned and existing sandboxes (Article 57(15)) to find the sandbox open to you, in your Member State or jointly with others. Before you apply, state exactly which uncertainty you want resolved, ideally focused on classification under Article 6 or on a specific requirement in Chapter III, Section 2. Plan for the three-month decision period that Article 58(2), point (a), requires the implementing acts to ensure, build it into your product timeline, and ask the competent authority in writing which period it currently applies. On entry, record in writing what the sandbox plan covers, and on exit request both the written proof and the exit report.
Article 60: testing in real world conditions outside a sandbox
If you want to test an Annex III high-risk AI system with real people and real outcomes before placing it on the market, a full regime applies: a plan, prior approval by the market surveillance authority, registration, informed consent and a maximum duration.
Applies where you are a provider or prospective provider of an Annex III high-risk AI system and you want to test it in real world conditions outside an AI regulatory sandbox, before placing it on the market or putting it into service. If you are established outside the Union, Article 60(4), point (d), requires you to appoint a legal representative established in the Union; that is a different figure from the authorised representative under Article 22.
Article 60(1), third subparagraph, leaves Union and national law on real-world testing of high-risk systems related to products under the Annex I harmonisation legislation unaffected. Article 60(4), point (i), contains a law enforcement carve-out: where seeking informed consent would prevent the system from being tested, testing may proceed without consent, provided the testing and its outcome have no negative effect on the subjects and their personal data are deleted after the test. For the systems referred to in Annex III, points 1, 6 and 7, in law enforcement, migration, asylum and border control, registration runs through the secure non-public section of the EU database under Article 49(4), point (d). For the systems referred to in Annex III, point 2, Article 49(5) requires registration at national level.
Article 60(1) provides that testing of high-risk AI systems in real world conditions outside AI regulatory sandboxes may be conducted by providers or prospective providers of high-risk AI systems listed in Annex III, in accordance with that Article and the real-world testing plan, without prejudice to the prohibitions under Article 5. The Commission specifies the detailed elements of that plan by implementing act. The third subparagraph of paragraph 1 provides that the paragraph is without prejudice to Union or national law on the testing in real world conditions of high-risk AI systems related to products covered by the Union harmonisation legislation listed in Annex I. Article 60(2) allows providers or prospective providers to test at any time before placing on the market or putting into service, on their own or in partnership with one or more deployers or prospective deployers. Article 60(3) provides that such testing is without prejudice to any ethical review required by Union or national law. Article 60(4), point (f), caps the duration: no longer than necessary to achieve its objectives and in any case no longer than six months, which may be extended by an additional six months subject to prior notification to the market surveillance authority with an explanation of the need. Article 60(4), point (g), requires that subjects belonging to vulnerable groups due to age or disability are appropriately protected. Article 60(9) expressly states that the provider or prospective provider remains fully subject to applicable Union and national law on any damage caused in the course of their testing in real world conditions. Chapter VI, which contains Article 60, is not among the exceptions in Article 113 and applies since 2 August 2026.
Article 60(1)-(4), Article 60(9), Article 113
Many organisations call what they do a pilot and assume that keeps them outside the Regulation. Article 60 shows that this does not hold once you test an Annex III system in real world conditions with real people and real outcomes. A full regime then applies: a plan, prior approval, registration with a Union-wide unique single identification number, informed consent, and a hard six-month clock with a maximum six-month extension. The heaviest requirement in practice is Article 60(4), point (k): the predictions, recommendations or decisions of the system must be capable of being effectively reversed and disregarded. If you are testing a selection, scoring or triage system whose output feeds straight into the workflow with nobody able to reverse it, your design does not qualify, however careful your consent form is. Note the timing too, because it is commercially interesting. Chapter VI applies since 2 August 2026, while the core obligations for standalone Annex III systems only apply from 2 December 2027. The testing route is therefore open before the requirements themselves bite, and that is exactly the window in which to validate your design rather than rebuild it later. Finally, Article 60(3) leaves any ethical review required under other law fully in place, and Article 60(9) expressly states that you remain fully subject to the applicable law on damage caused during the testing.
Inventory which running or planned trials are in fact real-world testing: real users, real data, outputs that feed into the workflow. Test those first against Article 60(4), point (k): can the output genuinely be reversed and disregarded? If not, redesign the trial before you submit anything. Then choose deliberately between two routes: supervised testing inside a sandbox under Article 57(5) and Article 58(4), or outside a sandbox under Article 60. Plan the six months realistically and decide in advance at which point you will request an extension, since that requires prior notification with a reasoned explanation. Check whether an ethical review is mandatory in your domain and start it in parallel, because Article 60(3) does not exempt you from it.
Systematic monitoring of high-risk AI in real use, after market placement.
The provider has a high-risk system on the market; deployers supply the real-world data via monitoring and signals.
The plan may be proportionate to the nature of the system and align with existing sectoral monitoring regimes.
Article 72 obliges providers to operate a post-market monitoring system with a plan forming part of the technical documentation, collecting relevant real-world data to evaluate continued compliance with Section 2.
Compliance does not stop at go-live: this article turns compliance into a continuous state. For deployers it is also the basis to force suppliers to act on deviations.
Design the monitoring together with the Article 12 logging: the same data flows feed both duties.
The duty to report serious incidents with high-risk AI, under strict deadlines.
A serious incident occurs with a high-risk system: death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of fundamental-rights protections or serious damage to property or environment.
For systems under sectoral reporting regimes with equivalent duties, reporting may run through that regime to avoid duplication.
Article 73 obliges providers to report serious incidents to the market surveillance authority: immediately after establishing the causal link and at the latest within 15 days, shortened to 10 days in the event of death and to 2 days for widespread infringement or serious disruption of critical infrastructure. Deployers inform the provider without delay.
The deadlines are too short to design the process during the incident: those who decide who reports at the first incident will not make 15 days, let alone 2. This is the GDPR breach playbook, but for AI.
Connect the AI incident process to the existing breach and security process and add the AI-specific definitions and deadlines.
Article 85: right to lodge a complaint with the market surveillance authority
Anyone with grounds to consider that the Regulation has been infringed may lodge a complaint with the relevant market surveillance authority. For an organisation that means your own staff, customers and candidates have a route to the regulator that does not run through you.
Applies as soon as anyone has grounds to consider that the Regulation has been infringed. There is no standing threshold: the right belongs to any person, and the complaint goes to the market surveillance authority of the Member State concerned.
Without prejudice to other administrative or judicial remedies, any natural or legal person having grounds to consider that there has been an infringement of the provisions of this Regulation may submit complaints to the relevant market surveillance authority. In accordance with Regulation (EU) 2019/1020, such complaints shall be taken into account for the purpose of conducting market surveillance activities, and shall be handled in line with the dedicated procedures established therefor by the market surveillance authorities.
The practical meaning of this article lies not in what it instructs you to do but in whom it gives a route. An employee who thinks the scheduling or appraisal system is wrong, a rejected candidate, a customer who feels mishandled: they do not have to convince you first and do not have to show standing. The complaint arrives at the authority, and the first question you then face is about record keeping: which system, which version, which assessment was carried out and when. That is the same record keeping Articles 26 and 72 already require of you, and that is exactly the point. Whoever has that file answers a complaint with documents; whoever does not answers it with a reconstruction after the fact, and a regulator reads that differently. Note too that this right does not depend on harm or on a decision, whereas the right to an explanation in Article 86 does.
Assume a complaint starts at the authority and not with you. Make sure that per AI system you can show which assessment was carried out, by whom, on what date and against which system version, and keep that as a living file rather than a one-off document. Also agree internally who receives a question from an authority and within what period.
Article 86: right to an explanation of a decision
A person affected by a decision that a deployer takes on the basis of the output of a high-risk AI system listed in Annex III may request an explanation of the role of that system in the decision-making procedure and of the main elements of the decision taken.
Applies where a deployer takes a decision about a natural person on the basis of the output of a high-risk AI system listed in Annex III, with the exception of point 2 of that Annex, and that decision produces legal effects or similarly significantly affects that person in a way they consider to have an adverse impact on their health, safety or fundamental rights.
Paragraph 2 excludes the right for AI systems where exceptions from, or restrictions to, that obligation follow from Union or national law in compliance with Union law. Paragraph 3 further limits the right to cases where it is not otherwise provided for under Union law, which makes the boundary with Article 22 GDPR a case-by-case question.
Paragraph 1 gives any affected person subject to a decision taken by the deployer on the basis of the output of a high-risk AI system listed in Annex III, with the exception of point 2 of that Annex, and which produces legal effects or similarly significantly affects that person in a way that they consider to have an adverse impact on their health, safety or fundamental rights, the right to obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision-making procedure and of the main elements of the decision taken. Paragraph 2 provides that paragraph 1 does not apply to the use of AI systems for which exceptions from, or restrictions to, that obligation follow from Union or national law in compliance with Union law. Paragraph 3 provides that this Article applies only to the extent that the right referred to in paragraph 1 is not otherwise provided for under Union law.
This right reaches you through a different channel than the rest of the Regulation. A regulator writes to you; a candidate or a citizen calls or emails, usually at your existing complaints or objections desk. That desk does not know today that an AI system was in the process, let alone what role it played, and that is where it goes wrong. Two things therefore matter more than the legal depth of the explanation itself: that your front line recognises such a request, and that it can be traced per decision which system in which version contributed to it. Without the second you can explain how your system works in general but not what happened in this case, and the latter is what is being asked. Note also the relationship with Article 22 GDPR: where that article already grants a right, Article 86 steps back, but the scope differs enough that you cannot settle the question in the abstract.
Record, per Annex III system that contributes to decisions about people, which decision was supported by which system version, and make sure your complaints or objections desk recognises a request for an explanation and routes it to someone who can answer it. Also determine per process whether Article 22 GDPR already grants a right, because Article 86 then steps back.
A continuous, documented risk management system across the entire lifecycle of a high-risk AI system.
The system is high-risk under Article 6 and the provider places it on the market or puts it into service.
Risks arising only from misuse beyond any reasonably foreseeable use fall outside the mandatory scope.
Article 9 requires a risk management system as a continuous, iterative process across the entire lifecycle, with identification, analysis, evaluation and mitigation of risks to health, safety and fundamental rights, and testing to determine the most appropriate measures.
This is not a one-off risk analysis but a living process: most organisations have an assessment, but no cycle that reruns on every change. The cycle is what a supervisor will request.
Start the risk management file now for systems that will become high-risk towards 2 December 2027: today’s design and procurement choices determine tomorrow’s residual risks.
Articles 43-49: conformity assessment, CE and registration
The route from assessment to CE marking and EU database registration before market placement of high-risk AI.
The provider places a high-risk system on the market; public deployers also register their use.
For most Annex III systems internal control suffices (Annex VI); a notified body is required for certain biometrics and where harmonised standards are lacking.
Article 43 governs the conformity assessment, Article 47 the EU declaration of conformity, Article 48 the CE marking and Article 49 the registration in the EU database before market placement or putting into service, including registration of the Article 6(3) assessment.
For buyers this is the simplest supplier check there is: ask for the declaration of conformity and the registration number. No declaration means the system may not be there by 2 December 2027.
Plan the conformity route backwards from 2 December 2027: standards selection, assessment, declaration and registration together take months, not weeks.
Articles 22-25: value chain and authorised representative
Role shifts in the AI value chain and the mandatory representative for non-EU providers.
A high-risk system is supplied, modified, rebranded or placed on the Union market from outside the EU.
Those acting solely as distributor or importer without the Article 25 triggers remain in that lighter role, with their own verification duties.
Article 25 provides that a distributor, importer, deployer or third party becomes the provider when it puts its name on a high-risk system, substantially modifies it or changes its intended purpose so it becomes high-risk; Article 22 obliges third-country providers to appoint a written authorised representative in the Union.
The most dangerous role switch is the unintended one: your own layer on top of a procured model, your own brand on a tool, and you suddenly carry the full provider duties. This belongs as a standing question in every AI project.
Include the role question in the AI register and in project gates, and contractually define who supplies which information and cooperation on changes.
EN 18286:2026: quality management system for EU AI Act regulatory purposes
The first completed European standard under the AI Act standardisation request: the quality management system that Article 17 requires from providers of high-risk AI systems.
Relevant to providers of high-risk AI systems, who must have a quality management system in place by 2 December 2027 (Annex III standalone) or 2 August 2028 (Annex I embedded in regulated products).
According to that same coverage statement the standard does not cover Article 17(2) to (4) or Article 72; those obligations must be substantiated independently.
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.
This is the first time the AI Act quality requirements exist as an auditable normative text, which is worth more than its legal status suggests. The common trap runs the other way: people read "first harmonised standard" and assume compliance now carries evidentiary weight. As long as the reference is not in the Official Journal, EN 18286 is simply a well-structured document with no legal presumption. You still carry the burden of showing your system meets Article 17. Conversely, anyone building on this structure now will not have to rebuild after citation.
Use the clause structure of EN 18286 as the table of contents for your quality dossier: separate the organisational clauses (governance, leadership, planning, support, management review) from the per-system clauses (lifecycle, operations, post-market monitoring, incident handling). Record which internal document evidences each clause. Note explicitly that Article 17(2) to (4) and Article 72 fall outside the standard and must be substantiated separately.
EN ISO/IEC 42001: artificial intelligence management system
The certifiable organisation-level AI management system, a European standard since 2026, but not a harmonised standard under the AI Act.
Usable by both providers and deployers seeking to structure AI governance organisation-wide.
Certification against ISO/IEC 42001 replaces no AI Act obligation and does not shift the burden of proof.
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.
EN ISO/IEC 42001:2026, European adoption via CEN-CENELEC
This is the most expensive misconception in the whole standards layer: an ISO/IEC 42001 certificate is not AI Act conformity. The certificate shows you have a governance structure, not that a specific high-risk system meets the regulation. Documented gaps against Article 17 include the absence of a per-system regulatory compliance strategy, of predetermined change management for continuously learning systems, of the Article 73 serious incident reporting timelines, and of a structured fundamental rights assessment. Vendors saying "ISO 42001 certified, therefore AI Act ready" are selling you a certificate, not your dossier.
Use ISO/IEC 42001 as the organisational layer (policy, roles, management review, internal audit) and put the per-system layer on top: a dedicated dossier per high-risk system along the clauses of EN 18286. Deliberately close the gaps named above: per-system compliance strategy, predetermined change management, incident reporting process with the Article 73 timelines, and fundamental rights assessment. In procurement, ask not for the certificate but for the statement of applicability and the audit report.
ISO/IEC 12792: transparency taxonomy of AI systems
The international taxonomy of transparency information elements, usable as a checklist for the Article 13 instructions for use.
ISO/IEC 12792:2025 (Information technology: Artificial intelligence: Transparency taxonomy of AI systems) was published in November 2025 by ISO/IEC JTC 1/SC 42. It specifies a taxonomy of information elements to help stakeholders identify and address transparency needs, and describes the semantics of those elements and their relevance to different stakeholders' objectives. The text was adopted as a European standard as EN ISO/IEC 12792:2025. It is not cited in the Official Journal and therefore confers no presumption of conformity under Article 40. For Article 13 the designated deliverable is prEN 18229-3.
The value lies in the completeness check: the taxonomy shows which information elements you can forget, and that is exactly where instructions for use fall short in practice. What it is not: a template that satisfies Article 13. The regulation itself determines what the instructions for use must contain, including the provider's details, characteristics and limitations, accuracy metrics, oversight measures and expected lifetime. Also watch the confusion with Article 50: those transparency obligations have applied since 2 August 2026 and fall on providers of AI systems that interact directly with natural persons or generate synthetic content, and on deployers of emotion recognition, biometric categorisation and deepfakes. They apply regardless of high-risk classification. For systems already placed on the market before 2 August 2026, the machine-readable marking under Article 50(2) has a transition until 2 December 2026.
Structure your instructions for use as a numbered list following the elements of Article 13(3) one for one, and use the ISO/IEC 12792 taxonomy alongside it as a checklist for missing elements. Keep Article 50 transparency information separate, since it addresses the end user rather than the deployer.
ISO/IEC 23894: guidance on risk management for AI
The international guidance for AI-specific risk management, usable as an interim structure while prEN 18228 remains in draft.
ISO/IEC 23894:2023 (Information technology: Artificial intelligence: Guidance on risk management) was published in February 2023 and is the first international standard dealing specifically with risk management for AI. It is non-prescriptive and built on the ISO 31000 structure. The text was adopted by CEN-CENELEC as EN ISO/IEC 23894:2024. It is not cited in the Official Journal and therefore confers no presumption of conformity under Article 40 of the AI Act. The deliverable intended to do so for Article 9 is prEN 18228.
EN ISO/IEC 23894:2024, European adoption via CEN-CENELEC
ISO/IEC 23894 gives you the vocabulary and process flow of AI risk management, and that is usable today. Where it falls short: it is guidance, not a requirements set, and it is written from organisational risk while Article 9 starts from risk to the health, safety and fundamental rights of others. A risk register built entirely along ISO/IEC 23894 therefore does not automatically cover Article 9. Use it as scaffolding, not as evidence.
Adopt the ISO/IEC 23894 process flow (context, identification, analysis, evaluation, treatment, monitoring, recording) and add two AI Act-specific fields per risk: who outside your organisation can be affected, and what residual risk you deem acceptable on what justification. That lets you connect the register to the final EN 18228 without rebuilding it.
ISO/IEC 24029 series: assessment of the robustness of neural networks
The international series making neural network robustness testable, usable as methodology under Article 15 while prEN 18229-2 remains in draft.
Particularly relevant to high-risk systems based on neural networks.
ISO/IEC TR 24029-1:2021 (Assessment of the robustness of neural networks, Part 1: Overview) is a technical report mapping the topic and available assessment methods. ISO/IEC 24029-2:2023 (Part 2: Methodology for the use of formal methods) describes the application of formal methods in assessing robustness. The series is aimed at AI developers and users assessing robustness across the lifecycle. Neither part is cited in the Official Journal, so no presumption of conformity under Article 40 arises. For Article 15 the designated deliverable is prEN 18229-2, which as at June 2026 was still in drafting.
Part 1 is a technical report and therefore not a requirements set: it gives an overview, not a benchmark. Part 2 is the sharper text substantively, but formal methods are only feasible for relatively bounded models. For large generative models you hit the limits quickly, leaving empirical testing. The trap is making a robustness claim measured only on the average test set: Article 15 is specifically about behaviour under errors, faults and unexpected input.
Choose deliberately per system between formal verification (for bounded models) and empirical stress testing, and record the choice and its justification. Test explicitly on out-of-distribution input, missing fields and edge cases, and document the performance degradation observed. Add those results to the technical documentation and to the instructions for use where they define the limits of use.
ISO/IEC 5259 series: data quality for analytics and machine learning
The five-part international series on data quality, in practice the most usable structure for the Article 10 data governance dossier.
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.
ISO/IEC 5259 series, ISO/IEC JTC 1/SC 42
This is currently the most concrete help available for Article 10, because part 2 actually makes data quality measurable rather than merely discussing it. What it is not: coverage of Article 10. The regulation asks for things the series does not address, such as examination for possible bias with a view to fundamental rights and representativeness for the specific intended user population in the EU. A dataset scoring well on every 5259 measure can still structurally under-represent a population group.
Use part 2 to fix a small number of hard quality measures per dataset and part 4 to describe the process that maintains them. Add two AI Act fields the series does not cover: representativeness for the intended user population, and the outcome of the bias examination with the measures taken. Retain the measurement results per dataset version, not only for the latest version.
prEN 18228: AI risk management for high-risk systems
The draft European standard filling in the Article 9 risk management system, built on a product-safety logic rather than an enterprise-risk logic.
Relevant to providers preparing for the high-risk obligations applying from 2 December 2027 (Annex III) or 2 August 2028 (Annex I).
prEN 18228 (AI risk management) is the JTC 21 deliverable under M/613 intended to confer presumption of conformity with Article 9 of the AI Act: the risk management system that providers of high-risk AI systems must establish, implement, document and maintain across the full lifecycle. The public Enquiry ran until 30 July 2026. The standard has not yet been published as an EN and is not cited in the Official Journal. The prEN designation means it is a draft text.
prEN 18228 (draft standard), CEN/CLC/JTC 21 under M/613
The distinguishing feature is the perspective. prEN 18228 is written from product safety: it concerns risks to the health, safety and fundamental rights of third parties, not risks to your organisation. Anyone filling an Article 9 dossier with an existing ISO 31000 or ERM register makes exactly the mistake this standard exposes: that register looks inward, Article 9 looks outward. And a draft standard is not yet evidence: you can adopt the method, but you cannot prove anything with it towards a supervisory authority today.
Build your Article 9 risk register now with an outward view: for each foreseeable use and foreseeable misuse, name the person or group who can be affected, the measure that reduces the risk, and the residual risk that remains. Keep the structure separate from your ERM register so the final EN 18228 can be mapped over it later without rewriting the content.
prEN 18229-1: AI trustworthiness framework part 1, logging
The draft European standard for the automatic event recording that Article 12 requires of high-risk AI systems.
Providers build in the logging capability (Article 12) and keep the logs under their control (Article 19); deployers retain the logs generated by the system (Article 26(6)).
prEN 18229-1 (AI trustworthiness framework, Part 1: Logging) is the JTC 21 deliverable under M/613 for Article 12 of the AI Act: high-risk AI systems must technically allow for the automatic recording of events over their lifetime. As at June 2026 the deliverable was at the Enquiry stage. It has not yet been published as an EN and is not cited in the Official Journal.
prEN 18229-1 (draft standard), CEN/CLC/JTC 21 under M/613
Article 12; Article 19; Article 26(6); Article 40
Logging is the obligation that is cheapest to get right now and most expensive to repair later, because a system that does not log cannot start logging retroactively. Mind the split of roles: the provider must build in the logging capability, the deployer must retain the logs. Buying a system without checking whether it logs means buying a hole in your own dossier. This standard is still a draft text and therefore carries no evidentiary weight yet.
Put the logging requirement in your procurement terms and in the acceptance test: which events are recorded, with what timestamp, how long they are retained, and how you export them to a supervisory authority. Document those answers per system now, so the final EN 18229-1 only needs to be mapped against what you already record.
prEN 18229-2: AI trustworthiness framework part 2, accuracy and robustness
The draft European standard meant to make the appropriate level of accuracy and robustness under Article 15 measurable.
prEN 18229-2 (AI trustworthiness framework, Part 2: Accuracy and robustness) is the JTC 21 deliverable under M/613 for Article 15 of the AI Act, which requires high-risk AI systems to achieve an appropriate level of accuracy, robustness and cybersecurity and to declare accuracy metrics in the instructions for use. 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.
prEN 18229-2 (draft standard), CEN/CLC/JTC 21 under M/613
Article 15 leaves open what "appropriate" means, and that open norm is precisely what this deliverable would fill in. Until it is finished, you must justify yourself which accuracy level fits your application and why. The common trap is putting a single percentage in the instructions for use without stating on which population and under which conditions it was measured: that is not a metric, it is a marketing figure. A supervisory authority will ask about the measurement setup.
Record a test protocol per high-risk system: which metric, which test population, which subgroups measured separately, and what performance degradation under out-of-distribution conditions is acceptable. Use the ISO/IEC 24029 series for robustness methodology and retain the raw test results, not only the summary.
prEN 18229-3: AI trustworthiness framework part 3, transparency and human oversight
The draft European standard for the transparency and oversight requirements of Articles 13 and 14 for high-risk AI systems.
Providers design in the oversight measures under Article 14; under Article 26(2) deployers assign natural persons with the necessary competence, training and authority and give them the mandate they need.
prEN 18229-3 (AI trustworthiness framework, Part 3: Transparency and human oversight) is the JTC 21 deliverable under M/613 addressing Articles 13 and 14 of the AI Act: transparency and provision of information to deployers, and the design for effective human oversight 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. This deliverable concerns Article 14 (high-risk) and not the Article 50 transparency obligations, which apply since 2 August 2026.
prEN 18229-3 (draft standard), CEN/CLC/JTC 21 under M/613
Articles 13 and 14; Article 26(2); Article 40
Human oversight is the obligation that most often exists on paper and fails in practice. Article 14 requires the designated person to be able to genuinely understand, override and reverse the output. A staff member with thirty seconds per case and no mandate to deviate is not human oversight, only a signature. The common mistake is waiting for this standard while the bottleneck is not technical but organisational: mandate, time and escalation route.
Describe per high-risk system who exercises oversight, what information that person sees at the decision moment, how much time is allotted, what mandate exists to deviate, and how a deviation is recorded. Those four answers are the core of your Article 14 evidence and will not change with the final normative text.
prEN 18284: quality and governance of datasets in AI
The draft European standard operationalising the Article 10 data governance requirements for training, validation and testing data.
Applies to providers of high-risk AI systems that are trained on data.
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.
prEN 18284 (draft standard), CEN/CLC/JTC 21 under M/613
Article 10 is where most organisations actually fail, because they never recorded the provenance and processing history of their data. prEN 18284 will turn that recording into a normative requirement. The common mistake is waiting for the standard before starting data lineage: that documentation is almost impossible to reconstruct retroactively. What you do not record now cannot be proven two years from now.
Start a dataset passport per high-risk system now: provenance, collection method, processing steps, representativeness for the intended user population, known gaps and the bias examination performed. Use the ISO/IEC 5259 series as an interim structure and keep the fields generic so they can be renamed to the terminology of the final EN 18284.
prEN 18285: conformity assessment framework for AI systems
The draft European standard operationalising the conformity assessment procedure of Article 43 and Annex VII.
The Article 43 conformity assessment rests on the provider. The authorised representative established in the Union keeps the EU declaration of conformity and the technical documentation available to the supervisory authority and cooperates with it under Article 22.
prEN 18285 (Conformity assessment framework) is the JTC 21 deliverable under M/613 covering the conformity assessment of high-risk AI systems under Article 43 and Annex VII of the AI Act. 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. Standardisation request M/613 was amended by Implementing Decision C(2025)3871 of 23 June 2025 and expires on 28 February 2027.
prEN 18285 (draft standard), CEN/CLC/JTC 21 under M/613
Article 43 and Annex VII; Article 22; Article 40
This is the deliverable that determines how heavily the rest weighs. For most Annex III systems the provider may self-assess (internal control), but that does not mean nothing is required: it means you must be able to show the complete dossier yourself. The trap is thinking self-assessment is light. The notified body is absent, the burden of proof is not. While prEN 18285 remains in draft, there is no recognised blueprint for that self-assessment and you must justify the structure yourself.
Determine per system which assessment route applies (internal control or notified body) and build your dossier as one an external party would have to be able to read, even where you self-assess. Plan backwards from 2 December 2027 for standalone Annex III systems and 2 August 2028 for systems embedded in regulated products.
Public classifier for the high-risk use cases in Annex III.
The full legal text in the public AI Act Explorer.
Public route for structuring measures by role and context.
The full legal text of the prohibited practices with all categories and exceptions, in the public AI Act Explorer.
Public decision route for the distinct transparency obligations.
Public generator for structuring a fundamental rights impact assessment.
Public guide to GPAI model obligations and exceptions.