Wie führt man Auditnachweis bei einem Sprachmodell?

Die Frage kommt spätestens beim zweiten KI-Audit, und sie bringt erfahrene Auditoren ins Stocken. Sie bitten um einen Nachweis, dass das System richtig arbeitet. Sie bekommen ein Bildschirmfoto: eine Eingabe, eine gute Antwort, Datum in der Ecke. Sieht ordentlich aus. Dann stellen Sie dieselbe Frage noch einmal, und die Antwort lautet anders. Nicht falsch, nur anders. Und Ihnen wird klar, dass Sie eben nichts geprüft haben.

Das ist kein Fehler des Betriebs und kein Trick des Anbieters. Es ist die Eigenschaft der Sache. Ein Sprachmodell ist nicht deterministisch: Dieselbe Eingabe erzeugt nicht zwangsläufig dieselbe Ausgabe. Wer das mit den Mitteln prüft, die bei einer Maschine oder einer Buchung funktionieren, prüft ins Leere.

Ich baue selbst KI-Systeme und auditiere sie. Deshalb hier die Antwort, die ich im Kursraum gebe, und die Prüfobjekte, die ich in einem echten Audit verlange.

Warum das Ergebnis kein Nachweis ist

Die ISO 19011 definiert Auditnachweis in Abschnitt 3.10 als Aufzeichnungen, Tatsachenfeststellungen oder andere Informationen, die für die Auditkriterien relevant und **verifizierbar** sind. Auf dem letzten Wort liegt das ganze Gewicht.

Verifizierbar heißt: Ein Dritter kann nachvollziehen, dass die Aussage stimmt. Bei einer Rechnung geht das, sie liegt vor und ändert sich nicht. Bei einer Maschineneinstellung geht das, sie steht im Protokoll. Bei einer einzelnen Modellausgabe geht es nicht, denn sie ist nicht wiederholbar. Sie ist eine Momentaufnahme aus einem Vorgang, den Sie nicht gesehen haben.

Ein Bildschirmfoto beweist, dass irgendwann irgendetwas auf einem Bildschirm stand. Es beweist nicht, welches Modell geantwortet hat, mit welchem Systemprompt, auf welcher Datengrundlage und ob jemand die Antwort vor der Verwendung angesehen hat.

Daraus folgt die Verschiebung, die den ganzen Unterschied macht. Beim klassischen System prüfen Sie das Ergebnis. Beim Sprachmodell prüfen Sie **den Prozess, der zum Ergebnis führt**. Der Prozess ist stabil und dokumentierbar, das einzelne Ergebnis ist es nicht.

Sechs Nachweisobjekte, die tragen

Das sind die Dinge, nach denen ich frage. Sie sind alle aufzeichenbar, alle verifizierbar und alle unabhängig von der einzelnen Antwort.

Der wichtigste Satz zu dieser Tabelle: Jede Zeile ist eine **dokumentierte Information**, nicht eine Beobachtung. Sie können sie mitnehmen, ablegen und in zwei Jahren wieder hervorholen. Genau das kann ein Bildschirmfoto nicht.

Der Freigabeschritt verdient eine eigene Bemerkung, weil er in fast jedem Audit derselbe Streitpunkt ist. Menschliche Aufsicht, die nur im Konzept steht, ist keine. Ich frage deshalb nicht, ob jemand draufschaut, sondern woran ich das erkenne: ein Häkchen mit Zeitstempel, ein zweiter Benutzername, ein Bearbeitungsstand, ein Vermerk im Vorgang. Wenn es keine Spur gibt, gibt es keinen Nachweis, und dann steht die Aufsicht im Konzept und nirgendwo sonst.

Beim Eingabefenster lohnt das Nachfragen besonders, weil die erste Antwort fast immer zu großzügig ausfällt. „Das System hat Zugriff auf unser Wiki“ ist keine Beschreibung des Eingabefensters, sondern eine Beschreibung einer Berechtigung. Entscheidend ist, was tatsächlich in die Anfrage hineinwandert: Wie viele Textstücke werden ausgewählt, wonach, und was passiert, wenn nichts Passendes gefunden wird? Antwortet das System dann aus dem allgemeinen Modellwissen weiter, ohne das kenntlich zu machen, haben Sie eine Auskunft ohne Grundlage, und sie sieht aus wie jede andere.

