KI-Pilotprojekt im Mittelstand: Klein starten, belastbar entscheiden

01 · Der richtige Startpunkt

Ein Pilot braucht einen Vorgang, kein Schlagwort.

„Wir möchten KI im Kundenservice nutzen“ ist noch kein Pilotumfang. Darin können E-Mail-Eingang, Wissenssuche, Klassifikation, Antwortentwurf, Kulanzentscheidung und Dokumentation stecken. Jeder Teil nutzt andere Quellen, hat andere Fehlerfolgen und braucht eine andere Freigabe. Ein kleiner Pilot wählt deshalb einen überprüfbaren Ausschnitt: zum Beispiel eingehende Serviceanfragen einer bestimmten Art erfassen, vorhandene Referenzen prüfen und eine Vorgangsakte für die zuständige Sachbearbeitung vorbereiten.

Die Grenze sollte so formuliert sein, dass Anfang und Ende beobachtbar sind. Der Eingang kann eine definierte E-Mail mit bestimmten Pflichtangaben sein. Der Endzustand kann eine vorbereitete Akte mit Quelle, Zuordnung, offenen Fragen und Status sein. Preiszusagen, rechtliche Bewertungen oder endgültige Kundenkommunikation bleiben außerhalb, wenn sie eine menschliche Entscheidung erfordern. Diese Nicht-Ziele sind kein Mangel. Sie verhindern, dass ein Versuch still zu einem unkontrollierten Betriebsprozess anwächst.

Hilfreich ist ein Prozess, der häufig genug vorkommt, um unterschiedliche Fälle zu kennen, dessen Fehler aber im Pilot begrenzt bleiben. Ein seltener Sonderfall liefert kaum Lernmaterial. Ein hochkritischer Vorgang mit unmittelbaren Folgen ist als erster Test dagegen oft unnötig riskant. Der Pilot sollte eine reale betriebliche Frage beantworten, ohne dafür gleich den gesamten Ablauf umzubauen.

Für die Auswahl können zwei oder drei Kandidaten nebeneinander betrachtet werden. Entscheidend sind nicht nur erwarteter Nutzen oder technische Attraktivität. Prüffragen sind auch: Ist der heutige Ablauf überhaupt bekannt? Sind Fälle und Quellen zugänglich? Kann eine Fachrolle zeitnah prüfen? Bleibt ein Fehler vor einer Kunden-, Zahlungs- oder Systemwirkung erkennbar? Ein weniger spektakulärer Vorgang mit klaren Grenzen liefert häufig die bessere Entscheidungsgrundlage als ein großer Anwendungsfall mit vielen ungeklärten Abhängigkeiten.

Der ausgewählte Fall wird anschließend in einem Satz beschrieben: „Wenn dieser definierte Eingang vorliegt, bereitet der Pilot auf Basis dieser Quellen genau dieses Arbeitsergebnis für diese Fachrolle vor.“ Lässt sich der Satz nicht ohne mehrere „und außerdem“ formulieren, ist die Grenze meist noch zu weit. Dann wird geteilt, bevor Aufwand, Anbieter oder Modell verglichen werden.

02 · Vor der Technik

Quellen, Regeln und Ausnahmen bestimmen die Machbarkeit.

Ein Modell kann nur mit dem arbeiten, was im Prozess verfügbar und freigegeben ist. Deshalb beginnt die Datenprüfung nicht mit einer großen Datenplattform. Sie beginnt mit einer einfachen Liste: Welche Informationen kommen am Eingang an? Welche Quelle gilt als maßgeblich? Welche Felder müssen vorhanden sein? Was geschieht bei Widersprüchen? Welche Inhalte dürfen nicht in den Pilot gelangen?

Gerade in gewachsenen Unternehmen liegen Regeln verteilt: ein Teil im ERP, ein Teil in Dokumentvorlagen, ein Teil in E-Mails und ein Teil im Erfahrungswissen einzelner Mitarbeitender. Der Pilot muss diese Lücken nicht vollständig beseitigen. Er muss sie sichtbar machen. Wenn eine Entscheidung nur durch stilles Erfahrungswissen möglich ist, gehört sie zunächst in die Fachfreigabe und nicht in eine automatisierte Regel.

Auch die Systemgrenzen gehören dazu. Muss der Pilot nur lesen oder auch schreiben? Gibt es eine Testumgebung? Lassen sich Zugriffe auf die wirklich benötigten Daten beschränken? Wie werden Änderungen an Regeln oder Quellen freigegeben? Eine technisch elegante Lösung ist nicht belastbar, wenn sie auf unklaren Berechtigungen oder wechselnden Dokumentständen beruht.

Entscheidungstool · Pilot-Gate

Fünf Prüffelder vor einer Umsetzungszusage.

Die Matrix ist kein Punktesystem und keine Konformitätsprüfung. Sie zeigt, ob der nächste sinnvolle Schritt bereits ein technischer Pilot ist oder zunächst Prozessklärung benötigt.

