Управление рисками ИИ
Назначение
Документ описывает, как в ИИ-конвейере выявляются, оцениваются и контролируются риски решений с применением ИИ: моделей машинного обучения, языковых моделей, помощников по знаниям, автоматизаций и агентных сценариев.
Задача управления рисками — не запретить ИИ, а не допустить ситуации, когда решение влияет на бизнес-процесс, клиентов, деньги или регуляторные обязательства без понятного качества, владельца и режима остановки.
Основные идеи
- Риск зависит от влияния решения. Внутренний помощник и решение, влияющее на клиентский лимит, требуют разной строгости.
- Человек в контуре — управленческое решение. Нужно явно определить, где ИИ советует, где готовит черновик, а где действие выполняется автоматически.
- Качество должно измеряться. Нельзя запускать решение, если непонятно, как проверяется точность, полнота, стабильность или полезность результата.
- Ограничения должны быть видимыми пользователю. Если решение не подходит для юридически значимых выводов, это должно быть явно зафиксировано.
- Остановка должна быть заранее описана. У работающего решения должны быть условия пересмотра, отключения или отката.
Как это работает
Управление рисками ИИ встроено в контрольные точки:
| Этап | Что проверяется | Решение |
|---|---|---|
| Новая | есть ли очевидно высокий риск | отправить в оценку, отклонить или запросить безопасность |
| Оценка | класс риска, данные, влияние на процесс, человек в контуре | выбрать маршрут деливери и уровень контроля |
| Деливери | качество, тестирование, ограничения, журналирование, откат | разрешить запуск или вернуть на доработку |
| Ожидает эффекта | фактическое качество и влияние на процесс | подтвердить эффект, скорректировать или остановить |
| Поддержка | деградация, инциденты, изменение данных и процесса | продолжить, пересмотреть или отключить |
Связанные разделы: модель управления ИИ, управление данными, модель контрольных точек.
Основные виды риска
| Риск | Что может пойти не так | Как контролировать |
|---|---|---|
| Ошибка результата | решение даёт неверный ответ, прогноз или рекомендацию | тестовые наборы, ручная проверка, пороги качества |
| Галлюцинации | языковая модель уверенно выдумывает факты | ссылки на источники, ограничение контекста, проверка критичных ответов |
| Смещение | результат системно хуже для части клиентов, продуктов или процессов | анализ выборок, проверка справедливости, ограничения применения |
| Утечка данных | чувствительная информация попадает в неподходящий контур | классификация данных, маскирование, контроль доступа |
| Автоматическое действие без контроля | решение выполняет действие, которое должен подтвердить человек | человек в контуре, лимиты, журнал действий |
| Деградация качества | данные или процесс изменились, а решение продолжает работать по-старому | мониторинг, периодический пересмотр, сигналы остановки |
| Невоспроизводимость | невозможно понять, почему был получен результат | версии данных, модели, промпта, правил и параметров |
| Репутационный риск | решение выглядит несправедливым, непрозрачным или небезопасным | объяснимость, правила применения, коммуникация ограничений |
Классы влияния
Минимальная классификация по влиянию:
| Класс | Описание | Требования |
|---|---|---|
| Подсказка | ИИ помогает пользователю, но не принимает решение | предупреждение об ограничениях, базовая проверка качества |
| Черновик | ИИ готовит текст, документ, расчёт или рекомендацию для проверки человеком | обязательное подтверждение человеком, журналирование |
| Рекомендация | ИИ влияет на выбор, приоритет или действие | метрики качества, объяснение факторов, владелец решения |
| Автоматическое действие | ИИ запускает действие без ручного подтверждения | строгие лимиты, откат, аудит, расширенное согласование |
| Критичное влияние | решение влияет на деньги, клиентов, риск, безопасность или юридически значимые процессы | независимая проверка, человек в контуре, регулярный пересмотр |
Чем выше класс влияния, тем больше требований к проверке, мониторингу и документированию.
Что фиксировать в карточке инициативы
Для инициатив со средним и высоким риском нужно фиксировать:
- класс влияния;
- тип решения;
- используемые данные;
- владельца бизнес-решения;
- владельца технического решения;
- ограничения применения;
- метрики качества;
- результаты проверки;
- режим участия человека;
- условия остановки;
- план отката;
- дату следующего пересмотра.
Эти данные могут храниться как поля карточки, артефакты или задачи, но они должны быть доступны при прохождении контрольных точек.
Проверка перед запуском
Перед переводом инициативы в ожидание эффекта нужно ответить на вопросы:
- на каких данных проверено решение;
- какие метрики качества достигнуты;
- что считается ошибкой;
- кто проверял результаты;
- какие ограничения известны;
- что пользователь увидит в интерфейсе;
- кто отвечает за инциденты;
- как решение отключить;
- что произойдёт при недоступности модели, данных или внешнего сервиса.
Если на эти вопросы нет ответов, решение может быть прототипом, но не управляемым внедрением.
Мониторинг после запуска
После запуска нужно отслеживать:
- качество результата;
- объём использования;
- долю ручных исправлений;
- жалобы и инциденты;
- изменение входных данных;
- задержки и ошибки интеграций;
- стоимость работы решения;
- фактическое влияние на бизнес-показатели.
Для решений высокого влияния должен быть задан пересмотр: например, раз в квартал, после изменения источника данных или после значимого инцидента.
Роль ИИ-помощника
ИИ-помощник может:
- собрать описание рисков;
- подготовить черновик проверки безопасности;
- подсказать ограничения;
- сформировать список вопросов к владельцу данных;
- помочь с отчётом по инициативе;
- подготовить задачи на проверку качества.
Но ИИ-помощник не должен самостоятельно утверждать рисковые переходы, давать финальное заключение безопасности или обходить права доступа.
Условия остановки
Решение должно быть остановлено или пересмотрено, если:
- качество ниже согласованного порога;
- обнаружена утечка или нарушение доступа;
- изменился источник данных;
- пользователи массово исправляют результат;
- выросла стоимость эксплуатации;
- решение используется не по назначению;
- бизнес-эффект не подтверждается;
- появились новые регуляторные или внутренние ограничения.
Анти-паттерны
Плохое управление рисками:
- «проверим качество после запуска»;
- языковая модель отвечает без ссылок на источники в критичном процессе;
- автоматизация выполняет действие без журнала и отката;
- ограничения написаны в документе, но не видны пользователю;
- нет владельца инцидентов;
- нет даты пересмотра;
- риск не влияет на решение о переходе.
Хорошее управление рисками делает риск частью маршрута инициативы, а не поздним стоп-краном.