Legal Document Interpretation Disclaimer Prompt Template

This prompt is designed for AI features that summarize contracts, extract clauses from filings, or answer questions about legal documents. It produces a structured output that includes a mandatory disclaimer stating the response is not legal advice, identifies ambiguous clauses requiring attorney review, and refuses to recommend specific legal actions. The primary job-to-be-done is creating a programmatic, auditable boundary between document intelligence and the unauthorized practice of law (UPL). The ideal user is a product engineer or compliance architect embedding AI into a legal tech, contract management, or due diligence platform where the model must handle legal text without overstepping into legal counsel.

Use this prompt when your application ingests legal text and you need a consistent, machine-readable refusal and disclaimer layer. Concrete scenarios include: a contract review tool that flags risky clauses but must not suggest specific redlines; a legal research assistant that summarizes case law but must not predict litigation outcomes; or a filing analysis feature that extracts obligations but must not make materiality judgments. Do not use this prompt for general Q&A, creative writing, or workflows where legal liability is not a concern. It is also inappropriate for attorney-facing tools where the user is a licensed professional who has explicitly waived disclaimers, or for fully internal document processing pipelines that do not surface output to end users.

Before deploying, pair this prompt with an evaluation harness that tests for boundary violations: check that the output never contains phrases like 'you should file,' 'we recommend,' or 'the best course of action is.' Validate that the disclaimer appears in every response, not just when the model detects high-risk content. Implement a human review queue for any output flagged as containing a conclusory legal judgment. The next step after integrating this prompt is to build regression tests using your organization's actual legal documents to ensure the refusal behavior remains stable across model updates and prompt revisions.

This template is designed to be placed in your system instructions or as a pre-pended user message for any AI feature that summarizes, extracts, or interprets legal documents. It enforces a strict boundary: the model must not provide legal advice, recommend specific legal actions, or make conclusive legal judgments. Instead, it produces a clear disclaimer, identifies clauses that require attorney review, and offers only factual extraction or summarization. The template uses square-bracket placeholders that your application must populate before sending the request to the model.

textCopy
You are an AI assistant that helps users understand legal documents. You do not provide legal advice, and you must never recommend a specific legal action, strategy, or outcome.

When responding to any request involving a legal document, you must follow these rules:

1. BEGIN EVERY RESPONSE with the following disclaimer, verbatim:
"DISCLAIMER: I am an AI assistant and not a licensed attorney. The following information is not legal advice. It is provided for informational and educational purposes only. You should consult a qualified legal professional before making any decisions based on this document."

2. You may perform the following tasks:
   - Summarize factual content and procedural history.
   - Extract defined terms, parties, dates, and obligations.
   - Identify and quote specific clauses when asked.
   - Explain the plain meaning of common legal terms.

3. You must REFUSE the following requests:
   - Recommending whether a party should sign, agree, or settle.
   - Predicting the outcome of litigation or negotiation.
   - Determining the enforceability or validity of a clause.
   - Providing a "risk score" or legal conclusion about any provision.
   - Drafting new contract language beyond template placeholders.

4. When you encounter a clause that is ambiguous, unusual, or potentially significant, you must flag it using this format:
"[REVIEW RECOMMENDED] Clause [NUMBER/LOCATION]: [BRIEF DESCRIPTION OF CONCERN]. An attorney should review this provision before you rely on it."

5. If a user asks you to perform a refused task, respond with:
"I cannot provide that analysis because it would constitute legal advice. I can [LIST PERMITTED ALTERNATIVES]. Would you like me to proceed with one of those options?"

6. Do not cite specific statutes, case law, or jurisdictional rules unless the user has provided them as context. You may reference general legal concepts but must not apply them to the user's specific situation.

[INPUT]: The legal document text or user question to process.
[CONTEXT]: Any additional instructions, such as specific clauses to focus on or output format preferences.
[OUTPUT_SCHEMA]: The expected structure for the response, if a specific JSON or markdown format is required.
[CONSTRAINTS]: Additional application-level rules, such as maximum response length or required sections.
[RISK_LEVEL]: Set to "HIGH" to enforce the strictest refusal behavior; set to "STANDARD" for educational contexts where some flexibility is acceptable.

To adapt this template, replace the square-bracket placeholders with values from your application context. For example, if your product is a contract review tool, you might set [CONTEXT] to "Focus on termination clauses and indemnification provisions" and [OUTPUT_SCHEMA] to a JSON object with summary, extracted_clauses, and review_recommended fields. The [RISK_LEVEL] parameter is a critical control: when set to HIGH, the model should refuse even borderline requests; when set to STANDARD, it may provide more general educational context. Always test both settings against your eval suite before deploying. For high-stakes legal workflows, pair this prompt with a human review step and log every refusal for audit purposes.

This prompt is designed to sit inside a document processing pipeline where user-uploaded legal documents or contract text flow through extraction, summarization, or Q&A steps before reaching the end user. The disclaimer prompt should be invoked as a post-processing guard—applied to the model's draft output before it is shown to the user, not as a separate user-facing step. The harness must treat this prompt's output as a structured compliance wrapper that either clears the content for display, appends a mandatory disclaimer, or blocks the response and escalates for human review.

Wire the prompt into your application as a synchronous validation layer between the primary generation step and the UI render. The application should: (1) take the raw model output and the original document context, (2) populate the [DOCUMENT_TYPE], [EXTRACTED_CONTENT], and [OUTPUT_SCHEMA] placeholders, (3) call the disclaimer prompt with response_format set to JSON if your model supports structured output mode, (4) parse the disclaimer_required, risk_flags, and safe_output fields from the response, and (5) branch based on the result. If disclaimer_required is true, prepend the generated disclaimer text to the user-facing output. If any risk_flags have severity: "high" or requires_human_review: true, route the entire response to a review queue and log the flagged clauses with the original document reference. Use a strict JSON schema validator on the response before acting on it—malformed JSON should trigger a single retry with the error message included in the retry prompt, then escalate to human review if the retry also fails.

For model selection, prefer models with strong instruction-following and structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller or older models that may collapse the structured fields into free text or ignore the refusal conditions. Set temperature=0 to maximize consistency on the binary disclaimer_required and risk_flags fields. Implement request-level logging that captures: the document hash (not the full document, to avoid logging sensitive content), the prompt version, the model and temperature, the raw disclaimer output, the validator result, and the final routing decision. This log becomes your audit trail for compliance reviews. For high-throughput pipelines, cache disclaimer results per document hash to avoid redundant model calls when the same document is processed multiple times. If your application operates in a regulated environment, ensure that the human review queue has an SLA and that escalated items block user-facing output until resolved—never default to showing un-reviewed content when the guard raises a high-severity flag.

The most common production failure mode is over-flagging: the prompt marks benign summarization as requiring disclaimer when the output is purely factual extraction. Mitigate this by maintaining a small golden dataset of 20–30 document-output pairs with expected disclaimer_required and risk_flags labels, and run regression tests before deploying prompt changes. A secondary failure mode is disclaimer fatigue where users ignore the disclaimer because it appears on every response. Address this by only prepending the full disclaimer when disclaimer_required is true, and consider a lighter inline notice for low-risk outputs. Do not skip the human review path for high-severity flags—this prompt is a guardrail, not a legal shield, and the application owner retains responsibility for outputs that reach users.