Streaming Output Real-Time PII Guard Prompt Template

This prompt is designed for real-time application teams who need to sanitize streaming model outputs before they reach end users, logs, or databases. It operates on partial text chunks as they arrive from a streaming API, detecting and redacting personally identifiable information (PII) such as names, email addresses, phone numbers, and physical addresses. Unlike batch PII scanners that wait for a complete response, this prompt handles the unique challenges of streaming: partial tokens, split entities across chunk boundaries, and strict latency budgets. Use this prompt when you are building a chat interface, copilot, or real-time agent that streams responses directly to users and you cannot afford to buffer the entire output before redaction.

The ideal user is a backend or platform engineer integrating an LLM provider's streaming endpoint into a customer-facing product. You have a WebSocket or server-sent events (SSE) connection delivering tokens incrementally, and you need to interpose a redaction layer that does not introduce perceptible lag. This prompt is part of a larger streaming pipeline: you will likely pair it with a lightweight buffer that accumulates tokens until a word boundary is reached, then flushes the sanitized chunk to the UI. You must also implement a stateful tracker that remembers partial matches across chunks—for example, if an email address is split as user@dom in one chunk and ain.com in the next, the guard must reassemble and redact the complete entity. The prompt template itself is the core instruction set you send to a fast, low-latency model (or a local classifier) to make redaction decisions on each buffered segment.

Do not use this prompt for offline batch processing, structured JSON field validation, or compliance-grade de-identification where a deterministic regex-based system with an audit trail is required. This prompt trades perfect recall for speed; it will miss some PII under high throughput or unusual formatting. It is a safety net, not a compliance guarantee. If you need to prove to an auditor that every Social Security number was redacted, use a batch regex pipeline with logged transformations. If you need to sanitize a live chat stream where a 50ms delay is acceptable but a 500ms buffer is not, this is the right tool. Before implementing, define your latency budget, your acceptable false negative rate, and your escalation path for high-risk PII categories that should trigger human review rather than automated redaction.

This prompt is designed to be called in a tight loop for each new text chunk arriving from a streaming model. It receives the previously buffered text and the new chunk, and its job is to output only the safe, redacted portion of the new chunk that can be immediately forwarded to the user. The core challenge is handling partial PII matches that span chunk boundaries, which requires a stateful buffer management strategy in the application harness, not just a single stateless prompt call.

textCopy
SYSTEM: You are a real-time PII redaction guard. Your only job is to output the safe, redacted version of the [CURRENT_CHUNK] that can be immediately displayed. You must never output PII.

CONTEXT:
- [BUFFERED_TEXT] is the text from previous chunks that ended with a potential partial PII match.
- [CURRENT_CHUNK] is the new text to process.
- [PII_CATEGORIES] is the list of PII types to redact (e.g., PERSON_NAME, EMAIL, PHONE_NUMBER, SSN, CREDIT_CARD, ADDRESS).
- [REDACTION_STRATEGY] specifies how to redact: MASK (replace with [REDACTED]), CATEGORY_TAG (replace with <PII_TYPE>), or REMOVE (delete entirely).

RULES:
1. Prepend [BUFFERED_TEXT] to [CURRENT_CHUNK] to form the full text to analyze.
2. Identify all instances of [PII_CATEGORIES] in the full text.
3. Apply [REDACTION_STRATEGY] to each identified PII instance.
4. Output ONLY the portion of the redacted text that corresponds to the original [CURRENT_CHUNK]. Do not output text that was part of [BUFFERED_TEXT].
5. If the [CURRENT_CHUNK] ends with a potential partial PII match (e.g., a sequence that looks like the start of a phone number or email), do NOT output that partial match. Instead, output the safe text up to that point and set [NEW_BUFFER] to the partial match.
6. If no PII is detected, output the entire [CURRENT_CHUNK] unchanged and set [NEW_BUFFER] to an empty string.
7. Never explain your actions. Output only the safe text and the new buffer state.

OUTPUT_SCHEMA:
{
  "safe_text": "The redacted portion of [CURRENT_CHUNK] ready for display.",
  "new_buffer": "Any trailing partial PII match to hold for the next chunk, or empty string."
}

To adapt this template, start by defining your [PII_CATEGORIES] precisely. A financial application might only care about CREDIT_CARD and ACCOUNT_NUMBER, while a healthcare app needs PATIENT_NAME, MRN, and DATE_OF_BIRTH. The [REDACTION_STRATEGY] should be chosen based on the downstream consumer: MASK is safest for logs, CATEGORY_TAG preserves data shape for debugging, and REMOVE is appropriate when the text must be completely clean. The most critical implementation detail is the buffer handoff: your application harness must persist [NEW_BUFFER] from one call to the next as [BUFFERED_TEXT] for the subsequent chunk. Test this boundary heavily with PII strings deliberately split across chunk borders.

Integrating the Streaming Output Real-Time PII Guard into a production application requires a stateful middleware layer that sits between the model's streaming response and the end user. The core challenge is that PII can span across chunk boundaries—a social security number like 123-45-6789 might be split as 123-45 in one chunk and -6789 in the next. A naive per-chunk regex or LLM call will miss this. The implementation harness must maintain a sliding buffer window of the last N tokens (typically 50-100 tokens or ~200 characters) to catch partial matches. When the buffer content plus the new chunk triggers a PII detection, the system must redact the sensitive span retroactively from the buffer before flushing clean tokens downstream. This buffering introduces a controlled latency trade-off: larger windows improve recall but increase time-to-first-byte for the end user.

For the LLM-based detection path, you'll call the prompt template on each buffered segment. To keep latency under 200ms per chunk, use a small, fast model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned local model) and set max_tokens to a low value since you only need a JSON verdict. Implement a two-tier architecture: a fast regex pre-filter for high-precision patterns (credit cards, SSNs, emails) that skips the LLM call entirely when no pattern matches, and the LLM prompt for contextual disambiguation (e.g., distinguishing a real name from a product name). The prompt template's [INPUT] should receive the buffered text segment, and [CONSTRAINTS] should specify the latency budget and redaction style. Parse the model's JSON response to extract redaction spans, then apply them to the buffer before releasing clean text. Log every redaction decision with the original span, redacted span, detection method (regex vs. LLM), and confidence score for audit trails.

Before deploying, build a streaming-specific eval harness that simulates chunk boundaries across your PII test set. Split known PII examples at random positions and verify the guard catches them regardless of where the chunk boundary falls. Measure both end-to-end latency (95th percentile under 500ms is a reasonable target for chat applications) and PII recall (aim for >99% on common categories). Implement a circuit breaker: if the LLM detection path exceeds your latency SLO for 3 consecutive chunks, fall back to regex-only redaction and alert the on-call channel. For high-risk domains like healthcare or finance, route all redacted outputs to a human review queue for sampling before the system auto-approves its own decisions. Never deploy a streaming PII guard without chunk-boundary fuzzing in your test suite—this is the most common failure mode in production.