News in Practice

CONFIDENTIALITY · PSEUDONYMISATION

“Our data must not leave the firm”

The objection is the right one, and most answers given to it are not answers. A confidentiality clause does not address the question raised.

For firms and legal departments that refuse any external processing of their matters. What a contractual undertaking is worth, and where the question that actually decides sits.

This is the first objection, it is raised in every firm and every legal department, and it is well founded. Whoever raises it is not obstructing on principle: they are applying a duty whose breach exposes them personally. The usual response consists in producing a confidentiality clause and an undertaking not to use the data. That response is serious, and it does not answer the question raised.

What a contractual undertaking is worth

It is worth a great deal, and one should start there rather than treat it with condescension. A confidentiality undertaking backed by liquidated damages, an audit right and an uncapped liability regime constitutes real legal protection. A provider who breaches it faces serious consequences, and that prospect is in itself a factor of security.

It organises the remedy. That is its function, and it is effective for almost every risk a firm encounters: a service failure, a delay, a non-conforming performance.

It does nothing else, and that is where the reasoning usually stops short.

What a firm actually checks today

It is worth describing current practice, because it is weaker than firms believe.

The contract is reviewed, often well: scope of the undertaking, liability regime, liquidated damages, governing law. That work bears entirely on the consequences of a breach.

What is almost never checked is the antecedent: what the provider actually does with the data. Technical documentation, where it exists, is read as one more declaration. It is a description of facts, and it is verified differently from an undertaking.

Why remedy is not enough here

Professional secrecy is not an obligation of result accompanied by compensation. Its breach is, in itself, the harm.

Information covered by secrecy leaves the firm and becomes accessible to a third party. The provider is at fault, it pays, the clause operates. What has been repaired? The firm's financial loss, perhaps. Not the client's position, nor the lawyer's standing under their duty.

Put differently: a firm cannot protect itself against a breach of secrecy through a mechanism that presupposes the breach has already occurred. The clause answers a risk of damage; secrecy poses a problem of a different nature.

There is also an evidential difficulty: to invoke the clause one must establish that a disclosure occurred, therefore discover it. Yet the circulation of information is almost never detectable from outside, and a firm learns of it through its consequences, months later, without being able to trace its source.

A firm cannot protect itself against a breach of secrecy through a mechanism that presupposes the breach has already occurred.

What foreign courts have held

Two decisions handed down abroad illuminate the reasoning, provided they are not transposed: legal professional privilege in the common-law sense is not the same construct as professional secrecy in civil-law systems.

In November 2025, a United Kingdom tribunal ruled on the conduct of a practitioner who had submitted client correspondence and official decisions to a consumer assistant. Its formulation, carried in the headnote of the published judgment, is unusually stark: uploading confidential documents into an open AI tool amounts to placing that information in the public domain, and therefore to breaching the confidentiality owed to the client.

The decisive point is not the severity of the phrase, it is what the phrase does not say. No leak had been identified, no client had complained: the breach was constituted by the upload itself. That is what a clause cannot capture, since it organises the remedy for a loss.

In February 2026, a United States federal court held to similar effect, finding that the provider's policy excluded any reasonable expectation of confidentiality. Another federal court reached the opposite conclusion the same day: the case law is divided, and it would be imprudent to derive a rule from it.

What runs through these decisions, notwithstanding their divergence, is a finding that the divergence does not disturb: the channel used determines the level of protection, regardless of the intention of the person using it.

Anonymisation and pseudonymisation: what each addresses

An intermediate response is often proposed: stripping identifying elements from documents before processing. It is sensible, it is effective, and it calls for two clarifications.

The first concerns vocabulary, and it is not cosmetic. Anonymisation is by definition irreversible: if the elements can be restored, the process is pseudonymisation, however robust it may be. A legal deliverable must carry real names, so restoration is necessary and the applicable regime is that of pseudonymisation. A provider using the word anonymisation for a reversible process is describing its own system inaccurately, and that imprecision should give pause.

The second concerns what the process protects. Replacing names, companies and addresses with opaque identifiers sharply reduces what a third party could draw from a leak: they obtain a legal structure without knowing whom it concerns. That is markedly better than a contractual undertaking, since it acts on the fact rather than on its remedy.

