DLP для LLM-трафика: как поймать кусок договора в промпте до ChatGPT за 30 мс и не словить штраф по 152-ФЗ 

Месяц назад мидл-аналитик крупного финтеха скормил в публичный Claude сырой дамп с кредитными скорингами 300 клиентов, чтобы «быстренько сгенерировать парсер». Корпоративный DLP пропустил инцидент, потому что для него это был легитимный HTTPS-трафик, а не пересылка файла `base.csv`. Утечку нашли только при подготовке к аудиту. Пытаться закрыть проблему shadow AI классическими ИБ-инструментами — это как ловить пули теннисной ракеткой. Если вы не парсите семантику на уровне исходящего потока, у вас нет ИБ, у вас карго-культ.

Иллюзия защищенного периметра

Тема DLP для LLM-трафика: как поймать кусок договора в промпте до ChatGPT за 30 мс и не словить штраф по 152-ФЗ звучит длинно, но описывает ровно одну критическую уязвимость 2026 года — egress-контроль. Сразу очертим границы: мы не обсуждаем защиту on-prem-весов (это инфраструктурная задача) и не говорим про промпт-инъекции (это входящий вектор атаки). Речь о том, что ваши сотрудники прямо сейчас сливают коммерческую тайну в сторонние публичные ассистенты.

Классический DLP, будь то InfoWatch или Solar Dozor, заточен под файлы, почту и USB. Он ищет конкретные расширения, контрольные суммы или регулярные выражения (например, формат номера карты). Трафик к LLM — это всегда TLS. Даже если вы настроили терминацию на корпоративном шлюзе, полезная нагрузка внутри — это неструктурированный текст в JSON-обертке. Паттерна нет. Регулярки бесполезны, когда разработчик вставляет 500 строк проприетарного исходного кода с просьбой найти баг, а юрист копирует текст соглашения, меняя только названия компаний. Это семантическая утечка, которую невозможно поймать статическими правилами.

Архитектура LLM-aware шлюза: инспекция под нагрузкой

Кстати, блокировка `chatgpt.com` на DNS-уровне работает до первой недели. Потом отдел маркетинга покупает удобный враппер-клиент, а разработчики начинают дергать API-ключи прямо из IDE. Периметр дырявый по определению.

Единственный рабочий подход — развертывание LLM-aware шлюза. Прокси-сервер, который встает в разрыв, терминирует TLS, парсит специфичные форматы API (OpenAI, Anthropic, Gemini) и на лету прогоняет текст через локальный классификатор. Главное требование к такому узлу — жесточайший бюджет латентности. Если ваша инспекция добавляет к запросу две секунды, UX становится невыносимым, и разработчики найдут способ обойти корпоративный VPN. Цель — уложить весь конвейер детекции в 30–50 мс на p99.

Отсюда следует, что тащить тяжелые LLM-модели для анализа самих промптов в реальном времени — самоубийство. Требуется быстрый специализированный NLP-классификатор, скомпилированный под целевое железо (TensorRT или ONNXRuntime), который ищет ПДн, номера договоров, токены, секреты и даже специфичные векторные эмбеддинги, если утекли данные из внутреннего RAG-контура.

import onnxruntime as ort  
import numpy as np  

# Пример узкого места: инференс локального PII-классификатора на шлюзе
# Бюджет времени: строго < 15 мс на батч
class PromptInspector:
    def __init__(self, model_path: str):
        # Использование CPUExecutionProvider для edge-нод без GPU, 
        # либо TensorrtExecutionProvider для high-load серверов
        self.session = ort.InferenceSession(model_path, providers=['CPUExecutionProvider'])
        self.input_name = self.session.get_inputs()[0].name
        
    def detect_leak(self, text_embeddings: np.ndarray) -> bool:
        # text_embeddings уже подготовлены легковесным токенизатором
        predictions = self.session.run(None, {self.input_name: text_embeddings})[0]
        # P99 latency этого вызова решает, выживет ли архитектура в проде
        return predictions[0] > 0.85 # Threshold уверенности в наличии коммтайны

Вся эта машинерия обязана работать on-premise, в вашем изолированном контуре. Если шлюз отправляет промпты на анализ в облачное API ИБ-вендора, вы просто создали легализованный канал утечки тех же самых данных, но уже третьей стороне.

Когда шлюз ловит триггер, система должна отработать по одному из сценариев:

• Блокировка (Hard Block): сброс соединения, возврат 403 с заглушкой «Запрос заблокирован политикой безопасности».
• Маскирование (Redaction): замена сущностей. «Иванов И.И.» превращается в `[PII_USER_1]`, запрос уходит в OpenAI, ответ возвращается, шлюз восстанавливает фамилию перед выдачей сотруднику. Выглядит как магия, но требует хранения стейта на прокси.
• Теневой алерт: запрос проходит без задержек, но событие мгновенно улетает в SOC-центр для расследования.

Каждое срабатывание, как и полные дампы промптов (если позволяет политика), необходимо сгружать в SIEM. Неизменяемый журнал аудита — единственный аргумент, который спасет компанию от штрафов ФСТЭК или РКН при разборе инцидентов. Вы должны показать, кто, когда и что пытался отправить в облако, и как автоматика это пресекла.

У нас в Morana Labs мы решаем это развертыванием полностью изолированного контура с кастомным LLM-gateway. Вместо громких заявлений про «100% блокировку» (которой в природе не существует) мы тюним квантованные модели под датасет конкретного клиента, вытягивая баланс precision/recall так, чтобы ловить реальные исходники и паспорта, не блокируя при этом легитимные запросы на рефакторинг open-source кода. И укладываемся в 25 мс инференса прямо на железе заказчика.