KI in Unternehmen — Use Cases, Agentensysteme und Workflows

Die meisten Unternehmen stecken nicht mehr in der Frage, ob KI eingesetzt wird, sondern in der Frage, wo genau — und ob das, was schon läuft, auch im Alltag trägt. Diese Seite ordnet drei Aufgaben, die dabei in der Praxis immer wieder auftauchen: Anwendungsfälle priorisieren, agentische Systeme vor dem Rollout bewerten und die Einführung so in operative Workflows überführen, dass sie nicht am ersten Ausnahmefall zerbricht. Der Maßstab ist jeweils die konkrete Aufgabe eines Teams, nicht ein allgemeines Versprechen über "KI im Unternehmen".

Anwendungsfälle priorisieren, statt Tools zu sammeln

Der häufigste Fehlstart ist nicht die falsche Technologie, sondern die falsche Reihenfolge: Ein Tool wird eingeführt, bevor klar ist, welche Aufgabe damit tatsächlich schneller, billiger oder verlässlicher wird. Eine tragfähige Priorisierung beginnt deshalb bei der Aufgabe, nicht beim Modell:

• Wiederholung und Volumen. Aufgaben, die oft und in ähnlicher Form anfallen, liefern messbaren Nutzen schneller als Einzelfälle, an denen ein System nie genug Übung bekommt.
• Fehlerkosten. Ein falscher Textentwurf ist ein Korrekturdurchgang. Eine falsche Zahl in einem Angebot oder eine falsche Freigabe in einem Kundenprozess ist ein anderes Risiko — die gleiche Modellklasse rechtfertigt hier nicht die gleiche Freigabestufe.
• Prüfbarkeit des Ergebnisses. Lässt sich eine Ausgabe in angemessener Zeit von einem Menschen kontrollieren, oder verlangt der Use Case blindes Vertrauen in ein Blackbox-Ergebnis? Wenn niemand im Team die Ausgabe in vertretbarer Zeit prüfen kann, ist das kein Betriebsmodell, sondern ein Risiko mit Verzögerung.
• Vorhandene Dateninfrastruktur. Ein Anwendungsfall, der sauber strukturierte, bereits vorhandene Daten nutzt, ist etwas anderes als einer, der zuerst eine neue Datenpipeline braucht, um überhaupt funktionsfähig zu sein.

Eine Priorisierung entlang dieser vier Kriterien ergibt typischerweise eine kurze Liste von zwei bis drei Anwendungsfällen, die sich in überschaubarer Zeit umsetzen und im Betrieb überprüfen lassen — nicht ein Backlog aus zwanzig Ideen, von denen die meisten nie über den Pilotstatus hinauskommen.

Agentensysteme bewerten, bevor sie live gehen

Ein Agentensystem unterscheidet sich von einem klassischen KI-Feature dadurch, dass es selbstständig mehrere Schritte ausführt, Werkzeuge aufruft und Zwischenentscheidungen trifft, ohne dass ein Mensch jeden einzelnen Schritt bestätigt. Genau das macht die Bewertung vor dem Rollout wichtiger, nicht optional:

• Handlungsspielraum. Was kann das System tatsächlich auslösen — eine E-Mail versenden, eine Zahlung anstoßen, einen Datensatz verändern? Der Handlungsspielraum bestimmt, wie viel eine einzelne Fehlentscheidung kosten kann, unabhängig davon, wie selten sie vorkommt.
• Nachvollziehbarkeit im Nachhinein. Wenn ein Agentensystem drei Wochen nach dem Rollout eine falsche Entscheidung getroffen hat, muss sich rekonstruieren lassen, welche Zwischenschritte dazu geführt haben. Ohne Protokollierung der Zwischenschritte ist jede nachträgliche Fehlersuche Rätselraten.
• Grenzen der Autonomie. Für welche Aktionen reicht eine automatische Ausführung, und ab welchem Schwellenwert — Betrag, Reichweite, Kundentyp — braucht es eine Freigabe durch einen Menschen, bevor das System weiterläuft? Diese Schwelle gehört vor den Rollout festgelegt, nicht nach dem ersten Vorfall.
• Verhalten außerhalb des Demo-Pfads. Ein Agentensystem, das im vorbereiteten Testszenario überzeugt, muss auch bei unvollständigen Eingaben, widersprüchlichen Anweisungen oder einem ausgefallenen Werkzeug ein definiertes Verhalten zeigen — nicht raten, was als Nächstes plausibel wäre.

