Организация как онтология: зачем людям и ИИ-агентам общий язык компании

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

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

У такой модели быстро обнаруживается следующий уровень сложности.

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

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

Компании требуется общий язык.

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

Представим компанию, в которой ИИ-агент должен подготовить предложение для клиента.

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

Все системы содержат корректные данные. Проблема возникает в момент действия.

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

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

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

Что такое онтология

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

В OWL 2 Primer консорциум W3C описывает онтологии как средство представления терминов предметной области и отношений между ними в форме, доступной для машинной обработки.

Для компании это можно сформулировать проще:

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

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

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

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

У этой идеи есть история

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

В работе The Enterprise Ontology, опубликованной исследователями Эдинбургского университета, предприятие описывалось через деятельность, организацию, стратегию и маркетинг. Задачей было создать общий набор терминов, пригодный для общения людей и построения информационных систем.

Позднее W3C разработал The Organization Ontology — словарь для описания организаций, подразделений, должностей, членства и организационных связей.

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

Словарь, схема данных, граф знаний и онтология

Эти понятия часто смешиваются, хотя они решают разные задачи.

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

Компания А → связана с → Сделка 42

Для навигации этого может быть достаточно. Для действия агента информации мало.

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

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

Слои данных, знаний, памяти, смысла и полномочий.

Почему эта проблема усиливается с появлением агентов

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

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

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

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

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

Организация как онтология

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

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

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

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

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

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

Один объект — одна каноническая идентичность — множество представлений

Один клиент может присутствовать в CRM, бухгалтерии, переписке, аналитике и системе поддержки. Представления будут различаться, но система должна понимать, что они относятся к одному объекту.

Отсюда следует правило:

Один объект — одна каноническая идентичность — множество представлений.

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

Агенту тогда доступна карта:

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

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

Минимальное ядро операционной онтологии

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

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

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

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

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

Как система определяет, что перед ней тот же самый объект?

У задачи может быть идентификатор в Plane. У материала — страница в Notion и отдельный адрес на сайте. У источника — канонический URL. У консультации — запись встречи и связанная с ней транскрибация.

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

2. Определение

Что именно означает сущность в этой компании?

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

Определение должно быть коротким и пригодным для принятия решения.

3. Состояния

Какие состояния проходит объект?

Для материала это может быть:

идея → исследование → структура → черновик → утверждено → опубликовано

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

4. Отношения

Как объект связан с другими объектами?

Материал основан на источнике. Утверждение подтверждается источником. Решение принимает человек. Агент выполняет задачу. Публикация создаётся из утверждённой версии материала.

Именно отношения превращают набор карточек в рабочую модель компании.

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

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

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

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

6. Владелец смысла

Кто отвечает за определение сущности и разрешает спорные случаи?

Предлагаю назвать эту роль владельцем смысла.

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

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

Операционная онтология компании.

Как это уже возникает в работе pimenov.ai

При создании серии «ИИ-компания» постепенно формируется собственная операционная онтология редакционного процесса.

Её упрощённый фрагмент выглядит так:

Тема → Источник → Утверждение → Материал → Решение → Публикация

У этих сущностей разные функции:

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

Между сущностями возникают отношения:

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

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

Онтология не заменяет контекст

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

Ему по-прежнему нужны:

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

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

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

Получается разделение функций:

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

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

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

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

В прикладной системе проверка может быть проще:

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

Так онтология превращается из справочника терминов в исполняемый контракт.

Когда отдельная онтология пока не нужна

Не каждому процессу требуется формальная модель.

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

Онтологический слой становится полезным, когда:

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

Чем выше автономность процесса, тем дороже расхождение в смысле.

Как начать без многолетнего проекта

Операционную онтологию лучше строить вокруг конкретного процесса.

Шаг 1. Выберите один сквозной результат

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

Шаг 2. Выпишите участвующие сущности

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

Шаг 3. Найдите конфликтующие термины

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

Шаг 4. Назначьте каноническую идентичность

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

Шаг 5. Опишите состояния и переходы

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

Шаг 6. Назначьте владельцев смысла

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

Шаг 7. Добавьте машинные проверки

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

Шаг 8. Подключите одного агента

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

Шаг 9. Проверьте реальные сбои

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

Общий язык становится частью инфраструктуры

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

По мере роста автономности этого уровня становится мало.

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

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

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

Источники

• W3C — OWL 2 Web Ontology Language Primer
• Mike Uschold et al. — The Enterprise Ontology
• W3C — The Organization Ontology
• W3C — Shapes Constraint Language
• OpenAI — Inside our in-house data agent
• Agent2Agent Protocol — Key concepts
• Anthropic — Effective context engineering for AI agents

Следующий шаг

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

Связанные материалы

• 10 контуров ИИ-компании
• Graphify для Claude Code: граф знаний по кодовой базе
• Mem0: память для ИИ-агентов

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov