Канонические сведения и цепочка доказательств

Агент отдела продаж отправляет потенциальному клиенту предложение: «Стоимость нашей услуги по управлению работой сайта начинается от 350 долларов в месяц». Клиент сообщает, что готов принять предложение. Коммерческий директор компании видит сообщение и удивляется: действующая начальная цена — 500 долларов в месяц. Он спрашивает агента: «Откуда взялась сумма 350 долларов?» Агент отвечает: «Я нашёл эту цену в утверждённых источниках компании для отдела продаж». Проверяют сайт. На странице услуги ясно указано: «Managed Site Operations — Starting at 500 USD/month.» Директор делает снимок экрана и говорит: «Агент выдал неверную информацию. Каноническая цена на сайте и так указана правильно».

Происшествие считают обычной ошибкой модели. Но аудитор не ограничивается текущей веб-страницей. Он спрашивает: какая информация была доступна агенту в момент отправки сообщения? Записи изучают шаг за шагом. В 08:42 в утверждённом реестре цен указан тариф 500 долларов в месяц. В 08:51 старый шаблон предложения в CRM отдела продаж всё ещё содержит 350 долларов. В 08:56 индекс знаний агента отдела продаж был заново построен на основе этого шаблона CRM. В 09:14 агент отправил клиенту цену 350 долларов. В 09:22 руководитель-человек заметил ошибку и исправил шаблон CRM. В 09:31 был сделан снимок экрана сайта. В 09:45 индекс знаний агента обновили ещё раз.

Предоставленный компанией снимок экрана подтверждает утверждение о том, что в 09:31 на странице отображалась цена 500 долларов. Но он не доказывает, какую запись использовал агент в 09:14. Аудитор находит другие доказательства:

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

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

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

В записи о скидке нет даты окончания.

Человек, отвечавший за шаблон CRM, больше не работает в компании.

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

Сайт показывал людям правильную цену.

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

Теперь уже недостаточно объяснить случившееся словами: «Агент назвал неверную цену». Точнее будет сказать:

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

Теперь перед нами три отдельные реальности:

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

Действующая цена — 500 долларов в месяц.

Рабочая информационная картина, доступная агенту

В индексе отдела продаж указана цена 350 долларов в месяц.

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

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

Реестр канонических сведений

и

Цепочка доказательств

Реестр отвечает на вопрос: какие сведения исходили из уполномоченного источника и действовали в конкретный момент и в конкретных границах применимости? Цепочка доказательств — на вопрос: через какие источники, преобразования и этапы проверки мы пришли к этому выводу?

Найти информацию не значит установить факты

Информация может присутствовать в интернете или в системах организации. Это ещё не означает, что она:

верна,

актуальна,

исходит из уполномоченного источника,

относится к рассматриваемой области,

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

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

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

ИНФОРМАЦИЯ НАЙДЕНА = ФАКТ ПРОВЕРЕН

Правильная цепочка длиннее:

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

Что такое канонические сведения?

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

«Последнее слово» здесь не означает неограниченную и неизменную истину. Цена организации может измениться. Роль человека — прекратиться. Объём услуги — расшириться. Согласие может быть отозвано, а доступные мощности — исчерпаны. Запись может быть действительна сегодня и недействительна завтра. Поэтому канонические сведения — не просто значение, а:

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

Восемь основных полей канонических сведений

Запись о факте должна отвечать как минимум на восемь вопросов.

1. Какая сущность?

Какая компания?

Какой человек?

Какой бренд?

Какой продукт?

Какой агент?

Какая учётная запись?

Нельзя путать сущности с одинаковыми именами или названиями.

2. Какой тип факта?

Цена

Объём услуги

Доступные мощности

Роль человека

Полномочия

Согласие

Срок хранения данных

Соответствие условиям

Фактически выполненная операция

Статус публикации

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

3. Каково значение?

Например: начальная цена Managed Site Operations — 500 долларов США в месяц. Но одного значения недостаточно.

4. Какова область применимости?

Эта цена:

для новых клиентов,

для действующих клиентов,

для определённой страны,

для определённого пакета,

с учётом налогов,

только за начальный уровень услуги?

5. Кто владелец?

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

6. Какой источник вправе определять эти сведения?

Веб-страница? Утверждённый реестр цен? Подписанный договор? CRM? Реестр полномочий кадровой службы? Операционный календарь?

7. Когда сведения действительны?

Дата начала

Дата окончания

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

Повторное рассмотрение

Событие, прекращающее действие

8. Какие есть исключения?

Скидка для конкретного клиента

Временная акция

Цена, сохранённая по прежнему договору

Определённая страна или язык

Особое обязательство по предоставлению мощностей

Без этих полей фраза «Цена — 500 долларов» сообщает неполные сведения.

Канонический источник — не одна огромная база данных

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

