Want an AI operating model you control and can change when needed?
In the AI Opportunity and Architecture Assessment we plan the target architecture and operating model for local, dedicated or hybrid AI with you, from €8,900 excl. VAT. Managed AI takes over the ongoing operation of existing AI stacks.
As organisations adopt AI, dependencies on models, APIs and operating platforms grow. AI sovereignty therefore concerns more than server location: it is the ability to govern data flows, models, access, operations and a future provider change. This article provides an auditable framework. As of August 2026.
Table of contents
- What AI sovereignty means
- Four dimensions instead of one server location
- Data residency, compliance and sovereignty
- Operating models compared
- The sovereignty and exit test
- How WZ-IT implements a sovereign target architecture
- Sources
What AI sovereignty means
AI sovereignty is the ability to make and technically enforce material decisions about an AI system: model selection and versioning, location and purpose of processing, access, logs, updates and component replacement.
It is not complete isolation. An organisation can use providers or cloud components and retain significant control if dependencies are known, limited and reversible. A robust architecture covers normal operation, failure, provider change and recovery.
Four dimensions instead of one server location
| Dimension | Key question | Typical evidence |
|---|---|---|
| Data sovereignty | Which content, metadata and logs cross which boundary? | Data-flow diagram, data classes, deletion and export plan |
| Model sovereignty | Can the model be reviewed, versioned and replaced? | Model card, licence review, evaluation set, rollback version |
| Infrastructure sovereignty | Who administers compute, storage, network and keys? | Role model, key design, asset and subprocessor inventory |
| Operational sovereignty | Can the service be updated, monitored and handed over safely? | Runbooks, monitoring, restore test, exit and recovery plan |
This separation prevents a common mistake: an open model on an undocumented platform is not automatically more sovereign than a tightly controlled service. Conversely, a contract cannot make a non-exportable data store or proprietary interface portable.
Data residency, compliance and sovereignty
A German or EU server location answers the data residency question only. A data-protection assessment also considers legal basis, purpose, processing agreements, subprocessors, safeguards and international transfers. The European Commission lists adequacy decisions, safeguards such as standard contractual clauses and narrow derogations as transfer mechanisms. A third-country link is therefore not automatically unlawful, but it needs a defensible assessment.
The CLOUD Act is also more precise than “US authorities can always access data”. It requires covered providers to comply with lawful orders for data in their possession, custody or control regardless of storage location. Provider jurisdiction, access and key control therefore belong next to location in the risk assessment.
The EU AI Act imposes no general European-hosting or self-hosting rule. Depending on use and role, transparency, documentation, human oversight, logging or risk management may be relevant. A controlled stack can make technical evidence easier, but is not automatic compliance.
Operating models compared
| Model | Control | Operating effort | Suitable when |
|---|---|---|---|
| Public AI API | low to medium, contract-dependent | low | data and task fit the service and speed matters |
| Dedicated managed instance | medium to high | delegated to a provider | isolation, region and professional operations should be combined |
| Self-hosted in a data centre | high with controlled administration | high | platform skills and sensitive workloads exist |
| On-premises | very high at the infrastructure boundary | very high | data or processes must technically remain on site |
| Hybrid | controllable per data class | medium to high | models should be routed by risk, quality and cost |
A gateway can connect local and external models behind one API. Rules such as “confidential documents only locally” still require reliable classification by the application. The detailed trade-off is covered in Cloud AI vs self-hosted AI.
The sovereignty and exit test
Before selecting a platform, answer six questions in writing:
- Data flow: Where do prompts, documents, embeddings, telemetry, error reports and backups go?
- Access: Which people and providers can access the service for administration or support?
- Keys: Who controls encryption keys and can technically deny access?
- Portability: Can models, vector data, prompts and logs be exported in usable formats?
- Operations: Who patches each layer, and how is a failed update rolled back?
- Exit: How long do export, rebuild and endpoint changes take, and has the procedure been tested?
Not every workload requires on-premises operation. Every production workload does require a deliberately selected operating model and an answer to exit.
How WZ-IT implements a sovereign target architecture
WZ-IT starts with data classes, load profile, integrations and operational ownership rather than a generic hardware recommendation. The result may be an AI Cube for on-site use, a managed AI and GPU stack, LLM hosting or a hybrid gateway architecture.
The scope can include identity, network segmentation, model and prompt versioning, permission-aware RAG, monitoring, backups and documented handover. This keeps operations delegable without giving up the architecture or exit path. The open-source LLM stack explains the components.
