Data Sovereignty and AI: How Enterprises Keep Their LLM Inside Their Own Infrastructure

Key Takeaways

• Data sovereignty in enterprise AI analytics means AI models execute inside the customer's own infrastructure. No data leaves, and no external cloud provider has access.
• The CLOUD Act gives US authorities legal authority to demand access to data held by US companies regardless of where that data is physically stored, including data stored in EU data centers by US cloud providers.
• Bring Your Own LLM, or BYOLLM, is the practical mechanism for data sovereignty. Enterprises connect their own approved LLM to the analytics platform instead of routing queries through a vendor-controlled model.
• GoodData.AI supports on-premises AI deployment through GoodData Cloud Native. AI models run locally on the customer's servers, with no data leaving the customer's infrastructure.
• DORA, effective since January 2025, together with NIS2, the EU AI Act, and GDPR creates a compounding regulatory requirement for data sovereignty in analytics, particularly for financial services, insurance, and critical infrastructure operators.

Why "Stored in the EU" Is Not the Same as "Sovereign"

The dominant misconception in enterprise AI procurement is that choosing EU data center hosting solves the sovereignty problem. It does not. Data stored in an EU data center by a US cloud provider remains subject to the US CLOUD Act, a 2018 law that gives US authorities the authority to compel US companies to produce data held anywhere in the world, regardless of the country where the data physically resides.

In July 2025, public reporting indicated that a Microsoft executive acknowledged this limitation, stating that the company cannot guarantee data sovereignty for European customers if the US government demands access under the CLOUD Act. This was not a policy announcement. It was a factual description of an existing legal reality that enterprise legal teams had been navigating quietly for years. For enterprises that process customer financial records, insurance contracts, patient data, or proprietary manufacturing metrics through AI systems, this admission reframed the vendor selection conversation.

In GoodData.AI's enterprise evaluations across the DACH market, the question that legal teams consistently raise is not where the data center is located, but who legally controls the infrastructure running the AI. Once that distinction is clear, the architectural requirements follow directly.

The clearest architectural response to CLOUD Act exposure is removing US-controlled infrastructure from the data processing chain entirely. This means either self-hosted deployment on the enterprise's own infrastructure or deployment on European-owned cloud infrastructure, not just EU-region nodes of US hyperscalers.

The Regulatory Stack That Makes Sovereignty Non-Negotiable in DACH

DACH enterprises in regulated industries face a compounding set of requirements that each independently justify data sovereignty architecture and collectively make it mandatory.

GDPR

GDPR prohibits transfers of personal data to third countries without adequate safeguards. Standard Contractual Clauses (SCCs) provide a legal mechanism for transfers to US providers, but SCCs cannot override CLOUD Act obligations. Legal teams in German financial institutions and insurance companies increasingly treat this as an unresolved tension rather than a solved problem. In practice, this means any AI analytics platform that routes data through US-controlled infrastructure carries residual legal risk that SCCs alone cannot eliminate.

DORA

The Digital Operational Resilience Act has been in force since January 2025. It applies to financial entities across the EU and imposes strict requirements on third-party IT service providers, including AI vendors. DORA requires financial institutions to maintain full visibility and control over their digital supply chain, including the right to audit and terminate service providers. For AI analytics specifically, this means vendors must be able to demonstrate where data is processed, who has access, and how the supply chain can be audited end to end.

NIS2

The revised EU directive on cybersecurity expanded the scope of regulated entities significantly in 2024, bringing manufacturers, pharmaceutical companies, and logistics operators under mandatory cybersecurity obligations that include data handling controls. For these sectors, AI analytics platforms that process operational data through external infrastructure introduce supply chain risk that NIS2 compliance programs must account for.

EU AI Act

The EU AI Act adds a fourth layer: high-risk AI systems used in credit scoring, insurance risk assessment, HR decisions, or critical infrastructure management must implement continuous risk management and maintain audit trails for all AI-generated outputs. Article 12 logging requirements, which mandate automatic event recording throughout the lifetime of every high-risk AI system, take effect on 2 August 2026. Organizations deploying AI analytics in high-risk contexts need compliant audit infrastructure in place before that date. A platform that processes this data through external infrastructure makes the audit trail structurally incomplete and difficult to defend in a regulatory review.

Taken together, these four frameworks make data sovereignty in AI analytics less of a procurement preference and more of a basic compliance requirement.

What BYOLLM Actually Means in an Analytics Context

Bring Your Own LLM, or BYOLLM, is the technical mechanism that enables data sovereignty in AI-powered analytics. In a standard AI analytics deployment, the platform vendor controls which LLM processes the queries, typically routing requests to OpenAI, Azure OpenAI, or Amazon Bedrock. Every query, every data summary, and every AI-generated insight passes through infrastructure and models the enterprise does not control.

