Privacy-first KI-Ereignisnachweise

Korrelierte Lifecycle-Events, lokale Inhalts-Fingerprints und öffentlich prüfbare technische Integritätsnachweise

Inhalt

1. Zusammenfassung
2. Problemstellung
3. Interaktionsstandard
4. Nachweisqualität
5. Tools und Aufsicht
6. Architektur
7. Hashing
8. Kontinuität
9. Merkle und Zeitstempel
10. Verifikation
11. Datenschutz
12. AI Act
13. Aussagegrenzen

1. Zusammenfassung

Azalee ist eine technische Audit- und Integritätsschicht für KI-Systeme, Agenten und Workflows. Die Plattform ist nicht als zweite Rohdatenbank für Unterhaltungen gedacht. Sie speichert kryptografische Fingerprints, sichere Kontrollmetadaten, Reihenfolge, Kontinuität und Verankerungsnachweise.

Eine reale KI-Interaktion wird als zusammengehörige Ereignisfolge protokolliert. Frage und Antwort bleiben beim Nutzer. Das Kundensystem berechnet lokal input_hash und output_hash. Azalee erhält diese Fingerprints sowie Status, Dauer, Versionen und korrelierende IDs.

2. Problemstellung

Ein einzelner Eintrag „Antwort erzeugt“ reicht für spätere technische Prüfungen oft nicht. Es bleibt unklar, welcher Input gemeint war, ob die Ausgabe zugestellt oder blockiert wurde, ob ein Tool handelte, ob eine Freigabe vorlag und ob eine nachweisbare Reihenfolge bestand.

Vollständiges Rohdaten-Logging dupliziert dagegen Prompts, Antworten, Transkripte, Dateien und Kundendaten und erhöht Datenschutz-, Geheimhaltungs- und Sicherheitsrisiken. Azalee trennt deshalb Inhalt und Nachweis.

3. Kanonischer Interaktionsstandard

Jede normale Input-zu-Output-Interaktion verwendet eine stabile session_id für Gespräch oder Lauf und eine correlation_id für den einzelnen Turn.

4. Nachweisqualität

Bei kanonischen Ereignistypen wird geprüft, ob die erwarteten Fingerprint-Felder vorhanden sind.

5. Tools, Policy und menschliche Aufsicht

Externe Aktionen erhalten eine eigene Tool-Ereignisfolge: tool.call.started, completed, failed oder blocked.

Menschliche Aufsicht wird separat mit human.approval.requested, granted, rejected und human.override protokolliert. Policy-, Risiko- und Änderungsereignisse erklären technische Zustandswechsel.

6. Architektur

7. Hashing und Kanonisierung

Ein kryptografischer Hash ist ein deterministischer Fingerabdruck. Dieselbe kanonische Eingabe erzeugt denselben Hash; eine relevante Änderung erzeugt einen anderen. Azalee hasht durchgehend mit SHA-256. Anker und Events, die vor dem 25.07.2026 geschrieben wurden, verwenden SHA3-256; da beide Digests 32 Byte lang sind und man dem Wert das Verfahren nicht ansieht, wird der Algorithmus je Zeile in hash_algo mitgeführt und reist als hashAlgo in jedem Beweis mit. Ein Prüfer muss das im Beweis angegebene Verfahren verwenden — mit dem heutigen Standardwert nachzurechnen würde einen gültigen historischen Beweis als manipuliert melden. Die Kanonisierung folgt RFC 8785 (JCS).

Unabhängige Inhaltsprüfung setzt voraus, dass das Original und die lokale Kanonisierungsregel beim Nutzer erhalten bleiben. Azalee kann verborgene Inhalte aus einem Hash nicht rekonstruieren.

8. Kontinuität und Reihenfolge

session_id gruppiert einen längeren Lauf. correlation_id gruppiert eine konkrete Interaktion. sequence beschreibt logische Reihenfolge. Optional verweist jedes Event auf den vorherigen Hash. Entfernen, Einfügen oder Ersetzen wird dadurch erkennbar.

Eine Sequenz schließt Lücken in der Mitte einer Session. Sie schließt das Ende nicht: Wer die letzten Ereignisse weglässt, hinterlässt keine Spur, die Kette endet einfach früher. Deshalb gibt es zwei zusätzliche Ereignisse. session.sealed wird genau einmal am Ende gesendet und deklariert total_events; weichen deklarierte und vorliegende Anzahl voneinander ab, ist die Session sichtbar unvollständig. system.heartbeat wird regelmäßig gesendet, solange eine Session offen ist, und deklariert at_sequence; meldet ein Lebenszeichen eine höhere Sequenz als das letzte vorliegende Ereignis, wurde das Ende abgeschnitten. Erst beide zusammen machen Stille zu einem Ereignis.

Ehrliche Grenze: Vollständigkeit wird relativ zu dem bewiesen, was das System deklariert hat. Eine Session, die nie begonnen wurde, existiert nirgends und kann nicht vermisst werden. Garantiert ist, dass alles, was einmal begonnen hat, danach entweder lückenlos oder sichtbar kaputt ist.

9. Merkle-Wurzeln und Zeitnachweise

Ein Merkle-Baum verdichtet viele Event-Hashes zu einer Wurzel. Ein Inclusion-Pfad zeigt, dass ein bestimmter Fingerprint Teil des Batches war, ohne andere Kundenevents offenzulegen.

