Zum Hauptinhalt springen
Wenn Ihr Agent Kundendaten verarbeitet, sind die zwei Stellen, an denen PII leakt, die Prompts, die Sie upstream senden und die Logs, die Sie behalten. Dieses Rezept verdrahtet PII-sicheres Logging Ende-zu-Ende: Eine PII-Mask-Regel scheuert den Request vor dem Modell, roher gematchter Inhalt bleibt per Default aus Ihrem Match-Feed heraus, und die Request-Log-Aufbewahrung wird begrenzt, sodass nichts verweilt. Alles unten ist Workspace-Konfiguration in der Konsole — Ihre App ruft weiterhin unverändert /v1/chat/completions auf.
Jeder Konfigurationsschritt ist rollengesteuert. Ein Guardrail zu verfassen erfordert Developer+; die Aufbewahrung oder Compliance-Residency zu ändern erfordert Workspace-Admin. Das Lesen des Matches-Feeds ist für jedes Mitglied offen.

​
1. Die PII-sichere Logging-Pipeline in drei Schritten

Eine PII-sichere Pipeline besteht aus drei unabhängigen Kontrollen, jede ein Schalter, den Sie einmal für den ganzen Workspace umlegen:

Am Rand maskieren

Eine pii-Guardrail-Regel redigiert E-Mails, SSNs, Karten und mehr zu typisierten Tags, bevor das Upstream-Modell den Request je sieht.

Keine rohen Inhalte loggen

Der Guardrail-Schalter Log raw content ist per Default aus, sodass der Match-Feed aufzeichnet, dass eine Regel feuerte, niemals den gematchten Teilstring.

Aufbewahrung begrenzen

Die Request-Log-Aufbewahrung beträgt per Default 30 Tage und ist serverseitig auf ein hartes Maximum von 180 Tagen begrenzt — kurzlebig per Design.
Der Rest dieser Seite verdrahtet alle drei mit einem konkreten Beispiel zusammen.

​
2. PII maskieren, bevor das Modell sie sieht

Erstellen Sie ein Guardrail mit einer einzelnen pii-Regel auf der input-Stage und der mask-Aktion. Bei einer Mask-Aktion wird jeder Treffer durch einen typisierten Tag ersetzt — eine E-Mail wird zu [EMAIL], eine SSN wird zu [SSN] — sodass das Upstream-Modell einen bereinigten Request erhält, nicht das Original. 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ssn", "credit_card", "ip"]
}
In der Konsole: Guardrails → Neues Guardrail, fügen Sie die Regel oben hinzu (oder starten Sie vom PII Shield-Preset unter der Kategorie PII) und speichern Sie dann. Hängen Sie es über das Guardrail-Dropdown des Schlüssels an einen API-Key an, oder setzen Sie es als Workspace-Default, sodass jeder Schlüssel es erbt.
Möchten Sie manche Entitäten maskiert, aber andere ganz abgelehnt? Eine Regel kann Pro-Entitäts-Overrides tragen — email/phone maskieren, aber block auf ssn/credit_card — über entity_actions. Siehe Guardrails für den vollständigen PII-Entitäten-Satz, Custom-Regex-Entitäten und die Pro-Entitäts-Override- Syntax.
Senden Sie einen Request mit diesem Schlüssel, und die E-Mail wird im Flug redigiert: 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Draft a reply to jane@acme.com about her SSN 123-45-6789"}
    ]
  }'
Das Modell sieht Draft a reply to [EMAIL] about her SSN [SSN]. Die Originalwerte verlassen nie das Gateway.
Input-Stage-Masking ist, worauf sich eine PII-sichere Pipeline stützt — es scheuert den Request, bevor der Upstream-Aufruf erfolgt. Output-Stage-Masking funktioniert sowohl auf Nicht-Streaming- als auch auf Streaming-Antworten (Streaming schreibt jeden Chunk an Ort und Stelle um), sodass Sie auch PII redigieren können, die das Modell ausgibt.

​
3. Rohe Inhalte aus Ihren Logs heraushalten

