Irgendwo in Ihrem Stack hat ein Agent bereits die Zahl produziert, die eines Tages vor einem Prüfer liegen wird. Er hat den Wert berechnet – oder generiert; das lässt sich möglicherweise nicht unterscheiden – jemand hat ihn in eine Präsentation eingefügt, und die Präsentation wurde verschickt. Monate später kommt die Frage, die jedes KI-System in der Produktion irgendwann bekommt: Woher stammt diese Zahl, und würden wir sie heute wieder erhalten?
Die meisten Teams antworten mit einem Transkript. In einer Umfrage aus Q1 2026 unter 420 Organisationen, die KI-Agenten in der Produktion betreiben, konnten nur 17 % die vollständige Abfolge von Tool-Aufrufen, Eingaben und Ausgaben hinter einer bestimmten Agentenaufgabe im Nachhinein rekonstruieren (AgentNode, 2026). Die übrigen 83 % hatten unvollständige Logs, gar keine Logs oder Logs, die das Reasoning des Modells erfassten, aber nicht, was es tatsächlich aufgerufen hatte. Ein Transkript und ein Gefühl.
Der Nachweis wird zum Gesetz
Eine Weile war das ein technisches Versäumnis. Es ist dabei, ein rechtliches zu werden.
Der EU AI Act verpflichtet Hochrisiko-KI-Systeme dazu, technisch zu ermöglichen – von Anfang an eingebaut, nicht nachträglich ergänzt – „die automatische Aufzeichnung von Ereignissen (Logs) über die Lebensdauer des Systems" (European Commission, 2024). Manuelle Aufzeichnungen erfüllen Artikel 12 nicht. Die Logs müssen ausreichen, um Situationen zu identifizieren, die ein Risiko oder eine wesentliche Änderung darstellen könnten, die Marktüberwachung zu unterstützen und den tatsächlichen Betrieb des Systems zu überwachen. Für die biometrische Fernidentifikation nennt der Artikel die Mindestanforderungen ausdrücklich: jede Nutzungsperiode, die geprüfte Referenzdatenbank, die Eingabedaten, die zu einer Übereinstimmung geführt haben, die natürlichen Personen, die das Ergebnis verifiziert haben. Das ist kein „irgendwelche Logs aufbewahren". Das ist die Entscheidung rekonstruieren.
Die Fristen rücken näher. Der Act trat am 1. August 2024 in Kraft; Verbote galten ab Februar 2025, Pflichten für Allzweck-KI-Modelle ab August 2025 – und die Hochrisikopflichten, darunter Artikel 12, gelten ab dem 2. August 2026 (Future of Life Institute, 2026). Acht Tage nach dem Datum dieses Beitrags. Hochrisikosysteme in regulierten Produkten (Anhang I) folgen im August 2027.
Auch für die Aufbewahrung gilt eine Untergrenze. Anbieter müssen automatisch generierte Logs mindestens sechs Monate aufbewahren, und Artikel 26(6) legt Betreibern dieselbe Pflicht auf – länger, wo andere Rechtsvorschriften wie die DSGVO dies verlangen, und in jedem Fall angemessen zum vorgesehenen Zweck des Systems, nicht nur das Minimum (artificialintelligenceact.eu, 2024).
Das alles kommt nicht im Vakuum. DSGVO Artikel 30 erwartet schriftliche Verzeichnisse von Verarbeitungstätigkeiten – Zwecke, Datenkategorien, Empfänger, Löschfristen, Sicherheitsmaßnahmen – seit 2018, auf Anfrage der Aufsichtsbehörde vorzulegen (gdpr-info.eu, 2016). SOC 2 CC7.2 erwartet, dass Systemkomponenten auf Anomalien überwacht und Befunde analysiert werden; CC7.3 erwartet die Bewertung, ob ein Ereignis die Ziele beeinträchtigt hat (AICPA, 2022). In einem Type-II-Audit werden diese Kriterien anhand von Log-Nachweisen über den gesamten Prüfzeitraum geprüft – typischerweise zwölf Monate (AgentNode, 2026) – nicht anhand eines Screenshots vom Tag des Prüferbesuchs.
Warum „mehr loggen" scheitert
Der Reflex ist Ausführlichkeit: Tracing aktivieren, alles speichern, ein Dashboard kaufen. Drei Probleme bleiben bestehen.
Transkripte zeichnen auf, was gesagt wurde, nicht was lief. Ein Chat-Log ist das Modell, das sein eigenes Verhalten kommentiert. Unter den 83 % oben fällt genau diese Gruppe: Reasoning erfasst, Tool-Aufrufe nicht. Wenn Kommentar und Ausführung auseinanderfallen, behält das Transkript eine gerade Miene – berechnet und generiert lesen sich auf der Seite identisch. Sie sind es nicht.
Ein Log, den man nicht erneut ausführen kann, ist Aussage, kein Beweis. Selbst Teams, die jeden Tool-Aufruf erfassen, können ihn meist nicht erneut ausführen und vergleichen, weil nichts die Umgebung festgehalten hat, in der er lief. Das SQL wurde an jenem Tag frisch generiert, gegen eine Datenbank, die sich seitdem verändert hat; die Arithmetik wurde aus einem Modell gesampelt, das von Anfang an nicht stabil war. Das sechs – oder zwölf – Monate aufzubewahren bedeutet, Behauptungen länger zu speichern, nicht sie überprüfbar zu machen. Artikel 12 ist präzise formuliert: Das System muss die Aufzeichnung technisch ermöglichen. Reproduzierbarkeit, die nicht von Anfang an eingebaut wurde, lässt sich nicht nachträglich durch eine Logging-Bibliothek nachrüsten.
Metadaten sind keine Korrektheit. Der minimal tragfähige Prüfnachweis – sechs Kernfelder, darunter Trace-ID, Zeitstempel und Agentenidentität (AgentNode, 2026) – belegt Wer und Wann. Er sagt nichts darüber aus, ob die Zahl richtig war oder ob sie heute gleich herauskäme. Forschung zur Beobachtbarkeit von LLM-Agenten kommt zum selben Schluss: Rückverfolgbarkeit muss die Artefakte des gesamten Agenten-Lebenszyklus abdecken, nicht nur die Nachrichten (CSIRO Data61, 2024).
Das Versagen ist strukturell. Freie Ausführung – ein Modell, das Zeichenketten ausgibt, die etwas anderes ausführt – produziert nichts Stabiles genug zum Aufzeichnen, egal wie viel davon festgehalten wird.
Herkunftsnachweis als Teil des Ergebnisses
SQAIs Antwort besteht darin, den Nachweis zu einer Eigenschaft der Ausführung zu machen, nicht zu einem Merkmal des Loggings. Jedes ausgeführte Ergebnis trägt vier Hashes, von denen jeder eine eigene Prüffrage beantwortet:
contract_hash— was laufen durfte: der exakte Capability-Vertrag, der in Kraft war (sha256:79f1c5a6c716…).plan_hash— wozu die Anfrage aufgelöst wurde: der validierte Plan mit aufgezeichnetem Auflösungsweg (decision_path: "exact_spec").invocation_hash— was lief, auf was: die Capability plus kanonisierte Eingaben, einschließlich einesinput_hashder Daten zum Ausführungszeitpunkt.computation_hash— was herauskam: an Aufruf und Wert gemeinsam gebunden.
Die Konstruktionen sind domänensepariert, sodass kein Artefakt ein anderes imitieren kann:
invocation_hash = sha256("sqai:invocation:v1\0" + canonicalJson(identity))
computation_hash = sha256("sqai:computation:v1\0" + invocation_hash + canonicalJson(value))
Neben den Hashes liegt der Determinismus-Envelope – die aufgezeichnete Ausführungsumgebung: runtime_bundle_version 0.1.0 und dessen sha256, Plattform und Architektur, precision_mode: float64, thread_count: 1 sowie der Seed, wo einer erforderlich ist. Die zehn Simulations-Capabilities, die einen benötigen, verweigern die Ausführung ohne ihn – seed_required, kein stillschweigend abweichendes Ergebnis. Alles, was die Zahl verändern könnte, ist entweder festgeschrieben oder dokumentiert.
Was das konkret bringt: Im März berechnet ein Agent einen Kapitalwert:
finance.npv(0.1, [-1000, 300, 420, 560, 680])
→ 505.020148896933
computation_hash b74f67d0d7a594aa…
Im Juli fragt der Prüfer nach. Sie führen den Aufruf erneut aus – dieselbe typisierte Spec, dieselbe festgeschriebene Runtime – und vergleichen Hashes: b74f67d0d7a594aa… erneut, byteidentisch. Es spielt keine Rolle, ob die Wiedergabe in TypeScript oder Python läuft. canonicalJson und canonical_json sind ein sprachübergreifender Serialisierungsvertrag – Schlüssel sortiert, -0 zu 0 normalisiert, festes Unicode-Escaping – sodass derselbe Wert dieselben Bytes und damit denselben Hash in beiden Sprachen ergibt. Die Determinismus-Seite zeigt zwei solcher Envelopes, Monate auseinander, nebeneinander.
Und wenn die Wiedergabe nicht übereinstimmt, ist das ein Signal. Eine geänderte Quelle schlägt laut mit schema_revision_mismatch fehl – die Engine weigert sich, stillschweigend eine andere Zahl gegen andere Daten zu berechnen und sie der Vergangenheit zuzuschreiben. Die Abweichung benennt, was sich verändert hat.
Das lässt sich auf die Pflichten abbilden. Automatische Aufzeichnung über die Lebensdauer des Systems: Jedes ausgeführte Ergebnis zeichnet sich konstruktionsbedingt selbst auf – es gibt keinen nicht aufgezeichneten Pfad, weil die Ausführungsoberfläche aus 4.574 schreibgeschützten Capabilities mit typisierten Eingaben besteht, nicht aus freien Zeichenketten. Sechs oder zwölf Monate Aufbewahrung: Die Ergebnis-Envelopes speichern; Aufbewahrung wird zur Speicherentscheidung statt zur Archäologie. Nachweise über einen SOC-2-Prüfzeitraum: Die Artefakte sind der Nachweis – die Antwort an den Prüfer ist eine Wiedergabe, keine Untersuchung. Die gleiche Pipeline erzeugt den Nachweis für jede Capability, und der persistente Prüfpfad ist im Pro-Tarif von SQAI enthalten.
Acht Tage – und jede Prüfung danach
Das August-Datum bindet formal Hochrisikosysteme in der EU. Aber solche Fristen setzen die Vorlage für jede nachfolgende Prüfung – den SOC-2-Auditor, den Beschaffungsfragebogen, den eigenen CFO im März, der nach einer Zahl aus dem Januar fragt. Agenten werden aufgefordert werden, ihre Antworten zu begründen, wie es von Mitarbeitern erwartet wird: mit Nachweisen. Die meisten Stacks können sie nicht liefern, weil generiertes SQL und gesampelte Arithmetik nichts Stabiles genug zum Aufzeichnen hinterlassen – ein Problem, das weit vor der Prüfung beginnt.
Eine Antwort, die man wiedergeben kann, ist eine Antwort, die man verteidigen kann. Alles andere ist ein Screenshot.