KI-Automatisierung: Definition, Einsatzmöglichkeiten, Grenzen und Umsetzung

KI-Automatisierung beginnt nicht mit einem Agenten

Ein Lieferant schickt ein Datenblatt als PDF. Ein Mitarbeiter liest Maße, Material und Artikelnummer heraus, ordnet das Produkt einer Kategorie zu, überträgt die Werte ins PIM und prüft anschließend den Import in den Shop. Ein Sprachmodell kann Teile dieser Arbeit beschleunigen. Es sollte aber weder die GTIN erfinden noch ungeprüft Preise überschreiben oder ein unvollständiges Produkt veröffentlichen.

Genau an dieser Stelle wird der Begriff KI-Automatisierung oft unscharf. Manche Anbieter meinen damit eine normale Automation mit einem einzelnen Modellaufruf. Andere sprechen von autonomen Agenten, obwohl ein Mensch jeden Schritt bestätigt. Für die Umsetzung ist der Name weniger wichtig als die Aufteilung der Verantwortung: Was interpretiert die KI? Welche Regeln bleiben fest programmiert? Welche Aktion darf das System ausführen? Und was passiert, wenn Eingaben fehlen oder ein Ergebnis falsch ist?

Was bedeutet KI-Automatisierung?

Klassische Automation führt vorher festgelegte Schritte aus: Wenn eine Bestellung bezahlt ist, wird ein definierter Status gesetzt. Wenn ein Pflichtfeld fehlt, stoppt der Import. Der gleiche Eingang führt unter den gleichen Bedingungen zum gleichen Ergebnis. Diese Berechenbarkeit ist kein Nachteil. Für Preise, Steuern, Berechtigungen, Grenzwerte und Buchungen ist sie meistens erwünscht.

KI kommt dort hinzu, wo Eingaben variieren oder eine Zuordnung nicht vollständig mit Regeln beschrieben werden kann. Ein Modell erkennt beispielsweise, dass „Außenmaterial 100 % Schurwolle“ im Lieferanten-PDF zum Attribut `Material` gehört. Es kann eine Service-E-Mail als Lieferproblem klassifizieren oder aus mehreren passenden Produkten eine begründete Vorauswahl erstellen. Das Ergebnis bleibt jedoch eine modellbasierte Ableitung und keine fest codierte Wahrheit.

Die Definition des EU AI Act beschreibt ein KI-System als maschinenbasiertes System, das mit unterschiedlichem Autonomiegrad arbeitet und aus Eingaben ableitet, wie es Ausgaben wie Vorhersagen, Inhalte, Empfehlungen oder Entscheidungen erzeugt. Erwägungsgrund 12 grenzt solche Systeme von einfacherer Software ab, die ausschließlich von Menschen definierte Regeln automatisch ausführt.^[1]

Diese rechtliche Definition beantwortet nicht, wie ein guter Commerce-Workflow gebaut wird. Die Europäische Kommission weist in ihren nicht bindenden Leitlinien selbst darauf hin, dass die Einordnung nicht mechanisch erfolgen kann und jedes System anhand seiner konkreten Merkmale geprüft werden muss.^[2]

Vier Stufen, die häufig verwechselt werden

Ein Agent ist damit keine Voraussetzung für KI-Automatisierung. Viele produktive Prozesse brauchen nur einen oder zwei eng begrenzte KI-Schritte in einem ansonsten deterministischen Workflow. Das ist oft leichter zu testen, günstiger zu betreiben und einfacher abzusichern.

Wo KI in einem Prozess sinnvoll arbeitet

Die OECD beschreibt KI-Systeme vereinfacht als Zusammenspiel aus Eingaben, einer operativen Logik und Ausgaben wie Empfehlungen, Vorhersagen oder Entscheidungen. Menschen oder Maschinen können anschließend auf diese Ausgaben reagieren.^[3]

Für Geschäftsprozesse ist diese Zerlegung hilfreich. Sie lenkt den Blick weg vom Modellnamen und hin zur Aufgabe. Ein KI-Schritt ist besonders plausibel, wenn der Prozess wiederholt auf variable Inhalte trifft, ein überprüfbares Ziel hat und ein falsches Ergebnis rechtzeitig erkannt oder folgenarm zurückgewiesen werden kann.

• Freitext, E-Mails, PDFs, Tabellen oder Bilder verstehen und strukturieren.
• Anfragen, Dokumente, Produkte oder Fehlerfälle einer vorgegebenen Klasse zuordnen.
• Felder und Beziehungen aus ungleich aufgebauten Quellen extrahieren.
• Entwürfe für Produkttexte, Antworten oder Zusammenfassungen aus freigegebenen Quellen erzeugen.
• Passende Produkte oder nächste Bearbeitungsschritte vorschlagen und begründen.
• Abweichungen oder ungewöhnliche Fälle zur Prüfung markieren.

KI ist dagegen kein Ersatz für vorhandene APIs, eindeutige Datenbankabfragen oder stabile Geschäftsregeln. Der aktuelle Lagerbestand gehört aus dem ERP oder Shop gelesen. Die Mehrwertsteuer wird berechnet. Eine Retourenfrist wird anhand von Datum und Vertragsregeln geprüft. Ein Modell kann die Absicht einer Kundenanfrage erkennen, sollte aber keine verbindliche Frist raten.

