Eine gute KI-Demo beweist noch keinen guten Arbeitsablauf

Eine KI-Demo zeigt, dass ein bestimmtes Ergebnis unter bestimmten Bedingungen gelingt. Sie zeigt noch nicht, dass dein Team dieselbe Aufgabe mit wechselnden Unterlagen, anderen Personen und echten Fehlerfolgen zuverlässig erledigt. Für eine Einsatzentscheidung musst du deshalb den vollständigen Ablauf prüfen: vom Eingang der Daten bis zum kontrollierten Arbeitsergebnis und zum Umgang mit Ausnahmen.

Dieser Artikel beschreibt einen eigenen Prüfweg zwischen Vorführung und betrieblicher Nutzung. Das durchgehende Beispiel einer Dokumentenprüfung ist fiktiv. Es gibt keine erfundenen Kundenresultate und keine pauschale Erfolgsquote. Die praktische Abnahme einzelner Dokumentenfälle vertieft der Beitrag KI-Dokumentenverarbeitung abnehmen.

Was eine Demo tatsächlich belegt

In einer Vorführung sind Eingangsmaterial, Aufgabe und gewünschtes Ergebnis häufig vorbereitet. Das ist für die Erklärung einer Funktion sinnvoll. Die Person kennt das Werkzeug, hat Zugriffsrechte und weiss, welche Formulierung zum Beispiel passt. Daraus folgt eine begrenzte Aussage: Diese Kombination hat in diesem Durchlauf funktioniert.

Notiere diese Bedingungen, statt die Demo abzuwerten. Welche Datei wurde verwendet? War sie bereits bereinigt? Welche Vorlage kam zum Einsatz? Gab es frühere Versuche? Wurde ein fehlendes Feld während der Vorführung mündlich ergänzt? Ohne diese Informationen lässt sich das Ergebnis später nicht reproduzieren.

Eine Demo darf auch eine zukünftige Bedienidee zeigen. Dann muss erkennbar bleiben, welche Teile bereits funktionieren und welche simuliert sind. Ein manuell eingetragener Status ist kein Nachweis einer fertigen Schnittstelle. Ein vorbereitetes Ergebnis ist kein Beleg dafür, dass das Modell es gerade erzeugt hat.

Warum ähnliche Aufgaben unterschiedlich ausfallen

Das Experiment Navigating the Jagged Technological Frontier untersuchte 758 Beratungsbeschäftigte und unterschiedliche Aufgaben mit GPT-4. Die Ergebnisse unterscheiden sich je nach Aufgabenart; bei einer Aufgabe ausserhalb der untersuchten Leistungsgrenze sank die Wahrscheinlichkeit korrekter Lösungen mit KI-Unterstützung. Das Experiment belegt keine heutige Fehlerquote für dein Werkzeug.

Die praktische Konsequenz ist eine Prüfregel: Übertrage Erfolg nicht allein aufgrund einer ähnlichen Oberfläche. Zwei Dokumente sehen beide wie Angebote aus, verlangen aber unterschiedliche Schlussfolgerungen. Eines enthält eine eindeutige Lieferfrist. Beim anderen steht die Frist in einem veralteten Anhang und wird im Begleitschreiben eingeschränkt.

Ein beeindruckender Umgang mit dem ersten Dokument beantwortet nicht die Frage nach dem zweiten. Der Test muss die fachlichen Unterschiede enthalten. Die Bezeichnung "Angebotsprüfung" ist für die Auswahl der Fälle noch zu grob. Du brauchst die Bedingungen, unter denen eine Aussage tatsächlich zulässig ist.

Den vollständigen Ablauf aufzeichnen

Im fiktiven Team beginnt die Aufgabe mit einer eingehenden Datei. Ein Mitarbeiter prüft Dateityp, Lesbarkeit und Zuordnung. Danach werden Angaben extrahiert, mit dem Auftrag verglichen und in eine Prüfliste übertragen. Eine fachlich zuständige Person entscheidet über Abweichungen. Erst danach wird ein freigegebenes Ergebnis gespeichert.

Die Demo zeigt nur die Extraktion. Im Betrieb gehören jedoch Vorbereitung, Berechtigungen, Prüfung und Übergabe dazu. Zeichne diese Schritte in einer einfachen Tabelle auf. Für jeden Schritt stehen Eingang, Handlung, Ergebnis und verantwortliche Rolle fest. Ein leerer Verantwortungswert ist eine offene Aufgabe, keine Kleinigkeit für später.

Ergänze den Fehlerweg. Was passiert bei einer unlesbaren Seite? Was passiert bei einer nicht verfügbaren Schnittstelle? Wer findet einen Vorgang wieder, wenn der Browser geschlossen wird? Diese Fragen entscheiden darüber, ob der Ablauf auch nach einem gelungenen Modellaufruf weiter funktioniert.

Ein fiktives Beispiel: acht Felder sind nicht acht richtige Felder

