Организация, готовая к работе с агентами

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

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

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

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

Готовность к работе с агентами — это не просто:

• доступ к модели;
• окно чата на сайте;
• подключённая почта;
• несколько выданных ключей API;
• надпись «AI-first».

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

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

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

Что означает готовность к работе с агентами?

Организация, готовая к работе с агентами, — не просто та, о которой системы ИИ могут найти информацию.

Такая организация:

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

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

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

Опубликовать API недостаточно

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

Поэтому организации могут оценивать свою готовность по техническим подключениям: «У нашей системы есть API». «Агент подключается к почте». «Интеграция календаря готова». «Мы дали доступ к CRM». Для конкретного процесса эти связи могут быть необходимы, но сами по себе они недостаточны. Наличие двери не означает, что её следует открывать при любых обстоятельствах. Агент может уметь создавать карточку клиента, но не должен повторно регистрировать того же человека. Он может отправлять приглашения на встречу, но должен знать часовой пояс участника, цель встречи и иметь его явное одобрение. Он может подготовить ценовое предложение.

Но не должен превращать индивидуальную скидку руководителя продаж в общее правило.

API отвечает на вопрос: «Как технически выполнить эту операцию?»

GBO задаёт и другие вопросы:

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

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

Организация должна знать собственные факты

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

Сначала организация должна разобраться в себе.

Необходимы ясные ответы на вопросы:

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

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

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

Шесть основ готовности организации к работе с агентами

В этой книге я рассматриваю подготовку организации через шесть основ:

1. Основа достоверных сведений

2. Основа идентичности

3. Основа возможностей и пригодности

4. Основа полномочий

5. Основа действий и доказательств

6. Основа восстановления

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

1. Основа достоверных сведений

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

Основа достоверных сведений отвечает на вопросы:

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

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

Что означает единый достоверный источник?

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

Например:

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

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

Единый достоверный источник — не один файл, а одна авторитетная точка обращения для каждого факта.

За сведения должен кто-то отвечать

Информация может присутствовать в системе, хотя никто не знает, кто обязан поддерживать её актуальность. Кто меняет цену?

Кто утверждает объём услуги?

Кто обновляет часы работы?

Кто отзывает полномочия агентов?

Кто решает, оказывать ли услуги в определённой стране?

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

Ответственный за сведения обязан:

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

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

Срок актуальности сведений

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

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

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

Примеры статусов:

• Черновик
• Ожидает одобрения
• Активна
• Ограничена
• Срок истёк
• Отменена
• Архивная

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

Наличие записи не означает, что она действительна.

2. Основа идентичности

Основа идентичности связывает организацию, её людей, бренды, агентов и официальные каналы.

У организации могут различаться:

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

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

Основа идентичности включает как минимум:

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

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

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

Но на уровне организации вопросы могут оставаться без ответа:

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

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

agent_id

public_name

technical_identity

operator

human_owner

purpose

connected_systems

accessible_data

allowed_actions

prohibited_actions

approval_thresholds

subagents

valid_from

valid_until

shutdown_method

last_reviewed

status

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

Теневые агенты

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

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

Но организация не знает:

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

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

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

Как агент представляет себя

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

Но пользователь должен понимать:

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

Например, вводный текст, иллюстрирующий подход этой книги, мог бы выглядеть так. Это не заявление о полномочиях существующего работающего ассистента: «Этот ассистент предоставляет общие сведения об услугах от имени NobleJackal и может подготовить запрос на встречу. Цены, юридические обязательства и окончательное принятие проекта требуют одобрения уполномоченного человека». Такое пояснение не ослабляет агента. Оно делает границы его поведения видимыми.

3. Основа возможностей и пригодности

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

Для каждой услуги следует раскрыть:

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

Все эти сведения должны быть понятны.

Их можно вести в реестре возможностей и пригодности.

Названия услуги недостаточно

«ИИ-автоматизация» может быть названием услуги.

