Vordenker

Warum AI-Governance immer wieder scheitert

mm
Unite.AI zu deinen bevorzugten Quellen auf Google hinzufügen

Das Problem ist nicht, dass Organisationen keine AI-Richtlinien haben. Es ist vielmehr, dass diese Richtlinien nichts bewirken.

Irgendwo zwischen dem ordentlich formatierten PDF und dem bereitgestellten Modell verflüchtigt sich die Absicht. Teams improvisieren. Ausnahmen häufen sich. Governance entwickelt sich von einem System zu einer Verhandlung – und in regulierten Branchen wie Gesundheitswesen und Lebenswissenschaften ist diese Lücke nicht nur peinlich. Sie ist eine betriebliche Haftung.

Die Lösung ist nicht mehr Dokumentation. Es geht darum, Governance wie Software zu behandeln.

Die Governance-Lücke ist bereits messbar

Die AI-Adoption hat sich dramatisch beschleunigt, während die Governance-Infrastruktur nicht Schritt gehalten hat. Eine Studie von Ernst & Young aus September 2025 fand heraus, dass nur 10% der Unternehmen vollständig auf die Prüfung von AI-Systemen vorbereitet sind. Gleichzeitig fand eine neue Studie von Ponemon heraus, dass 92% der Organisationen sagen, dass generative AI die Art und Weise verändert hat, wie Mitarbeiter auf Informationen zugreifen und sie teilen, aber nur 18% haben vollständig AI-Governance in Insider-Risikoprogramme integriert.

Das Muster ist konsistent: AI ist bereits in der täglichen Arbeit eingebettet. Die Aufsicht holt erst nach. Und je länger die Governance in Dokumentenform bleibt, desto schlimmer wird die Lücke.

Governance, die funktioniert

Das Konzept ist einfach: Wenn eine Governance-Anforderung den Build nicht verfehlen kann, kann sie auch die Produktion nicht schützen.

Echte Governance hat Eingaben, Ausgaben, Enforcement-Punkte und beobachtbare Ergebnisse. Sie läuft kontinuierlich – nicht quartalsweise. Und entscheidend: Sie produziert Beweise als Nebenprodukt der Arbeit, nicht als separates Compliance-Ritual, das danach angehängt wird.

Das Betriebsmodell sieht so aus:

Richtlinie → Kontrollen → Beweise → Metriken

Richtlinien definieren die Absicht. Kontrollen erzwingen das Verhalten. Beweise beweisen die Ausführung. Metriken validieren die Ergebnisse. Dies ist kein neues Konzept – es ist genau so, wie reife Sicherheits- und Compliance-Systeme bereits funktionieren. Der Wechsel besteht darin, die gleiche Logik auf AI anzuwenden.

Kontrollen sind keine Vorschläge. Beweise sind keine Dokumentation. Und wenn eine Kontrolle manuelle Anstrengung erfordert, um Beweise zu produzieren, ist es keine Kontrolle. Es ist eine Hoffnung.

Risikostufen, nicht Risiketheater

Nicht jedes AI-System verdient die gleiche Prüfung. Die Behandlung eines internen Tools mit geringem Risiko mit der gleichen Strenge wie ein klinisches Entscheidungsunterstützungsmodell ist die Art und Weise, wie Organisationen entweder zum Stillstand kommen oder sich unnötigerweise aussetzen.

Das NIST AI-Risikomanagement-Framework, das 2023 veröffentlicht wurde, bietet eine grundlegende Struktur für die Überlegung – die AI-Risiken über vier Funktionen abbilden: Govern, Map, Measure und Manage. Ein funktionaler Unternehmens-Governance-Modell baut auf dieser Logik mit praktischen Risikostufen auf:

Stufe Umfang Kontrollen
Minimal Interne Tools, keine sensiblen Daten Registrierung, leichte Überprüfungen
Begrenzt Benutzerorientiert, moderates Risiko Dokumentation, Überprüfung, Sicherheitstests
Hoch Regulierte oder hochwertige Entscheidungen Formale Risikobewertung, Audit-Protokollierung, strenge Änderungskontrolle
Verboten Unzulässige Anwendungsfälle Bei Design und Bereitstellung blockiert

Was dies den Entwicklerteams gibt, ist etwas, das sie selten von Governance-Prozessen bekommen: Klarheit. Nicht “Was sollen wir tun?”, sondern “Welche Stufe ist dies, und was löst das aus?”

Gute Governance entfernt Zweideutigkeit. Große Governance entfernt Debatten.

Richtlinie-als-Code: Von beratend zu ausführbar

Richtlinien, die in Dokumenten geschrieben sind, sind beratend. Richtlinien, die in Pipelines kodiert sind, sind durchsetzbar.

