Free resource · 42 checks · No email required
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.
01 · 6 checks
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.
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.
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.
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.
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.
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.
Deciding the threshold after seeing the number is how every result becomes acceptable.
02 · 6 checks
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.
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.
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.
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.
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.
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.
A request that hangs holds a connection, a worker, and a user's attention. Failing at a known point is strictly better.
03 · 5 checks
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.
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.
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.
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.
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.
Hitting a limit and retrying immediately extends the outage you are trying to recover from.
04 · 6 checks
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.
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.
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.
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.
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.
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.
Ten minutes of adversarial prompting finds more than a week of speculation, and gives you regression cases.
05 · 6 checks
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.
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.
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.
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.
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.
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.
EU-only requirements are common in European work and are far cheaper to satisfy before launch than after.
06 · 5 checks
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.
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.
A log you cannot query during an incident is storage, not observability.
Cost is attributable to a feature, and ideally to a tenant.
A single total tells you the bill went up. Attribution tells you what to fix.
You alert on quality proxies, not only on errors.
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.
An observability layer that quietly becomes your largest store of personal data is its own compliance problem.
07 · 4 checks
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.
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.
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.
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.
Required in several regimes, and the thing users are angriest about when it is missing.
08 · 4 checks
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.
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.
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.
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.
If the answer is no, the real risk is not technical. It is that the only person who can fix it is on holiday.
Smaller than a call
Stuck on one of these?
Reply to one item rather than booking a call. Tell me which check you are least sure about and I will tell you what I would do, in writing, at no cost. I answer these myself.
Opens your mail client with the subject filled in. Nothing is stored on this site.
If it would be faster to have this built than checked: AI Integration · all resources