EU AI Act за 90 дней: таблица соответствия «статья → функция Krasper Raigate»

Коротко. EU AI Act перестал быть проблемой будущего. Его обязательства для систем высокого риска действуют, и большинство компаний, наспех внедривших языковые модели в 2023–2024 годах, сейчас находятся не на той стороне статей 9–15. Этот материал — рабочее сопоставление: каждая статья, что она требует в операционных терминах и как это закрывает прозрачный слой управления вроде Krasper Raigate. Плюс план на 90 дней в трёх фазах для тех, кто стартует поздно.

Содержание

1. Часы соответствия, которые вы уже должны были запустить
2. Классификация рисков: куда на самом деле попадает использование языковых моделей
3. План на 90 дней в трёх фазах
4. Сопоставление кратко
5. Обязательства до внедрения (статьи 9, 10, 11)
6. Операционные обязательства (статьи 12, 13, 14)
7. Обязательства по качеству (статья 15)
8. Взгляд эксплуатанта (статья 26)
9. Что на самом деле дают 90 дней
10. Источники и сам текст регламента

1. Часы соответствия, которые вы уже должны были запустить

EU AI Act вступил в силу 1 августа 2024 года. Ключевые даты для любой организации, использующей языковые модели в продуктиве:

• 2 февраля 2025: вступают в силу запреты на ИИ неприемлемого риска и обязательства по грамотности сотрудников в области ИИ.
• 2 августа 2025: вступают в силу обязательства для моделей общего назначения (GPAI) и их поставщиков.
• 2 августа 2026: вступает в силу основная масса обязательств для систем высокого риска, включая весь вес статей 9–15.
• 2 августа 2027: обязательства высокого риска распространяются и на ИИ, который является компонентом безопасности продуктов, регулируемых другими актами ЕС.

Соблазнительно считать обязательства высокого риска задачей на будущее. Это не так: доказательства соответствия ретроспективны. Когда в 2027 году надзорный орган откроет дело, он спросит, как выглядело ваше управление в 2026-м, и понадобятся записи, а не заверения. Значение имеет первый день, за который вы можете доказать, что контроли работали, и для большинства организаций он уже прошёл.

Именно поэтому план на 90 дней вообще реалистичен: основная работа — в инструментировании и доказательствах, а не в написании новой политики с нуля. Если у вас есть прозрачный слой управления, значительная часть доказательств уже возникает как побочный продукт обычного трафика.

2. Классификация рисков: куда на самом деле попадает использование языковых моделей

Первый вопрос — классифицируется ли конкретный сценарий как высокорисковый по регламенту. Дерево решений:

Большинство корпоративных внедрений языковых моделей попадает в одну из двух категорий. Высокий риск, если сценарий указан в Приложении III: отбор персонала, кредитный скоринг, образование и оценка экзаменов, управление критической инфраструктурой, поддержка правоохранительной деятельности, миграция и убежище, судебные решения. Ограниченный риск, если ИИ взаимодействует с людьми (чат-бот поддержки, генератор контента, чьи тексты или изображения получают конечные пользователи). Модели общего назначения, встроенные в любую из категорий, наследуют обязательства той категории, в которой развёрнуты.

Ошибка — считать, что «мы просто используем ChatGPT внутри для продуктивности» помещает вас в корзину минимального риска. Как только это внутреннее использование возвращает результат в решение высокого риска (шорт-лист кандидатов, кредитная оценка, сортировка клиентских претензий), обязательства высокого риска распространяются и на языковую модель.

3. План на 90 дней в трёх фазах

Три фазы по тридцать дней с явными результатами:

Фазы идут последовательно, потому что каждый артефакт опирается на предыдущий. Нет смысла инструментировать контроли, пока не известно, каким сценариям они нужны, а систему нельзя задокументировать, пока этих контролей нет. Утверждение идёт последним, потому что ответственные за систему должны ратифицировать документацию, иначе она ничего не значит.

4. Сопоставление кратко

Компактное сопоставление по операционным статьям:

• Ст. 9: система управления рисками. Требуется: непрерывно выявлять, оценивать и снижать риски на протяжении жизненного цикла ИИ-системы. Даёт прокси: реестр активов с уровнями риска по каждой зарегистрированной системе; процесс периодического пересмотра с записями решений.
• Ст. 10: управление данными. Требуется: обучающие, валидационные и тестовые данные должны отвечать критериям качества; происхождение и смещения должны исследоваться. Даёт прокси: в части управления во время инференса он обеспечивает, чтобы данные, покидающие организацию в сторону сторонней модели, соответствовали правилам защиты данных, с политиками, срабатывающими до отправки запроса.
• Ст. 11: техническая документация. Требуется: вести техническую документацию, подтверждающую соответствие, доступную надзорным органам. Даёт прокси: наборы политик, аудиторские следы и отчёты оценок, выгружаемые как пакет соответствия.
• Ст. 12: ведение записей. Требуется: автоматическая запись событий («логов») для прослеживаемости работы системы. Даёт прокси: аудиторские события на каждый вызов с цепочкой хешей для выявления подмены; хранение только на добавление.
• Ст. 13: прозрачность и информирование эксплуатантов. Требуется: предоставлять ясную и достаточную информацию о возможностях, ограничениях и предполагаемом использовании системы. Даёт прокси: документацию по каждой системе в интерфейсе управления; эндпоинты трассировки, показывающие, какая политика применялась к какому вызову.
• Ст. 14: человеческий надзор. Требуется: обеспечить человеческий надзор; люди должны понимать выводы системы и иметь возможность вмешаться. Даёт прокси: процессы согласования со сроками; средства переопределения; явную запись в аудите «это решение принял / переопределил [субъект]».
• Ст. 15: точность, устойчивость, кибербезопасность. Требуется: достигать и поддерживать надлежащий уровень точности, устойчивости и кибербезопасности. Даёт прокси: фреймворк оценок для периодического тестирования; меры кибербезопасности, встроенные в сам прокси (отказ в закрытое состояние, подписанные наборы политик, обратные пути с ограничением по ролям).

Дальше каждая статья разбирается в операционных терминах: что она требует на практике, где обязательство ложится операционно и что конкретно есть, когда слой управления развёрнут как следует.

5. Обязательства до внедрения (статьи 9, 10, 11)

Статья 9: управление рисками

Регламент требует системы управления рисками, а не разовой оценки. Различие существенно: система — это документированный процесс, который работает непрерывно на протяжении жизненного цикла ИИ, с пересмотрами по времени или по существенному изменению.

Операционное ядро — реестр активов: каждая ИИ-система в организации является зарегистрированной записью с определённым уровнем риска (низкий / средний / высокий / критический), определённым владельцем, описанным графом зависимостей (какие наборы данных её питают, какие системы потребляют её вывод) и заданной периодичностью пересмотра. При существенном изменении (новая версия модели, новый источник данных, новый контекст развёртывания) пересмотр запускается автоматически и фиксируется новое решение.

Что спросит надзорный орган: «Покажите оценку рисков этой ИИ-системы в том виде, в каком она была восемь месяцев назад». Что нужно предъявить: версионированную запись из реестра активов с датированными решениями, обоснованием и людьми, которые их утвердили.

Статья 10: управление данными

Для обучающих данных регламент задаёт критерии релевантности, репрезентативности, отсутствия ошибок и статистических смещений. Большинство компаний, использующих языковые модели, свои модели не обучает, но зубы у статьи 10 всё равно есть: данные, которые ваши приложения отправляют в стороннюю модель, сами по себе вопрос управления.

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

Статья 11: техническая документация

Приложение IV перечисляет, что должна охватывать техническая документация: общее описание ИИ-системы, проектные спецификации, требования к данным, методологию обучения (где применимо), процедуры валидации и тестирования, метрики точности и устойчивости, меры кибербезопасности и архитектуру системы.

Для эксплуатанта практический ответ — вести один пакет соответствия на каждую ИИ-систему со всеми этими разделами и, где возможно, генерировать его, а не писать руками. Аудиторские следы, версии политик и отчёты об оценках — это доказательства, а не повествование. Повествование оборачивается вокруг доказательств; несущая часть — доказательства.

6. Операционные обязательства (статьи 12, 13, 14)

Статья 12: ведение записей

Статья 12 тихо меняет то, как вообще должны строиться ИИ-системы. Она требует автоматического логирования событий, позволяющего проследить работу системы. Стандарт, к которому на практике сходятся регуляторы: логи, устойчивые к подмене, доступные только на добавление и пригодные для восстановления.

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

Пример аудиторского события с явными ссылками на статьи:

Поле compliance_refs и делает аудиторский след полезным для регулятора. Когда орган просит доказательства по надзору из статьи 14, вы запрашиваете в хранилище аудита события, где compliance_refs содержит EU_AI_ACT_ART_14, и предъявляете их.

Статья 13: прозрачность для эксплуатантов

Статья 13 обязывает поставщиков высокорисковых ИИ-систем давать эксплуатантам ясную и достаточную информацию. Со стороны эксплуатанта зеркальное обязательство — правильно эту информацию использовать: знать, что система может и чего не может, каковы её ограничения и где проходят границы предполагаемого применения.

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

