A lawyer pastes the twenty pages of a pleading into a chat window and asks for a summary. Three seconds later the summary is there. At the same moment the client’s name, the opposing party’s name, a tax code, an IBAN, a home address and a docket number are sitting on a server that is not theirs, in a country that probably is not theirs, inside a service whose terms can change.
This is not a textbook case and it is not a beginner’s mistake. It is the normal way people use a tool that works well, and the cost only shows up later.
What is actually being transmitted
The GDPRopens in a new tab calls personal data any information that makes a person identifiable, directly or indirectly. In a court filing that covers far more than names: tax codes, dates of birth, addresses, licence plates, land registry references, IBANs, docket numbers. It often covers special categories too, because an employment case talks about health and a separation talks about family life.
Pasting that text into an outside service is processing, and it deserves to be treated as such: who receives it, on what legal basis, for how long, and whether it is used to train anything. In the regulation’s own vocabulary the firm remains the controller and the model provider is, at best, a processor under Article 28. “At best” because a personal subscription paid with a credit card has no such agreement behind it, and with no agreement there is nobody to pass a share of the responsibility to.
Above the GDPR sits professional secrecy, which does not depend on the regulation and is not discharged by a contract. The Italian bar’s code of conductopens in a new tab says it twice: Article 13 binds a lawyer to confidentiality over everything learned in the retainer, and Article 28 calls secrecy a duty that is “primary and fundamental, as well as a right”. Underneath sits Article 622 of the criminal codeopens in a new tab, which punishes disclosure of a professional secret and does not require an audience: it is enough that the information reaches somebody who had no claim to it. None of the three changes because the recipient is a program rather than a person, and none of the three is satisfied by a checkbox inside a service.
The text can stay, the names cannot
What makes the problem solvable is that almost none of the questions people ask a model need the real names. “Summarise this pleading”, “find the preliminary objections”, “rewrite this paragraph shorter”: those are questions about the structure of the text, not about the people in it. The model needs to know there is a claimant, a defendant and a judge, not who they are.
So the difference between a usable filing and an unusable one comes down to one step: replace every identifying value with a placeholder before the text leaves. And the placeholders have to be stable. If Mario Rossi becomes [FULLNAME_1] on page one and [FULLNAME_7] on page five, the model reads two different people and the summary gets the relationships wrong.
Why find-and-replace is not enough
The first instinct is to open the document and swap the names by hand. That works while the document is short and you remember everything. Then something survives: the surname written once without a first name, the company abbreviation used only in the exhibit, the date of birth in a table, the tax code split across two lines by the layout. Every value you miss is a value that leaves.
There is also the part you cannot see by reading. A .docx carries tracked changes, comments and file properties, and the name in “Author” is almost always a real person. A PDF made from a scan has a text layer under the image. Covering what you can see leaves what is underneath intact, and whoever receives the file can select it.
What to remove, in order of how much it identifies
Going from “take out the names” to “anonymise a filing” is easier with an order to follow, because memory at nine in the evening does not have one. This is the order people who do it for a living use, from the value that identifies on its own to the value that identifies alongside the others.
First, unique codes: tax code, VAT number, IBAN, docket number, file reference, licence plate, policy number, certified email address. Each of them points at one person and needs no name beside it. Second, names in every form they take: individuals, companies, but also opposing counsel and the court-appointed expert, who are proper nouns exactly like the rest. Third, identifiers of place and time: home address, date of birth, land registry sheet, parcel and unit. On their own they look generic; together they narrow to one person in two steps, which is why the GDPR speaks of identification that is “indirect” too. Fourth, whatever sits outside the body of the text: file properties, comments, tracked changes, the file name itself.
The order does one job: when time runs out, it runs out from the last line upwards and not from the first line down. A filing that still carries its comments is a problem; a filing that still carries a tax code is not anonymised at all.
What the bar associations have written
This is not a matter left to each person’s judgement. The Rome bar council has published a short guide to the use of artificial intelligence that says, in substance, two things: make the data anonymous before handing it to a tool, and do not use public chatbots for text that contains confidential information. The Turin bar has done the same with a survey document of its own. Above both sits the CCBE guideopens in a new tab (the Council of Bars and Law Societies of Europe) on the use of generative AI by lawyers, dated 2 October 2025, which repeats the same recommendation on a continental scale.
None of these is a source of law and none carries a penalty of its own. They matter anyway, for a practical reason: in front of a disciplinary board the question is not “was it forbidden”, it is “what would a diligent lawyer have done”. A guide from your own bar is precisely the yardstick that question gets measured against, and the fact that three separate bodies land on the same recommendation (strip the data first, do not use public tools with the data still in) makes it hard to call excessive.
And then you need to get back
The point that usually surfaces late is the return trip. Text with placeholders goes to the model and comes back with the same placeholders in it. That answer has to be mapped onto the real case: [FULLNAME_1] has to become the client’s name again, [IBAN_2] has to become the IBAN, or the work stays an exercise that someone has to retype.
That is why redacting and substituting are not the same thing, and why a tool that covers data permanently does not serve this purpose: there is nothing left under a black box to put back. The difference between the two deserves its own piece.
It is worth naming what you have just done, because the word changes the obligations. A filing with placeholders in it is not anonymised: it is pseudonymised, and pseudonymised data stays personal data for whoever holds the mapping. That is not a quibble. It is precisely the property that makes the text safe to send out, because the recipient has no mapping and for them that text identifies nobody. The practical consequence fits in one question, where does the mapping live, and the right answer is: wherever the case file lives, which is inside the office.
How Omissia does it
Omissia is a program that runs on the computer of whoever uses it, language model included. It opens the filing, finds the identifying values, shows them one by one where they sit, and replaces them only once they have been seen. The text that comes out has stable placeholders and pastes into any model. When the answer comes back, the app puts the real values where they belonged, reading a mapping that never left the machine.
It does not answer the question of whether to use AI on a case at all: that stays with whoever signs. What it removes is the part where the answer depends on how carefully you proofread. How it works, step by step.