ai-governance mlops agentops risk-management agents

Vom Modell zum Agenten: Die Neugestaltung der drei Schutzlinien

Wie sich die Governance von MLOps auf Agentensysteme überträgt: Was jede der drei Schutzlinien hinzufügen muss, wo die Lücken liegen, und welche Signale die EU-, FDA- sowie Finanzaufsichtsbehörden senden.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 20268 Min. Lesezeit1734 Wörter

Quellen: From MLOps to AgentOps: Redrawing the Three Lines of Defense

Agierende KI durchbricht die für herkömmliche Software und konventionelle Modelle entwickelten Governance-Verfahren, doch diese Behauptung lässt sich leicht anhand eines konkreten Beispiels veranschaulichen. Jahrelange Arbeit im Bereich MLOps – einschließlich Modellverwaltung, Validierungsworkflows, Drift-Überwachung sowie Genehmigungsprozessen in Unternehmens- und Finanzdienstleistungsumgebungen – wird nicht einfach verworfen, wenn eine Organisation LLMs und Agenten einsetzt. Was sich ändert, ist enger und spezifischer, als die meisten Menschen annehmen.

Stellen Sie sich ein Team für Modellrisiken vor, das einen gewöhnlichen Antragsformular bearbeitet. Das Formular stellt die üblichen Fragen zu den Trainingsdaten, der Versionnummer, dem Freigabestatus sowie dem Datum der letzten Abweichungskontrolle – Fragen, mit denen das Team bereits zahlreiche Anträge bearbeitet hat. Dann folgt die Beschreibung des Systems: vier zusammenarbeitende Agenten, sechs unter ihnen geteilte Tools, ein täglich neu erstellter Abrufindex sowie ein Ergebnis, das durch eine Kette von Schritten entsteht, bei denen jeder einzelne Schritt in Ordnung zu sein scheint. Nichts auf dem Formular passt dazu.

Eine McKinsey-Umfrage zum Thema KI-Vertrauen aus dem Jahr 2026, die etwa fünfhundert Organisationen umfasst, zeigt ein ähnliches Bild: Rund ein Drittel der Unternehmen gibt an, dass ihre Governance-Reife für die bereits im Einsatz befindlichen autonomen Agenten ausreichend sei. Die Übrigen verwenden weiterhin das alte Antragsformular und hoffen, dass es ausreicht. In der Regel reicht es jedoch nicht, weshalb es wichtig ist, genau herauszufinden, wo es versagt.

Was das bestehende Programm bereits abdeckt

MLOps-Governance umfasst die Reihe von Kontrollmechanismen, die sicherstellen, dass ein traditionelles Machine-Learning-Modell von der Schulung bis zur Außerdienststellung zuverlässig bleibt. In der Praxis:

Versionierung von Modellen, damit stets klar ist, welches Modell in der Produktion läuft und warum.
Überwachung von Abweichungen, die einen Leistungsabfall erkennen, wenn sich die Eingabedaten ändern.
Datenspurierung bis zu den Schulungs- und Validierungsdatensätzen.
Genehmigungsprozesse vor jeder Veröffentlichung in der Produktion.
Die für jedes Produktivsoftware erwarteten CI/CD- und Change-Management-Verfahren, die im Rahmen dieses Programms umgesetzt werden und nicht daneben.

Niemand dieser Mechanismen funktioniert von selbst. Jemand muss für jede Kontrolle verantwortlich sein, und jemand anderes muss überprüfen, ob diese Person ihre Aufgabe erledigt hat.

Die Verantwortung wird in der Regel über das Konzept der drei Verteidigungslinien zugewiesen, ein Rahmenwerk, das Banken und andere regulierte Branchen seit Langem zur Zuweisung von Verantwortlichkeiten nutzen. Ein Hinweis zur Genauigkeit: Das Institute of Internal Auditors nannte es 2020 in „Three Lines Model“ um, wodurch der Schwerpunkt auf Wertschöpfung statt auf reinem Schutz gelegt wurde. In Finanz- und Modellrisikokreisen spricht man weiterhin von drei Verteidigungslinien, genauso wie in diesem Text, obwohl der offizielle Name sich geändert hat.

