Кто разрешил это действие?

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

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

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

Но главный вопрос остаётся без ответа:

Кто дал право отправить письмо?

Означает ли поручение «изучить потенциальных клиентов» разрешение писать внешним адресатам от имени компании?

Если цель названа, значит ли это, что одобрены все способы её достижения?

Может ли агент расширить свои полномочия, если действует из лучших побуждений?

Становится ли действие без разрешения правильным задним числом, если оно принесло положительный результат?

Здесь проявляется одно из важнейших различий в GBO: правильная цель не даёт нужных полномочий автоматически.

И сразу за ним следует второй вывод: благие намерения — не полномочия.

Техническая возможность, доступ и полномочия

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

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

Поэтому нужно различать пять понятий:

Техническая возможность

Может ли система технически выполнить действие?

Доступ

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

Техническое разрешение

Блокирует ли техническая система конкретную операцию или позволяет её выполнить?

Полномочия

Действительно ли право на такое поведение предоставлено надлежащим лицом или организацией?

Одобрение

Одобрил ли человек конкретное действие с его конкретными условиями?

Понятия кажутся близкими, но не совпадают. Действительный ключ API может служить основанием для аутентификации или доступа. Допустимые операции зависят от области действия ключа и правил авторизации системы. Роль пользователя тоже может определять часть этих технических разрешений. Указание человека может наделять полномочиями. А явно выраженное принятие конкретной операции перед её выполнением — это одобрение.

Техническое разрешение не заменяет организационных полномочий.

Открытая дверь ещё не даёт права войти.

Согласие, полномочия и одобрение

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

Согласие

Полномочия

Одобрение

Их часто используют как синонимы, хотя они отвечают на разные вопросы.

Согласие

Добровольное и информированное принятие конкретного использования или операции человеком, которого действие непосредственно затрагивает.

Например, согласие может потребоваться для:

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

Необходимость согласия зависит от конкретного использования.

Полномочия

Право человека или системы выполнять определённые действия от имени другого человека или организации.

С полномочиями связаны, например:

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

Во всех этих случаях важно, кто вправе совершить действие.

Одобрение

Принятие конкретного проекта, операции или действия до его выполнения.

Например, одобрение может потребоваться перед тем, как:

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

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

Согласие, полномочия и одобрение — разные шлюзы одной поведенческой цепочки.

Расширение полномочий, спрятанное в одном глаголе

Люди формулируют поручения короткими глаголами:

Исследуй. Найди. Подготовь. Отредактируй. Управляй. Оптимизируй. Реши. Продолжай.

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

За словом «найди» могут оказаться:

• поиск,
• составление списка кандидатов,
• сбор контактных данных,
• обращение к человеку,
• запрос встречи.

Так один глагол может превратиться в целую последовательность.

«Отредактируй» может быть понято как:

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

Это разные операции.

«Управляй» может включать:

• наблюдение,
• классификацию,
• подготовку черновиков,
• автоматические ответы,
• платежи,
• закрытие аккаунта.

За одним словом скрываются действия с совершенно разными последствиями.

Поэтому GBO проводит принципиальные границы: исследовать — не значит связываться.

Найти — не значит отправить сообщение.

Подготовить — не значит опубликовать.

Отредактировать — не значит развернуть в рабочей среде.

Рекомендовать — не значит купить.

Управление не даёт неограниченного права принимать решения.

Поручение решить проблему не делает допустимыми все способы её решения.

Цель, выраженная естественным языком, сама по себе не определяет границы поведения.

Одобрение цели не означает одобрения способа

Руководитель компании может сказать: «Сделай нас одним из самых заметных брендов в мире в области GEO». Это амбициозная цель.

В пределах предоставленных прав доступа и изменения агент может:

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

Но та же цель не разрешает автоматически:

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

Цель может быть законной, а способ — всё равно неправильным.

Желаемый результат не оправдывает все пути к нему.

Поэтому контракт полномочий должен содержать два отдельных раздела:

Желаемый результат

Чего требуется достичь?

Разрешённые способы

Какими действиями можно прийти к этому результату?

Нужен и третий, столь же ясный раздел:

Запрещённые способы

Какие действия нельзя использовать, даже если они помогают достичь цели?

Полномочия — не ключ, а контур

Во многих системах полномочия представляют как переключатель: включено или выключено. «Мы дали этому агенту доступ». Но реальные полномочия многомерны.

Их определяют следующие вопросы:

• Какое действие разрешено?
• В какой системе?
• С какими данными?
• От чьего имени?
• В отношении кого?
• С какой целью?
• В пределах какой суммы?
• В течение какого времени?
• Сколько раз?
• В какие часы?
• В какой стране или на каком канале?
• До какого уровня риска?
• С какого момента требуется одобрение человека?
• Можно ли делегировать полномочия другому агенту?
• Что делать при ошибке?

Эту совокупность можно назвать контуром полномочий. Он очерчивает пространство, в котором агент вправе действовать.

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

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

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

Ступень действия должна соответствовать полномочиям

В третьей главе мы построили Лестницу действий:

• Наблюдение
• Интерпретация
• Рекомендация
• Подготовка
• Выполнение
• Принятие обязательств
• Закрепление последствий

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

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

Контракт полномочий NOMOS

Четвёртым компонентом контракта поведения станет Контракт полномочий NOMOS.

Его каноническое определение:

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

Проще говоря, контракт полномочий объясняет агенту не только что делать, но и насколько далеко он вправе зайти.

Основные поля контракта полномочий

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

principal

authorized_agent

purpose

allowed_actions

prohibited_actions

target_systems

target_entities

allowed_data

prohibited_data

communication_channels

financial_limit

frequency_limit

valid_from

valid_until

geographic_scope

risk_level

human_approval_threshold

delegation_allowed

subagent_limits

logging_required

rollback_required

revocation_method

emergency_stop

version

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

Кто может наделять полномочиями?

Агент не может уполномочить сам себя.

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

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

Поэтому нужны два отдельных вопроса: кто дал указание?

И действительно ли этот человек вправе предоставить такие полномочия?

Цепочка полномочий

В организации полномочия не всегда переходят от одного человека прямо к агенту.

Например:

• Совет директоров утверждает общий бюджет.
• Генеральный директор даёт подразделению право расходовать средства.
• Руководитель подразделения наделяет закупочного агента полномочиями в пределах определённых категорий и сумм.
• Агент готовит заказ.
• Финансовая система выполняет платёж.

Эту связь можно назвать цепочкой полномочий.

Каждое звено должно отвечать на вопросы:

• Кто предоставил полномочия?
• Имел ли он право их передать?
• Какую часть передал?
• Какие ограничения сохранились?
• Когда полномочия истекают?
• Кто отвечает за операцию?

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

Делегирование не может расширять полномочия

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

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

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

Отмывание полномочий

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

Например:

• Исследовательский агент не имеет права отправлять сообщения.
• Но поручает почтовому агенту: «Свяжись с этим человеком».
• Почтовый агент отправляет сообщение.
• В результате несанкционированное действие теряется из виду внутри цепочки.

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

Другие примеры:

• Агент без прямых платёжных полномочий запускает автоматическое продление на платформе закупок.
• Агент без права публикации в рабочей среде вызывает инструмент CI/CD и развёртывает версию.
• Агент, которому нельзя передавать персональные данные, отправляет их в другой инструмент аналитики.
• Агент социальных сетей, не уполномоченный делать юридические заявления, передаёт текст на другую платформу публикации.

GBO проверяет не только последнее действие, но и цепочку полномочий.

Исполнение операции другим инструментом не решает проблему полномочий.

Теневые полномочия

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

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

Теневые полномочия опасны тем, что система может решить: «Раз я могу, значит, мне разрешено».

Однако остаточный доступ — не действующие полномочия.

Долг полномочий

Со временем в организации могут накапливаться:

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

Всё это остаётся в действующей среде.

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

Но после инцидента без ответа остаются вопросы:

• Почему этот агент имел доступ к этому аккаунту?
• Кто выдал разрешение?
• Были ли полномочия ещё действительны?
• Почему действие не потребовало одобрения человека?
• Как субагент увидел эти данные?
• Почему отозванная роль продолжала работать?

GBO требует регулярно измерять и сокращать долг полномочий.

Принцип минимальных привилегий

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

Поэтому основой должен быть принцип минимальных привилегий.

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

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

Постоянные и разовые полномочия

Здесь мы различаем полномочия на регулярную работу и полномочия на отдельную операцию.

Постоянные полномочия

Разрешают регулярно выполнять определённые действия.

Например:

• каждое утро классифицировать входящую почту,
• каждую неделю проверять состояние сайта,
• пополнять расходные материалы в пределах установленной суммы,
• выполнять утверждённый контент-план.

Полномочия на отдельную операцию

Выдаются на одно конкретное действие.

Например:

• Отправь это сообщение.
• Разверни эту версию в рабочей среде.
• Опубликуй это видео.
• Оплати этот счёт.
• Передай этот проект договора.

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

Прежнее одобрение — не доверенность на будущее

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

Сходство не продлевает полномочия.

Если постоянные полномочия не предоставлены явно, прежнее одобрение нельзя повторно использовать для новой операции.

Молчание — не одобрение

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

Но в операциях с серьёзными последствиями молчание нельзя трактовать как разрешение на:

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

Такие разрешения нельзя выводить из отсутствия ответа.

Не ответить — не значит сказать «да».

Информированное одобрение

Недостаточно просто спросить человека: «Вы одобряете?». Он должен понимать, что именно одобряет.

Хороший экран одобрения должен показывать:

• Что будет сделано?
• От чьего имени?
• В отношении кого или какой системы?
• Какие данные будут использованы?
• Какие расходы возникнут?
• Какие обязательства появятся?
• Можно ли отменить операцию?
• Будет ли она выполнена один раз или повторяться?
• Будут ли задания передаваться другим агентам?
• В чём существенный риск?

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

Усталость от одобрений

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

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

Поэтому хорошая система GBO должна:

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

Цель — не тревожить человека на каждом этапе.

Его нужно подключать там, где требуется содержательное решение.

Осмысленное одобрение

Одобрение действительно имеет смысл, если пользователь:

• может понять последствия операции,
• видит альтернативы,
• вправе отказаться,
• не несёт наказания за отказ,
• может позднее отозвать полномочия,
• при необходимости может попросить объяснение.

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

Согласие ограничено целью

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

Согласие на одну цель — не согласие на все цели.

Доступ к данным — не право их использовать

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

В отношении данных нужно различать четыре действия:

• Просмотр
• Обработка
• Передача
• Хранение

Разрешение на первое не охватывает автоматически остальные три.

Можно добавить и пятое действие:

• Повторное использование для новой цели

Каждое может потребовать отдельных полномочий.

Право расходовать деньги

Если агент может распоряжаться бюджетом, одной предельной суммы может быть недостаточно.

Нужно также определить:

• Какая категория?
• Какой продавец?
• Разовая покупка?
• Подписка?
• Есть ли автоматическое продление?
• Включены ли налоги и дополнительные сборы?
• Каков общий месячный лимит?
• Возможен ли возврат?
• Какое платёжное средство допустимо?
• В каких странах разрешены операции?

Агент может быть уполномочен купить товар за 50 долларов США. Это не даёт ему права открыть бессрочную подписку за 49 долларов в месяц. Первая сумма выглядит небольшой, но совокупное обязательство может оказаться гораздо больше.

Сумма операции и общая величина обязательств — не одно и то же.

Право говорить от имени компании

Агент может иметь точные сведения о компании. Это не означает, что он вправе высказываться от её имени по любому поводу.

Разных полномочий требуют:

• предоставление общей справочной информации,
• оказание технической поддержки,
• объявление цен,
• предоставление скидки,
• обещание срока поставки,
• предоставление юридических разъяснений,
• публикация заявления в связи с кризисом,
• раскрытие информации для инвесторов.

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

Уровни полномочий для ИИ-аватара

Использование цифрового образа человека нельзя свести к одному одобрению.

Как минимум нужно разделять разрешения на:

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

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

Разрешение создавать цифровую личность — не неограниченное право представлять человека.

Полномочия для рабочей среды

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

Публикация в рабочей среде может затронуть:

• реальных клиентов,
• поток выручки,
• данные,
• репутацию бренда,
• видимость в поисковых системах.

Её последствия выходят за пределы локальной работы.

Поэтому следует различать полномочия на:

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

В некоторых проектах агент может обладать всеми этими правами. Но это должно быть определено явно.

Полномочия в отношении юридических текстов и цен

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

Поэтому отдельные области контента следует отнести к категории повышенных полномочий:

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

Для них необходимы более высокие полномочия.

Чрезвычайные полномочия

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

Чрезвычайные полномочия следует использовать:

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

Эти условия ограничивают их применение.

Например, агент может:

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

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

• менять постоянную политику,
• закрывать не связанные с инцидентом аккаунты,
• создавать новые коммерческие обязательства.

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

Двойной контроль

Для операций с серьёзными последствиями решения одного человека или одного агента может быть недостаточно.

Например:

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

Здесь могут понадобиться две отдельные проверки.

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

Разделение обязанностей

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

Например:

• Закупочный агент делает выбор.
• Человек одобряет бюджет.
• Платёжная система выполняет операцию.
• Аудиторский агент проверяет квитанцию.

Такое разделение не нужно для каждой мелочи, но становится ценнее по мере роста риска.

Срок полномочий

Предоставленные агенту полномочия не должны действовать вечно.

Их можно ограничить:

• одной операцией,
• одной сессией,
• определёнными днями,
• конкретным проектом,
• сроком определённого договора.

После истечения срока полномочия должны прекращаться автоматически.

Забытые полномочия — уязвимость.

Продление полномочий

По истечении срока система не должна автоматически продолжать прежнее поведение.

Нужно заново оценить:

• Нужна ли ещё задача?
• Остался ли агент тем же?
• Тот ли человек за него отвечает?
• Изменился ли риск?
• Изменились ли используемые инструменты?
• Хватит ли более узких полномочий?

Продление — это проверка текущей потребности, а не копирование старого разрешения.

Отзыв полномочий

Человек должен иметь возможность отозвать предоставленные права.

В отношении агента можно:

• остановить его работу,
• закрыть доступ,
• приостановить задачи,
• отозвать прежние учётные данные.

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

• Не начинать новых действий
• Остановить субагентов
• Отменить запланированные операции
• В надлежащем объёме аннулировать токены доступа или ключи, относящиеся к отозванным полномочиям
• Сообщить об открытых задачах
• Удалить или архивировать данные согласно контракту полномочий
• Создать запись об отзыве

Неотзываемые полномочия не дают человеку полного контроля.

Одного аварийного выключателя недостаточно

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

Поэтому аварийная остановка должна охватывать:

• основного агента,
• субагентов,
• автоматизации,
• запланированные задачи,
• вызовы внешних инструментов.

После остановки также должно быть видно, какие операции остались незавершёнными.

Состояние полномочий должно быть видно

В момент действия агент должен иметь возможность прочитать:

Есть ли у меня полномочия на эту операцию? Когда они истекают? Какой действует денежный лимит? Требуется ли одобрение человека? Могу ли я делегировать задачу субагенту? Можно ли отменить операцию?

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

Шлюз полномочий NOMOS

Перед важным действием агент должен пройти следующие шлюзы:

1. Шлюз источника полномочий

Правильно ли установлены человек или система, давшие указание, и вправе ли они предоставить такие полномочия?

2. Шлюз цели

Действительно ли действие связано с поставленной целью?

3. Шлюз поведения

Входит ли именно это действие в число явно разрешённых?

4. Шлюз адресата

Находятся ли человек, организация, аккаунт или система, на которые направлено действие, внутри контура полномочий?

5. Шлюз данных

Есть ли действительные права на данные, которые будут использоваться и передаваться?

6. Шлюз ограничений

Соблюдаются ли пределы суммы, срока, частоты, канала и географии?

7. Шлюз согласия

Получены ли необходимые согласия людей, которых затрагивает действие?

8. Шлюз одобрения

Требуется ли при таком риске одобрение человеком конкретной операции и получено ли оно?

9. Шлюз делегирования

Действительна ли цепочка полномочий, если задача передана другому агенту?

10. Шлюз записи и возврата

Будет ли действие записано? Определены ли способы остановки, возврата и устранения последствий, а также их границы?

В упрощённом виде:

УСЛОВИЯ ДЕЙСТВИЯ В ПРЕДЕЛАХ ПОЛНОМОЧИЙ:

НАДЛЕЖАЩИЙ ИСТОЧНИК ПОЛНОМОЧИЙ

И ЯСНАЯ ЦЕЛЬ

И РАЗРЕШЁННОЕ ПОВЕДЕНИЕ

И ПРАВИЛЬНЫЙ АДРЕСАТ

И ДАННЫЕ, РАЗРЕШЁННЫЕ К ИСПОЛЬЗОВАНИЮ

И ОПЕРАЦИЯ В ПРЕДЕЛАХ ОГРАНИЧЕНИЙ

И НЕОБХОДИМОЕ СОГЛАСИЕ

И НЕОБХОДИМОЕ ОДОБРЕНИЕ

И ДЕЙСТВИТЕЛЬНОЕ ДЕЛЕГИРОВАНИЕ

И ПРОВЕРЯЕМЫЙ РЕЗУЛЬТАТ

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

Почему Шлюз полномочий — не оценка в баллах?

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

Доверие не заменяет документа о полномочиях.

История успехов не даёт автоматической доверенности на новую операцию.

