Traceability by Design: Auditfähigkeit ist Architektur, nicht Dokumentation

Woher kommt diese Zahl, und kann ich sie später exakt so belegen?

Gerade in High-Risk-Kontexten wird Traceability (Nachvollziehbarkeit über den gesamten Lebenszyklus) zum Engpass. Nachweise müssen dauerhaft belastbar sein - nicht nur „im Moment plausibel“.

Zur Einordnung: Den High-Risk-Kontext und die Grundlage über Datenqualität haben wir im Vorwochen-Post EU AI Act Art 10 behandelt.

Unsere These: Auditfähigkeit entsteht nicht durch zusätzliche PDFs, sondern durch eine Architektur, die Belege automatisch erzeugt.

Hinweis: Keine Rechtsberatung, sondern technische Einordnung.

Warum Traceability zum Problem wird

In vielen BI- und AI-Setups fehlt nicht Dokumentation, sondern Reproduzierbarkeit. Sobald eine Zahl oder ein Modell-Output hinterfragt wird, beginnt die Suche nach Quelle, Logik, Version und Freigaben. Ohne systematische Traceability wird das schnell zur Rekonstruktion.

inics Praxisbeispiel:

Ein Scoring-Modell unterstützt Entscheidungen. Im Review muss klar sein, welche Datenbasis, welche Logik, welcher Modellstand und welche Freigaben zu einem konkreten Ergebnis geführt haben.

EU AI Act: Was für Traceability zählt

Der EU AI Act macht Traceability nicht zum Selbstzweck. Er macht sie zur Voraussetzung, sobald ein Use Case tatsächlich in einem High-Risk-Kontext landet. Dann reicht es nicht, dass etwas „irgendwie dokumentiert“ ist - es muss nachvollziehbar sein, wie das System gebaut wurde, wie es betrieben wird und was sich über Zeit verändert hat.
‍

Wichtig: Das ist weniger „ein neuer Dokumentationsprozess“ als ein Plattform- und Governance-Merkmal. Wenn die Plattform die Nachweise automatisch erzeugt (und Verantwortlichkeiten/Controls klar sind), sinkt der Aufwand und Diskussionen werden schneller sachlich.

Der Denkfehler: Mehr Doku heißt nicht mehr Nachweisbarkeit

Mehr Dokumente erhöhen Aufwand, aber selten Nachweisbarkeit.
Traceability entsteht, wenn die Plattform zu jeder relevanten Aussage beantworten kann:

Was war der Input, welche Transformation ist gelaufen, welche Version war im Einsatz, welche Kontrollen und Entscheidungen gab es und wo liegt die Evidenz?

Audit Evidence Pack Blueprint: das Zielbild für Traceability

Ein Audit Evidence Pack ist kein einzelnes Dokument. Es ist ein automatisch entstehender Satz von Artefakten, der Nachvollziehbarkeit praktisch macht:

• Lineage von Quelle bis KPI oder Modell-Output (z. B. über Unity Catalog Lineage / dbt Metadaten).
• Versionierung für Code, Modelle, Semantik und zentrale Konfigurationen.
• Run Evidence, also Run-Referenz, Zeitpunkt, Input-Versionen/Partitionen, Outputs, Check-Status und Referenzen auf Versionen.
• Betriebs-Logging plus Retention, damit nachvollziehbar bleibt, wie das System genutzt wurde und was bei Abweichungen passiert ist.‍
• RAG-Beispiel (nicht-deterministisch): Ohne saubere Evidence ist ein RAG-Output später oft nicht reproduzierbar, weil sich Quellenabrufe, Index/Embeddings oder Prompt-/Pipeline-Versionen verändern. Deshalb braucht es mindestens: Quellenabrufe, Index-/Embedding-Version, Prompt- und Pipeline-Version (idealerweise mit Run-Referenz).‍
• Auffindbare Ablage und Monitoring, damit Evidence schnell gefunden wird und Abweichungen im Betrieb sichtbar werden.

Kurzes Praxisbeispiel (Databricks + dbt):

Für einen KPI-Run wird automatisch ein Evidence Pack erzeugt, das u. a. diese Kerndaten enthält:

dbt: manifest.json + run_results.json (Transformationen + Test-Status)
Databricks: Workflow-Run-Referenz (Zeitpunkt, Status,Runtime/Cluster-Kontext)
Inputs: main.raw.sap_orders @ Delta version=4431, main.raw.fx_rates @Delta version=120
Output: main.gold.finance_revenue_daily @ Delta version=882 + Rowcount

→ Ergebnis: Ein Dritter kann den KPI nicht „glauben“, sondern belegen – inklusive Datenstand, Transformationslogik und Run-Referenz.

Pragmatiker-Start ohne Großprojekt

Man muss dafür kein großes Programm aufsetzen. In Projekten starten wir meist klein und sichtbar: ein kritischer Flow, ein KPI oder ein AI-Use-Case, der wirklich genutzt wird. Dann definieren wir, was man dazu jederzeit erklären können muss. Erst danach bauen wir die minimalen Bausteine, damit diese Antworten nicht gesucht, sondern geliefert werden.

Praktisch heißt das: Lineage und Versionierung zuerst. Danach Run Evidence und Logging standardisieren. Und zum Schluss Ablage, Retention und Monitoring so festlegen, dass es im Betrieb mitläuft.

Fazit

Der Markt belohnt nicht mehr Dokumentation, sondern Systeme, die Nachvollziehbarkeit im Betrieb erzeugen. Traceability by Design ist der Unterschied zwischen „wir glauben, es passt“ und „wir können es belegen“. Wenn Nachweise nicht automatisch entstehen, entstehen sie im Audit — als Stress, Aufwand und Risiko.

Im nächsten und letzten Teil geht es um Inventarisierung und Steuerung von AI und Analytics, damit Verantwortung und Priorisierung skalieren.

‍

‍