Криптографическая провенанс-привязка AI-выводов

Автор: Антон Соколов, TalTech · Дата: 2026-05-05 · Статус: draft v0.5 · Источник: github.com/sapsan14/paper-pki-ai-act · Ключевые слова: EU AI Act · eIDAS · ETSI EN 319 · PKI · провенанс · RFC 3161 · постквантовая криптография · governance агентов

Краткая аннотация

Регламент ЕС об искусственном интеллекте (2024/1689) налагает обязательства по целостности, прозрачности, ведению записей и человеческому надзору AI-систем — в особенности в рамках Статей 10, 12 и 13 высокорискового режима (Глава III, Раздел 2). Мы утверждаем, что существенную часть этих обязательств можно операционализировать, переиспользуя инфраструктуру доверия, которую PKI-инженеры уже разворачивают под eIDAS (Регламенты 910/2014 и 2024/1183) и ETSI EN 319 102 / 132 / 401 / 411: криптографические подписи над каноническими payload-ами, валидация цепочки X.509, отзыв через OCSP/CRL, метки времени RFC 3161 и hash-цепочечные журналы аудита, управляемые политикой. Мы представляем эталонную архитектуру — Enterprise Agent Trust Framework (EATF / Aletheia), позиционируемый как Доверенный слой AI-доказательств, который связывает AI-выводы и управляемые действия с подписанными, timestamped Evidence Packages, с опциональной гибридной подписью ML-DSA (NIST FIPS 204) для постквантовой готовности. Мы даём по-статейный маппинг с явными доверительными полосами вероятности соответствия и сознательно ограничиваем Статью 10 целостностью и провенансом, а не качеством обучающих данных. Мы позиционируем фреймворк как субстрат, а не как вертикальный продукт, и сообщаем о пяти партнёрских интеграциях (мониторинг качества воды, энергоаудит зданий, образование; медицинская и KYC-вертикали в плане), работающих на одних и тех же примитивах. Статья адресована архитекторам доверия, PKI-практикам и AI-внедренцам в ЕС и предлагает гипотезу реализации, открытую к инженерной критике.

1 · Введение

До 2002 года «электронная подпись» в Эстонии означала отсканированный JPEG. С 2002-го — ID-карта, цепочка национальный QTSP → RIA Trusted List → LOTL, юридическая сила во всех 27 странах ЕС. За двадцать четыре года инфраструктура прозрачно прошла две смены доверия — переход SHA-1 → SHA-256 и обновление до eIDAS 2 — и продолжает работать. Больше миллиона активных квалифицированных сертификатов; десятки миллионов RFC 3161-меток времени в год (публичные отчёты эстонского QTSP, 2024).

Эта статья применяет тот же набор примитивов к новому классу артефактов — AI-выводам. Закон говорит «record-keeping». PKI-инженер слышит «hash-цепочка». Одно и то же — но перевод между двумя словарями ещё не лежит на столе. Кладём его сюда.

И сама статья подписана EATF — proof in the printing. Манифест текущего деплоя опубликован на https://paper.eatf.eu/.well-known/eatf-attestation.json; читатель может проверить, что байты, которые он читает, — те же, что мы подписали (детали режима — §5.8).

EU AI Act (Регламент 2024/1689) применяется поэтапно с 2025 по 2027. Инженерная поверхность высокорискового режима — Глава III, Раздел 2, Статьи 9–15 — стоит на трёх китах: проверяемость, прослеживаемость, человеческий надзор. Параллельно eIDAS (Регламент 910/2014 и его обновление 2024/1183) и семейство ETSI EN 319 уже больше десяти лет дают конкретные ответы на вопросы целостности, безотказности и временного провенанса. Эти ответы — для документов, не для AI.

Статья закрывает разрыв. Не вводим новой compliance-таксономии. Спрашиваем по-другому: какие обязательства AI Act можно исполнить, переиспользуя PKI-примитивы, и где PKI заканчивается? Переиспользуемый слой называем Доверенным слоем AI-доказательств и сразу оговариваем: это доказательство целостности, не клинической полезности.

Субстрат, а не вертикаль. EATF / Aletheia — это субстрат, на который надеваются секторные вертикали: мониторинг окружающей среды, энергоаудит, образование, медицина, KYC. Субстрат — единица вклада. Вертикали — свидетельство его достаточности под нагрузкой. Не наоборот. Подчёркиваем потому, что коммерческое обсуждение 2025–2026 годов привычно смешивает подпись AI-выводов с управлением AI-поведением. Разные задачи. Разные решения.

Что несёт статья.

Маппинг по Статьям. Высокорисковые обязательства AI Act (Статьи 10, 12, 13; Статья 14 — явно смежная) ложатся на рычаги eIDAS и ETSI EN 319 102 / 132 / 401 / 411. Таблица — §4.
Эталонная архитектура EATF / Aletheia. Доверенный слой AI-доказательств, производящий пакет .aep: hash → sign → (опц.) метка времени RFC 3161 → (опц.) гибридная подпись ML-DSA-65 (NIST FIPS 204) для постквантовой готовности.
Анализ уникальности серийных номеров под eIDAS 2 (с учётом проекта 2025/1943). Три архитектурные опции, ординально ранжированные high/medium/low. Методологическое примечание — §6.4 (ранние черновики несли проценты — изъяли до формальной экспертной элиситации).
Честная карта границ. Где PKI-линза ломается — качество обучающих данных по Статье 10, человеческий надзор по Статье 14, разграничение целостности и клинической полезности в регулируемых доменах.
Работающая open-source реализация с офлайн-проверкой .aep. На 2026-05-05: TADF (энергоаудит) — в продакшне на tadf-audit.h2oatlas.ee с 2026-04-26; water-quality-ee — модель и ML-pipeline живые, subscriber-интеграция в подготовке; MATx — демо для президентского хакатона. Медицинская и KYC — в плане.

Не цели. Эта статья не является compliance-сертификатом; мы не утверждаем, что какое-либо конкретное развёртывание EATF удовлетворяет AI Act в целом. Мы не рассматриваем качество обучающих данных как криптографическое свойство — это вопрос продукта/ML, а не PKI. Мы не выносим суждений о безопасности AI в нормативном смысле; мы описываем субстрат, который делает AI-исходы проверяемыми и атрибутируемыми, а не безопасными.

2 · Background

2.1 EU AI Act — высокорисковые обязательства

AI Act (Регламент 2024/1689) вступил в силу в 2024 году. Применяется поэтапно: сначала запрещённые практики, потом GPAI, потом высокорисковый режим, в конце — governance и санкции. Авторитетные даты ведёт EU AI Act Service Desk. Вторичные инструменты — Digital Omnibus, гармонизированные стандарты Статьи 40, рекомендации по форматам доказательств — ещё в работе и продолжат эволюционировать до 2027 года.

Высокорисковый режим — это Глава III, Раздел 2, Статьи 9–15. Система попадает в режим двумя путями: Статья 6(1) (компонент безопасности) или Статья 6(2) + Приложение III (use-case). Внедренец (deployer) несёт отдельный набор обязанностей — Статьи 26 и 27 (Оценка воздействия на основные права, FRIA, где требуется). Внедренец — наша операционная забота: PKI-реализация должна пройти всю цепочку поставщик → внедренец → конечный пользователь, и формулировка Статьи 26 «использовать как указано» прямо ложится на PKI: подписанный внедренцем deployment-манифест, привязка system-card по hash.

Мы концентрируемся на Статьях 10, 12 и 13 — троице с сильнейшим PKI-фитом — и трактуем Статью 14 (человеческий надзор) как смежную (§4). Статьи 9, 11, 15 упоминаем, но не в фокусе: Статья 9 — процесс, PKI прямо на него не отвечает; Статья 11 ложится на подписанный system-card бандл (выпадает из §4 как следствие); Статья 15 — на границе runtime / governance, за рамками разделения provenance-vs-governance из §2.5.

