Compliance by Design

Viele KI-Projekte behandeln Compliance wie die letzte Mappe vor dem Go-live: Datenschutz prüfen, ein paar Screenshots sammeln, Risiken beschreiben, Freigabe unterschreiben – fertig.

Genau dort beginnt das Problem.

Denn eine Dokumentation, die erst nachträglich entsteht, kann oft nur noch erzählen, was angeblich passiert ist. Sie kann nicht zuverlässig beweisen, welche Modellversion tatsächlich lief, welche Daten in welcher Zone verarbeitet wurden, welche Tests vor der Freigabe bestanden waren, wer eine Ausnahme genehmigt hat oder warum eine spätere Änderung keinen erneuten Review ausgelöst hat.

Professionelle KI-Governance braucht deshalb einen anderen Ansatz:

Compliance ist kein Archivordner am Ende des Projekts. Compliance ist eine Architektur, die festlegt, welche Nachweise während der Arbeit entstehen müssen, wer sie verantwortet, welche Kontrollen technisch wirken und was nicht weiterlaufen darf, wenn Evidenz fehlt.

Das ist Compliance by Design.

Compliance by Design beginnt vor dem ersten produktiven Run

Bei klassischer Nachweisdokumentation wird zuerst gearbeitet und anschließend beschrieben, was gemacht wurde. Bei Compliance by Design wird vor Beginn des kritischen Workflows entschieden:

Welche regulatorische oder interne Anforderung ist relevant? Welcher konkrete Kontrollmechanismus erfüllt sie? Wer besitzt diese Kontrolle? Welche Evidenz muss automatisch oder manuell entstehen? An welche System-, Modell- und Artefaktversion wird der Nachweis gebunden? Wann wird er geprüft? Was blockiert die Freigabe? Wann muss der Nachweis erneuert werden? Wie lange darf oder muss er aufbewahrt werden?

Damit wandert Compliance aus dem Bereich der Erinnerung in den Bereich des Systemdesigns.

Dokumentation ist nicht gleich Compliance

Ein Projekt kann hervorragend dokumentiert und trotzdem nicht compliant sein.

Umgekehrt kann ein System eine materielle Anforderung erfüllen, aber später Schwierigkeiten bekommen, weil die Einhaltung nicht nachweisbar ist.

Deshalb müssen fünf Dinge getrennt werden:

Der Report ist also nicht die Kontrolle. Und die Kontrolle ist nicht automatisch der Nachweis ihrer eigenen Wirksamkeit.

Die zentrale Verschiebung: vom Protokoll zum operativen Steuerungssystem

In reifen KI-Projekten sollte das Projektmanagement- oder Governance-System nicht erst nachträglich mit Ergebnissen befüllt werden.

Risiken, Entscheidungen, Gates, Ausnahmen, Evidenz und Releases sollten während der tatsächlichen Arbeit dort entstehen.

Das verändert die Qualität der Nachweise fundamental.

Wenn ein Agent einen Arbeitsschritt startet, kann der Vorgang bereits mit einem Task, einer Datenklasse und einer zulässigen Tool-Policy verknüpft sein. Wenn ein Gate erreicht wird, ist definiert, welche Evidenz vorliegen muss. Wenn ein Modell gewechselt wird, erzeugt die Änderung einen neuen Prüftatbestand. Wenn ein kritischer Test scheitert, bleibt der nachgelagerte Release blockiert.

So entsteht kein Audit-Tagebuch, sondern eine ausführbare Kontrollstruktur.

Evidence by Construction

Der stärkste Nachweis ist häufig derjenige, der nicht separat erzeugt werden muss.

Wenn ein System bei jedem kritischen Run automatisch festhält, welches Modell und welche Version verwendet wurden, welche Policy galt, welche Datenklasse verarbeitet wurde, welche Tools aufgerufen wurden, welches Artefakt entstand, welche Eval-Version darüber lief und welches Gate anschließend entschieden wurde, entsteht Evidenz als Nebenprodukt eines korrekt gebauten Prozesses.

Das lässt sich als Evidence by Construction beschreiben.

Die Alternative wäre, Wochen später anhand von Chatverläufen, Erinnerungen und Screenshots zu rekonstruieren, was vermutlich passiert ist. Genau das skaliert bei agentischen Systemen nicht.

Compliance ist eine Kette, kein Dokument

Eine belastbare Compliance-Kette kann so aussehen:

Anforderung → Risiko → Kontrolle → Ausführung → Evidenz → Review → Entscheidung → Version → Monitoring

Jedes Glied erfüllt eine andere Funktion.

