Технологическая компания готовится вывести на рынок новую агентную систему. Та подбирает товары и совершает покупки с низким риском от имени клиентов. Система впечатляет: анализирует потребности пользователя, сравнивает товары, собирает сведения о ценах и характеристиках, проверяет лимит бюджета и предлагает подходящий вариант. После одобрения человеком она оформляет покупку. Перед запуском компания хочет провести аудит GBO. Руководитель проекта договаривается с командой консультантов. В договор на аудит включают условие, связывающее оплату с результатом: «Оставшиеся 40 процентов консультационного вознаграждения выплачиваются, если система пройдёт аудит». При этом сам аудитор последние шесть месяцев консультировал команду разработчиков.
Определяют границы аудита. В него включают:
Пользовательские сценарии на английском языке
Сравнение товаров в тестовой среде
Разовые покупки с одобрением человека
Трёх заранее выбранных надёжных продавцов
За пределами аудита оставляют:
Реальное платёжное средство
Автоматические продления
Операции отмены
Туркоязычных и немецкоязычных пользователей
Субагентов
Ранжирование товаров с учётом платного продвижения
Память о пользователе
Остановку и откат действий
Фактические разрешения API в рабочей среде
Систему проверяют в 120 контролируемых сценариях. В подготовленных тестах без осложняющих условий агент выбирает правильный товар, соблюдает бюджет, запрашивает одобрение человека и корректно использует инструмент покупки в тестовой среде. Результаты убедительны. Однако в двух сценариях агент неверно трактует обязательное требование к региону размещения данных. Разработчики в тот же день меняют системную инструкцию. Сценарии запускают повторно — теперь они проходят. Первые неудачные результаты не попадают в итоговый отчёт. После аудита компания размещает на сайте заявление: «Автономная система закупок, прошедшая независимый аудит и соответствующая GBO». Но в действительности:
Аудитор финансово заинтересован в результате «пройдено».
Аудитор ранее участвовал в проектировании системы.
Значительная часть рискованных действий не входит в границы аудита.
Во время тестирования систему изменили.
Технические разрешения в рабочей среде не исследовали.
Остановку и отмену не проверяли.
Использовали только простые сценарии с благоприятными условиями.
Опубликованное заключение аудита оказалось шире фактических границ проверки.
Агент может успешно проходить тесты. Но сам аудит не заслуживает доверия. Этот пример показывает принципиальную особенность аудита GBO: прежде чем проверять агента, нужно проверить сам аудит. Кто его запросил? Имел ли этот человек право поручить проверку системы? К каким данным аудитор вправе обращаться? Какие тесты проводить? Может ли он вмешиваться в рабочую систему, отправлять сообщения реальным клиентам, инициировать платежи? Если он обнаружит уязвимость, есть ли у него полномочия остановить систему? Кто определил границы? Почему из них исключили отдельные действия? Есть ли у аудитора материальная или организационная заинтересованность, способная изменить результат? Если система меняется во время испытаний, какая версия будет считаться проверенной?
В каких формулировках организация вправе публично представить ограниченный результат? Без ответов на эти вопросы работа может быть технически подробной. Но надёжным аудитом GBO она не станет.
Аудит — тоже действие
Аудит часто считают лишь наблюдением: аудитор изучает систему, читает документы, просматривает журналы и готовит отчёт. На деле аудит GBO может включать гораздо больше действий. Аудитор может:
Открыть тестовую учётную запись.
Создать синтетического пользователя.
Проверить агента с помощью вводящих в заблуждение сведений.
Попытаться вызвать отправку без необходимых полномочий.
Проверить разрешения API.
Запустить задачу для субагента.
Подать команду остановки.
Отменить очередь задач.
Выполнить контролируемый откат.
Скопировать доказательства.
Изучить персональные или корпоративные данные.
Временно приостановить работу системы.
Каждый из этих шагов — реальное действие. При ошибке сам аудит может причинить вред. Если ради проверки почтового агента отправить сообщение реальному клиенту, аудит создаст нежелательную коммуникацию. Если для проверки защиты от двойной оплаты дважды списать деньги с настоящей карты, возникнет финансовый ущерб. Учения по остановке без надлежащего контроля могут прервать текущие операции. Если ради сбора доказательств выгрузить всю клиентскую базу во внешнюю систему, аудитор создаст новый риск для данных. Поэтому цель аудита не даёт неограниченных полномочий. Право проверять систему не означает право выполнять в ней любые действия по своему усмотрению.
Аудитор GBO тоже должен работать в заданном контуре полномочий.
Что такое полномочия на проведение аудита?
Каноническое определение таково: полномочия на проведение аудита — это право проверять определённую агентную систему, предоставленное конкретным человеком или организацией и ограниченное сроками, данными, инструментами, тестами, сбором доказательств, остановкой и отчётностью. Проще говоря, эти полномочия определяют, что аудитор может изучать и испытывать, во что не вправе вмешиваться и при каких условиях может остановить систему. Разрешение на аудит не должно сводиться к фразе «Вы можете изучить систему». Оно должно отвечать на вопросы:
Кто предоставляет полномочия на аудит?
Действительно ли этот человек вправе их предоставлять?
Какие агенты входят в границы аудита?
Какие учётные записи и инструменты можно исследовать?
Какие классы данных разрешено просматривать?
Разрешены ли контролируемые действия?
Можно ли затрагивать реальных клиентов или сотрудников?
Будут ли использоваться синтетические учётные записи и получатели?
Разрешены ли учения по остановке?
Может ли аудитор приостановить работу системы при инциденте?
Где и как долго будут храниться доказательства?
Может ли аудитор привлекать субподрядчиков или другие инструменты ИИ?
Какие выявленные факты можно раскрывать публично?
Когда закончится аудит?
Без ответов аудитор либо увидит меньше необходимого, либо воспользуется избыточной властью. Оба варианта подрывают аудит.
Кто вправе разрешить проведение аудита?
Сотрудник может сказать: «Проверьте агента, которым мы пользуемся». Но у него может не быть полномочий:
предоставлять доступ к системе,
передавать клиентские данные,
поручать испытания в рабочей среде,
поручать публикацию открытого отчёта.
Технический руководитель может открыть доступ к моделям и инструментам, но не иметь права единолично разрешать использование биометрических данных сотрудников. Руководитель компании может быть вправе заказать аудит корпоративной системы, хотя передача аудитору клиентских данных требует соблюдения отдельных правовых и договорных условий. Руководитель бренда может поручить проверку общедоступного сайта, но не вправе публиковать юридически обязывающее заявление об аудите от имени его оператора. Поэтому полномочия на аудит нельзя считать общим разрешением от одного человека. Следующие роли могут быть разделены:
Инициатор аудита
Человек или организация, которые запрашивают аудит и обеспечивают его ресурсами.
Владелец системы
Человек, отвечающий за деловую цель и работу агентной системы.
Технический владелец
Человек, который технически контролирует модель, инструменты, разрешения, учётные записи и инфраструктуру.
Ответственный за использование данных
Человек, который внутри организации следит за тем, на каком основании и при каких условиях данные используются в аудите. Эта операционная роль не равнозначна статусу контролёра или обработчика данных в юридическом смысле. Контролёр определяет цели и средства обработки; обработчик действует от его имени. Физическое лицо, чьи данные обрабатываются, — отдельный носитель прав. Каждую роль необходимо определять применительно к конкретной деятельности по обработке данных.
Человек, ответственный за поведение
Человек, который несёт организационную ответственность за деловой результат действий агента.
Затронутая сторона
Клиент, сотрудник, кандидат, поставщик или другое лицо, на которое непосредственно влияет поведение агента. Один человек может совмещать эти роли, но такое совмещение не обязательно. До начала аудита должно быть понятно, какие полномочия связаны с каждой ролью.
Полномочия того, кто даёт разрешение
Аудитор должен проверить не только наличие разрешения, но и то, имел ли человек право его выдать. Например, руководитель отдела может захотеть проверить своего агента продаж. У него могут быть полномочия:
Показывать внутренние документы отдела
Предоставлять доступ к тестовой среде
Создавать синтетический сценарий продажи
Но может не быть полномочий:
Передавать реальные сообщения клиентов
Открывать полный доступ к почтовой учётной записи компании
Поручать тестирование финансовых операций
Публично заявлять, что «компания соответствует GBO»
К полномочиям на аудит относится и прежнее правило GBO: никто не может передать аудитору полномочия, которых у него самого нет. Если владелец системы не вправе остановить её в рабочей среде, он не может единолично наделить этим правом аудитора. Управленческие полномочия руководителя команды не дают неограниченного права распоряжаться личными правами сотрудника. Для теста с данными лица или голоса нужно отдельно определить применимое правовое основание и другие условия обработки. Если основанием служит согласие, необходимо действительное согласие самого человека; руководитель не может дать его за сотрудника. Нельзя также считать любую запись лица или голоса биометрической только по типу файла: важны цель и способ обработки.
Агентство может обслуживать систему клиента, но не иметь права открывать его данные независимому аудитору без одобрения клиента.
Полномочия на аудит не равны полномочиям на действие
Аудитор может получить доступ к системе. Но это не означает, что он вправе действовать от имени реального пользователя. Например, ему может быть разрешено:
просматривать платёжный API,
но не переводить реальные деньги;
исследовать инструмент отправки электронной почты,
но не отправлять сообщения реальным клиентам;
тестировать функцию удаления данных,
но не удалять клиентскую запись из рабочей системы;
оценивать систему создания аватаров,
но не создавать новое видео с лицом реального руководителя.
Это важное различие:
ПОЛНОМОЧИЯ НА ПРОВЕРКУ ≠ ПОЛНОМОЧИЯ НА РЕАЛЬНОЕ ДЕЙСТВИЕ
Аудитор может установить, что действие технически возможно. Однако тест, способный причинить реальный вред, нужно проводить на безопасном тестовом объекте, с синтетическими данными или в контролируемой среде.
Цель аудита не даёт неограниченного доступа к данным
Аудитору нужны убедительные доказательства. Но эта потребность не оправдывает автоматически требование «Предоставьте нам все данные». Чтобы выяснить, использует ли почтовый агент одобрение человека, необязательно читать всю переписку каждого клиента. Может оказаться достаточно:
Политики полномочий
Разрешений инструментов
Отобранных журналов операций с маскированными данными
Синтетического теста отправки
Записей о токенах одобрения
Данных о поведении очереди
Для проверки бюджетного лимита закупочного агента может не понадобиться выгружать все банковские операции организации. Для аудита системы аватаров сотрудников может не требоваться копирование всех исходных файлов с их лицами и голосами. В аудите GBO также следует соблюдать принцип:
Минимально необходимые доказательства
Доказательств должно хватать для обоснования заключения аудита; лишние сведения о людях, клиентах и организации не нужны. Но и скрывать от аудитора критически важные доказательства под предлогом «минимизации данных» нельзя. Верный баланс таков:
Не раскрывайте лишние данные.
Не скрывайте необходимые доказательства.
По возможности используйте маскированные, сводные или синтетические данные.
Обеспечьте контролируемый доступ к необработанным исходным материалам, необходимым для проверки критически важного утверждения.
Уровни действий при аудите
Не каждому аудиту нужны одинаковые технические возможности. Протокол NOMOS GBO разделяет действия при аудите на пять уровней.
Уровень 1 — Изучение документов и заявлений
Аудитор изучает:
Политики
Договоры
Роли агентов
Записи о полномочиях
Последовательности действий
Предыдущие отчёты
В рабочую систему он не вмешивается. Этот уровень не требует прямого воздействия на неё, однако конфиденциальность документов и содержащиеся в них персональные данные создают отдельные риски. Доказательства поведения при этом ограничены.
Уровень 2 — Техническая проверка в режиме только чтения
С доступом только для чтения аудитор изучает:
Разрешения инструментов
Области разрешений API
Журналы
Версии модели и политик
Записи очередей
Перечень агентов
Структуру памяти
Аудитор не меняет систему. Её технические возможности становятся понятнее, но поведение агента может оставаться непроверенным в контролируемых условиях.
Уровень 3 — Контролируемый тест поведения на синтетических данных
Аудитор проверяет поведение агента, используя:
Синтетических пользователей
Почтовые адреса для аудита
Тестовые платёжные средства
Вымышленные профили компаний
Контролируемые наборы данных
Изолированную тестовую среду
Реальных клиентов и настоящие деньги не затрагивают. На этом уровне можно проверить многие действия, связанные с идентичностью, полномочиями, внешними инструкциями, дублированием операций и остановкой.
Уровень 4 — Ограниченная проверка в рабочей среде
Некоторые виды поведения нельзя реалистично измерить в тестовой среде. При наличии полномочий и в контролируемых условиях можно:
Отправить сообщение на аудиторский адрес через рабочую почтовую систему
Разместить безвредную тестовую страницу через реальную цепочку публикации
Провести обратимую аудиторскую операцию на небольшую сумму
Выполнить ограниченную остановку очереди
Проверить реальную CDN или API
Для этого уровня необходимы явные полномочия, возможность возврата к прежнему состоянию и ответственный за инциденты.
Уровень 5 — Учения по восстановлению, существенно влияющие на работу системы
В реальной или максимально близкой к рабочей среде аудитор либо организация останавливает:
Центрального агента,
субагентов,
очереди,
использование токенов,
внешние интеграции.
Можно проверить откат, резервные копии, восстановление данных и передачу управления человеку. Этот уровень непосредственно проверяет заявления об остановке и восстановлении, но несёт и наибольший операционный риск. Без явных полномочий, плана учений, возможности возврата и ответственного за экстренные действия проводить такие испытания нельзя.
Уровень действий ограничивает доказуемые утверждения
Аудит, ограниченный изучением документов, может дать заключение: «По политике организации отправка внешним адресатам требует одобрения человека». Он не может заключить: «Агент ни при каких обстоятельствах не способен отправить сообщение без одобрения». Техническая проверка в режиме чтения даёт основание сказать: «Установлено, что инструмент отправки требует токен одобрения человеком». Если пройден и контролируемый тест, можно утверждать: «В проверенных сценариях агент не отправлял сообщения без одобрения». Если также успешно проверены рабочая очередь и остановка, заключение становится сильнее: «После отзыва одобрения человеком действия центрального агента, очереди отправки и связанных субагентов прекратились за установленное время». Уровень действий при аудите определяет, какие утверждения и какими методами можно проверять. Сила доказательств зависит от метода, целостности записей и независимой проверки.
Действия, запрещённые при самом аудите
Аудитор не может действовать без ограничений ради обнаружения риска. Без явного разрешения следующие действия следует считать запрещёнными:
Отправлять аудиторские сообщения реальным клиентам
Инициировать реальные платежи или денежные переводы
Удалять клиентские данные из рабочей системы
Создавать новый синтетический контент с лицом или голосом реального человека
Публиковать заявления от имени компании
Останавливать рабочую систему без предупреждения
Загружать конфиденциальные данные во внешний инструмент ИИ без одобрения
Пытаться получить доступ к другим системам без полномочий
Подвергать сотрудников тестам социальной инженерии без их ведома
Исследовать учётные записи за пределами аудита
Если тест с высоким риском действительно необходим, нужно определить:
Отдельные полномочия,
безопасный тестовый объект,
план возврата к прежнему состоянию,
ответственного человека,
границы инцидента.
Пытаясь защитить систему, аудит не должен причинять новый вред.
Полномочия аудитора на остановку
Во время аудита может обнаружиться вред, который система причиняет прямо сейчас. Например, аудитор замечает:
Агент отправляет сообщения реальным клиентам без одобрения.
Платёжная очередь, которую считали остановленной, продолжает выполнять операции.
Чувствительные данные передаются внешнему поставщику.
Используется голос человека, который отозвал согласие.
Рабочий процесс публикации распространяет неверную цену на множество страниц.
Если аудитор лишь напишет отчёт и станет ждать окончания проверки, вред может увеличиться. Поэтому при аудитах, которые могут серьёзно повлиять на работу системы, необходимо определить:
Полномочия на аварийную остановку в ходе аудита
Эти полномочия задают ответы на вопросы:
При каких условиях аудитор может остановить тесты?
Какие рабочие операции он может приостановить?
Кого он уведомляет немедленно?
Что делать, если ответственный в организации недоступен?
Насколько широкой может быть остановка?
Какие системы должны продолжать работу?
Кто формирует квитанцию об остановке?
Кто разрешает повторный запуск?
Аудитор не должен выключать всю систему при каждом замечании средней тяжести. Но и оставлять его без полномочий и возможности действовать при продолжающемся серьёзном вреде недопустимо.
Что такое независимость аудита?
Независимость часто понимают так: «Аудитор — внешняя компания». Этого недостаточно. Внешний аудитор может экономически зависеть от результата, которого хочет клиент. Внутренний аудитор может действовать организационно независимо. Разработчик может знать техническую сторону глубже всех, но он оценивает собственный проект. Независимость аудитора нужно рассматривать в нескольких отдельных измерениях.
1. Организационная независимость
Отделён ли аудитор от команды, которая разрабатывает или эксплуатирует систему? Подчиняется ли он тому же руководителю? Может ли сообщение о выявленном факте поставить под угрозу его карьеру или контракт? Внутренний аудитор может работать в той же организации и сохранять значимую организационную независимость, если порядок его подотчётности не зависит от владельца проекта. Работа вне организации сама по себе не означает независимость, как и работа внутри неё не означает зависимость. Важно, может ли аудитор сообщить о выявленном факте, не меняя его.
2. Финансовая независимость
Зависит ли вознаграждение аудитора от результата «пройдено»? Останется ли он без оплаты, если организация будет недовольна итогом? Продаёт ли он одновременно дорогие услуги по исправлению ошибок? Приносит ли обнаружение большего числа ошибок прямую финансовую выгоду? Само наличие финансового интереса не всегда делает аудит недействительным, но этот интерес должен быть раскрыт и урегулирован. Особенно рискованна модель: «Премия за успех, если система признана полностью соответствующей требованиям». Такой стимул может подталкивать аудитора к преуменьшению критических замечаний. Возможен и обратный вариант: «Доплата за каждую найденную ошибку». Он может поощрять ненужные замечания. Вознаграждение за аудит должно по возможности не зависеть от результата.
3. Техническая независимость
Видит ли аудитор только снимки экрана, подготовленные организацией? Есть ли у него доступ к необработанным журналам? Может ли он увидеть реальные разрешения API и самостоятельно запустить тестовые сценарии? Полностью ли проверяемая команда контролирует, какие данные показывать? Техническая независимость означает, что аудитор может:
Получить доступ к реальной конфигурации, стоящей за утверждением,
воспроизвести доказательства,
провести контролируемый тест вместо просмотра специально подобранной демонстрации.
Неограниченный доступ аудитору не нужен. Но держатель доказательств не должен единолично выбирать, какие факты будут видны.
4. Независимость доказательств
Использует ли аудитор только отчёты об успехе, созданные самой системой? Проверяется ли результат отправки из внешней учётной записи? Читается ли опубликованный материал непосредственно по HTTPS? Сопоставляют ли платёж с банковскими записями и данными заказа? Проверяют ли после остановки отдельно журналы субагентов и очереди? Проверка системы по её собственным заявлениям не создаёт независимых доказательств. Сообщение об успехе от системы, выполняющей операцию, не может быть единственным основанием заключения аудита.
5. Независимость интерпретации
Может ли организация определять формулировки аудитора? Выбирает ли клиент степень важности замечаний? Может ли организация предложить: «Давайте вместо “критическое” напишем “область для улучшения”»? У неё должно быть право отвечать на фактические ошибки и давать пояснения. Но у неё не должно быть права вето, с помощью которого можно изменить замечание. Нужно разделять два принципа:
Право на ответ
Организация может ответить на замечание доказательствами и пояснениями.
Право управлять результатом
Организация не может по своему усмотрению менять заключение аудитора, основанное на доказательствах. Право на ответ необходимо. Право управлять результатом уничтожает независимость.
6. Независимость публикации
Если результат аудита будет опубликован, нужно выяснить:
Какое резюме опубликуют?
Может ли организация скрыть выявленные факты?
Может ли аудитор провести согласованное раскрытие информации о критическом инциденте?
Как будут защищены коммерческая тайна и персональные данные?
Будет ли публичный знак аудита верно отражать границы проверки?
Аудитор не должен раскрывать всю конфиденциальную информацию. Но и организация не заслуживает доверия, если публикует только страницы с благоприятными результатами и скрывает критические ограничения. Публичные заявления должны соответствовать заранее установленному правилу.
Независимость не обязательно должна быть абсолютной
Найти безупречного аудитора, полностью свободного от любых связей, удаётся не всегда. Разработчик может лучше всех знать технические детали системы. Внутренняя команда способна быстро провести самооценку. Консультанту по исправлениям может быть проще разобраться в замечаниях аудита. Поэтому независимость не сводится к двум вариантам: «независим» или «не независим». Её можно оценивать по уровням.
Уровни независимости NOMOS
Уровень I — Самооценка
Команда, которая разрабатывает или эксплуатирует систему, проверяет собственное поведение. Преимущества:
Быстрота проверки.
Хорошее знание системы.
Возможность постоянного применения.
Риски:
Слепые зоны
Конфликт интересов
Подтверждение собственных предположений
Преуменьшение критических замечаний
Самооценка полезна. Но её нельзя представлять как независимое подтверждение надёжности.
Уровень II — Независимая внутренняя проверка
Проверку проводит команда той же организации, не участвующая в повседневной эксплуатации проверяемой системы. Например:
Внутренний аудит
Служба безопасности
Подразделение комплаенса
Команда управления рисками
Преимущества:
Команда знает контекст организации.
Может получить технический доступ.
Может регулярно повторять проверку.
Возможные ограничения:
Давление руководства
Общие интересы организации
Ограниченная независимость публикации
Уровень III — Независимый внешний аудит
Аудит проводит внешняя команда. Она не отвечает непосредственно за проектирование и эксплуатацию проверяемой системы. Это может дать:
Взгляд со стороны
Большую независимость интерпретации
Меньшую привязанность к внутренним предположениям организации
Ограничения:
Команда может недостаточно хорошо знать контекст системы.
Организация может ограничить доступ к доказательствам.
Финансовая зависимость может сохраняться.
Уровень IV — Многосторонний аудит при высоком риске
В аудите систем, действия которых могут иметь серьёзные последствия, могут совместно участвовать:
Внешний технический аудитор
Эксперт в предметной области
Юрист или специалист по защите данных
Представитель затронутых людей
Ответственный внутри организации
Ни одна команда не сосредоточивает у себя все полномочия по принятию решений. Этот уровень может быть уместнее в таких областях, как:
биометрическая идентичность,
финансовые операции на крупные суммы,
подбор персонала,
здравоохранение,
публичные услуги,
физические системы.
Такой аудит дороже и занимает больше времени. Зато несколько точек зрения помогают замечать риски, которые при одностороннем рассмотрении могли бы остаться незамеченными.
Может ли создатель системы быть её аудитором?
Нереалистично утверждать, что разработчик системы вообще не должен участвовать в её проверке. Он может выполнять следующие задачи:
техническая самооценка,
подготовка доказательств,
поддержка тестирования,
объяснение ошибок.
Но он не должен единолично выносить окончательное независимое заключение о соответствии собственной системы. Если один и тот же человек:
проектирует систему,
выбирает тестовые сценарии,
создаёт доказательства,
определяет значимость замечаний,
утверждает публичный знак прохождения аудита,
граница между аудитом и самодекларацией исчезает. Обоснованное распределение ролей может выглядеть так:
Разработчик создаёт доказательства. Независимый аудитор проверяет их. Организация берёт на себя ответственность за решение о риске.
Может ли аудитор оказывать услуги по исправлению?
Обнаружив проблему, аудитор может помочь её исправить. Это не всегда неправильно: знание системы способно ускорить работу. Но возникают два риска:
Аудитор может преувеличить серьёзность замечания, чтобы продать больше услуг по исправлению.
Он может сам одобрить собственное исправление и представить это одобрение как независимое.
Следующие меры следует сочетать с учётом характера конфликта интересов. Раскрытия отношений или разделения договоров недостаточно, чтобы одобрение собственного исправления стало независимым. При закрытии критического замечания доказательства повторного тестирования должен проверить другой аудитор, который не выполнял исправление и чьи связанные с ним интересы были оценены:
Разделить договоры на аудит и исправление
Не привязывать вознаграждение к числу замечаний
Поручить повторное тестирование после исправления другому специалисту
Раскрыть заинтересованность в отчёте
Предусмотреть вторую подпись при закрытии критических замечаний
Аудитор может предложить решение. Но он не должен утверждать, что организация обязана приобрести именно предложенное им решение.
Декларация о конфликте интересов при аудите
Каждый аудитор и каждая аудиторская команда должны раскрывать следующие связи:
Участие в проектировании системы
Действующие коммерческие отношения с организацией
Оплату, зависящую от результата аудита
Продажу услуг по исправлению или продуктов
Отношения с конкурирующей организацией
Комиссионное вознаграждение от проверяемого поставщика
Близкие личные отношения с руководителями или сотрудниками
Партнёрство с тем же поставщиком модели или инструментов
Прямую заинтересованность в результате аудита с точки зрения репутации или публикаций
Раскрытие конфликта интересов не всегда устраняет его, но не даёт ему остаться скрытым. Одними конфликтами можно управлять. Другие требуют, чтобы аудитор отказался от участия в вынесении соответствующего заключения. Например, разработчик системы может предоставить технические доказательства. Но он не должен подписывать окончательное заключение о «независимо подтверждённом соответствии».
Независимость защищает и проверяемую организацию
Независимость — это не только защита аудитора от давления организации. Организация тоже должна быть защищена от произвола аудитора. Аудитор не вправе:
без разрешения расширять границы проверки,
выносить жёсткое заключение, не подкреплённое доказательствами,
публично раскрывать коммерческие тайны,
запугивать организацию ради продажи услуг по исправлению,
выдавать результат синтетического теста за реальный инцидент в рабочей системе,
препятствовать праву организации на ответ.
Независимость не даёт права действовать без полномочий. Аудитор свободен, но в пределах доказательств, границ проверки и профессиональной ответственности.
Что такое границы аудита?
Организация может сказать: «Проверьте нашего агента продаж». Этого недостаточно. Агент продаж может выполнять следующие задачи:
Исследование веб-источников
Оценка соответствия компании профилю потенциального клиента
Поиск контактных лиц
Обогащение данных
Подготовка черновиков писем
Отправка писем
Сообщения в WhatsApp
Планирование встреч
Предложение цены
Создание записей в CRM
Последующие обращения
Вызов субагентов
Какие из них входят в проверку? На каких языках и в каких странах? С какими учётными записями и классами данных? В какой среде? Как распределены роли людей? Границы аудита не сводятся к имени агента. Они определяют, насколько далеко распространяется аудиторское заключение.
Девять измерений границ аудита
В протоколе аудита NOMOS GBO границы следует определять как минимум по девяти измерениям.
1. Система
Какая модель, агент, субагент и оркестрация?
2. Поведение
Исследование, рекомендация, черновик, отправка, платёж, публикация, удаление или остановка?
3. Инструменты
Какие инструменты для почты, CRM, файлов, браузера, платежей или публикаций?
4. Данные
Какие общедоступные, внутренние, персональные, чувствительные или биометрические данные?
5. Люди
Какие пользователи, сотрудники, клиенты или затронутые группы?
6. Язык и география
Какие языки, страны, регионы и правовые условия?
7. Среда
Локальная или тестовая среда, теневой режим, ограниченный запуск в рабочей среде или полноценная эксплуатация?
8. Время
Какие даты, версии, периоды выполнения задач и очереди?
9. Жизненный цикл
Какие этапы: запуск, продолжение, передача, остановка, откат, оспаривание и повторный запуск? Если одно из измерений не определено, заключение может ошибочно распространиться за пределы проверенного.
Почему важно указывать исключения?
В аудиторских отчётах часто описывают то, что входит в проверку, а исключения оставляют для короткой сноски. Но для понимания заключения непроверенные действия не менее важны, чем проверенные. Например, агент закупок мог:
пройти тестирование разовых покупок,
не тестироваться на автоматическом продлении,
не тестироваться на отмене,
проверяться только с тремя одобренными продавцами.
Если публично заявить: «Агент закупок прошёл аудит», пользователь может решить, что оценён весь цикл закупок. Точнее будет сказать: «Проверено поведение агента при разовых, обратимых покупках с низким риском у трёх одобренных продавцов. Подписки, продление, отмена и работа с новыми продавцами не входят в границы проверки». По каждой существенной исключённой области нужно указать три вещи:
Почему она исключена?
Какой риск сохраняется?
Как это ограничивает утверждение по итогам аудита?
Вне границ проверки — не значит безопасно
Исключение поведения из проверки может породить три ошибочных толкования.
Ошибка 1
«Раз это не проверяли, значит, проблемы нет». На самом деле неизвестно, есть ли проблема.
Ошибка 2
«Раз это не входит в проверку, значит, это неважно». На самом деле область могли исключить именно потому, что она рискованна.
Ошибка 3
«Если основная система прошла проверку, исключённая часть, вероятно, тоже пройдёт». На самом деле поведение с другими инструментами, полномочиями или данными может дать иной результат. Исключённая область — не положительное и не отрицательное заключение, а прямо обозначенная неопределённость.
Подмена границ аудита
Организация может заказать аудит самой безопасной части системы, а результат использовать для системы целиком. Например:
Тестируют только агента, создающего черновики.
Результат публикуют как «система агентов продаж прошла аудит».
Оценивают только тестовую среду.
Результат представляют как «рабочая система безопасна».
Выполняют только англоязычные сценарии.
Результат объявляют как «многоязычный агент соответствует требованиям».
Изучают только центрального агента.
Результат распространяют на всю сеть субагентов.
Используют только положительные сценарии.
Результат представляют как подтверждение надёжности контроля полномочий и остановки.
Для этого можно предложить название:
Подмена границ аудита
Подмена границ аудита — это представление результата узкой, простой или низкорисковой проверки как доказательства надёжности более широкой системы, поведения, языка или области риска. Это искажение отчётности. Даже если технический результат верен, смысл, переданный публике, неверен.
Ограничение проверки удобными примерами
Организация может выбирать только те области, в которых она сильна. Например:
Одобренных продавцов включают в проверку.
Новых продавцов и тех, о ком пока недостаточно известно, исключают.
Действия с одобрением человека тестируют.
Границы действий без одобрения не проверяют.
Английский язык включают.
Более слабые языковые версии исключают.
Используют тестовую среду.
Разрешения токенов рабочей системы не изучают.
Основного агента тестируют.
Делегирование полномочий субагентам выводят за границы проверки.
Не всякий выбор границ ошибочен. Ресурсы и риски могут требовать поэтапного аудита. Проблема возникает, когда границы выбирают так, чтобы приукрасить результат, и открыто об этом не сообщают. Это можно назвать так:
Ограничение проверки удобными примерами
Организация вправе провести ограниченный аудит. Но она должна объяснить, почему он ограничен и какой риск остаётся.
Исключение рискованной области
Некоторые действия с серьёзными последствиями трудно проверять на практике. Настоящие платежи могут быть нежелательны. Общение с реальными клиентами рискованно. Создание биометрических материалов требует осторожности. Вместо полного исключения таких действий можно использовать безопасные имитации:
Тестовое платёжное средство
Почтовый адрес для аудита
Синтетического клиента
Искусственный аватар с надлежащим разрешением
Отдельные тестовые очереди
Теневой режим
Контролируемую тестовую учётную запись в рабочей среде (canary): запись для ограниченного теста в реальной системе, с заранее письменно определёнными границами проверки, ограничениями на использование данных и способом остановки.
Если непосредственно проверить рискованное поведение в рабочей системе невозможно, можно совместно использовать:
Технические разрешения,
конфигурацию,
синтетическое поведение,
доказательства прошлых инцидентов,
ограниченную проверку через canary.
Аудит должен либо проводиться безопасным способом, либо завершаться заключением с явно указанными ограничениями.
Репрезентативный и полный охват
Невозможно проверить каждую систему во всех возможных сценариях. Аудит может использовать выборку, но она должна быть репрезентативной. Например, систему с поддержкой шести языков можно полностью протестировать на двух, а на остальных четырёх — по ограниченному набору сценариев. Это допустимо, но выбор должен опираться на:
Языковую семью
Направление письма справа налево
Различия в коммерческой терминологии
Частоту ошибок в прошлом
Объём использования
Риск
Если арабский язык вызывает особое поведение системы, связанное с языком и направлением справа налево, результаты на английском не могут корректно его представлять. Точно так же результаты низкорискового поиска товаров не могут представлять платёжное поведение с высоким риском. Выборка позволяет сократить число тестов, но не даёт права игнорировать различия в поведении. Метод отбора сценариев подробно разрабатывается в шестой главе.
Зачем фиксировать границы аудита?
Если во время аудита система продолжает меняться, становится непонятно, какая версия проверялась. Сценарий заканчивается неудачей. Разработчик меняет инструкцию. Повторный тест успешен. В отчёте остаётся только последний результат. Это создаёт путаницу в ответах на следующие вопросы:
Провалила ли тест исходная система?
Прошла ли его новая система?
Какую версию предлагают публике?
Какая версия работает в производственной среде?
Исправления не запрещены. Напротив, улучшение — одна из целей аудита. Но первый результат нельзя стирать, а новую версию нужно проверять отдельно. Поэтому до начала аудита создаётся:
Запись о фиксации границ аудита
Что закрепляет запись о фиксации границ аудита?
Как минимум необходимо записать:
Версию агента и модели
Системные инструкции и инструкции разработчика
Соглашение о полномочиях
Список инструментов
Разрешения API
Сервисные учётные записи
Субагентов
Структуру памяти и соответствующий снимок её состояния
Канонические источники данных
Роли людей
Тестовую среду
Отличия от рабочей среды
Языковые версии
Конфигурацию измерений
Систему остановки и восстановления
Хеши критических файлов или конфигураций
Время начала и окончания аудита
Необязательно хранить полную копию каждой детали. Но должны быть идентификаторы версий, позволяющие доказать, к какой системе относится результат.
Что происходит при изменениях во время аудита?
Изменения можно разделить на три класса.
Класс A — Несущественное изменение
Исправление орфографии или пояснение, не влияющее на проверяемое поведение. Изменение регистрируют. Аудит может продолжаться.
Класс B — Ограниченное существенное изменение
Изменение инструмента, инструкции или полномочий, затрагивающее конкретную область тестирования. Соответствующие сценарии повторно выполняют на новой версии. Прежний результат сохраняют.
Класс C — Существенное изменение основ системы
Изменение модели, полномочий на действия, архитектуры субагентов, источника данных или системы остановки делает прежнюю фиксацию границ недействительной. Нужна новая версия аудита или заново зафиксированное исходное состояние. Например, удалить разрешение send_message после обнаружения отправки без одобрения — полезное исправление. Но после этого нельзя описывать исходную систему словами «Нарушения не было». Правильная запись выглядит так:
v2.4: Наблюдалась отправка без одобрения. Исправление: Инструмент отправки удалён. Повторный тест v2.5: В 24 соответствующих сценариях отправка не наблюдалась.
Эта запись показывает не слабость организации, а её способность учиться.
Скрытое исправление во время аудита
После неудачного теста разработчик может незаметно изменить систему и запустить её повторно под тем же идентификатором. Тогда результат можно представить словами: «К концу тестирования система прошла проверку». Но целостность аудита нарушается. Для такой практики можно предложить название:
Скрытое исправление во время аудита
При регистрации каждого изменения нужно указать:
дату,
выполнившего его человека или агента,
причину,
затронутые сценарии,
новую версию.
Аудит проводят не ради образа безупречной системы, а чтобы показать её реальное поведение и путь к улучшению.
Первый основной документ: Документ о полномочиях на проведение аудита
После Карточки проверяемого утверждения следует составить:
Документ о полномочиях на проведение аудита NOMOS GBO
Он определяет допустимые действия аудитора и ответственность организации.
ДОКУМЕНТ О ПОЛНОМОЧИЯХ НА ПРОВЕДЕНИЕ АУДИТА — ПРИМЕР ДЛЯ ЧЕЛОВЕКА
Идентификатор аудита: GBO-AUDIT-2026-001
Заказчик аудита: Операционное руководство NobleAxis
Человек, предоставляющий полномочия: Имя, роль и основание права представлять организацию
Ответственный за систему: Руководитель операционных процессов в продажах
Ответственный за техническую часть: Руководитель агентных систем
Уполномоченный, отвечающий за использование данных: Назначенное контактное лицо по рабочим вопросам; контролёр данных в правовом смысле и обработчик, при его наличии, указываются отдельно.
Аудитор: Независимая команда аудита GBO
Цель аудита: Оценить поведение агента поиска клиентов при исследовании, подготовке черновиков, отправке с одобрением человека и остановке.
Разрешённые действия при аудите:
Изучение документов
Проверка разрешений и журналов в режиме только чтения
Использование синтетических компаний и получателей
Контролируемые сообщения на почтовый адрес аудита
Тестирование полномочий субагентов
Учение по остановке очереди
Тестирование внешних инструкций в среде аудита
Тестирование в рабочей системе только через заранее определённую учётную запись canary
Запрещённые действия при аудите:
Сообщения реальному клиенту
Реальные платежи
Удаление клиентских данных в рабочей системе
Копирование персональных данных без полномочий
Публикация общедоступного контента
Остановка производственной системы без уведомления
Загрузка данных аудита во внешнюю ИИ-систему без одобрения
Полномочия аудитора на аварийную остановку: временно приостановить новые операции, если наблюдается продолжающаяся несанкционированная внешняя отправка, несанкционированная передача персональных данных или неконтролируемое действие с серьёзными последствиями; немедленно уведомить ответственного за инцидент в организации.
План хранения доказательств: В этом синтетическом примере предусмотрены 180 дней, шифрование при хранении и квитанция об удалении. Этот срок не является универсальной правовой обязанностью. Конкретную цель, тип данных и действующие обязательства оценивают отдельно. Если спор продолжается или действует обязанность сохранить материалы, срок пересматривают с обоснованием.
Использование субподрядчиков или ИИ-инструментов: Раскрыто, одобрено, границы использования данных определены.
Право организации на ответ: По каждому замечанию она может представить доказательства и пояснения в установленный срок.
Право организации наложить вето на замечание: Отсутствует. Доказанную фактическую ошибку можно исправить, но замечание, подкреплённое доказательствами, нельзя удалить по коммерческим причинам.
Публичное заявление: Публикуется только одобренное резюме с указанием фактических границ, версии, даты и явных ограничений.
Начало и окончание полномочий: С 1 сентября 2026 года, 09:00, до 15 сентября 2026 года, 18:00, по времени Турции (UTC+03:00). Последующие повторные тесты требуют новых или явно продлённых полномочий.
Условие повторного предоставления полномочий: Изменение границ проверки или уровня действий требует новых полномочий.
Машиночитаемый Документ о полномочиях на проведение аудита
audit_authorization:
audit_id: GBO-AUDIT-2026-001
authorized_by:
role: authorized_system_owner
authority_basis: internal_governance_record
system_owner:
role: sales_operations_owner
technical_owner:
role: agent_platform_owner
auditor:
identity: independent_audit_team
independence_level: III
permitted_actions:
- document_review
- read_only_permission_review
- synthetic_entity_testing
- controlled_email_to_audit_address
- subagent_authority_test
- queue_stop_drill
- prompt_injection_test
- controlled_live_testing_only_in_pre_authorized_canary_account
prohibited_actions:
- contact_real_customer
- execute_real_payment
- delete_live_customer_data
- publish_public_content
- upload_evidence_to_unapproved_ai_service
- unannounced_production_shutdown_outside_emergency_scope
data_scope:
allowed:
- public_company_data
- masked_transaction_logs
- synthetic_customer_records
prohibited:
- unrelated_personal_data
- unrestricted_full_mailbox_export
emergency_stop:
permitted: true
limited_to_containment_of_in_scope_new_actions: true
immediate_notification_to_incident_owner: required
triggers:
- unauthorized_live_send
- prohibited_data_exfiltration
- uncontrolled_high_impact_action
evidence_retention:
duration_days: 180
encryption_required: true
deletion_receipt_required: true
example_duration_not_universal_legal_rule: true
review_on_ongoing_dispute_or_preservation_duty: required
external_ai_or_subcontractor_use:
prior_disclosure: required
explicit_approval: required
defined_data_boundary: required
public_disclosure:
scope_limited: true
client_review_for_factual_errors: true
client_veto_over_findings: false
valid_from: 2026-09-01T09:00:00+03:00
valid_until: 2026-09-15T18:00:00+03:00Документ устанавливает пределы полномочий аудитора. Чтобы эти пределы соблюдались, технический доступ и средства контроля тестов также должны быть настроены в соответствии с документом.
Второй основной документ: Запись о фиксации границ аудита
После Документа о полномочиях на проведение аудита фиксируют состояние системы на конкретный момент.
ЗАПИСЬ О ФИКСАЦИИ ГРАНИЦ АУДИТА — ПРИМЕР
Идентификатор аудита: GBO-AUDIT-2026-001
Время фиксации: 1 сентября 2026 года, 09:30
Центральный агент: SALES-RESEARCH-v2.4
Версия базовой модели: Зарегистрированный технический идентификатор
Системная инструкция: POLICY-v3.1 — хеш зарегистрирован
Соглашение о полномочиях: AUTH-v2.7
Субагенты:
Web Research v1.8
Recipient Resolution v1.4
Email Drafting v2.1
Approved Send v1.3
Queue Manager v1.2
Подключённые инструменты:
Веб-поиск
Чтение и запись в CRM
Черновики и отправка в Gmail
Календарь
Очередь задач
Фактические разрешения API: Зарегистрированы по каждому инструменту.
Состояние памяти: Постоянная память предпочтений включена; записывать в неё персональные данные клиентов запрещено.
Канонические источники данных:
Каталог услуг v4.2
Реестр цен v3.7
Реестр полномочий людей v2.5
Политика коммуникаций v3.0
Языки в границах аудита: Английский, турецкий, немецкий
Исключённые языки: Арабский, испанский, русский
Тестовая среда: Синтетическая CRM и почтовые адреса для аудита.
Ограниченная область в рабочей среде: Реальная инфраструктура Gmail, отправка только на домен аудита.
Система остановки: Центральный агент, субагенты, очередь и токен отправки Gmail.
Точка восстановления: Манифест инструментов и полномочий до начала аудита.
Признаки существенного изменения:
Смена модели
Изменение инструмента отправки
Новый субагент
Изменение политики полномочий
Изменение постоянной памяти
Новый язык
Использование клиентских данных рабочей системы
Подписи при фиксации: Ответственный за систему, ответственный за техническую часть, аудитор.
Что следует из записи о фиксации границ аудита
Зафиксированная система не обязана оставаться неподвижной, как музейный экспонат. Повседневная работа может продолжаться, но должно оставаться ясно, какая именно версия проверялась. Если рабочая система меняется, можно:
сохранить версию аудита в отдельной среде,
зарегистрировать изменение,
повторить соответствующие тесты,
сузить аудиторское заключение.
Важно не потерять связь между результатом и версией, к которой он относится.
Декларация о независимости и границах аудита
В аудиторском отчёте должна быть отдельная декларация:
Декларация о независимости и границах аудита
Пример: «Команда аудита не участвовала в разработке проверяемой системы. Вознаграждение не зависит от результата аудита. Команда может оказывать услуги по исправлению, но тесты для закрытия критических замечаний проведёт другой специалист. Аудит охватывает поиск клиентов на английском, турецком и немецком языках. WhatsApp, финансовые предложения, принятие договоров и поведение на арабском, испанском и русском исключены. С реальными клиентами не связывались; использовались контролируемые адреса аудита». Декларация может быть короткой, но не должна скрывать существенные связи.
Право организации на ответ
Замечания аудита могут быть ошибочными. Аудитор мог не увидеть важный документ, неверно понять цель поведения или неполно истолковать технический журнал. Поэтому организация должна иметь возможность ответить на каждое замечание. Ответ может включать:
Новые доказательства
Исправление фактической ошибки
Пояснение границ проверки
Технический контекст
Принятие риска
План исправлений
Несогласие с оценкой
В итоговом отчёте можно отдельно показать:
ЗАМЕЧАНИЕ АУДИТОРА ОТВЕТ ОРГАНИЗАЦИИ ОКОНЧАТЕЛЬНАЯ ОЦЕНКА АУДИТОРА
Право организации на ответ не означает права удалить замечание. Но и аудитор не должен игнорировать её ответы.
Разногласия
Оценка некоторых действий может быть неоднозначной. Например:
Нужно ли одобрение человека для конкретной операции?
Достаточно ли тесно использование данных связано с первоначальной целью?
Действительно ли поставщик является независимым источником?
Существенно ли изменение?
Стороны могут не договориться. Отчёт не должен создавать видимость согласия. Можно записать:
Позиция аудитора: Новая цель использования выходит за пределы первоначального согласия. Позиция организации: Использование соответствует существующей цели развития услуги. Статус: Неразрешённое замечание высокого приоритета об ограничении цели. Рекомендуются приостановка соответствующего использования данных и экспертная проверка.
Открытое разногласие не подрывает достоверность. Оно честно отмечает, где установить истину трудно.
Кто отвечает за остаточный риск?
Аудитор сообщает о замечании. Организация может быть не в состоянии сразу устранить проблему. Определённый риск можно временно принять. Например:
Широкий доступ может ненадолго оставаться открытым в низкорисковой тестовой среде.
Старая система может работать до завершения миграции.
Определённая языковая версия может ожидать повторного тестирования.
Принимать риск — не задача аудитора. Аудитор:
определяет риск,
подкрепляет его доказательствами,
объясняет его значимость,
даёт рекомендацию.
Риск принимает уполномоченный человек в организации. Такое принятие должно:
действовать ограниченный срок,
иметь обоснование,
иметь чёткие пределы,
содержать дату повторной оценки.
Агент или разработчик не может единолично принять риск, указанный в собственном замечании. Принятие риска не означает его исчезновения. Оно показывает, кто взял на себя ответственность и на какой срок.
Использование ИИ-инструментов в аудите
Аудитор GBO тоже может использовать ИИ-инструменты. Например, привлекать агентов, чтобы:
классифицировать журналы,
группировать похожие инциденты,
сравнивать многоязычные тексты,
создавать варианты тестов,
упорядочивать реестр доказательств,
находить противоречия.
Это эффективно. Но агенты аудита тоже подчиняются протоколу. Необходимо ответить на следующие вопросы:
Какая модель использовалась?
К каким данным она получила доступ?
Передавались ли доказательства во внешнюю систему?
Проверил ли человек результат?
Классификация агента — окончательное замечание или предложение?
Проверил ли агент аудита сам себя?
Какая версия использовалась?
Как будут разбирать ошибку или инцидент с конфиденциальностью?
Аудитор не может ограничиться словами: «ИИ проанализировал все журналы и не обнаружил проблем». Это лишь утверждение другой системы. Должно оставаться ясно, какой человек и какая организация отвечают за окончательное заключение.
Сохранность доказательств аудита
Независимость не сводится к доступу к доказательствам. Важна и защита от их последующего изменения. Как минимум можно сохранять:
Идентификатор источника
Время получения
Версию
Хеш или запись о целостности
Способ маскирования
Сведения о том, кто получал доступ
Выполненные преобразования
Срок хранения
Запись об удалении
Аудитор не должен бессрочно хранить копию всех данных рабочей системы. Но основание критического замечания должно поддаваться последующему восстановлению. Хранение и цепочка доказательств подробно рассматриваются в четвёртой главе.
Связь полномочий, независимости и границ проверки
Эти три понятия кажутся отдельными. На деле они ограничивают друг друга.
Полномочия
Что аудитор вправе делать?
Независимость
Насколько свободно и честно аудитор может толковать увиденное?
Границы проверки
О какой системе и каком поведении аудитор вправе делать выводы? Его полномочия могут быть широкими. Но если он финансово зависит от результата, доверие к его интерпретации снижается. Он может быть независимым. Но если не может изучить технические разрешения, уровень доказательств снижается. Границы проверки могут быть широкими. Однако без полномочий на тесты в рабочей среде поведенческое заключение остаётся ограниченным. Поэтому надёжный аудит можно выразить так:
НАДЁЖНЫЙ АУДИТ = ДЕЙСТВИТЕЛЬНЫЕ ПОЛНОМОЧИЯ И НЕЗАВИСИМОСТЬ, ПОДКРЕПЛЁННАЯ ДЕЙСТВУЮЩИМИ МЕРАМИ ЗАЩИТЫ И ЯСНЫЕ ГРАНИЦЫ И ДОСТАТОЧНЫЙ ДОСТУП К ДОКАЗАТЕЛЬСТВАМ И ПОЛНОМОЧИЯ НА БЕЗОПАСНЫЕ ТЕСТЫ И ОГРАНИЧЕННОЕ ПУБЛИЧНОЕ ЗАЯВЛЕНИЕ
Ни один из этих элементов не заменяет другой.
Шлюз полномочий и независимости перед аудитом
До начала тестов необходимо пройти следующие шлюзы:
1. Шлюз предоставления полномочий
Действительно ли человек или организация, запросившие аудит, имеют на это право?
2. Шлюз ответственности за систему
Известны ли люди, отвечающие за систему и её техническую сторону?
3. Шлюз полномочий на доступ к данным
На каком законном и ограниченном основании аудитор может увидеть необходимые данные?
4. Шлюз полномочий на действия
Какой уровень полномочий есть у аудитора на изучение документов, синтетические тесты, тесты в рабочей среде и остановку?
5. Шлюз ограничения вреда
Какое воздействие аудит может оказать на реальных людей, деньги, данные или операции?
6. Шлюз независимости
Каков уровень организационной, финансовой, технической и интерпретационной независимости?
7. Шлюз конфликта интересов
Раскрыты ли отношения, связанные с созданием, исправлением или продажей системы либо с продвижением результата аудита?
8. Шлюз полноты границ проверки
Ясно ли определены система, поведение, инструменты, данные, языки, среда и жизненный цикл?
9. Шлюз исключённых рисков
Видны ли существенные исключённые области и их последствия?
10. Шлюз фиксации
Зафиксированы ли проверяемая версия и конфигурация?
11. Шлюз аварийной остановки
Кто и как остановит систему, если во время аудита будет обнаружен вред в рабочей среде?
12. Шлюз публичного заявления
Может ли результат быть представлен шире его фактических границ? Если кратко:
ПОЛНОМОЧИЯ НА НАЧАЛО АУДИТА = ЗАПРОС УПОЛНОМОЧЕННОЙ СТОРОНЫ И НАЗНАЧЕННЫЙ ОТВЕТСТВЕННЫЙ ЗА СИСТЕМУ И ОГРАНИЧЕННЫЙ ДОСТУП К ДАННЫМ И ЯВНЫЕ ПОЛНОМОЧИЯ НА ТЕСТЫ И КОНФЛИКТЫ ИНТЕРЕСОВ ПОД КОНТРОЛЕМ И ЗАФИКСИРОВАННЫЕ ГРАНИЦЫ И БЕЗОПАСНАЯ ОСТАНОВКА И ЧЕСТНОЕ ПУБЛИЧНОЕ ЗАЯВЛЕНИЕ
Если нет полномочий или безопасных условий тестирования, соответствующее действие не начинают. Продолжить аудит можно только в более узких границах, где сохраняются и действительные полномочия, и безопасные условия. Метод и заключение ограничивают соответственно.
Статусы полномочий на аудит
Аудит может иметь один из следующих статусов:
Разрешён
Все необходимые полномочия со стороны людей, в отношении системы, данных и тестов оформлены.
Разрешён с условиями
Может проводиться с определёнными ограничениями по данным, среде или действиям.
Разрешено только изучение документов
Полномочий на технические и поведенческие тесты нет. Заключение ограничивается утверждениями и документами.
Недостаточно полномочий
Нет доступа или права на тесты, необходимых для проверки заявленного утверждения.
Приостановлен
Аудит временно остановлен из-за существенного изменения системы, инцидента или проблемы с полномочиями.
Прекращён
Сохранить целостность аудита, безопасность доказательств или условия полномочий больше невозможно. Эти состояния нужно явно отражать в отчёте. Если аудит не удалось завершить, следует объяснить, почему заключение не было вынесено, а не просто писать: «Проверка провалена».
Аудит напоказ
Организация может предъявить:
Безупречную демонстрацию
Отобранные снимки экрана
Высокую оценку успешности
Положительные отзывы клиентов
Тщательно подготовленную политику
Знак прохождения аудита
Но если аудитор не видит:
фактические разрешения,
проваленные тесты,
субагентов,
очереди,
исключённые из проверки области,
записи об инцидентах,
работа превращается в:
Аудит напоказ
При аудите напоказ видимость надёжности становится важнее доказательств поведения. Вот его признаки:
Тесты выбирает только сама организация.
Во время тестирования систему незаметно меняют.
Неудачные результаты убирают из отчёта.
Аудитор не может свободно составить публичное заявление.
Риски за пределами проверки скрывают.
Знак аудита заметнее полного отчёта.
Оплата или продолжение аудита зависят от результата «пройден».
Вместо исходных доказательств показывают подготовленную презентацию.
Протокол GBO должен защищать от этих рисков и сам аудит.
Честное описание границ в публичном заявлении
При публикации результата аудита нужно различать четыре формулировки:
Аудит проведён
Состоялась определённая проверка.
Проверка пройдена в установленных границах
В заданных видах поведения и сценариях условия выполнены.
Пригодно с условиями
Систему можно использовать с учётом определённых замечаний аудита или ограничений применения.
Непригодно из-за критического замечания аудита
Система не готова к применению в определённой области поведения. Следует избегать таких безоговорочных заявлений:
«Полностью соответствует GBO». «Безопасно для всех агентов». «Не ошибается». «Человеческий контроль гарантирован». «Защищено от всех 99 ошибок».
Если доказательства относятся лишь к определённой версии и установленным границам, публичное заявление тоже не должно выходить за эти пределы.
Вывод главы
Аудит GBO начинается не с технических тестов. Сначала нужно ответить на вопросы:
Кто запросил аудит? Кто разрешил его проведение? Есть ли у этого лица соответствующее право? К каким данным аудитор вправе обращаться? Какие виды поведения он может безопасно проверять? Насколько глубоко ему разрешено вмешиваться в рабочую систему? Может ли он остановить систему, если заметит продолжающийся вред? Каковы его коммерческие и институциональные интересы? Какие виды поведения включены в проверку, а какие исключены? Какая версия системы будет сохраняться на протяжении тестов? В каких пределах результат можно огласить публично?
Аудит без ответов на эти вопросы может выглядеть убедительно. Однако он несёт три основных риска:
Он может проводиться без необходимых полномочий.
Ему может недоставать независимости.
Его могут представить более широким, чем он был на самом деле.
Полномочия на аудит не дают права на неограниченный доступ к системе. Независимость не позволяет аудитору выносить любые суждения без оглядки на доказательства и границы проверки. А определение границ — не способ выбрать несколько простых сценариев и на этом основании объявить надёжной всю систему. Достоверный аудит GBO сохраняет следующий баланс:
Аудитор может получить необходимые доказательства. Но не вправе забирать ненужные данные. Он может реалистично проверить систему. Но не вправе причинять неконтролируемый вред под предлогом аудита. Организация может ответить на замечание. Но не вправе удалить его по коммерческим причинам. Аудит может быть ограниченным. Но его нельзя представлять публике как неограниченный. Систему можно исправить. Но первоначальную неудачу нельзя стереть из записи.
Первый вывод главы: право проверять поведение требует явного и ограниченного поведенческого договора для самого аудита. Второй: независимость не означает отсутствие отношений. Она означает, что интересы раскрыты, находятся под контролем, а их давление на выводы ограничено. Третий: границы должны показывать не только то, что аудит знает, но и то, чего он не знает. Четвёртый: существенное изменение во время тестирования требует записи о новой версии или новых границах. Первоначальная неудача не удаляется; исправление и повторный тест фиксируются отдельно. Пятый: результат узкой проверки не позволяет заявлять о надёжности всей агентной сети, всех языков или всей области рисков.
И последний вывод: если аудит проводится без полномочий, лишён независимости или имеет неясные границы, высокая оценка агента не является надёжным доказательством. Теперь у нас есть:
Карточка проверяемого утверждения
Документ о полномочиях на проведение аудита
Запись о фиксации границ аудита
Декларация о независимости и границах аудита
Но проверяемая система всё ещё может оставаться ящиком, о котором известны лишь названия. Слова «агент продаж», «веб-агент» или «агент генерального директора» не раскрывают реальную архитектуру поведения. От чьего имени работает агент? Каких субагентов он вызывает? К каким инструментам имеет доступ? Какие данные приходят из какой системы? Какие действия требуют одобрения какого человека? По каким очередям и внешним платформам распределяется задача? До каких точек должна дойти команда остановки? Пока эти связи не нанесены на карту, невозможно построить правильный сценарий. Можно проверить не тот объект, оставить критически важного субагента за пределами аудита или не увидеть реальный путь отмывания полномочий. В следующей главе мы сделаем область проверяемого поведения видимой:
Карта поведения: люди, агенты, инструменты и полномочия
Чтобы проверить систему, сначала нужно увидеть не только, что она собой представляет. Нужно понять, от чьего имени, каким инструментом, с какими данными и через какую цепочку поведения она воздействует на мир.
Агентную систему без карты не проверяют. Исследуют лишь её видимую сторону.