KI-Governance braucht Architektur, nicht noch eine Checkliste

Die meiste KI-Governance beginnt nahe am Ende des Systems. Eine Richtlinie wird entworfen, ein Risikoregister angelegt, ein Gremium tagt, und eine Checkliste hält fest, was das System tun soll. Jedes dieser Artefakte hat seinen Zweck. Keines beantwortet die Frage, die in der Architektur irgendwann beantwortet werden muss: Welche Eigenschaft des Systems macht die Governance-Aussage wahr?

Eine Richtlinie kann festlegen, dass unsichere Ergebnisse von einem Menschen geprüft werden. Irgendwo im Code entscheidet etwas, was als unsicher gilt, und etwas anderes, ob ein unsicheres Ergebnis trotzdem weitergehen darf. Werden diese Entscheidungen nicht entworfen, gibt es sie trotzdem; sie fallen dann zufällig. Governance wird mehr als Dokumentation, wenn die Architektur sie durchsetzen kann.

Drei Aussagen stehen in fast jedem KI-Governance-Dokument.

"Menschen müssen unsichere Ergebnisse prüfen." Als Richtlinie ist das eine Absicht. Als Architektur braucht es einen Ort, an dem Unsicherheit ausdrücklich abgebildet ist, eine Grenze, die unsichere Ergebnisse nicht überschreiten können, eine bestimmte Person, die entscheidet, und eine Aufzeichnung dieser Entscheidung, die am Ergebnis hängen bleibt. Ohne die Grenze ist Prüfung eine Gefälligkeit, die die Pipeline erweist, wenn sie gerade Zeit hat.

"Die Nachvollziehbarkeit ist sichergestellt." Als Richtlinie heißt das meist, dass es Logs gibt. Als Architektur heißt es, dass das System die Beziehungen bewahrt, die nötig sind, um zu rekonstruieren, wie eine bestimmte Ausgabe entstanden ist: auf welchen Nachweisen sie ruht, welche Schritte sie berührt haben, welche Entscheidungen über sie getroffen wurden und von wem. Logs, die nie dafür entworfen wurden, wieder zusammengeführt zu werden, sind Speicher, keine Nachvollziehbarkeit.

"Das Modell darf X nicht tun." Als Richtlinie ist das eine Bitte an eine probabilistische Komponente. Als Architektur ist es eine deterministische Grenze, die nicht auf die Mitwirkung des Modells angewiesen ist: X ist von dort, wo das Modell sitzt, nicht erreichbar, oder eine Komponente, die X ablehnen kann, prüft darauf. Eine Regel, die sich an ein Modell richtet, ist eine Hoffnung. Eine Grenze um ein Modell herum ist eine Randbedingung.

Eine Aussage in einem Dokument kann über ein System wahr oder falsch sein, und das Dokument verrät nicht, was von beidem zutrifft. Eine Randbedingung in der Architektur lässt sich untersuchen, testen und, wenn sie bricht, bemerken.

COADF, das Compliance-Oriented AI Development Framework, ist ein öffentlich dokumentiertes Entwicklungsframework für KI-Systeme, die Regulierung standhalten müssen. Es ist aus Architekturarbeit im Forschungs- und Entwicklungsprojekt AnyLAI und dessen Produktpass-Demonstration AnyDPP entstanden, doch sein Zweck reicht über ein einzelnes Produkt, eine einzelne Regulierung oder eine einzelne Implementierung hinaus.

Es nennt acht Architekturprinzipien, jedes gebunden an die Pflicht, gegen die es geschrieben wurde, dazu Governance-Vorlagen, darunter eine Autonomieleiter für KI-Agenten, die Produktionscode schreiben, und ein maschinenlesbares Modell für den Bericht darüber, welche Kontrollen ein Projekt tatsächlich ausführt. Sein Gegenstand sind die Grenzen zwischen deterministischer Verarbeitung, probabilistischer KI, Nachweisen, Konfidenz, menschlicher Prüfung, Regeln, Nachvollziehbarkeit, externen Standards und dem, was das System veröffentlicht.

Der Name beschreibt eine Ausrichtung, kein Ergebnis. Die Entwicklungsmethode ist an regulatorischen Anforderungen ausgerichtet; der Name behauptet nie, dass ein damit gebautes System sie erfüllt.