Но из него агент не узнает:

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

Организация, готовая к работе с агентами, превращает название услуги в контракт поведения.

Каноническая запись об услуге

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

service_id

service_name

provider_identity

outcome

target_users

supported_use_cases

unsupported_use_cases

required_inputs

deliverables

scope_included

scope_excluded

pricing_model

starting_price

third_party_costs

supported_languages

supported_regions

capacity_status

estimated_start

evidence

quality_criteria

human_approval

failure_behavior

version

validity

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

Ясно определить, кому услуга не подходит

В записи нужно указать и тех, для кого услуга не предназначена.

Например:

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

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

Состояние доступных ресурсов

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

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

service_id

availability_status

accepting_new_work

earliest_start

capacity_band

last_updated

expires_at

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

Если ресурсы неизвестны, следует сказать: «Услуга предоставляется; возможную дату начала нужно уточнить».

4. Основа полномочий

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

Основа полномочий включает:

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

Ролевых полномочий может быть недостаточно

Организация может сказать: «Агент продаж имеет доступ к операциям продаж». Это слишком широко.

Такие операции могут включать:

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

Это не одни и те же полномочия. Их необходимо разделять по типам действий.

Матрица полномочий

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

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

Точки передачи человеку

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

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

Примеры:

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

Точку передачи человеку нельзя оставлять неопределённой, как в указании «спроси, если есть риск». Её следует описать максимально ясно.

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

Запрашивая одобрение, агент не должен ограничиваться вопросом «Продолжать?»

Он должен показать:

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

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

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

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

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

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

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

5. Основа действий и доказательств

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

Основные элементы этой основы:

• Каталог действий
• Предварительные условия
• Проверка входных данных
• Квитанция действия
• Независимая проверка
• Измерение
• Версионирование
• Хранение доказательств

Каталог действий

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

Например:

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

Для каждого действия нужны сведения:

• Необходимые входные данные
• Уровень полномочий
• Одобрение человека
• Уровень риска
• Ожидаемый результат
• Доказательство успеха
• Способ отмены

Условия завершения действия

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

Для публикации сайта условия завершения могут включать:

• Файлы переданы
• Хеши на удалённом сервере совпадают
• HTML на рабочем сайте корректен
• Канонические и языковые ссылки прошли проверку
• Мобильный и настольный вид проверены
• Критических ошибок нет
• Пакет для отката доступен

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

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

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

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

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

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

action_id

action_type

requested_by

performed_by

target

purpose

authorization

inputs_used

data_shared

started_at

completed_at

technical_result

real_world_verification

human_approval

rollback_status

open_uncertainties

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

Иерархия доказательств

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

Например, при публикации сайта:

• Команда выполнена успешно.
• Сервис передачи принял загрузку.
• Хеш файла на удалённом сервере совпал.
• Проверен ответ рабочего сайта по HTTPS.
• Настоящий браузер правильно отобразил страницу.
• Поисковый робот смог получить к ней доступ.
• Поисковая система проиндексировала страницу.
• Страница стала заметна по определённому запросу.
• Пользователь совершил действие, появился коммерческий результат.

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

Принятое уведомление — не индексация. Индексация — не позиция в поиске. Позиция в поиске — не клиент. Обращение клиента — не выручка.

Язык описания доказательств должен сохранять эти различия.

Принцип независимой проверки

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

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

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

6. Основа восстановления

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

На случай ошибки она заранее определяет:

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

Эти решения принимаются до инцидента.

Основа восстановления включает:

• Классификацию инцидентов
• Безопасное состояние
• Аварийную остановку
• Контрольные точки
• Резервную копию и откат
• Журнал инцидента
• Ответственного человека
• Уведомление
• Оспаривание
• Устранение вреда
• Первопричину
• Обновление контракта

Остановить агента и остановить систему — не одно и то же

Центрального агента можно отключить.

