Testing in Real-World Conditions Under the EU AI Act

Field-testing an AI system outside a lab is not the same as launching it. Regulation (EU) 2024/1689 carves out a distinct legal status for this activity — "testing in real-world conditions" — so that developers can gather genuine operational data without that act alone counting as placing the system on the market or putting it into service. The carve-out comes with binding conditions. Ignore them and the protection falls away.

The EU AI Act definition

Article 3, point 57 of Regulation (EU) 2024/1689 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; testing in real-world conditions outside an AI regulatory sandbox shall not qualify as placing on the market or putting into service of the AI system, provided that all the conditions laid down in this Regulation are met.

Three elements are decisive. First, the testing must be temporary — it ends; it does not become an open-ended deployment. Second, the purpose is data collection and conformity verification, not commercial operation. Third, the protection against being treated as a market launch depends entirely on meeting the conditions the Regulation sets out. Those conditions live primarily in Articles 60 and 61.

The distinction matters commercially. A high-risk AI system cannot go to market without a completed conformity assessment under Article 43. Real-world testing is a stage within the development path, not a shortcut past it.

The rules: Articles 60 and 61

Article 60: the testing plan and oversight framework

Before deploying subjects to a real-world test, the provider must prepare a real-world testing plan. Article 60 specifies what that plan must contain: the system's intended purpose; the testing objectives and the scientific or technical justification for why real-world conditions are necessary; the geographical scope and duration; a description of oversight measures; and the safeguards in place to protect participants.

The plan must be submitted to the market surveillance authority of each member state where testing will take place. Testing may not begin until the authority has not objected, or, depending on the member state's procedure, has given approval. Registration in the EU database (Article 49) is also required, making the test traceable to competent authorities.

Article 60 imposes strict time limits. Testing runs for the period specified in the approved plan. Extensions require a fresh submission. There is no open-ended field trial.

Throughout the test, the provider must maintain active oversight: monitoring the system's behaviour, recording results, and watching for unexpected risks or adverse outcomes. If such risks arise, the provider must suspend or terminate testing immediately and notify the market surveillance authority.

One safeguard is particularly important: where the AI system makes predictions about individuals, those predictions must be capable of being reversed or disregarded. A credit-scoring algorithm deployed in a real-world test at a regional lender cannot, during that test, trigger automated lending decisions that cannot be unwound. The human in the loop must be able to set aside whatever the system outputs.

Article 61: informed consent

Article 61 governs the people on whom the system is tested. Where the system processes personal data or otherwise directly involves natural persons, those persons must give informed consent before the test begins.

Informed consent under Article 61 is specific: the participant must understand that they are part of a real-world test, what data will be collected, how it will be used, and how they can withdraw. Consent obtained through vague or misleading descriptions does not satisfy the requirement. Where participants are in a vulnerable position — employees at a company running a workplace AI pilot, for example — the consent mechanism must account for any power imbalance that could compromise its voluntariness.

Participants retain the right to withdraw at any time without consequence. On withdrawal, the provider must stop using that participant's data for the test.

Article 61 also requires that test participants are informed of the contact details of the provider and of the market surveillance authority so they have a route to raise concerns.

Outside a sandbox and inside one

Real-world testing can happen in two settings. Where a national AI regulatory sandbox (Article 57) is already operational, testing can take place within it — the sandbox authority plays a coordinating role and may streamline the notification process. Where no sandbox exists or where the provider is not participating in one, testing follows the Article 60 procedure directly with the market surveillance authority.

The outcome in terms of legal status is the same in both cases: if the conditions are met, field testing does not qualify as placing on the market or putting into service.

Real-world testing vs an AI regulatory sandbox

These two concepts are often conflated. They are distinct.

An AI regulatory sandbox under Article 57 is a supervised development environment. Member states must establish one by 2 August 2026. The sandbox provides a structured setting in which providers — with priority access for smaller companies and start-ups under Article 58 — can develop, train, and validate AI systems under the guidance of competent authorities, with some regulatory flexibility in exchange for transparency and monitoring.

