capability map
Карта AI Platform
Семь устойчивых зон ответственности: от выбора сценария до эксплуатации, безопасности и ownership.
Это capability map, а не целевая архитектура конкретной компании и не строгий путь запроса. Строки читаются сверху вниз; пересечения показаны отдельно.
- 01
Стратегия и границы
Запланировано
Назначение
Как выбрать полезные ИИ-сценарии, определить границы платформы и решить, когда нужен внешний или собственный сервис моделей.
Граница ответственности
Определяет, какие сценарии требуют платформенной инвестиции и где проходит граница между MaaS, self-hosted и гибридным исполнением.
Ключевой вопрос
Когда общая платформа оправдана, а когда достаточно одного сценария?
Основные компоненты
Сценарии, зрелость, execution mode, критерии инвестиции
- 02
Управляющий контур (Control Plane)
Запланировано
Назначение
Как платформа управляет доступом к моделям, маршрутизацией запросов, лимитами и выпуском настроек.
Граница ответственности
Управляет доступом, стабильными именами, маршрутами, лимитами, политиками и выпуском конфигурации; сам инференс остаётся снаружи.
Ключевой вопрос
Какие общие контракты управляют доступом, маршрутами и выпуском?
Основные компоненты
Platform API и SDK, gateway, registry, routing, policies, quotas
- 03
Контур инференса (Inference Plane)
Проверено
Назначение
Как платформа запускает модели, распределяет нагрузку и управляет ресурсами для генерации, распознавания речи и векторизации.
Граница ответственности
Исполняет модельные нагрузки и управляет средами исполнения, пулами ресурсов, планированием, пакетной обработкой, памятью и кэшем; не выбирает бизнес-сценарий.
Ключевой вопрос
Где и как исполняется модельная нагрузка?
Основные компоненты
Runtimes, model pools, scheduling, batching, cache
- 04
Контекст и исполнение агентов (Context & Agent Runtime)
Запланировано
Назначение
Как система находит контекст, подключает инструменты, хранит состояние сессии и ограничивает память агента.
Граница ответственности
Собирает контекст и управляет многошаговой работой агента: поиском данных, инструментами, состоянием сессии, памятью, остановкой и восстановлением.
Ключевой вопрос
Как система собирает контекст, вызывает tools и хранит состояние?
Основные компоненты
Retrieval lifecycle, tool registry, execution, state, memory
- 05
Качество и жизненный цикл
Запланировано
Назначение
Как команда проверяет качество данных, моделей, промптов и агентов перед выпуском и после него.
Граница ответственности
Связывает изменения данных, моделей, промптов и агентов с evals, release gates, версиями, обратной связью и откатом.
Ключевой вопрос
Как изменение проходит проверку и попадает в production?
Основные компоненты
Evals, datasets, release gates, model/prompt/agent lifecycle
- 06
Эксплуатация и экономика
Запланировано
Назначение
Как команда следит за доступностью, нагрузкой, инцидентами и стоимостью работы ИИ-сценариев.
Граница ответственности
Связывает SLO, capacity, инциденты и cost attribution с эксплуатационными решениями; утилизация остаётся входом, а не решением.
Ключевой вопрос
Как связать SLO, capacity, инциденты и стоимость результата?
Основные компоненты
Observability, SLO, capacity, incidents, cost attribution
- 07
Безопасность и ответственность
Запланировано
Назначение
Как команда защищает данные, управляет доступом, проверяет действия системы и закрепляет ответственность.
Граница ответственности
Задаёт границы данных, доступ, guardrails, аудит и владельцев решений и реакции на инциденты; эта ответственность пересекает все области.
Ключевой вопрос
Где проходят границы данных, доступа и operational ownership?
Основные компоненты
Data boundaries, guardrails, access, audit, ownership
Как области пересекаются
- 01
Control Plane и Inference Plane
Control Plane задаёт route intent, policy и limits. Inference Plane отвечает доступностью, pressure и фактом исполнения.
- 02
Context & Agent Runtime и Quality & Lifecycle
Agent runtime собирает контекст и действия. Quality & Lifecycle проверяет версии данных, промптов, tools и поведения перед выпуском.
- 03
Эксплуатация, экономика, безопасность и ownership
SLO, capacity, cost, data boundaries, audit и владельцы решений проходят через все области, а не образуют отдельный шаг request path.