In einem herkömmlichen MLOps-Programm sieht die Aufteilung wie folgt aus:

Die erste Verteidigungslinie, die Produktentwicklung, Datenverarbeitung und Ingenieurwesen umfasst, ist für die Entwicklung, Tests, Bereitstellung und Dokumentation von Modellen verantwortlich.
Die zweite Verteidigungslinie, die Compliance und Risikomanagement umfasst, legt Richtlinien für die Nutzung von Modellen fest, überwacht Vorurteile und prüft hochriskante Anwendungen vor dem Start.

Die dritte Ebene, die interne Prüfung, hat die engste Aufgabenbeschreibung: Sie soll unabhängig bestätigen, dass die ersten beiden Ebenen das tun, was sie behaupten, ohne selbst etwas zu entwickeln oder zu genehmigen.

Diese Struktur ist ausgereift und gut verstanden und eignet sich für die Systeme, für die sie ursprünglich konzipiert wurde, nämlich Modelle mit fester Struktur, die einmal validiert und in den Zeitabständen zwischen Überprüfungen überwacht werden.

Wie sich jede Ebene für Agenten ändern muss

Die Governance von AgentOps beginnt ebenfalls mit diesen drei Ebenen, doch der Inhalt, den jede Ebene überprüft, unterscheidet sich, da sich die Systeme unterschiedlich verhalten. Die Unterschiede lassen sich auf fünf spezifische Punkte reduzieren.

Ein Artefakt wird zu vielen. Ein klassisches Modell ist etwas, das einzeln versioniert wird. Das Vier-Agenten-System hingegen besteht aus einem Bündel: dem Basismodell, vier Systemanweisungen, sechs Tool-Definitionen sowie einer selbstständig aktualisierten Abrufschicht. Jeder dieser Bestandteile kann das Verhalten verändern, weshalb jede Komponente versioniert und getestet werden muss. Das erinnert weniger an einen Registrierungseintrag und eher an Anweisungen sowie Tool-Schemata, die wie Quellcode behandelt werden – mit Versionskontrolle, Überprüfung von Pull-Requests sowie Canary-Tests anhand einer separaten Testgruppe, bevor etwas freigegeben wird. Wenn nur das Modell verfolgt wird, bleiben etwa drei Viertel der verhaltensbezogenen Aspekte unverwaltet.

Die korrekte Ausgabe fällt in den zulässigen Bereich. Wenn man einem traditionellen Modell dieselbe Eingabe gibt, liefert es dieselbe Ausgabe – deshalb ist die Validierung einfach. Ein LLM kann bei verschiedenen Ausführungen zwei unterschiedliche, aber nachvollziehbare Antworten liefern. Daher prüft die zweite Methode nicht mehr, ob eine Antwort richtig ist, sondern ob die Antworten meistens innerhalb eines akzeptablen Bereichs liegen. Dafür ist ein Bewertungssystem mit festgelegten Schwellenwerten erforderlich, beispielsweise eine Mindestbestehensrate in einem gelabelten Testset vor der Veröffentlichung, sowie ein Mechanismus für menschliche Überprüfung, wenn das Vertrauen oder die Bewertungsscores unter einen bestimmten Wert sinken. Die Einigung darüber, was unter „meistens akzeptabel“ in einem bestimmten Anwendungsfall zu verstehen ist, ist eine eigene Aufgabe – etwas, das nicht schon am Nachmittag erledigt werden kann.

Ein einzelner Eigentümer wird zu einer Kette. Ein einzelnes Modell, das eine einzige Vorhersage trifft, hat einen offensichtlichen Eigentümer. Ein System mit vier Agenten hingegen nicht. Wenn das Endresultat falsch ist, aber kein einzelner Schritt fehlerhaft war, erfordert die Diagnose ein Entscheidungsprotokoll, das die Zwischengaben sowie das Endprodukt festhält: die Eingaben jedes Agenten, jede Entscheidung und das, was weitergeleitet wurde. Ohne ein solches Protokoll kann niemand sagen, welcher Agent für den Fehler verantwortlich ist, und die beteiligten Personen streiten nach einem Vorfall darüber, anstatt im Voraus eine Einigung zu erzielen.