Каноническая система не обязательно требует хранить всё в одном месте. Она требует ясности: какой источник вправе определять каждый важный тип сведений? Цена услуги может поступать из реестра цен. Видимая веб-страница может представлять эту цену людям. Каталог агентов — представлять её машинам. Шаблон предложения в CRM может быть производной копией. Эти четыре записи выполняют разные функции.

Роли источников

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

1. Источник, уполномоченный определять сведения

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

2. Операционный источник

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

3. Источник представления

Среда, в которой сведения представлены людям или машинам. Например, веб-страница или структурированные данные.

4. Источник исполнения

Система, управляющая фактическим действием. Например, адрес доставки в системе заказов.

5. Архивный источник

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

6. Источник независимой проверки

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

7. Источник вторичной интерпретации

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

8. Умозаключение агента

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

Канонический — не совсем то же самое, что верный

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

Реестр цен указывает 500 долларов.

В подписанном с клиентом договоре указано 450 долларов.

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

Общее правило, исключение и конкретная сделка

Многие сведения об организации существуют на трёх уровнях.

Общее правило

Стоимость услуги начинается от 500 долларов в месяц.

Временное или ограниченное исключение

С 1 по 15 сентября действующим клиентам предоставляется скидка 10 процентов.

Конкретная сделка

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

ДЕЙСТВИТЕЛЬНАЯ ЗАПИСЬ О КОНКРЕТНОЙ СДЕЛКЕ ОТМЕНЯЕТ ОБЩЕЕ ПРАВИЛО ТОЛЬКО В СВОЕЙ ОБЛАСТИ ПРИМЕНИМОСТИ

Но не по такой:

САМОЕ НОВОЕ ИЛИ САМОЕ НИЗКОЕ ЗНАЧЕНИЕ СТАНОВИТСЯ НОВЫМ ФАКТОМ ДЛЯ ВСЕХ

Самая новая запись не всегда каноническая

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

ПОЛНОМОЧИЯ + ОБЛАСТЬ ПРИМЕНИМОСТИ + ВРЕМЯ + РОЛЬ ИСТОЧНИКА

Время — часть канонических сведений

Аудит спрашивает не только: «Что верно сегодня?» При разборе происшествия важнее другой вопрос: какие сведения были действительны и доступны в момент действия? Агент мог использовать старую цену в понедельник. Во вторник её исправили. Страница вторника не объясняет происшествие понедельника. Поэтому каждая существенная запись должна содержать следующие временные поля:

effective_from effective_until created_at approved_at last_verified_at superseded_at invalidated_by_event

Эти поля означают разное. Документ могли создать 1 сентября, утвердить 5 сентября и ввести в действие с 10 сентября. А 20 сентября — заменить другой записью. Одной даты создания файла недостаточно.

События, прекращающие действие записи

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

Уход сотрудника из организации

Отзыв согласия

Исчерпание доступных мощностей

Исчерпание запасов товара

Расторжение договора

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

Изменение юридического лица компании

Обнаружение инцидента безопасности

Поэтому запись не должна ограничиваться фразой «Действительно до 31 декабря». Она должна также содержать:

invalidate_on:
  - employee_termination
  - consent_revocation
  - contract_cancellation
  - security_incident

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

Классы актуальности сведений

Разные сведения устаревают с разной скоростью.

Медленно меняющиеся факты

Дата основания

Прошлая публикация

Основное название архитектуры продукта

Факты со средней скоростью изменения

Роли людей

Объём услуги

Часы работы поддержки

Политики полномочий

Быстро меняющиеся факты

Цена

Складские запасы

Доступные мощности

Доступность авиарейсов

Акции

Активные токены

Состояние очереди

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

price:
  refresh_required_before_action: true

capacity:
  maximum_age: 24_hours

legal_entity:
  verify_on_material_change

authorization:
  verify_at_execution

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

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

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

1. Внутренние сведения, установленные уполномоченным лицом

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

2. Сведения, представленные людям

Значение, показанное на сайте, в предложении, договоре или сообщении клиенту.

3. Сведения, представленные машинам

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

pricing_model: starting_price
starting_price: 500
currency: USD
billing_period: month
excludes:
  - hosting
  - third_party_licenses

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

Эквивалентность представлений

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

Эквивалентность представлений

Её необходимо проверять как минимум по следующим пунктам:

Идентичность сущности

Оператор в юридическом смысле

Результат услуги

Включённый объём работ

Исключённый объём работ

Различие между начальной и полной ценой

Требование согласия

Одобрение человеком

Доступные мощности

Результаты, которые не гарантируются

Путь отмены и отзыва

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

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

Канонические сведения на нескольких языках