Jedes Prinzip antwortet auf eine bestimmte Weise, in der sich KI-Systeme der Governance entziehen.

P-1 · Zuerst deterministisch, Probabilistisches unter Quarantäne. Alles, was einen Menschen, ein Dokument oder ein anderes System erreicht, ist standardmäßig deterministisch. Eine probabilistische Komponente bleibt auf eine begrenzte Aufgabe beschränkt und liefert einen Wert, eine Konfidenz und die Methode, mit der der Wert gewonnen wurde, nie einen nackten Wert, denn ein nackter Wert lässt sich weder blockieren noch offenlegen noch prüfen.

P-2 · Ausgabe hinter einem Konfidenztor. Konfidenz hängt an einem einzelnen Attribut, nicht an einem ganzen Dokument, denn ein einziger Wert für eine Datei verdeckt, welche Tatsache darin schwach belegt ist. Niedrige Konfidenz erreicht nie eine veröffentlichte Ausgabe. Ohne Nachweis gibt es keinen Wert: keinen Standardwert, keine Schätzung.

P-3 · Menschliche Prüfung durch Architektur. Die Prüfung wird durch Konfidenz ausgelöst, nicht durch einen Zeitplan. Die prüfende Person sieht eine Tatsache neben der Stelle der Quelle, aus der sie stammt, und entscheidet über diese Tatsache; ein abgelehnter Wert lässt das Attribut leer, statt zu einem zweiten Rateversuch einzuladen.

P-4 · Eine Spur, von Anfang bis Ende. Eine Kennung, die beim Eingang eines Dokuments entsteht, begleitet jeden Verarbeitungsschritt, jede Konfidenzbewertung und jede menschliche Entscheidung bis zur veröffentlichten Ausgabe, auf einer Spur, an die nur angehängt wird.

P-5 · Offenlegung maschineller Extraktion. Eine Ausgabe mit maschinell extrahierten Daten sagt das sichtbar, auf der Ausgabe selbst, und nennt die betroffenen Attribute.

P-6 · Das Fence-System. Eine Leitplanke, die in einem Dokument steht, ist ein Ratschlag. Eine Leitplanke, die in der Pipeline läuft und eine Auslieferung stoppt, ist ein Fence.

P-7 · Isolierung von Standardabhängigkeiten. Klassifikationssysteme, Terminologiedatenbanken und externe Validierungsdienste leben in Adaptern außerhalb des Kerndatenmodells. Ein externer Dienst kann Konfidenz erhöhen. Keiner von ihnen kann eine Ausgabe blockieren.

P-8 · Regeln als Daten, mit abgestufter Autonomie. Die Regeln, an denen eine Entscheidung gemessen wird, sind versionierte Daten, die Engine ändert sich nicht, wenn sich eine Regel ändert, und jede Entscheidung ist an die Regelversion gebunden, die sie erzeugt hat. Wie viel das System ohne Menschen tun darf, steht in diesen Regeln und nie über der Obergrenze, die das Recht zieht.

Einzeln betrachtet wirken mehrere davon wie gewöhnliche technische Sorgfalt. Zusammen bilden sie eine Disziplin, in der jedes Prinzip eine Schwäche abdeckt, die die anderen offen ließen. Konfidenz ohne Spur lässt sich nicht auditieren; eine Spur ohne Tor zeichnet getreu Werte auf, die niemand geprüft hat; ein Tor ohne Offenlegung verbirgt, was die Maschine beigetragen hat. Nichts davon übersteht das nächste Refactoring, wenn der Build nicht bemerkt, dass es bricht.

Nichts davon spricht gegen maschinelles Lernen. Probabilistische Komponenten sind wertvoll, wo Deutung nötig ist: beim Lesen eines unstrukturierten Dokuments, beim Erkennen einer Entität in uneinheitlich formatiertem Text, beim Einordnen dessen, was keine Regel vorhergesehen hat. Deterministische Komponenten sind wertvoll, wo Wiederholbarkeit, die Durchsetzung von Grenzen und reproduzierbare Validierung zählen. Der Fehler liegt darin, die Verteilung der Verantwortung zwischen beiden implizit zu lassen.

