EU AI Act — общеевропейский регламент об искусственном интеллекте, который закрепляет риск-ориентированный подход к ИИ-системам. Он определяет роли участников (провайдеры, внедряющие организации, дистрибьюторы и т. п.), вводит категории риска (запрещённые практики, high-risk, ограниченный риск, минимальный) и устанавливает обязанности по документированию, тестированию, маркировке и мониторингу систем. Практическая цель — сделать внедрение ИИ предсказуемым и проверяемым, а риски — управляемыми.
Материал ниже — прикладной гид для продакт-, ML- и compliance-команд. Мы объясняем механику регламента и даём инструменты, которыми реально пользоваться в проде: таблицы «роль → обязанность», чек-листы запуска, примеры артефактов и частые вопросы. Технические термины связываем с нашими базовыми страницами: архитектура моделей трансформер и LLM, практики генеративных систем генеративный ИИ, эксплуатация в стеке инференс и прикладной контур поиска знаний (RAG с эмбеддингами и векторными БД).
Короткая вводка: зачем бизнесу EU AI Act
- Предсказуемость внедрения. Понятная типология рисков и список обязательных процедур — от управления данными до мониторинга качества.
- Инжиниринг «по правилам». Регламент закрепляет то, что и так нужно для продакшена: метрики, логи, трейсинг, стабильные форматы и жизненный цикл моделей.
- Доверие и экспорт. Соответствие европейским требованиям упрощает продажи и партнёрства на рынках ЕС.
- Снижение юридической неопределённости. Роли и ответственность распределены заранее — меньше неожиданных претензий.
Важно: регламент касается не только «лабораторий», но и внедряющих компаний, использующих API/SDK сторонних моделей.
Базовые понятия (как читать документ)
AI system. Любая система, строящая выводы/предсказания на основе данных с автономными функциями принятия решений или поддержки решений. В современном проде это, например, сервисы на базе LLM и мультимодальные конвейеры на трансформере.
General-purpose AI (GPAI) / foundation models. Модели общего назначения, пригодные для широкого спектра задач (чаты, анализ, код и пр.). Для них регламент вводит отдельные обязанности по документации, тестированию и обмену информацией по рискам.
Роли участников.
- Провайдер (provider). Тот, кто разрабатывает/выпускает систему ИИ (или существенным образом изменяет её).
- Внедряющий/эксплуатирующий (deployer). Организация, которая использует систему ИИ в своём бизнес-процессе или продукте.
- Импортёр/дистрибьютор. Лица, вводящие систему ИИ на рынок ЕС или распространяющие её.
- Авторизованный представитель. Лицо в ЕС, уполномоченное действовать от имени провайдера.
Категории риска.
- Запрещённые практики. Узкая группа сценариев (манипулятивные техники, социальное скорингование и т. п.), которые нельзя применять в ЕС.
- High-risk AI. Системы, влияющие на безопасность, права и доступ к ключевым услугам (например, отбор кандидатов, критическая инфраструктура, медицина, образование, доступ к базовым услугам, некоторые биометрические задачи).
- Ограниченный риск. Требуют прозрачности/маркировки (например, генеративные интерфейсы с синтетическими медиа — «deepfakes»).
- Минимальный риск. Большинство повседневных функций без значимых юридических обязанностей, но с общими принципами добросовестности.
Архитектура регламента: как складывается соответствие
EU AI Act задуман как поток инженерных процедур на протяжении всего жизненного цикла системы — от проектирования до эксплуатации и вывода из эксплуатации:
- Управление рисками. Выявление/оценка/смягчение рисков, ревизия при изменениях модели или данных.
- Управление данными. Качество тренировочных/валидационных/тестовых наборов; учёт происхождения данных, лицензий и ограничений использования.
- Техническая документация. Описание модели, пределов применения, метрик качества, тестов и известных рисков; инструкции для внедряющих.
- Прозрачность и информирование. Понятное описание возможностей/ограничений, маркировка синтетического контента (где требуется), инструкции для человека-оператора.
- Человеческий контроль (human oversight). Роли и процедуры вмешательства человека, особенно для high-risk.
- Кибербезопасность и устойчивость. Защита от атак, валидация поведения при сбоях, управление доступами.
- Логирование и пост-рыночный мониторинг. Журналы событий/решений, сбор инцидентов, регулярные отчёты, механизмы отзывов/патчей.
На практике это накладывается на ваш производственный контур: стек ИИ, сервис инференса, пайплайны данных и операционные процедуры.
Карта «роли → обязанности» (упрощённо)
| Роль | Ключевые обязанности | Артефакты/процедуры |
| Провайдер (provider) | Управление рисками, тестирование и документация модели/версий; информационное сопровождение внедряющих; механизмы мониторинга и обновлений | Техническое досье (описание модели, пределы применения, метрики); Release-notes; инструкции для deployer; отчёты по инцидентам |
| Внедряющий (deployer) | Использование по назначению; оценка контекста применения; логирование и мониторинг в проде; информирование пользователей; маркировка (где требуется) | Регистры использования; журналы инференса; пользовательские уведомления; процедуры эскалации |
| Импортёр/дистрибьютор | Проверка комплектности документации; контроль маркировки/соответствия; взаимодействие с регуляторами | Чек-листы приемки; подтверждения соответствия |
| GPAI/foundation-провайдер | Дополнительные требования к документации, evals, безопасностям и обмену информацией (в т. ч. для интеграторов) | Карточки модели, отчёты об оценке, сводки по данным/ограничениям, рекомендации по безопасному использованию |
High-risk AI: «скелет» требований к продуктовой инженерии
High-risk-системы подпадают под расширенный набор процедур. В инженерных терминах это означает:
- Системный риск-менеджмент. Живой документ: список рисков → меры смягчения → ответственные → сроки пересмотра.
- Управление данными. Минимизируйте шум и смещение, фиксируйте источники и лицензии, следите за обновляемостью наборов.
- Качество и метрики. Чёткие KPI качества и устойчивости: точность, полнота, чувствительность, устойчивость к сдвигам данных.
- Наблюдаемость. Логи, трейсы, «чёрные ящики» для объяснимости, мониторинг деградаций.
- Human oversight. Определённые точки вмешательства; право отмены/пересмотра результата.
- Кибербезопасность. Тестирование на устойчивость к атакам/инъекциям, защита цепочек поставок.
Заметьте, что это совпадает с нормальной зрелой эксплуатацией ИИ-сервисов: регламент закрепляет хорошую инженерную практику.
GPAI и foundation-модели: что меняется для LLM-провайдеров
Если вы публикуете/развёртываете модель общего назначения (например, большую LLM), добавляются обязанности:
- Технические карточки модели. Ключевые характеристики, назначение, ограничения и известные риски.
- Eval-процедуры. Оценки на релевантных наборах задач (качество, безопасность, устойчивость).
- Рекомендации для интеграторов. Как безопасно встраивать модель в продукты; известные анти-паттерны.
- Происхождение данных и права. Описание классов данных/источников и юридические ограничения их использования.
- Инциденты и патчи. Каналы отчётности, исправления и «deprecation policy».
Эти артефакты ускоряют внедрение и уменьшают риск неправильного применения модели downstream-командами.
Прозрачность и маркировка: что просит регламент
- Синтетический контент. Ясная маркировка медиаматериалов, созданных/существенно изменённых ИИ, особенно при риске ввода в заблуждение.
- Информирование пользователя. Пользователь должен понимать, что общается с ИИ; где уместно — иметь доступ к человеческой точке контакта.
- Ограничения по доменам. Высокочувствительные сценарии (биометрия, критические решения) требуют повышенной прозрачности/проверяемости.
Для генеративных продуктов на GenAI это означает: чёткие контракты вывода, валидация до отдачи и хранение атрибутов происхождения данных/ответа.
Как EU AI Act накладывается на ваш AI-стек
| Слой стека | Что требует регламент | Что делать на практике |
| Данные | Качество, происхождение, лицензии | Манифест данных, дедуп, фильтры, версии наборов |
| Модель | Оценки/метрики, пределы применения | Карточка модели, «золотой набор», отчёты об eval |
| Инференс | Логирование, воспроизводимость | Журналы запросов/ответов, контроль версий, трейсинг |
| Оркестрация | Управление рисками/обновлениями | Канарейки, фичефлаги, процедуры отката |
| UX/Прозрачность | Информирование, маркировка | UI-маркировка синтетики, политики пользователя |
| Пост-мониторинг | Инциденты, деградации | SLA/SLO, алерты, root-cause, политики патчей |
См. также эксплуатационную плоскость инференса и роли/интерфейсы слоёв в AI-стеке.
Чек-листы соответствия
A) Любая команда, использующая ИИ (минимум за 2 недели)
- Определите назначение и границы применения системы (Business Use Case).
- Составьте реестр данных: источники, лицензии, даты обновления.
- Введите логирование запросов/ответов и версий модели/шаблонов.
- Подготовьте пользовательскую информацию (что делает ИИ, ограничения, контакт человека).
- Настройте маркировку синтетики (если релевантно).
- Заведите процесс post-market-мониторинга: сбор инцидентов, алерты, регулярные отчёты.
B) High-risk-сценарии (расширенный минимум)
- Полный риск-реестр (идентификация → смягчение → владелец → пересмотр).
- Карточка модели с метриками, известными рисками и условиями использования.
- Human oversight: кто и как может отменить/пересмотреть решение.
- Кибербезопасность: тесты на инъекции/отравление данных, контроль доступа/ключей.
- План отката: rollback/feature-flags и коммуникации для пользователей/партнёров.
C) GPAI/foundation-модели (для провайдеров)
- Публичные карточки модели и eval-отчёты.
- Сводка классов тренировочных данных и ограничений.
- Руководство по безопасной интеграции для внедряющих.
- Канал репортинга инцидентов и политика обновлений.
Таблица соответствия «риск → обязанности» (сигналы для практики)
| Категория | Обязанности (в общих чертах) | Практические маркеры готовности |
| Запрещённые практики | Не допускаются | Политика запретов, статическая/динамическая проверка фич |
| High-risk | Полный набор процедур (данные, документация, oversight, мониторинг) | Риск-реестр; карточка модели; журналы; канарейки; отчёты |
| Ограниченный риск | Прозрачность/маркировка | UI-маркировка; уведомления; журнал выдачи синтетики |
| Минимальный | Рекомендации добросовестности | Базовое логирование; инфо для пользователя |
Интеграция с LLM-продуктами и RAG-конвейерами
- Сокращайте контекст и храните ссылки на источники (ID фрагментов), если используете RAG. Это повышает проверяемость и облегчает аудит.
- Контракты вывода (JSON/таблицы) снижают долю неформата и упрощают пользовательскую прозрачность (что именно система «решила»).
- Разделяйте очереди и профили (light/standard/heavy), чтобы управлять задержками и бюджетом — эксплуатационная дисциплина полезна и для соответствия (трассируемость, объяснимость).
- Храните версии модели/шаблонов/ретривера: это ядро воспроизводимости в аудитах.
Частые ошибки и как их исправить
| Ошибка | Чем грозит | Исправление |
| Нет документации назначения/ограничений | Неправомерное применение модели downstream | Ввести карточку модели и инструкцию для внедряющих |
| Отсутствует логирование | Невозможность аудита/разбора инцидентов | Включить трейсинг, хранить версии и артефакты |
| Нет маркировки синтетики | Риск введения в заблуждение | Встроить маркировку/подпись на уровне пайплайна |
| Смешение очередей | Взрыв P95 и «слепые зоны» мониторинга | Развести chat/long/offline, ввести профили |
| Нет human oversight | Некорректные решения без пути эскалации | Назначить роли/процедуры вмешательства |
| «Сырые» данные | Смещения, нестабильность | Манифесты источников, фильтры, регулярные ревизии |
Примеры артефактов (что реально хранить)
- Release-notes модели (версия, дата, изменения, влияние на метрики/риски).
- Data-manifest (список наборов, лицензии, последние обновления, ответственные).
- Eval-отчёт (наборы задач, метрики качества/безопасности, выводы).
- Инцидент-лог (тип события, канал получения, статус, исправления).
- User-facing notice (для прозрачности и маркировки).
Вопросы совместимости с другими правилами
- Регламент проектировался так, чтобы стыковаться с существующими рамками приватности данных и кибербезопасности.
- Для финансовых/платёжных кейсов учитывайте отраслевые требования и внутренние политики клиентов.
- Для ИИ-продуктов, работающих с персональными данными, делайте акцент на минимизации, анонимизации и контроле хранения.
FAQ
Применяется ли EU AI Act к компаниям вне ЕС? Да, если вы выводите систему на рынок ЕС или её использование затрагивает пользователей/услуги в ЕС (включая удалённое предоставление).
Если я использую стороннюю LLM через API, я — провайдер или внедряющий? Обычно вы — внедряющий (deployer). Но если вы «существенно изменяете» систему (дообучение, новая цель/сервис) — часть обязанностей провайдера может перейти к вам.
Что делать стартапу на ранней стадии? Начните с минимального набора соответствия: назначение/границы, реестр данных, логирование, инфо пользователю, маркировка синтетики (если есть), простой риск-реестр. Затем наращивайте процедуры по мере роста критичности.
Как понять, что мой кейс — high-risk? Сверьтесь с перечнем доменов/сценариев высокой важности. Если система влияет на безопасность/права/доступ к ключевым услугам — скорее всего, это high-risk.
Нужно ли «полное соответствие» для MVP? Если вы не в high-risk, достаточно базового уровня прозрачности и логирования, но стоит сразу строить процессы «с запасом»: это дешевле, чем ретрофит в проде.
Как быть с генерацией изображений/видео («deepfakes»)? Для ограниченного риска — обязательна маркировка и чёткое информирование пользователя.
Словарь терминов
- AI system — система, выполняющая предсказания/решения на основе данных автономно или полуавтономно.
- GPAI / foundation model — модель общего назначения (например, крупная LLM). См. LLM и генеративный ИИ.
- High-risk AI — система с повышенными обязанностями (данные, документация, oversight, мониторинг).
- Human oversight — процедурный контроль и право человека вмешаться/переопределить результат.
- Маркировка синтетики — обозначение искусственно созданного/изменённого контента.
- Пост-рыночный мониторинг — сбор инцидентов/деградаций, отчётность и патчи.
- Карточка модели — документ с назначением, метриками, ограничениями, рисками и релиз-историей.
- Eval — оценка качества/безопасности на релевантных наборах.
- Инференс — эксплуатационное выполнение модели; см. инференс.