AI pilot to production readiness checklist

The short answer

An AI pilot is ready for production when the organization can answer four questions with evidence:

1. Does it create a measurable business outcome?
2. Does it behave acceptably on representative and adversarial cases?
3. Can it operate inside the real data, security, and integration boundary?
4. Can named people monitor, support, and stop it?

A polished demo is not one of the gates.

Use the checklist below as a go-live review for a generative AI feature, agent, retrieval workflow, copilot, document processor, or decision-support system. The exact controls will vary by use case and industry, but every production deployment needs an explicit answer in each area.

Gate 1: One workflow and one accountable owner

Write the production scope as an operational outcome:

Reduce first-pass contract review time for the commercial legal team while preserving attorney approval for every external response.

That is better than “deploy a legal AI assistant.” It identifies the user, task, expected improvement, and human authority.

The workflow needs a business owner who can accept or reject operational risk. The engineering team can own implementation; it should not quietly inherit the decision about whether a result is safe enough for legal, clinical, financial, or customer-facing use.

Evidence required: named owner, in-scope users, in-scope task, excluded tasks, baseline, target, and stop criteria.

Gate 2: A representative evaluation set

Do not approve the system from a handful of friendly prompts.

Build a versioned evaluation set from real work:

• common cases;
• rare but expensive cases;
• ambiguous inputs;
• incomplete or contradictory data;
• policy-sensitive requests;
• prompt-injection attempts;
• tool and dependency failures;
• examples where abstention is correct.

Score the final task outcome, not only the model response. An agent that chooses the right tool but writes the wrong customer record has failed.

Define acceptable thresholds before the final test. Otherwise, teams move the line after seeing the result.

Evidence required: versioned dataset, scoring rubric, baseline, pass thresholds, failure analysis, and sign-off.

Gate 3: Production data access and lineage

Pilots often run on a clean export. Production runs on missing fields, duplicate records, stale documents, permission boundaries, and undocumented business rules.

Map every source:

• system of record;
• data owner;
• update frequency;
• access control;
• retention rule;
• transformation or chunking logic;
• deletion and revocation behavior;
• evidence returned to the user.

If the system uses retrieval, test whether a user can retrieve a document they could not open in the original system. If access is filtered after retrieval, the boundary is already too late.

Evidence required: data-flow diagram, source inventory, permission tests, freshness checks, and deletion test.

Gate 4: Constrained actions and human approval

List everything the AI can read and change.

For each write action, define:

• allowed caller;
• allowed fields and values;
• validation;
• idempotency key;
• approval requirement;
• audit event;
• rollback path.

Use narrow verbs such as create_refund_draft instead of broad tools such as call_api. Put irreversible, financial, externally visible, or privilege-sensitive actions behind a review queue until evidence justifies a different policy.

Evidence required: tool inventory, permission matrix, approval policy, duplicate test, and rollback test.

Gate 5: Threat model and privacy review

The threat model must cover more than the model provider.

Review:

• untrusted documents and prompt injection;
• secrets in prompts, logs, traces, and tool responses;
• cross-tenant retrieval;
• excessive tool permissions;
• dependency and MCP server risk;
• data residency and retention;
• output disclosure;
• abuse and denial-of-service paths;
• model or prompt supply-chain changes.

The NIST AI Risk Management Framework is voluntary and use-case agnostic, but its Govern, Map, Measure, and Manage structure is a useful way to ensure risk ownership continues through deployment and operation.

Evidence required: threat model, privacy review, security tests, approved residual risks, and incident contacts.

Gate 6: Real integration behavior

Test the system against production-like latency, permissions, quotas, schemas, and failure modes.

Ask:

• What happens when retrieval is slow?
• What happens when the CRM rejects a write?
• What happens when the model times out after an action completes?
• Can a retry create a duplicate?
• Does the UI distinguish a draft from a completed action?
• Can users see which source or record supported the result?

A prototype often assumes every dependency succeeds. A production workflow must make partial failure visible and recoverable.

Evidence required: integration tests, timeout policy, retry policy, idempotency tests, and user-facing failure states.

Gate 7: Capacity, latency, and cost envelopes

