Source-traceable links from AI Act changes and obligations to actors, actions, evidence, controls and public tools.
EU Artificial Intelligence Act 2024/1689
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.
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.