Fragen vor KI-Automation: Was Entscheider zuerst klären Fragen vor KI-Automation: Was Entscheider zuerst klären

Ein Lead-Scoring-System ordnet neue Kontakte nach ihrer erwarteten Relevanz. Das Vertriebsteam sieht trotzdem doppelte Datensätze, widersprüchliche Prioritäten und offene Aufgaben. Diese Szene ist bewusst beispielhaft; sie ist keine dokumentierte Kundenfallstudie.

Sie zeigt jedoch die richtige Prüfspur: Nicht allein das Modell entscheidet über die Qualität einer Automation. Belastbar wird der Ablauf erst, wenn Eingaben, Zuständigkeiten, Ausnahmen und Folgen geklärt sind. Vor der Freigabe sollten Verantwortliche deshalb weniger über einzelne Funktionen sprechen und genauer auf den gesamten Entscheidungsweg schauen.

Welche Entscheidung soll die KI vorbereiten?

Der Satz, ein Prozess solle automatisiert werden, ist zu ungenau. Zuerst braucht es ein klar beschriebenes Entscheidungsobjekt: Soll das System Informationen sortieren, eine Empfehlung ausgeben, eine Aufgabe zuweisen oder selbst eine geschäftliche Aktion auslösen?

Diese Abstufungen haben unterschiedliche Folgen. Eine priorisierte Aufgabenliste kann ein Mitarbeiter prüfen. Eine automatisch versandte Absage, Preisfreigabe oder Vertragsänderung lässt sich häufig nicht ebenso leicht zurückholen.

Für jeden Anwendungsfall sollten daher Zweck, Eingaben, Ausgabe und erlaubte Folgeaktion dokumentiert werden. Ebenso muss feststehen, welche Fälle ausdrücklich außerhalb des Einsatzbereichs liegen. Der freiwillige AI Risk Management Framework des NIST nennt dafür unter anderem klar dokumentierte Rollen, menschliche Aufsicht, regelmäßige Überprüfung und Verfahren für Fehler oder Vorfälle.

Wer darf freigeben, übersteuern und stoppen?

Eine verantwortliche Person auf einer Projektfolie reicht nicht. Der operative Ablauf braucht mindestens eine fachliche Verantwortung für das Ziel, eine Prozessverantwortung für Übergaben und Ausnahmen sowie eine technische Zuständigkeit für Konfiguration, Betrieb und Änderungen.

Hinzu kommt die Stop-Befugnis. Wer Auffälligkeiten erkennt, muss wissen, ob er einzelne Vorgänge zurückhalten, Regeln ändern oder das System vollständig anhalten darf. Eine menschliche Prüfung ohne Zugriffsrecht und ohne Autorität bleibt eine Beobachterrolle.

Für Hochrisiko-KI-Systeme verlangt Artikel 14 der EU-KI-Verordnung eine wirksame menschliche Aufsicht. Dazu gehören je nach Kontext auch das Verständnis der Systemgrenzen sowie Möglichkeiten, Ausgaben zu übergehen oder den Betrieb zu unterbrechen. Diese Vorgaben gelten nicht pauschal für jedes CRM-Scoring. Risikoklasse und Pflichten müssen anhand des konkreten Einsatzes geprüft werden.

Auch der zeitliche Geltungsbereich ist differenziert. Die EU-Kommission dokumentiert die stufenweise Anwendung der Verordnung und bestehende Ausnahmen. Eine allgemeine Governance-Empfehlung ersetzt deshalb keine rechtliche Einordnung des jeweiligen Systems.

Welche Daten dürfen den Prozess auslösen?

Ein gutes Modell kann einen unklaren Datenfluss nicht reparieren. Im Lead-Management muss beispielsweise feststehen, welche Quelle einen neuen Datensatz anlegen darf, wie Dubletten erkannt werden und wie lange ein Signal als aktuell gilt.

Ein belastbarer Datenrahmen beantwortet mindestens folgende Punkte:

• Welche Quellen und Felder sind für die Entscheidung zugelassen?
• Wer korrigiert fehlende, veraltete oder widersprüchliche Angaben?
• Welche Regel verhindert doppelte Datensätze und parallele Bearbeitung?
• Was geschieht, wenn Pflichtinformationen fehlen?
• Welche Rollen dürfen Daten einsehen, ergänzen oder löschen?

Datenschutz-, Vertrags- und Zugriffsfragen gehören dabei in die fachliche Prüfung. Sie sollten nicht erst auftauchen, wenn der Workflow bereits produktiv arbeitet.

Wie behandelt der Workflow Unsicherheit und Ausnahmen?

Automationskonzepte beschreiben häufig den Idealfall: Ein Signal trifft ein, wird bewertet und löst eine passende Aktion aus. Im Betrieb sind jedoch gerade die uneindeutigen Fälle entscheidend.

