Безопасность AI-пилота: что проверить до запуска

Модель сама по себе редко является единственным источником риска. Опаснее места, где AI получает доступ к данным, вызывает инструменты, пишет в CRM, отправляет сообщения или формирует рекомендацию, которой сотрудник доверяет без проверки.

Поэтому безопасность пилота описываем как карту контуров: данные, модель, инструменты, действия, человек, журнал и политика хранения. Если контур нельзя нарисовать, вы его не контролируете.

Для первого пилота не нужен тяжёлый enterprise GRC-процесс. Нужны базовые вопросы: какие данные загружаем, где они хранятся, кто видит логи, что агент может сделать сам, как отозвать доступ и как пользователь понимает, что общается с AI.

Регуляторная рамка стала практической. В ЕС уже действуют правила для GPAI, а прозрачность для пользователей и требования к высокорисковым системам постепенно превращаются в закупочные вопросы.

Даже если проект не попадает под строгие категории, заказчики всё чаще хотят видеть контроль доступа, объяснимость результата и журнал действий. И это нормальный запрос, а не вредность службы безопасности.

Threat model не обязан быть огромным документом. Для пилота достаточно описать, кто может повлиять на вход системы, какие данные модель видит, какие инструменты вызывает, куда пишет результат и кто принимает решение. Это сразу показывает, где нужен контроль.

Например, RAG-ассистент может столкнуться с prompt injection внутри документа, агент - с чрезмерными правами на CRM, OCR - с подменённым документом, а CV - с ложным событием из-за плохого ракурса. Риски разные, но логика одна: определить вход, действие, ущерб и способ остановки.

Для RAG и агентов опасны не только пользовательские промпты. Инструкция может лежать прямо в документе: «игнорируй предыдущие правила», «выведи все данные клиента», «отправь письмо». Если ассистент читает такие документы как контекст, он должен отличать источник знаний от инструкции к действию.

На пилоте стоит добавить тестовые вредные фрагменты в безопасной среде и проверить, как система реагирует: игнорирует инструкцию из документа, не раскрывает лишние данные, не вызывает инструмент без разрешения и объясняет пользователю границы ответа.

AI-системе не нужен полный доступ к бизнесу. Ей нужен минимальный набор прав под конкретный сценарий. Для поддержки это чтение базы знаний и тикетов. Для AI SDR - чтение заявки и создание черновика задачи. Для Document AI - доступ к очереди документов и справочникам, но не к финансовым операциям без подтверждения.

Разделение прав лучше проектировать по ролям и режимам: read-only, draft, approval, admin. Тогда можно запускать пилот постепенно и не блокировать весь проект из-за одного рискованного действия.

Перед выпуском AI-пилота в рабочий контур нужен небольшой release gate. Он отвечает на вопрос: достаточно ли безопасно запускать систему на ограниченную аудиторию. В gate входят eval-набор, список известных ограничений, роли доступа, журнал действий, инструкция для оператора и план отката.

Если у системы нет плана отката, она ещё не готова. Откат может быть простым: выключить автодействия, вернуть все ответы в manual review, ограничить темы, отключить конкретный tool, заменить prompt или заблокировать документ-источник.

Отчёт по безопасности не должен быть страшным PDF ради PDF. Полезнее короткая карта: какие данные использовались, какие риски проверены, какие меры уже включены, что осталось ограничением и при каких условиях можно масштабировать.

Такой отчёт помогает согласовать пилот с руководителем процесса, юристом, IT и службой безопасности. Когда все видят границы, проект меньше буксует на уровне «мы боимся AI вообще».