Digital sovereignty as an architectural principle. Technology decisions beyond the cloud infrastructure

The debate on digital sovereignty has gained considerable momentum in recent years. The NIS2 Directive, stricter GDPR enforcement and geopolitical tensions have sensitised IT managers: Who controls our digital infrastructure? Where is our data stored? What happens if a cloud provider doubles its prices or changes its terms and conditions?

Cloud providers, multi-cloud strategies or Kubernetes - these infrastructure aspects are relevant, but fall short. After all, cloud dependency doesn't just arise when choosing a data centre, but with every architectural decision: from the database and identity services to the integration of LLM APIs.

A recent Bitkom study shows that 90% of German companies feel heavily dependent on services and technologies from abroad. At the same time, their trust in US providers is "considerably weakened" (37%). However, this dependency does not only arise from the choice of a cloud provider - it arises in fact with every technology decision.

This article argues in favour of establishing sovereignty as a strategic architectural principle - on an equal footing with performance, scalability and maintainability. We develop a pragmatic framework that helps software architects and engineering managers to make conscious decisions in the area of conflict between time-to-market, costs and sovereignty. Because the key insight is: sovereignty does not begin with the choice of data centre - it begins with the first import.

Anatomy of technical dependencies

The invisible stack: where cloud dependency begins

When we talk about sovereignty, we think in layers. A modern application architecture can be roughly divided into four layers, each with different sovereignty implications:

Infrastructure layer: This is where the classic cloud providers are located, as well as Kubernetes distributions and container runtimes. The sovereignty debate to date has focussed here. The seemingly obvious solution: Kubernetes as an abstraction layer that promises portability between different cloud providers.

Platform layer: This layer comprises databases, message queues, caching systems, identity providers and API gateways. This is where things become significantly more complex: for example, event-driven architectures with AWS EventBridge utilise manufacturer-specific features that cannot be mapped 1:1 to Apache Kafka.

Application layer: Frameworks, ORMs, HTTP clients, logging libraries - the supposedly harmless building blocks of applications. But dependencies lurk here too: If business logic is deeply embedded in framework specifics, migration becomes a challenge.

AI/ML layer: The youngest layer in the stack and also the most disruptive. Large language models, computer vision APIs, recommendation engines - often consumed as a cloud service. This layer is fundamentally different from all others: It is non-deterministic, evolves at high speed and embeds business logic in external black boxes.

Each level has its own lock-in mechanisms. While the infrastructure level is becoming increasingly interchangeable thanks to standardised interfaces (Kubernetes APIs, S3-compatible object storage), the higher levels are often even more proprietary.

Three dimensions of digital sovereignty

Sovereignty is multidimensional. We distinguish between three central dimensions that are relevant for architecture decisions:

Technology sovereignty refers to the ability to independently select, migrate or further develop technologies:

• Can I replace this component with an alternative without having to rewrite large parts of my system?
• Is the technology based on open standards or proprietary protocols?
• Do I have access to the source code and could I customise it?

An example: Switching from PostgreSQL to MySQL is straightforward - switching from DynamoDB to a relational database requires fundamental architectural changes.

Expertise sovereignty focuses on the ability to carry out critical operational processes independently at all times:

• Does our team have the knowledge to operate, decommission and further develop this technology?
• Is this knowledge sufficiently documented and distributed?
• Can we access external expertise in an emergency?

Managed services reduce operational expertise requirements in the short term, but create dependency in the long term. If no one in the team understands how the underlying technology works, a change of vendor becomes an existential challenge.

Data sovereignty includes control over the storage location, access and use of data:

• Where is the data physically stored and processed?
• Who can access the data and under what circumstances (including providers, authorities)?
• How complex is a complete data export into a usable format?
• Is there vendor lock-in due to proprietary data formats or APIs?

Data sovereignty is particularly critical for SaaS solutions and cloud services. A concrete example: A company uses a cloud-based analytics service and has been enriching its data with custom models for years. The raw data can be exported - but the trained models and configurations are proprietary and non-transferable.

The hidden costs of vendor lock-in

Lock-in manifests itself on various levels:

Explicit lock-in is the most obvious form: The use of proprietary APIs, vendor-specific features or closed protocols. Examples:

• AWS Lambda with EventBridge integration instead of standard HTTP triggers
• Azure-specific AD integration instead of the OIDC standard

These dependencies are documented, often even deliberately entered into. The trade-off is clear: higher speed and better integration versus lower portability.

Implicit lock-in is more insidious because it develops gradually:

Ecosystem effects: The decision in favour of AWS Lambda leads to the use of CloudWatch for monitoring, IAM for authorisations, Secrets Manager for credentials. Each component in itself could be replaced - the overall system no longer is.

Data gravity: The more data accumulates in a system, the more difficult migration becomes. Not only because of the volume, but also because of the links, indices, access patterns and historically grown structures.

