Wie viel darf die KI allein entscheiden? Stufen festlegen

1. Die falsche Frage

Irgendwann in jedem Agenten-Projekt fällt der Satz: »Bevor wir das produktiv schalten, müssen wir dem System vertrauen können.« Die Diskussion, die dann folgt, endet selten mit einer Entscheidung. Denn auf die Frage »Können wir dem Agenten vertrauen?« gibt es keine gute Antwort. Sie ist so sinnvoll wie die Frage, ob man einem neuen Mitarbeiter vertraut: Es kommt darauf an, wofür.

Zur Einordnung: Ein KI-Agent ist Software, in der ein Sprachmodell nicht nur Texte liefert, sondern selbstständig Werkzeuge bedient — E-Mails lesen, Datenbanken abfragen, Buchungen anlegen. Diese Handlungsfähigkeit macht die Vertrauensfrage drängend.

Wer die Frage trotzdem mit Ja oder Nein beantwortet, landet in einem von zwei teuren Extremen. Extrem eins: Der Agent darf nichts allein. Jede E-Mail, jede Buchung, jeder Datenbankzugriff wartet auf einen Klick. Das fühlt sich sicher an, macht den Agenten aber zum teuren Formular-Generator, dessen Entlastungseffekt gegen null geht. Extrem zwei: Der Agent darf alles. Das geht gut, bis es nicht mehr gut geht. In einer Befragung des Sicherheitsanbieters SailPoint berichteten 80 Prozent der Unternehmen, dass ihre KI-Agenten bereits unbeabsichtigte Aktionen ausgeführt haben, von unautorisierten Systemzugriffen bis zur Weitergabe sensibler Daten^[1]. Gartner erwartet, dass mehr als 40 Prozent der Agentic-AI-Projekte bis Ende 2027 eingestellt werden — neben Kosten und unklarem Nutzen ausdrücklich wegen unzureichender Risikokontrollen^[2]. Und das Vertrauen der Führungsetagen in vollautonome Agenten fiel laut Capgemini binnen eines Jahres von 43 auf 27 Prozent^[3].

Beide Extreme haben dieselbe Wurzel: Autonomie wird als Schalter behandelt, an oder aus. Die Sicherheitsforschung hat dafür einen Namen. OWASP, ein internationales Fachgremium für Software-Sicherheit, führt übermäßige Handlungsvollmacht (»Excessive Agency«) als eines der zehn größten Risiken von Sprachmodell-Anwendungen und nennt als Kernursache neben überzähligen Werkzeugen und Berechtigungen: übermäßige Autonomie^[4].

Die richtige Frage lautet deshalb nicht, ob Sie Ihrem Agenten vertrauen. Sie lautet: Wie viel darf diese konkrete Deployment-Konfiguration bei dieser Aktion allein entscheiden? Eine Konfiguration verbindet mindestens System und Version, Aktion, Tools und Rechte, zulässige Inputklassen, Betriebsumgebung, Kontrollmechanismen und verfügbare Aufsicht. Derselbe Buchhaltungsprozess kann deshalb mehrere Stufen benötigen: Rechnung lesen mit Nur-Lese-Rechten, Buchung schreiben und Zahlung freigeben sind verschiedene Konfigurationen. Wer sie getrennt einstuft, kann Entscheidungen begründen, dokumentieren und bei Änderungen neu prüfen. Genau diese Skala liefert das nächste Kapitel.

2. Der Regler: fünf Autonomie-Stufen

Beim autonomen Fahren käme niemand auf die Idee, pauschal über »Vertrauen ins Auto« zu diskutieren. SAE J3016 definiert sechs Stufen der Fahrautomatisierung, von Stufe 0 bis Stufe 5^[5]. Die Analogie macht die Verteilung von Entscheidung und Ausführung merkfähig, darf aber nicht mit einer Norm für Unternehmens-Agenten verwechselt werden. Morris et al. operationalisieren AGI-Fortschritt primär über Leistungsbreite, Leistungstiefe und Autonomie^[6]. Ihr Beitrag ist deshalb ein mittelbarer Bezugspunkt, keine Vorlage für die betriebliche Klassifikation. Näher liegt Parasuraman, Sheridan und Wickens: Ihre Automationsstufen trennen Informationsgewinnung, Entscheidung und Ausführung und enthalten auch die Ausführung nach menschlicher Freigabe^[7].

