Leitplanken: Anforderungen und Richtlinie

Definiert gewünschtes Verhalten, Grenzen, Fehlerreaktionen, menschliche Kontrollen und Sicherheitsanforderungen für Leitplanken. Diese Referenz legt die Annahmegrenze, das Fehlerverhalten und beobachtbare Beweise fest, während umgebungsspezifische Grenzen konfigurierbar bleiben.

Paketstatus: Referenzkontext bereit für menschliche Überprüfung. Der Vertrag und die Testszenarien sind abgeschlossen, es wird jedoch nicht behauptet, dass eine übernehmende Implementierung diese bestanden hat.

Entscheidung

Für Leitplanken wird eine versionierte Orchestrierungsrichtlinie und eine explizite Modellaufrufgrenze übernommen. Das für den Nutzer sichtbare Versprechen, Ausschlüsse, Autorität und Fehlerreaktion werden explizit gemacht, während gemessene Schwellenwerte als Annahmeentscheidungen offenbleiben. Dieses Paket ist ein Referenzvertrag: Das übernehmende Team muss numerische Grenzen, Anbieter, Rechtsordnungen und operative Verantwortliche anhand von Beweisen in der eigenen Umgebung wählen.

Umfang

• Die Akteure, Eingaben, Ausgaben, Zustände, Richtlinien- oder Schema-Versionen und extern sichtbaren Ergebnisse der Leitplanken, die durch diesen Anforderungsblock beschrieben werden.
• Primäre und alternative Schnittstellen, Hintergrundarbeiten, Caches, Integrationen, Supportwege und Beweise, die dieselbe Grenze ausüben können.
• Annahmespezifische Konfiguration, Rollout, Wiederherstellung und Verifikationsverantwortlichkeiten, die für eine sichere Anwendung der Referenz erforderlich sind.

Außerhalb dieses Blocks

• Die Wahl eines universellen Anbieters, Frameworks, einer Rechtsordnung, eines numerischen Schwellenwerts, einer Aufbewahrungsfrist oder eines Service-Level-Objectives für jeden Übernehmer.
• Die Behauptung, dass verpackte Szenarien gegen eine nachgelagerte Implementierung ausgeführt wurden oder dass diese Referenz eine rechtliche, Sicherheits- oder Barrierefreiheitszertifizierung gewährt.

Vertrag

• Speichere die Versionen von Prompt, Tool, Retrieval, Modell und Richtlinie, die benötigt werden, um jedes wesentliche Ergebnis zu reproduzieren oder zu erklären.
• Validieren Sie strukturierte Ausgaben vor jeglichen Nebenwirkungen; fehlerhafte oder unvollständige Ausgaben sind ein Fehler, keine teilweise Autorität.
• Trennen Sie nicht vertrauenswürdige Benutzer- oder abgerufene Inhalte von Systemrichtlinien und kennzeichnen Sie jedes Kontextobjekt mit Ursprung und Vertrauenskategorie.
• Begrenzen Sie Tokens, Tool-Aufrufe, Latenz und Ausgaben pro Anfrage; das Überschreiten einer Grenze führt zu einem benannten Fallback anstelle einer unbegrenzten Fortsetzung.
• Geben Sie an, welcher Akteur unter jedem wesentlichen Zustand welches Ergebnis erhält, einschließlich nicht verfügbarer, nicht autorisierter, leerer und teilweiser Bedingungen.
• Kennzeichnen Sie konfigurierbare Grenzen und Richtlinien als Auswahlmöglichkeiten mit Eigentümern; präsentieren Sie Beispielwerte nicht als universelle Anforderungen.
• Drücken Sie jede Leitplanke als messbare Invariante mit Signalquelle, Fenster, Schwellenwert, betroffenem Umfang, Aktion, Autorität, Eigentümer und sicherem Standardwert aus, wenn die Bewertung nicht verfügbar ist.
• Wenden Sie Grenzen vor irreversibler Arbeit an, machen Sie Überschreibungen eng und zeitlich begrenzt, protokollieren Sie Auslösungen und Umgehungen und testen Sie Fehlalarme, Umgehungen, Wiederherstellung und Wechselwirkungen zwischen mehreren Leitplanken.

Implementierungshinweise

• Überprüfen Sie den Vertrag mit Produkt, Implementierung, Betrieb, Sicherheit und betroffenen Nutzern, bevor Sie ihn über die Überprüfung hinaus fördern.
• Modellieren Sie Eingaben, Ausgaben, Akteure, Zustände, Invarianten, Nebenwirkungen und Beweise der Leitplanken, bevor Sie Framework- oder Anbieterdetails auswählen.
• Speichern Sie die anwendbare Leitplanken-Vertrags- oder Richtlinienversion mit wesentlichem Zustand, damit Migrationen, Wiedergabe und Supportentscheidungen zuordenbar bleiben.
• Führen Sie den Pfad hinter kontrolliertem Rollout ein, vergleichen Sie erwartete und beobachtete Ergebnisse und behalten Sie eine getestete Wiederherstellungsroute, bis Annahmebeweise vollständig sind.

Fehlerbehandlung und Schutzmaßnahmen

• Anbieterfehler, unsichere Ausgaben oder erschöpftes Budget führen zu einem begrenzten Fallback und behalten korrelationssichere Diagnosebeweise.
• Ungültiger oder widersprüchlicher Leitplankenzustand wird abgelehnt oder isoliert; die Implementierung schätzt niemals einen Wert, der Autorität erweitert oder eine Wirkung dupliziert.
• Wiederholungen sind begrenzt und verwenden dauerhafte Identität; nach Erschöpfung erreicht die Arbeit einen überprüfbaren Endzustand mit verantwortlichem Eigentümer.

Verifikation und Betrieb

• Ordnen Sie jedes Versprechen und jeden Ausschluss mindestens einem beobachtbaren Szenario zu und bestätigen Sie, dass keine zwei Zustände widersprüchliche Ergebnisse erfordern.
• Überwachen Sie Erfolg, Ablehnung, Validierungsfehler, Abhängigkeitsfehler, Erschöpfung von Wiederholungen und Wiederherstellung der Leitplanken nach Vertragsversion ohne sensible Nutzlastdimensionen.
• Führen Sie gepaarte positive und negative Fixtures nach Änderungen an Richtlinie, Schema, Abhängigkeiten, Migration oder Grenze erneut aus und bewahren Sie die resultierenden Beweise auf.

Annahmen zur Übernahme

• Namen und Werte im Beispiel sind ein konkretes Fixture, keine universellen Standardwerte; Übernehmer ersetzen sie durch dokumentierte Beweise und Eigentum.
• Das übernehmende System kann authentifizierte Identität, dauerhafte Betriebs- oder Versionsaufzeichnungen, begrenzte Telemetrie und einen kontrollierten Änderungsweg bereitstellen.

Die ausführbar aussehenden Beispiele in diesem Paket sind Fixtures und Akzeptanzverträge. Führen Sie den Sammlungsvalidator aus, um Struktur und Metadaten zu prüfen, übersetzen und führen Sie dann die Szenarien im Ziel-Repository aus, bevor Sie Implementierungsbeweise aufzeichnen.

Referenzen

• NIST AI 600-1, Generative AI Profile (gilt ab 2026-09-08)