Team specialisation: The engineering team becomes AWS experts. They know best practices, optimisations and workarounds. A switch to Azure would not only devalue systems, but also team expertise.

Transitive dependencies: A seemingly harmless library entails further dependencies, which in turn bring their own lock-ins. Package managers often have hundreds of transitive dependencies - a patchwork of potential sovereignty risks.

Kubernetes as a key technology deserves special attention, as it is often praised as a panacea for portability. The reality needs to be viewed in a more nuanced way:

Kubernetes standardises container orchestration by abstracting workload from infrastructure and allowing it to be automated via a generic interface. Another advantage is that portable ecosystems can be developed into specific platforms on the basis of Kubernetes. This enables an organisation's own cloud platform with features such as self-service, service catalogue, transparency and traceability, deployment mechanisms, end-to-end automation and automatically provisionable managed services.

In practice, however, this creates new challenges:

Distribution-specific differences: although EKS, AKS and GKE are all "Kubernetes", they differ in the details.

Ecosystem complexity: A productive Kubernetes platform consists of dozens of additional components that are often more binding than the Kubernetes distribution itself.

Operator pattern: More and more applications are being deployed as Kubernetes operators. Although these are portable, they are often optimised for specific distributions or cloud providers.

Managed vs. self-hosted: The decision between EKS and self-hosted Kubernetes is a fundamental sovereignty decision - despite identical APIs.

Kubernetes therefore solves portability at the infrastructure level, but creates new complexities. The effort required for the lifecycle management of Kubernetes is significant. The expertise required for this is expensive. Many interdependent services and components have to be harmonised and maintained over their lifetime.

Conclusion: Kubernetes is a tool for sovereignty - not its guarantee.

The area of conflict: speed, costs, sovereignty

Conflicting goals: speed, costs and cloud sovereignty

Architecture decisions are always a balancing act between competing goals. In addition to qualitative goals such as scalability, performance, security and reusability, the conflict between the following three goals must be weighed up and resolved:

Time-to-market (speed): How quickly can functionality be delivered? Managed services and SaaS solutions offer clear advantages here: Low setup time, no infrastructure complexity, out-of-the-box features, lifecycle management outsourced. An identity provider such as Auth0 is integrated in hours - a self-hosted Keycloak instance takes days to weeks.

Total cost of ownership (TCO): The total cost over the lifecycle of a solution. TCO considerations strive for a holistic perspective that goes beyond the summation of direct costs. The calculation here is often counter-intuitive: a seemingly expensive managed service can be more favourable in terms of TCO than a "free" open source alternative if operating costs and the development of expertise are also taken into account.

Sovereignty: The ability to have self-determination over technology, operational readiness (expertise) and data. As explained in the section on the three dimensions of sovereignty, this is a multidimensional variable.

These three objectives are in a tense relationship that can be visualised in a matrix:

Target matrix: Speed, costs, sovereignty

It is important to realise that there is no objectively "right" choice. The optimal decision depends on the context.

A pragmatic decision-making model

In order to systematically assess these complex conflicting objectives, we propose a three-stage decision-making model:

Stage 1: Context analysis

Before we compare technologies, we need to clarify the strategic context:

1. Business differentiation: is this component differentiating for the business model?
2. Criticality: How business-critical is this component?
3. Expected lifetime: How long is this solution expected to be in use?
4. Regulatory requirements: What compliance requirements apply? (GDPR-relevant personal data, NIS2-critical infrastructure, industry-specific regulations such as BAIT, KRITIS, etc.)

These four dimensions span a decision space. A component that is business-differentiating, highly critical, long-lived and regulated places higher demands on sovereignty. A commodity component for a tactical use case can live with strong vendor lock-in.

Stage 2: Target evaluation

We now systematically evaluate the three main objectives for each technology option under consideration:

Time-to-market:

• How quickly can we set up a production-ready solution?
• How long does the integration into existing systems take?
• How quickly can we utilise new features?

TCO (Total Cost of Ownership):

• Direct costs: licences, cloud resources, support contracts
• Personnel costs: for development, operation and maintenance
• Know-how development: training, certifications, learning curve
• Opportunity costs: What are we missing out on because resources are tied up?
• Exit costs: What would a later migration cost?

Sovereignty:

• Migration capability: How strong is the vendor lock-in? Is it based on standards?
• Controllability: How transparent is the technology? Can we debug, adapt and expand?
• Risk minimisation: How dependent are we on a vendor? What happens in the event of a failure or price increase?

Stage 3: Heuristic decision rules

Based on the context analysis and dimension evaluation, we can formulate heuristics:

Decision heuristics

Important: These rules are heuristics, not laws. They provide guidance, but are no substitute for context-specific judgement.

Open source and open weight models: the middle ground for AI/ML

The discussion about digital sovereignty in the AI sector is often reduced to the dichotomy of "proprietary APIs vs. self-hosted models". However, there is an important middle ground that is becoming increasingly relevant in practice: Open Weight models.

