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

Представим ошибку при публикации. На сайте компании предстоит существенно обновить цены.

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

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

Цена внесена:

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

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

Можно ли считать проблему полностью решённой, если восстановить старые файлы?

Что, если поисковые системы уже просканировали неверную цену?

Если её прочитала система ИИ?

Если клиент сделал снимок экрана?

Если в разговоре с отделом продаж на основе этой цены уже сложились ожидания?

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

И главный вопрос: почему ошибка прошла контроль перед публикацией?

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

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

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

Учитывать возможность ошибки при проектировании

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

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

Ошибка и вред — не одно и то же

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

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

Ошибка

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

Вред

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

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

Сбой бывает разным

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

Правильная операция с неверной информацией

Агент правильно применяет полученную информацию, но сама она неверна. Например, неправильная цена корректно внесена на все страницы.

Неправильная операция с верной информацией

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

Успешная операция без полномочий

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

Частичное выполнение

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

Повторное выполнение

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

Незаметный сбой

Система сообщает об успехе, но во внешнем мире операция не выполнена. Средство передачи пишет «завершено», хотя часть файлов осталась старой.

Отложенный сбой

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

Каскадный сбой

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

Неудача на человеческом уровне

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

Технический успех ещё не означает реального успеха

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

• HTTP 200
• Сборка успешна
• Файл загружен
• Вызов API принят
• Почтовый сервер получил сообщение
• Платёжный провайдер обработал запрос
• IndexNow принял уведомление

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

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

Проверять нужно и заявления об успехе

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

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

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

Модель может сказать: «Пользователь доволен». Возможно, он просто не ответил.

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

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

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

Сначала остановить, потом объяснять

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

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

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

Безопасная остановка

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

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

Для почтового агента безопасное состояние означает:

Прекратить отправку новых писем, сохраняя входящие без потерь.

Для сайта:

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

Для агента закупок:

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

Для системы аватаров:

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

Для клиентского портала:

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

Что произойдёт, когда агент остановится?

Без ответа на этот вопрос аварийная остановка может стать новой проблемой.

При сбое выбирать безопасную сторону

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

Например:

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

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

Скорость при неопределённости — не надёжность.

Что значит отменить действие?

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

Решение о здоровье или финансах могло уже иметь последствия. Поэтому отмену нужно рассматривать на трёх отдельных уровнях.

Техническая отмена

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

Отмена операции

Можно ли отменить заказ, платёж, бронирование, договор или публикацию?

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

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

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

Иллюзия отмены

Организация может сказать: «Не беспокойтесь, у нас есть резервная копия». Копия важна, но сама по себе она не является планом восстановления.

Резервная копия может:

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

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

GBO спрашивает: какую часть возникших последствий эта отмена действительно обращает вспять?

Лестница необратимости

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

1. Полностью обратимо

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

2. Легко отменить

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

3. Частично обратимо

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

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

5. Вред трудно устранить

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

6. Необратимо

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

Чем выше действие на этой лестнице, тем больше ему нужны:

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

По мере роста необратимости эти требования усиливаются.

С ростом необратимости должна расти ответственность, а не автономия.

Точка возврата

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

Его можно назвать точкой возврата.

Для письма:

До отправки.

Для покупки:

До одобрения платежа.

Для выпуска программного обеспечения:

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

Для публикации в социальной сети:

До того, как она станет публичной.

Для контента с ИИ-аватаром:

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

Окно отмены

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

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

Контрольные точки

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

Их можно назвать контрольными точками.

В веб-проекте контрольная точка может включать:

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

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

В обработке данных можно сохранять:

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

Так фиксируется промежуточное состояние.

В разговоре с агентом можно записывать:

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

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

Защитить главную страницу

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

Для этого система может действовать так:

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

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

Узкой задаче должен соответствовать узкий масштаб воздействия.

Масштаб воздействия

Один из первых вопросов при ошибке: насколько широко распространились её последствия?

Это можно назвать масштабом воздействия.

