KI-Automatisierung: sieben typische Fehler vor dem Livebetrieb

1. Fehler: Einen ungeklärten Prozess automatisieren

Eine Automatisierung beschleunigt auch falsche Regeln. Zeichne deshalb zuerst den heutigen Ablauf mit Auslöser, Eingaben, Entscheidungspunkten, Ausgaben und verantwortlichen Personen auf. Prüfe Häufigkeit, Fehlerkosten und Ausnahmen. Ein selten auftretender Vorgang mit vielen Einzelfallentscheidungen ist oft kein guter erster KI-Workflow.

Definiere außerdem ein messbares Ziel: beispielsweise weniger manuelle Zuordnung bei unveränderter Reklamationsquote. „Mehr Effizienz durch KI“ ist kein prüfbares Ziel. Vergleiche den Pilot mit einer Ausgangslage und berücksichtige neue Kontrollarbeit. Der Beitrag KI-Automatisierungsprojekt kalkulieren hilft bei Zeit und Kosten.

2. Fehler: Daten und Verantwortlichkeiten erst später klären

Erfasse vor dem Bau, welche Daten in jeden Schritt fließen, wo sie gespeichert werden, welche Unterauftragnehmer beteiligt sind und wann sie gelöscht werden. Personenbezogene Daten benötigen einen konkreten Zweck und eine passende Rechtsgrundlage. Ein Auftragsverarbeitungsvertrag ist dann relevant, wenn ein Anbieter personenbezogene Daten in der Rolle eines Auftragsverarbeiters verarbeitet; er ist keine pauschale Universalantwort für jeden KI-Einsatz.

Minimiere Daten: interne Kennungen statt Klarnamen, nur benötigte Spalten und getrennte Testdaten. Prüfe Tarif, Region, Aufbewahrung und Trainingseinstellungen des konkreten Dienstes. Consumer-Chat, Business-Workspace und API können unterschiedliche Bedingungen haben. Eine detaillierte Prüfliste bietet Kundendaten in KI-Tools.

3. Fehler: KI-Ausgaben direkt weiterverarbeiten

Ein Sprachmodell erzeugt wahrscheinliche Ausgaben; es garantiert weder Fakten noch ein gültiges Format. Behandle den Output technisch wie fremde Eingabe. Erlaube bei einer Klassifikation nur bekannte Kategorien. Prüfe bei JSON Pflichtfelder, Datentypen, Wertebereiche und maximale Länge. Inhalte für HTML, SQL, Dateipfade oder Befehle müssen zusätzlich sicher kodiert beziehungsweise von erlaubten Aktionen getrennt werden.

OWASP führt unzureichende Output-Behandlung als zentrales Risiko von LLM-Anwendungen. Das Problem wird größer, wenn die Ausgabe direkt E-Mails versendet, Daten löscht oder Code ausführt. Ein Formatcheck allein bestätigt zudem keine fachliche Richtigkeit. Für Aussagen und Entscheidungen brauchst du separate Plausibilitätsregeln, Quellen oder menschliche Freigabe.

Definiere für jede Prüfung, was bei einem Fehlschlag geschieht. Ein zweiter Modellaufruf mit demselben Inhalt ist keine verlässliche Validierung: Beide Antworten können denselben Fehler enthalten. Nutze stattdessen unabhängige Regeln, Referenzdaten oder eine qualifizierte Person. Speichere abgelehnte Fälle für das Testset, nachdem unnötige personenbezogene Angaben entfernt wurden. So lernt der Prozess aus realen Grenzfällen, ohne sie still zu überspringen.

4. Fehler: Nur den erfolgreichen Lauf planen

APIs liefern Timeouts, Limits und vorübergehende Fehler. Eingabedateien sind leer oder doppelt, ein Zielsystem ist nicht erreichbar. Lege für jeden Schritt fest: Wie lange warten, wie oft wiederholen, wann abbrechen und wer benachrichtigt wird? Wiederholungen müssen möglichst idempotent sein – derselbe Auftrag darf nicht zweimal eine Rechnung oder Kundenmail erzeugen.

Speichere einen eindeutigen Vorgangsschlüssel und den Bearbeitungsstatus. Fehlerhafte Fälle gehören in eine sichtbare Warteschlange mit verständlichem Grund, nicht in ein stilles Nirgendwo. Halte eine manuelle Ersatzroute bereit. „Fail closed“ ist bei riskanten Aktionen meist sicherer: Bei Unsicherheit stoppen statt ungeprüft fortfahren.

5. Fehler: Dem Modell zu viele Berechtigungen geben

Ein Workflow braucht nur die Werkzeuge und Daten, die für seinen engen Zweck notwendig sind. Verwende getrennte Konten, eingeschränkte API-Schlüssel und kleine erlaubte Aktionslisten. Ein Entwurfsassistent muss keine Nachricht selbst versenden können; ein Leseprozess benötigt kein Löschrecht.

Plane auch indirekte Prompt Injection ein. Ein Dokument oder eine Webseite kann Text enthalten, der das Modell zu einer unerwünschten Aktion bewegen soll. Markiere externe Inhalte als Daten, aber verlasse dich nicht allein auf diese Formulierung. Sicherheitsgrenzen müssen im Code und in Berechtigungen liegen. Das Modell darf keine Autorisierung ersetzen.

6. Fehler: Qualität, Kosten und Änderungen nicht überwachen

Protokolliere Zeitpunkt, Workflow- und Promptversion, Modell, Eingabetyp, Ergebnisstatus, Laufzeit, Token- oder Toolkosten und notwendige Korrektur – ohne unnötige sensible Inhalte in Logs zu kopieren. Definiere Warnschwellen: steigende Fehlerquote, ungewöhnliche Kosten, leere Ergebnisse oder wachsender manueller Rückstau.

Modelle, Schnittstellen und Datenquellen ändern sich. Ein Ablauf, der heute besteht, kann morgen andere Felder oder Ergebnisse liefern. Nutze ein festes Testset mit normalen Fällen und Grenzfällen und führe es nach relevanten Änderungen erneut aus. Dokumentiere Abhängigkeiten so, dass eine andere Person den Ablauf prüfen und abschalten kann; der Ratgeber KI-Workflows dokumentieren liefert die Struktur.

7. Fehler: Von der Demo direkt in den Livebetrieb gehen

Beginne mit historischen oder synthetischen Daten. Danach folgt ein Schattenbetrieb: Der Workflow erzeugt ein Ergebnis, aber ein Mensch führt die Aktion weiterhin aus und vergleicht beide Wege. Erst dann eignet sich ein begrenzter Pilot mit Freigabe. Lege vorab fest, welche Fehler zum sofortigen Stopp führen.

• Verantwortliche Person und Abschaltweg sind benannt.
• Datenschutz, Verträge und Berechtigungen wurden geprüft.
• Testset, Grenzfälle und Wiederholungslogik sind dokumentiert.
• Manuelle Route und Fehlerwarteschlange funktionieren.
• Qualitäts-, Kosten- und Sicherheitsgrenzen sind messbar.

Mehr Autonomie ist kein Selbstzweck. Wenn eine menschliche Freigabe günstig ist und einen großen Schaden verhindert, kann sie dauerhaft der wirtschaftlich bessere Prozess bleiben.