THE DATA PATH OF LEGAL AI

Confidentiality Does Not Endat the Chat Window

Where Data Travels in Legal AI

READING KEY

Legal AI
Confidentiality
Personal data
Data processing agreement
Pseudonymisation
Local models

Abstract. When a lawyer sends an extract from a case file to an artificial intelligence tool, the data do not enter only a language model. Logs, temporary copies, numerical representations and security records may be created along the way, while other service providers may also gain access to the content. A promise not to use data for training, a data processing agreement or a server on the organisation’s own premises can reduce particular risks. None of these measures, by itself, proves the confidentiality of the complete system. What matters is the actual, verifiable data path — from the first input to the final copy and its deletion.

She Clicks “Send”

A lawyer is preparing a response for a company. The document open on her screen contains the name of a former employee, her medical report, emails exchanged by management, the highest amount the client is prepared to offer in settlement and an unpublished decision to sell part of the business. All the lawyer wants from an artificial intelligence tool is a suggestion for structuring the arguments in a letter.

She could select three paragraphs. To save time, she attaches the entire document.

The chat window looks clean. Beside it is a reassuring statement that business data are not used to train the model. The file is encrypted in transit. Her organisation has a data processing agreement with the provider.

She clicks “send”.

When that button is pressed, the document may not go only to a model. It can leave traces in the browser, the application, an event log, a security system, a search index, the model provider’s systems, its further service providers and backups. Some traces live for moments, others for days, and still others until an account is deleted. The chat window shows what was sent. It does not necessarily show everyone who received the content, the purposes for which they processed it, where additional copies were created or when those copies will disappear.

This does not mean that every external service is impermissible. It means that confidentiality is not a property of a polished interface, a familiar brand or a single contractual sentence. It is a property of the entire data path — and a claim that must be capable of proof.

The example in this article is wholly fictional and is not based on a real client or matter.

First: What Are We Actually Protecting?

Not every item in the lawyer’s document is confidential for the same reason.

The former employee’s name is personal data. Her medical report falls within the special categories of personal data that attract additional requirements. The maximum settlement offer is part of the lawyer’s strategy. The proposed sale of the business unit may be commercially confidential information or, if the legal conditions are met, a trade secret — even if it does not relate to an identifiable natural person.

The statement “we removed the personal data” does not therefore mean “we removed the confidentiality”.

Article 6 of the Slovenian Zakon o odvetništvu, the statute governing the legal profession, requires a lawyer to protect what a client has entrusted to them and extends that duty to other people working in the law office. The Kodeks odvetniške poklicne etike — rendered here, unofficially, as the Slovenian Code of Professional Conduct for Lawyers — also addresses information that the lawyer learns about a client in confidence. In Decision U-I-115/14, Up-218/14, the Constitutional Court of the Republic of Slovenia linked confidentiality in the lawyer–client relationship with the constitutional protection of privacy. That protection is not without limits, but it is considerably wider than the question of whether a document contains a name.

The General Data Protection Regulation (GDPR) additionally requires a legal basis, data minimisation, purpose and storage limitation, appropriate security and accountability. Data concerning health and personal data relating to criminal convictions and offences are subject to additional rules. The possibility of processing data for the establishment, exercise or defence of legal claims is not a general licence to send an entire file to any service.

The Slovenian Zakon o poslovni skrivnosti — its title rendered here, unofficially, as the Trade Secrets Act — also protects certain undisclosed business information. Client agreements, internal policies and professional standards may add further duties.

The first question before using AI is therefore not “Does this document contain personal data?” The right question is: “What in this document is confidential, to whom, and on what legal basis?”

The Chat Window Is Only the Entrance

The same document can follow an uncontrolled service chain or a proposed local routing boundary. The five review questions remain: what data, who receives them, where they go, how long they remain and what evidence records the decision.

A large language model, or LLM, is a program that produces text by drawing on patterns learned from very large quantities of language. But the model is usually only one station within a larger system.

When the lawyer attaches a file, the application first has to receive its contents. It may extract text from the document. It may perform optical character recognition on scanned pages. It may divide the text into passages, send them to a search service and pass only selected extracts to the model. If the system searches an additional collection before composing the answer, the technical term is retrieval-augmented generation, or RAG. In plain language: search first, answer second. For confidentiality, the practical point is simple: the search collection is another place where data are processed.

