Legal Advice Request Triage and Handoff Prompt

This prompt is designed for legal tech platforms, court self-help systems, and AI-assisted legal intake tools that must distinguish between general legal information and specific legal advice. The core job is to classify a user's legal query by risk level, determine whether responding could constitute the unauthorized practice of law (UPL), and route high-risk requests to a licensed professional review queue instead of generating a direct AI response. Use this when your platform serves users across multiple jurisdictions, when the boundary between information and advice is legally consequential, and when an incorrect classification creates regulatory liability.

Before deploying, you must supply jurisdiction-specific escalation rules, definitions of UPL for each operating region, and a mapping of query categories to risk levels. The prompt requires [JURISDICTION_RULES], [UPL_DEFINITIONS], and [ESCALATION_QUEUE] as input context. Without these, the model cannot make accurate routing decisions. The output is a structured classification object containing a risk level, a binary UPL flag, a confidence score, and a routing destination. This output should be validated by your application layer before any automated response is returned to the user. A human reviewer must confirm the classification rules are legally sound in each jurisdiction before production use.

Do not use this prompt as a substitute for legal counsel review of your classification rules. The jurisdictional boundaries and escalation criteria must be defined by qualified legal professionals in your operating regions. This prompt is a routing mechanism, not a legal opinion generator. If your platform cannot support a human review queue for high-risk classifications, do not deploy this prompt. A false negative—classifying a UPL request as safe—exposes your organization to regulatory action. Pair this prompt with logging that captures every classification decision, the model's confidence, and the final routing outcome for auditability.

This prompt template is designed to be pasted into your system instructions or used as a classification step before a general-purpose model responds to a user. Its job is to distinguish between general legal information requests and specific legal advice that could constitute the unauthorized practice of law (UPL). The prompt forces a structured output that your application harness can parse to either allow a response, block it, or route it to a human reviewer. Replace every square-bracket placeholder with your platform's specific policy language, jurisdiction rules, and routing targets before deployment.

codeCopy
SYSTEM INSTRUCTION:
You are a legal-request triage classifier. Your only job is to analyze the user's query and classify it into one of three risk levels. You do not provide legal answers, commentary, or advice.

INPUT:
[USER_QUERY]

CONTEXT:
- Jurisdiction: [JURISDICTION]
- Platform Policy: [PLATFORM_POLICY_SUMMARY]
- Regulated Activities: [LIST_OF_REGULATED_ACTIVITIES]

CLASSIFICATION RULES:
1. **General Legal Information (Risk: LOW)**
   - The user asks for definitions, explanations of legal concepts, or descriptions of general legal processes without applying them to a specific personal or business situation.
   - Examples: "What is a non-disclosure agreement?", "Explain the patent application process."
   - Action: ALLOW automated response.

2. **Specific Legal Guidance (Risk: MEDIUM)**
   - The user asks how a law or process applies to their specific facts, requests document drafting for a specific scenario, or seeks strategic advice.
   - Examples: "Does my landlord have the right to enter my apartment without notice in Texas?", "Draft a cease and desist letter for my neighbor's barking dog."
   - Action: BLOCK automated response and route to [MEDIUM_RISK_QUEUE_NAME] for human review.

3. **Unauthorized Practice of Law (Risk: HIGH)**
   - The user explicitly asks for legal representation, asks the AI to act as their lawyer, or requests actions that are clearly reserved for licensed attorneys in [JURISDICTION].
   - Examples: "Be my lawyer for my divorce.", "File this motion for me.", "Tell me what to say in court tomorrow."
   - Action: BLOCK all responses and immediately escalate to [HIGH_RISK_ESCALATION_QUEUE_NAME] with a high-priority flag.

OUTPUT_SCHEMA:
You must respond with a single, valid JSON object conforming to this schema:
{
  "risk_level": "LOW" | "MEDIUM" | "HIGH",
  "confidence": 0.0-1.0,
  "reasoning": "A brief, factual explanation of the classification based on the rules.",
  "suggested_action": "ALLOW" | "BLOCK_AND_ROUTE" | "ESCALATE",
  "routing_target": "[QUEUE_NAME]" | null
}