Но могут продолжить работу:

• Субагенты
• Запланированные задачи
• Очереди писем
• Внешние автоматизации
• Подписки
• Файловые операции

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

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

Последнее безопасное состояние

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

Реестр контрактов поведения

Пять контрактов, разработанных в главах 4–8, внутри организации следует вести совместно.

Это можно назвать реестром контрактов поведения.

Реестр объединяет:

• Контракт идентичности
• Контракт возможностей
• Контракт пригодности
• Контракт полномочий
• Контракт восстановления и устранения вреда

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

Контракт поведения не статичен

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

При каждом изменении необходимо знать:

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

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

Контракт должен соответствовать реальному поведению

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

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

Поэтому нужно сопоставить две стороны:

Заявленные полномочия

То, что написано в политике.

Технически доступные полномочия

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

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

Обеспечивать правила технически

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

Например:

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

Инструкции важны. Но при высоком риске технический контроль надёжнее.

Слова агента «Я не должен» и ограничение системы «Ты не можешь» дают разный уровень уверенности.

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

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

Более устойчивый подход — определить:

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

Инструмент может смениться. Принцип поведения остаётся.

Распределение задач между человеком и агентом

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

Например:

В чём сильны агенты

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

Где центральная роль остаётся у человека

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

Это разделение не абсолютно, но полезно при проектировании работы.

Задача человека — не только одобрять

Было бы ошибкой свести человека к кнопке «Да».

Человек определяет:

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

Агент не должен создавать весь этот контекст самостоятельно.

Задача агента — не только ускорять

Агент даёт организации не только более быстрое выполнение операций.

При правильном использовании он может обеспечить:

• Согласованность
• Прослеживаемость
• Постоянный аудит
• Совпадение фактов в разных языковых версиях
• Воспроизводимое качество
• Раннее обнаружение ошибок

Ценность агента нельзя измерять только сокращением человеческого труда.

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

Данные, готовые для работы агентов

Данные организации должны быть пригодны для использования агентами. Но подход «соберём всё в одном месте» может быть опасен.

Данные должны быть:

• Достоверными
• Актуальными
• С известным источником
• Классифицированными
• С контролируемым доступом
• Ограниченными целью использования
• Удаляемыми при необходимости
• С возможностью регистрации использования

Все эти требования относятся к готовности данных.

Классы данных

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

• Общедоступные
• Внутренние
• Конфиденциальные
• Персональные
• Чувствительные
• С юридическими ограничениями
• Недоступные для использования агентами

У агента не должно быть одинаковых полномочий для всех классов данных.

Принцип минимально необходимых данных

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

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

Происхождение данных

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

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

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

Правила работы с неопределённостью

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

Что должен сделать агент:

• Предположить?
• Задать вопрос?
• Подготовить черновик?
• Запросить одобрение человека?
• Остановить задачу?

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

Бюджет неопределённости

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

Назовём это бюджетом неопределённости.

Например:

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

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

Управление изменениями

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

При изменении цены необходимо совместно пересмотреть:

• Страницу сайта
• Каталог услуг
• FAQ
• Schema
• Шаблон предложения
• Сведения, которыми пользуется агент продаж

Эти источники необходимо проверить вместе.

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

Небольшое изменение — серьёзные последствия для поведения

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

Но она может затронуть:

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

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

Версионирование

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

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

Без измерения готовность нельзя доказать

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

Примеры сценариев:

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

Тесты не должны состоять только из положительных сценариев. Нужно измерять и способность системы говорить «нет».

Негативные тесты

Организации, готовой к работе с агентами, следует проверять, например, следующее:

Что произойдёт, если пользователь оставит границы задачи неясными?

Какую цену выберет агент, если устаревшая запись заметнее?

Что, если неуполномоченный сотрудник даст поручение об оплате?

Если субагент запросит более широкий доступ?

Если срок записи о согласии истёк?

Если две услуги названы похоже?

