Confidential Meeting Summary Sanitization Prompt

This prompt is designed for knowledge workers, compliance officers, and communications leads who must distribute AI-generated meeting summaries without exposing confidential statements, off-record remarks, or restricted context. The primary job-to-be-done is to act as a first-pass sanitization layer: the model receives a raw transcript or detailed summary and returns a version where protected content is identified and redacted, while decisions, action items, and non-sensitive context are preserved. The ideal user operates in an environment where meeting notes move from a secure internal system to a broader distribution list—such as board observers, client stakeholders, or cross-departmental teams—and needs a repeatable, auditable filter before human review.

Use this prompt when the raw material contains a mix of public-ready and confidential discussion, and the cost of manual redaction across many meetings is prohibitive. It is appropriate for recurring operational meetings, project stand-ups, vendor calls, and internal reviews where sensitive asides, personnel matters, unreleased financial figures, legal strategy, or trade secret details may appear alongside routine updates. The prompt is not a replacement for legal review, formal classification, or data loss prevention (DLP) systems. Do not use it for meetings where the entire discussion is classified, where regulatory filing obligations apply to the raw transcript, or where redaction failure would create mandatory breach notification requirements. In those high-stakes scenarios, this prompt may serve as a pre-processing step, but a qualified human reviewer must always sign off on the final output.