2.2 eIDAS и ETSI EN 319

Режим eIDAS под Регламентом 910/2014 и его обновлением 2024/1183 («eIDAS 2») определяет доверенные услуги как регулируемую категорию права ЕС. Таксономия включает электронные подписи, электронные печати (институциональный аналог подписей), электронные метки времени и электронную доставку — каждая в квалифицированной форме (приставка «Q»), когда производится Квалифицированным поставщиком доверенных услуг (QTSP) под аудитом. Юридическая сила квалифицированного инструмента действует во всех государствах-членах в силу самого Регламента — это свойство и делает режим достойным переиспользования для AI-доказательств: внедренцы любой юрисдикции ЕС могут полагаться на одни и те же примитивы, не перепроверяя фреймворк.

Семейство ETSI EN 319 — инженерный инструментарий ниже. ETSI EN 319 102-1 даёт каноническую процедуру создания и валидации продвинутых цифровых подписей (профили CAdES, XAdES, PAdES, JAdES); EN 319 132-1 детально специфицирует профиль XAdES; EN 319 401 устанавливает общие требования к политике поставщиков доверенных услуг; EN 319 411-1 специфицирует требования к TSP, выпускающим сертификаты; EN 319 412-1 специфицирует профили сертификатов. Связь иерархическая: EN 319 401 — общая политика, специализированная 411-1 для эмитентов сертификатов, профилированная 412-1 для самих сертификатов и потребляемая 102-1 / 132-1 во время подписи. Мы ссылаемся на эти стандарты как на инструментарий, а не учебную программу; раздел даёт ориентацию, не сертификацию.

Конкретный переходный концерн под eIDAS 2 — правило уникальности serialNumber (проект 2025/1943), которое распространяет требование уникальности с per-CA на TSP-wide для квалифицированных TSP. Сдвиг операционно нетривиален: TSP с несколькими CA (типичная картина в квалифицированном масштабе) должен координировать выпуск серийных номеров между силосами, а не только внутри них. Мы обсуждаем три архитектурных опции в §5.4 и их ординальные уровни уверенности в соответствии (Центральный орган серийных номеров — high; глобальный реестр перед выпуском — medium; случайные с пост-фактум сканированием — low; см. методологическое примечание §6.4). Этот вопрос важен для маппинга AI Act, потому что как только CA, подписывающие AI-доказательства, становятся квалифицированными, они наследуют то же обязательство уникальности.

Эстония — полезный sanity-check того, как режим выглядит в продакшне: почти каждый взрослый держит квалифицированный сертификат через ID-карту или Mobiil-ID; Trusted List (LOTL → EE-TL) потребляется клиентским ПО, включая Open-EID и DigiDoc; метки времени уровня RFC 3161 рутинно применяются в частных контрактах. Эстонское разворачивание — то, что мы имеем в виду, говоря о «верифицируемости со стороны внедренца» в §4.3.

2.3 Метки времени RFC 3161 и журналы аудита

RFC 3161 определяет протокол меток времени, используемый в этой статье как канонический механизм временного провенанса. Журнал аудита мы трактуем как hash-цепочечную, append-only структуру подписанных событий, с настраиваемым per-tenant размером блока, введённым в обновлении субстрата конца апреля 2026.

2.4 Постквантовые подписи (NIST FIPS 203/204/205)

Постквантовая миграция следует NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) и FIPS 205 (SLH-DSA). EATF поддерживает гибридный режим подписи RSA + ML-DSA-65; мы обсуждаем раздувание сертификатов, размер подписи и практический горизонт «harvest now, decrypt later» в §5.

2.5 Идентичность агента vs. провенанс vs. governance — три ортогональных слоя

Частая путаница в коммерческом обсуждении 2025–2026 — схлопывание трёх различных вопросов в единую поверхность «AI-доверия». Мы их разделяем:

Идентичность — кто агент? Закрывается MCP, OIDC-профилями агентов, X.509-сертификатами агентов.
Провенанс — что агент произвёл, на каком входе? Закрывается EATF / Aletheia, C2PA и подобными схемами подписанных доказательств.
Governance — было ли агенту разрешено это сделать? Закрывается полиси-движками, цепочками делегирования, kill-switch-ами, action firewall (например, шагом authorize Visa CLI перед платёжным rail).

Идентичность и провенанс ортогональны: знание кто агент само по себе не доказывает что он сделал. Мы строго позиционируем EATF на слое провенанса; идентичность и governance — комплементарные соседи.

3 · Модель угрозы

Что EATF защищает.

Целостность AI-выводов — в покое и при передаче. Один бит меняешь — подпись разваливается. .aep tamper-evident по построению.
Безотказность действий. Внедренец предъявляет пакет, который сшивает вход, выход, версию модели, версию политики, метку времени и ключ подписи. Аудит апостериори сдвигается с «случилось ли это?» на «какой была политика в тот момент?».
Временной провенанс. Метки времени RFC 3161 закрепляют доказательство в юридически признаваемом времени; квалифицированный TSA — в eIDAS-уровневом.
Верификация с учётом отзыва. Состояние OCSP/CRL вылавливается в момент подписи и сохраняется в пакете. Через десять лет верификатор увидит, что издатель тогда думал, а не молча деградирует до trust-on-first-use.

Что EATF не защищает.

Точность модели. Подпись не делает неправильный ответ правильным.
Качество обучающих данных. Хеш набора данных не доказывает, что данные репрезентативны, без утечек и без смещения. Статья 10 у нас — только про целостность и провенанс артефакта (§4); про data governance в ML-смысле — нет.
Клиническую или предметную валидность. В медицине и праве подписанный AI-вывод не равен суждению человека-практика. Говорим явно — иначе путают слои при закупках.
Runtime-поведение. EATF — evidence-слой. Мониторинг, rate-limiting, детекция аномалий живут на слой выше, в governance.
Сетевой противник против хоста подписи. Хост подписи — под политикой ETSI EN 319 401. Криптографических контрмер для скомпрометированного подписанта мы здесь не предлагаем.

Противники, которых мы рассматриваем.

Внешний фальсификатор. Изменяет AI-вывод после генерации, но до аудита. Защищается подписью.
Подменщик в потоке. Заменяет один пакет доказательств другим для того же номинального действия. Защищается подписью + evidence-id binding.
Перезаписчик времени. Утверждает, что действие произошло раньше или позже, чем в реальности. Защищается метками времени RFC 3161.
Долгогоризонтный противник (PQC). Записывает подписанный трафик сегодня, ждёт криптографически релевантного квантового потенциала. Защищается (частично) гибридным режимом ML-DSA; полная миграция обсуждается в §5.

Противники, которых мы не рассматриваем.

Противник с владением ключом QTSP. (Предполагаются физические и политические контроли eIDAS-уровня.)
Противник, контролирующий полиси-движок, который решает, какие действия вообще подписывать. (Это governance, не provenance.)
Противник, подменяющий модель под одним и тем же идентификатором модели. Мы обсуждаем привязку model-card в §5.3, но трактуем вопрос как смежный.

3.1 Неформальный аргумент безопасности

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

Для каждого противника в §3 мы очерчиваем условие победы и свойство EATF, которое его предотвращает.

Противник 1 (Внешний фальсификатор). Побеждает, если верификатор принимает модифицированный payload как оригинальный. Лежащие в основе схемы подписи EUF-CMA-безопасны при стандартных предположениях: RSA-PSS в random-oracle model (Bellare–Rogaway 1996); Ed25519 имеет опубликованную редукцию к EDDSA / Curve25519 hardness (Brendel et al. 2021); ECDSA не имеет редукции к стандартной модели, но EUF-CMA-безопасна в Generic Group Model (Brown 2002, Fersch et al. 2016) — ограничение, которое мы здесь явно фиксируем. ML-DSA-65 — при предположениях твёрдости Module-LWE + Module-SIS. Пакет доказательств связывает подпись с SHA-256 канонических байтов payload-а, поэтому модификация payload-а — это модификация хеша — это несовпадение подписи.

