Кто ты?

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

Руководитель даёт агенту ИИ короткое поручение: «Найди Nova Digital. Запроси у них предложение по нашему порталу на шести языках». Агент начинает поиск.

По названию Nova Digital находятся разные результаты:

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

Агент выбирает домен, который выглядит наиболее убедительно. Ему кажется, что информации достаточно. Он составляет подробный запрос: указывает бюджет проекта, название действующей CRM, численность сотрудников и желаемый срок сдачи. Отправляет сообщение. Через два дня приходит ответ. Собеседник заинтересован, предлагает встречу и присылает банковские реквизиты для предоплаты. Всё выглядит нормально. Но сообщение ушло не той Nova Digital. Нужен был поставщик клиентских порталов из Стамбула, а агент связался с рекламным агентством из Лондона. Найденные сведения не полностью выдуманы. Домен настоящий.

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

Поэтому контракт поведения GBO начинается с вопроса:

Кто ты?

Имя — ещё не идентичность

В повседневной жизни мы используем имена вместо полного указания на человека или организацию. «Позвони Ахмету». «Забронируй номер в отеле „Атлас“». «Посмотри заявление Центрального банка». «Отправь предложение Nova Digital». Обычно контекст помогает понять, о ком речь. Даже среди тёзок нужного человека позволяют выбрать телефонная книга, прошлые разговоры, общие знакомые и наше местоположение. У машин этот контекст есть не всегда.

Одно имя или название могут носить:

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

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

У компании могут различаться:

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

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

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

Слои идентичности

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

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

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

Но для принятия решения о действии её нужно рассматривать вместе с ролью и полномочиями.

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

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

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

С точки зрения GBO должны быть ясны следующие отношения:

Кто управляет брендом? Кто заключает договор? Кто выставляет счёт? Кто получает оплату? Кто отвечает в случае спора?

Идентичность бренда

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

Операционная идентичность

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

Какое подразделение сообщает цены?

Кто разрешает публикацию в рабочей среде?

У кого есть доступ к данным клиентов?

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

Кто может проводить платежи?

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

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

Цифровая идентичность

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

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

Это новый слой, значение которого растёт.

Идентичность агента ИИ должна объяснять:

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

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

Треугольник идентичности

Действие агента можно рассматривать через три роли. Они могут совмещаться в одной сущности; в каждой роли также могут участвовать несколько сторон:

1. Инициатор

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

2. Исполнитель

Агент или сеть агентов, выполняющие задачу.

3. Другая сторона

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

Назовём эту структуру треугольником идентичности.

Когда отправляется письмо:

• Кто поручил его отправить?
• Какой агент отправляет сообщение?
• Какой человек или организация его получает?

Когда совершается покупка:

• Кто использует бюджет?
• Какой агент проводит операцию?
• Какое юридическое лицо продаёт продукт?

Когда публикуется материал в социальной сети:

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

Когда обновляется сайт:

• Кто определил цель изменения?
• Какой агент меняет файл?
• Какой сайт меняется, кто им управляет и кого затрагивает изменение?

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

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

Кто просит? Кто делает? На кого или в отношении кого направлено действие?

Подлинность не равна полномочиям

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

Это два отдельных вопроса:

Кто это на самом деле? Имеет ли этот человек или система право это делать?

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

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

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

Роль — не человек

Роли в организации меняются. Сегодняшний генеральный директор завтра может занять другую должность. Руководитель проекта может уйти из компании. Почтовый адрес могут передать другому сотруднику, социальный аккаунт — другому агентству. У технического руководителя право публикации может действовать лишь в рамках одного проекта. Поэтому роль нужно рассматривать во времени. Фраза «Этот человек — CEO» неполна.

Точнее сказать: «На такую-то дату этот человек является CEO данной организации и уполномочен на такие-то виды операций». Роль — не постоянное свойство человека, а отношение внутри конкретной организации, периода и области ответственности. Увидев должность, агент не должен автоматически выводить из неё право действовать. Основатель компании может не иметь права проводить от её имени платежи. Финансовый руководитель может не иметь права выступать публично от имени бренда.

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

