Евгений Волков – Когда машина отвечает (страница 10)

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

Вопросы звучат сухо.

Но за ними скрывается почти политическая проблема в миниатюре.

Делегирование требует границ.

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

С программным агентом возникает тот же вопрос, только в новой форме.

Есть вещи, которые удобно поручить.

Есть вещи, которые удобно поручить после подтверждения.

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

Цена одного подтверждения

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

Но что значит «важным»?

Перед отправкой письма?

Перед письмом внешнему адресату?

Перед письмом, содержащим вложение?

Перед публикацией комментария?

Перед переносом встречи?

Перед отменой встречи?

Перед покупкой?

Перед каждой покупкой или только выше определённой суммы?

Перед удалением файла?

Перед изменением файла?

Перед командой, которая косвенно может удалить данные?

Если подтверждений слишком мало, возникает риск.

Если их слишком много, пользователь начинает нажимать «да» автоматически.

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

Поэтому хороший контроль не равен максимальному количеству окон «Вы уверены?».

Он должен появляться там, где меняется характер ответственности.

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

Сам факт появления таких механизмов многое говорит о технологии.

Если система только отвечает, её главный риск — содержание ответа.

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

Она должна не только понимать, что можно сделать.

Она должна понимать, что ей разрешено сделать сейчас.

Обратимость важнее впечатляющего интеллекта

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

Нужно спросить: насколько легко отменить результат?

Система изменила черновик документа — версию можно восстановить.

Переименовала десять файлов — неприятно, но обычно обратимо.

Отправила внутреннее письмо не тому сотруднику — исправить уже сложнее.

Опубликовала сообщение от имени компании — последствия выходят за пределы интерфейса.

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

Эта шкала важна потому, что слово «автономность» слишком часто звучит как одна величина. Будто можно поставить систему на линейку и сказать: здесь она автономна на двадцать процентов, а здесь на восемьдесят.

В реальности автономность многомерна.

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

Поэтому зрелая система контроля должна учитывать не только вероятность ошибки, но и масштаб возможного ущерба. В компьютерной безопасности иногда используют выражение blast radius — радиус поражения: насколько далеко распространится последствие, если что-то пойдёт не так. Для этой книги достаточно более простого слова — масштаб.

Ошибка с маленьким масштабом можно пережить.

Ошибка с большим масштабом должна встречать дополнительные барьеры.

Отсюда появляется важная идея: автономность можно выдавать не всей системе сразу, а по уровням.

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

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

Но такая рамка исправляет один распространённый страх.

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

Главный инженерный и общественный вопрос состоит в том, как дробить полномочия так, чтобы система получала свободу там, где ошибка переносима, и встречала сопротивление там, где последствия становятся труднообратимыми.

Чужой текст внутри вашего решения

Есть ещё одна особенность, из-за которой агент отличается от обычной автоматизации.

Чтобы выполнить задачу, он часто должен читать внешние данные.

Письма.

Сайты.

Документы.

Сообщения.

Репозитории кода.

И среди этих данных может находиться текст, который выглядит для модели как инструкция.

Человек обычно различает два уровня довольно легко.

Начальник говорит: «Прочитай письмо клиента и кратко перескажи».