In such systems, passages are often converted into numerical representations known as vector embeddings. They help a computer find text with a similar meaning. Numerical form, however, is not a magic eraser. A collection may retain not only the numbers, but also the original passage, the document name, a client or matter label and the identity of the user.

The study Text Embeddings Reveal (Almost) As Much As Text exactly reconstructed 92% of short, 32-token inputs for two types of embedding in controlled conditions. Tokens are the small units into which a model divides text. The finding does not apply to every model, text or attacker. It is sufficient, however, to support an important conclusion: an embedding should not be declared safe merely because a person cannot read it at a glance.

The same applies to an event log. It may be intended to detect errors, protect the service or measure performance. If the complete user input is accidentally written to it, however, the log becomes another copy of the confidential document. A cache, which holds data temporarily for speed, or a backup created to restore a system can produce the same result.

Encryption also has a precise but limited job. An encrypted connection protects a document against interception in transit, while an encrypted disk protects stored data against certain forms of unauthorised access. The execution environment must ordinarily turn the content back into readable form before the model can process it. Encryption therefore does not mean that the contractual provider or an appropriately authorised administrator can never technically see the information. It is an essential safeguard, not a substitute for controlling access, purpose and retention.

A useful data-flow map must therefore answer at least five questions:

What exactly was created or sent?
Who can access it?
Where is it processed?
How long does it remain?
What evidence supports each answer?

If an organisation knows only the name of the model, it does not yet know the data path.

Deletion Is Not a Single Event

A user normally sees one button for deleting a conversation. A system may see several different objects: the original file, extracted text, divided passages, embeddings, the answer, a security record, conversation history and a backup. Each object may have its own retention period and deletion process.

This does not mean that providers deliberately fail to delete data. It means that a deletion claim must be precise. What is deleted: the user’s view of the conversation, or also the file behind it? When does the retention period begin? What remains for security or legal reasons? When does the information disappear from backups? Are the associated embeddings and search records marked for deletion as well?

The lawyer in our opening scene could immediately delete the conversation and reasonably conclude that it was no longer visible in her account. She could not conclude from that fact alone that every copy across the chain had disappeared at the same moment. Verifiable retention is therefore not a single number. It is a table of data types, locations, periods, exceptions and deletion procedures.

“We Do Not Train on Your Data” May Be True — and Still Not Enough

Model training is only one possible purpose for which data may be used. A provider needs to process the input to produce an answer at all. It may also process content temporarily to prevent abuse, investigate faults, provide technical support or keep the service running. An application may separately store conversation history. A selected feature may create a file or collection that remains until it is deleted.

A provider’s statement must therefore be read literally. “We do not use your data for training” is not the same as “we do not retain your data”, “no human can see your data” or “no other service provider is involved”.

OpenAI offers a useful time-stamped example. Its Enterprise privacy page, updated on 8 January 2026, says that business inputs and outputs from the listed business products and developer platform are not used to train models by default. That is an important safeguard. It does not automatically apply to every personal account, nor does it answer every question about retention.

The provider’s documentation on API data controls, checked on 22 September 2026, states that default abuse-monitoring logs may contain customer content and, subject to the documented exceptions, are retained for up to 30 days. Modified Abuse Monitoring and Zero Data Retention are available to eligible customers after approval; their effect also depends on the feature used. Stored conversations, assistants, files or vector stores can follow rules different from those for a one-off response. Information sent to an external tool also enters that tool’s own data regime.

OpenAI’s sub-processor list — its list of further processors involved in providing the service — likewise shows why the inquiry does not end with the name of the provider. Updated on 9 July 2026, it includes infrastructure, security and support providers in different locations; their involvement may depend on the service, feature and settings selected. A customer must therefore examine not only the company with which it signed an agreement, but the wider chain through which its information may travel.

This is not an accusation that the provider is breaking its promise. On the contrary, it shows why a precise promise must be understood precisely. For a legal file, it is not enough to ask whether the provider trains a model. The organisation must examine the particular account, service, feature, processing region, sub-processors, retention periods, external tools and settings in its own application.

What a Data Processing Agreement Solves — and What It Does Not

