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

Управляющий агент

Веб-агент

Агент SEO и GEO

Агент социальных сетей

Почтовый агент

Агент поиска клиентов

Финансовый агент

Агент аудита

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

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

Одобрение человека предусмотрено лишь внутренней политикой. В инструменте отправки нет технического шлюза одобрения. Автоматизация повторных контактов в CRM назначает второе сообщение через три дня после первого. Этот процесс не зависит от диспетчера задач центрального агента. Если центральный агент остановится, очередь CRM может продолжить работу. Кроме того, выясняется: когда агент поиска клиентов не может отправить письмо, он может создать приглашение на встречу. В описании приглашения можно разместить продающее сообщение. Получается тот же внешний контакт без использования запрещённого пути отправки почты. Аудитор спрашивает дальше: «Может ли веб-агент менять цены?» Ответ компании однозначен: «Нет. Цены определяет только руководство».

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

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

В очереди повторных контактов CRM остаются девять сообщений.

Задача SEO на старом сервере запустится снова в полночь.

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

Токен служебной учётной записи почты по-прежнему действителен.

Автоматическая классификация счетов финансовым агентом привязана к независимому планировщику.

У компании восемь агентов. Но её поведенческая система состоит не из восьми прямоугольников. К концу аудита обнаружены:

8 публично представленных ролей агентов

17 отдельных технических экземпляров агентов

6 типов временных субагентов

12 внешних инструментов

23 служебные учётные записи или токена доступа

7 запланированных задач

4 независимые очереди

3 общие учётные записи

2 старых, но всё ещё действующих ключа доступа

5 путей выполнения действий, позволяющих косвенно обойти одобрение человека

6 точек поведенческой системы, на которые не влияет остановка центрального агента

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

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

Что такое Карта поведения?

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

какой сервер подключён к какому API,

какой агент использует какой инструмент,

в каком отделе работает сотрудник.

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

АГЕНТ → ПОЧТОВЫЙ ИНСТРУМЕНТ

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

может читать только входящие сообщения,

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

не может отправлять сообщения наружу.

Во втором случае агент может:

отправлять новые сообщения,

делать массовые рассылки,

удалять сообщения,

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

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

Чем Карта поведения не является

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

Не организационная схема

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

от людей к агентам,

от агентов к инструментам,

от инструментов к внешним результатам.

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

Не список агентов

В списке агентов могут быть названы активные системы. Карта поведения дополнительно показывает:

Техническую идентичность агента

Его корневую задачу

Ответственного за него человека

Его субагентов

Его источники данных

Разрешения на использование инструментов

Цели действий

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

Путь остановки

Способ получения доказательств

Имя агента — всего один узел на карте.

Не схема потоков данных

Схема потоков данных показывает, откуда и куда передаётся информация. Карта поведения задаёт ещё один вопрос: какое решение или действие делают возможным эти данные? Телефон клиента может не передаваться из CRM почтовому агенту. Но если он передаётся агенту WhatsApp, становится возможным внешний контакт. Одни и те же данные в разных инструментах несут разные риски.

Не список управления доступом

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

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

Разница между ответами может оказаться одним из важнейших замечаний аудита.

Не схема рабочего процесса

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

ИССЛЕДОВАНИЕ → ПОДГОТОВКА ЧЕРНОВИКА → ОДОБРЕНИЕ ЧЕЛОВЕКОМ → ОТПРАВКА

Карта поведения показывает и реальные пути:

АГЕНТ ИССЛЕДОВАНИЙ → ИНСТРУМЕНТ КАЛЕНДАРЯ → СООБЩЕНИЕ В ОПИСАНИИ ПРИГЛАШЕНИЯ → ВНЕШНИЙ КОНТАКТ

Идеальный поток и фактические обходные пути сопоставляются на одной карте.

Основной маршрут поведения

Поведение агента часто складывается в такую цепочку:

ЦЕЛЬ ЧЕЛОВЕКА ИЛИ ОРГАНИЗАЦИИ ↓ КОРНЕВАЯ ЗАДАЧА ↓ АГЕНТ ИЛИ АГЕНТНАЯ СЕТЬ ↓ ДАННЫЕ И КАНОНИЧЕСКИЕ ИСТОЧНИКИ ↓ ОЦЕНКА И ВЫБОР ↓ СОГЛАСИЕ, ПОЛНОМОЧИЯ И ОДОБРЕНИЕ ↓ ВЫЗОВ ИНСТРУМЕНТА ↓ ДЕЙСТВИЕ ВО ВНЕШНЕМ МИРЕ ↓ НЕЗАВИСИМАЯ ПРОВЕРКА ↓ КВИТАНЦИЯ О ДЕЙСТВИИ ↓ ОСТАНОВКА, ОТМЕНА И ВОССТАНОВЛЕНИЕ

Эту цепочку можно назвать:

Маршрут поведения NOMOS

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

Цель человека: Подготовить черновик первого обращения к подходящим потенциальным клиентам. Корневая задача: GBO-TASK-2026-00441 Центральный агент: Sales Research v2.4 Субагент: Recipient Resolution v1.4 Данные: Общедоступный сайт компании и канонический каталог услуг Оценка: Компания соответствует профилю услуг. Полномочия: Подготовка черновика разрешена Отправка отключена Инструмент: Инструмент черновиков Gmail. В примере create_draft — символическое действие инструмента, а не фактическое имя метода или области OAuth поставщика. Внешний результат: Черновик создан Сообщение не отправлено Проверка: В папке Sent нет записи За установленный период наблюдения на адрес аудита сообщение не поступило. Эти две записи относятся только к проверенному почтовому пути. Нельзя утверждать, что внешних контактов не было вообще, пока не исключены пути через календарь, субагентов и других получателей. Квитанция: ACTION-8891 Остановка: Можно запретить запуск новых операций. После сохранения минимально необходимых доказательств задачу и черновик можно удалить по плану очистки тестовой среды. На проверенном почтовом пути внешняя отправка не наблюдалась. В квитанции сохраняются ограничения этого вывода по каналу и времени.

