Когда ответ становится действием

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

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

Теперь представим, что та же система говорит: «Я забронировала столик во втором ресторане на завтра, на 20:00». Если бронирование действительно завершено, система уже не просто ответила: она изменила состояние внешней системы. Сама фраза «я забронировала» ещё не доказывает, что операция состоялась; запись о бронировании нужно проверить отдельно. Столик зарезервирован. Изменилась доступная вместимость ресторана. Возможно, были переданы имя или контактные данные пользователя. Возможно, вступили в силу условия отмены. Возможно, использовались данные банковской карты или была внесена предоплата.

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

Между «нашла» и «сделала» начинается новая эпоха.

Именно между этими словами находится подлинная область GBO.

Ответ и действие — не одно и то же

Когда система ИИ производит информацию, она предлагает описание мира. Когда действует — меняет его. На первый взгляд различие простое. Но с развитием агентных систем граница становится всё менее отчётливой. Подготовить черновик — это ответить или совершить действие?

К чему отнести заполнение формы, если её ещё не отправили?

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

Создать приглашение в календаре — значит лишь предложить вариант?

Как оценивать редактирование файла без публикации?

В чём разница между подготовкой письма и его отправкой?

Запросить предложение от имени компании — значит просто запросить информацию без обязательств или уже начать коммерческие отношения?

Меняется ли мир, когда публикация в соцсети запланирована, но ещё не вышла?

На все эти вопросы нельзя ответить одним «да» или «нет». Действие — не переключатель с двумя положениями. Это лестница. На каждой ступени система чуть ближе подходит к миру. На более высоких ступенях обычно растут обязательства и устойчивость последствий. Но первые ступени не становятся от этого безрисковыми: даже простое чтение данных может затронуть приватность. Поэтому GBO спрашивает не только: «Есть ли здесь действие?»

Есть и другие вопросы:

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

Лестница действия

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

1. Наблюдение

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

2. Интерпретация

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

3. Рекомендация

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

4. Подготовка

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

5. Выполнение

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

6. Принятие обязательств

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

7. Закрепление последствий

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

Зачем нужна лестница действия?

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

Пользователь говорит: «Изучи потенциальных клиентов».

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

«Изучи» не означает «можешь отправлять».

«Подготовь» не означает «можешь публиковать».

«Найди» не означает «можешь связываться».

«Исправь» не означает «можешь выпускать в рабочую среду».

«Спланируй» не означает «можешь тратить деньги».

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

Маленькие движения, меняющие мир

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

Одна кнопка может:

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

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

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

Масштаб не заменяет правильность. Он лишь увеличивает последствия.

Агент может верно рассуждать и неверно действовать

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

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

Действие должно одновременно пройти несколько проверок:

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

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

Точка перехода к действию

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

В работе с электронной почтой — момент нажатия кнопки «Отправить».

В разработке программного обеспечения:

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

В закупках:

Момент подтверждения заказа или платежа.

В работе с социальными сетями:

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

В работе с данными:

Момент передачи информации в стороннюю систему.

В подборе персонала:

Момент, когда кандидату сообщают решение или предложение. По разные стороны границы находятся разные операции с разными последствиями. Названия «черновик», «анализ» или «рекомендация» не отменяют изменения состояния в фоне. Хорошая система GBO не оставляет точку перехода на волю случая. Она обозначает её явно.

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

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

Разовое разрешение не действует вечно

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

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

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

Разрешение всегда связано с контекстом:

• Действие
• Цель
• Объём
• Срок
• Источник
• Объект воздействия
• Риск
• Условие отзыва

Если меняется один из этих элементов, прежнее разрешение может потребовать пересмотра.

Один из основных принципов GBO: полномочия зависят от контекста. Системе не должно быть достаточно фразы «раньше разрешали». На какое действие было дано разрешение?

Когда?

От чьего имени?

В каких пределах?

С какими данными?

До какого результата?

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

Разница между целью и способом

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

Агент может:

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

Но он также способен:

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

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