03 · Verantwortung

Der Mensch im Prozess braucht eine benannte Rolle.

„Human in the loop“ klingt beruhigend, bleibt aber unbrauchbar, solange nicht feststeht, welcher Mensch was prüft. Eine Fachfreigabe braucht mindestens eine zuständige Rolle, einen konkreten Prüfgegenstand und eine Folge. Prüft die Sachbearbeitung nur Vollständigkeit? Darf sie eine Zuordnung ändern? Muss sie jede Ausgabe freigeben oder nur markierte Ausnahmen? Wer entscheidet bei wiederkehrenden Fehlern, ob der Pilot pausiert?

Die Rolle sollte zum bestehenden Betrieb passen. Ein Pilot darf nicht davon abhängen, dass eine einzelne technisch versierte Person dauerhaft jede Ausnahme auffängt. Ebenso wenig sollte die technische Umsetzung fachliche Regeln erfinden. Operations oder Fachabteilung verantworten die sachliche Entscheidung. Technik verantwortet Zugriffe, Ablauf, Protokollierung und den sicheren Zustand. Geschäftsführung oder Projektverantwortung entscheidet über Umfang und Ausbau. Kleine Unternehmen können mehrere Rollen in einer Person bündeln; die Verantwortungen sollten trotzdem getrennt beschrieben werden.

Diese Trennung verbessert auch die Bewertung. Wenn ein Ergebnis falsch ist, muss erkennbar sein, ob die Quelle fehlte, die Regel unklar war, das Modell ungeeignet reagierte oder die Freigabe nicht funktioniert hat. Ohne diese Zuordnung bleibt nur der pauschale Eindruck, die KI sei gut oder schlecht.

04 · Test und Abbruch

Erfolgskriterien allein reichen nicht.

Vor dem Start werden typische Normalfälle, Grenzfälle und bekannte Fehlerbilder zusammengestellt. Für jeden Fall braucht es ein erwartetes Ergebnis oder zumindest eine erwartete Reaktion: korrekt zuordnen, Rückfrage vorbereiten, an eine Rolle eskalieren oder bewusst keine Entscheidung treffen. Eine überzeugende Demo mit wenigen ausgewählten Beispielen ersetzt diesen Testkatalog nicht.

Ebenso wichtig sind Abbruchkriterien. Der Pilot sollte stoppen oder in manuelle Bearbeitung wechseln, wenn Quellen nicht erreichbar sind, Pflichtangaben fehlen, Ausgaben nicht nachvollziehbar sind oder ein Fehlerbild wiederholt auftritt. Für bereits erzeugte Zwischenergebnisse muss feststehen, ob sie verworfen, markiert oder manuell geprüft werden. Das schützt Folgesysteme und verhindert, dass ein Versuch unbemerkt produktive Wirkung entfaltet.

Gemessen werden nur Größen, die zum Prozess passen. Dazu können Vollständigkeit, Fehlzuordnung, notwendige Rückfragen, Eskalationen und Bearbeitungswege gehören. Ob daraus Zeitersparnis oder wirtschaftlicher Nutzen entsteht, lässt sich erst mit einem stabilen Vergleich und realen Betriebsdaten beurteilen. Ein Pilot sollte deshalb keine erfundene Rendite oder allgemeine Automatisierungsquote versprechen.

05 · Ausbauentscheidung

Das Ergebnis darf auch ein begründetes Nein sein.

Am Ende steht keine Präsentation, sondern eine Pilotakte. Sie hält Prozessgrenze, verwendete Quellen, Testfälle, Befunde, Fehler, Fachfreigaben, Abbruchweg und offene Voraussetzungen fest. Daraus entstehen drei mögliche Entscheidungen: begrenzt weiterarbeiten, zuerst Grundlagen verbessern oder den Ansatz verwerfen. Jede dieser Entscheidungen kann wirtschaftlich vernünftig sein.

Ein Ausbau ist erst sinnvoll, wenn die bisherige Grenze stabil ist. Dann werden zusätzliche Fälle, Systeme oder Schreibrechte einzeln geprüft. Gleichzeitig müssen Betrieb, Pflege und Änderungen geklärt werden: Wer aktualisiert Quellen? Wer testet eine neue Regel? Wie werden Zugänge entzogen? Welche Überwachung zeigt, dass der manuelle Rückfallweg nötig ist? Der Übergang vom Pilot zum Betrieb ist eine eigene Entscheidung und keine automatische Folge einer erfolgreichen Demo.

Wer diese Fragen früh beantwortet, startet nicht langsamer. Das Unternehmen vermeidet nur, technische Geschwindigkeit mit betrieblicher Reife zu verwechseln. Der Firmenanker-Arbeitsweg trennt deshalb Analyse, Pilot, Freigabe und Betrieb. Eine sichtbare Muster-Pilotakte zeigt, wie der dokumentierte Stand aussehen kann, ohne Kundenergebnisse oder Wirkung zu behaupten.