Define expected and peak load. Measure end-to-end latency at the percentiles users will experience, not only an average model call.

Calculate cost per completed business task, including retrieval, model calls, retries, evaluations, observability, storage, and human review. A lower model price does not help if failure recovery doubles the number of calls.

Set budgets and rate limits before launch. Decide what the system should do when a limit is reached: queue work, fall back to a smaller model, reduce optional enrichment, or stop.

Evidence required: load test, latency target, peak-capacity plan, unit economics, spend alert, and degradation policy.

Gate 8: Observability tied to outcomes

Infrastructure health is necessary but not sufficient.

Monitor three layers:

1. System: availability, latency, errors, queue depth, and dependency failures.
2. AI quality: evaluation score, groundedness, tool success, abstention, and policy violations.
3. Business outcome: time saved, resolution, conversion, rework, adoption, or another metric from the original scope.

Log enough context to investigate failure without creating a new privacy problem. Sample and redact deliberately.

NIST's AI RMF Core calls for monitoring AI behavior in production and clearly assigned review responsibilities. That makes monitoring an operating model, not just a dashboard.

Evidence required: dashboards, alert thresholds, on-call owner, investigation fields, and scheduled quality review.

Gate 9: User experience for uncertainty

Users need to understand what the system did, what it did not do, and what requires their decision.

Design for:

• citations or source evidence;
• editable drafts;
• clear approval states;
• uncertainty and missing-data messages;
• escalation;
• correction and feedback;
• visibility into completed actions.

Do not use a confident paragraph to hide an incomplete result. The right interface may be a structured form, review queue, or workflow panel rather than a chat window.

Evidence required: usability test with target users, approval comprehension, failure-state review, and accessibility check.

Gate 10: Release, rollback, and change control

Put the workflow behind a feature flag. Start with a bounded group and an explicit traffic ramp.

Version prompts, tools, retrieval configuration, policies, and evaluation sets. A model change is a release even when no application code changed.

Rollback must disable actions as well as the interface. If a worker or scheduled job continues running after the UI is switched off, the rollback is incomplete.

Evidence required: release plan, feature flag, canary group, rollback test, migration plan, and change log.

Gate 11: Runbook and incident response

The runbook should answer what an operator does when:

• quality drops;
• the model or provider is unavailable;
• a tool creates the wrong record;
• data access is broader than expected;
• costs spike;
• users report harmful or sensitive output;
• a new prompt-injection pattern appears.

Include severity, owner, containment, communication, recovery, and post-incident review. Run at least one tabletop exercise before broad release.

Evidence required: runbook, incident roles, kill switch, recovery procedure, and tabletop result.

Gate 12: Ownership after the project team leaves

Production needs durable ownership across product, engineering, security, data, and operations.

Define who:

• approves future model changes;
• maintains evaluation data;
• reviews quality and risk;
• updates integrations;
• pays and monitors the bill;
• trains users;
• decides when to retire the workflow.

The handoff should include code, architecture, evaluation results, deployment configuration, dashboards, runbook, known limitations, and a prioritized backlog.

Evidence required: responsibility matrix, trained operators, repository access, documentation, and accepted handoff.

A simple go-live decision

Mark each gate:

• Ready: evidence exists and the accountable owner accepts it.
• Conditional: a bounded launch is acceptable with a named action and deadline.
• Not ready: the missing control can create unacceptable operational or user risk.

One “not ready” in data permissions, irreversible actions, incident containment, or legal obligations should normally stop launch. A conditional item should never mean “we will remember after release.” Put it in the launch plan with an owner.

Production is an operating capability

The point of this checklist is not to turn every AI workflow into a year-long governance program. It is to expose the work a demo temporarily hides.

A focused production team can move quickly because it handles ownership, evaluation, integration, monitoring, and recovery together. That is the role of a forward deployed engineer: work inside the real environment, ship one bounded outcome, and leave the client with the code and operating system required to keep it running.

FDE's production workflow build takes one workflow from scope to live operation with an eval harness, review queue, observability, and runbook in six weeks.

Sources

• NIST AI Risk Management Framework
• NIST AI RMF Playbook
• NIST AI RMF Core