How does real world testing work outside a sandbox?

What is testing in real world conditions?

Testing in real world conditions, or TRWC, is defined in Article 3 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 conformity with the Regulation, and it does not qualify as placing the system on the market or putting it into service, provided that all the conditions in Article 57 or Article 60 are fulfilled. The definition has four elements: temporary testing, intended purpose, real world conditions, and a conformity purpose. Testing that is permanent, that is for a different purpose, that is in a simulated environment, or that is in fact a market launch disguised as testing, does not meet the definition. The distinction between testing and placing on the market matters, because a system that is placed on the market must meet the full conformity, registration and post market duties, while a system in real world testing is subject to the Article 60 conditions instead. A provider that describes a launch as testing, without a testing plan, without authority approval and without safeguards, will be treated as placing on the market, with the duties and enforcement that follow. The testing record should state the purpose, the duration, the conditions and the conformity questions the testing is designed to answer.

What conditions must Article 60 testing meet?

Article 60(4) sets out the conditions for real world testing outside a sandbox, including a real world testing plan, approval by the market surveillance authority, registration of the testing, safeguards for participants, monitoring, reporting of serious incidents, and oversight by suitably qualified persons. The plan must describe the system, the intended purpose, the testing, the participants, the data, the risks, the safeguards, the duration, the monitoring and the arrangements for stopping the test. The market surveillance authority must approve the plan before testing begins, and the authority can carry out unannounced remote or on site inspections and checks on the conduct of the test. The provider or prospective provider must ensure that the testing is effectively overseen by the provider and by deployers through suitably qualified persons with the necessary capacity, training and authority. The testing must be conducted in a way that protects participants, including vulnerable persons, and that respects data protection law. The full list of conditions in Article 60(4) must be checked in the consolidated text, because the conditions are detailed and cumulative, and a test that meets most conditions but misses one does not meet the Article 60 route.

For the broader regulatory framework, see codes, standards and sandboxes overview.

How long can real world testing last?

Article 60(4)(f) provides, in substance, that real world testing must be conducted for no longer than is necessary to achieve its objectives, and for a maximum of six months, which can be extended for the same period subject to prior notification to the market surveillance authority. The duration limit is therefore a maximum, not a target, and a test should be planned for the shortest duration that can achieve its objectives, with the extension used only where the objectives cannot be achieved within the first period and the authority has been notified in advance. The plan should state the duration, the objectives, the data to be gathered, and the criteria for ending the test early, including where a risk materialises or where the data is sufficient. The test should be stopped where the objectives are met, where the risks become unacceptable, or where a participant withdraws consent and the test cannot continue safely without that participant. The duration record should show the start date, the planned end date, any extension and its notification, and the actual end date, with the reasons for each. A test that continues beyond its approved duration, without notification and without a fresh approval, is outside the Article 60 route.

What does informed consent require under Article 61?

Article 61 requires informed consent from participants in testing in real world conditions outside regulatory sandboxes, subject to the conditions and exceptions in the Article. Participants must be informed about the testing, the system, the purpose, the risks, the data, the duration, the right to withdraw, and the arrangements for stopping the test, in a form they can understand, before they consent. Consent must be freely given, specific, informed and unambiguous, and participants must be able to withdraw at any time without detriment. Special provisions apply to vulnerable persons, including children and persons with disabilities, and to testing in law enforcement, migration and other sensitive contexts, which must be checked in the Article 61 text and in the sector law that applies. The consent record should show the information given, the form used, the date, the participant, and any withdrawal, with the data protection arrangements recorded alongside. Consent for real world testing does not replace a data protection lawful basis where one is required, and it does not authorise testing that is prohibited, that is high risk without the Article 60 conditions, or that is conducted without market surveillance authority approval. A provider should obtain legal advice on the consent form and process before testing begins, with the sector and data protection position checked.

How does Article 60a for Section B products differ?

Regulation (EU) 2026/1744 inserted Article 60a, which creates a parallel route for testing of high risk AI systems covered by Union harmonisation legislation listed in Section B of Annex I in real world conditions outside regulatory sandboxes. The Article 60a route must be checked in the consolidated text, because its conditions, its approval authority and its relationship to the sector legislation differ from Article 60. In outline, Article 60a recognises that Section B products follow sector procedures, and that real world testing for those products must be coordinated with the sector authority and the sector requirements, rather than following the Article 60 route alone. A provider of a Section B product, such as machinery, a vehicle or an aviation system, should therefore check whether Article 60 or Article 60a applies to its product, check the approval authority, the plan requirements and the safeguards for that Article, and record the Article relied on. A provider that follows Article 60 for a Section B product, without checking Article 60a, may follow the wrong route. A provider that follows neither Article, and that tests in real world conditions without approval, will be outside both routes.

Continue with regulatory sandboxes.

What does this guide not decide?

This guide does not decide whether any named test meets Article 60 or 60a, does not draft a real world testing plan or a consent form, and does not reproduce Articles 60, 60a and 61 in full. Real world testing needs the plan, the approval, the safeguards, the consent arrangements and the monitoring, checked against the consolidated Articles and the sector law for the specific system. A provider with a specific testing proposal should confirm the route, the plan and the consent arrangements with the market surveillance authority and a legal adviser before testing begins. Testing in real world conditions without approval is not a low risk shortcut, and a general guide cannot authorise it.

Frequently asked questions

Continue through this AI Act cluster

• codes, standards and sandboxes overview
• regulatory sandboxes
• sandbox plans and exit reports
• sandboxes for smaller firms
• providers
• deployers