Gartner prognostiziert, dass bis 2026 40 % der Unternehmenssoftwareanwendungen agentische KI enthalten werden. Im Jahr 2025 lag diese Zahl unter 5 %. Die Adoptionskurve ist steil. Die Governance-Kurve ist flach.

Weniger als jedes zehnte Unternehmen verfügt über ein Governance-Framework, das speziell für KI-Agenten entwickelt wurde, laut Gartners Forschung. Die meisten Unternehmen, die Agenten in der Produktion einsetzen, verlassen sich auf allgemeine Richtlinien zur KI-Nutzung, dieselbe Art von Dokumenten, die sie für Chatbot-Funktionen und Empfehlungssysteme erstellt haben. Diese Richtlinien gehen davon aus, dass ein Mensch jede Aktion initiiert und jede Ausgabe überprüft. Agenten durchbrechen diese Annahme. Sie handeln, treffen Kettenentscheidungen und rufen eigenständig externe Dienste auf.

Die Governance von KI-Agenten gehört in Ihre Systemarchitektur. Wenn Sie sie als Compliance-Dokument behandeln, werden Sie sie später zu einem Vielfachen der Kosten nachrüsten müssen.

Warum Governance standardmäßig auf Richtlinien setzt

McKinseys Bericht „State of AI 2025“ ergab, dass 62 % der Unternehmen angeben, dass ihre Organisationen mit KI-Agenten experimentieren. Governance und Risikomanagement hinkten weit hinterher. Das Muster ist bekannt: Die Technik liefert die Funktion, die Rechtsabteilung entwirft eine Richtlinie, und niemand verbindet beides auf Systemebene.

Es gibt praktische Gründe für diese Lücke. Governance wird als nicht-funktional empfunden. Kein Produktmanager erstellt dafür ein Ticket. Der Agent funktioniert in der Staging-Umgebung, besteht die Qualitätssicherung und geht in Produktion. Das Richtlinien-PDF liegt auf einem freigegebenen Laufwerk. 

Das KI-Risikomanagement-Framework des NIST zieht hier eine nützliche Unterscheidung. Seine Funktion „Govern“ (Steuern) umfasst die organisatorische Absicht: Rollen, Verantwortlichkeiten und Risikobereitschaft. Seine Funktion „Manage“ (Verwalten) umfasst die operative Durchsetzung: Überwachung, Incident Response und Laufzeitkontrollen. Die meisten Teams bleiben bei „Govern“ stehen und überspringen „Manage“. Sie definieren, was der Agent tun soll. Sie bauen nicht die Systeme, die einschränken, was er tun kann.

Eine Richtlinie, die besagt, dass der Agent ohne Genehmigung nicht auf Patientenakten zugreifen darf, hat kein Gewicht, wenn das Dienstkonto des Agenten weitreichende Datenbankberechtigungen besitzt. Die Einschränkung muss im System verankert sein, sonst existiert sie nicht.

Wie agentische KI-Governance als Architektur aussieht

Vier Designmuster machen Governance operativ. Jedes ist einer Funktion im KI-RMF des NIST zugeordnet. Keines erfordert ein dediziertes Governance-Team. Sie erfordern technische Entscheidungen während des Systemdesigns.

Entscheidungsgrenzen 

NIST nennt dies „Mensch-KI-Zusammenarbeit“. Sie klassifizieren Agentenaktionen nach Autonomiegrad, bevor Sie Agentencode schreiben. Einige Aktionen führt der Agent eigenständig aus: einen Bericht formatieren, einen Datensatz zusammenfassen. Einiges davon empfiehlt er: eine Transaktion zur Überprüfung markieren, eine Behandlungsanpassung vorschlagen. Manchmal eskaliert er: jede Aktion über einem bestimmten Geldbetrag, jede Entscheidung in einem regulierten Workflow.