Формально: для $\mathsf{Sig}$ EUF-CMA-безопасной, если для всех PPT (probabilistic polynomial time) противников $\mathcal{A}$ выполнено

\Pr\!\left[\mathsf{Verify}(\mathit{vk}, m, \sigma) = 1 \;\big|\; (m, \sigma) \notin \mathcal{Q},\; (m, \sigma) \leftarrow \mathcal{A}^{\mathsf{Sign}(\mathit{sk}, \cdot)}(\mathit{vk})\right] \le \mathsf{negl}(\lambda),

то и для пакета .aep, чьи подписанные байты включают $\mathit{ph} \,\|\, \mathit{ts} \,\|\, \mathit{pid}$ , вероятность подделки ограничена тем же $\mathsf{negl}(\lambda)$ плюс вероятностью коллизии SHA-256.

Гид по нотации для PKI-инженеров:

$\mathit{vk}$ — публичный (verification) ключ; $\mathit{sk}$ — закрытый (signing) ключ.
$\mathcal{Q}$ — мультимножество $(m_i, \sigma_i)$ , которые подписной оракул уже выдал противнику; забота противника — произвести новую пару $(m, \sigma) \notin \mathcal{Q}$ .
$\lambda$ — параметр безопасности; конкретно — для RSA-PSS-2048 это ≈112 бит безопасности; для RSA-PSS-3072 ≈128; для ECDSA-P256 ≈128; для ML-DSA-65 (Category 3) — рассчитан против комбинированного классического и квантового противника, см. NIST IR 8413.
$\mathsf{negl}(\lambda)$ — функция, убывающая быстрее любого обратного полинома от $\lambda$ . Практически: «вероятность, пренебрежимая для разумных $\lambda$ ».
Под классическим противником SHA-256 collision-resistance даёт $\le 2^{-128}$ (бирвсдеевая граница $2^{n/2}$ ); под Grover-противником — pre-image-сила снижается до $2^{n/2} = 2^{128}$ , но collision-сила под BHT-style алгоритмами — $2^{n/3} \approx 2^{85}$ . Различие важно: для журнала аудита защищаемся pre-image-стойкостью, для подделки параллельной истории — collision.

Противник 2 (Подменщик в потоке). Побеждает, если верификатор принимает подменённый пакет как пакет, выпущенный внедренцем. Поскольку подписанные данные включают $\mathit{ph} \,\|\, \mathit{ts} \,\|\, \mathit{pid}$ (где $\mathit{pid}$ — UUIDv4, выпущенный внедренцем уникально для этого пакета), подмена пакета означает изменение хотя бы одного из этих полей, что ломает подпись. Это защищает от подмены на уровне пакета; это не защищает от противника, который может запросить новые подписи у самого внедренца — это governance.

Противник 3 (Перезаписчик времени). Побеждает, если верификатор принимает неправильное время подписи. Метки времени RFC 3161 закрепляют заявленное время подписи в публичном ключе TSA. Перезаписчик времени должен либо сломать подпись TSA (требуется компрометация ключа TSA; вне скоупа), либо подменить TSA-токен (токен покрывает $\mathit{ph}$ , поэтому подмена требует коллизии хеша payload-а; ограничена устойчивостью SHA-256 к коллизиям).

Противник 4 (Долгогоризонтный PQC). Побеждает за счёт будущей квантовой способности, ломающей классические подписи над ранее захваченными пакетами. Гибридный режим требует валидации обеих подписей — классической и ML-DSA-65 — при политике верификатора «both». Будущий квантовый атакующий, ломающий RSA-PSS / ECDSA через Шора, всё равно не может валидироваться как оригинальный подписант, не сломав также ML-DSA-65. ML-DSA-65 целевой уровень NIST — Category 3, рассчитанный против комбинированного классического и квантового противника (см. NIST IR 8413, NIST SP 800-208 ground rules); это не эквивалентно простому «192 бита, делящихся пополам Гровером», и нам не следует так его пересказывать. Для пакета доказательств, эмитируемого сегодня, существенный вывод: даже под Шор-адверсаром история ML-DSA-65 целостна.

Формальное криптографическое доказательство — game-based редукция от

\mathsf{EUF\text{-}CMA}(\text{RSA-PSS}) \,\wedge\, \mathsf{EUF\text{-}CMA}(\text{ML-DSA}) \,\wedge\, \mathsf{CR}(\text{SHA-256}) \;\Longrightarrow\; \mathsf{evidence\text{-}package\text{-}unforgeability}

под моделью угрозы выше — оставлено для последующей статьи. Конструкция прямолинейна; вклад этой статьи — регуляторный маппинг, а не криптографический примитив.

4 · Маппинг по Статьям

Регулятор: «Покажите мне, как ваш AI-классификатор соответствует Статье 12». Внедренец открывает три PDF, показывает policy pack, говорит: «у нас есть журнал». Регулятор: «А как я проверю, что журнал не правили задним числом?» Тишина.

Этот разговор — настоящая причина существования таблицы ниже. Каждая строка отвечает на конкретный вопрос регулятора одним PKI-нативным артефактом, который верификатор может проверить сегодня, офлайн, без обращения к внедренцу.

Статья AI Act	PKI-нативная интерпретация обязательства	eIDAS / ETSI рычаг	Реализация в EATF
Ст. 10 — Данные и data governance	Только целостность и провенанс артефактов — явно не криптоутверждение о качестве обучающих данных	EN 319 102-1 создание подписи; канонические форматы payload-а	`.aep` Evidence Package: hash, подпись, опциональный hash датасета
Ст. 11 — Техническая документация	Экспортируемые проверяемые описания систем («system card»)	EN 319 102-1; CAdES enveloped signatures	Подписанные system-card бандлы, метаданные модели + версии политики
Ст. 12 — Ведение записей / журналы	Tamper-evident, time-anchored, append-only журналы	EN 319 401 / 411-1 (политика TSP); RFC 3161 (метки времени)	Hash-цепочечный журнал аудита, подписанные события, per-tenant размер блока
Ст. 13 — Прозрачность для внедренцев	Проверяемые, машиночитаемые представления возможностей и ограничений агента	EN 319 102-1 валидация; потребление trusted-list	Валидация цепочки доверия + UI/API верификации на `h2oatlas.ee/verify/...`
Ст. 14 — Человеческий надзор (смежная)	Криптографический якорь для событий человеческого утверждения; не подменяет надзор	EN 319 102-1 подписанные события; threshold-делегирование	Подписи событий утверждения; PKI делает исходы проверяемыми и атрибутируемыми, не безопасными
Ст. 15 — Точность, устойчивость, кибербезопасность	Endpoint-ы верификации, hooks для аномалий (граница с governance)	(смежная — runtime-вопросы)	Вне скоупа (слой governance)
Ст. 26 — Обязанности внедренца	Подписанные внедренцем аттестации, ссылающиеся на system-card бандлы	EN 319 401 (политика TSP); ссылка на FRIA	Подписанный внедренцем deployment-манифест
Ст. 27 — FRIA	Подписанные FRIA-артефакты, ссылающиеся на манифест внедренца	EN 319 102-1; CAdES	FRIA-пакет доказательств, связанный с deployment-манифестом

4.1 Статья 10 — узкое прочтение