Professional secrecy, however, does not attach only to identifiers. A transaction described with its figures, its sector and its timetable may remain recognisable to someone in the market. Pseudonymisation sharply reduces exposure without eliminating it, and that is how it should be assessed: as a mitigation, not as a guarantee of impossibility.

The question of downstream sub-processors

One difficulty escapes contractual reasoning entirely, and it is systematic.

The provider a firm contracts with almost never performs alone. It relies on a hosting provider, often on a model provider, sometimes on infrastructure vendors. Those third parties are not parties to the firm's contract and are bound to it only through the chain of upstream agreements.

The firm therefore asks its client to trust a chain whose length and links it does not know. The clause organises liability in cascade without reducing the number of places through which the information passes.

The question that actually decides

It does not concern the undertakings given, it concerns the facts: what actually leaves the firm, and where does it go?

That question has a factual, verifiable answer, independent of any promise. It breaks down into four points that any firm can put to any provider, including one it already uses.

What data leaves the firm's infrastructure, and in what form: the whole document, an extract, a pseudonymised version, a derived representation, metadata?

Where is it processed physically, and under which jurisdiction do those facilities sit?

How long does it remain there, and what is left after processing?

Who, at the provider, can technically access it; and where a pseudonymisation process is used, where is the correspondence table held and who holds the key?

These four questions call for written answers signed by someone who binds the provider. An evasive answer is itself information.

The question of the key should be put systematically, because it determines everything. A pseudonymisation process whose correspondence is held in the same place and accessible to the same people as the data protects nothing: it adds a step, not a barrier. The same process with encrypted correspondence whose key is not stored alongside the encrypted data changes the nature of the risk.

Why architecture answers where a clause cannot

Data that does not leave cannot be disclosed. Data that leaves in a form from which nothing can be drawn without a key held elsewhere cannot be disclosed either. In both cases there is nothing to enforce, nothing to monitor, nothing to establish before a court: the protection rests on a state of fact rather than on future conduct.

The difference from the contractual approach is the difference between a promise and a property. A promise may be kept or not, and its observance depends on future behaviour. A property of architecture is verifiable at the moment it is observed and depends on nobody's conduct.

Two recent episodes give the measure of this. In 2026, a breach at a major legal research provider exposed data linked to several thousand corporate clients, including law firms. And in late July 2026, conversations shared with assistants were found indexed by search engines: their authors had chosen to share them, almost none expected the pages to become findable.

Neither resulted from a contractual breach: one was a security incident, the other an unanticipated consequence of a feature. In both cases the clause would have been perfectly observed.

What this implies for a professional layer

This requirement applies to every system, including those addressed to legal professionals, and it would be dishonest to pretend otherwise.

A legal processing layer relies on general-purpose models, the very ones the market knows. What distinguishes it from a consumer account is therefore not the absence of external processing, it is what leaves and in what form: documents whose identifying elements have been replaced locally before any transmission, an encrypted correspondence table whose key is not held with the data, a professional contractual regime excluding training.

The reader is therefore entitled to put the four questions above to any provider, including the one writing these lines, and to require written answers. A system claiming that no data ever leaves would deserve close examination: that is an assertion very few architectures can sustain.

What the objection still legitimately covers

It does not disappear entirely, and it would be dishonest to claim otherwise. Three points remain whatever the architecture.

The first is internal access. A system giving the whole firm a view of every matter creates a secrecy problem inside the firm itself: the question of information barriers is not settled by the fact that data does not leave.

The second is traceability. Knowing is one thing; being able to demonstrate it to a client, a bar or a court is another, and it presupposes records someone must have planned for.

The third concerns duration. An architecture is a state, and states change: a technical evolution, a change of ownership at the provider, an infrastructure migration may alter what was verified on entry. What was observed once is no undertaking for the future, and nothing obliges a provider to volunteer a change that breaches no clause.

The answer lies in one simple contractual requirement, and it is the one place where the contract regains its full usefulness: an obligation to give prior notice of any change affecting the processing or location of data, coupled with a right to terminate. The contract does not protect secrecy; it protects the firm's knowledge of its own arrangements.

That verification is therefore not a single act but a recurring requirement, to be carried in the firm's governance in the same way as the renewal of an insurance policy.