Open source vs. open weight: While genuine open source models disclose model weights as well as training code and the underlying training data (e.g. Mistral, Olmo), open weight models are limited to the publication of model weights (e.g. Llama, Qwen). The training process remains proprietary.

Sovereignty perspective:

Technology sovereignty: Open weight models offer complete control over inference and deployment. Fine-tuning is possible, but the reproducibility of the training is limited. Nevertheless: significantly greater sovereignty than with proprietary APIs.

Know-how sovereignty: Operation requires ML Ops expertise (model deployment, optimisation, monitoring), but the learning effort is lower than with training from scratch. The community offers extensive documentation and tooling (vLLM, Ollama, llama.cpp).

Data sovereignty: Complete control: data never leaves your own infrastructure. No dependency on vendor policies regarding data usage, retention or access.

Practical considerations:

Pay attention to licence models: Llama has usage restrictions for >700M monthly users. Mistral and others offer Apache 2.0 licences without such restrictions. The choice of licence has a significant impact on long-term sovereignty.

Accept performance gap: Open Weight models are typically 6-12 months behind state-of-the-art proprietary models (GPT-5, Claude Sonnet 4.6 or Opus). For many use cases, however, the performance is still sufficient - especially with domain-specific fine-tuning.

Infrastructure investment: Hosting a Llama 4-109B model requires at least an H200 GPU (approx. €2,500-9,000/month cloud costs; depending on provider and geographical region) plus ML engineering capacity. In addition, there is the learning curve for prompt optimisation, as open source models often require different prompting strategies than GPT.

Quantisation as an enabler: Modern quantisation techniques make it possible to run larger models on consumer hardware. A quantised Llama-3-70B runs on 2× RTX 4090 - this democratises access considerably.

Strategic recommendation:

Hybrid approach with gradation:

• Prototyping & non-critical use cases: Proprietary APIs (GPT, Claude) for maximum velocity
• Production & standard tasks: Open Weight models self-hosted (Llama, Mistral) for balance between performance and sovereignty
• Highly sensitive data & compliance: Fine-tuned open weight models on-premise with strict access controls
• Commodity tasks (e.g. classification, simple extraction): Small models (Llama-3-8B, Mistral-7B) - often surprisingly powerful with specific fine-tuning

The landscape is developing rapidly: what is still proprietary today may be available as Open Weight tomorrow. Companies should design their architecture in such a way that it is still possible to switch between model types with reasonable effort - for example, through abstraction via frameworks such as LangChain or Semantic Kernel, combined with their own prompt management.

Conclusion: Open Weight models are not a compromise, but often the most pragmatic way to achieve AI sovereignty. They offer 80-90% of the capabilities of proprietary models with significantly greater control and without the existential vendor risks. This is the sweet spot for most corporate use cases.

Conclusion

Sovereignty is not a binary state, but the process of making trade-off decisions on a continuum. There is no universally "right" decision. The optimal balance between time-to-market, cost and sovereignty depends on the context.

Establishing a culture of sovereignty in the engineering organisation is more important than the individual technology decision.

This is particularly relevant in the context of AI/ML: large language models pose new challenges to our existing concepts of sovereignty. The infrastructure debate is important - but, as shown, incomplete. Sovereignty is a continuous process that requires constant trade-offs. This article expands this perspective: every technology decision is a sovereignty decision. The 3-step model mentioned above helps to make these decisions consciously instead of unconsciously becoming dependent.

Call-to-action for software architects:

1. Inventory your dependencies: Create an SBOM (Software Bill of Materials) - not just for security, but for sovereignty.

2. Evaluate your sovereignty portfolio: Which components are critical and differentiating? Where are the biggest vendor lock-in risks?

3. Define exit strategies: For your top 5 dependencies: What would be the alternatives? What would a change cost?

4. Establish sovereignty audits: Half-yearly: Where have risks changed? Where should we make adjustments?

5. Use the decision model: For the next technology decision: context, dimensions, heuristics - systematically weigh them up.

Sovereignty is not a luxury that only corporations or public organisations can afford. It is a strategic necessity for every organisation that wants to remain capable of acting in the long term. The question is not whether we deal with sovereignty - but how consciously and systematically we do it.

We have the infrastructure layer under control - now it's time to raise the sovereignty discussion to the level where it belongs: in the software architecture, in the design, in every technology decision. Because sovereignty starts with the first import.

Clarify the sovereignty strategy in the expert call

The five recommendations for action above show the way, but often require more expertise and capacity than IT teams can muster in day-to-day business. If you are looking for support or help getting started, take advantage of our free expert call: 60 minutes, cloud-neutral, without sales pressure. In an open exchange, we will categorise your current dependencies, identify critical lock-in risks in your architecture and develop ideas for your first concrete steps. You will receive personalised recommendations that are tailored to your initial situation, your compliance requirements and your resources.