Pre-Market Testing Plan for High-Risk AI Under the EU AI Act

What the plan has to prove, and for what scope

Providers of high-risk AI systems must be able to show that testing was performed before the system is placed on the market or put into service. That testing has to be suitable for the system's intended purpose, use defined metrics and probabilistic thresholds, and be recorded in technical documentation. A test plan is the document that makes those three expectations reviewable before any test runs.

Start with scope. The Act's recitals frame risk identification and mitigation around the intended purpose and reasonably foreseeable misuse, and they include risks arising from the interaction between the AI system and its operating environment. A plan scoped only to the model in isolation will miss that last category. Write the intended purpose as it appears in your documentation, list the foreseeable misuse scenarios you identified and how you identified them, and describe the operating environment the tests must represent.

The recitals also describe risk management as a continuous, iterative process across the lifecycle, with significant decisions and actions justified and documented. Treat the pre-market plan as one stage of that process. It should record why scope, thresholds and deviations were chosen, not only what the results were.

Metrics, acceptance thresholds and gates

Choose metrics that reflect the intended purpose rather than the ones a model reports by default. For each metric, state the measurement method, the dataset or scenario set it runs on, the threshold that counts as acceptable, and the reasoning for that threshold. Where outputs are probabilistic, express thresholds as a probability or rate with a stated confidence or sample size, so a pass is reproducible and not a one-off result.

Separate thresholds into two kinds. Release-blocking thresholds are conditions that must be met before market placement or putting into service. Monitoring thresholds are values you expect to watch after release. Keeping them distinct avoids pre-market criteria that cannot be verified until real traffic exists.

Define entry and exit criteria for each test phase. Entry criteria usually cover a frozen system version, a approved test dataset, a configured environment and a signed-off scope. Exit criteria cover thresholds met, defects triaged, deviations documented with rationale, and residual risks accepted by a named owner. A threshold missed and then relaxed without a recorded justification is the most common finding a reviewer will question.

Environments, procedures and real-world testing

Specify the test environment in enough detail to reproduce it: system version, model and configuration, infrastructure, integrations the system calls, and data used. If the environment differs from the intended deployment, say how and why the difference does not invalidate the result. Describe procedures as repeatable steps, including how adversarial and misuse scenarios are constructed, who runs them and how failures are recorded.

If you plan to test under real-world conditions, plan for the conditions the Act's recitals describe: a testing plan submitted to the competent market surveillance authority, registration of the testing in the EU database (subject to limited exceptions), a limited testing period, additional safeguards for persons in certain vulnerable groups, a written agreement defining the roles and responsibilities of prospective providers and deployers, and effective oversight by competent authorities. Check the operative article text before relying on real-world testing, and treat these items as additional plan sections with their own owners and records.

Where pre-market testing ends and runtime evidence begins

Pre-market testing answers whether the system, as built and as intended to be used, meets your documented criteria before release. It produces a bounded body of evidence tied to a specific version. Once the system is live, different questions apply: what the system was allowed to do in each interaction, and what it actually did. Because risk management continues across the lifecycle, pre-market results can seed post-market review, but they do not substitute for operational evidence. Document the handoff point in the plan, including which team owns evidence after release.

Trussed does not provide pre-deployment testing or red-teaming, so it does not replace anything in this plan. Trussed enforces policy in the execution path, with allow, redact, block, rate limit and escalate actions applied to individual interactions and tool calls. Enforced at runtime, not reviewed after the fact, that enforcement generates audit-ready evidence mapped to the EU AI Act once a system is live.