Für KI-Agenten im Unternehmen schlagen wir fünf Stufen vor. Die Zahl fünf ist nicht die Eigenleistung des Papiers. Sie dient als merkfähige Skala; neu kombiniert werden betriebliche Entscheidungsrechte, eine risikobasierte Maximalstufe, technische Durchsetzung und ein evidenzgebundener Auf- und Abstieg. Die engste Vorarbeit von Feng, McDonald und Zhang beschreibt ebenfalls fünf Stufen, dort über die Rollen Operator, Collaborator, Consultant, Approver und Observer^[8]. Das eigene Modell klassifiziert dagegen eine Deployment-Konfiguration und fragt vor allem, wer eine wirksame Aktion entscheiden und ausführen darf.

Eine grobe Zuordnung zu Feng et al. ist möglich, aber nicht eindeutig: Stufe 0 liegt nahe bei deren Operator-Rolle; Stufe 1 hält jede wirksame Aktion unter menschlicher Entscheidung und liegt zwischen Operator und Collaborator; Stufe 2 kann je nach Freigabepolicy mehrere Nutzerrollen berühren; Stufe 3 liegt nahe bei Approver, weil Menschen nur definierte Ausnahmefälle entscheiden; Stufe 4 ähnelt Observer, bleibt hier aber auf einen geschlossenen Policy-Rahmen mit Stopprecht begrenzt. Auf ein Gegenstück zu grenzenloser Autonomie verzichten wir bewusst; dass vollständig autonome Agenten gar nicht entwickelt werden sollten, ist eine in der Literatur ausdrücklich vertretene Gegenposition^[9].

Die Stufe wird anhand derselben Entscheidungs- und Kontrollrechte bestimmt. Bei Widerspruch gilt die niedrigere Stufe. »Unknown«, Policy-Verletzungen und Fälle außerhalb der Inputgrenze führen auf jeder Stufe in einen sicheren Zustand; kein Modell darf die harte Autorisierungsgrenze selbst lockern.

Stufe 2 und 3 unterscheiden sich damit nicht durch ein Bauchgefühl über »Regel« und »Ausnahme«, sondern durch die dokumentierte Freigabepolicy: Auf Stufe 2 enthält sie fachliche Fallklassen, in denen ein Mensch vor Ausführung entscheidet; auf Stufe 3 trifft der Mensch nur Entscheidungen zu Fällen, die die erlaubte Policy nicht abschließend behandeln kann. Stufe 4 beseitigt auch diese fachlichen In-Scope-Ausnahmen. Sie erweitert nicht den Scope.

Die Grenze der Fahranalogie ist wesentlich. Beim Fahren sitzt der Mensch im Fahrzeug und kann in Sekunden übernehmen. Ein Agent arbeitet dagegen asynchron, nachts und in vielen Vorgängen parallel. Die Eskalation hat keinen besetzten Fahrersitz. Deshalb braucht jede Deployment-Konfiguration einen benannten Verantwortlichen, Vertretung, Reaktionszeit, maximalen Backlog und einen sicheren Zustand bis zur Entscheidung. Die veröffentlichte ISO/IEC TS 8200:2024 behandelt die Kontrollierbarkeit automatisierter KI-Systeme^[10]. Für die Praxis folgt daraus: Kontrollübergabe und Stop müssen als Betriebsfähigkeit geplant werden, nicht als spontane Erreichbarkeit einer Einzelperson.

3. Welche Aufgabe auf welche Stufe?

Die Stufe ist keine Geschmacksfrage. Die folgende Matrix ist der verständliche Einstieg, aber nicht das vollständige Risikomodell. Sie liefert eine vorläufige Maximalstufe. Erst die anschließenden Overrides entscheiden, ob diese Stufe für die konkrete Deployment-Konfiguration vertretbar ist.

Frage eins: Wie groß ist der plausible Schaden?

