Large language models (LLMs; AI) accessed via cloud APIs have become standard instruments for text summarisation, classification, and qualitative analysis, and lots of other operations. Their use, however, conflicts with data protection obligations whenever input texts contain personal data. This article outlines an architectural pattern that resolves this tension: locally executed, model-based text anonymisation as a preprocessing layer — a privacy proxy — placed in front of any cloud-based LLM. We discuss the limitations of rule-based de-identification, summarise the empirical evidence for context-sensitive approaches, and derive practical selection criteria for anonymisation tooling in research, healthcare, and enterprise settings.
1. The problem: capable models, prohibitive data flows
Organisations face a structural conflict. On one side, cloud-hosted LLMs (GPT-4-class models, Claude, Gemini) offer analytical functions that are hard to reproduce on-premise at comparable quality. On the other, the GDPR — in particular the principles of data minimisation and purpose limitation (Art. 5) and privacy by design and by default (Art. 25) — as well as sector-specific regimes such as HIPAA, restrict the transmission of personal data to third-party processors. In practice, this frequently results in one of two suboptimal equilibria: blanket prohibitions on LLM use, or informal non-compliance in which sensitive texts are pasted into chat interfaces regardless of policy.
A third option receives comparatively little attention: decoupling the de-identification step from the analysis step, and executing the former exclusively using local infrastructure.
2. The privacy-proxy architecture
The pattern is clear. Before any content leaves the organisational boundary, a locally running anonymisation model detects and replaces personal identifiers with consistent placeholders:
Input: “Lisa Dina joined Apple in May 2019. Colleagues describe Lisa D. as very focused, and L. Dina now leads the office in Munich.”
Output: “PERSON_1 joined ORG_1 in DATE_1. Colleagues describe PERSON_1 as very focused, and PERSON_1 now leads the office in LOCATION_1.”
Only the transformed text’s subsequently transmitted to a cloud LLM for downstream tasks such as summarisation or thematic coding. Two properties are critical:
- Local execution of the anonymisation itself. Delegating de-identification to a cloud LLM (“please anonymise the following”) is self-defeating: the personal data have already been disclosed at the moment of the request. The anonymisation model must run on hardware under the controller’s authority — ideally offline-capable and deployable in air-gapped environments.
- Referential consistency. Co-referring surface forms (“Lisa Dina”, “Lisa D.”, “L. Dina”) must map to the same placeholder. Without consistent entity resolution, the anonymised text loses analytical utility, since relational structure (who did what) is destroyed. Where re-linkage is required, a locally stored codebook mapping placeholders to originals preserves reversibility under the controller’s exclusive access; tools such as Textwash™ Pro generate this codebook as a standard output artefact.
Three deployment configurations follow from this pattern: (i) fully local end-to-end processing, the default in research and clinical contexts in which ethics boards mandate local handling; (ii) the proxy configuration proper, in which cloud LLMs receive only anonymised text; and (iii) automated pipelines, in which anonymisation runs as an API stage within existing systems (e.g., before centralised log storage or within n8n/Make/Zapier workflows), with on-premise or self-hosted deployment preserving data sovereignty.
3. Why rule-based de-identification is insufficient
Regular expressions and gazetteer lookups perform acceptably on structured identifiers (email addresses, phone numbers) but degrade sharply on unstructured text. Three failure modes dominate:
- Surface variation. Names appear as full forms, initials, abbreviations, and misspellings; static lists cannot enumerate these variants.
- Descriptive identifiers. Locations and persons are frequently referenced descriptively (“the village where I grew up, right on Lake Constance”) rather than nominally. No keyword list captures such references.
- Quasi-identifiers and mosaic effects. Combinations of occupation, age, cultural identity, and temporal detail can be re-identifying even when no single “classic” identifier is present — the well-documented basis of linkage attacks in the disclosure-control literature.
Context-sensitive approaches deal with these failure modes by classifying tokens based on their linguistic environment rather than list membership. The open-source Textwash™ project (Kleinberg, Davies, & Mozes, 2022) illustrates this class of systems: a transformer-driven model trained to detect a configurable taxonomy of entity types (persons, locations, organisations, dates, occupations, ages, cultural identity, and other identifiable attributes), developed in an academic research context and released under GPL-3.0.
4. Empirical evidence
A recurring weakness in the anonymisation tool market is the absence of published error measurement. Anonymisation without a quantified false-negative rate is risk management by assumption. The evidence base for context-sensitive anonymisation, by contrast, includes several relevant strands:
For procurement and governance purposes, this distinction matters: peer-reviewed evaluations provide citable evidence for data protection impact assessments (DPIAs), whereas vendor self-attestations do not.
5. Legal characterisation
The proxy architecture operationalises data minimisation directly rather than compensating for its absence contractually. Three consequences are noteworthy:
- Processor scope. If personal data are never transmitted, the cloud LLM provider does not act as a processor for that data category, simplifying Art. 28 GDPR obligations and eliminating third-country transfer questions (Chapter V) for the analysis step.
- Anonymisation vs. pseudonymisation. Fully anonymised data fall outside the material scope of the GDPR (Recital 26), unlike pseudonymised data. Where a codebook is retained, the output is pseudonymised from the perspective of the codebook holder but anonymous from the perspective of the cloud provider — a distinction with direct consequences for data sharing and open-science archiving.
- HIPAA alignment. The Safe Harbor method (§164.514(b)(2)) enumerates identifier categories — names, dates, contact details, geographic subdivisions — that map naturally onto the configurable entity-type taxonomies of modern anonymisation tools.
6. Selection criteria
Two questions separate defensible tooling from marketing claims:
Is there an observational evaluation? Providers should be able to point to published benchmarks or studies quantifying detection performance — including failure cases. Absent this, risk claims should be treated with caution.
Why would the data need to leave the local system at all? A “privacy tool” that itself requires cloud processing of raw text merely relocates the disclosure. Fully local, offline-capable execution remains the reference standard for sensitive corpora. Implementations of the local-first principle exist across form factors — for instance, Textwash™ Pro packages the research-grade model as a desktop application (macOS, Windows, Linux) requiring no internet connection, with API and self-hosted cloud variants for pipeline integration — but the criterion is architectural, not brand-specific: the anonymisation step must be auditable and must execute within the controller’s boundary.
Secondary criteria include multilingual coverage (relevant for European deployments), configurable entity taxonomies (to balance legal requirements against information usefulness), throughput at corpus scale, and audit-ready reporting (codebooks, statistics, repeatable validation evidence).
The apparent trade-off between LLM-enabled productivity and data protection is an artefact of architecture, not an inherent conflict. A locally executed, context-sensitive anonymisation layer allows organisations to route the computationally demanding analysis to cloud models as guaranteeing that identifiable data never cross the organisational boundary. The approach adopts privacy by design in the literal sense — as the first stage of the text-processing pipeline rather than a retrospective control — and, where tooling with a peer-reviewed evidence base is chosen, yields documentation that stands up in DPIAs, ethics applications, and audits.