Für jeden Weg durch das System kann eine Architektur, die die Grenze ernst nimmt, sagen, welche Komponente Schlüsse ziehen darf, welche entscheidet, welche prüft, welche blockieren kann und welcher Zustand oder welche Ausgabe außerhalb sichtbar wird. Stehen diese Antworten im Code statt in einem Diagramm, kann ein Reviewer sie überprüfen, und eine Änderung, die eine Entscheidung über die Grenze verschiebt, fällt im Review auf.

Ein Konfidenzwert beschreibt, wie stark etwas gestützt ist. Er macht nichts wahr. Ein Modell, das sich eines Werts sehr sicher ist, den es aus dem falschen Dokument gelesen hat, hat eine präzise Aussage über das Falsche getroffen.

Die architektonische Folge ist, dass Konfidenz ändern sollte, was das System tun darf, nicht nur, was es anzeigt. In COADF gehört Konfidenz zu einem Attribut und zu dem Nachweis dahinter, und niedrige Konfidenz wird zu einer Frage an einen Menschen statt zu einem veröffentlichten Wert. Das Framework behandelt eine Tatsache außerdem so, dass sie mehrere Lesarten zugleich trägt, etwa ob ihre Quelle echt ist und was sie tatsächlich abdeckt, und lässt diese Lesarten nie zu einer Zahl zusammenfallen. Eine Kennzahl auf einem Dashboard informiert. Eine Kennzahl, die entscheidet, wohin ein Wert gehen darf, steuert.

"Es gibt einen Menschen im Loop" ist die schwächste Form einer Aufsichtsbehauptung, weil sie jede Frage offen lässt, auf die es ankommt. Die KI-Verordnung legt die Anforderung in den Entwurf selbst: Artikel 14 verlangt, dass Hochrisiko-KI-Systeme so konzipiert und entwickelt werden, dass sie während ihrer Verwendung von natürlichen Personen wirksam beaufsichtigt werden können.

Architektonisch muss Aufsicht vier Fragen beantworten. Was löst den Bedarf an einem Menschen aus? Worüber entscheidet diese Person: über einen ganzen Fall oder über eine Tatsache gegen ihre Quelle? Was kann nicht weitergehen, bevor die Entscheidung vorliegt? Und wie wird die Entscheidung, samt der Angabe, wer sie getroffen hat und warum, Teil derselben Spur wie der Wert, um den es geht? Ein Prüfschritt, den die Pipeline unter Last umgehen kann, ist keine Aufsicht. Er ist eine Warteschlange.

Nachvollziehbarkeit wird meist als das Vorhandensein von Logs geprüft. Ein nützlicherer Test ist, ob sich eine einzelne veröffentlichte Ausgabe zurückverfolgen lässt: vom außen sichtbaren Ergebnis zur Entscheidung, die es freigegeben hat, zur Verarbeitung, die es erzeugt hat, zu den Nachweisen, auf denen es ruht. Nachweis, Verarbeitung, Entscheidung, Ergebnis. Muss irgendein Glied dieses Weges durch Raten rekonstruiert werden, ist das System nicht nachvollziehbar, gleich wie viel es aufzeichnet.

Deshalb behandelt COADF die Spur als Architektur und nicht als Betrieb: eine Kennung vom Eingang bis zur Ausgabe, eine Spur, an die angehängt und die nie umgeschrieben wird, und eine Kette, die sich in einer Form exportieren lässt, die jemand lesen kann, der das System nicht gebaut hat. Artikel 12 der KI-Verordnung fasst die Aufzeichnungspflichten ebenso, als etwas, das ein Hochrisiko-System technisch ermöglichen muss.

Eine Governance-Regel, die von nichts geprüft wird, verfällt im Tempo der Codebasis. Manche Regeln können nur Menschen beurteilen. Viele kann der Build prüfen: eine Abhängigkeit, die zwischen zwei Schichten nicht bestehen darf, eine Formulierung, die eine öffentliche Oberfläche nie verwenden darf, eine Auslieferung, die nicht weitergehen darf, solange eine vorgeschriebene Prüfung fehlschlägt. COADF behandelt solche Regeln als Bedingungen, an denen ein Build oder eine Auslieferung scheitern können muss, und ordnet seine Fences nach Daten, Architektur, Text und Prozess.

