Есть два способа делать AI governance. Первый — написать политику. Документ на сорок страниц: принципы ответственного ИИ, комитет, матрица ролей, требование «использовать ИИ этично». Его подписывают, кладут в SharePoint и возвращаются к нему на следующем аудите. Второй способ — встроить governance в путь запроса: каждый вызов модели физически не может обойти маскирование PII, контроль доступа, guardrails, лимиты и аудит, потому что они стоят на пути пакета, а не в голове разработчика.
Этот текст — про второй способ. Тезис простой и жёсткий: governance, который нельзя обойти технически, — это не документ, это control plane.
Что такое AI Governance
Если совсем без жаргона: AI governance — это набор правил и механизмов, которые определяют, что ИИ-системе в компании можно, чего нельзя, и как убедиться, что она этого и правда придерживается. Три вопроса, на которые оно отвечает:
- Что ИИ позволено? Какие данные он видит, какие действия совершает, кому и что отвечает. Ассистенту можно читать базу знаний, но не зарплаты; можно создать тикет, но не перевести деньги без человека.
- Как гарантировать, что он это соблюдает? Не «мы попросили модель вести себя прилично», а технические ограничители, которые стоят на пути и которые модель не может уговорить.
- Как это доказать? Регулятору, аудитору, клиенту — что система работает в рамках, что решения объяснимы, а данные защищены.
Аналогия: у бухгалтерии есть внутренний контроль — не потому что бухгалтеры плохие, а потому что через деньги проходит риск, и нужны процедуры, разделение прав, аудиторский след. AI governance — то же самое для ИИ-систем: не про недоверие к технологии, а про то, что через ИИ теперь проходят деньги, персональные данные и решения, влияющие на людей.
Важно, чем governance не является. Это не «затормозить ИИ» и не юридический отдел, пишущий запреты. Хороший governance, наоборот, разрешает двигаться быстро — потому что когда защита встроена в платформу, командам не нужно каждый раз изобретать её заново и согласовывать вручную. Плохой governance тормозит; хороший — убирает трение.
Регулятор с 2024–2026 гг. перевёл это из «желательно» в «обязательно»: EU AI Act (закон ЕС об ИИ) требует конкретных технических мер и грозит штрафами от оборота компании, а ISO/IEC 42001 — международный стандарт, по которому governance можно сертифицировать. Это уже не добрая воля, а требование рынка и закона.
Почему политика не работает
Политика описывает желаемое поведение людей. Но в проде поведение определяет код и инфраструктура, а не намерения. Между политикой и продом — разрыв, в который проваливаются все громкие инциденты: PII в логах провайдера, RAG, отдавший сотруднику зарплаты коллег, агент, выполнивший инъекцию из письма, счёт за токены в шестизначных суммах за ночь. Ни один из них не случился потому, что кто-то не читал политику. Они случились, потому что на пути запроса не стояло ничего, что бы их остановило.
Политика — это спецификация. Control plane — её реализация. Нет смысла писать спецификации, которые нечем исполнить.
Что такое AI Control Plane
Это управляющий слой между приложениями и моделями, через который проходит весь трафик к LLM — свой хостинг, облачные API, агентные вызовы. Внутри — набор плоскостей контроля, каждая закрывает одну категорию риска:
- Data plane — что уходит наружу: маскирование PII, Zero Data Retention.
- Identity plane — кто что видит: RBAC/ABAC на уровне RAG.
- Safety plane — что модель принимает и отдаёт: guardrails против инъекций, джейлбрейков, токсичности, галлюцинаций.
- Audit plane — что произошло: неизменяемый трейс каждого решения.
- Cost/resilience plane — сколько это стоит и падает ли: gateway, кэш, бюджеты, fallback.
- Compliance plane — соответствие: EU AI Act, ISO 42001, provenance.
- Quality plane — не деградирует ли: непрерывная оценка, drift, fairness.
- Supply-chain plane — из чего собрано и что несанкционировано: AIBOM, Shadow AI, kill-switch.
- Autonomy plane — что агенту позволено делать самому.
- Operating model — кто всем этим владеет и как это живёт как AIMS.
Ни одна плоскость не самодостаточна. ZDR без контроля доступа отдаёт чужие данные, только не провайдеру, а своему же сотруднику. Guardrails без аудита нельзя доказать регулятору. Аудит без бюджетов разоряет. Плоскости собираются в одну систему — по отдельности каждая оставляет дыру.
Принципы курса
1. Governance-by-design, не bolt-on. Контроль встроен в архитектуру на этапе проектирования, а не прикручен ревью после инцидента. Это дешевле и единственное, что масштабируется.
2. Явные переходы состояний, не инкапсулированная логика. Каждый контроль — это внешнее, наблюдаемое состояние (статус в манифесте, запись в аудит-логе, вердикт policy engine), а не «if» глубоко в коде сервиса. Governance, который нельзя увидеть снаружи, нельзя ни проверить, ни доказать.
3. Честная граница. У каждого паттерна есть failure mode. Маскирование PII ломается на неструктурированных именах; pre-filtering RAG — на сложных ABAC-правилах; guardrails — на новых классах инъекций. Инженер, который знает границу своего контроля, надёжнее того, кто верит в его полноту.
«Ковчег» — сквозной кейс
Чтобы паттерны собирались в одну систему, а не в россыпь разрозненных приёмов, весь курс идёт на одном вымышленном продукте — «Ковчег». Это ИИ-ассистент банка (или страховщика: разница для курса не принципиальна). Название придумано специально, чтобы не путать с реальными системами и кейсами.
«Ковчег» намеренно выбран так, чтобы задеть все плоскости governance сразу — поэтому у него две ипостаси:
- RAG-ассистент отвечает сотрудникам на вопросы по внутренним системам компании (вики Confluence, задачи Jira, документы SharePoint, база PostgreSQL). RAG — retrieval-augmented generation, то есть модель отвечает не из головы, а сначала находит релевантные документы, потом формулирует ответ по ним. Ключевое требование: сотрудник должен видеть через ассистента ровно то, к чему у него есть доступ в самих системах, — не больше.
- Агент не просто отвечает, а действует: создаёт тикеты, готовит проекты решений по клиенту (вплоть до кредитных), обращается к внутренним API. Агент — ИИ, которому дали инструменты и право ими пользоваться самостоятельно.
Почему именно банк и именно с такими функциями. Во-первых, данные: ФИО, паспорта, счета — персональные данные под GDPR плюс банковская тайна, цена утечки максимальна. Во-вторых, регуляторика: оценка кредитоспособности прямо отнесена EU AI Act к высокорисковым системам (high-risk) — это включает самый строгий набор требований. В-третьих, действия: агент, готовящий решения по деньгам клиента, — это уже не «чат-бот ошибся», а реальный ущерб.
«Ковчег» — не самый простой, а самый требовательный пример. Если governance-паттерн работает на нём, он тем более сработает на менее рискованном продукте.
Театр соответствия
Большинство «AI governance» на рынке — это театр соответствия: документы, комитеты, чек-листы, которые создают ощущение контроля, не создавая контроля. Регулятор это уже понял — EU AI Act требует не деклараций, а технической документации, логов, систем управления рисками и машиночитаемой маркировки. Штрафы считаются от оборота. Компания, у которой governance живёт в PDF, а не в control plane, узнает о разрыве в момент инцидента или проверки — когда уже поздно.
Где ломается
Здесь — не failure mode конкретного паттерна, а граница самого подхода. Control plane — это инженерное решение, и у него есть цена.
Сложность границ плоскостей. Каждая плоскость контроля — это отдельный сервис, отдельная задержка, отдельная точка отказа. Десять плоскостей на пути запроса означают десять мест, где что-то может отвалиться. Control plane — это архитектурный компромисс между безопасностью и эксплуатационной сложностью: чем больше контроля, тем больше поверхности для отказов. Решение — не убирать плоскости, а проектировать их как fail-closed: если audit plane упал, запрос не проходит тихо, он блокируется.
Скорость как жертва. Каждый контроль добавляет задержку. Маскирование PII — лишний проход по тексту. ABAC на RAG — проверка атрибутов при ретривале. Guardrails — отдельный вызов модели-классификатора. На высокой нагрузке сумма задержек становится ощутимой. Это не аргумент против control plane, а инженерная реальность: защиту платят скоростью, и эту цену нужно считать сознательно.
Ложное ощущение полноты. Самый коварный failure mode — уверенность, что control plane покрывает всё. Покрытие определяется тем, какие плоскости включены и какие классы рисков они рассматривают. Новые классы инъекций, новые типы утечек через side channels, паттерны использования, которых не было при проектировании, — всё это дыры, которые control plane не закроет автоматически. Честная граница — это признание того, что защита отстает от атаки всегда.
Как читать курс
Главы 1–9 — плоскости контроля, каждая самостоятельна и даёт рабочий паттерн. Глава 10 собирает их в операционную модель и reference-архитектуру «Ковчега» целиком. Порядок рекомендованный, но не жёсткий: если горит приватность или доступ — начинайте с 1–2; если горит регулятор — с 6; если строите агентов — с 9. Сквозной кейс «Ковчег» проходит через все главы, чтобы паттерны собирались в одну систему, а не в россыпь разрозненных решений.
Полный курс AI Governance: https://www.dobryakov.com/howto/ai-governance-control-plane.html
Если вы ставите ИИ в прод под регуляторный риск — у вас есть два пути. Написать политику на сорок страниц и молиться, что ни один инженер не забудет про неё в следующий релиз. Или поставить control plane, через который запрос не проходит без маскирования, проверки прав и аудита. Штрафы EU AI Act считаются от оборота. Политика в SharePoint не остановит ни одного из них.