Where a provider processes personal data on behalf of a customer, Article 28 GDPR requires a contract or other binding legal act. Providers often call this a data processing agreement or data processing addendum, abbreviated to DPA. The underlying idea is straightforward: the document governs the relationship between the controller, which determines the purposes and essential means of processing, and the processor, which processes personal data on the controller’s documented instructions.

These roles are not merely headings on the first page of a contract. If a provider decides for itself why it will use data for a particular operation, it may have a different role for that purpose. If a law firm uses a personal consumer account, one cannot simply assume that the relationship is the same as under a business service contractually designed to process data on the organisation’s instructions. The actual service and actual decision-making must be assessed.

A good DPA is not decorative bureaucracy. It defines the subject matter and duration of processing, types of data, confidentiality of authorised personnel, security duties, use of sub-processors, assistance with incidents and data-subject rights, audit rights and the return or deletion of data.

But a contract governs a relationship. It does not perform the customer’s assessment for it.

A DPA can govern	A DPA does not itself decide
instructions, purposes, duration and types of data	whether the customer has a legal basis for the processing
confidentiality of authorised personnel and security measures	whether disclosure is appropriate under duties of professional secrecy
engagement and responsibility of sub-processors	whether only the minimum necessary part of the file is sent
assistance with incidents, individual rights and impact assessments	whether the selected account, feature and setting match the contract
evidence, audits and return or deletion	whether every copy in every layer has actually been deleted
contractual safeguards for international transfers	whether those safeguards are effective in the particular circumstances

The point can be reduced to one sentence: a DPA is a map of responsibilities between the parties, not permission to send any data one chooses.

Where new technology, the scale of processing and the sensitivity of the data are likely to create a high risk to people, a data protection impact assessment (DPIA) may also be required under Article 35 GDPR. A DPIA is not automatically mandatory for every question sent to a language model; the trigger is the risk of the particular processing. A DPA does not decide that question either.

The contract’s boundary is even clearer where content is not personal data. If a document reveals a company’s negotiating strategy but does not relate to an identifiable natural person, Article 28 does not protect that content by itself: it governs the processing of personal data. Professional rules, the client agreement, trade-secret law and suitable security measures must protect such information. An organisation that checks only its personal-data agreement may therefore overlook highly sensitive non-personal content.

OpenAI’s Data Processing Addendum, updated on 1 December 2025 and effective from 1 January 2026, identifies OpenAI Ireland Ltd as the provider for customers in the European Economic Area and Switzerland. Where the provider processes customer personal data on the customer’s behalf, it acts as a processor. The document addresses instructions, security, sub-processors, deletion, incidents and transfers. It also leaves the customer responsible for required notices, rights, permissions and the selection of settings. Its appendix states that the intended transfer of sensitive data is not anticipated, although such data may unexpectedly occur in unstructured content such as free-form text and attached files.

For the lawyer in our opening scene, the existence of the DPA still does not answer whether the medical report had to be sent, whether the selected feature was intended for such data, or whether three cleaned paragraphs would have been enough to suggest a structure for the letter.

The same is true of transfers from the European Economic Area. Standard Contractual Clauses can be an important mechanism. Following the judgment of the Court of Justice of the European Union in Case C-311/18, Schrems II and Commission Implementing Decision (EU) 2021/914, however, organisations must also assess the particular circumstances, the law of the destination country and any supplementary measures required. The label of a European data centre does not, by itself, reveal where support personnel may connect from or where every category of system data is processed.

Before the Boundary: Less Data, Not False Anonymity

The best time to reduce risk is before information is sent. If the model does not need the complete file for the task, it should not receive it merely because attaching it is easier.

The first step is substantive reduction: select only the passage required for a clearly defined purpose. The second is to reduce identifiability by replacing or removing unnecessary information. The third is to check whether the altered document can still reveal a person, a matter or a trade secret.

Three words are often confused at this point, with dangerous consequences.

De-identification is a useful technical umbrella term for processes that reduce identifiability. It does not, by itself, tell us what legal result has been achieved.

Pseudonymisation means that personal data can no longer be attributed to a specific person without additional information kept separately. If the lawyer replaces a name with CLIENT_A and stores the mapping securely and separately in her office, she has reduced the risk. Because the identity can be restored using the mapping, the information will normally remain personal data and data-protection law will continue to apply.

