EU AI Act compliance in 2026: what it actually requires for PII handling

The EU AI Act became fully applicable in August 2026 for most high-risk systems. If you're building or deploying AI in the EU — or selling AI products to EU customers — you're in scope. The question is what "in scope" actually means for how you handle personal data.

The AI Act and GDPR are not the same thing

A lot of compliance thinking conflates the two. GDPR is about personal data. The AI Act is about AI systems and their risk. They overlap — a lot — but they're separate regimes with separate obligations and separate enforcement bodies.

GDPR already requires data minimisation, purpose limitation, and privacy by design. The AI Act adds requirements around transparency, human oversight, technical robustness, and accuracy — specifically for high-risk systems.

If your AI system handles personal data and falls into a high-risk category (employment decisions, credit scoring, healthcare, critical infrastructure), you need to comply with both. And they interact in awkward ways.

What counts as high-risk under the AI Act

Annex III of the AI Act lists the high-risk categories. These include systems that assess creditworthiness, make decisions about employment or worker management, categorise people, and evaluate risks in healthcare. If your AI product touches any of these areas, you're high-risk.

High-risk systems require a conformity assessment, technical documentation, a quality management system, post-market monitoring, and — critically — data governance measures. That last one is where PII handling gets complicated.

The data governance requirement

Article 10 of the AI Act requires that training and input data for high-risk systems be subject to data governance practices. This includes relevance, representativeness, and quality controls. It also explicitly requires that personal data used in high-risk AI systems be subject to appropriate data minimisation.

In practice, this means you can't just feed raw customer data into your AI system and hope for the best. You need documented processes for what personal data enters the system, why it's necessary, and how you ensure it's not used beyond its stated purpose.

The logging requirement

High-risk systems must automatically record events throughout their lifecycle — what inputs were processed, what outputs were produced, when and by whom. This logging requirement exists to enable post-incident investigation and regulatory audit.

Here's the problem: if you log prompts and responses containing personal data, you've created a GDPR problem. You're retaining personal data beyond its operational purpose, possibly indefinitely, in a log store that may not have appropriate access controls.

The solution is metadata-only logging. You record that a request happened, what entity types were detected, what action was taken, and the latency. You do not log the content. This satisfies the AI Act's audit trail requirement without creating a GDPR retention problem.

What this means operationally

• Scrub PII from prompts before they reach your LLM provider — the provider becomes a processor, not a controller
• Log metadata about requests, not request content
• Document your PII detection and remediation process as part of your technical documentation
• Include your guardrail configuration in your conformity assessment evidence
• Monitor for drift — AI systems degrade; your PII detection rates should be tracked over time

The EU sovereignty angle

The AI Act doesn't explicitly require EU hosting. But many public sector clients and regulated industries in the EU are moving to require it contractually. If your LLM provider is US-based and you're sending personal data in prompts, you have a Chapter V GDPR problem regardless of what the AI Act says.

Guarrix runs on Scaleway in France and STACKIT in Germany for enterprise clients. No data crosses the EU border. The scrubbed prompt that reaches your LLM provider contains no personal data — so the transfer is clean.