Если внешний источник противоречит каноническому?

Если путь возврата не работает?

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

Долг готовности к работе с агентами

Организация может быстро начать пользоваться агентами.

При этом:

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

Технология движется вперёд, а управление отстаёт.

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

Признаки долга готовности

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

Больше агентов в неподготовленной организации

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

Увеличение числа агентов не заменяет недостающее управление.

Иногда правильнее не добавлять агента, а упростить существующую систему поведения.

Важна целостность поведения, а не число агентов

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

Потому что важно:

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

Пять уровней готовности организации к работе с агентами

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

Уровень 1 — Подключение

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

Уровень 2 — Определённость

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

Уровень 3 — Контракты

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

Уровень 4 — Обеспечение правил

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

Уровень 5 — Проверяемость и обучение

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

Заблуждения о готовности к агентам

«У нас отличный сайт. Мы готовы».

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

«Вся наша информация в облаке».

Доступность сведений не означает их точности, актуальности или авторитетности.

«Модель очень мощная».

Мощность модели не устраняет отсутствие организационных контрактов.

«Человек и так всё контролирует».

Что, когда и на основании каких сведений он контролирует?

Если это неясно, одобрение может быть лишь ритуалом.

«При ошибке отключим».

Как?

Остановятся ли также субагенты, запланированные задачи и внешние системы?

«Агент только рекомендует».

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

Клиентский интерфейс, готовый к агентам

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

Клиент или его агент должны иметь надёжный доступ к следующим сведениям:

• Идентичность организации
• Объём услуги
• Способ ценообразования
• Необходимые входные данные
• Условия пригодности
• Границы поддержки
• Контакт человека
• Согласие и использование данных
• Порядок выполнения и отмены операции
• Дата актуализации

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

Готовность к агентам — не манипуляция

Организация может устроить себя так, чтобы агенты выбирали её чаще. Это легко превращается в манипуляцию. Цель GBO — не украшать сигналы.

Готовность к агентам означает:

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

В этом и состоит её смысл.

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

Пример организации: от разрозненности к готовности

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

Исходное состояние:

• Более 40 услуг
• Несколько языков
• Разные форматы цен
• Старые и новые страницы
• Несколько агентов
• Автоматизации почты, сайта, социальных сетей и поиска клиентов
• Разрозненные записи о полномочиях

Если компания просто добавит нового агента, риск возрастёт.

Преобразование можно провести в следующем порядке:

1. Перечень услуг

Выявить реальные услуги, цены и объёмы работ.

2. Каноническая запись

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

3. Многоязычная согласованность

Каждый язык должен звучать естественно и передавать те же факты.

4. Разделение ролей агентов

Разделить агентов сайта, почты, социальных сетей, SEO/GEO и исследования потенциальных клиентов.

5. Границы полномочий

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

6. Контрольные точки качества

Ввести проверки сборки, семантики, настоящего браузера, хешей на рабочем сайте и эффективности.

7. Запись измерений

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

8. Стабилизация

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

Практический путь на первые девяносто дней

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

Дни 1–30 — Упорядочить факты

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

Дни 31–60 — Закрепить поведение в контрактах

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

Дни 61–90 — Испытать и обеспечить границы

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

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

Контракт готовности организации к работе с агентами NOMOS

Главный результат этой главы — Контракт готовности организации к работе с агентами NOMOS.

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

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

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

Шлюз готовности организации к работе с агентами

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

1. Шлюз достоверных сведений

Известны ли канонические сведения, ответственные за них и их версии?

2. Шлюз идентичности

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

3. Шлюз возможностей

Ясны ли реальные услуги, входные данные, объём работ и доказательства?

4. Шлюз пригодности

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

5. Шлюз полномочий

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

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

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

7. Шлюз действий

Определены ли пути операций, условия завершения и квитанции?

8. Шлюз проверки

Проверяют ли агента независимо от его собственного заявления об успехе?

