Wer darf entscheiden, wenn KI-Agenten arbeiten?

7 Min. Lesezeit

KI-Agenten halten längst Einzug in betriebliche Abläufe, die Entscheidungsfrage aber bleibt oft offen: Wer darf eine Bestellung auslösen, eine Kundenzusage treffen, eine Freigabe erteilen? Gastautor Karl Wibbecke, Inhaber der Deutschen Automatisierungsgesellschaft, skizziert ein Operating Model mit vier Aktionsklassen und klaren Verantwortungsgrenzen zwischen Geschäftsleitung, Fachbereich und IT.

Verwandt87% mehr KI-Budget, 14% klare Verantwortung  /  Erst die Entscheidungsthese, dann das Organigramm

KI-Agenten werden erst dann zu einem unternehmerischen Thema, wenn ihre Analyse eine reale Wirkung auslösen kann. Ein belastbares Operating Model legt deshalb fest, welche Aktionen der Agent selbst ausführen darf, wann ein Mensch entscheidet und wie Ausnahmen sowie Wiederanläufe kontrolliert werden.

Vom KI-Einsatz zur Prozessverantwortung

Ein KI-Agent kann Informationen aus mehreren Systemen zusammenführen, Vorgänge priorisieren und Folgeaktionen vorbereiten. Sobald er jedoch Daten verändert, eine Bestellung auslöst oder gegenüber einem Kunden eine Zusage macht, wird aus einer technischen Funktion eine unternehmerische Entscheidung. Die entscheidende Frage lautet deshalb nicht nur, was das Modell kann. Ein Unternehmen muss vorab festlegen, welche Handlung der Agent in welchem Prozesszustand selbst ausführen darf und wer die Folgen verantwortet.

Diese Klärung gehört in das Operating Model, nicht in eine einzelne Eingabe oder in das Ermessen eines Projektteams. Es verbindet Geschäftsziele, Prozessregeln und technische Kontrollen. Die Geschäftsleitung bestimmt den zulässigen Risikorahmen. Der Fachbereich beschreibt, wann ein Fall eindeutig ist und welche Ausnahmen eine Entscheidung verlangen. Die IT setzt Berechtigungen, Protokollierung und Rückfallwege so um, dass diese Vorgaben im Betrieb tatsächlich greifen.

Ein solches Modell bremst Automatisierung nicht zwangsläufig. Es verhindert vielmehr, dass jede neue Funktion erneut über Grundsatzfragen verhandeln muss. Wenn Entscheidungsklassen, Zuständigkeiten und Eskalationswege feststehen, kann ein Unternehmen weitere Anwendungsfälle schneller beurteilen und vergleichbare Risiken nach demselben Maßstab behandeln.

Entscheidungsrechte vor Ablaufregeln

Viele Projekte beginnen mit einer Abfolge von Arbeitsschritten: Daten lesen, bewerten, Ergebnis erzeugen und Aktion auslösen. Für einen kontrollierbaren Betrieb reicht diese Ablaufbeschreibung nicht. Sie muss um Entscheidungsrechte ergänzt werden. Dazu gehört für jeden Schritt, welche Datenquelle maßgeblich ist, welche Voraussetzungen erfüllt sein müssen, welche Wirkung die Aktion hat und ob sie rückgängig gemacht werden kann.

Besonders wichtig sind die Übergänge zwischen Analyse und Wirkung. Ein Agent darf beispielsweise Liefertermine vergleichen und einen Bestellvorschlag erstellen. Daraus folgt noch nicht, dass er eine Bestellung verbindlich abschicken darf. Ebenso kann er eine Serviceanfrage klassifizieren und eine Antwort vorbereiten, ohne Preise, Fristen oder Haftungsaussagen selbst zu bestätigen. Der gleiche technische Ablauf erhält dadurch unterschiedliche Freigabepunkte, abhängig von finanzieller, rechtlicher oder betrieblicher Tragweite.

Die Regeln müssen auf den tatsächlichen Prozesszustand Bezug nehmen. Eine Freigabe, die gestern erteilt wurde, kann heute wertlos sein, wenn sich Preis, Lieferfähigkeit oder Kundendaten geändert haben. Deshalb braucht jede folgenreiche Aktion eine Prüfung, ob die zugrunde liegenden Daten noch gültig sind und ob die erteilte Berechtigung genau für diesen Zustand gilt.