Zeitstempelung bindet eine Batch-Wurzel oder einen Paket-Hash an einen Zeitpunkt. Nur ein tatsächlich verifizierter qualifizierter Vertrauensdiensteanbieter darf als qualifizierter eIDAS-Zeitstempel bezeichnet werden.

10. Verifikation

Ein Prüfer bewertet zunächst Event-Typen, Status, Reihenfolge, Qualität, Tool-/Policy-/Freigabe-Kontext und Versionsfelder. Danach werden Event-Fingerprint, Merkle-Inclusion, veröffentlichte Wurzel und Zeitnachweis geprüft.

Ohne Kundenoriginal bestätigt Azalee Existenz und Integrität der gespeicherten Verpflichtung, aber nicht den verborgenen Inhalt.

Der Beweis reist als Proof Bundle (azalee-proof-<event_id>.zip): Manifest, Leaf-Hash, Merkle-Pfad, Wurzel als Rohbytes, RFC-3161-Token, TSA-Kette, OpenTimestamps-Proof, signierte Eingangsquittung und ein VERIFY.md mit den Befehlen zum Nachrechnen. Geprüft wird mit azalee-verify, einer quelloffenen CLI unter MIT-Lizenz, die keinen einzigen Netzwerkaufruf macht. Ein Beweis, der nur auf azalee.garden funktioniert, waere keiner: ein Dritter muss bei blockiertem azalee.garden zum selben Ergebnis kommen. Jede Aussage wird einzeln gemeldet, nie als Sammelampel; fehlende Belege erscheinen als ungeprüft und nie als bestanden.

event.json liegt dem Bundle in der Regel nicht bei, denn Azalee speichert nur Hashes und Steuer-Metadaten, nie den Inhalt. Der Halter legt sein aufbewahrtes Original daneben; es muss den Leaf-Hash reproduzieren. Originale aufbewahren — Azalee beweist, dass sie unverändert sind, verwahrt sie aber nicht.

Alle je veröffentlichten Wurzeln stehen zusaetzlich in einem öffentlichen, verketteten Feed unter /api/roots. Wer ihn einmal speichert, erkennt beim naechsten Abruf, wenn eine alte Wurzel verändert wurde oder fehlt. Der Feed enthaelt nur Wurzeln und Zeiten — keine Kundenkennungen, keine Namen, keine Mengenangaben.

11. Sicherheit und Datenschutz

Erlaubte Klartext-Metadaten sind Ereignistyp, Status, Dauer, opake IDs, Versionen, Tool-/Policy-Namen, Reason Codes und Hash-Felder. Personenbeziehbare Akteure sollen nur als opake Referenzen übertragen werden.

Nicht übertragen werden sollen Rohfragen, Antworten, Transkripte, Aufnahmen, Dateien, Tool-Argumente/-Ergebnisse, Kundendatensätze, E-Mail-Adressen, Passwörter, API-Schlüssel, Tokens oder Secrets.

12. Einordnung zum EU AI Act

Artikel 12 der Verordnung (EU) 2024/1689 verlangt für bestimmte Hochrisiko-KI-Systeme automatische Ereignisaufzeichnung. Azalee unterstützt technische Muster für Aufzeichnung, Traceability, Monitoring, Risikoereignisse, menschliche Aufsicht und spätere Verifikation.

Azalee bestimmt nicht, ob ein Kundensystem Hochrisiko ist, ersetzt weder Risikomanagement noch technische Dokumentation oder menschliche Aufsicht und stellt keine automatische Compliance-Zertifizierung dar.

13. Aussagegrenzen

• Ein passender Hash zeigt Übereinstimmung mit einem Fingerabdruck, nicht Wahrheit des Inhalts.
• Ein Zeitnachweis zeigt Existenz einer kryptografischen Verpflichtung zu einem Zeitpunkt, nicht fachliche Richtigkeit.
• Ein Merkle-Proof zeigt Batch-Inclusion, nicht Vollständigkeit aller jemals stattgefundenen Aktionen.
• Azalee kann nur Events nachweisen, die am echten Runtime-Punkt tatsächlich emittiert wurden.
• Fehlende historische Events dürfen nicht nachträglich erfunden werden.
• Ein Contract-Badge ist keine behördliche Zertifizierung und keine Garantie jeder Modellantwort.
• Zwischen Eingang und Verankerung liegt ein Fenster, in dem ein Event unverankert bei Azalee liegt. Die beim Ingest ausgestellte, signierte Quittung schließt es: der Kunde haelt damit ein Artefakt, das Azalee nicht mehr ändern kann. Wer keine Quittung aufbewahrt, hat fuer dieses Fenster keinen Gegenbeweis.
• client_time ist eine Behauptung des Kundensystems und nie ein Beweis; belastbar ist allein das von Azalee gemessene received_at.
• Signierte Checkpoints im C2SP-Format ermöglichen die Mitzeichnung durch unabhängige Zeugen. Solange kein Zeuge konfiguriert ist, ist Azalee der einzige Unterzeichner seiner eigenen Checkpoints und Split-View ist nicht ausgeschlossen — ein Log, das seinen eigenen Checkpoint zeichnet, belegt dazu nichts. Der Verifier meldet diese Pruefung dann als ungeprüft, nicht als bestanden.

Technische Grundlagen

Verordnung (EU) 2024/1689. Verordnung (EU) Nr. 910/2014. Verordnung (EU) 2024/1183. RFC 3161. NIST FIPS 202. RFC 8785. RFC 9162.