Sovereignty begins with architecture
Sovereign AI is not a hosting location, a compliance badge or a private endpoint. It is the ability to decide where knowledge lives, who may retrieve it, which models may process it and how every consequential action can be reconstructed.
The quickest way to evaluate a platform is to ignore the interface for a moment and follow one piece of information. Ask where the original file, extracted text, embeddings, knowledge graph, prompt, model response and audit evidence live. If the answer changes at each step, control is fragmented.
◇A sovereign system should preserve the same control model from source knowledge to final action.
Seven questions every buyer should ask
A strong evaluation turns broad claims into specific, testable answers. Ask the vendor to demonstrate each answer with your own permission model and a realistic request.
- Where do files, extracted content, vectors, graphs and activity logs physically reside?
- Can Personal, Teamspace and Organisation knowledge be isolated with different owners and permissions?
- Which approved model handles each task, and can your policy override the router?
- What information leaves your infrastructure when an external model is used?
- Can a denied retrieval be shown alongside the policy and identity that blocked it?
- Which agent actions require a named human approval before execution?
- Can the complete evidence record be exported without depending on the vendor’s interface?
Run a boundary test, not a scripted demo
Connect one document that a project team may see and another that only a restricted group may see. Ask the same question from both scopes. A credible platform should answer from the permitted source, fail closed in the restricted scope and produce evidence for both outcomes.
Then switch the approved model. The knowledge boundary, citations and audit trail should remain intact. Governance that changes with the model is not governance; it is a collection of provider-specific settings.
Watch for architectural red flags
Some warning signs sound convenient during procurement: a single company-wide vector store, permissions copied only during ingestion, audit logs added after the response, or approval handled outside the agent workflow. Each creates a gap between policy and actual behaviour.
- ‘Private’ means a tenant in the vendor’s account, not infrastructure you control.
- Access rules are flattened during indexing and cannot be evaluated at retrieval time.
- Model routing optimises cost but cannot explain why a model was selected.
- Agent tools execute first and create an approval ticket afterwards.
- Audit exports omit prompts, sources, model identity, cost or denied attempts.
Buy the evidence, not the theatre
A useful proof of value should end with an evidence package: the connected sources, active knowledge scope, retrieved passages, selected model, generated output, approval decision and complete activity timeline.
If the platform can produce that package for a real question your organisation already debates, you have something worth scaling. If it can only produce a polished answer, you have another chatbot.
◇The final buying question is simple: can your team prove why the system knew, answered and acted the way it did?