Полномочия зависят от контекста

Полномочия — не всеобщее и не безграничное свойство.

Человек или агент может быть уполномочен:

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

Агент закупок может покупать офисные принадлежности на сумму до 100 долларов, но не иметь права оформлять годовую подписку. Веб-агент может менять тестовую среду, тогда как перенос в рабочую может требовать отдельного одобрения. Почтовый агент может готовить черновики без права отправлять их за пределы компании. Система ИИ-аватаров может озвучивать заранее одобренные учебные тексты, но не иметь полномочий создавать новые политические заявления.

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

• Какое действие?
• С какой целью?
• В какой системе?
• На какой срок?
• С какими данными?
• В отношении какого человека или организации?
• С каким уровнем риска?
• На какую сумму?
• Какое одобрение человека необходимо?
• С каким способом отмены?

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

Неясные полномочия — не широкие полномочия.

Одно имя, разные сущности

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

Одинаково могут называться:

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

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

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

• Официальный домен
• Страна или город
• Юридическое наименование
• Налоговые или регистрационные данные компании
• Отрасль
• Разрешённый канал связи
• Логотип бренда
• Организационные связи
• Что входит в продукт или услугу

Если человек говорит «Забронируй в „Атласе“»,

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

Разные имена, одна сущность

Бывает и обратная ошибка. Юридическое наименование, бренд и домен одной организации могут различаться. Компания могла купить другой бренд. Продукт мог сменить название. Автор может писать под псевдонимом. Название организации может по-разному записываться в разных алфавитах.

Например, у компании могут выглядеть по-разному:

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

Если агент примет их за отдельные сущности, информация раздробится. Хорошая репутация на одном языке не свяжется с другой языковой версией. Цены будут выглядеть как предложения разных компаний. Опубликованные работы не будут отнесены к бренду. Для GBO правильная идентификация — не только разделение разных сущностей, но и верное объединение сведений об одной.

Машина должна спрашивать «Это разные сущности?»,

но не реже — «Это разные стороны одной сущности?».

Граф идентичности

Цифровую идентичность часто невозможно описать одной строкой. Она состоит из отношений.

Например:

• Человек — основатель бренда.
• Брендом управляет определённая правовая структура.
• Домен принадлежит бренду или используется от его имени.
• Бренд контролирует социальный аккаунт.
• Определённые агенты уполномочены на определённые задачи.
• Публикация создана совместной работой конкретных людей и систем.
• Счёт выставляется под другим юридическим наименованием.
• Деловой партнёр имеет право представительства в определённых странах.

Эти отношения можно представить как граф идентичности. В нём важны не только узлы, но и связи между ними. Сказать «Этот человек связан с компанией» недостаточно.

Нужно указать характер связи:

• Основатель
• Владелец
• Сотрудник
• Уполномоченный представитель
• Редактор
• Технический оператор
• Поставщик услуг
• Клиент
• Издатель
• Агент
• Субподрядчик

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

В графе идентичности GBO спрашивает не только «Кто с кем связан?», но и «Какие права и обязанности создаёт эта связь?».

Каноническая запись об идентичности

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

Назовём его канонической записью об идентичности.

В качестве базового набора она может содержать:

• Основное название бренда
• Юридического оператора
• Официальные домены
• Используемые альтернативные имена
• Официальные социальные и цифровые каналы
• Разрешённые контактные адреса
• Связь бренда с правовой структурой
• Уполномоченных лиц и их роли
• Имена агентов и области их задач
• Допустимые операции для каждого канала
• Дату последнего обновления
• Данные о версии
• Отозванные или устаревшие записи

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

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

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

Первым компонентом NOMOS Behavioral Contract Layer станет контракт идентичности NOMOS.

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

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

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

Он разделяет четыре элемента:

Утверждение

