Генеративный ИИ меняет модель угроз: чувствительные данные теперь могут уйти не через флешку, а через обычный промпт. Сотрудник вставляет фрагмент договора, выгрузку из CRM или переписку с клиентом — и формально «просто спрашивает модель».
Для российских организаций это пересекается с требованиями 152-ФЗ, внутренними политиками ИБ и ожиданиями регуляторов/аудиторов. Ниже — практическая рамка: процессы, технические контроли и роль AI Gateway на платформе AIaaS.
Почему классический DLP не закрывает LLM автоматически
Традиционный DLP заточен под файлы, почту и съёмные носители. В LLM-сценариях данные путешествуют как текст в API, иногда порезанный на чанки, иногда смешанный с системным промптом и историей диалога.
Нужны правила именно на уровне AI-шлюза: детектирование PII/PCI/коммерческих маркеров до вызова модели, маскирование, блокировка, карантин и алерт.
Учтите мультимодальность: скриншоты паспортов, фото анкет, PDF-вложения. DLP только на plain text оставляет дыру в самом популярном пользовательском сценарии «сфоткал и спросил».
Карта данных для ИИ-сценариев
До внедрения составьте матрицу: какие сущности могут попасть в промпт (ФИО, телефон, паспорт, ИНН, содержимое тикетов, тела писем), в каких системах они живут, допустим ли вывод за периметр.
Для каждого пилота явно запишите: «в модель можно / нельзя / только в маскированном виде». Без этого ИБ вынуждена либо запрещать всё, либо закрывать глаза.
Свяжите карту данных с владельцами процессов: CRM, HR, support, legal. Иначе список сущностей будет неполным, а политики — формальными.
- Категории данных и грифы
- Разрешённые контуры обработки
- Срок хранения промптов и ответов
- Кто имеет доступ к сырым логам
- Процедура инцидента при утечке через ИИ-канал
Технические контроли в gateway
Централизуйте вызовы LLM. Именно шлюз становится точкой, где применяются политики до и после модели: redaction телефонов и документов, запрет вложений определённого типа, ограничение моделей для чувствительных проектов.
Логируйте метаданные всегда; сырой текст — по политике и с шифрованием. Для разбора качества используйте ролевой доступ и маскированные витрины.
Настройте режимы реакции: mask (заменить и продолжить), block (отклонить запрос), quarantine (на review). Для prod клиентских каналов чаще нужен block+alert, для внутреннего assist — mask.
Таблица рисков: сценарий → угроза → контроль
Сведите типовые угрозы в операционный список, понятный и ИБ, и владельцам продуктов. Ниже — минимальный набор для старта контроля.
- Оператор вставляет ПДн клиента в чат → утечка в модель → DLP redaction до вызова + обучение
- Разработчик кладёт ключ LLM в CI → несанкционированный доступ → секреты в vault, короткоживущие ключи
- RAG индексирует черновик с грифом → ответ не тому сотруднику → ACL-фильтр до генерации
- Логи промптов без TTL → новое хранилище ПДн → политика хранения и шифрование
- Теневой ChatGPT → обход контролей → корпоративный канал + мониторинг аномалий
152-ФЗ: на что смотреть прагматично
С точки зрения архитектуры важны: правовые основания обработки, минимизация данных, инструкции для операторов/подрядчиков, прозрачность того, где обрабатываются данные, и возможность обеспечить права субъекта. Конкретную юридическую позицию формирует ваша compliance-служба — ИТ даёт техническую реализуемость.
Запросите у AIaaS-провайдера: описание контуров, subprocessors, запрет обучения на ваших данных, сроки хранения, процедуру удаления, возможности локализации.
Проверьте, можете ли вы выполнить запрос субъекта на удаление/уточнение в цепочке: приложение → логи gateway → индекс RAG. Если технически нельзя — это дыра процесса, а не «вопрос юристам потом».
Человеческий фактор и теневой ИИ
Если корпоративного канала нет, запреты обходят. Рабочая стратегия: дать удобный разрешённый инструмент с SSO, понятными лимитами и быстрым откликом — и параллельно мониторить аномалии.
Обучение сотрудников должно быть предметным: что нельзя вставлять в промпт, как пользоваться маскированием, куда эскалировать сомнительный кейс. Общие лозунги «думайте о безопасности» не работают.
Встройте подсказки в UI: перед отправкой длинного текста — предупреждение о ПДн; в шаблонах — кнопки «вставить без персональных данных». Удобство снижает обход политик лучше штрафов.
Сценарии с повышенным риском
Контакт-центр и CRM, разбор обращений с ПДн, кадровые документы, медицинские и финансовые данные, вложения из почты. Для них чаще нужен отдельный проект в gateway с жёсткими политиками и human-in-the-loop.
Связанные материалы: ИИ в CRM и контакт-центре, Document AI, RAG и база знаний.
Для таких контуров запретите «свободный чат» без контекста системы. Разрешайте только сценарии с фиксированными полями и утверждёнными шаблонами промптов.
Аудит и доказательства
Аудиторам нужны не слайды, а следы: кто вызвал модель, какая политика сработала, был ли redaction, куда ушёл запрос, сколько хранится лог. Проверьте, что платформа отдаёт события в SIEM и умеет строить отчёты по проектам.
Регулярно тестируйте негативные кейсы: попытка отправить паспортные данные, выгрузку клиентов, секреты из vault. Результаты фиксируйте как часть control testing.
Храните evidence pack: конфиг политик, результаты тестов, RCA инцидентов, список subprocessors. Это ускоряет ответы на questionnaire банков, партнёров и внутреннего аудита.
Модель операционной ответственности
CISO задаёт политики и принимает риск. Владелец платформы внедряет контроли в gateway. Владельцы продуктов не обходят шлюз «для скорости». FinOps следит, чтобы безопасность не отключали ради снятия лимитов.
Такое разделение ролей стоит описать до масштабирования — иначе в инциденте не будет понятного владельца.
В RACI явно укажите, кто утверждает исключение из DLP (временный allow). Исключения без срока и владельца — путь к постоянной дыре.
Минимальный набор политик DLP для старта
Не ждите идеального классификатора на все категории данных. Запустите узкий, но жёсткий набор правил и расширяйте его по инцидентам и ложным срабатываниям.
Каждое правило должно иметь владельца, severity, режим реакции и тест-кейс. Иначе политики быстро превращаются в непрозрачный чёрный ящик.
- Паспорт/серия-номер, СНИЛС, ИНН, телефоны, email — mask или block
- Секреты: API keys, passwords, private keys — block + alert
- Выгрузки CRM/клиентские списки — block вне approved проектов
- Вложения сканов документов в свободный чат — quarantine
- Исключения только с TTL и записью в журнал рисков
Инцидент через ИИ-канал: что делать
Даже при хороших контролях нужен playbook инцидента: кто объявляет severity, как блокируется проект/ключ, как оценивается объём потенциально ушедших данных, кого уведомляют.
Технически подготовьте заранее: возможность revoke ключей, выгрузку audit trail за период, процедуру удаления логов, коммуникационный шаблон для бизнеса.
После инцидента обязательны RCA и усиление правила DLP. Инцидент без изменения контроля почти гарантированно повторится в другом отделе.
Практический план на 30 дней
Инвентаризация ИИ-использования, выбор единого канала, пилот DLP-правил на 2–3 проектах, обучение пилотной группы, отчёт для риск-комитета. Параллельно зафиксируйте требования в договоре с провайдером.
Для системного подхода используйте чеклист как выбрать AIaaS и архитектуру корпоративного шлюза.
День 1–5: инвентаризация ключей и сервисов. День 6–15: включение gateway и базового redaction. День 16–25: негативные тесты и обучение. День 26–30: отчёт и решение о масштабе политик.
После первых 30 дней переходите в ритм: ежемесячный control test, квартальный пересмотр карты данных, разбор всех исключений с истекшим TTL.
Частые вопросы
Нет. Запрет без альтернативы усиливает теневой ИИ. Нужен корпоративный канал с DLP, аудитом и разрешёнными сценариями — иначе сотрудники продолжат использовать личные сервисы.
Даже при наличии правовых оснований нужны минимизация, защита, учёт и контроль подрядчиков. Технически — маскирование, ограничение контура, договоры и аудит. Юридическую квалификацию даёт ваша служба compliance.
В приложении — дополнительный контроль; обязательно — в едином gateway, иначе политики разъедутся между командами. Централизованный enforcement проще доказывать аудиторам.
По умолчанию — метаданные и факт срабатывания политик. Сырой текст — только при обоснованной необходимости, с шифрованием, коротким TTL и жёстким ACL. Иначе лог сам становится хранилищем ПДн.