Sensitive Data Sanitization Prompt for Golden Sets

Privacy engineers and ML teams preparing production-derived test data face a hard constraint: golden datasets must mirror real-world distributions, but they cannot contain real PII, secrets, or regulated data. This prompt detects and redacts sensitive data while preserving the structural and semantic properties that make a test case valid. Use it when you are sampling production logs, support tickets, or user-generated content to build regression suites, and you need a sanitized record, a redaction log, and a re-identification risk assessment before the data enters your test infrastructure.

This prompt is designed for a specific job: transforming a single raw record into a safe, test-ready artifact. The ideal user is a privacy engineer or ML engineer who has already extracted candidate records from a production system and needs to run them through a sanitization gate. The required context includes the raw text, a defined risk level (e.g., strict for GDPR/HIPAA, moderate for internal-only test data), and an optional entity allowlist. Do not use this prompt for bulk, unsupervised sanitization of entire databases; it is a record-level review tool. It is also not a substitute for a formal data protection impact assessment (DPIA) or legal review of your data-handling policies.

The prompt's output is a structured JSON object containing three artifacts: a sanitized_record with placeholders replacing sensitive entities, a redaction_log mapping each placeholder to its entity type and confidence score, and a re_identification_risk score with a supporting rationale. This structure is designed to be machine-readable so you can programmatically validate that no high-risk entities remain in the sanitized text before it enters your test suite. A common failure mode is over-redaction, where the prompt removes context necessary for the test case to be valid (e.g., redacting a product name that is the subject of a support ticket). To mitigate this, always provide an entity allowlist for domain-specific terms that are safe to retain.

Before integrating this prompt into an automated pipeline, you must establish a human review step for records where the re_identification_risk score exceeds your defined threshold. The prompt's risk assessment is a heuristic, not a guarantee. In regulated environments, a qualified reviewer should sign off on any record derived from production data before it is committed to a golden dataset. After reading this section, proceed to the prompt template to see the exact instructions and output schema, then review the implementation harness for guidance on wiring this into a CI/CD pipeline with validation and logging.

This prompt template is designed to be dropped into your sanitization harness. It accepts a raw record, a redaction policy, and a style preference, and returns a sanitized record with an auditable redaction log and a re-identification risk assessment. The template uses square-bracket placeholders that you must replace with your specific data, policy definitions, and output constraints before sending it to the model. The prompt enforces a strict JSON output schema so that downstream validation and logging can be automated.

textCopy
You are a data sanitization engine for golden test datasets. Your task is to detect and redact sensitive information from a single input record while preserving as much analytical and structural utility as possible.

## INPUT RECORD
[INPUT_RECORD]

## REDACTION POLICY
[REDACTION_POLICY]

## REDACTION STYLE
[REDACTION_STYLE]

## INSTRUCTIONS
1. Identify every instance of sensitive data in the input record that matches the categories defined in the redaction policy.
2. Replace each sensitive instance with a redaction token that follows the redaction style. The token must preserve type information (e.g., [REDACTED_EMAIL]) but must not leak the original value.
3. If the redaction policy requires partial preservation (e.g., last four digits of an account number), apply that rule consistently.
4. If the input record contains no sensitive data, return the record unchanged and note this in the redaction log.
5. After redacting, assess the re-identification risk of the sanitized record on a scale of LOW, MEDIUM, or HIGH. Consider residual quasi-identifiers, rare values, and linkability to external data.
6. If the re-identification risk is HIGH, flag the record for human review and explain which residual fields contribute most to the risk.

## OUTPUT SCHEMA
Return a single JSON object with exactly these fields:
{
  "sanitized_record": "string (the fully redacted record)",
  "redaction_log": [
    {
      "original_value_type": "string (e.g., EMAIL, SSN, IP_ADDRESS, CREDIT_CARD, PHONE, NAME, ADDRESS, SECRET_KEY)",
      "redaction_token": "string (the replacement token used)",
      "position": "string (character offset range or field path where the redaction occurred)",
      "partial_preservation_applied": "boolean"
    }
  ],
  "re_identification_risk": "string (LOW | MEDIUM | HIGH)",
  "risk_explanation": "string (required if risk is MEDIUM or HIGH; otherwise empty)",
  "human_review_required": "boolean"
}

## CONSTRAINTS
- Do not invent or hallucinate sensitive data that is not present in the input record.
- Do not redact data that is not covered by the redaction policy, even if it seems sensitive.
- Preserve the original structure of the input record (JSON, text, tabular) in the sanitized output.
- If the input record is empty or unparseable, return an error object: {"error": "string describing the issue"}.

Adapting the template: Replace [INPUT_RECORD] with the raw record you need to sanitize—this could be a JSON object, a log line, a database row, or free text. Replace [REDACTION_POLICY] with a concrete list of data categories to detect, such as "email addresses, social security numbers, credit card numbers, API keys, and IP addresses." Replace [REDACTION_STYLE] with your preferred token format, such as "use uppercase category tokens like [REDACTED_EMAIL]" or "use consistent placeholder text like <REDACTED>." If your golden set requires partial preservation for certain fields (e.g., keeping the domain of an email address), encode those rules explicitly in the redaction policy. Before deploying this prompt, run it against a small set of known records with ground-truth redactions and validate that the output JSON schema is strictly respected. For high-risk domains like healthcare or finance, always route records flagged with human_review_required: true to a human reviewer before they enter your test suite.

This prompt is not a one-off utility; it is a pipeline component that must produce auditable, machine-readable output before golden records enter any test suite. The implementation harness wraps the LLM call in a validation layer that checks for schema compliance, re-identification risk thresholds, and completeness of the redaction log. Because the prompt handles production-derived data that may contain real PII, secrets, or regulated content, the harness must treat every output as suspect until validated and must never write unredacted records to long-term storage accessible by downstream systems.

A typical integration flow: (1) Load the raw record and the prompt template with placeholders for [INPUT_RECORD], [PII_CLASSES], [REDACTION_STYLE], and [OUTPUT_SCHEMA]. (2) Call the model with a low temperature (0.0–0.2) to maximize deterministic redaction behavior. (3) Parse the JSON output and validate it against the expected schema—reject any response that fails to parse, omits required fields like redaction_log or reidentification_risk, or contains placeholder tokens. (4) Run a secondary check: for each entry in redaction_log, confirm that the original value does not appear in the sanitized_record. If it does, flag for human review. (5) Score the reidentification_risk field; if it exceeds a configured threshold (e.g., medium or higher), route the record to a manual review queue rather than automatically accepting it. (6) Log the model version, prompt hash, input hash, and validation result for auditability. This log becomes part of the golden set's provenance chain.

Retry logic should be conservative. If validation fails due to malformed JSON, retry once with a stricter schema reminder appended to the prompt. If the retry also fails, quarantine the record and alert a human reviewer. Do not loop indefinitely—malformed outputs on sanitization tasks often indicate the model is struggling with an ambiguous input, and repeated retries risk leaking sensitive data into logs or downstream error queues. For high-sensitivity environments, consider running the prompt through two different models and comparing the redaction_log outputs; discrepancies trigger human review. Avoid wiring this prompt directly into a CI/CD pipeline without a manual approval gate for any record flagged as reidentification_risk: high or with an empty redaction_log despite detected PII classes in the input.