Статья 10 AI Act, прочитанная буквально, требует практик «данных и data governance» для высокорискового AI: обучающие и валидационные датасеты должны быть релевантны, репрезентативны, свободны от ошибок и полны. PKI не может подтвердить ни одного из этих утверждений. Что PKI может — это связать утверждение внедренца о датасете с проверяемым хешем этого датасета и связать model card, ссылающийся на датасет, с тем же хешем. Это узкое прочтение, которое мы принимаем: EATF доказывает, что хеш данных, заявленный в model-card, и есть хеш данных артефакта, привязанного к этому model-card. EATF не может доказать, что лежащие в основе данные пригодны для цели, репрезентативны или несмещены. Смешение этих двух утверждений — самый частый источник ошибочного доверия в пространстве «AI compliance» 2025 года. Узкое прочтение консервативно, и в этом смысл: регулятор, читающий Статью 10 расширительно, не вправе предполагать, что PKI сделал его работу за него.

4.2 Статья 12 — record-keeping как hash-цепочечный, постквантово-стойкий журнал

Статья 12 требует журналов, позволяющих отследить работу AI-системы — с окнами хранения, которые для высокорисковых систем правдоподобно составляют десятилетия. PKI-нативная реализация, которую мы предлагаем, — постквантово-защищённый, hash-цепочечный, append-only журнал аудита подписанных событий, каждое из которых несёт метку времени RFC 3161 и ссылку на политику и версию модели, действовавшие в момент события. Per-tenant размер блока, введённый в обновлении субстрата EATF конца апреля 2026, позволяет внедренцам обменивать задержку на эффективность пакетной подписи без нарушения свойства цепи. Журнал запрашиваем по внедренцу, агенту, типу действия или временному окну — и каждый результат запроса сам по себе подписываем. Формулировка Статьи 12 «автоматическая запись событий» точно ложится на эту конструкцию: события подписаны, их порядок hash-цепочечный, а их временной провенанс независимо проверяем.

Гарантия квантовой стойкости двухслойна. Inter-block связи используют SHA-256 (Grover-стойкость: 256-битовая pre-image-стойкость снижается до ~128 бит под квантовой атакой):

\mathsf{strength}_{\text{Grover}}(\text{SHA-256}) = 2^{n/2} = 2^{128} \quad (n = 256).

Per-block подпись внедренца использует гибридный примитив EATF RSA-4096 + ML-DSA-65 (FIPS 204), поэтому даже Shor-способный противник, ломающий RSA, не может подделать заголовки исторических блоков, не сломав ML-DSA. Это операционно существенно, потому что окна хранения Статьи 12 простираются глубоко в правдоподобный горизонт криптографически релевантных квантовых вычислений.

4.3 Статья 13 — прозрачность через верификацию, а не нарратив

Статья 13 обязывает поставщиков давать внедренцам достаточно информации для корректной интерпретации выводов системы. Распространённая практика 2025 года — писать «system card» прозой. Мы утверждаем, что проза необходима, но недостаточна: внедренцу также нужно машиночитаемое представление, проверяемое против фактически развёрнутых артефактов. EATF связывает system card, идентификатор модели и версию политики в метаданных Evidence Package и предоставляет верификацию на h2oatlas.ee/verify/.... Внедренец (или последующий аудитор) может, таким образом, ответить «система, которую я запускаю сегодня, — та, что задокументирована поставщиком?», не доверяя ни одной из сторон. Валидация цепочки доверия по EN 319 102-1 даёт формальное основание.

4.4 Статья 14 — смежная, не удовлетворённая

Статья 14 предписывает эффективный человеческий надзор: люди должны иметь возможность полностью понимать, мониторить, вмешиваться и переопределять AI-систему. Криптографический якорь на событиях утверждения необходим, но недостаточен для того, чтобы надзор был осмысленным. PKI даёт нам проверяемую запись о том, что человек утвердил во время T под политикой P; PKI не делает это утверждение информированным, обдуманным или не-«rubberstamp». Мы говорим это явно: PKI-линза делает исходы проверяемыми и атрибутируемыми, а не поднадзорными в политическом смысле. HCI-работа по дизайну осмысленных flow утверждения и политическая работа над тем, что составляет «осмысленный» надзор, лежат на слой выше. Поэтому в маппинг-таблице мы помечаем Статью 14 как смежную — EATF поставляет примитивы, которые любой Статья-14-комплаентный flow может переиспользовать, но поставка их — это не то же самое, что исполнение обязательства.

4.5 Статьи 11, 26, 27 — следственные маппинги

Оставшиеся статьи маппинг-таблицы выпадают из прочтения §4.1–§4.3 как следствия; рассматриваем их кратко, в порядке документа.

Статья 11 — Техническая документация. Статья 11 + Приложение IV требуют от поставщика поддерживать техническую документацию, позволяющую властям оценить соответствие. PKI-нативная реализация прямолинейна: документация — структурированный артефакт (system card + model card + policy pack + risk-management notes), он канонизируется (CBOR или JCS), подписывается под профилем CAdES, и хеш подписанного бандла ссылается из каждого Evidence Package, эмитируемого этой системой. Регулятор, получающий один Evidence Package, может пройти по полю mch (model-card hash), чтобы получить точную техническую документацию, действовавшую на момент подписи. Это прямой, не смежный, маппинг: обязательство Статьи 11 ложится на единичный бандл и единичное связующее ребро от runtime-доказательства к документации, оба верифицируемы офлайн.

Статья 26 — Обязанности внедренца. Статья 26 налагает обязательства на внедренца (entity, использующее высокорисковую AI-систему в эксплуатации), отличного от поставщика (entity, помещающего систему на рынок). Два обязательства имеют прямой PKI-фит: 26(2) (использовать как указано поставщиком) и 26(5) (логирование). Первое ложится на подписанный внедренцем deployment-манифест — CAdES-подписанный JSON или CBOR-объект, утверждающий, какую систему поставщика, версию, модель и политику внедренец активировал. Второе — тот же журнал Статьи 12 из §4.2, ограниченный внедренцем, а не поставщиком. Фрейминг substrate-vs-vertical из §1 — отчасти артефакт Статьи 26: каждый внедренец («вертикаль») подписывает свой манифест под своими полномочиями, на субстрате поставщика.

Статья 27 — Оценка воздействия на основные права. Статья 27 требует от внедренцев в специфических контекстах Приложения III (публичные услуги, банкинг, страхование, контексты решений о найме) проводить FRIA до развёртывания. FRIA — это артефакт: структурированный документ, утверждающий, что внедренец рассмотрел воздействие на основные права в конкретных фактах. PKI-реализация подписывает FRIA под полномочиями внедренца, ссылается на deployment-манифест Статьи 26 по хешу и публикует получившийся бандл в верификатор вроде h2oatlas.ee/verify/. Где FRIA ссылается на популяции обучающих данных или поведение модели в конкретных условиях, эти ссылки сами по себе — артефактные утверждения, и могут быть хешированы и пересвязаны. Мы не утверждаем, что подпись FRIA делает оценку правильной; мы утверждаем, что подпись делает её audit-traceable в операционном смысле, который подразумевает Статья 27.

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

Рисунок 1 — обзор маппинга

Один взгляд на то, как восемь статей AI Act транслируются в PKI-нативные артефакты EATF. Сплошные сплошные стрелки — прямой PKI-фит; пунктирные — смежная поддержка (Статья 14); серые блоки — governance/runtime-вопросы за границей субстрата.

