The AI production readiness review: 12 questions I ask before launch

At 9:17 on a Tuesday morning, Priya had one hand on her coffee and the other on the laptop trackpad. Her support agent had answered 48 test questions correctly. Then a customer asked about a refund, and the agent invented a policy that did not exist.

That is the moment an AI production readiness review earns its place. Before launch, I want clear answers about failure behavior, data, cost, security, monitoring, and human recovery. A polished demo is not a production AI system until someone can explain what happens when the model is wrong.

I've shipped enough software to know that launch pressure makes smart teams skip boring questions. I've also built two live multi-model AI platforms, and every production review has reminded me of the same thing: reliability is not a final inspection. It is the load-bearing structure.

The first four questions test the promise

A product can fail before the model makes a single mistake. It can fail because the team never defined what a good answer means, who owns the decision, or when the system should stop.

Here's the part most people miss. The conventional advice is to launch a small MVP and learn from users. That works for a signup flow with a broken button. It is weaker advice for an AI system that can produce confident, plausible output at scale. You may learn from users, but your users may pay the price for your unfinished assumptions.

1. What exact job is the system doing?

Write the job in one sentence that names the input, the output, and the user decision it supports.

"Help a support agent find the correct refund policy from approved documents" is testable. "Improve customer support with AI" is not. The first sentence gives you a boundary. The second gives you a conference slide.

If the system creates marketing drafts, decide whether it is generating ideas, producing publishable copy, or preparing a draft for human review. Those are different products with different risk profiles.

2. What does failure look like?

List the failures you would rather see than a confident wrong answer.

• The system says it does not know.
• The system routes the request to a person.
• The system asks for missing information.
• The system refuses an unsafe or unsupported action.

This is not pessimism. It is product definition. In a live support bot, a clean handoff is often better than an invented refund rule. In an agent that updates a database, a blocked action is better than a plausible but destructive write.

3. Who is allowed to trust the output?

A draft for an internal employee is not the same as a decision delivered directly to a customer. An internal research assistant can surface uncertainty in ways that a checkout assistant cannot.

Map every output to a level of human review. I usually ask whether the user can inspect the source, edit the result, reject the action, and recover from a bad one. If the answer to all four is no, the launch bar should rise.

The NIST AI Risk Management Framework is useful here because it pushes teams to identify intended users, harms, oversight, and monitoring before deployment. You do not need a large governance program to apply the basic habit.

4. What evidence says the system is ready?

A few successful conversations are not evidence. Build a test set from real or carefully reconstructed cases, then record expected answers, acceptable alternatives, refusal cases, and escalation cases.

Call this the Eval Loop. It is a living test system that runs before release and after every meaningful change. Include ordinary questions, ambiguous questions, adversarial prompts, empty inputs, long inputs, and requests that require the system to admit it lacks information.

For every test, capture:

• The user input and relevant context.
• The expected behavior, not only expected wording.
• The model output and tool calls.
• A pass, fail, or needs-review result.

A model upgrade is not automatically an improvement. If you cannot compare the new version against the old one on the same cases, you are guessing.

The next four questions test the system around the model

The model is one component. Production behavior comes from the whole path around it: retrieval, tools, permissions, retries, queues, storage, and the person who receives the result.

What I keep seeing when I ship AI products is a team spending days on the system prompt while a timeout causes duplicate tool calls. The prompt gets polished. The invoice gets larger. The database gets messier.

5. What happens when the model is unavailable?

Test provider timeouts, rate limits, malformed responses, partial outages, and a provider returning a valid response with the wrong structure. OpenAI, Anthropic, and other providers publish status information, but your application still needs its own behavior when a request fails.

Define a fallback for each important path. That may be another model, a cached answer, a queue for later processing, or a plain human workflow. Do not route every failure to a more expensive model without limits. That is how a minor outage becomes a retry storm.

6. What happens when a tool call is wrong?

A tool call deserves more scrutiny than a paragraph of text. A wrong draft is inconvenient. A wrong deletion, payment, email, or database write can be expensive, and sometimes irreversible.

Use permissions that match the action. Separate read tools from write tools. Require confirmation for irreversible actions. Log the arguments, result, user, and authorization decision. OWASP's Top 10 for Large Language Model Applications places excessive agency among the risks teams need to control, and the warning is practical: never give an agent more authority than the job requires.

7. How much context can the system actually use?

A model may support a large context window, but that does not mean every available document belongs in every request. Long context raises cost, latency, and the chance that relevant information gets buried under noise.

Treat the Context Budget as a real product constraint. Decide how much space goes to system instructions, conversation history, retrieved material, tool results, and the final response. Then test what happens when each area grows.

For a retrieval system, inspect the evidence that reached the prompt, not only the final answer. A wrong answer may come from poor retrieval, stale content, conflicting documents, or a prompt that failed to label the source clearly.

8. Can you reconstruct what happened?

If a user reports a bad answer at 11:42 p.m. on a Saturday, can you see the model version, prompt version, retrieved documents, tool calls, latency, token counts, cost, and final response?

If not, you do not have a production system yet. You have a system that works when nobody asks questions.

