Guardrail erstellen

Policies sind das Herzstück der Guardrail-Engine. Sie definieren in natürlicher Sprache, was erlaubt, blockiert oder modifiziert wird — und Palverons NL-Policy-Builder übersetzt einfache Prosa in das passende Detection-Setup.

Neuen Guardrail anlegen

1. Navigieren Sie zu Guardrails in der Sidebar.
2. Klicken Sie Neuer Guardrail (oben rechts).
3. Der Policy-Editor öffnet sich.

📸 Screenshot: Policy-Editor — leere neue Policy mit NL-Builder-Prompt.

NL-Policy-Builder

Oben im Editor sitzt der NL-Policy-Builder — ein einzelnes Textfeld, das einfaches Deutsch in eine funktionierende Policy kompiliert.

Tippen Sie eine Beschreibung wie:

„Blockiere jeden Prompt, der Kreditkartennummern, IBANs oder Sozialversicherungsnummern enthält. Erlaube, wenn der Nutzer die Anfrage für einen Banking-Workflow explizit begründet hat."

Klicken Sie Policy generieren. Der Builder befüllt:

• Name — aus der Kernaussage abgeleitet („Finanzielle PII blockieren")
• Neural Instruction — eine saubere Umformulierung Ihrer Prosa, bereit zur Prüfung
• Enforcement-Aktion — BLOCK, MODIFY, APPROVAL oder FLAG, basierend auf Intent-Verben („blockieren", „maskieren", „freigeben", „loggen")
• Detection-Mode — AUTO per Default; der Builder wählt EXACT, wenn Keywords dominieren, und SEMANTIC, wenn Intent dominiert (siehe Detection Mode)
• Vorgeschlagene Keywords / Regex-Patterns — für jede genannte Entity

Prüfen und editieren Sie jedes Feld vor dem Speichern — der Builder ist ein Startpunkt, keine finale Policy.

Was der NL-Builder gut kann

• Identifizieren, welche Enforcement-Aktion den Verben in Ihrer Beschreibung entspricht
• Generieren von Starter-Keyword-Listen für gängige PII-Typen (E-Mail, Telefon, IBAN, SSN, Kreditkarte)
• Wahl eines sinnvollen Detection-Mode, basierend darauf, ob Sie exakte Muster oder fuzzy Intent beschrieben haben

Was Sie weiterhin selbst entscheiden

• Edge-Cases — „blockieren, außer wenn der Agent im Kundensupport-Workflow mit begründeter Anfrage ist"
• Scope — welche Agenten die Policy betrifft
• Attestation-Level — automatisch für die meisten Policies; nur bei compliance-gebundenen überschreiben

Der Builder wird von POST /api/v1/ai-assist angetrieben — siehe die Policies-API, wenn Sie ihn programmatisch aufrufen wollen (z. B. um Policies aus einer Risiko-CSV zu erzeugen).

Manuelle Felder

Wenn Sie den Builder überspringen möchten, ist jedes Feld direkt editierbar.

Name

Ein kurzer, beschreibender Label (z. B. „PII-Schutz für Kundendaten" oder „Keine Finanzberatung"). Erscheint in Traces, Audit-Logs und Annex-IV-Berichten.

Neural Instruction (Kernanweisung)

Formulieren Sie die Regel in natürlicher Sprache. Beispiele:

• „Blockiere jeden Versuch, personenbezogene Kundendaten — E-Mail-Adressen, Telefonnummern oder Adressen — an ein KI-Modell zu senden."
• „Wenn der Agent eine Finanzberatung geben soll, maskiere die Antwort und füge einen Disclaimer hinzu."
• „Erfordere eine menschliche Freigabe, wenn der Agent eine E-Mail an einen externen Empfänger senden will."

Detection-Mode

Drei Modi verfügbar — siehe Detection Mode für das vollständige Bild:

Enforcement-Aktion

Attestation-Level

Scope

• Alle Agenten — gilt für jeden Agenten im Projekt
• Bestimmte Agenten — aus Multi-Select-Dropdown wählen
• Bestimmte Agent-Typen — gilt für alle Agenten eines Typs (z. B. chatbot, code_assistant)

Policy aktivieren

Nach dem Speichern ist die Policy Inaktiv. Klicken Sie den Toggle Aktiv / Inaktiv zum Aktivieren. Nur aktive Policies laufen im Verify-Flow.

Policy testen

1. Navigieren Sie zum Playground.
2. Wählen Sie einen Agenten, der im Scope liegt.
3. Senden Sie einen Test-Prompt, der die Policy auslösen sollte.
4. Öffnen Sie den Trace im Trace Explorer und bestätigen Sie, dass die Policy gefeuert hat — und prüfen Sie die match_details darauf, was konkret ausgelöst hat.

Wenn eine Policy auslöst, wenn sie nicht sollte (False Positive), zeigt der NGE-Breakdown im Trace die Confidence-Scores — meist ein Hinweis, die Neural Instruction zu verschärfen oder von AUTO auf EXACT zu wechseln.