Der Prozess muss deshalb auch das Nicht-Handeln beherrschen. Liegt die Bewertung unterhalb eines geprüften Schwellenwerts, widersprechen sich Datenquellen oder weicht ein Fall von den freigegebenen Parametern ab, sollte keine unkontrollierte Folgeaktion entstehen.

Im Lead-Beispiel könnte ein System eindeutige Kontakte priorisieren, während unvollständige Datensätze in eine Prüfliste wechseln. Strategisch wichtige oder ungewöhnliche Fälle gehen an eine benannte Rolle. Welche Rolle das ist, hängt vom Unternehmen und vom konkreten Prozess ab; eine feste Eskalation an Vertrieb oder Marketing ist keine allgemeingültige Lösung.

Auch Zeit gehört zur Ausnahmelogik. Bleibt eine Prüfung zu lange offen, braucht es eine erneute Zuweisung, eine Eskalation oder einen definierten Abbruch. Sonst verschiebt die Automation den Rückstau lediglich an eine andere Stelle.

Woran lässt sich ein belastbarer Betrieb erkennen?

Mehr verarbeitete Datensätze belegen noch keine bessere Entscheidung. Vor dem Pilotbetrieb braucht es eine Baseline: Wie lange dauert der bestehende Ablauf, wie häufig wird nachgearbeitet und welche Fehler treten bereits ohne KI auf?

Danach lassen sich passende Messgrößen auswählen. Bei einer Lead-Qualifizierung können dazu falsch priorisierte Kontakte, manuelle Korrekturen, Bearbeitungszeit, übersteuerte Empfehlungen und liegen gebliebene Aufgaben gehören. Die Auswahl richtet sich nach dem Geschäftsziel und dem möglichen Schaden einer Fehlentscheidung.

Wo es der Prozess erlaubt, kann das System zunächst im Hintergrund mitlaufen, ohne Aktionen auszulösen. Die Ergebnisse werden mit realen Entscheidungen verglichen. Erst wenn auch Ausnahmefälle geprüft wurden, sollte die Automation schrittweise mehr Befugnisse erhalten.

Ändern sich Modell, Datenquelle, Schwellenwert oder Folgeaktion wesentlich, ist eine erneute Prüfung sinnvoll. Eine einmalige Pilotfreigabe ist kein dauerhafter Qualitätsnachweis.

Welche Dokumentation braucht die KI-Automation?

Governance besteht nicht aus einer einzelnen Richtlinie. Sie muss sich in Berechtigungen, Prüfungen, Protokollen und Änderungswegen wiederfinden. Die internationale Norm ISO/IEC 42001 beschreibt dafür ein organisationsweites Managementsystem mit Richtlinien, Verantwortlichkeiten, Risikobehandlung, Leistungsbewertung und fortlaufender Verbesserung. Sie ersetzt keine gesetzlichen Vorgaben, bietet aber eine belastbare Struktur.

Für einen einzelnen Workflow sollte die Dokumentation zumindest Zweck und Grenzen des Systems, Datenquellen, Rollen, Freigaben, Schwellenwerte, Testfälle und Abschaltverfahren enthalten. Änderungen an Modellen oder Regeln müssen nachvollziehbar bleiben. Dasselbe gilt für übersteuerte Ausgaben, Störungen und Beschwerden.

Diese Unterlagen sind kein Selbstzweck. Sie verkürzen die Fehlersuche und verhindern, dass kritisches Prozesswissen nur bei einzelnen Projektbeteiligten liegt.

Welche Fragen gehören in die Freigaberunde?

1. Welche geschäftliche Entscheidung soll das System unterstützen oder ausführen?
2. Welche Aktionen darf es ohne zusätzliche Freigabe auslösen?
3. Welche Fehler sind möglich und welche Folgen hätten sie?
4. Wer trägt die fachliche Verantwortung und wer darf den Betrieb stoppen?
5. Welche Datenquellen sind zugelassen und wie werden Qualitätsprobleme behandelt?
6. Wann muss das System einen Fall zurückhalten oder an einen Menschen übergeben?
7. Welche Protokolle werden für Prüfung, Beschwerden und Fehleranalyse benötigt?
8. Mit welchen Ausgangswerten und Qualitätskriterien wird der Pilot bewertet?
9. Wie funktionieren Rücknahme, Wiederanlauf und erneute Freigabe nach Änderungen?
10. Welche rechtlichen oder branchenspezifischen Anforderungen gelten für diesen Einsatz?

Fehlen belastbare Antworten, ist weiteres Modell-Tuning verfrüht. Das Ziel ist nicht die größtmögliche Automatisierung, sondern eine kontrollierte Delegation: Das System übernimmt klar begrenzte Arbeit, während Verantwortung, Eingriffsrechte und Folgen beim Unternehmen bleiben.