Keep sensitive data out of logs where possible, and apply retention rules before launch. Still, retain enough structured information to reproduce a failure. A request ID that follows the call across your application, model provider, queue, and database is a small investment with a large payoff.

The final four questions test trust and operations

A launch is not a finish line. It is the point where strangers start creating inputs your test set did not anticipate. Your team needs a way to notice, understand, and respond without waiting for a dramatic incident.

This is where many teams feel genuinely stretched. You may be one founder, one product manager, or one engineer carrying a system that suddenly behaves like a small company. That pressure is real. The answer is not to pretend you can monitor everything. Choose the signals that tell you when the load-bearing parts are shifting.

9. What will you measure every day?

Choose a small operating dashboard before launch. Five useful signals beat a wall of charts nobody opens.

Track:

• Task success rate from the eval loop and sampled production reviews.
• Escalation and fallback rate.
• Median and high-percentile latency.
• Cost per completed task, including retries.
• Tool errors, safety blocks, and user corrections.

Separate model quality from system quality. A response may be correct while the experience is too slow. A fast answer may be useless because retrieval failed. Your dashboard should help you tell those two stories apart.

10. Who responds when the system fails?

Name the person or team responsible for each failure category. Someone owns provider outages. Someone owns bad content. Someone owns security reports. Someone owns the decision to pause a feature.

Write the first-response steps in plain language. If a customer-facing agent starts inventing policies, can you disable the risky path without taking down the whole product? Feature flags, kill switches, and read-only modes are not signs of weak confidence. They are how you reduce blast radius.

Run a short incident exercise before launch. Give the team a fabricated report like, "The agent sent 300 incorrect renewal notices." Then watch how long it takes to identify the affected requests, stop the action, and notify the right people. If that exercise surfaces confusion about who owns the call, you have your answer.

11. How are privacy and security handled?

Document what data enters the model, where it is stored, who can access it, and how long it stays available. Check provider retention settings and contractual terms. Review secrets, access tokens, customer identifiers, uploaded files, and tool permissions.

Run prompt injection tests against retrieved documents and user inputs. A malicious instruction inside a web page, email, or uploaded file should not gain authority over your system prompt or tools.

Do not call a generic content filter your security plan. Apply authorization outside the model. Validate tool parameters in code. Treat model output as untrusted input until your application checks it.

12. What will make you pause the launch?

Set stop conditions while everyone is still calm. Examples include an unacceptable rate of unsupported answers, a cost ceiling, a rise in high-risk tool calls, a provider dependency without fallback, or a failure to reproduce incidents.

This question matters because launch meetings reward optimism. A person who asks to pause can sound difficult, especially when sales or leadership has already made a public promise. A written stop condition turns a personal argument into an agreed operating rule.

Make the rule visible. If you cannot say what would stop the launch, you have not finished the review.

How I run the review with a real team

I do not schedule a four-hour meeting and read twelve questions aloud. That produces polite nods and very little evidence.

Instead, I ask the team to bring artifacts. Each owner gets a question and a short deadline. The group reviews the test set, failure logs, architecture diagram, permissions, cost estimate, runbook, and rollback plan. Missing evidence becomes a launch task, not a launch excuse.

A practical review packet contains:

• A one-page description of the user job and failure boundaries.
• A representative evaluation set with results from the current model.
• A diagram of model, retrieval, tools, storage, queues, and fallbacks.
• A cost and latency sample from realistic traffic.
• An incident runbook with a pause switch and named owners.

The review should leave you with decisions, not comments. Mark each question ready, blocked, or unknown. Unknown is a useful result. It tells you where the system is still a guess.

With an adaptive learning system like the one I built for Ziggyloo, the hardest cases are not always the spectacular ones. They are the quiet moments: a question phrased strangely, a parent expecting a clear explanation, a learner repeating a misconception. Production readiness means preparing for those ordinary failures too.

So the deeper lesson is simple: an AI product is ready when the team can explain its boundaries, observe its behavior, and recover when it crosses them. You do not need perfect answers before launch. You need honest ones.

FAQ

What is an AI production readiness review?

An AI production readiness review is a structured check of whether an AI feature can operate safely and reliably with real users. It covers the model, data, tools, permissions, cost, monitoring, human escalation, privacy, and recovery plans.

What belongs on an AI product launch checklist?

Your AI product launch checklist should include a defined user job, failure cases, evaluation results, fallback behavior, tool permissions, context limits, observability, cost tracking, privacy controls, incident ownership, and launch stop conditions.

How do I measure AI reliability after launch?

Measure task success, unsupported-answer rate, escalation rate, latency, tool errors, cost per completed task, and user corrections. Review sampled production interactions against the same eval loop used before launch.

Can a small team run an AI reliability checklist?

Yes. A small team can use the same questions with lighter documentation. Start with a representative test set, clear ownership, a pause switch, basic request tracing, and a weekly review of failures and cost.

Before you put the launch date on the calendar, ask someone who did not build the feature to walk through all twelve questions. Give them permission to find the loose bolt. That is not slowing you down. It is how you give the people who trust your product a safer place to land.

The model is not the product. The system around the model is what your users actually experience.