GDPR has been in force since 2018, and yet here we are: vast swaths of organizations believe they're compliant but are nonetheless running AI workloads on infrastructure that creates exposure they've never mapped.
The reason is often a misread of one word: transfer. GDPR Article 44 restricts moving personal data outside the European Economic Area, but "transfer" doesn't require a deliberate export. It happens through a cloud provider's routing decisions, through support access from engineers in non-EEA jurisdictions, and through the legal jurisdiction of whoever operates the infrastructure. Run AI on a US-operated cloud and your data sits within reach of US law: the CLOUD Act lets US authorities compel a US provider to produce data wherever in the world it's stored. A data center in Frankfurt doesn't change who ultimately controls access to it.
Three EU frameworks are converging on the same questions: where data lives, who controls it, and how AI systems handle it.
GDPR — Article 44 restricts transfers outside the EEA. Articles 25 and 32 require data protection by design and appropriate technical measures. For AI systems processing personal data, infrastructure controls aren't optional; they're a legal requirement.
EU AI Act — Introduces obligations for high-risk AI systems: data governance, logging and traceability, and technical documentation. Deploying AI in regulated contexts requires infrastructure that supports audit-ready data handling.
NIS2 — Raises the bar on network security for operators of essential and important services. Default-deny posture, documented controls, and incident-response SLAs are now regulatory requirements across a wide range of EU organizations.
These aren't aligned by accident. The EU is systematically closing the gap between data-protection law and AI deployment reality. The infrastructure decisions you make now determine whether you're ahead of that curve or behind it.
None of the three regimes cares what flag flies over your headquarters. They trigger on what you do and whom you touch. Well keep the same framing as above to help think about this:
GDPR follows the person. If you offer services to or monitor the behaviour of people in the European Economic Area (the 27 EU states plus Iceland, Liechtenstein, and Norway), you're in scope, whether you operate from Stockholm or San Francisco. The UK runs its own near-identical regime, UK GDPR, since Brexit.
The AI Act follows the market. It applies if you place an AI system on the EU market, if you deploy one from inside the EU or, reaching across borders, if your system's output is used in the EU. Its heaviest obligations, the documentation and logging requirements below, land on high-risk systems specifically, not on every model.
NIS2 follows the sector. It applies to medium and large organizations in designated essential and important sectors — energy, health, finance, digital infrastructure, and others — operating in the EU, with the specifics set country by country.
Here's the part that many end up skipping or misinterpreting: a US provider doesn't automatically put you offside. Since 2023, the EU-US Data Privacy Framework has given certified US firms a lawful basis to receive EU data, and thousands rely on it. The catch is that it rests on a single adequacy decision — one already under appeal at the EU's top court, and one a future ruling could pull out from under you. The Court has struck down its two predecessors, Safe Harbor and Privacy Shield, for exactly that reason. Building on it means building on ground that has collapsed twice before. In-region infrastructure removes the dependency entirely: there is no transfer to challenge and no adequacy decision to lose.
Data residency gets treated as a checkbox: pick a region, tick the box. For AI workloads it has four parts, and most setups fail at least one:
Storage in-jurisdiction — data at rest on infrastructure physically and legally within the EEA.
Compute in-jurisdiction — when AI processes personal data, the processing must occur in-jurisdiction too. Running inference on Frankfurt-stored data over compute that routes through Virginia is not residency.
Key control in-jurisdiction — encryption key management under an entity subject to EEA law. If a US provider holds your keys under a US court order, your data is reachable regardless of where the servers sit.
Support-access controls — data must not be reachable by support engineers outside the jurisdiction without explicit authorization, which requires documented access controls and audit logging.
Private AI infrastructure addresses all four by design: in-region deployment keeps storage and compute in-jurisdiction, BYO KMS keeps keys under your control, and VPC isolation plus access logging produces the audit trail compliance teams need.
GDPR governs personal data broadly. The AI Act governs AI systems specifically — and adds infrastructure requirements GDPR doesn't.
High-risk AI systems must maintain technical documentation, operational logs, and data-governance records. In healthcare, financial services, law enforcement, or critical infrastructure, these aren't optional; they require structured logging, audit-trail export, and data-lineage tracking.
When the model, the compute, and the logging layer are all operated by the same US provider, you inherit a documentation and audit dependency that's hard to satisfy under the AI Act. Private infrastructure — where you control the logging and audit layer — is a cleaner position, and a far easier one to defend in front of a regulator.
From inception, Aurora has run in-region deployment across the Nordics and other European markets, in addition to other deployments in our global network. These deployments are configured for VPC isolation with no default public routing and clients BYO KMS for full encryption-key control, a default-deny firewall posture and full access logging, exportable for compliance reporting.
The throughline across all three regulations is the same question: can you prove where your data sits, who can reach it, and what touched it? GDPR asks it about transfers, the AI Act about audit trails, NIS2 about security posture. Aurora is built so the answer is yes by default — keys you hold, traffic that stays in-region, every access logged. If you're mapping your own exposure, book a data-residency review with our infrastructure team.
Legal note: Aurora does not provide legal advice. This post reflects Aurora's understanding of EU regulatory requirements as of June 2026. Organizations should confirm compliance requirements and infrastructure applicability with their legal and compliance teams.