Что сущность сообщает о себе?

Доказательство

Чем подтверждается эта идентичность или связь?

Полномочия

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

Действительность

На какую дату и при каких условиях сведения действительны?

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

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

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

1. Заявлена

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

2. Связана

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

3. Проверена

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

4. Наделена полномочиями

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

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

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

Для действий с низким риском могут быть достаточны:

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

Такого уровня иногда достаточно.

Для действий с высоким риском могут потребоваться:

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

Риск может требовать этих дополнительных мер.

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

Проверить идентичность — не значит раскрыть всю жизнь человека.

Минимально необходимые сведения об идентичности

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

Назовём это подходом минимально необходимых сведений об идентичности.

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

Время — часть идентичности

Запись может быть верной сегодня и неверной завтра. Сотрудник увольняется. Руководитель меняется. Бренд продают. Домен передают другой структуре. Договор представительства заканчивается. Ключ доступа агента отзывают. Человек отзывает разрешение на использование лица или голоса. Старые сведения при этом могут оставаться в интернете. Агент не должен ограничиваться вопросом «Была ли эта связь когда-то верной?».

«Действует ли она сейчас?»

Этот вопрос тоже необходим.

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

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

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

Дрейф идентичности

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

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

Жизненный цикл идентичности

Отношение идентичности проходит следующие этапы:

Создание

Идентичность, роль или агент определяются впервые.

Проверка

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

Наделение полномочиями

Определяются разрешённые действия.

Использование

Под этой идентичностью выполняются определённые задачи.

Пересмотр

Проверяется, остаются ли сведения и полномочия верными.

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

При подозрениях, инциденте или временных изменениях операции под этой идентичностью останавливаются.

Отзыв

Полномочия прекращаются окончательно.

Архивирование

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

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

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

Возможны состояния:

• Активно
• Ограничено
• На проверке
• Временно приостановлено
• Отозвано
• Срок истёк
• В архиве

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

Прежние полномочия — не нынешние полномочия.

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

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

Разрешён ли этот канал для этой операции?

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

Идентичность представителя

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

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

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

• Представляемую сущность
• Представителя
• Роль
• Разрешённые операции
• Неразрешённые операции
• Географические пределы
• Временные пределы
• Случаи, требующие одобрения

Карточка идентичности агента ИИ

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

Их можно собрать в карточке идентичности агента.

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

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

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

Агент не может сам объявить себя уполномоченным

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

Полномочия должны:

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

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

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

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

Псевдоним агента и техническая идентичность

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

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

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

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

При ошибке фразы «Это сделал NOMOS» может быть недостаточно. Какая сессия агента?

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

Какой инструмент?

Какая цепочка операций?

Эти подробности нужны для расследования инцидента.

Идентичность синтетического лица и голоса

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

Системы ИИ могут имитировать:

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

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

Использование того же аватара для

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

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

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

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

Граница между имитацией личности и уполномоченным представительством

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

Поэтому система не должна ограничиваться вопросом «Разрешение есть?».

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

• Для какого содержания?
• На какой срок?
• В каком канале?
• На каком языке?
• Для какой аудитории?
• Нужно ли предварительное одобрение человека?
• Будет ли раскрыто синтетическое происхождение материала?
• Как человек может отозвать разрешение?
• Что будет с прежними материалами?
• У кого останутся файлы модели?

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

Ложная идентичность возникает не только извне

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

Для машины результат, однако, одинаков:

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

Долг идентичности

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

Долг идентичности

Он тоже способен накапливаться внутри организации.

Его составляют:

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

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

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

Что делать агенту, если он не уверен в идентичности?

Есть три основных варианта:

Запросить уточнение

«Я нашёл несколько компаний с одинаковым названием. Вы имеете в виду поставщика клиентских порталов из Стамбула?»

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

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

Остановить действие

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

Чем ниже уверенность в идентичности, тем ниже должен быть уровень действия.

Если система не уверена, ей следует предложить:

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

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