Vier Aktionsklassen für den Betrieb

Eine praxistaugliche Einteilung trennt vier Aktionsklassen. Sie beschreibt nicht die Leistungsfähigkeit des Modells, sondern die Wirkung im Geschäftsprozess. Der Agent erhält nur die Berechtigungen, die für seine Klasse erforderlich sind. Ein Wechsel in eine höhere Klasse verlangt eine eigene Prüfung und gegebenenfalls eine menschliche Freigabe.

Die Einteilung bleibt absichtlich unabhängig von einer bestimmten Software. Sie lässt sich auf Einkauf, Service, Personalprozesse oder technische Betriebsabläufe übertragen. Entscheidend ist, dass jede konkrete Funktion genau einer Wirkungsklasse zugeordnet wird.

Rollen von Geschäftsleitung, Fachbereich und IT

Die Geschäftsleitung entscheidet, welche Folgen ein Agent ohne zusätzliche Zustimmung auslösen darf. Dazu zählen finanzielle Obergrenzen, zulässige Vertragswirkungen, tolerierbare Betriebsunterbrechungen und der Umgang mit sensiblen Daten. Diese Grenzen sollten als nachvollziehbare Richtlinie beschlossen werden. Eine pauschale Freigabe für einen Anwendungsfall ist zu ungenau, weil derselbe Agent harmlose und folgenreiche Aktionen ausführen kann.

Der Fachbereich übersetzt den Risikorahmen in belastbare Prozessregeln. Er definiert Pflichtdaten, zulässige Wertebereiche, eindeutige Standardfälle und Ausnahmen. Außerdem benennt er die Personen oder Rollen, die bei Unsicherheit entscheiden. Prozessverantwortung bleibt damit dort, wo auch heute fachliche Folgen beurteilt werden. Der Agent verändert die Ausführung, nicht die fachliche Zuständigkeit.

Die IT bildet diese Regeln in Identitäten, Rollen und technischen Kontrollen ab. Ein Agent sollte eine eigene technische Identität besitzen. Berechtigungen müssen auf Systeme, Datenobjekte und Aktionen begrenzt sein. Protokolle sollten erkennen lassen, welche Daten verwendet wurden, welche Regel gegriffen hat, welche Aktion vorbereitet oder ausgeführt wurde und wer eine Freigabe erteilt hat. So entsteht eine prüfbare Kette statt eines nachträglichen Rätselns über Modellantworten.

Ein Beispiel aus Beschaffung und Service

In einem mittelständischen Betrieb meldet ein Kunde den Ausfall einer Komponente. Der Agent liest Auftrag, Wartungsvertrag und Lagerbestand, ordnet die Störung einer Produktgruppe zu und bereitet einen Serviceeinsatz vor. Diese Schritte gehören zur Analyse und Vorbereitung. Sie sparen Zeit, ohne bereits eine externe Verpflichtung auszulösen.

Ist das benötigte Ersatzteil verfügbar und deckt der Vertrag den Standardfall ab, kann der Agent einen internen Vorgang anlegen und einen Terminvorschlag erzeugen. Eine verbindliche Kundenzusage bleibt zunächst gesperrt. Weichen Kosten, Lieferzeit oder Vertragsumfang vom Standard ab, übergibt das System den Fall mit den relevanten Belegen an die zuständige Person. Diese sieht nicht nur eine Empfehlung, sondern auch den erkannten Prozesszustand und den Grund der Eskalation.

Nach der Freigabe muss der Agent prüfen, ob sich wesentliche Daten verändert haben. Wurde das letzte Ersatzteil zwischenzeitlich reserviert, darf die alte Zustimmung nicht automatisch weiterverwendet werden. Der Vorgang springt in die Vorbereitung zurück oder wird erneut vorgelegt. Dieser Mechanismus verhindert, dass eine formal richtige Freigabe auf einer veralteten Lage ausgeführt wird.

Ausnahmen und Eskalation