Anonymisation requires more: the person must no longer be identifiable by means reasonably likely to be used. Deleting names often falls short of that threshold.

The difference is visible in a single passage. The original contains a person’s full name. A pseudonymised version replaces it with CLIENT_A, while a separate table in the law office records the identity. In a version someone calls anonymous, the table may have been destroyed — but the person’s unique role, small town, exact date and a publicly known event may still reveal who they are. Deleting a key does not delete the world around the document.

Our fictional file might still contain this sentence:

On 14 March, the finance director of the town’s only major medical-device manufacturer was admitted for treatment following an event at a closed supervisory-board meeting.

There is no name. Yet the combination of role, industry, place, date and event may identify the person. Linking becomes easier still if the document retains a case number, public judgment, email address, filename or tracked changes.

Recital 26 GDPR therefore requires account to be taken of all the means reasonably likely to be used to identify a person. The European Data Protection Board’s Guidelines 01/2025 on Pseudonymisation emphasise transformation, separate storage of additional information and measures against unauthorised attribution. As at the cut-off date of this article, they remain labelled as a version adopted for public consultation.

The EDPB’s Guidelines 02/2026 on Anonymisation, open for comments until 30 October 2026, propose examining whether a record can be singled out, linked with other information or used to infer information about an identifiable person. Their status matters: they provide a current analytical framework, not a final text.

Legal documents are particularly difficult to clean automatically. Roles, timelines, relationships, rare events and references to public sources can all reveal people. An older preprint, Towards De-identification of Legal Texts, reported that the general tools used in its narrow, non-Slovenian corpus missed at least one name in 84% of documents. That figure is not an assessment of today’s models, nor does it tell us how a Slovenian system would perform. It is a useful warning that a simple list of names is not enough.

Reducing identifiability must also cover document properties, comments, previous versions, signatures, stamps, images and text inside scans. At the same time, legal meaning must survive. Removing the date that determines a deadline, or the role that determines a legal consequence, may protect identity while destroying the task. Rare facts and difficult cases require human review.

This is the central technical problem in cleaning legal material. Sometimes a system must generalise a fact instead of deleting it: an exact address can become a region, a date of birth can become a year, and an employer’s name can become a role. Yet each alteration may affect jurisdiction, a time limit, a person’s status or the legal relationship. A good minimisation process therefore measures not only how much identifying information has disappeared. It also asks how much legal meaning remains and how much risk of re-identification persists.

The honest objective is not a button marked “anonymise”. It is a process that shows what was detected, what was changed, what remains risky and why a particular data path was selected.

We Are Not Choosing Only a Model

The lawyer has now taken one important step. Instead of the complete file, she has selected the three paragraphs she actually needs and replaced personal names locally with consistent labels. A question remains which, at first sight, appears simple: which model should receive them?

The question is already slightly wrong. An organisation normally chooses at least four things:

the model that will generate the answer;
the service through which that model is made available;
the contractual provider that will receive the data;
the execution environment in which the answer will actually be computed.

This distinction is invisible to many users and legally decisive. ChatGPT is a service that uses models from the GPT family; it is not the model itself. A model from the same family can be accessed directly from OpenAI or through a service operated in Microsoft’s environment. Claude can be used directly through its developer or through another managed platform. Depending on licences and technical requirements, models from the Llama, Mistral, Qwen, DeepSeek and Gemma families may be run by a third-party host or by the organisation itself.

Nor does a division into “closed” and “open” models answer the confidentiality question. A closed-weight model generally cannot be downloaded into the organisation’s own environment, so an external service or platform must be used. With a model whose weights are accessible, the files containing its learned numerical parameters can be downloaded and executed elsewhere. But accessible weights do not necessarily mean open software, open training data or an unrestricted licence. Above all, they do not mean local processing. If a third party hosts the model, that host still receives the document.

The most important rule in this article is therefore:

The model’s name does not tell you who receives the document. The selected data path does.

Five Routes Through Today’s Market

The market becomes easier to understand when services are grouped by how they are used, rather than by flags or model names. The following overview is not a provider ranking and does not suggest that every service sold under one brand is identical. Names are examples of types of offering. The customer must still inspect the particular account, contract, feature and processing region.