Das EU-KI-Gesetz, das im August 2024 in Kraft trat und bis 2026 schrittweise eingeführt wird, erfordert menschliche Aufsichtsmechanismen für Hochrisiko-KI-Systeme. Wenn Sie in europäische Märkte verkaufen, sind diese Grenzen eine gesetzliche Vorschrift. Wenn nicht, sind sie immer noch eine technische Schutzmaßnahme. Ohne sie entdecken Sie den tatsächlichen Entscheidungsspielraum des Agenten erst während eines Vorfalls, nicht während des Designs.

Berechtigungszuweisung 

OWASP hat in seinem Update 2025 „exzessive Handlungsfähigkeit“ zu seinen Top 10 für LLM-Anwendungen hinzugefügt. Das Risiko: ein Agent mit Zugriff auf Tools und Daten, die er für die aktuelle Aufgabe nicht benötigt. Die Lösung ist dasselbe Prinzip, das Sie auf jeden Microservice anwenden. Begrenzen Sie den Datenzugriff und die API-Berechtigungen des Agenten pro Sitzung, pro Aufgabe. Wenn der Agent Kundensupportanfragen bearbeitet, sollte er keinen Schreibzugriff auf Abrechnungsdaten haben. Dies ist das Prinzip der geringsten Privilegien, angewendet auf eine neue Art von Dienst.

Audit-Trail by Design 

Gartners AI TRiSM Framework betont Rückverfolgbarkeit und Erklärbarkeit als operative Anforderungen. Jede Agentenaktion benötigt einen Log-Eintrag, der die Eingabe, die Argumentationskette, die Ausgabe und das Konfidenzsignal erfasst. Diese Logs sollten in der Produktion abfragbar und sowohl für das Debugging als auch für die Compliance-Überprüfung strukturiert sein.

Wenn ein Regulator, ein Kunde oder Ihr eigenes Incident-Response-Team fragt „Warum hat der Agent das getan?“, benötigen Sie innerhalb von Stunden eine Antwort, keine dreiwöchige forensische Rekonstruktion. Teams, die das Audit-Logging zur Bauzeit überspringen, rekonstruieren es am Ende aus Anwendungs-Logs und Datenbank-Snapshots – ein langsamer und unzuverlässiger Prozess.

Human-in-the-Loop-Breakpoints 

Codebridges menschliche Verifizierung unterscheidet zwischen sinnvoller menschlicher Kontrolle und einer reinen Abnicker-Genehmigung. Ein Breakpoint funktioniert nur, wenn der Prüfer genügend Kontext erhält, um in weniger als dreißig Sekunden eine echte Entscheidung zu treffen: die vorgeschlagene Aktion des Agenten, die verwendeten Daten, die berücksichtigten Alternativen. Wenn Sie den Breakpoint als modales Dialogfeld mit einem Ja/Nein-Button und ohne Kontext gestalten, klicken die Prüfer automatisch auf „Ja“. Sie haben dann das Compliance-Häkchen, aber keine tatsächliche Aufsicht.

Entwickeln Sie die Überprüfungsschnittstelle zusammen mit dem Agenten, nicht nachdem der Agent ausgeliefert wurde.

Die Kosten der Nachrüstung

McKinseys Daten zeigen, dass Organisationen mit ausgereifter KI-Governance eine 1,5-mal höhere Wahrscheinlichkeit haben, einen positiven ROI aus KI-Initiativen zu erzielen. Das Gegenteil zeigt Ihnen, was eine Nachrüstung kostet.

Stellen Sie sich ein HealthTech-Produkt vor, das einen Agenten zur Patienten-Triage ohne strukturiertes Audit-Logging ausgeliefert hat. Der Agent funktionierte. Sechs Monate später forderten Regulierungsbehörden Entscheidungsaufzeichnungen an. Das Team verbrachte drei Monate damit, die Ausführungsschicht des Agenten neu aufzubauen, um die Logs zu erstellen, die von Anfang an hätten existieren sollen. Die Feature-Entwicklung wurde eingestellt. Die Compliance-Frist bestimmte die Roadmap.

