Последняя миля AI-агентов: почему после пилота меняется работа всей команды

От эксперимента к production: дело не в одном промпте

Материал Harvard Business Review о том, почему одни AI-агенты доходят до production, а другие остаются демонстрациями, опубликован как спонсорский текст AWS и Arize, а не как независимое исследование редакции HBR. При этом он точно описывает практическую проблему: убедительный прототип собрать проще, чем подтвердить стабильную и безопасную работу агента в реальном бизнес-процессе.

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

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

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

Эти данные не являются аудитом действующих систем и не описывают отдельно российский рынок. Это самоотчёты 1 993 участников из 105 стран, собранные в июне и июле 2025 года. Их нельзя переносить на конкретную страну, отрасль или компанию. Но они указывают на общий паттерн: интерес и пилоты распространяются быстрее, чем практики устойчивой эксплуатации.

В доступном наборе источников нет подтверждённой статистики production-внедрений AI-агентов в России и сопоставимых локальных кейсов. Российский контекст корректнее сводить к адаптации общего контура под конкретную организацию: её учётные системы, модель прав, владельцев процессов и правила работы с данными. Универсального рецепта источники не предлагают.

• 23% опрошенных McKinsey сообщили о масштабировании агентов хотя бы в одной функции.
• 39% сообщили об экспериментах с агентными системами.
• Результаты основаны на самоотчётах, а не на независимой проверке внедрений.

Почему агента нельзя эксплуатировать как обычный чат-бот

Поведение агента зависит не только от модели. На результат влияют системные инструкции, контекст, поиск по базе знаний, описания инструментов, права доступа, состояние внешних API и последовательность уже выполненных шагов. Изменение промпта, модели, поискового индекса или одного инструмента способно повлиять не только на стиль ответа, но и на редкий многошаговый сценарий. Авторы HBR, AWS и Arize называют разрыв между удачным демо и надёжностью verification gap.

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

Главный организационный вопрос заключается в том, советует система или действует самостоятельно. В рекомендательном сценарии сотрудник может принять, исправить либо отклонить результат. Если агент меняет внешнюю систему, необходимы чёткие границы: перечень разрешённых действий, условия подтверждения человеком, правила эскалации и возможность остановить выполнение. Контроль должен зависеть от последствий конкретного действия, а не от самого факта использования ИИ.

• На поведение агента влияют модель, данные, инструменты, права и интеграции.
• Трассировка помогает отличить ошибку модели от сбоя API, проблемного документа или неверной настройки инструмента.
• Чем выше автономия в корпоративных системах, тем существеннее границы действий и эскалация человеку.

Цитата в переводе

«Традиционное ПО детерминировано: одинаковый вход, одинаковый выход, одинаковый путь в коде. Агенты так не работают.»

Продакт и владелец процесса: превратить идею в контракт задачи

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

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

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

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

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

Инжиниринг: от настройки промпта к управляемому контуру

У инженерной команды появляется набор задач, который можно условно назвать Agent DevOps. Это не обязательно отдельная должность или новый отдел. Агентную систему нужно выпускать и сопровождать как изменяемый программный продукт, а не как разовую конфигурацию промпта. Microsoft описывает такой контур через трассировки, оценки, мониторинг и использование production-сигналов для улучшений.

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

Второй слой связан с оценкой поведения. Вместо нескольких удачных демонстраций нужны наборы типовых, редких, конфликтных и уже проваленных сценариев. Там, где требования можно формализовать, проверяют схему результата, заполнение полей или обращение только к разрешённому инструменту. Для смысловой оценки остаются экспертная выборка и осторожное применение модельных оценщиков. HBR, AWS и Arize рекомендуют сочетать эти уровни и не считать LLM-оценку окончательным арбитром.

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

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

• Трассировки связывают запрос, модель, поиск, tool calls и ошибки.
• Регрессионные eval-наборы должны включать исторические и production-сценарии.
• Версионируется вся конфигурация агента, а не только приложение.
• Права и интерфейсы интеграций определяют фактическую границу автономии.

Операции и SRE: мониторить доступность и качество поведения

