Когда AI получает инструменты, главный вопрос меняется. Уже не «может ли он выполнить действие», а «должен ли он иметь право выполнить его без человека». Мы проходили эту границу почти на каждом внешнем адаптере Agent Core.
Я бы распределял права не по степени доверия к модели вообще, а по последствиям конкретной операции.
Низкий риск — чтение и подготовка
Собрать данные, найти отклонение, подготовить черновик, сформировать предложение изменения. Такие действия часто можно автоматизировать шире, если доступ к источнику сам по себе разрешён.
Даже здесь полезны ссылки на источник и журнал, но ошибка обычно обратима до внешнего эффекта.
Средний риск — обратимое изменение
Изменение внутреннего статуса или создание черновика в системе может быть автоматическим, если есть строгие условия и простой rollback. Но scope должен быть ограничен.
Я бы избегал универсального «редактировать всё». Права на конкретный тип объекта или поле проще контролировать.
Высокий риск — деньги, клиент и публичный мир
Отправка сообщения, удаление, платёж, публичная публикация или изменение критичных данных требуют более строгой политики. Где-то нужен человек, где-то достаточно immutable preview и узкого автоматического правила.
Ограничение: полностью универсальной матрицы нет. Цена ошибки зависит от бизнеса. Поэтому правила должны настраиваться по процессам и ролям, а не быть одинаковыми для всех.
Полномочия должны расширяться постепенно
Я бы начинал с минимального набора и добавлял права только после того, как предыдущий уровень работает предсказуемо. Сначала чтение, затем подготовка, потом ограниченное изменение и лишь после доказательства — более самостоятельные внешние действия.
Такой путь кажется осторожным, но он позволяет понять реальную цену автономности. Часто выясняется, что бизнес получает основную пользу уже на чтении и подготовке, а опасные права нужны лишь нескольким редким операциям.
Полезно также разделять права по роли человека. То, что допустимо для собственника, не обязательно должно быть доступно менеджеру или внешнему подрядчику. AI-интерфейс не отменяет обычную модель доступа — он должен наследовать и усиливать её.
Риск определяется не названием действия, а его эффектом
Одинаковая команда может иметь разную цену ошибки в разных системах. «Изменить статус» внутри служебной очереди и «изменить статус» заказа, который видит клиент, технически похожи, но бизнес-последствия отличаются. Поэтому каталог полномочий полезно строить вокруг внешнего эффекта: кто увидит изменение, можно ли его отменить, затрагивает ли оно деньги, обязательства или публичную информацию.
Это позволяет не спорить о том, «умный ли AI». Даже сильная модель должна работать внутри правил, которые соответствуют конкретной операции. Чем сложнее последствия, тем больше смысла в предварительном просмотре, подтверждении человеком или дополнительной проверке условий.
Подтверждение человеком — не единственный механизм безопасности
Кнопка «подтвердить» полезна там, где человек действительно способен оценить изменение. Но если оператор каждый раз механически подтверждает десятки одинаковых действий, контроль становится формальным. Для повторяемого низкорискового эффекта лучше иметь узкое правило допуска, ограниченный набор полей и автоматическую проверку результата.
И наоборот, редкое действие с высокой ценой ошибки не стоит автоматизировать только ради того, чтобы убрать один клик. Здесь человеческое подтверждение может быть частью нормального процесса. Цель — не максимальное количество автономных операций, а разумное распределение контроля.
После любого write нужен read-back
Отдельная ошибка автоматизации — считать успешный технический ответ доказательством результата. Внешняя система может принять запрос, обработать его иначе, сохранить не все поля или показать состояние, которое не соответствует ожиданию. Поэтому после изменения полезно перечитать тот объект или публичный результат, который должен был поменяться.
Если read-back совпал с ожидаемым состоянием, действие можно считать подтверждённым. Если нет — нужен понятный статус неопределённости и передача человеку. Такая схема важна не только для AI: она дисциплинирует любые интеграции, где технический транспорт и бизнес-эффект — разные вещи.
Массовость меняет класс риска
Операция, безопасная для одной записи, может стать рискованной при массовом запуске. Поэтому количество объектов, частота действий и допустимая область изменений должны быть частью разрешения. Полномочие «создать внутреннюю заметку» не обязано автоматически означать право создать её для всей базы.
Я бы разделял одиночные и массовые эффекты, даже если они используют один API. Для массового действия нужен отдельный лимит, предварительная выборка или подтверждение состава объектов. Это уменьшает радиус ошибки без необходимости запрещать полезную автоматизацию полностью.
Журнал нужен для ответа на два разных вопроса
Первый вопрос — почему система решила действовать: какие данные она увидела, какое правило или условие сработало. Второй — что реально произошло во внешней системе после действия. Эти два слоя нельзя смешивать. Объяснение решения не заменяет подтверждение результата, а успешный результат не объясняет, почему действие вообще было разрешено.
Такой журнал помогает пересматривать границы автономности. Если определённый класс операций стабильно проверяется и не требует содержательного вмешательства человека, его можно рассматривать как кандидата на более высокий уровень автоматизации. Если исключения часты или эффект трудно проверить, подтверждение лучше оставить.
Автономность — не самостоятельная бизнес-метрика
Я бы не ставил задачу «довести AI до максимальной автономности». Иногда оптимальная система почти всё читает и готовит, но лишь небольшую часть действий выполняет сама. Если это снимает навигацию, собирает контекст и ускоряет принятие решения, ценность уже возникает.
Поэтому вопрос «что разрешить без меня» лучше решать от процесса и последствий. Что можно проверить автоматически? Где ошибка обратима? Где действие затрагивает клиента, деньги или публичную информацию? Где человек добавляет реальное решение, а где только нажимает формальную кнопку? Ответы и задают границу.
Отдельно я бы проверял срок жизни разрешения. Полномочие, выданное для одного процесса или этапа, не обязано автоматически оставаться правильным после изменения системы, роли сотрудника или логики бизнеса. Права нужно уметь пересматривать так же, как пересматриваются сами процессы.
Мы начинаем проектирование AI-действий с карты полномочий и способов проверки, а не с максимальной автономности: https://imr.top-experts.pro/contacts/
Если нужен не отдельный отчёт, а регулярный контроль по рабочим данным компании, см. AI-ассистента руководителя по продажам и управлению.
Связанный кейс Agency: Автоматизация публикаций: почему workflow ещё не означает публикацию.