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

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

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

На сайте одного из поставщиков он видит:

• Надёжная инфраструктура
• Хостинг для бизнеса
• Высокая производительность
• Регулярное резервное копирование
• Безопасное размещение сайта
• 200 долларов в год

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

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

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

Разместить сайт Постоянно обеспечивать его работу

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

Поэтому второй основополагающий вопрос GBO звучит так:

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

Заявление и возможности — не одно и то же

Компания может сказать: «Мы разрабатываем решения на основе искусственного интеллекта». За этой фразой могут стоять очень разные вещи.

Компания может:

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

В широком смысле всё это можно назвать «решениями на основе ИИ». Но возможности за этими формулировками разные.

Компания может сказать: «Мы работаем на международном рынке».

Это тоже может означать что угодно из следующего:

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

Слова компании о самой себе ещё не объясняют её реальный рабочий потенциал. Маркетинговые формулировки обычно широки. Информация для действия, напротив, должна быть конкретной и точной. Человек может прочитать общее описание и задать уточняющий вопрос. Агент же способен принять его за структурированное описание возможностей. Увидев «AI automation», он может решить, что автоматизировать можно все процессы. По фразе «Global service» — предположить, что одна и та же услуга доступна в каждой стране. А «24/7 infrastructure» — прочитать как круглосуточное вмешательство специалистов.

Фразу «Full-service branding» он может понять так, будто логотип, упаковка, сайт, социальные сети и все производственные файлы входят в одну цену. Проблема здесь не только в маркетинговом преувеличении. Когда неопределённое заявление превращается в поведение агента, возникает настоящая ошибка выбора.

Поэтому GBO проводит чёткое различие:

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

Что такое возможности?

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

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

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

Конкретный результат

Что будет получено?

Отчёт?

Работающее программное обеспечение?

Опубликованная страница?

Одобренный черновик?

Управляемое сопровождение?

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

Заданные входные данные

Что нужно для работы?

Данные?

Доступ?

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

Документация существующей системы?

Исходные файлы?

Без достаточных исходных материалов обещать результат нельзя.

Условия

В какой среде эти возможности применимы?

Есть ли требования к технологии, стране, языку, бюджету, команде или срокам?

Ограничения

Что не входит в работу?

Какие случаи требуют отдельного задания?

На каком этапе должен подключиться человек или другой специалист?

Полномочия

Уметь выполнить работу и иметь разрешение на неё — разные вещи.

Критерии качества

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

Возможность подтверждения

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

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

Результат получен случайно или его можно повторить в сходных условиях?

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

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

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

Возможности

Умеешь ли ты выполнять эту работу?

Доступные ресурсы

Есть ли у тебя ресурсы, чтобы сделать её сейчас, в нужном масштабе и в нужный срок?

Пригодность для задачи

Подходишь ли ты для этой работы, этого клиента, этого риска и этих условий?

Компания может уметь выполнить работу, но не иметь свободных ресурсов. Может иметь ресурсы, но не подходить для задачи. Может выглядеть подходящей, но не суметь подтвердить свои возможности. Агенту недостаточно увидеть, что «эта компания предлагает такую услугу».

Нужно знать и другое:

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

Уметь что-то делать и продавать это как услугу — разные вещи

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

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

Нужны также:

• Чёткий состав работ
• Условия принятия заказа
• Цена или способ её определения
• Форма передачи результата
• Критерии качества
• Ответственность человека
• Процедура внесения изменений
• Границы поддержки
• Порядок работы с ошибками и отката
• Юридические или лицензионные условия

Иными словами, технический навык не становится коммерческой услугой автоматически.

Пять состояний возможностей

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

1. Заявленные возможности

Сущность говорит, что умеет что-то делать: «Мы предлагаем корпоративные решения на основе ИИ». Это исходная информация, но её пока недостаточно.

2. Описанные возможности

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

3. Продемонстрированные возможности

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

4. Операционные возможности

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

5. Возможности, готовые к действию

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

Однако агент не находит ответов на вопросы:

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

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

Контракт возможностей

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

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

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

Назовём это Контрактом возможностей NOMOS.

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

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

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

