В 2:07 ночи приложение может выглядеть живым: процессы запущены, инфраструктура отвечает, привычные метрики не горят красным. Но ИИ-агент внутри контура уже срывает запросы, пользователи ждут ответа, а у команды возникает неприятный вопрос: кто обязан поднять трубку? Ответственность за ИИ-агентов быстро становится не теоретической темой для архитектурных встреч, а частью ночного дежурства — и для российских IT-команд это означает необходимость пересматривать привычные границы между разработкой, платформой, ML и бизнесом.
Именно этот разрыв разбирает The New Stack: агент способен продолжать работу в составе внешне исправного приложения, но его собственная цепочка принятия решений, вызовы инструментов или взаимодействие с моделью уже могут деградировать. Классическая схема on-call в такой ситуации даёт сбой не из-за нехватки алертов, а потому что неясен владелец инцидента. SRE отвечает за доступность платформы, команда продукта — за пользовательский сценарий, разработчики — за код интеграции, а специалисты по ИИ — за качество модели. Когда агент начинает действовать непредсказуемо или просто перестаёт укладываться в допустимое время ответа, каждый из этих контуров может сказать: «Это не совсем наша поломка».
У обычного сервиса границы ответственности обычно понятнее. Есть владелец API, целевые показатели доступности, runbook, дежурная смена и процедура эскалации. У агента одна пользовательская задача нередко проходит через несколько слоёв: модель интерпретирует запрос, оркестратор выбирает следующий шаг, агент вызывает корпоративный поиск или другую систему, получает результат и формирует ответ. Ошибка может находиться в любом звене — либо в их сочетании. Например, сервис доступен, но агент слишком долго повторяет неудачный вызов инструмента; модель отвечает, но выбирает неверную последовательность действий; внешняя система не падает, но возвращает данные в неожиданном виде.
Проблема усугубляется тем, что успех ИИ-агента нельзя описать только традиционными инфраструктурными метриками. Низкая загрузка CPU и отсутствие ошибок 500 не означают, что пользователь получил полезный результат. Для агентных систем приходится одновременно наблюдать за задержкой, числом шагов, долей успешных завершений сценария, сбоями вызова инструментов, стоимостью выполнения и качеством результата. Последний параметр особенно неудобен для эксплуатации: нельзя поставить один универсальный порог и считать задачу решённой. Агент может технически вернуть ответ быстро, но ответить не на тот вопрос или выполнить действие, которого от него не ждали.
Отсюда следует практический вывод: ответственность за ИИ-агентов нельзя оставлять в виде расплывчатого «это зона AI-команды». Для каждого агентного сценария нужен назначенный сервисный владелец — команда или роль, которая отвечает за работу функции для пользователя, а не только за конкретную библиотеку или модель. У этого владельца должны быть понятные контакты для эскалации, границы допустимого поведения и право остановить автоматизацию. Иначе дежурный инженер ночью будет не устранять инцидент, а выяснять, в какой Slack-канал писать.
Полезно заранее разделить хотя бы четыре типа сбоев. Первый — инфраструктурный: недоступна сеть, очередь, база или сам сервис. Второй — интеграционный: агент не может вызвать нужный инструмент либо получает некорректный ответ. Третий — поведенческий: система выполняет лишние шаги, зацикливается, нарушает ограничения сценария. Четвёртый — продуктовый: агент работает штатно с точки зрения логов, но перестаёт решать пользовательскую задачу. Для каждого типа нужны свои алерты, ответственный контур и заранее согласованное действие: повторить запрос, переключиться на упрощённый сценарий, отключить инструмент, передать задачу человеку или временно выключить агента.
Для бизнеса это вопрос не только надёжности, но и доверия. Пока агент предлагает подсказки в интерфейсе, цена ошибки может быть терпимой. Когда он получает доступ к внутренним системам, запускает процессы, работает с клиентскими данными или выполняет операции от имени сотрудника, отсутствие владельца превращается в управленческий риск. Нельзя всерьёз говорить об автономности, если в момент сбоя никто не уполномочен определить: агент продолжает действовать, переходит в безопасный режим или немедленно останавливается.
Командам, которые уже выводят агентов в продакшен, стоит включить в запуск не только тестирование промптов и оценку качества, но и операционную часть: карту зависимостей, журнал действий, лимиты на число шагов и расходы, ручной выключатель, процедуру разбора инцидентов. Ответственность за ИИ-агентов должна быть видна в той же степени, что и ответственность за платежный сервис или критичный API. Главный открытый вопрос теперь не в том, смогут ли агенты выполнять больше задач, а в том, успеют ли компании построить для них понятную эксплуатационную модель до первого ночного инцидента.