AI production readiness checklist: what to prove before go-live.

Ownership and the number it must move.

Every item in this checklist belongs to somebody before the review is scheduled. The first evidence line is the owner: a named person with time budgeted for upkeep. A technically clean workflow that belongs to nobody has nobody to answer for it in six months. The pilot's champion can be the owner, as a decision with time attached.

The second line is the number: the metric the workflow must move, the baseline measured before the build, and the condition under which it gets switched off. The steps from working demo to that point are in moving AI from pilot to production; if several candidates compete for the slot, score them with an AI workflow audit and bring the winner.

Evaluation evidence.

The core artifact is a test set built from real inputs: requests the workflow actually received during the pilot, malformed and hostile ones included, each paired with the output a reviewer would accept. Against that set, agree thresholds per error type: how many outputs may be substantively wrong, how many cosmetically wrong, how many refused. One accuracy number hides the failures a review board cares about.

The second artifact is the regression rule: the test set is re-run and recorded before any model or prompt change reaches production. The precedent is Google's 2017 paper The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction, which presents 28 specific tests and monitoring needs for production ML systems. You will not need all 28; you need the ones your reviewers ask about, with results attached.

Data, access and logs.

Bring a one-page inventory: the data classes the workflow touches (public, internal, confidential, regulated), the systems it reads and writes, and the service accounts it runs under. What reviewers want is scope: each account limited to what the workflow needs, and who approved the access. A workflow running on a personal account or an admin key fails this item.

Logs are the second half: where prompts, outputs and audit events are stored, who can read them, how long they are kept. Defaults deserve a check as of November 2026: model invocation logging on Amazon Bedrock is disabled by default, and when enabled it writes to a destination in the same account and Region. The reviewer's question: if the workflow produced something wrong in March, can you show what it was asked and what it answered?

Security review against the OWASP Top 10 for LLM applications.

The list to review against is OWASP's Top 10 for LLM Applications, 2025 revision. Five of the ten land directly on a workflow going live:

• LLM01, prompt injection. Inputs that alter the model's behavior, direct or through retrieved content. Evidence: what happens to untrusted text, and what an injected instruction can reach.
• LLM02, sensitive information disclosure. The model repeating data it should not. Evidence: the data classes in scope, and tests of what outputs contain.
• LLM05, improper output handling. Treating output as safe because the model produced it. Evidence: where outputs land, and the validation before anything executes or stores them.
• LLM06, excessive agency. Permissions and tool access beyond what the workflow needs. Evidence: the permission list, and the blast radius of a wrong action.
• LLM10, unbounded consumption. Runaway usage, accidental or induced. Evidence: rate limits, spend caps, and what happens when they are hit.

Failure path, human review and incidents.

Three questions define this item: what happens when an output is wrong, what happens when the service is down, and who finds out. The evidence is a written fallback (what people do while it is unavailable or untrusted), a notification list with names, and a review level set by the cost of an error: what ships unreviewed, what a human checks first, what always goes to a person.

Add the incident runbook: the first three steps when the workflow misbehaves in production, who takes them, and where the off switch is. Getting reviewers to apply the review level after go-live is a change problem; we covered it in AI change management for large teams.

Model version, retirement and quotas.

Pin the exact model version and its retirement date. As of November 2026, under Microsoft Foundry's standard lifecycle a generally available model has its retirement date set at launch, 18 months out; at 12 months it closes to new customers; at 18 months inference returns 410 Gone. Standard, Global Standard and Data Zone Standard deployments upgrade to the replacement automatically, region by region; Provisioned deployments do not, and their owners migrate manually. Generally available models from Anthropic, DeepSeek, Fireworks and Mistral AI on Foundry follow a 12-month lifecycle instead.

As of November 2026, Amazon Bedrock models launched on or after 7 September 2026 move through Active, Legacy and End-of-Life, with a Legacy notice period of six months for most models and 45 days for some; after End-of-Life, requests fail and migration does not happen automatically. Anthropic gives at least 60 days' notice before retiring a publicly released model on platforms it operates; Bedrock and the Google-managed offering on Google Cloud set their own dates. Write the retirement date next to the version pin, and re-run the test set before any swap, automatic or manual.

The last line is cost: cost per run against expected volume, quota and rate limits, a spend alert someone owns, and weekly sampled outputs checked against the thresholds. Write down what happens at ten times the volume.

The AI production readiness checklist in one table.

One row per item from the sections above. The signature split is our recommendation; adapt it to your org chart.

Do it yourself, or bring us in.

For one high-stakes workflow, doing this internally is worth it: you know your reviewers, and the evidence pack doubles as the workflow's documentation. Outside help fits when review prep keeps losing to roadmap work, or when the pilot's champion is too close to write down what it cannot do.

Our embedded engineers take a pilot through these items with your team: test set and thresholds, access scopes, the five OWASP risks, the pinned version and its retirement date. Your team pairs on the work, so it can run and extend what we built when we leave.

Frequently asked questions.

Keep reading.