Confidential Business Information Redaction Prompt for Contracts

This prompt is designed for legal, procurement, and security teams who need to review contracts using an external large language model (LLM) but must first prevent the exposure of confidential business information (CBI). The core job-to-be-done is to transform a sensitive contract into a redacted, analysis-ready document where specific categories of proprietary data—such as pricing tables, payment terms, and trade secrets—are systematically masked. The ideal user is an engineer or legal operations professional integrating this prompt into a pre-processing pipeline, not a business user manually copying and pasting text into a public chatbot.

Use this prompt when the contract contains information that is commercially sensitive but not necessarily personally identifiable information (PII). This is distinct from PII redaction; the focus here is on corporate confidentiality. You should not use this prompt if you require a perfect, lossless redaction for legal admissibility without human review, or if the contract's meaning is entirely dependent on the specific numbers being redacted. The prompt requires a pre-defined [REDACTION_SCHEMA] that lists the categories of CBI to target, such as 'pricing', 'payment schedules', or 'non-public technical specifications'. Without a clear schema, the model will make inconsistent redaction decisions.

Before deploying, you must pair this prompt with a validation harness that checks the output for residual CBI using the same schema. A human-in-the-loop review step is mandatory for high-stakes contracts to catch over-redaction that could alter contractual obligations or under-redaction that leaks sensitive data. The next step is to define your organization's specific redaction categories in the [REDACTION_SCHEMA] variable and run the prompt against a golden dataset of pre-labeled contracts to measure its precision and recall before integrating it into a production AI pipeline.

The prompt below is designed to be dropped directly into your application's pre-processing layer. It instructs the model to act as a redaction engine, identifying and masking specific categories of confidential business information—such as pricing, payment terms, and trade secrets—while preserving the structural integrity of the contract. The template uses square-bracket placeholders for all dynamic inputs, making it safe for variable substitution in production pipelines. Before deploying, ensure your redaction categories are defined with sufficient precision to avoid both under-redaction (leaking sensitive data) and over-redaction (breaking the downstream analysis task).

textCopy
You are a confidential business information redaction engine. Your task is to process the provided contract text and redact specific categories of sensitive business information before the document is sent for external analysis.

## INPUT
[CONTRACT_TEXT]

## REDACTION CATEGORIES
[REDACTION_CATEGORIES]

## INSTRUCTIONS
1. Scan the entire contract text for any information that falls within the defined redaction categories.
2. Replace each identified instance with a placeholder token in the format: `[REDACTED:<CATEGORY_NAME>]`.
3. Preserve all other text, including formatting, clause numbering, and section headers, exactly as it appears.
4. Do not redact information that falls outside the defined categories, even if it appears sensitive.
5. Do not summarize, paraphrase, or alter the contract structure in any way.
6. If no information from the defined categories is found, return the original text unchanged.

## OUTPUT FORMAT
Return a JSON object with the following schema:
{
  "redacted_text": "<full contract text with redactions applied>",
  "redaction_log": [
    {
      "category": "<category name from the defined list>",
      "placeholder": "[REDACTED:<CATEGORY_NAME>]",
      "original_text_snippet": "<first 50 characters of the redacted text>",
      "location": "<section or clause reference where the redaction occurred>"
    }
  ],
  "redaction_count": <total number of redactions applied>
}

## CONSTRAINTS
- Never include the full original sensitive text in the `original_text_snippet` field if doing so would expose the confidential information. Truncate to a safe prefix.
- If the contract contains information that could be used to infer a redacted value (e.g., a formula that derives the redacted price), flag it in an additional `inference_risks` array.
- Do not redact standard legal boilerplate, definitions of terms, or publicly known entity names unless they explicitly contain category information.

## RISK LEVEL
[RISK_LEVEL]

## EXAMPLES
[EXAMPLES]

To adapt this template for your organization, start by defining your [REDACTION_CATEGORIES] with precision. Instead of a vague category like "financial terms," use specific, enumerable definitions such as "per-unit pricing," "volume discount tiers," "payment schedule dates and amounts," and "royalty percentage rates." The [RISK_LEVEL] parameter controls the model's aggressiveness: at low, the model errs toward under-redaction to preserve analysis utility; at high, it errs toward over-redaction and flags inference risks. The [EXAMPLES] placeholder should contain 2-4 few-shot demonstrations showing the contract text before and after redaction, including edge cases where a number might be a date (do not redact) versus a price (redact). Wire the output redaction_log into your audit trail and the inference_risks array into a human review queue before the redacted text is released to an external model.

Wiring this prompt into a production application requires a pre-processing pipeline that executes before any contract text is sent to an external model. The prompt itself is designed to be stateless and idempotent, accepting a raw contract string and a JSON schema of redaction categories, and returning a redacted version. In practice, you will wrap this prompt in a service that manages the organization-specific redaction schema, handles chunking for long contracts, and enforces a strict no-logging policy for the raw input. The harness must treat the raw contract as toxic data that should never be persisted in plaintext in logs, error messages, or debugging traces.

A robust implementation starts with a schema registry that maps your organization's confidential categories to the [REDACTION_CATEGORIES] placeholder. Each category should include a name, description, and a list of keywords or patterns that help the model identify the information. For example, a pricing category might include terms like 'rate card', 'discount schedule', and 'volume pricing tier'. This schema is injected into the prompt at runtime. For contracts exceeding the model's context window, implement a sliding window chunker that splits the document by clause or section boundaries, processes each chunk independently, and reassembles the redacted text. Use a deterministic chunking strategy with overlap to prevent redaction gaps at boundaries. The reassembly step must verify that the total character count of the redacted output matches the expected length accounting for redaction markers.

Validation and retry logic is critical because a failed redaction that leaks confidential terms into an external model is a security incident. After the model returns a redacted contract, run a post-processing verification step that checks for the presence of known confidential terms from your schema using a combination of regex and substring matching. If any high-confidence confidential terms are detected in the output, log the failure to an internal audit system, increment a retry counter, and re-invoke the prompt with a stronger [CONSTRAINTS] block that explicitly lists the missed terms as examples of what must be redacted. Set a maximum of 2 retries before the document is routed to a human review queue. For model choice, prefer a model with strong instruction-following and low hallucination rates on extraction tasks. Run periodic evaluations against a golden dataset of contracts with known confidential terms to measure redaction recall and over-redaction rates. Finally, ensure all prompt invocations are wrapped in an observability layer that records the prompt version, schema version, chunk count, retry count, and validation result, but never the raw or redacted contract text itself.

What to avoid: Do not send the raw contract to the model without first validating that the redaction schema is correctly populated. Do not skip the post-redaction verification step, even if the model appears confident. Do not log the raw contract or the redacted contract to any system that is not explicitly approved for confidential data storage. The redacted output should be treated as sensitive until a human reviewer or automated policy confirms it is safe for external use. Next, integrate the redacted output into your downstream contract analysis workflow, and schedule a monthly review of the redaction schema to add new categories as your organization's definition of confidential business information evolves.