Skip to content
17 min read

Digital Sovereignty and AI

There’s hardly a small or medium-sized business in Germany today that doesn’t have an AI prototype sitting on the back burner. A chatbot running on test data. A script that reads invoices. A proof of concept that looked promising in the demo. And yet, the vast majority of these projects never go live. The reason rarely lies with the AI itself—it lies in the gap between the prototype and actual operations, and increasingly also in a question that many companies ask too late: Where exactly is the model running that my data ends up in?

At VIALUTIONS, this topic concerns us on two fronts: as consultants for digital sovereignty and as a company that has consistently migrated its own Microsoft 365 infrastructure to sovereign open-source technology. What applies to Nextcloud, MailCow, and KeyCloak applies just as much to AI infrastructure—except that the starting point for AI is far more complicated, because the model, hosting, training data, and application often come from different parties in different jurisdictions.

AI sovereignty is not a footnote, but an architectural decision

Digital sovereignty means being able to make self-determined decisions about one’s own systems and data at any time—without technological isolation, but with genuine freedom of choice, robustness, and resilience against vendor lock-in. With generative AI, this issue becomes particularly acute because corporate data is not only stored in an AI workflow but is also actively processed, contextualized, and, in some cases, passed on to third parties.

Anyone launching an AI project today without considering model provenance and hosting location is often recreating the very dependency they’ve just broken away from by switching to Microsoft 365—only this time at the model level rather than the Office suite. Three questions should be asked at the start of every AI project:

Where is the data processed? The EU legal jurisdiction is the minimum requirement; a physical server location in Europe is the more robust standard.

Who is training the model with my data? Many U.S. providers reserve implicit or explicit training rights to prompts, unless contractually excluded.

What happens in the event of provider failure or termination? An exit strategy should be considered from the outset, not just when the contract is terminated.

The Four Ways Companies Are Using AI Today

Before we can talk about sovereignty, we need to understand what kind of AI deployment we’re actually referring to. In practice, these terms are often used interchangeably, but they refer to very different architectures with different risk profiles.

Generative AI is the basic function: a language model generates text, code, or images based on a prompt. This is the entry level—a chat interface, a writing assistant, or a summarization feature. The risk is manageable as long as it is clear which model is responding and where it is hosted.

RAG (Retrieval Augmented Generation) connects a language model to a company’s own data. Instead of relying on the model’s pre-trained knowledge, the system first searches the company’s own knowledge base—documents, wikis, databases—and passes the relevant results to the model as context. This significantly reduces hallucinations and makes AI responses traceable because they can be traced back to specific sources. For RAG, the following applies: As soon as company data is incorporated into the context of a prompt, the question of model location and data processing is no longer optional.

MCP (Model Context Protocol) is the technical interface layer through which a language model can access external systems—such as CRM, ERP, databases, and internal tools—in a structured manner. MCP standardizes how a model “sees” and calls upon tools, similar to an API specification between applications. For companies, MCP means that AI not only gains read access to documents but also, potentially, write access to business processes. This significantly increases the duty of care regarding permissions, logging, and approval logic.

Agentic AI goes one step further: Instead of responding to a single request, an AI agent independently plans multi-step tasks, invokes tools (often via MCP), makes interim decisions, and processes workflows—such as a complete invoice intake process from recognition to approval and forwarding. Agentic AI delivers the greatest automation benefits, but also poses the highest control risk: Who is liable if an agent makes a wrong decision? How can an autonomously running agent be made auditable?

The four methods build on one another. A realistic path for most medium-sized companies leads from generative AI through RAG to initial MCP integrations and only then—once governance has reached the appropriate level of maturity—to true agent-based workflows.

Prototyping and production are two different projects

The most common mistake in AI projects is underestimating the leap from prototype to production system. A proof of concept demonstrates that something works in principle. A production system must do so reliably, securely, and consistently—for all users, under real-world load, for years to come.

Prototype / MVP

Operational Deployment

Goal

Demonstrate feasibility, test hypotheses

Reliable business process

Data set

Test data or a small sample

Complete, real-world business data

Error tolerance

High — Errors are to be expected

Low — SLAs, monitoring, and escalation are required

Security & Permissions

Often a secondary concern

Role- and permission-based approach; audit log required

Model Governance

A single, hard-coded model

Model selection documented, changes planned

Hosting

Often the provider’s SaaS, untested

Audited, contractually secured location

Operation

One-time setup, maintained by developers

Continuous operation, maintenance, update process

Cost

Low, often a free tier

Predictable based on usage and scaling

