Глава 11. Итог: операционная модель комплаенса и кросс-юрисдикционная матрица | Григорий Добряков

Григорий Добряков

Курс · AI Compliance

Глава 11Курс AI Compliance

Глава 11. Итог: операционная модель комплаенса и кросс-юрисдикционная матрица

Capstone. Собирает главы 1–10 в операционную модель: не «прошли аудит», а «продукт непрерывно находится в состоянии соответствия».

Ситуация на «Компасе»

«Компас» прошёл весь путь: определил, что попадает под закон (гл. 1), классифицировался как high-risk (гл. 2), построил RMS, data governance, документацию, oversight и логи (гл. 3–4), распределил роли по цепочке (гл. 5), закрыл прозрачность (гл. 6) и due diligence по модели (гл. 7), собрал досье и заверил соответствие (гл. 8), разобрался с США, UK и остальным миром (гл. 9–10). Возникает соблазн выдохнуть: «Прошли».

И тут — главная ловушка комплаенса. Продукт меняется, модель под капотом обновляется, рынки прибавляются, регуляторика движется (Колорадо урезали за две недели, Omnibus сдвинул даты, Канада уронила закон). Соответствие — не точка, в которую пришли, а состояние, которое либо поддерживают, либо теряют. Эта глава — про механизм, который держит состояние.

Что говорит норма (сводно)

Соответствие в AI Act по своей конструкции процессное, а не разовое: Risk Management System (Art. 9) прямо описана как непрерывный процесс на весь жизненный цикл, а post-market monitoring (Art. 72) обязывает следить за системой в эксплуатации. Существенная модификация системы (связь с Art. 25, гл. 5) запускает conformity-оценку заново — то есть каждое крупное изменение продукта или модели возвращает вас к части обязательств. Мульти-юрисдикционность (гл. 9–10) добавляет второе измерение: один baseline плюс дельты, которые тоже живут и меняются.

Как это ложится на продукт

«Компас» собирает кросс-юрисдикционную матрицу целиком: строки — рынки (EU, штаты США, UK, далее по мере экспансии), столбцы — триггеры (скоринг-найм, чат-бот, foundation-модель), на пересечении — что требуется и текущий статус. Это операционализация карты из глав 9–10.

Поверх матрицы — операционная модель комплаенса: у соответствия есть владелец; изменение продукта, смена foundation-модели, выход на новый рынок или сдвиг регуляторики — это явные триггеры пересмотра, а не события, которые проходят незамеченными. Досье поддерживается живым: статусы в реестре, а не «раз в год вспомнили перед аудитом». Здесь курс прямо опирается на принцип из корневого CLAUDE.md — явные переходы состояний (статус в реестре) вместо логики, спрятанной в чьей-то голове.

Стык с соседним курсом ai-governance: там, где эта модель требует технической реализации — неизменяемые аудит-логи (гл. 4), непрерывный eval качества/дрейфа, policy-as-code для классификации, — она ложится на control plane. Комплаенс-состояние держится не силой воли, а инфраструктурой. Кросслинки — в _crosslinks.md.

Артефакт главы и всего курса — compliance operating model: реестр «системы × юрисдикции × статусы» плюс список триггеров пересмотра и назначенный владелец.

Где ломается

Матрица без владельца и триггеров протухает. Комплаенс-долг копится тихо, как техдолг: модель обновили — bias-профиль поехал; рынок добавили — строку в матрице забыли; закон изменили — снимок устарел. Реестр, который никто не обязан обновлять, к следующей проверке уже неверен.

«Существенная модификация» снова серая. Когда обновление foundation-модели или доработка скоринга требует повторной conformity-оценки — вопрос трактовки (гл. 5). Порог легко недооценить и пропустить перезапуск обязательств.

Регуляторный дрейф. Новые акты, сдвиги дат, урезания законов — матрица должна иметь процесс обновления, а не быть разовым снимком. Без этого «карта мира» из глав 9–10 устаревает незаметно.

Что делать инженеру/продакту

Оформить комплаенс как реестр с явными статусами и триггерами (изменение системы, смена модели, новый рынок, изменение регуляторики), а не как ежегодный проект с датой окончания. Назначить владельца и привязать пересмотр к релиз-процессу — тогда соответствие живёт в пайплайне, а не в календаре аудитора.

Свести воедино артефакты всех глав (applicability memo, classification record, RMS, technical file, transparency map, due diligence, DoC, ISO-трек) в одно досье и одну матрицу — это и есть рабочая операционная модель «Компаса».

Провокация

Комплаенс — не проект с датой завершения, а свойство продукта, которое либо поддерживается, либо деградирует. Компания, которая «прошла аудит» и выдохнула, к следующей проверке уже не соответствует — потому что продукт, модель и закон ушли вперёд, а состояние никто не держал. Настоящий результат этого курса — не пройденный аудит «Компаса», а механизм, при котором «Компас» остаётся соответствующим, пока меняются он сам и мир вокруг него.

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

Ставите ИИ-продукт под регуляторным риском?

Разбор вашего продукта по EU AI Act: класс риска, роль в цепочке поставки, обязательства и досье — как проектное ограничение на входе, а не проверка юриста в конце.

Написать на почту

Движок перехода

Next Move Engine — система, которая доводит команду до автономного цикла доставки.

Next Move Engine →