Вероятность хорошего результата не устраняет отсутствие согласия.

Поэтому Шлюз полномочий основан на логике И. Если отсутствует одно из критических условий, действие недопустимо.

Как действовать при неясных полномочиях

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

Перейти на более низкую ступень действия

Подготовить черновик вместо отправки. Оставить изменение в тестовой среде вместо публикации в рабочей. Собрать корзину вместо покупки.

Попросить уточнение

«Мне только подготовить это сообщение или также отправить?» «Применить изменение в тестовой среде или на работающем сайте?» «Нужно ли для этой суммы отдельное одобрение финансового отдела?»

Остановиться

Если риск высок, а полномочия нельзя проверить, выполнять операцию не следует. Толковать неопределённость в пользу более широких прав — неверное поведение.

Сомнительные полномочия — не полномочия.

Минимальный достаточный вопрос

Агенту не обязательно на каждом шаге показывать длинные формы одобрения.

Иногда достаточно одного ясного вопроса: «Мне лишь подготовить письмо или вы разрешаете также отправить его от имени компании?» «500 долларов — разовый расход или допустима ежемесячная подписка?» «Мы используем этот аватар только для учебных видео?» «Можно ли развернуть эту версию в рабочей среде или оставить только в тестовой?» Хорошая система закрывает пробел в полномочиях самым коротким вопросом, которого достаточно для решения.

Квитанция полномочий

После каждого важного действия можно создать:

Квитанцию полномочий

как запись об основании выполнения.

Она показывает:

• Что было сделано?
• Кто запросил действие?
• Кто предоставил полномочия?
• Каким правом обладал тот, кто их предоставил?
• В какой версии и роли работал агент?
• Полномочия были разовыми или постоянными?
• Какие данные использовались?
• Какие ограничения применялись?
• Когда получено одобрение человека?
• Можно ли отменить операцию?
• Когда истекают полномочия?

Пример:

Действие: потенциальному клиенту отправлен запрос встречи для обсуждения предложения. Инициатор: руководитель компании. Объём полномочий: одна отправка только этому адресату с одобренным текстом. Переданные сведения: общее описание услуг и корпоративный адрес электронной почты. Непереданные сведения: финансовые записи, личный телефон и клиентские данные. Обязательства: письмо не содержит обязывающих условий по цене или договору. Отправивший агент: уполномоченный почтовый агент. Время одобрения: 14:42. Возврат: письмо нельзя отозвать; дальнейшую переписку можно остановить.

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

Одобрение человека не должно быть ритуалом

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

Затем система говорит: «Человек одобрил». Это не настоящий контроль.

Одобрение человека должно быть:

• понятным,
• конкретным,
• основанным на необходимой информации,
• добровольным,
• отзываемым.

Без этих условий оно теряет смысл.

Клик не доказывает, что человек понял.

GBO проектирует одобрение как настоящий момент решения, а не юридический щит.

Пример: веб-агент

Агент получает задачу улучшить сайт с точки зрения SEO и GEO.

В рамках своих полномочий агент может:

• Читать файлы
• Изучать поисковую выдачу
• Готовить черновики материалов
• Редактировать код
• Запускать тесты
• Формировать пакет публикации с возможностью отката
• Проверять работающий сайт по HTTPS

Но для следующих операций может потребоваться отдельное одобрение:

• Изменить цены
• Изменить юридические тексты
• Купить новую платёжную услугу
• Изменить настройки DNS или домена
• Писать внешним адресатам от имени клиента
• Удалить канонические публикации
• Выполнить крупную миграцию URL
• Опубликовать от имени компании сравнительные заявления о превосходстве

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

Пример: агент поиска клиентов

Агенту поиска клиентов можно поручить:

Изучай общедоступные сведения о компаниях. Классифицируй признаки потребности. Рассчитай оценку пригодности. Подготовь черновик обращения.

При этом могут быть запрещены:

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

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

Пример: закупочный агент

Закупочному агенту можно дать такие полномочия:

Покупай заранее одобренные офисные принадлежности в пределах 100 долларов за операцию и 500 долларов в месяц суммарно.

За пределами этих полномочий могут остаться:

• Подписки
• Автоматические продления
• Новые продавцы
• Международные налоговые обязательства
• Товары без возможности возврата
• Личное использование
• Контролируемые товары или товары высокого риска

Одного ограничения суммы недостаточно. Важны также категория и тип операции.

Пример: ИИ-аватар

Руководитель может разрешить следующее:

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