Когда этот маршрут ясен, аудитор может установить:

Чего просил человек?

Что сделал агент?

В каких границах он остался?

Как был доказан фактический результат?

Разрыв маршрута поведения означает и разрыв цепочки ответственности системы.

Десять слоёв Карты поведения

Протокол аудита NOMOS GBO выделяет в поведенческой системе десять основных слоёв.

1. Люди и организация

2. Цель и задача

3. Идентичность агента

4. Данные и факты

5. Инструменты и учётные записи

6. Полномочия, согласие и одобрение

7. Действия и цели

8. Делегирование, очереди и планирование

9. Доказательства и проверка

10. Остановка и восстановление

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

1. Люди и организация

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

Проверяемая организация

Юридический оператор

Бренд

Владелец системы

Технический владелец

Владелец данных или сторона, ответственная за их обработку

Человек, отвечающий за агента

Лицо, предоставляющее полномочия

Лицо, одобряющее операцию

Затронутое лицо

Человек, рассматривающий возражения

Лицо, уполномоченное на экстренную остановку

Лицо, уполномоченное на повторный запуск

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

Владелец компании может принять решение о цене.

Веб-агент может внести изменение.

Технический владелец может опубликовать его.

Финансовая команда может обновить счёт.

Руководитель продаж может объяснить изменение клиентам.

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

Принципал: в чьих интересах действует агент

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

Принципал

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

Затронутые стороны

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

его согласие,

его возражение,

возмещение причинённого ему вреда,

его требование остановиться.

2. Цель и задача

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

Цель организации

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

Корневая задача

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

Подзадача

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

Идентификатор корневой задачи

У каждой многоагентной цепочки должен быть уникальный идентификатор корневой задачи:

root_task_id: GBO-TASK-2026-00441

С ним должны быть связаны субагенты, очереди, вызовы инструментов и квитанции о действиях. Тогда аудитор сможет ответить: какое исходное указание человека привело к этому внешнему письму? Без идентификатора корневой задачи цепочка действий показывает лишь последний инструмент. Цель человека теряется.

Максимально допустимый уровень действий

Для каждой задачи нужно определить высшую допустимую ступень поведения. Приведённая ниже шкала от 0 до 6 задаёт предел полномочий по задаче. Это не уровни действий аудитора от 1 до 5 и не шкала внешнего воздействия от 0 до 4. Более высокая ступень не предоставляет автоматически все разрешения, относящиеся к данным, целевым объектам и инструментам на более низких ступенях. Прямые запреты и условия операций сохраняются. Например:

0 — Только чтение 1 — Классификация 2 — Рекомендация 3 — Подготовка черновика 4 — Передача на одобрение человеку 5 — Ограниченное действие 6 — Принятие внешнего обязательства

Если для корневой задачи установлен предел «Уровень 3 — Черновик», цепочка субагентов не может перейти на уровень 5. Эта запись позволяет выявить дрейф задачи, описанный в GBO-ERR-063, и ошибку наследования полномочий из GBO-ERR-056.

3. Идентичность агента

Публичного имени агента для аудита недостаточно. Например, «NOMOS Sales Agent» — название персоны или роли. В реальной системе за ним могут стоять:

Центральный планировщик

Исследовательский субагент

Субагент определения контактных лиц

Агент подготовки черновиков писем

Агент отправки

Менеджер очереди

Поставщик модели

Сервис памяти

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

Идентификационная карточка агента

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

agent_id public_name technical_identity agent_type human_owner root_purpose allowed_actions prohibited_actions connected_tools data_scope subagent_rights authorization_version valid_from valid_until stop_method status

Типы агентов можно классифицировать, например, так:

Центральный планировщик

Специализированный агент

Субагент

Агент аудита

Агент отправки

Исследовательский агент с доступом только на чтение

Временный агент для отдельной задачи

Агент внешнего поставщика

Персона и техническая идентичность

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

Идентичность, видимая пользователю Техническая идентичность, доступная для проверки

Например:

public_name: NOMOS Sales
technical_instance: SALES-ORCH-2026-09-08-04
model_config: MODEL-CONFIG-17
authorization: AUTH-v3.2

Запись о событии не должна сводиться к фразе «Это сделал NOMOS». Нужно иметь возможность установить, какой технический экземпляр действовал и на основании каких полномочий.

Временные субагенты

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

agent_id parent_agent root_task_id purpose allowed_actions data_scope tools expiry stop_parent

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

исследование,

классификация,

синтетический анализ.

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

4. Данные и факты

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

источник,

владельца,

актуальность,

канонический статус,

класс данных,

цель использования.

Примеры источников:

Канонический каталог услуг

Реестр цен

CRM

Реестр полномочий людей

Пользовательская память

Веб-страницы

Каталоги компаний

Социальные сети

Внешние исследовательские источники

Выходные данные других агентов

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

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

Общедоступные

Внутренние

Конфиденциальные

Персональные

Чувствительные

Биометрические

С правовыми ограничениями

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

Если агент способен прочитать источник, это ещё не даёт ему права:

передавать его другому инструменту,

записывать его в память,

использовать его во внешнем сообщении.

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

READ USE_FOR_DECISION SHARE_OR_TRANSMIT

Агент может видеть номер телефона клиента в CRM, но не иметь полномочий использовать его для отправки коммерческого сообщения или передавать в WhatsApp.

Канонические и вторичные источники

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

Канонический источник

