Зміст
Вступ
Референтна архітектура корпоративної платформи ШІ — не готове креслення, яке можна розгорнути в будь-якій компанії. Вона визначає розподіл відповідальності: де живуть дані, як із них формується контекст, хто керує діями агентів і як безпека працює на кожному рівні.
Це підсумкова рамка серії. Її цінність не в переліку продуктів, а у здатності поєднати бізнес-завдання, знання й технології в систему, яка зберігає керованість за зміни моделей, постачальників і сценаріїв.
Чому це важливо
Без спільної архітектури підприємство швидко отримує набір не пов’язаних між собою помічників. Кожен зберігає власну копію документів, дублює інтеграції та по-своєму тлумачить права доступу. Такі сервіси можуть давати локальну користь, але їхня вартість і ризики зростають швидше за можливості.
Платформний підхід дозволяє сценаріям розвиватися незалежно. Новий підрозділ отримує спільні правила роботи зі знаннями, пошуком, безпекою та спостережуваністю, а не ще один ізольований чат. Це зменшує дублювання й робить інвестиції у фундамент корисними для багатьох процесів.
Основне пояснення
У центрі архітектури перебувають корпоративні знання, а не 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
Такий поділ дає змогу замінити модель, розширити індекс або підключити новий застосунок без перебудови всієї системи. Проте шари не мають залишатися абстракцією на схемі: для кожного потрібні власник, інтерфейс, показники якості та порядок змін.
Безпека
Безпека є наскрізним принципом, а не окремим сервісом поруч із моделлю. Права доступу слід успадковувати з корпоративного контуру та застосовувати під час пошуку, формування контексту й виконання дій агентом. Користувач з обмеженими правами не повинен отримувати документ лише тому, що він потрапив до векторного індексу.
| Компонент | Обов’язкова вимога |
|---|---|
| Доступ користувача | Корпоративна автентифікація та ролі |
| Шар знань | Збереження прав, класифікації та версій |
| RAG | Пошук лише за дозволеними джерелами |
| Агенти | Дії суворо в межах наданих повноважень |
| LLM | Ізольоване розміщення та контрольовані оновлення |
| Спостережуваність | Аудит дій без нового каналу витоку |
Архітектура має враховувати спроби додати шкідливі інструкції через документи, чутливі дані в журналах і надмірні повноваження агентів. Перевірка вмісту, обмежені інструменти, маскування полів і регулярний аналіз подій безпеки є обов’язковими заходами.
Корпоративний приклад
Інженерний холдинг створює єдину платформу для проєктних підрозділів, служби промислової безпеки, експлуатації та центру компетенцій. Підрозділи мають різні робочі процеси, проте використовують спільні служби ідентифікації, пошуку, інтеграції та аудиту.
Проєктувальник отримує допомогу під час роботи з технічною документацією, фахівець з експлуатації — зведення з історії обладнання, а експерт — добірку нормативних підстав. Кожна можливість розвивається окремо, але не створює ізольовану базу знань чи власну модель доступу.
Приклад з промислової безпеки
Експерт готує висновок щодо небезпечного виробничого об’єкта. Платформа отримує актуальні відомості із системи управління ресурсами підприємства, знаходить чинні нормативні документи, зіставляє архівні висновки та результати обстежень, а потім формує чернетку з обов’язковими посиланнями на джерела.
Експерт перевіряє матеріали, вносить корективи й ухвалює остаточне рішення. ШІ скорочує час пошуку, робить знання доступнішими та допомагає помічати суперечності, але не замінює інженерну оцінку й не ухвалює рішення в регульованому процесі.
Типові помилки
- Будувати всю архітектуру навколо однієї моделі або постачальника.
- Дублювати дані між компонентами без чіткої ролі та власника.
- Не залучати бізнес-підрозділи до визначення сценаріїв і показників.
- Відокремлювати безпеку від пошуку, агентів і джерел знань.
- Не визначати власників шарів, інтерфейсів і процедур змін.
- Вважати моніторинг інфраструктури достатньою спостережуваністю платформи.
Практичні висновки
Починайте проєктування цільової платформи з карти бізнес-сценаріїв і джерел знань. Далі визначте межі шарів, відповідальних і правила інтеграції. Конкретні моделі та продукти обирайте лише після цих рішень.
- Визначте системи-джерела та правила володіння даними.
- Створіть єдиний шар знань із метаданими, версіями та правами доступу.
- Розділіть пошук і RAG, оркестрацію, моделі та користувацькі застосунки.
- Вбудуйте аудит, керування доступом і спостережуваність у всі шари.
- Установіть показники якості пошуку, відповідей, безпеки та бізнес-ефекту.
- Розгортайте рішення поетапно: від перевірюваного сценарію до платформного стандарту.
Ключові тези
- Корпоративний ШІ — це платформа знань, а не одна LLM.
- Бізнес-завдання та джерела істини визначають архітектуру раніше за моделі.
- Поділ на шари дає компонентам змогу розвиватися незалежно.
- Безпека й спостережуваність мають охоплювати всю платформу.
- ШІ посилює експерта, а відповідальність за рішення залишається за людиною.