Bewertet werden zwei Perspektiven getrennt: der Schaden für die Organisation (Geld, Betrieb, Reputation, Recht) und der Schaden für betroffene Personen oder Gruppen (materielle Nachteile, Diskriminierung, Privatsphäre, Gesundheit, Sicherheit und Grundrechte). Der höhere Wert bestimmt die Zeile der Matrix. Ein Bewerber-Ranking kann für das Unternehmen billig zu korrigieren und für die betroffene Person trotzdem folgenreich sein.

Frage zwei: Wie gut lässt sich der Schaden wiederherstellen?

Umkehrbarkeit ist kein reines Ja/Nein-Merkmal. Zu dokumentieren sind Zeit, Kosten, Sichtbarkeit, notwendige Zustimmung Dritter und fortbestehende Folgeschäden. Ein Buchungssatz kann technisch stornierbar sein, während eine versendete Nachricht, ein verpasster Anspruch oder eine offengelegte Information nicht vollständig zurückgeholt werden kann. Für die Matrix gilt »umkehrbar« nur, wenn die Wiederherstellung rechtzeitig, verlässlich und ohne wesentliche Restschäden möglich ist.

Aus beiden Fragen entsteht eine Ersttriage mit vier Feldern. Die Spanne ist bewusst konservativ: Sie ist kein automatisches Freigabeurteil, sondern der Ausgangspunkt für die Override-Prüfung.

Nach der Matrix folgt eine verbindliche Override-Prüfung. NIST verlangt, Wahrscheinlichkeit und Ausmaß positiver wie negativer Auswirkungen zu dokumentieren^[11]. Für jede Konfiguration werden deshalb mindestens diese Fragen beantwortet:

Das Ergebnis wird in einem Stufenregister festgehalten. Eine Zeile bezeichnet genau eine Deployment-Konfiguration, nicht nur eine Aufgabe. Pflichtfelder sind System- und Modellversion, Prompt-, Policy- und Toolset-Version, konkrete Aktion, Tools und Rechte, Inputquellen und -grenzen, Betriebsumgebung, Kontrollen, Owner, Datum, Override-Ergebnis und Stufe. Erhält dieselbe Aufgabe andere Rechte oder Inputs, entsteht eine neue Zeile.

Der Zahllauf zeigt die konservative Policy des Modellunternehmens: hoher plausibler Schaden, geringe Wiederherstellbarkeit und externe Wirkung führen zu Stufe 1. Im Beispiel darf der Agent die Zahlungsdatei vorbereiten, aber keine Zahlung freigeben oder senden. Ob eine Bank Doppelfreigaben, Betragslimits oder andere Vollmachtsregeln erzwingt, hängt von Produkt, Zahlungsart, Vertrag und internen Kontrollen ab. Diese Anforderungen sind je Unternehmen zu prüfen; sie sind keine allgemeine Begründung für die Stufe.

Woher das Register kommt: In einem 90-minütigen Erstworkshop werden die Konfigurationen und Overrides zeilenweise geprüft. Mindestrollen sind Process Owner, IT/Engineering, Informationssicherheit, Datenschutz/Legal und interne Kontrolle oder Revision. Bei Beschäftigtenbezug gehört die Beschäftigtenvertretung dazu; bei Außenwirkung muss eine Kunden- oder Betroffenenperspektive vertreten sein. Nicht jede Rolle muss in jeder Sitzung anwesend sein, aber jede Auslassung wird mit Verantwortlichem und Nachholtermin dokumentiert. Ein »erklärter Skeptiker« kann ergänzen, ersetzt diese Funktionen aber nicht.

Die Logik trägt über die Buchhaltung hinaus, wenn die Deployment-Konfiguration statt eines abstrakten Aufgabennamens betrachtet wird. Ein Vertriebs-Agent kann einen internen Angebotsentwurf mit Nur-Lese- und Entwurfsrechten auf Stufe 3 bearbeiten, während derselbe Workflow mit Versandrecht und verbindlicher Preiszusage auf Stufe 1 oder 2 fällt. Ein IT-Agent kann ein Testsystem innerhalb einer geschlossenen Sandbox automatisiert neu starten; das Löschen produktiver Nutzerkonten bleibt wegen Rechteumfang, Folgeschaden und Recovery auf einer niedrigeren Stufe. Die Stufe gehört damit weder dem Agenten noch der Aufgabe allein. Sie gehört der dokumentierten Kombination aus System, Aktion, Rechten, Inputs, Umgebung und Kontrollen. Für Ketten aus mehreren Agenten kommen Koordinationsregeln hinzu, die dieses Whitepaper nicht abdeckt.