Ein Fence muss außerdem zeigen, dass er wirkt. COADF nennt die Praxis einen Zahnbeweis: Der echte Fehler wird in die echte Datei eingebaut, der Fence schlägt an, und der Einbau wird zurückgenommen. Ein Fence, den niemand je hat scheitern sehen, ist ein Kommentar mit einem Testrunner daneben. Für Berichte gilt dieselbe Regel: Eine Kontrolle zählt nur dann als erzwungen, wenn ihr Nachweis in einem benannten Lauf lief und erfolgreich war.

Regulierung prägt Anforderungen; sie ist kein Entwurf. Rechtstexte werden geändert, und technische Standards werden in eigenen Zyklen überarbeitet. Nach der Ökodesign-Verordnung für nachhaltige Produkte legen delegierte Rechtsakte, Produktgruppe für Produktgruppe, fest, was ein digitaler Produktpass enthalten muss. Ein semantisches Merkmalslexikon wie ECLASS oder ein Modell für digitale Zwillinge wie die Verwaltungsschale (Asset Administration Shell) folgt seinem eigenen Veröffentlichungsrhythmus.

Ein System, das dieses Vokabular fest in seine Kernlogik schreibt, wird genau dort brüchig, wo sich Regulierung bewegt. COADF hält externe Standards in Adaptern, die Konfidenz beisteuern, aber nicht entscheiden können, und Regeln in versionierten Daten, sodass eine Regeländerung die Engine unberührt lässt und frühere Entscheidungen weiterhin die Regelversion nennen, unter der sie getroffen wurden. Ein Prinzip mit dem Artikel zu verknüpfen, auf den es antwortet, erklärt, warum es das Prinzip gibt. Ob dieser Artikel für ein bestimmtes System gilt, bleibt eine Rechtsfrage.

COADF ist ein öffentlich dokumentiertes Entwicklungsframework. Es ist keine Zertifizierung, kein Prüfstandard und kein Verfahren zur Bewertung der Übereinstimmung mit Rechtsvorschriften. Es ist keine behördliche Genehmigung, keine Garantie für die Einhaltung von Vorschriften und keine Rechtsberatung. Keine Behörde und keine Stelle hat es bewertet, geprüft oder befürwortet. Nichts darin wird von irgendwem erteilt, verliehen oder entzogen, und wer es anwendet, erhält kein Siegel und kein Zeichen.

Architekturarbeit wird nützlicher, wenn sich ihre Annahmen und Grenzen untersuchen lassen. Ein privates Framework lässt sich nur beschreiben; ein veröffentlichtes kann gelesen, verglichen und bestritten werden.

Die Veröffentlichung gibt den Ideen ein stabiles Vokabular, sodass ein Gespräch über Konfidenztore oder Fences nicht damit beginnen muss, die Begriffe neu zu definieren. Sie macht Entwurfsentscheidungen überprüfbar, auch jene, die sich als falsch erweisen könnten. Sie gibt anderen Architektinnen und Architekten etwas Konkretes, dem sie widersprechen können, und Implementierungen einen Bezugspunkt, an dem sie erklären können, wo sie übereinstimmen und wo sie bewusst abweichen. Und sie hinterlässt einen datierten, öffentlichen technischen Nachweis dessen, was wann gesagt wurde.

Ein öffentliches Architektur-Framework muss nicht jeden Umsetzungsmechanismus veröffentlichen. COADF dokumentiert die Prinzipien und Praktiken, die für die öffentliche Prüfung bestimmt sind, während bestimmte umsetzungsspezifische Mechanismen außerhalb der öffentlichen Ausgabe bleiben. Seine Seiten sagen Prinzip für Prinzip, welche Teile vollständig und welche nur als Prinzip dargestellt sind, sodass die Grenze selbst sichtbar ist, auch wo das Detail es nicht ist.

COADF Version 2.2 ist auf Englisch, Deutsch, Spanisch, Französisch und brasilianischem Portugiesisch öffentlich dokumentiert: die acht Prinzipien, die Governance-Vorlagen, der Kontrollbericht und eine an Primärquellen gelesene Regulierungskarte, dazu das ganze Framework als herunterladbare Ausgaben. Die nützlichste Antwort auf ein Architektur-Framework ist keine Zustimmung. Es ist eine genaue Lektüre und ein konkreter Einwand.