Drift-Überwachung ist keine Verhaltensüberwachung. Bei Drift-Prüfungen werden Vorhersagen mit einer bekannten Basislinie verglichen. Dabei bleibt unberücksichtigt, was ein Agent während der Ausführung tut: die von ihm aufgerufenen Tools, die von ihm ausgeführten Aktionen sowie ob er im definierten Rahmen bleibt. Agent-Überwachungsplattformen beheben diesen Blindpunkt, indem sie den gesamten Ausführungspfad aufzeichnen – einschließlich Toolaufrufe, Parameter sowie der Art und Weise, wie die Ausgabe eines Agents die des nächsten beeinflusst. Viele dieser Plattformen stützen sich auf offene Standards wie OpenTelemetry, die dafür sorgen, dass die Aufzeichnungen zwischen verschiedenen Anbietern kompatibel sind. Für dieses System ist der Ausführungspfad das einzige Artefakt, anhand dessen ein Prüfer die Ereignisse später rekonstruieren kann. Ohne ihn prüft man eine „Black Box“ und bezeichnet dies als unabhängige Überprüfung.

Die Neuanpassung des Kalenders wird zu einer kontinuierlichen Veränderung. Traditionelle Modelle werden nach einem Zeitplan neu trainiert: monatlich, quartalsweise oder immer dann, wenn genügend neue Daten anfallen. Ein auf RAG oder kontinuierlichem Feintuning basierendes System kann sein effektives Verhalten so oft ändern, wie seine Wissensbasis aktualisiert wird – möglicherweise täglich. Wenn die Abrufschicht jede Nacht aktualisiert wird, überprüft eine dritte Ebene, die auf quartalsweisen Überprüfungen beruht, das System nur etwa neunzigmal seltener als es sich ändert.

Wo sich die beiden Ansätze treffen

Im direkten Vergleich weisen die beiden Ansätze eine gemeinsame Struktur auf. Gleich drei Ebenen sind relevant, und beide erfordern Versionierung, Testing, Überprüfung sowie unabhängige Prüfung. Die Unterschiede liegen in der Granularität, der Häufigkeit sowie dem Objekt, das jeweils überprüft wird.

Bei der Governance von MLOps liegt hier kein Fehler vor. Die damit verbundenen Fragen basierten einfach auf der Annahme, dass sich das Verhalten des Modells zwischen den Überprüfungen nicht ändert – doch ein System, dessen Abrufindex jede Nacht neu erstellt wird, kann nicht so lange unverändert bleiben. Alle fünf Unterschiede resultieren daraus, dass diese Annahme nicht zutrifft: Was früher monatlich geändert wurde, kann nun täglich ändern, manchmal sogar, ohne dass jemand das Modell überhaupt berührt.

Um diese Lücke zu schließen, ist es nicht notwendig, eine neue Governance-Funktion von Grund auf zu entwickeln. Stattdessen müssen die bestehenden Strukturen um Funktionen erweitert werden, die zuvor nicht benötigt wurden, wobei der Aufwand jeder dieser Erweiterungen ehrlich bewertet werden muss:

Erste Maßnahme: Versionskontrolle für Anfragen und Tools sowie Canary-Testing vor der Einführung. Dabei handelt es sich hauptsächlich um eine Änderung in den ingenieurtechnischen Praktiken und nicht um die Einrichtung eines neuen Teams.
Zweite Zeile: Eine Bewertungsschranke, die die Akzeptanzschwelle angibt, zusammen mit einem schriftlichen Eskalationsweg für Entscheidungen, die mehrere Agenten betreffen. Dies ist ein echtes Projekt zur Erstellung von Richtlinien, und in der ersten Phase werden tatsächliche Verhandlungen mit den Rechtsabteilungen und den Compliance-Teams stattfinden.
Dritte Zeile: Werkzeuge zur Laufzeit-Überwachbarkeit sowie die Fähigkeiten, ein Entscheidungsprotokoll statt einer statischen Modellkarte zu prüfen. Für die meisten Funktionen zum Umgang mit Modellrisiken bedeutet das eine neue Einstellung oder umfassende Schulungen – nicht nur ein Häkchen in einem alten Überprüfungsformular.

