Представьте: все плоскости построены. PII маскируется, RAG знает права, guardrails стоят, аудит пишется, бюджеты держат, контент помечен, качество меряется, supply chain под AIBOM, агент за policy-гейтом. Через полгода приходит аудит ISO 42001 — а доказать нечего. ACL-синхронизация тихо сломалась в марте, golden-датасет не обновляли с запуска, kill-switch ни разу не тестировали, а владельца у кредитного модуля формально нет. Технические контроли прокисли — не от атаки, а от энтропии. Их некому было поддерживать и нечем аудировать.
Это финальная и самая недооценённая плоскость governance. Технические паттерны без операционной модели деградируют. Эта глава собирает их в AI Management System (AIMS по ISO/IEC 42001): с владельцами, жизненным циклом, реестром систем, политиками-как-кодом и автогенерируемой доказательной базой.
Бизнес-цель: управляемая система, а не набор контролей
Превратить набор контролей в управляемую систему, которая переживает уход конкретного инженера и проходит аудит без аврала. Что должно быть гарантировано бизнесу:
- Каждая AI-система имеет владельца, класс риска и жизненный цикл.
- Governance выражен как код и сам под версией и аудитом.
- Доказательства соответствия генерируются автоматически из живых плоскостей.
Драйверы: регулятор и организационный дрейф
- ISO/IEC 42001: сертифицируемый AIMS — требование ~40% enterprise-RFP в ЕС (2026).
- EU AI Act: Art. 9 (RMS), Art. 17 (quality management), Art. 72 (post-market monitoring), Art. 11–12 (документация и логи).
- Организационный дрейф: без владельцев и процесса контроли прокисают. ACL отстаёт, датасет устаревает, kill-switch не тестируется. Это тихий отказ governance.
Архитектурный паттерн: AIMS + Policy-as-Code Control Plane
Операционная модель поверх control plane. Политики — это код и гейты в CI/CD. Каждая AI-система живёт в реестре с ролями и жизненным циклом. Доказательства соответствия генерируются автоматически из артефактов предыдущих плоскостей.
Инженерный стек
| Слой | Инструмент | Назначение |
|---|---|---|
| AIMS/GRC | ISO 42001-aligned процессы | Трекеры рисков и политик |
| Registry | MLflow Registry / внутренний реестр | Реестр AI-систем с метаданными |
| Policy-as-code | OPA/Rego | Единый язык гейтов |
| Evidence | Аудит-лог + eval-отчёты + AIBOM + red-team | Автоматические доказательства |
Инженерная реализация
Шаг 1. Реестр AI-систем
Каждая система — запись: класс риска, владелец, статус жизненного цикла, ссылки на её контроли и доказательства. Без реестра governance не существует — нечего назначать, нечего аудировать, нечего выводить из эксплуатации.
Шаг 2. RACI governance
Кто владелец риска, кто аппрувит релиз, кто держит kill-switch, кто отвечает за evals. Governance board — процесс с полномочиями, а не совещание для галочки. Владелец без права остановить релиз — декоративен. Это частый провал: роль есть в оргсхеме, реальной власти нет, и релиз катится, потому что «бизнес ждёт».
Шаг 3. Policy-as-code как единый слой
OPA-политики сведены в один версионируемый репозиторий. Изменение политики — это PR, ревью и новая версия. Governance сам под аудитом: каждый гейт, каждое правило, каждое исключение оставляет след в Git.
Шаг 4. Lifecycle и gates — state machine
dev → risk-classification → security-gate → eval-gate
→ release → post-market monitoring → retireКаждый переход — явное наблюдаемое состояние с автогенерацией technical documentation из артефактов. Не «if» в CI-скрипте, а внешний статус системы в реестре. Если гейт спрятан в bash-однострочнике, его невозможно ни аудировать, ни воспроизвести.
Шаг 5. Post-market monitoring, замкнутый на политики
Drift, инциденты и feedback-петля обновляют реестр, RMS и сами политики. Инцидент → новый red-team кейс → новое правило OPA. Система учится на собственных сбоях, а не ждёт следующего аудита.
Шаг 6. Reference-архитектура «Ковчега» (capstone)
Полная диаграмма control plane: как все плоскости стыкуются в один путь запроса и один слой доказательств. Это карта, доведённая до уровня, по которому можно пройти аудит. Реестр из двух систем с классами риска и владельцами, RACI, единый policy-as-code репозиторий, lifecycle-гейты в CI, автогенерация technical documentation из артефактов.
Финальный артефакт — AIMS-досье «Ковчега»: одна папка, из которой проходится аудит. Классификация, контроли, доказательства, владельцы, инцидент-процесс. Всё в одном месте, всё сгенерировано из живых систем, ничего не собрано вручную накануне.
Где ломается
Governance-театр на новом уровне. Реестр и board существуют, но политики не исполняются в проде. Снова разрыв «PDF vs control plane»: красивая документация, за которой стоит ноль enforcement. Единственное лекарство — policy-as-code и автодоказательства, а не скриншоты к аудиту.
Владелец без полномочий. Роль есть, остановить релиз не может. Декорация, которая создаёт иллюзию контроля и снимает мотивацию ставить настоящего владельца.
AIMS без автоматических доказательств превращается в ручной сбор артефактов к дате аудита. Та же энтропия, только с папкой. Через цикл-два артефакты перестают отражать реальность, потому что их собирают отдельно от работы.
Over-governance. Слишком тяжёлый процесс убивает скорость. Команды уходят в Shadow AI — разворачивают модели в обход процесса, потому что легальный путь мучителен. Governance конкурирует с удобством: если легальный путь хуже теневого, теневой победит.
Реестр отстаёт от реальности без автообнаружения систем. Тот же принцип, что у AIBOM: если системы не обнаруживаются автоматически, реестр превращается в ещё один мёртвый документ.
Стандарты и маппинг
- ISO/IEC 42001: весь стандарт (AIMS, Annex A).
- EU AI Act: Art. 9 (RMS), Art. 17 (QMS), Art. 72 (post-market), Art. 11–12.
- NIST AI RMF: Govern — в центре.
Свод — матрица «требование → контроль → доказательство». Каждое требование стандарта маппится на конкретный контроль из конкретной главы и на конкретный артефакт, который этот контроль генерирует.
Чеклист зрелости
- L1: реестр AI-систем и назначенные владельцы существуют.
- L2: policy-as-code гейты в CI, lifecycle со статусами, автодоказательства из аудит-лога, eval-отчётов и AIBOM.
- L3: сертифицируемый AIMS, post-market monitoring замкнут на политики, матрица соответствия с живыми доказательствами, governance сам под версией и аудитом, автообнаружение систем.
Что дальше
Курс дал control plane и операционку под него. Следующий горизонт — межорганизационный governance: провенанс и доверие между агентами разных компаний, verifiable credentials для ИИ-агентов, отраслевые кодексы практик поверх AI Act. Это за периметром enterprise, с которого курс начинался.
Все плоскости контроля собираются в одну операционную модель — AIMS плюс policy-as-code — и владельцем этой модели становится инженерный лидер. Если у вас нет человека, который держит governance целиком — от OPA-репозитория до реестра систем до автодоказательств — через год вы будете объяснять аудиторам, почему kill-switch ни разу не тестировали.