Штрафы AI Act до 7% выручки: комплаенс пора встраивать в ML-пайплайн

Штраф за нарушение запретов EU AI Act достигает 35 млн евро или 7% мирового годового оборота, за остальные нарушения — до 15 млн евро или 3%. На этом фоне KDnuggets публикует короткий, но показательный тезис: модель может быть одновременно передовой и соответствующей нормам, если перестать считать governance последним барьером перед релизом и встроить его в каждый этап ML-пайплайна. Оригинал — краткий анонс без метрик и кейсов, поэтому ниже разбор того, как эта идея выглядит на практике.

Почему проверка перед релизом ломается

Типичный сценарий знаком почти любой команде. Data science обучает модель, выбирает метрики, выкатывает на стейджинг. Затем подключаются юристы и риск-менеджеры. Оказывается, что у датасета нет документированного происхождения, решения модели не логируются, а один из признаков коррелирует с защищённым атрибутом. Итог: недели переработки или заморозка проекта.

Для высокорисковых систем AI Act требует управления данными, технической документации, логирования, человеческого надзора, а также заданного уровня точности и устойчивости. Часть этого нельзя воссоздать ретроспективно: историю данных и условия обучения, которые не записывались, не восстановить. Сроки применения отдельных положений обсуждаются и корректируются, но состав требований известен заранее. Ждать финального аудита нет смысла.

Что встраивать на каждом этапе

Практическая рамка уже существует. NIST AI RMF описывает четыре функции: Govern, Map, Measure, Manage. ISO/IEC 42001, опубликованный в декабре 2023 года, задаёт требования к системе управления ИИ в организации. Осталось привязать их к стадиям пайплайна:

• Данные: lineage, лицензия и основание для использования, версия датасета, отчёт о перекосах по группам.
• Обучение: зафиксированные конфиги и seed, трекинг экспериментов, воспроизводимая сборка.
• Валидация: метрики качества в разрезе подгрупп (например, разница TPR и FPR между ними), тесты на устойчивость, red-teaming для генеративных моделей.
• Деплой: model card, подписанный артефакт, согласование релиза с названным владельцем риска.
• Эксплуатация: мониторинг дрейфа, логи решений, пороги алертов, процедура отката, человек в контуре там, где это требуется.

Ключевой приём — превратить чек-лист в автоматику. Если в репозитории нет актуальной model card или отчёт о смещениях хуже заданного порога, CI-пайплайн падает, как при провалившихся юнит-тестах. Комплаенс становится частью инженерной дисциплины, а не бумажной процедурой.

Где подводные камни

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

С чего начать

Начните с инвентаризации: список всех моделей в продакшене и в разработке, у каждой есть владелец и уровень риска. Выберите одну высокорисковую модель и пройдите на ней весь путь. Введите единый шаблон model card. Добавьте два-три автоматических гейта в CI: наличие документации, отчёт о смещениях, проверка логирования. Определите, кто имеет право остановить релиз. Когда процесс заработает на одной модели, масштабировать его на остальные будет проще, чем писать регламент с нуля для всего портфеля сразу.