Buyer guide / Sovereign AI
Make sovereignty a specification.
For a business buying an AI system, sovereignty becomes useful when it describes enforceable control over data, processing and operations. Ask for the deployment map, access model and exit plan before relying on a regional label.
1. Where does each copy of the data go?
Map primary storage, backups, model inputs, embeddings, logs and support exports. Record each location and the parties responsible for it. A European database does not establish where every downstream component processes information.
2. Who can administer the system?
Identify client administrators, infrastructure operators, model providers and support personnel. Document how privileged access is granted, time-limited, recorded and revoked, including emergency access.
3. What are the model-processing terms?
Specify the model endpoint, processing location, retention, provider access and permitted uses of submitted information. Check the actual configuration and contract for the chosen service, rather than generalising from a consumer chatbot or a provider’s nationality.
4. Who controls encryption keys and recovery?
Document key custody, rotation, backup protection and recovery responsibilities. Key ownership has practical meaning only when access paths and recovery procedures reflect it. Test how service is restored without widening access unintentionally.
5. Where are permissions enforced?
Data retrieval and tool execution must enforce the user’s permissions outside the language model’s instructions. An ontology supplies business context, but it is not itself an access-control mechanism. Recheck authority when an action is executed.
6. What evidence establishes that it works?
Agree representative tasks, source-quality checks and failure cases before acceptance. Evaluate unsupported answers, wrong calculations, information leakage and actions outside scope. Preserve the evidence and identify who owns the decision to accept the system.
7. What happens when something changes?
A source schema, model version or permission change can affect a previously accepted workflow. Establish versioning, regression checks, monitoring, escalation and rollback. Define which changes require renewed review by the business owner.
8. Can the organisation leave?
Request documented export formats for data, definitions and relevant logs. Identify dependencies on proprietary services and the effort to replace them. Agree handover, deletion and ongoing operating responsibilities before an exit is needed.
The output: a decision-ready deployment brief
A useful brief names the workflow, the data and model-processing paths, the accountable owners, the controls to demonstrate and the unresolved questions. Compare candidate architectures against that same brief.
Counterfold uses discovery to translate these questions into a scoped build. European cloud, on-premises and defined hybrid options are assessed for the actual workload. Any legal or regulatory assessment depends on the organisation and intended use.
Practical answers
Questions before the first conversation.
Does European hosting automatically make an AI system compliant?
No. Hosting location is one design input. The relevant purposes, data, access, contracts and obligations still require assessment for the specific use.
Must every component be self-hosted?
Not necessarily. The choice depends on control requirements, sensitivity, capabilities and operating capacity. Managed and self-hosted components should be evaluated against the same explicit requirements.
What should we bring to an initial discussion?
Bring one decision or workflow, the types of source systems, the people who own them and the main access or hosting constraints. Avoid sending sensitive records in the initial enquiry.