Название результата должно быть ясным

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

Например, «услуги брендинга» — очень общее выражение. Что из перечисленного в него входит?

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

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

и «полная система визуальной идентичности» — разные результаты. «Хостинг»

и «управляемое сопровождение сайта» — тоже разные результаты. «Консультации по SEO»

не равны «техническому внедрению и постоянной работе над видимостью». «Создание ИИ-аватара»

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

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

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

В веб-проекте передаваемые материалы могут включать:

• Дизайн-файлы
• Код
• Изображения
• Конфигурацию
• Документацию

Но для клиента настоящий результат —

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

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

Передаваемые материалы

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

Приемлемый итог

Как будет подтверждено, что всё это работает и соответствует цели?

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

Без исходных материалов возможности не реализуются

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

Дизайнеру необходимы:

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

Без этого не построить подходящую систему идентичности бренда.

Разработчику нужны:

• сведения о существующей системе;
• документация интеграций;
• права доступа;
• структура данных;
• критерии приёмки.

Без них нельзя сдать надёжное программное обеспечение.

Специалисту по конверсии нужны:

• надёжные аналитические данные;
• объём трафика;
• намерение пользователя;
• существующая воронка;
• определение конверсии.

Без этого нельзя получить научно обоснованный результат.

Агенту необходимы:

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

Без них он не может действовать безопасно. Маркетинговый язык часто скрывает требования к исходным материалам. Фраза «мы всё решим» звучит уверенно. Но если не объяснить, что должен предоставить клиент, в начале проекта возникнут трения. Для GBO исходные материалы — не только вопрос управления проектом. От них зависит, может ли агент выбрать услугу. Если пользователь не может передать нужные данные, услуга может не подойти. Если нельзя предоставить необходимые доступы, результат может измениться. Если выборка недостаточна, нужно менять метод тестирования.

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

Предварительное условие — не препятствие

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

Компания может сказать: «Мы выполняем интеграцию с CRM». Но если у целевой CRM нет доступа к API, интеграция может оказаться невозможной.

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

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

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

Предварительное условие — не слабость услуги, а объяснение реальности, в которой её возможности работают.

Возможности без границ ненадёжны

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

Границы могут определять:

• Отрасли, которые не обслуживаются
• Неподдерживаемые технологии
• Недопустимые способы использования
• Работы, оплачиваемые отдельно
• Операции, требующие одобрения человека
• Результаты, которые не гарантируются
• Зависимости от третьих сторон
• Исключения по юридическим или этическим основаниям

Указать границы — не значит преуменьшить возможности. Так становится понятно, в каких пределах на них можно положиться.

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

Для поведения необходимо знать, что не входит в услугу

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

Покупая «разработку логотипа», они могут ожидать:

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

Им может показаться, что всё это тоже включено.

При покупке «хостинга» могут ожидаться:

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

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

Фразу «автоматизация на основе ИИ» можно понять так:

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

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

Цена — часть возможностей

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

Выбирая поставщика, агент должен знать, является ли цена:

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

Одного «от 500 долларов» недостаточно. Какой объём работ покрывают эти 500 долларов?

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

Входит ли обслуживание?

Включены ли лицензии?

Включены ли налоги?

Входит ли перенос данных?

Включены ли шесть языков?

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

Если цены нет, её нельзя выдумывать

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

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

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

Агент может выбрать один из следующих шагов:

• Запросить диапазон бюджета
• Попросить предварительную оценку
• Объяснить способ ценообразования
• Отложить сравнение по фиксированным ценам

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

Начальная цена — не полная стоимость

Услуга разработки ПО может стоить от 1 000 долларов.

Но отдельно могут оплачиваться:

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

Хостинг может стоить 200 долларов в год, а активное сопровождение — требовать отдельной ежемесячной оплаты. Разработка логотипа может стоить 1 000 долларов, тогда как полная визуальная идентичность, упаковка, шаблоны и производственные носители определяются отдельным объёмом работ. Если агент замечает только самое низкое число, он принимает неверное экономическое решение.

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

Основную услугу Обязательные расходы на третьих лиц Дополнительные работы при определённых условиях Постоянное сопровождение Необязательные расширения

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