Ein FinTech-Parallelfall: ein Agent, der Transaktionen mit geringem Wert ohne explizite Entscheidungsgrenzen automatisch genehmigte. Ein False Positive löste eine Compliance-Überprüfung aus. Das Team stellte fest, dass es nicht erklären konnte, welche Transaktionen der Agent genehmigt hatte, auf welcher Grundlage oder wo der Schwellenwert im Code lag. Sie haben den gesamten Workflow neu gestaltet.

Beide Teams hatten Richtlinien. Keines der Teams hatte Systeme, die diese Richtlinien zur Laufzeit durchsetzten. Die Kosten waren Entwicklungszeit, verzögerte Markteinführungen und ein erodiertes Vertrauen bei Kunden und Regulierungsbehörden. Für jedes Unternehmen, das im EU-Markt tätig ist oder regulierte Bereiche wie HealthTech und FinTech ins Visier nimmt, machen die gestaffelten Fristen des EU AI Act dies zu einem zeitlich begrenzten Problem. Sie bauen die Compliance entweder jetzt in die Architektur ein oder pausieren die Feature-Bereitstellung später, um sie hinzuzufügen.

Praktiken zur Steuerung agentischer KI-Systeme: Ein Ausgangspunkt

Bevor Ihr Team eine Agentenfunktion entwickelt, müssen vier Fragen während der Sprintplanung beantwortet werden.

1. Was kann dieser Agent ohne menschliches Eingreifen entscheiden? Definieren Sie die Autonomiestufen und integrieren Sie diese in die Ausführungslogik des Agenten. Überprüfen Sie die Stufen vierteljährlich, wenn der Aufgabenbereich des Agenten erweitert wird.
2. Welchen minimalen Daten- und API-Zugriff benötigt dieser Agent? Legen Sie Berechtigungen pro Aufgabe fest. Behandeln Sie den Agenten in Ihrer Architektur als nicht vertrauenswürdigen Dienst, denn aus Sicherheitssicht ist er genau das.
3. Was protokollieren Sie, und wer kann es abfragen? Entwerfen Sie das Audit-Schema, bevor Sie das Ausgabeformat des Agenten gestalten. Ihre zukünftigen Incident-Responder und Compliance-Prüfer sind die Nutzer dieser Daten.
4. Wo erfolgt eine menschliche Überprüfung, und welchen Kontext benötigt diese? Entwickeln Sie die Überprüfungsoberfläche als erstklassige Komponente, nicht als nachträglich angeflanschten Genehmigungsbildschirm.

Codebridge bietet eine tiefere Struktur für Teams, die dies weiter formalisieren möchten. Doch diese vier Fragen decken den architektonischen Bereich ab, den die meisten Teams übersehen.

Fazit

Die Teams, die Governance von Anfang an als Architektur betrachteten, werden ihre Ingenieurstunden für neue Funktionen aufwenden. Die Teams, die dies aufgeschoben haben, werden diese Stunden damit verbringen, bestehende Systeme unter regulatorischem oder operativem Druck neu aufzubauen. McKinseys 1,5-fache ROI-Lücke zwischen gesteuerten und ungesteuerten KI-Programmen spiegelt diese Divergenz wider.

Die Governance von KI-Agenten ist eine Praxis des Systemdesigns. Sie können sie mit Ihrem bestehenden Team und in der bereits verwendeten Sprint-Kadenz umsetzen. Die Kosten für einen sofortigen Start belaufen sich auf wenige Stunden Planungsaufwand pro Funktion. Die Kosten für einen späteren Start sind Monate der Überarbeitung von Systemen, die bereits in Produktion sind.

Sie benötigen kein Governance-Komitee. Sie benötigen vier beantwortete Fragen pro Agentenfunktion, beginnend mit der, die Ihr Team gerade entwickelt.