An application programming interface, or API, is an agreed technical route through which an organisation’s application automatically sends a request to an external service and receives an answer. The user may never see the provider’s own chat window, but the data still cross the organisation’s boundary.

Route	Typical examples	Who may receive the content	For confidential legal material
public consumer chat service	personal accounts for services such as ChatGPT, Claude, Gemini, Le Chat and DeepSeek	the operator of the public service and its further providers	generally unsuitable as the default route for a complete confidential file
direct business service from a model developer	business accounts and APIs from OpenAI, Anthropic, Google, Mistral, Cohere and others	the contractual model-service provider and its listed sub-processors	may be suitable after checking the contract, settings, retention, features and transfers
managed multi-model cloud platform	Microsoft Foundry, Amazon Bedrock and Google’s managed model services	principally the selected cloud provider; access by the model developer depends on the platform’s architecture and terms	may provide stronger organisational control, but requires assessment of the specific deployment
model with accessible weights hosted by a third party	Llama, Mistral, Qwen, DeepSeek, Gemma and other models run by an external host	the model host, its infrastructure and its further providers	accessible weights alone do not reduce contractual or transfer risk
model in the organisation’s own or strictly controlled environment	locally deployed models with accessible weights	the organisation, its administrators and any contracted host or maintainer	provides the greatest direct control, but also the greatest security and operational responsibility

Public Consumer Chat Service

A public chat service is designed for rapid, direct use. It may be free or paid, but the subscription price does not determine the provider’s legal role. A personal subscription is not automatically equivalent to a business service under which the provider processes data on the documented instructions of an organisation.

This does not make every question asked through such a service impermissible. Summarising a publicly available statute does not raise the same issues as uploading a client’s medical report. For a complete confidential file, however, a consumer account is generally the wrong starting point unless the organisation has examined the terms, purposes, retention, recipients and permitted categories of data in advance.

Direct Business Service from a Model Developer

A business service or API may offer a clearer contractual allocation of roles, instructions, sub-processors, security, retention and deletion. The OpenAI example described above falls within this category. But the word “business” is not the end of the inquiry. Different features within the same platform may create different objects, logs and retention periods. A one-off request that the application does not deliberately retain as conversation history is not the same as a stored thread, an uploaded file, a vector search collection or a connection to an external tool.

This route may therefore be appropriate for a necessary and properly minimised passage if the legal basis, professional duty, contract and settings are aligned. It is not a general licence to upload the whole matter.

Managed Cloud Platform

This is where the most important shift in perspective occurs. One company may have developed the model, while another processes the customer’s information by running that model in its own environment.

Microsoft’s documentation for models sold directly by Azure in Foundry, including OpenAI models, states that prompts, outputs, embeddings and training data are not available to OpenAI or the other model developers whose models are offered there. Microsoft hosts the models in its own environment. The same documentation cautions that deployment type, feature, stored state and abuse monitoring can affect processing location and retention.

Amazon Bedrock likewise provides access to models developed by different companies. But Bedrock is not one single data path. AWS documents several data-retention modes. With none, AWS says that it does not store model inputs or outputs after processing and does not share them with the model provider. With default, retention follows the model’s policy: AWS may retain content for abuse detection or policy enforcement, while the model provider does not receive it. With aws_review, authorised AWS personnel may review content for safety purposes, but the content remains within AWS and is not shared with the provider. The legacy setting named provider_data_share is therefore misleading today: AWS says that it currently follows the same AWS-only review behaviour rather than sending content to the model developer. For models that require review, retained data may be kept for up to 30 days. A Claude, Llama, Mistral or other model accessed through Bedrock does not therefore necessarily follow the same data path as the developer’s direct service. The model, account, region, feature and actual retention setting must still be checked.

Google’s documentation on managed models makes the same point from another angle. Google states that it does not use customer data to train or fine-tune models without the customer’s permission or instruction. Yet processing without retention depends on the selected settings and features: abuse monitoring, connections to certain search services, stored conversation state and request-response logging can create different retention outcomes.

