Use Case
LLM-Audit-Trail für einen regulierten Finanz-Workflow
Ein Finanzdienstleister implementierte ein unveränderliches Audit-Log für einen KI-gestützten Analyseworkflow, um jeden generierten Output für Compliance-Zwecke vollständig rekonstruierbar und zuordenbar zu machen.
Auf einen Blick
Ergebnisse
- ✓ Jeder KI-generierte Output innerhalb von 2 Minuten aus dem Audit-Log rekonstruierbar
- ✓ Compliance-Audit ohne Befunde zum KI-Tooling-Recordkeeping bestanden
- ✓ Sechsmonatiger Audit-Log erhalten und abfragbar, gemäß interner Aufbewahrungsrichtlinie
Stack
- — Append-Only Postgres-Audit-Log mit zeilenweiser Hash-Verifikation
- — Git-backed versionierter Prompt-Registry
- — Explizites Modell-Versions-Pinning in der LLM-Client-Konfiguration
- — Interner FastAPI-Rekonstruktionsendpunkt
Typischer Zeitrahmen
3–4 Wochen
Kick-off bis Übergabe
Risiken & Guardrails
- Log-Storage-Wachstum bei hohem Request-Volumen — Retention-Policy erforderlich
- Prompt-Registry-Adoption: Teams dürfen Versionierung nicht umgehen
- Nur Hash-Speicherung der Inputs kann forensische Tiefe begrenzen
Herausforderung
Ein Finanzdienstleister hatte einen LLM-gestützten Workflow zur Zusammenfassung von Analysten-Research-Notizen und zur Kennzeichnung Compliance-relevanter Sprache eingesetzt. Das System lieferte nützliche Ergebnisse, aber das Compliance-Team äußerte eine Sorge: Wenn ein Regulierungsprüfer fragte, warum eine bestimmte Notiz auf eine bestimmte Weise zusammengefasst worden war, gab es keinen Mechanismus, um die exakten Inputs, den Prompt und die zum Zeitpunkt der Generierung verwendete Modell-Version zu rekonstruieren.
Die Aufbewahrungspflichten des Unternehmens erforderten, dass KI-generierte Outputs in einem regulierten Prozess reproduzierbar und zuordenbar sein müssen. Der Audit-Trail fehlte.
Vorgehen
Strukturiertes Audit-Log-Schema: Entwurf einer Append-Only-Protokolltabelle mit: request_id, timestamp, user_id, input_payload_hash (SHA-256 des Raw-Inputs), prompt_id und prompt_version, model_id und model_version, output_hash sowie einer metadata-JSON-Spalte für nachgelagerten Kontext. Das Log ist unveränderlich — Zeilen werden eingefügt, nie aktualisiert oder gelöscht.
Prompt-Registry: Alle Prompt-Templates in eine versionierte Registry überführt. Jedes Template wird durch prompt_id und version-Tag identifiziert. Deployments inkrementieren die Version; die vorherige Version bleibt abfragbar. Keine Produktions-Prompt-Änderung ist ohne Erstellung eines neuen Versionseintrags möglich.
Modell-Versions-Pinning: Die LLM-Aufrufkonfiguration wurde aktualisiert, um den exakten Modell-Versions-String statt eines Alias zu verwenden. Die Version wird zum Anfragezeitpunkt protokolliert. Der Rollout einer neuen Modell-Version erfordert eine explizite Konfigurationsänderung, die einen Versionsinkrement im Audit-Log auslöst.
Rekonstruktions-Tooling: Ein leichtgewichtiges internes Tool ermöglicht dem Compliance-Team den Abruf des exakten Input-Payloads, Prompt-Templates und der Modell-Version für jede protokollierte request_id. In einer Tabletop-Compliance-Übung vor der Freigabe demonstriert.
Typische Ergebnisse
In diesem Engagement beobachtete Outcomes — keine Garantien für jedes Deployment:
- Jeder KI-generierte Output im regulierten Workflow innerhalb von 2 Minuten aus dem Audit-Log rekonstruierbar
- Compliance-Audit ohne Befunde zum KI-Tooling-Recordkeeping bestanden
- Sechsmonatiger Audit-Log erhalten und abfragbar, gemäß interner Aufbewahrungsrichtlinie des Unternehmens
Tech-Stack
- Audit-Log: Append-Only Postgres-Tabelle mit zeilenweiser Hash-Verifikation
- Prompt-Registry: Git-backed versionierter YAML-Store mit Migrations-Tooling
- Modell-Pinning: Expliziter Versions-String in der LLM-Client-Konfiguration, beim Start validiert
- Rekonstruktionstool: Interner FastAPI-Endpunkt mit Compliance-Team-Zugriff
Verwandte Use Cases
Bereit, das Projekt zu starten?
Lass uns über dein Vorhaben sprechen.
Sag uns kurz, was du baust. Wir antworten mit einem klaren nächsten Schritt: Audit, Prototyp-Plan oder Delivery-Vorschlag.
Projekt starten →