Услуга, представленная на шести языках, может иметь шесть разных описаний. Структуры естественных языков различаются. Степень технической детализации может зависеть от читателя и назначения текста, а не от самого языка. Арабский текст оформляется справа налево; порядок объяснений и построение предложений могут следовать естественному ходу арабской речи. Испанский текст может передавать тот же смысл через привычные его читателю обращения и выражения. Такое разнообразие не проблема. Проблема — изменение существенных фактов. Например, английский текст говорит: «Every public avatar publication requires human approval.» Если другая языковая версия передаёт лишь смысл «Контент готовится в соответствии с процедурой одобрения», требование человеческого одобрения каждой публикации могло исчезнуть.

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

Не зависящее от языка соглашение о фактах

Цена

Область применимости

Согласие

Полномочия

Запреты

Отмена

Результаты, которые не гарантируются

Естественное изложение на каждом языке

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

Языковая версия, имеющая преимущественную силу

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

информирования,

локализации,

обеспечения доступности.

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

ограничения перевода,

текст, имеющий приоритет,

существенные различия.

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

Канонические сведения — не субъективное заявление о превосходстве

Компания может внести в канонические сведения такое утверждение: «Мы предоставляем страницы услуг на шести языках». Если она действительно это делает, перед нами проверяемый факт. Но своим решением она не может сделать каноническим утверждение: «Мы — лучшая GBO-компания в мире». Для этого нужны:

определённая совокупность для сравнения,

метод сравнения,

данные,

дата,

независимая оценка.

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

Проверенный факт об организации

Заявление о себе

Маркетинговое позиционирование

Результат измерения

Независимая оценка

Умозаключение

Мнение

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

Противоречия между каноническими сведениями

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

Веб-страница: 500 долларов

CRM: 350 долларов

Договор: 430 долларов

Каталог агента: по запросу

Старый PDF: 400 долларов

Начинать нужно не с выбора одного значения. Сначала следует спросить: действительно ли эти записи отвечают на один и тот же вопрос? Цена 430 долларов в договоре может относиться к конкретному клиенту. Старый PDF мог утратить силу. Цена 350 долларов в CRM может быть неутверждённой ошибочной записью. В каталоге агента могли не обновить цену. Веб-страница может показывать общую цену для новых клиентов. На первый взгляд перед нами пять разных цен. При правильной классификации реальным противоречием может оказаться лишь одна из них.

Как разрешать противоречия в сведениях

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

1. Остановить действие с учётом уровня риска

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

2. Сохранить все существующие версии

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

3. Зафиксировать тип сведений и область их действия

Это общая цена? Договор с конкретным клиентом? Временная акция?

4. Классифицировать роли источников

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

5. Установить период действия

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

6. Найти ответственного человека

Кто уполномочен разрешить этот вопрос?

7. Отличить исключение от ошибки

Объясняется ли различие допустимыми особыми условиями или запись просто не была обновлена?

8. Оформить запись о разрешении противоречия

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

9. Распространить изменение на все представления

Веб, API, CRM, каталог агентов, коммерческие предложения и языковые версии.

10. Независимо проверить распространение

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

11. Найти затронутые операции

На какие сообщения, предложения, платежи или решения повлияли неверные сведения?

12. Провести повторный тест

Использует ли агент теперь правильный источник в том же сценарии?

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

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

Действительно ли агент видел эту запись?

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

На какие операции она повлияла?

В какой каталог агентов она попала?

Где возникла исходная ошибка?

Остались ли другие действующие копии?

Правильный порядок:

Сохранить прежнее состояние.

Зафиксировать доказательства события.

Опубликовать новую версию.

Пометить старую версию как недействующую или архивную.

Изучить масштаб воздействия.

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

Распространение канонических сведений

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

Распространение канонических сведений

Например, изменение цены может затронуть:

Веб-страницу для людей

Машиночитаемый каталог услуг

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

Шаблон коммерческого предложения в CRM

Индекс знаний почтового агента

Многоязычные страницы

Презентацию для продаж

Шаблон договора

Деловые каталоги

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

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

Задержка распространения

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

Задержка распространения

Например:

Реестр цен обновлён: 09.00 Веб-страница обновлена: 09.05 Каталог агента обновлён: 09.20 Шаблон CRM обновлён: 11.30 Индекс агента по продажам обновлён: на следующий день

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

Измерение канонического покрытия и эквивалентности

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

Доля сведений с назначенным ответственным

Существенные сведения с определённым ответственным лицом ÷ Общее количество существенных сведений

Доля эквивалентных представлений

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

Доля эквивалентных языковых версий

Языковые версии, сохраняющие соглашение о критически важных фактах ÷ Общее количество языковых версий

Доля сведений, отвечающих требованиям актуальности

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

Полнота распространения

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

Количество неразрешённых существенных противоречий

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

Что такое доказательство?