Die Stufe muss durchgesetzt werden

Eine Stufe im Prompt ist keine Kontrolle. Rechte im Zielsystem, Service-Identitäten, Whitelists, Betrags- und Mengenlimits sowie ein externer Stop setzen sie technisch durch^[4]. Der Stufenregister-Eintrag enthält deshalb auch die Versionsstände. Änderungen an Modell, Prompt, Toolset, Rechten, Policy, Datenquellen, Inputklassen, Betriebsumgebung, Kontrolllogik oder verfügbarer Aufsicht lösen eine Re-Einstufung aus. Fremder Input, im Beispiel jede eingehende Rechnung, bleibt ein eigener Angriffsweg; Bewährung im Normalbetrieb beweist keine Angriffsfestigkeit.

4. Freigabe-Design: Vier Augen, neu gedacht

Mit der Stufe steht das Was. Das Wie entscheidet über Erfolg oder Frust: Freigaben müssen so gebaut sein, dass sie schützen, ohne zu lähmen.

Freigabepunkte, Schwellen und Kapazität

Eine Freigabe sitzt unmittelbar vor der wirksamen Aktion. Ihre Policy verwendet messbare Kriterien wie Betrag, neuer Empfänger, Datenabweichung oder Inputklasse. Agenten-Frameworks bieten dafür technische Unterbrechungen und funktionsbezogene Genehmigungen^[12], ^[13]. Ein Mengen-Limit begrenzt Serienschäden. Ebenso wichtig ist die Aufsichtskapazität: Jede Eskalationsklasse braucht Owner, Vertretung, Priorität, Reaktionszeit und maximalen Backlog. Wird das Limit überschritten oder fehlt die Vertretung, degradiert die Konfiguration automatisch auf eine niedrigere Stufe oder pausiert in einem sicheren Zustand. Im Beispiel landen Buchhaltungseskalationen beim Teamleiter mit benannter Vertretung; nach vier Arbeitsstunden oder ab zehn offenen Hochprioritätsfällen stoppt die automatische Ausführung. Reaktions- und Backlog-Kennzahlen dienen der Prozesssteuerung, nicht dem individuellen Performance-Ranking. Rollenbasierte Zugriffe, Auswertungszweck, Löschfristen und Beteiligungsrechte werden vor Produktivsetzung festgelegt.

Kontrollkette statt künstliches Vier-Augen-Paar

Die erste Instanz sind deterministische Regeln: Dreier-Abgleich, Empfänger gegen Stammdaten, Betrag gegen Policy, Dateiformat und Rechteprüfung. Ein Prüfmodell darf nur dort ergänzen, wo semantische Beurteilung nötig ist. Seine Unabhängigkeit ist funktional zu belegen: getrennte technische Identität und Rechte, getrennte Instruktionen, möglichst unabhängige Evidenzquellen, sanitizierte Inputs und ein eigener Protokollpfad. Ein anderes Grundmodell kann korrelierte Fehler reduzieren, beweist diese Trennung aber nicht. Das Prüfmodell darf weder eine harte Autorisierungsgrenze lockern noch seine eigene Evidenz erzeugen. Zufalls- und Risikostichproben aus durchgewinkten Fällen prüfen schließlich die gesamte Kette.

Meldet die Kontrollkette zu viele Fehlalarme, stumpfen Empfänger ab; dieses Muster ist seit den Neunzigern dokumentiert^[14]. Nur echte Abweichungen sollen den Menschen erreichen. OWASP empfiehlt für Aktionen mit großer Wirkung menschliche Freigabe und Autorisierung in den nachgelagerten Systemen^[4]. Wo Gesetz, Vertrag, Bankprodukt oder interne Policy zwei natürliche Personen verlangen, ersetzt weder Regelwerk noch Prüfmodell eine von ihnen. Im Zahlungsbeispiel ist die Doppelautorisierung eine konservative Unternehmenspolicy, bis die konkreten bank- und vollmachtsrechtlichen Anforderungen geprüft sind. Die maschinelle Kontrolle ergänzt die Menschen, sie zählt nicht als zweites menschliches Auge.

