The EU's Legal Framework for Private AI

You’ve heard about the AI Act. Probably NIS2. Maybe DORA if you’re in financial services. The alphabet soup of EU regulations touching AI is growing fast — and most coverage focuses on what’s banned. Emotion recognition in workplaces. Social scoring. Manipulative dark patterns.

But if you’re running AI privately — self-hosted models on your own or rented infrastructure — the question isn’t what’s prohibited. It’s what’s required. And the answer involves not one law but five overlapping frameworks, each with its own deadlines, definitions, and enforcement teeth.

Here’s the map.

Five laws, one AI stack

The EU doesn’t regulate AI with a single law. It regulates AI through layers, each targeting a different aspect of the stack:

Law	What it governs	Applies from
GDPR	Personal data in AI inputs and outputs	May 2018
AI Act	The AI system itself — risk level, transparency, oversight	August 2025–2028
Data Act	Cloud infrastructure and data portability	September 2025
NIS2	Cybersecurity for critical sectors	October 2024
CADA	EU sovereignty for cloud and AI infrastructure	Proposed June 2026

If you’re running a private LLM for research, legal analysis, or decision support, all five potentially apply. Not because you’re doing anything wrong — but because the EU regulates the entire stack from data to model to infrastructure to output.

Five overlapping laws, each targeting a different layer of the AI stack. No single regulation covers everything — and none of them disappear because you self-host.

GDPR: the foundation you already know (but might be getting wrong)

GDPR has been in force since 2018, but its application to AI keeps expanding through court rulings and regulatory guidance. Three areas matter most for private AI.

Legal basis for processing. Every time your AI system processes personal data — names in documents, email addresses in research inputs, health information in medical literature — you need a legal basis under Article 6. For most private AI use cases, that’s either “legitimate interest” (you have a genuine business reason that doesn’t override the individual’s rights) or “consent” (rare for enterprise AI). The legitimate interest route requires a balancing test — and regulators are scrutinizing these more aggressively for AI workloads than for traditional data processing.

Automated decision-making. Article 22 gives individuals the right not to be subject to decisions based solely on automated processing that produce legal effects or significantly affect them. If your AI generates recommendations that humans rubber-stamp without real review, that’s “solely automated” in practice — even if a person technically clicks “approve.”

The part most people miss: GDPR applies to your self-hosted model too. Running Llama on your own GPU doesn’t exempt you from data protection obligations. You’re still a data controller. You still need a legal basis. You still need to honor data subject rights — including the right to explanation and the right to erasure. The model being local doesn’t change the law; it just changes who’s responsible for compliance (you, not a cloud provider).

The AI Act: risk tiers and what “deployer” means

The EU AI Act is the world’s first comprehensive AI regulation, and it’s rolling out in phases. Prohibited practices took effect in February 2025. General-purpose AI model obligations applied from August 2025. Most remaining obligations take effect on 2 August 2026 — though under the May 2026 Digital Omnibus agreement, the high-risk system requirements have been pushed back to 2 December 2027 (and to August 2028 for AI embedded in regulated products).

Risk classification matters. The AI Act sorts AI systems into four tiers: unacceptable (banned), high-risk (heavy regulation), limited risk (transparency obligations), and minimal risk (largely unregulated). If your private AI assists in hiring, credit scoring, legal interpretation, or medical diagnosis, it’s likely high-risk — regardless of whether it’s self-hosted or cloud-based.

Provider vs. deployer. The AI Act distinguishes between providers (who build or place AI systems on the market) and deployers (who use them). If you download an open-weight model and run it for your organization, you’re a deployer. But if you fine-tune it substantially or integrate it into a product you offer to others, you might become a provider — with significantly heavier obligations including conformity assessments, technical documentation, and post-market monitoring.

Open-source exemptions exist, but they’re narrow. Free and open-license GPAI models whose weights and architecture are publicly available get reduced obligations — primarily transparency and copyright compliance. But if the model is classified as posing “systemic risk” (based on compute thresholds), all obligations apply regardless of license. And the exemption covers the model provider, not you as the deployer — your obligations remain the same.

Running a model on your own GPU does not exempt you from data protection obligations. Self-hosting changes who is responsible for compliance — and that someone is you.

Data Act: your right to leave

The EU Data Act has been applicable since 12 September 2025, and its cloud switching provisions directly affect anyone running AI on rented infrastructure.

Switching rights. Chapter VI requires cloud and infrastructure providers to let you move your workloads to another provider — or to your own infrastructure — at any time. The provider must initiate the switch within two months and complete it within 30 days (extendable to seven months for complex migrations). Switching charges were capped and must be eliminated entirely by 12 January 2027.

Why this matters for AI. GPU rental for AI inference is sticky. Your model, your data pipeline, your monitoring — it’s all configured for a specific provider’s infrastructure. The Data Act says your provider can’t exploit that stickiness. They must provide functional equivalence — materially comparable outcomes for the same inputs when you switch to a similar service.