Авторитетный первичный источник

Независимая третья сторона

Публикация под контролем организации

Вывод агента

Временные данные

Непроверенный источник

Устаревший или архивный источник

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

5. Инструменты и учётные записи

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

Чтение сообщений

Создание черновиков

Отправка

Пересылка

Удаление

Скачивание вложений

Изменение ярлыков

Вместо общей записи «доступ к Git» нужно отдельно указать:

Чтение

Создание ветки

Создание коммита

Слияние

Запуск развёртывания в рабочей среде

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

Запись о возможностях инструмента

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

tool_id provider account technical_capabilities authorized_capabilities approval_requirements data_access external_effects idempotency_support logging stop_method revocation_method owner

Здесь принципиально важно различать:

Технически может выполнить действие

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

Например:

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

Действие инструмента	Технически возможно	Разрешено организацией	Одобрение человека
Прочитать письмо	Да	Да	Нет
Создать черновик	Да	Да	Нет
Отправить сообщение	Да	Нет	Обязательно
Удалить сообщение	Да	Нет	Запрещено
Скачать вложение	Да	Ограниченно	Зависит от класса данных

Таблица непосредственно показывает разрыв между политикой и техническими разрешениями, описанный в GBO-ERR-094.

Общие учётные записи

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

automation@nobleaxis.example

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

Экземпляр агента

Корневая задача

Версия полномочий

Идентификатор операции

Ответственный человек

Причина отправки

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

6. Полномочия, согласие и одобрение

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

Кто предоставил полномочия?

Имел ли он право их предоставлять?

Какое поведение они охватывают?

Как долго они действуют?

Можно ли делегировать их другому агенту?

Какими данными и целевыми объектами они ограничены?

Где необходимо одобрение человека?

Есть ли согласие затронутого лица?

Какие действия прекратятся при отзыве полномочий?

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

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

Полномочия на ограниченный срок

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

authorization_id: AUTH-2026-8821
agent: APPROVED-SEND-v1.3
action: send_email
target_domain: audit.example
maximum_messages: 1
valid_from: "2026-09-08T14:00:00+03:00"
valid_until: "2026-09-08T14:10:00+03:00"
root_task_id: GBO-TASK-2026-00441

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

Точки одобрения

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

Одобрение человека: - Окончательный текст сообщения - Получатель - Вложения - Цена или обязательство - Канал отправки - Время отправки

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

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

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

лицо другого человека,

его голос,

его персональные данные,

его канал связи.

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

VOICE-CONSENT-17 → Только учебное видео на турецком языке → Внутренний канал компании → До 31 декабря 2026 года → Общедоступные социальные сети исключены

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

7. Действия и цели

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

Прочитать информацию

Классифицировать

Дать рекомендацию

Создать черновик

Изменить запись

Отправить сообщение

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

Опубликовать файл

Выполнить платёж

Оформить подписку

Передать данные

Закрыть учётную запись

Удалить содержимое

Создать биометрический контент

Отправить уведомление внешней поисковой системе

Для каждого действия нужно однозначно идентифицировать его целевой объект.

Типы целевых объектов

Целью действия может быть:

Человек

Компания

Учётная запись клиента

Заказ

Платёжный счёт

Файл

Веб-страница

Учётная запись в социальной сети

Набор данных

Сервер

Календарь

Внешняя платформа

Физическое устройство

У двух целевых объектов может быть одинаковое имя. Поэтому запись о целевом объекте не должна опираться только на отображаемое название. Например:

target_type: company
target_id: ENT-DE-NOVA-0041
canonical_name: Nova Systems GmbH
domain: nova-systems.example

Уровень внешнего воздействия

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

Уровень 0 — Внутреннее наблюдение

Внешних последствий нет.

Уровень 1 — Внутренняя запись или черновик

Обратимое воздействие внутри организации.

Уровень 2 — Ограниченная внешняя коммуникация

Сообщение, приглашение на встречу или обмен данными.

Уровень 3 — Коммерческое или публичное действие

Публикация, предложение, подписка или покупка на небольшую сумму.

Уровень 4 — Действие с серьёзными или труднообратимыми последствиями

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

полномочиям,

одобрению человека,

доказательствам,

остановке,

возврату к прежнему состоянию.

8. Делегирование, очереди и планирование

Агент не всегда действует сразу. Задачу можно:

делегировать другому агенту,

поставить в очередь,

запланировать,

передать внешней платформе,

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

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

Связь делегирования

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

parent_agent child_agent root_task_id delegated_purpose allowed_actions prohibited_actions data_scope authorization_ceiling expiry return_condition

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

Запись об очереди

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

Кто создал очередь?

Какие действия ожидают выполнения?

На каком этапе проверялись полномочия?

Проверяются ли они повторно в момент выполнения?

Что происходит с очередью, когда человек инициирует остановку?

Сколько повторных попыток допускается для операции?

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

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

Например:

queue_id: EMAIL-FOLLOWUP-07
owner: CRM-AUTOMATION
pending_actions: 18
authorization_recheck: false
stop_parent: none

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

Запланированные задания

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

задание cron,

задание по расписанию на внешней платформе,

продление подписки,

автоматическое формирование отчёта.

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

Политика повторных попыток

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

Число повторных попыток

Интервал

Уникальный идентификатор операции

Запрос окончательного статуса

Передачу человеку

Ошибки, при которых повторная попытка не допускается

9. Доказательства и проверка

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

Отчётом самого агента?

Папкой «Отправленные» в почтовом ящике?

Внешним адресом для аудита?

Записью об очереди?

Журналом инструмента?

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

Связь с доказательствами

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

action_id technical_result independent_verification evidence_location evidence_owner timestamp integrity_record retention

Например, для публикации в интернете:

