Манифест: AI Governance как control plane, а не PDF-политика

Что такое AI Governance простыми словами

Если совсем без жаргона: AI governance — это набор правил и механизмов, которые определяют, что ИИ-системе в компании можно, чего нельзя, и как убедиться, что она этого и правда придерживается. Три вопроса, на которые оно отвечает:

• Что ИИ позволено? Какие данные он видит, какие действия совершает, кому и что отвечает. (Ассистенту можно читать базу знаний, но не зарплаты; можно создать тикет, но не перевести деньги без человека.)
• Как гарантировать, что он это соблюдает? Не «мы попросили модель вести себя прилично», а технические ограничители, которые стоят на пути и которые модель не может уговорить.
• Как это доказать? Регулятору, аудитору, клиенту — что система работает в рамках, что решения объяснимы, а данные защищены.

Аналогия: у бухгалтерии есть внутренний контроль — не потому что бухгалтеры плохие, а потому что через деньги проходит риск, и нужны процедуры, разделение прав, аудиторский след. AI governance — то же самое для ИИ-систем: не про недоверие к технологии, а про то, что через ИИ теперь проходят деньги, персональные данные и решения, влияющие на людей.

Важно, чем governance не является. Это не «затормозить ИИ» и не юридический отдел, пишущий запреты. Хороший governance, наоборот, разрешает двигаться быстро — потому что когда защита встроена в платформу, командам не нужно каждый раз изобретать её заново и согласовывать вручную. Плохой governance тормозит; хороший — убирает трение.

Регулятор с 2024–2026 гг. перевёл это из «желательно» в «обязательно»: EU AI Act (закон ЕС об ИИ) требует конкретных технических мер и грозит штрафами от оборота компании, а ISO/IEC 42001 — международный стандарт, по которому governance можно сертифицировать. Детали — в главе 6; здесь важно, что это уже не добрая воля, а требование рынка и закона.

Почему политика не работает

Политика описывает желаемое поведение людей. Но в проде поведение определяет код и инфраструктура, а не намерения. Между политикой и продом — разрыв, в который проваливаются все громкие инциденты: PII в логах провайдера, RAG, отдавший сотруднику зарплаты коллег, агент, выполнивший инъекцию из письма, счёт за токены в шестизначных суммах за ночь. Ни один из них не случился потому, что кто-то не читал политику. Они случились, потому что на пути запроса не стояло ничего, что бы их остановило.

Политика — это спецификация. Control plane — её реализация. Курс отказывается писать спецификации, которые нечем исполнить.

Что такое AI Control Plane

Это управляющий слой между приложениями и моделями, через который проходит весь трафик к LLM — свой хостинг, облачные API, агентные вызовы. Внутри — набор плоскостей контроля, каждая закрывает одну категорию риска:

• Data plane — что уходит наружу: маскирование PII, Zero Data Retention (гл. 1).
• Identity plane — кто что видит: RBAC/ABAC на уровне RAG (гл. 2).
• Safety plane — что модель принимает и отдаёт: guardrails против инъекций, джейлбрейков, токсичности, галлюцинаций (гл. 3).
• Audit plane — что произошло: неизменяемый трейс каждого решения (гл. 4).
• Cost/resilience plane — сколько это стоит и падает ли: gateway, кэш, бюджеты, fallback (гл. 5).
• Compliance plane — соответствие: EU AI Act, ISO 42001, provenance (гл. 6).
• Quality plane — не деградирует ли: непрерывная оценка, drift, fairness (гл. 7).
• Supply-chain plane — из чего собрано и что несанкционировано: AIBOM, Shadow AI, kill-switch (гл. 8).
• Autonomy plane — что агенту позволено делать самому (гл. 9).
• Operating model — кто всем этим владеет и как это живёт как AIMS (гл. 10).

Ни одна плоскость не самодостаточна. ZDR без контроля доступа отдаёт чужие данные, только не провайдеру, а своему же сотруднику. Guardrails без аудита нельзя доказать регулятору. Аудит без бюджетов разоряет. Курс собирает их в одну систему.