9. Шлюз восстановления

Работают ли механизмы остановки, возврата, оспаривания и устранения вреда?

10. Шлюз человеческой ответственности

Есть ли реальный человек, отвечающий за каждое критическое действие?

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

ГОТОВНОСТЬ ОРГАНИЗАЦИИ К РАБОТЕ С АГЕНТАМИ =

КАНОНИЧЕСКИЕ ФАКТЫ

И ПРАВИЛЬНАЯ ИДЕНТИЧНОСТЬ

И ЯСНЫЕ ВОЗМОЖНОСТИ

И ПРОВЕРЕННАЯ ПРИГОДНОСТЬ

И ПОЛНОМОЧИЯ С ОБЕСПЕЧЕННЫМИ ГРАНИЦАМИ

И ОГРАНИЧЕННЫЕ ДАННЫЕ

И ЗАФИКСИРОВАННОЕ ДЕЙСТВИЕ

И НЕЗАВИСИМАЯ ПРОВЕРКА

И ПРОВЕРЕННОЕ ВОССТАНОВЛЕНИЕ

И ОТВЕТСТВЕННОСТЬ ЧЕЛОВЕКА

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

Например, работу можно ограничить:

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

Так можно ограничить режим действий.

Готовность к агентам — уровень полномочий, а не балл

Организация может заявлять о готовности на 80%.

Но если недостающие 20% относятся к критическим областям, таким как:

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

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

Пока критический шлюз не пройден, общая оценка не создаёт права на действие.

Когда организация может дать агенту больше свободы?

Более самостоятельная работа агента возможна, когда:

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

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

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

Коммерческая ценность готовности к агентам

Эта перестройка нужна не только для безопасности.

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

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

Готовность к агентам — не только подготовка к будущим технологиям. Это уменьшение сегодняшней организационной разрозненности.

Организация, не готовая к людям, не готова и к агентам

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

Ясность для машины не заменяет ясность для человека. Она её требует.

Двадцать пять вопросов для проверки готовности организации

• Какова каноническая идентичность организации?
• Ясна ли связь бренда с юридическим оператором?
• Все ли действующие агенты включены в реестр?
• Известен ли человек, отвечающий за каждого агента?
• Известны ли подключённые к агентам системы и данные?
• Есть ли канонический источник каждого важного вида информации?
• Согласованы ли сведения о цене, объёме работ и услугах?
• Отделены ли старые или отозванные записи от текущих?
• Понятны ли реальный результат и необходимые входные данные каждой услуги?
• Ясно ли, что входит в объём работ, а что исключено?
• Определены ли условия для подходящих и неподходящих клиентов?
• Актуальны ли сведения о ресурсах и доступности?
• Разделены ли полномочия людей и агентов по типам действий?
• Разделены ли полномочия на подготовку черновиков, отправку, публикацию и принятие обязательств?
• Известны ли точки передачи человеку?
• Обеспечиваются ли границы полномочий технически?
• Получает ли агент доступ только к необходимым данным?
• Определено ли, как он действует при неопределённости?
• Создаёт ли каждое значимое действие квитанцию?
• Отделяется ли технический успех от реального результата?
• Есть ли независимая проверка?
• Есть ли последнее безопасное состояние и путь возврата?
• Можно ли вместе остановить субагентов и запланированные задачи?
• Доступен ли людям понятный путь оспаривания и устранения вреда?
• Пересматривается ли контракт поведения после инцидентов и обновляется ли при необходимости?

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

Вывод главы

Готовность к работе с агентами — не подключение ИИ-системы к компании.

Она означает:

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

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

Без надлежащего организационного порядка агент может:

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

Сама по себе сила агента — не зрелость.

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

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

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

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

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

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

Как измерять квалифицированное действие?

Потому что хорошее поведение — это:

• не только действие;
• не только успех;
• не только удовлетворённость пользователя.

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

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