A procurement team sends a vendor a single question: is your platform sovereign? The answer comes back the same afternoon. "Yes. All customer data is hosted in our London region." The team ticks the box. Nine months later, during a supplier review, someone asks which company operates the servers that run the model, and the answer turns out to be a subsidiary of a US corporation. The hosting region was never the exposure.
This is the most common failure in sovereign AI platform selection, and it happens because the question being asked and the question that matters are not the same question. A sovereign AI platform is one where the processing tier sits under the jurisdiction the buyer needs, and hosting region is only one of six things that determines whether it does.
What follows is the checklist. It is deliberately vendor-agnostic: it is a specification any buyer can hold a shortlist against, including ours. The broader regulatory and market picture behind it sits in our sovereign AI guide for UK organisations.
What makes a platform sovereign, and what does not
Two terms get used as synonyms in vendor marketing and mean materially different things in a supplier contract.
Data residency is a location choice. You select the region your data is stored and usually processed in, on infrastructure operated by whichever company runs the platform. It is a real and useful control. It addresses latency, some contractual data-transfer requirements, and the reasonable expectation that a UK organisation's documents sit in the UK.
Data sovereignty is a jurisdiction question. It asks whose law reaches the company operating the infrastructure. That is a question about corporate structure, not geography.
The two diverge because of how extraterritorial law works. The US CLOUD Act (2018) compels US-headquartered companies to produce customer data on demand regardless of where that data physically sits. It follows corporate control. A US-owned provider operating a London data centre is squarely within its reach. Microsoft confirmed to the French Senate in June 2025 that it cannot guarantee EU data will never be accessed by US authorities, which is the clearest available statement of the limit residency reaches. Resolving that exposure is an architectural decision about the processing tier, which for AnswerVault customers means the Enterprise sovereign tier specifically rather than the product as a whole.
That is not an argument that residency is worthless. For most organisations, residency plus a rigorous audit trail is a proportionate answer, and Chapter V of the GDPR is concerned with transfers rather than with corporate nationality. The argument is narrower: if your risk assessment has concluded that foreign-jurisdiction access is a live risk, residency does not address it, and a vendor answering a sovereignty question with a region name has not answered it.
The six-point sovereign AI platform checklist
Six questions, in the order that eliminates candidates fastest. Any vendor can answer all six in a single call. The ones who cannot are telling you something.
1. Which legal entity operates the processing tier?
Not the data centre, and not the hosting provider. The entity that operates the servers on which the model runs, and the country under whose law that entity is incorporated. This is one sentence long when the answer is good. When the answer arrives as an architecture diagram, the diagram is doing work the sentence could not.
Ownership chains matter here. A UK-registered subsidiary of a US parent is generally within the reach of US law through the parent. Ask for the ultimate parent, not the contracting entity.
2. Where does inference actually run?
Many platforms achieve regional storage for documents at rest and then send the actual reasoning step to a model hosted somewhere else. That is the gap most buyers miss, because storage is what the security questionnaire asks about and inference is what reads the content.
Ask specifically: when a member of staff asks a question, which region and which company processes the document text in order to compose the answer? Storage location and inference location are separate facts and should be stated separately.
3. What does the model fall back to?
Availability engineering and sovereignty commitments pull in opposite directions. A platform with a primary model in an EU region and an automatic failover to a US region has a sovereignty boundary that holds until the day it matters most.
The right answer is that there is no cross-jurisdiction fallback, and that the platform fails closed rather than failing over. Get it in writing, because it is a configuration choice rather than an architectural property, and configurations change.
4. What does the contract commit to, as distinct from what the architecture allows?
Architecture can be changed by a deployment. Contracts cannot. The distinction is the whole substance of the sovereignty claim.
Look for a specific commitment naming the jurisdiction, the processing entity, and the absence of cross-border transfer, with a notification obligation if any of that changes. A marketing page describing a sovereign option is not a commitment. A schedule in the agreement is.
5. Who are the subprocessors, and can the list change without notice?
The processing tier is rarely one company. Model hosting, observability, error tracking, and support tooling can each introduce a different jurisdiction, and any of them may touch content or query text.
Ask for the current subprocessor list, the notification period for additions, and whether you have a right to object. A vendor unwilling to publish the list has decided that the list is a liability, which is useful information.
6. How do you exit, and what leaves with you?
Sovereignty includes the ability to stop. If the governance metadata, the curation decisions, and the audit log are only exportable in a proprietary shape, the practical cost of exit can exceed the risk that prompted the sovereignty requirement in the first place.
Ask what an export contains, in what format, and how long it takes. The answer also tells you how seriously the vendor treats the audit trail as a customer asset rather than internal telemetry.
Sovereign AI platforms compared: four postures
Held against the checklist, the market sorts into four architectural postures rather than a list of vendors. Most shortlists contain one of each without the buyer realising the postures are not comparable.
| Posture | Storage jurisdiction | Processing entity | Typically clears | Typically fails |
|---|---|---|---|---|
| Mainstream cloud, regional deployment | Buyer's region | Non-domestic parent | 2 | 1, 3, 4 |
| Hyperscaler sovereign programme | Buyer's region | Domestic operator, foreign technology parent | 1, 2, 5 | 3, 4 (varies by programme and contract) |
| Independent regional infrastructure | Buyer's region | Domestically owned | 1, 2, 4 | 3, 6 (model provenance and portability vary) |
| Sovereign by design | Buyer's region | Domestically owned, no cross-border fallback | 1 to 6 | Smaller vendor field; less product maturity in adjacent features |
The column that decides most procurements is the third one. Two platforms can present identical hosting-region claims and sit in different postures entirely, because one operates its own processing tier and the other rents it from a company incorporated elsewhere.
Where sovereign AI tools usually fail the checklist
Sovereign AI tools concentrate their failures in three predictable places, and knowing where to look shortens an evaluation considerably.
The first is point 2. Storage residency is easy to deliver and easy to evidence, so it becomes the claim. Inference location is harder to deliver and harder to evidence, so it goes unmentioned. If a data sheet states a hosting region and says nothing about where the model runs, assume the two are different until told otherwise.
The second is point 3. Fallback behaviour is genuinely difficult, because a strict no-cross-border-failover policy means accepting an outage rather than degrading gracefully. Vendors who have made that trade-off will say so plainly, because it cost them something.
The third is point 4. A surprising number of sovereignty claims live entirely in marketing copy and are absent from the agreement. This is the cheapest gap for a buyer to close and the one most often left open: ask for the clause.
For a sector-specific version of the same evaluation, with the audit-trail and supervisory dimensions that regulated financial firms have to satisfy, see our guide to AI knowledge platforms for financial services.
How AnswerVault answers the checklist
AnswerVault is a governed AI knowledge layer that connects SharePoint, Google Drive, and Confluence and answers only from the document sets an organisation approves. Against the six points, the honest answer differs by tier, and stating that plainly is more useful than a single sovereignty claim covering the whole product.
The Starter, Pro, and Business tiers run on mainstream cloud infrastructure with a commercially managed AI tier. They should be assessed on a data-residency basis, with region selection available from Business upwards. They clear point 2 for storage, and they do not clear point 1, because the processing tier is not under UK corporate control. Presenting them as sovereign would be the exact substitution this guide argues against.
The Enterprise sovereign tier is the one built for the checklist. It runs on non-US infrastructure with UK corporate control over the processing tier, no cross-jurisdiction model fallback, and a contractual commitment rather than a configuration setting. Every query, answer, and cited source is logged and exportable, so point 6 is answerable in a defined format rather than negotiated at exit. AnswerVault is ISO 27001 aligned, G-Cloud listed, and ISO 42001 certification is underway; the subprocessor list, attestations, and audit rights a procurement team needs for points 5 and 6 are on our security and compliance page.
Curation sits underneath all of it, because jurisdiction alone does not make an answer defensible. Approval is at the document level with named subject matter expert sign-off, superseded documents stop informing answers when they are replaced, and citation is at the sentence level. Staff reach it through web chat, Teams, Slack, and CLI, with a REST API on the roadmap.
Next steps
Send the six questions to your shortlist before the next demo. They take a vendor an hour to answer properly and they will reorder the shortlist more than any feature comparison, because they separate the platforms that have made the sovereignty trade-offs from the platforms that have made the sovereignty claim.
If your assessment lands on residency rather than full sovereignty, that is a legitimate conclusion reached deliberately, which is the point. Our sovereign AI guide for UK organisations covers the regulatory background in full, and the tier-by-tier detail including which deployment answers which point is on the pricing page.
AnswerVault is built by Catapult CX, an enterprise technology consultancy. The product was originally developed for a global pharmaceutical company with strict data governance requirements; the same architecture now powers the SaaS platform.