Confidential Document Summarization with Redaction Prompt

This prompt is designed for legal and compliance teams who need to generate useful summaries of privileged or confidential documents without risking data exfiltration. The core job-to-be-done is producing a conceptual abstract of a sensitive source document that preserves analytical utility—key themes, decisions, risks, and obligations—while strictly prohibiting the reproduction of named entities, specific financial figures, and other direct identifiers. The ideal user is a legal operations professional, compliance analyst, or privacy engineer who needs to share the gist of a document with a downstream system or colleague but cannot expose the raw text. Required context includes the full source document text and a clear definition of what constitutes a confidential identifier in the organization's specific regulatory environment.

This prompt is not a replacement for a redaction tool that operates on the source document itself. It is a safety layer for AI-generated text, meaning the original document remains unaltered and the summary is a new artifact that must be independently reviewed. Use this prompt when the summary's utility depends on conceptual understanding rather than verbatim detail, and when a human reviewer will validate the output before any downstream use. Concrete scenarios include summarizing a privileged contract for a business stakeholder who lacks access to the original, preparing a sanitized case summary for an external auditor, or generating a risk abstract from a confidential regulatory filing that can be shared with a steering committee.

Do not use this prompt when the downstream consumer needs exact quotes, specific dollar amounts, party names, or dates to perform their task. Do not use it as a substitute for document redaction software in e-discovery or FOIA workflows. Do not use it when the summary will be published or shared without human review, as the model may still leak identifiers through paraphrasing or inference. The prompt is a defense-in-depth measure, not a cryptographic guarantee. Before deploying, you must pair it with an evaluation harness that tests for named entity leakage, numerical data exposure, and privilege boundary preservation using a golden dataset of confidential documents with known redaction targets. If your use case requires zero-tolerance leakage prevention, this prompt alone is insufficient—combine it with a deterministic redaction pre-processor and a human-in-the-loop approval step.

This template is designed to be used as a system prompt or combined instruction where the confidential document text is appended at the end. It forces the model to abstract content into a safe summary rather than reproducing or closely paraphrasing the source material. The square-bracket placeholders let you adjust the risk tolerance, output structure, and domain-specific redaction rules without rewriting the core instruction.

textCopy
You are a secure document summarization assistant operating in a zero-retention environment. Your task is to produce a summary of the provided document that conveys the essential subject matter, decisions, and conclusions without exposing any confidential, privileged, or personally identifiable details.

## Document
[DOCUMENT_TEXT]

## Redaction Rules
- Replace all person names with [INDIVIDUAL] or a role-based placeholder such as [CLIENT], [ATTORNEY], or [EXECUTIVE].
- Replace all organization names with [ORGANIZATION] or a sector-based placeholder such as [LAW_FIRM], [REGULATOR], or [COMPETITOR].
- Replace all monetary amounts, percentages, dates, and specific numerical figures with [VALUE] or [DATE].
- Replace all locations, addresses, and jurisdiction references with [LOCATION] or [JURISDICTION].
- Replace all case numbers, docket numbers, filing identifiers, and contract references with [REFERENCE_ID].
- Do not reproduce any sentence verbatim from the source document. Paraphrase at a minimum distance.
- If the document contains attorney-client privileged communication, legal strategy, or settlement discussions, abstract the topic without revealing the position, argument, or negotiation detail.
- If you cannot summarize a section without risking exposure, state: "[SECTION REDACTED - insufficient safe abstraction path]" and move to the next section.

## Output Structure
Return a JSON object with the following schema:
{
  "summary": "string (safe abstracted summary)",
  "topics_identified": ["string"],
  "redaction_notes": ["string (list of what was redacted and why)"],
  "confidence": "high|medium|low",
  "sections_omitted": ["string (sections that could not be safely summarized)"]
}

## Constraints
- [CONSTRAINTS: e.g., 'Maximum summary length 300 words', 'Do not mention document type if it reveals privilege', 'Preserve chronological order of events without specific dates']
- Risk level for this document: [RISK_LEVEL: low|medium|high|critical]
- If risk level is critical, increase abstraction and reduce detail density by 50%.

Adapt this template by adjusting the redaction rules to match your organization's data classification policy. For legal documents, add specific privilege rules. For financial documents, add PCI and non-public financial data rules. For healthcare, add PHI identifiers from the HIPAA Safe Harbor list. Always test the adapted prompt against a golden dataset of documents with known confidential entities to measure redaction recall and precision before production deployment. If the model consistently fails to redact a specific entity type, add an explicit rule and a few-shot example rather than relying on the model to infer the boundary.

Integrating this prompt into a production application requires treating the model call as one step inside a larger privacy-preserving pipeline. The application layer should own data sanitization, policy enforcement, and output validation rather than relying solely on the prompt to prevent leakage. Before the prompt ever sees the document, run a deterministic PII scanner and a named entity recognition pass to flag and mask known identifiers, financial figures, and privilege markers. The prompt receives a pre-redacted document and a structured list of masked tokens, which it can reference without revealing the underlying values. This separation of concerns means the model handles semantic summarization while the application layer handles cryptographic-level redaction guarantees.

The implementation harness should follow a pre-process → prompt → post-validate → audit loop. Pre-processing strips explicit identifiers and replaces them with typed placeholders like [PERSON_1] or [AMOUNT_A], storing the mapping in a secure session store that the model cannot access. The prompt template receives the redacted text in the [DOCUMENT] placeholder and the placeholder type list in [REDACTED_ENTITY_TYPES] so it can reason about document structure without seeing raw values. After the model returns a summary, the post-validation layer runs a suite of checks: regex scans for residual PII patterns, fuzzy matching against the original document's named entities, and a semantic similarity check to ensure no sentence in the summary is a near-verbatim copy of a source sentence. Any summary that triggers a validation failure is either sent to a repair prompt or escalated for human review, depending on the [RISK_LEVEL] parameter.

For model choice, prefer a model with strong instruction-following and low hallucination rates on summarization tasks. GPT-4o and Claude 3.5 Sonnet both perform well on this structured redaction-summarization pattern, but always run the same validation suite regardless of model. Set temperature to 0 or a very low value (0.1 maximum) to reduce creative paraphrasing that might accidentally reconstruct redacted details. Implement retry logic with exponential backoff for transient API failures, but do not retry on validation failures without modifying the input—a second call with the same redacted document and a failed validation is unlikely to produce a safe result. Log every prompt version, the redacted document hash, the raw model output, validation results, and any human review decisions to an append-only audit store. This audit trail is essential for compliance reviews and for debugging leakage incidents.

When deploying this in a legal or compliance context, add a human review gate for any summary flagged by the post-validation layer. The review interface should display the original document side-by-side with the proposed summary, highlight any validation failures, and require explicit approval before the summary is released. For lower-risk internal use cases, you can configure the harness to auto-approve summaries that pass all validation checks while routing only failures to review. Never store the original document and the redaction mapping in the same database table without access controls that enforce separation—an attacker who compromises the application should not be able to trivially reverse the redactions. Finally, run periodic red-team exercises against the full pipeline, including the pre-processor, prompt, and post-validator, to catch regression failures when models or document formats change.