У эффектной демонстрации обычно один сюжет: ИИ получает цель, составляет план, открывает нужные сервисы и доводит задачу до результата. В реальной компании вопрос звучит иначе: что произойдет, если цель двусмысленна, данные противоречат друг другу, а у системы есть право писать клиентам или распоряжаться деньгами?
Чат-бот ошибается в ответе. Агентная система — в действии. Она планирует, вызывает инструменты, оценивает результат и выбирает следующий шаг, поэтому одна неверная интерпретация способна размножиться на десятки операций.
Представим поручение: «Верни недовольных клиентов». Агент может подготовить причины оттока и проекты писем. А может решить, что лучший способ — раздать максимальные скидки всей базе. Обе стратегии формально служат цели, но только одна отвечает намерениям бизнеса.
Безопасность создается не моделью самой по себе, а полномочиями, лимитами, правилами согласования, журналом действий и механизмом остановки.
Автономность полезно проектировать не как один режим, а как лестницу.
Уровень 0 — наблюдение. Система читает разрешенные данные и объясняет выводы, но ничего не меняет.
Уровень 1 — подготовка. ИИ создает черновик письма, задачи, отчета или решения. Публикация и любое изменение остаются за человеком.
Уровень 2 — ограниченное исполнение. Система самостоятельно выполняет обратимые и низкорисковые действия: классифицирует обращения, обновляет служебные поля, назначает типовые задачи. Все работает только в заданных пределах.
Уровень 3 — условная автономность. Агент ведет процесс целиком, пока соблюдены лимиты. Исключения, крупные суммы, внешние обещания, работа с чувствительными данными и необратимые шаги передаются ответственному сотруднику.
Уровень 4 — высокая автономность в изолированном контуре. Система долго работает без подтверждений, но только с ограниченными инструментами, бюджетом, временем и данными. Человек наблюдает и может немедленно вмешаться.
Уровня «делай что угодно от имени компании» здесь нет. Должностная инструкция агента должна быть исполнена не только текстом в промпте, но и техническими ограничениями.
Если человек подтверждает каждый шаг, система безопаснее лишь на бумаге. Вскоре сотрудник начинает нажимать «разрешить» не читая — и контроль превращается в ритуал.
Разумнее разделить действия по последствиям. Автоматически можно разрешить то, что обратимо, проверяемо и укладывается в небольшой лимит. Подтверждение требуется там, где действие:
Так появляется контроль в точках риска. В низкорисковых операциях человек остается «над циклом»: наблюдает за метриками и вмешивается при отклонениях. В значимых решениях он находится «в цикле»: агент обязан запросить явное подтверждение.
Фраза «разрешить действие?» почти бесполезна. Система должна показать само действие, основания, ожидаемые последствия и способ отмены. Человеку нужен контекст, а не еще одна кнопка.
Опасно подключать агента под учетной записью руководителя или администратора «для удобства». В таком случае любая ошибка получает тот же радиус поражения, что и действия владельца аккаунта.
Практическое правило — отдельная идентичность и минимальные права. Агент поддержки может читать обращение и историю конкретного клиента, создавать задачу и готовить ответ. Ему не нужен экспорт всей базы или доступ к настройкам интеграций. Агент маркетинга может собирать статистику и готовить кампанию, но увеличение бюджета сверх порога требует подтверждения.
По умолчанию лишнее запрещено. Повышенные полномочия выдаются на конкретную задачу и ограниченное время, а затем отзываются. «Прочитать», «создать черновик», «изменить», «опубликовать» и «удалить» — разные разрешения, даже если сервис предлагает один широкий доступ.
Это инженерная гигиена: отказ одного компонента не должен открывать всю инфраструктуру.
Если после инцидента нельзя восстановить цепочку решений, автономностью нельзя управлять. Журнал должен отвечать на семь вопросов:
Нужен не текст внутренних рассуждений, а операционный след: события, параметры вызовов, решения правил, подтверждения и итоговые изменения. Сам журнал не должен стать хранилищем секретов: чувствительные поля маскируются, доступ разграничивается, срок хранения задается заранее.
Аудит показывает, где агент просит лишние права, зацикливается, создает слишком много исключений или заставляет людей отменять действия. Это материал для улучшения процесса, а не просто «черный ящик» на случай аварии.
Команда «стоп» должна быть системным механизмом, который модель не может отменить своим решением. Условия остановки задаются заранее:
Безопасная пауза — это не аварийное завершение. Система не повторяет рискованную операцию, фиксирует состояние, отзывает временные полномочия и сообщает человеку, что сделано, почему работа остановлена и какой выбор требуется.
Например, агент обрабатывает возвраты. До установленной суммы он действует самостоятельно. Если число возвратов резко выросло, реквизиты не совпадают или клиент просит другой способ выплаты, система ставит процесс на паузу, сохраняет материалы и зовет сотрудника.
Сначала составляют матрицу: какие действия допустимы, какие требуют подтверждения, а какие всегда запрещены. Затем агент работает в теневом режиме — предлагает шаги, но не исполняет их. Решения сравнивают с решениями сотрудников.
После этого включают обратимые операции и лимиты. Полномочия расширяют по данным: доля успешных задач, число вмешательств, ложные остановки, отмены и стоимость ошибок. Отдельно проверяют недоступность сервиса, противоречивые документы, вредоносный контент и внезапный рост нагрузки.
Нужен аварийный контур: одна команда останавливает новые действия, активные задачи переходят в безопасное состояние, временные доступы отзываются, ответственные получают уведомление. Этот сценарий стоит репетировать заранее.
Перед запуском задайте несколько неудобных вопросов. Что агент может сделать безвозвратно? Каков максимальный ущерб одной ошибки? Чьи полномочия он использует? Увидим ли мы отклонение до жалобы клиента? Кто остановит систему ночью? Что останется в журнале? Если конкретного ответа нет, повышать автономность рано.
Полезный ИИ-сотрудник не должен спрашивать разрешение на каждую мелочь и не должен действовать бесконтрольно. Рутину он выполняет сам, риск распознает заранее, а неоднозначное решение передает человеку.
В AiHummer мы рассматриваем право на остановку, ограниченные полномочия и проверяемый журнал не как дополнительные функции, а как основу промышленного ИИ-сотрудника. Настоящая автономность начинается не там, где человека убрали из процесса, а там, где компания в любой момент понимает, что делает система, почему она это делает и как безопасно вмешаться.