GDPR and AI: a concrete case from a firm

A lawyer asked us, in plain words: « concretely, does article 32 of GDPR protect me if I use ChatGPT on a client file? » Here is the answer we wrote back, with the reasoning, the case law, and the practical fix.

The question, fully

He runs a small commercial litigation practice. He uses ChatGPT to draft the first pass of a structured note: list of arguments, response to the opposing brief, summary of attachments. He pays for ChatGPT Team. He does not see his prompts used anywhere. His position was simple: I pay a professional plan, my data is not used for training, article 32 of GDPR says I have to take « appropriate measures », I am taking them. So I am fine, no?

What article 32 actually says

Article 32 asks the controller and the processor to put in place technical and organizational measures « appropriate to the risk ». The text gives examples: pseudonymization, encryption, integrity, restoration, periodic testing. It does not say « buy a paid plan ». It says « do an assessment, and act accordingly ».

The CNIL's 2024 guidance on generative AI is consistent. It states three steps a professional has to walk through before sending data to a third party model:

1. Identify a clear legal basis for the processing (article 6).
2. Run a proportionality test: is the data needed for the prompt, or can the result be obtained from less?
3. Apply security measures « adapted to the sensitivity ». Pseudonymization is named explicitly.

Why « paying for the pro plan » is not the answer

A paid plan from OpenAI, Anthropic or Google addresses the training question: your prompts are not used to retrain models by default. That is real, and a meaningful improvement. It addresses none of the others:

• The provider can still retain prompts up to 30 days for abuse detection.
• The data is processed on infrastructure that is, for the major providers, located or accessible from the United States.
• A subpoena or a CLOUD Act request, however unlikely in your specific case, becomes a question your DPO must be able to answer.
• Article 32 says « appropriate to the risk ». A client file is high risk by definition. The bar to clear is high.

What « appropriate measures » actually look like

The CNIL has been explicit: pseudonymization at the source is the most defensible practice for client-level data sent to a generative AI service. The reasoning is simple. If the data leaving your firm no longer identifies the client, the issue stops being a transfer of personal data and becomes a transfer of an abstract reasoning task.

That is exactly the role Hexagone AI plays. The mapping « marker ↔ real value » stays on your machine. Only the protected version reaches ChatGPT, Claude or Cursor. When the answer comes back, the markers are swapped for the real values, locally.

The concrete workflow

1. You open the client file in Hexagone AI. It creates a « protected twin » next to it: identifiers replaced with stable markers (CLIENT_A12, AMOUNT_47, DATE_3).
2. You drag the protected twin into ChatGPT, exactly the way you would have used the original file.
3. You get back a structured note, with the same markers. Hexagone AI re-injects the real values, locally, only on the version you open.
4. An audit trail is logged automatically. You can show your DPO what was substituted, when, and on which file.

So, are you fine?

Without pseudonymization: not really. You are betting on the goodwill of a foreign provider and on the silence of an unlikely incident. With pseudonymization at the source: yes, in the strict sense that article 32 was meant to capture. The data that left your machine cannot reidentify your client. The reasoning that was done on it is yours to use.