A managed platform is therefore not automatically safer or more dangerous than a direct provider. Its advantages may include clearer organisational control, selectable processing regions, access management and an established contractual framework. Its limit is the same as elsewhere: the organisation must verify the exact service, model, feature, region, logs, external connections and human access.

Third-Party Host of a Model with Accessible Weights

The same model with accessible weights may be offered by numerous external hosts. In that case, the model developer may not receive the document, but the host does. The host’s terms determine whether the content is retained, what it is used for, where it is processed and who can access it.

The model licence governs use of the weights. It does not replace a DPA, supply a legal basis for the client’s document or guarantee that the host creates no logs. The label “open model” describes some aspect of access to the model; it does not describe the confidentiality of the selected service.

Model in the Organisation’s Own Environment

If an organisation downloads model weights and runs them on a server it genuinely controls, it removes one important external recipient. The user input does not travel to the model developer merely because the developer created the model. Subject to their licences, size and technical requirements, models from the Llama, Mistral, Qwen, DeepSeek and Gemma families are among those that may be deployed in this way.

Locality must still be demonstrated. If the server runs at an external host, if logs are sent to remote support or if the application uses external search, translation or monitoring, third parties re-enter the data path.

Suitability Is Not a Property of a Logo

No provider or model can be labelled “safe”, “unsafe” or “compliant” once and for all. A particular route is suitable or unsuitable for a particular confidential legal document and purpose.

A route is unsuitable by default where the organisation cannot demonstrate the recipient’s contractual role, the purposes of use, processing location, retention periods, sub-processors, deletion options or actual settings. Uncontrolled use of a personal chat account for a complete case file will generally fall into this category, particularly where the service itself warns that it is not designed for sensitive data.

An external business route may be conditionally suitable where the task is permitted, only the minimum necessary content is sent, the contract matches the actual processing, features and retention have been checked, transfers have an appropriate legal basis and the residual risk is acceptable. Some tasks will also require identifiers to be removed or replaced locally and a human to approve the disclosure.

Deployment in the organisation’s own environment may offer the greatest direct control. Even that route is not automatically suitable if the server is poorly secured, copies cannot be deleted, too many people have administrative access or the model’s reliability on the relevant Slovenian legal task has not been demonstrated.

The same document may therefore produce three different decisions. Public statutory text can be sent to an approved external service without the risks raised by client material. A well-pseudonymised contractual passage may be suitable for a verified business route. A complete file containing health or criminal-conviction data may require strictly local processing, manual work or a decision not to use a model at all.

DeepSeek as an Example, Not a Separate Category

DeepSeek illustrates the difference between the name of a model and the data path. It is not a separate category of the market.

For the direct services within the scope of DeepSeek’s Privacy Policy, the document updated on 10 February 2026 states that personal information is processed and stored in the People’s Republic of China, that inputs may be used to develop and improve the service, including training models, and that users should not submit sensitive information for which the service is not designed. That direct route is therefore not a suitable default choice for a complete confidential legal file. China does not appear on the European Commission’s list of countries whose data-protection framework it has formally found adequate for transfers, so a transfer of personal data would require another appropriate mechanism and proof that its conditions are met.

If a third-party host runs the same model, the contract, infrastructure and data path of that host must be assessed. If an organisation downloads the weights and runs them inside a closed environment under its control, the document does not travel to China merely because the model was developed there. The same rule applies to American, European and other models. Country of development matters for supply-chain, licensing and model-assurance questions, but it is not a substitute for evidence of where the actual processing occurs.

An In-House Server Removes a Recipient, Not Responsibility

Self-hosting can materially change the risk. An organisation can keep content within its environment, set retention periods, separate matters, control network connections and prevent user prompts from reaching an external model provider.

But a server on the organisation’s premises is not proof of security. Someone must maintain the operating system, drivers, libraries, the software that runs the model and the user interface. Someone must control administrative accounts, keys, logs, temporary files, caches and backups. Updates, error reports and extensions may create outbound connections. If the system runs at a cloud host, an external processor re-enters the data path.

The statement “the model runs locally” becomes meaningful only when the organisation knows where computation and storage occur; who has administrative access; which outbound connections are permitted; what the real network traffic shows; the origin and versions of the model and software; the settings for automatic transmission of technical usage data, often called telemetry; the route taken by logs and copies; and the deletion procedure. Mistral’s instructions for using its coding tool with offline models, for example, expressly point out that running a local model also requires disabling telemetry, automatic updates, external tools, connectors and other network paths.