Ein Operating Model zeigt seine Qualität nicht im Standardfall, sondern bei widersprüchlichen oder unvollständigen Daten. Dafür braucht der Agent eindeutige Stopppunkte. Er muss anhalten, wenn Pflichtinformationen fehlen, Quellen einander widersprechen, eine Berechtigung abgelaufen ist oder die erwartete Wirkung nicht sicher bestimmt werden kann. Unsicherheit darf nicht durch eine sprachlich überzeugende Vermutung verdeckt werden.

Die Eskalation sollte den Fall nicht als lose Chatnachricht weiterreichen. Sie muss den aktuellen Zustand, die verwendeten Quellen, die bislang ausgeführten Schritte, die offene Entscheidung und mögliche Folgen enthalten. Der Empfänger kann dann fachlich entscheiden, ohne den gesamten Vorgang neu zu rekonstruieren. Gleichzeitig bleibt sichtbar, ob die Ausnahme durch eine Datenlücke, eine Prozessregel oder eine technische Störung entstanden ist.

Für wiederkehrende Ausnahmen braucht es einen geregelten Verbesserungsweg. Der Fachbereich kann eine Regel präzisieren oder einen neuen Standardfall definieren. Die IT passt Berechtigungen und Prüfungen an. Die Geschäftsleitung entscheidet, wenn sich dadurch der Risikorahmen verschiebt. Eine einzelne Freigabe sollte dagegen nie stillschweigend zur allgemeinen Regel werden.

Protokollierung und kontrollierter Wiederanlauf

Protokollierung erfüllt zwei Aufgaben. Sie ermöglicht die Prüfung eines einzelnen Vorgangs und liefert Hinweise, ob die festgelegten Grenzen im Betrieb funktionieren. Dafür genügen technische Logdateien allein nicht. Entscheidend ist eine verständliche Ereigniskette aus Prozesszustand, Entscheidung, Freigabe und Wirkung. Personenbezogene oder vertrauliche Inhalte sollten nur gespeichert werden, wenn sie für Nachweis und Betrieb erforderlich sind.

Nach einem Abbruch darf der Agent nicht beliebig an der letzten technischen Stelle fortsetzen. Zuerst muss geklärt werden, welche Schritte erfolgreich waren, welche externen Wirkungen bereits eingetreten sind und ob der Prozesszustand noch aktuell ist. Der Wiederanlauf beginnt an einem definierten sicheren Punkt. Bei einer Bestellung kann das bedeuten, zunächst den Bestellstatus beim Lieferanten zu prüfen, bevor ein erneuter Versand möglich ist. So werden Doppelaktionen vermieden.

Der Betrieb sollte außerdem wenige aussagekräftige Kennzahlen beobachten: Wie oft greift ein Stopppunkt, wie lange dauert eine Eskalation, wie häufig wird eine Empfehlung überstimmt und welche Aktionen scheitern nach einer Freigabe? Diese Werte beweisen keine Qualität des Modells. Sie zeigen aber, ob Regeln zu eng, zu weit oder im Alltag unverständlich sind und wo eine Überarbeitung nötig ist.

Prüffragen für ein tragfähiges Operating Model

Vor dem produktiven Einsatz sollten Geschäftsleitung, Fachbereich und IT gemeinsam jeden Übergang mit Wirkung prüfen. Welche Aktion verändert Daten oder löst eine Verpflichtung aus? Welcher Prozesszustand muss dafür bestätigt sein? Wer darf in einer Ausnahme entscheiden? Wie lange gilt eine Freigabe? Welche bereits eingetretene Wirkung muss der Wiederanlauf berücksichtigen? Und woran erkennt das Unternehmen, dass eine Regel im Betrieb nicht trägt?

Die Antworten müssen nicht jede denkbare Situation vorwegnehmen. Sie müssen jedoch so konkret sein, dass ein Team einen neuen Fall eindeutig einer Aktionsklasse zuordnen und den zuständigen Entscheidungsweg bestimmen kann. Dann bleibt Verantwortung auch bei zunehmender Automatisierung sichtbar. Der Agent übernimmt Arbeitsschritte innerhalb festgelegter Grenzen; das Unternehmen behält die Kontrolle über Entscheidungen und Folgen.

Häufig gestellte Fragen

Bildquelle: Deutsche Automatisierungsgesellschaft