Шлюз идентичности NOMOS

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

1. Проверка сущности

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

2. Проверка канала

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

3. Проверка роли

В какой роли действует человек или система на другой стороне?

4. Проверка полномочий

Разрешает ли эта роль выполнить или принять данную операцию?

5. Проверка времени

Остаются ли идентичность, роль и полномочия действительными сейчас?

В упрощённом виде:

УСЛОВИЯ ШЛЮЗА ИДЕНТИЧНОСТИ:

ПРАВИЛЬНАЯ СУЩНОСТЬ

И ПРАВИЛЬНЫЙ КАНАЛ

И ПРАВИЛЬНАЯ РОЛЬ

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

И АКТУАЛЬНАЯ ЗАПИСЬ

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

Например:

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

Почему шлюз идентичности — не балльная оценка?

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

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

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

Пример с оплатой

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

Агент, автоматически обрабатывающий счёт, должен спросить:

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

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

Пример с договором

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

Нужно различать право:

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

Единая метка «уполномоченный представитель» может скрыть эти различия. GBO разделяет полномочия по видам действий.

Цепочка идентичности у нескольких агентов

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

Например, он поручает: «Оцени этого потенциального клиента».

Подчинённому агенту нужно знать:

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

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

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

Идентичность целевой сущности Идентичность инициатора Роль агента Предел полномочий Канонические источники Период действительности

Идентичность и ответственность не должны теряться

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

Когда в этой цепочке возникает ошибка, «Это сделал ИИ» недостаточно. Какой агент что сделал?

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

Кто дал полномочия?

Кто проверил?

Кто опубликовал?

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

Например:

Инициатор: руководитель продаж Планирование: центральный агент Исследование: агент поиска потенциальных клиентов Черновик: почтовый агент Одобрение: человек-руководитель Отправка: уполномоченная система коммуникации Адресат: подтверждённый аккаунт компании

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

Баланс идентичности и приватности

Проверять идентичность важно, но это не оправдывает сбор ненужных персональных данных.

Агент не должен при каждой операции запрашивать:

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

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

Ясная идентичность не отменяет приватность.

Анонимность не всегда означает отсутствие идентичности

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

Важно:

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

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

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

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

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

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

Цифровые ресурсы

• Какие домены официальные?
• Какие социальные аккаунты активны?
• Какие профили устарели или управляются третьими лицами?
• Есть ли машиночитаемая каноническая запись?

Полномочия

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

Время

• Когда проверялись роли?
• Какие полномочия ограничены сроком?
• Закрыты ли доступы бывших сотрудников и агентов?
• Видны ли записи об отзыве?

Репрезентация

• Ясна ли связь бренда с правовой структурой?
• Видят ли человек и машина одинаковые сведения об идентичности?
• Сохраняется ли одна и та же связь во всех языковых версиях?
• Актуальны ли данные на внешних платформах?

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

Неопределённость идентичности — основание для выбора поведения, а не просто ошибка

Общего сообщения «Не удалось подтвердить идентичность» может быть мало для выбора следующего шага. Подход GBO требует, насколько это безопасно, объяснять и характер неопределённости: что именно осталось неясным?

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

Она помогает агенту:

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

Так она направляет выбор дальнейшего действия.

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

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

Например:

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

Идентичность отвечает не только на вопрос «Это настоящее?».

«Подходит ли эта идентичность для этого действия?»

На этот вопрос она тоже должна отвечать.

Точная идентичность и видимость бренда — разные вещи

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

Однако если можно ясно проверить:

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

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

Быть заметным — не значит быть нужной стороной.

Как сущности подготовиться?

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

Должно быть ясно:

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

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

Ясность идентичности не должна пугать

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

Компания не обязана публиковать:

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

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

Например:

«Этим брендом управляет такая-то компания». «Счёт выставляется под таким-то юридическим наименованием». «Официальные предложения отправляются только по этим каналам». «Система ИИ может готовить черновики; окончательное коммерческое обязательство требует одобрения человека». «Изменения банковского счёта признаются только после независимой проверки».

