Глава 10. Governance Operating Model & AIMS: операционка и reference-архитектура (capstone)

Бизнес-цель клиента

Превратить набор контролей в управляемую систему, которая переживает уход конкретного инженера и проходит аудит без аврала. Обещания бизнесу:

1. Каждая AI-система имеет владельца, класс риска и жизненный цикл.
2. Governance выражен как код и сам под версией/аудитом.
3. Доказательства соответствия генерируются автоматически из живых плоскостей.

Драйвер: угроза или регулятор

• 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-система живёт в реестре с ролями и жизненным циклом; доказательства соответствия генерируются автоматически из артефактов глав 1–9.

Инженерный стек & провайдеры

• AIMS/GRC: ISO 42001-aligned процессы; трекеры рисков/политик.
• Registry: MLflow Registry / внутренний реестр AI-систем.
• Policy-as-code: OPA/Rego как единый язык гейтов (гл. 2, 3, 6, 9).
• Evidence: аудит-лог (гл. 4) + eval-отчёты (гл. 7) + AIBOM (гл. 8) + red-team (гл. 3, 9) как автоматические доказательства.

Инженерная реализация

### Шаг 1. Реестр AI-систем

Каждая система (RAG «Ковчег», агент «Ковчег») — запись: класс риска (гл. 6), владелец, статус жизненного цикла, ссылки на её контроли и доказательства.

### Шаг 2. RACI governance

Кто владелец риска, кто аппрувит релиз, кто держит kill-switch, кто отвечает за evals. Governance board — процесс с полномочиями, а не совещание для галочки. Владелец без права остановить релиз — декоративен (частый провал).

### Шаг 3. Policy-as-code как единый слой

OPA-политики глав 2/3/6/9 сведены в один версионируемый репозиторий. Изменение политики = PR + ревью + версия. Governance сам под аудитом.

### Шаг 4. Lifecycle & gates (state machine)

dev → risk-classification (гл.6) → security-gate (гл.3,8) → eval-gate (гл.7)
    → release → post-market monitoring (гл.7,8) → retire

Каждый переход — явное наблюдаемое состояние, с автогенерацией technical documentation из артефактов. Не «if» в CI-скрипте, а внешний статус (принцип из CLAUDE.md).

### Шаг 5. Post-market monitoring, замкнутый на политики

Drift/incident/feedback-петля (гл. 7–8) обновляет реестр, RMS и сами политики. Инцидент → новый red-team кейс + новое правило OPA. Система учится.

### Шаг 6. Reference-архитектура «Ковчега» (capstone)

Полная диаграмма control plane: как плоскости 1–9 стыкуются в один путь запроса и один слой доказательств. Это карта из _index.md, доведённая до уровня, по которому можно пройти аудит.

Где ломается

• Governance-театр на новом уровне. Реестр и board есть, но политики не исполняются в проде — снова разрыв «PDF vs control plane» (гл. 0). Единственное лекарство — policy-as-code + автодоказательства, а не скриншоты к аудиту.
• Владелец без полномочий — роль есть, остановить релиз не может. Декорация.
• AIMS без автоматических доказательств превращается в ручной сбор артефактов к дате аудита — та же энтропия, только с папкой.
• Over-governance. Слишком тяжёлый процесс убивает скорость → команды уходят в Shadow AI (гл. 8). Governance конкурирует с удобством; если легальный путь мучителен, его обходят.
• Реестр отстаёт от реальности без автообнаружения систем (тот же AIBOM-принцип, гл. 8).

Стандарты и маппинг

• 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 (в центре).
• Свод: матрица «требование → контроль (глава) → доказательство (артефакт)».

Лаба и артефакт (capstone)

Собрать reference-архитектуру «Ковчега»: реестр из двух систем с классами риска и владельцами, RACI, единый policy-as-code репозиторий (политики глав 2/3/6/9), lifecycle-гейты в CI, автогенерацию technical documentation из артефактов глав 1–9. Финальный артефакт курса — AIMS-досье «Ковчега»: одна папка, из которой проходится аудит: классификация, контроли, доказательства, владельцы, инцидент-процесс. Это защита курса.

Чеклист зрелости

• L1: реестр AI-систем и назначенные владельцы существуют.
• L2: policy-as-code гейты в CI, lifecycle со статусами, автодоказательства из аудит/eval/AIBOM.
• L3: сертифицируемый AIMS, post-market monitoring замкнут на политики, матрица соответствия с живыми доказательствами, governance сам под версией и аудитом, автообнаружение систем.

Что дальше

Курс дал control plane и операционку под него. Следующий горизонт — межорганизационный governance: провенанс и доверие между агентами разных компаний, verifiable credentials для ИИ-агентов, отраслевые кодексы практик поверх AI Act. Но это уже за периметром enterprise, с которого курс начинался — и тема отдельного разговора.

Источники

• [ISO 42001 guide 2026 (Konfirmity)](https://www.konfirmity.com/blog/iso-42001)
• [ISO 42001 vs NIST AI RMF vs EU AI Act (EC-Council)](https://www.eccouncil.org/cybersecurity-exchange/responsible-ai-governance/eu-ai-act-nist-ai-rmf-and-iso-iec-42001-a-plain-english-comparison/)
• [Global AI Governance Comparison 2026 (GAICC)](https://gaicc.org/blog/ai-governance-comparison-eu-ai-act-nist-iso-42001/)

Как это устроено — инженерные разборы

Отдельные howto из практики, где плоскость контроля показана на работающем коде и артефакте.

• Cursor rules как governance: как держать планку качества, когда команда вайб-кодитПравила как governance: планка качества, когда команда вайб-кодит.
• Скилл, который онбордит другие скиллыGovernance над жизненным циклом компонентов.
• Google A2A поверх Git: production-ready транспорт для агентов между организациямиA2A поверх Git: межорганизационный транспорт агентов — горизонт «что дальше».

Читать дальше

• Все главы курса →
• Подключить эксперта как MCP →