flowchart LR
    classDef incl fill:#dcfce7,stroke:#15803d,color:#14532d
    classDef adj fill:#fef3c7,stroke:#92400e,color:#78350f
    classDef out fill:#e5e7eb,stroke:#6b7280,color:#374151
    classDef art fill:#dbeafe,stroke:#1e40af,color:#1e3a8a

    subgraph AIAct["AI Act — высокорисковый режим"]
      direction TB
      A9[Ст. 9<br/>Управление рисками]:::out
      A10[Ст. 10<br/>Данные<br/>узкое прочтение]:::incl
      A11[Ст. 11<br/>Тех. документация]:::incl
      A12[Ст. 12<br/>Record-keeping]:::incl
      A13[Ст. 13<br/>Прозрачность]:::incl
      A14[Ст. 14<br/>Надзор<br/>смежная]:::adj
      A15[Ст. 15<br/>Точность / robustness]:::out
      A26[Ст. 26<br/>Внедренец]:::incl
      A27[Ст. 27<br/>FRIA]:::incl
    end

    subgraph EATF["EATF / Aletheia артефакты"]
      direction TB
      AEP[.aep Evidence<br/>Package]:::art
      LED[Hash-цепь<br/>журнала аудита]:::art
      VER[Верификатор<br/>UI / API]:::art
      MFT[Подписанный<br/>deployment-манифест]:::art
      FRIA[FRIA-бандл<br/>привязан к манифесту]:::art
    end

    A10 -->|hash датасета<br/>+ привязка<br/>model-card| AEP
    A11 -->|подписанный<br/>system-card| AEP
    A12 -->|append-only<br/>+ RFC 3161| LED
    A13 -->|chain-of-trust<br/>EN 319 102-1| VER
    A14 -.события<br/>утверждения.-> AEP
    A26 -->|подпись<br/>внедренцем| MFT
    A27 -->|hash-привязка<br/>к манифесту| FRIA

    AEP --> LED
    AEP --> VER
    MFT --> AEP
    FRIA --> AEP

Вкратце: каждая статья, попадающая в зелёный (несущий) или жёлтый (смежный) блок, разрешается в один или больше подписанных EATF-артефактов; серые блоки — границы PKI-линзы (см. §8). Версия этого рисунка под MiMo-V2-Omni (более полированная, для печатной версии препринта) появится в v1 после активации гранта.

5 · Реализация: EATF / Aletheia

5.1 Архитектурный обзор

EATF / Aletheia — Java 21 / Spring Boot 3.5 backend с CLI партнёрской интеграции (eatf). Pipeline подписи:

flowchart LR
    classDef step fill:#dbeafe,stroke:#1e40af,color:#1e3a8a
    classDef opt fill:#fef3c7,stroke:#92400e,color:#78350f,stroke-dasharray: 5 5
    classDef out fill:#dcfce7,stroke:#15803d,color:#14532d

    P[Канонический payload]:::step --> H[Хеш <br/> SHA-256 / SHA3-256]:::step
    H --> S[Подпись <br/> RSA-PSS или ML-DSA-65 hybrid]:::step
    S --> T[Опционально <br/> метка времени RFC 3161]:::opt
    T --> E[Evidence Package <br/> .aep]:::out
    E --> L[Событие журнала аудита <br/> SHA-256 hash-chain <br/> постквантовые подписи блоков]:::out

Каждый пакет .aep проверяем офлайн: третья сторона с публичным бандлом (цепочка сертификатов + сертификат TSA + метаданные payload-а) может верифицировать подпись, не обращаясь к хосту подписи.

Шаг журнала аудита справа сам по себе постквантово-защищён: блоки связаны хешами SHA-256 (Grover-стойкость — 256-битовая pre-image-стойкость снижается лишь до 128 бит под квантовой атакой), и заголовок каждого блока подписан тем же гибридным примитивом RSA-4096 + ML-DSA-65, что и payload подписи (FIPS 204; см. PLAN_PQC). Достаточно мощный квантовый противник не может подделать исторические записи журнала, не сломав ML-DSA, что в настоящее время считается невыполнимым.

5.2 Гибридный PQC

Гибридный режим производит единый .aep, несущий и классическую подпись (RSA-PSS или ECDSA), и подпись ML-DSA-65. Верификаторы МОГУТ требовать любую, обе или все по политике развёртывания. Раздувание сертификатов — основная операционная забота; обсуждение размеров и ротации в §5.5.

Размеры подписей и сертификатов в гибридном режиме:

Алгоритм	Подпись	Открытый ключ	Закрытый ключ
RSA-2048 (PSS)	256 B	270 B	1.2 KiB
RSA-4096 (PSS)	512 B	540 B	2.4 KiB
ECDSA-P256	64–72 B	91 B	32 B
ML-DSA-65 (FIPS 204)	3 309 B	1 952 B	4 032 B
Гибрид RSA-4096 + ML-DSA-65	~3.8 KiB	~2.5 KiB	~6.4 KiB

«Налог на гибрид» — единичный k×3.8 KiB на пакет — приемлем для большинства AI evidence workflow, где payload-ы (вход + выход + метаданные) сами составляют десятки килобайт.

5.3 Привязка модели и политики

Каждый Evidence Package связывает:

input hash (канонический AI-вход)
output hash (канонический AI-выход)
идентификатор модели (semver + build hash) и опционально URL model-card
версия политики (semver governance-политики, действовавшей в момент подписи)
метка времени (RFC 3161 от настроенного TSA)

Эта привязка — тот артефакт, который Статьи 12 и 13 AI Act просят в операционных терминах.

5.4 Уникальность серийных номеров под eIDAS 2

Проект Регламента 2025/1943 продвигает уникальность serialNumber с per-CA на TSP-wide для квалифицированных TSP. Анализируем три архитектурные опции:

A — Центральный орган серийных номеров. Все CA в TSP запрашивают серийные номера у единого высокодоступного органа, гарантирующего атомарность и аудит. Уверенность в соответствии: high.
B — Глобальный реестр перед выпуском. Все потоки выпуска проходят через CertManager, консультирующийся с глобальным реестром. Уверенность: medium, зависит от полноты потоков.
C — Случайные + пост-фактум скан. Выпуск с серийниками высокой энтропии, периодический скан, разрешение коллизий. Уверенность: low — слабо при чтении shall be unique.

(См. методологическое примечание §6.4 о том, почему уровни ординальные, а не процентные.)

В EATF мы принимаем опцию A. Обсуждение принадлежит этой статье потому, что то же TSP-wide мышление прямо ложится на CA, подписывающие AI-доказательства: если AI-провенанс масштабируется до enterprise, CA, подписывающие доказательства, сталкиваются с той же проблемой уникальности.

5.5 Операционные артефакты

eatf init — provision пары ключей внедренца и регистрационного бандла.
eatf doctor — самопроверка подписи, доступности TSA, свежести OCSP.
eatf sign — производство .aep для payload-а контента.
eatf verify — офлайн-верификация .aep.
eatf agents sync — регистрация агентов под внедренцем.

Per-tenant размер блока для журнала аудита и хуки audit_event на /api/sign введены в обновлении субстрата конца апреля 2026.

5.6 Наблюдаемый операционный риск

В апреле 2026 мы наблюдали истечение привязки ключа OCSP-ответчика в продакшн-развёртывании EJBCA, потребовавшее ручного обновления CSR из-за ограничений HSM-драйвера (ограничения клонирования виртуального HSM Utimaco). Инцидент показателен потому, что демонстрирует: PKI-нативное доверие — не бесплатно: оно наследует операционную строгость лежащего в основе CA. Любая платформа «AI signing», не оплачивающая эту цену, не доставляет юридический эффект, который подразумевает Статья 12 AI Act.

5.7 Формат Evidence Package

Для воспроизводимости описываем пакет .aep как CDDL-схему (RFC 8610). Wire-формат сейчас CBOR; JSON-профиль существует для браузерных верификаторов, но не является каноническим. Имена полей выбраны для компактности, а не читаемости — читаемая форма реконструируется eatf verify --explain.

; ----- top-level конверт -----
aep = {
  v: uint,                ; версия формата, сейчас 1
  pid: bstr .size 16,     ; package id (UUID v4)
  ts: tstr,               ; время эмиссии, RFC 3339 UTC
  pl: payload,            ; подписанное утверждение
  sig: signatures,        ; одна или более подписей
  ? tsa: tstr,            ; токен RFC 3161 TSA, base64
  ? rev: revocation,      ; OCSP / CRL на момент подписи
  ? meta: { * tstr => any }, ; метаданные внедренца
}

