Back to blog

Data anonymization before AI: how micapa.ai does it

Pasting a contract into ChatGPT hands your client's data to someone else. Here is how we trained a model that masks it first, with real accuracy figures.

Ilustración de un documento con datos personales cubiertos por etiquetas de colores que fluyen hacia un módulo de inteligencia artificial

You have a contract, a court ruling or a 40-page case file and you want AI to summarise it. You paste it into ChatGPT and ten seconds later you have your summary. You have also just sent your client’s name, ID number, home address and bank account to someone else’s server. Data anonymization is the step almost nobody takes before using AI, and it is the step we have turned into a product with micapa.ai.

Why anonymize before the AI, not after

The practical reason is simple: whatever goes into the model has already left your building. It does not matter what the provider’s privacy policy says, or that you pay for the business plan. If the document travelled with the personal data inside it, you have already lost control over that data. Anonymizing afterwards is not a thing.

The legal reason is the GDPR. The personal data of your clients, employees or patients can only be processed for the purpose it was collected for. Running it through an AI service to draft a report is, in most cases, a new processing activity that requires a data processor agreement, a legal basis and, if the provider sits outside the European Union, additional safeguards. With an anonymized document most of that problem disappears, because what you send is no longer personal data.

And there is a business reason that tends to be forgotten: law firms, accountancy practices, clinics and HR departments are exactly the ones that stand to gain most from AI, because they live on long documents. They are also the ones using it least, because they do not dare. Stripping personal data out of the text is what unlocks that use.

Anonymization and pseudonymization are not the same thing

The two terms get mixed up a lot, so it is worth separating them. To anonymize is to remove any possibility of identifying the person, irreversibly. To pseudonymize is to replace the data with a code or label that lets you recover the original if you hold the key. The GDPR still treats pseudonymized data as personal data, but considers it a recommended security measure.

For working with AI, the useful approach is a mix of both. The language model receives the document with labels such as PERSON_1, COMPANY_2 or ADDRESS_1, and answers using those same labels. When the answer comes back to your team, the labels are swapped back for the real data, which never left your server. The AI provider sees an anonymous document. You see the complete result. At micapa.ai we call this the round trip, and it is the use case we trained the model for.

micapa.ai interface showing a document with personal data replaced by labels

Why find-and-replace is not enough

The first idea any technical team has is a list of patterns: a Spanish ID number is eight digits and a letter, an IBAN starts with a country code, a phone number has nine digits. That works for those and for little else. Names do not follow patterns. Addresses show up split across three lines. The same person is “María López García” on page one, “Mrs López” on page three and “the claimant” on page fifteen. If you mask the first and leave the other two, you have anonymized nothing: any reader can reconstruct who she is.

The other common failure is the opposite one. Systems that mask too much turn the document into Swiss cheese, and the AI can no longer understand what it is being asked. A summary of a ruling in which you cannot tell who is suing whom is worthless.

The real problem is not detecting personal data. It is detecting all of it, not over-detecting, and keeping track of who is who consistently across the whole document.

What we trained

We started where almost everyone starts: a system of patterns and lists. On real documents it never got past 57 % accuracy, and no amount of extra patterns moved it. We changed architecture and trained a small language model, with output forced into a structured format, on a corpus of more than 80,000 public documents. It detects 13 entity types: personal names, companies, addresses, official identifiers, bank accounts, phone numbers, email addresses, sensitive dates and the rest of the data that turns up in a real Spanish case file.

We measured the result on our own benchmark of 2,824 hand-annotated mentions of personal data, and these are the figures for the model that is in production today:

  • Complete leaks: 5 out of 2,824 mentions came through with nothing masked at all. Coverage of 99.8 %.
  • Personal names: F1 of 0.983, with precision of 0.980 and recall of 0.987. It is the entity that matters most and the one that performs best.
  • Companies: F1 of 0.923.
  • Addresses: F1 of 0.898. The hardest entity, because an address can run over two lines and mix street, floor, town and postcode in any order.
  • Overall F1 across the 13 types: above 0.93.
  • Identity consistency: F1 of 0.889 overall and 0.981 on names. This metric checks that “María López García”, “Mrs López” and “the claimant” receive the same label throughout the document. It is what makes the round trip possible.

A note on how to read these figures. Exact F1 penalises the model for masking “12 Main Street” when the annotation said “12 Main Street, 3rd floor B”. For the reader of the ruling, the address is masked either way. That is why the metric we care about most is coverage, and that one sits at 99.8 %.

Complex on the inside, cheap on the outside

The pipeline has several stages: text normalisation, detection, working out who is who, generating consistent labels and the reverse substitution when the answer comes back. What it does not have is a giant model in the middle. We chose a small model on purpose, and that has two consequences that matter to a small business.

The first is that it runs on modest hardware. It needs a GPU, but an ordinary GPU, not a cluster, to process a law firm’s archive. The second is that the cost per document is low, and that makes it possible to run everything you send to AI through the model, not just what someone decides is sensitive.

Request access now

Try something simple. Take the last document someone on your team pasted into ChatGPT and count how many pieces of personal data it carried. There are almost always more than anyone remembers. Then decide whether that document should have gone out like that.

micapa.ai is launching as a standalone product for cleaning documents before they go to any AI, and we are giving free access to anyone who needs it. Request access now at micapa.ai and try it on your own documents. The figures that matter are yours, not ours.