Warum KI-Projekte nach dem Prototyp stehen bleiben

Demo und Betrieb. Eine Demo kann zeigen, ob ein Modell ein Dokument versteht oder eine verständliche Antwort formuliert. Ein produktiver Ablauf muss zeigen, ob die richtige Person das richtige Ergebnis rechtzeitig im richtigen System erhält. Dazu gehören auch Eingänge, die unvollständig, widersprüchlich oder außerhalb des vorgesehenen Umfangs sind.

Zwei Fragen. Schreiben Sie die beiden Fragen getrennt auf. „Kann das Modell eine Rechnung auslesen?“ ist ein technischer Versuch. „Kann unser Team Lieferantenrechnungen mit weniger Nacharbeit zuverlässig zur Freigabe bringen?“ ist eine betriebliche Frage. Für die zweite Frage müssen neben der Extraktion auch Zuordnung, Kontrollen, Zuständigkeiten und Schnittstellen geprüft werden.

Rahmenwerk. Das freiwillige NIST AI Risk Management Framework betrachtet Risiken über Entwicklung, Nutzung und Bewertung hinweg. Es ist keine DACH-Konformitätsbescheinigung. Für ein kleines Projekt lässt sich daraus eine nützliche Leitfrage ableiten: Welche Beobachtung fehlt noch zwischen dem vorgeführten Modellverhalten und dem zugesagten Geschäftsergebnis?

Die folgende Tabelle ordnet sechs Beobachtungen aus einem stockenden KI-Pilot je einer Diagnosefrage und dem nächsten sinnvollen Nachweis zu.

Beantworten Sie die Fragen mit einem konkreten Vorgang statt mit einem allgemeinen Ja oder Nein. „Es gibt Monitoring“ ist weniger aussagekräftig als die Beobachtung, dass eine fehlgeschlagene Übertragung innerhalb des vereinbarten Zeitraums in einer betreuten Liste auftaucht. Halten Sie fest, welche Konfiguration verwendet wurde, damit eine spätere Änderung die Beobachtung nicht stillschweigend entwertet.

Fachliche und technische Befugnis. Ein begeisterter Ersteller kann einen Prototyp betreiben, ohne später für die fachliche Qualität zuständig zu sein. Ein IT-Verantwortlicher kann wiederum die Plattform pflegen, ohne Preisregeln, Rechnungsfreigaben oder Kundenzusagen entscheiden zu dürfen. Diese Aufgaben müssen ausdrücklich zusammengeführt werden.

Benannte Rollen. Benennen Sie deshalb eine Person für das fachliche Ergebnis, eine für den technischen Betrieb und eine Vertretung. In einem kleinen Betrieb dürfen mehrere Rollen bei derselben Person liegen. Entscheidend ist, dass sie Zeit, Befugnisse und einen klaren Aufgabenbereich hat. Ein Name in einer Präsentation reicht nicht, wenn die Person keine Quellen ändern oder Ausnahmen bearbeiten darf.

Ende eines Vorgangs. Klären Sie auch das Ende eines Vorgangs. Ist eine Aufgabe abgeschlossen, sobald eine Antwort formuliert ist, erst nach Speicherung im CRM oder erst nach Annahme durch das Team? Eine gemeinsame Definition verhindert, dass Entwicklung und Fachbereich unterschiedliche Erfolge melden.

Übergabe. Machen Sie die Zuständigkeiten bei der Übergabe sichtbar, bevor die Person, die die Lösung ursprünglich gebaut hat, sich zurückzieht. Die übernehmende Person sollte wissen, wie sie die eingesetzte Version erkennt, offene Fälle findet und Hilfe erhält. Andernfalls können gewöhnliche Änderungen zu einer informellen Abhängigkeit von einem einzelnen, nicht verfügbaren Mitarbeiter führen.

Reale Eingänge. Ein Muster-PDF kann sorgfältig ausgewählt sein; der reale Eingang enthält möglicherweise gedrehte Scans, mehrere Dokumente in einer Datei und falsche Kundennummern. Ein Wissensassistent kann eine richtige Quelle finden, obwohl der anfragende Mitarbeiter sie nicht sehen darf. Ein Kalender kann einen freien Termin zeigen, während eine andere Person gleichzeitig bucht.

