KI-Ergebnisse dokumentieren: Modellwechsel prüfen

Wenn dieselbe Rechnung nach einem Modellwechsel plötzlich anders klassifiziert, ausgelesen oder bewertet wird, ist das nicht automatisch ein Fehler. Für ein KMU wird es aber zum Risiko, wenn niemand mehr nachvollziehen kann, welche Modell-, Prompt- und Regelversion das Ergebnis erzeugt hat. Deshalb sollten Unternehmen bei KI-gestützten Rechnungsprozessen mindestens den Anwendungsfall, die Eingabereferenz, Modell- und Promptversion, Prüfregeln, Ergebnis, menschliche Entscheidung und Freigabe protokollieren. So werden Änderungen testbar, Abweichungen erklärbar und problematische Versionen zurückrollbar.

Das Ziel ist keine lückenlose Speicherung jedes eingegebenen Dokuments. Eine gute Dokumentation verbindet vielmehr wenige belastbare Referenzen mit einem kontrollierten Änderungsprozess. Das schützt sensible Rechnungsdaten, begrenzt den Aufwand und liefert trotzdem die Belege, die Fachabteilung, Datenschutz und interne Kontrolle benötigen.

Warum gleiche Eingaben unterschiedliche KI-Ergebnisse liefern können

Bei klassischer Software führt dieselbe Eingabe unter denselben Bedingungen meist zum selben Resultat. Generative und lernende Systeme können variabler reagieren. Schon ein Wechsel des Modellanbieters oder einer Modellversion kann Feldzuordnungen, Zusammenfassungen oder Formulierungen verändern. Auch ein unverändertes Modell arbeitet anders, wenn sich Systemanweisung, Promptvorlage, Ausgabeformat oder referenzierte Stammdaten ändern.

Im Rechnungsprozess kommen weitere Stufen hinzu. Ein Scan wird vor der KI-Auswertung zugeschnitten, entrauscht und per OCR in Text umgewandelt. Wenn sich diese Vorverarbeitung ändert, sieht das Modell faktisch eine andere Eingabe. Auch Temperatur, Token-Limits, regionale Einstellungen, zusätzliche Dokumente im Kontext oder ein aktualisiertes Regelwerk beeinflussen das Resultat. Wer nur den Modellnamen notiert, übersieht daher einen großen Teil der wirksamen Konfiguration.

Für KMU sind besonders jene Felder kritisch, die eine Zahlung, Buchung oder Frist steuern: Lieferant, IBAN, Rechnungsnummer, Netto- und Bruttobetrag, Umsatzsteuer, Leistungsdatum und Fälligkeit. Ein stilistisch anderer Buchungstext ist meist weniger riskant als eine falsch übernommene Kontoverbindung. Die Protokollierung und der Testumfang sollten sich an dieser Auswirkung orientieren.

Welche Informationen ein brauchbarer KI-Nachweis enthält

Ein Nachweis muss drei Fragen beantworten: Was wurde verarbeitet? Mit welcher Konfiguration? Wer oder was hat das Ergebnis geprüft und freigegeben? Die folgende Tabelle zeigt einen praxistauglichen Mindestumfang. Statt vollständiger Rechnungstexte können interne Dokument-IDs, pseudonymisierte Testfallnummern oder Hashwerte verwendet werden.

Nachweisfeld	Beispiel	Nutzen
Anwendungsfall und Version	Rechnungseingang, Extraktion v3	Trennt fachlich unterschiedliche KI-Funktionen
Eingabereferenz	Dokument-ID und Datei-Hash	Belegt die geprüfte Grundlage ohne unnötige Kopien
Anbieter und Modell	Anbieter, Modellfamilie, konkrete Bereitstellung	Macht Modellwechsel und Anbieteränderungen sichtbar
Prompt, Regeln und Schema	Prompt v7, Steuercode-Regeln v4, JSON-Schema v2	Ordnet das Ergebnis der tatsächlich wirksamen Logik zu
Technische Einstellungen	Temperatur, Sprachraum, OCR-Version	Erklärt Unterschiede außerhalb des Modells
Ergebnis und Prüfstatus	Extrahierte Felder, Konfidenz, Regelverletzungen	Zeigt Qualität und erkannte Unsicherheiten
Menschliche Entscheidung	Korrigiert, freigegeben oder abgelehnt	Belegt die wirksame Kontrolle bei kritischen Vorgängen
Zeitpunkt und Freigabe	Ausführung, Prüfer:in, Release-ID	Verbindet Einzelfall und ausgerollte Änderung

