Disclaimer Injection: Adding Legal Notices to AI Responses Automatically
Disclaimer injection in Keeptrusts is currently an output-phase compliance feature, not a generic banner switch: financial-compliance prepends required disclaimer lines when a response looks like investment advice, and healthcare-compliance does the same for medical-advice style output. In practice, automatic legal notices work best when they are paired with explicit block or escalation controls rather than treated as the only safeguard.
Use this page when
- You need to understand how Keeptrusts adds compliance notices to AI responses today.
- You want to choose between disclaimer-only behavior, hard block behavior, and human escalation.
- You need a practical way to explain disclaimer injection without claiming a broader generic policy surface than the docs support.
Primary audience
- Primary: Technical Engineers, Compliance owners, and platform operators
- Secondary: Technical Leaders and reviewers responsible for high-risk workflows
Start with what the product actually exposes
Automatic disclaimers are easy to describe badly because many teams think of them as a text templating feature. In Keeptrusts, the documented public behavior is narrower and more useful than that.
The current customer-facing declarative policies that explicitly prepend disclaimers are domain-specific output controls:
financial-compliancefor finance-oriented advice patterns.healthcare-compliancefor medical-advice patterns.
Both policies work the same basic way.
They examine the completed model output, look for built-in advice heuristics, and prepend disclaimer text when the response appears to cross into advice rather than general information.
They can also block explicitly configured phrases. That is the important operational distinction. A disclaimer is for cases where the output may continue with a clear notice. A block is for language that should never be delivered at all.
That distinction matters more than the disclaimer text itself.
Example: finance-oriented disclaimer injection
The finance policy is the clearest documented example because it shows both disclaimer prepending and phrase blocking in one place.
pack:
name: financial-disclaimer-controls
version: 1.0.0
enabled: true
policies:
chain:
- financial-compliance
- human-oversight
- audit-logger
policy:
financial-compliance:
blocked_patterns:
- guaranteed return
- strong buy
- strong sell
required_disclaimers:
- This is not financial advice.
- Consult a qualified financial advisor before making investment decisions.
human-oversight:
action: escalate
audit-logger:
retention_days: 365
This config expresses three separate decisions.
First, some phrases are unacceptable and should block immediately.
Second, advice-like content that is still allowed should receive a notice. The financial-compliance docs are explicit that the disclaimer is prepended, not appended, and that the gateway adds it only when the output looks like advice and does not already start with the same disclaimer text.
Third, a higher-risk route can still be escalated with Human Oversight rather than relying on disclaimers alone.
That last point is usually where mature teams end up. If the output has regulatory or customer-impact consequences, a notice helps, but review workflow matters more.
Why prompt-only disclaimers are not enough
It is tempting to tell the model, in a system prompt, to always add a disclaimer. That can work some of the time, but it is not the same as an output policy.
Prompt instructions are advisory to the model. Output policies are enforced by the gateway after the model responds.
That is the core reason disclaimer injection belongs in governance config rather than only in prompts. If the model forgets the requested language, the policy can still apply the notice. If the model produces a blocked phrase, the policy can stop it entirely.
The same logic is why disclaimer injection is not a substitute for Prompt Injection Detection or DLP Filter. Those policies protect different parts of the request-response path.
Where disclaimer injection fits in the control stack
In practice, disclaimers sit near the end of the chain because they act on the completed output.
That makes them complementary to earlier controls:
- Prompt Injection Detection protects the request boundary.
- DLP Filter and other input-side controls prevent unsafe material from crossing the boundary in the first place.
- Data Routing Policy decides which providers may receive the request.
- Output-side compliance policies decide what the user is allowed to see after the provider responds.
This layered view is important because disclaimers can easily be oversold. They improve transparency and reduce ambiguity, but they do not sanitize a bad input, rewrite a provider contract, or replace a human review queue.
Be precise about what is declarative today
The current docs also describe response-rewriter as a runtime-only response transformation control rather than part of the customer declarative config schema. That is a useful boundary to keep in mind when explaining the product.
If you are writing public or customer-facing guidance, it is safer to describe automatic disclaimer behavior through the documented compliance policies that already expose it declaratively. In the current docs, that means the finance and healthcare compliance controls.
This is also why the title question has a careful answer. Keeptrusts can add legal or compliance notices automatically, but the current public declarative examples are domain-specific rather than a universal disclaimer policy block.
When a disclaimer should become a block or escalation
The easiest way to misuse disclaimer injection is to push too much responsibility onto the notice itself.
Use a disclaimer when the response can still be delivered safely if the user is clearly warned about the limits of the output.
Use a block when the phrasing itself is not acceptable. In the financial policy, examples such as guaranteed return or overly directive recommendation language belong in blocked_patterns.
Use escalation when the route is materially risky even after a notice. This is where Human Oversight becomes the stronger control.
That three-part split keeps the policy explainable:
- Notice for allowed-but-sensitive output.
- Block for prohibited output.
- Escalate for output that requires a person.
Validation workflow
Treat disclaimer injection like any other governed behavior: validate both the positive and negative paths.
kt policy lint --file policy-config.yaml
Then verify at least these cases:
- A neutral informational answer that should not receive a disclaimer.
- An advice-like answer that should receive the disclaimer prefix.
- A prohibited phrase that should block rather than display with a notice.
- A route where
human-oversightshould escalate instead of returning assistant content.
If your application also depends on provider resilience, validate those routes independently. Disclaimer injection happens after a provider returns. Multi-provider resilience helps you get a response. Compliance policies decide whether and how that response is delivered.
Key takeaways
- Keeptrusts currently documents automatic disclaimer prepending through domain-specific output policies such as
financial-complianceandhealthcare-compliance. - In those policies, disclaimer text is prepended when advice heuristics fire; it is not just appended as decoration.
- Disclaimer injection should be paired with blocking rules for prohibited language and escalation when a human decision is required.
- Do not rely on prompts alone for mandatory notices when the gateway can enforce them after generation.
- Treat disclaimer injection as one layer in the governance stack, not the whole control strategy.