AI-агенты - не автоматизация: что должно быть до запуска программных агентов
Традиционная автоматизация следует инструкциям.
Когда отправлена форма - создать запись в CRM. Когда оплачен счёт - обновить статус аккаунта. Когда контракт достигает даты продления - уведомить аккаунт-менеджера.
AI-агент работает иначе.
Он может интерпретировать цель, решать, какая информация ему нужна, выбирать инструменты, определять последовательность действий, оценивать промежуточные результаты и менять подход до завершения задачи.
Эта разница звучит технически. На самом деле она операционная.
В тот момент, когда ПО может решать, как выполнить задачу, а не просто исполнить предопределённый шаг, компания должна ответить на новый набор вопросов: что агент имеет право решать? К каким системам он имеет доступ? Какие действия требуют согласования? Что происходит при неполной информации? Кто отвечает за результат? Как можно отменить некорректное действие?
Агент - не просто более умная версия Zapier.
Это новый участник операционной модели.
Прежде чем позволить AI-агенту действовать внутри бизнес-процесса, должны существовать восемь условий: процесс понятен; человек-владелец несёт ответственность за результат; необходимые данные доступны и достаточно надёжны; разрешения ограничены минимально необходимым; границы решений явно определены; действия с высоким влиянием требуют согласования; действия и сбои логируются; и компания может остановить и отменить работу агента.
Если несколько из этих условий отсутствуют, ближайшая задача - не разработка агента.
Это исправление процессов и систем.
Автоматизация, копайлоты, рабочие процессы и агенты - это не одно и то же
Рынок использует термин "AI-агент" почти для каждого рабочего процесса с языковой моделью. Это делает архитектурные решения сложнее, чем нужно.
Anthropic разделяет рабочие процессы, где модели и инструменты следуют предопределённым путям выполнения, и агентов, где модель динамически управляет собственным процессом и использованием инструментов. Компания также рекомендует начинать с простейшей архитектуры, способной надёжно решить проблему, а не добавлять автономию по умолчанию. (Anthropic)
Практическое бизнес-разграничение выглядит так:
| Тип системы | Как работает | Пример | Операционный риск |
|---|---|---|---|
| Автоматизация на основе правил | Выполняет фиксированные правила | Создать задачу после смены стадии сделки | Низкий при корректных правилах |
| Копайлот | Формирует рекомендацию или черновик | Подготовить ответ клиенту | Человек остаётся ответственным |
| LLM-процесс | Использует AI внутри предопределённой последовательности | Классифицировать запрос, подготовить ответ, направить на проверку | Умеренный и относительно отслеживаемый |
| AI-агент | Динамически выбирает действия и инструменты | Исследовать аккаунт и определить следующее действие | Выше, так как поведение может варьироваться |
| Мультиагентная система | Несколько агентов делегируют или координируют задачи | Исследование, анализ, проверка на соответствие и исполнение | Максимальная сложность координации и доверия |
Это разграничение важно, потому что каждый шаг к автономии увеличивает число возможных путей выполнения.
Фиксированный рабочий процесс может дать сбой в трёх предсказуемых местах.
Агент может дать сбой при интерпретации, планировании, извлечении данных, выборе инструмента, генерации аргументов, обработке разрешений, верификации, повторных попытках, эскалации или выполнении.
Больше автономии создаёт больше потенциальной ценности - но и больше способов ошибиться.
Самая распространённая ошибка: передать агенту неясный процесс
Представьте компанию, которая хочет, чтобы агент квалифицировал входящие лиды.
Запрошенный рабочий процесс звучит просто:
Рассмотреть каждый лид, определить, квалифицирован ли он, обновить CRM и подготовить следующую коммуникацию.
Но исследование выявляет: маркетинг и продажи используют разные определения квалифицированного лида; несколько полей CRM необязательны или устарели; правила владения аккаунтами содержат недокументированные исключения; стратегические лиды обрабатываются иначе; текущий процесс зависит от суждения менеджера по продажам; и никто не измеряет, сколько квалифицированных лидов отклоняется ошибочно.
Агент не может решить эту неоднозначность.
Он превратит неоднозначность в автоматизированную непоследовательность.
Если обучен или настроен на исторических решениях CRM, он также может воспроизвести те же недокументированные привычки, которые создали проблему.
Возможности модели здесь не являются ограничивающим фактором.
The company has not yet defined what a correct decision looks like. This is a form of process debt -and AI does not resolve it. It scales it.
Как выглядит готовность к агентам
Готовность к агентам следует оценивать по восьми взаимосвязанным областям.
Процесс
Текущий рабочий процесс должен быть видимым, прежде чем его можно делегировать.
Документируйте триггер; ожидаемый результат; нормальный путь; типичные исключения; обязательные входные данные; критерии завершения; и зависимости вверх и вниз по потоку.
Процесс не должен быть идеальным. Он должен быть понятным.
Красный флаг: два опытных сотрудника описывают существенно разные версии одного рабочего процесса.
Ответственность
Каждый автоматизированный процесс нуждается в одном ответственном бизнес-владельце.
Этот человек не обязан проверять каждое действие. Он должен владеть: определением успеха; политикой исключений; правилами согласования; проверкой производительности; эскалацией инцидентов; и решениями об изменении или отключении агента.
"IT владеет системой" недостаточно, когда агент выполняет процесс продаж, финансов, HR или обслуживания клиентов.
IT может владеть платформой.
Бизнес-функция владеет результатом.
Данные
Агент должен знать: какие источники являются авторитетными; какие поля обязательны; насколько свежими должны быть данные; как обрабатываются конфликтующие записи; какую информацию агент не должен использовать; и что происходит при отсутствии доказательств.
Предоставление агенту доступа к большему объёму данных не улучшает производительность автоматически.
Доступ к дублированной, устаревшей, противоречивой или не соответствующей разрешениям информации может ухудшить результаты.
Красный флаг: команда не может определить источник истины для основного решения, которое агент должен принимать.
Разрешения
Агент должен получить минимальный доступ, необходимый для его задачи.
Текущие рекомендации OWASP по безопасности агентов подчёркивают минимальные привилегии, изоляцию инструментов и контекстов, человеческое согласование для действий с высоким риском, структурированную валидацию, ограничения выполнения и разделение между принятием решений и необратимыми операциями. (OWASP Cheat Sheet Series)
Не давайте агенту широкие администраторские учётные данные только потому, что сужение разрешений требует дополнительных инженерных усилий.
Вместо этого разделяйте инструменты по возможностям: чтение записи клиента; создание черновика; обновление некритичного поля; запрос согласования; отправка согласованного сообщения; и выдача возврата в рамках определённого лимита.
Агент не должен получать универсальный инструмент с именем manage_customer_account, когда бизнес может предоставить более узкие, проверяемые операции.
Границы решений
Компания должна разграничить: что агент может предполагать; что он может рекомендовать; что он может изменять; что требует подтверждения; и что он не должен делать никогда.
Например, агенту может быть разрешено классифицировать запрос; определять недостающую информацию; рекомендовать следующий шаг; и составлять черновик ответа.
Ему может быть запрещено: изменять условия контракта; одобрять кредит; удалять записи; принимать кадровые решения; отправлять юридически значимые сообщения; и обходить ограничения доступа.
Границы решений должны быть реализованы в инструментах и разрешениях, а не просто записаны в промпте.
Человеческое согласование
"Human-in-the-loop" - это не кнопка.
Компания должна определить, кто проверяет действие; какую информацию видит проверяющий; сколько у него времени; истекает ли срок согласования; требуют ли изменённые параметры нового согласования; что происходит, когда никто не отвечает; и как эскалируются срочные случаи.
Проверяющий, получающий расплывчатое сообщение "Согласовать действие агента?" не осуществляет содержательный контроль.
Интерфейс согласования должен показывать: предлагаемое действие; релевантные доказательства; затрагиваемую запись; существенные последствия; уверенность или неопределённость; и точные параметры, которые будут выполнены.
Логирование и наблюдаемость
Продакшен-агент должен оставлять достаточно данных для восстановления произошедшего.
Полезные записи включают запрос пользователя или системы; версию агента и модели; версию инструкций и политик; извлечённые источники; выбранный инструмент; аргументы инструмента; область разрешений; событие согласования; результат; повторные попытки; ошибки; длительность; расчётную стоимость; и финальный статус.
Агентские платформы всё чаще рассматривают трейсы, журналы выполнения, использование токенов, ошибки и задержки как основные контроли жизненного цикла, а не опциональные средства отладки. (Google Cloud Documentation)
Финальный текстовый ответ - не адекватный аудиторский след.
Откат и остановка
Перед развёртыванием команда должна знать, как приостановить агента; отозвать его учётные данные; остановить активные выполнения; определить затронутые записи; отменить обратимые изменения; изолировать неисправные интеграции; восстановить предыдущий рабочий процесс; и уведомить владельцев процессов.
Аварийная кнопка, требующая от инженера развернуть новый код - не эффективный операционный контроль.
Выбор правильного уровня автономии
Правильный вопрос не в том, нужно ли "автоматизировать процесс с помощью агента".
Правильный вопрос - какой уровень автономии процесс может безопасно поддерживать.
| Уровень | Поведение агента | Подходящее применение |
|---|---|---|
| 1. Рекомендация | Анализирует информацию и предлагает действие | Новые, неоднозначные, высокорисковые или плохо измеряемые процессы |
| 2. Действие после согласования | Подготавливает и выполняет действие только после подтверждения | Повторяемые процессы с существенными, но проверяемыми последствиями |
| 3. Ограниченная автономия | Выполняет самостоятельно в рамках явных ограничений | Стабильные, высокообъёмные, обратимые, измеримые задачи |
A company can begin at Level 1 and increase autonomy only after collecting evidence. Our guide to evaluating an AI agent before production provides a concrete framework for what that evidence should include and how to measure it.
Обычно это безопаснее, чем начинать с широкой автономии и убирать разрешения после инцидента.
Пример: AI-агент для входящих лидов
Допустим, цель - сократить время ответа на лид.
Слабая реализация может дать агенту полный доступ к CRM и электронной почте и попросить его "квалифицировать и контактировать новые лиды".
Более сильная архитектура разделяет рабочий процесс:
- Прочитать новый лид и разрешённые данные CRM
- Проверить наличие обязательной информации
- Применить документированные критерии квалификации
- Определить неопределённость или противоречивые данные
- Присвоить один из трёх исходов: явно неквалифицированный; требует проверки; и вероятно квалифицированный
- Подготовить обновление CRM
- Составить персонализированное письмо
- Запросить согласование перед отправкой
- Записать доказательства, решение и проверяющего
- Эскалировать стратегические или необычные аккаунты
Только после того, как команда продемонстрирует надёжную работу, агент может получить разрешение отправлять сообщения для узкой категории типовых лидов.
Процесс становится более автономным, потому что доказательства оправдывают изменение - а не потому, что вендор модели выпустил новую версию.
Когда агент - неверное решение
Не начинайте с агента, когда:
- Детерминированное правило может решить задачу
- Процесс меняется каждую неделю
- Никто не отвечает за результат
- Исключения обрабатываются через недокументированное суждение
- Необходимые данные недоступны
- Действия нельзя отменить
- Команда не может определить правильный результат
- Ошибки останутся невидимыми
- Ожидаемый объём задач не оправдывает операционные затраты
An agent should earn its complexity. If your company is introducing AI systems at scale, our guide to AI governance for mid-market B2B covers the practical controls needed to manage the full lifecycle.
Фиксированный рабочий процесс часто дешевле, проще для тестирования, безопаснее и легче в обслуживании.
Считайте ценность на уровне завершённой задачи
Не оценивайте экономику агента, используя только стоимость токенов.
Практическая модель:
Годовая ценность = (Объём задач x Сэкономленное время x Полная стоимость труда) + Возвращённая выручка + Избежанная стоимость ошибок
Проверка должна охватывать: операционную стоимость AI; стоимость человеческой проверки; стоимость обслуживания; и ожидаемую стоимость сбоев.
Более дешёвая модель не экономична, когда создаёт больше исправлений, эскалаций, повторных попыток или ошибок, видимых клиентам.
Аналогично, экономия времени сотрудников создаёт ценность только тогда, когда высвобожденная ёмкость используется продуктивно.
Чек-лист готовности к агентам
Перед утверждением разработки ответьте на следующее:
| Вопрос | Если ответ "нет" |
|---|---|
| Может ли команда описать текущий процесс? | Агент автоматизирует неполное понимание |
| Есть ли один ответственный бизнес-владелец? | Сбои станут спором между IT и бизнесом |
| Измерим ли ожидаемый результат? | Производительность нельзя оценить |
| Документированы ли типичные случаи и исключения? | Необычные случаи приведут к непредсказуемым действиям |
| Определены ли авторитетные источники данных? | Агент может действовать на основе устаревшей или противоречивой информации |
| Можно ли ограничить разрешения по инструменту и действию? | Потенциальное влияние сбоя слишком широко |
| Явно ли определены правила согласования? | Человеческий контроль будет непоследовательным |
| Прослеживаемы ли действия? | Сбои нельзя надёжно расследовать |
| Можно ли отменить изменения? | Небольшая ошибка может стать крупным операционным инцидентом |
| Превышает ли ожидаемая ценность полную операционную стоимость? | Агент - это расход на технологии, а не улучшение бизнеса |
К чему сводится решение
AI-агент не должен быть утверждён только потому, что демонстрация выглядела интеллектуальной.
Он должен быть утверждён, когда: процесс понятен; границы обеспечиваемы; данные подходят; экономика убедительна; риск контролируется; и результат измерим.
Самый безопасный первый вопрос не:
Какую агентскую платформу нам купить?
Правильный вопрос:
Какое бизнес-решение мы готовы отдать ПО - и какие доказательства показывают, что мы к этому готовы?
В Fill System наш Консалтинг по AI и автоматизации процессов начинается именно с такой оценки готовности - картирование процесса, определение границ решений и выявление того, что необходимо исправить до безопасной работы агента.
Запросите бесплатную диагностику чтобы выяснить, готовы ли ваши операции к AI-агентам - или что необходимо изменить в первую очередь.
Considering AI agents for your operations?
Запросите бесплатную диагностику и получите четкую картину, что исправить в первую очередь - без обязательств.