KI-Automatisierung im Unternehmen: Grundlagen und Einsatzfelder.

Was KI-Automatisierung im Unternehmen bedeutet

Klassische Automatisierung verarbeitet strukturierte Eingaben nach eindeutigen Regeln. KI erweitert diesen Ansatz um Aufgaben wie das Erkennen eines Anliegens im Telefongespräch, die Klassifikation einer freien E-Mail, die Suche in Unternehmenswissen oder das Extrahieren von Angaben aus unterschiedlich aufgebauten Dokumenten.

Der entscheidende Schritt folgt nach dem Modellaufruf: Das Ergebnis muss validiert, in einen fachlichen Zustand übersetzt und kontrolliert an ein Zielsystem übergeben werden. Erst die Verbindung aus KI-Funktion, Prozesslogik, Integration und Betrieb wird zu einer nutzbaren Unternehmenslösung. Ein Chatfenster oder eine einzelne Modellantwort ist noch keine Prozessautomatisierung.

KI-Automatisierung, Workflow und KI-Agent unterscheiden

Ein klassischer Workflow führt vorab festgelegte Schritte und Wenn-Dann-Regeln aus. KI-Automatisierung ergänzt diesen Ablauf dort, wo unstrukturierte Sprache, Texte oder Dokumente eingeordnet werden müssen. Ein KI-Agent plant dagegen Teile seines Vorgehens dynamisch und wählt innerhalb vorgegebener Grenzen Werkzeuge oder Zwischenschritte selbst aus.

Für Unternehmensprozesse ist nicht der höchste Autonomiegrad das Ziel. Entscheidend ist, dass Datenquellen, erlaubte Aktionen, Freigaben und Abbruchbedingungen zur Wirkung des Vorgangs passen. Viele belastbare Lösungen kombinieren deshalb einen kontrollierbaren Workflow mit einzelnen KI-Funktionen, statt den gesamten Prozess einem Agenten zu überlassen.

• Workflow: feste Zustände, Regeln und Übergaben für vorhersehbare Abläufe
• KI-Funktion: Klassifikation, Extraktion oder Formulierung bei unstrukturierten Eingaben
• KI-Agent: dynamische Auswahl von Werkzeugen und Zwischenschritten innerhalb begrenzter Rechte

Welche Prozesse sich für KI-Automatisierung eignen

Ein geeigneter Einstieg hat einen klaren Auslöser, wiederkehrende Fälle und ein prüfbares Ergebnis. Das Volumen allein entscheidet nicht. Ebenso wichtig sind stabile fachliche Kategorien, zugängliche Daten, eine verantwortliche Fachrolle und ein sinnvoller Weg für Ausnahmen.

Ein Prozess kann auch dann geeignet sein, wenn nicht jeder Fall automatisch abgeschlossen wird. Häufig entsteht der größte betriebliche Nutzen dadurch, dass Informationen vollständig vorbereitet, Standardfälle geroutet und schwierige Fälle mit besserem Kontext an Mitarbeitende übergeben werden.

• Wiederkehrender Eingang über Telefon, E-Mail, Dokument, Formular oder Systemereignis
• Definierbare Pflichtangaben, Kategorien, Qualitätskriterien und Folgeaktionen
• Verfügbare und ausreichend verlässliche Referenz- oder Beispieldaten
• Korrekturen sind schneller und sicherer als die vollständige manuelle Bearbeitung
• Klare fachliche Verantwortung für Ausnahmen, Freigaben und spätere Änderungen

Wann ein Anwendungsfall noch nicht bereit ist

KI ist kein Ersatz für fehlende Prozessentscheidungen. Wenn Teams denselben Eingang unterschiedlich bewerten, Pflichtdaten unbekannt sind oder niemand die Folgen einer falschen Zuordnung verantwortet, verlagert eine Automatisierung das Problem nur in Software.

Auch hochwirksame Einzelfallentscheidungen eignen sich selten als erster vollautomatischer Schritt. Beginnen Sie dort mit Assistenz: Das System sammelt Informationen, erstellt einen Vorschlag und dokumentiert die Grundlage. Die verbindliche Entscheidung bleibt zunächst bei einer zuständigen Person.

• Unklarer Prozessbeginn oder wechselnde Zielzustände
• Keine belastbare Quelle für korrekte Antworten oder Klassifikationen
• Seltene Fälle ohne ausreichende Testbasis
• Hohe rechtliche, finanzielle oder sicherheitsrelevante Wirkung ohne wirksame Kontrolle
• Fehlender Prozessverantwortlicher oder kein tragfähiger manueller Rückfallweg

Use Cases mit sieben Fragen priorisieren

Eine Priorisierung muss Nutzen und Umsetzbarkeit getrennt sichtbar machen. Ein häufig auftretender Vorgang kann wirtschaftlich interessant sein, aber wegen schlechter Daten oder weitreichender Systemrechte ungeeignet für den ersten Pilot. Umgekehrt kann ein kleiner, klarer Teilprozess die bessere Lernfläche bieten.