Fehlt die Anforderung, weiß niemand, warum die Kontrolle existiert. Fehlt das Risiko, ist die Maßnahme möglicherweise unverhältnismäßig. Fehlt die Kontrolle, bleibt Compliance deklarativ. Fehlt Evidenz, ist die Wirksamkeit nicht nachweisbar. Fehlt Versionierung, ist unklar, für welchen Systemzustand der Nachweis galt. Fehlt Monitoring, altert die Entscheidung unbemerkt.

Die eigentliche Einheit der Compliance ist deshalb nicht das PDF, sondern die verknüpfte Evidenzkette.

Der Compliance Stack für KI-Projekte

Für praktische Projekte hilft ein mehrschichtiger Stack.

1. Scope & Classification

Welche Rolle hat die Organisation? Welches System, welcher Use Case und welche Nutzergruppe sind betroffen? Welche Rechtsräume und Branchenregeln sind relevant? Handelt es sich überhaupt um einen regulierten Hochrisiko-Fall oder um ein wesentlich einfacheres Szenario?

2. Risk & Impact

Welche Schäden oder Grundrechtsbeeinträchtigungen sind realistisch? Welche Datenrisiken existieren? Welche Personen oder Gruppen können betroffen sein? Wo sind Fehlentscheidungen reversibel – und wo nicht?

3. Control Design

Welche technischen und organisatorischen Kontrollen adressieren diese Risiken? Dazu gehören beispielsweise Datenzonen, Tool-Rechte, Gates, menschliche Aufsicht, Rate Limits, Ausnahmeregeln oder Freigabeprozesse.

4. Operational Evidence

Welche Logs, Testresultate, Reviews, Entscheidungen und Versionen entstehen tatsächlich im Betrieb?

5. Technical Documentation

Wie werden Zweck, Systemarchitektur, relevante Versionen, Abhängigkeiten, Datenflüsse, Tests, Einschränkungen und Betriebsbedingungen zusammenhängend dokumentiert?

6. Change & Lifecycle Governance

Welche Änderungen lösen Re-Tests, neue Freigaben, Impact-Assessments oder eine Neubewertung der Risikoklasse aus?

7. Monitoring & Incident Response

Wie wird nach dem Go-live erkannt, ob sich Leistung, Risiken, Provider, Daten oder Nutzerverhalten verändern?

Der Stack macht deutlich: Compliance beginnt nicht beim Archivieren. Sie beginnt bei Scope und Design.

Erst klassifizieren, dann dokumentieren

Ein verbreiteter Fehler ist die maximale Dokumentation ohne vorherige Risikoklassifikation.

Das führt zu zwei Problemen. Erstens erzeugt man unnötige Bürokratie für harmlose Workflows. Zweitens kann die Masse an Dokumenten kritische Nachweise sogar verdecken.

Professioneller ist ein risikoproportionaler Ansatz:

Use Case beschreiben. Rolle und Verantwortlichkeit bestimmen. Daten- und Betroffenenklassen erfassen. Regulatorischen Scope prüfen. Risikoniveau und Reversibilität bewerten. Daraus Kontroll- und Evidenztiefe ableiten.

Mehr Dokumentation ist nicht automatisch mehr Compliance. Bessere Zuordnung ist mehr Compliance.

Provider und Deployer sind nicht dasselbe

Gerade beim EU AI Act ist die Rolle entscheidend.

Ein Unternehmen, das ein Hochrisiko-KI-System entwickelt und unter eigenem Namen bereitstellt, hat andere Pflichten als eine Organisation, die ein vorhandenes System einsetzt. Daneben können Importeur, Distributor, autorisierter Vertreter oder andere Akteure relevant werden.

Auch die Datenschutzrollen funktionieren anders: Verantwortlicher und Auftragsverarbeiter sind keine Synonyme für Provider und Deployer.

Deshalb gehört an den Anfang eines Compliance-Plans eine Role Map.

Ohne sie entsteht schnell die falsche Dokumentation für die falsche Pflicht.

Ein aktueller Rechtsstand ist selbst ein Projektartefakt

Compliance-Dokumentation muss nicht nur das System versionieren, sondern auch die regulatorische Grundlage.

Das ist besonders bei schnell veränderlicher KI-Regulierung wichtig. Stand August 2026 gilt der AI Act grundsätzlich seit dem 2. August 2026, während die Regeln für viele eigenständige Hochrisiko-Systeme nach dem 2026 in Kraft getretenen AI Omnibus erst ab dem 2. Dezember 2027 und für in regulierte Produkte eingebettete Hochrisiko-Systeme ab dem 2. August 2028 greifen.^[1]

Ein Projekt sollte daher dokumentieren:

Welche Rechtsfassung geprüft wurde, zu welchem Datum, welche Einstufung daraus abgeleitet wurde, welche offenen Leitlinien oder Standards noch fehlen, und wann ein erneuter Legal Review vorgesehen ist.