Время ответа и время решения — разные вещи

В поддержке и сопровождении часто встречается одна неясность: «Ответ в течение часа». Эта фраза не означает, что за час проблема будет решена.

Время ответа

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

Время решения зависит от:

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

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

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

• Время первого ответа
• Время до начала расследования
• Срок, за который планируется временно уменьшить последствия
• Целевое время решения
• Внешние зависимости с неопределёнными сроками

Сделать один раз — не значит уметь делать постоянно

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

Когда это было сделано? В какой версии? Какой командой? При каких условиях? Поддерживается ли это до сих пор?

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

Дрейф возможностей

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

Назовём это дрейфом возможностей.

Он проявляется так:

• В списке остаются услуги, которые уже не предоставляются
• Новые услуги описываются в рамках старого состава работ
• Утверждения опираются на сотрудников, которых больше нет в команде
• Устаревшие технологии или сертификаты выглядят актуальными
• Возможности прототипа преподносятся как промышленная услуга
• Решение для одного клиента описывается как универсальный продукт
• Новые заявки принимаются, хотя свободных ресурсов уже нет

Дрейф идентичности искажает ответ на вопрос «кто ты?». Дрейф возможностей — на вопрос «что ты можешь?».

Долг заявленных возможностей

Со временем у организаций накапливается множество услуг и обещаний.

На разных страницах остаются:

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

Всё это может сохраняться в разных частях сайта.

Такое накопление назовём долгом заявленных возможностей: разрывом между тем, что организация обещает уметь, и её текущей операционной реальностью. Чем больше долг, тем труднее агентам действовать правильно. Одна страница говорит «мы это делаем», в другой записи услуги нет, каталог цен описывает иной объём работ, FAQ подразумевает другую гарантию, а отдел продаж говорит что-то ещё. Машина не знает, какую информацию использовать. Цель GBO — не только сделать новые услуги видимыми, но и уменьшить этот долг.

Приукрашивание возможностей

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

Это не значит, что соответствующая организация сертифицировала услугу.

Агент должен сохранять различия:

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

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

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

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

Заявление

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

Объяснение

Описывает, как она это делает и каковы ограничения.

Пример

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

Тест

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

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

Есть действующая промышленная система или проверяемая публикация.

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

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

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

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

Ограниченных доказательств недостаточно для широких гарантий.

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

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

Границы доказательства должны быть видны:

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

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

Гарантия результата и обязательства по процессу

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

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

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

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

Возможности и готовность принять работу

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

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

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

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

Уметь делать что-то — не значит иметь возможность сделать это сейчас.

Ресурсы — не только численность сотрудников

Рабочий потенциал компании нельзя измерять одним количеством людей.

Он может зависеть от:

• Распределения компетенций
• Инструментов и инфраструктуры
• Текущей проектной нагрузки
• Процедур одобрения
• Зависимостей от поставщиков
• Охвата языков и стран
• Часов поддержки
• Зависимости от ключевых специалистов
• Уровня автоматизации
• Нагрузки по контролю качества

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

Настоящий вопрос: можно ли действительно получить этот результат в это время и с таким качеством?

Возможности, зависящие от одного человека

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

Этот риск особенно существенен в таких областях, как:

• заказная разработка ПО;
• безопасность;
• право;
• техническое сопровождение;
• креативное руководство;
• языковая экспертиза.

В этих областях зависимость от одного специалиста особенно важна.

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

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

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

Как понять возможности агента ИИ?

Сказать об агенте ИИ «он может управлять сайтами» — слишком широко. Что именно из следующего он умеет?

• Читать файлы
• Редактировать код
• Запускать тесты
• Искать информацию в интернете
• Загружать файлы по разрешённому зашифрованному каналу передачи
• Проверять хеш опубликованного файла
• Менять DNS
• Писать тексты о ценах
• Менять юридическое содержание
• Отправлять сообщения клиентам

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

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

Знание того, как им пользоваться Полномочия на использование Способность проверить результат

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

Список инструментов — не контракт возможностей.

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

У агента или услуги можно различить два вида возможностей:

Декларативные возможности

Описывают, что можно сделать: «Я могу провести аудит canonical и hreflang».

Исполнимые возможности

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

Сочетание возможностей

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

Образуется цепочка задач:

• Исследовательский агент собирает сведения.
• Стратегический агент строит модель принятия решений.
• Контент-агент пишет текст.
• Агент-разработчик реализует систему.
• QA-агент проверяет её.
• Агент публикации выпускает результат в рабочую среду.
• Агент измерений отслеживает итог.

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

Иллюзия составных возможностей

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

Но без общей записи фактического состояния:

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

Для составных возможностей нужны:

• Общая идентичность
• Общий канонический источник
• Передача задачи и полномочий
• История версий
• Шлюзы качества
• Квитанция действия
• Путь отката

Передача возможностей

Один агент может передать задачу другому.

Но при каждой передаче должны сохраняться:

• Требуемый результат
• Допустимые исходные данные
• Запрещённые методы
• Граница полномочий
• Критерий качества
• Крайний срок
• Пороги обязательного одобрения человеком
• План возврата

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

Поэтому возможности можно передавать, но контракт нужно передавать вместе с ними.

Поведение при неудаче — часть возможностей

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

Агент:

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

Как хостинг-провайдер действует при сбое?

Что делает команда разработки, если релиз не удался?

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

Создаёт ли агент ИИ ложную уверенность, когда данных недостаточно?

Если поведение при неудаче не описано, контракт возможностей неполон.

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

Частичный успех

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

Частичный успех нужно зафиксировать ясно:

• Что завершено?
• Что не завершено?
• Почему?
• Какой риск остаётся?
• Можно ли использовать результат?
• Нужно ли решение человека?

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

Честность в описании возможностей

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

Это способность сказать: «Мы умеем это делать, но нам нужны такие исходные данные». «Эту часть мы выполняем; другая относится к отдельному объёму работ». «Этот результат можно измерить, но нельзя гарантировать». «Мы работаем с этой технологией, но эту версию не поддерживаем». «Если выборка недостаточна для контролируемого сравнения, мы пересматриваем план сбора данных и отделяем пригодные наблюдательные выводы от утверждений о причинности». «Цена относится к начальному объёму работ; расходы на третьих лиц не включены». «Агент может подготовить черновик, но не имеет права его отправлять». Это не признаки слабости, а ориентиры, позволяющие машине принять правильное решение.

Способность воздержаться

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

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

Знать, чего ты не можешь, — одно. Знать, чего не следует делать, — другое.

GBO включает и то и другое в контракт возможностей.

Машиночитаемая запись возможностей

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

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

capability_name

provider_identity

outcome

supported_use_cases

unsupported_use_cases

required_inputs

eligibility

deliverables

quality_criteria

commercial_terms

third_party_costs

capacity_status

supported_languages

supported_regions

required_permissions

human_approval

evidence

version

valid_from

valid_until

failure_behavior

rollback

contact_or_action_endpoint

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

Главное правило: машиночитаемая запись не должна обещать больше, чем видимая страница услуги.

Соответствие видимого и машиночитаемого описания возможностей

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

Если страница говорит «только для действующих клиентов», каталог не должен представлять услугу как доступную всем.

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

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

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

Происхождение возможностей

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

Использует субподрядчика?

Зависит от сторонней платформы?

Применяет инструмент с открытым исходным кодом?

Эксплуатирует лицензированную модель?

Работает в собственных системах клиента?

Это можно объяснить, не раскрывая подробностей коммерческой тайны.

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

Зависимость от третьих сторон

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

• Облачный провайдер
• Платёжная система
• Поисковая система
• Социальная платформа
• Поставщик модели
• Сервис лицензирования
• Поставщик карт или данных

Любой из них может столкнуться со сбоем или изменить правила.

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

• существующие зависимости;
• риски, находящиеся вне контроля;
• альтернативный план или план возврата —

в той мере, в какой это возможно.

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

Как понять, что услуга готова?

Услугу можно считать готовой к действию при следующих условиях:

• Её идентичность связана с правильным поставщиком.
• Результат ясно определён.
• Необходимые исходные данные известны.
• Видно, что входит и не входит в объём работ.
• Цена или способ ценообразования объяснены.
• Известны доступные ресурсы и условия начала работы.
• Доказательства обозначают границы обоснованного заявления.
• Записи для людей и машин не противоречат друг другу.
• Путь выполнения операции или связи безопасен.
• Определены поведение при неудаче и порядок возврата.

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

Шлюз возможностей NOMOS

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

1. Шлюз результата

Ясно ли, что будет получено?

2. Шлюз доказательств

Соответствует ли сила доказательств масштабу заявления о возможностях?

3. Шлюз состава работ

Определено ли, что включено и что исключено?

4. Шлюз исходных данных

Можно ли обеспечить нужные данные, доступ, участие людей и предварительные условия?

5. Шлюз ресурсов

Может ли поставщик или агент выполнить эту работу сейчас и в нужном масштабе?

6. Коммерческий шлюз

Понятны ли ценообразование, расходы на третьих лиц и продолжающиеся обязательства?

7. Шлюз исполнения

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

8. Шлюз неудачи

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

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

УСЛОВИЯ ШЛЮЗА ВОЗМОЖНОСТЕЙ:

ЯСНЫЙ РЕЗУЛЬТАТ

И НАДЛЕЖАЩЕЕ ДОКАЗАТЕЛЬСТВО

И ЧЁТКИЙ СОСТАВ РАБОТ

И ДОСТАТОЧНЫЕ ИСХОДНЫЕ ДАННЫЕ

И ДОСТУПНЫЕ РЕСУРСЫ

И ПОНЯТНЫЕ КОММЕРЧЕСКИЕ УСЛОВИЯ

И БЕЗОПАСНОЕ ИСПОЛНЕНИЕ

И ПЛАН НА СЛУЧАЙ НЕУДАЧИ

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

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

Что делать агенту, если сведений о возможности не хватает?

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

Задать вопрос

«Входит ли миграция данных в цену?» «Покрывает ли пакет реагирование на инциденты по выходным?» «На шести языках доступен только контент или также живая поддержка?»

Снизить уровень действия

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

Найти другой вариант

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

Пример закупочного агента

Компания хочет обновить свои продающие презентации.

Агент получает задание: «Найди поставщика систем презентаций для руководителей. Наш бюджет — 4 000 долларов. Через две недели нам нужна первая презентация для совета директоров». Агент находит трёх поставщиков.

Поставщик A

Показывает очень сильные визуальные работы. Заявляет, что создаёт «презентации мирового уровня». Цена, срок сдачи и ответственность за содержание не указаны.

Поставщик B

Выглядит скромнее.

Зато объясняет:

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

Поставщик C

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

Но прежде чем выбрать B, агент должен проверить:

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

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

Пример агента ИИ

Компания ищет агента для управления электронной почтой.

На странице продукта написано: «Полностью автономное управление электронной почтой». Звучит впечатляюще.

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

• Он только классифицирует входящие сообщения?
• Готовит черновики?
• Отправляет автоматически?
• Кому он может писать?
• Как обрабатывает письма с ценами, договорами или юридической информацией?
• Умеет ли читать вложения?
• Куда передаёт персональные данные?
• Как останавливается ошибочная отправка?
• В какой момент требуется одобрение человека?
• Ведётся ли журнал операций?

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

Возможности неотделимы от безопасности

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

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

Может ли система аватаров остановить создание неразрешённого сценария?

Проверяет ли веб-агент границы задания перед изменением работающего сайта?

Замечает ли закупочный агент скрытую подписку или автоматическое продление?

Безопасность — не страховка, существующая отдельно от возможностей.

Умение, которое нельзя применить безопасно, не является полноценной возможностью.

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

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

Если поставщик говорит: «Мы создаём веб-интерфейсы»,

важно спросить:

• Есть ли альтернатива для маломощных устройств?
• Предусмотрен ли резервный двумерный вариант?
• Поддерживается ли управление с клавиатуры?
• Предусмотрен ли режим уменьшения анимации?
• Есть ли субтитры и текстовые расшифровки?

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

