Belege, die einer Re-Berechnung standhalten.
Eine PDF mit einem Stempel ist kein Audit-Beweis. Audit-fähige Evidence muss drei Eigenschaften haben: sie muss unveränderlich sein, sie muss sich auf einen bestimmten Zeitpunkt festnageln lassen, und sie muss von einem zurechenbaren Akteur signiert sein. Der Evidence Vault in RealSyncDynamics.AI implementiert alle drei — nicht als Marketing-Begriff, sondern als technische Konstruktion.
Was im Vault liegt
Jeder Evidence-Record ist ein Tupel aus Artefakt-URL (S3 in eu-central-1), Artefakt-SHA-256, verknüpften Controls (z. B. aiact.art11.annex_iv), Subject-Pointer (welche Usecase, welcher Vendor, welches Deployment), Retention-Datum und Signatur. Das Artefakt selbst kann eine Annex-IV-PDF sein, ein Scan-Ergebnis als HAR, ein Consent-Snapshot oder ein Agent-Run-Trace.
Hash-Chain pro Tenant
Innerhalb eines Tenants haben Evidence-Records eine monoton steigende chain_index. Jeder Record speichert artefact_sha256 seines Vorgängers in prev_sha256. Eine SQL-Verifikation in einem Schritt deckt Tampering auf:
- LAG-Fenster über
artefact_sha256ordered bychain_index - WHERE
prev_sha256 IS DISTINCT FROM expected_prev - Leeres Result-Set = Kette unversehrt. Nicht-leer = P1-Incident.
Ed25519-Signaturen mit per-Tenant-Key
Bei Tenant-Creation wird ein Ed25519-Schlüsselpaar generiert und der private Key in AWS-KMS (eu-central-1, HSM-backed) gehalten. Der Public Key wird im Tenant-eigenen Trust-Portal veröffentlicht. Signatur eines Records ist Ed25519(artefact_sha256 || prev_sha256 || sealed_at). Jeder Auditor mit dem Public Key kann jede Signatur verifizieren — die Plattform muss dafür nicht angerufen werden.
RFC-3161-Timestamps
Für Records mit hoher Stake (Annex-IV-Sections, signierte DPIA, Incident-Report, Regulator-Export) wird der Artefakt-SHA-256 zusätzlich an zwei unabhängige EU-RFC-3161-TSAs (Bundesdruckerei, Swiss Post) gesendet. Der Doppel-Timestamp + die beiden TSA-Signaturen landen in metadata.tsa. Kosten pro Record: ~€0.01 — wir wenden es selektiv auf alle kind IN (annex_iv_section, dpia_signed, incident_report, regulator_export) an.
Audit-Rekonstruktion
"Welche Policy war am 2026-04-15 14:00 aktiv? Was hat sie auf Event X entschieden?" — diese Frage ist nur durch das Zusammenspiel von Audit-Log + Policy-Bundle-Versionierung + Evidence-Vault beantwortbar. Der Audit-Log nennt jede Policy-Mutation per Zeitstempel. Policy-Bundles im Object Storage sind versioniert mit ihrem SHA. Evidence-Records für Policy-Decisions speichern den policy_bundle_sha. Aus einer event_id heraus rekonstruiert die Plattform: welcher Bundle aktiv war, welche Regeln getroffen haben, was zurückkam, wer eskaliert hat.
Regulator-Export-Pack
Wenn eine Behörde ein Audit-Pack anfordert, generiert die Reporting-Service ein ZIP mit deterministischem Namen: regulator-export-<tenant>-<from>-<to>.zip. Es enthält Inventory-JSONs, Policy-Snapshots, Policy-Decisions als Parquet, Evidence-Records + Artefakte, Audit-Log als Parquet, und das Verification-Output der Chain-Query. Das ZIP wird mit zwei Schlüsseln signiert: dem Tenant-Key (Beweis "wir bestätigen unsere Aussagen") und dem Plattform-Key (Beweis "die Plattform bestätigt, was sie geliefert hat"). Two-of-two-Signatur.
Was bewusst nicht im Vault liegt
Personenbezogene Daten in raw form gehören nicht in den Vault. Der Vault hält den Hash der Daten, der Beweis ist die Konsistenz mit anderen Records. Ein DSR-Löschantrag erreicht die Source-Tabellen, der Vault bleibt unangetastet — die Hashes referenzieren keine personenbezogenen Inhalte mehr.