# Production Readiness Checklist for AI
Many organizations confuse two moments: the moment when an AI model or application works technically, and the moment when the solution is actually ready for production. The gap between these two moments determines whether AI becomes a real operating capability or another pilot that stalls after the first quality incident or cost spike.
This checklist is designed for go/no-go decisions. Its purpose is not to prove that a solution is perfect. It is to confirm that the organization understands the risks, has clear decision owners, and can sustain an AI service under growing volume and data variability.
In practice, production readiness is an operating discipline, not an end-of-project test. The best teams use an SRE-like approach: they define reliability requirements, set SLO/SLA targets, monitor degradation signals, and establish response procedures before the system enters a critical workflow.
How to use this checklist
This checklist is built as a shared tool for business, IT, data/ML, security, legal, and operations. For each item, the team should assign a status: met, partially met, not met, then decide on conditional or full launch.
The most important rule is simple: no owner means no readiness. If an item is important but has no clearly accountable person to maintain it after launch, the organization is taking on hidden operational risk.
It is also worth separating minimum requirements from target-state requirements. In an initial rollout, you may accept lower monitoring automation or a narrower use case scope, but only if there is a clear plan to reach target standards within a defined timeline.
Gate 1: business value and context
The first gate answers whether you are solving the right problem and whether the boundaries of expected outcomes are clear.
- Does the use case have a business owner with decision authority over priorities and scope? - Is there a defined process baseline: time, cost, quality, rework, volume, error level? - Are the breakeven threshold and stop conditions defined if value fails to materialize after launch? - Does the target process define exception handling and a clear point where a human takes control? - Have you identified user groups that require different quality controls or rollout paths?
Missing baselines are a common failure pattern. After launch, teams showcase activity and query volume but cannot prove whether process KPIs improved. Production readiness without value metrics creates investment disputes a few months later.
Gate 2: data and input quality
An AI system is only as stable as its data and knowledge sources.
- Are there clear data owners and definitions for critical business fields? - Has data quality been validated on a sample representative of production traffic? - Have data failure modes been identified and documented: missing fields, delays, duplicates, stale records? - Is version control in place for reference datasets, prompts, and post-processing rules? - Does the data pipeline monitor freshness, completeness, and consistency?
In a GenAI context, additionally: - Do document sources have accountable owners for content freshness? - Is it clear which documents are sources of truth vs. supporting references? - Is knowledge updating independent from irregular manual effort?
NIST AI RMF 1.0 emphasizes that AI risk management requires continuous measurement and monitoring. That means data quality is not a one-time pre-launch validation; it is a permanent part of operations.
Gate 3: architecture and integrations
Many initiatives stop at the demo interface because integration into real work systems proves more expensive and harder than expected.
- Has the architecture been evaluated for scalability and maintainability, not only MVP delivery speed? - Is the solution embedded in users' target operating systems (CRM, ERP, ticketing, DMS, workflow)? - Are stable APIs in place, with a plan for upstream system changes? - Is there a defined fallback when the model fails, is too slow, or returns low-quality output? - Do latency and throughput meet process requirements?
A sound integration decision is: deploy AI first where the data and decision loop can be closed inside one workflow. A poor decision is: launch a side tool and hope users manually transfer output back into the process.
Gate 4: reliability, SLA, and observability
Without observability, there is no operational trust in AI. It is not enough to know the system is running. You must know how it is running and when it starts degrading.
- Are SLO/SLA targets defined for key dimensions: availability, response time, output quality, error rate? - Does monitoring cover not only infrastructure but also model quality and business-output quality? - Do alerts have severity levels, owners, and response-time expectations? - Does the incident runbook define diagnostics, escalation, and rollback criteria? - Is there a regular post-incident review cycle and error-learning process?
Google SRE Workbook (2018) shows that mature systems do not eliminate all failures; they build fast detection and controlled recovery. The same standard should apply to AI services, especially those shaping operational decisions.
Gate 5: security, compliance, and risk
AI production readiness requires a security and compliance layer designed in proportion to use case risk.
- Is use case risk classification documented and approved? - Are handling rules for sensitive, personal, and contract-restricted data clearly defined? - Have model and service vendors completed legal/security due diligence? - Do user and system logs enable auditability and decision traceability? - Are human-in-the-loop (HITL) conditions defined for high-impact decisions?
ISO/IEC 42001:2023 structures AI management-system requirements across accountability, monitoring, and continuous improvement. In production terms, governance cannot be an afterthought; it is an entry criterion.
Gate 6: operations, roles, and people readiness
Moving AI to production also means launching a new way of working.
- Does every critical area have an owner: business, process, data, platform, risk, user support? - Does the operations team have skills to handle AI quality incidents, not just technical outages? - Have end users received guidance on working with AI output and criteria for rejecting it? - Do line managers have a standard for evaluating AI-assisted work quality? - Is there an issue-reporting channel and a feedback loop for prompts, rules, and configuration?
The most frequently overlooked item is management readiness. If managers cannot distinguish a fast output from a correct output, productivity pressure will push teams toward quality risk.
Gate 7: cost and economic durability
Many AI solutions are launched under low load, and cost issues appear only at scale.
- Does the cost model cover volume growth and seasonality scenarios? - Does the team track cost per unit of business value, not just total infrastructure cost? - Are usage limits and budget-protection mechanisms in place? - Does the model include the cost of integrations, monitoring, support, and model updates? - Are de-escalation or feature-retirement decisions defined for when economics deteriorate?
Mature LLMOps and MLOps treat cost as an operational quality metric. Low-cost, low-quality output is as problematic as high quality without cost control.
Go/No-Go decision model
After passing all seven gates, use a simple model:
- `Go` - all critical criteria are met, risks are controlled, owners are assigned. - `Conditional Go` - 1-2 non-critical criteria are missing, with a closure plan, owner, and deadline. - `No-Go` - at least one critical criterion is unmet (for example: no process owner, no quality monitoring, no security rules for sensitive data).
What matters most is documenting the decision. If the organization launches conditionally, it must explicitly state which risks are accepted and who is accountable for reducing them.
Typical pre-production anti-patterns
The first anti-pattern is "let's launch now and add monitoring later." In practice, that means late quality degradation detection and expensive operational firefighting.
The second anti-pattern is "users will figure it out." Without review standards, feedback loops, and accountability, users create local workarounds that destroy outcome consistency.
The third anti-pattern is "we have an SLA because the vendor promises uptime." Vendor uptime does not guarantee business-process quality. You must monitor the full chain: data, model, integrations, human decisions, and final outcomes.
The fourth anti-pattern is "let's defer owner assignment for now." No owner is the cheapest choice before launch and the most expensive one after an incident.
What leaders should do in 30 days
In week one, pick 2-3 use cases with the highest business impact and run a formal production readiness review using this checklist.
In week two, close critical gaps: owners, quality monitoring, incident runbook, fallback, and sensitive-data rules.
In week three, launch an operational dashboard linking technical metrics to business-process metrics.
In week four, make a go/no-go decision and schedule production reviews after 30 and 90 days.
