Verfahrensversionen für KI-Agenten sicher wechseln
Steuern Sie Verfahrensversionen für KI-Agenten mit unveränderlichen Ständen, geregelten Fallübergängen, Regressionstests und nachvollziehbarem Rollback.
Verfahrensversionierung für KI-Agenten bedeutet, die genauen Anweisungen, Entscheidungsregeln, Quellenannahmen und Werkzeugverträge eines bearbeiteten Falls zu erhalten. Wird ein Prompt an Ort und Stelle überschrieben, lässt sich dieser Verlauf nur schwer rekonstruieren. Behandeln Sie einen Verfahrensstand als unveränderliche Konfiguration. Binden Sie jeden Lauf daran und entscheiden ausdrücklich, wie offene Fälle auf einen neueren Stand wechseln.
Dieser Artikel behandelt operative Worker, die nach einem definierten Verfahren Fallakten oder Empfehlungen vorbereiten. Im Mittelpunkt steht die Änderungskontrolle, nicht das Modelltraining. Auch ein neues Modell, ein anderer Konnektor oder veränderte Zugriffsgrenzen können das Verhalten beeinflussen. Der Verfahrensdatensatz muss deshalb diese Abhängigkeiten referenzieren. Der Prompt allein beschreibt nicht das gesamte System, dessen Ergebnisse später nachvollzogen werden sollen.
Bestimmen, was zu einem Verfahrensstand gehört
Beginnen Sie mit den Schritten, die eine qualifizierte Prozessverantwortliche wiedererkennt: notwendige Eingaben, zulässige Quellen, Entscheidungspunkte, Ausschlüsse, Nachweispflichten und menschliche Übergaben. Verknüpfen Sie diese Schritte mit ausführbarer Konfiguration und Werkzeugverträgen. Speichern Sie die genehmigte fachliche Bedeutung neben der maschinenlesbaren Konfiguration. So können Prüfende eine Änderung beurteilen, ohne ausschließlich Quellcode lesen zu müssen.
Das NIST AI RMF Playbook unterstützt dokumentierte Aktivitäten zur Steuerung von KI-Risiken. Der folgende unveränderliche Freigabedatensatz ist unser technischer Entwurf für einen begrenzten Ablauf. Er ist weder ein von NIST festgelegtes Schema noch eine rechtliche Aufbewahrungsvorgabe oder ein Nachweis externer Prüfung. Die Verantwortung für die konkrete Ausgestaltung bleibt bei der betreibenden Organisation.
| Bestandteil | Warum er dokumentiert wird | Zu untersuchende Änderung |
|---|---|---|
| Verfahrensrevision | Kennzeichnet genehmigte Schritte und Ausschlüsse | Eine neue Regel verändert, welche Fälle menschliche Prüfung benötigen |
| Quellenregel | Definiert zulässige Nachweise und ihre Aktualität | Eine bisher erlaubte Quelle ist nicht mehr verfügbar oder geeignet |
| Werkzeugvertrag | Definiert erlaubte Argumente und Nebenwirkungen | Ein Konnektor akzeptiert ein neues Ziel oder verändert Standardwerte |
| Modellkonfiguration | Kennzeichnet die verwendete Verarbeitungskomponente | Anbieter oder Modelleinstellung verändern das Ausgabeverhalten |
| Evaluierungsreferenz | Verknüpft den Stand mit geprüften Fällen und Feststellungen | Ein Ergebnis gehört zu einer früheren Konfiguration |
| Freigabereferenz | Dokumentiert die Zustimmung zum begrenzten Einsatz | Die zustimmende Rolle deckt das geänderte Verfahren nicht mehr ab |
Vertrauliche Prompts, Kundendokumente und Zugangsdaten bleiben in den dafür vorgesehenen geschützten Speichern. Der Freigabedatensatz kann Referenzen und Prüfsummen enthalten. Eine Prüfsumme hilft, unveränderte Bytes zu erkennen. Sie erklärt jedoch nicht die fachliche Bedeutung einer Änderung. Bewahren Sie deshalb eine verständliche Änderungsbeschreibung und die Verantwortung für die Folgenbewertung auf. Beides muss zum tatsächlich bereitgestellten Stand passen.
Änderungen einordnen, bevor Tests ausgewählt werden
Eine reine Darstellungsänderung braucht möglicherweise nicht dieselbe Evaluierung wie ein neuer Entscheidungszweig. Aber auch eine sprachliche Anpassung kann das Modellverhalten ändern, wenn sie eine Anweisung statt einer sichtbaren Beschriftung betrifft. Prüfen Sie die tatsächlichen Ausführungseingaben. Ein Ticket mit der Bezeichnung „Textbereinigung“ sagt noch nichts darüber aus, ob die Änderung für das Verfahren unbedenklich ist.
Unterscheiden Sie drei praktische Klassen: Darstellung, Verhalten und Befugnisse. Darstellung verändert die Ansicht, ohne Ausführungseingaben zu beeinflussen. Verhaltensänderungen betreffen Vorbereitung oder Empfehlungen innerhalb bestehender Grenzen. Änderungen der Befugnisse betreffen erlaubte Systeme, Daten, Aktionen oder Freigaberegeln. Für die letzte Klasse müssen die technischen Durchsetzungsgrenzen ausdrücklich geprüft werden. Gute Aufgabenqualität allein reicht dafür nicht aus.
Eine Regel für offene Fälle wählen
Drei Strategien sind üblich: unter dem ursprünglichen Stand abschließen, unter dem neuen Stand neu beginnen oder über einen ausdrücklich dokumentierten Übergang migrieren. Wählen Sie nach Risiko und Kompatibilität des Falls. Ein alter Entwurf mit einer neuen Freigaberegel ist später nur zuverlässig interpretierbar, wenn der Übergang und seine Bedeutung im Verlauf festgehalten wurden.
Dokumentieren Sie bei einer Migration den bisherigen Stand, den neuen Stand, den betroffenen Fall, den Grund und die weiter gültigen Nachweise. Kennzeichnen Sie vorbereitete Ergebnisse, die neu erstellt werden müssen. War eine Freigabe an das alte Ergebnis gebunden, darf sie nicht allein wegen unveränderter Fallkennung bestehen bleiben. Die Aktion und ihre Grundlage entscheiden darüber, ob eine erneute Prüfung erforderlich ist.
Eine dringende Sicherheitskorrektur kann verlangen, alle betroffenen Fälle zu stoppen, statt sie fertiglaufen zu lassen. Ermitteln Sie, welche Aktionen bereits externe Systeme erreicht haben. Ihre Folgen bleiben auch nach dem Verfahrenswechsel bestehen. Der Migrationsplan braucht daher einen Ergebnisabgleich und gegebenenfalls eine gesondert berechtigte Korrekturaktion. Ein neuer Verfahrensstand hebt eine bereits entstandene Verpflichtung nicht von selbst auf.
Rollback als neue Betriebsentscheidung behandeln
Die frühere Konfiguration aufzubewahren ist sinnvoll. Ihre erneute Auswahl ist jedoch nicht automatisch sicher. Seit ihrem letzten Einsatz können sich Quellenberechtigungen, Zugangsdaten, Systemzustände und fachliche Regeln geändert haben. Prüfen Sie die relevanten Abhängigkeiten erneut, bevor neue Arbeit an den alten Stand geht. Dokumentieren Sie, welche Voraussetzungen geprüft wurden und welche weiterhin unklar sind.
Erfassen Sie den Rollback als neues Bereitstellungsereignis mit Verweis auf das ältere Verfahren. Schreiben Sie die Historie nicht um, damit die fehlerhafte Bereitstellung verschwindet. Bewahren Sie betroffene Fälle, beobachtetes Problem und Umfang der Wiederherstellung auf. Dadurch bleibt unterscheidbar, ob lediglich Software wiederhergestellt oder auch eine fachliche Wirkung tatsächlich rückgängig gemacht wurde.
Übergänge mit einem eigenen Fallsatz prüfen
Erstellen Sie einen synthetischen Fall mit einem abgeschlossenen Vorbereitungsschritt, einer offenen Prüfung und einer Aktion mit unbekanntem Ausgang. Ändern Sie die Nachweisanforderung des Verfahrens. Der abgeschlossene Schritt muss seine ursprüngliche Herkunft behalten. Die Prüfung muss die neue Anforderung erkennen. Die unklare Aktion muss vor einer Wiederholung abgeglichen werden. Jeder dieser Zustände erfordert eine andere Reaktion.
Führen Sie danach dieselbe Eingabe unter beiden Ständen mit deaktivierten externen Wirkungen aus. Vergleichen Sie Quellenabdeckung, unbelegte Aussagen, Übergabeentscheidungen und vorgeschlagene Aktionen. Ein Textvergleich hilft, genügt aber nicht. Zwei anders formulierte Entwürfe können gleichwertig sein. Ein einziger geänderter Empfänger kann dagegen die erforderliche Befugnis vollständig verändern, obwohl der übrige Text gleich geblieben ist.
Bewahren Sie die fachliche Interpretation neben dem maschinellen Vergleich auf. Unterscheiden Sie beabsichtigte Änderungen, unerwartete Verschlechterungen und ungelöste Meinungsverschiedenheiten. Nicht jede Abweichung ist ein Fehler. Umgekehrt darf nicht jede Abweichung als harmlose Modellschwankung abgetan werden. Welche Unterschiede entscheidend sind, ergibt sich aus den fachlichen Anforderungen des Verfahrens und den Folgen einer falschen Entscheidung.
Einen brauchbaren Änderungsverlauf erhalten
Eine nützliche Historie beantwortet vier Fragen: Welcher Stand hat den Fall bearbeitet, warum war er freigegeben, was wurde danach verändert und hatte die Änderung Auswirkungen auf das Ergebnis? Hinterlegen Sie stabile Verweise in der Fallakte. Ein Eintrag ausschließlich im Bereitstellungswerkzeug hilft einer prüfenden Person wenig, wenn sie darauf keinen Zugriff hat oder die fachlichen Zusammenhänge fehlen.
Wird eine alte Quelle nach der geltenden Aufbewahrungsregel gelöscht, dokumentieren Sie ihr Fehlen und die Folgen für die Überprüfung. Ersetzen Sie sie nicht unbemerkt durch eine neuere Quelle mit dem Anschein, der frühere Lauf hätte diese verwendet. Reproduzierbarkeit kann dadurch eingeschränkt sein. Der Verlauf muss diese Einschränkung ehrlich zeigen, statt eine vollständige Wiederholbarkeit vorzutäuschen.
Lassen Sie vor Einführung der Vorlage eine absichtlich unterbrochene Migration rekonstruieren. Eine qualifizierte Person sollte erkennen können, welche Arbeit fortgesetzt werden darf, welche Freigaben veraltet sind und welche externen Ergebnisse unbekannt bleiben. Hängt die Antwort vom persönlichen Gedächtnis einzelner Entwickler ab, fehlt ein Übergangsdatensatz. Versionsnummern sind erst dann hilfreich, wenn sie solche konkreten Betriebsentscheidungen ermöglichen.
Vorlage und ergänzende Umsetzungsleitfäden nutzen
Nutzen Sie den übergeordneten Leitfaden für die umfassendere Architektur und wenden Sie diesen Artikel auf eine klar begrenzte Umsetzung an. Die ergänzenden Artikel behandeln verwandte Entscheidungen, ohne diese Vorlage zu ersetzen.
Bearbeitbare Vorlage herunterladen. Nächster Schritt.
Technischer Entwurf vom 18. Oktober 2026. Primärquellen wurden an diesem Datum geprüft; die fachliche Prüfung steht noch aus. Die Vorlagen beschreiben vorgeschlagene Tests, keine gemessenen Kundenergebnisse. OATI bleibt eine Entwicklervorschau. Lokale Implementierungsnachweise belegen keine unabhängige Prüfung, Kundenabnahme oder Produktionsreife einer konkreten Bereitstellung.