Insurance businesses process a stream of requests in which almost every message contains personal data: the policyholder's full name, policy number and series, document data, address, and payout details. The temptation to hand this stream to a language model for first-pass classification and reply drafting is obvious, but the direct risk is sending personal data to an external LLM. Below is an open review of what can be built with this class of tools (LLM & Security Gateway) to achieve automation without sending personal data to the model. This is a technology overview, not a description of a KT.Team project.
What business result the insurer gets
The main measurable result is shorter first-pass processing time for claims and correspondence with zero transfer of source personal data to an external model. The gateway handles three routine tasks at the start of loss adjustment: classifying the request (insurance type, event type, urgency), extracting structure (what happened, which documents are attached, what the customer wants), and preparing a draft reply for the operator. The operator no longer reads every message from scratch and works with an already annotated and anonymized summary. What goes out is not "Ivanov Ivan, OSAGO policy AAA 0000000", but `<PERSON>`, `<POLICY_NUMBER>` - and the regulatory risk of leakage on the model provider's side is eliminated at the architectural level.
Why anonymization is done at the gateway, not in the application
The key decision is where exactly to strip personal data. If this is done inside each LLM-consuming service, the rule has to be duplicated in dozens of places, and one missed integration equals a leak. That is why anonymization is moved to a single point, the LLM gateway through which all traffic to the models passes. This matches the "minimal changes to the core, business logic alongside" approach: the LLM tool itself is not modified, and the privacy policy lives as a separate layer in front of it. An open stack for this is assembled from two mature international components:
- LiteLLM — an open-source proxy/gateway to an LLM that intercepts requests before they are sent to the model and applies guardrails.
- Microsoft Presidio — an open-source framework for detecting, masking, and anonymizing personal data in text (names, phone numbers, email addresses, card numbers, locations, and custom entities).
The integration is officially documented: LiteLLM connects Presidio as a guardrail and masks personal data before the model is called (docs.litellm.ai, microsoft/presidio). This is the "read before you write" principle: instead of a homegrown regex-based detector, a proven international tool is used.
How it works in a claims stream
The gateway configuration defines a `pre_call` guardrail mode, which anonymizes input before the model request:
```yaml
guardrails:
- guardrail_name: "presidio-mask-guard"
litellm_params:
guardrail: presidio
mode: "pre_call"
pii_entities_config:
PERSON: "MASK"
EMAIL_ADDRESS: "MASK"
PHONE_NUMBER: "MASK"
CREDIT_CARD: "MASK"
```
The text "My e-mail test@example.com" goes to the model as "My e-mail `<EMAIL_ADDRESS>`" - the provider never sees the original value (docs.litellm.ai). For insurance entities that are not available out of the box, such as policy number, tax ID, social insurance number, VIN, and driver's license number, ad hoc recognizers are added (custom patterns); this is a standard Presidio capability.
Actions are configured by entity type: `MASK` replaces values with a placeholder, while `BLOCK` rejects the request outright if it contains a critical entity (for example, payment details that are not needed in the LLM at all). The `output_parse_pii` mode can restore the original values in the response on the gateway side, so the operator sees a normal draft while the values never leave the perimeter. A separate `logging_only` mode masks personal data in logs (Langfuse and others) so data does not leak even through observability.
Important from a compliance standpoint: masking/pseudonymization at the gateway reduces risk, but under GDPR pseudonymized data remains personal data as long as there is "additional information" that enables re-identification (EDPB guidelines on pseudonymisation, nordlayer). Practical takeaway: the mapping table of "placeholder -> original value" must be stored separately and must not leave the insurer's perimeter. The same logic also applies to requirements under Federal Law GDPR.
Transferability and loose coupling
Because both LiteLLM and Presidio are open-source and communicate over HTTP, the privacy layer is separable: it can be handed off to another team or contractor without rewriting, the model provider behind the gateway can be changed without altering the anonymization policy, and Presidio can be deployed within your own perimeter. The model itself is an interchangeable component behind a single controlled boundary.
Process flow
Claim/letter -> LLM gateway (LiteLLM): personal-data detection (Presidio) -> MASK/BLOCK -> anonymized text is sent to the LLM -> classification + extraction + draft reply -> (optional) placeholder restoration on the gateway -> claims adjuster. In parallel: the placeholder mapping table and masked logs remain inside the insurer's perimeter.
Business process takeaway
The bottleneck in loss adjustment - manual first-pass review of each request - is handled by a gateway that anonymizes personal data before the model and returns the operator a ready annotated summary with a draft reply. The business result is faster initial processing and lower regulatory risk, because the policyholder's name and policy number physically do not leave the perimeter. The stack is assembled from mature open-source components, extended with a thin layer of custom recognizers for insurance entities, and remains fully separable.
