KI-Automatisierung im Unternehmen: Wo sich LLM-Workflows wirklich lohnen

Drei Kriterien entscheiden, ob ein Use Case trägt

Ob sich KI-Automatisierung für ein Unternehmen rechnet, hängt weniger vom Modell ab als vom Zuschnitt des Workflows. Drei Kriterien haben sich als verlässlicher Filter erwiesen:

• ✓Volumen: Der Prozess kommt hundertfach pro Monat vor, nicht dreimal. Der Aufwand für Anbindung, Prompts und Tests ist weitgehend fix - er amortisiert sich über Wiederholung.
• ✓Prüftoleranz: Ein Mensch kann das Ergebnis schneller prüfen, als er es selbst erzeugt hätte. Wo Prüfen so lange dauert wie Selbermachen, spart das LLM nichts.
• ✓Strukturierte Ausgabe: Das Ergebnis lässt sich als Datensatz validieren - Felder, Kategorien, Verweise auf Quellen. Freitext, der ungeprüft weiterfließt, ist keine Automatisierung, sondern ein Risiko.

Wo LLM-Workflows heute verlässlich liefern

Fehlt eines der drei, ist das kein Veto - aber ein Signal, den Workflow neu zu schneiden, bevor generative KI ins Spiel kommt. Oft ist der bessere erste Schritt klassische Workflow-Automatisierung ohne Modell: Regeln, Formulare, Integrationen. Machine Learning und LLMs erweitern diese Basis, sie ersetzen sie nicht.

Die Muster, die tragen, sind unspektakulärer als die Demos: Extraktion strukturierter Daten aus Dokumenten (Rechnungen, Bestellungen, Verträge) mit Validierung gegen Bestandsdaten; Triage und Antwortentwürfe im Support, bei denen ein Mensch die Antwort abschickt; Zusammenfassungen langer Vorgänge - Tickets, Incidents, Fallakten - für die Menschen, die entscheiden; und interne Assistenten, die Wissen aus eigenen Dokumenten per RAG auffindbar machen.

Beim Stichwort Chatbot lohnt Ehrlichkeit: Ein interner RAG-Assistent über die eigene Dokumentation hat klaren, messbaren Nutzen und begrenztes Risiko. Ein kundenzugewandter Marketing-Chatbot ist ein anderes Projekt - höhere Transparenzanforderungen, Fehlertoleranz nahe null und Reputationsrisiko pro falscher Antwort. Wer mit dem internen Fall startet, lernt am billigen Ende.

Menschliche Aufsicht ist Architektur, kein Übergangszustand

Die verbreitete Annahme, Review-Schritte seien eine Anlaufphase und fielen später weg, ist das teuerste Missverständnis in diesem Feld. Aufsicht ist eine Architektureigenschaft: Für jeden Workflow wird entschieden, ob ein Mensch jedes Ergebnis prüft (Draft-and-Review), Stichproben zieht oder nur Ausnahmen sieht, die an der Validierung scheitern. Diese Entscheidung hängt an der Fehlertoleranz des Prozesses - nicht am Vertrauen ins Modell.

Für Agent-Workflows, die selbst Aktionen ausführen, gilt dieselbe Disziplin wie für jede IAM-Rolle: Least Privilege bei den Tools, die der Agent aufrufen darf, vollständiges Logging jeder Aktion, Umkehrbarkeit als Designkriterium. Ein Agent, dessen Aktionen weder zuordenbar noch rückholbar sind, gehört nicht in Produktion.

Der EU AI Act, in der gebotenen Kürze

Die gute Nachricht: Die meisten der hier beschriebenen Workflows - Extraktion, Triage mit menschlichem Versand, interne Assistenten - sind unter dem EU AI Act bei ehrlicher Lesart minimales oder begrenztes Risiko. Was trotzdem jetzt fällig ist: ein Inventar der KI-Systeme mit begründeter Risikoklasse, rollengerechte KI-Kompetenz im Team und Transparenz, wo Menschen mit KI interagieren. Wie diese Pflichten im Detail greifen, behandelt der eigene Artikel zum EU AI Act für Cloud-Operations-Teams - hier genügt: Die Klassifizierung gehört in die Use-Case-Auswahl, nicht ans Projektende.

Was es ehrlich kostet

Die Modellkosten pro Anfrage sind fast nie der relevante Block. Teuer sind: die Anbindung an Bestandssysteme, der Aufbau einer Evaluationsbasis (ein Set echter Fälle mit bekannten Soll-Ergebnissen, gegen das jede Prompt- und Modelländerung läuft), der Review-Aufwand im Betrieb und die Pflege, wenn sich Dokumente, Prozesse oder Modelle ändern. Ein Workflow ohne Evaluationsset ist nicht billig, sondern unbezahlt - die Rechnung kommt mit dem ersten stillen Qualitätsverlust.

Realistisch kalkuliert: ein kleines Projekt pro Workflow, kein Programm; laufende Kosten aus Betrieb und Review, gemessen gegen die eingesparte manuelle Zeit. Wenn diese Rechnung nur mit optimistischen Annahmen aufgeht, ist der Use Case falsch geschnitten.

Eine Auswahl-Sequenz, die sich bewährt hat

Vor dem ersten Projekt, in dieser Reihenfolge:

• ✓Prozesskandidaten listen und je Kandidat Volumen, Fehlertoleranz und heutigen manuellen Aufwand notieren - eine Zeile pro Prozess genügt.
• ✓Die zwei besten Kandidaten gegen die drei Kriterien prüfen; den besseren wählen, nicht beide.
• ✓Baseline messen, bevor irgendetwas gebaut wird: Wie lange dauert der Prozess heute, wie oft, mit welcher Fehlerquote.
• ✓Evaluationsset aus echten Fällen aufbauen, dann erst Prompts und Anbindung.
• ✓Mit Draft-and-Review in Produktion gehen und die Review-Quote messen - sinkt sie nachweislich, kann die Aufsicht auf Stichproben umgestellt werden.

FAQ