Connected is not sovereign: what it takes to qualify a frontier model route

Agent platform field notes, two of eight. The first note argued that no model provider, runtime or cloud may be the trust root. This one is about the next question a municipality asks: can we use a frontier model at all, and if we do, what are we allowed to say about it?

The question

A Dutch municipality wants an agent that helps caseworkers with social-support applications. The best models for the job are hosted abroad by companies whose terms change quarterly. The municipality’s own hardware can run smaller models that are good enough for some steps and not for others. Everyone in the room agrees the answer is “both”. Nobody can say, in writing, what “both” means when a citizen’s data is on the line.

My short answer: model assurance and deployment topology are two different decisions, and the word “sovereign” belongs to exactly one assurance class. A route to a remote model can be qualified, governed and safe. It is still never sovereign, and the platform must make it structurally impossible to pretend otherwise.

Two classes, not a slider

I defined two assurance classes and refused to add a third.

In the first, sovereign, inference, data, keys, identity, evidence, telemetry and operations all stay inside the boundary the municipality controls or has explicitly delegated. No remote model provider is required for anything. Self-hosted inference, qualified and accepted, is the only permitted serving.

In the second, frontier-connected, the governor stays local, but a policy-approved, minimised payload may go to one exactly specified remote route. Provider, legal entity, endpoint, processing region, retention, training-use posture, subprocessors and expiry are all pinned and visible.

The rule that does the work: the second class never inherits or implies the first. One deployment may offer execution configurations from both classes, but every claim, evidence record, service level and release decision binds to the exact class and route. Nothing generalises across them.

Why no third class, no “mostly sovereign”, no percentage? Because a slider invites exactly the sentence I am trying to make impossible: “it’s sovereign, except for the parts that aren’t.”

A slider would let the sentence “it is sovereign, except for the parts that are not” survive. I would rather not. The map is not the territory, and a percentage of sovereignty is a map with the coastline left off.

A route is a contract, not a setting

The practical consequence is that “which model do we use” stops being a configuration value and becomes a governed record.

A route pins, immutably: the provider and its contracting legal entity (a brand name is not enough), the endpoint and its processing region, the model snapshot or exact version, the API version, the retention posture, the assurance class, the allowed data classes, the named use case, the egress policy, the evaluation contract, the qualification state, its expiry, and a separately qualified fallback set.

Each of those is its own record with its own version and digest, and the route’s fingerprint covers all of them. Change the region, the retention terms or the subprocessor list, and you have a different route that has to be qualified again. There is no editing a live route in place.

Before a route can carry regulated data it needs a provider assurance decision with the executed terms and data-processing agreement, a transfer decision where a transfer is actually triggered, and a data-egress policy that lists the exact fields allowed out, the transforms applied, and what happens on failure. For the social-support use case specifically, that meant pseudonymisation unless identified data is demonstrably required, case fragments rather than dossiers, no training opt-in, and completed impact assessments before anything goes live.

The invariants I would not negotiate

• Every use case has a pinned allow-list of routes. Routing is never open-ended provider selection, however clever the router.
• Primary and fallback routes are qualified independently. A fallback is not “the same thing, elsewhere”. It is another route, with its own decisions.
• No automatic failover across providers or across assurance classes. If a sovereign route is unavailable, the run degrades safely: it waits for a human, abstains, or is denied. It does not quietly phone out. This costs availability. It is the right cost.
• Model output is a proposal. A tool call produced by the model is authorised and executed by deterministic local components, or not at all.
• A material change suspends qualification. New subprocessor, new region, new retention terms, new API version, model deprecation: the affected production qualification is suspended until the legal, technical, evaluation and municipal gates pass again.
• Provider logs are not evidence. The local invocation record carries the route fingerprint, the classification and redaction decisions, the provider’s request identifier where supplied, a digest of the response, the policy decision, whether a human used the output, and latency, tokens and cost. Full prompts and outputs live, where retention is legally required, in a separately authorised store referenced by digest.

What this changes for the people in the room

For the CIO, “can we use a frontier model” becomes answerable: yes, as a frontier-connected route, for these use cases, with these fields, under this decision, until this date. Not as a vibe.

For the privacy officer, every route is an object with a transfer decision attached, or a recorded reason why none was needed. The assessment is not a document somewhere; it is a dependency the run cannot be admitted without.

For the engineer, the adapter is boring on purpose. It speaks the provider’s wire format and nothing else. Everything that matters lives in the canonical records the adapter is not allowed to change.

For the vendor who wants to sell “sovereign AI”: you are welcome, as long as the thing on the box matches the assurance class in the evidence record.

What I cannot prove yet

Same grade as last time: prototype. The contract exists, the records are schema-locked, validators check closure and digest continuity, and the demos exercise the failover prohibition. What has not happened is a real provider changing its terms under a live qualification, a real transfer assessment surviving a real regulator, or a real outage where the safe-degradation path had to hold with a caseworker waiting. The validators also cannot prove things they are not designed to prove: signer authorisation, key revocation, inclusion in a transparency log. Those are explicitly out of scope and documented as such.

The honest cost is operational. Every route qualification is work, and the expiry dates mean the work recurs. A municipality that wants ten frontier use cases will have ten sets of decisions to maintain. I consider that the price of the word.

What to do with this

Ask your platform team one question: when the sovereign route goes down at 15:00 on a Friday, what does the system do?

If the answer involves the word “fallback” and does not involve the words “class”, “qualified” and “human”, the sovereignty claim is one incident away from being false.

The next field note compares the major agent frameworks on one axis only: what each actually governs, and what it leaves to you.

Computer says no. For a sovereign route that is looking longingly at a remote one, that is not a sketch. That is the specification.

References

The allusions and quotations in this piece, with their origin:

• Alfred Korzybski, Science and Sanity (1933): “the map is not the territory”.
• Little Britain (BBC, 2003-2006): “Computer says no”, Carol Beer at the desk.