Zusammenfassung

  • draft-das-eu-ai-act-execution-enforcement-00 vom 5. September 2026 ist ein aktiver individueller Internet-Draft von Sangam Das mit angestrebtem Informational-Status. Er ist weder IETF-Standard noch regulatorische Prüfung.
  • Ein folgenreicher Vorgang bleibt als Candidate Act wirkungslos, bis vorgegebene maschinenlesbare Bedingungen geprüft, aktgebundene Befugnis ausgestellt und am Finality Sink unmittelbar vor der ersten geschützten Außenwirkung erneut verifiziert wurden.
  • Abschnitt 35 beschränkt die Sicherheitseigenschaft ausdrücklich auf vermittelte Wirkungen. Die dort gezeigte direkte externe API neben dem Sink fällt nicht unter den Schutz.
  • Die Python-Referenz v0.1.0 demonstriert eine einzige lokale API zur Wirkungserfassung. Entwurf und Repository bezeichnen sie nicht als produktionsreifes Sicherheitsprodukt oder Rechts-Compliance-Engine.
  • Erforderlich ist ein Nachweis über die geschlossene Wirkungsfläche: vollständige Pfade, Versions- und Berechtigungsstand, Umgehungsprivilegien, Ausnahmen und Negativtests je Pfad.

Der perfekte Prüfer kann optional sein

Der technische Ablauf trennt Rechenfähigkeit von Ausführungsbefugnis. Ein KI-System darf eine Zahlung, Nachricht, Veröffentlichung, Datenänderung oder Maschinenaktion vorbereiten. Der Vorgang wird als Candidate Act festgehalten. Eine geschützte Funktion prüft Bedingungen, die eine zuständige Stelle bereits maschinenlesbar gemacht hat. Erst dann entsteht eng begrenzte Befugnis für genau diesen Akt. Der Sink kontrolliert Digest, Signatur, Zielbindung, Ablauf, Widerruf, Einmaligkeit und aktuellen Zustand unmittelbar vor der Wirkung.

Das verhindert wichtige Kurzschlüsse. Eine authentisierte Workload ist nicht zu jeder denkbaren Aktion berechtigt. Eine alte Freigabe gilt nicht für geänderte Empfänger oder Beträge. Nachträgliches Logging ist keine Prävention.

Die härteste Frage betrifft jedoch den Weg. Abbildung 75 verzweigt den Agenten zu einem Finality Sink und zu einer direct external API. Für die direkte API, sagt der Text, ist kein Finality-Schutz hergestellt. Der Prüfer kann alles richtig machen und trotzdem nicht entscheiden, weil ein anderer Pfad ihn nicht aufruft.

Ein geschütztes Zahlungs-Gateway bei zugleich direktem Settlement-Zugang wäre ein solches Muster. Ebenso eine kontrollierte Publikationsschnittstelle neben beschreibbarem öffentlichem Objektspeicher oder ein Datenbank-Proxy neben einer Notfall-Verbindung. Dies sind keine behaupteten Vorfälle, sondern Topologiebeispiele.

Der ausgewählte Übergang bestimmt den Umfang

Der Entwurf verlangt keinen Sink für jedes Token, jede Leseoperation oder jedes Paket. Er zielt auf ausgewählte folgenreiche Übergänge. Diese Begrenzung folgt einer sinnvollen minimalen Spezifikation: Nicht die gesamte Berechnung muss zentralisiert werden, sondern der Moment, an dem Geld, Nachricht, Datei, Commit oder Stellbefehl nutzbar wird.

Wird eine Wirkung als geschützt bezeichnet, müssen dennoch alle Wege zu dieser Wirkung erfasst oder ausdrücklich ausgenommen werden. Eine Auswahl des Übergangs ist keine Auswahl nur der bequemsten API. Fallbacks, Batch-Zugänge, SDKs, Administrator-Konten, Speicherregeln und Empfängerdienste gehören in die Karte.

Bei Fernwirkungen reicht die lokale Zusage nicht. Der Entwurf warnt, dass lokale Validierung eine beliebige Internet-Anfrage nicht atomar macht. Empfängerseitige Sinks, Idempotenz, Transactional Outbox oder koordinierte Zustände können nötig sein. Der Beobachtungspunkt liegt dort, wo die Außenwirkung zuerst tatsächlich nutzbar wird.

Was der laufende Code belegt

Version 0.1.0 implementiert kanonische Darstellung, SHA-256, Ed25519, Besitznachweis, Policy-Epochen, Nonces und lokale SQLite-Verarbeitung. Im synthetischen Supportbeispiel wird eine Zwecksubstitution vor dem Wirkungseintrag abgelehnt.

Der README-Text nennt die tragende Annahme: Die einzige wirkungsschreibende API befindet sich im Sink. Im realen Einsatz müssen Netz-Egress, Datenbank-Commit, Zahlung, Dateifreigabe, Werkzeugaufruf und andere Wirkungswege gleichwertig vermittelt werden.

Das ist belastbare Evidenz für ein begrenztes Modell, nicht für eine unbekannte Produktionsumgebung. Es fehlen Produktions-HSM und -TEE, verteilte Einigung, vollständiger PKI-Lebenszyklus, formale Verifikation, Hochverfügbarkeit, Seitenkanalschutz, vollständige entfernte Atomizität und Konformitätsbewertung. Logische Trennung in einem Python-Prozess sperrt keinen uneingeschränkten Prozessadministrator aus.

Ein Wirkungsflächen-Nachweis

Der Nachweis beginnt mit der Wirkung: Welcher externe Zustand wird wo erstmals verwendbar? Danach erfasst er Gateway, Broker, Verbindung, SDK, Speicher, Netzwerk, Cloud-Steuerung, Empfänger sowie Migrations-, Notfall- und Administratorpfade.

Jeder Weg wird an Schutzgrenze, Sink-Identität, Routing- und Policy-Version, Credentials und nutzende Principals gebunden. Negativtests prüfen fehlende, abgelaufene, widerrufene, wiederverwendete, veränderte oder falsch gebundene Befugnis. Erfolg bedeutet: auf keinem erfassten Weg entsteht die Wirkung. Ungeprüfte Wege bleiben unbekannt; bewusste Ausnahmen benennen ihre andere Autorität.

Dieser Nachweis ist eine Empfehlung von Daniel Kade. Er stammt nicht von IETF, EU oder dem Entwurfsautor und bewertet nicht, ob eine Regel rechtlich richtig übersetzt wurde. Der Draft lässt Hochrisiko-Einstufung, Verbote, menschliche Aufsicht und Gesamtkonformität ausdrücklich außerhalb des Protokolls.

Auch die mögliche IETF-Fläche bleibt eng: Aktdarstellung, Kanonisierung, Evidenz, aktgebundene Autorisierung, Besitznachweis, Sink-Bindung, Aktualität, Widerruf und Fehlersemantik. Nach Heng Lus Vorrang laufenden Codes darf Komponentenkonformität nicht zur Systemgewissheit aufgebläht werden.

Ein Finality Sink kann jeden ungültigen Akt ablehnen, der ihn erreicht. Den Akt auf einem anderen Weg sieht er nicht.

Quellen