Ошибка могла затронуть:

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

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

Например:

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

Это можно назвать сокращением масштаба воздействия. Здесь ставится тот же вопрос, что и в принятом в литературе по безопасности подходе blast radius: если что-то пойдёт не так, насколько далеко распространится вред?

Поэтапное внедрение

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

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

• производительность,
• ошибки,
• поведение пользователей,
• безопасность.

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

Безопасность повторных попыток

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

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

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

Как обращаться с частичным успехом?

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

Нужно сказать: «Пять языков готовы. Арабская версия не опубликована, поскольку не прошла проверку RTL». Если платёж проведён, но записи о заказе нет, операцию нельзя закрывать. Если письмо отправлено, а вложение не загружено, результат неполон.

Сообщение о частичном успехе должно показывать:

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

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

Незаметный сбой

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

Собственное заявление исполняющей системы об успехе не должно быть единственным доказательством.

Например:

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

Независимая проверка

Агент что-то делает. Другой метод проверяет результат.

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

Ложное заявление об успехе

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

GBO предпочитает такие формулировки: «Передача файлов завершена; содержимое действующего сайта ещё не проверено». «Уведомление об обходе принято; это не доказательство индексирования». «Тестовая среда прошла проверку; производительность в рабочей среде не измерена». «Запрос предложения отправлен; интерес клиента или результат продажи пока неизвестен». Это различие лежит в основе доверия.

Что такое инцидент?

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

Но ситуацию следует рассматривать как инцидент, если она затрагивает:

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

Воздействие в этих областях требует работы с инцидентом.

Такой тип инцидента можно определить следующим образом:

Инцидент в поведении агента

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

Тяжесть инцидента

Инциденты не одинаковы. Можно использовать практическую классификацию.

Низкая

Небольшая локальная ошибка, которую легко исправить.

Средняя

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

Высокая

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

Критическая

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

Чем выше тяжесть:

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

Первые минуты инцидента

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

1. Выявить

Что произошло на самом деле?

2. Остановить

Прервать продолжающееся действие.

3. Ограничить

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

Не допустить распространения последствий.

4. Сохранить доказательства

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

5. Вернуться в безопасное состояние

К последней проверенной версии или безопасному режиму работы.

6. Уведомить ответственного человека

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

Сохранение доказательств

При возникновении ошибки система должна:

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

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

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

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

Журнал инцидента

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

incident_id

detected_at

detected_by

affected_systems

affected_people

agent_identity

authorization_version

action_receipts

initial_signal

actual_behavior

expected_behavior

impact

containment

rollback

notifications

recourse

compensation

root_cause

contract_change

closed_at

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

Исправление ошибки и устранение вреда — не одно и то же

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

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

Исправление

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

Устранение вреда

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

Компенсирующее действие

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

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

Извинение само по себе не устраняет вред

Система или организация может сказать: «Нам жаль, что это произошло». Это важно.

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

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

Извинение не заменяет ответственности.

Право на оспаривание

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

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

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

Возможность оспаривания

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

Объяснение звучит так: «Мы отказали вам по этой причине».

Возможность оспаривания означает другое: «Если вы считаете решение ошибочным, вы можете представить такие доказательства и запросить пересмотр». Цель GBO не ограничивается объяснимым поведением.

Поведение, которое можно оспорить

Требуется и такая возможность. Объяснённая ошибка остаётся ошибкой. Человек должен иметь возможность повлиять на решение.

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

Действенный порядок оспаривания должен быть:

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

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

Кто может оспорить действие?

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

Право на отзыв

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

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

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

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

Как связаться с человеком

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

Пользователь должен знать:

К кому обращаться? За какое время мне ответят? Будет ли операция приостановлена на время рассмотрения? Какие записи мне нужно предоставить?

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

Кто несёт ответственность?

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

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

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

Например:

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

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

«Это сделал ИИ» — недостаточное объяснение

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

Она не отвечает на вопросы:

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

