Image generated with AI
Sovereign AI is the ability to decide how artificial intelligence (AI) uses data, where it runs, who operates it, which models and components it depends on, and how those dependencies can be changed. It is not achieved by storing data in Europe alone. It requires effective control across the complete AI lifecycle: data and knowledge, cloud and compute, models, applications, agents, security, operations, governance, and exit.
For European enterprises1, this has become a practical business issue. AI is moving from experiments into customer service, engineering, production, administration, and decision support. As usage grows, so do consumption costs, reliance on external platforms, and the consequences of a model, price, policy, or service changing unexpectedly. Sovereignty increasingly determines whether an organization can scale AI without surrendering cost control, continuity, intellectual property, or freedom of choice.
The T-Systems view is deliberately pragmatic: sovereignty is not maximum independence at any price. It is the right, verifiable level of control for the consequence of each workload. A public-information assistant and an AI system that influences a safety-relevant production process should not use the same control profile. The objective is to make these differences explicit, design the architecture accordingly, and preserve the ability to change course.
AI dependencies are becoming operational
When a model supports a core workflow, access to that model is no longer a feature of an innovation project; it is part of the service chain. A change in availability, functionality, usage conditions, or regional access can affect employees, customers, or production. The more tightly an application is coupled to one model and one provider-specific framework, the harder it becomes to respond.
AI changes the economics of technology consumption
Many organizations are accustomed to predictable software subscriptions or infrastructure capacity. Generative AI introduces a more variable cost structure shaped by input and output volume, model size, context length, retrieval, agent loops, retry, and the number of tasks automated. A pilot may look inexpensive while usage is limited. At enterprise scale, the same architecture can generate rapidly growing consumption and make the model layer a material cost center. This is why “tokenomics” is emerging as a useful management lens: not the price of a token in isolation, but the total cost of completing a business task with an acceptable level of quality, latency, security, and control. A premium model may be justified for a complex, high-value task. It may be wasteful for classification, summarization, or routine retrieval. Conversely, running a model in a controlled European environment can improve independence but will not automatically be cheaper if utilization is poor or operations are inefficient. The decision has to consider cost per successful outcome, not marketing labels.
The regulatory environment is becoming operational
he EU AI Act became applicable on 2 August 2026, with specific obligations following different timelines. Its framework covers providers and deployers, general-purpose models, transparency, governance, and risk-based obligations. From the same date, the AI Office and national authorities began exercising enforcement responsibilities. Sovereignty does not equal compliance, but architectures with clear data flows, accountable operations, controlled change, logging, and accessible evidence make compliance work more manageable.
Together, these forces change the board-level question. It is no longer simply, “How quickly can we adopt AI?” It is, “How can we scale AI while retaining the decisions that matter?”
Image generated with AI
Sovereignty is often reduced to location. Data residency matters, but it answers only where data is stored or processed. It does not establish who can administer the environment, whether a remote operator is subject to another jurisdiction, how encryption keys are controlled, whether prompts are retained, how models are updated, or whether the application can continue if one component becomes unavailable.
A more useful enterprise model separates three dimensions:
These dimensions apply across the full AI stack. The European Commission’s 2026 Cloud Sovereignty Framework2 offers a useful parallel. It assesses strategic, legal and jurisdictional, data and AI, operational, supply-chain, technological, security and compliance, and sustainability objectives rather than relying on one location. Although the framework was created for cloud procurement, its underlying lesson is directly relevant to AI: sovereignty must be evaluated across dependencies and supported by evidence.
For T-Systems, control must survive every handoff. A controlled cloud foundation is valuable, but sovereignty can still be lost in an opaque model service, inaccessible agent memory, proprietary orchestration, or an uncontrolled support route.
You can display all external content on the website at this point.
I agree that personal data may be transmitted to third-party platforms. Read more about this in our privacy policy.
Sovereignty spans cloud, data, models, and the full technology stack. Don’t miss out on how Carsten Bange and Dr. Maja Himmer of T-Systems discuss how rising AI costs, model risks, and geopolitical dependencies are making open models, multi-cloud, European infrastructure, and sovereignty by designing strategic priorities for enterprises.
[Text generated with AI]The discussion about sovereign models is often blurred by imprecise use of “open.” Enterprises should distinguish at least three operating models.
A proprietary model accessed through an API can provide strong performance and rapid access to new capabilities. It can be entirely appropriate for workloads with public or low-sensitivity data, reversible outputs, and low continuity impact. The trade-off is limited control over model weights, training methods, update timing, and long-term availability. The enterprise controls the surrounding application but not the model itself.
An open-weight model makes its trained parameters available under defined license conditions. An organization can deploy it on selected infrastructure and gain greater control over data flows, model versions, operating location, and update timing. That is materially different from sending prompts to an external black-box API.
Open weights do not necessarily mean open source. The training data, training code, data-selection process, or complete development pipeline may remain unavailable. The license may also restrict commercial use, redistribution, or modification. Open weight therefore improves deployability and operational control, but it does not automatically provide full transparency or technological sovereignty.
A genuinely open-source approach provides broader visibility and rights across the model and its development components. In principle, this can support inspection, adaptation, independent operation, and long-term continuity. In practice, openness exists on a spectrum: source code may be available while training data is not; documentation may describe data selection without releasing the dataset; or a permissive-looking model may still depend on proprietary tooling.
The correct procurement question is not “Is the model open?” It is “Which artifacts, rights, and operational options do we actually receive?” Model cards, licenses, training documentation, evaluation evidence, security maintenance, software dependencies, and hardware requirements all belong in the assessment.
This precision prevents two errors: if an API can never support a sovereign strategy, and assuming that a downloadable model is automatically safe, transparent, maintainable, or compliant. Openness strengthens choice; it does not replace evaluation, governance, or security engineering.
Sovereignty and AI economics are often presented as competing goals. In practice, they can reinforce each other when an enterprise introduces model choice and workload routing.
Not every task requires the largest or newest model. A high-capability proprietary service may be valuable for complex reasoning, while a smaller model operated in a controlled environment may handle extraction, classification, translation, summarization, code support, or knowledge retrieval at lower cost and with stronger data control. The right answer may also change as models improve, prices shift, or the use case matures.
The architecture therefore needs an abstraction layer between applications and models. T-Systems’ AI Foundation Services provide unified access to open and closed models across cloud environments, together with retrieval, fine-tuning, assistant, and agent capabilities. The strategic value is the ability to route workloads, evaluate alternatives, and reduce provider-specific logic in business applications.
A sound economic assessment should include:
This creates a more disciplined choice than defaulting either to the highest-performing external model or to self-hosting everything. Sovereignty becomes an optimization problem with explicit constraints: quality, cost, latency, confidentiality, resilience, and regulatory exposure.
European enterprises rarely operate in a clean-slate environment. Their estates combine public cloud, private cloud, on-premises systems, sector platforms, edge locations, and legacy applications. A multi-cloud strategy can reduce concentration risk and give workloads a more appropriate home. It can also multiply complexity if identities, policies, data, observability, and operations fragment across environments.
The objective is not distribution for its own sake, but to be a governable portfolio. Some use cases benefit from global platform services; others need stronger European controls. Critical or latency-sensitive workloads may require private, dedicated, or edge deployment. The workload should drive the decision.
T Cloud supports this portfolio approach by combining T-Systems cloud platforms with integration and managed services for hybrid and multi-cloud environments. The sovereign element is not simply the availability of another infrastructure. It is the ability to place workloads deliberately, apply consistent controls, and retain a credible alternative.
Portability is central to that promise. The EU Data Act requires providers of data-processing services to facilitate switching and interoperability, make relevant interfaces available, and support machine-readable export in applicable cases. It also addresses obstacles to using several services at the same time. For AI, the architectural scope of portability must extend beyond ordinary data export. Organizations need to account for prompts, embeddings, retrieval indexes, evaluation sets, policies, guardrails, adapters, agent definitions, logs, and application interfaces.
Portability should be tested rather than assumed. Can a team replace a model without rewriting the application? Can it move a retrieval workload while preserving permissions and traceability? Can it restore a critical service from controlled backups? Can it continue in a reduced mode if a provider-specific capability disappears? Answers to these questions reveal whether multi-cloud is a resilience strategy or merely a more complicated form of lock-in.
An AI assistant produces an answer. An AI agent can plan, call tools, retrieve information, update systems, initiate workflows, and act with a degree of autonomy. This makes agentic AI potentially valuable and structurally more demanding.
The model is only one part of an agent. The complete “agent harness” includes memory, enterprise data sources, retrieval, tools, identities, permissions, orchestration, communication protocols, monitoring, and human approval. Each component creates a sovereignty question.
Where does the agent’s memory reside? Which conversations or intermediate results are retained? Which systems can the agent read or change? Which identity does it use? Can tool permissions be limited by task and context? Are its actions logged in a form that supports investigation? Can the underlying model be changed without replacing the orchestration framework? Can agents communicate through open interfaces, or are they tied to a proprietary protocol?
These questions must be answered before autonomy expands. An agent that sends a message has a different consequence from one that releases a payment, alters production, modifies code, or initiates an administrative process. Sovereignty-by-design combines modularity with least privilege, tool allow lists, transaction limits, approval gates, evaluation, tamper-resistant logs, rollback, and emergency suspension.
Modularity is especially important. If a framework tightly couples the model, memory, tools, and workflow, changing the model may require replacing the entire agent stack. Open interfaces and separated components allow the enterprise to evolve each layer independently. This is the same lesson that shaped modern software architecture: avoid unnecessary coupling, define stable contracts, and design replaceability before migration becomes urgent.
T-Systems’ AI and data portfolio connects data foundations, platform foundations, AI services, applications, and managed operations. That end-to-end scope matters more with agents because control can be lost between individually acceptable components. Enterprise deployment requires a common governance model across the full action chain, not only a secure model endpoint.
Image generated with AI
A useful policy defines several sovereignty profiles and maps use cases to them. These profiles are an operating aid, not legal classifications or fixed product bundles.
Governed access is suitable for public or low-sensitivity information, reversible outputs, and uses with little impact on continuity. Controls should include an approved service with clear data-use terms, identity controls, logging, human review, and an easy way to substitute the model.
Controlled enterprise fits confidential knowledge, internal workflows, intellectual property, or uses with moderate operational dependency. Controls should include a controlled processing location, an isolated environment where required, encryption, permission-aware retrieval, version control, exportable assets, and monitored operations.
Sovereign critical applies to regulated, safety-relevant, public-authority, or operationally critical uses with limited reversibility. Controls should include strong jurisdictional and operational protections, dedicated or strongly isolated environments, controlled keys and privileged access, an auditable supply chain, robust oversight, and tested continuity and exit plans.
The classification should consider what happens if the service is unavailable, whether an output materially affects a person or physical process, what data and intellectual property are exposed, whether a human can reverse the outcome, which obligations apply, and how quickly an alternative must be activated.
This proportional model avoids weak control and over-engineering while giving business, IT, security, data, legal, procurement, and operations a shared language. The question is whether the complete system’s control profile fits the consequence of the use case.
Image generated with AI
Sovereign AI becomes deployable when responsibility is connected across the lifecycle. T-Systems brings together five layers that enterprises otherwise have to assemble and govern separately.
Sovereignty is weakest at handoffs: data to model, model to agent, cloud to operations, and policy to evidence. An accountable architecture makes those transitions governable.
Image generated with AI
Organizations do not need to solve sovereignty across the entire estate before acting. They need a repeatable assessment that exposes the most consequential gaps. Five questions provide a useful first pass.
Where are data, metadata, prompts, embeddings, model artifacts, logs, backups, and agent memories stored and processed? Where are administration, monitoring, support, and disaster recovery performed? Location alone is not enough, but it creates the map on which other controls depend.
Who can legally or technically access each layer? Who operates the infrastructure, approves models, controls encryption keys, grants tools to agents, reviews incidents, and authorizes changes? Identify parent companies, subcontractors, support teams, and privileged identities rather than relying only on the contracting entity.
How are models trained, evaluated, updated, and retired? How are data-use restrictions enforced? How can the organization recover, switch, or continue in a reduced mode? How is evidence produced continuously rather than assembled only for an audit?
What purpose was the model or system designed for? What artifacts and rights are available? What dependencies are critical? What happens when the model, price, license, protocol, or regional availability changes? What level of functional loss is acceptable during a transition?
When must a human approve an action? When should a model or use case be reclassified? When are exit, recovery, and substitution tested? When does a commercial or technical change trigger an architecture review?
Apply these questions to two or three representative workloads rather than an abstract enterprise average. Select one low-consequence use case, one confidential enterprise workflow, and one critical or regulated scenario. The comparison reveals which controls should become shared platform capabilities and which should remain workload-specific.
The output should be a prioritized backlog of data and identity gaps, architecture decisions, model alternatives, security controls, operating responsibilities, evidence, and continuity tests. That is how sovereignty becomes a funded transformation program.
Europe does not need to choose between access to global innovation and control over critical digital capabilities. It needs a both-and strategy: use global ecosystems where they fit, strengthen European infrastructure and model options, and preserve credible alternatives where dependency would create unacceptable risk.
The decisive capability is reversibility. Can an enterprise change a model, move a workload, alter operations, or continue a critical process without starting again? Can it explain which decisions remain under its control and prove that those controls work?
Sovereign AI makes these questions part of architecture and operations before dependencies harden. Done well, it can improve resilience, sharpen cost decisions, strengthen compliance readiness, and accelerate adoption by giving business owners a controlled route to production. For T-Systems, that is the practical promise of sovereignty: not less AI, but more freedom to use AI on terms the enterprise can defend.
No. Sovereign cloud provides controlled infrastructure for storage, compute, identity, encryption, and operations. Sovereign AI extends control to data pipelines, model selection and updates, prompts, retrieval, agents, tools, application logic, evaluation, monitoring, human oversight, and exit across the full lifecycle.
Not for every workload. European or locally deployable models can increase operational and technological control for sensitive or critical use cases. Other workloads may use external proprietary services when the enterprise controls data and orchestration, understands dependencies, and preserves a realistic alternative.
No. Open-weight models make trained parameters available for deployment on selected infrastructure. Open-source models provide broader visibility and rights, potentially including source code and development components. Training data, licenses, documentation, security maintenance, and operational dependencies still require separate review.
It can, but not automatically. Model choice and workload routing can avoid expensive models for tasks that smaller or locally operated models can perform effectively. Measure infrastructure, operations, integration, monitoring, retries, human review, and switching effort through cost per accepted business outcome.
Agents add memory, tools, identities, permissions, orchestration, protocols, and autonomous actions. Sovereign agent architecture requires modularity, least privilege, explicit tool controls, human approval for consequential actions, complete logging, monitoring, rollback, and the ability to replace models or components.
No. Sovereignty can support traceability, access control, documentation, oversight, resilience, and evidence, but compliance depends on the organization’s role, the system and use case, the applicable obligations, and implementation. Legal, risk, security, data, and technical teams must still assess each deployment.
1 European Commission: AI Act regulatory framework, official regulatory overview, European Commission
2 European Commission, Directorate-General for Digital Services: Sovereign Cloud Framework explained, news article, June 2026, European Commission
3 European Commission: Data Act explained, official legislative overview, European Commission