Для SRE и операционных команд привычны показатели доступности, задержек и ошибок API. У агента сервис может оставаться технически доступным, но выбирать неуместный инструмент, повторять действие, слишком часто передавать работу человеку или расходовать больше ресурсов на одну операцию. Поэтому мониторинг дополняют сигналами о завершении задач, эскалациях, отменах, ошибках инструментов, стоимости и соблюдении политик.

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

Отдельной операционной функцией становится работа с исключениями. Кто-то должен принять эскалацию, проверить спорное действие, отменить ошибочный результат и передать проблему инженерам или владельцу процесса. Если такой маршрут не назначен, автономия агента переносит риск на сотрудника, который случайно заметит проблему. До запуска необходимы playbook, аварийная остановка и откат версии. Они не исключают ошибок, но задают порядок реакции.

Microsoft в собственном кейсе описывает инвентаризацию агентов, телеметрию поведения и действий, а также показатели соответствия правилам и времени устранения несоответствий. Это самоописание Customer Zero, а не независимый отраслевой стандарт. Однако оно показывает, как governance становится регулярной операционной задачей.

• Доступность сервиса не равна корректности поведения агента.
• Нужны владельцы очереди исключений, эскалаций и инцидентов.
• Разбор инцидента должен приводить к изменению теста, данных, правила или конфигурации.

ИБ и governance: контролировать всю цепочку действия

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

Практичный контраргумент к идее максимального контроля состоит в том, что одинаково тяжёлые требования для всех сценариев могут замедлить полезные низкорисковые эксперименты. Microsoft описывает риск-ориентированную модель: поиск знаний и low-code сценарии могут допускать более широкий доступ, тогда как агенты, работающие через несколько внутренних и внешних систем, требуют более строгого управления. Это не универсальная классификация, а пример соразмерности контроля последствиям.

У ИБ, privacy и compliance появляются дополнительные задачи: моделирование угроз для агентной цепочки, проверка минимальных привилегий, тестирование попыток обойти правила, аудит действий и расследование инцидентов. Часть этой работы близка к DevSecOps. Однако агент добавляет смысловой выбор и выбор инструмента, поэтому контролировать приходится как инфраструктуру, так и правила, по которым система действует.

• Агенту нужны отдельная идентичность и минимальные привилегии.
• Контролировать следует разрешённые tool calls и их параметры.
• Уровень контроля должен зависеть от последствий действия, а не от названия технологии.

Кейс AGCO: при масштабе появляются отбор и сопровождение

В клиентской истории Microsoft компания AGCO сообщает, что более 900 сотрудников добровольно вызвались создавать агентов. Компания также заявляет о нескольких сотнях enterprise-агентов в production и ещё нескольких сотнях решений в когортах, где они консолидируются и оптимизируются для корпоративного использования. Это пример перехода от разрозненной разработки сотрудниками к управляемому портфелю. Однако источник представляет собой совместную историю клиента и вендора, а не независимый аудит масштаба или эффекта.

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

AGCO и Microsoft также заявляют, что в quality-процессах агентные решения читают, валидируют и передают информацию о проблемах качества, а отдельные проверки сократились с недель примерно до часа. Методика измерения, база сравнения и независимая проверка в материале не раскрыты. Поэтому это заявление компаний, а не доказанный универсальный эффект.

• Более 900 сотрудников AGCO добровольно вызвались создавать агентов, по данным customer story.
• AGCO и Microsoft заявляют о нескольких сотнях enterprise-агентов в production.
• Кейс показывает организационный пример, но не заменяет независимую оценку результатов.

Цитата в переводе

«Речь не об экспериментах с ИИ ради самого ИИ, а о применении там, где он важнее всего.»

Новые компетенции: не одна профессия, а новые пакеты задач

Доступные источники не доказывают появление одной массовой универсальной профессии для управления AI-агентами. Корректнее говорить о перераспределении задач между существующими ролями. Конкретная схема будет различаться у крупной регулируемой компании, производственного предприятия и небольшой сервисной команды.

В product management растёт значение проектирования границ автономии, участия человека и критериев приёмки. В software, ML и data engineering востребованы оценка поведения, трассировки, безопасные интеграции, версионирование и релизные гейты. В операциях это обработка исключений, проверка спорных результатов и сопровождение эскалаций. В ИБ и governance это аудит действий, политики доступа и моделирование угроз. Речь не о перечне новых вакансий, а о карте задач, следующей из production-практик.