Fünf sinnvolle Beispiele im E-Commerce

Lieferantendaten in Produktdaten überführen

Die KI erkennt Tabellen, Feldnamen und beschreibende Angaben in unterschiedlichen Dokumenten. Feste Logik prüft Datentypen, erlaubte Einheiten, GTIN-Prüfziffern, Pflichtfelder und vorhandene Kategorien. Unsichere Zuordnungen landen in einer Freigabemaske; erst geprüfte Daten werden ins PIM geschrieben.

Service-Anfragen vorbereiten oder bearbeiten

Ein Modell klassifiziert die Anfrage und extrahiert Bestellnummer, Produkt und Anliegen. Der Workflow ruft den echten Bestellstatus ab und prüft die Identität sowie erlaubte Aktionen. Eine Antwort kann automatisch entstehen; Adressänderung, Erstattung oder Storno folgen aber festen Regeln und benötigen je nach Risiko eine Freigabe.

Produkte beraten statt nur Schlagwörter suchen

Eine Produktberatung übersetzt einen Bedarf wie „leichter Wanderschuh für breite Füße und nasses Gelände“ in überprüfbare Kriterien. Suche und Filter arbeiten mit Katalogattributen, Bestand und Preisen. Das Sprachmodell formuliert Rückfragen und Begründungen, darf fehlende Produkteigenschaften aber nicht ergänzen.

Bestellungen aus E-Mails und PDFs erfassen

Im B2B-Handel kann KI Positionen, Mengen, Einheiten und Lieferhinweise aus freien Bestellungen lesen. Kundenkonto, Vertragsprodukte, Preise, Kreditlimit und Verfügbarkeit kommen aus den führenden Systemen. Uneindeutige Artikel oder abweichende Konditionen werden nicht stillschweigend übernommen, sondern zur Klärung vorgelegt.

Feed- und Listing-Fehler priorisieren

Ein Modell kann Fehlermeldungen verschiedener Marktplätze bündeln, Ursachen beschreiben und eine Korrektur vorschlagen. Die eigentliche Änderung wird gegen Kanalspezifikation, interne Datenquelle und Veröffentlichungsregeln geprüft. Damit hilft KI bei der Interpretation, während die Datenhoheit im PIM oder Shop bleibt.

Der vertikale Leitfaden KI-Automatisierung im E-Commerce ordnet diese und weitere Prozesse entlang der Commerce-Wertschöpfungskette ein – von Produktdaten und Beratung bis zu Service, Bestellungen und Backoffice.

Eine produktionsfähige KI-Automatisierung besteht aus mehr als einem Prompt

Eine Demo beginnt oft mit Eingabe und Modellantwort. Ein produktives System braucht davor und danach weitere Schichten. Die genaue Architektur hängt vom Prozess ab, aber die folgende Reihenfolge deckt die wichtigsten Verantwortlichkeiten ab.

1. Trigger festlegen: Ereignis, Zeitplan, Datei, Nachricht oder manueller Start.
2. Kontext abrufen: nur die benötigten Daten aus Shop, ERP, PIM, CRM oder Wissensquellen lesen.
3. Deterministisch vorprüfen: Pflichtfelder, Berechtigungen, Grenzwerte und bekannte Ausschlussregeln anwenden.
4. KI-Aufgabe eng definieren: klassifizieren, extrahieren, zusammenfassen, entwerfen oder eine begrenzte Auswahl treffen.
5. Ausgabe validieren: Schema, Datentypen, Referenzen und fachliche Regeln prüfen.
6. Risikoabhängig freigeben: sichere Standardfälle automatisch weiterführen, unsichere oder folgenreiche Fälle vorlegen.
7. Aktion ausführen: mit einer klar begrenzten Systemidentität schreiben oder einen Folgeprozess anstoßen.
8. Betrieb beobachten: Ergebnisqualität, menschliche Korrekturen, Kosten, Laufzeit, Fehler und Wiederholungen erfassen.

Das NIST AI Risk Management Framework verlangt keinen bestimmten technischen Stack. Es fordert jedoch, Geschäftskontext, Aufgaben, Wissensgrenzen, menschliche Aufsicht und erwartete Fehlerkosten zu dokumentieren. Systeme sollen vor der Einführung und regelmäßig im Betrieb getestet werden; auch tragfähige Alternativen ohne KI gehören in die Entscheidung.^[4]

Welche Prozesse eignen sich für KI-Automatisierung?

Ein geeigneter Prozess ist weder vollständig chaotisch noch bereits mit drei einfachen Regeln gelöst. Er hat ein wiederkehrendes Ziel, genügend digitale Beispiele und eine verantwortliche Fachseite. Variable Eingaben verursachen heute Aufwand, aber die erlaubten Ergebnisse und Fehlerfolgen lassen sich trotzdem beschreiben.

