ИИ без права на стоп — это не автономность, а отсутствие управления

2026-09-01 19:30:26 Время чтения 9 мин 71
Ядро ИИ-системы внутри контуров полномочий и механизма безопасной остановки

Автономность часто измеряют не тем

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

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

Представим поручение: «Верни недовольных клиентов». Агент может подготовить причины оттока и проекты писем. А может решить, что лучший способ — раздать максимальные скидки всей базе. Обе стратегии формально служат цели, но только одна отвечает намерениям бизнеса.

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

Пять уровней автономности вместо переключателя «вкл./выкл.»

Автономность полезно проектировать не как один режим, а как лестницу.

Уровень 0 — наблюдение. Система читает разрешенные данные и объясняет выводы, но ничего не меняет.

Уровень 1 — подготовка. ИИ создает черновик письма, задачи, отчета или решения. Публикация и любое изменение остаются за человеком.

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

Уровень 3 — условная автономность. Агент ведет процесс целиком, пока соблюдены лимиты. Исключения, крупные суммы, внешние обещания, работа с чувствительными данными и необратимые шаги передаются ответственному сотруднику.

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

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

Human-in-the-loop — не очередь из бессмысленных согласований

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

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

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

Так появляется контроль в точках риска. В низкорисковых операциях человек остается «над циклом»: наблюдает за метриками и вмешивается при отклонениях. В значимых решениях он находится «в цикле»: агент обязан запросить явное подтверждение.

Фраза «разрешить действие?» почти бесполезна. Система должна показать само действие, основания, ожидаемые последствия и способ отмены. Человеку нужен контекст, а не еще одна кнопка.

У ИИ-сотрудника должен быть собственный пропуск

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

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

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

Это инженерная гигиена: отказ одного компонента не должен открывать всю инфраструктуру.

Что должно попадать в журнал

Если после инцидента нельзя восстановить цепочку решений, автономностью нельзя управлять. Журнал должен отвечать на семь вопросов:

  1. Кто и когда поставил задачу?
  2. Какая цель и какие ограничения были переданы системе?
  3. Какая версия агента, модели и правил использовалась?
  4. Какие источники данных и инструменты были вызваны?
  5. Какие действия планировались и какие действительно выполнены?
  6. Где запрашивалось согласование и кто его дал?
  7. Каков результат, что изменилось и можно ли это отменить?

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

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

Stop conditions: когда система обязана прекратить работу

Команда «стоп» должна быть системным механизмом, который модель не может отменить своим решением. Условия остановки задаются заранее:

  1. достигнут результат либо исчерпано допустимое число шагов, время или бюджет
  2. одна и та же ошибка повторяется, а прогресс отсутствует
  3. данные конфликтуют, обязательное поле отсутствует или уверенность ниже заданного порога
  4. агент пытается вызвать запрещенный инструмент либо выйти за область задачи
  5. действие превышает лимит суммы, количества адресатов или числа изменяемых объектов
  6. обнаружен необычный всплеск активности или отклонение от нормального сценария
  7. внешний текст пытается выдать себя за системную инструкцию
  8. ответственный сотрудник нажал «остановить»

Безопасная пауза — это не аварийное завершение. Система не повторяет рискованную операцию, фиксирует состояние, отзывает временные полномочия и сообщает человеку, что сделано, почему работа остановлена и какой выбор требуется.

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

Как повышать самостоятельность без прыжка в неизвестность

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

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

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

Перед запуском задайте несколько неудобных вопросов. Что агент может сделать безвозвратно? Каков максимальный ущерб одной ошибки? Чьи полномочия он использует? Увидим ли мы отклонение до жалобы клиента? Кто остановит систему ночью? Что останется в журнале? Если конкретного ответа нет, повышать автономность рано.

Зрелость — это управляемая свобода действий

Полезный ИИ-сотрудник не должен спрашивать разрешение на каждую мелочь и не должен действовать бесконтрольно. Рутину он выполняет сам, риск распознает заранее, а неоднозначное решение передает человеку.

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