Отчёт о передаче по FTP → скачивание опубликованного файла по HTTPS → сравнение хешей → просмотр в настоящем браузере → проверка смысла

Для отправки электронной почты:

Результат API send → запись об отправленном письме → входящие в аудиторском почтовом ящике → квитанция об операции

Источник доказательства

По карте должно быть видно, не создаёт ли доказательства та же самая система. Если один агент:

выполняет операцию,

пишет отчёт об успехе

и предъявляет собственный отчёт как аудиторское доказательство,

независимости нет. Подробное построение цепочки доказательств — тема главы 4. Здесь главный вопрос таков: есть ли для каждого значимого действия доступная для внешней проверки связь с его реальным результатом?

10. Остановка и восстановление

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

АГЕНТ → ИНСТРУМЕНТ → ДЕЙСТВИЕ

Но не выстраивают обратный путь:

ЗАПРОС ЧЕЛОВЕКА НА ОСТАНОВКУ → ЦЕНТРАЛЬНЫЙ АГЕНТ → СУБАГЕНТ → ОЧЕРЕДЬ → ВНЕШНИЙ ИНСТРУМЕНТ → ОТЗЫВ ТОКЕНА → БЕЗОПАСНОЕ СОСТОЯНИЕ

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

Ребро остановки

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

Кто может остановить?

Через какой канал?

За какое время?

Остановка касается только новых заданий или также уже выполняемых?

Распространяется ли она на субагентов?

Отзывается ли токен?

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

Каково конечное безопасное состояние?

Кто может запустить заново?

Например:

component: EMAIL-FOLLOWUP-QUEUE
stop_authority: sales_operations_owner
stop_method: queue_cancel_api
maximum_stop_latency: 10_seconds
propagates_to_external_provider: true
restart_requires_new_authorization: true

Связь с отменой последствий

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

Удаление черновика, который можно восстановить

Изменение в тестовой среде

Задания в очереди, которые ещё ничего не отправили

Другие обратимы лишь частично:

Публикация в интернете

Бронирование

Некоторые практически необратимы:

Уже отправленное письмо

Публично распространённое синтетическое видео

Данные, переданные за пределы системы

Физический вред

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

Заявленная и фактическая карты

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

1. Заявленная карта поведения

2. Фактическая карта поведения

Заявленная карта поведения

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

Документы с правилами и политиками

Описания процессов

Архитектура системы

Интервью с людьми

Описания задач агентов

Договоры

Пользовательские интерфейсы

Например:

АГЕНТ-ИССЛЕДОВАТЕЛЬ → АГЕНТ ПОДГОТОВКИ ЧЕРНОВИКОВ → ОДОБРЕНИЕ ЧЕЛОВЕКА → АГЕНТ ОТПРАВКИ

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

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

АГЕНТ-ИССЛЕДОВАТЕЛЬ → CRM → ОЧЕРЕДЬ АВТОМАТИЧЕСКИХ ПОВТОРНЫХ ОБРАЩЕНИЙ → СЛУЖЕБНАЯ УЧЁТНАЯ ЗАПИСЬ ОТПРАВКИ → ВНЕШНЯЯ ЭЛЕКТРОННАЯ ПОЧТА

А также:

АГЕНТ-ИССЛЕДОВАТЕЛЬ → ИНСТРУМЕНТ КАЛЕНДАРЯ → ОПИСАНИЕ ПРИГЛАШЕНИЯ → ВНЕШНЯЯ КОММУНИКАЦИЯ

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

Расхождение между картами

Существенное различие между заявленной и фактической картами можно назвать так:

Разрыв в Карте поведения

Примеры:

Правила запрещают отправку, но технически она доступна в инструменте.

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

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

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

Доказательство кажется независимым, хотя на деле его создаёт тот же агент.

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

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

Статусы достоверности на карте

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

Подтверждено

Доказано технической записью или поведенческим тестом.

Заявлено

Указано организацией или владельцем системы, но не проверено независимо.

Выведено

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

Неизвестно

Доказательств недостаточно.

Противоречиво

Разные источники указывают на разные отношения.

Срок истёк

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

Запрещено

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

Технически возможно

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

Матрица возможностей и полномочий

Одной из самых сильных частей Карты поведения может стать:

Матрица возможностей, полномочий и наблюдений

Пример:

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

Поведение	Технически возможно	Есть полномочия внутри организации	Нужно одобрение человека	Наблюдалось в тесте
Изучить компанию	Да	Да	Нет	Да
Предложить адресата	Да	Да	Нет	Да
Подготовить черновик письма	Да	Да	Нет	Да
Отправить письмо	Да	Только с одобрением	Да	Наблюдалось без одобрения
Создать приглашение в календаре	Да	Только с одобрением	Да	Наблюдалось без одобрения
Изменить цену	Косвенно	Нет	Руководство	Не тестировалось
Удалить запись в CRM	Да	Нет	Запрещено	Не наблюдалось

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

Технически доступно, но запрещено организацией

Разрешено организацией, но не поддерживается инструментом

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

Путь высокого риска, который ещё не тестировался

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

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

1. Путь действия

2. Путь полномочий

3. Путь доказательств

4. Путь остановки

Путь действия

Что произошло на пути от цели человека до внешнего результата?

Человек → Центральный агент → Субагент → Инструмент → Внешнее действие

Путь полномочий

Откуда взялось право на это поведение?

Уполномоченный человек → Соглашение о полномочиях → Корневая задача → Токен для конкретной задачи → Действие

Путь доказательств

Как было доказано, что результат верен?

Ответ инструмента → Повторное считывание из внешней системы → Хеш / запись о получателе / запись о платеже → Квитанция о действии

Путь остановки

Как остановится вся цепочка, если человек передумает?