Bewerten Sie jeden Kandidaten mit derselben Skala und dokumentieren Sie die Begründung. So wird aus einer Ideensammlung ein vergleichbares Portfolio, das Fachbereich, IT, Datenschutz und Informationssicherheit gemeinsam prüfen können.

• Ziel: Welcher fachliche Zustand soll nach der Bearbeitung erreicht sein?
• Eingang: Welche Daten liegen vor, und wie stark unterscheiden sie sich?
• Prüfbarkeit: Woran lässt sich ein korrektes Ergebnis eindeutig erkennen?
• Wirkung: Welche Folgen hätte eine falsche Klassifikation, Extraktion oder Antwort?
• Integration: Welche Systeme müssen gelesen oder beschrieben werden?
• Ausnahmeweg: Wer übernimmt Fälle mit geringer Sicherheit oder unbekanntem Muster?
• Betrieb: Wer überwacht Qualität, Kosten, Änderungen und Störungen?

Zielarchitektur: KI erkennen lassen, Prozesse kontrollieren

Eine robuste Architektur trennt Eingang, KI-Verarbeitung, Validierung, Prozesssteuerung und führende Systeme. Diese Trennung begrenzt Wirkung: Ein Modell darf einen Vorschlag liefern, erhält aber nicht automatisch weitreichende Rechte in ERP, CRM oder DMS.

Validierung und Geschäftsregeln prüfen Format, Pflichtfelder, Referenzdaten und zulässige Zustandswechsel, bevor eine Aktion stattfindet. Technische Identitäten, Protokollierung, Wiederholungsregeln und Fehlerwarteschlangen sorgen dafür, dass Übergaben auch bei Störungen nachvollziehbar bleiben.

• Eingang: kontrollierte Übernahme von Gespräch, Nachricht, Dokument oder Ereignis
• Erkennung: Klassifikation, Extraktion, Formulierung oder Quellenabfrage innerhalb klarer Grenzen
• Validierung: Schema, Pflichtfelder, Referenzdaten, Plausibilität und Konfidenz prüfen
• Prozess: Regeln, Zustände, Freigaben, Ausnahmen und Eskalationen steuern
• Integration: begrenzte und beobachtbare Lese- oder Schreibaktionen in führenden Systemen
• Rückmeldung: Ergebnis, Fehler oder Klärungsbedarf nachvollziehbar an Menschen und Systeme übergeben

Beispielprozess: von der E-Mail zum geprüften Vorgang

Ein typischer Beispielprozess beginnt mit einer eingehenden E-Mail samt Anhang. Die KI klassifiziert das Anliegen und extrahiert vorgeschlagene Stammdaten. Eine Validierung gleicht Kundennummer, Pflichtfelder und zulässige Werte mit dem führenden System ab. Nur ein vollständiger, plausibler Standardfall darf den nächsten Status erreichen.

Fehlen Angaben oder widersprechen sich Daten, entsteht kein stiller Fehler im ERP. Der Vorgang wechselt in eine Klärungswarteschlange. Die Prüfansicht zeigt Originalnachricht, extrahierte Werte, unsichere Felder und die geplante Folgeaktion. Nach Korrektur kann der Workflow kontrolliert fortgesetzt werden; jede Übergabe bleibt protokolliert.

Human-in-the-Loop richtig gestalten

Menschliche Kontrolle sollte nicht pauschal nach jedem Schritt stattfinden. Sie gehört gezielt an Stellen mit Unsicherheit, hoher Wirkung oder fachlicher Verantwortung. Dazu zählen beispielsweise rechtlich relevante Kommunikation, kostenwirksame Freigaben oder sensible Einzelfallentscheidungen.

Eine gute Prüfansicht zeigt Quelle, erkannten Inhalt, offene Unsicherheit und die Wirkung der Freigabe. Mitarbeitende müssen korrigieren, ablehnen oder zurückstellen können, ohne den gesamten Vorgang neu aufzubauen. Korrekturen sollten außerdem als auswertbares Signal in die Qualitätsprüfung einfließen, statt in freien Notizen zu verschwinden.

Pilotieren, ohne eine Demo mit Produktion zu verwechseln

Ein Prototyp beantwortet eine technische Frage: Kann das System die vorgesehenen Eingänge grundsätzlich verarbeiten? Ein Pilot beantwortet eine betriebliche Frage: Funktioniert der begrenzte Ablauf mit realen Rollen, Systemen, Ausnahmen und Kontrollen zuverlässig genug für den Alltag? Erst der Pilot liefert eine Grundlage für die Entscheidung über den Regelbetrieb.

Legen Sie vor dem Test fest, welche Fallgruppen enthalten sind, welche bewusst ausgeschlossen bleiben und bei welchem Ergebnis der Versuch beendet oder angepasst wird. Testdaten müssen neben typischen Fällen auch unvollständige, widersprüchliche, unbekannte und missbräuchliche Eingaben enthalten. Sonst wird nur die einfache Mitte des Prozesses geprüft.

