Die Demo beantwortet eine Frage überzeugend. Im Alltag kommen andere Formulierungen, unvollständige Daten und Zeitdruck hinzu. Der Übergang in den Betrieb braucht deshalb eine eigene Entscheidung.
Zwei unterschiedliche Fragen
Ein Pilot fragt: Ist die Idee unter begrenzten Bedingungen tragfähig? Der Produktivbetrieb fragt: Können wir uns im vorgesehenen Alltag ausreichend auf diese Anwendung verlassen und sie betreuen?
Der Übergang ist keine reine Vergrösserung der Nutzerzahl. Neue Rollen, Datenquellen und Sonderfälle können die Bedingungen wesentlich verändern. Dokumentieren Sie deshalb, was im Pilot tatsächlich geprüft wurde und was noch offen ist.
Einen Abnahmekatalog festlegen
Definieren Sie vor dem Rollout, welche Nachweise vorliegen müssen. Dazu gehören fachliche Qualität, Zugriffsprüfung, Fehlerbehandlung, wirtschaftlicher Nutzen und ein verantwortlicher Betrieb.
Fachbereich: Ergebnisse anhand repräsentativer Fälle beurteilt.
Technik: Anmeldung, Schnittstellen und Ausfälle geprüft.
Datenverantwortliche: Quellen, Versionen und Aktualisierung freigegeben.
Betrieb: Zuständigkeiten, Meldestelle und Rückfallverfahren festgelegt.
Projektverantwortliche: offene Risiken und Grenzen dokumentiert.
Ein Abnahmekatalog muss zur Anwendung passen. Für einen internen Schreibassistenten sind andere Nachweise nötig als für ein System, das Bestellungen auslöst.
Mit unbekannten Fällen testen
Nutzen Sie nicht ausschliesslich Beispiele, mit denen die Anwendung entwickelt wurde. Stellen Sie ein separates Prüfset zusammen. Es sollte normale Fälle, seltene Ausnahmen und bewusst nicht lösbare Aufgaben enthalten.
Messen Sie den gesamten Ablauf. Ein schneller Entwurf spart wenig, wenn seine Kontrolle länger dauert als die bisherige Bearbeitung. Bei Wissensassistenten müssen Suche und Antwort getrennt geprüft werden. Microsoft beschreibt diese Bewertung von RAG-Lösungen ausführlicher.
Ausfälle und falsche Antworten einplanen
Überlegen Sie, was bei fehlenden Daten, einer nicht erreichbaren Schnittstelle oder einer widersprüchlichen Antwort geschieht. Die Anwendung braucht einen erkennbaren Fehlerzustand und einen praktikablen Weg zurück zur bisherigen Bearbeitung.
Ein Beispiel: Ein Rechnungsassistent kann einen Lieferanten nicht eindeutig zuordnen. Er sollte den Fall zur Prüfung geben und die Unsicherheit zeigen. Eine zufällig plausible Zuordnung wäre im produktiven Prozess gefährlicher als ein klarer Abbruch.
Dokumentieren Sie auch, wie eine fehlerhafte Änderung zurückgenommen wird. Eine bekannte, getestete Vorgängerversion ist oft wertvoller als eine improvisierte Korrektur unter Zeitdruck.
Verantwortung übergeben
Benennen Sie eine fachliche und eine technische Verantwortung. Klären Sie, wer neue Datenquellen freigibt, wer Qualitätsprobleme untersucht und wer das System bei einem ernsten Fehler einschränken kann.
Das NIST AI RMF Core betrachtet Risikomanagement als fortlaufende Aufgabe. Für den Betrieb übersetzen wir das in wenige konkrete Routinen: Rückmeldungen sichten, Fehlerbilder prüfen, Änderungen testen und Entscheidungen dokumentieren.
In kontrollierten Schritten erweitern
Starten Sie mit einer klaren Nutzergruppe und dem freigegebenen Datenumfang. Eine Erweiterung auf einen weiteren Standort oder Bereich sollte als Änderung behandelt werden. Neue Begriffe, Berechtigungen und Arbeitsweisen können zusätzliche Tests verlangen.
Definieren Sie vorher, welche Beobachtungen zu einer Pause führen. Das können unzulässige Zugriffe, wiederkehrende fachliche Fehler oder ein unerwartet hoher Kontrollaufwand sein. Solche Kriterien verhindern, dass ein Rollout allein deshalb weiterläuft, weil bereits viel Arbeit investiert wurde.
Ein fiktives Übergabeprotokoll
Ein interner Assistent darf technische Handbücher zweier Produktfamilien durchsuchen. Preise und Kundendaten sind ausgeschlossen. Der Service bestätigt das Prüfset, die IT bestätigt die Rollenprüfung, und eine Fachperson übernimmt die monatliche Quellenprüfung.
Im Protokoll stehen zudem bekannte Grenzen: ältere Scans, nicht dokumentierte Sonderumbauten und fehlende Übersetzungen. Diese Fälle werden an den Service übergeben. Erst nach einer gesonderten Prüfung wird der Umfang erweitert.
Wann der Pilot noch nicht bereit ist
Fehlen belastbare Testfälle, eine zuständige Person oder ein Rückfallverfahren, ist die Anwendung noch nicht sinnvoll übergeben. Das bedeutet nicht, dass der Pilot wertlos war. Er kann genau diese Lücken sichtbar gemacht haben.
Für die wirtschaftliche Entscheidung hilft unsere Anleitung zum KI-ROI. Unsere KI-Beratung für Unternehmen begleitet die Verbindung zwischen Pilot, Abnahme und laufendem Betrieb.




