Здравствуй, Хабр!

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

И вот, когда индекс ИИ‑хайпа от @anti_agi вышел на плато, а Билл Гейтс сообщает нам, что мы не готовы к эпохе ИИ — по‑моему, самое время это сделать!

В последнее из 20+ лет в индустрии время я занимаюсь сравнительно узкой предметной областью автоматизации: «проектное управление». И в этой же области имею теперь еще и практический опыт внедрения ИИ‑агентов. Но, как мне кажется, то, о чем я здесь пишу, может быть одинаково применимо к любой бизнес задаче, в которой ИИ‑агенты могут быть полезны на корпоративном уровне, а не только индивидуальном.

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

Надо ли вам это читать?

Этот текст, насколько я могу судить, несколько отличается от принятого на Хабре по стилю изложения и по характеру подачи.

Здесь не будет ни слова о «кодинг‑агентах», не будет ссылок на github и на мои пет‑проекты, не будет мемных картинок (увы!).

Зато будет много букв и много ссылок на материалы, которые подтверждают или опровергают написанное мной. И эти материалы, в идеале, надо бы тоже глянуть, если хотите разобраться в вопросе поглубже. Возможно, это просто привычка, которая осталась со мной еще со времен защиты кандидатской, и в современных условиях она не так уж и нужна — ведь любой может «загуглить» или «спросить у клода». Но мой опыт говорит, что в инфопузыре ИИ‑агентизации очень много того, что называется agent‑washing. Мне пришлось даже завести отдельного агента, который собирает ежедневные, еженедельные и ежемесячные сводки происходящего, отделяя «зерна от плевел», и ведет специфическую базу знаний по этой теме. Так вот — ссылки здесь будут на материалы, которые прошли через такое информационное сито и базу знаний попали.

Если материал «зайдет», и его не заминусуют сильно, то у меня в планах опубликовать на площадке еще две части триптиха:

— Особенности ИИ‑агентов в управлении проектной деятельностью. И когда в них вообще есть смысл.

— Как внедрять ИИ‑агентов в команде управления проектом. «Грабли», «Костыли» и «Велосипеды».

О терминах не спорят, и не договариваются — их «вытягивают по жребию»

Давно где‑то услышал (и внутренне согласился), что расхожая фраза «О терминах не спорят, о них договариваются» — вроде бы конструктивна и мудра, но по‑факту ведет к тому же спору только уже в рамках договаривания. А с высоты прожитых лет можно прийти к тому, что о терминах не нужно даже договариваться, их надо просто брать — и обсуждать уже исходя из того, что «вытянули по жребию».

Поэтому вот нам с вами термины:

В индустрии термин «ИИ‑агент» применяется настолько широко, что под ним могут скрываться поисковая система, чат‑бот, аналитический помощник, заранее заданный процесс с языковой моделью и действительно автономная система. А определение «агент это LLM+harness» — понятно техногикам (к коим и себя отношу) и не понятен больше никому.

Для понимания агентности полезно различать режимы самостоятельности «решений» ИИ‑агентов:

1. Ответ. Система формирует текст или находит информацию, но не участвует в выполнении процесса.

2. Контекстная помощь. Система использует корпоративные документы и данные, готовит справку, документ или расчет.

3. Рекомендация. Система анализирует ситуацию и предлагает решение или действие, которое подтверждает человек.

4. Исполнение. Система выбирает и выполняет разрешенные действия в корпоративных системах, обращаясь к человеку только в предусмотренных случаях.

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

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

В дальнейшем под агентной автоматизацией будет пониматься класс решений, где часть процесса делегируется ИИ‑агенту. Под агентной системой — конкретная реализация бизнес‑процесса с участием ИИ‑агента. Под агентизацией (внедрением ИИ‑агентов) — организационная практика внедрения такой системы.

Агентизация vs автоматизация

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

— ERP, CRM, ECM, BPM и учетными системами;

— витринами и семантическими моделями данных;

— API и интеграционной платформой;

— RPA‑роботами, выполняющими операции в системах без API;

— базами знаний и формализованными регламентами;

— механизмами идентификации, разграничения доступа и аудита.

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

Если процесс не определен, данные противоречивы, а полномочия сотрудников неясны, агент не устраняет эти проблемы. Он начинает воспроизводить их с большей скоростью и меньшей предсказуемостью. В довольно свежем исследовании «Инфосистемы Джет» и Smart Ranking 44% опрошенных компаний связали отказ от агентных решений именно с незрелостью процессов, данных и интеграций. В исследовании участвовали 52 крупные компании, поэтому результаты следует считать индикатором состояния крупного бизнеса, а не всего рынка. Кроме того, исследование проведено при участии интегратора — и это тоже надо учитывать.

