Continuous Assurance: KI-Trust ist kein Stichtag

Viele Organisationen behandeln KI-Konformität wie eine Prüfung mit Bestehensdatum: ein Audit, ein Bericht, ein Haken. Doch ein KI-System ist kein statisches Bauteil. Es lernt weiter, wird mit neuen Daten gefüttert, in neue Prozesse eingebettet und trifft unter realen Bedingungen Entscheidungen, die im Labor nie auftauchten. Vertrauen, das auf einem einzelnen Stichtag beruht, ist deshalb in dem Moment veraltet, in dem es ausgesprochen wird.

Trust-Infrastructure setzt an genau dieser Stelle an. Nicht der bestandene Audit-Termin schafft Vertrauen, sondern die Fähigkeit, jederzeit nachzuweisen, dass ein System sich noch so verhält wie zugesichert. Der Fachbegriff dafür ist Continuous Assurance — fortlaufende, belegbare Zusicherung statt punktueller Momentaufnahme. Der EU AI Act schreibt diese Denkweise nicht nur vor; er macht sie zur Pflicht.

Warum der Stichtag-Audit zu kurz greift

Ein klassischer Konformitätsnachweis dokumentiert einen Zustand zu einem Zeitpunkt. Das ist notwendig, aber nicht hinreichend. Zwischen zwei Prüfungen verändert sich fast alles, was für die Risikobewertung relevant ist: Eingangsdaten verschieben sich (Data Drift), das Nutzungsumfeld ändert sich, neue Schnittstellen kommen hinzu, Modelle werden nachtrainiert. Ein System, das im März als unbedenklich eingestuft wurde, kann im September systematisch anders entscheiden — ohne dass jemand eine Zeile Code geändert hat.

Für Hochrisiko-KI ist diese Lücke kein theoretisches Problem. Genau deshalb verlangt der EU AI Act keine einmalige Bestätigung, sondern einen Mechanismus, der den Betrieb über die gesamte Lebensdauer hinweg beobachtet. Wer Trust als Stichtag versteht, erfüllt die Form, verfehlt aber die Substanz.

Post-Market-Monitoring: die Pflicht nach Art. 72

Der Kern dieser Logik steht in Artikel 72 der Verordnung (EU) 2024/1689. Provider von Hochrisiko-KI müssen ein Post-Market-Monitoring-System einrichten und dokumentieren — ein System zur Beobachtung nach dem Inverkehrbringen. Es sammelt, analysiert und bewertet aktiv und systematisch Daten über die Leistung des KI-Systems im realen Einsatz, und zwar über dessen gesamte Lebensdauer.

Dieses Monitoring ist kein loses Versprechen, sondern Teil eines verpflichtenden Post-Market-Monitoring-Plans, der in die technische Dokumentation gehört. Der Plan beschreibt, welche Daten erhoben werden, wie sie ausgewertet werden und wann das Ergebnis ein Eingreifen auslöst. Art. 72 verlangt damit ausdrücklich einen kontinuierlichen, datenbasierten Prozess — keine Wiederholungsprüfung im Jahresrhythmus.

Die Beobachtung endet nicht bei der internen Auswertung. Stellt das Monitoring ein ernstes Risiko oder eine schwerwiegende Störung fest, greift die Meldepflicht für schwerwiegende Vorfälle nach Artikel 73. Aus Beobachtung wird so eine handlungsauslösende Kette: erkennen, bewerten, melden, korrigieren.

Die Rolle der Deployer

Trust ist keine reine Provider-Aufgabe. Auch die Betreiber — im EU-AI-Act-Vokabular die Deployer — stehen in der Pflicht. Nach Artikel 26 müssen Deployer den Betrieb eines Hochrisiko-KI-Systems auf Grundlage der Betriebsanleitung überwachen, automatisch erzeugte Protokolle aufbewahren und den Provider informieren, wenn die Nutzung ein Risiko erzeugt oder ein schwerwiegender Vorfall auftritt.

