Why local pseudonymisation better protects your files

The pseudonymisation performed locally changes the risk before AI is used: the document stays on the computer, identifiers become stable codes and the key stays separate. The model chosen afterwards sees only [PERS1] or [ORG1], never the original name. This is about who reads the file during analysis, rather than a “hosted near you” slogan. Lexanon processes locally, offering code replacement or redaction through Banco, then decodes the response on the machine.

Pseudonymisation and anonymisation: understand the difference

The pseudonymisation replaces an identifier with a code. “Dupont” becomes [PERS1]. “SAS Acme” becomes [ORG1]. The same person or company keeps the same code on every page and, where possible, across every document. A separately stored mapping table restores identities. As long as it exists, the data remains personal.

Anonymisation in the strict sense seeks an irreversible result: nobody should be able to re-identify anyone in practice by reasonable means. Litigation files rarely meet that threshold. Context, amounts, dates or a retained key often suffice to identify the person. Describing a “cleaned” PDF as outside the regulation would therefore be misleading.

The redacting a document is also different from pseudonymisation. Redaction masks with a rectangle or strike-through. pseudonymisation replaces identifiers and preserves a useful thread for reviewing the matter or querying a model. Choose between them during analysis. Neither guarantees compliance on its own. The legal professional remains responsible for the final check.

For methodology and product scope, the Lexanon guide and the FAQ expand on this distinction without repeating it here.

What local processing changes

The decisive factor is where the file is opened for analysis, rather than the provider's logo.

In a local workflow, the document stays on the machine for detection and replacement. Names, addresses, social security numbers and opposing parties remain on the computer while Banco builds the codes. The mapping table stays with the firm. Only afterwards, if the professional chooses, can processed text be sent to a model using the firm's chosen API key (BYOK). The model sees codes. Lexanon decodes the response locally. The professional reads restored names.

In a workflow where the raw file goes to a remote service for “cleaning”, “detection” or “preparation” before AI, the risk shifts: a third party receives identifiable content during processing. Even with a European server or sovereignty claims, the document has already left the computer. The remote preparation pipeline reads the original before the model does.

The pseudonymisation performed locally does not eliminate every risk. It reduces exposure before AI queries. It is preparation rather than a cure-all. Without this initial pseudonymisation, the first recipient of the original is the remote pipeline rather than the legal professional.

In practice, the firm also saves governance time. Instead of deciding case by case whether a trainee may paste a PDF into a chat, the rule is simple: no identifiable document leaves before processing. The professional then chooses the model, question and detail level. The original stays on the computer. Codes travel; the key stays.

This reasoning also connects with the adoption barriers discussed in why legal AI adoption remains limited : while the workflow requires sending the raw file, many firms stay away or turn to uncontrolled uses.

The circular problem: remote cleaning receives the original first

A common sales argument reassures customers about the later workflow: “the AI only sees already processed text”. The useful question comes earlier: who receives the matter to prepare it?

The remote pipeline receives the original before the model. The cleaning, identifier detection or PII redaction service therefore becomes the first recipient of identifiable content. The process is circular: the original is sent to obtain a less identifiable file, through a third party that reads exactly what was meant to be protected.

Public cloud API documentation states this plainly.

Google Cloud Sensitive Data Protection (formerly DLP) offers inspection and de-identification methods where content is sent in the API request. The file or text therefore travels to the service for inspection or transformation.

Azure AI Language uses an asynchronous workflow for PII detection and redaction in native documents: the PDF or DOCX is placed in cloud Blob storage, then detected and masked in the cloud. The document leaves before it is “cleaned”.

ChatGPT and OpenAI's Files API store and process uploaded files on their servers. A prompt saying “pseudonymise before reading” does not change the fact that the file has already been transmitted and processed remotely.

AWS Comprehend DetectPiiEntities likewise receives plain text in the request's Text parameter. The same logic applies: remote detection of transmitted content.

An AI integration that uploads a document for preparation follows the same pattern. Even with an instruction for pseudonymisation in the prompt, the remote provider has already received the original matter. A prompt cannot reverse time or remove the file from servers that just processed it. Requesting pseudonymisation after upload still means entrusting identifiable data to the cloud.

The pseudonymisation on the computer breaks this cycle. Detection and replacement happen before anything leaves. What may then be sent to a model is already coded text rather than raw identifiable content, under the firm's control. The point at which the file is read becomes the decision point rather than an overlooked preparation step.