ИИ не должен становиться ширмой, за которой исчезает ответственность.

Коренная причина

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

Видимая причина:

Агент использовал неправильное число.

Но коренной причиной могло быть одно из следующего:

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

Разбор коренных причин нельзя сводить к вопросу «Почему модель ошиблась в рассуждении?». Нужно исследовать систему целиком.

Пять «почему»

Чтобы разобраться в проблеме, можно несколько раз задать вопрос «почему?». Цепочка ниже — одно из возможных объяснений, а не доказательство коренной причины. Каждое звено нужно сверить с записями и проверить альтернативные причины.

Почему опубликовали неверную цену? Потому что агент перепутал две услуги.

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

Почему её не было? Потому что не существовало единого канонического каталога.

Почему не было такого каталога? Потому что цены хранились только в видимых текстах.

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

Эта цепочка не возлагает всю вину на агента. Она показывает пробел в устройстве системы.

Исправлять контракт, а не только человека

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

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

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

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

Это не снимает ответственности с людей. Но такой подход полезнее, чем наказать человека и оставить систему без изменений.

Обучение и наказание — разные вещи

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

Надёжной организации нужна культура, в которой:

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

Это не культура безответственности. Это культура настоящего обучения.

Предотвращённый инцидент

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

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

Долг восстановления

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

Со временем накапливаются:

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

Эти нерешённые вопросы образуют накопленный долг.

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

Если возможности действий растут, а возможности восстановления — нет, система становится не сильнее, а уязвимее.

Долг по устранению вреда

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

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

Организация может сказать: «Проблема исправлена».

А пострадавший — ответить: «Но мне так и не объяснили, что со мной произошло». GBO различает техническое завершение работы и устранение последствий для человека.

Контракт восстановления и устранения вреда NOMOS

Пятым и последним компонентом контракта поведения станет Контракт восстановления и устранения вреда NOMOS.

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

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

Проще говоря, этот контракт отвечает на вопрос «Что мы будем делать, если что-то пойдёт не так?» ещё до инцидента.

Основные поля контракта

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

action_type

failure_modes

detection_signals

safe_state

automatic_stop_conditions

containment_scope

checkpoint

rollback_method

rollback_window

irreversible_point

human_owner

notification_rules

affected_party_contact

appeal_channel

compensation_policy

evidence_retention

root_cause_review

contract_update

recovery_test_date

version

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

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

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

1. Шлюз обнаружения

Как будет выявлено, что действие пошло не так?

2. Шлюз остановки

Как остановить продолжающуюся операцию?

3. Шлюз ограничения

Как уменьшить масштаб воздействия?

4. Шлюз контрольной точки

Есть ли проверенное состояние, к которому можно вернуться?

5. Шлюз возврата

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

6. Шлюз ответственности человека

Какой человек или какая организация отвечает за инцидент?

7. Шлюз уведомления

Кого, когда и о чём нужно уведомить?

8. Шлюз оспаривания

Как пострадавший сможет оспорить решение или действие?

9. Шлюз устранения вреда

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

10. Шлюз обучения

Какой контракт или элемент системы изменится, чтобы ошибка не повторилась?

В простом виде:

УСЛОВИЯ ОТВЕТСТВЕННОГО ВОССТАНОВЛЕНИЯ:

ОБНАРУЖЕНИЕ

И ОСТАНОВКА

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

И БЕЗОПАСНЫЙ ВОЗВРАТ

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

И УВЕДОМЛЕНИЕ

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

И УСТРАНЕНИЕ ВРЕДА

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

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

Почему Шлюз восстановления должен срабатывать до действия?

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

Поэтому до действия с высоким риском нужно спросить: что произойдёт, если мы ошибёмся?

Если ответа нет, уровень действий следует снизить.

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

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

Человеку должны быть видны:

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

Он должен видеть всё это до решения.

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

Период ожидания для действий с серьёзными последствиями

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

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

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

Пример: публикация сайта