CONSTRAINTS:
- If the query is ambiguous, default to the higher risk level.
- Do not include any text outside the JSON object.
- If the user's query is in a language other than English, classify based on the translated meaning but set confidence to 0.5.

To adapt this template, start by defining your jurisdiction's specific rules for what constitutes legal advice. Work with your legal counsel to populate the [LIST_OF_REGULATED_ACTIVITIES] placeholder with concrete examples. Next, configure your routing targets: [MEDIUM_RISK_QUEUE_NAME] might point to a paralegal or customer support queue, while [HIGH_RISK_ESCALATION_QUEUE_NAME] should go directly to a compliance officer or in-house counsel. The output schema is designed to be machine-readable; your application harness should parse the risk_level and suggested_action fields to enforce the routing decision programmatically, never relying on the model to execute the action itself. Always log the full JSON payload for audit trails.

This prompt is designed to be called as a synchronous classification step before any substantive legal response is generated. In a typical architecture, the user's query passes through this triage prompt first. The model returns a structured JSON object containing a risk_level, classification, jurisdiction_flags, and a routing_decision. Your application code must parse this JSON, validate it against a strict schema, and branch the user's session based on the result. If the routing decision is escalate_to_human, the user should never see an AI-generated legal answer; instead, they should be placed into a review queue with the full triage payload attached. If the decision is safe_to_respond, the original query and the triage metadata can be passed to a downstream legal information prompt that has been separately tested for grounded, non-advisory responses.

Validation is the most critical part of this harness. The model's JSON output must be checked for schema conformance before any routing decision is executed. At minimum, validate that risk_level is one of the allowed enum values (low, medium, high, critical), that routing_decision is either escalate_to_human or safe_to_respond, and that the jurisdiction_flags array contains only recognized jurisdiction codes from your configured list. If validation fails, do not fall through to a default safe-to-respond path. Instead, treat the failure as an implicit escalation: log the raw output, flag it for human review, and return a neutral holding message to the user. This fail-closed pattern prevents a malformed model output from accidentally allowing unqualified legal advice to reach a user. Implement a retry with exponential backoff (max 2 retries) using a temperature of 0 and the same prompt, but if validation still fails, escalate.

Logging and audit trail requirements are substantial for legal workflows. Every triage decision must be logged with the user's original query, the full model response, the validation result, the routing action taken, and a timestamp. If the request is escalated, attach the triage payload to the review queue item so the human reviewer can see exactly why the system flagged the request. For safe_to_respond decisions, log the triage metadata alongside the downstream AI response so that any future audit can reconstruct the decision boundary. Do not log the user's query or the model's output to any system that is not covered by your data retention and legal hold policies. If your application serves multiple jurisdictions, ensure that jurisdiction-specific escalation rules are applied in the application layer after the model returns its flags—do not rely solely on the model to enforce jurisdictional nuance without code-level checks.

Model choice matters. This prompt benefits from a model with strong instruction-following and low refusal variability. A model that is overly cautious may classify every legal query as high risk, flooding your review queue. A model that is too permissive may miss unauthorized-practice-of-law risks. Start with a mid-tier model that supports structured JSON output (e.g., GPT-4o, Claude 3.5 Sonnet) and evaluate false-positive and false-negative rates against a labeled golden dataset of 200+ legal queries spanning information requests, advice requests, and ambiguous cases. Track these metrics in your observability dashboard. If your false-positive escalation rate exceeds 15%, tune the prompt's examples and constraints before considering a model change. If false negatives (missed escalations) exceed 1%, add more explicit refusal examples and consider raising the risk threshold in the application layer.

Human-in-the-loop integration is the final piece. When a request is escalated, the human reviewer needs the original query, the triage classification, the jurisdiction flags, and any relevant context from the user's session. Build a review interface that allows the reviewer to confirm the escalation, reclassify the request as safe, or mark it as requiring a licensed professional response. Track reviewer decisions and feed them back into your evaluation dataset to improve the prompt over time. Never use the reviewer's decision to automatically retrain or fine-tune a model without legal review of the data pipeline. Finally, set a service-level objective for review queue response time—users waiting for legal guidance will not tolerate multi-day delays, so if your review queue backlog grows, invest in prompt tuning to reduce false escalations rather than letting the queue degrade the user experience.