Ответственность и операционная модель

Кто владеет production ИИ-сценариями, слоями платформы, стоимостью, качеством и инцидентами.

Проблема

Production AI ломается, когда ответственность размазана между исследованием моделей, продуктовыми командами, инфраструктурой и поддержкой без операционной модели.

Симптомы

Продукт владеет UX, но не качеством модели.
Платформа владеет развёртывание, но не результатами сценария.
Никто не владеет разбором стоимости.
Инциденты debug-ит тот, кто помнит промпт.

Ментальная модель

AI Platform должна включать продуктовые команды, не становясь bottleneck. Для этого нужны понятные RACI, типовые маршруты и правила эскалации.

При миграции на self-hosted продуктовая команда отвечает за сценарий, критерии успеха и первичный model discovery. Платформа отвечает за self-hosted candidate, мощность, профиль задержки, контроль качества, резервный маршрут и эксплуатацию.

Если эти роли не разделить, миграция превращается либо в research без production-ответственности, либо в инфраструктурный проект без продуктового критерия успеха.

Архитектура

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

У production AI-сценария должен быть владелец route policy, context budget, tool policy и cache strategy. Иначе стоимость и качество будут "ничьи": продукт видит UX, платформа видит GPU, но никто не владеет траекторией агента целиком.

RACI для AI-сценария

quality

Owner: scenario quality

Продуктовый критерий успеха и датасет.

route

Owner: route policy

direct, RAG, agentic, human review и fallback.

prompt

Owner: prompt family

Версии промпта и совместимость с моделями.

tools

Owner: tool registry

Стабильность tools, allowed tools и аудит.

cache

Owner: cache hit SLO

Prefix stability, route affinity и regression.

cost

Owner: cost review

Стоимость сценария и принятый результат.

Что MaaS снимал с команды

MaaS снимает часть операционной ответственности: масштабирование, доступ к новым моделям, часть защитных контуров, эксплуатацию рантайма и обновления. В self-hosted эти вопросы возвращаются внутрь команды.

MaaS скрывает	Self-hosted возвращает
масштабирование	планирование мощности
обновления рантайма	обновления vLLM и рантайма
часть защитных контуров	собственные политики
жизненный цикл модели	процесс релиза
SLA провайдера	собственный SLO
платёж за токены	люди, железо и процессы

Принцип

Self-hosted даёт контроль, но возвращает ответственность.

Метрики

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

Компромиссы

Центральная ответственность платформы повышает согласованность, но может замедлить команды. Ответственность продукта повышает скорость, но может фрагментировать безопасность, стоимость и телеметрию. Зрелые организации явно делят зоны ответственности.

Анти-паттерны

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

Чеклист

✓У каждого сценария есть продуктовый владелец и владелец платформы.
✓Релизы моделей проходят ревью качества и стоимости.
✓Процесс инцидента включает откат промпта, модели или инструмента.
✓У продуктовых команд есть SDK, шаблоны и playground.
✓У сценария есть владелец route policy, context budget, tool policy и cache strategy.
✓Исключения из платформенного пути отслеживаются и ревьюятся.