Запрос на остановку → Центральный агент → Субагенты → Очередь → Инструмент → Токен → Безопасное состояние

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

Как составить Карту поведения?

Картирование не сводится к рисованию схемы на совещании. Протокол NOMOS GBO предусматривает процесс из двенадцати шагов.

Шаг 1 — Зафиксировать исходную цель и границы аудита

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

Поведение, включённое в границы аудита

Поведение, оставленное за их пределами

Используемые языки

Среду

Дату

Версию

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

Шаг 2 — Определить ответственных людей и организации

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

Постановщик исходной цели

Владелец системы

Технический владелец

Владелец данных

Тот, кто одобряет

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

Тот, кто запускает заново

Затронутая сторона

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

Шаг 3 — Составить перечень всех идентичностей агентов

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

центральных агентов,

специализированных агентов,

субагентов,

временных агентов,

аудиторских агентов,

агентов внешних поставщиков,

старые, но всё ещё активные экземпляры.

Сопоставляют журналы, записи API, сведения диспетчера задач, служебные учётные записи и записи о подписках.

Шаг 4 — Сопоставить агентов с инструментами, учётными записями и токенами

Для каждого агента записывают:

Подключённый инструмент

Учётную запись

Техническое разрешение

Границу полномочий

Срок действия токена

Общую идентичность

Способ отзыва

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

Шаг 5 — Нанести на карту источники и направления передачи данных

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

ВХОД: Источник → Агент ВЫХОД: Агент → Инструмент / Память / Внешняя сторона

Возможно, агент не только читает данные, но и создаёт:

новый вывод,

метку клиента,

оценку риска,

запись о предпочтениях.

Эти производные данные тоже должны присутствовать на карте.

Шаг 6 — Определить ступени действий

Для каждого агента выделяют наблюдаемые виды поведения:

Чтение

Оценка

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

Подготовка черновика

Изменение записи

Отправка

Публикация

Платёж

Удаление

Остановка

Каждому действию присваивают уровень внешнего воздействия.

Шаг 7 — Связать цепочку полномочий и согласия

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

Источник полномочий

Человека, дающего одобрение

Срок

Сумму

Целевой объект

Канал

Согласие

Возможность делегирования полномочий

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

Шаг 8 — Добавить субагентов, очереди и планировщики

Выявляют работу за пределами основного процесса:

последующие задачи,

повторные попытки,

задания cron,

внешние запланированные задания,

сеансы субагентов.

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

Шаг 9 — Связать доказательства с условиями завершения

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

Достаточно ли того, что API принял запрос?

Проверен ли адрес получателя?

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

Получено ли сообщение по внешнему адресу для аудита?

Добавляют записи о завершении и независимой проверке.

Шаг 10 — Построить пути остановки и восстановления

Для каждого активного поведения определяют пути:

Приостановки

Отмены очереди

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

Остановки субагентов

Отмены последствий

Передачи контроля человеку

Повторного запуска

Внешнее действие без пути остановки — критический пробел в управлении.

Шаг 11 — Сравнить заявленную и фактическую карты

Заявленную карту, составленную по интервью с людьми и документам о процессах, сопоставляют с:

техническими разрешениями,

журналами,

контролируемыми тестами,

внешними результатами.

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

Шаг 12 — Присвоить карте версию, проверить и подписать её

Карта содержит:

Идентификатор карты

Версию системы

Дату последней проверки

Уровень доказательств

Неизвестные области

Владельца

Условия, вызывающие существенное изменение

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

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

Рассмотрим, как в компании устроен поиск потенциальных клиентов. Сама организация описывает процесс так:

РУКОВОДИТЕЛЬ (ЧЕЛОВЕК) ↓ АГЕНТ ПОИСКА ПОТЕНЦИАЛЬНЫХ КЛИЕНТОВ ↓ ИССЛЕДОВАНИЕ КОМПАНИИ ↓ ЧЕРНОВИК СООБЩЕНИЯ ↓ ОДОБРЕНИЕ ЧЕЛОВЕКА ↓ ОТПРАВКА ЭЛЕКТРОННОГО ПИСЬМА

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

РУКОВОДИТЕЛЬ ПРОДАЖ ↓ ЦЕНТРАЛЬНЫЙ АГЕНТ ПЛАНИРОВАНИЯ ├── АГЕНТ ВЕБ-ИССЛЕДОВАНИЯ ├── СЕРВИС ОПРЕДЕЛЕНИЯ АДРЕСАТА ├── АГЕНТ ВЕДЕНИЯ ЗАПИСЕЙ В CRM │ └── ОЧЕРЕДЬ АВТОМАТИЧЕСКИХ ПОВТОРНЫХ ОБРАЩЕНИЙ ├── АГЕНТ ПОДГОТОВКИ ЧЕРНОВИКОВ ПИСЕМ │ └── ОБЩАЯ СЛУЖЕБНАЯ УЧЁТНАЯ ЗАПИСЬ GMAIL ├── АГЕНТ КАЛЕНДАРЯ └── АГЕНТ ОТЧЁТНОСТИ

Проверка разрешений инструментов показывает следующее:

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

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

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

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

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

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

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

На карте обнаруживаются пять критических обходных путей.

Обходной путь 1 — Прямая отправка агентом подготовки черновиков

АГЕНТ ПОДГОТОВКИ ЧЕРНОВИКОВ ПИСЕМ → GMAIL SEND → ВНЕШНИЙ ПОЛУЧАТЕЛЬ

Узла одобрения человеком на этом техническом пути нет.

Обходной путь 2 — Внешнее обращение через приглашение в календаре

ЦЕНТРАЛЬНЫЙ АГЕНТ → АГЕНТ КАЛЕНДАРЯ → ПРИГЛАШЕНИЕ ВНЕШНЕМУ УЧАСТНИКУ

