- Three procurement categories are sold under one word: sovereign AI, self-hosted open-weight deployment, and a foreign foundation model behind a local interface.
- The third is the most common and the least often named. The application layer may be excellent; the intelligence is rented and the data crosses a border to reach it.
- Seven diagnostics separate them. They differ enormously in evidential weight, and treating them as equivalent produces false clearance.
- Client-side network inspection is conclusive on a positive and worthless on a negative, because production wrappers call upstream from their own backend.
- Tokenizer and latency fingerprinting are real corroborating signals and are defeatable by a vendor who normalises what it reports.
- The egress-blocked demonstration is the only one that cannot be prepared for. A local model keeps answering with the outside world cut off.
- The lab's position: build the hybrid, log the escalation, and make provenance a property of the architecture rather than a claim in a deck.
The object under examination
A wrapper is an application that owns its interface, its workflow, its integrations and its support relationship, and rents the part that thinks. The rented part is a foundation model operated by a company in North America or Europe with whom the buyer has no contract, no service level, and no route of recourse.
Nothing in that description is an accusation. The lab builds hybrid systems that call frontier models, and for a large class of work that is the right engineering. What fails is the naming. A wrapper described as sovereign carries a residency position, a continuity position and a pricing position that the architecture cannot support, and those three positions are exactly what a board approves when it approves the purchase.
Sovereignty, stated precisely: the contracting party owns the model or licenses weights on terms it controls, inference executes on hardware that party or the buyer operates, and the location of that hardware is written into the agreement. Three conditions, held together. A product satisfying two of them is not two-thirds sovereign. It is a different category with a better story.
| Property | Sovereign | Self-hosted open weights | Wrapper |
|---|---|---|---|
| Inference execution | Vendor or buyer hardware, named region | Buyer hardware or tenancy | Provider data centres, region unspecified |
| Kill switch held by | Vendor, under contract | Buyer | Provider, and its regulator |
| Weight custody | Vendor, transferable on exit | Buyer, on disk | Provider, not transferable |
| Cost function | Compute or capacity | Hardware and operations | Tokens or credits, with margin |
| Failure surface | Vendor default | Buyer operations | Outage, policy change, export control, repricing |
Seven diagnostics, weighted honestly
The order below runs from cheapest to most decisive. The weight given to each matters more than the technique, because a diagnostic that produces a false clearance is worse than no diagnostic at all.
Interrogating the model. Ask the product which foundation model it runs on, then ask again in different phrasing, then again deep in a long conversation where the system prompt has more context competing with it. A leak is strong evidence. A denial is nearly worthless, because a system prompt can instruct denial and because models misidentify themselves constantly. The lab has run a self-hosted open-weight deployment that insisted it was built by OpenAI, an answer that was false and would have condemned an honest vendor. Catch carelessness with this. Clear nobody.
Network inspection. Record the client traffic during a completion. A request to api.openai.com, api.anthropic.com, generativelanguage.googleapis.com or a hosted-inference endpoint settles the matter. A clean trace settles nothing, because production wrappers call upstream from their own backend and the client only ever speaks to the vendor's domain. What remains useful in the trace is endpoint resolution, the operator of the network it sits on, and round-trip timing.
Latency fingerprinting. Measure time to first token from a client on a Caribbean network, then measure a direct call to a known foreign provider from the same client. Local inference on regional hardware and a proxied call to us-east-1 have different floors, and the floor is harder to fake than the mean, because a vendor can add delay but cannot subtract distance. Treat a consistent match against the foreign floor as a reason to escalate rather than as a finding.
Tokenizer fingerprinting. Model families segment text differently, so identical prompts yield different token counts and different behaviour at the boundaries: unusual scripts, long digit runs, emoji sequences, repeated whitespace. Where a product exposes token counts or usage metering, comparing those against known tokenizers is a genuine signal. It is defeatable by normalising the reported figures, and it fails entirely when nothing is exposed, so it corroborates rather than determines.
The sub-processor schedule. The strongest documentary check, because it is contractual. A foundation-model provider listed as a sub-processor for inference closes the question. No schedule at all, or a clause permitting substitution at the vendor's discretion without notice, answers it differently. Misrepresentation here is a breach with consequences rather than a marketing exaggeration, which is precisely why it survives a vendor who prepares for everything else.
Cost structure. Ask for an invoice rather than a rate card, then ask whether the vendor will fix a price at three times current volume. Capacity pricing looks like GPU hours, node hours and throughput. Resale pricing looks like tokens, requests or credits. A vendor whose own costs scale with your tokens cannot hold that price, and the explanation of why characterises the architecture more accurately than any technical review.
The egress-blocked demonstration. Run the product on a network where outbound access to the major foundation-model providers is blocked at the firewall, or deploy it into a tenancy where you control egress. Give notice; this is a test rather than an ambush. A model executing on infrastructure you control keeps answering. A wrapper returns an error or falls back to a canned response. No architecture diagram alters that outcome, and no preparation defeats it.
If a buyer has appetite for two diagnostics rather than seven, take the sub-processor schedule and the egress-blocked demonstration. Those are the two that cost money to fake. Everything else on the list can be rehearsed by a vendor who has read this page.
Where this teardown is weak
Publishing a diagnostic degrades it, and this one degrades in a specific direction: the cheap checks lose value first, because they are the ones a system prompt or a normalisation layer can defeat over a weekend. The lab judges the trade acceptable, because the buyers who need the framework do not have one and the vendors capable of defeating it were already ahead of those buyers.
The deeper limitation is that provenance is being treated as a property of one system when the exposure is almost always accumulation. A client with a properly assessed core deployment, an unlogged transcription tool that joins meetings, a browser extension three people installed, and a fourth supplier's assistant embedded in a support queue has one good architecture and an unmapped surface. In the engagements the lab has run across the region this year, a complete inventory of AI systems in use has generally not existed before we built one, and its length has been the first finding rather than the last.
There is also a case the lab loses. For a small team with no infrastructure staff, no on-call rota and no appetite for GPU operations, self-hosting is worse engineering than a well-chosen wrapper, and saying otherwise would be selling. The honest recommendation there is a wrapper with an accurate description, a sub-processor schedule on file, and a documented manual fallback for anything the business cannot run by hand.
The reference stack
The architecture the lab builds makes the diagnostic unnecessary, because the answer becomes structural rather than assertive.
An open-weight model from a downloadable family forms the floor, quantised to fit whatever hardware is actually available, running on infrastructure the client or the lab operates in a location named in the contract. Retrieval over the client's own corpora does the work that most teams reach for fine-tuning to do, and it does it with lower operational cost and a much shorter path to correcting a wrong answer. Evaluation and regression testing run in-region against a held-out set, so a model change is detected by the test suite rather than by a customer complaint.
A routing layer sits above the floor and can escalate to a frontier model for the rare genuinely hard task. That escalation is logged, and an explicit policy governs which data classes may take that path, which is the difference between a hybrid architecture and an undisclosed dependency. Where the escalation path is unavailable, the floor keeps answering, degraded but running, which is the property that matters at four in the morning.
The economics follow from that shape rather than fighting it. A system whose baseline cost is compute rather than tokens has a bill that does not move when a provider on another continent reprices, and a continuity position that does not depend on a decision made in a jurisdiction where nobody in the region has standing. The lab set out the structural case for that in The Shift to Localised LLMs. This piece is the diagnostic half of the same argument, aimed at buyers evaluating somebody else's claim rather than building their own stack.
What to do with this
Inventory first. List every AI system in use, including the ones nobody procured, and put a named owner against each. Then issue one written request to every vendor on that list for the current sub-processor schedule and a written statement of the inference location, on the same day. The replies and the silences will triage the list before any engineering starts.
Reserve the egress-blocked demonstration for systems touching regulated data, because it takes real effort on both sides and should be spent where the result changes a decision. And for any system embedded in a process the business cannot run manually, write the fallback down now and name the person who invokes it.
Every diagnostic above can be run against the lab's own deployments. Clients do run them, and that is the correct relationship to have with a vendor making a claim of this kind, including this one.