Die Demo extrahiert aus einem Angebot acht Felder: Anbieter, Angebotsnummer, Datum, Nettobetrag, Währung, Laufzeit, Kündigungsfrist und Leistungsumfang. Alle Felder sind ausgefüllt. Das Publikum sieht eine ordentliche Tabelle und bewertet das Ergebnis als vollständig.

Im anschliessenden Test enthält ein Angebot zwei alternative Leistungspakete. Das Modell übernimmt den Preis aus Paket A und die Laufzeit aus Paket B. Die Tabelle bleibt vollständig ausgefüllt, beschreibt aber kein tatsächlich angebotenes Paket. Ein Vollständigkeitswert von acht aus acht erkennt diesen Fehler nicht.

Der Abnahmetest muss deshalb die Verbindung zwischen den Feldern prüfen. Gehören Preis, Umfang und Laufzeit zum selben Angebotsteil? Welche Quelle belegt die Zuordnung? Ein Ergebnis mit einem offenen Feld ist akzeptabler als eine vollständig ausgefüllte, aber vermischte Variante. Diese Priorität muss vor dem Test feststehen.

Aus dem Vorführfall ein Testset entwickeln

Beginne mit echten Aufgabenarten, deren Daten für den Test freigegeben sind. Ergänze veränderte oder synthetische Fälle, wenn seltene Fehler gezielt geprüft werden müssen. Trenne beide Arten im Protokoll. Synthetische Fälle zeigen das Verhalten unter konstruierten Bedingungen; sie beweisen keine Häufigkeit im Tagesgeschäft.

Diese Tabelle ist ein Startpunkt, kein vollständiger Sicherheitskatalog. Der Fachbereich ergänzt die Fehler, deren Folgen im eigenen Prozess relevant sind. Die IT ergänzt technische Ausfälle. Die Personen, die später mit den Ergebnissen arbeiten, ergänzen Missverständnisse bei der Übergabe.

Lege für jeden Fall vorab eine Referenz fest. Sie enthält die erwarteten Angaben, zulässige Varianten und die erforderliche Reaktion auf fehlendes Wissen. Wenn der Prüfer erst nach der Ausgabe entscheidet, was als richtig gilt, lässt sich ein attraktives Ergebnis leicht nachträglich rechtfertigen.

Ungeübte Nutzer gehören in den Test

Eine Vorlage, die nur ihr Ersteller bedienen kann, ist noch keine Teamlösung. Lass eine zweite Person mit der Dokumentation arbeiten. Sie erhält dieselben Zugriffe und Informationen, die später im Betrieb verfügbar sind. Zusätzliche mündliche Hilfen werden als Unterstützungsaufwand protokolliert.

Beobachte, wo die Person stoppt. Fehlt ein fachlicher Begriff? Ist unklar, welches Dokument die gültige Version ist? Verwechselt sie einen Entwurf mit einer Freigabe? Diese Beobachtungen führen zu Änderungen am Ablauf oder an der Oberfläche. Nicht jeder Fehler ist ein Promptproblem.

Ein separater Beitrag zum Kollegentest einer KI-Vorlage zeigt, wie sich diese Übergabe prüfen lässt. Für die Entscheidung zählt der dokumentierte Einsatz durch die vorgesehene Nutzergruppe, nicht nur die sichere Bedienung durch die Person auf der Bühne.

Wiederholbarkeit ohne falsches Versprechen prüfen

Ein erfolgreicher Durchlauf reicht nicht, wenn die Aufgabe regelmässig wiederkehrt. Wiederhole ausgewählte Fälle und dokumentiere Modell, Vorlagenstand und Quellenfassung. Unterschiedliche Formulierungen sind nicht automatisch Fehler. Abweichende Beträge, Zuständigkeiten oder Schlussfolgerungen sind dagegen fachlich relevant.

Definiere deshalb stabile Anforderungen an Bedeutung und Handlung. Die Ausgabe darf sprachlich variieren, muss aber dieselben belegten Angaben und dieselben offenen Punkte enthalten. Ein exakter Textvergleich ist für solche Aufgaben oft zu eng. Eine reine Ähnlichkeitsbewertung ist wiederum zu schwach, wenn ein einziges Wort eine Zusage verändert.

Bewahre die Erstversuche auf. Wenn nur der beste von fünf Durchläufen gezeigt wird, ist die Auswahl selbst Teil des Aufwands. Der Betrieb braucht eine Regel für unbrauchbare Ergebnisse und für Wiederholungen. Diese Regel muss verhindern, dass Beschäftigte so lange neu anfragen, bis eine gewünschte Aussage erscheint.

Die Prüfung muss dem vorgesehenen Einsatz ähneln

