KI-Policy-Versionskontrolle ist die Praxis, die KI-Guardrail-Policy in Git zu speichern, Änderungen durch PRs zu reviewen und jedes Produktions-Release auf eine spezifische Policy- Version zu pinnen. Jede Entscheidung, die das System macht — jede Refusal, jedes Routing zu Human-Review, jeder Kosten-Cap — trackt zurück zur Policy, unter der es operierte. Die Policy und der Code, der sie durchsetzt, bewegen sich zusammen.
Warum die Policy versionieren.
- Auditierbarkeit. «Welche Regel galt um 14:23 am 2026-04-02?» sollte eine Antwort haben. Ohne Versionskontrolle hat sie null.
- Rollback. Eine Policy-Änderung, die zu viele False-Refusals produziert, kann wie eine Code-Änderung zurückgerollt werden. Ohne Versionierung ist Rollback «mache rückgängig, was irgendjemand ins Doc geschrieben hat».
- Regulatorische Bereitschaft. Der EU AI Act, Sektor-Regulatoren (FINMA, BaFin) und die meisten Enterprise-Kunden fragen nach einer versionierten Policy als Evidenz. Bauen Sie sie; Sie werden sie brauchen.
Wie die Policy-Datei aussieht.
Markdown oder YAML in Version-Control, neben der Eval- Rubrik und den Prompts. Jede Klausel ist nummeriert. Jede Klausel hat eine assoziierte Fixture in der Eval-Harness, die assertert, dass das System sie honoriert. Der Release-Tag pinnt die Policy-Version: wenn das System eine Entscheidung macht, zeichnet der Observability-Trace sowohl die Modell-Version als auch die Policy-Version auf.
Der Änderungs-Prozess.
Policy-Edits gehen wie Code durch PR-Review. Product, Engineering und Legal (wo zutreffend) reviewen. Der PR enthält die neuen Fixtures, die die neuen Klauseln testen, und das Regression-Gate muss gegen sowohl die alten als auch die neuen Fixture-Sets passen. Mergen triggert ein Re-Baseline jeder Metrik, die die neue Policy affected.
Häufige Fragen.
- Was ist KI-Policy-Versionskontrolle?
- KI-Policy-Versionskontrolle ist die Praxis, die KI-Guardrail-Policy in Git zu speichern, Änderungen durch PRs zu reviewen und jedes Produktions-Release auf eine spezifische Policy-Version zu pinnen. Jede Entscheidung, die das System macht, trackt zurück zur Policy, unter der es operierte — was Rollback, Audit und regulatorische Response straightforward macht.
- Wo sollte die Policy-Datei leben?
- In Version-Control, neben der Eval-Rubrik, den Prompts und dem Agent-Code. Markdown oder YAML sind die gängigen Formate; jede Klausel ist nummeriert und hat eine assoziierte Fixture in der Eval-Harness. Die Policy in Notion oder einem Wiki ohne Versionierung zu speichern, ist der häufigste Pfad zu einem Audit-Failure.
- Wie hilft Policy-Versionskontrolle mit dem EU AI Act?
- Auditoren fragen nach der Policy, die zum Zeitpunkt einer gegebenen Entscheidung in Kraft war. Mit Versionskontrolle plus Observability-Traces, die die Policy-Version pro Request aufzeichnen, ist die Antwort ein Git-Ref. Ohne sie erfordert die Antwort Rekonstruktion aus Logs und Gedächtnis, und Rekonstruktion ist das, was Auditoren bestrafen.
- Wer reviewt eine Policy-Änderung?
- Product besitzt die Policy. Engineering reviewt den Enforcement-Mechanismus. Legal oder Compliance reviewt, wenn die Änderung Refusal-Kategorien, Audit-Verpflichtungen oder regulatorische Klauseln berührt. Das PR-Template fragt nach Sign-off von allen drei, wo zutreffend.
Englische Fassung: KI-Policy-Versionskontrolle on the EN edition.