Кратко

  • draft-das-eu-ai-act-execution-enforcement-00 датирован 5 сентября 2026 года. Это активный индивидуальный Internet-Draft Sangam Das с заявленным целевым статусом Informational, а не стандарт IETF или заключение регулятора.
  • Существенная операция остаётся не вступившим в силу Candidate Act; затем проверяются заранее заданные ограничения, выдаётся полномочие для точного акта, а Finality Sink повторяет проверку перед первым защищённым внешним эффектом.
  • Раздел 35 прямо ограничивает свойство эффектами, прошедшими через защищённую границу. Показанный рядом прямой внешний API такой защиты не получает.
  • Python-реализация v0.1.0 моделирует единственный локальный API записи эффекта. Проект и репозиторий не называют её производственным средством безопасности или правовым движком соответствия.
  • Для системного утверждения нужен отчёт о замкнутости поверхности эффекта: все пути, версии маршрутов, обходные полномочия, исключения и отрицательные испытания каждого пути.

Отказ важен только на неизбежном пути

Архитектура разделяет вычисление и право на действие. ИИ может подготовить платёж, сообщение, публикацию, запись или команду, но результат сначала фиксируется как Candidate Act. Защищённая функция проверяет машиночитаемые условия, определённые компетентной стороной. Разрешение связывается с содержанием, целью, получателем, эпохой политики, сроком и sink. Перед эффектом снова проверяются digest, подпись, отзыв, однократность, доказательство владения и текущее состояние.

Это не позволяет принять аутентификацию workload за разрешение на все его действия. Одобрение одной суммы не переносится на другую. Журнал после отправки не равен предотвращению.

Но схема в разделе безопасности показывает развилку: агент обращается к Finality Sink и к direct external API. Для второго маршрута, говорит документ, finality protection не установлена. Компонент может безошибочно отказать всему, что видит, и не увидеть решающий вызов.

Так бывает в абстрактной схеме, где платёжный gateway защищён, а сервисная учётная запись достигает settlement напрямую; публикационная служба требует разрешение, а storage credential открывает файл; database proxy контролируется, но существует аварийная строка подключения. Это не утверждения о реальных инцидентах. Они определяют единицу проверки: поверхность эффекта, а не наличие продукта.

Выбранное последствие, полный набор путей

Проект не требует пропускать через sink каждый token, read или packet. Он выбирает существенные переходы. Такая минимальность разумна: не надо централизовать все вычисления, чтобы защитить момент платежа, отправки, commit, публикации или активации.

Но после выбора последствия необходимо включить все пути к нему либо явно назвать исключения. Основной API, fallback, batch, SDK, административная учётная запись, storage rule и сервис получателя могут привести к одному результату. Удобный маршрут не определяет весь периметр.

Для удалённого эффекта важна точка наблюдения. В документе сказано, что локальная проверка не делает произвольный Internet request атомарным. Могут потребоваться sink у получателя, idempotency, transactional outbox или координация состояний. Испытание должно доходить до первого реально доступного внешнего состояния.

Граница демонстрации

Версия 0.1.0 реализует каноническое представление, SHA-256, Ed25519, proof-of-possession, эпохи политики, nonce и локальное потребление в SQLite. В синтетическом примере поддержки подмена цели отклоняется до записи эффекта.

README называет решающую предпосылку: единственный effect-recording API находится внутри sink. В реальной среде сетевой выход, commit базы, платёж, экспорт файла, вызов инструмента и иные пути должны быть опосредованы эквивалентно.

Это работающий код для ограниченной модели, а не доказательство неизвестной production topology. Нет производственных HSM и TEE, распределённого консенсуса, полного PKI lifecycle, формальной верификации, высокой доступности, защиты от side channel, полной удалённой атомарности или оценки соответствия. Логическое разделение внутри одного Python-процесса не изолирует данные от его неограниченного администратора.

Отчёт о замкнутости

Сначала отчёт определяет последствие и момент его первой внешней пригодности. Затем перечисляет gateway, broker, connection, SDK, storage, network egress, cloud control plane, recipient, а также миграционные, пакетные, аварийные и административные пути.

Каждый путь связывается с защищённой границей, идентичностью sink, версиями route и policy, credentials и principal. Отрицательные тесты используют отсутствующее, истёкшее, отозванное, повторное, изменённое или неверно связанное полномочие. Успех означает отсутствие эффекта по всем перечисленным путям.

Непроверенный маршрут получает статус неизвестно. Преднамеренное исключение называет отдельную власть и сужает обещание. Это рекомендация Daniel Kade, а не требование IETF, ЕС или автора. Отчёт не решает, правильно ли закон переведён в constraint. Сам draft оставляет правовую классификацию риска, запреты, достаточность человеческого контроля и полное соответствие за пределами протокола.

Потенциальная область стандартизации тоже уже юридического заголовка: представление акта, канонизация, evidence, act-bound authorization, proof-of-possession, sink binding, freshness, revocation и error semantics. Принцип Heng Lu о первенстве работающего кода требует не превращать соответствие компонента в недоказанное утверждение о системе.

Finality Sink отклоняет недействительный акт, который до него дошёл. Акт на другом маршруте он не контролирует.

Источники