30. September 2026 · KI · Automatisierung · Regulatorik · Mittelstand

Die Freigabe, die niemand sieht

Eine Freigabe kann wie geplant funktionieren und trotzdem lange unbemerkt warten. Warum Wartezustände bei Automatisierung und KI-Agenten überwacht gehören.

Wer Automatisierungen oder KI-Agenten Aufgaben übertragen lässt, baut an kritischen Stellen einen Menschen ein: Bevor eine Änderung produktiv wird, Daten das Haus verlassen oder etwas nicht mehr rückgängig zu machen ist, muss jemand zustimmen. Das Prinzip ist richtig, und Regelwerke greifen es auf. Über eine Eigenschaft solcher Freigaben wird dabei selten gesprochen: Sie sind unsichtbar, solange niemand hinsieht.

Ein typisches Szenario

Angenommen, ein automatisierter Ablauf – ein Datenabgleich, ein Software-Rollout, eine Berechtigungsänderung – erreicht Schritte, die eine menschliche Freigabe brauchen. Sie warten über viele Stunden, unbemerkt. Nichts ist kaputt. Das Freigabetor funktioniert genau so, wie es gebaut ist: Es hält an und wartet. Es versagt allein seine Sichtbarkeit.

Der Grund ist strukturell. Ein Prozess, der blockierend auf eine Freigabe wartet, meldet sich in der Regel nicht selbst – er ist ja blockiert. Von außen sieht ein wartender Prozess aus wie ein ruhiger: keine Fehlermeldung, kein Alarm, keine Ausgabe. Wer nicht gezielt nachsieht, hält die Stille für Normalbetrieb oder für einen Arbeitsschritt, der eben noch läuft. Und wer die Freigabe erteilen müsste, weiß unter Umständen nicht einmal, dass sie ansteht – die Anfrage liegt in einer Oberfläche, die gerade niemand geöffnet hat.

Sichtbar werden solche Wartezeiten typischerweise erst im Nachhinein, wenn jemand die Zeitstempel der Protokolle auswertet. Daraus folgt ein Zweites: Ohne diese Zeitstempel bliebe nicht einmal die Größenordnung bekannt – nur der vage Eindruck, dass es „diesmal etwas länger gedauert“ hat.

Was Regelwerke unter menschlicher Aufsicht verstehen

Die europäische KI-Verordnung (Verordnung (EU) 2024/1689) regelt in Artikel 14 die menschliche Aufsicht über Hochrisiko-KI-Systeme. Diese sollen so gestaltet sein, dass natürliche Personen sie während ihrer Nutzung wirksam beaufsichtigen können. Absatz 4 zählt auf, wozu die beaufsichtigenden Personen befähigt sein sollen. Dazu gehört, den Betrieb zu überwachen, um Anomalien, Fehlfunktionen und unerwartete Leistung zu erkennen, ebenso, „sich einer möglichen Neigung zu einem automatischen oder übermäßigen Vertrauen in die von einem Hochrisiko-KI-System hervorgebrachte Ausgabe (‚Automatisierungsbias‘) bewusst zu bleiben“, die Ausgabe außer Acht zu lassen, außer Kraft zu setzen oder rückgängig zu machen und „in den Betrieb des Hochrisiko-KI-Systems einzugreifen oder den Systembetrieb mit einer ‚Stopptaste‘ oder einem ähnlichen Verfahren zu unterbrechen“.

Ob ein konkretes System unter diese Vorschrift fällt, ist eine Frage der Einstufung im Einzelfall. Als Maßstab taugt der Gedanke auch dort, wo die Verordnung nicht greift.

Das NIST AI Risk Management Framework (AI RMF 1.0, Januar 2023) formuliert es als Organisationsaufgabe: Prozesse für menschliche Aufsicht sollen definiert, bewertet und dokumentiert sein (MAP 3.5), Rollen und Verantwortlichkeiten für das Zusammenspiel von Mensch und KI klar abgegrenzt (GOVERN 3.2). Das Framework hält zudem fest, dass es nützlich sein kann, Daten darüber zu erheben, wie oft und aus welchen Gründen Menschen die Ausgaben eingesetzter KI-Systeme überstimmen.

Beide Texte setzen voraus, dass der Mensch da ist, wenn er gebraucht wird. Wie er rechtzeitig davon erfährt, ist Sache der Umsetzung – und genau dort liegt die Lücke aus dem Szenario.

Warten ist ein Zustand, der überwacht werden muss

Aus dem Szenario lassen sich vier Regeln ableiten. Sie gelten für Skripte, Pipelines und Workflow-Werkzeuge ebenso wie für KI-Agenten – und umso mehr, je selbstständiger ein Ablauf arbeitet, denn desto seltener schaut jemand zu.