Nichts davon ist optional, wenn das Ziel darin besteht, glaubwürdig festzustellen, welcher der vier Agenten die Entscheidung getroffen hat.

Was die Regulierungsbehörden bisher gesagt haben

Kein einziges regulatorisches Rahmenwerk hat sich vollständig an künstliche Intelligenzen mit Agentenfunktionen angepasst, doch drei bestehende Modelle aus verschiedenen Branchen zeigen, in welche Richtung sich die Entwicklung bewegt.

Das EU-KI-Gesetz gilt für alle Branchen. Die Transparenzpflichten gemäß Artikel 50 treten unabhängig von weiteren Entwicklungen am 2. August 2026 in Kraft. Die anspruchsvolleren Hochrisikopflichten aus Anhang III gelten zunächst ebenfalls zu diesem Datum, doch das vorgeschlagene Digital Omnibus-Paket, das im Mai 2026 grundsätzlich vereinbart wurde und noch einer formellen Verabschiedung harrt, würde deren Inkrafttreten auf Dezember 2027 verschieben. Ein Konformitätskalender sollte diese Verschiebung als ausstehend ausweisen.
Die Behandlung kI-gestützter Medizinprodukte durch die FDA ist sektorspezifisch und produktorientiert; ihr wichtigstes Instrument ist der Predetermined Change Control Plan. Im Rahmen eines PCCP berechtigt die ursprüngliche Zulassung bereits zu bestimmten späteren Modellupdates, sofern diese innerhalb der festgelegten Leistungsgrenzen bleiben. Dazu gehören Leitlinien zu guten Praktiken im maschinellen Lernen sowie ein Qualitätsmanagement-System, das auf ISO 13485 ausgerichtet ist. Im Grunde wird die Änderungskontrolle zum Bestandteil des Zulassungsverfahrens, anstatt erst später als zusätzliche Pflicht hinzugefügt zu werden.

Die Finanzbranche ist teilweise deshalb aufschlussreich, weil sie bestimmte Aspekte ausklammert. Die interbehördliche Leitlinie SR 26-2 von 2026, die SR 11-7 ersetzt hat, schließt generative und agierende KI ausdrücklich aus ihrem formellen Geltungsbereich aus. Ein ausgereiftes Rahmenwerk räumt ein, dass Tools, die für eine bestimmte Generation von Modellen entwickelt wurden, nicht automatisch auf die nächste übertragen werden können, und die darunter arbeitenden Unternehmen entwickeln bereits jetzt Regeln zur Steuerung solcher Agenten, bevor die Aufsichtsbehörden dazu kommen.

Keines der drei Dokumente dient als Vorlage zum Kopieren. Wenn man sie zusammen liest, deuten sie eine Richtung an: Änderung der im Voraus genehmigten Grenzen, Einführung von Risikostufen sowie die offene Anerkennung einer Diskrepanz zwischen den aktuellen Regeln und dem Verhalten der Agenten.

Zurück zum Anmeldeformular

Das vorhandene Anmeldeformular kann bleiben. Neben diesem benötigt das Team ein separates Fragebogen für Mehr-Agentensysteme, das sich an den drei Bereichen orientiert, auf denen es bereits beruht, und man sollte davon ausgehen, dass ehrliches Beantworten tatsächlich Anstrengung erfordert.

Welcher Schritt wird zuerst nachgeholt? Wahrscheinlich die Versionsverwaltung, da es sich um ein Problem der Versionskontrolle handelt, das Ingenieure bereits lösen können. Die Verantwortlichkeitsklärung bei aufeinanderfolgenden Entscheidungen wird vermutlich am längsten dauern. Es handelt sich dabei um ein organisatorisches Gestaltungsproblem in technischem Gewand, und kein Bewertungsschritt kann das beheben.