Die Felder müssen nicht in einer einzigen Datenbanktabelle liegen. In vielen Unternehmen genügt eine Kombination aus unveränderlichem Audit-Eintrag, versionierter Konfiguration und einem Testprotokoll je Release. Entscheidend ist, dass die Referenzen zusammenpassen und nur berechtigte Personen Änderungen oder Freigaben vornehmen können.

Praxisbeispiel 1: Ein Modellwechsel verändert die Fälligkeit

Ein Installationsbetrieb erhält Rechnungen von Großhändlern in mehreren Layouts. Die bisherige KI erkennt Zahlungsziele wie „14 Tage netto“ zuverlässig. Nach einem Modellupdate interpretiert sie bei einigen Belegen das Bestelldatum statt des Rechnungsdatums als Ausgangspunkt. Die Trefferquote über alle Felder bleibt hoch, doch die Fälligkeit verschiebt sich in einzelnen Fällen.

Ohne Versionsnachweis fällt die Ursache erst durch verspätete Zahlungen auf. Mit einem festen Testset aus typischen und schwierigen Belegen wird die Abweichung vor dem Rollout sichtbar. Der Betrieb vergleicht für jede Version Rechnungsdatum, Zahlungsziel und berechnete Fälligkeit. Ein deterministischer Check stellt zusätzlich sicher, dass das Datum rechnerisch zum erkannten Zahlungsziel passt. Das Release wird gestoppt, die alte Version bleibt aktiv und der problematische Testfall ergänzt künftig das Regressionstest-Set.

Wichtig ist die Trennung der Aufgaben: Die KI darf Text und Feldkandidaten erkennen. Die Datumsberechnung selbst sollte eine nachvollziehbare Regel ausführen. Dadurch hängt ein kritischer Fristwert nicht allein von einer probabilistischen Antwort ab.

Praxisbeispiel 2: Eine bessere Mahnung enthält den falschen Betrag

Ein Dienstleistungsunternehmen lässt eine KI Entwürfe für freundliche Zahlungserinnerungen formulieren. Nach einer neuen Promptversion klingt der Text klarer und persönlicher. In einem Test übernimmt das System jedoch einen Teilzahlungsbetrag aus einer Notiz, obwohl im offenen Posten ein anderer Restbetrag steht.

Die Lösung ist nicht nur ein längerer Prompt. Der fachliche Wahrheitsbestand muss außerhalb des freien Textes feststehen: offene Summe, Rechnungsnummer und Frist kommen aus strukturierten, geprüften Daten. Die KI formuliert lediglich den sprachlichen Rahmen. Vor dem Versand vergleicht eine Regel alle im Text verwendeten Beträge und Daten mit diesen Quellen. Bei einer Abweichung wird der Entwurf blockiert und einer Person vorgelegt.

Ein solches Vorgehen passt zum bereits erläuterten Vier-Augen-Prinzip im Rechnungsprozess: Nicht jede Textänderung braucht zwei Freigaben, aber zahlungsrelevante Abweichungen erhalten eine klare Kontrollschwelle.

Rechtsrahmen: Was vorgeschrieben ist und was gute Praxis bleibt

EU AI Act: Nicht jede Rechnungs-KI ist automatisch ein Hochrisiko-System

Der EU AI Act ordnet Pflichten nach Rolle und Risikoklasse. Ein Assistent für Rechnungsextraktion oder Formulierung ist nicht allein wegen des Einsatzes von KI automatisch ein Hochrisiko-System. Maßgeblich sind der beabsichtigte Zweck und der konkrete Einsatzkontext. Die Europäische Kommission weist in ihren derzeitigen Entwurfsleitlinien zur Einstufung von Hochrisiko-Systemen ausdrücklich darauf hin, dass nur eine begrenzte Zahl von Anwendungsfällen als hochriskant eingestuft wird. Diese Leitlinien sind aktuell ein Entwurf und nicht rechtsverbindlich.

Für tatsächlich als hochriskant eingestufte Systeme enthält die Verordnung konkrete Vorgaben. Artikel 12 behandelt die technische Fähigkeit zur Protokollierung, Artikel 14 die menschliche Aufsicht und Artikel 15 Genauigkeit, Robustheit und Cybersicherheit. Diese Bestimmungen lassen sich als Qualitätsmaßstab verwenden, dürfen aber nicht pauschal als unmittelbar geltende Pflicht für jede betriebliche Rechnungs-KI dargestellt werden.

