Что скрывается за AI-стратегией SAP, Oracle и Palantir: зачем корпоративному ИИ семантическое ядро

В корпоративном ИИ происходит тихий сдвиг. На поверхности его видно как очередную волну разговоров про агентов, RAG, knowledge graph, ontology, process intelligence, AI‑ready data, business context и agentic platforms. SAP говорит о графе знаний для агентов, Microsoft — о переходе от systems of record к systems of action, Oracle — об агентах внутри корпоративных приложений, Palantir — об Ontology, Celonis — о Process Intelligence Graph, Alibaba и Yonyou — о корпоративных агентных платформах.

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

Если в компании слово «заказ» в производстве, снабжении, финансах и продажах означает разные вещи; если статус живёт в комментарии; если справочник считается «данными», но не объясняет предметную область; если Excel спорит с ERP, то LLM получает не предприятие, а набор фрагментов. А потом мы удивляемся, что ответы разные, выводы плавают, а агент уверенно действует в тумане.

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

Мировые вендоры не верят в голую LLM над хаосом

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

SAP развивает граф знаний и бизнес‑облако данных вокруг своих агентов. Microsoft говорит уже не просто о системах регистрации, а о системах действия. Oracle встраивает AI Agents в корпоративные приложения и развивает тему данных, пригодных для ИИ. Palantir много лет строит линию Ontology как операционного представления предприятия. Celonis говорит о Process Intelligence Graph, который связывает события, процессы, KPI и бизнес‑контекст. Alibaba и Yonyou идут к корпоративным агентным платформам, где важны не только модели, но и маршруты, API, права доступа, безопасность и совместная работа агентов.

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

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

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

Почему вопрос не только в модели

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

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

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

Если этот контекст не задан явно, LLM восстанавливает его сама. Иногда удачно. Иногда опасно. И чем серьёзнее задача, тем меньше хочется полагаться на удачное угадывание.

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

Слово не равно термину

LLM хорошо работает со словами. Но предприятие работает не просто словами, а терминами.

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

В обычном разговоре можно сказать «партия», «заказ», «план», «остаток», «потребность» и надеяться, что собеседник поймёт. В корпоративной ИИ‑системе так делать рискованно. Модель может выбрать смысл по статистической вероятности, а не по правилам конкретного предприятия.

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

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

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

Термин не равен предмету

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

Возьмём «заказ на производство». Это может быть название документа в ERP, управленческое обязательство перед производством, основание для потребности в материалах, элемент производственного плана, строка в отчёте или тема обсуждения на планёрке.

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

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

Именно на этом уровне корпоративный ИИ начинает отличаться от обычного чат‑бота над документами.

Предмет не равен экземпляру

Класс объекта и конкретный экземпляр объекта — разные сущности. Если их не различать, ИИ начинает путать правило и случай.

«Номенклатура» как класс и конкретная позиция номенклатуры — разные уровни. «Заказ поставщику» как тип документа и заказ № 456 от 15 мая — разные сущности. «Склад» как объект учёта и конкретный склад материалов — тоже разные сущности.

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

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

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

Строка в таблице ещё не факт

Строка в Excel, ERP‑отчёте или выгрузке сама по себе ещё не является управленческим фактом. Она становится фактом только вместе с источником, временем, статусом, владельцем и правилом интерпретации.

Допустим, в таблице написано: остаток — 100 штук. На первый взгляд всё понятно. Но для управленческого ответа этого недостаточно.

На каком складе этот остаток? На какую дату? Он доступен или зарезервирован? Это физический остаток, бухгалтерский остаток или доступный к использованию остаток? Есть ли блокировка по качеству? Данные пришли из ERP, Excel, внешней системы или ручного комментария? Кто владелец этих данных? Когда они обновлялись?

Та же история с другими показателями. «Потребность = 80» — это под какой заказ, на какой срок, подтверждённая или расчётная? «Просрочка = 5 дней» — по какому обязательству, кто владелец, есть ли согласованная отсрочка? «Себестоимость = 1200» — плановая, фактическая, нормативная, за какой период и по какой методике?

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

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

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

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

Это не так.

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

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

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

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

RAG не равен памяти предприятия

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

Но RAG отвечает прежде всего на вопрос: что найти в корпусе документов? Семантическое ядро отвечает на другой вопрос: что найденные фрагменты означают в системе предприятия?

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

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

Это не делает RAG плохим. Это просто показывает его границу. Поиск контекста не заменяет архитектуру смысла.

Агент не равен архитектуре предприятия

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

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

Агенту нужны инструменты. Инструментам нужны права. Правам нужны роли. Ролям нужны границы ответственности. Действиям нужны статусы и правила подтверждения. Без этого агент становится ускорителем хаоса.

Например, агент может подготовить заказ поставщику. Но можно ли ему выбрать поставщика? Изменить цену? Согласовать срок? Отправить заказ? Изменить резерв? Создать обязательство? Уведомить производство? Запустить эскалацию?