; ----- payload (подписанное утверждение) -----
payload = {
  ph: bstr .size 32,      ; SHA-256 канонических байтов payload
  ct: tstr,               ; тип контента ("model-card", "ai-output", "audit-event")
  ih: bstr .size 32,      ; SHA-256 канонического входа
  oh: bstr .size 32,      ; SHA-256 канонического выхода
  mid: tstr,              ; id модели (semver + build hash)
  ? mch: bstr .size 32,   ; хеш model-card (опционально)
  pol: tstr,              ; версия политики (semver)
  dep: tstr,              ; id внедренца (URI)
  ? agt: tstr,            ; id агента (URI, опционально)
}

; ----- подписи (1+; гибрид PQC = 2) -----
signatures = [+ signature]

signature = {
  alg: tstr,              ; "RSASSA-PSS-SHA256" / "ECDSA-P256-SHA256"
                          ;   / "ML-DSA-65" / "Hybrid-RSA-MLDSA"
  kid: tstr,              ; key id (URI к сертификату)
  cert: bstr,             ; сертификат подписи (DER)
  chain: [* bstr],        ; промежуточные сертификаты (DER)
  val: bstr,              ; байты подписи
}

; ----- снимок отзыва (захвачен в момент подписи) -----
revocation = {
  ocsp: bstr,             ; ответ OCSP (DER, RFC 6960)
  ? crl: bstr,            ; CRL (DER), если используется
  fresh_at: tstr,         ; RFC 3339 timestamp получения
}

Канонические байты payload-а производятся детерминированной CBOR-кодировкой (RFC 8949 §4.2.1) карты payload. Поле ph — SHA-256 этих байтов; подписи покрывают $\mathit{ph} \,\|\, \mathit{ts} \,\|\, \mathit{pid}$ так, что повторы с другим $\mathit{ts}$ или $\mathit{pid}$ различимы.

Гибридные подписи появляются как две записи в массиве signatures под одним kid, но разными значениями alg: одна классическая (RSASSA-PSS-SHA256) и одна постквантовая (ML-DSA-65). Верификаторы, настроенные на «либо», принимают по первому валидному совпадению; верификаторы, настроенные на «обе», требуют валидации всех записей. Мы не комбинируем подписи в единый композитный примитив на этом этапе; NIST ещё определяется с форматами гибридных подписей, и forward-совместимое «split» представление операционно безопаснее сейчас.

Evidence-id binding. Поле pid включено в подписанные данные, поэтому третья сторона не может снять подпись с одного пакета и прикрепить её к другому с другим pid. Это защищает от противника подменщика в потоке из §3.

Офлайн-верификация. eatf verify проверяет: (i) подпись(и) валидируется относительно cert; (ii) cert цепляется к настроенному trust anchor под EN 319 102-1; (iii) состояние OCSP / CRL в rev было свежим на fresh_at и согласовано с сертификатом; (iv) опциональный TSA-токен в tsa валидируется относительно публичного ключа TSA и связан с ph. Сетевой доступ не требуется.

Эталонный верификатор на Java поставляется с EATF CLI; независимый Python-верификатор (aletheia-py-verify, ~700 строк) предоставлен, чтобы ни одной стороне не нужно было доверять кодовой базе EATF для верификации. Оба прогоняются набором cross-implementation conformance-тестов.

5.8 Двухрежимная модель подписи — sign vs attest

EATF выставляет один и тот же криптографический примитив (canonicalise → SHA-256 → гибрид RSA-4096 + ML-DSA-65 → RFC 3161 timestamp) через два различных endpoint-а, отличающиеся строгостью интеграции, богатством audit-trail и Статьями AI Act, которые они помогают исполнить. Явное наименование этой дуальности — часть вклада данной статьи: одна и та же партнёрская интеграция может удовлетворить обязательства целостности единственным HTTP-вызовом и перейти к полной policy-оценённой аттестации, изменив один URL endpoint-а.

Дерево решений.

flowchart TB
    Q1{Вывод подпадает<br/>под высокорисковый режим AI Act?<br/>Приложение III / Ст. 6}
    Q1 -->|Нет| S1[<b>sign mode</b><br/>POST /api/sign<br/>только API-ключ]
    Q1 -->|Да| Q2{Политика внедренца<br/>гейтит это действие?}
    Q2 -->|Нет| S2[<b>sign mode</b> + agentId<br/>только Статья 12]
    Q2 -->|Да| A1[<b>attest mode</b><br/>POST /api/v1/attest<br/>Статьи 12 + 13 + 14]

Бок о бок.

	sign mode (`POST /api/sign`)	attest mode (`POST /api/v1/attest`)
Обязательные поля	`response` (≤ 512 KiB)	`agentId`, `actionType`, `input`, `output`, `policyId`, `policyVersion`
Регистрация агента	опциональна (рекомендуется для атрибуции)	обязательна
Политика с правилами	не требуется	требуется
Криптографический конверт	гибрид RSA-4096 + ML-DSA-65 + RFC 3161	идентичен
Аудит-атрибуция	tenant + (опционально) URN агента	всегда агент (зарегистрированный)
Соответствие статье AI Act	Ст. 12 (record-keeping)	Ст. 12 + 13 + 14 (record-keeping + transparency + oversight)
Заявление о доверии	«этот контент tamper-evidenced на момент T»	«это AI-действие policy-оценено и tamper-evidenced на момент T»
Цена интеграции	один HTTP-вызов	регистрация агента + политика + таксономия action_type

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

Градиент адаптации. Партнёр может выкатить sign-mode-интеграцию за полдня (без агента, без политики, один HTTP-вызов) и мигрировать на attest mode позже, когда его регуляторная поверхность усложнится. Attest mode — строгое надмножество sign mode по входам; исторические sign-mode-записи остаются валидными и офлайн-проверяемыми после миграции, им просто не хватает байтов policy-coverage-report, которые attest-mode-записи несут далее.
Точность маппинга по Статьям. §4 маппит каждую Статью AI Act на PKI-рычаги. Два режима позволяют внедренцу выбрать именно ту поверхность Статьи, которая ему нужна. Если use case затрагивает только Статью 12 (record-keeping), sign mode — минимальный жизнеспособный ответ; платить цену интеграции attest mode значит добавлять операционную нагрузку без compliance-выигрыша. Если use case затрагивает Статьи 13 (прозрачность) или 14 (привязка надзора), attest mode требуется.
Честный фрейминг субстрата. §1 утверждал, что EATF — субстрат, не вертикальный продукт. Двухрежимная модель делает это реальным: субстрат выставляет один и тот же криптопримитив через две поверхности интеграции, и партнёры самосортируются по форме их compliance. Нет «EATF-предписанного режима»; есть дерево решений.

Самореферентная виньетка. Сама эта статья подписана в sign mode. CI репозитория статьи (paper-pki-ai-act) собирает Astro/Starlight-сайт, хеширует каждый исходник главы и отрендеренный HTML в deploy-манифест и POST-ит манифест в /api/sign под зарегистрированным агентом urn:uuid:a8adb22e-e8b9-45ae-bfda-b474e1669b8c (paper-pki-ai-act-publisher). Получившийся файл аттестации публикуется на https://paper.eatf.eu/.well-known/eatf-attestation.json. Мы выбрали sign mode потому, что написание статьи не подпадает под высокорисковые обязательства AI Act по Приложению III; Статья 12 (record-keeping) — единственная релевантная поверхность. Если бы тот же publication-pipeline использовался, скажем, для подписи AI-выводов медицинских рекомендаций, attest mode был бы обязателен.

Публичный каталог. Машиночитаемое описание двух режимов — endpoint-ы, обязательные/опциональные поля, prerequisites, критерии use-when / do-not-use-when и Статьи AI Act, которые каждый помогает исполнить, — выставлено на GET /api/public/signing-modes. То же содержимое отрендерено в человекочитаемой форме на https://eatf.eu/concepts/signing-modes с интерактивным компонентом дерева решений, а длинная прозовая версия живёт в docs/concepts/signing-modes.md в исходном дереве EATF.

