ИИ-агенты в бизнес-операциях: где они работают, а где тихо терпят неудачу

Основная идея

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

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

Что изменилось и почему это сейчас важно

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

Построение операционной модели

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

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

Измерение результата решения

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

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

Где срывается исполнение

Основная ошибка — агент с большой свободой действий без ответственного, который выдаёт правдоподобный, но непроверенный результат, а ошибки проявляются лишь при крупном сбое.

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

Как это выглядит на практике

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

Главный контраргумент

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

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

30-дневная последовательность внедрения

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

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

Ведите журнал решений, а не панель мониторинга

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

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

Редакционный вывод

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