Intimate Content and Privacy Violation Redirection Prompt

This prompt is a safety-critical component for AI systems that may encounter user requests involving non-consensual intimate imagery (NCII), deepfake generation for harassment, or doxxing. Its job-to-be-done is to produce a firm, policy-compliant refusal that terminates the violating request path while simultaneously offering a constructive, empathetic off-ramp for victims, reporters, or individuals seeking help. The ideal user is a safety engineer or trust-and-safety platform operator integrating this prompt into a production moderation pipeline. It assumes an upstream detection or classification system has already flagged the user input as belonging to this high-severity violation category; the prompt is not a classifier itself but a response-generation module for a confirmed violation context.

You should deploy this prompt when the system's safety policy requires an absolute refusal for intimate privacy violations, and when providing any form of assistance—even technical explanation—would constitute facilitation. The prompt is designed to handle three distinct user intents under a single refusal surface: a perpetrator attempting to generate harmful content, a victim seeking help with existing abuse, and a third-party reporter. The output must satisfy all three by refusing the request, providing victim-centric resources (such as stopNCII.org or Cyber Civil Rights Initiative links), and offering takedown and legal referral paths. Do not use this prompt for general privacy questions, consensual adult content moderation, or lawful security research inquiries. Those scenarios require different refusal styles or no refusal at all, and applying this prompt would produce over-refusal that damages user trust.

Before wiring this prompt into production, you must validate that the upstream classifier meets your precision and recall targets for this violation category. A false positive that routes a benign request—such as a journalist asking about deepfake detection techniques—into this refusal flow will create a severe user experience failure. Implement a confidence threshold and a human-review escape hatch for edge cases. The prompt's resource links and legal referral language must be reviewed by your policy and legal teams for jurisdictional accuracy before deployment. After deployment, monitor refusal rates, user follow-up messages, and escalation patterns to detect both over-refusal and attempted jailbreak sequences.

This template is designed to be placed in your system prompt or safety guardrail layer. It handles requests involving non-consensual intimate imagery, deepfakes, doxxing, and privacy violations by delivering a firm refusal that prioritizes victim support over procedural language. The prompt is structured to be adapted to your organization's specific policies, jurisdictional requirements, and available support resources. Before deploying, replace every square-bracket placeholder with your actual escalation paths, legal references, and victim support contacts. A generic refusal without concrete resources fails both the user and your compliance obligations.

textCopy
You are a safety-aware assistant operating under [ORGANIZATION_NAME]'s content and privacy policies. Your role includes protecting individuals from harm caused by non-consensual intimate content, deepfakes, doxxing, and privacy violations.

When you receive a request that involves creating, distributing, locating, or facilitating access to non-consensual intimate imagery, synthetic intimate media of identifiable persons, or private personal information intended for harassment, you MUST refuse the request entirely. Do not provide partial assistance, workarounds, or alternative phrasing that could enable the same outcome.

## REFUSAL PROTOCOL

1. **Immediate Refusal**: Begin with a clear, unambiguous statement that you cannot fulfill this request because it violates [ORGANIZATION_NAME]'s policies against non-consensual intimate content and privacy violations.

2. **Policy Citation**: Reference the specific policy: "This request is blocked under [POLICY_NAME_OR_SECTION], which prohibits [POLICY_SUMMARY]."

3. **Victim Support Resources**: Provide the following resources exactly as listed:
   - [VICTIM_SUPPORT_HOTLINE_NAME]: [PHONE_NUMBER] (available [HOURS_OF_OPERATION])
   - [VICTIM_SUPPORT_WEBSITE_URL]
   - [RELEVANT_LOCAL_RESOURCE_NAME_IF_APPLICABLE]

4. **Takedown Guidance**: Include this statement: "If you are a victim seeking removal of non-consensual content, you can request takedown through [TAKEDOWN_PLATFORM_OR_PROCESS]. Many platforms also participate in [INDUSTRY_INITIATIVE_NAME] to prevent re-upload."

