Страховой бизнес обрабатывает поток обращений, где почти каждое сообщение содержит персональные данные: ФИО страхователя, номер и серию полиса, данные документов, адрес, реквизиты выплаты. Соблазн отдать этот поток языковой модели для первичной классификации и подготовки ответа очевиден, но прямой риск — передача персональных данных (ПДн) во внешнюю LLM. Ниже — открытый разбор того, что можно построить на этом классе инструментов (LLM & Security Gateway), чтобы получить автоматизацию без передачи ПДн в модель. Это обзор технологии, а не описание проекта KT.Team.
Какой бизнес-результат получает страховая
Главный измеримый результат — сокращение времени первичной обработки заявления и переписки при нулевой передаче исходных ПДн во внешнюю модель. Шлюз берёт на себя три рутинные операции на входе в урегулирование убытков: классификацию обращения (вид страхования, тип события, срочность), извлечение структуры (что произошло, какие документы приложены, чего хочет клиент) и подготовку черновика ответа оператору. Оператор перестаёт читать каждое письмо «с нуля» и работает с уже размеченным и обезличенным резюме. При этом наружу уходит не «Иванов Иван, полис ОСАГО ХХХ 0000000», а `<PERSON>`, `<POLICY_NUMBER>` — и регуляторный риск утечки на стороне провайдера модели снимается на архитектурном уровне.
Почему обезличивание делают на шлюзе, а не в приложении
Ключевая развилка — где именно резать ПДн. Если делать это внутри каждого сервиса-потребителя LLM, правило придётся дублировать в десятках мест, и одна забытая интеграция = утечка. Поэтому обезличивание выносят в единую точку — LLM-шлюз, через который проходит весь трафик к моделям. Это соответствует подходу «минимальная модификация ядра, бизнес-логика рядом»: сам инструмент LLM не дорабатывается, политика приватности живёт отдельным слоем перед ним. Открытый стек для этого собирается из двух зрелых международных компонентов:
- LiteLLM — open-source прокси/шлюз к LLM, который перехватывает запрос до отправки в модель и применяет guardrails.
- Microsoft Presidio — open-source фреймворк для обнаружения, маскирования и анонимизации ПДн в тексте (имена, телефоны, e-mail, номера карт, локации и кастомные сущности).
Связка документирована официально: LiteLLM подключает Presidio как guardrail и маскирует ПДн до вызова модели (docs.litellm.ai, microsoft/presidio). Это и есть принцип «read before you write»: вместо самописного детектора регулярками берётся проверенный международный инструмент.
Как это работает на потоке заявлений
В конфигурации шлюза описывается guardrail с режимом `pre_call` — обезличивание входа до запроса в модель:
```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"
```
Текст «Мой e-mail test@example.com» уходит в модель как «Мой e-mail `<EMAIL_ADDRESS>`» — провайдер исходного значения не видит (docs.litellm.ai). Для страховых сущностей, которых нет «из коробки» — номер полиса, ИНН, СНИЛС, VIN, номер водительского удостоверения — добавляются ad hoc recognizers (свои паттерны), это штатная возможность Presidio.
Действия настраиваются по типу сущности: `MASK` заменяет на плейсхолдер, `BLOCK` целиком отклоняет запрос с критичной сущностью (например, если в текст попали платёжные реквизиты, которые в LLM не нужны вовсе). Режим `output_parse_pii` умеет восстановить исходные значения в ответе на стороне шлюза — оператор видит нормальный черновик, а наружу значения так и не уходили. Отдельный режим `logging_only` маскирует ПДн в логах (Langfuse и др.), чтобы данные не утекали даже через наблюдаемость.
Важно с точки зрения комплаенса: маскирование/псевдонимизация на шлюзе снижает риск, но псевдонимизированные данные по GDPR остаются персональными, пока существует «дополнительная информация» для обратной привязки (EDPB guidelines on pseudonymisation, nordlayer). Практический вывод: таблица соответствия «плейсхолдер → исходное значение» должна храниться отдельно и не покидать контур страховой. То же логика применима и к требованиям 152-ФЗ.
Отчуждаемость и слабая связанность
Поскольку и LiteLLM, и Presidio — open-source и общаются по HTTP, слой приватности отчуждаем: его можно передать другой команде или подрядчику без переписывания, сменить модель-провайдера за шлюзом без изменения политики обезличивания, развернуть Presidio в собственном контуре. Сама модель — взаимозаменяемый компонент за единым контролируемым периметром.
Схема процесса
Заявление/письмо → LLM-шлюз (LiteLLM): detection ПДн (Presidio) → MASK/BLOCK → обезличенный текст уходит в LLM → классификация + извлечение + черновик ответа → (опц.) восстановление плейсхолдеров на шлюзе → оператор урегулирования. Параллельно: таблица соответствия плейсхолдеров и логи с маскированием остаются внутри контура страховой.
Вывод для бизнес-процесса
Узкое место урегулирования убытков — ручной первичный разбор каждого обращения — закрывается шлюзом, который обезличивает ПДн до модели и возвращает оператору готовое размеченное резюме с черновиком ответа. Бизнес-результат: быстрее первичная обработка и ниже регуляторный риск, потому что имя страхователя и номер полиса физически не покидают контур. Стек собирается из зрелых open-source компонентов, дорабатывается тонким слоем кастомных распознавателей под страховые сущности и остаётся полностью отчуждаемым.
