Der Prototyp überzeugt in der Demo, und drei Monate später nutzt ihn niemand mehr. Das liegt selten am Modell. Die heutigen Sprachmodelle sind für die meisten Aufgaben im Mittelstand gut genug – gescheitert wird an allem, was um das Modell herum fehlt.

Ein typischer Verlauf: Ein Betrieb möchte eingehende Kundenanfragen per KI vorsortieren und mit einem Antwortentwurf versehen. Der Prototyp ist nach zwei Wochen fertig und beeindruckt in der Vorführung mit zehn ausgesuchten E-Mails. Im Alltag kommen Anfragen mit Anhängen, auf Englisch, als Weiterleitung mit fünf Zitatebenen, oder es sind gar keine Anfragen, sondern Rechnungen. Die Kolleginnen korrigieren anfangs geduldig, dann immer seltener – und irgendwann sortieren sie wieder von Hand.

Was in der Demo fehlt

Eine Demo läuft auf ausgewählten Beispielen. Der Betrieb liefert Sonderfälle:

  • Unvollständige Daten: fehlende Kundennummern, veraltete Stammdaten, Dokumente in fünf Formaten
  • Unerwartete Eingaben: alles, woran beim Bau niemand gedacht hat
  • Andere Nutzung: Kolleginnen und Kollegen, die den Ablauf anders verwenden als geplant

Ohne definierte Fehlerbehandlung bricht der Ablauf beim ersten Sonderfall ab – und wird umgangen. Eine Lösung, der man nicht vertraut, wird nicht genutzt, selbst wenn sie in 90 Prozent der Fälle richtig liegt.

Drei Fragen vor dem Prototyp

Wer betreibt die Lösung nach dem Projekt? Jemand muss merken, wenn sie schlechter wird, Rückmeldungen sammeln und Anpassungen veranlassen. Ist diese Rolle nicht besetzt, verwaist die Lösung mit dem Projektende.

Woher kommen die Daten dauerhaft? Für die Demo wurden Beispieldaten von Hand exportiert. Im Betrieb braucht es eine stabile Anbindung an das Postfach, das ERP oder die Ablage – mit Zugangsdaten, die nicht an einer Person hängen.

Was passiert, wenn die KI unsicher ist? Eine gute Lösung erkennt Fälle, in denen sie danebenliegen könnte, und gibt sie an einen Menschen weiter, statt zu raten. Diese Weiterleitung muss so bequem sein, dass sie auch genutzt wird.

Den Erfolg vorher festlegen

Viele Prototypen enden ohne klares Urteil, weil nie festgelegt wurde, was „funktioniert“ bedeutet. Legen Sie vor dem Start eine messbare Größe fest, zum Beispiel:

  • Anteil der Anfragen, die ohne Korrektur richtig einsortiert werden
  • Zeit von Eingang bis Antwort
  • Anzahl der Fälle, die zurück an einen Menschen gehen

Messen Sie den heutigen Stand vorher. Nur dann lässt sich nach dem Test sagen, ob sich die Lösung lohnt – oder ob sie beendet werden sollte. Auch das ist ein gutes Ergebnis, wenn es früh kommt.

Die laufenden Kosten mitdenken

Ein Prototyp kostet einmal Entwicklungszeit. Der Betrieb kostet dauerhaft: Nutzungsgebühren für das Sprachmodell, die mit dem Volumen steigen, Pflege der Anbindungen bei Updates und etwas Zeit für die fachliche Betreuung. Diese Kosten sind meist überschaubar, sollten aber vor der Entscheidung auf dem Tisch liegen.

Checkliste

  1. Messbares Ziel und heutigen Ausgangswert festhalten
  2. Verantwortliche Person für den Betrieb benennen
  3. Dauerhafte Datenquelle klären, nicht nur einen Export
  4. Weg für unsichere Fälle festlegen
  5. Mit echten, ungefilterten Daten testen – auch mit den unangenehmen
  6. Laufende Kosten abschätzen

Ein Prototyp, der diese Punkte beantwortet, hat gute Chancen, produktiv zu werden. Einer ohne Antworten bleibt eine Demo.