Jede Regel, die feuert, zeichnet einen Match auf — seinen Typ, seine Aktion, seine Stage und einen Detail-String. Ob der Match auch den gematchten Teilstring speichert (die tatsächliche E-Mail-Adresse, die tatsächliche SSN), wird durch den Log raw content-Schalter des Guardrails gesteuert, der per Default aus ist — die datenschutzkonservative Haltung.
Mit Log raw content aus zeigt der Matches-Feed, dass eine pii-Regel eine email auf der input-Stage maskierte, aber niemals die Adresse selbst. Das ist genau, was Sie für eine PII-sichere Pipeline wollen: volle Auditierbarkeit dessen, was feuerte, null behaltene PII. Lassen Sie ihn in Produktion aus; schalten Sie ihn pro Guardrail nur für kurzlebige Triage ein. Der Schalter ist nicht rückwirkend.
Lesen Sie den Feed unter Guardrails → Matches (GET /api/guardrail/match, Member). Gruppieren und filtern Sie nach Guardrail, Regeltyp und Aktion, um Ihre Masking-Rate zu sehen, ohne je einen echten Wert offenzulegen. Einen Match als False Positive zu markieren ist eine Admin-Aktion (POST /api/guardrail/match/:id/mark-fp).

​
4. Begrenzen, wie lange Request-Logs leben

Die Request-Log-Erfassung ist ein Opt-in-Troubleshooting-Feature, und wenn sie an ist, ist die Aufbewahrung begrenzt:
EinstellungWertVerhalten
Default-Aufbewahrung30 TageAngewendet, wenn kein Pro-Workspace-Wert gesetzt ist.
Hartes Maximum180 TageJeder längere Wert wird serverseitig heruntergebremst.
Sie können die 180-Tage-Obergrenze nicht überschreiten — sie wird zur Schreibzeit durchgesetzt, nicht eine Empfehlung. Kombiniert mit dem Masking aus §2 halten selbst erfasste Logs bereinigten Text, und sie altern nach einer festen Uhr aus.
Behandeln Sie erfasste Request-Logs als Debugging-Hebel, nicht als Datenspeicher. Aktivieren Sie die Erfassung während eines Vorfalls, halten Sie das Aufbewahrungsfenster eng und verlassen Sie sich für die Steady-State- Observability auf den Matches-Feed (der nie rohe PII hält, wenn Log raw content aus ist).

​
5. Recht-auf-Löschung und Residency

Zwei weitere Kontrollen runden eine konforme Pipeline ab:
Eine Nutzer-Selbstlöschung tritt in ein 30-Tage-Grace-Fenster, nach dem PII gescheuert wird und eine Kaskaden-Purge die Request-Logs, die Guardrail-Matches und die Firewall-Events dieses Nutzers zusammen entfernt — sodass kein Artefakt die Löschungsanfrage überlebt.
Setzen Sie die Region, an die Ihre Compliance-Report-Artefakte gepinnt werden (us, eu, uk, ap, cn, global), über PUT /api/compliance/residency (Admin). Cross-Region-Lesungen eines Reports werden zurückgehalten. Das pinnt die Region des Report-Artefakts — es ist kein Geo-Pinning von Inferenzdaten.

​
6. Verifizieren, bevor Sie ausliefern

Beweisen Sie, dass das Masking tut, was Sie erwarten, bevor irgendein Traffic davon abhängt:
1

Die Regel in der Sandbox testen

Öffnen Sie den Test-Tab im Guardrail-Editor, fügen Sie Beispieltext mit einer echt aussehenden E-Mail und SSN ein, wählen Sie die input-Stage und führen Sie aus. Die Sandbox gibt das Verdikt und den gerenderten Text ([EMAIL], [SSN]) zurück, ohne einen Upstream-Aufruf oder Kontingent- Verbrauch.
2

Gegen ein Korpus evaluieren

Der Eval-Tab führt die Policy über gebündelte oder Custom-JSONL-Korpora aus, sodass Sie Trefferrate und False Positives messen können, bevor Sie live gehen.
3

Bestätigen, dass der Feed sauber bleibt

Senden Sie einen echten Request, öffnen Sie dann Matches und bestätigen Sie, dass der Eintrag zeigt, dass die Regel feuerte, mit keinem gematchten Teilstring — Beweis, dass Log raw content aus ist.

​
Verwandt

Guardrails-Referenz

Der vollständige PII-Entitäten-Satz, Custom-Entitäten, Pro-Entitäts-Overrides und der Matches-Feed.

Eine RAG-Pipeline absichern

Grounding- und PII-Kontrollen für retrieval-augmentierte Agenten.

SOC-2-Evidenz

Guardrail- und Firewall-Aktivität in signierte Audit-Reports verwandeln.

Datenexfiltration

Das Bedrohungsmodell hinter dem Heraushalten von PII aus der Leitung und den Logs.