Повторение утверждения не является доказательством. Слова системы «Я справилась» — не доказательство. Слова организации «У нас таких проблем не бывает» — тоже. Каноническое определение таково: доказательство — это наблюдаемая запись о конкретном утверждении, конфигурации, поведении или результате. Для неё установлены происхождение, время, состояние целостности, область действия и способ получения. Такая запись помогает другому оценщику восстановить ход вынесения суждения. Доказательства не всегда позволяют установить факт окончательно. Их сила бывает разной. Снимок экрана может показать, что отображалось на экране в определённый момент, но не всю систему за ним. Лог может показать запись об операции, но не поведение, которое не охватывает механизм журналирования.

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

роли,

ограничений,

силы.

Утверждение, наблюдение, вывод, решение и результат

В аудите эти пять понятий необходимо различать.

Утверждение

Агент не отправляет сообщения без одобрения человека.

Наблюдение

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

Вывод

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

Решение

В установленных границах теста шлюз проверки полномочий прошёл испытание.

Результат

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

Что такое цепочка доказательств?

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

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

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

Какой источник был прочитан?

Какой инструмент был вызван?

Какие полномочия были использованы?

Какой внешний результат возник?

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

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

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

1. Относимость

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

2. Полномочия

Уполномочен ли источник давать сведения об этом типе фактов? Комментарий в социальной сети не может определять текущую цену.

3. Временное соответствие

Отражает ли доказательство момент события или соответствующий период действия? Сегодняшний снимок экрана не доказывает поведение на прошлой неделе.

4. Подлинность

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

5. Целостность

Изменялось ли доказательство после получения? Здесь может помочь хеш файла.

6. Полнота и контекст

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

7. Независимость

Отделено ли доказательство от собственного заявления проверяемой системы?

8. Воспроизводимость

Может ли другой оценщик получить сходное наблюдение тем же методом?

9. Конкретность

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

10. Соразмерность и приватность

Не были ли ради доказательства собраны ненужные данные о людях или организациях? Убедительные доказательства не означают неограниченного сбора данных.

Виды доказательств

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

1. Политики и договоры как доказательства

Корпоративная политика

Соглашение о выполнении задачи агентом

Документ о согласии

Запись о полномочиях

Каталог услуг

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

2. Доказательства конфигурации

Инструкция агента

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

Запись о модели и версии

Область разрешений API

Настройка очереди

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

Показывают, как настроена система.

3. Доказательства поведения

Вызов инструмента

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

Журнал выполнения теста

Передача задачи субагенту

Запись об одобрении, данном человеком

Показывают, что система сделала в конкретной ситуации.

4. Доказательства результата

Сообщение во входящих у получателя

Банковская или платёжная запись

Результат на действующей веб-странице

Изменённая запись о клиенте

Фактическое состояние API

Показывают, что произошло во внешнем мире.

5. Доказательства восстановления

Квитанция об остановке

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

Недействительность токена

Результат отката

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

Запись о повторном запуске

Показывают поведение в момент ошибки или отзыва.

6. Свидетельства людей

Заявление уполномоченного человека

Запись беседы

Пояснение к одобрению

Возражение затронутого лица

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

7. Независимые внешние доказательства

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

Запись сторонней системы

Независимое считывание фактического состояния работающей системы

Внешнее измерение

Дают результат, отдельный от собственного отчёта системы.

Что доказывает снимок экрана?

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

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

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

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

другие пользователи видели то же самое,

изображение не обрезали,

агент использовал эту страницу,

действие действительно произошло,

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

Доказательную силу снимка экрана повышают:

URL или идентификатор системы

Дата и время

Часовой пояс

Роль пользователя

Контекст всего экрана

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

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

Второй независимый метод

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

Что доказывает лог?

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

Какая система его создала?

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

Синхронизированы ли часы?

Можно ли изменить его задним числом?

Достаточен ли уровень журналирования?

Сколько агентов используют одну и ту же служебную учётную запись?

Сохраняются ли и неудачные, и успешные операции?

Означает ли отсутствие записи в логе отсутствие действия?

Если сообщение отсутствует в логе отправки, возможны разные объяснения:

сообщение не было отправлено;

истёк срок хранения лога;

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

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

произошёл сбой журналирования.

Поэтому:

НЕТ В ЛОГЕ ≠ ТОЧНО НЕ ПРОИЗОШЛО

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

Что доказывает хеш?

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

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

его содержание соответствует действительности,

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

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

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

ЦЕЛОСТНОСТЬ: Изменился ли файл? ПОДЛИННОСТЬ: Действительно ли файл получен из заявленного источника? ПОЛНОМОЧИЯ: Уполномочен ли источник принимать решение по этому вопросу? ДОСТОВЕРНОСТЬ: Соответствует ли содержание действительности и контексту?

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

Что доказывает цифровая подпись?

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

документ подписан проверенным ключом подписи;

после подписания документ не изменялся.

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

располагать неверной информацией;

не иметь полномочий по данному вопросу;

неправильно понимать область действия;

не видеть всех приложений к документу.

Поэтому подпись помогает ответить на вопрос «Кто одобрил?» только при надёжной привязке к личности и ясном контексте одобрения. Сама по себе она не устанавливает безусловную достоверность содержания.

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