Три принципа, на которых стоит курс

1. Governance-by-design, не bolt-on. Контроль встроен в архитектуру на этапе проектирования, а не прикручен ревью после инцидента. Это дешевле и это единственное, что масштабируется.

1. Явные переходы состояний, не инкапсулированная логика. Каждый контроль — это внешнее, наблюдаемое состояние (статус в манифесте, запись в аудит-логе, вердикт policy engine), а не «if» глубоко в коде сервиса. Governance, который нельзя увидеть снаружи, нельзя ни проверить, ни доказать.

1. Честная граница. У каждого паттерна есть failure mode. Маскирование PII ломается на неструктурированных именах; pre-filtering RAG — на сложных ABAC-правилах; guardrails — на новых классах инъекций. Раздел «Где ломается» есть в каждой главе: инженер, который знает границу своего контроля, надёжнее того, кто верит в его полноту.

Провокация

Большинство «AI governance» на рынке — это театр соответствия: документы, комитеты, чек-листы, которые создают ощущение контроля, не создавая контроля. Регулятор это уже понял — EU AI Act требует не деклараций, а технической документации, логов, систем управления рисками и машиночитаемой маркировки. Штрафы считаются от оборота. Компания, у которой governance живёт в PDF, а не в control plane, — это компания, которая узнает о разрыве в момент инцидента или проверки.

Курс — про то, чтобы узнать раньше и построить иначе.

Сквозной кейс — «Ковчег»

Чтобы паттерны собирались в одну систему, а не в россыпь разрозненных приёмов, весь курс идёт на одном вымышленном продукте — «Ковчег». Это ИИ-ассистент банка (или страховщика: разница для курса не принципиальна). Название придумано специально, чтобы не путать с реальными системами и кейсами.

«Ковчег» намеренно выбран так, чтобы задеть все плоскости governance сразу — поэтому у него две ипостаси:

1. RAG-ассистент отвечает сотрудникам на вопросы по внутренним системам компании (вики Confluence, задачи Jira, документы SharePoint, база PostgreSQL). «RAG» — retrieval-augmented generation, то есть модель отвечает не из головы, а сначала находит релевантные документы, потом формулирует ответ по ним. Ключевое требование: сотрудник должен видеть через ассистента ровно то, к чему у него есть доступ в самих системах, — не больше.
2. Агент не просто отвечает, а действует: создаёт тикеты, готовит проекты решений по клиенту (вплоть до кредитных), обращается к внутренним API. «Агент» здесь — ИИ, которому дали инструменты и право ими пользоваться самостоятельно.

Почему именно банк и именно с такими функциями. Во-первых, данные: ФИО, паспорта, счета — персональные данные под GDPR плюс банковская тайна, цена утечки максимальна (главы 1–2). Во-вторых, регуляторика: оценка кредитоспособности прямо отнесена EU AI Act к высокорисковым системам (high-risk) — это включает самый строгий набор требований (глава 6). В-третьих, действия: агент, готовящий решения по деньгам клиента, — это уже не «чат-бот ошибся», а реальный ущерб (глава 9).

Иными словами, «Ковчег» — это не самый простой, а самый требовательный пример. Если governance-паттерн работает на нём, он тем более сработает на менее рискованном продукте. Каждая глава показывает свою плоскость контроля на «Ковчеге»; глава 10 собирает их в единую reference-архитектуру.

Как читать курс

Главы 1–9 — плоскости контроля, каждая самостоятельна и даёт рабочий паттерн. Глава 10 собирает их в операционную модель и reference-архитектуру «Ковчега» целиком. Порядок рекомендованный, но не жёсткий: если горит приватность или доступ — начинайте с 1–2; если горит регулятор — с 6; если строите агентов — с 9. Сквозной кейс «Ковчег» проходит через все главы, чтобы паттерны собирались в одну систему, а не в россыпь разрозненных решений.

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

• Дальше: Privacy / ZDR — PII не покидает периметр: маскирование и Zero Data Retention
• Все главы курса →
• Подключить эксперта как MCP →