Document Redaction for External Sharing Prompt Template

This playbook is for legal and compliance engineers who need a final, auditable safety net before model-generated documents leave the organization. The primary job-to-be-done is to detect and redact personally identifiable information (PII), privileged legal content, and confidential business data from reports, contracts, and summaries that were produced by another model or pipeline. The ideal user is someone who owns the 'last mile' of an AI workflow—they are not the model builder, but the person responsible for ensuring that the output is safe for external distribution to clients, regulators, or third parties. You should use this prompt when the document has already been generated and you need a structured, traceable redaction pass that produces both a clean document and a decision log.

This prompt is not a replacement for upstream data minimization, access control, or secure retrieval architecture. Do not use it as the only line of defense if you can prevent sensitive data from entering the model's context window in the first place. It is also not suitable for real-time streaming scenarios where token-by-token redaction with low latency is required; for that, see the Streaming Output Real-Time PII Guard Prompt Template. The prompt assumes the input is a complete, discrete document that can be processed in a single request. It is designed for batch or on-demand review, not for high-throughput, sub-second API response filtering.

Before using this prompt, ensure you have a clear definition of what constitutes 'confidential business data' and 'privileged legal content' for your organization. The prompt uses configurable placeholders like [CONFIDENTIAL_TERMS] and [PRIVILEGED_PATTERNS] that you must populate with your internal taxonomy. If your definitions are vague, the model will make inconsistent redaction decisions. Pair this prompt with a human review step for any document that will be shared with regulators or opposing counsel. The structured audit log this prompt produces is your primary artifact for compliance; treat it as a controlled record. After running this prompt, always validate the output against your original document to confirm that no sensitive content leaked through the redaction process.

This prompt template is designed to be pasted directly into your orchestration layer. It instructs the model to act as a redaction engine, scanning a provided document for specified categories of sensitive information and returning a sanitized version alongside a structured justification log. The template uses square-bracket placeholders for all dynamic inputs, ensuring you can programmatically inject the source document, redaction rules, and output format requirements before each call.

textCopy
You are a document redaction engine. Your task is to prepare a document for external sharing by identifying and redacting sensitive information.

Follow these rules precisely:
1. Scan the provided [DOCUMENT] for any instances of the categories listed in [REDACTION_CATEGORIES].
2. Replace any detected sensitive text with the redaction label specified in [REDACTION_CATEGORIES] (e.g., `[REDACTED-PERSON_NAME]`).
3. Do not alter any text that does not match a redaction category.
4. Preserve all original formatting, line breaks, and non-sensitive punctuation.
5. For each redaction you make, record a justification in the audit log.

Your response MUST be a valid JSON object conforming to the [OUTPUT_SCHEMA] below. Do not include any text outside the JSON object.

[DOCUMENT]:
"""
[INPUT_DOCUMENT]
"""

[REDACTION_CATEGORIES]:
[REDACTION_CATEGORIES_JSON]

[OUTPUT_SCHEMA]:
{
  "redacted_document": "string (the full document text with sensitive information replaced by redaction labels)",
  "audit_log": [
    {
      "original_text": "string (the exact text that was redacted)",
      "redaction_label": "string (the label used for replacement, e.g., REDACTED-PERSON_NAME)",
      "category": "string (the category from REDACTION_CATEGORIES that triggered the redaction)",
      "confidence": "string (HIGH, MEDIUM, or LOW)",
      "reason": "string (a brief justification for the redaction decision)"
    }
  ]
}

To adapt this template, replace the placeholders as follows: [INPUT_DOCUMENT] should contain the full text of the model-generated report, contract, or summary. [REDACTION_CATEGORIES_JSON] must be a JSON array of objects, each defining a category (e.g., PERSON_NAME), a redaction_label (e.g., [REDACTED-PERSON_NAME]), and a description to guide the model. The [OUTPUT_SCHEMA] is provided inline for strict JSON mode compliance, but you can also pass it as a tool parameter or response format definition if your platform supports it. Before deploying, test this prompt against a golden dataset of documents with known PII to measure recall and precision, and implement a post-processing validation step to ensure the returned JSON is parseable and the redacted_document length is consistent with the audit log entries.

This prompt is designed to be the final safety gate before a model-generated document leaves your controlled environment. It should be wired into your application as a synchronous post-processing step: the primary model generates a draft, the draft is passed to this redaction prompt, and the sanitized output is what gets shared externally. The original, unredacted output must never be logged, stored, or transmitted outside the redaction boundary. Implement this as a mandatory pipeline stage, not an optional review step, to prevent accidental bypass.

The implementation harness requires three core components: input assembly, output validation, and audit logging. For input assembly, inject the [DOCUMENT] and [SHARING_CONTEXT] placeholders from your application state. The [REDACTION_RULES] should be loaded from a configuration store that your compliance team can update without code changes—this allows you to add new PII categories or privileged terms as regulations evolve. For output validation, parse the model's response against the expected schema: a redacted_document string, a redaction_log array of objects with original_text, redacted_text, category, and justification fields, and a redaction_summary object. If the output fails schema validation, implement a retry loop with a maximum of two additional attempts, each time appending the validation error to the prompt as a [PREVIOUS_ERROR] context. After two failed retries, escalate to a human review queue rather than silently falling back to the original document.

Model choice matters here. Use a model with strong instruction-following and low hallucination rates, such as Claude 3.5 Sonnet or GPT-4o, because the cost of a missed PII instance far outweighs the inference cost. Set temperature=0 to maximize deterministic behavior. For the audit trail, persist the full redaction_log alongside a hash of the original document and the redacted output in an append-only store. This gives your compliance team a searchable record of every redaction decision. Never log the unredacted document itself in application logs or monitoring systems—if you need debugging traces, log only the redaction log and document hash. Finally, implement a periodic sampling review where a human auditor examines a random subset of redacted documents against their originals to measure recall and precision, feeding findings back into the [REDACTION_RULES] configuration.