The practical implication: if you’re renting GPU servers for private AI and your provider is subject to jurisdictional risks you didn’t anticipate, the Data Act guarantees your right to leave without being held hostage by technical lock-in or punitive fees.

NIS2 and DORA: if you’re in a regulated sector

The NIS2 Directive expanded EU cybersecurity obligations to 18 critical sectors — including energy, transport, healthcare, finance, digital infrastructure, and public administration. It’s been in effect since October 2024, though national transposition is still incomplete in several member states.

AI systems inherit NIS2 obligations. If you’re in a covered sector and your AI system is part of your operational infrastructure, NIS2’s requirements apply to it: risk management, incident reporting within 24 hours, supply chain security assessments, and management accountability. Penalties for essential entities reach up to 10 million euros or 2% of global revenue.

DORA adds a financial services layer. The Digital Operational Resilience Act applies specifically to financial institutions and their ICT providers. If your private AI handles anything in financial services — risk assessment, fraud detection, trading analysis — DORA requires concentration risk analysis (don’t depend on a single AI provider), regular resilience testing, and incident classification procedures.

The combined effect: running a private LLM in healthcare or financial services isn’t just an AI Act question. It’s simultaneously an NIS2/DORA question about cybersecurity and operational resilience. Your AI infrastructure is critical infrastructure — regulate it accordingly.

Your private AI is part of your infrastructure. In NIS2 sectors, it needs incident response, supply chain assessment, and management accountability — just like every other critical system.

CADA: what’s coming

The Cloud and AI Development Act (CADA) was proposed by the European Commission in June 2026 as part of the EU’s tech sovereignty package. It’s not law yet — but it signals where regulation is heading.

Three pillars. CADA aims to strengthen European cloud and AI infrastructure through: investment in EU-based high-performance computing, interoperability standards for cloud services, and — most critically — sovereignty requirements for critical use cases. Defense, public administration, and critical infrastructure would need to use “highly secure EU-based cloud capacity.”

Data localization for AI. The proposed framework would require that EU citizen data be stored and processed within EU borders for critical applications, and that AI training and deployment for those use cases use EU-compliant infrastructure. This goes further than GDPR (which allows transfers with safeguards) — it would mandate EU-only infrastructure for certain workloads.

The market context. AWS, Azure, and Google Cloud together control over 70% of the European cloud market. CADA is the EU’s attempt to rebalance this dependency. Whether it succeeds as regulation or accelerates European cloud investment, the direction is clear: the EU wants critical AI workloads on EU-controlled infrastructure.

The compliance stack in practice

Here’s what this means if you’re running a private AI system in the EU today:

Obligation	Source law	You must…
Legal basis for personal data	GDPR Art. 6	Document why you’re processing personal data through AI
Right to explanation	GDPR Art. 22	Provide meaningful information about automated decisions
Risk classification	AI Act	Classify your AI system’s risk level and meet corresponding requirements
Human oversight	AI Act (high-risk)	Ensure humans can override AI decisions that affect people
Transparency	AI Act (all GPAI)	Disclose that content is AI-generated when applicable
Data portability	Data Act Ch. VI	Ensure you can move your AI workloads between providers
Cybersecurity	NIS2	Implement risk management and incident reporting for AI infrastructure
Concentration risk	DORA (financial)	Don’t depend on a single provider for critical AI capabilities

None of these go away because you self-host. In fact, self-hosting makes you — not a cloud provider — the entity responsible for most of them.

What to do now

1. Map your AI systems to risk tiers. The next AI Act deadline is August 2026, and the high-risk conformity requirements follow from December 2027. If any of your AI systems are high-risk (HR, legal, medical, credit), start the conformity assessment process now. The six-step guide from Orrick is a practical starting point.

2. Audit your GDPR legal basis for AI processing. “We have legitimate interest” isn’t enough. Document the balancing test: what’s your interest, what’s the impact on individuals, and what safeguards do you have? The bar is higher for AI than for traditional processing.

3. Check your Article 22 compliance. If AI outputs lead to decisions that affect people — hiring recommendations, risk scores, eligibility determinations — verify that meaningful human review actually happens. “A human clicks approve” doesn’t count if they never override.

4. Review your GPU provider contract for Data Act compliance. Does it include switching provisions? Functional equivalence commitments? Elimination of switching charges by 12 January 2027? If not, the contract may already be non-compliant.

5. If you’re in a NIS2 sector, include AI in your cybersecurity risk assessment. Your private AI is part of your infrastructure. It needs incident response procedures, supply chain assessment, and management accountability — just like your other critical systems.

6. Watch CADA. It’s not law yet, but if your workloads involve government, defense, or critical infrastructure data, start planning for EU-only infrastructure requirements. The direction is unmistakable.

7. Document everything. Every regulation above requires records: processing records (GDPR), technical documentation (AI Act), risk assessments (NIS2), concentration analysis (DORA). Start building the documentation habit now. It’s cheaper to maintain compliance than to retrofit it.