Die Aussage „Das haben wir damals geprüft“ reicht nicht.

Die gefährliche Illusion einer universellen Aufbewahrungsfrist

Auch bei Retention sind pauschale Zahlen problematisch.

Eine verbreitete Kurzform lautet: „KI-Projektdokumentation muss X Monate aufbewahrt werden.“ So allgemein funktioniert das nicht.

Für bestimmte Pflichten des EU AI Act gelten unterschiedliche Fristen. Für Anbieter von Hochrisiko-KI-Systemen nennt Artikel 18 für bestimmte Dokumente grundsätzlich zehn Jahre nach Inverkehrbringen oder Inbetriebnahme.^[7] Artikel 19 verlangt bei automatisch erzeugten Logs unter Kontrolle des Providers grundsätzlich mindestens sechs Monate, soweit anderes Unions- oder nationales Recht nichts Abweichendes vorsieht. Für Betreiber nennt Artikel 26 für entsprechende Logs ebenfalls mindestens sechs Monate, soweit sie unter ihrer Kontrolle stehen und kein anderes Recht abweichende Regeln setzt.^[8]

Datenschutz-, Arbeits-, Finanz-, Gesundheits- oder andere sektorale Regeln können wiederum andere Anforderungen erzeugen.

Daraus folgt:

Retention muss pro Artefakt und Rechtsgrund bestimmt werden.

Ein einziger „Compliance-Archivzeitraum“ ist meist zu grob.

Die Compliance Matrix

Eine der wirksamsten Strukturen ist eine Matrix, die aus abstrakten Pflichten konkrete Projektobjekte macht.

Die Matrix verhindert drei typische Fehler: ownerlose Pflichten, Kontrollen ohne Nachweis und Dokumente ohne Anlass für Aktualisierung.

Das Minimum Viable Evidence Pack

Nicht jedes Projekt braucht ein regulatorisches Dossier in der Tiefe eines Hochrisiko-Systems.

Für einen normalen professionellen KI-Workflow kann jedoch ein Minimum Viable Evidence Pack sinnvoll sein. Das ist keine gesetzlich definierte Mindestliste, sondern ein methodischer Basisstandard:

System Card mit Zweck und Grenzen. Datenfluss- und Datenklassifikationskarte. Modell-/Provider-/Versionsregister. Risk & Decision Log. Eval Record für kritische Qualitätskriterien. Gate-/Release Record. Change Log. Incident Log. Zuständigkeiten und Eskalationsweg.

Damit wird ein kleines Projekt nicht überreguliert, bleibt aber später rekonstruierbar.

System Card: der Zweck als Kontrollobjekt

Die System Card sollte mehr leisten als ein Produktsteckbrief.

Sie definiert mindestens:

Intended Use, Non-Intended Use, Nutzergruppen, relevante Datenklassen, erlaubte Aktionen, bekannte Grenzen, kritische Abhängigkeiten, System Owner und Review-Datum.

Diese Angaben sind nicht statisch.

Wenn ein Team aus einem internen Textassistenten später ein System für Bewerberauswahl macht, ist das keine kleine Funktionsänderung. Der Use Case hat sich fundamental verändert – und damit möglicherweise der gesamte regulatorische Scope.

Data Map: nicht nur „Welche Daten haben wir?“

Eine Compliance-fähige Datenkarte beschreibt nicht nur Datenquellen.

Sie sollte für relevante Datenflüsse beantworten:

Herkunft, Zweck, Sensitivität, Rechts- und Policy-Grundlage, Speicherort, Transferzone, Zugriffsrollen, Retention, Löschlogik und Downstream-Empfänger.

Gerade bei hybriden KI-Architekturen wird damit sichtbar, ob ein scheinbar lokaler Workflow später doch Daten über Telemetrie, Retrieval, Debugging oder externe Tools exportiert.

Risiko- und Folgenabschätzung muss vor der Wirkung liegen

Ein Impact Assessment, das erst nach dem Rollout erstellt wird, hat seine wichtigste Funktion bereits verfehlt.

Der Sinn ist nicht, bereits entstandene Wirkung nachträglich zu beschreiben, sondern mögliche Auswirkungen vor einer kritischen Verwendung zu identifizieren und Kontrollen darauf auszurichten.

Das Prinzip findet sich sowohl im Datenschutz als auch im AI Act wieder. Unter der DSGVO ist eine Datenschutz-Folgenabschätzung bei voraussichtlich hohem Risiko grundsätzlich vor der Verarbeitung durchzuführen. Der EU AI Act verlangt für bestimmte Betreiber bestimmter Hochrisiko-Systeme eine Grundrechte-Folgenabschätzung vor dem Einsatz.^[9]

