KI-Dokumentenverarbeitung abnehmen: Testfälle für den Fachbereich

Der Fachbereich nimmt eine KI-Dokumentenverarbeitung anhand festgelegter Soll-Ergebnisse ab. Dazu gehören vollständige Dokumente ebenso wie fehlende Angaben, widersprüchliche Summen und doppelte Zustellungen. Eine korrekt ausgelesene Rechnung allein reicht für die Freigabe eines automatisierten Ablaufs nicht.

Das Beispiel in diesem Artikel ist fiktiv. Es prüft die Übernahme von Rechnungsangaben in einen internen Entwurf. Es beschreibt keine rechtliche Rechnungsprüfung und keine tatsächlich ausgeführte Buchung. Die fachlichen Regeln und Testfälle dienen als anpassbares Arbeitsmittel.

Extraktion, fachliche Prüfung und Aktion getrennt abnehmen

Die Verarbeitung einer Rechnung enthält mehrere Aufgaben. Die Extraktion überträgt Angaben aus dem Dokument in Felder. Die fachliche Prüfung bewertet Vollständigkeit, Widersprüche und die Einhaltung betrieblicher Regeln. Die anschliessende Aktion legt einen Entwurf an oder überträgt freigegebene Daten. Ein korrektes Feld beweist nicht, dass die gesamte Kette richtig arbeitet.

Ein Beispiel: Die Rechnungsnummer wird korrekt erkannt, aber die Schnittstelle legt denselben Vorgang zweimal an. Die Extraktion hat bestanden, der Gesamtprozess nicht. Umgekehrt kann ein Entwurf technisch genau einmal angelegt werden, obwohl die Währung falsch übernommen wurde. Eine einzelne Erfolgsquote über alle Schritte verdeckt solche Unterschiede.

Lege deshalb je Stufe einen prüfbaren Vertrag fest. Für die Extraktion sind das Quellenwerte und zulässige Leerzustände. Für die Validierung sind es Regeln und erwartete Fehlerhinweise. Für die Aktion sind es Zielzustand, Freigabe und Wiederholungsverhalten. Ein Gesamttest verbindet diese Einzelprüfungen.

Was Forschung und technische Erfahrungsberichte beitragen

The ML Test Score von Breck und Kollegen behandelt Tests und laufende Beobachtung als Bestandteile produktiver ML-Systeme. Die Arbeit aus 2017 ist ein Erfahrungs- und Bewertungsrahmen, kein Nachweis einer bestimmten Fehlerquote heutiger Dokumentenmodelle. Für die Abnahme leite ich daraus ab, Eingabedaten, Modellverhalten und Systemintegration getrennt zu prüfen.

Buçinca, Malaya und Gajos untersuchten 2021 in einem Experiment mit 199 Personen Eingriffe, die eigenständiges Nachdenken vor KI-gestützten Entscheidungen anregen. Sie reduzierten übermässige Übernahme von KI-Vorschlägen gegenüber einfachen Erklärungsansätzen, erhielten aber teils schlechtere subjektive Bewertungen. Das ist kein Rechnungstest. Für deine Freigabe ist die Spannung relevant: Eine als bequem bewertete Oberfläche garantiert keine wirksame fachliche Kontrolle.

Meine Empfehlung lautet deshalb, die Prüfperson die kritischen Originalwerte sichtbar vergleichen zu lassen. Eine Schaltfläche "geprüft" ohne definierten Prüfgegenstand ist kein ausreichendes Kontrollkonzept. Welche Werte kritisch sind, muss der Fachbereich anhand der Fehlerfolgen festlegen.

Einen brauchbaren Referenzbestand aufbauen

Für einen Referenzbestand muss eine fachlich geeignete Person die erwarteten Werte aus den Originalen bestimmen. Eine zweite Prüfung ist bei besonders folgenreichen Feldern sinnvoll. Die Referenz darf nicht ausschliesslich aus der Ausgabe desselben Modells entstehen, dessen Qualität du anschliessend bewertest.