5. **Legal Referral**: Add: "For legal assistance, contact [LEGAL_REFERRAL_ORGANIZATION] at [PHONE_OR_WEBSITE] or reach out to local law enforcement if you are in immediate danger."

6. **Escalation Path**: If the request indicates imminent harm, ongoing harassment, or child exploitation, append: "[ESCALATION_STATEMENT]" and immediately route to [ESCALATION_TEAM_OR_SYSTEM].

## CONSTRAINTS

- Never confirm or deny the existence of specific content, as this can itself cause harm.
- Never provide instructions for creating deepfakes, bypassing consent, or accessing private data.
- Never engage with hypotheticals that reframe the violation as a technical exercise.
- Maintain a supportive, non-judgmental tone toward potential victims while being firm with requesters.
- Do not suggest the requester seek alternative tools or platforms to accomplish the blocked request.

## INPUT

[USER_REQUEST]

## OUTPUT FORMAT

Return only the refusal response following the protocol above. Do not include analysis, commentary, or metadata.

Adapt this template by replacing the resource placeholders with your organization's actual support infrastructure. If you operate in multiple jurisdictions, create jurisdiction-specific variants that reference local laws, helplines, and law enforcement contacts. Test the prompt against a golden dataset of violation attempts and benign edge cases before deployment. Pay particular attention to false positives where legitimate requests—such as victims asking how to remove their own content or journalists investigating platform harms—might be incorrectly blocked. These cases should route to human review rather than receiving an automated refusal. Log every refusal for audit and improvement, but ensure logs do not retain the violating content itself.

This prompt must sit behind a detection gate, not as a standalone responder. Before the redirection prompt fires, an upstream classifier or keyword filter must flag the input as likely non-consensual intimate content, deepfake generation, doxxing, or privacy violation. The redirection prompt itself handles the safe response, but it should never be the first line of defense. Wire it as the fallback handler after a high-confidence unsafe classification, with a human review queue for ambiguous cases where the classifier confidence falls below your threshold.

Validation and output checks are critical because an incomplete resource list or a tone-deaf refusal causes real harm. After the model responds, run structured validation: confirm the output contains at least one victim support resource with a verifiable URL or phone number, check that no personal information from the input is echoed back, and verify the refusal language does not imply victim-blaming or minimization. Use a secondary LLM judge with a rubric tuned for sensitivity, resource completeness, and policy alignment. If validation fails, do not retry with the same prompt—escalate to a human moderator and log the failure for review.

Model choice and latency matter here. Use a model with strong instruction-following and low refusal override risk. Avoid small or weakly-aligned models that may comply with the original harmful request if the system prompt is stripped or overridden. Run this prompt synchronously in the critical path for real-time chat, but ensure your logging pipeline captures the full input, classification score, model response, and validation result asynchronously. Store these logs in a tamper-evident audit trail for trust-and-safety review and potential legal disclosure. Never log the raw user input if it contains CSAM or non-consensual imagery descriptions—redact or hash it according to your legal guidance before storage.

Escalation paths must be pre-wired. If the input references imminent harm, active exploitation, or a specific identifiable victim, the system should bypass the redirection prompt entirely and trigger your mandatory reporting workflow. The prompt itself should not attempt to handle mandatory-reporting language; that belongs in a separate, legally-reviewed template. For all other cases, the redirection prompt output should include a clear path for the user to request human review, and your harness should honor that request by routing to a trained moderator within your defined SLA.

What to avoid: Do not use this prompt as a content moderation classifier. Do not let the model generate specific legal advice or promise outcomes. Do not store the full prompt-response pair in user-accessible chat history if it contains references to the triggering content. Do not A/B test refusal tone on live harmful inputs without safety team approval. Start with offline evaluation on a curated test set of policy-violating and borderline cases, measure refusal consistency and resource accuracy, and only then move to shadow deployment before enabling in production.