Frontier AI sovereignty starts with an exit test

An AI supplier can remain available while the customer loses the ability to leave it. The failure usually arrives quietly: prompts become platform settings, evaluation cases stay in one dashboard, a workflow assumes one tool syntax, and nobody can say what would have to move if price, access or capability changed.

On 15 July, the European AI Office published findings from a forum of more than 100 experts on frontier AI. The report gives Europe four practical objectives: the ability to access, choose, control and benefit from any frontier model. For a small company buying rather than training such systems, those verbs describe a procurement test more useful than a flag on the model card.

The test is simple to state. Can the company move one real task to a credible alternative, preserve the evidence needed to judge it and restore service within a time the business has already accepted? If that has never been demonstrated, provider choice exists in a slide deck, not in operations.

Four verbs, four records

The expert report does not equate sovereignty with autarky. Some participants argued for European capability across the stack; others warned against assuming that every layer must be domestic. The shared conclusion was narrower: Europe needs reliable access, provider diversity, independent evaluation and terms that let it retain value from deployment.

That distinction scales down well. An SME has little leverage over frontier-model development, but it controls the records around its own use. Each of the report’s four verbs can become a file or a repeatable check.

Objective	Evidence an SME can keep	Failure signal
Access	Named accounts, quotas, regions, support route and a documented fallback	A critical workflow depends on one untested endpoint or personal login
Choose	A representative evaluation set run against at least two viable model configurations	The team compares marketing claims instead of results on its own work
Control	Approved instructions, permissions, tool calls, review rules and incident logs	The supplier dashboard is the only place where the system can be understood
Benefit	Baseline effort, usage cost, quality result and owner for each deployed task	More model use is counted as value without measuring the business outcome

Source: European AI Office Expert Forum report. Last verified 2026-07-20.

This is not an argument for maintaining two production systems. Most small teams should not pay that tax. It is an argument for keeping the task legible enough that a second route can be proved before the first one becomes difficult to unwind.

Define the task before the provider

An exit test starts with a task record, not a vendor inventory. Choose one bounded piece of work: classify an incoming request, extract fields from a document, draft a reply for review or retrieve an answer from an approved knowledge base. Record what enters, what a usable result looks like, who reviews it and what happens when the result is uncertain.

The record should include twenty to fifty representative cases. They need not form a scientific benchmark. They need to contain the ordinary cases, the costly edge cases and at least a few inputs the system must refuse or escalate. Preserve the expected result and the reason it matters. A score without the underlying cases is hard to interpret after either the model or the business rule changes.

Then separate the parts of the system:

1. Business rule: the decision, wording or extraction the company actually needs.
2. Context: documents, examples and current data supplied to the model.
3. Instructions: system prompts, output schema and escalation rules.
4. Connections: tools, permissions, queues and destinations the model may use.
5. Provider layer: model name, endpoint, parameters and service terms.

Only the fifth item should have to change during a clean model switch. In practice, some instructions and tool definitions will need adaptation. The exit test measures how much adaptation, by whom and with what loss of quality. It does not pretend that models are interchangeable components.

Run the six-part exit test

The smallest useful exercise can fit inside one working day and should leave six results.

1. Export the working specification

Save the current system instructions, output schema, tool definitions, retrieval settings and human-review rule outside the supplier console. Remove secrets and personal data from the test pack. Name the version and date it. If an important setting cannot be exported, reproduce it in the task record while the team still remembers what it does.

2. Freeze representative cases

Run the current configuration on the chosen cases and retain the inputs, outputs, review decisions, latency and usage. This is the baseline. Do not rely on an aggregate success percentage alone. The next model may improve the average while failing the one case that creates a contractual or safety problem.

3. Move to one credible alternative

Select a model and delivery route the company could genuinely use. Recreate only what the task needs. Avoid building a universal abstraction layer for a one-day test; a small adapter or manual batch is enough to reveal whether prompts, schemas and tools travel cleanly.

The expert report highlights provider diversity, open software environments, interoperability and data portability as ways to reduce switching costs. Open weights can expand the available choices, but they do not remove the work. Someone must still provide suitable hardware, runtime, updates, monitoring and security.

4. Compare business failures

Review both sets of outputs blind where possible. Count the cases accepted as-is, corrected, escalated and rejected. Record any change in latency and estimated cost at the expected volume. The relevant question is not which model wins a general benchmark. It is whether the alternative keeps this workflow inside its agreed quality, time and cost limits.

5. Reconnect permissions safely

If the system can call tools, give the alternative the minimum test permissions. Verify every allowed action, denied action and human approval boundary. A model that produces equivalent text but cannot respect the workflow’s permission design is not yet a fallback.

6. Time the return to service

Measure the work from the decision to switch until a reviewed result reaches the normal destination. Note the manual steps, the person who performed them and the remaining gaps. Set an expiry date for the test because model versions, APIs and internal systems change. A fallback last exercised a year ago is an archive, not a route.

The output can be one page: current route, alternative route, quality delta, cost delta, switching time, blockers and the next retest date. That is enough evidence for a renewal or architecture decision.

Public infrastructure changes the option set

The report treats computing infrastructure and the energy behind it as urgent European priorities. It also recommends that public computing capacity remain genuinely accessible to a broad group of developers rather than a small set of incumbents.

The current AI Factory network is one concrete part of that option set. The Commission lists 19 AI Factories and 13 antennas, with access prioritised for startups and SMEs. EuroHPC describes free computing resources and customised support for eligible European users. That can help a company develop, adapt or test a model without treating a commercial API as the only possible route.

It is not automatically a production fallback. Access conditions, project timing, data handling, deployment responsibilities and ongoing operations still need to fit the task. An AI Factory application should therefore use the same task record as the exit test: defined cases, required compute, data constraints, expected result and an owner after the supported work ends.

This prevents public capacity from becoming a second isolated experiment. The useful outcome is not merely access to a supercomputer. It is a tested capability the company can retain, operate or procure with clearer evidence.

Put the test before the renewal

The AI Office report is strategic and explicitly does not represent a final Commission position. Its most useful contribution for a small buyer is nevertheless immediate. Access without a tested alternative is dependency. Choice without comparable cases is shopping. Control without an operating record is confidence. Benefit without a baseline is usage.

Pick the AI workflow whose interruption would create the most manual work this week. Export its specification, freeze twenty representative cases and run one alternative before the next contract renewal. If the switch works, the company has a real option. If it fails, the blockers are now visible while the current service still runs.