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

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

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

Основное объяснение

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

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

flowchart TB
  users[Пользователи] --> apps[Корпоративные приложения и агенты]
  apps --> orchestration[Оркестрация]
  orchestration --> rag[RAG и поиск]
  orchestration --> llm[LLM]
  rag --> knowledge[Слой корпоративных знаний]
  knowledge --> erp[Планирование ресурсов]
  knowledge --> ecm[Документооборот]
  knowledge --> plm[PLM]
  knowledge --> archives[Архивы и порталы]
  security[Безопасность и аудит] --- apps
  security --- rag
  security --- knowledge
  observability[Наблюдаемость] --- orchestration
  observability --- llm

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

Безопасность

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

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

Корпоративный пример

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

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

Пример из промышленной безопасности

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

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

Типичные ошибки

1. Строить всю архитектуру вокруг одной модели или одного поставщика.
2. Дублировать данные между компонентами без ясной роли и владельца.
3. Исключать бизнес-подразделения из определения сценариев и показателей.
4. Отделять безопасность от поиска, агентов и источников знаний.
5. Не определять владельцев слоев, интерфейсов и процедур изменений.
6. Считать мониторинг инфраструктуры достаточной наблюдаемостью платформы.

Практические выводы

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

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

Ключевые тезисы

• Корпоративный ИИ — платформа знаний, а не одна LLM.
• Бизнес-задачи и источники истины определяют архитектуру раньше моделей.
• Разделение слоев позволяет развивать компоненты независимо.
• Безопасность и наблюдаемость обязаны охватывать весь контур.
• ИИ усиливает эксперта, сохраняя за человеком ответственность за решение.