Real-world testing under Article 60 is a field test of a near-final system. The system exists; it has been trained and validated; it is being tested in genuine operational conditions to verify conformity and collect data that laboratory conditions cannot replicate. The system is not being developed during the test — it is being evaluated.

A system can pass through a sandbox during development and then conduct a real-world test — the two are sequential steps, not alternatives.

Frequently Asked Questions

Does real-world testing mean the AI system is already on the market?

No. Article 3, point 57 is explicit: real-world testing does not qualify as placing the system on the market or putting it into service, provided the conditions in the Regulation are satisfied. Those conditions include a submitted and approved testing plan, time limits, active oversight, and the ability to reverse or disregard the system's predictions. If any condition is not met, the protection falls away and the deployment may be treated as a market launch — triggering the full Article 43 conformity-assessment requirement for high-risk systems.

Which systems can use real-world testing?

The framework in Articles 60 and 61 applies to AI systems being tested for conformity with requirements of the Regulation. In practice this is most relevant for high-risk AI systems, where conformity assessment (Article 43) is mandatory and where real-world data is often necessary to complete it. There is no express restriction that prevents a limited-risk or minimal-risk system from using this route, but the procedural obligations in Article 60 would apply regardless.

What happens if a participant withdraws consent mid-test?

Under Article 61, withdrawal must be possible at any time without consequence to the participant. On withdrawal, the provider must stop processing that participant's data for the testing activity. The test itself may continue with remaining participants, provided the plan still has a valid basis — but the withdrawn participant's data from the testing period cannot continue to be used.

Does a real-world test outside a sandbox still need to be registered?

Yes. Article 60 requires registration in the EU database under Article 49. This ensures that market surveillance authorities have visibility of field tests running in their jurisdiction, even when no sandbox is involved.

How long can real-world testing last?

Article 60 requires that the testing plan specifies a duration. There is no fixed maximum in the Regulation, but the period must be justified by the testing objectives and approved by the market surveillance authority. Testing cannot be extended indefinitely; an extension requires the authority's agreement. The "temporary" requirement in the Article 3, point 57 definition is not cosmetic — it means the test must have a defined end.

What must the real-world testing plan contain?

The plan must cover: the AI system's intended purpose and the specific testing objectives; the scientific or technical reasons real-world conditions are needed; geographic scope and duration; oversight measures; safeguards for participants; and the mechanism for reversing or disregarding the system's outputs. It is submitted to the market surveillance authority of each member state where testing takes place before the test begins.

How Confir maps to this process

Documenting a real-world test correctly involves several overlapping obligations: the Article 60 plan, Article 61 consent records, Article 49 registration, and the Article 43 conformity evidence that testing is meant to produce. Confir's rule-based, deterministic engine structures this across its compliance assessment areas. The AIRC module (covering Articles 5, 6, 43, and 50) tracks where a system sits in the conformity-assessment path; the AIGM module (Articles 9, 72, and 73) covers the ongoing monitoring and incident-reporting duties that run in parallel. The Article 47 EU Declaration of Conformity and the Article 11 / Annex IV technical documentation pack are generated from the same structured intake — so when the real-world test concludes and the full conformity file is assembled, the documentation is already structured around the right articles, not reconstructed from notes after the fact.

Confir starts at €600/year and runs without consultants or implementation cycles. Details at confir.eu.

Related terms

• AI regulatory sandbox — the supervised development environment under Article 57, where real-world testing can also take place
• Intended purpose — the use for which the AI system is tested; determines the applicable risk tier and conformity requirements
• AI system — the definition in Article 3, point 1 that establishes what is subject to the Regulation
• Conformity assessment — the Article 43 procedure that real-world testing helps fulfil for high-risk systems
• AI risk management — the Article 9 risk management system that runs throughout development, including the testing phase
• Article 43: conformity assessment — the full conformity-assessment framework, including the Annex VI and Annex VII procedural routes