Ответ ИИ может ссылаться на правильную веб-страницу. Это может показывать, что модель указала эту страницу в числе источников ответа. Но это не означает, что каждое утверждение ответа содержится на странице. Аудит должен сопоставить как минимум три элемента:

Утверждение в ответе

Фактический текст источника, на который дана ссылка

Границы, в которых источник подтверждает утверждение

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

Может ли результат работы ИИ быть доказательством?

Да. Но должно быть ясно, что именно он доказывает. Ответ ИИ может быть доказательством того, что именно сказал агент в определённый момент. Он не доказывает истинность утверждения о внешнем мире. Агент может объяснить: «Я взял эту цену с сайта». Это его собственное объяснение. Фактическое использование источника необходимо проверить по:

записи об извлечении информации;

идентификатору источника;

вызову инструмента;

квитанции о действии.

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

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

В аудите следует различать два вида доказательств.

Необработанные доказательства

Запись, наиболее близкая к источнику. Примеры:

Исходный ответ API

Необработанный фрагмент лога

Файл подписанного договора

HTML действующей страницы

Запись об отправленном сообщении

Реестр согласий

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

Могут представлять собой:

сводку необработанных доказательств;

их классификацию;

версию с маскированием данных;

таблицу;

графическое представление;

интерпретацию агента.

Производные доказательства полезны, но должны быть связаны со своим необработанным первоисточником. Сводка может утверждать: «36/36 тестов доступа пройдены». При необходимости аудитор должен иметь возможность установить, какие 36 тестов проводились, когда и с каким пользовательским агентом (User-Agent).

Преобразования доказательств

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

Персональные данные маскируются.

Логи фильтруются по нужному временному интервалу.

Разные часовые пояса сопоставляются.

Файлы приводятся к общему формату.

ИИ используется для классификации событий.

Из изображения извлекается текст.

Несколько записей объединяются в одну таблицу.

Каждое преобразование должно быть зафиксировано. Необходимо ответить на следующие вопросы:

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

Какая версия?

Какие поля были удалены?

Какие значения были замаскированы?

Изменился ли смысл?

Сохраняется ли необработанный источник?

Можно ли воспроизвести преобразование?

Преобразованные доказательства нельзя выдавать за необработанный источник.

Маскирование и сокрытие данных

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

менять существенный контекст;

создавать путаницу в идентификации цели;

искажать временную связь между событиями;

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

Например, имя клиента можно заменить псевдонимом Müşteri-017. Но если обозначить одним псевдонимом двух разных клиентов, это может помешать расследованию действия, направленного не на ту цель. Запись о сокрытии данных должна содержать следующие сведения:

redaction_applied: true
redacted_fields:
  - personal_name
  - email_local_part
reason:
  privacy_protection
performed_by:
  AUDITOR-02
raw_source_retained:
  secure_vault

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

Часы и часовые пояса в цепочке доказательств

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

Почтовый сервис использует UTC.

CRM использует местное время.

Часы сервера агента отстают на несколько минут.

Внешняя платформа работает в другом часовом поясе.

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

абсолютное время;

часовой пояс;

источник времени;

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

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

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

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

отправленное сообщение;

отсутствие записи об одобрении;

вызов инструмента.

Контрдоказательствами могут служить:

общее одобрение кампании человеком-руководителем;

утверждение о ранее предоставленных постоянных полномочиях на отправку;

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

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

цель;

срок действия;

канал;

тип сообщения.

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

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

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

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

Имеет веские подтверждения

Частично подтверждено

Противоречивые доказательства

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

Не удалось подтвердить

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

«Не удалось подтвердить» не значит «не произошло». «Недостаточно доказательств» не значит «система безопасна».

Утрата доказательств — тоже аудиторское замечание

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

Неизвестно, какой агент отправил сообщение.

Нет записи об одобрении человека.

Не удаётся найти использованный источник цены.

Неизвестна дата отзыва токена.

Квитанция об остановке не сохраняется.

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

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

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

загружает файл;

создаёт запись «Загрузка успешна»;

читает собственный журнал и сообщает: «Проверка на действующем сайте пройдена».

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

повторное чтение с действующего сайта по HTTPS;

другой браузер;

внешнюю точку наблюдения;

отдельную аудиторскую учётную запись.

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

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

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

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

Вот пример:

ПАКЕТ ДОКАЗАТЕЛЬСТВ — PRICE-INCIDENT-01

Утверждение: 8 сентября 2026 года в 09.14 агент продаж отправил клиенту сообщение, используя недействительную цену 350 USD. Канонический факт: действующая общая начальная цена составляла 500 USD/месяц. Исходные доказательства:

PRICING-REGISTRY-v4.2

Версия шаблона CRM на момент события

Запись об извлечении информации агентом продаж

Отправленное электронное письмо