Verification cannot stop on installation day. A new version of the software that runs the model may add error reporting, an extension may begin calling an external service, or an administrator may temporarily enable detailed logging to troubleshoot a fault. The source of the model file, its cryptographic file fingerprint — or hash — its licence and its compatibility with the execution environment also need to be checked.

Local does not necessarily mean easy. It means more direct control and more direct responsibility.

The Model Stays In-House — but Does It Understand Slovenian?

A confidential data path is not enough if the model misunderstands the legal question. Language performance is therefore a second axis of assessment, applicable to every model regardless of its country of origin.

Fluent Slovenian does not prove correct handling of legal concepts, time limits, exceptions, citations, negation or relationships across a long document. Nor does the label “legal model” prove anything without testing on relevant Slovenian tasks. The model must be assessed on the real work it is expected to do: does it preserve negation, connect people with their roles, distinguish a deadline from a date, find a distant exception and stop when its sources are insufficient?

The most capable external service may have a less desirable data path, while a model suitable for local deployment may perform less well — or simply remain unmeasured — in Slovenian. Translating a document into English may help the model while changing legal meaning or opening another data path to a translation service. Selection must therefore weigh confidentiality, verifiability and performance on the specific task at the same time.

This question needs comparative testing of its own and belongs in a planned separate article: The Model Runs Here. But Does It Understand Our Language?

From a Blanket Ban to the Right Route

An organisation does not need one answer for every document. It needs rules that select different routes for different categories of data and task.

Public statutory text can be handled differently from an unpublished medical file. An internal draft containing no personal or confidential facts can be treated differently from a contractual passage in which names can be replaced. Confidential content need not always be excluded entirely: sometimes the organisation can select the minimum necessary passage locally, pseudonymise it effectively, examine the residual risk and only then use an approved external route.

A useful organisational model has four outcomes:

Ordinary approved processing for public and non-sensitive data.
An approved business or local route for low-risk internal information.
External processing only after local minimisation and review for confidential content whose risk can be controlled.
Local processing only, a human decision or no model at all for high or uncontrolled risk.

This is not a statutory classification and does not replace an assessment of the particular case. Its value is organisational: it relieves the user of having to make the decision in the last second, when the document is already poised to leave the system.

OpenLegalCore: a Gateway That May Remain Closed

OpenLegalCore starts from the proposition that a legal result is not enough if the method, sources, transformations, limitations and review path cannot be inspected. In A Result Is Not a Method, we connected that requirement with a reproducible evidence path. Confidentiality adds another question: what should be allowed to cross the organisation’s boundary at all?

The status must be stated without fine print:

As at 22 September 2026, the OpenLegalCore local safeguarding gateway is a research and architectural concept. No software implementation for de-identification or pseudonymisation exists, so this is not a description of a completed or tested feature.

The concept is that, before any external processing, a document would first enter a local safeguarding gateway. This would not be a single “anonymise” button, but a sequence of verifiable decisions.

First, the gateway would identify the task’s purpose and the information’s sensitivity class. It would then inspect both the visible text and hidden document layers: properties, comments, tracked changes, headers, images, signatures and optically recognised text. A language-based detector would propose direct and indirect identifiers, legal roles, relationships and rare combinations of facts. References to the same person or entity would be replaced consistently with labels such as CLIENT_A, EMPLOYER_B and COURT_1.

The mapping between those labels and the real information would remain encrypted and separate inside the local environment. The external model would not receive it. A further step would assess residual identifiability and the risk of linking the text to public sources. Only then would deterministic software rules select a route:

local processing only;
external processing of the minimum pseudonymised passage;
mandatory human approval;
blocking the request before model processing.

The distinction between a language-based detector and predefined software rules is crucial. A model may be useful for proposing names, roles, relationships and ambiguous passages. It should not be allowed to reinterpret an organisational prohibition from one request to the next. A deterministic rule must check whether mandatory fields are complete, whether the provider is approved for the relevant data class, whether the mapping remains local, whether approved retention settings are in use and whether the request must be blocked when evidence is missing. Simple pattern matching may provide an additional screen for telephone numbers or particular identifiers, but it cannot by itself understand Slovenian legal text or declare a document anonymous.

