You're deploying an LLM application into production. Your security team asks: "What happens when someone tries to extract PII through prompt injection?" Your compliance officer asks: "How do we prove we're moderating hallucinations in real-time?" Your CTO asks: "Can we do this without routing sensitive data through external APIs?"
Here's a policy template that answers all three questions. Copy it, customize it, and put it into practice this week.
Purpose of the Template
This Runtime Guardrail Policy outlines how your organization scores, moderates, and monitors LLM prompts and responses in production. It's designed for teams deploying customer-facing chatbots, internal knowledge assistants, or any LLM application where hallucinations, prompt injection attacks, or safety violations pose significant risks.
The policy covers:
- Real-time trust dimension scoring
- Threshold scores for acceptance or rejection
- Moderation locations (VPC, air-gapped, or cloud)
- Review processes for flagged interactions
This policy focuses on runtime controls, supporting your broader AI Management System (ISO/IEC 42001) or model risk framework (SR 11-7).
Prerequisites
Before implementing this policy, ensure you have:
Technical infrastructure:
- An LLM application with accessible prompt/response endpoints
- A scoring service that evaluates trust dimensions with latency under 100ms
- API integration between your application and scoring service
Organizational readiness:
- Defined risk appetite for each trust dimension (e.g., "Reject responses with a faithfulness score below 0.7")
- Clear ownership: who configures guardrails, reviews flagged content, and updates thresholds
- A monitoring dashboard or logging system to track moderation decisions
Compliance context:
- If subject to the EU AI Act and your LLM is high-risk, this policy supports your Technical Documentation (Annex IV) requirement for bias detection and mitigation
- For financial services under SR 11-7, this policy demonstrates monitoring controls for vendor-provided or outsourced models
The Template
RUNTIME GUARDRAIL POLICY FOR LLM APPLICATIONS
Version 1.0 | Effective Date: [DATE]
1. SCOPE
This policy applies to all LLM applications deployed in [production/customer-facing/internal] environments where prompt or response content creates risk of:
- Hallucinations affecting decision accuracy
- Safety violations (hateful, violent, sexual, harmful content)
- Security exploits (prompt injection, jailbreaking attempts)
- Privacy breaches (PII leakage in responses)
Covered systems: [List specific applications, e.g., "Customer support chatbot (CS-BOT-01)", "Internal HR knowledge assistant (HR-LLM-02)"]
2. TRUST DIMENSIONS AND THRESHOLDS
2.1 Hallucination Metrics
- Faithfulness/Groundedness: Minimum acceptable score = [0.7]
Action if below threshold: [Reject response, return fallback message]
2.2 Safety Metrics
For each dimension, define accept/reject threshold (0.0-1.0 scale):
- Illegal content: [0.9]
- Hateful content: [0.8]
- Harassing content: [0.8]
- Racist content: [0.9]
- Sexist content: [0.9]
- Violent content: [0.9]
- Sexual content: [0.8]
- Harmful content: [0.8]
- Unethical content: [0.7]
- Jailbreaking attempts: [0.9]
Action if any dimension exceeds threshold: [Reject prompt/response, log incident, notify security team if jailbreaking detected]
3. DEPLOYMENT ARCHITECTURE
Guardrails will be deployed in: [VPC / air-gapped environment / cloud with data encryption]
Rationale: [e.g., "VPC deployment required to maintain GDPR compliance and prevent sensitive customer data from routing through external platforms"]
Scoring latency requirement: [<100ms for user-facing applications, <500ms for internal batch processing]
4. CUSTOMIZATION AND CONFIGURATION
Guardrail thresholds may be adjusted by: [AI Governance Lead, Security Architect]
Adjustment process:
- Propose threshold change with risk justification
- Review flagged content sample (minimum 100 interactions) to validate new threshold
- Update configuration via [API call / configuration file / admin dashboard]
- Document change in guardrail change log with effective date
5. MONITORING AND REVIEW
Daily monitoring: Automated dashboard tracking rejection rate by trust dimension
Weekly review: Security team reviews all jailbreaking attempts and prompt injection flags
Monthly review: AI Governance Lead reviews threshold effectiveness, adjusts if rejection rate exceeds [10%] or falls below [0.5%]
Quarterly [root cause analysis](/glossary/root-cause-analysis): For each trust dimension with >50 rejections/month, conduct analysis to identify:
- Common prompt patterns triggering rejection
- Whether rejections indicate user intent or model sensitivity
- Recommended threshold or [model recalibration](/glossary/model-recalibration)
6. INCIDENT ESCALATION
If guardrails detect:
- >10 jailbreaking attempts from single user/session: Escalate to Security Operations
- Faithfulness score trending downward over 7 days: Escalate to Model Risk team for model recalibration assessment
- Any safety violation in regulated context (e.g., financial advice, medical information): Escalate to Compliance Officer within 24 hours
7. DOCUMENTATION AND AUDIT TRAIL
All moderation decisions (accept/reject) will be logged with:
- Timestamp
- Trust dimension scores
- Threshold applied
- Accept/reject decision
- Prompt and response content (if permissible under data retention policy)
Retention period: [12 months minimum, 36 months for regulated applications]
Audit access: [Compliance Officer, Internal Audit, External Auditors upon request]
How to Customize It
Step 1: Set thresholds based on risk appetite, not vendor defaults.
Don't accept 0.7 as a universal faithfulness threshold just because it sounds reasonable. Run a calibration exercise: take 200 representative prompts from your application, score them, and review the responses that fall between 0.6 and 0.8. If you're building a customer support bot where "I'm not sure" is acceptable, you might tolerate 0.6. If you're building a medical information assistant, you might require 0.85.
Step 2: Align deployment architecture with your data classification.
If your LLM processes personal data under GDPR, deploying guardrails in a VPC or air-gapped environment isn't optional, it's a data minimization and purpose limitation requirement. If you're handling public information, cloud deployment might be sufficient. Match your architecture to your Data Protection Impact Assessment.
Step 3: Define ownership with job titles, not roles.
"AI Governance Lead" is better than "responsible party." "Security Architect" is better than "technical owner." When an incident happens at 2am, your on-call engineer needs to know exactly who approves a threshold change.
Step 4: Customize trust dimensions to your application's risk profile.
If you're deploying an internal HR chatbot, "sexual content" and "harassing content" are critical dimensions. If you're deploying a financial research assistant, "unethical content" and "faithfulness" matter more. Don't score dimensions you don't care about, it creates noise and slows down your moderation pipeline.
Step 5: Set monitoring cadences based on volume, not calendar convenience.
If you're processing over 5 million requests per day, daily monitoring isn't sufficient, you need hourly dashboards. If you're processing 500 requests per week, monthly review is fine. Scale your oversight to your risk exposure.
Validation Steps
Before you put this policy into production:
1. Run a dry-run test with historical data. Take 1,000 recent prompts and responses from your application. Score them against your proposed thresholds. Calculate your rejection rate. If it's above 15%, your thresholds are too strict. If it's below 0.1%, your thresholds are too permissive or your trust dimensions don't match your actual risks.
2. Verify latency under realistic load. If your policy requires <100ms scoring latency, test it under peak traffic conditions. A guardrail that works in staging but adds 500ms latency in production will get disabled by your engineering team within a week.
3. Confirm your logging captures what auditors will ask for. Run a mock audit. Ask your Compliance Officer: "Show me all instances where we rejected a response due to faithfulness concerns in the last 30 days." If you can't produce that report in under 10 minutes, your logging isn't sufficient.
4. Test your escalation paths. Simulate a jailbreaking attempt. Does your Security Operations team actually receive the alert? Do they know what to do with it? If your policy says "escalate within 24 hours" but nobody's monitoring the escalation queue, you've written a policy that creates liability instead of reducing it.
5. Document your threshold rationale. If a regulator asks why you set faithfulness at 0.7 instead of 0.8, you need a better answer than "it seemed reasonable." Document your calibration process, your sample size, and your risk trade-offs. That documentation belongs in your Technical Documentation (Annex IV) if you're subject to the EU AI Act, and in your model validation evidence if you're under SR 11-7.
This policy template won't prevent every LLM failure. But it will give you a documented, auditable process for catching the failures that matter most before your users do.