Эти полномочия не включают:

• Рекламу в социальных сетях
• Генерацию на новом языке
• Личные сообщения клиентам
• Политические или финансовые заявления
• Передачу модели голоса другому поставщику
• Бессрочное использование в архиве

Контракт полномочий делает эти границы видимыми.

Как на самом деле связаны полномочия и доверие

Доверять человеку или агенту важно. Но доверие — не то же самое, что неограниченная доверенность.

Даже для самых надёжных сотрудников люди используют:

• бюджетные лимиты,
• право подписи,
• роли доступа,
• двойной контроль.

Это не недоверие, а организационная ответственность. Тот же принцип действует для ИИ-агентов.

Границы не уменьшают доверие. Они позволяют ему сохраняться.

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

Коммерческая ценность чётких полномочий

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

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

Как организации подготовиться?

В эпоху агентов организациям нужны следующие элементы:

Реестр агентов

Какие агенты работают?

Реестр инструментов

К каким аккаунтам, файлам и системам они обращаются?

Карта полномочий

Какие действия разрешены каждому агенту?

Запрещённое поведение

Какие операции никогда не должны выполняться автоматически?

Пороги одобрения

При какой сумме, риске или действии подключается человек?

Правила делегирования

Может ли агент поручать задачи другому агенту?

Срок и отзыв

Когда заканчиваются полномочия и как их отозвать?

Система записи

Для каких действий создаются квитанции?

Аварийная остановка

Как остановить всю цепочку?

Восемнадцать вопросов для проверки полномочий

Перед действием агента можно задать следующие вопросы:

• Кто дал указание: какой человек или система?
• Вправе ли этот человек или система предоставлять такие полномочия?
• Для какой цели они выданы?
• Входит ли запрашиваемое действие в их явно определённый объём?
• На какой ступени находится действие: наблюдение, подготовка, выполнение или принятие обязательств?
• Правильно ли определены адресат, организация или система?
• Есть ли действительные права доступа и использования нужных данных?
• Будут ли данные передаваться в другую систему?
• Соблюдаются ли пределы бюджета, времени, частоты и географии?
• Требует ли действие согласия других людей?
• Нужно ли одобрение человека при таком уровне риска?
• Не принято ли прежнее одобрение ошибочно за постоянные полномочия?
• Действительна ли цепочка при передаче полномочий другому агенту?
• Не получил ли субагент больше прав, чем основной агент?
• Не принимается ли технический доступ за официальные полномочия?
• Не истёк ли срок полномочий?
• Будет ли действие записано и ясны ли пределы возврата и устранения последствий?
• Может ли человек остановить использование полномочий прямо сейчас?

Не нужно явно задавать все эти вопросы при каждой мелкой операции. Но ответы должны быть предусмотрены в устройстве системы.

Уровни готовности полномочий

Предложение этой главы можно свести к пяти уровням готовности:

1. Неявные полномочия

Агент предполагает, что ему разрешено, исходя из широкого задания на естественном языке.

2. Документированные полномочия

Разрешения записаны, но не применяются системой автоматически.

3. Структурированные полномочия

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

4. Обеспеченные системой полномочия

Система технически блокирует действие за пределами прав или передаёт его на одобрение человеку.

5. Проверяемые и отзываемые полномочия

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

Квалифицированные полномочия

Чтобы полномочия считались:

Квалифицированными полномочиями

они должны отвечать следующим условиям:

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

Квалифицированные полномочия — не указание агенту «делай всё, что потребуется».

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

Так задаются предоставленные права.

Вывод главы

Агент может найти правильную идентичность, подтвердить реальные возможности и выбрать самый подходящий вариант. И всё же он может не иметь права действовать. Правильный выбор не даёт полномочий автоматически. Хорошая цель не разрешает любые способы. Технический доступ — не организационная доверенность. Прежнее одобрение — не постоянные полномочия. Молчание — не согласие. Успешный результат не делает несанкционированный процесс правильным.

Поэтому перед каждым важным действием GBO спрашивает:

Кто разрешил это действие?

И не довольствуется одним именем.

Он спрашивает также:

Имел ли этот человек право предоставлять полномочия? Какое действие он разрешил? Для какой цели? На какой срок? С какими данными? В пределах какой суммы? На каком канале? С каким одобрением человека? Можно ли было передать полномочия другому агенту? Может ли человек их отозвать?

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

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

Поэтому последний вопрос контракта поведения звучит так:

Что будет, если что-то пойдёт не так?

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

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