Law firms, legal departments, insurers, and debt collection service providers process highly sensitive, case-related data with DEPLAW — names and addresses of clients and opposing parties, contract content, litigation strategy, financial circumstances, and, not infrequently, special categories of personal data under Art. 9 GDPR (e.g. health data or information on criminal convictions). As a professional bound by confidentiality, you are subject to attorney-client privilege (Section 43a BRAO) and the criminally sanctioned protection of private secrets (Section 203 StGB). This page explains how DEPLAW’s architecture technically supports you in reliably meeting these obligations when using language models (LLMs).

The core problem with cloud-based LLM services

As soon as content is transmitted to an external, cloud-operated service, it leaves the controlled environment and is processed on infrastructure you don’t control. This raises several critical risks:

Loss of control over the dataThere is no reliable way to verify or guarantee where, for how long, and for what purpose the data is retained there.
Data processing agreements & third-country transfersUsing an external provider regularly constitutes data processing on your behalf (Art. 28 GDPR); if the infrastructure is located outside the EU/EEA, the third-country transfer issue is added on top (Schrems II, US CLOUD Act).
Training on input dataWith many commercial services, it isn't cleanly ruled out whether inputs are used for further model training — an unacceptable residual risk for case-related data.
Incompatibility with professional obligationsDisclosing client secrets to an insufficiently bound third party can conflict with confidentiality obligations — regardless of whether data actually leaks out in the individual case.

Guiding principle: local and on-premise LLMs

DEPLAW therefore favors locally run language models — operated on-premise or in a dedicated, controlled environment. The models run within this environment; the data being processed never leaves it.

Reason Meaning
Data sovereignty and control Inputs, intermediate results, and outputs remain entirely within the controller’s power of disposal — the entire risk category around data processing agreements, third-country transfers, and opaque reuse falls away.
Demonstrable compliance Because the entire processing chain is operated in-house, the technical and organizational measures required under Art. 32 GDPR can be documented in a robust way.
Compatibility with confidentiality obligations Since no data is transmitted to third parties, no “disclosure” within the meaning of Section 203 StGB takes place.
No use for training Locally run models are not further trained on client data; inputs serve only to process the respective request.
Availability and independence Operation is independent of the availability, pricing changes, and terms of use of external services.

AI Connectors describes how to technically connect a local or self-hosted model — the connector’s URL simply points to your own endpoint instead of a cloud provider.

The pseudonymization service

In addition to connecting local models, DEPLAW provides a pseudonymization service. It uses the master data stored in the case file — names, addresses, and other identifying details of the parties involved — and replaces their occurrences in a document with pseudonyms or placeholders before it’s sent to an external model.

EINGABEDOKUMENT Max Mustermann Musterstr. 1, Köln Dritter: Dr. A. Weber Pseudonymisierungs- service Ersetzt bekannte Akten-Stammdaten PSEUDONYMISIERT [PERSON_1] [ORT_1] Dr. A. Weber (Klartext – nicht in Stammdaten)

Not to be used alone for sensitive documents

Limitation Meaning
Limited coverage Only information known as master data is captured. People or details that appear in the document but aren’t stored in the case file remain in plain text — like “Dr. A. Weber” in the example above.
Remaining sensitive content Special categories under Art. 9 GDPR and contextual information often still allow a person to be identified even after names have been replaced.
Residual risk of re-identification Combining the data with further information can lead to re-identification; for especially sensitive content, this carries greater weight.

Best practice: workflows with multiple LLM models (multi-LLM operation)

Some cases are so complex and fact-intensive that the highest possible model quality is desired — a quality that, in individual cases, only particularly powerful external models can achieve. This creates a conflict between processing quality and confidentiality. DEPLAW resolves it through multi-LLM operation with a local sanitize roundtrip: a local model prepares the data in a data-minimizing way, an external model processes only the pseudonymized version, and re-identification happens again entirely locally.

Technically, the AI processing here is just a normal step in the BPMN workflow — a service task with a defined input and output and full logging. The external models used are vendor-independent and interchangeable (including OpenAI, Anthropic, Google), without changing anything about the protection mechanism.

KONTROLLIERTE UMGEBUNG – ON-PREMISE Akte / Workflow Klartext bleibt lokal Lokales LLM Sanitize der Eingabe schreibt Mapping State-Map Klartext ↔ Pseudonym Rückschlüsselung De-Pseudonymisierung verlässt die Umgebung nie VERTRAUENSGRENZE nur pseudonymisierter Prompt pseudonymisierte Antwort Externes LLM Leistungsstarkes Modell für komplexe, sachverhalts- intensive Analysen
Only pseudonymized content crosses the trust boundary. Plain text, master data, and the mapping table (state map) remain within the controlled environment at all times.

The process

  1. Local sanitizing

    A local LLM pseudonymizes the input within the controlled environment and removes or replaces identifying features.

  2. Save state

    The mapping between plain text and pseudonym is saved as state in the case file or workflow. This mapping table never leaves the controlled environment.

  3. External processing

    Only the pseudonymized prompt is sent to the external model. Only pseudonymized content crosses the trust boundary — no plain text, no master data.

  4. Receiving the response

    The external model's likewise pseudonymized response is brought back into the controlled environment.

  5. Local re-identification

    Using the saved states, the response is de-pseudonymized and the re-identified result is stored in the case file.

State handling in the case file and workflow

The mapping is encrypted and persisted per case or matter and is tied to the respective workflow step. This keeps multi-step processing consistent, pseudonyms stable across multiple requests, and results deterministically re-identifiable. The states are subject to the same protective measures as the rest of the case file (encryption, least privilege, deletion policy) and are resolved exclusively locally.

Comparing the operating modes

Mode A – purely local Mode B – multi-LLM roundtrip
Data leaves the environment No — fully local Only pseudonymized; the mapping stays local
Model quality Limited by the local model External top-tier models usable
Residual risk Minimal Depends on pseudonymization quality
Recommended for Highest protection needs, Art. 9 data Complex, well-pseudonymizable cases

Use cases

Traffic lawExtensive accident accounts, expert reports, and chains of correspondence with many parties and cross-references.
Criminal lawDocument-intensive proceedings with complex facts — handled with particular care due to the special categories involved (Art. 9 GDPR).
Data protection lawComplex fact-pattern analyses, data subject requests, and incident assessments with a high volume of documents.

How to set it up in DEPLAW

The protection mechanism isn’t a separate component, but built directly into the AI service tasks themselves: fields like _enablePseudonymization (default: enabled) on tasks such as PromptToLLM or LlmExtractionTemplateRun control whether the input is pseudonymized before being passed on. For multi-LLM operation, additionally set up a local AI connector that you use for sanitizing, plus a second connector for the external top-tier model — you decide per service task which connector applies to which workflow step.

Summary

  • Local/on-premise models are the most privacy-friendly operating mode and the decisive one for sensitive case data.
  • The pseudonymization service is a supplementary layer of protection — not anonymization and not standalone protection for highly sensitive documents.
  • Multi-LLM operation with a local sanitize roundtrip unlocks external top-tier models for complex cases, without plain text or the mapping table ever leaving the controlled environment.
  • The higher a document’s protection requirements, the more the rule applies: purely local instead of roundtrip.