Menschliche Genehmigung und Ausführungsherkunft
Eine menschliche Genehmigung ist Teil eines Ausführungsdatensatzes. Dieses Playbook erklärt, was vor einer Aktion, bei der Entscheidung durch eine prüfende Person und nach der Ausführung erfasst werden muss.
Zahlungsausführung
Übermittlung akzeptiert
Zahlung angefordert
Lieferantenzahlung übermitteln · €420,000
Agent für Treasury-ZahlungenGenehmigung erforderlich
Betrag überschreitet den Schwellenwert von €250,000
Zahlungslimits · Version 3Treasury genehmigte
Rechnung und Genehmigungsumfang bestätigt
Treasury-PrüferTool hat die Übermittlung akzeptiert
Übermittlung akzeptiert; endgültige Abwicklung der Zahlung wird nicht angezeigt
Zahlungstool
Was in jeder Phase zu erfassen ist
Ein Agent fordert eine Zahlung oberhalb des Prüfschwellenwerts an. Die Richtlinie erfordert eine Genehmigung. Die Nachweise müssen diese Anfrage mit der Prüfung und dem späteren Ausführungsergebnis verbinden.
- 1
Die Anfrage erfassen
Dokumentieren Sie Agent, vorgeschlagene Aktion, relevante Eingaben und Anfragekennung.
- 2
Die Richtlinienentscheidung aufbewahren
Dokumentieren Sie Richtlinienversion, bewerteten Kontext, Ergebnis und Begründung.
- 3
Die menschliche Entscheidung anhängen
Bewahren Sie Identität, Entscheidung, Begründung und Zeitpunkt der prüfenden Person sowie ihre Beziehung zur ursprünglichen Anfrage auf.
- 4
Dokumentieren, was ausgeführt wurde
Verbinden Sie die zulässige Aktion und ihr Ergebnis mit derselben Anfrage. Eine abgelehnte Anfrage muss von einer abgeschlossenen Aktion unterscheidbar bleiben.
- 5
Das Prüfarbeitsprodukt vorbereiten
Sammeln Sie Datensätze und unterstützendes Material mit einem Manifest und Integritätsinformationen.
Die sinnvolle Einheit ist die vollständige Entscheidung: Anfrage, Regel, prüfende Person, Ergebnis und unterstützende Nachweise. Lineage Explorer und Evidence Room bieten die Untersuchungs- und Prüfoberflächen für diese Arbeit.
Verifizierungsprüfungen und Grenzen
Ein Sealed Evidence Bundle gibt der prüfenden Person ein zu untersuchendes Artefakt. Die Verifizierung prüft seine kryptografische Struktur anhand des bereitgestellten Materials und der Vertrauenskonfiguration.
Authentizität erfordert eine Schlüsselprüfung außerhalb des Bundles. SEK-, TEK- und Receipt-Signaturen werden alle gegen die Schlüssel geprüft, die das Bundle in keys/jwks.json einbettet, sodass das Bundle offline nur seine interne Konsistenz belegt. Um zu belegen, dass es von KLA stammt, verankern Sie diese Schlüssel gegen eine von KLA veröffentlichte JWKS oder einen Schlüssel-Fingerabdruck.
Der OpenTimestamps-Bitcoin-Anker wird offline als vertrauenswürdig angenommen. Seine Bestätigung vergleicht die Blockhöhe mit der aktiven Bitcoin-Chain, und ein ausstehendes Kalender-Receipt bleibt bis zu einem Kalender-Upgrade ausstehend.
Der Nachweis des immudb-Ledger-Ankers ist offline vorhanden und parst. Die Bestätigung seiner Inklusion gegen den signierten Zustand des Ledgers erfordert eine Netzwerkprüfung.
- Manifest-Signatur
- Das Manifest kanonisiert (RFC 8785 / JCS) und sein Digest wird neu berechnet. Der abgesetzte JWS trägt gültige SEK- und TEK-ES256-Signaturen über diesen Digest, geprüft gegen die öffentlichen Schlüssel, die das Bundle in keys/jwks.json einbettet.
- Merkle-Inklusion
- Jede Artefaktdatei wird neu gehasht (SHA-256) auf den vom Manifest deklarierten Digest, der Inklusionsbeweis jedes Artefakts erreicht die versiegelte Wurzel, und die neu berechnete Merkle-Wurzel entspricht dem Manifestwert.
- Receipt-Signaturen
- Jede Governance-Receipt-Kette wird verifiziert: die ed25519-Signatur jedes Receipts wird gegen einen im Bundle eingebetteten Schlüssel geprüft, und der prevReceiptHash jedes Schritts verweist auf den vorherigen Schritt, von Genesis bis zuletzt.
- Ledger-Hash-Kette
- Jeder exportierte Ledger-Eintrag wird neu auf seinen angegebenen Hash gehasht, und aufeinanderfolgende Einträge sind durchgängig über previousHash verkettet.
- OpenTimestamps-Anker
- timestamp.ots wird nach den strengen OpenTimestamps-Regeln geparst und bindet an den neu berechneten Manifest-Digest. Ist das Receipt Bitcoin-attestiert, meldet der Verifier dessen Blockhöhe; ein ausstehendes Kalender-Receipt wird als noch ausstehende Bitcoin-Bestätigung akzeptiert.
Regulatorische Präzedenzfälle
Diese Referenzen beschreiben unterschiedliche Kontexte der Aufbewahrung von Datensätzen. Nutzen Sie sie, um die Nachweisfrage in jedem Regelwerk zu untersuchen, und folgen Sie der Quelle für deren Umfang.
SOX
Praxis der Aufbewahrung
COSO Framework: 17 Prinzipien, 87 Schwerpunkte, 40% Big 4 Audit-Mängelquoten
MiFID-II
Praxis der Aufbewahrung
100 Mikrosekunden UTC Abweichung (HFT), WORM Speicherung, 5-7 Jahre Aufbewahrung, 72-Stunden-Rekonstruktion
DSGVO
Praxis der Aufbewahrung
2FA jetzt erwartet (Haga Hospital Geldstrafe), dokumentierte Zugriffsverfahren erforderlich
MDR
Praxis der Aufbewahrung
IEC 62304 Audit-Trails, vollständige Versionskontrolle, Rückverfolgbarkeit von Anforderungen zu Tests
Quelle: Verordnung (EU) 2024/1689. Prüfen Sie die für Ihr System geltenden Anforderungen gemeinsam mit den für die rechtliche und operative Bewertung verantwortlichen Personen.
Fragen und Details
Erfordert Artikel 12 explizit kryptographische Integrität?
Nein, aber das Muster von MiFID II, SOX, GDPR und MDR ist eindeutig: Prinzipienbasierter Text wird innerhalb von 2-4 Jahren zu präskriptiver Praxis. Prüfer und benannte Stellen werden "automatische Aufzeichnung" als Protokollierung mit nachweisbarer Integrität interpretieren.
Welche Aufbewahrungsfristen gelten für KI-Logs?
Artikel 12 spezifiziert 6 Monate Minimum für automatisierte Logs, aber sektorspezifische Anforderungen haben häufig Vorrang. Finanzinstitute sollten 5-7 Jahre erwarten. Technische Dokumentation muss 10 Jahre nach Inverkehrbringen des Systems aufbewahrt werden.
Wann werden harmonisierte Standards veröffentlicht?
prEN ISO/IEC 24970 (Protokollierungsstandard) ist im Draft International Standard Ballot. prEN 18286 (QMS Standard) trat im Oktober 2025 in öffentliche Befragung ein. Finale Standards erwartet Q4 2026, aber Prüfererwartungen bilden sich jetzt.
Welchen Zugriff werden benannte Stellen haben?
Nach Annex VII können benannte Stellen vollen API-Zugriff auf Trainings-, Validierungs- und Testdatensätze verlangen. Sie können direkte Tests durchführen, wenn sie mit Anbieter-Nachweisen unzufrieden sind. Datensatzzugriffslogs werden selbst zu Audit-Zielen.
Wie sollten wir ML-Modell-Nachweisbarkeit handhaben?
Schwellenwerte für umfassende Protokollierung bleiben unklar, aber Prüfer werden wahrscheinlich erwarten: Modellversionsverfolgung, Hyperparameter-Änderungen, Training-Run-Metadaten und Entscheidungsrückverfolgbarkeit für Hochrisiko-Ausgaben.