The key difference is not technical but organizational: A prototype must be convincing, while a production system must be accountable. This affects data protection officers, IT security, compliance, and—in the case of critical infrastructure or regulated industries—regulatory requirements as well. Those who fail to consciously plan this transition will get stuck in the pilot phase or introduce a security risk into production.

That’s why European hosting isn’t just a “nice-to-have”

For companies that take AI sovereignty seriously, choosing the right model and hosting infrastructure is a pivotal decision. The European market for sovereign AI infrastructure has seen significant growth in recent months. Here’s an overview of some approaches:

TextCortex (Berlin) positions itself as an agent infrastructure for businesses: a centralized, GDPR-compliant gateway to various AI models, featuring a visual agent builder and integrations with Slack, Teams, and SharePoint. The company highlights its ISO and SOC 2 certifications, as well as its policy of not training models using customer data. The focus is on rapid enterprise-wide deployment and model independence—here, sovereignty refers primarily to compliance and control, rather than exclusively to models of European origin.

Melious takes a more consistent infrastructure approach: a unified API compatible with OpenAI and Anthropic interfaces for over 60 open models, operated exclusively on European infrastructure. The data centers are distributed across multiple European providers in eight countries and audited independently of any single provider. According to the company, customer data is not used for training purposes and remains under European jurisdiction at all times. For companies that continue to use existing code with OpenAI or Anthropic SDKs but want to migrate to European infrastructure, this is a pragmatic solution that avoids the need for refactoring.

9brains (Germany) specifically targets small and medium-sized businesses with a multi-layered platform: secure AI chat with access to market-leading models such as Claude, GPT, Gemini, and Mistral in a centralized, GDPR-compliant environment, supplemented by a data integration layer for RAG, API, and MCP connections to cloud and on-premises systems, as well as an automation layer with reusable “skills” and persistent agents. The platform is hosted by Hetzner in Germany. With this, 9brains already covers all four use cases described above—generative, RAG, MCP, and agentic—on a single platform, which structurally simplifies the path from prototype to production deployment.

Poland, as a European AI hub, deserves special attention—not only because of the close integration between VIALUTIONS consult (Berlin) and VIALUTIONS sp. z o.o. in Wrocław, but also because Poland is making targeted investments in state-funded AI sovereignty. With PLLuM (Polish Large Language Model), a consortium led by NASK, the Wrocław University of Technology, and several institutes of the Polish Academy of Sciences operates an open model trained on Polish data. The model was developed entirely with government funding and is deliberately trained on organic, manually processed data rather than on synthetic data used by other models. The project cites full control over the model and independence from foreign providers—combined with lower costs achieved through in-house technical solutions—as its key features. Eleven new model variants are now available openly and free of charge, ranging from lightweight versions for simple tasks to a 70-billion-parameter model for more sophisticated text processing. The first municipalities, such as Gdynia, are already testing PLLuM in production in citizen chatbots. For companies with ties to Poland—or, more generally, for anyone looking for a European model outside the usual Western European providers—this development is worth a look.

The common thread among these providers: sovereignty is not achieved through a single model, but through an infrastructure that ensures transparency regarding model selection, hosting location, and data processing—and allows for a switch if necessary—exactly the same principle behind Nextcloud, MailCow, and KeyCloak as alternatives to Microsoft.

What this means for your AI operationalization

Based on our own experience migrating from Microsoft 365 to a self-managed infrastructure—and from our work on AI projects for our clients—we’ve identified some guidelines that make the transition from prototype to production-ready AI deployment easier:

Start with the simplest, most meaningful use case. Generative AI or an initial RAG setup based on a clearly defined knowledge base provides reliable experience more quickly than an ambitious agentic workflow that integrates into all business processes from the very beginning.

Decouple the application from the model. Working with a model-agnostic API or platform allowsyou to switch providers without having to rebuild the application—that’s freedom of choice in practice.

Clarify the hosting location and training rights in a contract, not just in marketing materials. A data processing agreement with clear provisions regarding server location and data usage should be in place before the first production prompts, not after.

Do not plan MCP and Agentic features until governance is in place. Roles, approvals, logging, and an escalation process for incorrect decisions are prerequisites, not afterthoughts.

Treat the transition from prototype to production as a separate project —with its own budget, timeline, and acceptance process—not as an automatic continuation of the pilot phase.

Digital sovereignty in AI is not a state that you achieve once and then check off your list. Just as with our own migration away from Microsoft 365, it is a process of deliberate decisions—which model, which location, which level of automation—that evolve as the company and the European AI ecosystem mature. Those who set up the architecture correctly today will save themselves the migration tomorrow.

VIALUTIONS advises companies on breaking free from Microsoft dependencies and operationalizing AI on sovereign, European infrastructure—from the initial sovereignty consultation through to productive operation.