Ein KI-Modell austauschen und am selben Ablauf prüfen

Prüfen Sie bei einem Modellwechsel den vollständigen betroffenen Anwendungsablauf. Eine neue Modellkennung in der Konfiguration reicht als Nachweis nicht aus. Nutzen Sie einen bestehenden Bewertungssatz und halten Sie fest, welche Änderung Sie tatsächlich vergleichen.

Die beiden Konfigurationen eindeutig festhalten

Dokumentieren Sie Modellkennung, Promptfassung, bereitgestellte Quellen, Werkzeuge und Einstellungen beider Varianten. Bleiben Eingaben, Regeln und Verarbeitung gleich, lässt sich der Modellwechsel gezielter untersuchen. Müssen Sie auch Prompt, Adapter oder Auswertung ändern, vergleichen Sie zwei Anwendungskonfigurationen; schreiben Sie den Unterschied nicht allein dem Modell zu.

Microsoft beschreibt den Vergleich gespeicherter Varianten anhand derselben Fälle und die Prüfung einzelner Fehler. Für Ihren Ablauf müssen die fachlichen Sollentscheidungen vor dem Vergleich feststehen.

Unterschiede je Fall sichtbar machen

Das folgende Beispiel ist vollständig erfunden. Eine Anwendung soll aus einer Nachricht eine Projektkennung extrahieren oder eine manuelle Prüfung anfordern. Sie vergibt keinen Projektzugriff. Die Feldnamen sind unser eigenes internes Schema, keine Anbieter-API.

Die Tabelle enthält angenommene Ausgaben zur Erklärung. Sie ist kein ausgeführter Modelltest. Die Fallbeschreibungen ersetzen nicht die versionierten Originaleingaben eines echten Vergleichs.

Im zweiten Fall wählt die neue Variante trotz Unklarheit ein Projekt. Im dritten verletzt sie den Feldvertrag. Eine zusammengefasste Bewertung würde diese unterschiedlichen Fehlerursachen verdecken. Auch formal gültige Ausgaben müssen fachlich passen.

Fehler vor der Weiterverarbeitung behandeln

OWASP empfiehlt, Modellausgaben vor der Übergabe an nachgelagerte Komponenten zu validieren. Im Beispiel darf ein fehlendes Pflichtfeld nicht als erfolgreicher Extraktionslauf weiterlaufen. Die Anwendung muss die Ausgabe ablehnen oder in den vorgesehenen Prüfweg führen. Ein vorhandenes Projektfeld ist weiterhin keine Zugriffsberechtigung.

Prüfen Sie neben solchen Fach- und Formatfällen auch tatsächlich benötigte Sprachen, Ausfälle und Wiederholungen. Ein einzelner Durchlauf zeigt keine stabile Fehlerhäufigkeit. Werden bekannte Fehler zum Anpassen der neuen Variante genutzt, sind ergänzende zurückgehaltene Fälle für eine unabhängige Kontrolle nötig.

Freigabe und Rückkehr gemeinsam planen

Legen Sie vor der Freigabe fest, welche Fehler den Wechsel verhindern und wer offene Unterschiede beurteilt. Im Tabellenbeispiel sind die vorschnelle Projektzuordnung aus einer unklaren Nachricht und das fehlende Pflichtfeld zunächst zu klären.

Bewahren Sie die bisherige Anwendungskonfiguration und einen überprüften Rückkehrweg auf. Klären Sie dabei auch, ob das bisherige Modell weiterhin verfügbar ist und die gespeicherten Daten kompatibel bleiben. Nach dem Wechsel sind die tatsächlichen Ergebnisse des betroffenen Ablaufs zu beobachten; drei illustrative Fälle belegen keine allgemeine Produktionsreife.

Quellen

• Microsoft — Evaluate models, prompts, and agents

• OWASP 2025 — Improper Output Handling