If a result returned from an external model, permitted identifiers would be reinserted only inside the local environment. Before using the result, a human would see the changes, residual risks, selected provider, retention mode and reason for the routing decision.

The system would also preserve an evidence record, but without creating another copy of the confidential document. The record could contain the policy version, purpose, data class, route, versions of the detector and rules, outcome of human review and deletion status. It should not contain the original text, real names, the local mapping or even a cryptographic hash of a private document where that hash could be used to test whether the document was present in the system.

This distinction matters for an open project as well. Openness of method does not require openness of data. On the contrary, a publicly described procedure allows specialists to examine the logic of decisions without seeing client documents. An organisation can demonstrate internally which policy version authorised a route without storing the very content it is trying to protect inside the evidence system.

The threat model, decision schema, synthetic test cases, measurement method and, perhaps later, code could be public. Client documents, mapping tables, operational logs, incident material, credentials and sensitive network details should remain private.

The most important property of such a gateway would not be that it always finds a route to a model. It would be that it knows when to stop.

For now, this is a research plan. Before it could be called a product, testing on Slovenian legal documents would need to measure at least missed direct identifiers, indirect identifiers, rare fact combinations, consistency of replacement labels, loss of legal meaning, hidden document layers, the possibility of re-identification and the quality of human review. It would require synthetic or otherwise lawfully prepared test sets, versioned rules and predefined thresholds for blocking a request. Without such evidence, the word “anonymiser” would be a promise, not a result.

What OpenLegalCore can credibly offer today is something different: a publicly verifiable plan for what a future system must prove before it is trusted with a confidential file. Until code and measurements exist, it remains a research concept — and that limitation is itself part of the method.

Twelve Questions Before Clicking “Send”

Before a legal document enters either external or local model processing, someone should be able to answer:

Does it contain personal data, health or criminal-conviction data, material protected by professional duties of confidentiality, or a trade secret?
What is the smallest part of the document the model genuinely needs for this task?
Can unnecessary identifying information be removed or replaced locally?
Does the remaining combination of facts still reveal the person, client or matter?
Which application, retrieval store, model service and infrastructure will actually process the content?
Who acts as controller, processor and sub-processor?
Do the legal basis, professional duty and contract cover this exact use?
Where are logs, caches, embeddings and backups created?
Are the data used to answer the request, provide security and support, measure performance, improve a service or train a model?
How long does each copy remain, and how is its deletion proved?
Do the data or remote access cross the European Economic Area, and on what legal basis?
Must the system block the processing because one of these answers cannot be demonstrated?

The purpose of this list is not to make every user read a contract and inspect network traffic before every prompt. The organisation must do that work in advance: approve services and settings, define data classes, build technical boundaries and show users clearly what is allowed.

Limits of This Analysis

This article does not provide a legal opinion on a particular law firm, service or transfer. It does not rank providers from safe to unsafe and does not claim that every external use is impermissible. Contract terms, technical features and sub-processor lists change. Provider examples are therefore tied to documents checked on 22 September 2026.

Different areas of law, professions, categories of data and purposes may require different decisions. Professional secrecy and evidential privilege also vary between jurisdictions; the Slovenian rules discussed here must not be assumed to define their scope elsewhere. A sound data path does not guarantee a correct legal answer. A model can still select the wrong source, miss an exception or express a mistaken conclusion fluently. Confidentiality is a necessary condition of a responsible system, not evidence of its legal quality.

Back to the Button

Return to the lawyer.

This time, the document does not vanish immediately behind the word “send”. Before it leaves her environment, the system shows which passages were selected, which identifiers were replaced, which rare facts remain, who would receive the extract, where it would be processed, what retention applies and which rule authorises the route.

The gateway may open towards an approved business service. The task may be redirected to a local model. A human may have to approve the decision. The gateway may remain closed.

That last possibility is evidence of control, not failure.

Confidentiality does not end at the chat window. That is where the question begins — a question every serious legal AI system should be able to answer:

What left, to whom, for what purpose, for how long — and what evidence tells us so?

Selected Sources

Legal, technical, provider and project sources last checked: 22 September 2026.