World Economic Forum относит AI, big data и cybersecurity к быстрорастущим навыкам; 85% опрошенных работодателей ожидают использовать upskilling в 2025–2030 годах. Это прогноз намерений работодателей, а не доказательство того, что именно агенты создадут определённое число рабочих мест. Опрос WEF основан на 1 043 ответах компаний из 55 экономик и 22 отраслевых кластеров.

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

• Не подтверждено появление одной универсальной массовой роли менеджера AI-агентов.
• Подтверждаемый сдвиг задач: больше оценки, контроля интеграций, управления исключениями и AI-risk практик.
• 85% опрошенных WEF работодателей ожидают применять upskilling в 2025–2030 годах.

Как отличить управляемое внедрение от пилота

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

Полный контур оценок, мониторинга и governance не устраняет ошибки и не гарантирует окупаемость. Он не отменяет недетерминированность модели и не делает модельного оценщика безошибочным. Но без такого контура компании труднее объяснить, ограничить и исправить сбой. Рациональная цель состоит в контроле, соразмерном последствиям действий агента, а не в максимальном числе согласований.

• Разделяйте рекомендательные сценарии и автономные действия.
• Проверяйте сценарии до релиза, а не только удачные демонстрационные примеры.
• Назначайте владельца инцидента, процедуру отката и путь эскалации.

Что это означает на практике

Ниже приведён чек-лист для команды, которая оценивает готовность агента к переходу из пилота в управляемую эксплуатацию.

Чек-лист готовности AI-агента к production

Сохраняемая версия чек-листа подготовлена отдельным PDF-файлом для скачивания.

Контракт задачи и автономия

Перед релизом команда должна договориться не о том, насколько убедительно выглядит демо, а о допустимом поведении системы в конкретном процессе.

• Определите результат задачи и цену ошибки.
• Разделите рекомендательные сценарии и автономные действия.
• Зафиксируйте запрещённые действия и действия, требующие подтверждения человека.
• Назначьте владельца процесса и владельца очереди исключений.

Инженерный и операционный контур

Техническая доступность агента не заменяет контроля за качеством его действий.

• Версионируйте модель, промпты, инструменты, данные и policy-конфигурацию.
• Соберите набор типовых, редких, конфликтных и уже проваленных сценариев.
• Настройте трассировки запросов, вызовов модели, поиска, инструментов и ошибок.
• Проверяйте новую конфигурацию относительно стабильной до выпуска.
• Определите playbook, аварийную остановку и порядок отката версии.

Доступы, исключения и улучшения

Граница автономии определяется не названием технологии, а конкретными правами и последствиями действий.

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

Вывод

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

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

В production ценится не только умение пользоваться LLM, но и способность сделать автоматизацию проверяемой, безопасной и понятной тем, кто отвечает за результат перед клиентом и бизнесом.

Источники

• Microsoft Foundry: Build 2026: From observability to ROI for AI agents on any framework
• Microsoft Customer Story: AGCO Corp.
• McKinsey: The State of AI
• Harvard Business Review: What Separates AI Agents That Ship to Production from Those That Don't
• Microsoft Inside Track: Governing AI agents at scale: Lessons from our journey at Microsoft
• World Economic Forum: Future of Jobs Report 2025: 78 million new job opportunities by 2030, but urgent upskilling needed to prepare workforces

Практический чек-лист

Чек-лист готовности AI-агента к production

PDF-версия чек-листа предназначена для сохранения и обсуждения на встрече продуктовой, инженерной, операционной и ИБ-команд.

Контракт задачи и автономия

• Определите результат задачи и цену ошибки.
• Разделите рекомендательные сценарии и автономные действия.
• Зафиксируйте запрещённые действия и действия, требующие подтверждения человека.
• Назначьте владельца процесса и владельца очереди исключений.

Инженерный и операционный контур

• Версионируйте модель, промпты, инструменты, данные и policy-конфигурацию.
• Соберите набор типовых, редких, конфликтных и уже проваленных сценариев.
• Настройте трассировки запросов, вызовов модели, поиска, инструментов и ошибок.
• Проверяйте новую конфигурацию относительно стабильной до выпуска.
• Определите playbook, аварийную остановку и порядок отката версии.

Доступы, исключения и улучшения

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