Datenschutz gilt unabhängig von der KI-Einstufung

Die österreichische Datenschutzbehörde betont in ihren FAQ zu KI und Datenschutz, dass die Datenschutz-Grundverordnung neben dem AI Act weiterhin gilt. Dazu gehören Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung sowie Integrität und Vertraulichkeit. Sie weist außerdem darauf hin, dass statistisch erzeugte Ausgaben falsch sein können und die Nutzung eines externen KI-Anbieters die Verantwortung des einsetzenden Unternehmens nicht beseitigt.

Für die Dokumentation bedeutet das: Nicht vorsorglich jeden Rechnungsinhalt ein zweites Mal in einem KI-Protokoll speichern. Häufig reichen Referenz, Hash, Version und Prüfentscheidung. Aufbewahrungsfristen, Zugriffsrechte und Löschkonzept sollten pro Anwendungsfall festgelegt werden. Werden personenbezogene Daten an einen Dienstleister übermittelt, sind außerdem Rechtsgrundlage, Auftragsverarbeitung, Sicherheitsmaßnahmen und mögliche Drittlandtransfers zu prüfen.

Deutschland: Änderungen erneut testen und revisionsfest dokumentieren

Die deutsche Datenschutzkonferenz beschreibt in ihrer Orientierungshilfe zu technischen und organisatorischen Maßnahmen bei KI-Systemen den gesamten Lebenszyklus von Gestaltung und Entwicklung bis zu Betrieb und Monitoring. Für den Betrieb empfiehlt sie, bekannte Modellparameter und Verarbeitungsschritte revisionsfest zu dokumentieren. Nach Änderungen und Aktualisierungen sollen Tests wiederholt sowie Ergebnisse und notwendige Anpassungen festgehalten werden. Auch schleichende oder plötzliche Verhaltensänderungen sind zu beobachten.

Österreich und Deutschland wenden denselben europäischen Datenschutzrahmen an. In der praktischen Umsetzung setzt die österreichische Behörde in ihrer FAQ einen gut zugänglichen Schwerpunkt auf Verantwortlichkeit und Datenminimierung; die deutsche Orientierungshilfe beschreibt technische und organisatorische Kontrollen detaillierter. Für grenzüberschreitend tätige KMU ergänzen sich beide Perspektiven.

Ein kontrollierter Modellwechsel in sieben Schritten

Anwendungsfall abgrenzen: Legen Sie fest, ob die KI Daten extrahiert, Vorschläge erstellt, Anomalien meldet oder Texte formuliert. Dokumentieren Sie, welche nachgelagerten Entscheidungen davon abhängen.
Risiko und kritische Felder bestimmen: Kennzeichnen Sie Werte, die Zahlungen, Steuern, Fristen oder Empfänger beeinflussen. Für sie gelten strengere Fehlergrenzen als für Stil oder interne Zusammenfassungen.
Ein repräsentatives Testset pflegen: Für einen kleinen Betrieb können 20 bis 50 anonymisierte oder synthetische Fälle ein sinnvoller Start sein. Enthalten sein sollten typische Belege, schlechte Scans, Gutschriften, Teilzahlungen, mehrere Steuersätze und bekannte Problemfälle.
Erfolg vorab definieren: Messen Sie nicht nur eine Gesamtquote. Legen Sie für kritische Felder eigene Mindestwerte und absolute Ausschlusskriterien fest, etwa keine ungeprüfte Änderung von IBAN oder Bruttobetrag.
Alt und neu parallel testen: Lassen Sie die neue Version zunächst im Schattenbetrieb laufen. Vergleichen Sie Ergebnisse feldweise und untersuchen Sie nicht nur Verschlechterungen, sondern auch unerwartete Verbesserungen.
Freigabe und Rückweg festlegen: Eine fachlich verantwortliche Person bestätigt Testbericht und bekannte Einschränkungen. Die alte Konfiguration bleibt für einen definierten Zeitraum wiederherstellbar.
Nach dem Rollout überwachen: Beobachten Sie Korrekturquoten, blockierte Prüfungen und neue Fehlermuster. Ein Release ist nicht abgeschlossen, nur weil der erste Test bestanden wurde.

Wer bereits KI in der Rechnungsverarbeitung kontrolliert einführen möchte, kann diesen Ablauf als konkrete Erweiterung des Pilotbetriebs nutzen. Bei KI-Kontierungsvorschlägen sollte das Testset insbesondere verschiedene Steuerfälle, Erlös- und Aufwandskonten sowie bewusst mehrdeutige Positionen enthalten.

