Summary: The EU AI Act’s delayed compliance deadlines don’t change existing GDPR obligations. Learn where sensitive personal data is exposed across AI prompts, transcripts, memory, and logs, and how classification, redaction, and tokenization can reduce risk without disrupting AI applications.
The EU made two contradictory headlines this summer. On August 2, enforcement for general-purpose model providers went live. Days before that, the AI Omnibus rule went into force and pushed compliance for high-risk AI systems to December 2027.
Depending on which headline your compliance team heard, you’ve probably got people asking “Are we compliant yet?” or “Great, we have another year!” Both readings miss the critical point: neither date changes what GDPR requires for sensitive data moving through your AI applications. You already need to be protecting sensitive data in AI applications, and have needed to since the beginning.
What the AI Act Actually Requires
The model provider rules govern companies like OpenAI, Anthropic, Google, and the rest. If you’re deploying applications on top of their models instead of building your own, you didn’t miss an August deadline.
Instead, you might care about the December 2027 deadline for “high-risk systems” which requires data governance, automatic logging, human oversight, and conformity assessments. “High risk” is a use case list, and includes things like employment decisions, credit, biometrics, education, and essential services. Internal copilots and customer service chatbots aren’t on that list unless they’re used to make one of those decisions – no matter how much sensitive data flows through them.
The Obligations that Never Moved
What people forget in the AI Act news is that there are standing requirements from the EU for protecting personal data that predate the entire AI revolution. It’s GDPR, and nothing about the AI Omnibus rule changes your GDPR requirements. Article 5 of GDPR limits personal data use to only what’s required. Article 32 describes pseudonymisation and encryption as valid means to protect personal data.
Now consider where personal data lands in a typical AI app. A customer engaging with a support chatbot might provide their name, email, and account number. Their chat exchange is sent to the model provider, stored in a chat transcript, and saved to memories for the user’s next session. The personal data might also make its way to logs and analytics. Each of these is processing under GDPR, today. If your model is US-hosted, sending it clear-text customer data can also count as an international data transfer under Chapter V.
GDPR access requests make the problem concrete. Under Article 15, a customer can ask for a copy of the personal data you hold about them. If their personal information sits in your AI transcripts, memories, and logs today, how long would it take your team to answer that request?
None of this waits until December 2027. Regulators looking at your AI application today don’t need the AI Act to ask you what’s in your transcripts.
The AI Act does add one obligation that touches data protection: logging. If your system is high-risk, Article 12 requires logging as a part of system design, and Article 26 requires you to keep those logs for at least 6 months, starting December 2027. The contents of those logs are still governed by GDPR. They should hold only the personal data the purpose requires, for no longer than the purpose needs. If your application logs the whole exchange (user prompts, model answers, and tool calls), that log becomes a second copy of the personal data exchanged in the conversation.
The solution is to keep personal data out of your logs – and anywhere else it isn’t required. Separate the record of what happened from the content of what was said. An audit trail has to show what personal data was found and what you did to redact or secure that data.
Protecting Your Data Without Breaking Your Application
The simplest solution is to strip sensitive data before it reaches the model, but that can break downstream systems that require the real values – such as an API to book an appointment that requires an account number or an escalation to a human support agent who needs a name and email. Instead of stripping the data, consider classifying the data going to the model and deciding, per value, how to protect it. Some things should be redacted outright – anything not relevant for the application. Other detected identifiers can be replaced with a reversible placeholder. The model still understands and reacts to the sentence, the transcript, memory, and logs hold the placeholder, and an authorized system can still exchange that placeholder for the real value.
This is pseudonymisation. Whoever can reverse the placeholder can still identify the person, so the data stays personal and your controller obligations stand – including data processing agreements with the company operating the data vault. What changes is exposure. A leaked transcript holds those placeholders instead of account numbers. Prompts sent to US-hosted models are stripped of detected identifiers, and logs stop being a copy of conversations.
This is what ALTR’s AI Data Cloak does. It classifies sensitive values in prompts, agent memory, and tool calls, then redacts them or swaps them for placeholders backed by the same PCI DSS-certified vaulted tokenization ALTR uses for databases. Authorized systems can retrieve the real value, and the audit log records every protection decision and every access request.
The AI Act deadline will arrive eventually and, if your use case is high-risk, you need to plan for it. But the reason to protect personal data in your AI applications was never the AI Act; GDPR applied the whole time. AI just makes the data harder to track.
If your AI rollout is stalled on data protection, or shipping without answers for your security or compliance teams, get in touch for a demo. ALTR classifies and protects sensitive data in your databases, and now in your AI applications.