Вот история, от которой любой 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. Доступ к этому сейфу должен быть у минимального числа сервисов.
| Метод | Где лучше применять | Плюсы / Минусы |
|---|---|---|
Полное удаление (Redaction)***** |
Для вывода на экран операторам, в небезопасных логах. | Максимально безопасно. Теряется контекст и связь данных. |
Токенизация (Masking)<PHONE_ID_1> |
В промптах LLM, в аналитических логах, в RAG. | Сохраняет смысл (это телефон) и связи (тот же телефон). Требует сложной системы управления ключами (Vault). |
Хешированиеsha256(salt+phone) |
Для поиска дублей, антифрода, статистики. | Дешево, необратимо (без ключа). Нельзя восстановить исходник, если он понадобится. |
Политики хранения: "Минимизация данных"
Меньше данных — меньше добычи для хакеров. Соблазн "сохранить всё для дообучения" в эпоху 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% рисков бесплатно.
Нужна помощь с защитой AI?
Мы помогаем компаниям строить безопасные контуры вокруг LLM. Настроим скраббинг, vault, политики доступов и научим вашу команду жить с этим. Работаем быстро, безопасно и без доступа к вашим реальным данным.
Запросить консультацию