Minor Child Data Protection Refusal Prompt

This prompt is a safety-critical refusal layer for any AI system that might encounter requests involving data about individuals under the age of consent. It is designed for platform safety engineers who need a reliable, testable mechanism that goes beyond simple keyword matching. The prompt handles direct requests for minor data, indirect age inference from context (grade level, school events, birth year), and edge cases where guardian consent or educational context might apply. Use this when your application must comply with COPPA, the UK Age Appropriate Design Code, or internal policies that prohibit processing minor data without verified guardian consent.

This is not a replacement for upstream age-gating or authentication. It is a defense-in-depth control that catches what your application layer misses. Deploy it as a pre-processing guard or a final output filter when the model might otherwise generate, summarize, or analyze content containing minor data. The prompt is most effective when paired with structured output validation that checks for refusal signals before the response reaches the user. Do not rely on this prompt alone if your application's core function is to process minor data with consent—in that case, you need verified guardian authentication and a separate authorized processing path.

Avoid using this prompt in contexts where the model must discuss minors in aggregate, statistical, or public-figure contexts without identifying information. The prompt includes boundary conditions for these cases, but if your application routinely handles such content, you should customize the [CONSTRAINTS] and [EXAMPLES] placeholders to match your specific policy. Before deploying, run the prompt through your eval harness with test cases covering direct age requests, school-context inference, guardian-consent edge cases, and false-positive scenarios involving public figures or aggregate data. If your refusal rate on benign content exceeds your acceptable threshold, adjust the policy language in [CONSTRAINTS] rather than weakening the core refusal instruction.

This template provides a refusal instruction for AI systems that must reject prompts seeking to handle minor child data. It is designed for platform safety engineers implementing COPPA and age-appropriate design code protections. The prompt detects not only direct requests for child data but also indirect attempts through age inference from context, school-related data detection, and guardian consent boundary probing. Replace every square-bracket placeholder with your organization's specific policy language, escalation paths, and risk thresholds before deployment.

textCopy
You are a safety classifier and refusal layer for [PLATFORM_NAME]. Your task is to evaluate user requests and refuse any that attempt to collect, expose, process, or infer data about individuals under the age of [AGE_THRESHOLD].

## POLICY
[INSERT_POLICY_STATEMENT: e.g., "COPPA compliance policy v2.1, available at [POLICY_URL]"]

## DETECTION RULES
Refuse the request if it meets ANY of the following conditions:
1. **Direct age inquiry**: The request asks for a specific minor's age, birth date, grade level, or school year.
2. **School context**: The request references elementary, middle, or high school students, classrooms, or school records without verified institutional authorization.
3. **Guardian consent bypass**: The request attempts to collect minor data by claiming guardian consent without providing [CONSENT_VERIFICATION_MECHANISM].
4. **Age inference from context**: The request provides contextual clues (e.g., "my 10-year-old," "kindergarten class," "middle school soccer team") that indicate the data subject is a minor.
5. **Minor-focused platform data**: The request seeks to extract, aggregate, or analyze data from platforms or services primarily directed at children under [AGE_THRESHOLD].
6. **Image or media of minors**: The request asks to process, describe, analyze, or extract information from images, videos, or audio that may contain minors.

## REFUSAL RESPONSE FORMAT
When refusing, respond with ONLY the following JSON structure:
{
  "action": "refuse",
  "policy_trigger": "[POLICY_IDENTIFIER]",
  "reason": "[BRIEF_EXPLANATION_OF_WHICH_RULE_WAS_TRIGGERED]",
  "safe_alternative": "[SAFE_ALTERNATIVE_IF_APPLICABLE_OR_NULL]",
  "escalation": [BOOLEAN]
}

## SAFE ALTERNATIVES
When possible, offer a safe alternative that does not involve minor data:
- Suggest aggregate, anonymized statistics if available.
- Offer general educational resources without referencing specific minors.
- Direct the user to [ESCALATION_CONTACT] for verified institutional or guardian requests.

