What does the EU AI Act require for data sovereignty?
Under Regulation (EU) 2024/1689, providers and deployers of high-risk AI systems must implement documented data governance practices covering training data quality, bias examination, and data access controls. These obligations, anchored in Article 10, came into force on August 2, 2026.
Enterprises using third-party LLM providers for high-risk applications must also satisfy GDPR Chapter V requirements for cross-border data transfers. Non-compliance with high-risk AI obligations can result in fines up to €15 million or 3% of global annual turnover.
TL;DR - Key Takeaways
- The EU AI Act's high-risk AI obligations, including Article 10 data governance requirements, became enforceable on August 2, 2026. If you have not started compliance work, you are already behind.
- Article 10 requires providers of high-risk AI systems to implement data governance practices covering training data collection, bias examination, and documentation of data gaps. You cannot outsource this obligation to your LLM vendor.
- When your AI system processes EU personal data and sends it to a non-EU LLM provider, both the EU AI Act and GDPR Chapter V apply simultaneously. Having a Standard Contractual Clause does not mean you have data sovereignty.
- Third-party LLM providers introduce a sovereignty gap: your data governance obligations exist regardless of whether the model training or inference happens outside your control.
- A conformity assessment (Article 43) is required before placing a high-risk AI system on the EU market. Data governance documentation under Article 10 is a prerequisite for passing it.
The EU AI Act does not just regulate what AI systems do. It regulates what happens to your data before, during, and after AI processing. For high-risk AI systems, that means documented data governance, training data quality controls, bias documentation, and full audit trails.
If you are using a US-based LLM to process EU data in a high-risk context, you have a GDPR problem layered on top of an AI Act problem. This article maps the specific obligations and gives you a practical checklist.
Related article: EU AI Act Enterprise Compliance Guide 2026
Nobody Was Ready for August 2
Ask most enterprise security teams when the EU AI Act becomes their problem, and you will hear one of three answers: "next year," "when regulators start enforcing," or a vague reference to 2027.
Two days ago, on August 2, 2026, the high-risk AI system obligations under Regulation (EU) 2024/1689 became enforceable across the EU.
Not guidance. Not a grace period. The real thing.
This does not mean your legal team missed a memo. The EU AI Act is genuinely complex. It rolled out in phases, and the phase that matters most for data-intensive enterprise AI systems, Title III on high-risk AI, just arrived. If your organization runs AI systems that touch credit scoring, employment, education, critical infrastructure, biometric identification, or medical devices, you are now subject to data governance rules that did not exist in enforceable form last week.
Here is what those rules actually require.
)
What "High-Risk" Means for Your Data
The EU AI Act defines high-risk AI systems through Annex III. The list covers AI used in biometric identification, critical infrastructure management, educational access decisions, employment and worker management, access to essential services, law enforcement, migration and border control, and administration of justice.
If that sounds broad, it is. Most large enterprises running AI at scale in regulated industries will have at least one system in scope.
What matters for data sovereignty is not just whether your system is high-risk. It is what obligations attach to the data flowing through it.
Article 10: The Data Obligation You Cannot Delegate
Article 10 of the EU AI Act is the core data governance requirement for high-risk AI systems that use training data.
It requires providers to apply appropriate data governance and management practices. In practice, that means:
1. Data collection and origin
You must document where training data came from, how it was collected, and under what conditions. "We downloaded it from the internet" is not a compliant answer.
2. Pre-processing documentation
Any annotation, labeling, cleaning, enrichment, or aggregation of training data must be documented. The methodology matters.
3. Bias examination
Training and validation data must be examined for possible biases that could affect the system's outputs. You must document what was found and how it was addressed.
4. Relevance and representativeness
Data sets must be relevant, sufficiently representative for the intended purpose, and as free of errors as possible.
5. Special category personal data
Article 10(5) permits the use of special categories of personal data in training only when strictly necessary for bias detection and correction, subject to strict safeguards.
What Article 10 does not allow: pointing at your LLM vendor and saying they handle this. The obligation sits with the provider of the high-risk AI system, which in most enterprise deployments is you, not OpenAI, Anthropic, or Google.
Articles 11-13: Documentation and Transparency Obligations
Article 10 is not the only data-related obligation. Articles 11, 12, and 13 layer additional requirements on top.
- Article 11: requires technical documentation that includes the design choices related to training data, the data sets used for training, validation, and testing, and the intended purpose of each.
- Article 12: requires high-risk AI systems to have logging capabilities that automatically record events relevant to identifying risks and material modifications throughout the system's lifetime. Your audit trail has to be built into the system, not added later.
- Article 13: requires that providers give deployers information sufficient to understand the training data used and its limitations. If you are the deployer buying a third-party AI product, you have a right to this information. If you cannot get it, that is a risk flag.
)
Where GDPR and the AI Act Collide
The EU AI Act is not a replacement for GDPR. It runs in parallel. And for enterprises using AI that processes EU personal data, the two frameworks create overlapping obligations that are easy to underestimate.
The collision point is data transfer.
When your high-risk AI system sends EU personal data to a US-based LLM provider for inference or training, GDPR Chapter V applies. Chapter V governs transfers of personal data to third countries outside the European Economic Area. The mechanisms include Standard Contractual Clauses (SCCs), Binding Corporate Rules, and adequacy decisions.
Here is the problem: a valid SCC satisfies GDPR's transfer requirement. It does not give you data sovereignty.
Signing an SCC means your LLM vendor has contractually agreed to certain protections. It does not mean you know where your data is processed, whether it is used in model training, or whether a court order from a non-EU jurisdiction could compel its disclosure.
The EU AI Act now adds an additional layer. Under Article 10, you are responsible for documenting your training data and its properties. If your training data includes EU personal data processed via a third-party provider under an SCC, you still carry the Article 10 documentation obligation. The contract does not transfer it.
For a detailed breakdown of what transfer mechanisms actually protect and where the gaps are, see AI Data Sovereignty: Why Enterprises Need It Before Deploying LLMs.
The Third-Party LLM Provider Problem
Most enterprises using AI are not building models from scratch. They are calling APIs. This creates a specific data sovereignty gap that the EU AI Act makes harder to ignore.
When you build a high-risk AI application on top of a third-party LLM:
You are the provider of the high-risk AI system. The model vendor is your supplier. The data governance obligations in Article 10 apply to you, not them.
You need documentation of the training data used in the model, the bias examination conducted, and the representativeness of the data for your intended use case. Most commercial LLM providers offer limited visibility into this. Their model cards are public but incomplete for compliance purposes.
You need processing agreements that specifically address Article 10 obligations, not just GDPR data processing agreements.
You are responsible for the conformity assessment under Article 43 before placing the system on the market or putting it into service.
This is not hypothetical. The obligation sits with the organization deploying the system for a specific high-risk purpose, even if the underlying model was built by someone else.
)
Enforcement Timeline
| Date | What becomes enforceable |
|---|---|
| August 1, 2024 | EU AI Act enters into force |
| February 2, 2025 | Prohibited AI practices (Article 5); governance provisions |
| August 2, 2025 | GPAI model obligations; EU AI Office established |
| August 2, 2026 | High-risk AI system obligations including Article 10 data governance (NOW) |
| August 2, 2027 | High-risk AI systems listed in Annex I (safety components in regulated products) |
Fines for high-risk AI violations (including Article 10 data governance failures): up to €15 million or 3% of global annual turnover, whichever is higher.
Fines for prohibited AI practice violations: up to €35 million or 7% of global annual turnover.
Compliance Checklist: Data Sovereignty Under the EU AI Act
Use this to assess your current position. Each item maps to a specific obligation.
1. Classify your AI systems against Annex III
Do any of your AI systems fall into the high-risk categories? Start here. If yes, all obligations below apply.
2. Assign a provider/deployer role
Are you the provider (placing the system on the market) or the deployer (using it in your organization)? Obligations differ. Providers carry the heaviest data governance burden.
3. Document training data under Article 10
Where did training data come from? What pre-processing was applied? What bias examination was conducted? This must be in your technical documentation.
4. Implement logging under Article 12
Does your system automatically log events throughout its lifecycle? Logging must be built into the system, not bolted on.
5. Map cross-border data flows against GDPR Chapter V
Is EU personal data transferred to non-EU LLM providers? What transfer mechanism applies? Document this separately from your Article 10 documentation.
6. Review third-party LLM contracts
Do your agreements with LLM vendors address Article 10 obligations? Do they provide the training data documentation you need for your own compliance?
7. Prepare for conformity assessment (Article 43)
High-risk AI systems require a conformity assessment before market placement. Your data governance documentation is a prerequisite input.
8. Register in the EU AI Act database (Article 71)
Providers of high-risk AI systems must register in the EU-wide database of high-risk AI systems.
For the complete sovereign AI architecture that satisfies these requirements at the infrastructure level, see How to Build a Sovereign AI Architecture.
Frequently Asked Questions about Data Sovereignty Requirements under the EU AI Act
1. What does the EU AI Act require for data sovereignty?
The EU AI Act (Regulation (EU) 2024/1689) requires providers of high-risk AI systems to implement documented data governance practices under Article 10. These include training data documentation, bias examination, data quality standards, and special safeguards for personal data in AI training. These obligations sit with the organization deploying the high-risk AI system, not the underlying model vendor. For personal data, GDPR Chapter V transfer requirements also apply simultaneously.
2. Which AI systems are considered high-risk under the EU AI Act?
High-risk AI systems are listed in Annex III of Regulation (EU) 2024/1689. The categories include AI used in biometric identification, critical infrastructure management, education and vocational training, employment and worker management, access to essential services, law enforcement, migration and asylum, and administration of justice. Systems used as safety components in regulated products (medical devices, machinery, aviation) are also covered under Annex I.
3. Does using a third-party LLM API relieve me of EU AI Act data obligations?
No. If you build a high-risk AI application on a third-party LLM, you are the provider of that high-risk system for EU AI Act purposes. You carry the Article 10 data governance obligations, the Article 11 technical documentation obligation, and the Article 43 conformity assessment obligation. Your contract with the LLM vendor does not transfer these to them.
4. What is the difference between EU AI Act data obligations and GDPR?
GDPR governs the processing of personal data, including cross-border transfers under Chapter V. The EU AI Act adds data governance obligations specific to AI systems, including training data quality, bias documentation, and audit logging. The two frameworks apply simultaneously. Having a GDPR-compliant data processing agreement with your LLM vendor does not satisfy your EU AI Act Article 10 obligations, and vice versa.
5. When do EU AI Act data obligations apply?
The data governance obligations under Article 10 for high-risk AI systems became enforceable on August 2, 2026. The EU AI Act entered into force on August 1, 2024, with a 24-month implementation period for the main high-risk AI provisions. Certain AI systems listed in Annex I (safety components in regulated products) have an extended deadline of August 2, 2027.
Related Articles
- The Complete Guide to Data Sovereignty for Enterprise AI (2026)
- Data Sovereignty vs Data Residency vs Data Localization
- AI Data Sovereignty: Why Enterprises Need It Before Deploying LLMs
- How to Build a Sovereign AI Architecture
About the Author
Roger Howroyd is Head of Global SEO and AI at NeuralTrust, where he leads the company's search strategy across SEO, AEO, GEO, and LLM optimization. He specializes in AI-powered search, content strategy, backlink development, and SEM. Connect on LinkedIn.
NeuralTrust is an AI agent security platform, recognized in the Gartner Hype Cycle for Application Security 2026, the Gartner Hype Cycle for Infrastructure Security 2026, the Gartner 2025 Market Guide for AI Gateways and Guardian Agents, and the KuppingerCole 2025 Leadership Compass for Generative AI Defense. ISO 27001 certified. Headquartered in Barcelona.
)
)
)
)
)