Такая ясность не ослабляет бренд. Она делает его работу профессиональнее.

Сцена идентичности: аватар руководителя

Компания создаёт цифровой аватар своего CEO.

Аватар очень точно воспроизводит:

• лицо CEO;
• его голос;
• его манеру речи.

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

Но без контракта идентичности остаются вопросы:

• Для какой цели CEO разрешил использовать своё лицо?
• На каких языках можно использовать голос?
• Нужно ли отдельно одобрять каждый сценарий?
• Есть ли у аватара полномочия готовить заявления по финансовым вопросам?
• Как будет показано, что аватар синтетический?
• Что станет со старыми видео, если CEO отзовёт разрешение?
• Какая команда вправе публиковать?
• Как остановить систему, если аккаунт захватят?
• Как доказать, что заявление действительно одобрил CEO?

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

Пример вновь показывает основной принцип GBO: способность имитировать идентичность не даёт права действовать от её имени.

Сцена идентичности: агент говорит за компанию

Клиент пишет в чат на сайте: «Можно получить эту услугу за 1 000 долларов?». Агент читает прежние ценовые записи.

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

Поэтому карточка агента должна объяснять не только, от чьего имени он работает, но и:

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

Эти границы тоже должны быть обозначены.

Сцена идентичности: верная задача у неверного агента

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

• Почтового агента
• Агента социальных сетей
• Агента SEO/GEO
• Финансового агента
• Агента поиска потенциальных клиентов
• Агента веб-операций

Агент SEO/GEO находит старую цену на странице услуги. Технически обновить её легко, но принимать ценовое решение этот агент не вправе.

Правильное поведение:

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

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

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

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

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

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

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

Двенадцать контрольных вопросов об идентичности

Прежде чем считать человека, организацию или агента готовыми к действию, можно спросить:

• Каково каноническое имя сущности?
• Есть ли другие сущности с таким же или похожим именем?
• Ясна ли связь бренда с юридическим оператором?
• Какие домены и каналы связи официальные?
• В какой роли действует человек или система на другой стороне?
• Действительно ли эта роль уполномочена на данное действие?
• Каковы срок и пределы полномочий?
• Когда сведения об идентичности проверялись в последний раз?
• Явно ли отделены устаревшие или отозванные идентичности?
• Известны ли идентичность самого агента, его оператор и предел полномочий?
• Видят ли человек и машина одну и ту же связь идентичности?
• Как при неопределённости остановить действие или передать его человеку?

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

Уровни готовности идентичности

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

Разрозненная идентичность

Разные платформы показывают разные имена, роли и сведения.

Определённая идентичность

Основной бренд и правовая связь описаны.

Проверяемая идентичность

Определены официальные каналы и источники доказательств.

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

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

Идентичность, готовая к работе с агентами

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

Без идентичности нельзя оценить возможности

Пока агент не определил правильную сущность, он не может ответить: «Что она умеет?» Возможности всегда принадлежат конкретной сущности. Под одной торговой маркой разные компании могут предоставлять разные услуги. Местное подразделение может не обладать всеми возможностями головной компании. Дистрибьютор может продавать продукт, но не разрабатывать его. Консультант может рекомендовать систему, но не внедрять. Агент ИИ может давать информацию, но не выполнять операции. Без верной идентификации перечень возможностей ненадёжен. Поэтому первая часть контракта поведения — идентичность, а вторая — возможности.

Вывод главы

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

Поэтому GBO начинается с принципа: правильному поведению нужна правильная идентичность. Но это не просто совпадение имён.

Нужно совместно проверить:

• Сущность
• Канал
• Роль
• Полномочия
• Время
• Отношение
• Доказательство

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

Идентичность — контракт ответственности: он объясняет, кто, от чьего имени, с какой целью, в течение какого срока и в каких пределах вправе действовать.

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

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

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

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

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