Карта автономии AI: как решить, что агенту можно делать без человека

Привет! Я Андрей Непряхин — директор департамента разработки в AGIMA.

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

Самая опасная мысль на встрече про AI-агента обычно звучит вполне разумно: он уже неплохо отвечает, пора дать ему действовать самому. Именно в этом месте обсуждение качества модели подменяет обсуждение полномочий системы.

В предыдущем разборе я показывал этот риск на возврате платежа. AI прочитал обращение, нашёл заказ и предложил вернуть деньги. Дальше возможны три разные системы: первая показывает предложение оператору, вторая сама создаёт заявку, третья отправляет команду в платёжный сервис. На демо они выглядят почти одинаково. Модель одна. Риск - разный.

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

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

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

Автономия относится не к модели, а к действию

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

Уровень стоит назначать не продукту целиком, а конкретной паре «действие + объект». Например:

• прочитать карточку заказа;
• предложить категорию обращения;
• изменить статус;
• отправить сообщение наружу;
• удалить запись.

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

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

Четыре режима: кто предлагает, кто действует, кто отвечает за границы

Четыре режима автономии. Выше - не значит лучше: уровень выбирают под конкретное действие и его риск.

A0 - человек принимает решение и выполняет действие

Человек сам готовит решение и выполняет действие. AI может служить справочным инструментом, но не формирует рабочее предложение для этого шага: такое участие уже относится к A1.

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

A1 - AI готовит, человек подтверждает

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

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

A2 - AI выполняет ограниченное действие, человек контролирует результат

Агент создаёт или изменяет запись через явный контракт. До исполнения код проверяет схему, права, бизнес-ограничения и допустимость аргументов. После исполнения система сохраняет фактический результат, а не только намерение модели. Человек сверяет каждую операцию или ограниченную партию результатов; это и отличает A2 от выборочного контроля в A3.

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

A3 - агент действует самостоятельно в заданной политике

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

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

Не повышайте уровень по одной метрике

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

Перед переходом полезно пройти четыре гейта.

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

1. Контекст и права

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

Минимальные вопросы:

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

2. Проверки качества на трёх уровнях

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

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

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

3. Цена ошибки и обратимость

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

Дальше проверяются четыре вещи:

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

Если ответы расплывчаты, уровень повышать рано.

4. Владелец, остановка и откат

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

Откат не обязательно означает замену модели. Иногда достаточно перевести конкретное действие с A3 на A2, оставить чтение автономным, а запись снова отправлять на контроль. Но остановка новых действий и восстановление уже изменённых данных - разные операции. Обе процедуры нужно проверить до запуска.

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

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

Матрица действий полезнее общего уровня системы

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

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

Где живёт карта и кто замечает расхождения

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

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

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

Зачем здесь слой связанного контекста

Для A1 иногда достаточно нескольких документов и хорошего поиска по ним. На A2 и A3 нужен проверяемый рабочий контекст: объекты, связи, роли и текущее состояние процесса. Его можно получать через API, реестры и справочники; отдельная графовая модель не обязательна.

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

• одна ли сущность скрывается за разными именами в Jira, CRM и протоколе встречи;
• какое решение считается последним;
• какое правило действует для конкретного типа объекта;
• какие сведения устаревают и через сколько;
• как сослаться на источник, не раскрывая лишние данные модели.

Без этого агент может правильно рассуждать на неверном контексте. Хорошая генерация не компенсирует устаревший статус сделки или перепутанного клиента.

Шесть анти-паттернов, которые ломают автономию

1. Прыжок из демо сразу в A3

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

2. Одна оценка уверенности вместо бизнес-правил

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

У нас похожий промах случился в production-контуре. Инспектор tool-call блокировал действия по имени инструмента - включая запуск субагента и удаление временного файла. После отката безусловную блокировку оставили только для катастрофических аргументов, а эвристику по имени инструмента подчинили режиму ключа: в режиме наблюдения она лишь записывает событие. Поэтому для решения об автономии нужны причина, применённое действие и итог операции, а не одна доля срабатываний.

3. Человек, который ничего не успевает проверить

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

4. Контур молчит, и отказ никто не замечает

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

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

5. Рассуждение модели вместо журнала состояния

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

6. Одинаковый уровень для всех действий

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

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

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

Как собрать первую карту за один рабочий разбор

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

1. Нарисуйте путь одной рабочей единицы от входа до результата.
2. Выпишите действия, которые меняют внешнюю систему, отдельно от чтения и подготовки.
3. Для каждого действия укажите объект, систему, текущего исполнителя и цену ошибки.
4. Назначьте текущий режим A0-A3. Не пытайтесь сразу выбрать целевой.
5. Опишите минимальный следующий переход и одну проверку, которая даст основание его оценить.
6. Зафиксируйте запрещённые действия, лимиты, владельца остановки и отрепетированную процедуру восстановления. Сохраните решение в версионируемой политике и добавьте проверку расхождений с рабочими настройками.
7. Запустите ограниченный контур и собирайте не только качество ответа, но и долю ручных исправлений, неизвестные исходы, время проверки и реальные инциденты.

Внешние рекомендации поддерживают именно такой постепенный подход. Anthropic разделяет предопределённые workflows и системы, где модель сама выбирает процесс и инструменты, и советует увеличивать сложность только тогда, когда она нужна. NIST AI RMF рассматривает управление рисками как непрерывную работу с контекстом, измерением и мерами управления, а не как разовую проверку перед запуском. Карта автономии переводит эти общие принципы на уровень конкретных действий процесса.

Вместо вывода

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

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

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

Материалы AGIMA по соседним частям контура

• LLM предлагает, код исполняет: как разделить reasoning и side effects в production-пайплайне
• AI Gateway как единая точка входа к LLM: как дать сотрудникам ИИ и не потерять контроль
• DLP для LLM: как обезличивать запросы и не ломать поиск по сотрудникам