EU AI Act Статья 15: требования к точности и устойчивости

Производственный AI-агент в рабочем процессе кредитования финтех-компании производил неточные результаты верификации доходов в 0,3% заявок — примерно 15 случаев в месяц. Показатель точности выглядел приемлемым при тестировании: 99,7%.

Через три месяца после развёртывания эти 15 ежемесячных случаев превратились в паттерн: неточность была не случайной. Она коррелировала с конкретным форматом документа о доходах, используемым двумя банками в одном регионе. Клиенты этих банков систематически оказывались в невыгодном положении.

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

TL;DR

Статья 15 требует, чтобы системы AI высокого риска достигали соответствующих уровней точности, устойчивости и кибербезопасности

Точность — это не единый тест: она должна поддерживаться в течение всего жизненного цикла системы и измеряться по релевантным подгруппам

Устойчивость охватывает защищённость от ошибок, неисправностей и несоответствий — включая состязательные входные данные

Кибербезопасность требует защиты от атак, которые могут изменить поведение системы

Обработка ошибок и резервное поведение должны быть определены, задокументированы и протестированы

Что охватывает статья 15

Статья 15 EU AI Act озаглавлена «Точность, устойчивость и кибербезопасность». Она содержит три различных, но перекрывающихся требования.

Точность

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

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

Критически важно, что требование к точности распространяется на подгруппы. Система с 99% общей точностью, систематически хуже работающая для конкретных демографических или географических групп, не удовлетворяет статье 15, если это снижение производительности создаёт дискриминационные эффекты.

Устойчивость

Статья 15 требует, чтобы системы были «устойчивы к ошибкам, неисправностям или несоответствиям, которые могут возникнуть в системе или в среде, в которой функционирует система».

Для AI-агентов устойчивость охватывает:

Устойчивость к входным данным — Как агент обрабатывает неправильно сформированные входные данные, неожиданные граничные случаи или входные данные вне его обучающего распределения?
Операционная устойчивость — Как ведёт себя агент, когда восходящие зависимости (API, базы данных, внешние сервисы) дают сбой или производят неожиданные выходные данные?
Поведение в деградированном режиме — Что происходит, когда компонент системы недоступен? Агент безопасно завершает работу или продолжает с неполной информацией способами, увеличивающими риск?
Состязательная устойчивость — Может ли система быть манипулирована через тщательно сформированные входные данные, предназначенные для изменения её поведения? Инъекция промптов, отравление данных и атаки на извлечение модели являются основными состязательными угрозами для AI-агентов.

Кибербезопасность

Статья 15 явно включает кибербезопасность как измерение устойчивости. AI-системы должны разрабатываться «с учётом обеспечения соответствующего уровня кибербезопасности».

Для AI-агентов основные проблемы кибербезопасности:

Инъекция промптов — Вредоносный контент в среде агента, заставляющий его вести себя вопреки своим инструкциям
Извлечение модели — Запросы, предназначенные для реконструкции модели или её обучающих данных
Отравление обучающих данных — Манипуляция обучающими данными для создания backdoor-поведения
Манипуляция при выводе — Манипуляция входными или выходными данными модели в реальном времени

Эти классы атак требуют как технических мер снижения (валидация входных данных, фильтрация выходных данных, ограничение скорости), так и мер снижения на уровне управления (конституциональные правила, устойчивые к манипуляциям, обнаружение аномалий для дрейфа поведения).

Практическая реализация

Реализация точности

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

Измеряйте точность по подгруппам. Совокупные метрики точности могут скрывать систематическое снижение производительности. Определите релевантные подгруппы для вашего случая использования — демографические, географические, по типу продукта, по формату документа — и измеряйте точность по подгруппам.

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

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

Реализация устойчивости

Измерение устойчивости	Тип теста	Минимально необходимое
Граничные случаи входных данных	Граничное тестирование	Определённое поведение для всех входных данных
Сбой зависимости	Хаос-тестирование	Задокументированное поведение в деградированном режиме
Состязательные входные данные	Red team / инъекция промптов	Протестированный, задокументированный остаточный риск
Сдвиг распределения	Shadow deployment	Оповещения мониторинга при обнаружении сдвига

Определите безопасное поведение при сбое. Каждый режим сбоя должен иметь определённый обработчик. «Агент возвращает ошибку» — это безопасное поведение при сбое. «Агент продолжает с неполной информацией» без задокументированного обоснования — нет.

