KI scheitert selten am Modell –
meist am Datenlayer
In LegalTech funktionieren KI-Features oft genau so lange, bis jemand eine
einfache Frage stellt:
„Können wir das später nachweisen?“
Ab da zählen nicht mehr Prompts, sondern Daten:
Quelle. Stand. Zeitstempel. Referenz. Entscheidungspfad.
Wenn diese Felder fehlen, wird KI nicht „smarter“ – sie wird nur schwerer zu auditieren.
Das Bottleneck sind Daten, nicht Modellqualität
In regulierten Prozessen zählt nicht nur das Ergebnis, sondern der reproduzierbare
Pfad dorthin.
Was dafür in vielen LegalTech-Produkten fehlt:
- strukturierte Registerdaten (als Felder, nicht als PDF-Anhang)
- klare Quellenreferenzen (Source-Link statt Screenshot)
- Zeitstempel („Stand wann?“)
- exportierbare Evidenz (Report/Akte, ohne Copy-Paste)
- Entscheidungen als Datenobjekt (im Case-/Workflow-System, nicht nur im Kommentar)
Das ist kein „Nice to have“.
Das Geldwäschegesetz regelt Aufzeichnungs- und Aufbewahrungspflichten (u. a. fünf Jahre).
Quelle: GwG § 8 (amtlich)
Der Klassiker: PDFs statt Datenfelder.
Viele Systeme starten „AI-first“ – bleiben aber „PDF-first“. Das wirkt schnell, ist aber instabil.
Typische Schwachstellen:
- Handelsregister liegt als PDF vor (keine Felder, kein diff, kein sauberer Stand)
- Transparenzregister wird als Screenshot abgelegt (ohne Abrufzeitpunkt als Datenfeld)
- PEP-/Sanktionslistenchecks landen als Freitext (statt strukturiertes Ergebnis + Zeitstempel)
- News/Adverse Media wird als Linkliste gespeichert (ohne Metadaten/Referenzlogik)
Ergebnis: Schnelle Automatisierung. Schwache Nachweisbarkeit.
Und mit EU-Harmonisierung wird das relevanter: Teile des EU-AML-Pakets gelten ab 10. Juli 2027.
Quelle: Preventing abuse of the financial system for money laundering and terrorism purposes (until 2027)
Der kleinste Standard, der KI zuverlässig macht
Statt monatelang Governance-Dokumente zu schreiben, reicht ein Minimal-Contract für jedes Prüf-Event:
Quelle + Datum/Zeitstempel + Ergebnis + Entscheidung
Beispiel (audit-ready gedacht):
Handelsregister | 12.02.2026, 09:14 | „Vertretung geändert“ | Entscheidung: „Review vor Mandatsannahme“
News/Adverse-Media-Update | 12.02.2026 | „Relevanter Treffer“ | Entscheidung: „Eskalation“
Transparenzregister | 12.02.2026 | „UBO-Nachweis (Snapshot)“ | Entscheidung: „Dokumentiert“Damit wird KI-Output:
- exportierbar (Report/Akte ohne Copy-Paste)
- prüfbar (Quelle + Stand + Referenz)
- vergleichbar (Verläufe/Versionen)
- workflowfähig (Review/Case statt Bauchgefühl)
Signals vs Snapshots (Architekturprinzip, kein Regulatorik-Begriff)
Für robuste KYC/KYB-Workflows hilft ein einfaches Engineering-Prinzip:
Signals = Änderungen/Ereignisse, die einen Review anstoßen können
Snapshots = dokumentierter Stand zu einem Zeitpunkt („Stand heute“)
Praxisbeispiele:
- Signals: Änderungen aus dem Handelsregister für Unternehmen auf einer Watchlist (bei uns: täglich surfaced)
- Snapshots: UBO-Informationen aus dem Transparenzregister als Abruf/Snapshot inkl. Abrufzeitpunkt
Wichtig für Architektur und Kommunikation:
Für das Transparenzregister ist öffentlich vor allem ein Abruf-/Pull-Verfahren (Einsichtnahmeschnittstelle/automatisiertes Einsichtnahmeverfahren) dokumentiert. Ein event-getriebener UBO-Change-Feed ist dort öffentlich nicht als Standard beschrieben.
Konsequenz: UBO-Änderungen müssen über regelmäßige Re-Checks (Snapshot-Vergleich) abgedeckt werden, nicht über automatische Trigger aus dem Transparenzregister.
Quelle: (TR API)
Evidence Layer vs Decision Layer
Eine klare Rollenverteilung macht Produkte stabil:
Evidence Layer (Datenebene)
- liefert Daten, Dokumente, Referenzen, Zeitstempel
Decision Layer (Produktebene)
- bewertet (Regeln/KI), entscheidet, eskaliert
- speichert Entscheidung + Begründung als Case-Objekt
- erzeugt Review-Tasks, Exporte, QA-Flows
Kurz: Evidenz wird geliefert. Entscheidungen werden im Case-System verantwortet.
Wie Company.info in den Stack passt
Company.info liefert die Evidenzbasis, die KI-Workflows belastbar macht:
- Handelsregister: strukturierte Unternehmens-/Registerdaten + tägliche Änderungen für Watchlists
- Transparenzregister: UBO-Informationen als Snapshot mit dokumentiertem Abrufzeitpunkt
- PEP-/Sanktionslistenchecks: Screening-Ergebnisse als Datenpunkte (für Intake/Review)
- News / Adverse Media: Updates für definierte Watchlists inkl. Referenzen/Fundstellen
- KYC-Report (PDF): gebündelte Daten + Dokumente als Nachweispaket (für Ablage/Weitergabe)
Zwei einfache Blueprints für Product Teams
1) Audit-ready Intake
Ziel: KI unterstützt die Entscheidung, aber der Nachweis bleibt reproduzierbar.
- Handelsregister-Daten/Dokumente abrufen
- PEP-/Sanktionslistencheck durchführen
- News/Adverse Media prüfen
- Transparenzregister-Snapshot dokumentieren (UBO)
- Evidence Fields speichern (Quelle, Zeit, Ergebnis)
- Entscheidung im Case speichern (ok/review/escalate + kurzer Grund)
- optional: KYC-Report als Nachweispaket ausgeben
2) Reviews über Watchlist-Änderungen
Ziel: anlassbezogene Reviews statt permanent alles neu zu prüfen.
- Watchlist definieren
- tägliche Handelsregister-Änderungen beziehen (Signal)
- Relevanz klassifizieren (Regeln/KI)
- Review-Case erzeugen
- Entscheidung + Grund speichern
- parallel News/Adverse Media Updates einbeziehen
- Transparenzregister bei Bedarf via Re-Check (Snapshot)
Fazit
KI in LegalTech scheitert selten an Modellqualität.
Sie scheitert an fehlender Datenstruktur im Evidence Layer.
Wer Evidence Fields standardisiert, macht aus „AI Feature“ eine verlässliche Infrastruktur: prüfbar, exportierbar, reproduzierbar.
Möchten Sie sehen, wie strukturierte Registerdaten per REST-API in einen KI-Workflow integriert werden? Wir zeigen Ihnen gern ein technisches Beispiel.