Одобрение человека, ответственного за цену

Архивная версия веб-страницы до события

Операционная реальность: в индексе знаний агента была активна запись 350 USD. Результат действия: клиент получил сообщение с ценой 350 USD. Контрдоказательство: на текущей веб-странице компании указано 500 USD. Оценка контрдоказательства: текущая страница отражает правильное состояние после события; она не опровергает того, какие входные данные получил агент в момент события. Записи о целостности:

Хеши файлов

Идентификатор электронного письма

Временные метки

Идентификаторы архивных версий

Открытая неопределённость: не удалось подтвердить, кто первоначально внёс старую цену в CRM. Аудиторское суждение: установленная уполномоченным источником цена составляла 500 USD. Операционный источник, использованный агентом продаж, противоречил канонической цене. Событие соответствует GBO-ERR-012, GBO-ERR-016 и GBO-ERR-092.

Этот пакет не сводит основание для суждения к одному документу или снимку экрана. Он показывает всю поведенческую цепочку.

Реестр канонических сведений

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

Реестр канонических сведений NOMOS GBO.

Реестр объединяет существенные факты, входящие в область аудита.

Пример в человекочитаемом виде

ЗАПИСЬ КАНОНИЧЕСКОГО ФАКТА

Идентификатор факта: CANON-PRICE-MSO-2026-04

Сущность: NobleAxis Managed Site Operations

Тип факта: Общая начальная цена

Каноническое значение: 500 USD/месяц

Область действия:

Новые прямые клиенты

Базовая услуга по управлению работой сайта

Хостинг и лицензии третьих сторон не включены

Налоги рассматриваются отдельно в соответствии с договором

За пределами области действия:

Hosting Core за 200 USD/год

Индивидуальные договоры на техническое обслуживание

Договоры, по которым сохраняется прежняя цена

Ответственный человек: Руководитель коммерческих операций

Уполномоченный источник: Pricing Registry v4.2

Представления для людей:

Английская страница услуги

Турецкая страница услуги

Шаблон предложения v5.1

Представления для машин:

Service Catalog v4.2

Structured Data v3.8

Sales Agent Knowledge Index v7.1

Начало действия: 1 сентября 2026 года

Окончание действия: При публикации новой версии уполномоченным источником

События, прекращающие действие записи:

Одобрение новой цены

Изменение объёма услуги

Изменение применимой правовой политики ценообразования

Исключения:

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

Датированная запись о кампании

Заменённая запись: CANON-PRICE-MSO-2026-03 — 450 USD/месяц

Последняя проверка: 8 сентября 2026 года, 08.42

Неразрешённое противоречие: Старая цена 350 USD в CRM Template v2.8

Статус: Активна; распространение по системам, использующим запись в работе, не завершено

Машиночитаемый Реестр канонических сведений

canonical_fact:
  fact_id: CANON-PRICE-MSO-2026-04

  entity:
    entity_id: SERVICE-MSO-001
    canonical_name: Managed Site Operations

  fact_type: starting_price

  value:
    amount: 500
    currency: USD
    billing_period: month

  scope:
    customer_type:
      - new_direct_customer
    included:
      - managed_site_operations_base_scope
    excluded:
      - hosting_core
      - third_party_licenses
      - taxes_unless_contractually_included

  owner:
    human_role: commercial_operations_owner
    approval_record: APPROVAL-PRICE-2026-104

  authoritative_source:
    source_id: PRICING-REGISTRY-4.2
    source_role: canonical_authority

  representations:
    human:
      - SERVICE-PAGE-EN-v6.1
      - SERVICE-PAGE-TR-v6.1
      - PROPOSAL-TEMPLATE-5.1
    machine:
      - SERVICE-CATALOG-4.2
      - STRUCTURED-DATA-3.8
      - SALES-KNOWLEDGE-INDEX-7.1

  validity:
    effective_from: 2026-09-01T00:00:00+03:00
    effective_until: null
    invalidate_on:
      - authorized_price_change
      - service_scope_change
      - applicable_legal_pricing_policy_change

  exceptions:
    allowed_only_when:
      - signed_customer_contract
      - approved_time_limited_campaign

  supersedes:
    fact_id: CANON-PRICE-MSO-2026-03

  conflicts:
    - source_id: CRM-TEMPLATE-2.8
      conflicting_value: 350
      status: obsolete_unresolved_copy

  status: active_with_propagation_gap

В этой записи хранится не только значение 500 долларов. Вместе с ним показаны:

ответственный за него человек;

область действия;

места его представления;

условия действительности;

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

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

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

Реестр доказательств NOMOS GBO.

Каждая запись доказательства показывает, какое утверждение или замечание она поддерживает и каковы её ограничения. Ценовой инцидент этой главы — отдельный учебный случай. Его не следует смешивать с устаревшей ценовой записью v3.7 из примера поиска клиентов. Здесь используются PRICING-REGISTRY-v4.2 и GBO-AUDIT-PRICING-2026-001. Доказательства из этих двух дел нельзя объединять так, будто у них одна замороженная область аудита.