„Wartet auf Freigabe“ wird ein eigener, überwachter Zustand. Mit dem Zeitpunkt, zu dem die Anfrage gestellt wurde, einem vereinbarten Schwellenwert und einem Alarm, wenn er überschritten ist. Der Alarm geht an eine benannte Stelle mit Vertretung, nicht an ein Postfach, das niemand liest. Weil sich ein blockierend wartender Prozess in der Regel nicht selbst meldet, muss ein anderer den Zustand abfragen – die Überwachung kommt von außen. Der Schwellenwert richtet sich danach, was hinter dem Schritt wartet: Eine nächtliche Routineaufgabe verträgt Stunden, eine Änderung, auf die ein Team wartet, nicht.

Freigabepflichtige Schritte werden angekündigt, bevor sie ausgelöst werden. Wer weiß, dass in wenigen Minuten eine Zustimmung fällig wird, sieht hin. Eine kurze Nachricht an die freigebende Person kostet nichts – und sie ist die letzte Meldung, die der Prozess noch selbst absetzen kann, bevor er blockiert.

Der freigabepflichtige Schritt kommt ans Ende. Steht er mitten im Ablauf, wartet alles mit, was danach kommt – auch Arbeit, die gar keine Freigabe braucht. Am Ende blockiert er nur sich selbst. Wo das nicht geht, sollten unabhängige Schritte vorher erledigt oder parallel weitergeführt werden.

Wartezeiten werden gemessen, nicht geschätzt. Beginn der Anfrage und Zeitpunkt der Entscheidung stehen in den Protokollen; die Differenz ist eine Kennzahl, die sich auswerten lässt. Das deckt sich mit dem Hinweis des NIST-Frameworks, Daten über menschliche Eingriffe zu sammeln: Wer nicht misst, wie Aufsicht tatsächlich stattfindet, weiß nicht, ob sie stattfindet.

Zu viele Freigaben sind auch keine Aufsicht

Die naheliegende Reaktion auf eine übersehene Freigabe wäre, mehr Kontrolle einzubauen. Das verschiebt das Problem nur. Wer zehnmal am Tag bestätigen muss, bestätigt irgendwann, ohne hinzusehen. Die Freigabe wird zur Formalie, und die Aufsicht existiert nur noch auf dem Papier – das ist die Form von Automatisierungsbias, die Artikel 14 beschreibt, nur eine Ebene höher.

Aus der Alarmierung ist das Muster bekannt. Das BSI beschreibt im IT-Grundschutz-Baustein DER.1 als Gefährdung, dass bei falsch eingestellter Alarmierung vermehrt Fehlalarme auftreten können; die Zuständigen können dann „eventuell nicht mehr zwischen einem Fehlalarm und einem sicherheitsrelevanten Ereignis unterscheiden“ und nehmen Meldungen möglicherweise nicht schnell genug wahr. Für Freigaben gilt dasselbe. Das SRE-Buch von Google formuliert für Alarme einen Grundsatz, der sich übertragen lässt: „Every page should be actionable.“ Eine Freigabe, bei der die freigebende Person nichts zu entscheiden hat, ist keine.

Das andere Extrem – gar keine Freigaben – ist ebenso wenig eine Lösung. Das Ziel sind wenige, bedeutsame Freigaben. Kandidaten dafür sind Schritte, die sich nicht zuverlässig zurücknehmen lassen, deren Wirkung über den eigenen Verantwortungsbereich hinausreicht, bei denen Daten das Haus verlassen oder bei denen Berechtigungen vergeben werden. Was sich sauber zurückrollen lässt und dessen Ergebnis automatisch geprüft wird, braucht meist keinen Menschen davor, sondern eine Kontrolle danach.

Checkliste für Freigaben in Automatisierungen

  • Jede Freigabe hat eine benannte verantwortliche Person mit Vertretung.
  • Der Zustand „wartet auf Freigabe“ ist sichtbar, hat einen Schwellenwert und löst einen Alarm aus.
  • Die Freigabe wird angekündigt, bevor der Prozess blockiert.
  • Der freigabepflichtige Schritt steht so spät wie möglich im Ablauf.
  • Wartezeiten und Entscheidungen werden protokolliert und regelmäßig ausgewertet.
  • Der Alarm für offene Freigaben wurde mindestens einmal testweise ausgelöst und ist tatsächlich angekommen.
  • Die Liste der Freigaben wird regelmäßig darauf geprüft, ob jede einzelne ihren Zweck noch erfüllt.

Wie sector7 unterstützt

Wir ordnen mit Ihnen ein, was Ihre KI-Nutzung nach dem EU AI Act auslöst, und legen Risikoklassifizierung, Dokumentationspflichten und klare Zuständigkeiten fest – mehr unter Souveräne KI. Betreute Umgebungen überwacht unser NOC rund um die Uhr automatisiert; erkannte Auffälligkeiten werden nach den vertraglich vereinbarten Prozessen bearbeitet, wie unter Managed Services & Support beschrieben.

Quellen

Sprechen wir über Ihre Situation.

Gespräch vereinbaren+49 212 240915 0