Trenne Entwicklungsfälle von Fällen für die Abschlussprüfung. Wenn die Umsetzung an jedem Testdokument nachgebessert wurde, zeigt ein erneuter Erfolg vor allem Anpassung an bekannte Beispiele. Neue Dokumente mit vergleichbaren Anforderungen prüfen besser, ob die Regeln über den Einzelfall hinaus funktionieren.

Der Bestand braucht die tatsächlich vorkommenden Dokumentarten und schwierige Varianten. Dazu zählen beispielsweise mehrseitige Rechnungen, ungewöhnliche Positionsbeschreibungen und fehlende Angaben. Erweitere den freigegebenen Umfang erst, wenn die neue Variante geprüft ist. Eine Testdatei mit sauberem Layout deckt keinen unleserlichen Scan ab.

Grenze den Abnahmegegenstand ein

Für die Übung beginnt der Ablauf mit einer eingehenden Datei. Er endet mit einem geprüften Datensatz im Status "Entwurf" oder einer nachvollziehbaren Rückfrage. Die Übertragung in ein Buchhaltungssystem ist ein zusätzlicher Schritt mit eigener Freigabe.

Definiere die Felder vor dem Test: Lieferant, Rechnungsnummer, Datum, Positionen, Währung, Nettobetrag, ausgewiesene Steuer und Gesamtbetrag. Lege fest, welche Angaben aus dem Dokument übernommen werden und welche das System selbst berechnet. Ein berechneter Kontrollwert darf nicht unbemerkt den dokumentierten Wert ersetzen.

Der Fachbereich verantwortet die Soll-Ergebnisse. Die technische Umsetzung muss belegen, dass der Ablauf diese Regeln einhält. Wenn dieselbe KI die Angaben extrahiert und ihre Richtigkeit allein beurteilt, fehlt eine unabhängige Kontrolle. Für Summen nutzt du eine nachvollziehbare Rechnung; für Quellenwerte die Originaldatei.

Das vollständige Ausgangsdokument

Die fiktive Rechnung R-104 des fiktiven Lieferanten Beispieltechnik enthält folgende Angaben:

Ausgewiesener Nettobetrag: 360,00 EUR. Ausgewiesene Steuer im Beispiel: 68,40 EUR. Ausgewiesener Gesamtbetrag: 428,40 EUR. Rechnungsdatum: 14.10.2026. Die Steuerangabe gehört zum synthetischen Dokument; daraus folgt keine Aussage zur steuerlichen Behandlung eines echten Vorgangs.

Die Kontrollrechnung lautet 2 × 120 + 3 × 40 = 360 und 360 + 68,40 = 428,40. Der erwartete Datensatz übernimmt die Werte mit Quellenbezug und bleibt ein interner Entwurf. Er löst weder Zahlung noch Buchung aus.

Testfälle vor dem ersten Lauf schreiben

Die Dublettenprüfung braucht eine fachliche Regel. Im Beispiel bildet die Kombination aus Lieferant und Rechnungsnummer einen ersten Hinweis. Eine korrigierte Rechnung oder Gutschrift darf deshalb nicht blind gelöscht werden. Solche Fälle erhalten eine eigene Prüfung mit Bezug zum bereits bekannten Dokument.

Für A-04 darf die Anwendung die falsche Kopfsumme nicht still korrigieren. Der Unterschied ist ein Befund, den der Fachbereich klären muss. Das gilt auch dann, wenn die Rechenlogik eindeutig ist: Die extrahierten Dokumentdaten und der berechnete Kontrollwert haben unterschiedliche Funktionen.

Die Abnahme dokumentieren

Ein Testlauf erhält eine eindeutige Kennung. Speichere Eingabedatei, verwendete Konfiguration, tatsächliche Ausgabe und das erwartete Ergebnis. Notiere danach "bestanden", "nicht bestanden" oder "nicht prüfbar" mit Begründung.

Ein nicht ausgeführter Übertragungstest bleibt "nicht prüfbar". Er wird nicht durch eine passende Bildschirmansicht bestanden. Bei einer Integration prüfst du den tatsächlichen Zielzustand: Wurde genau ein Entwurf angelegt? Bleibt die Freigabe leer? Ist die Dokumentreferenz erhalten? Ein erfolgreicher API-Aufruf allein beantwortet diese Fragen nicht vollständig.

