The word “sovereign” has joined “secure,” “private,” and “responsible” in the pile of AI marketing terms that have lost most of their meaning through overuse. Every vendor claims it. No two vendors mean the same thing by it.
This is a problem for schools, because the difference between two products that both claim sovereignty can be the difference between protecting student data and leaking it. The vocabulary is broken in a place where the precision actually matters.
So let’s fix it. Here is a more useful framework — five levels of AI sovereignty, ordered from loosest to strictest. Use this when you evaluate a product, when you read a vendor pitch, when you sit in a procurement meeting. The same question applies at every level: what, specifically, is being kept where, and who exactly can see it?
Level 0: API wrapper with default terms
The product calls a major AI provider’s API on the back end. Your data goes through that provider’s systems. The provider’s standard terms apply — which usually means logging for abuse monitoring, retention for a fixed period, and a contractual but not architectural commitment about training. This is what the majority of “AI for X” startups actually are, regardless of what their marketing says.
Sovereignty score: zero. The product is a thin layer of UX over a service that owns the actual intelligence.
Level 1: API wrapper with enterprise terms
Same as Level 0, but the vendor has signed a business-tier agreement that prohibits training on inputs and may have reduced data retention. This is a real improvement — a contract is enforceable in a way that a marketing claim isn’t. But the data still leaves the school’s vendor boundary, and a district lawyer asking “who sees this data?” still has to accept the answer “the AI provider does, briefly, but they’ve contracted not to use it.”
Sovereignty score: one. Better than nothing, but the architecture is unchanged.
Level 2: Hosted inference on open-weight models
The vendor uses a third-party hosting service to run open-source AI models. The host doesn’t make its money by training on your data — it makes its money by selling compute. The model itself is open-weight, which means it can’t be tainted by your data in any meaningful way (the model weights don’t update when you use it). Several reputable providers in this space have explicit no-training policies in their terms of service.
This is a meaningful step-change. The vendor is no longer dependent on a company whose business model is data-hungry by design.
Sovereignty score: two. Real privacy, real architectural improvement, but still a third-party in the trust chain.
Level 3: Vendor-controlled stack on rented infrastructure
The vendor rents GPU compute from a cloud provider but runs their own software stack — their own inference server, their own model weights, their own logging, their own database. No third-party AI service is in the data path. The cloud provider’s role is reduced to providing the metal and the network. From a privacy standpoint, this is when “sovereign” starts to be honestly defensible.
What you can claim at this level: no AI provider sees the data, no model is trained on it, the vendor controls deletion and retention, and the vendor can attest to the entire data flow.
What you cannot claim: data never physically leaves any building. It leaves the school and goes to a data center somewhere. It just doesn’t leave the vendor’s control.
Sovereignty score: three. This is where most enterprise SaaS lives, and it’s a perfectly reasonable bar for most use cases.
Level 4: Dedicated tenancy with regional and audit controls
Same as Level 3, but with contractual single-tenancy guarantees, defined geographic regions (your data stays in Texas, or in the United States, or in a specific cloud region), formal compliance certifications (SOC 2 Type II, FedRAMP, StateRAMP if applicable), and customer audit rights. This is what large district procurement teams actually want when they say sovereign.
The cost difference between Level 3 and Level 4 is significant. The compliance overhead is significant. Most school districts don’t actually need this level — they need Level 3 with good documentation. But the largest districts and the most security-conscious institutions do, and any vendor selling at scale needs a path here.
Sovereignty score: four.
Level 5: True on-premise deployment
The vendor ships hardware to the school. The compute, storage, and inference all happen inside the building’s network. Data physically does not leave the premises. This is the purest form of sovereignty and what most people mentally picture when they hear the word.
Almost no one actually deploys this way for K–12. Schools don’t have server rooms. They don’t have IT staff who can maintain GPU infrastructure. The hardware is expensive and dates quickly. The exceptions are unusual: federal schools, defense department schools, certain charter networks with unusual privacy charters, and institutions in regulated jurisdictions where the law requires it.
Sovereignty score: five. Mostly aspirational for the K–12 market, but worth understanding because it sets the ceiling.
How to use this framework
Three practical applications.
When evaluating a vendor, ask which level they actually operate at — not which level their marketing implies. The honest answer should be one specific number, not a range. A vendor who says “it depends on the deployment option” is telling you something useful: most of their customers are at the lower end.
When writing a procurement requirement, specify the level you actually need rather than the level that sounds most impressive. Most schools genuinely need Level 3. Asking for Level 5 in an RFP without good reason will eliminate good vendors and only get you bad ones who are willing to lie.
When you’re a vendor — and this is where I’m writing from — be precise about the level you offer today, even if your roadmap promises more. Saying “we are Level 3 today and offer Level 4 for districts who require it” earns trust in a way that vague sovereignty claims don’t. The vendors who overclaim now will get caught later. The ones who undersell what they actually do will look conservative in a way the market eventually rewards.
What to read for
When you read AI vendor marketing — including ours — read for what’s specific and what’s vague. “Private AI” is vague. “Your data never trains a model and never leaves our infrastructure” is specific. “Enterprise-grade security” is vague. “SOC 2 Type II audited annually” is specific. “Sovereign deployment” is vague. “Dedicated single-tenant deployment in your choice of US region with quarterly audit rights” is specific.
The vagueness isn’t always bad faith. Sometimes the vendor genuinely hasn’t done the work to know what they’re claiming. But for a school choosing where to put student data, that distinction doesn’t matter — both kinds of vagueness create the same risk.
Sovereignty isn’t a sticker. It’s a specific set of architectural and contractual decisions that produce specific guarantees. The vendors who can name those decisions are the ones worth talking to.
Next week: a different angle on the same problem. We’ll look at why the failure modes that killed Jasper and Inflection are exactly the failure modes a sovereign AI vendor has to design around — and why the AI startup playbook of the last three years gives terrible advice for the education market.