Что делает IBP-платформу AI-ready: 7 признаков зрелой архитектуры

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

Термин AI-ready всё чаще появляется в описаниях корпоративных систем. Вендоры открывают SDK, готовят MCP-серверы, добавляют AI-ассистентов и инструменты для разработки с помощью искусственного интеллекта.

Всё это действительно расширяет возможности платформы. Открытый SDK упрощает интеграцию, MCP даёт современным AI-инструментам стандартный способ взаимодействия с корпоративными системами, а генеративный ИИ заметно ускоряет разработку.

SDK (Software Development Kit) – набор инструментов для разработки и интеграции. MCP (Model Context Protocol) – протокол, через который AI-приложения взаимодействуют с внешними инструментами и источниками данных. Оба механизма полезны, но сами по себе не подтверждают безопасность и зрелость AI-архитектуры.

Но для крупной компании этого недостаточно.

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

Поэтому AI-ready – не наличие отдельного чат-бота и не поддержка конкретной LLM. Это способность платформы предоставить ИИ бизнес-контекст, инструменты и управляемые границы действий.

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

В контексте IBP (Integrated Business Planning, интегрированного бизнес-планирования) AI-ready означает готовность системы не только отвечать на вопросы, но и работать с актуальными данными планирования, ограничениями бизнес-модели и правилами компании. Проверять эту готовность следует на реальных задачах, а не по наличию AI-ассистента в интерфейсе.

1. ИИ доступен контекст бизнеса, а не только набор документов

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

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

Даже сильная LLM без этого контекста будет давать общие ответы.

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

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

В Knowledge Space AI-агента уже сегодня можно подключать к контексту конкретного проекта – документации, базе знаний, файлам и таблицам, схемам и инструкциям.

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

2. Архитектура не привязана к одной AI-модели или поставщику

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

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

Одной компании понадобится локальная LLM. Другой – внешний AI-сервис. Третьей – собственная модель машинного обучения. Где-то ресурсоёмкий расчёт логичнее оставить во внешнем вычислительном контуре, а в платформе сохранить пользовательскую работу и управление процессом.

Поэтому зрелая AI-ready платформа должна уметь работать с разными архитектурными комбинациями.

Knowledge Space поддерживает несколько архитектурных вариантов:

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

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

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

3. Платформа должна задавать ИИ правила работы

Один из главных рисков корпоративного ИИ связан даже не с известными «галлюцинациями».

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

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

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

Поэтому платформа нужна ИИ ещё и как система координат.

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

Именно такой подход позволяет постепенно расширять полномочия AI-агентов: сначала дать им доступ к информации, затем – к отдельным действиям, сохраняя ограничения корпоративной системы.

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

4. Нужен полноценный жизненный цикл разработки

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

Для корпоративного решения после этого работа только начинается.

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

AI-ready платформа должна поддерживать полноценный жизненный цикл разработки: тестирование, перенос изменений, версионирование и сопровождение.

В Knowledge Space уже используются Git-подход, история изменений, частичный перенос изменений и мониторинг вычислений. В платформе также развивается горизонтальное масштабирование расчётов и инструментарий CI/CD.

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

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

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

5. AI-ready нужно проверять на реальных объёмах данных

Прототип AI-решения можно собрать на небольшой выборке практически в любой современной среде.

IBP работает в другом масштабе.

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

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

В одном из тестовых кейсов Knowledge Space по планированию спроса модель включает 6 тыс. SKU, 4 тыс. клиентов и 124 недели истории. Тестовый набор содержит 24 млн значений; стенд работал на инфраструктуре с 5 CPU и 14 ГБ RAM.

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

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

Именно на этом уровне начинает проявляться разница между AI-демонстрацией и промышленным корпоративным решением.

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

6. ИИ должен встраиваться в бизнес-процесс

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

Часть из них производит сильное первое впечатление, но затем практически не используется.

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

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

Именно из этих четырёх частей – модель, интерфейс, интеграции и управление процессом – складываются решения на Knowledge Space.

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

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

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

7. ИИ должен участвовать в развитии решений на платформе

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

В Knowledge Space уже есть интеграционный модуль, который позволяет включать AI-сервисы в цепочку обработки данных: передавать им запрос или событие, получать результат и использовать его на следующем этапе процесса. ИИ также применяется командой KS при разработке отдельных расчётных сервисов.

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

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

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

Как проверить AI-ready платформу на пилоте

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

Частые вопросы об AI-ready IBP

Достаточно ли встроенного чат-бота, чтобы считать IBP-платформу AI-ready?

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

Нужна ли IBP-системе собственная языковая модель?

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

Какие метрики нужно оценить на пилоте AI-агента?

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

AI-ready – свойство всей платформы, а не отдельной AI-функции

Открытый Python SDK облегчает работу разработчиков, а MCP даёт AI-агентам стандартный способ взаимодействия с корпоративными инструментами. Это важные элементы современной технологической архитектуры.

Но промышленное применение ИИ требует большего. Нужно понимать:

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

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

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

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

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