Damit verteilt die Verordnung die Beweislast über die gesamte Kette. Der Provider liefert die Beobachtungslogik, der Deployer liefert die Betriebsrealität. Continuous Assurance funktioniert nur, wenn beide Seiten Evidenz erzeugen, die sich zusammenführen lässt — nicht zwei getrennte Aktenordner, sondern ein durchgängiger Nachweis-Strang. Genau hier entscheidet sich, ob eine Organisation im Ernstfall belegen kann, dass sie ihrer Sorgfaltspflicht nachgekommen ist.

Von der Pflicht zur Infrastruktur: AIMS als Betriebsmodell

Die rechtliche Pflicht beschreibt das Was, nicht das Wie. Damit Post-Market-Monitoring nicht zur manuellen Dauerbelastung wird, braucht es ein Betriebsmodell, das kontinuierliche Verbesserung strukturell verankert. Das liefert ein AI-Management-System nach ISO/IEC 42001.

ISO 42001 folgt der bekannten Plan-Do-Check-Act-Logik und macht den Check-Act-Teil zur Daueraufgabe: Überwachung, Messung, interne Audits, Managementbewertung und kontinuierliche Verbesserung sind keine Projektphasen, sondern ein laufender Kreislauf. In der AEGIRA-Lesart ist Maturity deshalb AIMS — ISO 42001 verschränkt mit der Reifegrad-Logik von CMMI v3. Reife bemisst sich nicht daran, ob ein Audit einmal bestanden wurde, sondern daran, wie verlässlich und reproduzierbar eine Organisation Evidenz erzeugt, bewertet und auf Abweichungen reagiert.

So schließt sich der Kreis zwischen Recht und Praxis. Art. 72 verlangt fortlaufende Beobachtung, ISO 42001 liefert das Managementgerüst, das diese Beobachtung in einen wiederholbaren Prozess überführt. Aus einer Compliance-Anforderung wird eine Trust-Infrastructure: ein System, das nicht behauptet, sondern belegt.

Was das für die Praxis heißt

Continuous Assurance verlangt eine andere Frage als der klassische Audit. Nicht „Haben wir die Prüfung bestanden?", sondern „Können wir jederzeit nachweisen, dass unser System sich noch korrekt verhält?". Drei Bausteine tragen diese Fähigkeit:

Erstens, Evidenz muss laufend und automatisch entstehen — Logs, Leistungskennzahlen, Drift-Indikatoren —, nicht erst auf Nachfrage rekonstruiert werden. Zweitens, es braucht definierte Schwellen, ab denen Beobachtung in Handlung umschlägt, samt klarer Zuständigkeit. Drittens, die Nachweise von Provider und Deployer müssen zusammenführbar sein, damit im Prüfungs- oder Vorfall-Fall ein lückenloses Bild entsteht.

Welche Systeme überhaupt unter diese Monitoring-Pflicht fallen, hängt an der Risikoeinstufung. Wer hier unsicher ist, klärt zuerst die Klassifizierung — eine erste Orientierung dazu bietet ki-risikostufe.de. Erst wenn feststeht, dass ein System hochriskant ist, greift der volle Pflichtenkatalog aus Art. 72 und Art. 26.

Mit Blick auf die Durchsetzung des EU AI Act am 02.12.2027 ist der Vorlauf knapp genug, um jetzt zu beginnen. Continuous Assurance ist nichts, was sich kurz vor einem Stichtag nachholen lässt — sie braucht eine Historie. Eine Organisation, die erst im Spätherbst 2027 mit dem Sammeln von Evidenz anfängt, kann genau das nicht vorweisen, worauf es ankommt: einen belegbaren Verlauf.

Trust ist deshalb kein Datum, sondern ein Zustand, den man halten muss. Wer ihn als nachweisbare, audit-fähige Infrastruktur aufbaut, statt ihn am Stichtag zu behaupten, ist nicht nur regelkonform — er ist vorbereitet. Mehr zur AEGIRA Trust-Platform: aegira.ai.