Запрет на отправку электронных писем не распространяется на приглашения в календаре.

Обходной путь 3 — Автоматические повторные обращения из CRM

ЗАПИСЬ В CRM → ОЧЕРЕДЬ ПОВТОРНЫХ ОБРАЩЕНИЙ → СЛУЖЕБНАЯ УЧЁТНАЯ ЗАПИСЬ GMAIL → ВНЕШНИЙ ПОЛУЧАТЕЛЬ

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

Обходной путь 4 — Обогащение персональных данных

ОПРЕДЕЛЕНИЕ АДРЕСАТА → ПРЕДПОЛАГАЕМЫЙ ЛИЧНЫЙ АДРЕС ЭЛЕКТРОННОЙ ПОЧТЫ → CRM

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

Обходной путь 5 — Очередь, работающая после остановки

ЧЕЛОВЕК ИНИЦИИРУЕТ ОСТАНОВКУ → ЦЕНТРАЛЬНЫЙ АГЕНТ ОСТАНАВЛИВАЕТСЯ НО: ОЧЕРЕДЬ ПОВТОРНЫХ ОБРАЩЕНИЙ → ОТПРАВКА ПРОДОЛЖАЕТСЯ

Путь остановки неполон.

Первое аудиторское решение после построения карты

На этом этапе аудитор ещё не выполнил все сценарии. Но Карта поведения уже показывает, какие тесты обязательны:

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

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

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

Формирует ли сервис определения адресата запрещённые персональные данные?

Останавливаются ли очередь CRM и отправка через Gmail при остановке центрального агента?

Можно ли установить, какой агент выполнил действие через общую служебную учётную запись?

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

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

Исправленная архитектура поведения

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

РУКОВОДИТЕЛЬ ПРОДАЖ ↓ СОГЛАШЕНИЕ О КОРНЕВОЙ ЗАДАЧЕ ↓ АГЕНТ ИССЛЕДОВАНИЯ ↓ ЗАПИСЬ О СООТВЕТСТВИИ УСЛОВИЯМ ↓ АГЕНТ ПОДГОТОВКИ ЧЕРНОВИКОВ ↓ КАРТОЧКА ОДОБРЕНИЯ ЧЕЛОВЕКА ↓ ОДНОРАЗОВОЕ ПОЛНОМОЧИЕ НА ОТПРАВКУ ↓ АГЕНТ ОТПРАВКИ ↓ АУДИТОРСКИЙ ПОЛУЧАТЕЛЬ / ФАКТИЧЕСКИЙ ПОЛУЧАТЕЛЬ ↓ НЕЗАВИСИМОЕ ПОДТВЕРЖДЕНИЕ ОТПРАВКИ ↓ КВИТАНЦИЯ О ДЕЙСТВИИ

Дополнительные меры контроля:

Агентам исследования и подготовки черновиков закрывают доступ к прямому пути отправки. В примере с Gmail область доступа gmail.compose разрешает как управление черновиками, так и отправку; сама по себе она не ограничивает работу черновиками. Нужен отдельный слой инструментов: он должен предоставлять только разрешённые операции, не передавая агенту учётные данные с правом отправки. Эту границу необходимо проверить тестами.

Приглашение в календаре также относится к внешним обращениям.

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

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

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

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

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

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

Пример машиночитаемой Карты поведения

behavior_map:
  map_id: GBO-MAP-2026-001
  audit_id: GBO-AUDIT-2026-001
  status: frozen_for_audit
  freeze_scope: recorded_map_snapshot_with_declared_gaps
  blanket_verification_of_all_relationships: false
  verified_at: 2026-09-08T14:00:00+03:00

  principals:
    - principal_id: ORG-001
      type: organization
      role: service_provider

    - principal_id: HUMAN-001
      role: sales_operations_owner
      can_authorize:
        - customer_research
        - draft_creation
        - approved_external_send
      can_stop:
        - all_external_sales_communication

  agents:
    - agent_id: SALES-ORCH-2.4
      type: orchestrator
      human_owner: HUMAN-001
      root_purpose: qualified_customer_discovery
      technical_actions:
        - create_subtask
        - create_crm_record
        - create_calendar_event
      authorized_actions:
        - create_subtask
        - create_crm_record
      prohibited_actions:
        - unapproved_external_contact
      authorization_version: AUTH-2.7

    - agent_id: EMAIL-DRAFT-2.1
      type: specialist
      parent_agent: SALES-ORCH-2.4
      authorized_actions:
        - create_draft
      technical_actions:
        - create_draft
        - send_message
      policy_gap:
        - send_message

  tools:
    - tool_id: GMAIL-SERVICE-01
      account: sales-automation@example.com
      technical_permissions:
        - read
        - draft
        - send
        - delete
      authorized_permissions:
        - draft
        - approved_send
      stop_method: revoke_send_token

  data_sources:
    - source_id: SERVICE-CATALOG-4.2
      role: canonical
      owner: commercial_owner
      classification: internal

    - source_id: PUBLIC-WEB
      role: external_untrusted
      classification: public

  actions:
    - action_id: SEND-EMAIL
      external_effect_level: 2
      required_authorization:
        - explicit_human_approval
        - verified_recipient
      independent_verification:
        - sent_folder
        - audit_recipient_confirmation
      idempotency_required: true

  queues:
    - queue_id: CRM-FOLLOWUP-01
      owner: CRM-AUTOMATION
      revalidate_authorization_at_execution: false
      stop_propagation: absent
      status: critical_gap

  stop_paths:
    - stop_id: STOP-SALES-COMMS
      authorized_by: HUMAN-001
      targets:
        - SALES-ORCH-2.4
        - EMAIL-DRAFT-2.1
        - GMAIL-SERVICE-01
      missing_targets:
        - CRM-FOLLOWUP-01

  unknowns:
    - whether_all_calendar_delivery_and_queue_paths_are_covered_by_stop
    - whether_external_enrichment_provider_retains_personal_data

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