Точно так же пользователь может сказать: «Сделай сайт одним из сильнейших в мире источников по GEO».

Такая цель может предполагать:

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

и другие подобные способы.

Но та же цель не оправдывает:

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

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

Хорошая цель не оправдывает плохой способ.

Поэтому контракт поведения включает две отдельные составляющие:

• Целевой результат
• Разрешённые и запрещённые способы

Агент должен знать не только куда идти, но и какими путями идти нельзя.

Расширение задачи

У агентов, работающих длительное время, возникает ещё один риск:

Расширение задачи

Система обнаруживает новые подзадачи на пути к главной цели. Часто это полезно. Оптимизируя сайт, она может заметить недостающие языковые страницы. Редактируя описание услуги — обнаружить противоречие в каталоге цен. Во время публикации — выявить проблему с картой сайта. Изучая клиента — понять, что его контакты устарели. Хороший агент не ограничивается одной узкой командой: он видит связанные проблемы, которые нужно решить ради цели. Но у расширения задачи должен быть предел.

Если агент начинал с редактирования контента, а затем перешёл к тому, чтобы:

• менять записи DNS;
• открывать новые аккаунты от имени компании;
• покупать платные услуги;
• отправлять сообщения клиентам;
• переписывать юридические тексты;

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

Расширение задачи можно разделить на три вида:

Необходимое расширение

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

Вспомогательное расширение

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

Расширение полномочий

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

Задача может вырасти. Полномочия не должны расти сами собой.

Большие последствия при кажущемся низком риске

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

Поэтому обратимость нельзя измерять одним вопросом: «Есть ли кнопка, которая возвращает всё как было?»

Нужно различать три уровня возврата:

Технический откат

Может ли система вернуться к прежней версии?

Коммерческая обратимость

Можно ли отменить финансовое, договорное обязательство или обязательство по поставке?

Устранение человеческих последствий

Можно ли действительно устранить воздействие на репутацию, доверие, приватность или отношения?

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

Контур действий

Для каждого агента можно определить:

Контур действий

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

В этот контур входят:

• Системы, к которым разрешён доступ
• Данные, которые разрешено использовать
• Операции, которые разрешено выполнять
• Сумма, которую разрешено потратить
• Люди, с которыми разрешено связываться
• Файлы, которые разрешено менять
• Временной интервал, в котором разрешено работать
• Допустимый уровень риска
• Пороги, требующие одобрения человека
• Способ отмены действия

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

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

Контур действий веб-агента:

Может менять файлы в тестовой среде. Запускать сборку и тесты. Вносить небольшие обратимые исправления в определённой ветке кода. Изменения в рабочей среде, DNS, платежах, юридических текстах и ценах требуют одобрения человека.

Контур действий агента по закупкам:

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

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

Что такое поведенческий триггер?

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

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

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

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

Когда все условия выполнены, действие можно запустить.

Если чего-то не хватает, агент должен выбрать поведение на ступень ниже:

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

Поведенческий триггер GBO — не кнопка убеждения. Это контрольный рубеж безопасности и пригодности для задачи.

Готовность к действию, подкреплённая доказательствами

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

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

Эти элементы — не сумма баллов. Они не компенсируют друг друга. Очень сильные доказательства не закрывают отсутствие полномочий. Высокая известность бренда не устраняет проблему безопасности. Низкая цена не делает неподходящий объём работ подходящим. Хороший API не заменяет разрешение пользователя.

Поэтому в основе логики GBO лежит логическое «И»:

УСЛОВИЯ ПЕРЕХОДА К ДЕЙСТВИЮ:

СООТВЕТСТВИЕ НАМЕРЕНИЮ

И ДОКАЗАТЕЛЬСТВА

И ВОЗМОЖНОСТИ

И ПОЛНОМОЧИЯ

И БЕЗОПАСНОСТЬ

И ОПРЕДЕЛЁННЫЕ ПРАВИЛА ВОЗВРАТА И УСТРАНЕНИЯ ПОСЛЕДСТВИЙ

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

Агент может:

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

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