Das Anti-Pattern: Freigabe-Ermüdung

Warum dieser Aufwand um das Wort »wirklich«? Weil die naheliegende Lösung, einfach alles freigeben zu lassen, nachweislich nicht funktioniert. In unserem Beispiel läuft der Agent zunächst auf Stufe 1, alles wird freigegeben. Nach einigen Wochen winkt der Buchhalter über 40 Freigaben am Tag durch, und eine Fehlbuchung passiert trotz Vier-Augen-Prinzip. (Die Zahlen des Beispiels sind eine Modellrechnung.) Das ist keine Charakterschwäche, sondern ein seit Jahrzehnten dokumentiertes Phänomen: Automation Bias, die Neigung, automatischen Systemen auch dann zu folgen, wenn sie irren. Ein systematisches Review mit 74 eingeschlossenen Studien dokumentiert Automation Bias einschließlich sogenannter negative consultations, bei denen korrekte Vorentscheidungen nach falscher Systemberatung revidiert werden; Arbeitslast, Aufgabenkomplexität und Zeitdruck werden als Einflussfaktoren berichtet^[15]. Forscher um Sterz haben zudem präzisiert, wann menschliche Aufsicht überhaupt wirksam ist: Die Person braucht echte Eingriffsmacht über das System, Zugang zu den relevanten Informationen, Selbstkontrolle und eine zur Aufsichtsrolle passende Haltung^[16]. Fehlt eines davon, ist die Freigabe eine Unterschrift, keine Kontrolle.

Die Konsequenz ist kontraintuitiv: Die Fehlbuchung im Beispiel führt nicht zu mehr Kontrolle, sondern zur richtigen. Kleinbeträge mit sauberem Abgleich wandern auf die Schwellenfreigabe der Stufe 2 und nach Bewährung auf Stufe 3; der Buchhalter sieht statt 40 Routinefreigaben nur noch die echten Ausnahmen. Anthropic berichtet aus der Telemetrie seines Coding-Agenten ein passendes Muster: Erfahrene Nutzer genehmigen seltener jede Einzelaktion und greifen dafür gezielter ein^[17]. Die Beobachtung stammt allerdings von einem Anbieter, und in Nutzungsdaten sieht nachlassende Wachsamkeit genauso aus wie gereiftes Vertrauen. Aktuelle Forschung mahnt zur Demut: Besser gestaltete Kontrolloberflächen erhöhten in Tests die Zuversicht der Prüfenden in ihr Urteil, ihre tatsächliche Fehlererkennung aber kaum^[18]. Gefühlte Kontrolle ist nicht wirksame Kontrolle — ob die Aufmerksamkeit ankommt, misst die Stichprobe, nicht das Bauchgefühl. Als Designprinzip gilt: Gutes Freigabe-Design minimiert nicht das Risiko pro Freigabe. Es maximiert die Aufmerksamkeit pro Freigabe.

5. Der Regler bewegt sich: Auf- und Abstieg

Eine Stufe ist keine Ehrenurkunde, die man einmal verleiht. Sie ist eine Betriebsgröße wie ein Budget: regelmäßig überprüft, begründet verändert, in beide Richtungen.

Aufstieg nach Bewährung

Der Agent startet eine Stufe unter der nach Triage und Overrides zulässigen Maximalstufe. Vor Beginn des Beobachtungsfensters legt der Owner je Risikoklasse Fehlerdefinitionen, Nenner, Stichprobenverfahren, Mindestfallzahl, Grenzwerte und Stop-Regeln fest. Eine universelle Zwei-Prozent-Grenze gibt es nicht; der bisherige Wert bleibt höchstens eine illustrative Modellannahme.

Die Stichprobe wird aus den freigegebenen und durchgewinkten Fällen gezogen, nach Risikoklasse und Inputquelle geschichtet und für seltene Hochrisikofälle gezielt verdichtet. Fallzahl und Beobachtungsdauer werden aus Schadensschwere, erwarteter Basisrate und akzeptierter Unsicherheit abgeleitet und vorab dokumentiert. Erst wenn alle vorab festgelegten Kriterien erfüllt sind, darf der Owner die Hochstufung begründen. Herstellerpraxis, nachgewiesene Zuverlässigkeit schrittweise in mehr Autonomie zu übersetzen, ist ein nützlicher Erfahrungswert^[19], ersetzt diesen Nachweis aber nicht.

