Манифест: комплаенс — это проектное ограничение, а не проверка в конце

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

Без жаргона: AI compliance — это ответ на три вопроса про вашу ИИ-систему.

• Попадаю ли я под регулирование и под какое? Не всякий ИИ регулируется одинаково. Закон смотрит не на то, «умный» ли продукт, а на то, что он делает с людьми: отбирает на работу, оценивает кредит, ставит диагноз — или просто пишет черновики писем.
• Что это включает? Если система попала в строгий класс — какой конкретно список обязанностей на мне: какие документы, какие процессы, какой контроль человека, какая отчётность.
• Как это доказать? Регулятору, аудитору, корпоративному клиенту в RFP — что система реально работает в рамках, а не что вы это пообещали в презентации.

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

Важно, чем комплаенс не является. Это не «запретить ИИ» и не бесконечная бюрократия ради бумаги. Наоборот: понятный регуляторный класс разгоняет команду — потому что убирает неопределённость. Хуже всего не строгий режим, а неизвестный режим, когда никто в компании не знает, high-risk у них продукт или нет, и решение висит до первого письма от регулятора или отказа корпоративного клиента подписать контракт.

Почему «проверить в конце» не работает

Регуляторные требования — не про поведение кода в рантайме, а про свойства системы, которые нельзя добавить постфактум. Систему управления рисками нельзя «дописать за неделю»: она предполагает, что вы анализировали риски, *когда* принимали проектные решения. Data governance нельзя предъявить задним числом: если обучающие данные собраны без учёта репрезентативности и смещений, единственный честный ответ аудитору — «мы не знаем, на чём это училось». Human oversight нельзя приклеить к готовому продукту, где UX построен на полной автоматизации, — это меняет сам продукт.

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

Почему флагман — EU AI Act

Регуляторных режимов много, и они расходятся по философии (об этом — главы 9–10). Но курс строит позвоночник на EU AI Act по трём причинам:

• Он самый структурированный. Риск-ориентированный подход даёт ясную механику: класс риска определяет режим. На нём удобно учиться читать регуляторику вообще.
• Он де-факто глобальный floor, как GDPR. Экстерриториальность означает: если ваш ИИ используется в ЕС — вы под ним, где бы вы ни сидели. Проще строить продукт под самый строгий режим и продавать «AI Act ready», чем поддерживать разные версии.
• У него зубы. Штрафы считаются от глобального оборота (детали — глава 8), а не символические. Это переводит комплаенс из «желательно» в «обязательно».

Остальные режимы — США, Великобритания, Китай, международный слой — идут ближе к концу, как карта горизонта: куда движется индустрия и что задевает продукт при выходе за пределы ЕС. Не параллельные позвоночники, а расширение кругозора через сюжет экспансии «Компаса».

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

1. Compliance-by-design, не bolt-on. Регуляторный класс определяется на этапе замысла и входит в требования, а не выясняется на ревью перед релизом. Это дешевле и это единственное, что масштабируется.

1. Закон — это навык чтения, не аутсорс. Классифицировать систему, определить свою роль в цепочке поставки и вывести из этого список обязательств — то, что продуктовая и инженерная команда должна уметь сама. Внешний юрист проверяет и заверяет; но команда, которая не понимает собственный режим, не может ни проектировать, ни спорить с ним.

1. Честная граница. У регуляторики есть серые зоны: спорные классификации, движущиеся даты вступления в силу, трактовки, по которым ещё нет практики. Раздел «Где ломается» есть в каждой главе. Продакт, который знает, где норма неоднозначна, надёжнее того, кто верит, что «в законе всё написано однозначно».

Провокация

Большинство «AI compliance» на рынке — это театр соответствия наоборот: не построить контроль, а построить *видимость* того, что вопрос под контролем. Компании нанимают консультанта, получают папку политик и считают вопрос закрытым — до момента, когда корпоративный клиент в RFP просит доказательство соответствия, а его нет, потому что политики никогда не были связаны с продуктом. Регулятор и рынок это уже поняли: EU AI Act требует не деклараций, а классификации, документации, логов и систем управления рисками; корпоративные закупки в ЕС требуют ISO/IEC 42001. Компания, у которой комплаенс живёт отдельно от продукта, узнаёт о разрыве в худший момент — на сделке или на проверке.

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

Сквозной кейс — «Компас»

Чтобы регуляторный режим собирался в одну картину, а не в россыпь разрозненных требований, весь курс идёт на одном вымышленном продукте — «Компас». Это HR-tech SaaS: он принимает поток резюме и заявок, скринит их и ранжирует кандидатов для рекрутёров на базе чужой foundation-модели, а с кандидатами общается чат-ботом (статус заявки, уточняющие вопросы). Продаётся международно — ЕС, США, Великобритания. Имя вымышленное, чтобы не путать с реальными продуктами.

«Компас» выбран так, чтобы одним продуктом задеть все узлы EU AI Act:

• Скоринг и ранжирование кандидатов при найме прямо поименованы в Annex III как высокорисковое применение. Это переводит «Компас» в самый строгий класс и включает почти весь список обязательств (главы 3–4). Найм — чистый, неспорный пример high-risk.
• Продукт построен на чужой foundation-модели, а не на своей. Это поднимает вопрос цепочки поставки: «Компас» — provider своей системы, но deployer чужой GPAI-модели; часть ответственности делится с провайдером модели (главы 5, 7).
• Чат-бот с кандидатом — взаимодействие ИИ с человеком, попадает под требование прозрачности (Art. 50): человек должен понимать, что говорит с машиной (глава 6).
• Международные продажи — при выходе на США «Компас» встречает NYC Local Law 144 (обязательный bias-аудит инструментов найма) и Colorado AI Act, в UK — иной, principles-based подход. Это вытягивает главы 9–10 через сюжет, а не приложением.

«Компас» — намеренно требовательный пример: high-risk, чужая модель под капотом, прямой контакт с людьми, чьи карьеры он затрагивает, и три юрисдикции сразу. Если модель комплаенса работает на нём, на менее рискованном продукте она тем более сработает. Каждая глава показывает свой узел режима на «Компасе»; глава 11 собирает их в единую операционную модель.

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

Главы 1–8 — EU AI Act по ходу сюжета продукта: от «попадаем ли мы» до «доказали и живём». Главы 9–10 — мир за пределами ЕС как расширение кругозора. Глава 11 собирает всё в операционную модель и кросс-юрисдикционную матрицу «Компаса». Порядок рекомендованный: если нужно быстро понять свой класс риска — читайте 1–2; если уже знаете, что high-risk, и горит подготовка — 3–4 и 8; если строите на чужой модели — 5 и 7. Сквозной кейс «Компас» проходит через все главы, чтобы режим собирался в одну картину.

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

• Дальше: Scope — Попадаете ли вы: scope и экстерриториальность
• Все главы курса →
• Подключить эксперта как MCP →