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

Понедельник начинается не с автономности

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

Но у рабочего процесса другие вопросы. Из какой системы агент получил сведения о клиенте? Может ли он только читать карточку или ещё и менять её? Кто разрешил отправить сообщение? Что произойдёт, если в обращении не хватает данных, API не отвечает или модель неверно поняла исключение? Где увидеть последовательность действий и кто остановит её до необратимого шага?

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

Интерес к теме при этом реален. В Wordstat показы фразы «ИИ агенты для бизнеса» выросли со 148 до 249 в неделю за 13 полных недель выбранного интервала. Ряд колеблется, а показы не равны людям и не прогнозируют трафик. Тем не менее запрос всё чаще формулируют не как любопытство к модели, а через создание, разработку и внедрение.

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

Где заканчивается чат

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

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

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

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

1. Ограниченную цель. Не «заниматься сервисом», а, например, классифицировать входящее обращение и подготовить карточку для подтверждения сотрудником.
2. Инструменты. Читать конкретные источники и выполнять только перечисленные действия.
3. Состояние. Помнить, что уже проверено, что изменено и почему задача остановилась.
4. Границы исполнения. Передавать человеку исключения, не превышать права и завершать работу по явному условию.

Если модель только отвечает, это чат-помощник. Если она действует через инструменты, возникает агентный сценарий. Если у сценария есть владелец, метрика, журнал, лимиты, эскалация и остановка, он становится управляемым процессом.

Четыре уровня зрелости

Лестница ниже — методика НТА для разговора о конкретном сценарии, а не национальный стандарт и не рейтинг платформ.

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

Национальный ГОСТ Р ИСО/МЭК 42001-2024 рассматривает ИИ не как разовый эксперимент, а как объект системы менеджмента, которую создают, внедряют, поддерживают и постоянно улучшают. ГОСТ Р 59276-2020 связывает доверие к прикладной системе ИИ с подтверждением качества на стадиях создания и эксплуатации. Для бизнеса из этого следует простой вывод: доверие нельзя выдать модели один раз после удачной демонстрации. Его подтверждают в конкретной операции и пересматривают по данным.

Паспорт управляемого агентного сценария

До выбора платформы заполните паспорт одной операции. Если ответ остаётся общим, сценарий ещё не готов к делегированию.

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

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

Если сценарий обрабатывает персональные данные, название «агент» не отменяет обязанностей оператора. Статья 19 Федерального закона № 152-ФЗ требует правовых, организационных и технических мер защиты, определения угроз и контроля принятых мер. Конкретные основания обработки, состав данных, архитектуру и меры нужно проверять для отдельной компании; эта статья не заменяет правовое заключение.

Как выбрать первый процесс

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

Подходящий сценарий обычно сочетает пять признаков:

1. Вход неоднороден, но результат проверяем. Например, нужно извлечь сведения из свободного текста и разложить их по известным полям.
2. Граница узкая. Один тип обращения, одна роль, один набор инструментов и понятный момент завершения.
3. Действие обратимо. Черновик или метку можно проверить и исправить до внешнего последствия.
4. Исключения видны. Команда знает случаи, которые нельзя решать автоматически, и кому их передавать.
5. Есть базовая линия. До запуска измерены время, качество, доля возвратов, ручные касания и цена ошибки.

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

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

Что измерять до расширения

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

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

Добровольная рамка NIST AI RMF группирует работу с рисками вокруг функций Govern, Map, Measure и Manage, отдельно требует определять человеческий надзор и тестировать систему до запуска и в эксплуатации. Это американская методика, а не обязательное правило для России. Но её процессная логика переносима: сначала описать контекст и допуски, затем измерить поведение, управлять риском и пересматривать решение.

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

Где здесь НТА

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

НТА соединяет эту задачу с обследованием процессов, системным анализом и корпоративной разработкой. Для детерминированной части маршрута может быть уместна low-code-среда, например BPMSoft Конструктор; для неоднозначного шага — модель с ограниченными инструментами; для высокого риска — явное подтверждение ответственной роли. Технологии выбираются после границы процесса, а не вместо неё.

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

Тест понедельником

На ближайшем рабочем совещании возьмите один кандидат и за десять минут запишите четыре ответа:

1. Какой измеримый результат агент должен оставить в системе?
2. Какое одно действие ему разрешено без человека?
3. Какой порог или тип исключения немедленно передаёт работу сотруднику?
4. Какой сигнал останавливает сценарий целиком?

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

Важное уведомление

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