Возможности и юридические границы

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

Но должен разграничивать:

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

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

Где граница услуги пересекается с другой услугой?

Смешение близких услуг может привести к ошибочному выбору.

Например:

• SEO и GEO
• Хостинг и сопровождение сайта
• Логотип и визуальная идентичность
• Отчётность и система принятия решений
• Оптимизация конверсии и разработка ПО
• Создание ИИ-аватара и полномочия на публикацию от имени организации
• Консультации по DevOps и постоянное управление инфраструктурой

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

Где начинается эта услуга? Где заканчивается? На каком этапе нужна другая услуга?

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

Проверка готовности возможностей

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

Пятнадцать контрольных вопросов о возможностях

Об услуге, продукте или агенте можно спросить:

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

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

Польза контракта возможностей для людей

Контракт возможностей предназначен не только машинам. Его цель — уменьшить ложные ожидания и упростить сравнение. Ясный состав работ, комплект результатов и критерии приёмки дают опору и разговору о продаже, и реализации. По записи можно также проверять, не описывают ли сотрудники одну услугу по-разному. Такие коммерческие результаты не возникают автоматически. Длительность переговоров, долю подходящих запросов и разногласия нужно измерять отдельно. Услуга может показаться подходящей меньшему числу людей; важно, чтобы правильное соответствие стало легче различить.

Коммерческая ценность ясного описания возможностей

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

Организация выглядит профессиональнее, если клиент и агент легко находят ответы на вопросы:

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

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

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

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

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

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

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

В тайне могут остаться:

• Собственные промпты
• Исходный код
• Веса внутренней системы оценивания
• Анализ конкурентов
• Детали безопасности
• Ядро автоматизации
• Цены поставщиков
• Внутренние инструкции агентам

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

• Реальный состав услуги
• Способ ценообразования
• Существенные исключения
• Необходимое одобрение человека
• Расходы на третьих лиц
• Ограничения ресурсов
• Негарантируемые результаты
• Путь отзыва или отмены

Верный принцип таков:

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

Квитанция возможностей

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

Квитанция возможностей

В ней фиксируется выполненная работа.

Запись показывает:

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

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

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

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

Составить перечень возможностей

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

Разделить соседние услуги

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

Подготовить каноническую запись состава работ

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

Объяснить ценовые условия

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

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

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

Поддерживать актуальность сведений о ресурсах

Отслеживать приём новых заказов и условия по срокам.

Обеспечить соответствие машиночитаемых записей

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

Определить поведение при неудаче

Кто и что будет делать, если возникнет проблема?

Как агенту говорить о неясных возможностях?

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

Неверно: «Эта компания предоставляет полную клиентскую поддержку на шести языках».

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

Неверно: «Этот хостинг включает управляемую поддержку круглосуточно».

Точнее: «Пакет включает хостинг; активное реагирование на инциденты и управляемое сопровождение могут быть отдельной услугой».

Неверно: «Эта система ИИ-аватаров полностью соответствует законодательству».

Точнее: «Система описывает меры контроля согласия, раскрытия информации, происхождения и отзыва; соответствие правовым требованиям необходимо отдельно оценить для конкретной страны и сценария использования». Честное выражение неопределённости не делает агента слабым. Оно делает его надёжным.

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

Чтобы утверждать, что организация действительно умеет что-то делать, недостаточно фразы «мы уже делали это раньше».

Сильнее сказать: «Мы способны получить этот результат с такими исходными данными, в таком составе работ, через такие шлюзы качества и при таких ограничениях; вот доказательства; а в этих случаях мы не принимаем заказ или запрашиваем одобрение человека». Фраза длиннее, но именно в ней — точность, которую требует эпоха агентов.

Вывод главы

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

Но возможности — это не:

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

Настоящие возможности складываются из следующего:

Ясный результат Необходимые исходные данные Проверяемое доказательство Чёткий состав работ Доступные сейчас ресурсы Понятные коммерческие условия Безопасное исполнение Поведение при неудаче

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

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

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

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

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

В следующей главе мы перейдём к одному из самых деликатных вопросов GBO:

Когда агенту следует выбрать тебя?

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

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