GDPR-Compliant Contact Minimization Prompt Template

This prompt is designed for compliance engineering teams who need to reduce contact records extracted by upstream models to only the fields strictly necessary for a declared processing purpose. It operates as a post-extraction repair and minimization step, taking a verbose or over-extracted contact object and producing a minimized record with PII redaction, purpose limitation annotations, and retention flags. Use this prompt when your pipeline ingests model-generated contact data that may contain excess personal data, and you need a programmatic, auditable minimization layer before storage or further processing. This is not a data extraction prompt; it assumes a contact record already exists and requires repair and reduction.

The ideal user is a backend engineer, data pipeline operator, or compliance officer integrating AI-generated data into a system of record. The required context includes the raw contact record, the declared processing purpose (e.g., 'order fulfillment', 'newsletter delivery'), and the applicable data retention policy. The prompt works best when the upstream model has been overly enthusiastic in extracting every possible field, leaving you with a record that contains unnecessary PII like birthdates, secondary phone numbers, or personal identifiers irrelevant to the stated purpose. It is particularly valuable in environments subject to GDPR Article 5(1)(c) data minimization requirements, where you must demonstrate that only adequate, relevant, and limited personal data is processed.

Do not use this prompt as a substitute for a data extraction step. If you need to pull contact information from unstructured text, use a dedicated extraction prompt first, then pipe the result into this minimization template. Do not use it for records where the processing purpose is undefined or overly broad; the prompt requires a specific, declared purpose to make defensible minimization decisions. Avoid using this prompt when the upstream model output is already minimal and well-structured, as the repair step may introduce unnecessary latency. Finally, this prompt is not a legal compliance guarantee—it is a technical control that must be paired with human review for high-risk processing activities and regular audits of minimization decisions.

This prompt template is designed to be dropped into your orchestration layer, eval harness, or human-review queue. It takes a raw contact record—likely extracted from unstructured text by a previous model—and produces a minimized version that retains only the fields necessary for a declared processing purpose. The template uses square-bracket placeholders so you can inject the specific input, context, output schema, constraints, examples, tools, and risk level at runtime. Do not ship this prompt without first calibrating the [PURPOSE] and [RETENTION_RULES] placeholders against your organization's actual data protection policies and records of processing activities.

textCopy
You are a GDPR compliance assistant. Your task is to minimize a contact record to only the fields strictly necessary for the stated processing purpose. You must redact any personal data that is not required, flag records that exceed retention limits, and never invent or infer missing data.

## INPUT
Contact Record:
[INPUT]

## CONTEXT
Processing Purpose: [PURPOSE]
Legal Basis: [LEGAL_BASIS]
Data Subject Jurisdiction: [JURISDICTION]

## OUTPUT SCHEMA
Return a valid JSON object with exactly this structure:
{
  "minimized_record": {
    "id": "string | null",
    "given_name": "string | null",
    "family_name": "string | null",
    "email": "string | null",
    "phone": "string | null",
    "company": "string | null",
    "job_title": "string | null",
    "city": "string | null",
    "country": "string | null"
  },
  "redacted_fields": ["string"],
  "retention_flag": {
    "exceeds_limit": true | false,
    "recommended_action": "delete" | "anonymize" | "review" | "retain",
    "reason": "string"
  },
  "purpose_alignment": {
    "is_aligned": true | false,
    "unnecessary_fields": ["string"],
    "explanation": "string"
  },
  "confidence": "high" | "medium" | "low"
}

## CONSTRAINTS
[CONSTRAINTS]
- Never include fields not listed in the output schema.
- If the input contains special category data (health, ethnicity, religion, biometrics, etc.), redact it entirely and note it in redacted_fields.
- If the processing purpose does not justify a field's presence, remove it and list it in unnecessary_fields.
- If the record's age exceeds the retention period defined in [RETENTION_RULES], set exceeds_limit to true.
- Set confidence to "low" if the input is ambiguous or incomplete; do not guess.

## EXAMPLES
[EXAMPLES]