Promising a “cleaned” result after sending the original reverses the proper order. A professional seeking to reduce risk starts with local processing, then chooses a BYOK model if desired, rather than first entrusting the matter to a remote pipeline to “prepare” information it was not meant to see.

The mapping table: a central component

Without a table, a code such as [PERS1] is just an opaque alias. With a table, pseudonymisation remains reversible for the key holder. This is precisely what distinguishes it from permanently deleting identifiers.

A useful table has several properties.

Consistency: the same entity gets the same code everywhere. Otherwise, the model and professional lose track. “Dupont” on page 2 and “Mr Dupont” on page 17 should both become [PERS1] if they refer to the same person.

Separation: the table is not pasted into the PDF exported for AI. It stays separate, with the firm, under local control.

Readable categories: people, organisations, places and technical identifiers. Categories depend on document type. A commercial contract has different priorities from criminal case evidence.

Human review: no engine guarantees exhaustive detection. A handwritten signature, stamp, email header or metadata can still identify someone. Review remains necessary before disclosure.

In Lexanon, this table accompanies the pseudonymisationmode. Redaction masks content without producing the same narrative references. Both use Banco during analysis. The firm chooses according to the destination: human sharing where masking is sufficient, or AI preparation where codes preserve structure.

For document batches, code stability becomes critical. If each file invents its own numbering, the model sees ten people where there is only one. Consistent pseudonymisation across the matter prevents this. The professional can merge, correct and approve before export.

How Lexanon manages the workflow

Lexanon is desktop software. Document analysis runs locally. The document does not leave the machine for this step.

During analysis through Banco, the firm chooses:

1. the pseudonymisation : replacement with codes such as [PERS1], [ORG1], with a separate key;
2. or redaction: masking the relevant areas.

Both options use Banco. An engine installed on the computer reads the file, rather than “our cloud AI”. The data remains personal. Lexanon does not claim to take it outside the regulation or guarantee automatic compliance.

Only then comes BYOK. The firm supplies its own API key for its chosen model. The prompt is sent already processed. Lexanon decodes the response on the computer. The professional reads the restored text, reviews it and decides.

Public prices: €450 excluding VAT per year or €45 excluding VAT per month, with a 7-day trial. Contact: [email protected].

This workflow meets a simple constraint: reduce risk before AI through local pseudonymisation or redaction, without banning model use or confusing a remote “preparation” pipeline with local reading of the file.

FAQ

Does local pseudonymisation take data outside the GDPR?

No. pseudonymisation reduces certain risks. It does not make data anonymous while a key, context or identifying details remain. The firm remains responsible for processing and disclosure decisions. A tool speeds up detection; it does not issue a compliance certificate.

Why process locally before sending text to AI?

Because the risky step is often the first reading of the raw file. If that happens on the computer, the remote model receives only codes. pseudonymisation prepares this text. The response is then decoded locally under the legal professional's control.

Does a remote cleaning or detection service receive my matter in plain text?

Yes, in the usual cloud PII detection or redaction API workflow: content is sent in the request or uploaded before processing. The remote service reads the original to “prepare” the file. Local pseudonymisation avoids that initial disclosure. The pipeline never receives what it should not have seen.

Does Lexanon pseudonymise or redact?

Both options are available during analysis through Banco: replacement with stable codes and a separate key, or masking of the relevant areas. Choose according to the destination: sharing with a person or preparing a BYOK AI query.

What happens to the mapping table?

It stays with the firm, separate from the text sent to the model. Without it, identities cannot be restored in a controlled way. With it, pseudonymisation remains reversible for the key holder. Lexanon then decodes responses on the computer.

Conclusion

The pseudonymisation performed locally does not promise the impossible. It changes the order: first pseudonymisation of the document on the computer, then model selection. Stable codes preserve the thread of the matter. The key stays separate. Redaction remains available where masking suffices. Lexanon manages the choice locally through Banco and decodes responses on the machine.

The remote pipeline receives the original before the model. Local processing breaks that cycle. For more on masking versus codes, see redaction of lawyers' documents. For the adoption context, see why legal AI adoption remains limited. Methodology and product questions: guide and FAQ.

Notice. This article provides general information about pseudonymisation of legal documents and local processing. It is not personalised legal advice. The firm remains responsible for assessing each document and deciding whether to disclose it.