Sovereignty washing: a glossary for the phrases already doing the work
Five phrases are already carrying the word sovereign into vendor decks. Here is the honest reading of each, and the question every one skips.
Sovereignty washing is arriving for AI vendors this quarter, and most of the deck copy is already written. The word sovereign now closes deals faster than any vendor can be checked, which is exactly the condition under which a word gets borrowed by companies whose architecture never earned it. The pattern is not new to enterprise technology. Cloud vendors ran the same trick with a "sovereign cloud" pitch before AI vendors ever touched the word, and security trade coverage was already calling it sovereignty washing months before Karp made sovereignty the word of the summer. What is new is the target. The borrowing is moving from the infrastructure layer, one contract removed from anyone who would notice, into the AI vendor deck itself, carried by five phrases that sound like architecture and commit to much less.
Where the word already had a life
Cloud infrastructure buyers have been fighting a version of this fight for longer than AI vendors have been in the room. A "sovereign cloud" that still routes its control plane through the same handful of hyperscalers, a data residency pitch that stops at where bytes sit and says nothing about who holds the keys: trade coverage on the pattern was circulating before a single AI vendor put the word on a slide. A more recent read of the same failure mode makes the mechanism explicit: sovereignty depends on who operates the infrastructure and who holds the keys, and a claim that stops at where the data sits has already conceded both.
Karp's manifesto gave the word a louder stage and handed every AI vendor selling into a data-sensitive enterprise a front-of-deck term it did not have to earn. We already published the diligence test that closes the gap: five architecture and contract questions a buyer can run in an afternoon, aimed at the address where inference runs and the title on the resulting weights. This piece sits beside it. Not the questions a buyer asks. The phrases a vendor already prints, read the way an honest vendor would mean them, and the gap each one leaves open before the questions ever get asked.
Five phrases, read the way an honest vendor would mean them
Each phrase below is narrowly true most of the time it gets used. That is the point. A fabricated claim is easy to catch. A true claim scoped to answer a smaller question than the one being asked is not, and it is the more common failure mode by far.
"Private endpoints"
A private endpoint is a real control, at the network layer only. Traffic between the customer and the vendor's compute moves over a dedicated network path instead of the public internet, which closes one specific class of interception. That much of the phrase holds every time a vendor uses it.
What it does not say is what sits at the other end of that path. Network privacy and compute tenancy are two different questions, and a private endpoint answers only the first. The inference the endpoint connects to can still run in a shared pool, processing another customer's request in the same cycle as this one, with isolation enforced by software policy rather than a hard boundary. Ask what runs behind the endpoint. The route the request takes to get there is the smaller question.
"Dedicated instance"
This sounds like the stronger claim, an exclusivity promise where a private endpoint only promised privacy in transit. Within its narrow scope it usually is stronger: a dedicated instance means a customer's compute allocation is not shared with another tenant's workload at that moment, a claim a vendor can back with a real architecture diagram.
Dedication ends at the compute. It has nothing to say about the model running on that instance: whether it was trained on this customer's data alone, whether the weights the instance produces belong to the customer, or whether the identical base model serves every other customer on an equally dedicated instance down the hall. A customer can have a fully dedicated instance and a model that has never once been theirs. Ask who owns what the dedicated instance produces. Who else shares the rack is the smaller question.
"Your data is never used for training"
Read narrowly and technically, this is often true. Base model training runs are expensive, scheduled events, and a vendor is not quietly retraining its foundation model on customer prompts between requests. Most vendors who say this mean exactly that scoped claim, and mean it honestly.
The sentence is narrow by design. It leaves out evaluation sets, fine tuning, and the corrections a reviewer makes when a draft comes back wrong: three processes that shape a model's future behavior without ever being called training in the sentence a vendor is willing to sign. A prompt can sit outside training entirely and still shape the version of the model that serves a competitor next quarter. The honest question was never whether training happens. It is which of the neighboring processes the sentence was built to exclude.
"Only telemetry leaves"
Telemetry is an old word, borrowed from infrastructure monitoring, where it meant CPU load, memory pressure, request latency: numbers about the system, not the content moving through it. Used that way, "only telemetry leaves" is a reasonable and checkable claim about keeping the lights on.
Nothing stops a vendor from aliasing the same word onto a much bigger payload. A prompt hash, a token count broken out by field, a sample of outputs pulled for quality review: all of it can be filed under telemetry by a team that never updated the word after the product changed underneath it. The phrase survives unchanged while what travels under it grows. A vendor with nothing to hide will hand over the field list before being asked twice, because a defined schema costs nothing to share and an undefined one costs everything to defend.
"Zero retention"
This usually means what it says about storage: a prompt and its output are processed and then deleted, not written to a database that persists past the request. Several model providers offer exactly this as a setting, and where it is the default rather than an option a customer has to remember to enable, the claim holds.
Retention describes what happens after processing, and the promise stops exactly there. It says nothing about the copies that exist during processing: a cache holding the request for the length of a session, a downstream log aggregator the retention promise never covered, an evaluation sample pulled before deletion to check the model is behaving. None of those are retention in the narrow sense the phrase protects. Ask whether zero retention is the default configuration or an option, and ask who else in the pipeline the promise was never written to cover.
Why the same five phrases keep working
None of the five phrases is a lie on its own terms. That is what makes sovereignty washing harder to catch than an ordinary false claim, and why it survives a demo unchallenged. Each one is narrowly, technically true, built to answer a smaller question than the one sovereignty asks. A private endpoint is a real network control. A dedicated instance is a real resource allocation. Zero retention is often a real storage setting. The washing is not in any single sentence. It sits in the deck's silence about the two facts none of the five phrases were built to answer: the address where inference runs, and the name on the title to the resulting weights.
This is the same mechanism cloud vendors ran with a sovereign cloud pitch a year earlier, and the reason it keeps recurring is structural. No single vendor's honesty is really the question. A sales conversation rewards whichever word closes the room fastest. An engineering team ships the narrowest true version of that word it can build by the deadline the sales conversation already promised. The gap between the phrase and the architecture is just where the deadline landed.
The fix is not a longer glossary. It is a habit: read each phrase for exactly what it commits to, then ask what it was scoped to avoid saying. Five phrases in a deck cost nothing to print. An architecture that survives five specific questions costs a company its entire approach to how the product gets built.
What passes in our own file
Since the five phrases are also how Nodes gets tested, here is the honest version of each, stated plainly rather than glossed. Inference runs inside the customer's own VPC, single tenant, the only tenant on that instance. Weights fine tuned on a customer's data stay that customer's property, with an exit right if the relationship ends. Nothing leaves the boundary in any form telemetry could stretch to cover; the vendor's own view of a deployment is an up or down status page. Retention is not a policy layered on top of a shared system, because there is no shared system for a customer's data to sit inside, however briefly. Our security file states two facts and nothing beyond them: SOC 2 Type I and Type II.
The anchor pilot, a Fortune 500 insurance carrier, covers four years of production data across 10,765 agents, logged under the Decision Traces methodology, and any decision inside it can be pulled up with what it read and why. The wider architecture is built to answer for itself rather than a slide, which is the only version of the five phrases worth signing.
Karp is right that sovereignty is worth fighting for, and worth naming precisely. He is also handing every vendor in the category a word expensive enough to be worth faking. The five phrases above will keep showing up on decks through the rest of the year, most of them printed by people who believe every word they wrote. The deck will use the word correctly. Whether the architecture earns it was always the only question worth asking.
Sources
Let's Stop Sovereignty Washing
Cloud Washing in the Age of AI: When Sovereign Isn't
Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises. Methodology: Decision Traces.