Genau wie die Infrastruktur vor der Bereitstellung validiert wird, können AI-Systeme durch automatisierte Überprüfungen gesperrt werden, die überprüfen, ob ein Anwendungsfall registriert ist, ob erforderliche Dokumentation vorhanden ist, ob Bewertungsergebnisse definierte Schwellenwerte erreichen und ob der Zugriff auf sensible Daten dem Prinzip der geringsten Privilegien folgt. Diese Überprüfungen laufen in CI/CD. Sie warten nicht auf ein Komitee. Sie sind nicht von jemandes Gedächtnis oder Wohlwollen abhängig.

Open Policy Agent – ein abgeschlossenes Cloud Native Computing Foundation-Projekt – zeigt genau, wie Regeln versioniert, überprüft und konsistent über Engineering-Ökosysteme hinweg durchgesetzt werden können. Das Muster ist verstanden. Die Lücke ist, dass AI-Teams dies nicht anwenden.

Das sicherste AI-System ist nicht das mit den besten Richtlinien. Es ist das, das technisch nicht in der Lage ist, sie zu brechen.

LLM-spezifische Kontrollen: Wo es interessant wird

Generative AI introduceiert eine Kategorie von Risiken, für die traditionelle Governance-Frameworks nicht konzipiert wurden – Prompt-Injektion, Ausgabemanipulation, Tool-Missbrauch. Diese sind keine Randfälle. Sie sind strukturelle Eigenschaften der Funktionsweise von LLMs, und wie Unite.AIs Berichterstattung über agentische AI-Governance festgestellt hat, wird die Governance-Lücke noch deutlicher, wenn AI-Systeme von der Beantwortung von Fragen zu Handlungen übergehen.

Effektive Governance für GenAI-Systeme erfordert Kontrollen, die speziell für LLM-Verhalten konzipiert sind: strikte Trennung von Systemanweisungen und Benutzereingaben, kontrollierter Tool-Zugriff und Allowlists, Ausgabeverifizierung vor der Ausführung, Schutz vor Datenexfiltration und sichere Standardwerte für einen sanften Ausfall.

Diese entsprechen direkt den dokumentierten Schwachstellenklassen im OWASP Top 10 für LLM-Anwendungen – ein community-getriebenes Framework, das nun über 600 Contributing-Experten aus 18 Ländern umfasst. LLM-Governance ist weniger darüber, was das Modell weiß, und mehr darüber, was das System es tun lässt.

Beweise sind Infrastruktur, nicht Papierkram

Prüfer vertrauen nicht auf Absicht. Sie vertrauen auf Aufzeichnungen.

In einem System, in dem Governance funktioniert, werden Beweise automatisch generiert: Modelkarten, die die beabsichtigte Verwendung und Einschränkungen beschreiben, Daten-Dokumentation, die die Herkunft abdeckt, Bewertungsberichte, die Leistung und bekannte Risiken zeigen, Protokolle, die Entscheidungen und Änderungen erfassen. Diese Artefakte existieren nicht für Prüfungen. Sie existieren, weil das System sie benötigt, um zu funktionieren.

Die stärkste Prüfposition ist, wenn Beweise bereits vorliegen, bevor jemand danach fragt. Dies ist nicht theoretisch – Regulierungsbehörden bewegen sich bereits in diese Richtung. Wie jüngste Analysen zu verteidigbarer AI-Governance feststellen, werden die Fragen, die Regulierungsbehörden bald stellen, nicht mehr nur “Haben Sie es aufbewahrt?” sondern “Können Sie beweisen, was passiert ist, unter welcher Richtlinie, mit welchen Daten und mit wessen Autorität?”

Das eigentliche Argument: Governance als Beschleuniger

Der hartnäckige Mythos ist, dass Governance und Geschwindigkeit im Widerspruch zueinander stehen. In der Praxis verlangsamen schlecht konzipierte Governance-Prozesse Teams. Gut konzipierte Governance entfernt Reibung.

Wenn Kontrollen standardisiert sind, Überprüfungen automatisiert sind und Erwartungen kodifiziert sind, hören Teams auf, zu verhandeln, und beginnen zu bauen. Veröffentlichungen werden vorhersehbarer. Entscheidungen erfordern nicht mehr Heldentaten von einer kleinen Gruppe von Spezialisten, die sich an die Richtlinien erinnern.

Governance skaliert, wenn sie Infrastruktur ist. Sie skaliert nicht, wenn sie nur ein Gefühl ist.

Das Ziel war nie Kontrolle um ihrer selbst willen. Es ist Momentum ohne Chaos – und die Organisationen, die dies richtig machen, sind nicht diejenigen mit den ausführlichsten PDF. Sie sind diejenigen, die den richtigen Weg zum einfachsten Pfad gemacht haben.

Sitaram Srivatsavai ist ein Thought Leader im Bereich CRM-Engineering mit 18+ Jahren Erfahrung in CRM, iOS und Web-Plattformen. Er leitet globale Teams, die groß angelegte Unternehmenssoftware liefern, mit Fokus auf Architekturüberprüfungen, Automatisierungsmodernisierung und Sicherstellung von Zuverlässigkeit, regulatorischer Konformität und skalierbarer Leistung.