EU AI Act Приложение IV: чеклист документации для AI-систем
Прежде чем система AI высокого риска может быть выведена на рынок ЕС, её провайдер должен собрать техническую документацию, демонстрирующую соответствие требованиям EU AI Act. Эта документация не является единовременной подачей — она должна поддерживаться в актуальном состоянии на протяжении всего жизненного цикла системы и предоставляться надзорным органам по запросу.
Приложение IV EU AI Act точно определяет, что должна содержать эта документация. Это один из наиболее конкретных и actionable разделов регулирования — и один из наименее обсуждаемых в инженерных кругах.
TL;DR
- Приложение IV определяет восемь категорий документации, обязательных для систем AI высокого риска
- Документация должна быть собрана до выхода на рынок и поддерживаться в актуальном состоянии на протяжении всей работы
- Ключевые пробелы для развёртываний AI-агентов: определение предполагаемой цели, описание обучающих данных, доказательства управления рисками и процедуры мониторинга
- Документация должна быть «соответствующей цели демонстрации соответствия» — функциональной, а не просто существующей
- Документация Приложения IV напрямую связана со статьями 9, 12, 13, 14, 15 и 17
Восемь категорий документации
Приложение IV определяет восемь категорий технической документации. Для каждой регулирование требует документации, которая является «соответствующей, релевантной и понятной».
Категория 1: Общее описание AI-системы
Обязательное содержание:
- Предполагаемая цель AI-системы
- Название и версия программного обеспечения
- Как AI-система взаимодействует с аппаратным или программным обеспечением, частью которого она не является
- Версии соответствующего программного обеспечения или прошивки и требования к их обновлениям
Для AI-агентов эта категория требует чёткого, конкретного изложения предполагаемой цели, которая соответствует категории высокого риска Приложения III, под которую подпадает система. Расплывчатые формулировки цели («обеспечить поддержку принятия решений») не удовлетворяют этому требованию — вам нужна конкретность относительно того, какие решения, для каких пользователей, в каком контексте.
Категория 2: Спецификации проектирования и процесс разработки
Обязательное содержание:
- Общий дизайн AI-системы (технические спецификации)
- Дизайнерские решения, допущения и ограничения проектирования
- Методологии обучения, техники и основные дизайнерские решения
- Спецификации дизайна для входных данных
- Архитектура модели и используемые вычислительные ресурсы
Для AI-агентов, использующих базовые модели (Claude, GPT-4, Gemini), это требует документации: какая базовая модель используется, какая версия, как вы её настроили (системные промпты, дообучение, если есть), и ограничения, которые вы применили через слой управления. Вам не нужно документировать внутренний дизайн модели Anthropic — вам нужно документировать конфигурацию вашего развёртывания.
Категория 3: Информация об обучении, валидации и тестировании
Обязательное содержание:
- Наборы данных для обучения, валидации и тестирования (или, для систем на основе базовых моделей, применяемые практики управления данными)
- Методы, использованные для проверки обучающих данных
- Метрики точности, устойчивости и другие метрики производительности
- Методология тестирования, включая тестирование на дискриминационные эффекты
Это категория доказательств по статье 15. Результаты тестов, метрики точности, анализ подгрупп и результаты состязательных тестов принадлежат сюда. Для AI-агентов, использующих базовые модели без специального обучения, задокументируйте методологию оценки, применённую перед развёртыванием, и результаты.
Категория 4: Мониторинг, функционирование и контроль
Обязательное содержание:
- Возможности и ограничения AI-системы
- Достигнутый уровень точности, устойчивости и кибербезопасности (и уровень, по которому он измеряется)
- Разумно предсказуемые непреднамеренные использования и предсказуемые злоупотребления
- Процессы, предусмотренные для надзора человека
- Спецификации входных данных и условия, при которых система может давать сбой или производить некорректные результаты
Это одна из наиболее требовательных категорий для развёртываний AI-агентов. Раздел «возможности и ограничения» должен честно документировать, что агент может и что не может надёжно делать — а не только то, для чего он предназначен. Известные режимы сбоя должны быть здесь указаны.
Категория 5: Система управления рисками
Обязательное содержание:
- Резюме рисков, выявленных в соответствии со статьёй 9
- Применённые меры снижения
- Остаточные риски и основание для их принятия
Это категория доказательств соответствия статье 9. Система управления рисками по статье 9 должна быть обобщена в документации Приложения IV, с чёткой записью выявленных рисков, мер снижения и принятия остаточного риска.
Категория 6: Изменения, внесённые в систему
Обязательное содержание:
- Изменения, внесённые в систему в течение её жизненного цикла
- Изменения, предварительно одобренные нотифицированным органом (где применимо)
- Журнал изменений с датами, характером изменений и оценкой влияния на соответствие
Для AI-агентов эта категория требует процесса управления изменениями, документирующего: обновления версий модели, изменения правил управления, расширения области применения и любые архитектурные изменения. Каждая запись должна включать оценку влияния на соответствие — изменяет ли это изменение позицию соответствия системы?
Категория 7: Декларация соответствия ЕС
Ссылка на Декларацию соответствия ЕС — отдельный документ, в котором провайдер заявляет, что AI-система соответствует всем применимым требованиям EU AI Act.
Это формальный юридический документ. Он должен ссылаться на конкретные статьи EU AI Act, относительно которых декларируется соответствие. Для AI-агентов декларация обычно охватывает статьи 9–17 и применимую категорию Приложения III.
Категория 8: План мониторинга после выпуска на рынок
Обязательное содержание:
- Спецификация системы мониторинга после выпуска на рынок
- Сроки и методология мониторинга
- План сбора данных
- Процесс корректирующих действий
Это категория операциональных доказательств соответствия. В плане мониторинга должно быть указано: какие метрики отслеживаются, как часто, кто их проверяет и что запускает корректирующее действие. Это напрямую связано с требованием непрерывного управления рисками по статье 9.
Сводный чеклист
| Категория Приложения IV | Ключевой пробел для AI-агентов | Проверка статуса |
|---|---|---|
| Общее описание | Конкретная предполагаемая цель, отслеживание версий | Является ли ваша предполагаемая цель конкретной и соответствующей Приложению III? |
| Спецификации проектирования | Документация базовой модели | Задокументирована ли конфигурация вашего развёртывания? |
| Обучение/тестирование | Результаты оценки, анализ подгрупп | Есть ли у вас результаты тестов в файле? |
| Мониторинг и контроль | Известные режимы сбоя, надзор человека | Честно ли задокументированы режимы сбоя? |
| Управление рисками | Принятие остаточного риска | Задокументированы ли решения по статье 9? |
| Управление изменениями | Оценки влияния обновлений модели | Запускают ли обновления проверку соответствия? |
| Декларация соответствия | Требуется юридическая проверка | Составлена и подписана ли декларация? |
| Мониторинг после выпуска | Активный план мониторинга | Задокументирован ли ваш план мониторинга? |
Распространённые пробелы в документации
Пробел 1: Предполагаемая цель слишком расплывчата. «Поддержка принятия решений с помощью AI» не является достаточным описанием предполагаемой цели для Приложения IV. Вам нужно: какие решения, принимаемые кем, в отношении кого, в каком процессе, с какими полномочиями принятия решений. Агент кредитных решений должен документировать: автоматизированный предварительный скрининг заявок на потребительские кредиты от лиц с верифицируемым доходом, в ЕС, на суммы до X евро.
Пробел 2: Отсутствует журнал изменений. Развёртывания AI-агентов часто меняются — обновления модели, обновления правил, расширения области применения. Приложение IV требует задокументированного журнала изменений. У многих команд нет систематического механизма для фиксации этого.
Пробел 3: Известные режимы сбоя недостаточно задокументированы. Категория 4 требует документации «условий, при которых система может давать сбой или производить некорректные результаты». Это требует честной документации известных ограничений. Занижение режимов сбоя для создания видимости большей компетентности не соответствует статье 15.
Пробел 4: План мониторинга после выпуска является декларативным. В плане мониторинга должна описываться операциональная система, а не намерение осуществлять мониторинг. Задокументируйте: какие метрики, какие инструменты, какие пороги оповещений, кто проверяет и что происходит, когда срабатывает оповещение.
О операциональных доказательствах, наполняющих документацию Приложения IV, см. EU AI Act Статья 12: требования к логированию и EU AI Act Статья 9: непрерывное управление рисками.
Часто задаваемые вопросы
В: Когда должна быть собрана документация Приложения IV?
До выхода AI-системы на рынок или ввода её в эксплуатацию в ЕС. Для AI-агентов, развёртываемых для пользователей в ЕС или затрагивающих физических лиц в ЕС, это означает до производственного развёртывания. Документация должна поддерживаться в актуальном состоянии на протяжении всей работы системы.
В: Как долго должна храниться документация Приложения IV?
Десять лет с даты вывода системы AI высокого риска на рынок или ввода её в эксплуатацию, или до конца рабочего срока системы — в зависимости от того, что дольше.
В: Должны ли все восемь категорий документироваться для всех систем AI высокого риска?
Да. Приложение IV явно перечисляет все восемь категорий как обязательные. Однако глубина и детализация, требуемые для каждой категории, являются «соответствующими» системе — более простая система требует менее детальной документации, чем сложная. Стандарт — документация демонстрирует соответствие, а не достигает определённой длины.
В: Мы используем стороннюю базовую модель. Нужно ли нам документировать, как обучалась модель?
Для самой базовой модели: вы документируете публично заявленные спецификации дизайна модели и подход к обучению (например, документация Anthropic для Claude). Для вашего развёртывания: вы документируете вашу конфигурацию, правила управления и результаты оценки. Вы несёте ответственность за соответствие вашего развёртывания, а не за внутреннюю документацию обучения провайдера модели.
В: Существует ли официальный шаблон ЕС для документации Приложения IV?
Нет. EU AI Act определяет требования к содержанию, а не к формату. Документируйте вашу AI-систему в любом формате, который лучше всего демонстрирует соответствие восьми категориям. Чёткая, структурированная техническая документация с явным соответствием требованиям Приложения IV легче поддаётся проверке регулятором, чем соответствие формату документа.
Николай Ковтун, основатель Infracortex AI Studio. Cortex генерирует операциональные доказательства соответствия — журналы решений, записи управления рисками, данные мониторинга, — которые наполняют вашу документацию Приложения IV. Забронируйте 30-минутный звонок для аудита готовности к Приложению IV.
См. также: EU AI Act Статья 9: непрерывное управление рисками | EU AI Act Статья 12: требования к логированию — детальный разбор | EU AI Act Статья 15: требования к точности и устойчивости
Cortex build: 0.1.35-260423