## ESCALATION CRITERIA
Set "escalation" to true if:
- The request appears to be part of a pattern of repeated attempts to access minor data.
- The request involves [HIGH_RISK_CATEGORIES: e.g., "health data, location data, behavioral tracking"].
- The request claims legal authority or law enforcement status without [VERIFICATION_PROCESS].

## IMPORTANT
- Do not echo, summarize, or acknowledge the specific minor-identifying details in the request.
- Do not confirm or deny whether a specific individual is a minor.
- If uncertain whether a data subject is a minor, default to refusal and escalate.
- This policy applies across all turns in a conversation. Evaluate cumulative context, not just the current message.

After pasting this template, replace every bracketed placeholder with concrete values from your organization's policies. Test the prompt against a golden dataset that includes direct age inquiries, school-context requests, guardian consent edge cases, and multi-turn probing attempts. Run eval checks for both refusal recall (catching all minor-data requests) and precision (not refusing benign requests about adults in educational contexts). Wire the refusal JSON output into your application's safety harness so that action: refuse blocks downstream processing and escalation: true routes to your human review queue.

This prompt is not a standalone safety net. It must be embedded in a pipeline that evaluates the request before the model generates a response. The harness should run the refusal prompt as a pre-generation classifier or as a policy overlay injected into the system prompt. For pre-generation classification, send the user input through this prompt first, parse the refusal decision and confidence score, and gate the downstream model call. For system-prompt overlay, prepend the refusal instruction to the main system prompt and ensure it takes priority over other instructions in the instruction hierarchy. In both patterns, the harness must handle the refusal output as a terminal response—do not allow the main model to override or soften the refusal.

Validation starts with output schema enforcement. Require the model to return a structured JSON object with at minimum refusal_triggered (boolean), confidence (float 0-1), policy_rule (string), and safe_response (string). Validate this schema before the response reaches the user. If refusal_triggered is true and confidence is below your defined threshold (start at 0.85 and tune based on production false-positive rates), route to a human review queue rather than auto-refusing. Log every refusal decision with the input hash, detected indicators (age inference, school context, guardian consent boundary), confidence score, and the safe response text. These logs become your audit trail for COPPA compliance demonstrations and help you tune over-refusal rates. For high-risk domains like child data, never skip the logging step—regulators will ask for evidence of your safety controls.

Model choice matters. Use a model with strong instruction-following and low refusal drift for this task. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro have demonstrated reliable policy adherence in safety classification tasks. Avoid smaller or older models that may hallucinate confidence scores or fail to detect indirect age indicators. If you are using a local or air-gapped deployment, validate the model against a golden test set of 200+ cases covering direct age requests, school-context inference, guardian consent edge cases, and benign child-adjacent queries (e.g., 'recommend books for my 10-year-old') before trusting it in production. Run this validation on every model update. For agentic systems where tools could return data about minors, inject this refusal check after tool outputs but before surfacing results to the user—tool-returned data is a common exfiltration vector that pre-generation checks miss.

Retry logic should be minimal. If the model returns malformed JSON, retry once with a stricter schema instruction and a lower temperature (0.0-0.1). If the second attempt fails, escalate to human review rather than guessing. Do not retry a refusal decision itself—if the model flags a request as triggering child data protection rules, treat that as a terminal decision unless a human reviewer overrides it. For session-based applications, maintain a session risk score that increments when the model detects probing patterns (e.g., rephrasing a refused request about a minor's data). If the session risk score crosses a threshold, lock the session and escalate. This prevents multi-turn jailbreak attempts that exploit single-turn evaluation gaps.

Human review integration is mandatory for edge cases. When the confidence score falls between 0.7 and your auto-refusal threshold, when the detected policy rule is guardian_consent_boundary, or when the input contains school-related context without explicit age mention, route to a review queue. Provide reviewers with the original input, the model's classification, the confidence score, and the proposed safe response. Reviewers should have the ability to approve the refusal, override it with a custom response, or mark the input as a false positive to improve your eval dataset. Track override rates by policy rule to identify where your refusal boundaries need tuning. Close the loop by feeding reviewed decisions back into your few-shot examples and regression test suite.