Банки хотят подключить LLM к первой линии поддержки и предобработке заявок, но 26-я статья закона «О банках» и 152-ФЗ запрещают передавать банковскую тайну и персональные данные в сторонние модели. Облачная LLM — это «недоверенный сторонний обработчик»: всё, что в неё уходит, нужно очищать на входе и аккуратно восстанавливать на выходе (Ploomber, разбор Presidio).
LLM & Security Gateway решает это на уровне прокси: он стоит между приложением банка и моделью, находит в тексте ФИО, номера счетов и карт, заменяет их на стабильные плейсхолдеры до отправки и подставляет реальные значения обратно в ответ. Ниже — открытый разбор того, что можно собрать на этом классе инструментов. Это не кейс KT.Team, а обзор на публичных компонентах со ссылками.
Какой бизнес-результат получает банк
Оператор первой линии или скоринг-конвейер получает ответ модели по реальному обращению, при этом номер карты и ФИО клиента физически не покидают периметр банка. Результат измеримый: сокращается время обработки типового обращения, снижается доля ручной классификации заявок, а служба ИБ получает аудируемую точку, где видно каждое отправленное в модель сообщение. Банковская тайна остаётся внутри — в облако уходит текст вида «клиент `<PERSON>` по карте `<CREDIT_CARD>` оспаривает операцию».
Как устроена обфускация на открытых инструментах
Эталонная сборка — связка LiteLLM Gateway и Microsoft Presidio. Presidio распространяется под лицензией MIT и из коробки распознаёт более 50 типов сущностей: имена, номера кредитных карт, телефоны, банковские счета, финансовые данные — через комбинацию NLP, регулярных выражений и контрольных сумм (microsoft/presidio).
В LiteLLM Presidio подключается двумя контейнерами — Analyzer (детектирует PII) и Anonymizer (маскирует), а сам gateway запускает проверку в режиме `pre_call`, то есть до того, как запрос дойдёт до модели. Какие сущности маскировать, а какие блокировать, задаётся в YAML (docs.litellm.ai):
```yaml
pii_entities_config:
CREDIT_CARD: "MASK"
PERSON: "MASK"
US_BANK_NUMBER: "BLOCK"
```
`MASK` подменяет значение плейсхолдером вроде `<CREDIT_CARD>`, `BLOCK` целиком отклоняет запрос с запрещённой сущностью. Порог уверенности (`presidio_score_thresholds`) гасит ложные срабатывания.
Восстановление значений в ответе
Ключ к «бесшовности» для оператора — обратимость. В LiteLLM флаг `output_parse_pii: true` включает восстановление: пользователь вводит чувствительные данные, модель видит маскированную версию («клиент `<PERSON>`»), отвечает с плейсхолдером, а gateway подставляет реальное значение перед возвратом оператору (docs.litellm.ai).
Глубже это реализуют решения с локальным «сейфом» соответствий. Цикл — Anonymize, Deanonymize и Vault, который хранит связку «плейсхолдер → реальное значение»: gateway создаёт session ID, заменяет PII на обратимые токены формата `{{ENTITY_TYPE_randomhex}}`, кладёт маппинг локально и восстанавливает оригиналы из него в ответе (Microsoft PII Shield). Принципиально, что сам маппинг и детекция работают локально — реальные данные не покидают инфраструктуру банка (LaxmiKumar Reddy, разбор Presidio).
Сценарий: обращение и скоринг
В чат-бот-сценарии банка приложение отдаёт сырой текст в прокси, прокси прогоняет его через детекцию, подменяет каждый кусок PII плейсхолдером и возвращает очищенный текст — модель никогда не видит реальный номер счёта или телефон (Microsoft PII Shield). Для скоринга заявки логика та же: модель классифицирует обращение, оценивает тональность и риск по обезличенному тексту, а решение возвращается оператору уже с восстановленными идентификаторами клиента.
Почему это «минимальная модификация ядра»
Подход не требует ни форка модели, ни патчей в CRM или АБС. Gateway — отдельный микросервис рядом с бизнес-логикой, OpenAI-совместимый: интеграция сводится к смене одного URL (philterd.ai). Это совпадает с принципом «не дорабатывать ядро инструмента»: банк меняет точку входа в LLM, а не переписывает свои системы. Компоненты зрелые и международные (Presidio — MIT, LiteLLM — open source), что даёт отчуждаемость: настройку recognizer-ов и YAML-политику можно передать другой команде без переписывания.
Важная оговорка из документации самого Presidio: нет гарантии, что система найдёт всю чувствительную информацию, поэтому детекцию дополняют allow/deny-списками, блокировкой по `BLOCK` для критичных сущностей (счета, СНИЛС) и логированием для аудита (microsoft/presidio). Для банка это означает политику «fail-closed»: при сомнении запрос блокируется, а не уходит в облако.
Вывод для бизнес-процесса
Точка вмешательства в процессе — шлюз между фронт-офисом и LLM. Обращение клиента проходит через gateway: ФИО, счета и карты обезличиваются по политике (MASK для имён/карт, BLOCK для счетов/СНИЛС), модель работает с анонимным текстом, ответ де-анонимизируется из локального сейфа и попадает оператору. Банк получает скорость и автоклассификацию LLM, не вынося банковскую тайну за периметр, и аудируемый журнал каждого запроса для ИБ и регулятора.
