EU AI Act Статья 12: требования к логированию — детальный разбор
Когда инженерные команды слышат «требования к логированию по EU AI Act», большинство предполагает, что ответ — «включить подробное логирование». Статья 12 более конкретна и более требовательна. Это не требование объёма. Это требование структуры.
Полный текст статьи 12 содержит три абзаца. Последствия для реализации значительно шире. Вот что на самом деле требует закон — в переводе на инженерные термины.
TL;DR
- Статья 12 EU AI Act требует автоматического, точного логирования событий для систем AI высокого риска
- Логирование должно обеспечивать выявление рисков, мониторинг после выпуска и проверку регуляторами
- Конкретные требуемые данные: период использования, референсная база данных, входные данные и идентичность лиц, осуществляющих надзор
- Логи должны иметь защиту от фальсификации — не просто сохраняться, но быть верифицируемыми
- Статья 12 не определяет формат; она определяет функцию — ваши логи должны обеспечивать возможность реконструкции AI-решений
Что на самом деле говорит статья 12
Статья 12 EU AI Act озаглавлена «Возможности логирования». Оперативный текст для систем AI высокого риска гласит:
«Системы AI высокого риска должны технически обеспечивать автоматическую запись событий (‘логи’) в течение всего жизненного цикла системы… Возможности логирования должны обеспечивать мониторинг работы системы AI высокого риска с целью выявления ситуаций, которые могут привести к тому, что система AI представит риск…»
Три фразы определяют требование:
«Автоматическая запись» — Логи должны генерироваться системой, а не составляться вручную. Агент, требующий от человека документировать свои действия, не соответствует этому стандарту. Логирование должно быть встроено в архитектуру системы.
«В течение всего жизненного цикла системы» — Логирование не является пунктом чеклиста при запуске. Оно должно работать от первоначального развёртывания до вывода из эксплуатации. Обновления системы не должны создавать пробелы в логировании.
«Выявление ситуаций, которые могут привести к риску» — Это определяет функциональный стандарт. Ваши логи должны быть структурированы так, чтобы аномалия, нарушение политики или нарастающий рисковый паттерн были обнаруживаемы из данных логов. Логи, фиксирующие только успешные завершения, не соответствуют этому стандарту.
Полный текст см. в официальном тексте EU AI Act, опубликованном в Официальном журнале Европейского союза.
На кого распространяется статья 12
Статья 12 распространяется на провайдеров систем AI высокого риска. Системы высокого риска определены в Приложении III EU AI Act и охватывают:
- Биометрическую идентификацию и категоризацию
- Управление критической инфраструктурой
- Оценку в сфере образования и профессионального обучения
- Принятие решений в сфере занятости
- Основные частные и публичные услуги (включая кредитный скоринг)
- Правоохранительную деятельность
- Миграцию и пограничный контроль
- Отправление правосудия
AI-агенты, развёртываемые в финтехе (кредитные решения, оценка мошенничества), здравоохранении (сортировка пациентов, расписание), страховании (обработка претензий, андеррайтинг) и юридических технологиях (проверка документов с юридическим эффектом, анализ доказательств), вероятно, квалифицируются как высокорисковые в зависимости от их функции.
Даже там, где система не достигает порога высокого риска, логирование уровня статьи 12 становится де-факто стандартом в корпоративных закупках. Корпоративные клиенты в регулируемых отраслях всё чаще требуют соответствия поставщиков статье 12 даже для систем GPAI.
Чеклист логирования по статье 12 для инженерных команд
Структурные требования
□ Автоматическое логирование встроено в архитектуру системы Подсистема логирования должна быть первоклассным компонентом архитектуры агента, а не плагином или запоздалой мыслью. Она должна работать без инициации человеком.
□ Логи генерируются по каждому периоду использования Каждая сессия или определённый период использования должен производить отдельный набор логов с идентифицируемыми границами. Вы должны быть в состоянии сказать: «В течение периода [начало] — [конец] вот все события».
□ Генерация логов продолжается в течение всего жизненного цикла системы Убедитесь, что обновления, изменения модели и инфраструктурные изменения не создают пробелов в логировании. Требуется непрерывное покрытие.
Требования к содержанию
□ Зафиксирована референсная база данных Для каждой сессии вывода: к какой базе знаний, версии модели или референсным данным обращалась система? Это должно быть зафиксировано с ссылками на версию или хэш.
□ Зафиксированы входные данные Входные данные, используемые в каждом AI-решении, должны быть зафиксированы. Для агента, работающего с данными клиентов, это включает: к какой записи клиента, к каким полям данных, к какому запросу или промпту был осуществлён доступ. Минимизация данных применяется к хранению, а не к логированию — доказательства того, какие данные использовались, должны существовать.
□ Зафиксирована идентичность лиц, осуществляющих надзор Там, где применяется статья 14 (надзор со стороны человека), идентичность лица, осуществляющего надзор, и характер этого надзора должны быть зафиксированы. Полностью автоматизированные системы должны фиксировать отсутствие проверки человеком и политическую основу для этого исключения.
□ Зафиксированы решения и их обоснование Статья 12 требует логирования событий, имеющих отношение к выявлению рисков. Лог, фиксирующий «решение принято» без обоснования, которое его породило, не может соответствовать стандарту обнаружения рисков. Обоснование решения — оценка политики, уровень риска, применённое конкретное правило — должно быть включено.
Требования к целостности
□ Логи имеют защиту от фальсификации EU AI Act не определяет технический механизм, но функциональное требование ясно: логи должны быть верифицируемыми. Если запись лога может быть изменена без обнаружения, она не может служить доказательством аудита. Криптографическая подпись и хеш-цепочка удовлетворяют этому требованию.
□ Логи хранятся отдельно от производственной системы Логи, хранящиеся только в производственной системе, могут быть изменены или удалены при компрометации системы. Неизменяемое хранение логов — системы с добавлением, write-once хранилище или вторичные службы подписания — удовлетворяет требованию целостности.
□ Период хранения соответствует правовым требованиям Статья 12 требует хранения, соответствующего системе, с минимумом шесть месяцев. Регулируемые отрасли обычно требуют более длительных периодов. Изучите ваши конкретные регуляторные требования и настройте хранение соответственно.
Операционные требования
□ Логи доступны регуляторным органам Статья 12 требует, чтобы логи были доступны национальным компетентным органам по запросу. Это означает, что доступ к логам должен быть возможен без простоя системы, а формат должен быть интерпретируем рецензентами, не являющимися инженерами.
□ Логирование охватывает сбои системы и аномалии Стандарт обнаружения рисков требует, чтобы аномалии, ошибки и поведение вне области применения отображались в логах. Система, логирующая только успешные завершения, не соответствует этому требованию.
| Требование | Распространённая реализация | Проверка разрыва |
|---|---|---|
| Автоматическое логирование | Встроено в слой управления | ✅ если на уровне управления, ❌ если только на уровне приложения |
| Зафиксированы входные данные | Запись доказательств включает параметры запроса | ✅ если параметры захвачены, ❌ если только статус-код |
| Защита от фальсификации | Подписи Ed25519 + хеш-цепочка | ✅ если подписано, ❌ если plaintext |
| Трассировка надзора человека | Записи очереди эскалации | ✅ если эскалация зафиксирована, ❌ если только неформально |
| Хранение 6+ месяцев | Определена политика хранения | ✅ если политика существует, ❌ если ad hoc |
Распространённые разрывы, которые пропускают инженерные команды
Ошибка 1: Логирование на уровне приложения, а не на уровне управления. Логи приложения фиксируют, что сделало приложение. Логи управления фиксируют, был ли агент авторизован на это. Стандарт обнаружения рисков статьи 12 требует второго. Если ваши единственные логи находятся на уровне приложения, вам недостаёт доказательств авторизации.
Ошибка 2: Логирование выходных данных, а не входных. Многие команды фокусируются на логировании того, что произвела AI-система. Статья 12 требует логирования входных данных, использованных в решении. Входные данные — это то, что нужно аудитору для реконструкции причинности.
Ошибка 3: Рассмотрение хранения как требования к логированию. Хранение логов необходимо, но недостаточно. Логи, которые хранятся, но не структурированы для обнаружения рисков, не имеют защиты от фальсификации и недоступны в интерпретируемом формате, не соответствуют функциональному стандарту статьи 12.
Ошибка 4: Пробелы при обновлениях. Изменения версии модели, обновления инфраструктуры и выпуски функций могут создавать пробелы в логировании, если подсистема логирования не является частью контракта развёртывания. Статья 12 требует непрерывного покрытия. Встройте непрерывность логирования в ваш процесс развёртывания.
Как статья 12 соотносится с другими статьями EU AI Act
Статья 12 не работает изолированно. Она напрямую связана с:
- Статьёй 9 (Управление рисками) — Риски, которые статья 9 требует от вас управлять, — это те риски, которые должны быть обнаруживаемы в логах статьи 12. Система логирования является операциональной реализацией системы управления рисками.
- Статьёй 14 (Надзор со стороны человека) — События надзора со стороны человека, инициированные в соответствии со статьёй 14, должны быть зафиксированы в соответствии со статьёй 12. Лог — это место, где надзор человека становится верифицируемым доказательством.
- Статьёй 17 (Система управления качеством) — Системы управления качеством, требуемые статьёй 17, должны включать логирование как компонент текущего мониторинга.
- Приложением IV (Техническая документация) — Дизайн системы логирования должен быть задокументирован в технической документации, требуемой Приложением IV.
Часто задаваемые вопросы
В: Применяется ли статья 12 к AI-агентам, используемым только внутри компании, а не клиентами?
Классификация высокого риска основана на функции, а не на аудитории. AI-агент, принимающий решения в сфере занятости, обрабатывающий кредитные заявки или управляющий критической инфраструктурой, является высокорисковым независимо от того, обращён он к клиентам или к внутреннему персоналу. Сопоставьте Приложение III с конкретной функцией вашего агента.
В: Что представляет собой адекватное логирование «входных данных» для AI-агента?
Стандарт — это то, что необходимо для реконструкции решения в целях аудита. Для агента кредитных решений: данные заявителя, к которым был осуществлён доступ, временной период запроса, версия модели, оценённые правила политики. Для агента клиентского обслуживания: запись клиента, данные о продукте, контекст предыдущего взаимодействия. Фиксируйте то, что нужно аудитору соответствия для отслеживания причинности от входа к решению.
В: Существуют ли конкретные требования к формату по статье 12 EU AI Act?
Нет. Статья 12 определяет функцию, а не формат. Логи должны быть способны обнаруживать риски, обеспечивать мониторинг и поддерживать проверку регулятором. JSON, структурированные базы данных и подписанные бинарные форматы — все удовлетворяют требованию, если соответствуют функциональному стандарту. Текстовые логи без защиты от фальсификации — нет.
В: Когда начнутся правоприменительные действия по статье 12?
Обязательства EU AI Act по системам высокого риска для существующих систем стали применимы в августе 2026 года. Национальные надзорные органы наращивают правоприменительный потенциал. Первые правоприменительные действия сосредоточены на вопиющих пробелах — системах без значимого логирования. Грамотная архитектура управления сейчас обеспечивает защищаемый базовый уровень.
В: Можем ли мы использовать нашу существующую систему SIEM для соответствия статье 12?
Системы SIEM, разработанные для логирования событий безопасности, могут удовлетворять некоторым требованиям статьи 12 при правильной настройке — особенно для захвата событий и хранения. Обычно они не удовлетворяют требованию защиты от фальсификации без дополнительной настройки (WORM-хранилище, криптографическая подпись). Что важнее, системы SIEM не захватывают данные уровня управления: оценки политик, ссылки на конституциональные правила, цепочки авторизации. Вам, вероятно, нужны обе системы.
Николай Ковтун, основатель Infracortex AI Studio. Cortex реализует логирование, соответствующее статье 12, для развёртываний AI-агентов — автоматическое, с защитой от фальсификации и структурированное для проверки регуляторами. Забронируйте звонок для аудита вашего текущего логирования по чеклисту статьи 12.
См. также: EU AI Act Статья 9: непрерывное управление рисками для AI-агентов | EU AI Act Статья 14: построение практического надзора человека | Почему логи вашего AI-агента не пройдут аудит
Cortex build: 0.1.35-260423