Und beim Systemprompt geht es nicht um Geheimniskrämerei, sondern um Versionierung. Er ist die Betriebsanweisung des Systems. Bei einer Maschine würde niemand akzeptieren, dass die Arbeitsanweisung in einem Textfeld steht, das jeder ändern kann und das keine Historie führt. Bei KI-Anwendungen ist genau das der Normalfall, und es ist der häufigste Punkt, an dem meine Nachweiskette reißt.

Was Norm und Gesetz dazu verlangen

Die ISO/IEC 42001 führt drei Maßnahmen, die genau hier greifen. **A.6.2.6** verlangt die Elemente für Betrieb und Überwachung des KI-Systems. **A.6.2.7** verlangt, die technische Dokumentation zu bestimmen. Und **A.6.2.8** trägt den Titel, der die Sache auf den Punkt bringt: Aufzeichnung von Ereignisprotokollen. Die Organisation muss festlegen, in welchem Umfang protokolliert wird.

Auf der Rechtsseite steht Artikel 12 der KI-Verordnung. Er verlangt für Hochrisiko-Systeme die **automatische Aufzeichnung von Ereignissen über die Lebensdauer** des Systems. Absatz 2 sagt, wozu: um Situationen zu erkennen, die ein Risiko oder eine wesentliche Änderung bedeuten, um die Beobachtung nach dem Inverkehrbringen nach Artikel 72 zu ermöglichen und um den Betrieb nach Artikel 26 Absatz 5 zu überwachen.

Für eine bestimmte Gruppe wird Absatz 3 dann sehr konkret und nennt einen Mindestumfang: den Zeitraum jeder Verwendung mit Beginn und Ende, die Referenzdatenbank, gegen die abgeglichen wurde, die Eingabedaten, die zu einem Treffer geführt haben, und die Identität der Personen, die das Ergebnis überprüft haben.

• Die Pflicht aus Artikel 12 trifft **Hochrisiko-Systeme**. Wer ein Sprachmodell für interne Textarbeit einsetzt, fällt in aller Regel nicht darunter.
• Der genannte Mindestumfang aus Absatz 3 gilt für eine noch engere Gruppe, nämlich biometrische Systeme nach Anhang III Nummer 1 Buchstabe a.
• Trotzdem ist die Aufzählung für jeden Betrieb brauchbar, weil sie zeigt, was der Gesetzgeber für die Mindestmenge an Nachvollziehbarkeit hält.

Ich sage das so deutlich, weil in Beratungsgesprächen gern das Gegenteil passiert: Artikel 12 wird zitiert, als gälte er für jeden Chatbot. Das ist falsch, und es beschädigt die Glaubwürdigkeit derer, die ihn zu Recht anführen.

Ein Punkt, der beim Wort Protokoll regelmäßig untergeht: Es gibt zwei Sorten davon, und nur eine trägt. Das Betriebsprotokoll hält fest, dass der Dienst lief, wie schnell er antwortete und wann er ausfiel. Das ist Verfügbarkeit. Für die Nachweisführung brauchen Sie das andere: eine Aufzeichnung der **Nutzung**, also wer wann welche Anfrage gestellt hat, unter welchen Bedingungen sie beantwortet wurde und was mit dem Ergebnis geschah. Wenn ein Betrieb mir ein Protokoll zeigt und darin stehen Antwortzeiten in Millisekunden, dann habe ich das falsche Dokument in der Hand.

Dazu kommt die Aufbewahrung. Ein Protokoll, das nach sieben Tagen überschrieben wird, hilft bei einem Audit nicht, das ein halbes Jahr später stattfindet. Die Frage nach der Aufbewahrungsfrist gehört deshalb an dieselbe Stelle wie die Frage nach dem Umfang, und beide sollten dieselbe Antwort haben wie die übrigen Aufzeichnungen des Managementsystems.

Die Änderung, die niemand unterschreibt

Hier liegt der Unterschied zu jedem anderen System, das Sie je auditiert haben. Eine Maschine ändert ihr Verhalten, wenn jemand sie umbaut. Eine Software ändert es, wenn jemand ein Update einspielt. Ein zugekauftes Sprachmodell kann es ändern, **ohne dass in Ihrem Haus irgendjemand etwas tut**.

Ein Praxisfall aus einem Lieferantenaudit: Die Auswertung eingehender Anfragen lief seit einem Jahr stabil. Zwischen zwei Stichproben änderte sich die Formulierung der Ergebnisse spürbar. Niemand im Betrieb hatte etwas geändert. Der Anbieter hatte die Modellversion hinter demselben Produktnamen ausgetauscht. Vertraglich war nichts geschehen, technisch alles.