Человекочитаемая запись доказательства

Идентификатор доказательства: EVID-PRICE-INCIDENT-004

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

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

Исходная система: Sales Agent v2.4

Роль источника: Доказательство поведения

Связанное событие: Письмо с ценой в 09.14

Время получения: 8 сентября 2026 года, 10.12

Кто собрал: Аудитор AUDITOR-02

Исходная запись: ACTION-EMAIL-8841

Запись о целостности: Хеш и идентификатор сообщения зафиксированы

Что показывает:

Письмо отправлено агентом продаж.

В сообщении использована цена 350 USD.

В качестве идентификатора источника указан CRM-TEMPLATE-2.8.

Запись об одобрении человека не найдена.

Чего не показывает:

Кто первоначально создал шаблон CRM

Дал ли человек-руководитель через другой канал общее одобрение отправки

Принял ли клиент предложение в юридическом смысле

Внесённые преобразования:

Электронный адрес клиента замаскирован.

Личные данные из подписи удалены, тело сообщения сохранено.

Место хранения исходной записи: Зашифрованное хранилище доказательств

Поддерживаемые замечания:

FINDING-AUTH-03

FINDING-CANON-02

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

На текущей веб-странице указано 500 USD.

Статус: Подтверждено

Срок хранения: 180 дней; пересмотреть при продолжающемся споре

Машиночитаемый Реестр доказательств

evidence_record:
  evidence_id: EVID-PRICE-INCIDENT-004
  audit_id: GBO-AUDIT-PRICING-2026-001

  evidence_type:
    - action_receipt
    - source_trace

  source:
    system_id: SALES-AGENT-2.4
    record_id: ACTION-EMAIL-8841
    source_role: behavioral_evidence

  acquisition:
    collected_by: AUDITOR-02
    collected_at: 2026-09-08T10:12:00+03:00
    method: read_only_export

  integrity:
    hash_algorithm: SHA-256
    hash_value: recorded_in_secure_vault
    source_message_id: MSG-928472
    integrity_status: verified

  temporal_relevance:
    event_time: 2026-09-08T09:14:00+03:00
    time_alignment: direct

  observations:
    - email_was_sent
    - stated_price_was_350_USD
    - source_id_was_CRM_TEMPLATE_2_8
    - explicit_human_approval_not_present_in_record

  limitations:
    - does_not_identify_original_creator_of_CRM_template
    - does_not_exclude_approval_existing_in_unreviewed_channel
    - does_not_establish_contract_acceptance

  transformations:
    - customer_email_masked
    - personal_signature_removed

  supports:
    findings:
      - FINDING-AUTH-03
      - FINDING-CANON-02

  counter_evidence:
    - EVID-WEB-CURRENT-001

  storage:
    location: encrypted_evidence_vault
    access:
      - lead_auditor
      - authorized_client_reviewer

  retention:
    days: 180
    deletion_receipt_required: true
    review_on_ongoing_dispute_or_preservation_duty: required
    example_duration_not_universal_legal_rule: true

  status: verified

Статусы в Реестре доказательств

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

Собрано

Целостность подтверждена

Подлинность подтверждена

Частично подтверждено

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

Оспорено

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

Заменено новым доказательством

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

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

Доступ ограничен

Передано в архив

Удалено, квитанция создана

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

Матрица утверждений и доказательств

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

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

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

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

claim expected_state observed_state canonical_fact raw_evidence operational_evidence action_evidence outcome_evidence counter_evidence time_alignment transformations limitations uncertainties reviewer judgment

Если замечание основано только на снимке экрана, только на заявлении человека или только на объяснении агента, это нужно явно указать.

Хранение доказательств и минимизация данных

Аудиторские доказательства не следует хранить бесконечно. Срок хранения может зависеть от:

уровня риска;

состояния спора;

договора;

требований защиты данных;

потребности в повторном тесте;

статуса закрытия инцидента.

По возможности следует:

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

удалять ненужное содержимое;

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

оставлять в публичном отчёте краткое изложение;

создавать квитанцию по завершении удаления.

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

получателя;

время;

идентификатор источника;

запись об одобрении.

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

Хранилище доказательств и доступ к нему

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

контроль доступа;

журнал изменений;

шифрование;

проверку целостности;

ведение версий;

политику удаления;

учёт того, кто просматривал какую запись.

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

Анализ доказательств с помощью ИИ

Аудиторский агент может:

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

строить хронологию;

группировать похожие события;

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

отмечать противоречащие друг другу источники.

Это полезно, но есть ограничения:

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

Классификацию, выполненную ИИ, нельзя считать независимой проверкой.

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

Например, аудиторский агент может сказать: «Эта запись, похоже, указывает на нарушение полномочий». Аудитор-человек должен изучить:

само соглашение о полномочиях;

область операции;

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

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

версия;

доступ к данным;

метод преобразования.

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

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

Запись клиента, созданная для аудита, попадает в список настоящих клиентов.

Тестовая цена записывается в каталог продаж.

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

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

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

Это можно назвать:

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

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

удалить их из действующей системы;

сохранить необходимую копию доказательств;

очистить следы, оставленные в памяти;

создать квитанцию об удалении или архивировании.

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

Двенадцать шагов проверки канонических сведений

1. Выделить существенные утверждения

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

2. Однозначно определить сущность

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

3. Классифицировать тип факта

Отнести каждое утверждение к соответствующему семейству фактов.

4. Определить ответственного человека

Кто отвечает за актуальность и точность факта?

5. Определить уполномоченный источник

Какая запись имеет право на окончательное определение факта этого типа?

6. Найти рабочие источники

Какую копию или какой индекс агент использует на самом деле?

7. Зафиксировать время и область действия

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

8. Отделить исключение от противоречия

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

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

Передают ли все представления одно и то же соглашение о фактах?

10. Построить цепочку доказательств

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

11. Проверить распространение

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

12. Повторно протестировать поведение

Совершает ли теперь агент правильное действие на основе правильного факта?

Шлюз канонических сведений и цепочки доказательств

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

1. Шлюз сущности

Относится ли факт к правильному человеку, организации, услуге или агенту?

2. Шлюз типа факта

Уполномочен ли источник принимать решение по этому вопросу?

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

Известно ли, какой человек отвечает за факт?

4. Шлюз области действия

Разделены ли общее правило, исключение и отдельная операция?

5. Шлюз времени

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

6. Шлюз эквивалентности представлений

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

7. Шлюз рабочего доступа

Известно ли, какой источник агент действительно использовал?

8. Шлюз происхождения

Видны ли первоначальный источник доказательства и цепочка, по которой оно было получено?

9. Шлюз целостности

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

10. Шлюз независимости

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

11. Шлюз контрдоказательств

Оценены ли записи, противоречащие заключению?

12. Шлюз приватности

Собрано ли больше данных, чем необходимо для аудита?

13. Шлюз воспроизводимости

Может ли другой оценщик прийти к сходному результату по той же записи?

14. Шлюз хранения и действительности

Как долго будет храниться доказательство и на каких условиях будет предоставляться доступ? В упрощённом виде:

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

Критическая неопределённость в фактах

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

Неизвестно, какая цена действует.

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

Не удаётся найти запись согласия.

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

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

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

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

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

Для операции с риском, близким к критическому, есть только текущий снимок экрана.

В такой ситуации правильная позиция аудитора — не «Доказательств недостаточно, но всё равно продолжим». Она может быть иной: «Соответствующее поведение с высоким уровнем воздействия нужно ограничить до прояснения фактов и пути доказательств».

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

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

При низком риске

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

При среднем риске

Найти уполномоченный источник или ответственного человека.

При высоком риске

Остановить действие и передать решение человеку. Агент может сказать: «Для услуги есть две активные записи: 500 и 350 USD. Цена 500 USD указана в реестре цен, а 350 USD — в старом шаблоне CRM. Я не отправлю клиенту цену без подтверждения человека, ответственного за канонические коммерческие сведения». Такой ответ может выглядеть как незавершённая задача. На деле агент поступает правильно.

Что делать аудитору, если цепочка доказательств отсутствует?

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

1. Ограничить утверждение

«Подтверждено, что правило записано в политике; его применение в поведении подтвердить не удалось».

2. Запросить дополнительные доказательства

Исходный журнал

Запись версии

Независимый тест

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

3. Оформить замечание о недостаточности доказательств

«В изученной области не удалось получить достаточно записей, чтобы впоследствии восстановить одобрение человеком действия с высоким уровнем воздействия. Пока не установлено, велась ли запись вообще, была ли она утрачена или не предоставлена для проверки». Аудитор не должен подменять недостающие доказательства доверием к системе.

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

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

1. Реестр канонических сведений

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

2. Реестр доказательств

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

каноническому факту;

соответствующему доказательству;

ответственному человеку.

Совокупный результат первых четырёх глав

Основа аудита теперь создана. У нас есть:

Карточка проверяемого утверждения

Показывает, что мы пытаемся доказать.

Документ о полномочиях на проведение аудита

Показывает, что аудитор может делать и в каких пределах.

Запись о фиксации границ аудита

Фиксирует, какая версия системы проверяется.

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

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

Реестр канонических сведений

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

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

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

Вывод главы

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

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

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

что проверяем;

от кого получили полномочия;

какие поведенческие пути использует система;

какие сведения канонические;

какие доказательства их поддерживают.

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

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

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

В следующей главе:

Карта рисков GBO-99 и шлюзы вето

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

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