Auf dieser Seite
Eine Demo liest eine Beispielrechnung, extrahiert den Betrag und erstellt eine übersichtliche Zusammenfassung zur Freigabe. Im tatsächlichen Ablauf kommen Rechnungen über drei Kanäle herein, einige gehören zu einer anderen juristischen Person und das Freigabesystem akzeptiert nur Personen mit einer bestimmten Rolle. Die Extraktion funktioniert weiterhin. Der Workflow nicht. Das ist ein Beispiel und kein Bericht von Kund:innen.
Eine Diskussion über die Einführung von KI in ältere Geschäftssysteme verweist auf Daten, vorhandene Software und lokale Gewohnheiten als hartnäckige Hürden. Die sprechende Person beschreibt die Praxis eines Unternehmens, keine allgemeine Erfolgsquote. Entscheidend ist der Unterschied zwischen dem Nachweis einer Komponente und ihrer Nutzung in der Arbeit.
Die Demo bestimmt ihre Umgebung
Eine Demo kann saubere Eingaben auswählen. Sie kann das Konto im Voraus freigeben, eine Warteschlange überspringen, einen fehlgeschlagenen Durchlauf zurücksetzen und die mehrdeutige Ausgabe von der entwickelnden Person erklären lassen. Das ist sinnvoll, um eine Fähigkeit zu demonstrieren. Gefährlich wird es, wenn das Team den Test der Fähigkeit als Beleg für die Betriebsbereitschaft behandelt.
Bei der Rechnungsaufgabe ist die Extraktion nur ein Schritt. Die Organisation muss klären, welches Postfach maßgeblich ist, wie doppelte Eingänge erkannt werden, ob sich der Betrag nach dem Einreichen ändern lässt, wer freigeben darf und wohin ein fehlgeschlagener Eintrag geht. Eine ausführlichere Zusammenfassung beantwortet diese Fragen nicht.
Am einfachsten zeigt sich die Grenze, wenn ein Arbeitselement vom Eingang bis zum akzeptierten Ergebnis verfolgt wird:
Eine vorgeführte Fähigkeit wird erst dann zu nützlicher Arbeit, wenn lokale Daten, Berechtigungen und Wiederherstellung sie mit dem tatsächlichen Workflow verbinden.
| Phase | Frage bei der Demo | Frage bei der Einführung |
|---|---|---|
| Eingabe | Kann das Modell dieses Beispiel lesen? | Kann es jedes autorisierte Format verarbeiten und andere zurückweisen? |
| Kontext | Kann es einen Betrag finden? | Kann es Lieferant:in, juristische Person und Richtlinienversion richtig zuordnen? |
| Aktion | Kann es eine Zusammenfassung erstellen? | Kann es nur erlaubte Aktionen ausführen und Duplikate vermeiden? |
| Fehler | Kann die vorführende Person es erneut versuchen? | Wer sieht einen festgefahrenen Vorgang, korrigiert ihn und setzt ihn sicher fort? |
| Nutzung | Sieht das Ergebnis hilfreich aus? | Nutzt und vertraut die zuständige Person dem Ergebnis in der echten Warteschlange? |
Dieser Vergleich ist konzeptionell. Er besagt nichts über eine gemessene Fehlerrate von KI-Projekten.
Verfolge den lokalen Zustand
Datenintegration wird oft als letzter Schritt bezeichnet, als wäre sie ein Kabel, das nach Fertigstellung des Produkts angeschlossen wird. Das lokale Datenmodell kann die Bedeutung des Produkts verändern. Für ein Unternehmen gilt eine Rechnung vielleicht als „eingegangen“, sobald sie in einem Postfach landet. Ein anderes zählt sie erst, wenn die passende Bestellung zugeordnet wurde. Handelt das System auf Grundlage des falschen Zustands, kann ein technisch gültiger API-Aufruf trotzdem ein geschäftlicher Fehler sein.
Frage, woher jeder Fakt stammt und wer ihn korrigieren kann. Frage dann, was das System bei widersprüchlichen Fakten tut. Muss ein Entwurf zur Freigabe ungültig werden, wenn sich der Quelldatensatz anschließend ändert? Prüft die ausführende Komponente erneut, ob die Berechtigung noch gilt, wenn sie während der Warteschlange widerrufen wurde? Diese Fragen gehören zur Einführung und sind keine kosmetischen Details.
Der Artikel zur Workflow-Erhebung beginnt früher und beobachtet die tatsächliche Arbeit der Bedienpersonen. Hier lautet die Frage, was wahr sein muss, damit eine vorgeführte Fähigkeit diesen Workflow übersteht.
Prototypisiere die Fähigkeit, teste dann den Workflow
Ein kleiner Prototyp kann schnell zeigen, ob ein Modell die Kernaufgabe überhaupt bewältigen kann. Er muss am ersten Tag nicht alle Kontrollen des Produktivbetriebs enthalten. Der Fehler liegt darin, die verbleibende Arbeit als kleinen Abschluss einzuplanen, ohne sie zu untersuchen.
Ein hilfreicher Prototyp benennt seine Grenze. Er könnte sagen: „Lies freigegebene Beispielrechnungen, schlage Felder vor und führe keine externe Aktion aus.“ Beim nächsten Test können autorisierte Live-Datensätze verwendet werden, während das Schreiben ins Freigabesystem weiterhin deaktiviert bleibt. Erst wenn Datenzuordnung, Berechtigungen und Wiederherstellung geklärt sind, sollte das System dort schreiben. Jeder Schritt beantwortet eine andere Frage.
Die Einführung hat auch eine menschliche Seite. Wer bisher mehrdeutige Rechnungen bearbeitet, braucht eine Möglichkeit, dem Vorschlag zu widersprechen, Änderungen einzusehen und zu wissen, ob das System denselben Fehler wiederholen wird. Erfordert der neue Ablauf mehr Prüfungen, als er einspart, zeigt sich das an der tatsächlichen Nutzung. Eine erfolgreiche Vorführung belegt keine Akzeptanz.
Die Freigabefrage lässt sich operativ formulieren: Kann eine andere autorisierte Bedienperson ein Arbeitselement erledigen und einen Fehler beheben, ohne dass die vorführende Person dabei ist? Sie sollte die ursprüngliche Eingabe finden, die vorgeschlagene Aktion sehen, ihre Berechtigungsgrundlage erkennen und einen Fehler weiterleiten können. Eine eingeübte Rücknahme ist wichtig, denn ein erfolgreicher erster Durchlauf sagt nichts über Duplikate oder teilweise Schreibvorgänge aus. Der Leitfaden zur Einführung von KI in bestehende Workflows bietet einen umfassenderen Rahmen. Für diese Freigabe bleibt der Test eng gefasst und wird mit der Ausnahme wiederholt, die den normalen Ablauf am ehesten unterbricht.
Das Ergebnis, das zählt, ist keine generierte Ausgabe. Es ist ein akzeptiertes Arbeitselement im echten Prozess, mit einem bekannten Weg für Ausnahmen. Solange dieser Weg nicht funktioniert, bleibt die Demo ein hilfreicher Beleg für eine einzelne Komponente. Sie belegt nicht, dass die Aufgabe erledigt ist.
Häufig gestellte Fragen
Warum kann eine erfolgreiche Demo im Produktivbetrieb scheitern?
Eine Demo nutzt oft vorbereitete Daten und eine einzelne Bedienperson. In der echten Arbeit kommen veränderliche Datensätze, Zugriffsbeschränkungen, verzögerte Ereignisse, Ausnahmebehandlung und Menschen hinzu, die dem Ergebnis vertrauen müssen.
Was sollte ein Einführungstest umfassen?
Nutze einen autorisierten echten Workflow mit gewöhnlichen Fällen und Ausnahmen. Prüfe Quelldaten, zulässige Aktionen, Wiederherstellung bei Fehlern, zuständige Personen und ob die vorgesehenen Nutzer:innen das Ergebnis tatsächlich verwenden.
Bedeutet das, dass das Modell unwichtig ist?
Nein. Für Aufgaben, die ein Modell benötigen, ist seine Qualität notwendig. Ob es innerhalb des umgebenden Systems und Workflows sicher handeln kann, entscheidet ebenfalls über die Einführung.