Shipping a model behind a real feature is still production software. These are the controls I check, grouped the way I think about them, drawn from Shipping an LLM feature without it going sideways, Prompt injection is just untrusted input, and Evals before vibes.

Reliability

  • Every model call has a timeout — A hung or slow provider shouldn't hang your request. Bound every call and fail fast.
  • There is a fallback when the model call fails — A cached answer, a simpler path, or an honest message beats a 500 on a bad upstream day.
  • A kill switch can disable the AI feature without a deploy — When it goes sideways you want an off switch in seconds, not a release cycle.
  • Retries are bounded and safe to repeat — Unbounded retries turn one slow call into a cost and outage multiplier.
  • Per-user or per-tenant rate limits protect the feature — One abusive caller shouldn't exhaust the budget or the provider quota for everyone.
  • Long answers stream so the first token arrives fast — Perceived speed stops the impatient retries that quietly double your spend.

Safety & injection

  • Retrieved and user content is treated as untrusted input, never as instructions — Everything in the context window is hostile until proven otherwise. That is the whole threat model.
  • Model output is validated before anything uses it — Constrain to a schema or an allow-list at the boundary; never trust the shape of a generation.
  • Model output never reaches a dangerous sink unchecked — SQL, shell, eval, file paths, and outbound fetches built from model text are injection waiting to happen.
  • Retrieved context is clearly separated from instructions — Make it structurally obvious which tokens are data and which are commands.
  • Low-confidence retrieval is handled with an honest 'I don't know' — An answer with no real source behind it is the failure mode that loses trust.
  • Sensitive data is kept out of prompts and logs where it doesn't belong — The prompt and the trace are both places regulated data leaks by accident.

Evals & quality

  • There is an eval set, not just vibes, for the feature — A prompt change that looks better in one demo can be worse across a hundred real questions.
  • Prompt and model changes run against the eval set before shipping — Catch the regression before users do, not after.
  • Cost per request is measured (tokens in and out, cached, model, path) — Cost per request, bucketed by feature, points straight at the expensive offender.
  • Production answers are monitored or sampled for quality — Quality drifts. Watch a sample so you find out before your users tell you.
  • Answers cite their sources where it matters — Citations let a user verify, and let you debug a wrong answer back to its source.

What makes an LLM feature production-ready?

Beyond a good prompt: a timeout and a fallback on every model call, a kill switch, output validation before anything uses the result, an eval set instead of vibes, and cost-per-request measurement.

How do you prevent prompt injection?

Treat all retrieved and user content as untrusted input, never as instructions; separate context from commands; and validate model output before it reaches any sink like SQL, a shell, eval, or an outbound fetch. Prompt injection is an old appsec problem, not a new one.

What should you check before shipping an LLM feature?

Reliability (timeouts, fallback, kill switch, bounded retries), safety (untrusted input, output validation, grounding), and quality (an eval set, regression runs, cost and quality monitoring). This checklist scores all three.

What is an LLM kill switch?

A configuration flag that disables the AI feature instantly, without a deploy, so when an answer goes wrong or a provider degrades you can turn it off in seconds and fall back to a safe path.