Teste zusätzlich den Wiederanlauf nach einer Unterbrechung. Wenn ein Vorgang bereits im Ziel angekommen ist, muss ein erneuter Start diesen Zustand berücksichtigen. Sonst entsteht trotz korrekter Extraktion ein doppelter Vorgang. Die konkrete Wiederanlaufregel muss zur Schnittstelle passen und mit dem Betreiber abgestimmt sein.

Aus Fehlern eine Freigabeentscheidung ableiten

Ein falscher Centbetrag, eine vertauschte Währung und eine ungewollte Buchung haben unterschiedliche Folgen. Definiere vor dem Test, welche Fehler die Freigabe blockieren. Im Beispiel blockieren erfundene Pflichtwerte, unerkannte Summenwidersprüche und jede Übertragung ohne Freigabe.

Eine Gesamtquote verdeckt diese Unterschiede. "Fünf von sechs Tests bestanden" ist keine Freigabe, wenn der fehlgeschlagene Test eine unautorisierte Buchung betrifft. Zeige deshalb die Fallklassen und den Status jedes blockierenden Kriteriums.

Bei einem Fehler wird zuerst die Ursache untersucht und die Umsetzung korrigiert. Danach werden der betroffene Fall und die relevanten bisherigen Fälle erneut ausgeführt. Halte die begrenzte Freigabe ausdrücklich fest, beispielsweise nur für die geprüfte Dokumentart und ohne automatische Buchung.

Trefferquoten mit dem richtigen Nenner berechnen

Angenommen, ein synthetischer Test umfasst 20 Dokumente mit je zehn erwarteten Feldern. Das sind 200 Feldwerte. Wenn 196 richtig sind, beträgt die Feldgenauigkeit 98 Prozent. Wenn die vier Fehler auf vier verschiedenen Dokumenten liegen, sind nur 16 von 20 Dokumenten vollständig richtig, also 80 Prozent. Beide Zahlen beschreiben denselben Test und beantworten verschiedene Fragen.

Auch diese Dokumentquote reicht nicht allein. Vier falsch erkannte interne Bemerkungen haben andere Folgen als vier falsche Gesamtbeträge. Zeige deshalb Feldarten und Fehlerfolgen. Für Pflichtfelder mit blockierender Bedeutung gilt die vorab festgelegte Freigaberegel; ein guter Durchschnitt über unkritische Felder gleicht ihre Verletzung nicht aus.

Erfasse zudem die Fälle, die das System korrekt zur manuellen Klärung gibt. Eine hohe manuelle Quote kann sicher, aber wirtschaftlich unattraktiv sein. Eine niedrige manuelle Quote ist kein Vorteil, wenn das System dafür unsichere Werte still übernimmt. Der Abnahmebericht braucht sowohl Fehlerbefunde als auch den verbleibenden Bearbeitungsaufwand.

Warum null beobachtete Fehler keine Fehlerfreiheit beweisen

Ein kleiner Test kann einen Fehler übersehen, obwohl er im Betrieb vorkommt. In einem rein mathematischen Modell mit unabhängigen Fällen und einer konstanten tatsächlichen Fehlerwahrscheinlichkeit von fünf Prozent beträgt die Chance auf null Fehler in 20 Fällen etwa 35,8 Prozent. Die Rechnung lautet 0,95 hoch 20. Das Modell ist eine Illustration und keine Schätzung für dein System.

In echten Dokumentbeständen sind Fälle zudem oft ähnlich. Zwanzig Rechnungen desselben Layouts liefern weniger Vielfalt als zwanzig unterschiedliche Anforderungen. Die Testzahl allein beschreibt deshalb die Aussagekraft nicht. Dokumentiere die abgedeckten Formate, Fallklassen und bekannten Lücken.

Für eine Freigabe mit hohen Fehlerfolgen braucht die Fallzahlplanung eine passende statistische und fachliche Begründung. Ein kleines redaktionelles Muster wie die sechs Fälle dieses Artikels ist ein Einstieg in die Spezifikation, kein vollständiger Sicherheitsnachweis. Seine Aufgabe besteht darin, die erwarteten Reaktionen eindeutig zu machen.