Статья 14: человеческий надзор

Статья 14 — одна из самых операционно конкретных в регламенте. Она требует, чтобы физические лица могли эффективно надзирать за ИИ-системой, понимать её выводы, вмешиваться при необходимости и игнорировать или переопределять её решения. В понятие «физические лица» входят как сотрудники эксплуатанта, так и, в зависимости от контекста, затронутые конечные пользователи.

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

7. Обязательства по качеству (статья 15)

Статья 15: точность, устойчивость, кибербезопасность

Статья 15 замыкает круг. Предыдущие статьи описывают, что система должна делать; статья 15 — насколько хорошо она это делает на самом деле и насколько устойчив этот результат.

Три подобязательства:

• Точность. Система должна достигать надлежащего уровня точности для своего назначения, а метрики измерения точности должны быть объявлены в технической документации.
• Устойчивость. Система должна быть устойчива к ошибкам, сбоям и несогласованностям, включая враждебные входные данные и данные вне обучающего распределения.
• Кибербезопасность. Система должна проектироваться и разрабатываться так, чтобы обеспечивать надлежащий уровень кибербезопасности на протяжении жизненного цикла.

Операционно это ложится на три компонента. Фреймворк оценок прогоняет периодические наборы тестов против развёрнутой системы и выдаёт отчёты о точности, привязанные к версии модели и версии набора политик. Монитор дрейфа следит за продуктивным трафиком на предмет сдвигов распределения, обесценивающих заявленную точность. Базовый уровень кибербезопасности включает сам прокси: умолчания с отказом в закрытое состояние, подписанные наборы политик, обратные пути с ограничением по ролям, mTLS для трафика между сервисами и подтверждение цепочки поставки для артефактов развёртывания.

8. Взгляд эксплуатанта (статья 26)

Большинство описанных выше обязательств адресовано поставщикам высокорисковых ИИ-систем. Статья 26 — статья эксплуатанта: у организации, которая использует такую систему, есть собственные обязанности, включая использование системы по назначению, мониторинг её работы, обеспечение человеческого надзора, хранение логов не менее шести месяцев и уведомление органов о серьёзных инцидентах.

Для организации, встраивающей стороннюю языковую модель в высокорисковый процесс, это зеркальное отражение статей 9–15. Поставщик отвечает за модель. Эксплуатант отвечает за то, что он с этой моделью делает. Аудиторский след, который производит слой управления, — основная доказательная база эксплуатанта по статье 26.

9. Что на самом деле дают 90 дней

Девяноста дней хватает, чтобы перейти от отсутствия обоснованной позиции по соответствию к обоснованной позиции организации, которая использует языковые модели и не готовилась к AI Act заранее. Их не хватает, чтобы построить собственную платформу управления с нуля, поэтому почти каждое успешное 90-дневное внедрение опирается на уже готовый прозрачный слой управления, который остаётся настроить.

Что у вас будет через 90 дней при хорошем исполнении:

• Полная инвентаризация сценариев использования ИИ с классификацией по уровню риска
• Слой управления, применяющий контроли статей 9, 10 и 13 к продуктивному трафику
• Аудиторский след, удовлетворяющий статье 12, с цепочкой хешей против подмены
• Процессы согласования для надзора по статье 14
• Базовые замеры для отчётности о точности и устойчивости по статье 15
• Пакет соответствия, который можно передать аудитору, внутреннему комитету по рискам или закупкам заказчика

Чего у вас не будет через 90 дней — закрытой задачи. Обязательства регламента непрерывны, и 90 дней лишь доводят вас до точки, с которой их можно начать выполнять по-настоящему.

10. Источники и сам текст регламента

Полный текст Регламента (ЕС) 2024/1689 опубликован в Официальном журнале Европейского союза и свободно доступен на EUR-Lex. Статьи, упомянутые в материале:

• Статья 5 (запрещённые практики ИИ)
• Статья 6 и Приложение III (высокорисковые ИИ-системы)
• Статья 9 (система управления рисками)
• Статья 10 (данные и управление данными)
• Статья 11 (техническая документация)
• Статья 12 (ведение записей)
• Статья 13 (прозрачность и предоставление информации эксплуатантам)
• Статья 14 (человеческий надзор)
• Статья 15 (точность, устойчивость и кибербезопасность)
• Статья 26 (обязанности эксплуатантов высокорисковых ИИ-систем)
• Статья 50 (обязательства прозрачности для поставщиков и эксплуатантов отдельных ИИ-систем)

Чтение исходного текста занимает больше времени, чем любой пересказ, включая этот, но для тех частей, которые реально влияют на решение о внедрении, к первоисточнику стоит обращаться напрямую.