Хороший реестр отвечает на простые вопросы: что может пойти не так, насколько это вероятно, насколько больно ударит по делу, кто за это отвечает и что делаем заранее. Для ИИ-проектов это особенно важно, потому что риски часто лежат на стыке технологий, данных, людей и регуляторики.
В реестре обычно есть поля: название риска, описание, причина, вероятность, влияние, уровень риска, владелец, статус, план снижения, план реагирования, дата пересмотра и ссылка на доказательства. Если проект связан с AI agent, стоит отдельно фиксировать риски промпт-инъекций, утечки контекста, небезопасных tool calls, ошибок RAG, галлюцинаций, некорректной автоматизации и отсутствия human-in-the-loop.
Risk Register не нужен ради отчетности. Его смысл в том, чтобы команда заранее видела опасные места и могла принимать решения: где добавить guardrails, где включить ручное подтверждение, где ограничить права агента, где настроить мониторинг, а где вообще отказаться от автоматического действия.
Примеры
- Риск промпт-инъекции: пользователь может вставить инструкцию, которая заставит агента игнорировать правила. В реестре фиксируют вероятность, влияние, владельца и меры: фильтр входа, tool policy, тестовые атаки и ручное подтверждение опасных действий.
- Риск утечки персональных данных: агент может отправить во внешнюю модель лишние данные из CRM или документов. Меры: маскирование полей, allowlist данных, журналирование запросов и запрет передачи чувствительных фрагментов.
- Риск ошибки в автоматическом действии: агент может создать счет, изменить сделку или отправить письмо не тому адресату. В реестре указывают, какие действия требуют подтверждения человеком и как выполняется откат.
- Риск зависимости от внешнего API: если API модели, CRM или рекламного кабинета недоступен, процесс встает. План снижения: retries, fallback-сценарий, лимиты, мониторинг и понятное сообщение пользователю.
- Риск роста стоимости: агент может расходовать слишком много токенов или запускать лишние проверки. В реестре фиксируют лимиты бюджета, алерты и правила остановки.
Где используется
- Запуск ИИ-агента в поддержку, продажи, финансы или юридический отдел.
- Подготовка проекта к пилоту, аудиту или согласованию с безопасностью.
- Контроль рисков при подключении агента к CRM, почте, базе знаний, 1С или API.
- Описание guardrails: какие действия разрешены, какие запрещены, какие требуют подтверждения.
- Планирование мониторинга: какие ошибки, события и аномалии нужно отслеживать.
- Согласование ролей: кто владелец риска, кто принимает решение, кто делает откат.
- Оценка подрядчика или платформы перед внедрением AI-решения.
- Подготовка документации для AI governance и внутренней политики безопасности.
- Регулярный пересмотр рисков после обновления модели, промптов, инструментов или данных.
Связанные термины
Частые вопросы
Чем Risk Register отличается от threat model?
Threat model глубже разбирает угрозы безопасности: кто атакует, через какие входы и какие меры защиты нужны. Risk Register шире: туда попадают не только атаки, но и операционные, финансовые, юридические, продуктовые и организационные риски.
Нужен ли реестр рисков маленькому AI-проекту?
Да, но он может быть простым. Для пилота достаточно таблицы с риском, вероятностью, влиянием, владельцем, статусом и планом действий. Главное — чтобы команда реально пересматривала ее, а не хранила как формальность.
Какие риски первыми добавить для ИИ-агента?
Начните с утечки данных, промпт-инъекций, неверных действий через инструменты, галлюцинаций, ошибок интеграций, роста стоимости, отсутствия логов и непонятного владельца ответственности.
Как оценивать уровень риска?
Чаще всего используют простую шкалу: вероятность от 1 до 5 и влияние от 1 до 5. Итоговый уровень считают как произведение. Высокие риски требуют владельца, срока и конкретного плана снижения.
Как ИИ может помогать вести Risk Register?
ИИ может находить похожие риски в документах, группировать события из логов, предлагать формулировки и напоминать о пересмотре. Но финальная оценка риска и решение по мерам защиты должны оставаться за ответственным человеком.