Eine unbekannte Rückmeldung aus dem Zielsystem behandeln

Erweitere A-05 um einen technischen Sonderfall: Der Übertragungsaufruf endet ohne eindeutige Rückmeldung. Die Anwendung weiss nicht, ob im Ziel bereits ein Entwurf existiert. Ein automatischer zweiter Aufruf darf diesen Zustand nicht ungeprüft ignorieren.

Der Test muss eine eindeutige Vorgangskennung verwenden und den Zielbestand kontrollieren. Erwartetes Ergebnis: Der Ablauf ordnet den Vorgang als unklar ein, prüft den vorhandenen Zielzustand und erzeugt keinen zweiten Entwurf. Die genaue technische Umsetzung hängt von den Möglichkeiten der Schnittstelle ab. Wenn diese Prüfung nicht möglich ist, braucht es einen manuellen Klärungsweg.

Teste danach den umgekehrten Fall: Im Ziel existiert sicher kein Entwurf. Die kontrollierte Wiederaufnahme muss genau einen erzeugen und den Abschluss dokumentieren. So prüfst du sowohl die Vermeidung von Doppelverarbeitung als auch die Vermeidung still verlorener Vorgänge.

Fachliche Freigabe braucht einen verständlichen Entscheidungsvermerk

Der Vermerk nennt Dokumentarten, Teststände, bestandene Kriterien, bekannte Einschränkungen und ausgeschlossene Aktionen. Er trennt technische Betriebsbereitschaft von fachlicher Zustimmung. Eine technische Person bestätigt die Schnittstellenprüfung; die zuständige Fachperson bestätigt die inhaltlichen Regeln. In kleinen Teams kann eine Person mehrere Rollen übernehmen, muss sie aber ausdrücklich kennen.

Bei einer begrenzten Freigabe muss die Einschränkung im tatsächlichen Ablauf wirksam sein. "Keine automatische Buchung" reicht als Satz nicht, wenn die Anwendung trotzdem über eine unkontrollierte Buchungsfunktion verfügt. Prüfe, welche Aktion tatsächlich ausgeführt wird und wie der Freigabestatus berücksichtigt wird.

Nach dem Start werden echte Ausnahmen in einen geprüften Testbestand überführt. Bewahre dabei Datenfreigaben und erforderliche Vertraulichkeit. Die Versionierung der Vorlage hält Änderungen nachvollziehbar; die Excel-Kontrolle hilft bei unabhängigen Summenprüfungen. Der Betrieb erhält damit konkrete Fälle statt allgemeiner Fehlerbeschreibungen.

Übergabe an den laufenden Betrieb

Die Abnahme endet mit dem freigegebenen Umfang, den ausgeschlossenen Fällen und einer benannten Bearbeitung der Ausnahmen. Ein Mitarbeiter muss erkennen, wo unvollständige Dokumente liegen und wer sie übernimmt. Leere Fehlerordner im Test beweisen keine funktionierende Ausnahmebearbeitung.

Die Betriebsübergabe nach dem KI-Pilot ergänzt Zuständigkeit und Wiederanlauf. Der Beitrag zur ERP-Integration der Dokumentenverarbeitung ordnet die Schnittstellen ein. Für fachliche Kontrollen in Tabellen hilft die Prüfung von Excel-Daten.

Lege für einen fehlgeschlagenen Test einen eigenen Befund an. Er enthält Eingabe, erwartetes Ergebnis, tatsächliche Abweichung und die betroffene Version. Nach einer Korrektur läuft derselbe Fall erneut, ergänzt um einen bislang erfolgreichen Kontrollfall. Damit prüfst du, ob die Korrektur das konkrete Problem behebt und einen benachbarten Ablauf weiterhin richtig behandelt.

Quelle und Einordnung

Der NIST AI RMF Core nennt dokumentierte Testbestände, Methoden und Bewertungen im Rahmen der Risikomessung. Meine Abnahmetabelle ist eine eigene Konkretisierung für den beschriebenen Entwurfsprozess. Sie belegt keine Zertifizierung und keine universelle Mindestanzahl an Tests. Quellenprüfung: 21.10.2026.