Что делать, когда AI-система ошибается в реальной операции

Почему классический регламент не подходит для ИИ

Классическое реагирование на инциденты строится на трёх допущениях: сбой воспроизводим, он заявляет о себе как ошибка, и у дежурного есть рычаг, меняющий исход. В продакшене с языковой моделью все три допущения перестают действовать одновременно. Модель может ошибаться, но возвращать 200 OK и уверенный связный текст; одинаковый запрос даёт разные результаты из-за пакетной обработки на GPU и неассоциативного сложения чисел с плавающей точкой; а дежурный часто вообще не может изменить саму модель.

Ошибка модели обычно «тихая». В контуре поиска и генерации (RAG) поиск возвращает слабо релевантные документы, генератор всё равно пишет связный ответ, и каждый шаг в трейсе помечается успешным. Регрессия приходит не равномерно, а «сегментно»: несколько процентов запросов в одном сегменте клиентов почти не сдвигают агрегированную метрику качества, поэтому сигнал часто приходит от аккаунт-менеджеров, а не от мониторинга.

Полезно разделять два типа инцидентов: ошибки самой модели (деградация, предвзятость, галлюцинация) и ошибки из-за внешнего воздействия (инъекции промптов, отравление данных, утечки). У них разная логика обнаружения, локализации и юридической оценки. Разделение помогает не складывать поведенческие сбои в общую корзину «прочее» и быстрее находить владельца исправления.

Подготовка до запуска: порог, владелец и аварийная кнопка

Быстро реагируют те, кто заранее определил, что считать инцидентом. Зафиксируйте порог отката для каждой выпущенной модели: аномальную частоту, показатель дрейфа или отклонение по справедливости, при достижении которых включается резерв или остановка. Команда без порога тратит первые часы на споры, есть ли проблема вообще; команда с порогом эти часы тратит на реагирование.

Назначьте владельца и маршрут эскалации до того, как что-то сломалось. Для ИИ в цепочку обязательно входит специалист по данным или ML-инженер, который может в реальном времени разбираться в поведении модели, а не тот, кого пригласят уже после инцидента для отчёта. Поскольку сбой редко ограничен одной системой, в реагировании участвуют и эксперты из нетехнических областей — продукта, клиентского сервиса, риска.

Аварийный переключатель должен быть проверен заранее: дежурный обязан уметь отключить функцию ночью, в одиночку, без деплоя и без второго человека. Отключайте на уровне конкретной способности, а не всего сервиса, и отрабатывайте сценарий в «игровой день» до запуска. Непроверенный стоп-переключатель — это вера, а не контроль. Помните, что расписания и версии меняются, поэтому такую проверку стоит повторять регулярно.

• Определите порог отката и именованный резерв для каждой модели.
• Назначьте владельца, ML-инженера и маршрут эскалации.
• Проверьте, что дежурный может остановить функцию один, без деплоя.
• Отработайте «игровой день»: включение резерва и глобального стопа.

Первые минуты: локализуй, а не диагностируй

Когда что-то выглядит неверно, не бросайтесь искать причину. Сначала ограничьте вред минимально действующим контролем: отключите конкретный инструмент, сценарий или защиту, переведите затронутые случаи на проверенный резерв или на ручную проверку. Контроль уровня функции сохраняет сервис и избегает бизнес-эскалации от полной остановки.

Для систем с высоким риском держите глобальный стоп-контроль, недоступный самой модели или агенту, и применяйте его только тогда, когда продолжение работы опаснее остановки. Понятие «изолировать систему» здесь почти всегда неверный первый шаг: перевод на правило или резерв может причинить меньше вреда, чем отключение всего сервиса.

До любых изменений зафиксируйте след: развёрнутый промпт, версии шаблона, модели и провайдера, идентификаторы найденных документов с оценками релевантности, последовательность вызовов инструментов, исходный вывод, временные метки и идентификатор запроса. Полный след отделяет «поиск ничего не нашёл» от «генератор проигнорировал контекст» — это разные причины и разные владельцы исправления.

Кому сообщить и что записать

Тип инцидента определяет правовую и коммуникационную реакцию. Это общий материал, а не юридическая консультация: последствия зависят от юрисдикции и конкретных обстоятельств. В ряде стран регуляторы и суды уже рассматривали выдуманную моделью политику как ошибку, за которую отвечает организация, а предвзятость инструмента найма — как действие, совершённое от имени работодателя. Если юристы узнают об инциденте из запроса прессы — регламент провален.

Фиксируйте по ходу инцидента: кто затронут, какие данные в зоне ответственности, какие действия предприняты и кто их одобрил, когда отправлены уведомления. Заранее уведомите владельцев операций, продукта, безопасности и риска. Клиентам дайте ясное объяснение влияния и следующих шагов, а не только «красную» страницу статуса — прозрачность восстановления часто укрепляет доверие сильнее, чем полное отсутствие ошибок.

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

Восстановление, проверка и обратная связь

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

После локализации добавьте инцидент и его безопасные вариации в наборы для оценки и регрессионных тестов. Исправьте нужный контроль — защиту, порог, промпт, правило поиска или права доступа, — а не просто «улучшите промпт». Проверьте изменение и на самом инциденте, и на обычных пользовательских сценариях, а после выкладки сверьте производственные базовые метрики.

Пересмотрите архитектуру контроля. Ужесточение порога может подавить одну ошибку, но увеличить ложные срабатывания в другом месте, поэтому не закручивайте порог автоматически после каждого случая. Оценивайте, действительно ли ручные проверяющие ловят проблемы: если уровень одобрения держится около 90% и выше, рецензенты скорее подтверждают, чем оценивают, и такая «проверка человеком» не является настоящим слоем безопасности.

Метрики, которые вы реально контролируете

Перепишите посмертный разбор: для вероятностной системы корневая причина часто невосстановима. Вместо формулировки «мы улучшили промпт» оценивайте время до обнаружения, время до локализации, использовался ли стоп-переключатель и сработал ли он, и была ли достигнута цель сдерживания. Такая версия разбора не заставляет инженеров чувствовать себя виноватыми за ограничения самой модели.

Разделите соглашение об уровне сервиса (SLO) на три уровня: сервисный, поведенческий и уровень сдерживания. Доступность и задержка необходимы, но недостаточны. Поведенческое качество ограничено моделью, которую вы не обучали, поэтому честно скажите руководству, какие числа вы можете двигать, а какие принадлежат чужому тренировочному запуску. Сдерживание — доля плохих ответов, перехваченных до того, как их увидел пользователь, и минуты от обнаружения до отключения, — это уровень, который команда действительно может гарантировать.