Diese Bewertung ist keine einmalige Freigabe. Ein Agentensystem, das neue Werkzeuge oder neue Datenquellen erhält, braucht dieselbe Prüfung erneut, weil sich der Handlungsspielraum mit jeder Erweiterung verschiebt.

Operative Workflows einführen, die im Alltag tragen

Ein Anwendungsfall, der im Pilotprojekt funktioniert, ist noch kein operativer Workflow. Dazwischen liegt die Arbeit, die selten im Projektplan auftaucht, aber darüber entscheidet, ob ein System nach drei Monaten noch genutzt wird:

• Zuständigkeit im Fehlerfall. Wer wird informiert, wenn eine KI-gestützte Aufgabe falsch läuft, und wer hat die Befugnis, das System in dem Moment anzuhalten? Ohne benannte Zuständigkeit übernimmt in der Praxis niemand diese Rolle, bis ein Vorfall sie erzwingt.
• Prüfpunkte statt Blankovertrauen. Ein Workflow braucht definierte Stellen, an denen ein Mensch das Ergebnis stichprobenartig oder vollständig gegenprüft — abgestuft nach den Fehlerkosten, die im ersten Schritt der Priorisierung schon benannt wurden.
• Dokumentation, die Bestand hat. Was ein System tut, warum es diese Berechtigung hat und wer die letzte Änderung freigegeben hat, muss auch dann noch auffindbar sein, wenn die Person, die es eingeführt hat, das Team verlassen hat.
• Ein Weg zurück. Jeder eingeführte Workflow braucht einen definierten Rückfall auf den manuellen Prozess, falls das System ausfällt oder abgeschaltet werden muss — nicht als Notlösung, die im Ernstfall improvisiert wird, sondern als vorbereiteter Schritt.

Diese vier Punkte sind unspektakulär, und genau deshalb werden sie unter Zeitdruck übersprungen. Sie sind auch der Unterschied zwischen einem Werkzeug, das ein Team benutzt, und einem Werkzeug, das ein Team irgendwann stillschweigend abschaltet, weil niemand mehr genau weiß, was es eigentlich tut.

Wo das in der Praxis schiefgeht

Der wiederkehrende Fehler ist nicht technischer, sondern struktureller Natur: Ein Use Case wird ausgewählt, weil ein Anbieter ihn im Vertriebsgespräch gut demonstriert hat, nicht weil er die vier Priorisierungskriterien oben erfüllt. Das Ergebnis ist ein System, das im Piloten überzeugt und im Betrieb schnell an Randfällen scheitert, die im Demo-Szenario nie vorkamen — falsch formatierte Eingaben, ein ausgefallenes Drittsystem, eine Kundenanfrage, die nicht in das erwartete Muster passt. Zu diesem Zeitpunkt existiert meist weder eine benannte Zuständigkeit für den Fehlerfall noch ein vorbereiteter Rückfall auf den manuellen Prozess — beides Punkte, die vor dem Rollout einfacher zu klären gewesen wären als danach.

Nächster Schritt

Wer gerade vor der Frage steht, welcher Anwendungsfall zuerst drankommt, ob ein bestehendes Agentensystem die eigene Freigabeschwelle einhält, oder wie eine Einführung zu einem Workflow wird, der auch in drei Monaten noch läuft, kann direkt Kontakt aufnehmen. Eine kurze Beschreibung der aktuellen Situation und der anstehenden Entscheidung reicht als Ausgangspunkt für ein erstes Gespräch.