AI and GDPR: where your company's data ends up

There's a meeting that repeats. The first two go well: the team sees the assistant working, understands what it's for, gets enthusiastic. In the third, someone from finance turns up, or the external adviser, and asks the question that freezes the project: «but is this GDPR compliant?».

It's a badly framed question, which is why it gets a bad answer. The GDPR doesn't pass or fail tools: it regulates processing. The same tool can be perfectly lawful at one company and an infringement at the one next door, depending on what data you put into it, for what purpose and what paperwork you've signed. So the useful question isn't whether something «complies». It's this one: where exactly does our data end up, who is accountable if it comes off badly, and what happens the day someone asks us to delete theirs.

What follows is what clients ask me and what I have to be able to answer in writing. I'm not a lawyer and this isn't legal advice: it's the list of what has to be settled before signing anything.

1. You are still the controller

This is the underlying misunderstanding. When you contract an AI assistant, your company remains the data controller: you decide what data is processed and what for. The vendor is the processor: it processes that data on your behalf and following your instructions. Contracting doesn't delegate accountability; it splits it, and the part that goes nowhere is yours.

From that comes the first concrete obligation: article 28 of the GDPR requires a data processing agreement between the two. It isn't a formality or a stray clause in the general conditions: it's a document with prescribed content (subject matter, duration, nature and purpose of the processing, types of data, categories of data subjects, security obligations, what happens to the data at the end). If a vendor doesn't offer you one, signed, it isn't that they have some paperwork outstanding: it's that you are handing over personal data with no basis for doing so. Ours is published and can be read in full before talking about prices, which is how I think it should always be.

And an uncomfortable consequence of being the controller: before the Spanish Data Protection Agency and before your own employees, you answer first. That the failure was the vendor's is a matter between you and your vendor.

2. Your team's free account is already a problem

Before worrying about the vendor you're going to contract, look at what is already happening. At nearly every company of 20 to 200 people there are people pasting information into AI tools with their personal account: a contract to be summarised, a client's email to be rewritten, a table with names to be sorted.

That is a transfer of data to a third party with no processing agreement, no retention control and no record of what went out. It's called shadow AI and it is, today, the most common and least monitored risk. It also has a cruel asymmetry: it's invisible until it isn't. Nobody knows anything until a client asks why their documentation is turning up where it shouldn't.

What matters for this conversation: banning it by memo doesn't work — people use those tools because they get the work done. Providing an official route that works just as well is the only thing that genuinely reduces it. A well-framed AI project doesn't add data protection risk; it channels the risk you already had running loose.

3. «Do you train on our data?» is half a question

It's the star question and it almost always gets a reassuring «no» that doesn't cover what you think. «We don't train on your data» can be true and still leave out three things that matter just as much:

Retention. Even if there's no training, how long are queries kept? Many vendors keep a history for days or weeks to detect abuse. That's legitimate, but it has to be stated and bounded.
Subprocessors. Your vendor almost certainly relies on others: hosting, third-party models, support tools. The GDPR gives you the right to know who they are and to object to changes. Ask for the list, with the name and function of each one.
Human support. Can a vendor technician read your conversations to resolve an incident? If the answer is yes — and sometimes it has to be — let it be logged like any other access.

Ask the complete question: who can see this, for how long, and where is the record that they saw it.

4. Where it's processed, not where the company is registered

A vendor having a legal entity in Spain doesn't mean your data stays in Spain. What counts is where it's actually processed, including the AI models called underneath.

If there is processing outside the European Economic Area, a valid transfer mechanism is needed: an adequacy decision from the European Commission for that country, or standard contractual clauses with the corresponding risk assessment. It isn't impossible or unusual — it's done every day — but it has to be documented, and the ground moves: what is covered today by an adequacy decision may need something else tomorrow.

A concrete question, in writing: in which region the data is processed, which models are invoked and under what mechanism if any of them leaves the EEA. A clear answer here tells you more about the vendor than any certification on the website.

5. What should never go in

The GDPR requires minimisation: processing only the data necessary for the purpose. Applied to a corporate assistant, this translates into an architecture decision, not a policy of good intentions.

Payroll, performance reviews, health data, disciplinary records: none of that needs to live in the same semantic search index as the product manuals and the procedures. And it isn't only a matter of principle. When a sensitive piece of data enters a search index by relevance, the system will do its job — find the most pertinent thing — without distinguishing who is asking. I covered it in detail here: the most common leak in corporate assistants isn't a hack, it's the design working exactly as intended.

The practical rule: if the data isn't needed to answer work questions, it doesn't go in. And if it is needed, it goes in with the permission checked at the moment of searching, not filtered afterwards.

6. The question almost nobody asks: what if someone asks to be erased?

An employee leaves and exercises their right to erasure. Or a client asks you to delete their data. In a classic system you delete a few rows and that's that. In an AI system, that data may have become vectorised fragments spread across a vector store, a search index and a conversation history.

The prudent position is the one I apply: if a vector derives from a document containing personal data, treat it as though it were still personal data. That forces you to be able to trace which fragments came from which document, delete them and reindex — not just mark the original as deleted.

Ask this question in the demo and watch the face. It's the best detector of whether someone has thought through the full lifecycle of the data or only the pretty part, the one with the flawless answer. It's in the same vein as the five questions I'd take into any meeting with a vendor.

7. What you should have in writing before signing

A signed data processing agreement, with the content required by article 28.
A list of subprocessors, with the function of each and advance notice of changes.
The processing region and, if data leaves the EEA, the mechanism covering it.
A retention policy: what is kept, for how long and for what purpose.
An erasure procedure that also reaches derived data, with a deadline and verification.
An access log, including the vendor's own accesses during support.

Setting the vendor aside, two more remain on your company's side: updating the record of processing activities to include this use, and assessing with your adviser whether a data protection impact assessment is needed — fairly likely when the processing affects employee data at any scale. And there's one more layer, the EU AI Act, which applies in phases and which for an internal assistant translates mainly into transparency obligations and training for the people who use it. Discuss it with whoever handles your compliance; it isn't something your software vendor should be deciding.

The part nobody tells you

All of this sounds like friction, and it is. But it's friction you pay once, at the start, and it tidies up the project as a side effect: it forces you to decide what information goes in, who can see it and for how long. Those are exactly the same questions you have to answer for an assistant to be useful, not just lawful.

That's why I distrust the vendor who dispatches this conversation with a «relax, we comply with everything». Compliance isn't a state you possess; it's a set of decisions you can show. Ours are written down, and if you spot a gap, I'd rather hear it from you than from the regulator.