Тестируйте деградированный режим явно. Сценарии сбоя для AI-агентов включают: API модели недоступен, база данных недоступна, слой управления отключён, очередь эскалации заполнена. Что делает агент в каждом случае? Протестируйте. Задокументируйте.

Реализация кибербезопасности

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

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

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

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

Обязательство по тестированию

Статья 15 подразумевает обязательство по тестированию — вы не можете продемонстрировать соответствующую точность и устойчивость без тестирования. NIST AI Risk Management Framework — широко используемый ориентир для реализации статьи 15 — определяет, что тестирование должно включать:

Тестирование перед развёртыванием на репрезентативных наборах данных
Состязательное тестирование (red teaming, попытки инъекции промптов)
Анализ производительности по подгруппам
Анализ режимов сбоя и документация
Непрерывный мониторинг после развёртывания с задокументированными базовыми линиями

Требования к обработке ошибок

Требование статьи 15 к устойчивости имеет прямое следствие для обработки ошибок: «соответствующие меры для минимизации и снижения» потенциальных ошибок должны быть на месте.

Для AI-агентов это означает:

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

Обработка ошибок должна быть протестирована. Обработчики должны быть проверены на работоспособность на практике, а не только определены в документации.

Ошибки должны быть зафиксированы. В соответствии со статьёй 12, ошибки входят в число событий, которые должны быть зафиксированы. Незафиксированная ошибка — это ошибка, которую нельзя отслеживать, и требование мониторинга по статье 15, которое не выполнено.

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

Часто задаваемые вопросы

В: Требует ли статья 15 конкретного порога точности?

Нет. Статья 15 требует «соответствующей» точности — стандарта, зависящего от контекста. Вы должны определить, что означает «соответствующая» для вашей системы, продемонстрировать её достижение и поддерживать её. Система, достигающая своего определённого порога в совокупности, но систематически дающая сбой для конкретных подгрупп, всё равно может нарушать статью 15.

В: Как статья 15 взаимодействует с требованиями GDPR к точности автоматизированных решений?

Статья 22 GDPR предоставляет субъектам данных права в отношении чисто автоматизированных решений со значительными последствиями, включая право на оспаривание. Статья 15 является обязательством по проектированию: создайте систему для достижения и поддержания точности. Они взаимодополняют друг друга. Статья 15 требует от вас построить точную систему; статья 22 GDPR требует от вас обрабатывать случаи, когда она ошибается.

В: Что считается состязательным тестированием для целей EU AI Act?

Состязательное тестирование означает систематические попытки произвести сбои, ошибки или манипулированное поведение через специально сформированные входные данные. Для AI-агентов: попытки инъекции промптов (может ли внешний контент переопределить системные инструкции?), зондирование границ (что происходит на краю определённых рабочих условий?) и стресс-тестирование (как ведёт себя система при высокой нагрузке или деградированных зависимостях?). Red teaming — использование специальной команды для попытки реалистичных атак — является рекомендуемым подходом.

В: Требуют ли обновления модели от нашего провайдера повторного тестирования по статье 15?

Да. Обновления модели могут изменять характеристики точности и устойчивости. Непрерывное требование точности по статье 15 означает, что значительные обновления модели запускают проверку ваших доказательств точности. Это не обязательно требует полного повторного тестирования с нуля — целенаправленная оценка, сфокусированная на возможностях, изменённых в обновлении, часто соразмерна.

В: Как статья 15 взаимодействует с системой управления рисками по статье 9?

Статья 15 определяет стандарт качества для точности и устойчивости. Статья 9 требует непрерывной системы управления рисками. Система управления рисками по статье 9 является операциональным механизмом для поддержания стандартов статьи 15. Меры управления рисками для выявленных рисков точности (мониторинг, триггеры переобучения, проверка человеком для выходных данных с низкой уверенностью) — это то, как вы одновременно соблюдаете обе статьи.

Николай Ковтун, основатель Infracortex AI Studio. Слой управления Cortex генерирует доказательства, необходимые для демонстрации соответствия статье 15 — поведенческий мониторинг, обнаружение аномалий и защищённые от фальсификации записи производительности системы. Забронируйте 30-минутный звонок для оценки пробелов по статье 15.

См. также: EU AI Act Статья 9: непрерывное управление рисками для AI-агентов | EU AI Act Статья 12: требования к логированию — детальный разбор | Наблюдаемость AI-агентов vs управление: в чём разница?

Cortex build: 0.1.35-260423