Ответ зависит не от модели, а от архитектуры ролей, прав, статусов, бизнес‑процесса и правил контроля.

Поэтому вопрос не в том, нужен ли агент. Вопрос в том, в какую предметную и организационную систему он встроен.

Что я называю семантическим ядром предприятия

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

В это ядро входят термины, объекты, экземпляры, атрибуты, статусы, события, роли, источники данных, связи мэппинг и правила качества. Не обязательно всё это должно жить в одном большом монолитном графе. В разных организациях такой слой может быть собран через data catalog, knowledge graph, онтологию, процессную модель, доменные витрины, корпоративный словарь, MDM, систему качества НСИ, правила мэппинга, регламенты или комбинацию этих инструментов.

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

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

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

Где место глубокого обучения

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

Но deep learning не заменяет семантическое ядро предприятия.

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

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

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

Мини‑пример: почему остаток растёт, а дефицит остаётся

Представим, что руководитель спрашивает ИИ: почему складской остаток растёт, а производство всё равно жалуется на дефицит?

Плохой вход — просто выгрузка остатков.

Формально модель видит данные. Но для ответа ей не хватает смысла.

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

Если дать доменный срез, ситуация меняется.

Теперь ИИ может не просто сказать «остаток есть», а объяснить противоречие: физический остаток не равен доступному остатку, потому что большая часть зарезервирована или не прошла нужный статус. Дальше уже можно обсуждать варианты действия: проверить резерв, найти замену, ускорить поставку, пересмотреть план, поднять эскалацию.

Качество ответа изменилось не потому, что модель стала «умнее». Изменился вход: вместо строки данных она получила предметно объяснённый доменный срез.

Почему это важно именно сейчас

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

Но следующий этап уже виден. ИИ начинают подключать к процессам, задачам, ERP, CRM, документообороту, финансам, закупкам, производству и управленческой аналитике. Там ошибка меняет класс. Это уже не «неудачный текст», а неправильное действие, неверный приоритет, ложная картина риска, ошибочный прогноз, некорректная эскалация.

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

Мировые вендоры потому и строят knowledge graph, ontology, process intelligence graph, business data cloud и agentic platforms, что голая языковая модель над хаосом не даёт устойчивого корпоративного результата.

Вывод

Есть ещё один вывод, который пока лучше оставить как вопрос, а не как окончательный ответ. Возможно, за всем этим движением — knowledge graph, ontology, process intelligence graph, business data cloud, agent memory и agentic platforms — стоит не просто развитие набора полезных ИИ‑функций. Возможно, крупные вендоры начинают собирать новый класс корпоративных систем: интеллектуальное предприятие, которое не только отвечает на вопросы, но и помогает собрать комплексную сбалансированную управленческую позицию для действия.

Что это означает на практике — тема отдельной статьи. Здесь важно зафиксировать более ранний слой: такая система невозможна, если предприятие не объяснило машине собственные термины, объекты, статусы, источники, связи и правила качества.

Корпоративный ИИ начинается не с выбора модели и не с подключения агента к ERP. Это важные шаги, но они не первые.

Первый шаг — сделать предприятие понятным для машины и проверяемым для человека.

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

Модель может отвечать. RAG может находить. Агент может действовать. ERP может хранить транзакции. Deep learning может находить закономерности.

Но предприятие должно сначала объяснить, что именно всё это означает.

Что почитать по теме

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

• SAP Joule Agents и SAP Knowledge Graph — линия агентов, бизнес‑контекста и графа знаний.

• Microsoft Dynamics 365: systems of record → systems of action — переход от систем регистрации к системам действия.

• Oracle AI Agents for Fusion Applications — агенты, встроенные в корпоративные приложения и бизнес‑процессы.

• Oracle AI Data Platform и материалы про agent memory — данные и память для корпоративного ИИ.

• Palantir Ontology — операционная онтология предприятия как модель реального мира для людей и ИИ.

• Celonis Process Intelligence Graph — процессный интеллект, KPI, правила и цифровой двойник операций.

• Alibaba Wukong и Yonyou BIP 5 — корпоративные агентные платформы, API, права доступа, workflow и multi‑agent teamwork.

• Gartner / Reuters по рискам agentic AI projects — почему агент сам по себе не гарантирует результата.

Вопрос к читателям

Как вы сейчас решаете в корпоративных ИИ‑проектах проблему терминов и предметной области: через RAG, онтологии, справочники, data catalog, process mining, ручные промпты — или этот слой пока обычно остаётся «в голове у экспертов»?

И второй вопрос шире: не кажется ли вам, что за knowledge graph, ontology, process intelligence graph, business data cloud и agentic platforms у крупных вендоров стоит не просто развитие набора полезных ИИ‑функций, а попытка собрать новый класс корпоративных систем — интеллектуальное предприятие, которое не только отвечает на вопросы, но и собирает комплексную сбалансированную управленческую позицию для действия?