Five questions that test any AI sovereignty claim
Palantir says sovereignty is your alpha. Agreed. Here is how a buyer verifies the claim before signing.

Sovereignty became the most valuable word in enterprise AI this month, which means it is about to become the least reliable one. Palantir published a white paper arguing that alpha comes from sovereignty over data, model weights, and compute, and the argument is right. Every vendor deck moving through procurement this quarter will contain the word sovereign, and most of them will be describing an API wrapper with a nicer logging page. That is what happens to words that close deals: they get borrowed faster than they can be verified. AI sovereignty needs a test a buyer can run without a lab, and the vendor's own slide is not that test. Here are the five questions I would put to any sovereignty claim, including ours.
What Karp is right about
The white paper, "Sovereignty Is Your Alpha," extends a manifesto Alex Karp has championed, and the strongest parts deserve a fair reading before anyone reaches for a knife.
Tokenmaxxing is the paper's word for high-volume consumption of metered API tokens: activity that feels like progress while producing disposable scripts instead of durable systems. The meter runs, the demos multiply, and at the end of the year the enterprise owns nothing it could not buy again next year on the same terms as every competitor.
The wealth-tax frame is harsher and more useful. Send proprietary data to an external lab for inference or fine-tuning and the lab absorbs your winning plays. Whatever made your underwriting or your distribution unusual gets averaged into the next release and sold to everyone, including the competitor across the street. You pay a fee for the privilege of being commoditized, and for a carrier the plays being absorbed are decades of judgment no rival could assemble from public data.
The sharpest claim is about weights. Weights are the distilled form of institutional knowledge; a model fine-tuned on your decisions is your decisions, compressed into a file. "Controlling your weights is controlling your fate," the manifesto argues, and the prescription follows directly: open-weight models deployed in strictly controlled environments. We have made the adjacent argument from the data side, that the moat is the data that never leaves your VPC. Karp makes it from the weights side. Both point at the same architecture.
The five questions
None of the five require a benchmark. They are architecture and contract questions, answerable inside a standard security review, and each carries a passing answer and a tell. Five, because each closes a different door: compute, weights, data, interaction, accountability. A vendor with sovereign architecture answers in minutes, because the answers are facts about a system that exists. A vendor with a sovereign slide answers with adjectives. Ask all five in one sitting; the pattern across the answers is the finding.
Where does inference run?
The passing answer: inside your VPC, single-tenant, in an account your own team can inspect. The model comes to the data.
The tell is the phrase "private endpoints." A private endpoint into a shared cloud means the road is private while the destination is still a building someone else operates, with other tenants on other floors. Single-tenant matters as much as the address; a dedicated namespace inside somebody else's multi-tenant control plane fails the same way. If the vendor's architecture diagram shows your data crossing an account boundary to reach the model, the sovereignty claim has already failed, whatever the arrow is labeled. Ask for the diagram, then ask who holds root on the account where the GPUs live.
Who owns the weights, including at exit?
The passing answer: you do. The model fine-tuned on your data is your property, named as such in the contract, and if the relationship ends the weights stay in your cloud while the vendor leaves with nothing you value.
The tell: "your data is never used for training." That sentence answers a question nobody asked and stays silent on the one that matters, which is who keeps the fine-tuned model. A vendor can honor the training promise to the letter and still hold your weights hostage at renewal. Escrow is the half measure to watch for: a copy you may someday receive is a claim ticket; the model already running in your account is property. Ownership at exit is where the wealth tax Karp describes either exists or does not, so make the contract say the words.
What leaves the perimeter, ever?
The passing answer: nothing. The vendor's entire view of the deployment is an up or down status page, gated by a password you set and can change without telling anyone. There is no egress path to argue about because none exists.
The tell: "only telemetry." Telemetry is a word that can hold anything from a heartbeat ping to your full prompt stream, and a vendor who leaves it undefined is counting on nobody asking. Request the telemetry schema, field by field, and watch how long it takes to arrive. If any field derives from your data, the perimeter has a door in it, and doors widen under commercial pressure.
Who sees the prompts and corrections?
The passing answer: nobody outside your boundary. The interaction layer is where expertise leaks. Every prompt an underwriter writes and every correction a reviewer makes encodes judgment the enterprise pays salaries to develop, and all of it stays inside.
The tell: an improvement pipeline that "learns from usage across customers." Cross-customer learning on raw interactions means your best people are tutoring a model your competitors will rent next quarter. This is the version of the wealth tax that survives a data processing agreement, because the DPA covers the corpus while the leak happens through the corrections. Ask what feeds the vendor's improvement loop, where that loop runs, and who can read its inputs.
What does the trace show for one decision?
The passing answer: pick any single decision the system made and get back a queryable trace: what was read, from which system, why it was relevant, and what input a human gave before anything acted. Sovereignty without traceability is just hosting. A model can run entirely inside your walls and still be unaccountable to the people who own it.
The tell: the demo pivots to aggregate dashboards. Adoption curves and usage heatmaps are what a vendor shows when no individual decision would survive inspection. Ask for one decision, chosen by your team rather than theirs, and insist on the full trail. The vendor who can produce it will be glad you asked.
Diligence is where sovereignty is decided
Most coverage will read the Palantir paper as an argument about national capacity. A buyer should read it as an argument about procurement, because the security review is the only room where a sovereignty claim meets people paid to disbelieve it.
I have watched that gate work. At a Fortune 500 insurance carrier, six AI hiring vendors were rejected in eighteen months, every one on architecture, before evaluation ever reached the product. Architecture reviews fail on the same cosmetic answers everywhere: shared inference behind private endpoints, telemetry nobody will define, no trail for any decision. Model quality never came up, because nobody got that far.
The same gate moves fast when the answers pass. With inference in the buyer's VPC and the weights on the buyer's title, there was no egress to negotiate. Legal approval took 17 days and the deployment went from contract to production in 34 days. Reviews run long when every answer opens a new thread to pull. When the answers close threads, the calendar collapses.
The five questions cost nothing and eliminate most of the field, so they belong at the front of the process. Buyers tend to run the pilot first and the security review second, which spends the evaluation budget on vendors who were never going to clear architecture. Reverse it. An hour with the five questions before any proof of concept saves the pilot for vendors who can survive the review.
One contract term changes the temperature of that room more than any other. Lead with ownership: the customer keeps the model even after the vendor is gone, so the strongest answer to the lock-in objection is that there is no lock. In diligence, that term reads as confidence. A reviewer can feel the difference between a right that was offered and a right that was extracted, and the vendor who volunteers the property title has nothing left to defend. The deeper argument about why the deployment address decides regulated deals is in the VPC gap; the five questions are that argument folded into an instrument a buyer can carry.
What passing looks like in production
Since the five questions are also how Nodes expects to be tested, here is our exam sheet. Inference runs inside the customer's VPC, single-tenant. Weights are customer-owned, exit included. Nothing crosses the perimeter, and the vendor view is the status page. Prompts and corrections stay inside the boundary. The compliance file says SOC 2 Type I and Type II, plainly, with no gesturing at frameworks we do not hold. And the trace exists for every decision: the anchor pilot at a Fortune 500 insurance carrier covers four years of production data and 10,765 agents, and any recommendation in the pilot can be pulled up with what it read, where each fact came from, and what a human decided about it. The logging methodology is published in Decision Traces, so question five can be checked against a paper instead of a promise.
Sovereignty reduces to two verifiable facts: a deployment address and a property title. Where does the model run, and who owns it when the relationship ends. Both can be checked in an afternoon of diligence by a buyer holding five questions and the patience to hear every answer all the way out. Karp gave the market the word this month, and the market will respond by printing it on everything. Most of those decks will fail the second question. The questions are how you keep the word honest.
Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises. Methodology: Decision Traces.