Когда ответ считается действием?

Для этого вопроса можно предложить практический критерий.

Поведение ИИ — уже не просто ответ, если оно делает хотя бы что-то одно из следующего:

• Создаёт запись во внешней системе
• Отправляет сообщение человеку
• Выделяет деньги или ресурсы
• Передаёт данные
• Меняет файл или состояние системы
• Создаёт обязательство от имени организации
• Посредством операции в системе напрямую меняет варианты, доступные другим людям
• Публикует общедоступное представление
• Посредством операции создаёт юридическое, коммерческое или репутационное обязательство
• Запускает процесс, который будет автоматически работать в будущем

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

Если эти пороги не определены явно, пользователь и агент могут вкладывать разные смыслы в один и тот же глагол.

Незаметные действия

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

Система может:

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

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

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

Цепочка полномочий между агентами

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

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

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

Успешный результат не означает правильного процесса

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

Хороший результат не оправдывает плохой процесс задним числом.

Поэтому оценка включает два отдельных вопроса:

Был ли результат полезен? Было ли действие выполнено с надлежащими полномочиями и по правильной процедуре?

Оба критерия должны быть выполнены.

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

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

Например, если:

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

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

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

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

Квитанция действия

В реальном мире важные операции оставляют запись. Счёт. Платёжный документ. Договор. Номер бронирования. Акт приёма-передачи. Действиям агентов нужна сопоставимая прозрачность.

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

Квитанция действия

Она фиксирует выполненную операцию.

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

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

Например:

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

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

Как измерять качество действия?

Агент может завершить много задач. Но само по себе это ещё не успех.

Качество действия можно измерять по следующим направлениям:

Пригодность для задачи

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

Точность

Были ли верны сведения, на которых основывалось решение?

Полномочия

Был ли агент явно уполномочен выполнить это действие?

Соразмерность

Не вышло ли действие за пределы необходимого для достижения цели?

Безопасность

Были ли защищены данные, деньги, репутация и целостность системы?

Объяснимость

Можно ли показать, почему было выбрано именно это поведение?

Возврат

Можно ли при ошибке остановить действие или устранить его последствия?

Фиксация

Можно ли проверить операцию впоследствии?

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

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

Вот какой вопрос он задаёт.

Неправильное действие — не просто техническая ошибка

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

Но у некоторых неправильных действий причины глубже:

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

Это не только ошибки программного обеспечения.

Это ошибки архитектуры поведения.

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

Какого контрольного рубежа не хватало?

Какое разрешение было неясным?

Какой информации придали неверный вес?

Какое ограничение не передали подчинённому агенту?

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

От эпохи ответов к эпохе действий

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

Её могут применить.

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

Для ответа важны:

• источник;
• неопределённость;
• актуальность;

все эти основания нужно учитывать.

Действие дополнительно требует:

• полномочий;
• определённого объёма;
• соразмерности;
• возможности возврата;
• фиксации;
• возможности для человека возразить;

без этого не обойтись.

Право действовать нужно получить

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

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

• Правильно подтвердить идентичность
• Ясно понять цель пользователя
• Определить подходящий вариант на основании доказательств
• Проверить границы полномочий
• Оценить уровень риска
• Подготовить путь возврата
• При необходимости получить одобрение человека

До завершения этих проверок система не должна действовать лишь потому, что у неё «есть доступ к инструментам».

Уметь пользоваться инструментом — не значит иметь право действовать.

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

Вывод главы

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

Поэтому в эпоху действий главный вопрос уже не ограничивается формулировкой: «Права ли система?»

Нужно спрашивать и другое:

Подходит ли это действие для задачи? Есть ли на него полномочия? Необходимо ли оно? Соразмерно ли? Можно ли его отменить? Может ли человек его остановить? Можно ли проверить его впоследствии?

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

К концу первой части мы уже можем различить три основных порога:

SEO поддерживает обнаружимость. В этой книге GEO рассматривается через условия правильного представления. GBO задаёт границы поведения, основанного на этом представлении.

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

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

Кто ты?

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