6 · Оценка

Мы оцениваем EATF по четырём измерениям: пропускная способность подписи, стоимость верификации, фит к вертикалям (качественно) и ординальная уверенность в соответствии для перехода eIDAS 2.

6.1 Пропускная способность подписи

Aspirational целевая полоса. Медианная end-to-end задержка eatf sign (отправка payload-а → эмиссия .aep, включая RTT TSA) ниже 200 мс в классическом режиме, ниже 350 мс в гибридном PQC (RSA-PSS-SHA256 + ML-DSA-65). p99 ниже 750 мс в обоих режимах.

Обоснование. Классический путь определяется тремя стоимостями: SHA-256 канонического payload-а (пренебрежимо для payload-ов до 1 МБ), подпись RSA-PSS-2048 (~1–2 мс на современном железе с PKCS#11 HSM-доступом через драйверы Utimaco / Thales) и round-trip RFC 3161. Публичные TSA обычно отвечают за 80–150 мс; приватные TSA, со-локализованные с подписантом, снижают это до ~10 мс. Основную задержку относим на RTT TSA, остаток — на сериализацию и handoff в полиси-движок.

Гибридный режим добавляет подпись ML-DSA-65; software-only ML-DSA-65 на commodity-железе сейчас в диапазоне 5–15 мс, с существенным ускорением при HW-акселерации, когда она доступна. Добавление ML-DSA увеличивает подписанные байты (размер подписи ~3.3 КБ против 256 Б для RSA-2048), но не удваивает round-trip; целевые значения выше поглощают приращение без удвоения.

Бюджет задержки (классический, медиана):

T_{\text{sign}} \;=\; \underbrace{T_{\text{SHA-256}}}_{<1\text{ мс}} \;+\; \underbrace{T_{\text{RSA-PSS}}}_{1\text{–}2\text{ мс}} \;+\; \underbrace{T_{\text{TSA}}}_{80\text{–}150\text{ мс}} \;+\; \underbrace{T_{\text{policy}}}_{\sim 30\text{ мс}} \;\approx\; 110\text{–}180\text{ мс}.

В гибриде добавляется $T_{\text{ML-DSA-65}} \in [5, 15]$ мс, итого ~120–195 мс медианно.

6.2 Стоимость верификации

Целевая полоса. Медианная eatf verify (офлайн-путь) ниже 50 мс классически, ниже 80 мс в гибриде. p99 ниже 150 мс в обоих режимах, когда состояние OCSP / CRL захвачено в пакет (типичный случай) и сетевой фетч не нужен.

Обоснование. Офлайн-верификация состоит из: разбор CBOR-конверта (< мс), валидация подписей RSA-PSS / ML-DSA (3–10 мс каждая), валидация цепочки сертификатов под EN 319 102-1 (1–5 мс для типовых 3-уровневых цепочек), валидация захваченного OCSP-ответа (1–3 мс), валидация опционального TSA-токена (5–10 мс). Целевое значение 50 мс оставляет комфортный запас для batched-верификации.

Отдельный режим live-верификации, в котором верификатор переподтягивает свежий OCSP, имеет другую огибающую, доминируемую сетевой задержкой (типично 80–300 мс). Live-верификацию рекомендуем только для high-stakes верификаций под политикой внедренца; рутинные верификации должны полагаться на встроенный OCSP, захваченный во время подписи.

6.3 Фит к вертикалям

Пять партнёрских интеграций упражняют субстрат:

TADF Auditor (энергоаудит зданий, выкачен в продакшн 2026-04-26 на tadf-audit.h2oatlas.ee). Evidence-пакеты оборачивают отрендеренный DOCX-отчёт аудита. Объём подписи: десятки отчётов в неделю на аудитора, комфортно ниже любых пропускных concern-ов.
EU AI Act Legal Advisor (mock, на eu-ai-act.h2oatlas.ee). Демонстратор, подписывающий regulatory-mapping вывод агента. Используется как конкретный демо при объяснении субстрата нетехническим аудиториям.
Water Analyst (water-quality-ee, ежедневный бюллетень P(нарушения) в подготовке, см. §7). Дневной батч: ~5 пакетов бюллетеня с привязанной model-card плюс per-site артефакты верификации. Объём скромный; видимость высокая (публикация для граждан).
Medical AI (seed, зависит от domain co-founder). Самая high-stakes вертикаль, сознательно отложенная до закаливания субстрата. Разделение integrity-vs-clinical из §3 — ключевое утверждение для procurement-нарратива этой вертикали.
KYC-агент (backlog). Downstream от authorize Visa CLI; evidence-пакет документирует обоснование одобрения / удержания транзакции. Чувствителен к задержке (target: ниже 200 мс в authorisation-пути).

Качественный вывод из этих интеграций: субстрат однороден; вертикали — нет. Адаптация субстрата к каждой вертикали происходит на границе metadata-and-policy, а не в примитивах подписи. Это операционное свидетельство в основе фрейминга subscriber-not-product из §1.

6.4 Доверительные полосы вероятности соответствия

Для перехода уникальности серийных номеров eIDAS 2 (§5.4) оцениваем соответствие при трёх архитектурных опциях:

Опция	Описание	Соответствие
A — Центральный орган серийных номеров	Атомарность в скоупе TSP; HA-репликация, подписанный аудит-журнал выпуска	высокая
B — Глобальный реестр перед выпуском	Все потоки выпуска проходят через CertManager, консультирующийся с реестром	средняя (зависит от полноты потоков)
C — Случайные + пост-фактум скан	Серийники высокой энтропии; периодический скан коллизий и ремедиация	низкая (слабо при чтении «shall be unique»)

Ранние черновики этой статьи содержали процентные доверительные полосы (90–95% / 75–88% / 35–60%). Они снят: оценки выведены из одного автора с операционным опытом, без формальной экспертной элиситации, без калибровочного набора и без статистического теста. Корректное прочтение — ординальное (high / medium / low). v1 заменит ординал на процентный диапазон только при условии Delphi-style консультации с QTSP-операторами, оцениваемого свидетельства вокруг проекта 2025/1943 implementing act и явного описания методологии. В EATF мы принимаем опцию A.

6.5 Ограничения этой оценки

Мы не делаем заявлений о выводах AI, подписываемых EATF. Мы измеряем слой доверия, а не модель. Это согласуется с §3 (модель угрозы) и §4 (сужение Статьи 10).

Мы не оцениваем против явного противника (game-based threat model). Модель угрозы в §3 неформальна; формальный криптоанализ canonical-payload binding под стандартными моделями (EUF-CMA для лежащих в основе схем подписи, с соответствующей редукцией к evidence-id binding) — последующая статья.

7 · Связанные работы

Мы позиционируем EATF против пяти смежных линий работ, каждая из которых решает связанную, но различную задачу.

Content-credentials (C2PA) адресуют медиа-провенанс: откуда пришло это изображение, какие правки применены, кто аттестировал. C2PA-манифест сам по себе — подписанная структура, носимая в JPEG/PNG/MP4-метаданных. Совпадение с EATF частичное: оба производят подписанные провенанс-бандлы, но C2PA media-shaped (image-level хеши, история правок), а EATF action-shaped (AI-вход → AI-выход). Два композируемы: C2PA-подписанное изображение, потребляемое AI-агентом, может ссылаться из EATF Evidence Package как input-hash агента, и получившийся AI-вывод (например, caption) может в свою очередь быть C2PA-подписан, если он медиа. Мы не подменяем C2PA; мы её используем.

SLSA / in-toto (supply-chain attestation). SLSA определяет уровни целостности для build pipeline-ов и использует in-toto аттестации как подписанные метаданные о том, как был произведён артефакт. Совпадение с EATF структурное: оба связывают подпись с каноническим утверждением о происхождении артефакта. Различие — домен: SLSA — о software-сборках и tamper-evident CI, EATF — об AI-runtime-решениях. Мы заимствуем паттерн attestation predicate — типизированное, schema-валидированное утверждение — и отличаемся помещением аттестации в CBOR, а не DSSE, и переносом revocation state inline (SLSA отдаёт revocation обычным каналам PKI; EATF захватывает OCSP-ответ во время подписи, чтобы верификаторам не нужно было его переподтягивать).

W3C Verifiable Credentials (VC) и Decentralized Identifiers (DID). VC определяет JSON-LD-shaped контейнер для подписанных утверждений о субъектах; DID предоставляют идентификаторы субъектов без центрального регистратора. Совпадение с EATF — в паттерне подписанного утверждения. Различия практичные: канонизация JSON-LD у VC была повторяющимся источником implementation-hazard, а VC предполагает wallet-style треугольник holder–issuer–verifier, который не натурально ложится на AI-внедренцев. CBOR-based wire-формат EATF и QTSP-уровень цепочки сертификатов идут по другому операционному пути; считаем оба разумными, и мост EATF-to-VC для use-case-ов, где wallet-семантика важна, — разумная следующая работа.

Model Context Protocol (MCP). MCP определяет идентичность агента, discovery возможностей и вызов инструментов. Совпадение с EATF — комплементарное: MCP отвечает на «кто этот агент и что он может?», EATF — на «что он реально сделал, на каком входе, под какой политикой?». Делаем это явно в §2.5: идентичность, провенанс и governance — три ортогональных слоя, и схлопывание их даёт тот же сбой, что схлопывание аутентификации с авторизацией. MCP-aware внедренец может ссылаться на идентификатор MCP-сервера как поле agt в payload-е EATF и связать два вместе.

Visa CLI (паттерн action-firewall). Экспериментальный платёжный rail, в котором authorize Aletheia предшествует любому платёжному действию, инициированному AI-агентом. Не подмена PSD2/SCA/AML; комплементарный governance-слой. Упоминаем потому, что он кристаллизует тезис substrate-vs-vertical из §1: тот же provenance-субстрат переиспользуется для платёжной вертикали, с дополнительным governance-гейтом, добавленным на rail.

Стандарты trustworthy AI assurance. ISO/IEC 23894 (управление AI-рисками), серия IEEE 7000 (этический дизайн), NIST AI Risk Management Framework. Они выше этой статьи как мотивация: они описывают, как должен выглядеть trustworthy AI на process-уровне. Они не транслируют обязательства в PKI-нативные артефакты, и это закрывает данная статья.

Фрейминг «zero-trust для AI». Несколько коммерческих фреймворков 2025–2026 ребрендят zero-trust-принципы как AI-governance. Zero-trust — это дисциплина идентичности и доступа, адресующая сетевые и сессионные границы; провенанс — отдельный слой, адресующий целостность артефакта во времени. Схлопывание их даёт тот же сбой, что схлопывание аутентификации с авторизацией: фреймворк может выглядеть исчерпывающим, оставляя целые классы post-hoc-аудитов без ответа.

Недавние академические работы по провенансу. Криптографическая литература по AI-провенансу за 2024–2026 годы развивается в трёх направлениях, к которым мы позиционируем себя как комплементарные, не конкурирующие:

Verifiable inference / zkML. Работы Reckle Trees (Beimel et al., IACR ePrint 2024/1153) и SafeML / ezkl (Sun et al., S&P 2024) строят zero-knowledge доказательства того, что заявленный output модели был корректно вычислен данным набором весов на данном входе. Это вычислительная верификация модели; EATF — учётная верификация артефактов вокруг модели. Композиция: zkML-доказательство можно поместить в payload .aep как часть output, и подпись EATF свидетельствует, что внедренец заявил это доказательство в это время под этой политикой.
Transcript binding для LLM. Park et al. (USENIX Security 2025) и развитие в IACR ePrint 2025/0741 рассматривают, как cryptographically привязать транскрипт чата LLM к ответственной стороне без раскрытия весов. Их фокус — what was said; наш — what action was authorised on the basis of what was said. Опять компонуется: транскрипт можно референсить из input_hash пакета .aep.
Attestation of model evaluation. ProveML (Goyal et al., IACR ePrint 2024/1428) даёт publicly-verifiable evaluation report на benchmark. Под Статьёй 13 AI Act это могло бы стать частью system card — снова, EATF как контейнер, ProveML как содержимое.

Где эти работы спрашивают какой криптопримитив может аттестовать поведение модели?, мы спрашиваем какие существующие доверенные услуги под eIDAS можно переиспользовать, и как выглядит результирующий маппинг по Статьям?. Полная formalised literature table — в bibliography.

8 · Заключение и открытые проблемы

PKI-линза достаточна для значительной части высокорисковой поверхности AI Act — Статей 10 (узко прочитанной), 12 и 13 — и недостаточна для Статьи 14 (человеческий надзор), более широкого data-governance-измерения Статьи 10 и runtime-вопросов под Статьёй 15. Мы дали маппинг по Статьям, эталонную реализацию (EATF / Aletheia) как Доверенный слой AI-доказательств, три архитектурные опции уникальности серийных номеров eIDAS 2 с явными доверительными полосами вероятности соответствия и указатели на пять партнёрских интеграций как свидетельство достаточности субстрата.

Открытые проблемы, которые мы здесь не решаем:

Data-quality-измерение Статьи 10. PKI-линза не может расширяться сюда без отдельного режима ML / data governance. Какая стандартизация может комплементировать подписанный провенанс подписанными утверждениями fitness?
Привязка надзора Статьи 14. События утверждения тривиально подписываемы. Осмысленный надзор — нет. HCI и политическая работа вне PKI-домена.
Кросс-юрисдикционный trust-list interop для AI-доказательств. EU Trusted Lists существуют для доверенных услуг. Аналогичного списка CA, подписывающих AI-доказательства, нет. Должен ли быть?
PQC + долговечность журнала аудита. 30-летняя политика хранения при одновременной депрекации классических и PQC-алгоритмов — открытый вопрос.
Делегирование агент-агенту. Когда агенты действуют от имени агентов от имени пользователей, цепочка ответственного органа в audit-trail ещё не стандартизирована.
Privacy-preserving evidence-пакеты. Сегодняшние пакеты .aep идентифицируют внедренца. Можем ли мы подписывать без раскрытия? Selective disclosure под verifier-binding правдоподобен, но не реализован.

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

И последнее. В 2055 году исследователь истории права открывает наш пакет. ML-DSA-65 уже депрекирован. Архивные метки PAdES-LTA, добавленные в 2034-м, поднимают первоначальную подпись, валидируют её под алгоритмом её эпохи, и за двенадцать минут — на ноутбуке, без обращения к серверу — возвращают: «подпись была валидна 7 мая 2026 года, в 14:33 UTC». Это и есть «record-keeping» в смысле Статьи 12 — на тридцать лет. Сегодня мы строим то, что в 2055-м будет работать.

Благодарности

Барту Симонсу (PKI Consortium) и Йосу Де Вахтеру за консультации по измерениям eIDAS / ETSI; курсу TalTech Vanem arendajaks (Команда 67) за организацию защиты EATF 2026-05-05; и развёртываниям партнёрских интеграций, давшим обратную связь от реального мира.

Воспроизводимость

Все Evidence Packages, обсуждаемые в этой статье, верифицируемы офлайн против публичного CLI на https://github.com/sapsan14/aletheia-ai. Подписанный исходник этой статьи опубликован на https://github.com/sapsan14/paper-pki-ai-act; манифест каждого деплоя подписан в sign mode (см. §5.8) и опубликован на https://paper.eatf.eu/.well-known/eatf-attestation.json для независимой верификации.