Typische Fehler bei der Dokumentation

Nur den Produktnamen speichern

Ein Produktname sagt nicht, welche Modellbereitstellung, Promptvorlage oder Regelversion aktiv war. Halten Sie die tatsächlich wirksame Konfiguration fest und verwenden Sie interne Release-IDs, die alle Bestandteile verbinden.

Vollständige Eingaben dauerhaft duplizieren

Mehr Daten bedeuten nicht automatisch mehr Nachvollziehbarkeit. Doppelte Rechnungskopien vergrößern Zugriffs- und Löschaufwand. Nutzen Sie Referenzen oder Hashwerte, solange der Originalbeleg in einem kontrollierten System verfügbar ist.

Nur Durchschnittswerte betrachten

Eine hohe Gesamttrefferquote kann wenige, aber schwerwiegende Fehler verdecken. Bewerten Sie kritische Felder einzeln und führen Sie eine Liste von Fehlern, die ein Release grundsätzlich blockieren.

Menschliche Freigabe ohne klare Aufgabe

Ein zusätzlicher Klick ist keine wirksame Aufsicht. Prüfer:innen müssen wissen, welche Werte sie mit welcher Quelle vergleichen, wann sie ablehnen und wie sie eine Korrektur dokumentieren. Informationen zu organisatorischen und technischen Schutzmaßnahmen bietet auch die öffentliche Claribill-Sicherheitsseite.

Änderungen direkt im Produktivbetrieb testen

Ein stiller Austausch von Modell oder Prompt verhindert einen fairen Vergleich. Versionieren Sie Änderungen, prüfen Sie sie mit demselben Testset und aktivieren Sie sie erst nach einer dokumentierten Freigabe.

Checkliste für den nächsten KI-Release

Ist der Anwendungsfall mit Zweck, Verantwortlichen und betroffenen Daten beschrieben?
Sind Modell, Bereitstellung, Prompt, Regeln, Schema und Vorverarbeitung versioniert?
Enthält das Testset typische Fälle, Grenzfälle und frühere Fehler?
Gibt es eigene Grenzwerte für Beträge, IBAN, Steuern und Fristen?
Werden neue und bisherige Version mit identischen Fällen verglichen?
Sind Freigabe, Sperrkriterien und Rollback dokumentiert?
Werden nur notwendige Protokolldaten gespeichert und Zugriffe begrenzt?
Erfasst das Monitoring Korrekturen und neue Fehlermuster nach dem Rollout?

Häufige Fragen

Reicht es, Modellname und Datum zu protokollieren?

Nein. Modellname und Zeitpunkt sind ein Anfang, erklären aber Änderungen durch Prompt, Ausgabeformat, Regeln, OCR, Kontext oder Einstellungen nicht. Eine interne Release-ID sollte diese Komponenten eindeutig zusammenführen.

Muss jeder einzelne Benutzer-Prompt gespeichert werden?

Nicht zwangsläufig. Bei einem festen Prozess sind versionierte Vorlage, Parameter und Eingabereferenz oft aussagekräftiger. Freie Abweichungen mit fachlicher Wirkung müssen nachvollziehbar sein. Gleichzeitig ist zu vermeiden, sensible Daten ohne klaren Zweck mehrfach zu speichern.

Ist eine KI-Antwort exakt reproduzierbar?

Nicht immer. Selbst bei gleicher Konfiguration können Dienste oder probabilistische Verfahren leicht unterschiedliche Ergebnisse liefern. Das Kontrollziel ist daher nicht zwingend Byte-für-Byte-Gleichheit, sondern ein nachvollziehbarer Prozess mit stabilen Qualitätsgrenzen, erkennbaren Abweichungen und einer belastbaren Freigabe.

Fazit: Versionen machen KI im Rechnungsprozess beherrschbar

KMU benötigen kein überladenes KI-Archiv. Sie brauchen eine klare Verbindung zwischen Anwendungsfall, Eingabe, wirksamer Konfiguration, Prüfergebnis und Freigabe. Ein kleines repräsentatives Testset, feldbezogene Qualitätsgrenzen und ein definierter Rückweg sind wichtiger als eine pauschale Trefferquote. So lassen sich Modellwechsel nutzen, ohne zahlungs- oder steuerrelevante Änderungen unbemerkt in den Alltag zu übernehmen.

Gleiche Rechnung, anderes KI-Ergebnis: Was KMU protokollieren sollten