KI in der Prozessautomatisierung Vol. 4:
Welche Use Cases lohnen sich wirklich?

Nein. Vol. 4 ist eigenständig verständlich. Die bisherigen Webinare liefern ergänzenden Kontext zu Offenheit, Workflows und Architektur.

Es verbindet beide Perspektiven. Ausgangspunkt ist das Prozessproblem. Wir betrachten messbaren Nutzen sowie Integration und Betrieb so weit, wie es für die Auswahl eines Use Cases und die Vorbereitung eines Piloten erforderlich ist.

Sie können einen eigenen Prozess als gedankliches Beispiel für die Bewertung nutzen. Eine individuelle Detailanalyse einzelner Teilnehmerprozesse ist nicht Bestandteil des Webinars.

Im Mittelpunkt steht eine technologieoffene Bewertungslogik anhand exemplarischer Prozesse, nicht die Vorführung einer bestimmten Software. Wir betrachten auch, wie sich Modelle austauschen und Lösungen in bestehende Systeme integrieren lassen.

Für informationsintensive Abläufe, in denen Informationen verarbeitet, Prüfungen und Entscheidungen vorbereitet oder Vorgänge über mehrere Beteiligte und Systeme hinweg weitergeführt werden. Entscheidend sind die Aufgaben und Herausforderungen im Prozess, nicht eine bestimmte Branche oder Abteilung.

Im Webinar lernen Sie KI-Use-Cases anhand nachvollziehbarer Kriterien zu vergleichen und einen Piloten mit messbaren Nutzenzielen und klaren Kontrollen vorzubereiten.

Denken Sie dabei an einen Prozess, bei dem heute viel gelesen, erfasst oder geprüft wird. Schon eine grobe Beschreibung hilft, die Bewertung auf Ihre Situation zu übertragen.

Computer Use ist vor allem dort interessant, wo Altsysteme keine Schnittstelle bieten: Der KI-Agent bedient die Oberfläche wie ein Mensch, liest den Bildschirm, klickt und tippt. Ein pauschales Verbot gibt es dafür nicht. Die Hürden entstehen vielmehr daraus, dass ein Agent mit weitreichendem Zugriff auf Anwendungen und Daten arbeitet und dabei schwerer zu kontrollieren ist als ein klar definierter API-Aufruf.

In der Praxis begegnen uns vor allem fünf Themen. Erstens der Datenschutz: Der Agent sieht alles, was auf dem Bildschirm angezeigt wird, also häufig auch personenbezogene Daten, die für die eigentliche Aufgabe nicht nötig sind. Das berührt Datenminimierung, Speicherdauer von Screenshots, Auftragsverarbeitung mit dem KI-Anbieter und gegebenenfalls Drittlandtransfers; je nach Umfang ist eine Datenschutz-Folgenabschätzung sinnvoll. Zweitens Berechtigungen und Nachvollziehbarkeit: Arbeitet der Agent unter dem Konto eines Mitarbeitenden, ist später kaum noch zu unterscheiden, wer was getan hat, und Prinzipien wie Funktionstrennung oder Vier-Augen-Prinzip werden ausgehebelt.

Drittens branchenspezifische Vorgaben: Für Finanzdienstleister gilt DORA, für viele Versorger und Verkehrsunternehmen KRITIS- bzw. NIS2-Anforderungen. Dort stellt sich etwa die Frage, ob der KI-Anbieter als IKT-Drittdienstleister geführt und gesteuert wird. Hinzu kommt der EU AI Act: Die meisten Backoffice-Automatisierungen fallen nicht in die Hochrisiko-Kategorie, bei Anwendungsfällen rund um Personal- oder Kreditentscheidungen kann das aber anders aussehen. Viertens die Mitbestimmung: Ein Agent, der Bildschirme erfasst und Aktionen protokolliert, kann als technische Einrichtung zur Leistungs- oder Verhaltenskontrolle gelten, sodass der Betriebsrat einzubinden ist. Fünftens die Legacy-Anwendung selbst: Lizenz- und Nutzungsbedingungen sollten automatisierten Zugriff erlauben, und schon kleine Oberflächenänderungen können das Verhalten des Agenten beeinflussen.

Wie wir das in Projekten absichern: Der Agent läuft auf einer dedizierten virtuellen Maschine statt auf einem produktiven Arbeitsplatz und nutzt eine eigene technische Identität mit minimalen Rechten. Erreichbar sind nur explizit freigegebene Anwendungen. Lesende Schritte dürfen automatisch laufen, schreibende oder nicht umkehrbare Aktionen benötigen zumindest anfangs eine menschliche Freigabe. Jede Aktion wird mit Zeitstempel und Kontext protokolliert, im Pilot arbeiten wir wo möglich mit Test- oder anonymisierten Daten. Außerdem behandeln wir Inhalte auf dem Bildschirm, etwa aus E-Mails oder Dokumenten, konsequent als Daten und nicht als Anweisungen, um Manipulation über eingeschleuste Texte (Prompt Injection) zu verhindern. IT-Sicherheit und Compliance sind dabei von Beginn an eingebunden.

Unsere Einordnung: Computer Use ist eine Brücke für Systeme ohne Schnittstelle, kein Ersatz für eine saubere Integration. Wo eine API existiert oder mit vertretbarem Aufwand geschaffen werden kann, ist sie in der Regel stabiler, besser prüfbar und leichter zu genehmigen. Das entspricht der Leitfrage aus dem Webinar: Löst der Agent echte Varianz, oder kaschiert er eine fehlende Schnittstelle?

Die konkreten Anforderungen hängen stark von Branche, Daten und Anwendungsfall ab. Diese Einordnung ersetzt daher keine rechtliche Prüfung; für Ihren konkreten Fall empfehlen wir eine individuelle Bewertung gemeinsam mit Datenschutz, IT-Sicherheit und gegebenenfalls Betriebsrat.

Das ist eher die Regel als die Ausnahme. Viele Prozesse laufen über E-Mail-Postfächer, Ablagen oder Fachsysteme, die Fallzahlen und Bearbeitungszeiten nicht sauber erfassen. Eine belastbare Baseline muss aber nicht perfekt sein. Sie muss nachvollziehbar sein und vor dem Piloten feststehen.

Ein pragmatischer Einstieg sind die Größen aus der Formel im Webinar: Volumen, heutiger Aufwand je Vorgang und realistisch reduzierbarer Anteil. Das Volumen lässt sich oft aus vorhandenen Quellen ableiten, etwa aus Postfach-Statistiken, Ticketsystemen oder Buchungen im Fachsystem. Den Aufwand je Vorgang ermitteln wir in der Regel über eine kurze Zeitmessung: Mehrere Sachbearbeitende erfassen über ein bis zwei Wochen für eine Stichprobe, wie lange einzelne Arbeitsschritte dauern und wie oft nachgearbeitet werden muss. Ergänzend helfen Interviews, um typische Varianten und Ausnahmen zu verstehen.

Wichtig ist, die Baseline auf Ebene der einzelnen Arbeitsschritte zu erheben, nicht nur für den Prozess als Ganzes. Nur so lässt sich später zeigen, wo KI tatsächlich entlastet, etwa beim Klassifizieren oder Extrahieren, und wo neuer Aufwand entsteht, etwa für Prüfung und Freigabe. Neben dem Bearbeitungsaufwand sollten auch Durchlaufzeit, Fehler- bzw. Nacharbeitsquote und, wo relevant, Servicequalität erfasst werden.

Ist eine Erhebung im Vorfeld kaum möglich, kann der Pilot selbst als Messinstrument dienen: Ein Teil der Fälle läuft wie bisher, ein Teil über den neuen Prozess. Der Vergleich beider Gruppen liefert dann die Grundlage für die Entscheidung. Ohne Ausgangswert bleibt jeder Nutzennachweis eine Schätzung.

Die entscheidende Frage ist nicht, wie komplex die Aufgabe wirkt, sondern ob der Lösungsweg bekannt ist. Bei der KI-gestützten Automatisierung ist der Prozessweg festgelegt: Die KI übernimmt einen klar umrissenen Schritt, etwa eine E-Mail als Reklamation klassifizieren und Produkt und Charge extrahieren. Danach geht es regelbasiert im Workflow weiter. Bei einer agentischen Komponente ist dagegen auch der Weg situationsabhängig: Der Agent erhält ein Ziel und entscheidet selbst, welche Quellen er abfragt, welche Werkzeuge er nutzt und welcher Schritt als nächstes sinnvoll ist.

Hinweise auf einen agentischen Teilprozess sind zum Beispiel, dass je nach Fall unterschiedliche Systeme wie ERP, CRM oder DMS in wechselnder Reihenfolge abgefragt werden müssen, dass Zwischenergebnisse bestimmen, was als nächstes passiert, oder dass sich die möglichen Varianten kaum vollständig als Prozessmodell beschreiben lassen. Lässt sich der Ablauf dagegen als Folge von Schritten aufzeichnen, auch mit Verzweigungen, ist ein Agent meist die falsche Wahl. Er wäre teurer, schwerer zu prüfen und weniger stabil als ein Workflow mit einem gezielten KI-Aufruf.

In der Praxis hilft ein einfacher Test: Versuchen Sie, den Prozess für zehn typische und zehn schwierige Fälle als Ablauf zu skizzieren. Gelingt das mit einer überschaubaren Zahl an Pfaden, ist die KI-gestützte Automatisierung meist der richtige Ansatz. Entstehen ständig neue Pfade, lohnt es sich, einen agentischen Teilprozess zu prüfen.

Wichtig ist außerdem: Mehr Autonomie erfordert mehr Leitplanken. Für einen Agenten muss klar geregelt sein, was er lesen und schreiben darf, auf welche Werkzeuge er zugreifen kann und wann er an einen Menschen übergibt. Deshalb empfehlen wir, agentische Komponenten zunächst eng begrenzt innerhalb eines klassisch gesteuerten Gesamtprozesses einzusetzen. Wie im Webinar betont: Agentisch ist nicht automatisch besser, sondern die einfachste ausreichende Form der Automatisierung gewinnt.

Das Muster ist weit verbreitet. Meist liegt es nicht an der KI selbst, sondern daran, dass der PoC die falsche Frage beantwortet hat. Viele PoCs testen, ob ein Modell gute Ergebnisse liefert. Für eine Betriebsentscheidung ist aber entscheidend, ob der Prozess als Ganzes besser, schneller oder günstiger wird. Das ist der Unterschied zwischen Modelltest und Pilot.

Drei Ursachen sehen wir besonders häufig. Erstens fehlt ein vorab definiertes Erfolgskriterium: Ohne Baseline und messbares Nutzenziel kann am Ende niemand sagen, ob der PoC erfolgreich war, und es folgt der nächste Test. Zweitens wurde die Integration ausgeklammert: Das KI-Ergebnis landet in einer Demo-Oberfläche, aber nicht im Workflow oder Fachsystem. Der Aufwand dafür zeigt sich erst danach und verändert den Business Case. Drittens wurden Betriebsfragen nicht geklärt: Wer ist verantwortlich, wenn die KI falsch liegt? Wie wird eskaliert? Was kostet der laufende Betrieb? Diese Fragen tauchen spätestens bei IT-Sicherheit, Datenschutz oder Revision auf und stoppen das Vorhaben.

Unsere Empfehlung: Legen Sie den Piloten von Beginn an auf Produktionsrealität aus. Das heißt, Prozessgrenze und Ausgangswert festlegen, ein messbares Ziel definieren, mit repräsentativen statt ausgewählten Fällen testen und Kontrollen, Verantwortlichkeiten und Integration bereits im Pilot mitdenken. Ebenso wichtig ist, vor dem Start festzuhalten, ab welchen Messwerten der Pilot in den Betrieb geht, angepasst wird oder beendet wird. Dann steht am Ende eine Entscheidung und nicht der nächste PoC.

Hilfreich ist auch ein Blick zurück auf die bisherigen PoCs: Häufig lassen sich vorhandene Ergebnisse mit überschaubarem Aufwand zu einem echten Piloten weiterentwickeln, wenn Integration und Betriebsfragen nachgezogen werden.