AI-агенты в enterprise: где кончается автономия

В 2024–2025 годах крупные вендоры — OpenAI, Anthropic, Google, Microsoft — сместили риторику от «чат-бота, который отвечает на вопросы» к «агенту, который выполняет задачи». Anthropic выпустил Claude с поддержкой инструментов и Model Context Protocol, OpenAI показал Operator и Agents SDK, Microsoft встроил автономных агентов в Copilot Studio. Обещание одно: агент сам планирует шаги, вызывает API, правит код, отправляет письма. Для enterprise это упирается в один вопрос — сколько свободы дать системе, которая иногда уверенно ошибается.

Что значит «автономия» на практике

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

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

Принято выделять уровни вовлечения человека:

• Human-in-the-loop — человек утверждает каждое значимое действие до его выполнения.
• Human-on-the-loop — агент действует сам, человек наблюдает и может вмешаться или откатить.
• Human-out-of-the-loop — полная автономия, человек видит только итог и метрики.

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

Цена вопроса: чем платят за лишнюю свободу

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

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

Где автономия оправдана, а где нет

Простое правило: чем обратимее действие и дешевле откат, тем больше свободы можно отдать. Ключевой критерий — обратимость, а не сложность задачи.

Кандидаты на высокую автономию

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

Где нужен человек в цикле

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

Как удержать контроль технически

Контроль над автономным агентом — это не «доверять или нет», а набор ограничений, которые вы задаёте заранее. Ниже — практический порядок, в котором их стоит выстраивать.

1. Определите границы полномочий. Агент получает не «доступ к системе», а конкретный набор инструментов с узкими правами. Read-only там, где не нужна запись.
2. Введите список действий, требующих подтверждения. Всё, что необратимо или стоит денег, идёт через человека — по умолчанию, а не по исключению.
3. Поставьте лимиты и бюджеты. Максимум шагов на задачу, потолок расхода токенов, лимит на сумму операции. При превышении — остановка, а не тихое продолжение.
4. Логируйте всю цепочку. Не только результат, но и промежуточные вызовы инструментов и решения. Без этого расследовать инцидент невозможно.
5. Изолируйте среду. Sandbox^*, отдельные тестовые ключи, доступ к реальным данным только на финальном шаге под контролем.
6. Заложите откат. Каждое автономное действие должно иметь понятный способ отмены — иначе это не автономия, а рулетка.

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

Организационная сторона

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

Практика, которую стоит закрепить до запуска:

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

Итог

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