# AI Feature Production Readiness Checklist The 42 checks an LLM feature should pass before it goes in front of users: evaluation, failure modes, cost, injection defence, EU AI Act transparency, observability, human oversight, and a kill switch. 42 checks across 8 sections. By Ergini, senior software and AI developer. https://ergini.com Full version, kept up to date: https://ergini.com/resources/ai-production-readiness-checklist Questions about any item are welcome at ergin@ergini.com. --- ## 1. Evaluation You cannot tell whether a change improved the system without this, and almost every team ships without it. If you do one section, do this one. - [ ] You have at least 50 labelled examples of the task, taken from real usage rather than invented. Why: Fifty is roughly where a regression becomes visible above the noise. Invented examples encode what you expect users to do, not what they do. - [ ] The eval runs on demand in under ten minutes and someone can run it without asking you how. Why: An eval that takes an afternoon or lives in one person's notebook stops being run, usually right when the pressure to ship is highest. - [ ] You know the current pass rate as a number, and it is written down somewhere other than a Slack message. Why: Without a recorded baseline, every future change is judged on vibes and the direction of travel is unknowable. - [ ] The eval includes the cases you already know are hard, not only the happy path. Why: An eval built from easy cases reports high numbers and predicts nothing. The hard cases are the entire signal. - [ ] Prompt and model version are recorded with each eval run. Why: Otherwise a score change cannot be attributed, and provider-side model updates look like your regression. - [ ] You have decided what pass rate is good enough to ship, before looking at the result. Why: Deciding the threshold after seeing the number is how every result becomes acceptable. ## 2. Failure modes and degradation Language models fail differently from the code around them: confidently, plausibly, and without raising anything. Every item here is about making failure visible or survivable. - [ ] An upstream timeout or 5xx produces a degraded but useful response, not a stack trace. Why: Provider outages happen. The user-facing question is whether your product becomes slower or becomes broken. - [ ] Empty or missing context is treated as an error state, not as an empty string passed to the model. Why: This is the single most common silent failure in retrieval systems: the model gets nothing, invents an answer, and looks confident doing it. - [ ] Retries are bounded and idempotent. Why: An unbounded retry loop on a paid API is a cost incident. A non-idempotent retry on a write is a data incident. - [ ] Output is validated against a schema before anything downstream consumes it. Why: Strict structured outputs make this cheap. Validating anyway means a provider change cannot corrupt your data layer. - [ ] You have a defined behaviour for a refusal, and it is not a crash. Why: Refusals arrive in a separate field on some providers and as ordinary text on others. Either way, parsing a refusal as a result throws. - [ ] Latency has a ceiling, and exceeding it fails rather than hanging. Why: A request that hangs holds a connection, a worker, and a user's attention. Failing at a known point is strictly better. ## 3. Cost and rate limits Cost problems in LLM features are almost always architecture problems wearing a billing disguise. These five catch the common ones before the invoice does. - [ ] You know the cost per request, to an order of magnitude. Why: Without it you cannot tell whether a feature is viable at ten times the traffic, which is the only number that matters. - [ ] You have a per-user or per-tenant cap, and hitting it degrades rather than bills. Why: One enthusiastic user or one loop in a client can generate a month of budget in an afternoon. - [ ] The model is invoked on genuine ambiguity, not on every event that could trigger it. Why: Calling a model on every webhook or keystroke is the most common source of a bill that looks inexplicable. - [ ] Prompt caching is in use where the provider supports it and the prefix is stable. Why: Long stable system prompts are exactly the case caching was built for, and the saving is usually large and free. - [ ] Rate-limit responses are handled with backoff, not with a retry storm. Why: Hitting a limit and retrying immediately extends the outage you are trying to recover from. ## 4. Prompt injection and data boundaries If your model reads anything a user or a third party can influence, that text is untrusted input. Treat it the way you would treat a form field, not the way you would treat your own prompt. - [ ] Retrieved documents and user text are clearly delimited from instructions in the prompt. Why: Not a defence on its own, but the precondition for every other one. Concatenating untrusted text into instructions removes the boundary entirely. - [ ] The model has no tool that can exfiltrate data to an arbitrary destination. Why: A tool that fetches a URL, sends an email, or posts to a webhook turns any successful injection into a data breach. - [ ] Tool permissions are scoped to the acting user, enforced server-side. Why: If the model decides what it is allowed to touch, an injection decides too. Authorisation belongs outside the model. - [ ] Anything irreversible routes through a human approval or a confirmation step. Why: The cheapest injection defence available: the attack has to get past a person as well as a prompt. - [ ] Model output rendered in a browser is escaped, including any markdown or HTML it produces. Why: Generated output is untrusted output. Rendering it raw reintroduces cross-site scripting through a novel door. - [ ] You have tried to break it yourself, with the obvious payloads, and written down what happened. Why: Ten minutes of adversarial prompting finds more than a week of speculation, and gives you regression cases. ## 5. Privacy and EU AI Act transparency Two regimes, largely overlapping engineering. Article 50 of the EU AI Act has been enforceable since 2 August 2026 and applies to ordinary products, not only high-risk ones. - [ ] Users are told they are interacting with an AI system, clearly and at first interaction. Why: Article 50(1). No grace period, and giving a bot a human first name converts an easy item into a clear breach. - [ ] Synthetic media you generate carries a machine-readable provenance mark, not only a visible caption. Why: Article 50(2). A caption rendered in your interface is not machine-readable and does not survive a download. - [ ] Content that appreciably resembles a real person is disclosed as AI-generated. Why: Article 50(4) deepfake disclosure, and it applies regardless of commercial intent. There is no advertising exemption. - [ ] You know which personal data reaches the model, and you can name the lawful basis. Why: GDPR. Prompts and retrieved context are processing, and a system that cannot answer this cannot pass a security review. - [ ] A deletion request reaches everything, including the vector store and any logs. Why: The path people forget is the embedding index. Deleting the source row and leaving the vector is not deletion. - [ ] Data residency is a deliberate decision, not whatever the default region was. Why: EU-only requirements are common in European work and are far cheaper to satisfy before launch than after. ## 6. Observability The same logging serves debugging, evaluation, security review, customer disputes and regulatory questions. It is the highest-leverage thing on this list after evals. - [ ] Every model call is logged with its inputs, output, model version, latency and token counts. Why: This one record answers most future questions. Reconstructing it after an incident is not possible. - [ ] Logs are queryable by user, by request and by time. Why: A log you cannot query during an incident is storage, not observability. - [ ] Cost is attributable to a feature, and ideally to a tenant. Why: A single total tells you the bill went up. Attribution tells you what to fix. - [ ] You alert on quality proxies, not only on errors. Why: The characteristic LLM failure returns a 200. Refusal rate, empty-context rate and validation-failure rate are the signals that move first. - [ ] Logging respects the privacy decisions above, with sensitive fields redacted. Why: An observability layer that quietly becomes your largest store of personal data is its own compliance problem. ## 7. Human oversight Not a compliance box. The presence and shape of a human gate is usually what separates a system people trust from one they turn off. - [ ] Anything irreversible, financial, or externally visible is approved by a person before it happens. Why: This removes the entire category of catastrophic failure for the cost of about a second of user effort. - [ ] The approver sees enough context to actually judge, not just an accept button. Why: A gate that cannot be evaluated is rubber-stamped, which is worse than no gate because it manufactures false assurance. - [ ] Overrides and rejections are logged. Why: Rejections are your best free training and eval data, and the record is what lets you loosen the gate on evidence later. - [ ] There is a documented route for a user to reach a human. Why: Required in several regimes, and the thing users are angriest about when it is missing. ## 8. Operational readiness The last four. Each one is the difference between a bad afternoon and a bad quarter. - [ ] There is a feature flag that disables the AI feature without a deploy. Why: The kill switch. When something goes wrong you want to stop it in seconds, not in a release cycle. - [ ] Prompts are versioned in the repository, not edited in a vendor console. Why: A prompt is code. Unversioned prompts cannot be reviewed, rolled back, or attributed to a change in behaviour. - [ ] You can roll back to the previous model and prompt together. Why: Providers deprecate and update models. Pinning a version and being able to return to it keeps that from being an outage. - [ ] Someone other than the author can explain how the feature works and where it fails. Why: If the answer is no, the real risk is not technical. It is that the only person who can fix it is on holiday. --- Written by Ergini. Free to use, share, and adapt inside your own team. If it would be faster to have this built rather than checked: https://ergini.com/services/ai-integration