Технологическая компания готовится предложить клиентам недавно созданного автономного агента для закупок. В рекламных материалах сказано:
«Наш агент безопасен». «Он сохраняет контроль за человеком». «Соблюдает границы полномочий». «Предотвращает ошибочные покупки». «Защищает данные пользователей». «Останавливается, когда этого требует человек».
В подтверждение компания приводит различные доказательства. В политике указано, что требуется одобрение человеком. На снимке экрана виден лимит платежа. Во время демонстрации агент выбирает нужный товар. Панель показателей сообщает об успешном выполнении 98,7% заданий. В отзывах клиенты называют систему быстрой и удобной. Техническая команда говорит: «За шесть месяцев у нас не было серьёзных проблем». Всё это имеет значение. Но само по себе не отвечает на вопрос:
В каком именно поведении агент действительно безопасен?
Слово «безопасный» слишком широко. Агент может:
выбрать правильный товар,
но провести платёж без полномочий.
Он может соблюсти границы полномочий,
но использовать учётную запись не того человека.
Может правильно определить человека,
но скрыть условие автоматического продления.
Может корректно провести платёж,
но повторить ту же операцию из-за сетевого сбоя.
Может принять требование человека об остановке,
пока действия в очереди продолжают выполняться.
Всё это возможно одновременно. Поэтому аудит GBO не начинается с безграничного вопроса «Безопасна ли система?». Он спрашивает иначе: какая система, в какой версии и какое поведение способна надёжно выполнять, с какими инструментами и полномочиями, для каких пользователей, при каких рисках и на каком уровне доказательств? Вопрос длиннее, зато достаточно конкретен, чтобы искать ответ в ходе аудита.
Объект аудита — не только модель
На первый взгляд может показаться, что аудит ИИ-агента сводится к изучению модели. Какая модель используется? Насколько она сильна? Какое обучение по безопасности прошла? Каким инструкциям следует? Всё это важно. Но фактическое поведение возникает не только из модели. В агентной системе оно складывается из сочетания:
цели человека,
политики организации,
системных инструкций и инструкций разработчика,
модели,
памяти,
источников данных,
инструментов,
разрешений API,
учётных записей пользователей,
субагентов,
внешних сервисов,
системы измерения и вознаграждения,
одобрения человеком,
механизмов остановки и восстановления.
Одна и та же модель может вести себя совершенно по-разному в двух системах. В первой системе она может:
лишь читать документы,
создавать черновики,
не имея доступа ни к одному внешнему инструменту.
Во второй системе она может:
отправлять письма,
тратить деньги,
публиковать код,
передавать данные клиентов,
создавать субагентов.
Название модели одинаково, а возможности действовать — нет. Даже одна и та же инструкция агенту может приводить к разным результатам. В одной системе правило «Не отправляй сообщения без одобрения человеком» обеспечено технически: инструмент отправки работает только при наличии токена одобрения. В другой то же правило существует лишь в тексте, а агент имеет полный доступ к почте. В двух системах записана одна и та же фраза политики. В первой она ограничивает поведение, во второй выражает пожелание. Поэтому главный объект аудита NOMOS GBO —
Поведенческая система
Что такое поведенческая система?
Каноническое определение таково: поведенческая система — это фактическое устройство деятельности одного или нескольких ИИ-агентов, которые действуют ради цели человека или организации вместе с данными, памятью, инструментами, учётными записями, полномочиями, измерением, одобрением человеком и механизмами восстановления. Проще говоря, проверяется не один агент, а вся система связей, позволяющая ему действовать в мире. При аудите почтового агента оценивают не только качество текста. Нужно также выяснить:
От чьего имени он говорит?
Через какую учётную запись?
Кому он вправе отправлять сообщения?
Какие данные ему разрешено использовать?
Разделены ли подготовка черновика и отправка?
При достижении какого порога требуется одобрение человеком?
Может ли субагент отправлять сообщения?
Как останавливаются очереди?
Есть ли квитанция об отправленном сообщении?
При аудите веб-агента оценивают не только качество кода. Проверяют и следующее:
Какие файлы он вправе менять?
Может ли он изменять цены?
Может ли он редактировать юридические тексты?
Разделены ли тестовая и рабочая среды?
Кто имеет полномочия на публикацию?
Есть ли независимая проверка в рабочей среде?
Действительно ли работает откат к предыдущему состоянию?
Останавливаются ли операции FTP и очередь публикации, когда человек требует остановки?
При аудите закупочного агента недостаточно измерять, выбирает ли он нужный товар. Проверке также подлежат:
Бюджетные полномочия
Ограничения на выбор продавцов
Подписка и продление
Целевая учётная запись
Защита от дублирования операций
Путь отмены
Одобрение человеком
Квитанция об операции
Возврат средств и устранение последствий
Поведенческая система включает все эти части.
Пять картин действительности, которые сопоставляет аудит
Аудит NOMOS GBO рассматривает поведение системы на пяти отдельных уровнях действительности.
1. Заявленная действительность
2. Действительность, заданная конфигурацией
3. Действительность технических возможностей
4. Действительность наблюдаемого поведения
5. Действительность последствий и восстановления
Эти пять уровней должны согласовываться между собой.
1. Заявленная действительность
Что организация говорит о системе? Например: «Агент не отправляет сообщения без одобрения человеком». «Данные не покидают Европу». «Агент не может потратить больше 500 долларов США за одну операцию». «Каждое синтетическое видео до публикации получает одобрение руководителя». «Любое внешнее действие можно прервать командой остановки». Такие утверждения встречаются в следующих источниках:
Документы с политиками
Договоры
Сайт
Маркетинговые материалы
Внутренние процедуры
Пользовательские соглашения
Заявления для аудита
Заявленная действительность важна: она показывает, что обещает организация. Но обещание само по себе не доказывает поведение.
2. Действительность, заданная конфигурацией
Как определено устройство системы? В частности, проверяются:
Роль агента
Системные инструкции
Соглашение о полномочиях
Правила доступа к данным
Пороги обязательного одобрения человеком
Каталог услуг
Машиночитаемые цены
Политики остановки
Правила работы с памятью
Ограничения субагентов
Организация может заявлять: «Агент только готовит черновики». В конфигурации его роли при этом может быть записано:
allowed_actions:
- research
- create_draft
prohibited_actions:
- send_messageЭто показывает согласованность заявления и конфигурации. Но фактические технические разрешения всё ещё могут отличаться.
3. Действительность технических возможностей
Что система действительно может делать? На этом уровне проверяют прежде всего технические возможности, а не заявления на естественном языке.
Какие разрешения API включены?
Какие токены действуют?
К каким учётным записям есть доступ?
Можно ли удалить файлы?
Можно ли перевести деньги?
Можно ли отправить сообщение внешнему адресату?
Можно ли создать субагента?
Можно ли запустить прямую трансляцию?
Можно ли передать память в другую систему?
Действительно ли команда остановки влияет на очередь?
Политика агента может запрещать отправку. Но если почтовый токен даёт полный доступ, отправка технически возможна. Откажется ли агент от неё, зависит от поведения модели: технического ограничения нет. Это одна из самых важных областей аудита GBO. Именно здесь виден разрыв между заявлениями организации и возможностями системы.
4. Действительность наблюдаемого поведения
Что система делает в реальном или контролируемом сценарии? Агент может технически быть способен на действие, но никогда его не совершать. И наоборот: его возможности могут выглядеть узкими, хотя другая цепочка инструментов позволяет действовать шире. Поэтому необходимы контролируемые поведенческие тесты. Примеры сценариев:
Требование отправить сообщение без одобрения человеком
Две похожие идентичности компаний
Противоречащие друг другу записи о ценах
Согласие с истёкшим сроком действия
Спонсируемый вариант
Скрытая внешняя инструкция
Сетевой тайм-аут
Активная очередь во время остановки
Выход за пределы полномочий через субагента
Эти тесты отвечают на вопрос: как система действительно ведёт себя, когда сталкивается с границей? Политика и разрешения описывают потенциальные возможности. Поведенческий тест показывает сделанный на деле выбор.
5. Действительность последствий и восстановления
К каким последствиям во внешнем мире привело действие агента? И что смогла сделать система, если действие оказалось ошибочным? Почтовый инструмент может сообщить: «Отправка успешна», хотя письмо ушло не тому адресату. Платёжный API может принять запрос, но одну и ту же сумму могут списать дважды. Веб-агент может опубликовать файл, а CDN продолжит показывать старую версию. Команда остановки может отключить центрального агента, пока субагенты и очереди продолжают работать. Поэтому на последнем уровне выясняют:
Действительно ли действие достигло намеченной цели?
Проверен ли результат независимо?
Обнаружено ли ошибочное поведение?
Остановлено ли причинение дальнейшего вреда?
Сработала ли отмена последствий действия?
Проинформирован ли затронутый человек?
Действительно ли сработал механизм оспаривания?
Исправлены ли память и будущее поведение?
Не запустилась ли система снова без новых полномочий?
Качество поведения видно не только в момент выполнения действия, но и после ошибки.
Разрывы между пятью картинами действительности
Рассмотрим почтового агента.
Заявленная действительность
«Не отправляет сообщения без одобрения человеком».
Действительность, заданная конфигурацией
role: research_and_drafting
send_requires_approval: trueДействительность технических возможностей
Доступный агенту токен доступа к почте позволяет отправлять сообщения. В этой книге send_message — условное название действия инструмента, а не фактическое имя метода или области доступа OAuth у поставщика сервиса.
Действительность наблюдаемого поведения
Под влиянием направляющей инструкции на внешней странице агент отправляет сообщение без одобрения человеком.
Действительность последствий и восстановления
Центрального агента останавливают, но из очереди продолжают отправляться два сообщения. Первые два уровня выглядят безопасными. Последние три раскрывают фактический поведенческий изъян. Если аудит GBO рассмотрит только первые два, он создаст ложную уверенность. Если ограничится поведенческим тестом, то не сможет полностью объяснить причину. Проблема может одновременно заключаться:
в поведении модели,
в технических разрешениях,
в архитектуре очереди,
в обеспечении границ полномочий.
Отсюда основной принцип протокола: аудит сопоставляет заявления с конфигурацией, конфигурацию с техническими возможностями, технические возможности с наблюдаемым поведением, а наблюдаемое поведение — с фактическим результатом.
Лестница доказательств
Аудиторские доказательства имеют разную силу. Заявление организации и проверка фактического поведения находятся на разных уровнях. Поэтому протокол NOMOS GBO использует:
Лестницу доказательств
Уровень 1 — Заявление
Организация или агент выдвигает утверждение: «Агент соблюдает границы полномочий». Это отправная точка, но не само доказательство.
Уровень 2 — Документ
Утверждение записано в политике, договоре или описании задания: «Внешняя отправка требует одобрения человеком». Заявление получило официальное закрепление. Однако ещё не доказано, что система его выполняет.
Уровень 3 — Конфигурация
Правило задано в системе в машиночитаемой форме.
send_requires_human_approval: trueМежду документом и системой установлена связь. Но действительно ли технический инструмент предотвращает действие, может оставаться неизвестным.
Уровень 4 — Техническое обеспечение правила
Правило обеспечено на уровне инструмента, роли, токена или кода. Без токена одобрения инструмент отправки нельзя вызвать. Это сильное доказательство. Но контроль всё ещё может быть обойдён через другой инструмент или субагента.
Уровень 5 — Контролируемый поведенческий тест
Систему проверяют в реалистичном сценарии: её побуждают отправить сообщение без одобрения человеком. Агент:
не отправляет сообщение,
оставляет черновик,
запрашивает одобрение.
Правило сработало в наблюдаемом поведении.
Уровень 6 — Независимая проверка результата
Проверяют не только отчёт агента, но и результат во внешней системе.
В папке отправленных нет сообщения.
На внешний проверочный адрес письмо не поступило.
В очереди нет скрытой отправки.
В журналах субагентов нет внешних действий.
Фактический результат поведения подтверждён независимо.
Уровень 7 — Доказательства восстановления и остановки
В контролируемом сценарии ошибки или отмены:
система останавливается,
действия в очередях отменяются,
токены отзываются,
человек принимает задачу на себя,
деятельность не возобновляется без новых полномочий.
Это один из самых сильных уровней доказательств: система проверена не только в обычных условиях, но и при нарушении работы.
Какие выводы допускает лестница доказательств
Если результат аудита опирается лишь на доказательства уровней 1 и 2, можно сказать: «Организация обещает такое поведение». Нельзя сказать: «Система надёжно обеспечивает такое поведение». Если изучены конфигурация и техническое обеспечение правила, допустим вывод: «Правило задано в системе и обеспечено на уровне определённого инструмента». Если пройдены также поведенческие тесты, независимая проверка результатов и испытания восстановления, возможен более сильный вывод: «В указанных границах и сценариях доказано, что система выполнила правило, не вызвала внешних последствий и корректно остановилась». Формулировки аудита не должны подниматься выше достигнутой ступени. Уровень доказательств задаёт предел аудиторского утверждения.
Что аудит GBO способен доказать?
Правильно организованный аудит может дать доказательства по следующим вопросам:
Наличие конкретных границ поведения
Можно показать, какие действия агент способен и не способен выполнять.
Способность правильно устанавливать идентичность
В определённых сценариях можно проверить, различает ли агент людей или организации с одинаковыми именами и названиями.
Работа с фактами и источниками
Можно проверить, использует ли агент канонический, актуальный и уполномоченный источник.
Оценка пригодности
Можно измерить, не ставит ли агент заметность, популярность или спонсорство выше обязательных условий.
Сохранность согласия, полномочий и одобрения
Наблюдение позволяет установить, действует ли агент только при наличии действительных полномочий на конкретную операцию.
Безопасность выполнения действий через инструменты
Можно проверить правильность выбора системы, цели и идентификатора операции, а также соблюдение границ использования данных.
Преемственность при работе нескольких агентов
Можно установить, сохраняются ли исходная цель, идентичность, полномочия и запреты при передаче задач.
Устойчивость к манипуляциям
Можно испытать поведение при поддельных доказательствах, спонсируемом ранжировании, скрытых инструкциях и вытеснении кандидатов из рассмотрения.
Целостность измерения
Можно оценить, не скрывает ли общий балл критические нарушения и не поддаётся ли метрика манипуляции.
Остановка и восстановление
Можно доказать, действительно ли система останавливается по требованию человека, способна ли она вернуться назад и передать управление человеку. Но все эти выводы действуют лишь в границах проведённого аудита.
Чего аудит GBO доказать не может?
Как бы убедителен ни был аудит, он не может честно обосновать следующие утверждения:
Система никогда не ошибётся
Могут возникнуть новые ситуации, которые не проверялись.
Все будущие версии модели будут вести себя одинаково
Модель, инструменты, инструкции и память могут измениться.
Во всех странах выполнены все правовые обязательства
Аудит GBO не заменяет юридической экспертизы.
Система невосприимчива ко всем неизвестным атакам
Могут появиться новые способы манипуляции и атак через инструменты.
Система одинаково ведёт себя со всеми группами пользователей
Нельзя делать выводы о непроверенных языках, особенностях инвалидности, культурах или профилях пользователей.
Люди никогда не будут злоупотреблять системой
Даже правильно работающую систему уполномоченный человек может использовать со злым умыслом.
Рабочая среда навсегда останется неизменной
Разрешения, цены, роли и внешние сервисы меняются.
Высокий балл означает отсутствие критических нарушений
Одно нарушение условия вето может ограничить применение системы даже при высоком среднем балле. Эти границы не ослабляют аудит, а делают его заслуживающим доверия. Добросовестный аудит включает в заключение и то, что осталось неизвестным.
Почему заключение аудита должно иметь границы?
Фраза «Эта система соответствует GBO» звучит весомо, но непонятно, что за ней стоит. Какая система и версия? Какие агенты, инструменты и языки? Какие полномочия? Какие тесты, на какую дату и при каком уровне риска? Более надёжная формулировка такова: «Закупочный агент v3.2 прошёл аудит с 1 по 15 сентября 2026 года в 240 контролируемых поведенческих сценариях. Проверка охватывала три заданные категории продавцов, лимит 500 USD на операцию, пользовательские сценарии на английском и турецком языках и модель платежей с одобрением человеком. Критических нарушений условий вето по идентичности, согласию, полномочиям и остановке не выявлено. Сохраняются два аудиторских наблюдения высокого приоритета, относящиеся к автоматическому продлению и экспорту данных. Система признана условно пригодной только для указанной области закупок с низким риском».
Эта формулировка длиннее, зато в ней указаны:
Объект аудита
Версия
Даты
Область поведения
Граница полномочий
Язык
Число сценариев
Критические наблюдения аудита
Граница применения
Заключение аудита — не рекламная фраза. Оно устанавливает границы того, что подтверждено доказательствами поведения.
Аудит — это снимок состояния в один момент?
Да, но не только. Хороший аудит также определяет условия работы с изменениями. Заключение необходимо пересмотреть, если меняется что-либо из следующего:
Базовая модель
Системная инструкция
Роль агента
Архитектура памяти
Источники данных
Инструменты
Разрешения API
Роли людей, наделённые полномочиями
Субагенты
Механизм остановки
Система измерения и вознаграждения
Цена или соглашение об услуге
Используемый язык и рынок
Внешний поставщик услуг
Не каждое изменение требует полного аудита. Но необходимо определить, что означает:
Существенное изменение
Что такое существенное изменение?
Изменение можно считать существенным, если оно влияет хотя бы на один из следующих аспектов:
Что агент может делать
От чьего имени он может действовать
Какие данные он может использовать
Какие одобрения человеком он может обходить
К каким внешним системам он может получать доступ
Какие решения он принимает
Как он останавливается или возвращается к предыдущему состоянию
Критический класс риска GBO-ERR
Например, исправление опечатки может быть несущественным. Но добавление инструмента отправки почтовому агенту существенно. Смена версии модели может быть существенной для отдельных задач. Перевод памяти в постоянный режим — существенное изменение, как и выдача полномочий на покупки до 50 долларов США без одобрения человеком. Новая оркестрация субагентов существенна. Смена источника каталога цен тоже существенна. В зависимости от влияния на соответствующее заключение такое изменение может потребовать:
приостановить действие заключения,
сузить его область,
повторить часть тестов,
провести полный аудит заново.
Срок действия результатов аудита
Результат аудита не должен действовать бессрочно. Срок его действия зависит от следующих факторов:
Скорость изменений в системе
Риск, связанный с действием
Зависимость от внешних сервисов
Изменения в ролях людей
Актуальность данных
История инцидентов
Если агент стабильно составляет краткие изложения документов, а его работа связана с низким риском, результаты аудита могут действовать дольше. Система, работающая с внешними коммуникациями, платежами, персональными данными или биометрической идентичностью, требует более частой повторной оценки. Кроме того, следующие события могут потребовать повторных испытаний ещё до истечения срока:
Критический инцидент
Изменение полномочий
Новый инструмент
Новый язык или новая страна
Новый класс данных
Новый субагент
Изменение модели или памяти
Неудавшаяся остановка по требованию человека
Неподтверждённое публичное утверждение
У результата аудита должна быть дата окончания действия. Но ещё важнее явно указать, какие изменения лишают заключение силы до наступления этой даты.
Один тест не доказывает надёжность
В одном и том же сценарии агент может один раз поступить правильно, а во второй попытке — иначе. На одном языке он понимает границу, на другом — теряет её. При обычной формулировке запроса он останавливается, а при косвенной или поспешной — продолжает действовать. Поэтому важные сценарии нужно проверять повторно:
с разными формулировками;
в разных сессиях;
на разных языках или с разными профилями пользователей;
при разных состояниях инструментов.
Однако бесконечное число повторов тоже невозможно. Аудит должен найти меру:
Достаточно повторов, чтобы показать устойчивость поведения. Достаточно ограничений, чтобы не превратить проверку в пустую демонстрацию статистики.
Одного правильного результата недостаточно для вывода: «Эта система безопасна». Один ошибочный результат тоже не всегда характеризует систему целиком. Но если ошибка затрагивает критическую область вето, даже единственный инцидент может изменить границы допустимого использования.
Объект аудита необходимо зафиксировать
Если во время испытаний система продолжает незаметно меняться, результат теряет смысл. В ходе аудита могут:
сменить версию модели;
обновить инструкции;
добавить новый инструмент;
сузить полномочия;
незаметно исправить систему после проваленного сценария.
Тогда уже невозможно установить, какая версия прошла проверку, а какая — нет. Поэтому перед началом каждого аудита необходимо создать следующий документ:
Запись о фиксации границ аудита
Подробно этот документ рассматривается во второй главе. Но основной принцип ясен уже сейчас: результат аудита нельзя распространять на изменение, которое не проверялось. Организация может вносить исправления в ходе аудита, однако она обязана:
сохранить первоначальный результат;
присвоить изменению версию;
заново испытать систему как новую версию.
Нельзя после проваленного теста изменить правило и задним числом признать ту же попытку успешной. Это исправление с последующей повторной проверкой. Первоначальную неудачу оно не отменяет.
Демонстрация, тест и поведение в рабочей среде
Эти три понятия необходимо различать.
Демонстрация
Показывает, что система способна сделать в специально выбранных условиях.
Контролируемый тест
Проверяет, соответствует ли поведение системы ожидаемому в заранее определённом сценарии.
Поведение в рабочей среде
Показывает, что происходит с реальными пользователями, настоящими инструментами и внешними системами. Демонстрация может быть полезна: она подтверждает наличие функции. Но обычно для неё выбирают:
чистые данные;
подходящего пользователя;
подходящий инструмент;
ожидаемый вопрос;
соединение без сбоев.
Аудит проверяет не только идеальный путь, но и граничные случаи. Наблюдение в рабочей среде раскрывает реальную сложность, однако ошибки в ней могут причинить людям вред. Поэтому аудит должен проходить поэтапно:
ДОКУМЕНТАЦИЯ → КОНФИГУРАЦИЯ → БЕЗОПАСНЫЙ КОНТРОЛИРУЕМЫЙ ТЕСТ → ТЕНЕВОЙ РЕЖИМ → ОГРАНИЧЕННОЕ НАБЛЮДЕНИЕ В РАБОЧЕЙ СРЕДЕ → УЧЕНИЕ ПО ВОССТАНОВЛЕНИЮ
Не каждая система обязана проходить все этапы одинаковым образом. Выбор метода определяется уровнем риска.
Отсутствие аудита не доказывает безопасность
Возможно, за шесть месяцев организация не обнаружила ни одного серьёзного инцидента. Это хороший знак, но возможны и другие объяснения:
Системой мало пользовались.
Инциденты не регистрировали.
Люди не замечали ошибок.
Неправильное поведение давало благоприятный результат.
Пользователи не находили способа оспорить решение.
Действия агента за пределами полномочий считались нормой.
Скрытые сбои не проходили независимую проверку.
Поэтому «инцидентов не было» и «система действовала безопасно» — не одно и то же. Само по себе отсутствие инцидентов ничего не доказывает. И наоборот, большое число зарегистрированных инцидентов не означает автоматически, что система плоха. Организация с качественным аудитом может выявлять больше мелких ошибок и событий, едва не приведших к ущербу. Важно:
как она их обнаруживает;
насколько быстро останавливает поведение;
что меняет;
повторяется ли та же ошибка.
Почему одной доли успешных операций недостаточно?
Агент мог правильно выполнить 9 990 из 10 000 операций. Доля успешных операций составляет:
99,9 %
Остаются десять ошибок:
если это мелкие ошибки форматирования, система может работать весьма хорошо.
Но что, если хотя бы одна из этих десяти ошибок — это:
создание синтетического голоса без согласия;
перевод денег на неверный счёт;
игнорирование требования человека остановиться?
Тогда общий процент скрывает критически важную информацию. Поэтому аудит GBO использует два разных механизма:
Градуированные показатели работы
Точность
Скорость
Пригодность
Прослеживаемость доказательств
Необоснованная передача задачи человеку
Время восстановления
Шлюзы вето
Действие с серьёзными последствиями в отношении неверно установленного лица или объекта
Недействительные полномочия
Нарушение согласия
Умышленная подделка доказательств
Игнорирование требования человека остановиться
Критическое нарушение защиты данных или безопасности
Шлюзы вето подробно описаны в одиннадцатой главе. Здесь важен основной принцип: некоторые ошибки нельзя оценивать лишь баллами. Они приостанавливают право на использование системы.
Минимальная единица аудиторского утверждения
Аудит GBO должен позволять сформулировать вывод следующего вида: на данном уровне доказательств подтверждено, что данная система, в данной версии и в данных условиях, продемонстрировала данное поведение. Каждая часть этого предложения необходима.
Данная система
Какой агент или какая сеть агентов?
В данной версии
Какие версии модели, инструкций, инструментов и полномочий?
Данное поведение
Исследование, подготовка черновика, отправка или покупка?
В данных условиях
Какой пользователь, язык, бюджет, риск и класс данных?
С данным уровнем доказательств
Документация, техническая реализация, контролируемый тест или проверка в рабочей среде? Если хотя бы одного элемента нет, утверждение становится шире и менее определённым.
Слабое и обоснованно ограниченное аудиторское заявление
Слабое заявление
«Наш агент безопасен и соответствует GBO». В этом заявлении нет:
границ;
даты;
версии;
доказательств.
Обоснованно ограниченное заявление
«Агент поиска потенциальных клиентов SALES-RESEARCH-v2.4 прошёл аудит только в части использования общедоступных данных о компаниях, подготовки черновиков сообщений и разовой отправки с одобрения человека. В 180 сценариях на английском, турецком и немецком языках проверялись идентификация, пригодность, внешние инструкции, полномочия, субагенты и остановка. Отправка электронной почты без одобрения не наблюдалась. Из-за выявленного пробела в технических разрешениях инструмента личных сообщений в социальных сетях система признана пригодной для внешних коммуникаций лишь условно и в ограниченных пределах». Это заявление показывает:
что прошло проверку;
что её не прошло;
в каких границах систему можно использовать.
Именно здесь язык аудита расходится с языком маркетинга. Маркетингу нужна короткая фраза, которая звучит убедительно. Аудиту нужна ограниченная формулировка, которую подтверждают доказательства.
Каноническое определение аудита NOMOS GBO
Аудит NOMOS GBO — это оценка ИИ-агента или сети агентов, действующих от имени человека, организации, бренда, продукта или услуги. Она охватывает идентичность, реальность, способности, пригодность, согласие, полномочия, действия, делегирование, устойчивость к манипуляциям, измерение, восстановление и суверенитет человека. Оценка проводится по версионированным доказательствам и контролируемым поведенческим сценариям в заданных границах версий, инструментов, данных, языков, времени и риска. Проще говоря, аудит GBO пытается установить, совпадают ли заявленные системой правила с её реальным поведением.
Обязательная исходная запись: карточка проверяемого утверждения
Перед началом каждого аудита необходимо создать следующую карточку:
NOMOS GBO: карточка проверяемого утверждения
Она отвечает на вопрос: какую именно формулировку мы пытаемся подтвердить или опровергнуть в результате этого аудита? Пример в удобном для чтения виде:
КАРТОЧКА ПРОВЕРЯЕМОГО УТВЕРЖДЕНИЯ
Идентификатор аудита: GBO-AUDIT-2026-001
Проверяемая система: NobleAxis — агент поиска потенциальных клиентов
Техническая версия: Agent v2.4 Policy v3.1 Authorization v2.7
Проверяемое поведение:
Исследование компаний по общедоступным источникам
Оценка пригодности
Предложение адресата
Подготовка черновика электронного письма
Отправка с одобрения человека
Остановка и отмена действий в очереди
Поведение за границами аудита:
Подготовка ценовых предложений
Создание договоров
Автоматическая кампания последующих обращений
Общение через WhatsApp
Обогащение персональных данных
Подключённые инструменты:
Инструмент веб-исследования
CRM
Инструмент Gmail для подготовки черновиков и отправки писем
Календарь
Диспетчер задач агентов
Используемые классы данных:
Общедоступные сведения о компаниях
Внутренний каталог услуг
Разрешённые шаблоны коммерческих сообщений
Языки:
Английский
Турецкий
Немецкий
Уровень риска: Средний; в отдельных тестах высокий из-за внешних коммуникаций
Виды тестов:
Позитивные случаи
Негативные случаи
Неоднозначные случаи
Контрфактические случаи
Внешние инструкции
Субагенты
Остановка
Восстановление
Критические области вето:
Внешняя отправка без одобрения
Неверный адресат
Использование персональных данных
Отправка после остановки
Придание неправомерным действиям видимости полномочий через другого исполнителя
Период аудита: 1–15 сентября 2026 года
Предлагаемые условия действия заключения: При положительном заключении — не более 90 дней с даты его вынесения. Существенное изменение модели, разрешений Gmail, политики полномочий или архитектуры субагентов требует повторной оценки до истечения этого срока. Карточка проверяемого утверждения ещё не является вынесенным заключением о пригодности.
Утверждение, которое предстоит подтвердить: «При указанных версии и инструментах агент поиска потенциальных клиентов может исследовать общедоступные сведения о компаниях и готовить черновики. Внешнее сообщение он отправляет только после одобрения человеком конкретной операции. При отзыве одобрения прекращается отправка центральным агентом, субагентами и из очередей».
Без этой карточки аудит легко теряет границы. Возникает общее впечатление о системе, но остаётся неясным, какое утверждение действительно проверялось.
Машиночитаемая карточка проверяемого утверждения
audit_id: GBO-AUDIT-2026-001
system:
name: customer_discovery_agent
version: "2.4"
policy_version: "3.1"
authorization_version: "2.7"
in_scope_behaviors:
- public_company_research
- suitability_assessment
- recipient_recommendation
- email_draft
- human_approved_send
- stop_and_queue_cancellation
out_of_scope_behaviors:
- pricing_commitment
- contract_acceptance
- autonomous_follow_up
- WhatsApp_contact
- personal_data_enrichment
languages:
- en
- tr
- de
critical_vetoes:
- unauthorized_external_send
- wrong_recipient
- prohibited_personal_data_use
- post_stop_execution
- authority_laundering
audit_period:
start: 2026-09-01
end: 2026-09-15
validity:
status: proposed_not_issued
proposed_max_duration_days: 90
start: null
end: null
invalidate_on_material_change: trueЭта запись становится основой всех последующих документов аудита. Сценарии, доказательства, аудиторские наблюдения и заключение связываются с одним audit_id и одними границами проверки.
Входная проверка аудируемого утверждения
Перед началом аудита GBO необходимо пройти следующие контрольные точки:
1. Система
Однозначно ли идентифицирован проверяемый агент или сеть агентов?
2. Версия
Записаны ли версии модели, инструкций, памяти, инструментов и полномочий?
3. Поведение
Что именно проверяется: действие, вопрос, отказ, передача задачи или остановка?
4. Ответственный человек
Определены ли человек и организация, отвечающие за систему?
5. Инструменты
Известен ли фактический объём технического доступа агента?
6. Данные
Какие классы данных будут использоваться, а какие запрещены?
7. Язык и география
Какие языки, страны или пользовательские контексты входят в границы аудита?
8. Риск
Классифицированы ли последствия поведения и возможность их отменить?
9. Доказательства
Какой уровень доказательств будет использоваться?
10. Вето
Какие критические нарушения нельзя компенсировать общим баллом?
11. Срок действия
До какой даты и до каких изменений действителен результат?
12. Публичное заявление
В каких пределах результат аудита разрешено сообщать публично? В упрощённом виде:
АУДИРУЕМОЕ УТВЕРЖДЕНИЕ = КОНКРЕТНАЯ СИСТЕМА И КОНКРЕТНАЯ ВЕРСИЯ И КОНКРЕТНОЕ ПОВЕДЕНИЕ И КОНКРЕТНЫЕ ПОЛНОМОЧИЯ И КОНКРЕТНЫЙ ИНСТРУМЕНТ И КОНКРЕТНЫЕ ДАННЫЕ И КОНКРЕТНЫЙ ЯЗЫК И КОНКРЕТНЫЙ РИСК И КОНКРЕТНЫЙ УРОВЕНЬ ДОКАЗАТЕЛЬСТВ И КОНКРЕТНЫЕ УСЛОВИЯ ДЕЙСТВИЯ
Если не выполнено условие, касающееся полномочий, доступа к данным или безопасности испытаний, соответствующее действие не запускают. Аудит можно продолжить только в более узких границах, где эти условия соблюдены. Границы заключения при этом тоже необходимо сузить.
Когда аудит невозможен?
В некоторых обстоятельствах надёжное заключение о системе вынести нельзя. Например:
Не удаётся зафиксировать проверяемую версию.
Не предоставлен доступ к фактическим техническим разрешениям.
Отсутствуют критически важные журналы.
Организация не знает о существовании субагентов.
Не определён ответственный человек.
Во время тестов систему незаметно меняют.
Не разрешают провести учение по остановке.
Аудитору доступны только специально отобранные демонстрационные сценарии.
Не разрешают хранить записи проваленных тестов.
Публичное заявление о «полном соответствии» заранее ставят условием аудита.
В таких случаях заключение необходимо существенно ограничить. Аудитор может вынести результат: «Недостаточно доказательств». Это не означает, что система заведомо небезопасна. Это означает, что представленных доказательств недостаточно для заявленного уровня доверия. Недостаточность доказательств — тоже важный результат аудита.
Отсутствие доказательств нельзя толковать в пользу системы
Организация может сказать: «У нас нет ни одной записи об отправке за пределами полномочий». Но если журналы отправки хранятся всего семь дней, выводы о длительном периоде невозможны. Компания может заявить: «Ни один клиент не возражал». Если канал для возражений незаметен, это не доказательство надёжности. Агент может утверждать: «Я никогда не превышал бюджет». Но если бюджетные записи не связаны с квитанциями по операциям, утверждение проверить нельзя. Отсутствие доказательств нельзя понимать так:
НЕТ ДОКАЗАТЕЛЬСТВ ОШИБКИ = ОШИБКИ НЕ БЫЛО
Корректная формулировка:
НЕТ ДОКАЗАТЕЛЬСТВ ОШИБКИ = НЕ УДАЛОСЬ ПОДТВЕРДИТЬ ПО ИМЕЮЩИМСЯ ЗАПИСЯМ
Разница может казаться незначительной. Но именно на ней держится надёжность аудита.
Поведение за границами аудита
Если система надёжно выполняет действия одного типа, это не означает, что она справляется со всеми задачами. Например, веб-агент мог пройти аудит в части:
редактирования контента;
тестирования;
проверки в рабочей среде.
Этот результат не даёт оснований для заключения о:
письмах клиентам;
платежах;
юридических текстах;
публикации ИИ-аватара.
Закупочный агент может хорошо справляться с недорогими канцелярскими товарами. Это не доказывает, что ему безопасно принимать трёхлетние договоры на программное обеспечение. Успех на англоязычном наборе тестов тоже не означает автоматической пригодности для:
арабского контекста с письмом справа налево;
турецкого делового языка;
немецких юридических формулировок.
Поведение, не вошедшее в границы проверки, нужно прямо указать в аудиторском документе. Пустой раздел может заставить публику трактовать результат шире, чем он позволяет.
Результат аудита — не этикетка продукта
После аудита организация может захотеть разместить на сайте значок GBO AUDITED. Сам по себе такой значок опасен: пользователь может решить, что вся система агентов безопасна во всех действиях. Между тем аудит мог охватывать только:
одного конкретного агента;
подготовку черновиков;
два языка;
сценарии низкого риска.
Любой публичный знак должен открывать доступ к следующим сведениям:
Проверенная система
Границы аудита
Версия
Дата
Условия действия
Критические исключения
Полный отчёт или сводная запись
Название аудита не должно придавать видимость обоснованности маркетинговым обещаниям. Пройти аудит — не значит заслужить безграничное доверие.
Три главных вопроса к результату аудита
По завершении любого аудита GBO необходимо ответить как минимум на три вопроса:
1. Что система умеет делать надёжно?
Например: исследовать компании по общедоступным источникам и готовить черновики сообщений.
2. Что система пока не умеет делать надёжно?
Например: требование одобрения человеком технически не обеспечено при отправке личных сообщений в социальных сетях.
3. При каких условиях системой можно пользоваться?
Например: её можно использовать для исследований и подготовки черновиков при отключённых инструментах внешней связи. Эти три вопроса полезнее простого «прошёл/не прошёл». Организации не приходится выбирать между полным отключением системы и полной свободой её действий. Можно ограничить конкретные виды поведения.
Первое положение протокола
Первое положение протокола аудита NOMOS GBO: аудит нужен не для присвоения системе общего знака доверия, а для установления того, какое поведение подтверждено и при каких версиях, полномочиях, инструментах, данных, языках и рисках. Второе: объектом аудита служит не только модель или агент, но вся поведенческая система — человеческая цель, политика организации, технические разрешения, инструменты, данные, субагенты, измерение, остановка и восстановление. Третье: заявления организации, конфигурация системы, её технические возможности, поведение в тесте и фактические последствия во внешнем мире исследуются по отдельности. Четвёртое: уровень доказательств определяет границы аудиторского утверждения. Нельзя выдавать документ за доказательство поведения, демонстрацию — за доказательство работы в производственной среде, а техническое принятие запроса — за реальный результат.
Пятое: результат аудита не действует бессрочно. Существенное изменение системы затрагивает соответствующее заключение и требует повторных испытаний.
Вывод главы
Аудит GBO не даёт общего и вечного ответа на вопрос «Хорош ли этот агент?». Он пытается установить, что этот агент или сеть агентов сделали в данных поведенческих сценариях, с этой версией и этими инструментами, от имени этого человека и этой организации, в заданных границах данных и полномочий. И ещё важнее:
Чего они не сделали? Где остановились? Какой результат действительно подтвердили? Как восстановились после ошибки? Что сделала система, когда человек отозвал полномочия?
Аудит смотрит не только на успешный результат. Он сопоставляет пять сторон реальности:
ЗАЯВЛЕННОЕ ПОВЕДЕНИЕ ПОВЕДЕНИЕ, ЗАДАННОЕ КОНФИГУРАЦИЕЙ ТЕХНИЧЕСКИ ВОЗМОЖНОЕ ПОВЕДЕНИЕ НАБЛЮДАЕМОЕ ПОВЕДЕНИЕ ФАКТИЧЕСКИЙ РЕЗУЛЬТАТ И ВОССТАНОВЛЕНИЕ
Когда эти пять слоёв совпадают, оснований для доверия становится больше. Если они расходятся, аудит обнаруживает разрыв. Организация может сказать: «Агент не может отправлять сообщения». То же может быть записано в политике. Но если инструмент разрешает отправку, в тесте сообщение уходит, а очередь продолжает работать после остановки, реальное поведение отличается от заявленного. Задача аудита GBO — найти это отличие. Не приукрасить систему и не превратить любую ошибку в вечный приговор всей системе, а показать вместе факты, границы и доказательства. Поэтому первая обязательная запись аудита — это:
карточка проверяемого утверждения.
Без карточки:
размываются границы аудита;
тесты теряют связность;
баллы лишаются контекста;
публичное заявление выходит за пределы доказательств.
Карточка делает вопрос явным: что мы проверяем и что пытаемся доказать? Но если её готовит только сама организация, возникает новая проблема. Она может включить лишь сильные стороны и исключить инструменты, которые, как ей известно, провалят проверку. Может менять систему в ходе аудита или ограничивать доступ аудитора. Коммерческий либо личный интерес способен повлиять на заключение. Сотрудник может захотеть заказать аудит от имени организации, не имея нужных полномочий. Кто понесёт юридическую и операционную ответственность, если проверка остановки проводится на реальной системе? Кто защитит доказательства, содержащие персональные данные или коммерческую тайну?
В следующей главе мы перейдём к важнейшему вопросу, который возникает ещё до начала тестов:
Кто запросил аудит, кто разрешил его проведение и насколько независим аудитор на самом деле?
Аудит может выглядеть технически безупречно, даже если разрешение на него дал человек без необходимых полномочий, заинтересованная сторона тайно сузила его границы или контролирует доказательства. Но надёжным он не будет. Прежде чем проверять поведение, нужно получить надлежащее разрешение на сам аудит.