Replacing a client’s name with “Client A” before asking AI to summarise a document reduces some exposure. It does not automatically make the document anonymous. An unusual job title, an address, a precise date or the description of a situation may still allow the person to be identified.
The CNIL distinguishes anonymisation, which aims to prevent identification irreversibly, from pseudonymisation, which replaces identifiers while allowing information to be attributed again using additional data. Pseudonymised data remains personal data. That distinction should guide the language used in an interface, contract or internal policy.
Start with the task, not the whole document
Imagine a professional practice that wants to rephrase a letter. To improve its tone or structure, does the model need the client’s name, date of birth and complete case history? Often, part of the text can be removed before considering any replacement mechanism.
This example describes a preparation method, not a guarantee applicable to every case. Professional confidentiality, categories of data and rules specific to the profession need to be assessed with the organisation’s appropriate specialists.
Look for indirect clues too
Thorough preparation examines names, contact details, case references, precise locations, distinctive amounts, dates and combinations of information. It also considers attachments, filenames and metadata when those elements are transmitted to the service.
An automated tool can help detect and replace information. Its quality depends on the format, language and context, however. A poorly recognised scan or an identifier written in an unusual way may be missed. Review proportionate to the sensitivity of the material remains necessary before sending it.
Protect the mapping table
If “Client A” can be linked to a real name through a table, that table needs separate, limited access. Sending it alongside the replaced text would remove the practical benefit of keeping them apart.
Consider temporary copies and logs as well. An interface may show prepared text while a technical trace retains the original document. Describing the full data journey helps reveal differences between what the user sees and what the system actually processes.
Choose the service and permitted uses
Preparing documents does not replace assessing the provider. Reuse conditions, retention, subprocessors, processing locations and deletion procedures remain separate questions. The CNIL encourages organisations to define permitted uses and train users on the limitations of generative systems.
For your team, an explicit rule is more useful than a general instruction to be cautious. Specify the document categories allowed, the information to remove, the review procedure and the person to contact when in doubt. Plan for an accidental disclosure too.
Test before expanding usage
Prepare fictional documents that represent your usual formats: letters, tables, meeting notes and scans. Deliberately include direct and indirect identifiers, then observe what is detected, what is missed and what is removed incorrectly.
This test helps define the tool’s role and the checks people must perform. By itself, it is not a legal determination that anonymisation has been achieved. Our approach to security and control over data begins with this kind of concrete scope before selecting the integration and appropriate protections.