Abstieg und Reset ohne Drama

Ein Critical Incident, das Überschreiten eines vorab festgelegten Grenzwerts, wiederholte Near Misses, ein Kontroll-Backlog über Limit oder eine materielle Konfigurationsänderung lösen automatisch Rückstufung oder Pause aus. Als materielle Änderungen gelten mindestens Modell, Prompt, Tools, Rechte, Policy, Datenquelle, Inputklasse, Betriebsumgebung, Kontrolllogik und Aufsichtskapazität. Danach beginnt der Bewährungsnachweis für die betroffene Risikoklasse neu; nur bei nachweislich lokal begrenzten Änderungen darf der Owner einen Teilreset begründen. Im Beispiel führt ein Modell-Update sofort zurück auf Stufe 2, nicht erst der spätere Kennzahlenanstieg. Jemand muss Kennzahlen und Änderungen prüfen, den Reset dokumentieren und den Regler bedienen.

Zur Ehrlichkeit gehört die Aufwandsseite. Die Einstufung ist ein Workshop, die Freigabe-Gates sind in den gängigen Frameworks Konfigurationsarbeit von Tagen. Der laufende Betrieb — Stichproben, Kennzahlen, ein monatlicher Review — kostet je Agent eher Stunden pro Monat als Stellen, aber er kostet sie dauerhaft, und der Weg von Stufe 1 zu Stufe 3 ist realistisch ein halbes Jahr. Der Nutzen trägt das: Im Beispiel spart der Agent je Rechnung zweistellige Minuten Bearbeitungszeit, dazu kommt pünktlich gezogenes Skonto (Modellrechnung).

Zwei Governance-Fragen werden vor der ersten Messung geklärt. Erstens die Beschäftigtenvertretung: Reaktionszeit und Eskalationsdaten können Verhalten oder Leistung sichtbar machen. Zweckbindung auf Prozesssteuerung, rollenbasierte oder aggregierte Auswertung, Zugriff, Löschfrist und Mitbestimmung werden deshalb vor Produktivsetzung festgelegt (§ 87 Abs. 1 Nr. 6 BetrVG)^[20]. Zweitens die Verfahrensdokumentation: Die GoBD verlangt, dass automatische Buchungsvorgänge anhand der Dokumentation und ihrer Anwendung nachvollziehbar sind^[21]. Das Stufenregister mit Konfiguration, Begründung, Owner und Datum ist eine Empfehlung dieses Whitepapers, nicht wörtlich vorgeschriebener »Kern« der GoBD-Dokumentation.

So endet das Modellbeispiel: Nach einem Jahr bearbeitet der Agent rund 70 Prozent der Rechnungen mit Bestellbezug ohne fallweise menschliche Freigabe (Modellrechnung). Zahlungen bleiben dennoch auf Stufe 1, weil die Beispielpolicy jede Freigabe natürlichen Personen vorbehält. Ob jede Einzelzahlung, ein Lauf oder eine Schwelle doppelt autorisiert werden muss, ist mit Bankprodukt, Vollmachten und internen Kontrollen abzugleichen. Mehr Autonomie und mehr Kontrolle können zusammenfallen, wenn der Scope eng, Rechte minimal und Ausnahmen belastbar besetzt sind.

6. Was der AI Act verlangt

Der AI Act verteilt Verantwortung auf verschiedene Akteure. Artikel 14 verpflichtet Anbieter von Hochrisiko-KI-Systemen, wirksame menschliche Aufsicht durch Design, Schnittstellen und festgelegte Maßnahmen zu ermöglichen. Artikel 26 verpflichtet Betreiber unter anderem, diese Aufsicht geeigneten natürlichen Personen mit Kompetenz, Training, Befugnis und Unterstützung zuzuweisen und den Betrieb zu überwachen^[22]. Das Stufenmodell ist deshalb weder reine Anbieter- noch reine Betreibermaßnahme. Es kann Anforderungen strukturieren, wenn Anbieterfunktionen und betriebliche Umsetzung getrennt nachgewiesen werden.

