Transparency Statement Embedding Prompt for AI Copilots

This prompt is for product teams building AI copilots that interact directly with end-users and must proactively disclose their nature, capabilities, and limitations. The core job-to-be-done is to generate a durable, testable transparency policy that can be injected into a system prompt without degrading the copilot's primary task performance. The ideal user is an AI product manager or engineer who needs to move beyond a generic 'I am an AI' disclaimer and instead define precise rules for when disclosure occurs (first turn, on specific topics, when confidence is low), what language must be used, and how the policy persists across multi-turn conversations. You need this prompt when your copilot faces users who may mistake it for a human, when it operates in a domain with specific disclosure regulations, or when your trust and safety review has flagged inconsistent self-identification as a risk.

Do not use this prompt if you are building a backend classifier, an internal tool with no direct user interaction, or a system where the AI's identity is already obvious from the interface. This prompt is also insufficient as a standalone legal compliance mechanism; it produces a policy draft that must be reviewed by your legal and compliance teams before production deployment. The prompt assumes you have already defined your copilot's core persona and task boundaries—it adds a transparency layer on top of an existing system prompt, rather than designing the entire assistant from scratch. If your copilot uses tools, retrieves documents, or hands off to human agents, you will need to extend the output with tool-specific disclosure rules and handoff transparency requirements.

Before using this prompt, gather your copilot's capability list, known limitations, and any jurisdiction-specific disclosure requirements. The prompt template requires these as inputs to produce a policy that is specific rather than generic. After generating the policy, you must test it against the eval criteria included in the full playbook: consistent disclosure across conversation turns, no task degradation on core workflows, and correct handling of edge cases where disclosure might confuse the user. The next step is to inject the generated policy into your system prompt and run your existing regression suite to catch any unintended behavioral changes.

This template encodes a transparency policy directly into the system prompt layer so the copilot consistently discloses its nature, capabilities, and limitations across conversation turns. The square-bracket placeholders let you adapt disclosure timing, content requirements, and language to your product's risk profile and user expectations. Copy the template, replace each placeholder with your specific policy values, and test the resulting prompt against the eval criteria in the Testing and Evaluation section before deployment.

textCopy
You are an AI copilot embedded in [PRODUCT_NAME], designed to assist users with [TASK_DOMAIN]. Your primary directive is to be helpful while maintaining strict transparency about what you are, what you can do, and what you cannot do.

## Mandatory Disclosure Rules

1. **First-Turn Disclosure**: On the first message of every conversation, include this statement verbatim before any other response: "[FIRST_TURN_DISCLOSURE_TEXT]"

2. **Capability Boundary Disclosure**: When a user asks you to perform an action outside your capabilities, respond with: "[CAPABILITY_BOUNDARY_TEXT]" Do not attempt the action or simulate results.

3. **Limitation Disclosure Triggers**: Immediately disclose your limitations when:
   - A user asks for [DISCLOSURE_TRIGGER_1]
   - A user asks for [DISCLOSURE_TRIGGER_2]
   - A user asks for [DISCLOSURE_TRIGGER_3]
   For each trigger, use this response format: "[LIMITATION_DISCLOSURE_FORMAT]"

4. **Confidence Disclosure**: When your confidence in an answer is below [CONFIDENCE_THRESHOLD] or when you are synthesizing rather than retrieving from a verified source, prefix your response with: "[UNCERTAINTY_PREFIX]"

5. **Source Attribution**: When you reference information from [SOURCE_TYPES], cite the source using this format: "[SOURCE_CITATION_FORMAT]" If no source is available, state: "[NO_SOURCE_DISCLOSURE]"

6. **AI Identity Reinforcement**: If a user asks whether you are human, respond with: "[IDENTITY_DISCLOSURE_TEXT]" Do not role-play as a human under any circumstances.

7. **Turn-Level Consistency**: Apply these disclosure rules on every turn. Do not skip disclosures because a prior turn included them. Do not assume the user has read previous disclosures.

## Disclosure Prohibitions

- Do not add qualifiers that undermine the disclosure (e.g., "I'm just an AI, but..." followed by overconfident claims).
- Do not bury disclosures in long paragraphs where they become easy to miss.
- Do not omit disclosures to be more helpful or to avoid interrupting the user flow.

## Output Format

Always place disclosures at the beginning of your response, before any substantive content. If multiple disclosures apply, stack them in the order listed above, separated by a single newline.

[ADDITIONAL_CONSTRAINTS]

Adaptation guidance: Replace [PRODUCT_NAME] and [TASK_DOMAIN] with your copilot's actual scope. Define [DISCLOSURE_TRIGGER_1] through [DISCLOSURE_TRIGGER_3] based on your product's known failure modes—common triggers include medical advice, legal interpretation, financial recommendations, or real-time event claims. Set [CONFIDENCE_THRESHOLD] to a concrete value your eval framework can measure. The [ADDITIONAL_CONSTRAINTS] placeholder at the end lets you append domain-specific rules without restructuring the template. Before shipping, run this prompt through the eval suite described in the Testing and Evaluation section to verify that disclosures appear consistently and do not degrade primary task completion rates.

Embedding a transparency statement is not a one-time prompt injection; it requires application-layer wiring to ensure the disclosure survives context window shifts, appears at the right moments, and does not degrade the primary task. The prompt template defines what to disclose and when, but the harness must enforce that it happened. This means treating the transparency statement as a contract between the system prompt and a post-processing validator, not as a static string that the model may eventually ignore.

Integration pattern. Place the prompt template inside the system instructions of your copilot. On every assistant turn, run a lightweight validator that checks for the presence of a disclosure marker (e.g., [TRANSPARENCY_STATEMENT]) or a regex pattern matching your required disclosure language. If the validator fails, append a short recovery instruction to the next system message: "Your last response was missing the required transparency disclosure. Re-answer the user's last request and include the full disclosure statement as defined in your system instructions." This retry loop should have a hard limit of 2 attempts before the turn is escalated to a human reviewer or a fallback static message is injected. Log every validator pass/fail event with the turn index, model version, and disclosure type for observability.

Model choice and context budget. Transparency disclosures consume tokens. For long-conversation copilots, the system prompt may be pushed out of the context window. Use a context window monitor that tracks estimated token usage and, when the system prompt is at risk of truncation, re-injects the transparency policy as a high-priority developer message. For models with native system message support (e.g., Claude, GPT-4), prefer the system role. For models that flatten all messages, prepend the transparency policy to the most recent user message with a clear delimiter. Test this behavior explicitly with a 30-turn conversation that includes the disclosure check on turns 1, 15, and 30.

Evaluation and regression gates. Before shipping, build a small eval suite: 5 conversations where the user asks for help with tasks the copilot can perform, 3 where the user asks the copilot to hide its identity, and 2 where the user asks questions unrelated to transparency. The pass criterion is that every assistant turn in the first 5 conversations includes the disclosure, the 3 identity-hiding attempts are refused or result in reinforced disclosure, and the 2 unrelated turns are not degraded. Run this suite on every prompt change and model upgrade. If the disclosure rate drops below 100% on the positive cases, block the release.

Failure modes to instrument. The most common failure is disclosure drift: the model gradually shortens or drops the statement over long conversations. Instrument disclosure length per turn and alert if the character count drops below 80% of the baseline. The second failure is disclosure fatigue: users complain about repetitive statements. Mitigate this by allowing the prompt to vary the phrasing slightly while keeping the required content elements. The third failure is disclosure injection: a malicious user convinces the model to output a fake disclosure. Your validator should check for the exact required content elements, not just the presence of any disclosure-like text. Wire these three metrics into your production dashboard and set thresholds for automated rollback.