Das NIST AI RMF, Funktion Measure, fordert unter anderem die Dokumentation von Tests und eine Bewertung unter Bedingungen, die dem Einsatz entsprechen. Das ist ein Rahmen für Risikomanagement, kein Zertifikat für eine konkrete Lösung. Der folgende betriebliche Ablauf ist eine eigene Umsetzung dieser Prüfrichtung.

Teste mit der tatsächlichen Rollenverteilung und dem vorgesehenen Dateibestand. Wenn die Produktivdaten unübersichtlicher sind als die Testdaten, dokumentiere diese Abweichung. Prüfe, ob Zugriffsrechte auch im Test wirksam sind. Ein technischer Administrator mit umfassenden Berechtigungen ist kein Ersatz für das Konto eines normalen Teammitglieds.

Berücksichtige zudem die Arbeitsumgebung. Ein Ergebnis, das nebenbei zwischen Telefonaten geprüft wird, braucht andere sichtbare Hinweise als eine Vorführung mit voller Aufmerksamkeit. Die Bedienung muss offene Punkte erkennbar machen, ohne dass jemand den gesamten Gesprächsverlauf rekonstruieren muss.

Aufwand und Ausnahmen zusammen rechnen

Miss die Vorbereitung der Daten, die eigentliche Verarbeitung, die Prüfung und die Nacharbeit. Erfasse auch die Zeit, die andere Rollen übernehmen. Eine fünf Sekunden schnelle Ausgabe kann eine zwanzigminütige Kontrolle auslösen. Die Modellgeschwindigkeit allein beantwortet keine Kapazitätsfrage.

Für seltene Ausnahmen brauchst du zunächst eine transparente Beobachtung, keine erfundene Jahresrechnung. Notiere, wie viele Fälle bisher aufgetreten sind und wie sie behandelt wurden. Eine Schätzung der späteren Häufigkeit bleibt als Annahme markiert. Sie darf nicht unbemerkt in eine vermeintlich gemessene Rendite wandern.

Wenn der Ablauf bei einem Dienstfehler stehen bleibt, muss das Team einen Ersatzweg kennen. Dazu gehört die Rückkehr zum bisherigen Verfahren und die Behandlung bereits begonnener Vorgänge. Der Beitrag zum Ausfall eines KI-Dienstes vertieft diese Betriebsseite.

Vor der Freigabe eine begrenzte Entscheidung treffen

Die Entscheidung muss den getesteten Scope nennen. "Freigegeben für vollständige Angebote mit einem Leistungspaket, unter fachlicher Prüfung" ist überprüfbarer als "Angebotsanalyse funktioniert". Nicht getestete Dokumenttypen bleiben ausserhalb der Freigabe. Ein späterer Ausbau braucht neue Fälle und eine neue Abnahme.

Die Prozessverantwortung entscheidet über Nutzen und verbleibende Risiken. Der Fachbereich bestätigt die Referenzfälle. Die technische Verantwortung bestätigt Fehlerbehandlung und Zugriffe. Diese Rollen können in einem kleinen Team bei wenigen Personen liegen, müssen aber trotzdem sichtbar sein.

Dokumentiere neben dem Ergebnis auch die Grenze: Welche Bedingungen wurden nicht geprüft? Welche Fehler sind noch offen? Welche Änderung löst eine erneute Abnahme aus? Dadurch wird die Demo zu einem nachvollziehbaren Ausgangspunkt für einen belastbaren Ablauf, statt zu einem Versprechen für alle späteren Situationen.

Prüfe ausserdem, ob die Abnahme dieselbe Version betrifft wie die spätere Bereitstellung. Ein Testprotokoll ohne Modell-, Vorlagen- und Quellenstand lässt diese Verbindung offen. Bei einer Änderung muss die zuständige Person den betroffenen Umfang erneut kontrollieren und die Freigabe entsprechend aktualisieren.

Ein Prüfauftrag für die nächste Vorführung

Bitte den Anbieter oder das interne Team, einen unbekannten, freigegebenen Fall zu bearbeiten und einen absichtlich unvollständigen Fall zu zeigen. Frage nach den nicht erfolgreichen Versuchen und dem Vorgehen bei Ausnahmen. Lass erklären, wie das Ergebnis geprüft und in den echten Prozess übernommen wird.

Halte jede Antwort als Beleg, Annahme oder offene Prüfung fest. Eine Folie mit einer Architektur ist ein Entwurf. Ein sichtbarer Durchlauf ist ein Einzelbeleg. Eine dokumentierte Serie mit klaren Abnahmekriterien ist eine breitere Grundlage. Diese Unterscheidung schützt vor einer Entscheidung, die mehr behauptet als die Vorführung zeigt.

Am Ende muss ein nächster Schritt stehen: ein begrenzter Test mit benannten Fallklassen, verantwortlicher Person und überprüfbarem Ergebnis. Wenn diese Angaben fehlen, ist die Demo weiterhin eine Demo. Das ist ein brauchbarer Zwischenstand, solange niemand ihn als fertigen Betrieb ausgibt.