Содержание
Введение
Успешный пилот корпоративного ИИ доказывает ценность одного сценария, но ещё не создаёт платформу. После пилота архитектору нужно связать бизнес-задачи, знания, процессы, безопасность и корпоративные системы в основу, которую можно расширять без постоянной переделки.
Главный вопрос этого этапа — не какую технологию выбрать первой. Важно определить, как разные подразделения будут безопасно использовать общие знания и сервисы, сохраняя ответственность за данные в исходных системах.
Почему это важно
Если каждое подразделение получает отдельный чат-бот, индекс документов и интеграции, предприятие быстро собирает набор несвязанных решений. Их сложно сопровождать, права доступа расходятся, а одни и те же данные приходится готовить несколько раз.
Целевая архитектура задаёт общий каркас. Она позволяет повторно использовать слой знаний, поиск, управление доступом и наблюдаемость, оставляя каждому подразделению свои сценарии и интерфейсы.
Основное объяснение
Корпоративную ИИ-платформу удобно разделить на логические слои: пользовательские приложения, агенты и оркестрацию, поиск и RAG, языковые модели, слой знаний, интеграции и исходные информационные системы.
flowchart TD
users[Пользователи] --> apps[Приложения и агенты]
apps --> search[Поиск и RAG]
apps --> models[Языковые модели]
search --> knowledge[Слой корпоративных знаний]
knowledge --> integrations[Интеграции]
integrations --> erp[Система управления ресурсами]
integrations --> ecm[Документооборот]
integrations --> archives[Файловые архивы]
Каждый слой отвечает за собственную задачу. Системы управления ресурсами предприятия, СЭД и другие системы остаются владельцами данных. Слой знаний объединяет разрешённые источники в понятную для поиска модель. RAG находит контекст, модель интерпретирует его, а агент выполняет только разрешённую последовательность действий.
Безопасность
| Слой | Основное требование |
|---|---|
| Пользовательские приложения | Аутентификация и роли |
| Агенты | Ограничение доступных действий |
| Поиск и RAG | Поиск только по разрешённым источникам |
| Интеграции | Защищённые интерфейсы обмена |
| Источники | Сохранение исходной модели доступа |
| Наблюдаемость | Журналирование и аудит |
Безопасность нельзя перенести в один шлюз перед моделью. Проверка прав, границы действий и аудит должны действовать во всех слоях, включая поиск и обращения к корпоративным системам.
Корпоративный пример
Инженерный холдинг хочет применять ИИ в проектном офисе, службе промышленной безопасности и инженерных подразделениях. Вместо трёх независимых решений команда создаёт общий слой знаний, единый поиск, централизованное управление доступом и стандартизированные интеграции.
Подразделения получают разные рабочие сценарии, но не дублируют документы, индексы и правила безопасности. В дальнейшем к этой основе можно подключать новые модели и приложения, не меняя владельцев данных.
Пример из промышленной безопасности
Эксперт готовит заключение по опасному производственному объекту. Платформа получает разрешённые сведения из системы управления ресурсами, находит нормативные документы и похожие архивные заключения, а затем собирает их в единое рабочее пространство.
Каждое обращение проходит проверку полномочий. Платформа ускоряет поиск и подготовку материалов, но эксперт проверяет источники, формулирует выводы и несёт ответственность за итоговое заключение.
Типичные ошибки
- Создавать отдельную архитектуру для каждого подразделения.
- Подключать модель напрямую к корпоративным системам.
- Дублировать корпоративные данные в нескольких сервисах.
- Не разделять ответственность между слоями платформы.
- Откладывать требования к масштабированию и безопасности.
Практические выводы
Результатом проектирования должна стать базовая архитектурная схема: логические слои, источники знаний, интеграции, модель безопасности, требования к нагрузке и правила развития платформы.
Начинайте с общего стандарта, который достаточно мал для первого внедрения, но предусматривает повторное использование сервисов. Тогда новые сценарии будут расширять платформу, а не создавать очередной изолированный продукт.
Ключевые тезисы
- Архитектура платформы важнее выбора отдельной технологии.
- Источники данных сохраняют роль владельцев информации.
- Каждый слой имеет ограниченную и понятную ответственность.
- Безопасность распределяется по всей архитектуре.
- Платформа должна развиваться без полной переработки.