Автор: Николай Никулин
Как связать 1С, CRM, почту, телефонию, документы и действия в общую операционную модель для людей и AI-агентов.
Содержание статьи 00 Компания хранится в системах, но работает объектами
01 Что такое онтология простыми словами
02 От таблиц к объекту «Клиент»
03 Из чего состоит онтология
04 Чем онтология не является
05 Зачем онтология AI-агентам
06 Онтология и RAG работают вместе
07 Как такой слой выглядит в контуре Comb
08 Как начать без проекта на несколько лет
09 Где онтологии ломаются
10 Цена и ограничения
11 Почему тема вернулась именно сейчас
AI уже умеет читать документы, разбирать переписку и готовить ответы. Проблема начинается, когда ему нужно понять, что карточка в CRM, контрагент в 1С, цепочка писем и запись звонка относятся к одному клиенту. Какой счёт актуален. Кто отвечает за следующий шаг. Что является фактом, а что только обещанием. И какое действие вообще разрешено выполнить.
Это уже не задача языковой модели. Это задача устройства контекста компании. Один из способов решить её - онтология.
Главная мысль: онтология задаёт не просто названия сущностей. Она связывает данные, бизнес-логику, действия и права в единую операционную модель.
00 Компания хранится в системах, но работает объектами
Разные системы — один объект
1С Контрагент 00451
CRM Компания 884
Почта assistant@…
Телефония call C-8432
Документы договор 18/26
Клиент: ООО «Ромашка» ответственный · задолженность · сделки · контакты · обязательства
Разные записи становятся одним объектом только после разрешения идентичности и явной привязки источников. Внутри компании нет одной таблицы с правильной картиной мира.
Клиент хранится сразу в нескольких местах:
как контрагент в 1С;
как компания и набор сделок в CRM;
как адреса и цепочки писем в почте;
как звонки и расшифровки в телефонии;
как договоры, протоколы и коммерческие предложения на диске;
как задачи сотрудников в Bitrix24;
как фактическая задолженность в учётной системе.
Для каждой системы это разные записи с разными идентификаторами. Для сотрудника - один клиент.
Человек обычно собирает эту картину в голове. Он помнит, что ООО «Ромашка» недавно сменило юридическое лицо, что письмо пришло от помощника директора, что обещание оплатить прозвучало в конце звонка, а карточка в CRM не обновлялась неделю.
AI-агент такой фон сам не восстанавливает. Ему можно загрузить много текста, но объём контекста не превращается автоматически в понимание устройства бизнеса.
Модель может найти похожее название. Может пересказать письмо. Может предположить связь. Но без дополнительного слоя она не знает:
какие записи обозначают один и тот же объект;
какой источник считается главным для конкретного свойства;
к какому моменту относится факт;
подтверждён ли он;
кто имеет право его изменить;
какое действие должно произойти дальше;
куда записать результат, чтобы он стал частью рабочего процесса.
Поэтому корпоративному AI нужен не только доступ к данным. Ему нужна карта того, что существует в компании и как с этим разрешено работать .
01 Что такое онтология простыми словами
Рабочая формула
Объекты
Свойства
Связи
События
Правила
Действия
Права
Операционная модель компании
Онтология соединяет семантику, правила исполнения и контур полномочий. В информационных системах онтология - это согласованная модель предметной области. Она описывает:
какие сущности существуют;
какими свойствами они обладают;
как связаны между собой;
какие правила действуют;
откуда появились сведения;
какие изменения допустимы.
В стандартах Semantic Web онтологии описываются через классы, свойства, экземпляры и формально заданные отношения. Например, W3C определяет OWL 2 как язык онтологий с формально определённым смыслом. 1
Но в корпоративных AI-системах термин часто используется шире. Здесь мало описать, что существуют Клиент , Заказ и связь Клиент сделал заказ . Нужна операционная часть:
рассчитать риск;
согласовать скидку;
создать задачу;
подтвердить резюме звонка;
отправить запрос;
записать результат обратно в CRM или 1С;
проверить полномочия;
сохранить историю решения.
Поэтому для этой статьи используем рабочую формулу:
Онтология компании = объекты + свойства + связи + события и утверждения + правила + разрешённые действия + права и история изменений
Это не единственное возможное определение. Оно полезно именно для разговора об AI-агентах и операционной системе компании.
Palantir называет свою Ontology операционным слоем организации. В нём семантические элементы - объекты, свойства и связи - соединены с действиями, функциями и динамической безопасностью. 2 Microsoft в Fabric IQ описывает онтологию как общую управляемую бизнес-модель для команд, агентов и рабочих процессов. 3
Обе формулировки важны по одной причине: онтология нужна не для красивой схемы. Она нужна, чтобы разные системы и участники одинаково понимали рабочую ситуацию.
Онтология - это контракт о смысле. Люди, приложения и агенты получают общий ответ на вопросы: что это за объект, с чем он связан, откуда известен факт и что с ним можно сделать.
02 От таблиц к объекту «Клиент»
От речи к рабочей задаче
Звонок источник
Утверждение требует проверки
Обязательство подтверждено
Задача CRM передано в работу
Правдоподобная фраза становится рабочим фактом только после проверки. Допустим, в компании есть ООО «Ромашка».
В исходных системах контекст выглядит так:
1С Контрагент: 00451 Задолженность: 1 250 000 ₽ Дата обновления: сегодня, 08:05
Bitrix24 Компания: 884 Сделка: D-491 Стадия: Согласование договора Ответственный: Петров Дата обновления: 6 дней назад
Почта Тема: «Оплата по договору 18/26» Отправитель: assistant@romashka.ru Последнее письмо: вчера
Телефония Звонок: C-8432 Участники: Петров, Иванова Расшифровка: клиент обещал оплатить до 2 сентября
Если просто передать эти четыре блока модели, она попробует связать их по названию, адресу, участникам и содержанию. Иногда правильно. Иногда нет.
В онтологии появляется один объект:
Customer: id: customer-1842 legal_name: ООО Ромашка manager: employee-32 segment: key_account
balances: - source: 1C amount: 1250000 observed_at: 2026-08-27T08:05:00+03:00
deals: - id: deal-D-491 source: Bitrix24 stage: contract_review updated_at: 2026-08-21
interactions: - email-thread-991 - call-C-8432
Это не означает, что все данные физически копируются в один файл. Объект может собираться из нескольких источников. Главное - у него появляется единая идентичность и понятные связи.
При этом каждое свойство должно сохранять происхождение:
источник;
время наблюдения;
актуальность;
автора или систему;
статус проверки;
версию правила, которым оно рассчитано.
Особенно важно не смешивать факт и утверждение.
Фраза «клиент оплатит до 2 сентября» ещё не является датой фактической оплаты. Это утверждение из разговора. Оно может быть записано так:
Claim: subject: customer-1842 predicate: plans_payment_by value: 2026-09-02 source: call-C-8432 speaker: contact-17 extracted_by: agent-call-summary-v3 confidence: 0.89 status: awaiting_confirmation
После проверки сотрудником утверждение может:
стать подтверждённым обязательством;
быть исправлено;
быть отклонено;
остаться неподтверждённым;
породить задачу в Bitrix24.
Этот переход важнее самого графа. Он не даёт агенту превратить любую правдоподобную фразу из расшифровки в официальный факт компании.
03 Из чего состоит онтология
Объекты
Объект - конкретная сущность, с которой работает бизнес.
Примеры типов объектов:
Клиент Контакт Сотрудник Сделка Счёт Товар Звонок Обязательство Задача Документ Решение Тендер
Клиент - тип объекта. ООО «Ромашка» - экземпляр.
Хорошая модель описывает реальность бизнеса, а не названия таблиц. Объект лучше назвать Клиент , а не CRM_COMPANY_V2 , даже если сегодня его основная запись живёт в CRM.
Свойства
Свойства описывают объект:
название; сегмент; статус; сумма; ответственный; дата следующего контакта; текущая задолженность; уровень риска.
Одни свойства приходят из систем напрямую. Другие рассчитываются.
Например, задолженность может поступать из 1С, а риск срыва оплаты - вычисляться по нескольким сигналам: сроку, истории платежей, последнему разговору и открытым обязательствам.
Связи
Связи объясняют контекст:
Сотрудник обслуживает Клиента Клиент участвует в Сделке Сделка содержит Товары Звонок относится к Клиенту Звонок породил Обязательство Обязательство выполняется Задачей Задача хранится в Bitrix24 Решение основано на Документах и Утверждениях
Именно связи позволяют агенту не искать всё подряд. Он начинает с конкретного клиента и проходит только по релевантному контуру.
События, утверждения и доказательства
Компания меняется во времени. Поэтому одной текущей карточки объекта недостаточно.
Нужны:
события - звонок состоялся, счёт оплачен, статус изменён;
утверждения - участник разговора сообщил, что оплатит позже;
доказательства - письмо, документ, запись, строка учётной системы;
временные границы - когда сведения были верны;
статус проверки - подтверждено, отклонено, требует проверки.
Для AI-систем это критично. Языковая модель работает с вероятностями. Операционная система компании должна уметь отличить вероятное извлечение от принятого факта.
Функции и правила
Функции отвечают на вопросы:
Какова рентабельность сделки? Есть ли товар на складах? Какой клиент рискует сорвать план? Какие обязательства просрочены? Кто должен согласовать скидку? Какое следующее действие допустимо?
Внутри может быть обычное правило, SQL, код, оптимизационная модель, ML или вызов LLM. Для пользователя и агента важен стабильный контракт функции: вход, выход, версия и область применения.
Действия
Действие - заранее описанная бизнес-команда.
Не «измени любую строку в CRM», а:
action: approve_discount
inputs: deal_id: Deal discount_percent: Decimal justification: String
checks: - deal.status == negotiation - discount_percent <= allowed_limit_for(user.role) - deal.margin_after_discount >= minimum_margin
requires_approval: - when: discount_percent > 10 role: sales_director
effects: - update Deal.discount - create ApprovalRecord - write result to CRM - notify responsible_employee - append audit_event
Такой контракт ограничивает пространство действий агента. Он не получает произвольный доступ к базе. Он выбирает из разрешённых операций, а система проверяет условия.
Palantir описывает действия в онтологии как транзакции, изменяющие один или несколько объектов по заданной логике. 4
Права и история
Два сотрудника могут видеть один объект по-разному. Один имеет доступ к сумме договора, другой - только к статусу. Агент сотрудника не должен автоматически наследовать доступ ко всей компании.
Поэтому права применяются не только к таблицам. Они нужны на уровне:
типов объектов;
отдельных свойств;
связей;
функций;
действий;
областей клиентов и подразделений;
контекста, который собирается для модели.
Каждое изменение должно оставлять след:
кто инициировал; какой агент участвовал; какие источники использовались; какое правило сработало; кто подтвердил; что записано во внешнюю систему; какая версия объекта получилась.
Без этого автономность быстро превращается в непрозрачность.
04 Чем онтология не является
Что делает каждый слой
База данных Где хранится запись? Строка счёта в 1С
RAG Где об этом написано? Фрагмент договора
Wiki Почему так решили? История проекта
MCP / API Как вызвать систему? Создать задачу
Навык Как выполнить задачу? Проверить тендер
Онтология Что это и что допустимо? Клиент · обязательство · действие
Слои не заменяют друг друга: каждый снимает свой тип неопределённости. Термин часто смешивают с соседними технологиями. Они связаны, но отвечают на разные вопросы.
База данных
База данных хранит записи и обеспечивает запросы и транзакции.
Онтология задаёт общий бизнес-смысл поверх одной или нескольких баз. Она объясняет, что таблица контрагентов в 1С и компания в CRM могут представлять один тип объекта.
Онтология может быть реализована в PostgreSQL, графовой базе, lakehouse или комбинации хранилищ. Наличие графовой базы само по себе ещё не создаёт онтологию.
Каталог данных
Каталог отвечает:
Где лежит поле и кто за него отвечает?
Онтология отвечает:
Что это за сущность в бизнесе, с чем она связана и как участвует в процессе?
Каталог полезен для происхождения и управления данными. Онтология использует эти сведения, но идёт дальше.
Семантический слой BI
Семантический слой BI согласует показатели, измерения и правила расчёта аналитики.
Онтология может включать эти определения, но также описывает операционные объекты, события, действия и права на изменение состояния.
Граф знаний
Практическое различие можно сформулировать так:
онтология описывает типы, значения и правила;
граф знаний заполняет эту модель конкретными объектами и связями.
В реальных продуктах эти части часто живут вместе, поэтому граница не всегда видна пользователю.
RAG
RAG ищет релевантные фрагменты текста и передаёт их модели.
Он хорошо отвечает на вопросы:
что написано в регламенте;
о чём говорили на встрече;
какие условия есть в договоре;
где упомянут конкретный риск.
Но RAG сам по себе не обязан знать, что два документа относятся к одной сделке, какая версия действует и кто вправе изменить статус.
LLM Wiki или корпоративная база знаний
Wiki хранит объяснения, историю решений, инструкции и контекст, который удобно читать человеку и модели.
Онтология хранит более жёсткую операционную структуру:
кто; что; с чем связано; в каком статусе; на основании чего; кто может изменить; каким действием.
Они дополняют друг друга.
MCP и интеграции
MCP, API и коннекторы дают агенту технический путь к системе.
Они отвечают на вопрос:
Как вызвать инструмент?
Онтология отвечает:
С каким бизнес-объектом мы работаем, что означает операция и при каких условиях она допустима?
Навыки агента
Навык описывает, как выполнить типовую задачу: провести анализ тендера, подготовить письмо, сверить номенклатуру.
Онтология даёт навыку опору: какие объекты использовать, какие свойства считать главными, где взять доказательства и какое действие выполнить после расчёта.
Коротко: интеграция даёт доступ, RAG даёт фрагменты, навык даёт процедуру, а онтология задаёт операционные координаты.
05 Зачем онтология AI-агентам
Цикл AI-агента
01 Запрос · роль · цель
02 Объект · связанные факты
03 Функция · предложение
04 Проверка прав
05 Подтверждение · действие
06 Запись · аудит
Агент получает ограниченный путь от запроса до проверяемого изменения состояния. Чат-бот может работать с одной беседой. Агент должен продолжать процесс за пределами беседы.
Ему нужно:
собрать достоверный контекст;
понять объект работы;
выбрать инструменты;
применить правила;
предложить или выполнить действие;
передать результат следующему участнику;
оставить состояние, с которого работу можно продолжить.
Без онтологии агент часто получает сырой набор инструментов:
search_crm get_1c_counterparty find_email search_transcripts update_deal create_task
Дальше модель сама решает, какие записи связать и какой результат считать актуальным. Чем больше систем, тем больше скрытых предположений.
С онтологией интерфейс меняется:
get_customer_context(customer_id) get_open_commitments(customer_id) calculate_payment_risk(customer_id) propose_next_action(customer_id) create_followup_task(commitment_id) request_manager_approval(action_id)
За этими инструментами всё ещё стоят 1С, CRM, почта и телефония. Но агент работает не с их внутренними таблицами, а с понятными объектами и ограниченными действиями.
Рабочий цикл выглядит так:
Запрос или событие ↓ Определение пользователя, роли и цели ↓ Поиск объекта в онтологии ↓ Сбор связанных фактов и доказательств ↓ Запуск функции или правила ↓ Предложение действия ↓ Проверка прав и условий ↓ Подтверждение человеком, если требуется ↓ Запись в рабочую систему ↓ Событие и аудит
Пример запроса:
Подготовь меня к звонку с ООО «Ромашка» и создай следующий шаг по итогам.
Агент может собрать:
активные сделки;
задолженность из 1С;
последние письма;
расшифровку прошлого звонка;
открытые обязательства;
просроченные задачи;
действующие ограничения по скидке.
После звонка он выделит новые утверждения и обязательства. Сотрудник подтвердит резюме. Затем контролируемое действие создаст задачу в Bitrix24. Онтология сохранит связь между задачей, обязательством, клиентом и источником.
Формальная задача остаётся в рабочей системе. Онтология не подменяет Bitrix24. Она делает понятным, почему задача появилась и к какому фрагменту операционного контекста относится.
06 Онтология и RAG работают вместе
Доказательства → координаты → исполнение
RAG документы · письма · расшифровки
↓ доказательства
Онтология объекты · связи · состояние
↓ координаты
Действия проверки · согласования · запись
RAG предоставляет доказательства, онтология задаёт координаты бизнеса, а слой действий выполняет контролируемые изменения. Выбирать между онтологией и RAG не нужно. Они решают разные части задачи.
RAG силён там, где знания живут в тексте:
договоры;
инструкции;
протоколы;
письма;
расшифровки;
проектная документация;
экспертные статьи.
Онтология сильна там, где важны идентичность, структура и текущее состояние:
какой это клиент;
какие сделки активны;
кто отвечает;
какие обязательства открыты;
какой документ действует;
на каком основании рассчитан риск;
какие действия разрешены.
Хороший агентский запрос часто проходит оба слоя:
1. Найти объект «Клиент». 2. Получить связанные сделки, людей и обязательства. 3. Ограничить поиск документами этого клиента и этих сделок. 4. Через RAG достать релевантные фрагменты. 5. Сформировать ответ с источниками. 6. Предложить разрешённое действие. 7. После подтверждения записать результат.
Так снижается шум. Агент не ищет «Ромашку» по всей базе знаний, где могут быть одноимённые организации, старые договоры и черновики. Он сначала понимает координаты объекта, а затем достаёт текстовые доказательства внутри нужного контура.
RAG даёт доказательства. Онтология даёт координаты. Слой действий даёт контролируемое исполнение.
LLM Wiki при этом остаётся полезной. В неё удобно складывать развёрнутую историю проекта, причины решений, инструкции и знания, которые плохо сводятся к свойствам объектов.
Онтология отвечает за операционное состояние. Wiki - за повествовательную память. RAG помогает извлекать нужные фрагменты из этой памяти.
07 Как такой слой выглядит в контуре Comb
Целевая схема контура Comb
1. Источники 1С · Bitrix24 · почта · телефония · документы
2. Контекстный слой идентичность · нормализация · происхождение · права
3. Онтология объекты · связи · утверждения · функции · действия
4. Исполнители агенты сотрудников и руководителей · приложения · человек
5. Результат задачи · письма · согласования · статусы · аудит
Такой слой может выглядеть в контуре Comb; схема показывает целевую архитектуру, а не заявление о полностью внедрённом серийном продукте. Comb соединяет знания компании, рабочие инструменты и AI-агентов. Онтология в такой архитектуре может стать общим слоем между источниками и действиями.
Источники 1С · Bitrix24 · Почта · Телефония · Документы · Сетевые диски ↓ Сбор и нормализация контекста идентификаторы · версии · источники · время · права ↓ Онтология компании объекты · связи · события · утверждения · функции · действия ↓ AI-агенты сотрудников и руководителей ↓ Контролируемые действия задача · согласование · письмо · изменение статуса · эскалация ↓ Рабочие системы и журнал решений
Минимальный набор объектов для клиентского контура может выглядеть так:
Employee Manager Customer Contact Deal Invoice Interaction Call Commitment Task Decision Document Claim Approval
Связи:
Employee reportsTo Manager Employee owns Customer Call involves Customer Call produced Claim Confirmed Claim becomes Commitment Commitment implementedBy Task Task trackedIn Bitrix24 Decision basedOn Claim and Document
Действия:
ApproveCallSummary ConfirmClaim RejectClaim CreateBitrixTask RequestClarification EscalateCommitment ApproveDiscount PublishDecisionToWiki
Сквозной сценарий:
Телефония передаёт запись и расшифровку звонка.
Агент находит участников и связывает звонок с клиентом.
Из текста извлекаются утверждения, решения и обязательства.
У каждого элемента сохраняется источник и статус проверки.
Сотрудник подтверждает резюме.
Подтверждённое обещание становится обязательством.
Действие CreateBitrixTask создаёт формальную задачу.
Агент руководителя видит не только текст резюме, но и объект задачи, основание, срок, владельца и исходный звонок.
Итог выполнения возвращается в тот же контур.
Развёрнутое объяснение решения при необходимости публикуется в LLM Wiki.
В таком устройстве агенты обмениваются не бесформенными сообщениями, а объектами и изменениями состояния.
Это не означает, что весь обмен должен стать жёстким JSON. Человек по-прежнему читает нормальный текст. Но под текстом есть структура, благодаря которой другой агент или система может продолжить работу без повторного угадывания контекста.
08 Как начать без проекта на несколько лет
Минимальный пилот
Контекст клиента
Подготовка
Звонок
Проверенное резюме
Обязательство
Задача
Контроль
Объекты: 8–12 Действия: только необходимые Запись: через подтверждение
Пилот ограничен одним замкнутым управленческим циклом. Плохая постановка задачи:
Построить онтологию всей компании.
Она почти гарантирует бесконечное моделирование, споры о терминах и отсутствие рабочего результата.
Лучше выбрать один замкнутый цикл, где решение проходит от данных до действия.
Например:
Подготовка к контакту → звонок → проверяемое резюме → обязательство → следующая задача → контроль руководителя
Шаг 1. Зафиксировать решение, а не набор данных
Нужно понять, какое решение должен принимать сотрудник или агент.
Не «собрать карточку клиента», а:
Определить следующий шаг после контакта и зафиксировать его в рабочей системе.
Шаг 2. Выделить минимальные объекты
Для первого пилота обычно достаточно 8-12 типов:
Клиент Контакт Сотрудник Звонок Утверждение Обязательство Задача Документ Решение
Не включать свойства «на будущее». Только то, что участвует в выбранном процессе.
Шаг 3. Назначить источники истины
Для каждого свойства нужен ответ:
Где берётся юридическое имя? Где хранится задолженность? Какая система владеет формальной задачей? Кто подтверждает обязательство? Как определяется актуальная версия документа?
У одного объекта может быть несколько источников. Но у конкретного свойства должен быть понятный приоритет и правило разрешения конфликтов.
Шаг 4. Решить идентичность
Самая приземлённая и самая дорогая часть - понять, какие записи относятся к одному объекту.
Понадобятся:
стабильные идентификаторы;
ИНН, номера договоров, адреса и другие ключи;
таблицы соответствий;
правила дедупликации;
ручная проверка спорных совпадений;
история слияния и разделения объектов.
Без этого красивый граф соединит не те сущности.
Шаг 5. Отделить факт от извлечения модели
Любое утверждение, выделенное LLM из письма или звонка, сначала должно сохранить:
источник;
цитируемый фрагмент или координаты;
уверенность;
модель и версию промпта;
статус проверки;
автора подтверждения.
LLM может помогать наполнять онтологию. Она не должна единолично определять истину.
Шаг 6. Описать действия и подтверждения
Для каждого действия нужны:
входные параметры;
проверки;
права;
необходимость подтверждения;
внешняя система записи;
идемпотентность;
журнал результата;
сценарий компенсации при ошибке.
На первом пилоте лучше оставить человека в контуре для всех изменений, которые влияют на деньги, обязательства или клиента.
Шаг 7. Измерять не размер графа, а эффект процесса
Полезные метрики:
время подготовки к контакту;
доля фактов, которые сотрудник исправил;
количество потерянных обязательств;
время от звонка до следующей задачи;
доля действий с понятным источником;
число повторных запросов контекста;
количество конфликтов идентичности;
доля изменений, прошедших нужное согласование.
Количество типов объектов и связей не является бизнес-результатом.
09 Где онтологии ломаются
Шесть антипаттернов
Копия таблиц
Объект-комбайн
Весь архив в графе
LLM-вывод как факт
Универсальная запись
Модель без процесса
Красивый граф не компенсирует ошибочную модель предметной области и отсутствие рабочего процесса. Копируют структуру исходных систем
Если модель повторяет таблицы 1С и CRM, она наследует их ограничения. После изменения схемы ломаются потребители, а бизнес всё ещё видит технические названия.
Хороший порядок обратный:
сначала понять предметную область; потом определить объекты; после этого привязать источники.
Palantir формулирует похожий принцип: сначала моделировать реальные сущности, а не воспроизводить форму исходных наборов данных. 5
Создают один огромный объект
Customer360 с сотнями полей выглядит удобно только в начале. В него начинают складывать клиента, сделки, контакты, платежи, обращения и документы.
В результате:
свойства противоречат друг другу;
трудно версионировать события;
права становятся грубыми;
связи теряются внутри полей;
объект невозможно переиспользовать.
Лучше разделять сущность, наблюдение, событие и документ.
Переносят в граф весь корпоративный архив
Не каждый абзац должен становиться узлом. Большие тексты лучше оставлять в документном хранилище и RAG, а в онтологии хранить связи, метаданные, проверенные утверждения и ссылки на доказательства.
Считают извлечение LLM готовым фактом
Модель может перепутать говорящего, срок, отрицание или контекст. Поэтому машинное извлечение должно проходить через статусы и правила подтверждения.
Дают агенту универсальное действие «обновить что угодно»
Широкий инструмент сокращает разработку, но убирает управляемость. Для продуктивного контура нужны узкие действия с проверками.
Описывают модель, но не подключают процесс
Онтология без приложения, агента или рабочего цикла превращается в документацию, которую никто не поддерживает.
У каждого объекта и действия должен быть реальный потребитель.
Не назначают владельцев смысла
ИТ может реализовать схему. Но только бизнес определяет, что считается активным клиентом, подтверждённым обязательством или допустимой скидкой.
У типов, правил и действий нужны владельцы. Иначе модель быстро расходится с практикой.
Пытаются закончить онтологию
Предметная область меняется. Появляются новые продукты, процессы и ограничения.
Онтология должна версионироваться и развиваться итеративно. В официальных рекомендациях Palantir также подчёркивается итеративность проектирования и необходимость начинать с ясных определений сущностей. 6
10 Цена и ограничения
Онтология не исправляет плохие данные автоматически.
Она, наоборот, делает проблемы видимыми:
у клиента три идентификатора;
статусы в системах расходятся;
никто не знает, какой источник главный;
правило расчёта живёт в Excel одного сотрудника;
решение принято, но основание не сохранено;
действие можно выполнить в обход согласования.
Это полезно, но требует работы.
Основные затраты:
разбор предметной области;
разрешение идентичности;
назначение источников истины;
очистка и привязка данных;
проектирование прав;
описание действий;
версионирование;
наблюдаемость;
участие владельцев процессов.
LLM может ускорить часть работы:
предложить черновую схему;
извлечь сущности из документов;
найти возможные связи;
подготовить описания свойств;
сопоставить поля;
обнаружить противоречия.
Но модель не должна в одиночку решать, что юридически считается договором, кто отвечает за клиента и когда обещание становится обязательством.
Не каждой компании нужна формальная OWL-онтология и отдельная графовая платформа. Для пилота может хватить:
PostgreSQL;
явных типов и связей;
таблицы идентичностей;
контрактов действий;
происхождение данных и доказательств;
политик доступа;
журналов событий;
API или MCP-инструментов поверх этой модели.
Ценность создаёт не конкретное хранилище. Ценность создаёт общая операционная семантика и её использование в реальных процессах.
Онтология также не заменяет системы учёта. 1С остаётся источником финансовых данных. CRM - системой продаж. Bitrix24 - источником формальных задач, если так устроен процесс. Почта - каналом коммуникации.
Онтология связывает эти системы и даёт агентам безопасный способ работать поверх них.
11 Почему тема вернулась именно сейчас
Онтологии существовали задолго до современных языковых моделей. W3C опубликовал первую версию OWL ещё в 2004 году, а актуальная рекомендация OWL 2 Second Edition вышла в 2012 году. 1
Но долгое время семантические технологии оставались отдельной инженерной дисциплиной. Их было дорого проектировать, а пользовательский интерфейс к ним оставался сложным.
LLM изменили вход в систему. Теперь человек может формулировать задачу обычным языком. Модель умеет разбирать документы, сопоставлять формулировки и вызывать инструменты.
Но язык решил только часть проблемы.
Чем больше агенту дают прав, тем важнее становятся вопросы:
с каким объектом он работает;
какие данные актуальны;
откуда они взяты;
какое правило применено;
что агент может изменить;
кто должен подтвердить действие;
как продолжить процесс после его ответа.
Поэтому онтология снова оказалась в центре корпоративной AI-архитектуры.
Palantir строит вокруг Ontology связь данных, логики, действий и безопасности. 7 В Ontology MCP компания также предоставляет объектные типы, действия и функции запросов как инструменты для внешних AI-агентов. 8
Microsoft развивает похожее направление в Fabric IQ: на август 2026 года Ontology находится в preview и описывается как общая управляемая бизнес-модель для команд, агентов и рабочих процессов. 3
Это не означает, что всем нужно копировать Palantir или Microsoft. Но направление понятно: корпоративному AI нужен слой, который связывает язык модели с реальным устройством компании.
ИТОГ Агенту нужен не только контекст, но и место в системе
Без онтологии AI остаётся умным внешним наблюдателем. Он может прочитать документы, собрать справку и предложить ответ. Но каждый раз заново угадывает, как устроена компания.
С онтологией у агента появляется опора:
какие объекты существуют; как они связаны; что известно точно; что только предполагается; где источник; какое действие допустимо; кто должен его подтвердить; куда записать результат.
Это не делает агента безошибочным. Не отменяет контроль человека. Не решает качество данных одной схемой.
Но превращает набор интеграций и промптов в управляемый контур.
Начинать стоит не с графа всей компании. Начинать стоит с одного решения, одного процесса и нескольких объектов, которые нужны, чтобы довести этот процесс от контекста до проверенного действия.
Онтология - не цифровая энциклопедия компании. Это каркас, по которому данные, люди и AI-агенты могут совместно выполнять работу.
ИСТ Источники
01 W3C, OWL 2 Web Ontology Language Document Overview (Second Edition) . https://www.w3.org/TR/owl2-overview/
02 Palantir, Ontology Overview . https://www.palantir.com/docs/foundry/ontology/overview
03 Microsoft Learn, What Is Ontology (Preview)? - Microsoft Fabric . По состоянию на 27 августа 2026 года функция отмечена как preview. https://learn.microsoft.com/en-us/fabric/iq/ontology/overview
04 Palantir, Action types - Overview . https://www.palantir.com/docs/foundry/action-types/overview
05 Palantir, Ontology design: Best practices . https://www.palantir.com/docs/foundry/ontology/ontology-best-practices
06 Palantir, Ontology design: Anti-patterns . https://www.palantir.com/docs/foundry/ontology/ontology-anti-patterns
07 Palantir, Why create an Ontology? https://www.palantir.com/docs/foundry/ontology/why-ontology
08 Palantir, Ontology MCP - Overview . https://www.palantir.com/docs/foundry/ontology-mcp/overview
Дополнительные официальные материалы для проверки терминов:
Palantir, The Ontology system : https://www.palantir.com/docs/foundry/architecture-center/ontology-system
Palantir, Ontology MCP sample architecture : https://www.palantir.com/docs/foundry/ontology-mcp/sample-architecture
Microsoft Learn, Create Entity Types - Ontology : https://learn.microsoft.com/en-us/fabric/iq/ontology/how-to-create-entity-types
W3C, OWL Semantic Web Standards : https://www.w3.org/OWL/
В материале
00 Компания хранится в системах, но работает объектами
01 Что такое онтология простыми словами
02 От таблиц к объекту «Клиент»
03 Из чего состоит онтология
04 Чем онтология не является
05 Зачем онтология AI-агентам
06 Онтология и RAG работают вместе
07 Как такой слой выглядит в контуре Comb
08 Как начать без проекта на несколько лет
09 Где онтологии ломаются
10 Цена и ограничения
11 Почему тема вернулась именно сейчас
Следующая статья: AGENTS.md для бизнеса: управляющий слой AI-сотрудника