Testfälle. Erstellen Sie eine kleine Sammlung zulässiger Testfälle aus dem tatsächlichen Einsatzkontext. Ergänzen Sie absichtlich schwierige Fälle: fehlende Angaben, geänderte Stammdaten, widersprüchliche Quellen, eingeschränkte Rechte und einen nicht erreichbaren Dienst. Beschreiben Sie zuerst das erwartete Verhalten. Sonst lässt sich eine flüssige Antwort nachträglich zu leicht als Erfolg interpretieren.

Rahmenwerk. Das NIST-Profil für generative KI behandelt unter anderem Prüfungen vor dem Einsatz und den Umgang mit Risiken im Lebenszyklus. Es liefert keine universelle Erfolgsquote für Ihr Projekt. Die konkrete Fallauswahl und die Freigabegrenzen müssen zum eigenen Ablauf passen.

Kritische Fehler. Trennen Sie einen kritischen Fehler von einer gewöhnlichen Korrektur. Ein falsches Satzzeichen und die Offenlegung der Daten eines anderen Kunden sollten nicht in derselben durchschnittlichen Genauigkeitsquote verschwinden. Legen Sie Prüfkriterien fest, bevor Sie die Auswertung durchführen, und halten Sie die ungeklärten kritischen Fälle in der Freigabeentscheidung sichtbar.

Angenommen, ein Betrieb erhält monatlich 600 Serviceanfragen. Die bisherige Bearbeitung benötigt im Mittel sechs Minuten. In einer Vorführung erstellt der Assistent den Entwurf in wenigen Sekunden. Daraus lässt sich noch keine monatliche Ersparnis ableiten.

Für eine erfundene Kontrollrechnung betrachten wir 100 vergleichbare Anfragen. Die folgende Tabelle zeigt diese synthetische Rechnung nach Zahl der Fälle, menschlicher Bearbeitungszeit und Minuten insgesamt.

Die neue Gesamtzeit beträgt 60 × 3 + 25 × 6 + 15 × 9 = 465 Minuten statt 600 Minuten. Die beobachtungsbedürftige Annahme wäre damit 135 Minuten weniger je 100 Anfragen, nicht eine vollständige Automatisierung.

Kapazitätswert. Würde diese Verteilung bei 600 Anfragen gelten, ergäbe sich ein rechnerischer Kapazitätsgewinn von 13,5 Stunden. Bei angenommenen 40 Euro pro Stunde wären das 540 Euro Kapazitätswert. Davon sind Software, Wartung, Quellenpflege und Einführung noch nicht abgezogen. Die Werte sind synthetisch und keine Kundenergebnisse oder garantierten Personalkosteneinsparungen.

Diagnose. Die Diagnose könnte ergeben, dass die 15 schwierigen Fälle überwiegend Preiszusagen betreffen. Dann ist eine gezielte Grenze sinnvoller als ein allgemeiner Modellwechsel: Der Assistent bereitet solche Anfragen zur menschlichen Prüfung vor und behauptet keine Zusage. Der nächste Test prüft genau diese Änderung, einschließlich der zusätzlichen Übergabearbeit.

Arbeitsbedingungen. Das Team sollte außerdem prüfen, ob die Verbesserungen bei der Bearbeitungszeit unter normalen Arbeitsbedingungen bestehen bleiben. Eine prüfende Person, die den Versuch kennt, arbeitet möglicherweise anders als jemand, der das Werkzeug zum ersten Mal sieht. Bewahren Sie Auswertungszeitraum, Beteiligte und Fallmischung zusammen mit der Berechnung auf, damit das Ergebnis interpretierbar bleibt.

