Что такое архитектор AI-платформы? Модели, данные, среда выполнения, безопасность и операции
Архитектор AI-платформы проектирует переиспользуемую основу для ИИ, через которую множество приложений, команд или контекстов арендаторов получают доступ к моделям, данным и поиску, средам выполнения агентов и инструментов, идентификации и разрешениям, оценке, наблюдаемости, квотам, секретам и возможностям развёртывания. Эта роль шире, чем инфраструктура, но уже, чем владение каждым продуктом с поддержкой ИИ: её центральная ответственность — решать, что должно быть общим, как общие возможности управляются и изолируются, и что должно оставаться специфичным для конкретного решения.
Что на самом деле проектирует архитектор AI-платформы?
Объектом работы является платформа: набор общих возможностей, который сокращает повторяющуюся работу по интеграции, сохраняя при этом явные границы безопасности, данных и эксплуатации. Платформа может предоставлять множеству потребляющих решений доступ к моделям, адаптеры провайдеров, примитивы поиска, выполнение агентов, брокеры инструментов, применение политик, оценку, телеметрию и сервисы развёртывания.
Платформа ценна не просто потому, что её компоненты централизованы. Она ценна, когда потребители получают стабильные возможности с чёткими контрактами, ответственностью, изоляцией, наблюдаемостью и правилами жизненного цикла. Поэтому ключевой архитектурный вопрос не «Какую модель должны использовать все?», а «Какие обязанности можно безопасно стандартизировать и переиспользовать, не стирая требования каждого решения?».
Архитектура решения и архитектура платформы решают разные задачи по охвату
| Архитектор AI-решения | Архитектор AI-платформы | |
|---|---|---|
| Основной охват | One concrete AI-enabled product, workflow or application. | Reusable AI capabilities consumed by multiple solutions, teams or tenant contexts. |
| Главный вопрос | How should this solution meet its business, data, security, quality and operational requirements? | Which shared capabilities and controls should solutions consume, and where must solution-specific ownership remain? |
| Ответственность за данные | Defines which domain data is authoritative and how the solution may use it. | Provides storage, retrieval, provenance or access primitives without automatically becoming the authority for every domain. |
| Оценка | Defines task-specific quality and acceptance criteria. | Provides reusable evaluation, telemetry and release mechanisms; it cannot define every domain's success threshold. |
| Жизненный цикл | Owns the lifecycle of the specific workload. | Owns shared capability versions, compatibility, onboarding, quotas, policy and operational contracts. |
Простейший пример
Представьте, что в организации есть пять продуктов с поддержкой ИИ: внутренний ассистент по документам, копилот службы поддержки клиентов, агент для разработки программного обеспечения, рабочий процесс проверки договоров и ассистент поиска по товарам. Каждый продукт мог бы независимо интегрировать API моделей, хранить учётные данные, реализовывать повторные попытки, собирать метрики токенов, создавать код поиска и строить собственные разрешения для инструментов.
Такое дублирование дорого и опасно, когда каждая команда изобретает свою модель безопасности и эксплуатации. Общая платформа вместо этого может предлагать одобренные подключения к провайдерам, обнаружение моделей, квоты, учётные данные, доступ с учётом арендатора, общую телеметрию, переиспользуемые сервисы поиска и контракт среды выполнения агентов и инструментов.
Но платформа должна остановиться на правильной границе. Решение для проверки договоров может требовать полномочий по юридическим документам и правил цитирования, которых нет у программного агента. Ассистенту поиска по товарам могут понадобиться специфичные для торговли правила актуальности и авторизации. Переиспользуемая инфраструктура не делает всю предметную истину переиспользуемой.
Общий путь AI-запроса
Где заканчивается простой пример
Централизация не является автоматически архитектурой. Единая точка входа перед несколькими API моделей полезна, но сама по себе она не создаёт AI-платформу. Производственной платформе также нужны границы идентичности, контракты возможностей, обработка работоспособности и жизненного цикла провайдеров, квоты, ответственность за секреты, наблюдаемость, правила совместимости, средства безопасности, дисциплина выпуска и чёткая эксплуатационная ответственность.
Противоположная ошибка также распространена: поместить каждый промпт, векторный индекс, бизнес-правило, агента и рабочий процесс приложения в один «AI-бэкенд». Это создаёт монолит, общий статус которого случаен, а не архитектурен. Платформа должна стандартизировать сквозные возможности, а не поглощать предметную ответственность только потому, что задействован ИИ.
Самое важное решение платформы: общее или специфичное для решения
| Область возможностей | Хороший кандидат для общей ответственности платформы | Обычно остаётся специфичным для решения |
|---|---|---|
| Доступ к моделям | Одобренные подключения к провайдерам, адаптеры, учётные данные, проверка работоспособности, примитивы маршрутизации, квоты | Приёмка моделей для конкретных задач, поведение промптов, порог качества |
| Извлечение данных | Примитивы загрузки, извлечение, индексирование, API поиска, контракты происхождения, хуки авторизации | Авторитетный корпус, правила актуальности, доменные метаданные, достаточность доказательств |
| Агенты и инструменты | Жизненный цикл среды выполнения, реестр/брокер инструментов, обеспечение разрешений, трассировка, отмена | Бизнес-процесс, семантика разрешённых действий, политика эскалации, успех задачи |
| Безопасность | Интеграция удостоверений, хранение секретов, обеспечение политик, контракты аудита, механизмы изоляции арендаторов | Классификация данных, правила бизнес-авторизации, принятие рисков для конкретной области |
| Оценка | Стенд, механика версионирования наборов данных, телеметрия, рабочий процесс экспериментов/релизов | Эталонные данные, доменный тестовый набор, порог приёмки, результат для пользователя |
| Операции | Шаблон развёртывания, работоспособность, метрики, интеграция с инцидентами, управление мощностями | SLO решения, если они различаются, влияние на непрерывность бизнеса, runbook'и для конкретных нагрузок |
Карта архитектурной ответственности
1. Доступ к моделям и провайдерам
Архитектор платформы определяет, как потребители обнаруживают и вызывают модели, не заставляя каждое приложение жёстко кодировать одного провайдера. Это включает адаптеры провайдеров, идентификаторы моделей, метаданные возможностей, аутентификацию, проверки работоспособности, конфигурацию конечных точек, нормализацию запросов и поведение совместимости.
Абстракция провайдера должна оставаться честной. Разные провайдеры предоставляют разные ограничения контекста, семантику инструментов, поведение структурированного вывода, мультимодальные возможности, средства безопасности, кэширование, ценообразование и режимы отказа. Хорошая абстракция создаёт стабильный контракт платформы, сохраняя доступ к возможностям, которые нельзя осмысленно свести к общему знаменателю.
2. Шлюз, маршрутизация, квоты и контроль затрат
Общий AI-шлюз может централизовать аутентификацию, маршрутизацию, ограничение скорости, повторные попытки, лимиты токенов, атрибуцию использования и обеспечение политик. Текущее руководство Microsoft по AI Gateway явно рассматривает лимиты токенов в минуту, квоты и изоляцию нескольких проектов как задачи платформы; AWS аналогично предоставляет квоты на аккаунт и модель и централизованные средства контроля.
Таким образом, шлюз — это больше, чем обратный прокси, когда он несёт специфичную для ИИ политику и операционную семантику. Но он не должен молча принимать бизнес-решения. Политика маршрутизации может предпочитать работоспособную локальную модель, более дешёвого провайдера или регионально совместимую конечную точку; однако приемлемость этого маршрута для конкретной задачи всё ещё остаётся контрактом между платформой и решением.
Маршрутизация также требует семантики отказов. Если предпочтительная модель недоступна, платформа должна знать, разрешён ли резервный вариант, требует ли облачный маршрут явного согласия, допустима ли модель с меньшими возможностями и как это решение отображается в наблюдаемости.
3. Общие данные, извлечение и сервисы обоснования
Сервисы извлечения данных — сильные кандидаты для платформы, потому что разбор, разбиение на фрагменты, индексирование, лексический поиск, семантический поиск, фильтрация метаданных, происхождение и механика цитирования переиспользуемы. Однако платформа не должна путать общий движок извлечения с общим источником истины.
Решение всё ещё владеет такими вопросами: какой корпус является авторитетным? Какая версия действительна? Может ли этот пользователь видеть этот документ? Насколько свежими должны быть данные? Что считается достаточным доказательством? Можно ли сгенерировать ответ, если извлечение не удалось? Это требования домена и решения, даже когда платформа предоставляет механизм извлечения.
Эта граница особенно важна в мультитенантных системах. Технически общий индекс или векторный сервис не оправдывает кросс-тенантную видимость. Контекст авторизации должен сохраняться через извлечение, а не добавляться только после того, как результаты поиска уже пересекли границу.
4. Среда выполнения агентов и инструментов
Агентные системы добавляют переиспользуемые задачи среды выполнения: жизненный цикл потока/сессии, циклы планирования, регистрация инструментов, вызов инструментов, отмена, тайм-ауты, одобрения человеком, интерфейсы памяти/состояния, протоколы удалённых агентов и корреляция трассировок. Платформа может предоставить эти механизмы, чтобы каждый продукт не пересобирал их заново.
Платформа также должна отделять разрешения инструментов от возможностей модели. То, что модель способна сгенерировать команду оболочки, не означает, что среда выполнения должна разрешать выполнение оболочки. Граница разрешений принадлежит архитектуре приложения/среды выполнения и должна обеспечиваться независимо от модели.
Текущие рекомендации AWS по агентному ИИ подчеркивают ограниченных агентов, явные полномочия, сквозную трассировку, версионированные артефакты поведения и человеческий надзор, соразмерный последствиям. Это вопросы, обеспечивающие работу платформы, но потребляющее решение всё ещё определяет, какие действия являются законными для его домена.
5. Идентификация, изоляция арендаторов и авторизация
Платформы ИИ часто находятся перед высокоценными моделями, проприетарными данными и инструментами, способными выполнять действия. Поэтому аутентификация — это только начало. Архитектура должна передавать контекст пользователя, сервиса, приложения и арендатора через каждую привилегированную операцию, где это необходимо.
RBAC и изоляция арендаторов решают разные задачи. RBAC отвечает на вопрос, что может делать идентичность; изоляция арендаторов отвечает на вопрос, с ресурсами какого арендатора эта идентичность может действовать. Платформа, которая проверяет роли, но теряет контекст арендатора, всё ещё может раскрыть не те данные.
Текущие рекомендации Microsoft по рабочим нагрузкам ИИ явно рекомендуют сегментацию идентичности и доступ к контенту с учётом авторизации. Рекомендации AWS по многопользовательской платформе генеративного ИИ аналогично рассматривают логическую изоляцию, централизованное управление и возможность аудита как вопросы платформы.
6. Секреты, учётные данные и границы доверия
Платформа должна определить, кто владеет ключами провайдера, удалёнными bearer-токенами, материалами для подписи и учётными данными инструментов, где они хранятся, какой процесс может к ним получить доступ, как они ротируются и могут ли они когда-либо попасть в браузер или недоверенный рендерер.
Это архитектурная граница, а не деталь реализации. Если каждое потребляющее приложение копирует учётные данные провайдера в свою собственную конфигурацию, организация дублирует как операционную нагрузку, так и радиус поражения. Централизация может снизить этот риск только в том случае, если сама платформа имеет более узкие, поддающиеся аудиту пути доступа.
7. Оценка, наблюдаемость и возможность аудита
Многоразовая платформа может предоставлять средства оценки, идентификаторы трассировки, метаданные модели/провайдера, метрики токенов и стоимости, задержку, частоту ошибок, связь версий промпта/модели, трассировки агентов/инструментов и контролируемое логирование. AWS и Microsoft рассматривают наблюдаемость и оценку как ключевые производственные вопросы для рабочих нагрузок ИИ.
Оценка платформы и оценка решения должны оставаться раздельными. Платформа может проверить, что конечная точка работоспособна, версия модели проходит общий набор регрессионных тестов и трассировки полны. Она не может решить, что юридический ответ, медицинский рабочий процесс или рекомендация продукта приемлемы без предметно-специфической эталонной истины и критериев приёмки.
Логирование также создаёт границу конфиденциальности. Журналы промптов и ответов могут содержать конфиденциальные или проприетарные данные. Поэтому архитектор платформы должен решить, что логируется, редактируется, сэмплируется, сохраняется и доступно, а не предполагать, что больше телеметрии всегда безопаснее.
8. Среда выполнения, развёртывание и локальность
Архитектор платформы решает, как общие возможности ИИ развёртываются и становятся доступными: управляемые облачные сервисы, самостоятельно размещённые конечные точки, локальный вывод, гибридная маршрутизация, контейнеризированные сервисы, настольные среды выполнения, частные сети или изолированные среды. Важное различие — между тем, где выполняется процесс управления/среды выполнения, и тем, где фактически происходят вывод и обработка данных.
Локальный клиент всё ещё может вызывать облачную модель. Облачная плоскость управления может маршрутизировать к локальной модели. Удалённый агент может выполнять инструменты внутри сети клиента. Поэтому архитектурные диаграммы должны показывать границы доверия и потоков данных, а не использовать «локальный» и «облачный» как расплывчатые ярлыки.
9. Жизненный цикл платформы, совместимость и подключение
Многоразовая возможность становится платформой только тогда, когда потребители могут полагаться на неё с течением времени. Для этого требуются версионированные контракты, правила миграции, политика совместимости, вывод из эксплуатации, тестирование релизов, откат, ответственность за инциденты, планирование мощности, документация и путь для подключения новых команд или приложений.
Быстро развивающиеся экосистемы ИИ делают это особенно важным. Имена моделей, SDK, версии протоколов, API провайдеров и возможности безопасности меняются независимо. Платформа должна поглощать часть этой волатильности, не скрывая изменения, которые существенно влияют на поведение решения.
Практическая модель control-plane / execution-plane / solution-plane
| Уровень | Типичные обязанности | Не должен неявно владеть |
|---|---|---|
| Control plane платформы | Реестр провайдеров, политика моделей, квоты, конфигурация тенантов, идентичности, секреты, правила маршрутизации, версии возможностей, конфигурация развёртывания | Бизнес-логика приложения или доменная истина |
| Execution/data plane платформы | Запросы на инференс, операции поиска, выполнение агентов/инструментов, извлечение, индексация, отправка телеметрии, применение политик | Кросс-тенантный доступ только потому, что инфраструктура общая |
| Solution plane | Пользовательский рабочий процесс, промпты/инструкции, выбор авторитетного корпуса, доменная авторизация, бизнес-правила, оценка и приёмка задач | Низкоуровневая интеграция с провайдерами, которой явно владеет платформа |
Это разделение помогает диагностировать дрейф платформы. Если приложение должно знать все учётные данные и эндпоинты конкретного провайдера, контракт платформы слишком тонкий. Если платформа решает, какая запись клиента юридически авторитетна или приемлем ли доменный ответ, платформа перешла в зону ответственности решения.
Что должен создавать архитектор AI-платформы?
| Архитектурный артефакт | Назначение |
|---|---|
| Карта возможностей платформы | Определяет, что предоставляет платформа, кто это потребляет и какие возможности остаются вне области охвата. |
| Контракт провайдера/модели | Определяет провайдеров, модели, возможности, границы абстракции, метаданные маршрутизации и семантику отката. |
| Модель идентичности и тенантности | Определяет идентичность пользователя/сервиса/приложения, контекст тенанта, точки подключения RBAC/ABAC и изоляцию ресурсов. |
| Политика шлюза и квот | Определяет ограничения скорости, бюджеты токенов/стоимости, управление маршрутизацией, повторные попытки и поведение при нагрузке. |
| Контракт поиска/данных | Определяет приём данных, происхождение, поиск, метаданные, распространение авторизации и то, где остаётся доменная авторитетность. |
| Контракт агента/инструмента | Определяет жизненный цикл среды выполнения, регистрацию инструментов, разрешения, согласования, отмену и поведение трассировки. |
| Модель секретов и границ доверия | Определяет владение учётными данными, хранение, границы процессов, ротацию и пути конфиденциальных данных. |
| Контракт оценки и телеметрии | Определяет общие метрики, трассировки, связи с наборами данных/версиями, политику логирования и точки расширения решения. |
| Политика жизненного цикла и совместимости | Определяет версии, миграции, вывод из эксплуатации, релизы, откат, ответственность за инциденты и адаптацию. |
Работа — это в основном компромиссы, а не максимальная централизация
Типичные компромиссы платформы
| Давление A | Давление B | |
|---|---|---|
| Абстракция провайдера | Stable portable platform API | Access to provider-specific capabilities and fast innovation |
| Повторное использование | Shared services reduce duplication | Isolation and domain autonomy prevent unsafe coupling |
| Управление | Central policy and auditability | Team speed and local experimentation |
| Наблюдаемость | Rich traces for debugging and evaluation | Privacy, data minimization and logging cost |
| Доступность | Fallback and multi-provider resilience | Predictable quality, compliance and data-location guarantees |
| Область охвата платформы | More reusable capabilities | Smaller blast radius and less platform lock-in |
Чем это отличается от смежных ролей?
| Роль | Основная архитектурная область |
|---|---|
| Архитектор AI-решений | Конкретное AI-решение и его сквозные требования, границы, компромиссы и приёмка в продакшене. |
| Архитектор AI-платформы | Переиспользуемые AI-возможности и операционные/безопасностные контракты, потребляемые несколькими решениями или командами. |
| Корпоративный архитектор | Общеорганизационный портфель бизнес/технологий, согласование возможностей и управления на более широком уровне. |
| Архитектор или специалист MLOps / LLMOps | Жизненный цикл моделей и AI, развёртывание, эксперименты, наблюдаемость, релизы и операционные практики; может сильно пересекаться, но не владеет автоматически всей общей платформой приложений. |
| Платформенный инженер / SRE | Реализует и эксплуатирует инфраструктуру платформы, надёжность, автоматизацию и опыт разработчиков; архитектурная ответственность может быть разделена с архитектором платформы. |
| AI / программный инженер | Реализует модели, интеграции, сервисы, агентов, поиск и продуктовую функциональность в рамках согласованной архитектуры. |
Эти границы организационные, а не универсальные. В небольшой команде один человек может нести несколько обязанностей. В регулируемом предприятии они могут быть разделены между группами архитектуры, безопасности, платформы, данных и эксплуатации. Полезное различие — это область архитектурной ответственности, а не должность, напечатанная на организационной схеме.
Доказательства реализации: как эти границы платформы проявляются в моей собственной работе
Aaasaasa AI Client: разделение провайдера, среды выполнения и разрешений
Aaasaasa AI Client — это локальное настольное AI-рабочее пространство, созданное с использованием Nuxt 4, Electron и TypeScript. Его AI Hub намеренно разделяет агента/клиента, провайдера, модель, расположение соединения/среды выполнения, разрешения и веб-клиент, вместо того чтобы рассматривать их как одно значение конфигурации.
Реализация включает прямые адаптеры провайдеров, интеграцию среды выполнения агента Codex, локальные пути Ollama/LM Studio, сервисы, совместимые с OpenAI, централизованные разрешения рабочего пространства, хранение учётных данных в главном процессе, DuckDB, поддержку Qdrant/векторов, извлечение PDF/читаемости и аутентифицированный доступ к каталогам на основе MCP.
Два урока платформы особенно актуальны. Во-первых, локальная среда выполнения — это не то же самое, что локальный инференс: локальный процесс Codex всё ещё может использовать облачную модель. Во-вторых, автоматическая маршрутизация не выполняет неявный откат с локального на платный облачный инференс. Это делает политику маршрутизации и локальность среды выполнения явными, а не выведенными из меток интерфейса.
| Реализованная граница | Значение для архитектуры платформы |
|---|---|
| Агент vs провайдер vs модель | Разные обязанности могут развиваться независимо, вместо того чтобы быть скрытыми за одним селектором «AI». |
| Разрешения отдельно от модели | Полномочия файловой системы/инструментов принадлежат политике среды выполнения, а не возможностям модели. |
| Секреты в главном процессе | Владение учётными данными следует за границей привилегированного процесса, а не за рендерером/интерфейсом. |
| Состояние провайдера и обнаружение моделей | Маршрутизация и доступность — это вопросы среды выполнения/платформы. |
| Никакого неявного облачного отката | Семантика стоимости, локальности и передачи данных остаётся явными политическими решениями. |
Aaasaasa AI CMS: авторизация в рамках тенанта как граница платформы
Кодовая база Aaasaasa AI CMS представляет отдельный пример реализации: RBAC в рамках тенанта реализуется через роли, разрешения и назначения ролей пользователям, привязанные к идентификатору тенанта. Системные разрешения группируются по возможностям, а поиск и обновление ролей остаются в рамках тенанта.
Это само по себе не является доказательством полноценной AI-платформы, но напрямую относится к одной из самых сложных границ общей платформы: переиспользуемый сервис должен сохранять кто что может делать и для какого тенанта. Добавление AI-инференса или поиска поверх прикладной платформы не отменяет этого требования.
Архитектурное следствие состоит в том, что шлюзы моделей, сервисы поиска и агенты должны использовать уже установленный контекст идентичности/тенанта, а не изобретать параллельную вселенную авторизации только для AI.
Source of Truth Research Engine: общая механика поиска без общей истины
Source of Truth Research Engine представляет третий пример реализации. Различные режимы исследования используют общее ядро доказательств: источники, артефакты, происхождение, утверждения, связи, противоречия, эталонную модель и журнал аудита. Система также обеспечивает локальный лексический поиск, опциональный семантический поиск, извлечение, снимки состояния и происхождение на основе SHA-256.
Проект явно рассматривает поиск и семантическое сходство как сигналы для обнаружения, а не как доказательства. Результат должен быть прослежен до конкретного источника и локатора, прежде чем он сможет подтвердить утверждение. Именно это различие необходимо AI-платформе: переиспользуемая механика поиска может быть общей, тогда как авторитет доказательств остаётся под управлением потребляющей методологии и предметной области.
Движок также демонстрирует, почему одна общая платформа не требует одной общей интерпретации. Исторический, научно-технический, рыночно-аналитический и мониторинговый режимы могут переиспользовать базовую инфраструктуру доказательств, сохраняя методологию, специфичную для каждого режима.
Как современные архитектурные руководства поддерживают этот охват платформы
ISO/IEC/IEEE 42010:2022 предоставляет общую дисциплину для описаний архитектуры программного обеспечения, систем, предприятий и связанных сущностей. Он не определяет роль AI Platform Architect, но усиливает необходимость выражать архитектурные concerns, взаимосвязи и точки зрения, а не сводить архитектуру к списку технологий.
NIST AI RMF 1.0 и Generative AI Profile формируют управление рисками AI на протяжении жизненного цикла, а не только на этапе выбора модели. Управление, картирование, измерение и менеджмент поэтому совместимы с архитектурой платформы, которая несёт общие средства контроля и доказательства для множества потребляющих рабочих нагрузок.
Текущее руководство Microsoft по рабочим нагрузкам AI рассматривает проектирование приложений, данные, безопасность, эксплуатацию, тестирование/оценку и GenAIOps как связанные архитектурные области. Его текущее руководство по AI Gateway также показывает практические платформенные concerns, такие как централизованный доступ к моделям, лимиты токенов для конкретных проектов, квоты и изоляцию между командами.
Текущий AWS Generative AI Lens и сценарий мультитенантной платформы аналогично разделяют базовые платформенные средства контроля и ответственность потребляющего приложения. AWS явно отмечает, что центральная платформа может обеспечивать общие guardrails и аудируемость, тогда как качество данных и наблюдаемость, специфичная для рабочей нагрузки, всё ещё остаются ответственностью потребляющих приложений или производителей данных.
Продукты вендоров различаются, но кросс-источниковый паттерн стабилен: производственные AI-платформы должны координировать идентичность, доступ к данным, модели, политику, оценку, наблюдаемость, ёмкость, стоимость и жизненный цикл. Кластер GPU или эндпоинт модели покрывает лишь часть этой ответственности.
Распространённые заблуждения
| Заблуждение | Почему это неверно |
|---|---|
| «AI-платформа — это кластер GPU». | Вычисления — это лишь один субстрат. Платформе также нужны контракты для идентичности, доступа к моделям, данных, политики, оценки, наблюдаемости и жизненного цикла. |
| «AI-шлюз — это просто обратный прокси». | Он также может нести маршрутизацию моделей, квоты токенов, атрибуцию затрат, применение политик, идентичность и телеметрию, специфичную для AI. |
| «Общий означает глобально общий». | Сервис может быть физически общим, но логически сегментированным по тенанту, приложению, региону, классификации или уровню риска. |
| «Одна центральная векторная база данных становится истиной компании». | Векторное хранилище или сервис поиска — это инфраструктура. Предметный авторитет, актуальность, происхождение и доступ остаются отдельными concerns. |
| «Оценка платформы заменяет оценку решения». | Общая регрессия и телеметрия не могут определить, приемлем ли ответ или действие, специфичные для предметной области. |
| «Абстракция провайдера должна скрывать все различия». | Некоторые различия являются существенными возможностями, семантикой безопасности или режимами отказа и должны оставаться видимыми. |
| «RBAC решает мультитенантность». | RBAC управляет действиями; изоляция тенантов управляет границами ресурсов. Может потребоваться и то, и другое. |
| «AI Platform Architect — это просто другое название для MLOps». | MLOps/LLMOps — это крупная пересекающаяся дисциплина, но общие границы приложения/среды выполнения, идентичности, шлюза, поиска и инструментов могут выходить за пределы операций жизненного цикла модели. |
Режимы отказа, которые должен предотвращать AI Platform Architect
| Режим отказа | Архитектурное последствие |
|---|---|
| Каждая команда хранит собственные ключи провайдера | Дублирование обработки секретов, несогласованная ротация и больший радиус поражения. |
| Абстракция провайдера скрывает требуемые возможности | Потребители не могут использовать нужные им функции или незаметно получают поведение, отличное от ожидаемого. |
| Общий поиск игнорирует контекст арендатора/пользователя | Утечка данных за границы может произойти до того, как приложение получит возможность отфильтровать результаты. |
| Резервный вариант незаметно меняет провайдера или локальность | Стоимость, соответствие требованиям, местоположение данных и качество вывода могут измениться без ведома вызывающей стороны. |
| Инструменты агента предоставляются по выбору модели | Мощная модель получает избыточные привилегии, поскольку полномочия времени выполнения не обеспечиваются независимо. |
| Все запросы/ответы журналируются по умолчанию | Наблюдаемость может создать новое хранилище конфиденциальных данных и проблему соответствия. |
| Платформа владеет одной общей оценкой качества | Доменные сбои остаются скрытыми за метриками работоспособности платформы. |
| Нет контракта версий для возможностей платформы | Изменения модели/провайдера/среды выполнения непредсказуемо ломают потребителей. |
| Всё, связанное с ИИ, централизовано | Платформа становится узким местом и монолитом вместо слоя многократно используемых возможностей. |
Практическая последовательность решений по архитектуре платформы
От потребности платформы к эксплуатируемой общей возможности
Краевые случаи и ограничения роли
Небольшой организации с одним ИИ-приложением может не требоваться отдельная ИИ-платформа или архитектор платформы. Преждевременное создание платформы может породить больше абстракции, чем ценности. Правильной архитектурой может быть одно хорошо спроектированное решение с несколькими многократно используемыми модулями.
Изолированное или суверенное развёртывание существенно меняет модель провайдера, обновлений и наблюдаемости. Размещение моделей, распространение артефактов, интеграция идентичности и экспорт телеметрии могут потребовать локальных эквивалентов.
Сильно регулируемые рабочие нагрузки или нагрузки с высокими последствиями могут требовать более сильной физической или организационной изоляции вместо логически общей платформы. Повторное использование никогда не является достаточной причиной ослаблять требуемую границу безопасности.
Управляемые облачные ИИ-сервисы могут снять бремя реализации, но не снимают архитектурную ответственность. Организация по-прежнему решает вопросы идентичности, доступа к данным, журналирования, хранения, квот, допустимости моделей, резервирования, оценки и приёмки решений.
Граница платформы также может различаться по модальности. Текстовый вывод, мультимодальная генерация, речь, использование компьютера и автономные агенты могут иметь разные требования к задержке, данным, разрешениям и наблюдаемости, даже если они используют общую инфраструктуру провайдера и идентичности.
Что могло бы изменить этот ответ?
Основное определение изменилось бы при изменении организационного охвата. Если архитектор отвечает за одну рабочую нагрузку, роль становится ближе к архитектору ИИ-решений. Если ответственность расширяется до стратегии возможностей, инвестиций, стандартов и целевых портфелей на уровне всей организации, она смещается к корпоративной ИИ-архитектуре.
Руководство по реализации меняется всякий раз, когда меняются провайдеры, продукты-шлюзы, протоколы агентов, регуляторные обязательства, возможности моделей или ограничения развёртывания. Именно поэтому архитектура платформы должна выражать стабильные обязанности и контракты отдельно от текущих механизмов поставщиков.
Контрольный список архитектора ИИ-платформы
| Вопрос | Ожидаемый ответ |
|---|---|
| Кто является фактическими потребителями платформы? | Названные решения, команды или контексты арендаторов с различными, но пересекающимися потребностями. |
| Что действительно является общим? | Явный список возможностей, а не расплывчатый «ИИ-бэкенд». |
| Что должно оставаться специфичным для решения? | Доменные полномочия, бизнес-процесс, приёмка задач и другие вопросы, принадлежащие рабочей нагрузке. |
| Как представлены модели/провайдеры? | Версионированные контракты провайдера/модели с возможностями и явной семантикой резервирования. |
| Как распространяется идентичность? | Контекст пользователя/сервиса/приложения/арендатора сохраняется на каждом привилегированном пути запроса. |
| Как обеспечивается изоляция арендаторов? | Ограничение области ресурсов отделено от проверок разрешений ролей. |
| Как обрабатываются секреты? | Привилегированное хранение, ротация, ограниченное раскрытие и поддающееся аудиту владение. |
| Как поиск сохраняет полномочия? | Общие механизмы с авторизацией, происхождением и правилами доказательств, принадлежащими домену. |
| Как ограничиваются инструменты и агенты? | Разрешения времени выполнения, ограниченные контракты инструментов, одобрения, отмена и прослеживаемость. |
| Как контролируются стоимость и ёмкость? | Квоты, контроль токенов/скорости, атрибуция использования и поведение при перегрузке. |
| Как измеряется качество? | Регрессия/оценка платформы плюс специфичная для решения эталонная истина и приёмка. |
| Как внедряются изменения? | Версионирование, совместимость, миграция, вывод из эксплуатации, откат и ответственность за инциденты. |
Заключение
Архитектор ИИ-платформы отвечает за многократно используемую архитектуру между возможностями ИИ и решениями, которые их потребляют. Роль определяет, как модели, провайдеры, поиск, агенты, инструменты, идентичность, арендаторы, секреты, оценка, наблюдаемость, квоты и операции времени выполнения становятся надёжными сервисами платформы, а не повторяющимися разовыми интеграциями.
Сложная часть — не максимизация повторного использования. Это выбор правильной границы. Сильная платформа стандартизирует механизмы, политику и операции там, где несколько потребителей действительно получают выгоду, сохраняя при этом специфичные для решения полномочия над данными, бизнес-логику, требования безопасности и критерии приёмки.
Это различие также объясняет связь с архитектурой ИИ-решений: архитектор решений делает одну систему с поддержкой ИИ пригодной для её цели; архитектор платформы делает общие возможности ИИ безопасными, многократно используемыми, эксплуатируемыми и развиваемыми across many such systems.
Связанные канонические знания
Эта статья следует за каноническими основами по компонентам генеративного ИИ, ADR против NFR и архитектуре ИИ-решений. Эти концепции являются предварительными условиями, поскольку платформа существует для предоставления переиспользуемых системных возможностей и для кодирования архитектурных решений в соответствии с явными требованиями к качеству и эксплуатации.
Генерация с дополнением из поиска — это один из примеров возможности, которая может предоставляться через платформу, но платформа не должна сводить инфраструктуру поиска, предметные знания и достоверность ответов в одно понятие.
Что такое RAG? Самое простое объяснение того, как это работаетКаноническое введение в генерацию с дополнением из поиска и границу между генерацией модели и извлечением внешних знаний.
Агентные протоколы, изоляция тенантов, управление ИИ, маршрутизация моделей, контекстная инженерия и MLOps/LLMOps — это нижестоящие или смежные узлы знаний. О них становится легче рассуждать, когда граница платформы явно определена.
Часто задаваемые вопросы
FAQ архитектора ИИ-платформы
Архитектор ИИ-платформы — это то же самое, что архитектор ИИ-решений?
Должна ли ИИ-платформа размещать собственные модели?
Достаточно ли ИИ-шлюза, чтобы считаться ИИ-платформой?
Следует ли централизовать поиск?
Заменяет ли оценка платформы оценку приложения?
Мультитенантность — это просто RBAC?
Глоссарий
Ключевые термины архитектуры ИИ-платформы
- ИИ-платформа
- Переиспользуемый набор связанных с ИИ технических и эксплуатационных возможностей, потребляемых множеством приложений, команд или тенантных контекстов.
- ИИ-шлюз
- Слой шлюза для ИИ-эндпоинтов, который может добавлять аутентификацию, маршрутизацию, квоты, политику, повторные попытки, атрибуцию затрат и специфичную для ИИ телеметрию помимо базового проксирования.
- Адаптер провайдера
- Компонент, который отображает контракт платформы на API, возможности, состояние работоспособности и семантику отказов провайдера модели.
- Изоляция тенантов
- Граница, которая предотвращает доступ одного тенантного контекста к ресурсам другого тенанта независимо от разрешений роли.
- Контракт возможности
- Версионированный интерфейс и поведенческое соглашение, описывающее, что предоставляет общий сервис платформы и что потребитель должен предоставить или взять на себя.
- Сервис привязки к источникам / поиска
- Общая механика для поиска и предоставления внешней информации ИИ-нагрузке; она не определяет автоматически, какая информация является авторитетной для предметной области.
- Стенд оценки
- Переиспользуемая инфраструктура для запуска тестов, наборов данных, версий моделей/промптов и метрик; предметная приёмка остаётся специфичной для решения.
- Плоскость управления
- Слой конфигурации и управления, который управляет возможностями платформы, идентичностями, политиками, квотами, версиями и состоянием развёртывания.
Первичные источники и актуальные рекомендации по архитектуре
Приведённые ниже источники подтверждают общие утверждения об архитектуре и производственной платформе. Разделы Aaasaasa AI Client, Aaasaasa AI CMS и Source of Truth Research Engine являются явно оригинальными доказательствами реализации. Внешние ссылки на текущее состояние были проверены 8 октября 2026 года.
ISO/IEC/IEEE 42010:2022 — Описание архитектурыДействующий опубликованный международный стандарт для концепций и связей описания архитектуры.
NIST AI Risk Management FrameworkРесурсы и текущий статус NIST AI RMF; AI RMF 1.0 находится на стадии пересмотра по состоянию на октябрь 2026 года.
NIST AI 600-1 — Профиль генеративного ИИПрофиль генеративного ИИ для применения соображений управления рисками ИИ на протяжении жизненного цикла ИИ.
Microsoft Azure Well-Architected — ИИ-нагрузкиАктуальные рекомендации по архитектуре, охватывающие приложение ИИ, данные, операции, оценку, ответственный ИИ и вопросы жизненного цикла.
Microsoft — Принципы проектирования для ИИ-нагрузокАктуальные рекомендации по сегментации идентичностей, границам безопасности, телеметрии, производительности, данным и компромиссам платформы.
Microsoft Foundry — Архитектура ИИ-шлюзаАктуальные рекомендации по ИИ-шлюзу для общего доступа к проектам, сдерживания токенов, квот и управления.
Azure Architecture Center — Доступ к моделям через шлюзРекомендации по архитектуре для централизованного доступа к моделям, маршрутизации, ограничения скорости, отработки отказов и обязанностей клиента/платформы.
AWS Well-Architected — линза генеративного ИИАктуальные рекомендации по производственной архитектуре для рабочих нагрузок генеративного ИИ в области безопасности, надежности, эксплуатации, производительности и затрат.
AWS — сценарий мультитенантной платформы генеративного ИИАктуальный пример, разделяющий централизованное управление платформой и аудируемость от качества данных потребляющих приложений и обязанностей, специфичных для рабочей нагрузки.
AWS Well-Architected — принципы проектирования агентного ИИАктуальные рекомендации по ограничению полномочий агентов, прослеживаемости, версионированию поведения, явным контрактам и человеческому надзору.
AWS CloudWatch — наблюдаемость генеративного ИИАктуальные возможности наблюдаемости и производственные метрики для моделей, агентов, баз знаний, инструментов и анализа затрат/задержек/ошибок.
Related Articles
MCP: объяснение — что он подключает, чего не делает и где ему место
Протокол контекста модели соединяет приложения ИИ с внешними инструментами, ресурсами и подсказками через стандартную границу клиент-сервер. Узнайте, что делает MCP, чего он не делает и где он вписывается в архитектуру агента.
Агентный ИИ: когда система ИИ может планировать, использовать инструменты и действовать
Агентный ИИ использует модели внутри многошаговых циклов выполнения, где они могут выбирать инструменты, наблюдать результаты, обновлять состояние и адаптировать своё следующее действие в рамках явных границ времени выполнения и разрешений.
GPU — не продукт: перспективная архитектура приватного ИИ
Инфраструктура приватного ИИ не должна проектироваться вокруг одного GPU или одной модели. Более устойчивый подход объединяет быстрые GPU для инференса, ИИ-системы с большим объемом памяти, узлы физического ИИ и опциональные передовые облачные модели за уровнем маршрутизации, учитывающим возможности.
RBAC против изоляции арендаторов: две разные границы безопасности
RBAC определяет, что пользователь может делать; изоляция тенантов определяет, к ресурсам какого тенанта это действие может получить доступ. Узнайте, почему безопасность многотенантного SaaS требует обеих границ.
Граница достоверности ответа: недостающий слой между релевантностью и надёжными ответами ИИ
Источник может быть релевантным, авторитетным и при этом неверным для задаваемого вопроса. Недостающий слой — применимость: условия, при которых ответ остаётся в силе, и изменения, вынуждающие пересмотреть его. В этой статье вводится понятие «Граница действительности ответа» как паттерн проектирования источников для людей, ИИ-поиска и RAG-систем.
Что ИИ-агент должен помнить, забывать, перевычислять или извлекать повторно?
Долгоживущие агенты не должны помнить всё. В этой статье представлена практическая модель жизненного цикла для определения того, что относится к долговременной памяти, что следует извлекать повторно, что безопаснее пересчитать, а что должно истечь по сроку действия или быть заменено.
Память ИИ-агента — это не RAG: как разграничить память, извлечение, состояние и контекст
Память агента, RAG, состояние и контекст часто используются так, будто они взаимозаменяемы. Это не так. Эта практическая архитектурная модель разделяет четыре уровня, показывает, где место каждого из них, и объясняет, что ломается, когда системы объединяют их в одно целое.
Что такое архитектор ИИ-решений? Границы системы, обязанности и компромиссы
Архитектор решений ИИ превращает бизнес-требования в готовую к производству систему ИИ, охватывающую данные, модели, инструменты, безопасность, среду выполнения, оценку и операции.
Суверенный ИИ: контроль над моделями, данными, инфраструктурой и зависимостями
Суверенный ИИ — это эффективный контроль над моделями, данными, инфраструктурой, программным обеспечением, операциями и стратегическими зависимостями, а не просто место размещения модели ИИ.
Архитектура ИИ на предприятии: что меняется, когда ИИ приходит в компанию
Архитектура ИИ для предприятий объясняет, как ИИ меняет корпоративные системы в таких областях, как полномочия на данные, идентификация, разрешения, поставщики, риски, управление, оценка, соответствие требованиям и операции.
Откуда LLM берёт данные? Источники данных RAG в Python
LLM не знает магическим образом о ваших файлах, базах данных или API. Это практическое продолжение серии о RAG показывает на простом Python, как внешние данные становятся извлекаемыми доказательствами: от текстовых файлов и SQL до полнотекстового поиска, эмбеддингов, сборки контекста и финального вызова LLM.
Генеративный ИИ: модели, поиск, инструменты и приложения — это не одно и то же
Генеративный ИИ — это больше, чем модель. Узнайте, как модели, поиск информации, инструменты, контекст, среды выполнения и приложения сочетаются друг с другом в производственных системах ИИ.