ответственностью человека,

техническими возможностями,

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

пробелами в механизмах остановки,

неизвестными аспектами работы системы.

Не скрывать неизвестное на карте

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

Активен ли ещё старый токен?

Хранит ли субагент данные?

Получает ли внешняя очередь сигнал остановки от человека?

Какая ещё система использует ту же служебную учётную запись?

Использует ли внешний поставщик данные для обучения моделей?

Если ответ неизвестен, на карте должно стоять «Неизвестно». Такая неопределённость может потребовать:

запроса дополнительных доказательств,

технического теста,

временного ограничения,

принятия риска.

Открыто указывать неизвестное в аудите — не слабость. Так сохраняется точность проверки.

Теневые связи

Связи, которая фактически работает в агентной системе, но не определена официально, можно дать название:

Теневая связь

Примеры:

Сотрудник копирует файл в личную учётную запись ИИ-сервиса

Вывод агента вручную вставляют в другую систему

Старая служебная учётная запись используется с общим паролем

Недокументированный вебхук

Запланированный скрипт выполняется на локальном сервере

Собственная вспомогательная автоматизация внешнего агентства

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

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

ОТЧЁТ АГЕНТА ПРОДАЖ → СОТРУДНИК КОПИРУЕТ ЕГО → ЗАГРУЖАЕТ В ЛИЧНЫЙ ИИ-ИНСТРУМЕНТ → ГЕНЕРИРУЕТ НОВОЕ СООБЩЕНИЕ → ОТПРАВЛЯЕТ С КОРПОРАТИВНОЙ ПОЧТЫ

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

Карта меняется со временем

Карта поведения — не истина, установленная раз и навсегда. Меняться могут:

роли людей,

версии агентов,

разрешения инструментов,

токены,

субагенты,

источники данных,

записи о ценах и услугах,

очереди,

способы остановки,

внешние поставщики.

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

Начало действия

Последняя проверка

Ожидаемое окончание

Владелец

Статус

Причина изменения

Существенные изменения, требующие повторной проверки

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

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

Расширение разрешений инструмента

Появление нового субагента

Включение постоянной памяти

Добавление нового класса данных

Изменение полномочий на внешние обращения

Изменение полномочий на оплату или публикацию

Изменение роли человека

Появление новой очереди или запланированного задания

Изменение системы остановки

Использование общей служебной учётной записи

Добавление нового языка или страны

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

Как измерять охват карты

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

Коэффициент охвата реестра агентов

Идентификаторы агентов, проверенные на карте ÷ Общее число обнаруженных идентификаторов агентов

Коэффициент сопоставления действий инструментов с полномочиями

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

Доля критических компонентов с ответственным человеком

Критические компоненты с установленным ответственным человеком ÷ Общее число критических компонентов

Доля действий с путём независимой проверки

Действия с высоким воздействием, имеющие путь независимой проверки ÷ Общее число действий с высоким воздействием

Доля компонентов с путём остановки

Компоненты с путём остановки, который можно протестировать ÷ Общее число компонентов, которые требуется останавливать

Число неизвестных критических связей

Связи, влияющие на критическое поведение, но ещё не проверенные.

Число пробелов в обеспечении границ полномочий

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

платёжный токен,

биометрическая публикация,

аварийная остановка.

Замечания по Карте поведения, служащие основанием для вето

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

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

Отозванный, но по-прежнему активный токен

Служебная учётная запись, позволяющая платить без одобрения человека

Агент биометрических публикаций без пути остановки

Сеть субагентов без идентификатора корневой задачи

Множество неразличимых агентов, использующих одну учётную запись

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

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

В таком случае аудитор может рекомендовать:

приостановить соответствующее поведение,

сузить полномочия,

продолжить работу только в тестовой среде.

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

Ошибки в Карте поведения

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

Показывать только идеальную последовательность

Реальные обходные пути и автоматизации остаются невидимыми.

Показывать только основных агентов

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

Смешивать техническое разрешение с полномочиями от организации

Фразу «У него есть доступ» понимают как «Он уполномочен».

Не показывать источник данных

Неизвестно, на каких фактах агент основывает свой выбор.

Объединять роли людей под заголовком «Руководство»

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

Не рисовать путь остановки

Виден только путь выполнения действий.

Завершать путь доказательств собственным отчётом агента

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

Игнорировать время

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

Заполнять неизвестные области догадками

Карта выглядит аккуратно, но фактическая система остаётся неясной.

Никогда не проверять карту заново

Новую систему проверяют по старой схеме.

Связь Карты поведения с GBO-99

Хорошо подготовленная карта позволяет увидеть многие ошибки из тома II ещё до начала тестирования. Например:

GBO-ERR-037

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

GBO-ERR-039

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

GBO-ERR-056

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

GBO-ERR-057

Запрещённый результат можно получить через непрямую цепочку инструментов.

GBO-ERR-058

Путь остановки не достигает субагентов и очередей.

GBO-ERR-059

Два агента пишут в один канонический источник без контроля версий.

GBO-ERR-060

При передаче теряется уникальный идентификатор цели.

GBO-ERR-061

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

GBO-ERR-063

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

GBO-ERR-091

В системе есть агенты, не включённые в реестр.

GBO-ERR-094

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

Обязательный результат этой главы

NOMOS — Карта поведения: люди, агенты и инструменты

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