Агентизация vs оргизменения

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

— кто делегирует системе решение;

— кто подтверждает действия;

— кто отвечает перед клиентом или регулятором;

— кто получает поток исключений;

— кто обновляет регламент, которым пользуется агент;

— кто может скрыто переложить на коллег проверку результатов;

— кто получает выгоду от сокращения труда, а кто — дополнительную нагрузку по контролю работы агентов.

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

Обучение также меняется. Сотрудник должен знать, когда использовать агента, как проверить основания, какие признаки указывают на ненадежность, когда отказаться от рекомендации и как сообщить об ошибке. В случае с ИИ‑агентами показывает эффективность подход «learning by doing».

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

Глобальные опросы подтверждают разрыв между распространением ИИ и доказанным результатом. По данным McKinsey за 2026 год, 40% крупных организаций сообщили о масштабировании агентов против 27% годом ранее, но только 37% всех респондентов связывали с ИИ хотя бы некоторое влияние на EBIT; доля компаний с существенным эффектом оставалась около 6%. Примерно для каждой пятой организации операционные расходы на ИИ уже ограничивали использование.

В отдельном исследовании McKinsey примерно 30% организаций достигли третьего или более высокого уровня зрелости в стратегии, управлении и контроле агентного ИИ; безопасность и риск были названы главным препятствием масштабированию.

Три проекта в одном

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

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

Агент как договор о делегировании

Управлять агентной системой продуктивнее не как еще одним приложением, а как договором о делегировании. В таком договоре должны быть определены:

— задача и допустимые цели;

— источники, которым разрешено доверять;

— доступные инструменты;

— действия, которые агент может выполнять самостоятельно;

— действия, требующие подтверждения;

— запреты;

— условия отказа от ответа;

— правила эскалации;

— доказательства, сохраняемые для последующего аудита;

— ответственный за результат.

Хороший договор о делегировании следует пяти принципам:

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

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

Зрелые внедрения строят проверяемую среду

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

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

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

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

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

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

После запуска система не становится стабильной

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

— поставщик обновляет модель (иногда без уведомления, как это было недавно с GLM);

— меняются правила модерации и формат ответов;

— обновляются промпты, скиллы и инструменты;

— изменяются базы знаний и корпоративные регламенты;

— накапливается, загрязняется или даже «заражается» память;

— меняется реальный поток задач.

Практический проект агента, анализировавшего производственные журналы небольшой команды, хорошо демонстрирует эксплуатационную сторону проблемы. За 135 дней существования он не работал как минимум 30 дней; два отдельных простоя продолжались 19 и 11 дней. Даже ежедневная проверка работоспособности завершалась ошибкой в 37% случаев. При смене моделей и ошибках прокси поведение системы менялось. При этом агент имел доступ только на чтение и обслуживал небольшой контур из трех человек. Это не основание для статистического обобщения. Его значение в другом: агенту нужен собственный «пульс» работоспособности, а молчание системы должно интерпретироваться как наблюдаемое состояние, а не как отсутствие проблем.

Замена модели, существенное изменение скиллов, инструментов или базы знаний должны запускать повторную приемку.

Человеческий контроль может оказаться фикцией

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

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

Если сотруднику ежедневно направляют сотни предложений и оценивают его по скорости закрытия очереди, организация сама создает стимул подтверждать их механически. Формальная кнопка «одобрить» не приводит, увы, к содержательному контролю.

Контроль следует проектировать как работу:

— показывать исходные и предлагаемые значения;

— приводить основание и ссылку на регламент;

— выделять неопределенность и исключения;

— давать реальную возможность отказаться;

— выборочно проверять решения после выполнения;

— измерять не число подтверждений, а качество проверки.

Меры обеспечения безопасности определяются радиусом возможных последствий

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

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

Ключевой вопрос при внедрении ИИ‑агентов звучит так: что самое опасное сможет сделать агент, если будет введен в заблуждение? Ответ определяет радиус последствий и, соответственно, мер по обеспечению безопасности.

OWASP Top 10 for Agentic Applications выделяют, среди прочего, перехват цели агента, неправильное использование инструментов, злоупотребление полномочиями и учетными данными, а также отравление памяти и контекста.

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

— минимальные полномочия;

— разделение чтения и изменения данных;

— краткоживущие учетные данные;

— отдельное подтверждение необратимых действий;

— промежуточная запись предложения перед применением;

— лимиты на сумму, количество и частоту операций;

— полная трассировка вызовов;

— аварийное отключение;

— безопасный ручной маршрут при отказе.