BYOLLM inverts this. The enterprise selects, hosts, and controls the LLM. The analytics platform connects to the enterprise's model rather than a vendor-hosted one. The result: data never leaves the enterprise's infrastructure, the enterprise chooses models aligned with its regulatory and security requirements, and there is no vendor lock-in on the AI layer.

In practice, BYOLLM in an analytics context requires the platform to support multiple LLM integrations, not just one preferred partner. GoodData.AI supports OpenAI, Azure Foundry, Amazon Bedrock, and self-hosted open-source models, including Llama and Mistral variants, through the same interface. For enterprises that need to run models locally, GoodData Cloud Native deploys the entire AI stack, including model inference, on the enterprise's own servers. Small models handle routing, medium models handle summarization, and larger models handle generation, all running locally, with privacy, performance, and cost controlled entirely by the enterprise.

This architecture answers the question German and Austrian legal teams keep coming back to in AI vendor evaluations: not "where is the data center?" but "who controls the model processing our data?"

How GoodData.AI's Architecture Addresses Sovereignty by Design

GoodData.AI offers two deployment models that address data sovereignty at different levels of infrastructure control.

GoodData Cloud is a fully managed SaaS offering hosted in the EU region on Azure and AWS. It is GDPR-compliant, supports EU data residency, and is appropriate for enterprises that require EU-region hosting but do not need full infrastructure control. It does not eliminate CLOUD Act exposure because it runs on US-owned infrastructure.

GoodData Cloud Native is the deployment model for enterprises that require full sovereignty. It runs on the enterprise's own infrastructure: on-premises, private cloud, or any combination of Azure, AWS, Google Cloud, Docker, or Kubernetes within the enterprise's own environment. The AI stack, including model inference, runs locally. For this deployment, data processing stays within infrastructure the enterprise fully operates, which materially reduces CLOUD Act exposure by removing US-controlled infrastructure from the processing chain.

GoodData.AI's position on this is explicit: sovereign AI analytics requires that AI models execute inside the customer's infrastructure, not in vendor-controlled cloud environments. This is not a feature flag or a compliance add-on. It is a deployment architecture designed from the ground up for enterprises where data leaving the building is not an option.

A German financial services company processing credit risk data for institutional clients provides a representative example of how this plays out in practice. After evaluating multiple platforms, the decisive requirement was that the full AI stack, including model inference, had to run on their own servers, with no data transiting external infrastructure during query execution. GoodData Cloud Native was architected to meet exactly this requirement.

The governed semantic layer that underlies GoodData.AI's AI stack adds a second sovereignty dimension beyond deployment architecture. AI models in GoodData.AI do not query raw database tables. They operate on a governed semantic layer where business metrics are defined once and enforced consistently. This means the enterprise controls not just where data is processed, but what data the AI can access and how it is interpreted. For regulated industries, this is the difference between an AI system that can be audited and one that cannot.

The Practical Evaluation Checklist for Sovereign AI Analytics

Enterprises evaluating AI analytics vendors on data sovereignty grounds typically work through a consistent set of questions that most vendor sales conversations fail to address directly. The relevant questions are:

Infrastructure control: Can the entire AI execution stack, including model inference, query processing, and data handling, run on infrastructure the enterprise owns and operates? Or does any component require routing through vendor-controlled cloud services?

Model selection: Can the enterprise choose, host, and update the LLM independently? Or is the enterprise locked into a vendor-controlled model that may change without notice?

Data access scope: Does the AI model have access to raw database tables, or does it operate through a governed layer that restricts and governs what data it can see and process?

Audit trail completeness: Are all AI query inputs and outputs logged, with full lineage traceable back to source data? Can this audit trail satisfy the requirements of DORA Article 30 (contractual documentation with ICT providers) and EU AI Act Article 12 (logging requirements for high-risk AI systems)?

Certification and compliance documentation: Does the vendor hold SOC 2 Type II, ISO 27001, and EU GDPR Compliant certifications? Is a Data Processing Agreement (DPA) with SCCs available? Can the vendor produce compliance documentation for an internal legal review within the enterprise's procurement timeline?

GoodData.AI satisfies all five criteria for Cloud Native deployments. For enterprises that have gone through this checklist and found that their incumbent analytics vendor cannot answer the infrastructure control question affirmatively, GoodData.AI's AI-assisted migration tooling provides a path to move existing BI assets, including dashboards, metrics, and reports, from legacy platforms to a governed, sovereign architecture without rebuilding from scratch.

Frequently Asked Questions about Data Sovereignty