Надёжность — реальное испытание агентного ИИ

За последние два года отрасль задавала один вопрос: способны ли AI‑агенты достаточно, чтобы справляться с реальной работой? Мы можем перестать задавать его. Мы знаем, что они способны, но нам необходимо сосредоточиться на том, сможем ли мы определить, когда агент собирается совершить дорогостоящую ошибку, — и сможем ли мы остановить её до того, как она произойдёт.

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

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

Почему агентный ИИ усиливает риск

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

Контекст

Агенты могут работать только с предоставленным контекстом. Поэтому, если контекст неполный, устаревший или ошибочный, неверная интерпретация на раннем этапе будет распространяться на каждый последующий шаг. Ошибочный ответ чат‑бота раздражает. Ошибочная интерпретация, меняющая права доступа или затрагивающая инфраструктуру, является инцидентом. Важно знать, использовал ли агент правильные доказательства, следовал ли политике и оставался ли в приемлемом радиусе воздействия, если что‑то пошло не так.

Базы знаний

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

Зелёная панель может вводить в заблуждение: инфраструктура выглядит в порядке, пока агент тихо запрашивает один и тот же инструмент снова и снова. Это ранний признак дрейфа, а не обычного сбоя.

Недетерминизм

Недетерминизм также усложняет реагирование на инциденты. Традиционный сбой сервиса обычно можно воспроизвести по идентификатору запроса и известной версии программного обеспечения. Запуск агента зависит от версии модели, полученных им документов, выводов инструментов и цепочки промежуточных решений. Без записи того, что агент получил и попытался выполнить, анализ первопричин и управление становятся гораздо сложнее.

Стоимость и задержка

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

Децентрализованный ИИ всё ещё нуждается в централизованной видимости

Децентрализация терпит неудачу без чётких ограничений. Передайте владение рабочими процессами и эскалацией фронтовым командам, но сохраняйте управление идентичностью, доступом и реагированием на инциденты на уровне предприятия. Финансовая команда может различить легитимное исключение из счёта и неправильное решение о платеже так, как это никогда не сделает общий бенчмарк.В том же опросе McKinsey обнаружил, что организации, сообщающие о реальном влиянии ИИ, почти в три раза чаще переработали свои рабочие процессы, а не просто добавляли ИИ к существующим.

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

Распределённые архитектуры упрощают потерю полной картины при поломке. Многие команды могут видеть объём токенов и стоимость, но они не могут увидеть, достиг ли агент действительно безопасно запланированного результата. Когда записи рабочего процесса находятся в разных местах, команды в итоге гонятся за симптомами, а не за причинами.

Стандартизованные телеметрические сигналы, такие как идентификатор модели и вызовы инструментов, могут помочь. Поведенческие базовые линии, например нормальное количество шагов в рабочем процессе, также необходимы для выявления полезного застревания системы. Оценка — это не одноразовый фильтр перед запуском. Это непрерывный цикл.

Как выглядит надёжный ИИ в реальном производстве

Надёжный ИИ — это управление ошибками, а не их избегание. Командам нужна видимость поведения; оповещения при отклонении производительности; и план сдерживания на случай, когда что‑то пойдёт не так. Самое главное, каждому агенту нужны чёткие ограничения доступа и автономных действий. Им также требуется человеческое одобрение. 

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

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

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

AI SRE закрывает цикл

Здесь и вступает в игру AI SRE. Агент AI SRE может собрать хронологию инцидента, сравнить текущее поведение с прошлым, и подготовить рекомендованное действие, пока организация сохраняет контролируемое исправление для обратимых задач и человеческое одобрение для любого значимого.

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

Именно эту роль и заполняет AI SRE: соединять децентрализованные инновации с централизованной видимостью и превращать агентный ИИ в систему, которой предприятие может доверять.