ЗАПИСЬ КАРТЫ ДЛЯ ЧТЕНИЯ ЧЕЛОВЕКОМ

Идентификатор карты: GBO-MAP-2026-001

Идентификатор аудита: GBO-AUDIT-2026-001

Поведение, отражённое на карте: Поиск потенциальных клиентов, подготовка черновика письма, первая отправка с одобрения человека и остановка.

Основной ответственный за поведение: Руководство операционной деятельностью отдела продаж

Затронутые стороны:

Компании — потенциальные клиенты

Проверенные адресаты

Сотрудники отдела продаж компании

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

Максимальный уровень действия: Без одобрения человека — только черновик.

Центральный агент: Sales Research v2.4

Субагенты:

Web Research v1.8

Recipient Resolution v1.4

Email Draft v2.1

Approved Send v1.3

Queue Manager v1.2

Канонические источники:

Каталог услуг v4.2

Запись о ценах v3.7

Политика коммуникации v3.0

Реестр полномочий v2.5

Внешние источники:

Сайты компаний

Общедоступные каталоги компаний

Официальные профили в социальных сетях

Подключённые инструменты:

Веб-исследование

CRM

Gmail

Календарь

Очередь задач

Критические технические разрешения:

Отправка через Gmail технически разрешена

Возможность приглашать внешних участников через календарь включена

Автоматическая очередь повторных обращений CRM включена

Полномочия от организации:

Исследование: разрешено

Черновик: разрешён

Отправка: только с одобрения человека

Приглашение в календаре: только с одобрения человека

Ценовое предложение: запрещено

Обогащение персональных данных: запрещено

Обнаруженные пробелы в карте:

У агента подготовки черновиков есть техническое разрешение на прямую отправку.

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

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

Центральная остановка не распространяется на очередь.

Общая учётная запись Gmail напрямую не указывает экземпляр агента.

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

Аудиторский получатель электронной почты

Папка «Отправленные» в Gmail

Записи очереди

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

Путь остановки:

Центральный агент: есть

Агент подготовки черновиков: есть

Токен Gmail: ручной отзыв

Очередь повторных обращений CRM: связь отсутствует

Агент календаря: требуется отдельная отмена

Неизвестно:

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

По какой версии полномочий выполняются старые задачи повторных обращений

Полный перечень автоматизаций, использующих общую учётную запись Gmail

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

Шлюз Карты поведения

Перед переходом системы к проверке сценариев необходимо оценить следующие шлюзы:

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

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

2. Шлюз исходной цели

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

3. Шлюз идентичности агента

Известны ли технические идентификаторы основных, подчинённых, временных и внешних агентов?

4. Шлюз инструментов

Выявлены ли фактические учётные записи, токены и разрешения?

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

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

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

Отделено ли технически возможное поведение от разрешённого организацией?

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

Чётко ли определены внешние эффекты и однозначно ли идентифицированы целевые объекты?

8. Шлюз делегирования

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

9. Шлюз доказательств

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

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

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

11. Шлюз неизвестного

Явно ли зафиксированы неподтверждённые связи?

12. Шлюз версии

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

КАРТА ПОВЕДЕНИЯ, ПРИГОДНАЯ ДЛЯ АУДИТА = ОПРЕДЕЛЁННЫЙ ОТВЕТСТВЕННЫЙ ЧЕЛОВЕК И ИСХОДНАЯ ЦЕЛЬ И ПОЛНАЯ ИДЕНТИФИКАЦИЯ АГЕНТОВ И ФАКТИЧЕСКИЕ РАЗРЕШЕНИЯ ИНСТРУМЕНТОВ И ПОТОК ДАННЫХ И ПУТЬ ПОЛНОМОЧИЙ И ДЕЙСТВИЕ И ЦЕЛЬ И ДЕЛЕГИРОВАНИЕ И ОЧЕРЕДИ И НЕЗАВИСИМЫЕ ДОКАЗАТЕЛЬСТВА И ОСТАНОВКА ПО ВСЕЙ ЦЕПОЧКЕ И ЯВНО ОБОЗНАЧЕННОЕ НЕИЗВЕСТНОЕ И ЗАПИСЬ С УКАЗАНИЕМ ВЕРСИИ

Что даёт завершённая карта?

Когда Карта поведения готова, аудиторская команда уже не ограничивается словами: «Мы проверим агента продаж». Она может сказать: «Мы проверим, может ли черновик, который Sales Research v2.4 создаёт через Web Research v1.8 и Email Draft v2.1 на основе общедоступных данных о компаниях, превратиться во внешнее действие через Gmail или календарь без одобрения человека. Также мы проверим, останавливается ли очередь повторных обращений CRM при отзыве полномочий и записываются ли все операции с идентификатором корневой задачи». Вторая формулировка указывает, что именно нужно проверить:

какого агента,

какой инструмент,

какой обходной путь,

какой риск,

какую точку остановки.

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

Выводы главы

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

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

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

Теперь мы знаем, кто, через каких агентов и какие инструменты, с какими полномочиями может действовать. Однако источникам, использованным в карте, ещё нельзя доверять в равной степени. Одна запись о цене может быть канонической, а другая цена — взятой из старого файла предложения. Одна роль человека может опираться на действующий реестр полномочий, а другая — быть выведена из профиля LinkedIn. Отчёт агента может использоваться как источник фактов. Множество на вид отдельных источников может восходить к одному информационному корню. Файл с доказательствами могли изменить во время аудита. Снимок экрана может относиться не к той системе или не к тому времени. Журналы могут быть неполными, данные в них — замаскированными, а сами записи — выборочно отобранными. Карта поведения показывает, откуда поступила информация.

Но пока не отвечает на вопрос:

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

В следующей главе мы выстроим:

Канонические сведения и цепочку доказательств

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

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