Ein hilfreicher Startpunkt ist ein klar abgegrenzter Teilprozess. Nicht „Kundenservice automatisieren“, sondern „deutschsprachige Lieferstatusanfragen mit eindeutig verifizierter Bestellnummer beantworten“. Diese Grenze liefert Testfälle, Rechte, Metriken und einen realistischen Fallback.

Der vorhandene KI-Readiness-Check prüft die organisatorische und technische Ausgangslage. Er ersetzt keine Prozessanalyse, zeigt aber, ob Daten, Governance und Betrieb für einen Pilot bereits tragfähig sind.

Was nicht oder nicht vollständig automatisiert werden sollte

Autonomie sollte sich nach der möglichen Folge eines Fehlers richten, nicht nach der sprachlichen Qualität einer Modellantwort. Ein System darf sehr überzeugend formulieren und trotzdem die falsche Produktvariante, Vertragsklausel oder Ursache ausgewählt haben.

• Entscheidungen mit hohen rechtlichen, finanziellen oder sicherheitsbezogenen Folgen ohne wirksame Kontrolle.
• Prozesse, deren Regeln, Eigentümer und gewünschtes Ergebnis intern ungeklärt sind.
• Schreibzugriffe mit breiten Administratorrechten, obwohl eine engere Service-Identität möglich wäre.
• Fakten, Preise, Bestände oder Produktmerkmale aus dem Modell ableiten, wenn ein führendes System existiert.
• Automatische Veröffentlichung, wenn Quellenbezug, Validierung oder Rücknahmeweg fehlen.
• Vollständige Autonomie als Ziel definieren, obwohl Assistenz oder Teilautomatisierung wirtschaftlicher wäre.

Auch eine menschliche Freigabe löst das Problem nicht automatisch. Das NIST-Profil für generative KI beschreibt Automation Bias: Menschen können Modellergebnissen übermäßig vertrauen, gerade wenn diese konsistent und professionell wirken. Eine Freigabemaske muss deshalb Quellen, Unsicherheit und die entscheidenden Prüfwerte sichtbar machen – nicht nur einen grünen Bestätigungsbutton.^[5]

Von der Idee zur betriebenen Automation

1. Den Ist-Prozess und die Ausnahmen erfassen

Dokumentiert werden Eingang, Bearbeitungsschritte, Systeme, Rollen, Volumen, Wartezeiten, Nacharbeit und bekannte Sonderfälle. Erst danach lässt sich erkennen, ob KI eine Lücke schließt oder nur einen schlechten Prozess schneller macht.

2. Den KI-Anteil bewusst klein schneiden

Die erste Version sollte eine konkrete Aufgabe lösen und eine klare Nicht-Zuständigkeit haben. Beispiel: Attribute aus Datenblättern vorschlagen, aber keine Produkte veröffentlichen. Ein enger Umfang verkürzt nicht nur die Entwicklung, sondern macht Fehler messbar.

3. Mit repräsentativen Fällen testen

Ein Testsatz braucht normale Fälle, schwierige Formate, fehlende Angaben, Widersprüche und Beispiele, die bewusst abgelehnt werden müssen. Der Pilot ist erst aussagekräftig, wenn er nicht nur die zuvor ausgewählten Erfolgsbeispiele verarbeitet.

4. Aktionen und Freigaben nach Risiko staffeln

Lesen, Entwurf erzeugen, Datensatz vorbereiten, schreiben und finanziell wirksame Aktion sind unterschiedliche Rechte. Diese Stufen sollten technisch getrennt und pro Anwendungsfall vergeben werden.

5. Wirkung und Betrieb gemeinsam messen

Gesparte Bearbeitungszeit allein reicht nicht. Relevant sind auch Akzeptanzrate, Korrekturaufwand, kritische Fehler, Eskalationen, Durchsatz, Laufzeit und Kosten pro Fall. Wenn Mitarbeitende jede Ausgabe neu prüfen oder Fehler mühsam suchen müssen, wurde Arbeit verschoben statt eingespart.

Woran eine gute KI-Automatisierung zu erkennen ist

Eine gute Automation ist nicht die mit dem autonomsten Agenten. Sie erreicht ein definiertes Prozessergebnis innerhalb vereinbarter Qualitäts-, Kosten- und Risikogrenzen. Die passenden Kennzahlen hängen vom Anwendungsfall ab.

• Fachliche Trefferquote oder Anteil vollständig korrekter Datensätze.
• Anteil der Vorschläge, die ohne Änderung akzeptiert werden.
• Menschliche Bearbeitungs- und Eskalationsquote.
• Zeit vom Eingang bis zum abgeschlossenen Prozess.
• Kritische Fehler, falsch ausgeführte Aktionen und sicher abgefangene Fälle.
• Modell-, Infrastruktur- und Betriebskosten pro verarbeitetem Fall.
• Stabilität nach Änderungen an Modell, Prompt, Datenquelle oder Zielsystem.

Vor dem Go-live wird festgelegt, welcher Wert gut genug ist und bei welchem Signal die Automation begrenzt oder abgeschaltet wird. Ohne diese Grenze bleibt „funktioniert meistens“ eine Demo-Beobachtung und keine Betriebsvereinbarung.