Was die Statistik erfasst. Ein grünes Dashboard ist nur so aussagekräftig wie seine Erfassung. Microsoft weist beispielsweise bei ereignisgesteuerten Copilot-Studio-Agenten darauf hin, dass ohne erfolgreich empfangene Auslösung keine Analysesitzung beginnt. Außerdem erscheinen Aktivitäten aus dem internen Testfenster nicht in der regulären Monitor-Auswertung. Microsoft-Dokumentation, geprüft am 26. September 2026.

Abgleich. Praktisch sollten Sie deshalb Eingang und Ausgang abgleichen. Wenn 100 Anfragen in einem Postfach liegen, aber nur 94 Vorgänge angelegt wurden, beantworten 94 erfolgreiche Ausführungen nicht die Frage nach den übrigen sechs. Eine kleine Abstimmungsliste kann diese Lücke sichtbar machen, ohne eine aufwendige neue Analyseplattform einzuführen.

Abbrüche. Dasselbe gilt für Abbrüche: Eine Person, die den Chat verlässt, hat ihr Anliegen nicht zwingend gelöst. Definieren Sie erfolgreiche Antworten, bestätigte Aktionen, menschliche Übergaben und offene Fälle getrennt. Erst dann können Sie die Zahlen sinnvoll mit dem ursprünglichen Ziel vergleichen.

Zuständigkeit für die Lücke. Vereinbaren Sie, wer der Lücke nachgeht. Ein Alarm ohne zuständige Person verschiebt einen unsichtbaren Fehler lediglich in einen unbeachteten Benachrichtigungskanal. Die Betriebsanweisung sollte benennen, was die Person prüft, wie der Fall nachgeholt und wie eine doppelte Verarbeitung vermieden wird.

Drei Möglichkeiten. Ein begrenzter technischer Fehler rechtfertigt oft eine gezielte Korrektur. Ein unklarer Prozess braucht zunächst eine fachliche Entscheidung. Fehlt nur eine Funktion, die das vorhandene System bereits unterstützt, kann dessen Einrichtung sinnvoller sein als eine zusätzliche Anwendung. Wenn der wirtschaftliche Nutzen auch unter realistischen Annahmen nicht trägt, ist ein begründeter Stopp ein brauchbares Projektergebnis.

Vor weiteren Arbeiten. Vereinbaren Sie vor weiteren Arbeiten eine konkrete Frage, ein begrenztes Budget und den erforderlichen Nachweis. Beispielsweise: „Die nächsten freigegebenen Testfälle sollen zeigen, ob die Zuordnung zum richtigen Kunden stabil funktioniert.“ Das ist prüfbarer als „Wir verbessern die KI noch etwas“.

Beim Beenden. Bewahren Sie beim Beenden eines Versuchs die gewonnenen Informationen auf: ungeeignete Daten, fehlende Schnittstellen, getestete Regeln und Gründe für die Entscheidung. Klären Sie außerdem, welche Konten, Kopien und laufenden Abonnements geschlossen werden. Ein Versuch sollte nicht als unbeachteter Parallelbetrieb weiterlaufen.

Bereits entstandene Kosten. Beurteilen Sie die Entscheidung zum Beenden nicht nach dem bereits ausgegebenen Betrag. Die nützliche Frage ist, ob die nächste vorgeschlagene Arbeit einen vertretbaren Zweck hat und ein Ergebnis liefert, das die Entscheidung ändern kann. Höhere bereits entstandene Kosten machen es nicht wahrscheinlicher, dass eine unklar definierte Verlängerung hilft.

Fordern Sie einen vollständigen Vorgang vom Eingang bis zum bestätigten Ergebnis, die Liste der offenen Fehler, benannte Verantwortliche und die laufenden Kosten. Lassen Sie die spätere Bedienperson eine typische Ausnahme bearbeiten. Prüfen Sie, ob ein Ausfall erkennbar ist und der bisherige Arbeitsweg weiter genutzt werden kann.

Der Automatisierungsleitfaden hilft bei der Eingrenzung. Die Kostenrechnung ergänzt Betrieb und interne Arbeit; Entwurf und Freigabe beschreibt die menschliche Entscheidung. Entscheidend für die nächste Freigabe ist ein belegter Arbeitsablauf, den jemand im Betrieb tatsächlich verantwortet.