• Fester fachlicher Scope und dokumentierte Nicht-Ziele
• Repräsentative Testfälle mit erwarteten Ergebnissen
• Getrennte Entwicklungs-, Test- und Produktivumgebung
• Begrenzte Berechtigungen und ein abschaltbarer Systemzugriff
• Vorab definierte Abbruch-, Freigabe- und Eskalationskriterien

Welche Kennzahlen den Betrieb wirklich erklären

Eine einzelne Modellgenauigkeit beschreibt noch keinen funktionierenden Prozess. Entscheidend ist, wie viele Vorgänge korrekt abgeschlossen, sinnvoll zur Prüfung übergeben oder wegen technischer Fehler unterbrochen werden. Messen Sie deshalb Modell-, Prozess- und Betriebsqualität getrennt.

Vergleichen Sie den neuen Ablauf mit einem dokumentierten Ausgangszustand. Eine niedrigere Bearbeitungszeit ist nur dann hilfreich, wenn Fehler, Nacharbeit und ungeklärte Fälle nicht gleichzeitig steigen. Die Kennzahlen müssen zu einer konkreten Entscheidung führen: weiter betreiben, Schwellenwert anpassen, Fallgruppe entfernen oder den Prozess neu gestalten.

• Fachliche Trefferquote je Fallgruppe statt nur ein globaler Durchschnitt
• Anteil automatisch abgeschlossener, geprüfter, korrigierter und abgebrochener Vorgänge
• Nacharbeitszeit und häufigste Korrekturgründe
• Fehler je Systemübergang sowie Zeit bis zur Erkennung und Behebung
• Kosten pro vollständig bearbeitetem Vorgang einschließlich Modell, Integration und Prüfung

Datenschutz, Sicherheit und Betrieb

Betriebsort und Modellname beantworten Sicherheitsfragen nicht allein. Entscheidend sind Zweckbindung, Datenminimierung, Zugriffskontrolle, technische Identitäten, Aufbewahrung, Protokollierung und eine klare Verantwortung für Änderungen und Vorfälle. Bei personenbezogenen Daten sind Rechtsgrundlage, Rollen, Empfänger und Löschkonzept im konkreten Prozess zu prüfen.

Auch die fachliche Qualität muss beobachtet werden. Eingänge und Daten ändern sich, Modelle oder Dienste erhalten Updates und Kategorien entwickeln sich weiter. NIST ordnet Governance, Kontextanalyse, Messung und Behandlung von Risiken als fortlaufende Funktionen über den Lebenszyklus ein; das BSI betont den Gesamtprozess von Daten und Modellen bis zum Betrieb. Regelmäßige Evaluation mit repräsentativen Fällen gehört deshalb zur Lösung und nicht in eine spätere Wartungsnotiz.

Standardprodukt, Plattform oder individuelle Integration?

Ein Standardprodukt passt, wenn Prozess, Datenquellen und Zielsysteme weitgehend dem vorgesehenen Funktionsumfang entsprechen. Eine Automatisierungsplattform bietet mehr Spielraum für Regeln und Konnektoren. Individuelle Entwicklung wird relevant, wenn fachliche Zustände, Berechtigungen, Datenmodelle oder Qualitätskontrollen unternehmensspezifisch sind.

Die Entscheidung sollte nicht nur Lizenzpreise vergleichen. Prüfen Sie Datenflüsse, Exportmöglichkeiten, Protokolle, Modellwechsel, Testbarkeit, Rollenmodell und den Aufwand für spätere Prozessänderungen. Eine schnelle Einführung ist kein Vorteil, wenn das Unternehmen kritische Logik oder Betriebsdaten nicht nachvollziehen und kontrolliert übertragen kann.

Vom Prozessproblem in den Regelbetrieb

Zuerst wird der reale Prozess mit Varianten, Daten, Entscheidungen und Risiken untersucht. Danach folgen Zielbild, Testkatalog und ein begrenzter Prototyp. Ein produktiver Pilot startet erst, wenn Schnittstellen, Berechtigungen, Prüfansicht, Fehlerweg und Verantwortlichkeiten festgelegt sind.

Der Pilot ist kein Endzustand. Vor dem Regelbetrieb braucht es eine ausdrückliche Betriebsentscheidung: Sind Qualitätsgrenzen erreicht, bleiben Risiken vertretbar, funktionieren Rückfallverfahren und übernimmt eine benannte Rolle Monitoring und Änderungen? Erst danach wird der Scope schrittweise erweitert.

• Prozess und Ausgangszustand dokumentieren
• Use Case anhand einheitlicher Kriterien priorisieren
• Zielarchitektur, Rechte und Ausnahmewege festlegen
• Prototyp mit repräsentativem Testkatalog evaluieren
• Begrenzten Pilot mit realen Rollen und Systemen betreiben
• Betriebsentscheidung treffen und Änderungen kontrolliert versionieren