Seit dem 02.08.2026 gelten weitere Vorgaben der KI-Verordnung (KI-VO), am 11.09.2026 beginnen die ersten Meldepflichten des Cyber Resilience Act (CRA). Gleichzeitig wurden zentrale Pflichten für Hochrisiko-KI nach hinten verschoben. Der naheliegende Schluss wäre, dass Unternehmen damit auch bei der Governance autonomer KI-Systeme Zeit gewonnen haben. So einfach ist es aber nicht.
Denn für viele intern eingesetzte Agenten ist das Hochrisiko-Regime der KI-Verordnung gar nicht ausschlaggebend. Ein System kann technisch weitreichende Rechte besitzen, ohne deshalb als Hochrisiko-KI eingestuft zu werden. Gleichzeitig können Datenschutzrecht, Informationssicherheitsanforderungen, das Gesetz über das Bundesamt für Sicherheit in der Informationstechnik (BSIG) oder vertragliche Pflichten längst greifen. Das eigentliche Governanceproblem liegt deshalb nicht darin, auf die nächste KI-spezifische Pflicht zu warten. Es liegt im Kontrollgegenstand: Bei klassischer KI kontrollieren Unternehmen Ergebnisse. Bei autonomen Systemen müssen sie Handlungsspielräume kontrollieren.
Ein klassisches KI-System erzeugt einen Vorschlag, den ein Mensch prüft und anschließend umsetzt. Zwischen Ergebnis und Wirkung liegt eine menschliche Entscheidung. Bei einem Agenten kann genau dieser Zwischenraum entfallen: Er greift auf Anwendungen zu, verändert Daten, versendet Nachrichten oder stößt Prozesse selbständig an. Die maßgebliche Frage lautet dann nicht mehr nur: Ist das Ergebnis richtig? Sondern zuerst: Was darf dieses System überhaupt tun?
Das Risiko sitzt in den Berechtigungen
Die Schwelle zu einem anderen Risikoprofil liegt nicht bei der vermeintlichen Intelligenz des Systems, sondern beim Zugriff. Ein Chatbot, der einen Text erzeugt, ist etwas anderes als ein Agent, der einen Datensatz ändert, einen Benutzer anlegt oder eine Zahlung auslöst. Auch die KI-Verordnung kennt den „Agenten“ nicht als eigene Risikokategorie. Ihre Einstufung knüpft insbesondere an die Rolle des Unternehmens und den Verwendungszweck des Systems an. Ein KI-System im Personalmanagement kann deshalb in das Hochrisiko-Regime fallen, obwohl es technisch keine Systeme verändert. Ein Agent, der Rechnungen prüft und weitreichende Schreibrechte im Enterprise-Resource-Planning-System (ERP) besitzt, kann dagegen außerhalb dieses Regimes liegen.
Das ist für die Governance zentral: Regulatorische Risikoklasse und technische Eingriffstiefe sind nicht dasselbe. Eine Freigabe nach der KI-Verordnung beantwortet deshalb nicht automatisch die Frage, welche Rechte ein Agent im Unternehmensnetz erhalten sollte. Dafür braucht es eine zweite Prüfung. Ihr erstes Sortierkriterium ist einfach: Darf das System nur lesen oder auch schreiben? Danach ist zu unterscheiden, welche Aktionen rückgängig gemacht werden können. Zahlungen, Löschungen, Rechtevergaben, die Anlage von Stammdaten oder Kommunikation nach außen haben ein anderes Risikoprofil als die Zusammenfassung eines Dokuments. Für schwer reversible Handlungen braucht es eine zusätzliche Kontrolle.
Ein abstraktes „Human in the Loop“ reicht dafür nicht. Menschliche Kontrolle ist nur dann Kontrolle, wenn der Mensch die Entscheidung tatsächlich ändern kann – mit ausreichender Information, Zeit und Befugnis. Wer nur Ergebnisse sieht, aufgrund des Volumens routinemäßig bestätigt oder für ein tatsächliches „Nein“ keinen Prozess kennt, schafft eine formale Freigabe, aber noch keine wirksame Aufsicht. Eine einfache Kontrollfrage lautet deshalb: Gibt es einen dokumentierten Fall, in dem ein Mensch den Agenten überstimmt hat? Wenn nicht, sollte geprüft werden, ob die vorgesehene Kontrolle tatsächlich funktioniert.
Eine Freigabe ist eine Zustandsaufnahme
Das zweite Problem liegt im klassischen Freigabeprozess. Ein KI-System wird zu einem bestimmten Zeitpunkt geprüft: für einen konkreten Einsatzzweck, eine Modellversion, definierte Datenquellen, bestimmte Werkzeuge und ein festgelegtes Berechtigungsprofil. Einige Monate später kann davon wenig übrig sein. Der Anbieter hat das Modell aktualisiert, der Fachbereich eine weitere Schnittstelle angebunden oder die IT zusätzliche Rechte vergeben. Formal besteht die Freigabe fort. Tatsächlich bezieht sie sich auf ein System, das es in dieser Form nicht mehr gibt.
Governance muss deshalb vom Projektschritt zum Dauerbetrieb werden. Neben turnusmäßigen Prüfungen braucht es Ereignisse, die zwingend eine Neubewertung auslösen: ein wesentlicher Modellwechsel, neue Datenquellen, zusätzliche Werkzeugzugriffe, erweiterte Schreibrechte oder eine Änderung des Einsatzzwecks. Das gilt auch für die technische Identität des Agenten. Er sollte nicht unter einem Sammel- oder Servicekonto mit historisch gewachsenen Rechten arbeiten, sondern einen eigenen Zugang mit genau den Berechtigungen erhalten, die für seinen Zweck erforderlich sind. Und der Prozess endet nicht mit der Abschaltung. Die Zugänge müssen ebenfalls entzogen werden. Ein Agent, der nicht mehr eingesetzt wird, dessen technische Identität aber weiterhin gültig ist, ist nicht vollständig außer Betrieb.
Nicht betroffen heißt nicht risikofrei
KI-VO, NIS-2 (in deutscher Umsetzung: BSIG), CRA und Datenschutz-Grundverordnung (DSGVO) sind keine vier Varianten derselben KI-Regulierung. Die KI-VO fragt, wofür ein System eingesetzt wird und welche Rolle das Unternehmen einnimmt. Das BSIG betrachtet bei den erfassten Einrichtungen die Widerstandsfähigkeit der Organisation und verlangt Risikomanagementmaßnahmen für Incident-Management, Lieferketten und Zugriffskontrolle. Der CRA stellt die Sicherheit von Produkten mit digitalen Elementen in den Mittelpunkt. Die DSGVO knüpft an die Verarbeitung personenbezogener Daten an.
Die jeweiligen Anwendungsbereiche sind deshalb getrennt zu prüfen. Ein extern eingesetzter Agent fällt nicht allein wegen weitreichender Systemrechte unter den CRA. Ein Unternehmen wird durch die Nutzung eines Agenten nicht automatisch vom BSIG erfasst. Und technische Schreibrechte machen ein System nicht für sich genommen zur Hochrisiko-KI. Daraus folgt aber keine regulatorische Lücke im Sinne von „nicht betroffen“. Die rechtliche Verantwortung kann lediglich aus einem anderen Rahmen kommen: etwa aus Datenschutzrecht, Informationssicherheit, Vertrag oder allgemeinen Organisationspflichten.
Daher ist die derzeitige Diskussion um verschobene Hochrisiko-Pflichten der KI-Verordnung für viele Unternehmensagenten missverständlich. Wer auf spätere Anwendungszeitpunkte wartet, wartet möglicherweise auf ein Regime, das für den eigenen Anwendungsfall gar nicht der entscheidende Maßstab ist. Gleichzeitig werden die Überschneidungen im Sicherheitsvorfall konkret. Bei einer Verletzung des Schutzes personenbezogener Daten kann Art. 33 DSGVO eine Meldung innerhalb von 72 Stunden auslösen. Für vom BSIG erfasste Einrichtungen gelten bei erheblichen Sicherheitsvorfällen eigene Meldefristen, die kürzeste sind 24 Stunden. Dieselbe kurze Frist kommt ab dem 11.09.2026 für Hersteller nach dem CRA für aktiv ausgenutzte Schwachstellen und bestimmte schwerwiegende Sicherheitsvorfälle hinzu. Ein Agentenvorfall löst nicht automatisch alle diese Pflichten aus. Ändert ein Agent etwa eigenständig Zahlungsdaten im ERP, kann daraus ein erheblicher Sicherheitsvorfall werden. Art. 33 DSGVO kommt aber nur hinzu, wenn dabei personenbezogene Daten verletzt werden; CRA-Pflichten wiederum nur, wenn ein betroffener Hersteller und ein entsprechendes Produkt mit digitalen Elementen im Spiel sind. Die Tatbestände, Rollen und Adressaten unterscheiden sich. Ein technischer Sachverhalt kann aber mehrere Prüfungen gleichzeitig erforderlich machen. Dafür braucht es keine getrennten Faktenlagen. Es braucht eine belastbare gemeinsame.
Vier Fragen, die jederzeit beantwortbar sein müssen
Für die Governance lässt sich das auf vier Nachweise verdichten:
- Was darf der Agent?
- Was hat er getan?
- Wer hat ihn freigegeben?
- Und wie halte ich ihn an?
Die erste Frage gehört in den Fachbereich. Dort muss eine benannte Rolle Zweck und Handlungsumfang des Use-Case verantworten. Ohne Risikoeigentümer gibt es keine Freigabe. Die zweite Frage verlangt vollständige Protokolle. Wenn ein Agent in kurzer Zeit Tausende Aktionen ausführen kann, muss sich später rekonstruieren lassen, mit welcher Identität er gehandelt hat, auf welche Systeme er zugegriffen hat und welche Aktionen tatsächlich ausgeführt wurden. Ohne diese Nachvollziehbarkeit fehlt im Vorfall nicht nur eine technische Information, sondern die Grundlage für die rechtliche Bewertung.
Legal, Compliance, Datenschutz und Informationssicherheit bilden dabei die zweite Linie. Sinnvoll ist ein gemeinsames Prüfverfahren, nicht vier hintereinandergeschaltete Freigaberunden. Bei den Systemrechten ist zusätzlich Genehmigung von technischer Erteilung zu trennen: Das zuständige Gremium genehmigt das Berechtigungsprofil, die IT setzt es um. Der Datenschutzbeauftragte nimmt eine besondere Rolle ein. Er berät und überwacht; die operative Freigabe sollte nicht bei der Stelle liegen, die diese Entscheidung anschließend kontrollieren soll. Auch die Geschäftsleitung muss nicht jeden Agenten einzeln genehmigen. Ihre Aufgabe liegt eine Ebene höher. Sie legt Risikokategorien, Freigabewege und Eskalationsschwellen fest und überwacht deren Umsetzung. Für Einrichtungen im Anwendungsbereich des BSIG entspricht das der Logik des § 38 BSIG: Die Geschäftsleitung kann operative Aufgaben verteilen, ihre Verantwortung für ein funktionierendes Risikomanagement aber nicht abgeben. Auf ihre Ebene gehören deshalb vor allem Abweichungen von der festgelegten Governance, ungelöste Vetos und Einsätze mit besonders hohem Schadenspotential.
Eine Abschaltmöglichkeit muss funktionieren, nicht nur existieren
Verantwortung endet nicht bei der Freigabe. Sie muss auch für den Fall geklärt sein, dass ein Agent gestoppt werden muss. Ein technisch vorhandener Kill-Switch reicht hier nicht aus. Entscheidend ist, wer die Abschaltung auslösen darf, wer den erforderlichen Zugang besitzt, wie lange der Vorgang dauert und welche bereits angestoßenen Aktionen weiterlaufen. Ebenso muss geklärt sein, welche Geschäftsprozesse nach der Abschaltung stillstehen und wie anschließend in einen kontrollierten Betrieb zurückgekehrt wird. Die Befugnis dafür muss unterhalb der Geschäftsleitung liegen. Ein autonomes System kann in wenigen Minuten mehr Aktionen ausführen, als ein Mensch einzeln prüfen kann. Seine Eindämmung darf deshalb nicht davon abhängen, ob zunächst ein Mitglied der Geschäftsführung erreichbar ist. Zudem muss die Abschaltung geprobt werden. Wer erst im Vorfall herausfindet, dass Zugangsdaten fehlen, ein abhängiger Prozess nicht gestoppt werden kann oder niemand weiß, wie das System wieder sicher in Betrieb genommen wird, hat keine belastbare Notfallkontrolle. Eine Abschaltmöglichkeit, die noch nie ausgelöst wurde, ist zunächst eine Behauptung.
Bestehende Governance muss erweitert, nicht neu erfunden werden
Dafür braucht es keine neue Parallelorganisation für KI. Zugriffsmanagement, Lieferantenprüfung, Protokollierung, Change-Management und Incident-Response sind bekannte Aufgaben. Bestehende Asset- oder Verarbeitungsverzeichnisse können ergänzen, wo KI eingesetzt wird und ob ein System schreibend auf andere Systeme zugreift. Agenten gehören mit eigener technischer Identität in das vorhandene Berechtigungsmanagement. Für schwer reversible Aktionen braucht es einen verbindlichen Katalog menschlicher Freigaben. Änderungen an Zweck, Modell, Werkzeugen oder Rechten müssen eine Neubewertung auslösen. Der Incident-Prozess muss festlegen, wer den Agenten stoppen darf und welche Protokolle im Ernstfall benötigt werden.
Autonome KI schafft damit keine vollständig neue Compliancedisziplin. Sie verändert den Kontrollgegenstand. Bei klassischen Systemen konnte die Kontrolle häufig zwischen Ergebnis und Wirkung stattfinden. Bei autonomen Systemen muss sie früher ansetzen: bei Zweck, Berechtigung und Handlungsgrenze. Wer beurteilen will, ob seine Governance dafür ausreicht, braucht deshalb zunächst keine weitere KI-Policy. Vier Antworten genügen: Was darf der Agent? Was hat er getan? Wer hat ihn freigegeben? Und wer kann ihn stoppen?
