Photo by Frans van Heerden: https://www.pexels.com/photo/scenic-photo-of-water-dam-during-daytime-2699258/
Eine Frage geht mir seit Wochen im Kopf herum, eine dieser Fragen, die einen um 23 Uhr überfallen, wenn man auf alles zurückblickt, was im Lauf des Tages produziert wurde. Die Frage ist einfach, in der Formulierung fast banal: wie gouvernieren wir, was wir nicht mehr lesen können?
Ich rede nicht abstrakt. Ich rede von dem, was täglich in Organisationen geschieht, die KI-Agenten nutzen. Von Pull Requests, die automatisch erzeugte Änderungen enthalten, von Spezifikationsdokumenten, die mit Claude koautorisiert sind, von Konfigurationen, die von Systemen vorgeschlagen werden, die die Infrastruktur besser verstehen als jene, die sie genehmigen müssen. Von jenem subtilen, fast unmerklichen Gefühl, Dinge abzunicken, die man nur teilweise versteht.
Dass es keine saubere Antwort auf diese Frage gibt, ist schon für sich aussagekräftig. Und dass dieselbe Frage immer öfter gestellt wird, in Aufsichtsräten, Rechtsabteilungen, Compliance-Teams, deutet darauf hin, dass wir einen Wendepunkt überschreiten. Keine graduelle Entwicklung. Einen Wendepunkt.
Die Annahme, die zusammenbricht
Klassische Governance ruht auf einer so eingewachsenen Annahme, dass sie unsichtbar geworden ist: dass genug Zeit besteht zu verstehen, was produziert wurde, bevor es in Produktion geht. Code Review. Dokumenten-Audit. Vertragsfreigabe. Validierung von Analysen. Unterschriften auf Deliverables. All das hat Jahrzehnte funktioniert, weil der Engpass die Produktion war. Die Zeit, etwas zu erschaffen, war lang genug, dass der Validierungsprozess hinterherkam.
Aber wenn ein KI-System in Minuten erzeugt, was Wochen brauchte, bricht diese Annahme. Sie biegt sich nicht, passt sich nicht an: sie bricht. Und das betrifft nicht nur Code. Es betrifft alles.
Wo es bricht, in der Praxis
Ich denke an Vertragsdokumente. Ein KI-Agent kann heute Vertragsentwürfe, spezifische Klauseln, Antworten auf Einwände, vorläufige Stellungnahmen verfassen. Die Qualität ist oft plausibel genug, um ein schnelles Lesen zu bestehen. Aber „plausibel genug“ im juristischen Bereich kann bedeuten: Klauseln, die schützend wirken und es nicht sind, veraltete Gesetzesverweise, sicher vorgetragen, Auslassungen, die erst im Streitfall sichtbar werden. Das Risiko ist nicht der grobe Fehler. Es ist die Subtilität des Fehlers in einem Kontext, in dem Subtilität alles ist.
Ich denke an Finanzanalysen. Dashboards, Prognosen, Szenarienanalysen, Business Cases. Genehmigt ein CFO, der eine KI-generierte oder ko-generierte Analyse erhält, etwas, das er versteht? Oder validiert er die oberflächliche Plausibilität von Zahlen, die einer Logik folgen, die niemand wirklich überprüft hat? Das Problem ist nicht, ob die Zahlen aufgehen. Das Problem ist, ob die zugrunde liegenden Annahmen korrekt sind, ob die angewandten Modelle angemessen sind, ob die Datenquellen verlässlich sind. Alles Dinge, die Domänenkompetenz zur Bewertung verlangen, eine Kompetenz, die der Review-Prozess voraussetzt, die die Produktionsgeschwindigkeit aber immer schwerer anwendbar macht.
Ich denke an externe Kommunikation. Mails an Kundinnen, Antworten auf Ausschreibungen, Produktdokumentation, Handbücher, interne Policies. Jede Organisation produziert täglich tausende Textartefakte. Wenn ein erheblicher Teil davon KI-erzeugt oder -unterstützt ist, wer garantiert die Kohärenz mit der Markenpositionierung? Wer prüft, dass eine Antwort an eine Kundin keine Erwartungen erzeugt, die die Organisation nicht erfüllen kann?
Und dann die Compliance. Hier ist das Paradox am größten. Wir sind mitten in der europäischen Regulierungswelle: AI Act, Cyber Resilience Act, Product Liability Directive, EAA, weiterentwickelnde DSGVO. Organisationen müssen Compliance-Dokumente, Risikobewertungen, Register, Policies produzieren. Die Versuchung, KI zur Beschleunigung dieser Produktion zu nutzen, ist enorm. Aber wir reden von Dokumenten, die Konformität mit Normen bezeugen, die in einigen Fällen genau die KI-Nutzung betreffen. Es liegt etwas Zirkuläres und Verstörendes darin, ein KI-System zu nutzen, um zu erklären, dass die eigenen KI-Systeme den Regeln zur KI entsprechen.
Ein epistemologisches Organisationsproblem
Das Problem ist nicht nur die Geschwindigkeit. Es ist die Kombination aus Volumen und Opazität. Ein Team, das KI für Code, Konfigurationen, Dokumente, Analysen, Kommunikation, Architekturentscheidungen einsetzt, produziert eine Menge an Artefakten, die kein menschlicher Review-Prozess realistisch zu 100 % abdeckt. Wahrscheinlich auch nicht zu 50. Wahrscheinlich auch nicht zu 20, wenn wir ehrlich sind.
Aber das schlimmste Problem liegt anderswo: viele dieser Artefakte sind plausibel genug, um eine oberflächliche Kontrolle zu bestehen. Was fast schlimmer ist, als wenn sie offensichtlich falsch wären. Ein offensichtlicher Fehler wird abgefangen. Ein plausibler Fehler wird genehmigt, deployed, veröffentlicht, unterzeichnet — und erst entdeckt, wenn er Folgen produziert.
Mir wird klar: wir stehen vor dem, was man ein epistemologisches Organisationsproblem nennen könnte: die Organisation weiß weniger über das, was sie produziert. Und die Lücke wächst täglich.
Drei Richtungen, keine erlösend
Ich habe keine endgültigen Lösungen. Niemand hat sie, und wer sie zu haben behauptet, unterschätzt das Problem wahrscheinlich. Aber einige Richtungen scheinen sinnvoll, auch wenn keine erlösend ist.
Die erste ist das, was man den Übergang von punktueller zu struktureller Kontrolle nennen könnte. Wenn du nicht jeden Output kontrollieren kannst, musst du das System kontrollieren, das die Outputs produziert. Das heißt: viel mehr in vorgelagerte Constraints, rigorose Spezifikationen, automatisierte Guardrails, Policy-as-Code investieren — statt in nachgelagerte Reviews. Das ist der Sinn von Spec-driven Development: ist die Spezifikation solide, schrumpft die Fehlerbandbreite des Outputs. Sie verschwindet nicht, aber sie wird eingegrenzt.
Für juristische Dokumente: geprüfte Templates mit klaren Platzhaltern, keine freie Generierung. Für Finanzanalysen: validierte Modelle mit kontrollierten Inputs, keine leeren Blätter. Für Konfigurationen: zertifizierte Baselines mit expliziten, begründeten Variationen. Das Prinzip dahinter ist einfach: Intelligenz — und damit Verantwortung — verlagern in die Problemdefinition, nicht in die Lösungsgenerierung.
Die zweite Richtung betrifft das, was wir verifizieren. Du kannst nicht jeden generierten Code lesen. Nicht jedes Dokument. Nicht jede Analyse. Aber du kannst Invarianten definieren, die einzuhalten sind, und sie automatisiert testen. Für Code: automatisierte Tests, Type Checking, statische Analyse, Sicherheitsprüfungen. Für Dokumente: automatisierte Checklisten, Strukturvalidierung, terminologische Kohärenzprüfung. Für Konfigurationen: Compliance-Policies as Code, Drift Detection, Pre-Deploy-Validierung.
Es ist ein Paradigmenwechsel: vom „ich habe dieses Artefakt gelesen und genehmigt“ zum „dieses Artefakt erfüllt diese überprüfbaren Eigenschaften“. Was wir mit automatisierten Tests in der Software-Welt schon tun. Nur dass es jetzt zur einzigen realistischen Verteidigungslinie für alles wird.
Die Grenze ist offensichtlich: überprüfbare Eigenschaften sind eine Teilmenge der wünschenswerten. Du kannst prüfen, ob ein Vertrag bestimmte Klauseln enthält, nicht ob er strategisch passt. Du kannst prüfen, ob eine Analyse intern kohärent ist, nicht ob die Annahmen stimmen. Aber immer noch viel besser als nichts.
Die dritte Richtung ist vielleicht die unbequemste: KI, die KI kontrolliert. Automatische Reviewer. Spezialisierte Validatoren. Systeme, die den Output anderer Systeme prüfen. Das rekursive Problem ist offensichtlich: wer kontrolliert die Kontrollierenden? Wenn ich dem Output der produzierenden KI nicht vertraue, warum sollte ich der prüfenden vertrauen?
Aber wahrscheinlich unvermeidlich. Und die Frage wird: wie behalten wir Punkte menschlicher Intervention an den Stellen, die wirklich zählen?
Meine Hypothese, noch im Feld zu prüfen, ist, dass die menschliche Rolle sich zu Architekturentscheidungen, ethischen Wahlmomenten, Ausnahmemanagement, Kalibrierung der Kontrollsysteme verlagert. Eine andere Rolle. Weniger operativ, mehr strategisch. Weniger Tun und mehr Festlegen der Regeln des Tuns.
Das organisatorische Risiko
Was beunruhigt mich daran am meisten? Nicht so sehr das technische Risiko. Bugs werden gefunden. Fehler in Dokumenten kommen ans Licht. Falsche Konfigurationen treten zutage. Was mich beunruhigt, ist das organisatorische Risiko: Teams, die sich daran gewöhnen, Outputs zu vertrauen, ohne sie zu verstehen, die langsam die Fähigkeit verlieren zu beurteilen, was sie genehmigen.
Ich sehe es schon. Entwicklerinnen, die generierten Code annehmen, ohne zu lesen. Manager, die Analysen genehmigen, ohne Annahmen zu prüfen. Compliance-Verantwortliche, die Dokumente unterzeichnen, die sie nur überflogen haben. Verständlich, wir stehen alle unter Druck, alle mit mehr zu tun, als wir bewältigen können. Aber auch gefährlich.
Die wichtigste Governance ist vielleicht nicht die über die Systeme, sondern die über die Kompetenzen der Menschen, die sie regieren sollen. Wenn wir die Fähigkeit verlieren zu verstehen, was wir produzieren, verlieren wir die Fähigkeit, es zu regieren. Egal wie viele automatische Kontrollschichten wir dazwischenschieben.
Wer haftet, und wie die Unsicherheit zu navigieren
Eine Frage, die in Italien und in Europa mit dem AI Act besonders dringlich wird: wer haftet? Wenn ein KI-erzeugter Vertrag einen Fehler enthält, der Schaden verursacht, wer antwortet? Die Operatorin, die ihn nutzte? Der Anbieter des KI-Systems? Der Manager, der genehmigt hat? Die Organisation insgesamt? Wenn eine KI-vorgeschlagene Konfiguration eine Sicherheitslücke öffnet, wird die Verantwortungskette plötzlich sehr wichtig.
Der europäische Rechtsrahmen versucht zu antworten. Der AI Act definiert Pflichten für Anbieter und Deployer. Die PLD erweitert die Haftung für fehlerhafte Produkte. Der CRA führt Security-by-Design-Anforderungen ein. Aber die Wahrheit: die Norm läuft der Technik hinterher, und in der Zwischenzeit müssen Organisationen Entscheidungen treffen. Entscheidungen mit rechtlichen Konsequenzen auf Basis von Regeln, die noch nicht ganz klar sind.
Was man tun kann: Traceability bauen. Wissen, welche Artefakte KI-erzeugt oder beeinflusst sind, mit welchen Prompts, unter welchen Bedingungen. Löst das Verantwortungsproblem nicht, erlaubt aber zumindest zu rekonstruieren, was geschehen ist.
Ich schreibe das alles und merke, wie unsicher der Boden ist, auf dem wir uns alle bewegen. Es gibt operative Prinzipien, die sinnvoll wirken: Vermutung struktureller Kontrolle, explizite Invarianten, verpflichtende Traceability, strategische menschliche Intervention, Kompetenz als Voraussetzung, Akzeptanz von Unsicherheit. Aber Prinzipien im Werden, unvollkommen, in Entwicklung, wahrscheinlich dazu bestimmt, von der Geschwindigkeit des Wandels rasch überholt zu werden.
Es liegt auch etwas zutiefst Frustrierendes in dieser Lage. Jahrelang hatten Menschen in diesem Feld die Aufgabe, Lösungen zu finden, Antworten zu geben, einen klaren Plan zu haben. Jetzt navigieren wir ein Terrain, in dem die Fragen klarer sind als die Antworten, in dem jede Lösung neue Probleme öffnet, in dem das Ehrlichste, was man sagen kann, lautet: „ich weiß es nicht, aber ich versuche zu verstehen“.
Vielleicht ist das die neue Rolle dessen, der komplexe Systeme regiert: nicht alle Antworten zu haben, sondern die richtigen Fragen zu stellen und Strukturen zu bauen, die Anpassung erlauben, wenn die Antworten sich ändern. Weniger beruhigend als ein definiertes Framework mit fünf Best Practices und drei strategischen Säulen. Aber die einzige ehrliche Governance, wenn die Welt schneller produziert, als wir verstehen können.
Ich frage mich oft, wo andere mitten in dieser Verwandlung die Spannung am stärksten spüren. An der Produktionsgeschwindigkeit, an der Bewertungsfähigkeit oder an etwas ganz anderem, das ich noch nicht sehe. Denn was mir vielleicht am meisten Sorge macht: nicht zu wissen, was ich nicht sehe.
Was du mitnimmst
Die menschliche Review von allem ist eine stille Annahme, die mit KI-Agenten schlicht zusammenbricht.
Drei operative Schritte: Governance per statistisch signifikantem Sampling, Policy-as-Code für ganze Fehlerklassen, aggressive Observability in der Produktion.
Das ernsteste Risiko ist nicht der grobe Fehler — es ist der plausible Fehler, der eine oberflächliche Review besteht.
PLD und AI Act legen Verantwortung auf Hersteller und Deployer: ohne zugewiesene Rollen gouvernierst du nicht, du hoffst.
Fragen & Antworten
Wie regiert man, was man nicht mehr lesen kann?
Das ist die zentrale Frage der KI-Governance 2026. Automatisch erzeugte Pull Requests, mit Claude koautorisierte Dokumente, von Systemen vorgeschlagene Konfigurationen, die die Infrastruktur besser verstehen als jene, die genehmigen müssen. Klassische Governance setzt Zeit voraus, um zu verstehen, was vor der Produktion entstanden ist — und diese Annahme ist gefallen. Sie biegt sich nicht, sie bricht.
Warum passt sich Governance nicht einfach dem KI-Tempo an?
Weil sie auf einem menschlichen Engpass ruht: dem Lesen. Code Review, Dokumenten-Audit, Vertragsprüfung — alles braucht ein Gehirn, das Zeile für Zeile liest. Wenn ein KI-Agent in Minuten erzeugt, was Wochen dauerte, „beschleunigt“ Review nicht: sie muss neu gedacht werden. Alles lesen ist keine Option mehr.
Was ist die praktische Antwort für CTOs und Justiziarinnen?
Drei Schritte: (1) Governance per intelligentem Sampling — einen statistisch signifikanten Anteil prüfen statt alles; (2) vorgelagerte automatische Constraints (Policy-as-Code, Type Systems, Property Tests), die ganze Fehlerklassen ohne menschliche Lektüre fangen; (3) aggressive Observability in der Produktion, weil das, was du vorab nicht geprüft hast, nachträglich korrigierbar sein muss. Vollständige Ex-ante-Inspektion weicht zeitlich verteilter Verifikation.
Wer haftet, wenn ein KI-Agent irrt?
Die rechtliche Antwort, die kommt (PLD, AI Act): Hersteller oder Deployer. Aber die operative Verantwortung muss entworfen, nicht erst danach entdeckt werden: wer schrieb den Prompt, wer genehmigte das Deployment, wer überwacht den Output in Produktion, wer kann eingreifen, wenn ein Fehler auftaucht. Eine Organisation, die diese Rollen nicht ausdrücklich zuweist, gouverniert nicht — sie hofft.
Der Autor
