The question most teams get wrong
Teams usually ask whether a given AI vendor is "GDPR compliant". That framing does not survive contact with the regulation. The GDPR does not certify products; it places obligations on the organisation that decides why and how personal data is processed. If your staff paste a customer's name, address and case history into a chat window, your organisation is the controller of that processing, whatever the vendor's marketing page says.
The practical question is narrower and more useful: does personal data need to leave your building for this task to work? In most day-to-day AI use — drafting a reply, summarising a meeting, rewriting a document — the answer is no. The model needs the shape of the problem, not the identity of the person.
The four articles that actually bite
Article 5 — data minimisation
You may only process personal data that is adequate, relevant and limited to what is necessary. Sending a full customer record to a model that only needs to rephrase two sentences fails this test before any other question is reached. Minimisation is the cheapest compliance win available, because it removes the problem rather than documenting it.
Article 28 — processors
If a cloud AI provider processes personal data on your instructions, it is a processor and you need a data processing agreement covering purpose, duration, sub-processors, security and deletion. Enterprise AI plans generally offer one. Consumer accounts, which is what most staff are actually using, generally do not.
Article 32 — security of processing
You must implement appropriate technical measures given the state of the art and the risk. Once local redaction is technically available and inexpensive, "we sent it in clear text because that was easier" becomes progressively harder to defend as appropriate.
Articles 44–49 — international transfers
Where the model runs matters. If inference happens outside the EEA, you need a valid transfer mechanism. If nothing identifying leaves the device, the transfer question largely dissolves — there is no personal data in the payload to transfer.
Accountability is the part people forget
Article 5(2) requires you to be able to demonstrate compliance. In an audit or a complaint, a policy document stating that staff should not paste personal data into AI tools is weak evidence. A log showing what was detected, what was redacted, when, and how long it took is strong evidence. The difference between the two is usually the difference between a short conversation with a regulator and a long one.
A workable position
- Assume staff are already using AI tools, because they are.
- Redact identifying data on the device, before the prompt is sent, so the payload contains no personal data.
- Restore the real values locally in the reply, so the output is still usable.
- Log every event with a timestamp and an identifier you can search later.
- Keep an enterprise agreement in place for the residual cases where identifying data genuinely must be sent.
This is the design Fairwall AI implements. Detection and redaction run on the user's own machine; the mapping between a placeholder and the real value never leaves it; and every protection event is written to a forensic audit trail you can search and export. Try the live demo to see the payload a model would actually receive.
See it on your own data.
A 30-minute walkthrough of detection, redaction and restore on the kind of documents your team actually handles.
Book a demoRelated reading
- Shadow AI: why most AI use is invisible to the organisation
- Reversible redaction, explained
- How to stop staff pasting client data into AI tools
This article is general information, not legal advice. Fairwall AI is a brand and product of Data Dynamics AI FlexCo, Vienna, Austria.