## TOOLS
[TOOLS]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace each placeholder with concrete values from your application context. The [INPUT] placeholder should receive a serialized contact record, typically JSON. The [PURPOSE] and [LEGAL_BASIS] placeholders must reflect the specific processing activity documented in your Article 30 records. The [RETENTION_RULES] should be injected as a structured policy snippet—for example, a JSON object mapping data categories to maximum retention periods. The [CONSTRAINTS] placeholder lets you add jurisdiction-specific rules, such as Schrems II transfer restrictions or local labor law requirements. The [EXAMPLES] placeholder should contain at least three few-shot demonstrations: one showing correct minimization, one showing over-redaction that breaks record utility, and one showing a retention flag triggered by stale data. The [TOOLS] placeholder is reserved for function-calling integrations, such as a tool that queries your data catalog for field-level retention policies. The [RISK_LEVEL] placeholder should be set to "high" for any workflow involving special category data or cross-border transfers, which triggers additional human-review gating in your harness.

Before deploying, validate that the output JSON matches the schema exactly. Common failure modes include the model adding extra fields like "address_line_1" that are not in the schema, setting confidence to "high" when the input is clearly ambiguous, or failing to flag a record that exceeds retention limits. Your eval harness should test for both over-redaction (removing fields that are necessary for the stated purpose, breaking downstream utility) and under-redaction (leaving PII that the purpose does not justify). Run these evals against a golden dataset of 50-100 records with known minimization outcomes before promoting the prompt to production. If your risk level is "high," route all outputs where confidence is "low" or retention_flag.exceeds_limit is true to a human review queue before any automated action is taken.

This prompt is designed to sit inside a post-extraction data hygiene pipeline, not as a standalone chat interaction. The typical integration point is after a model has extracted structured contact fields from unstructured text (email bodies, call transcripts, form submissions) and before those records land in a CRM, CDP, or data warehouse. The harness must enforce that the minimization prompt receives a complete input record, returns a strictly validated output, and never silently drops required fields that would break downstream systems.

Wire the prompt into an application workflow with these components: Input assembly — collect the extracted contact record, the declared processing purpose (e.g., 'order fulfillment', 'newsletter'), the applicable retention period in days, and the jurisdiction (e.g., 'EU', 'California'). Model call — send the assembled prompt to a model that supports structured output (GPT-4o with response_format, Claude with tool use, or any model with JSON mode). Set temperature=0 to reduce variance on redaction decisions. Output validation — validate the returned JSON against a strict schema: minimized_record must contain only permitted fields for the purpose, redacted_fields must list every field removed with a reason code, retention_days must not exceed the input maximum, and requires_review must be a boolean. Reject any output missing these keys. Retry logic — if validation fails, retry once with the validation error message appended to the prompt as [PREVIOUS_ERROR]. If the second attempt fails, route to a human review queue. Do not retry more than twice; over-redaction is safer than an infinite loop that eventually leaks data.

Add a human review gate for any record where requires_review is true or where the redacted_fields list includes fields that are typically required for the declared purpose (e.g., shipping address redacted for order fulfillment). The review queue should display the original record, the minimized record, and the redaction justifications side by side. Log every minimization decision with a trace ID, timestamp, model version, and the full prompt and response for auditability. For high-throughput pipelines, implement a sampling-based eval loop: send 5% of minimized records to a second judge model that scores over-redaction risk and under-redaction risk on a 1-5 scale, flagging any record scoring above 3 on either axis for human review. This catches drift in the minimization prompt's behavior before it affects all records.

Model choice matters. Use a model with strong instruction-following on constrained output tasks. GPT-4o and Claude 3.5 Sonnet perform well on field-level redaction with purpose limitation. Avoid smaller models (under ~7B parameters) for this task unless you've validated them on your specific contact schema and redaction rules, as they tend to either over-redact aggressively or miss PII in nested fields. If you must use a local model, run a calibration suite of 100 labeled records with known PII to measure precision and recall before deployment. Do not use this prompt on streaming outputs or partial records; the minimization logic requires the full extracted record to make correct purpose-limitation decisions. If your pipeline produces records incrementally, buffer until the extraction is complete before invoking minimization.