LLM guardrails for real product features

Decide what “wrong” means for this feature

Guardrails are only as good as your definition of failure. Before writing any, list the failures that would actually hurt for this feature, ranked by cost:

• Factual errors – an invented refund policy, a wrong API parameter, a citation that doesn’t say what’s claimed.
• Format errors – malformed JSON, missing fields, a value outside the allowed set, breaking the code downstream.
• Policy violations – legal or medical advice, commitments the business can’t keep, off-brand tone, competitor mentions.
• Data leaks – personal data in output or logs, another tenant’s data, the system prompt.
• Unsafe actions – a tool call with consequences the user didn’t intend.

Each failure gets a specific control and a test case in your eval set. “Make the AI safe” is not a requirement anyone can implement.

Input guardrails

• Validate and bound inputs like any user input: length limits, file type and size checks, character set normalization. Overlong inputs are a cost attack as well as a quality problem.
• Detect and redact sensitive data before it reaches a third-party model if your data agreements require it – card numbers, national IDs, credentials. Pattern-based detection catches most structured identifiers cheaply.
• Classify intent and scope. A cheap, fast classification call (or a small model) can route out-of-scope requests to a canned response before the expensive call happens.
• Mark untrusted content clearly in the prompt – retrieved documents, emails, web pages – and never give it the authority of the system prompt. This reduces prompt injection; it doesn’t stop it, which is why the permissions model in AI agent security matters.

Structured outputs: the highest-value guardrail

If the output feeds code, don’t parse prose. Use your provider’s structured output or tool-calling mode with a JSON Schema, and where the provider supports schema-constrained decoding, turn it on. The model then can’t return a field you didn’t define or a value outside an enum.

Then validate anyway. Run the result through a schema validator (Pydantic, Zod, JSON Schema) and add the business rules a schema can’t express: dates in the future, totals that add up, IDs that exist in your database, a discount that doesn’t exceed policy. On failure, retry once with the validation error included in the prompt; if it fails again, fall back to a safe default or a human.

Design schemas that make honesty easy. Include fields like confidence, needs_human_review, or an explicit “unknown” value, so the model has a valid way to say it doesn’t know instead of inventing something to fill a required field.

AI hallucination prevention: grounding and citations

You can’t stop a model from generating unsupported text, but you can make unsupported text detectable and rarer:

1. Retrieve before generating. Answer from your documents, not the model’s memory. See RAG architecture for how to get retrieval right – most hallucinations in RAG systems are retrieval failures.
2. Instruct and allow abstention. Tell the model to answer only from the provided sources and give it a clear way to say the sources don’t cover the question.
3. Require citations to specific source chunks, returned as structured IDs rather than free text.
4. Verify citations in code. Check that every cited ID was actually in the context. Drop or flag answers that cite nothing.
5. Check support for high-stakes claims. A second, cheaper model call can check whether each claim is entailed by its cited passage. It costs latency, so reserve it for answers where a wrong claim is expensive.
6. Pull exact values from systems of record. Prices, balances, dates and order states should come from a tool call or a template, not from generated text.

Output guardrails beyond format

• Policy checks for things the model must never say: commitments on refunds or timelines, regulated advice, competitor comparisons. Keyword rules catch the obvious cases; a classifier catches paraphrases.
• PII and secrets scanning on output, so the model doesn’t echo a credential or another user’s data that slipped into context.
• Link and domain allow-lists for any URL in output, both to stop phishing-style responses and to close a data-exfiltration channel.
• Moderation for user-generated content features, using your provider’s moderation endpoint or an equivalent classifier.
• Tool-call validation: treat a model’s request to call a tool exactly like an API request from an untrusted client – authorize, validate and rate-limit it.

Handling refusals and fallbacks

Refusals are a guardrail working, and also a UX problem. Over-refusal – the model declining reasonable requests – quietly kills feature adoption. Under-refusal is the incident.

Treat refusals as an explicit output state. Detect them (a schema field works better than string-matching “I can’t”), and give the product a defined path: a helpful message, a link to documentation, or a handoff to a person. Track the refusal rate per intent; a sudden jump after a model or prompt change is a regression, and a refusal on a request your policy allows is a bug to add to the eval set.

Every model call also needs a fallback for plain failures: timeouts, rate limits, provider outages. Decide in advance whether the feature degrades to a simpler model, a cached answer, a non-AI path, or a clear error.

Monitoring in production

Guardrails you can’t see firing aren’t guardrails. Log, per request: inputs (redacted as needed), retrieved sources, output, validation results, which guardrails triggered, latency, token usage and the user’s feedback.

Then watch a small set of rates over time: schema failures, retries, refusals, guardrail triggers, abstentions, escalations, and thumbs-down. Sample conversations weekly and have someone who knows the domain read them. The failures you find go into your LLM evaluation suite so they can’t silently return.

A minimal guardrail stack to ship with

• Input length and type limits; sensitive-data redaction where required.
• Structured output with schema validation plus business-rule checks, one retry, then fallback.
• Retrieval-grounded answers with verified citations and an explicit “not covered” path.
• Allow-listed links and tool arguments; every tool call authorized as the acting user.
• Refusal and error states designed into the UI.
• Logging of guardrail outcomes, and a weekly review that feeds the eval set.

That stack covers most product features without any third-party guardrail framework. Add one when you have a specific gap it closes. If you’d like help putting this into an existing product, it’s a core part of how I approach AI integration.

Related

• AI integration services for products already in production
• LLM evaluation for product features
• RAG architecture for production systems
• AI agent security: a practical threat model
• AI for customer support that actually resolves tickets
• RAG development services, measured on retrieval quality