Автономность следует выдавать поэтапно

Разумная траектория внедрения ИИ‑агентов состоит из последовательных режимов для каждого выделенного процесса.

Переход между режимами — это всегда должно быть осознанное управленческое решение.

В качестве критериев перехода можно использовать:

— класс обратимости действия;

— стоимость ошибки;

— долю исключений;

— долю обоснованных отказов агента;

— совпадение результатов повторных прогонов;

— число критических ошибок;

— работоспособность мониторинга;

— проверенный сценарий отката;

— решение владельцев процесса, агента на основе анализа рисков.

В примере Directum договоры на сумму до 1 млн рублей могут проходить по более автономному маршруту, а договоры свыше лимита передаются человеку. Заявлены сокращение первичной проверки с 30 до 5 минут, экономия около 4,8 млн рублей в год и точность 95%. Но это материал вендора об анонимном заказчике; методика расчета точности и границы измеренной выборки не раскрыты. Кроме того, последовательность действий заранее задана, поэтому решение можно рассматривать как управляемый процесс с языковой обработкой, а не как свободно планирующего агента.

У Zones система показывает проверяющему текущее и предлагаемое значение вместе с фрагментом регламента. При низкой уверенности рекомендация не формируется. Заявлены почти 90% точности рекомендаций, сокращение проверки на 50%, около 20 тыс. часов потенциальной автоматизации, из которых примерно 14 тыс. ожидается реализовать, и срок окупаемости 17 месяцев. Почти 90% означают, что приблизительно каждая десятая рекомендация может быть неверной. Учтем также, что это «история успеха» подрядчика, а часть показателей является прогнозом.

Готовность данных определяет границу возможностей

Успешные примеры агентизации объединяет не столько выбор модели, сколько предварительно подготовленная среда.

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

Пример 1Forma показывает ту же закономерность с другой стороны. Языковая модель там не вычисляет финансовый результат сама, а переводит вопрос пользователя в параметры строго определенного аналитического инструмента. На реальной инсталляции с более чем 5 тыс. пользователей авторы проверили три сценария; ответы занимали 26–38 секунд и требовали три‑четыре попытки вызова инструментов. Результаты были сверены с SQL. Это полезное подтверждение архитектурного принципа, хотя три сценария, конечно, не доказывают способность отвечать на произвольные финансовые вопросы.

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

Экономика агентов не строится только на стоимости инференса

Стоимость классической автоматизации часто оценивается через сокращение времени операции и высвобождение трудозатрат. Для агента такой расчет неполон.

Необходимо учитывать:

— разработку и обновление наборов испытаний;

— проверку результатов людьми;

— ручную обработку исключений;

— стоимость моделей и инструментов;

— наблюдаемость и расследование инцидентов;

— повторную приемку после изменений;

— простой внешних поставщиков;

— исправление неверно выполненных действий;

— дополнительную нагрузку на владельцев знаний и регламентов.

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

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

То же самое исследование от Инфосистемы Джет сообщает, что полуавтономные агенты находились в промышленной эксплуатации у 15% опрошенных компаний, автономные и мультиагентные системы — у 8%. При этом 46% не видели устойчивого экономического эффекта.

Gartner прогнозирует прекращение более 40% проектов агентного ИИ к концу 2027 года из‑за роста затрат, неясной ценности и недостаточного контроля риска. Это прогноз аналитической компании, а не наблюдаемый результат, но он точно формулирует критерии, которые обязательно надо проверять до масштабирования и тиражирования. Gartner также предупреждает об «agent washing» — переименовании ассистентов, чат‑ботов и RPA в агентов без появления содержательной автономности.

Выводы

Практика и доказательная база по внедрению ИИ‑агентов весьма неоднородна. Лабораторный тест, опрос менеджеров и рассказы вендоров — это данные разного уровня качества.

Внедрение ИИ‑агентов не отменяет ни классическую автоматизацию, ни управление организационными изменениями. Добавляется третья дисциплина: управление агентами.

Звучит как усложнение, но это неизбежная «плата» за те эффекты для бизнеса, которые действительно можно получить от агентизации.

Итак, зрелый проект внедрения должен одновременно:

— построить надежную информационную систему;

— изменить роли, стимулы и способы работы людей;

— определить, настроить и регулярно пересматривать допустимую самостоятельность агентов.

Частая ошибка состоит не в том, чтобы относиться к агенту как только к программному обеспечению ( он действительно является программным обеспечением). Ошибка в проекте внедрения — когда ограничиваются только этой перспективой и не замечают, что «программному обеспечению» передается право выбирать действие в условиях неполной определенности.

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

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