Für die Nachweisführung heißt das zweierlei. Erstens gehört die Modellversion in jede Aufzeichnung, nicht nur der Produktname. Zweitens braucht es eine Stelle, an der solche Wechsel überhaupt auffallen. In der Praxis ist das die Managementbewertung: ein eigener Tagesordnungspunkt mit dem aktuellen Bestand der eingesetzten KI-Systeme und den Änderungen seit dem letzten Mal.

Wer diesen Punkt nicht führt, merkt eine Änderung erst, wenn sie Folgen hat. Und dann ist die Frage, seit wann das System anders arbeitet, nicht mehr beantwortbar.

Wie ich im Audit tatsächlich vorgehe

Drei Griffe, die den Unterschied machen, und keiner davon braucht ein Werkzeug.

**Erstens: dieselbe Eingabe zweimal.** Ich lasse denselben Fall zweimal durchlaufen, mit Abstand. Weichen die Ergebnisse ab, ist das kein Befund, sondern die Ausgangslage. Der Befund entsteht daraus, wie der Betrieb damit umgeht. Gibt es eine Bandbreite, die als in Ordnung gilt? Wer hat sie festgelegt? Woran merkt jemand, dass sie verlassen wird?

**Zweitens: das Protokoll statt des Bildschirmfotos.** Ich frage nicht nach einem Beispiel, sondern nach dem Auszug für einen Zeitraum. Ein Beispiel bringt der Betrieb mit, ein Auszug entsteht vor meinen Augen. Der Unterschied ist derselbe wie zwischen einer vorbereiteten Akte und einem Griff ins Regal.

**Drittens: die Kette rückwärts.** Ich nehme ein Ergebnis, das der Betrieb tatsächlich verwendet hat, und gehe zurück: Welche Version hat es erzeugt, mit welchem Systemprompt, auf welcher Datengrundlage, wer hat es freigegeben. Wo die Kette reißt, liegt der Befund. Meistens reißt sie beim Systemprompt, weil ihn niemand versioniert.

Wichtig ist dabei die Auswahl des Falls. Ich lasse mir keinen zeigen, sondern ziehe ihn aus dem Bestand, und zwar bewusst keinen einfachen: einen Vorgang, bei dem etwas nachgefragt oder korrigiert wurde. Ein glatter Fall zeigt, dass die Kette an einem guten Tag hält. Ein strittiger zeigt, ob sie hält, wenn es darauf ankommt, und genau darum geht es im Audit.

Wo die Kette reißt, formuliere ich den Befund übrigens nicht als „das System ist nicht nachvollziehbar“. Das wäre eine Bewertung des Werkzeugs. Der Befund lautet, dass die Organisation den Umfang der Protokollierung nicht festgelegt hat oder ihn festgelegt, aber nicht eingehalten hat. Das ist überprüfbar, es hat eine Fundstelle, und es lässt sich abstellen. Der andere Satz führt nur zu einer Diskussion über Technik, die niemand gewinnt.

Und eine Erwartung nehme ich den Betrieben, weil sie sonst das Falsche bauen: Es geht nicht darum, jede Ausgabe reproduzierbar zu machen. Das ginge nur, indem man dem System die Fähigkeit nimmt, die man eingekauft hat. Es geht darum, die **Bedingungen** reproduzierbar zu machen, unter denen es gearbeitet hat.

Was das für zugekaufte Systeme bedeutet

Die meisten Betriebe bauen kein Modell, sie kaufen einen Dienst. Damit wandern vier der sechs Nachweisobjekte zum Anbieter: Modellversion, Filter, Protokoll und ein Teil des Eingabefensters liegen dort. Sie bleiben trotzdem in Ihrer Verantwortung, denn die Aussage nach außen macht Ihr Haus, nicht der Anbieter.

Deshalb gehören diese Punkte in den Vertrag und in die Lieferantenprüfung, nicht in ein Wunschkonzert: Werden Modellwechsel angekündigt, und mit welcher Frist? Bekommen Sie Protokolle, oder nur eine Verfügbarkeitszusage? Dürfen Sie prüfen oder prüfen lassen? Wer sind die Unterauftragnehmer?

Wer diese vier Fragen nicht beantwortet bekommt, hat kein Nachweisproblem, sondern ein Beschaffungsproblem. Und das ist die bessere Nachricht, denn ein Beschaffungsproblem lässt sich vor der Unterschrift lösen.