Regulated Activity Detection Prompt Template

This prompt is designed for compliance engineers and AI safety platform builders who need to intercept user requests before they reach a generative model and determine whether the request falls into a legally regulated domain such as medical advice, legal counsel, financial guidance, or electoral content. Use this prompt as an upstream classification gate in your AI pipeline. It produces a structured domain classification, applicable regulation flags, a risk tier, and a recommended guardrail action. This is not a prompt for generating compliant responses. It is a detection and routing prompt that should feed into downstream refusal, safe-alternative, or human-escalation workflows.

Deploy this when your application operates in multiple jurisdictions, serves users who may ask for professional advice, or must demonstrate audit-ready compliance decision trails. Wire the structured output into a routing layer that enforces the recommended guardrail action: block the request entirely, redirect to a safe-alternative workflow, escalate for human review, or allow with logging. Do not use this prompt when you need to generate a compliant answer to a regulated request—it only classifies and routes. Do not rely on it as your sole defense; pair it with downstream refusal prompts, tool-access denial rules, and session-level risk scoring for defense in depth.

Before integrating, define your jurisdiction set and map each regulation flag to a concrete enforcement action in your application code. Test with jurisdiction-aware eval cases that span multiple regulatory regimes and edge cases where a request touches more than one regulated domain. Log every classification decision with the full structured output, timestamp, and session identifier to produce audit trails. If the prompt returns low confidence or an ambiguous risk tier, default to the more conservative guardrail action and escalate for human review rather than allowing the request to proceed unexamined.

This template is designed to be pasted directly into your system instructions or a pre-processing classification node. It instructs the model to analyze a user request for signals that it falls into a legally or professionally regulated domain—such as medical, legal, or financial advice—and to return a structured classification object. The prompt uses square-bracket placeholders for your specific policy definitions, jurisdiction context, and output requirements. Replace these placeholders with concrete values before deployment. Do not leave any placeholder unresolved in production.

textCopy
You are a compliance classification system. Your job is to analyze the user's request and determine whether it seeks or implies a need for regulated professional advice. You do not provide the advice yourself. You only classify the request and recommend a guardrail action.

## POLICY DEFINITIONS
[POLICY_DEFINITIONS]

## JURISDICTION CONTEXT
[JURISDICTION_CONTEXT]

## INPUT
[INPUT]

## INSTRUCTIONS
1. Analyze the request against the defined regulated domains.
2. If the request falls into a regulated domain, identify the specific domain, applicable regulations, and the confidence of your classification.
3. Recommend exactly one guardrail action from the allowed list.
4. If the request is ambiguous, flag it for human review rather than guessing.
5. Do not generate the regulated content itself. Only classify and route.

## ALLOWED GUARDRAIL ACTIONS
- REFUSE: Block the request and return a safe refusal message.
- REDIRECT: Offer a safe, non-regulated alternative or general educational resource.
- HUMAN_REVIEW: Escalate to a qualified human reviewer.
- ALLOW: The request is not regulated; proceed normally.

## OUTPUT SCHEMA
Return a single JSON object with this exact structure:
{
  "regulated": boolean,
  "domain": string | null,
  "applicable_regulations": string[],
  "confidence": number,
  "guardrail_action": "REFUSE" | "REDIRECT" | "HUMAN_REVIEW" | "ALLOW",
  "reasoning": string,
  "safe_alternative": string | null
}

## CONSTRAINTS
- Never generate medical diagnoses, treatment plans, or drug prescriptions.
- Never generate legal advice, case strategy, or contract interpretation for a specific party.
- Never generate personalized financial advice, investment recommendations, or tax strategies.
- When confidence is below [CONFIDENCE_THRESHOLD], default to HUMAN_REVIEW.
- Cite the specific policy clause from [POLICY_DEFINITIONS] that applies.

To adapt this template, start by replacing [POLICY_DEFINITIONS] with your organization's concrete policy language. Vague policies produce inconsistent classifications. Define each regulated domain with clear inclusion and exclusion criteria, and provide boundary examples. Replace [JURISDICTION_CONTEXT] with the specific legal or regulatory frameworks that apply to your deployment region—such as HIPAA for US healthcare, GDPR for EU data, or SEC rules for financial content. Set [CONFIDENCE_THRESHOLD] to a numeric value between 0 and 1 that reflects your risk tolerance; 0.85 is a common starting point for high-risk domains. The [INPUT] placeholder should be replaced at runtime with the user's request text. Wire this prompt into a pre-processing step that runs before any generation model, so that regulated requests are intercepted early. Validate every output against the JSON schema before routing. Log all HUMAN_REVIEW and REFUSE decisions with the full classification payload for auditability. Run this prompt against a golden set of known regulated and non-regulated examples before every model or policy update to catch regressions.

The Regulated Activity Detection prompt is a classification gate, not a conversational feature. It should sit early in your request pipeline—before any domain-specific reasoning, tool calls, or user-facing responses are generated. The prompt expects a user utterance and a jurisdiction context, and it returns a structured classification payload. In production, you will wrap this prompt in an API call, validate the output against a strict schema, and route the result to the appropriate downstream handler: block, warn, escalate, or proceed. Do not treat this as a one-shot prompt you fire and forget; the output must be machine-verified before any action is taken.

Wire the prompt into your application with a thin service layer that handles model invocation, output validation, and retry logic. Use a model that supports structured output (JSON mode or function calling) and supply the expected schema at call time. After receiving the response, validate that domain_classification contains only allowed enum values, that regulated is a boolean, and that applicable_regulations is an array of strings matching your known regulation codes. If validation fails, retry once with the validation error appended to the prompt as a correction hint. If the second attempt also fails, log the raw output and escalate to a human review queue rather than guessing. For high-risk jurisdictions or risk_level: high classifications, always require human approval before the system acts on the detection result. Log every invocation with the input hash, jurisdiction, classification, confidence score, and reviewer decision for audit trails.

Model choice matters here. Use a model with strong instruction-following and low refusal-on-classification tendency—this prompt asks the model to classify, not to refuse. Avoid models that over-refuse on regulated topics, as they may conflate classification with endorsement. If you observe the model refusing to classify legitimate regulated-domain queries, add a system-level instruction that classification is a safety function, not an endorsement. For latency-sensitive applications, consider caching classifications for identical input-jurisdiction pairs. Do not use this prompt as a substitute for legal review; it is a triage tool that reduces the surface area your human reviewers must cover. The next step after implementation is to build a regression test suite using the jurisdiction-aware eval cases described in the Testing and Evaluation section.