Агент готовит новую страницу услуги на шести языках.

Продуманное восстановление включает следующие шаги:

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

Если обнаружена проблема:

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

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

Пример: электронное письмо

Агент по ошибке отправляет потенциальному клиенту сообщение без полномочий. Технически отозвать его невозможно: письмо уже в ящике получателя.

Надлежащее восстановление может включать:

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

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

Пример: покупка

Агент покупает не тот товар.

Для восстановления нужно выяснить:

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

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

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

Аватар руководителя публикуют с неодобренным текстом.

В таком случае следует:

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

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

Пример: подбор сотрудников

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

Надлежащее восстановление может включать:

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

Такие меры показывают: возврат к прежнему состоянию — не только вопрос состояния системы. На кону и возможности человека.

Пример: сеть агентов

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

Нужно также:

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

Проверка восстановления

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

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

Согласованы ли восстановленные данные?

Действительно ли отозванный ключ API больше не работает?

Доходят ли обращения по каналу оспаривания до реального человека?

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

Учения по восстановлению

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

Примеры учений

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

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

Уровни готовности к восстановлению

Этот подход можно представить в виде пяти уровней готовности:

1. Реактивный

Что делать при проблеме, решают лишь после её возникновения.

2. Документированный

План возврата есть, но его не проверяют регулярно.

3. Техническая обратимость

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

4. Готовность устранить последствия для людей и операций

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

5. Восстановление, готовое к работе с агентами

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

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

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

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

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

Квалифицированное восстановление

Не всякое восстановление отвечает необходимым требованиям.

Квалифицированное восстановление

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

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

Одно лишь восстановление старого файла не является квалифицированным восстановлением.

Не скрывать неудачу

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

Больше доверия вызывает такая формулировка: «В указанный период запись цены этой услуги была опубликована неверно. Ошибка исправлена. Затронутые обращения пересматриваются. Контракт публикации обновлён, чтобы ошибка не распространилась на другие языки и системы».

А такая — снижает доверие: «Небольшой технический сбой устранён». Если проблема заключалась не в техническом сбое, а в неверном коммерческом смысле, неправильно преуменьшать её таким образом.

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

Прозрачность не означает публикацию всего

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

Разумный баланс — достаточно ясно объяснить:

• что произошло;
• какой период затронут;
• какие данные или операции пострадали;
• что сделано;
• какие права есть у человека.

Именно эти сведения должны быть раскрыты в достаточной мере.

Ценность неудачи для GBO

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

Неверная цена

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

Сообщение без полномочий

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

Выбор не той компании

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

Публикация, которую нельзя отменить

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

Пять контрактов работают вместе

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

1. Контракт идентичности

Кто ты?

2. Контракт возможностей

Что ты действительно можешь?

3. Контракт пригодности

При каких условиях следует выбрать тебя?

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

Какое действие и до какого предела ты вправе выполнять?

5. Контракт восстановления и устранения вреда

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

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

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

В простом виде:

ОСНОВНЫЕ УСЛОВИЯ КОРРЕКТНОГО ПОВЕДЕНИЯ АГЕНТА:

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

И РЕАЛЬНАЯ СПОСОБНОСТЬ

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

И ДЕЙСТВИТЕЛЬНЫЕ ПОЛНОМОЧИЯ

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

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

Почему человек по-прежнему в центре?

Потому что вред не ограничивается состоянием системы.

На кону у людей:

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

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

Что правильно сказать, когда что-то пошло не так

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

Это гораздо полезнее, чем «Произошла ошибка». Такая фраза одновременно показывает проблему, поведение и ответственность.

Вывод главы

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

Сильная система:

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

Одним обещанием безошибочности не добиться. А способность к восстановлению можно спроектировать.

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

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

К концу второй части у нас есть всё ядро контракта поведения:

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

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

Первый вопрос будет таким:

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

Готовность к агентам — не просто опубликованный API или надпись «AI-ready» на сайте.

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

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

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

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