Testing in Real-World Conditions Under the EU AI Act

What the Act means by testing in real-world conditions

The Act defines testing in real-world conditions as temporary testing of an AI system for its intended purpose in real-world conditions, outside a laboratory or otherwise simulated environment. The aim is to gather reliable and robust data and to assess and verify the system's conformity with the Regulation's requirements.

Two consequences follow. First, the definition is tied to intended purpose and real conditions, so pre-deployment lab testing and simulated evaluations sit outside it. Red-teaming in a controlled environment is the same kind of activity: useful, but not what Article 60 regulates. Second, such testing does not count as placing the system on the market or putting it into service, but only if all the conditions in Article 57 or Article 60 are fulfilled. A missed condition puts that status at risk.

Testing may take place at any time before placing on the market or putting into service. A provider can run it alone or in partnership with one or more deployers or prospective deployers. Article 60 testing is without prejudice to the Article 5 prohibitions, and without prejudice to any ethical review required by Union or national law.

Real-world testing compared with sandboxes and lab testing

Governance teams often use these terms interchangeably. The Act does not. The route you choose determines who supervises the activity and which document governs it.

• Article 60 real-world testing (outside a sandbox): Testing for intended purpose in real-world conditions. Governed by a real-world testing plan submitted to the market surveillance authority in the Member State of testing, with approval of the testing and the plan.
• AI regulatory sandbox (Article 57): A controlled environment for development, training, testing and validation for a limited time before market placement or putting into service. It operates under a sandbox plan agreed between the provider and the competent authority, and may include supervised real-world testing.
• Pre-deployment lab or simulated testing: Testing outside the real-world definition. It does not use the Article 60 route and is not the subject of this guide.

Plan and approval: where most delay and exposure arise

Among the conditions, the provider must have drawn up a real-world testing plan and submitted it to the market surveillance authority in the Member State where testing will take place. That authority must approve the testing and the plan. If it gives no answer within 30 days, approval is understood to have been given. Where national law does not provide for tacit approval, the testing remains subject to an authorisation.

The practical point is that the 30-day rule is not universal. A multinational programme testing in more than one Member State needs a position per Member State, not a single assumption. Where the test involves deployers or prospective deployers, document the partnership arrangement as part of the same file.

Because testing must follow the approved plan, the plan is the reference against which any later question will be answered. A plan that is vague about scope gives you nothing to enforce and nothing to demonstrate against. Write scope in terms that can be tested: which functions the system may perform, which data it may touch, which actions require a human decision, and when the test ends.

Record which version of Article 60 you relied on. The original text limits the provision to Annex III systems, and the consolidated text dated 27 July 2026 is broader. As of November 2026, the consolidated version is the most recent official text.

Where runtime enforcement and evidence support the obligations

The Act requires a provider to test within an approved plan. It does not prescribe a technical architecture for doing so. Even so, a gap between plan and practice is the common failure. A plan that states limits on scope and human involvement is only a document unless something in the system's execution path applies those limits, and unless the provider can later show what happened.

Trussed is built for this part of the problem. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls. Policy can allow, redact, block, rate limit, or escalate for human approval. For a live test, that means scope limits from the approved plan can be expressed as policy and enforced at runtime, not reviewed after the fact, and defined situations can be held for human approval before the action proceeds.

Enforcement also generates audit-ready evidence, mapped to the EU AI Act among other frameworks. Each enforced decision leaves a durable record of what the system was permitted to do and what it did, which answers the question a regulator or auditor is likely to ask during or after a test. Deployment is self-managed in the customer's cloud, with configurable retention and data residency.

The limits matter. Trussed does not design tests, perform pre-deployment validation or red-teaming, or establish model lineage. It does not replace the plan, the authority's approval, or legal analysis of the Act's conditions. It supports the operating stages of the lifecycle: keeping behaviour inside the boundary and proving it did.