Why a gateway belongs in front of the model

A company wants a model to triage requests, draft responses, or extract facts from contracts. Source text will almost inevitably contain names, phone numbers, addresses, payment details, and internal identifiers. Sending the entire document to a model merely because it runs in a corporate account is a poor architectural default.

A better design places a data-minimisation gateway before the LLM. It receives a document, detects the sensitive entity types relevant to the process, replaces them with stable placeholders, and only then sends text to the model. If an employee needs a personalised result, a controlled service restores only the permitted values.

The gateway is useful with a local model too. Local inference answers where text is processed, not who can access it, what enters logs, or which data was unnecessary. Segmentation limits the impact of a model error, a leaked trace, or an incorrect route.

Do not overclaim: personal-data detection is probabilistic, and de-identified data can sometimes be linked back to a person through remaining context. This is a risk-reduction layer, not an automatic guarantee of anonymity.

Four independent planes

A practical design has four services with explicit boundaries.

**1. Intake and classification.** The document receives a task ID, process class, and policy. The gateway knows which entity types matter in a support request, contract, or CV. The original stays under the source system's retention rules, not in chat history.

**2. Detection and transformation.** The detector combines regular expressions, checksums, dictionaries, contextual rules, and an NER model. A separate module applies redact, mask, replace, hash, or encrypt operations.

**3. LLM processing.** The model sees placeholders such as `[PERSON_01]`, `[PHONE_01]`, and `[CONTRACT_02]`. It receives only the tools required for the business task. The replacement map never enters model context.

**4. Controlled restoration.** If a personalised draft is required, a separate service validates the user's role, result purpose, and allowed fields. Only then are selected placeholders restored. Analytics often requires no restoration at all.

The separation must be real: the model should not have the original text, replacement map, and decryption key at the same time.

What Presidio provides—and what it does not

Microsoft Presidio is an open set of components for detecting and de-identifying PII in text, images, and structured data. In a text workflow, Analyzer identifies entity spans and Anonymizer applies selected operators.

Official documentation describes multiple detection mechanisms: regular expressions, deny lists, checksums, rules, NER, and surrounding context. This is a useful gateway foundation because card numbers, phones, names, and internal codes need different methods.

The built-in entity catalog is not a ready-made profile for every country or company. A Russian business will need custom recognizers for local document formats, contract numbers, employee IDs, customer codes, and industry terms, plus a suitable Russian-language model. Default configuration must be tested on the company's own data.

Presidio also does not decide what the organisation may send to a model, who may restore values, or how long a mapping is retained. Those are policy and application-architecture decisions.

Choose an operator by purpose

Transformations may look similar while creating different utility and risk.

**Redaction** is appropriate when the entity is irrelevant to the model. It minimises data but can damage grammar and context.

**Masking** preserves part of the format, such as final digits. That can help an employee but may retain enough signal to link records.

**Placeholder replacement** preserves structure: one customer becomes `[CLIENT_01]` throughout the document. This is often sufficient for summarisation and classification.

**Hashing** supports grouping, but predictable values can be enumerated. Salt requires separate management. Presidio documentation notes that random salt provides stronger default protection while identical values no longer produce the same hash across calls. A persistent salt restores linkability and increases re-identification risk.

**Encryption** enables restoration, but the key and mapping become sensitive assets. Access to them should be narrower than access to model output.

For a support assistant, task-local placeholder replacement is often the right default. Aggregated analytics can use irreversible removal or independent placeholders. Persistent pseudonyms across months need an explicit business reason.

Where the placeholder map lives

Keep the mapping in a separate protected store with a short lifetime. Use the task ID as its key, not the customer's name. The model, vector database, and general logs have no access to it.

Minimum controls include:

  • encryption in transit and at rest;
  • a dedicated service identity for restoration;
  • a lifetime tied to the workflow;
  • no bulk reading of mappings;
  • logging the restoration event without logging values;
  • deletion after approval when reopening is unnecessary.

If a task ends with classification or statistics, do not create a mapping. Reversibility expands the risk surface and needs a named owner.

Never embed original content in the marker. `[IVANOV_01]` does not hide a surname. A marker should expose only type and a task-local sequence number.

RAG must be treated before indexing

A common mistake is to clean only the user's query while original documents remain in the vector database. The model then receives personal information through retrieved chunks although the interface appears protected.

A RAG route should:

  • classify the document and authorise indexing;
  • extract text from files and images;
  • detect sensitive entities;
  • choose what to remove, replace, or retain under policy;
  • index the sanitised copy;
  • keep the original reference in a controlled source system;
  • filter retrieval by user permissions before passing chunks to the model.

De-identification does not replace access trimming. A document can contain trade secrets without a single phone number or name. The gateway minimises defined entities; authorisation determines which documents a user may see at all.

How to measure detector quality

Average accuracy on somebody else's dataset says little about your workflow. Collect 200–500 safely handled examples from the real stream and manually label entity types. Include typos, abbreviations, inflections, mixed Cyrillic and Latin text, compact numbers, signatures, tables, and OCR errors.

Measure separately:

  • recall: the share of sensitive spans detected;
  • precision: the share of detections that are truly sensitive;
  • the share of documents with at least one dangerous miss;
  • utility loss: whether the model can still complete the task;
  • processing time and manual-review volume.

A false negative is more dangerous for privacy, but simply lowering the threshold creates false positives and destroys useful text. Combine methods: exact formats use regex and checksums, names use language models and context, and internal codes use dictionaries or custom recognizers.

Run every policy or model version against a fixed golden set. Include negative examples such as product codes, amounts, company names, and technical numbers that must not be removed without reason.

Handling uncertain documents

The gateway must be able to refuse, not only forward. If a document is high risk, OCR quality is poor, or the detector encounters an unknown format, route the task to manual review or to a stricter local environment.

Two thresholds are practical. Above the high threshold, replace automatically. Between high and low, flag for review. Below the low threshold, do not classify the span as an entity, while format anomalies may still stop the route.

Scan the model output again. It might reproduce information returned by a tool, generate plausible account details, or include data that was permitted at input but prohibited in an external response.

Economics of a small gateway

A pilot does not necessarily require a GPU. Regular expressions and checksums run on CPU, and a compact NER model often fits an ordinary server. The main costs are usually example annotation, custom-entity configuration, integration, and exception handling.

Calculate cost per processed and accepted document:

  • gateway and model infrastructure;
  • human review of borderline cases;
  • correction of false replacements;
  • rule maintenance as formats change;
  • incident and reprocessing costs.

Automation is useful when manual review falls without dangerous misses rising. If every second document requires restoration of dozens of entities, the chosen scope may be too broad. Start with one document class and one output.

A three-step pilot

**Step 1 — data map.** Select a process and list sources, entity types, recipients, and permitted result purpose. With security and data owners, decide what to remove, pseudonymise, or prohibit from model processing.

**Step 2 — shadow mode.** The gateway analyses copies but sends nothing to the production LLM. Measure misses, false positives, and loss of meaning. Freeze configuration as a versioned policy.

**Step 3 — limited route.** Enable one reversible scenario, such as drafting a reply. External sending stays with a person. Log detector and policy versions, never source values or keys.

Pilot success is not “PII was found in the demo.” It is a stable share of documents without dangerous misses, acceptable review time, and a clear refusal path.

Management takeaway

Do not connect a model directly to a document stream. Put an independent gateway in front of it, minimise data according to the specific process, and keep the restoration map outside LLM context.

The first practical step is to label sensitive entities in 200 real examples and measure not only average accuracy but the share of documents with at least one miss. That quickly shows where automation is already useful and where a person is still required.