Nicht jeder KI-Use-Case braucht deshalb automatisch eine formelle FRIA oder DPIA.

Aber jedes professionelle Projekt profitiert von der Grundfrage:

Welche Wirkung müssen wir verstehen, bevor wir den Systemzustand produktiv machen?

Kontrollen müssen an reale Systemgrenzen gekoppelt sein

Eine Policy in einem PDF kontrolliert nichts, solange sie nicht in einen wirksamen Prozess übersetzt wird.

Beispiele:

„Keine sensiblen Daten in externe Modelle“ → Data Router blockiert definierte Klassen. „Keine Veröffentlichung ohne Freigabe“ → Publishing Tool benötigt Gate Token. „Nur evaluierte Modellversionen“ → Deployment akzeptiert nur freigegebene Registry-Versionen. „Ausnahmen müssen genehmigt werden“ → Exception Record mit Owner, Begründung und Ablaufdatum.

Das ist die Brücke zwischen Compliance-Dokumentation und Compliance-Engineering.

No Evidence, No Release

Für kritische Artefakte sollte eine einfache Regel gelten:

Kein Nachweis, keine Freigabe.

Das bedeutet nicht, dass jeder kleine Textentwurf einen Compliance-Officer benötigt.

Es bedeutet, dass dort, wo ein Projekt eine Kontrollanforderung definiert hat, der nachgelagerte Zustand nur erreichbar ist, wenn das notwendige Evidence Packet existiert.

Ein Release-Gate kann zum Beispiel verlangen:

Eval bestanden, Datenfreigabe gültig, Modellversion registriert, bekannte Risiken akzeptiert, Human Authority benannt, Rollback vorhanden.

Damit wird Compliance vom Wunsch zur State Transition Rule.

Gate-Evidenz muss an einen Zustand gebunden sein

Eine Freigabe ohne Versionsbezug ist gefährlich.

„Freigegeben am 12. August“ sagt wenig, wenn danach Prompt, Modell, Datenbasis und Toolrechte geändert wurden.

Jede belastbare Freigabe sollte deshalb mindestens referenzieren:

System- oder Release-ID, Modellversion, relevante Policy-Version, Eval-Version, Daten- und Kontextstand, Entscheidung, Entscheider, Zeitpunkt und Gültigkeitsbedingungen.

Sobald eine definierte Bedingung verletzt wird, muss die Freigabe veralten.

Change Management ist Compliance Management

KI-Systeme verändern sich schnell.

Neue Modellversion. Neuer Provider. Neuer Systemprompt. Zusätzliche Datenquelle. Neue Nutzergruppe. Mehr Toolrechte. Höherer Automationsgrad. Anderer Outputkanal.

Jede Änderung kann den bisherigen Nachweis teilweise entwerten.

Deshalb braucht ein Projekt Change Classes.

Klasse A — kosmetisch

Keine materielle Auswirkung auf Funktion, Daten oder Risiko. Dokumentieren, aber kein Vollreview.

Klasse B — funktional

Funktion oder Verhalten ändert sich. Zielgerichtete Re-Evals und aktualisierte Dokumentation.

Klasse C — material risk change

Datenklasse, Nutzergruppe, Wirkbereich, Toolrechte, Autonomie oder kritische Abhängigkeiten ändern sich. Neuer Risiko-/Compliance-Review und gegebenenfalls neue Folgenabschätzung.

Die konkrete Einteilung muss projektspezifisch sein. Wichtig ist der Mechanismus: Änderung erzeugt automatisch eine Prüffrage.

Versionierung muss über Code hinausgehen

Git allein reicht nicht.

In KI-Projekten sollten mindestens folgende Objekte versionierbar oder eindeutig identifizierbar sein:

Systembeschreibung, Prompt- und Instruction-Set, Modell- und Providerkonfiguration, Retrieval-Quellen, Tool-Schema und Rechte, Eval-Suite, Policy-Regeln, Datenklassifikationen, Freigabe und technische Dokumentation.

Sonst entsteht eine seltsame Situation: Der Code ist exakt versioniert, aber niemand weiß, mit welcher Policy und welchem Modell der reale Release betrieben wurde.

Compliance braucht Eigentümer

Ownerless Controls sterben leise.

Jede wesentliche Kontrolle braucht mindestens:

Control Owner – verantwortet Funktion und Pflege.

Evidence Owner – stellt sicher, dass der Nachweis entsteht und auffindbar bleibt.

Reviewer – prüft Wirksamkeit oder Angemessenheit.

Accountable Authority – akzeptiert Restrisiko oder blockiert Freigabe.

In kleinen Teams können mehrere Rollen bei einer Person liegen. Die Rollenlogik sollte trotzdem explizit sein.