Before deploying this prompt, ensure you have a clear definition of what constitutes 'confidential' in your organization. The prompt template includes a [CONFIDENTIALITY_POLICY] placeholder where you must supply concrete categories—such as 'unreleased financial data,' 'personnel performance discussions,' 'attorney-client privileged communication,' or 'trade secret technical specifications.' Vague policies produce inconsistent redaction. You should also prepare a set of evaluation examples that test both over-redaction (where the model removes information that was safe to share, destroying the summary's utility) and under-redaction (where sensitive content slips through). After the model returns a sanitized summary, route the output to a human reviewer and log the original, the redacted version, and the reviewer's changes. This audit trail is essential for demonstrating due diligence if a disclosure incident occurs.

This prompt template is designed to be pasted directly into your system instructions or used as a user message. It instructs the model to act as a confidentiality filter, identifying and redacting sensitive information from meeting transcripts while preserving the actionable substance. The template uses square-bracket placeholders that you must replace with your specific inputs before use. The core logic separates the task into two phases: first, a strict identification of confidential material based on your provided rules, and second, a rewriting step that produces a safe-for-distribution summary.

markdownCopy
You are a Confidential Meeting Summary Sanitizer. Your task is to process a raw meeting transcript and produce a sanitized summary safe for distribution to [TARGET_AUDIENCE]. You must strictly follow a two-phase process.

**Phase 1: Identification**
Analyze the [RAW_TRANSCRIPT] and identify all text segments that match the following confidentiality rules. Do not output anything in this phase.
- **Off-Record Remarks:** Statements explicitly marked as "off the record" or similar.
- **Restricted Context:** Discussion of [RESTRICTED_TOPICS], including specific project names like [PROJECT_CODEWORDS].
- **Personal Data:** Any Personally Identifiable Information (PII) such as names, emails, or phone numbers not belonging to [ALLOWED_SPEAKERS].
- **Speculation:** Forward-looking financial or strategic speculation, including phrases like [SPECULATION_INDICATORS].

**Phase 2: Sanitization and Summary**
Generate a concise meeting summary containing only the following allowed elements:
- **Decisions Made:** Concrete decisions and their owners.
- **Action Items:** Tasks assigned, to whom, and deadlines.
- **General Status:** High-level, non-sensitive status updates.

**Critical Rules for Sanitization:**
1.  **Redact, Don't Rewrite:** Replace identified confidential segments with a `[REDACTED: <category>]` placeholder. Do not paraphrase or generalize the confidential information.
2.  **Preserve Action:** If an action item is directly tied to a redacted topic, include the action but describe it generically, e.g., "[ACTION OWNER] to follow up on a restricted topic by [DATE]."
3.  **No Source Attribution:** Do not attribute any statement to a specific speaker unless they are in the [ALLOWED_SPEAKERS] list.
4.  **Empty Summary:** If the entire transcript is confidential, output only: "No distributable content found."

**Output Format:**
Output only the sanitized summary in plain text. Do not include any preamble or meta-commentary.

To adapt this template, start by defining the [TARGET_AUDIENCE] precisely, as this determines the acceptable level of abstraction. For example, a summary for a company-wide update will be far more generic than one for a project team with clearance. Next, populate the [RESTRICTED_TOPICS] and [PROJECT_CODEWORDS] lists from your data classification policy. The [SPECULATION_INDICATORS] list should include phrases like "I think we might acquire" or "the stock will jump if." Before deploying, you must test this prompt with transcripts containing edge cases, such as action items that are themselves confidential or meetings where a single off-record remark invalidates a subsequent decision. The final step is to run the output through a validation check to ensure no [REDACTED] placeholder contains the original sensitive text and that the summary remains coherent.

This prompt is designed to be embedded in a post-meeting processing pipeline, not used as a standalone chat interface. The typical integration point is after a transcription service produces a raw transcript and before the sanitized summary is distributed to attendees or published to a knowledge base. The application layer should handle transcript segmentation (chunking long meetings into manageable sections), prompt assembly, and output validation before any human sees the result.

Model choice and invocation: Use a model with strong instruction-following and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Set temperature to 0 or a low value (0.1–0.2) to reduce variance in redaction decisions. Request a structured JSON output matching the [OUTPUT_SCHEMA] defined in the prompt template, and use the model's native structured output or function-calling mode if available to enforce field types and required fields. For meetings longer than the model's effective context window, split the transcript into overlapping segments of roughly 4,000–6,000 tokens, process each independently, and merge results with a deduplication step that resolves conflicting redaction decisions by preferring the more conservative (redacted) version.

Validation and retry logic: After receiving the model output, run automated validation checks before the summary reaches a human reviewer. Validate that the redaction_log contains an entry for every redacted span in the sanitized_summary, that each entry includes a rationale and severity field, and that no [REDACTED] placeholder appears without a corresponding log entry. Check for over-redaction by scanning for placeholder density exceeding a configurable threshold (e.g., more than 30% of sentences containing redactions) and flag these for human review. If validation fails, retry the prompt once with the validation errors appended as [PREVIOUS_ERRORS] in the prompt context. If the retry also fails, escalate to a human review queue with the raw transcript, the failed output, and the specific validation failures.

Human review integration: This workflow is high-risk because under-redaction leaks confidential information and over-redaction destroys actionable meaning. Route every output through a human review step before distribution. The review interface should display the original transcript side-by-side with the sanitized summary, highlight all [REDACTED] placeholders with hover-over rationales from the redaction_log, and allow the reviewer to accept, modify, or reject each redaction. Log all reviewer actions for audit purposes. For low-risk internal meetings, you may configure the system to auto-approve summaries where the severity field in all redaction log entries is below a defined threshold, but this threshold should be set conservatively and reviewed periodically.

Logging and observability: Log every prompt invocation with the model ID, prompt version, input transcript hash, output summary hash, validation results, retry count, and reviewer decision. Store these logs in an append-only audit store for compliance review. Monitor the rate of validation failures, human overrides, and retry escalations as leading indicators of prompt drift or model behavior changes. If a new model version causes a statistically significant increase in human overrides, roll back the model or prompt version and investigate the failure patterns before re-deploying.

What to avoid: Do not send the raw transcript to a third-party model API without confirming that your data processing agreement covers meeting content. Do not skip the human review step for meetings containing material non-public information, attorney-client privileged discussion, or personally identifiable information. Do not rely solely on the model's redaction decisions without the structured redaction_log—the log is your audit evidence and the primary surface for human review. Do not concatenate multiple meeting transcripts into a single prompt without clearing context between meetings, as this creates cross-meeting leakage risk.