DLP для AI: маскирование PII, политики хранения и "минимизация данных" в чатах

Вот история, от которой любой CISO покроется холодным потом: AI-ассистент техподдержки "запоминает" номер карты клиента, а через неделю выплёвывает его совершенно постороннему человеку в ответ на хитрый промпт. Такие инциденты уже случались – и будут случаться, пока вокруг LLM не построена нормальная DLP-защита.

Чат с нейросетью – это не просто окошко для переписки. Это труба, по которой в вашу инфраструктуру могут утекать PII: телефоны, номера договоров, медицинские записи. Без контроля вы рискуете нарушить Закон РК о персональных данных и GDPR, нарваться на штрафы и, что болезненнее, потерять доверие клиентов.

Ниже – практическая схема для CTO и COO без лишней воды. Только рабочие механики: очистка PII, безопасные логи, политики хранения, шифрование. Всё, чтобы ваш AI оставался умным, но "немым" в отношении секретов.

TL;DR: Чек-лист для руководителей

• Фильтруйте на входе и выходе: PII не должны попадать в модель. Используйте NER (распознавание сущностей) и регулярные выражения для замены данных на токены или маски до отправки в LLM.
• Минимизируйте хранение: Храните контекст чата не дольше 24–72 часов. Аудит-логи держите 30–90 дней в зашифрованном виде, а остальное безжалостно удаляйте. Меньше данных – меньше рисков.
• Разделяйте доступы: Инженеры видят технические токены, бизнес – обезличенный текст, и только отдельные сервисные роли имеют ключи для восстановления данных (де-токенизации).
• Policy-as-Code: Политики хранения и доступа должны быть кодом (IaC), а не словами в регламенте. Проверяйте их автоматически на уровне CI/CD.
• Слепое логирование: В логи должны попадать только Trace ID и маскированные данные. Настройте алерты на любые признаки утечки PII в логах.

Как движутся данные: безопасный конвейер

Чтобы понять, где ставить защиту, давайте проследим путь сообщения от пользователя к AI и обратно. Это не просто "запрос-ответ", это конвейер обработки.

Запрос пользователя 

  → API Gateway (Аутентификация)

    → PII Scrubber (Очистка: поиск PII и замена на токены)

      → Policy Router (Проверка: можно ли этому юзеру говорить об этом?)

        → LLM Proxy (Отправка очищенного промпта модели)

          → Post-filter (Проверка ответа модели: не выдала ли лишнего?)

            → Delivery (Доставка ответа в чат/веб)

              → Audit Log (Запись безопасных логов)

Главное правило: PII (Personal Identifiable Information) умирают на этапе PII Scrubber. В саму LLM, в логи провайдера и в ваши внутренние логи попадают только обезличенные токены (например, <PHONE_NUMBER_1>). Обратное превращение (де-токенизация) происходит только в самый последний момент перед показом ответа пользователю, и только если это абсолютно необходимо.

Маскирование и токенизация: как спрятать данные

Просто заменить всё звездочками (***) – плохая идея. Модель потеряет контекст. Если клиент спрашивает "Измените мой номер на ...", а модель видит "Измените *** на ***", она не поймет, о чем речь.

Что использовать вместо звездочек?

• NER + Словари: Используйте Named Entity Recognition для поиска имен и адресов, а регулярные выражения для телефонов и карт. Добавьте "белые списки" для безобидных данных (города) и "красные" для критичных.
• Форматосохраняющая токенизация (FPE): Хитрый метод, который превращает +7(900)123-45-67 в +7(000)987-65-43. Формат на месте, модель понимает – это телефон, но реальные цифры скрыты. Критично для бизнес-логики.
• Token Vault: Это сейф, где лежит таблица соответствия REAL_DATA ↔ TOKEN. Доступ к этому сейфу должен быть у минимального числа сервисов.

Политики хранения: "Минимизация данных"

Меньше данных – меньше добычи для хакеров. Соблазн "сохранить всё для дообучения" в эпоху AI огромен, но это западня.

• TTL (Time-To-Live) везде:
  • Контекст активного чата: 24–72 часа. Этого достаточно для диалога, но безопасно.
  • Аудиторные логи: 30–90 дней. Достаточно для разбора инцидентов.
  • Датасеты для тестов: до 180 дней, затем ротация.
• Право на забвение: Реализуйте кнопку "Удалить всё обо мне". Технически это вызов API, который стирает ключи из Token Vault для конкретного user_id. Без ключей зашифрованные логи превращаются в цифровой мусор, который невозможно прочитать.
• Data Minimization в RAG: Когда вы ищете контекст для ответа (RAG), не тяните весь профиль клиента. Берите только top-N фактов, нужных прямо сейчас.

Доступ и шифрование: Кто что видит?

Ключи от королевства – не для каждого. Принцип Need-to-Know здесь критичен как нигде.

• Ролевой доступ (RBAC):
  – AI-бот: Видит только токены.
  – Поддержка: Может видеть де-токенизированные данные только в активном диалоге.
  – Разработчики: Видят только токены и синтетические данные. Никакого продакшн-доступа к PII!
• Управление ключами (KMS): Храните ключи шифрования в специализированных сервисах (AWS KMS, HashiCorp Vault). Секреты в переменных окружения (.env) – это прошлый век и дыра в безопасности.
• Правило двух людей: Любые операции с мастером-ключами или массовая выгрузка ("дамп базы") должны требовать подтверждения от второго офицера безопасности.

Безопасные логи и наблюдаемость

Логи – первое, куда лезут хакеры (и аудиторы). Ваша задача – сделать их бесполезной добычей.

• Scrubbed Logs: Логируйте только после очистки. Если PII Scrubber пропустил данные – это инцидент.
• Алерты SIEM: Настройте триггеры на аномалии. Всплеск обнаружения PII? Попытка доступа к Vault в неурочное время? Кто-то выкачивает слишком много логов? Сирена!
• Внешние подрядчики: Если вы отправляете логи во внешний сервис аналитики, убедитесь, что туда уходят только хеши или токены. Никогда не шлите "сырой" текст чатов наружу.

FAQ: Ответы на частые вопросы

В: Сильно ли тормозит маскирование данных?
О: Незначительно. Современные NER-модели и регулярные выражения добавляют всего 5–15 мс задержки. Для голосовых ботов это может быть критично, там используют асинхронную подмену, но для чата это незаметно.

В: Можно ли хранить векторные эмбеддинги PII? Это безопасно?
О: Это "серая зона". Технически восстановить текст из вектора сложно, но возможно. Лучшая практика – токенизировать данные до векторизации. Тогда в векторной базе будут лежать векторы токенов, что абсолютно безопасно.

В: Как юридически оформить работу с LLM-провайдером?
О: Обязательно подпишите DPA (Data Processing Agreement). Убедитесь, что провайдер (OpenAI, Anthropic и др.) обязуется не обучать свои модели на ваших данных (у большинства есть опция Opt-out или Enterprise API с Zero-data retention).

В: С чего начать, если денег на дорогие DLP-системы нет?
О: Начните с open-source библиотек для PII Scrubbing (например, Microsoft Presidio) и жестких политик логирования. Это закроет 80% рисков бесплатно.