Artikel 14 und 26 sind für Hochrisiko-KI-Systeme verbindlich. Die meisten Buchhaltungs-Agenten im Mittelstand fallen nicht allein wegen ihrer Agentenform in diese Kategorie; Anwendungen etwa in Beschäftigung oder Kreditwürdigkeitsprüfung können jedoch unter Anhang III fallen^[22]. Der Rat nahm die Digital-Omnibus-Verordnung zur KI am 29.06.2026 an. Seine amtliche Mitteilung nennt als neue Anwendungstermine den 02.12.2027 für eigenständige und den 02.08.2028 für produktintegrierte Hochrisiko-Systeme; zugleich kündigt sie die Veröffentlichung im Amtsblatt an^[23]. Stand 17.07.2026 wird deshalb die Ratsannahme zitiert und die endgültige Amtsblattfundstelle vor Veröffentlichung des Whitepapers nachgezogen.

Artikel 4 verpflichtet Anbieter und Betreiber bereits seit Februar 2025 zu Maßnahmen für ausreichende KI-Kompetenz. Artikel 50 Abs. 1 richtet die Informationspflicht bei direkter Interaktion grundsätzlich an den Anbieter des interaktiven Systems. Sie entfällt, wenn die KI-Interaktion für eine angemessen informierte, aufmerksame und verständige Person unter den Umständen offensichtlich ist^[22]. Ein einsetzendes Unternehmen muss deshalb für die konkrete Anwendung prüfen, ob es selbst Anbieter ist und welche Betreiber-, Vertrags- oder Sektorpflichten daneben bestehen; der Betrieb unter eigenem Namen beantwortet diese Rollenfrage nicht automatisch.

Normativ ergänzt die bereits veröffentlichte ISO/IEC TS 8200:2024 zur Kontrollierbarkeit automatisierter KI-Systeme^[10] den kommenden, ausdrücklich auf Human Oversight fokussierten ISO/IEC-Leitfaden 42105. ISO/IEC 42105 befindet sich am 17.07.2026 als FDIS in Stufe 50.00 und ist noch nicht veröffentlicht^[24].

Ein Stufenregister, technische Freigaben, Kennzahlen und Protokolle unterstützen damit ausgewählte Kernbausteine wirksamer Aufsicht. Sie decken Art. 14 oder 26 nicht vollständig ab. Insbesondere systemspezifische Grenzen, Interpretationshilfen, Training, Datenqualität, Incident-Meldungen, Ressourcen und formale Konformitätsprüfungen liegen ganz oder teilweise außerhalb des Modells. Das Whitepaper bietet eine Governance-Heuristik, keine Rechtsauslegung für den Einzelfall.

Fazit: Drei Sätze zum Behalten

Erstens: Autonomie ist ein Regler, kein Schalter. Eingestuft wird die konkrete Deployment-Konfiguration aus System, Aktion, Rechten, Inputs, Umgebung und Kontrollen. Zweitens: Schadenshöhe und Wiederherstellbarkeit liefern nur die Ersttriage; Wahrscheinlichkeit, Betroffene und Grundrechte, Erkennbarkeit, Volumen, Angriffsexposition, Aufsichtskapazität und gesetzliche Mindestkontrollen können die Maximalstufe senken. Drittens: Freigaben sind knappes Gut. Technische Veto-Rechte, echte Ausnahmen, risikogeschichtete Stichproben und vorab definierte Reset-Regeln lenken Aufmerksamkeit dorthin, wo sie wirkt.

Der Einstieg bleibt überschaubar: Deployment-Konfigurationen erfassen, Matrix und Overrides durchlaufen, Rechte- und Kontrollmatrix dokumentieren und eine Stufe unter der zulässigen Maximalstufe starten. Ein halbtägiger Autonomie-Check kann dafür die erste Arbeitsfassung liefern. Das Ergebnis ist keine fertige Betriebsvereinbarung oder Konformitätsakte, sondern ein prüfbares Stufenregister samt offenen Evidenz-, Rechts- und Umsetzungsfragen.

Quellen