From AI Proof of Concept
to Production:
What Changes After the Demo

A proof of concept shows that an AI approach can work under selected conditions. Production must show that the whole service can behave acceptably across real inputs, failures, changes, permissions, costs, and human operations.

The gap is not a final deployment step. It is a change from demonstrating possibility to owning repeatable behavior. The NIST AI RMF Playbook organizes that work around governance, context, measurement, and risk management across the lifecycle.

1. Freeze the use case and decision rights

Write down the approved users, trigger, inputs, outputs, actions, exclusions, and business owner. Name who can change the scope, accept risk, approve a release, and stop the service.

A moving use case makes evaluation results expire. Version material changes instead of letting a demonstration grow through informal additions.

2. Replace curated examples with representative evaluation

Build datasets that reflect actual languages, document types, workflow segments, edge cases, missing context, malicious inputs, and expected seasonal or operational variation. Protect sensitive data and record how examples were selected.

Define task-specific measures and thresholds, including the cost of false positives, false negatives, abstentions, and human corrections. Re-run the same evaluation when the model, prompt, retrieval source, policy, or integration changes.

3. Own models, providers, prompts, and configuration

• Record the model and provider versions or approved selection policy.
• Version prompts, tool descriptions, policies, retrieval configuration, and evaluation code.
• Define how provider changes, deprecations, outages, and regional availability are handled.
• Keep secrets and environment configuration outside source and logs.
• Assign an owner for cost, quota, and contract changes.

A prototype that depends on an individual's account, hidden prompt, or manually prepared context is not an operable service.

4. Test the entire decision path

Unit tests around parsing are not enough. Test data retrieval, context assembly, model calls, structured outputs, validation, tool authorization, downstream side effects, human approval, retries, and audit records.

Include contract tests for external APIs and end-to-end cases for the important success and failure paths. Treat non-determinism as something to measure and constrain, not as a reason to skip repeatable tests.

5. Enforce security boundaries outside the model

Assume untrusted content can reach prompts through users, documents, web pages, or tool results. Validate inputs and outputs, separate trusted instructions from content, authorize every action server-side, and restrict data and tools to the approved task.

Do not rely on a prompt to protect money, production data, credentials, or privileged actions. OWASP's guidance on excessive agency recommends minimizing functionality, permissions, and autonomy, with human approval for high-impact actions.

6. Design human review as a product workflow

Specify which cases require review, what evidence the reviewer sees, how uncertainty is communicated, the time allowed, and what happens when nobody responds. Give reviewers a clear way to edit, reject, escalate, and explain a correction.

Measure review effort. A system that appears accurate but requires slow reconstruction of every answer may not improve the operation.

7. Set latency, cost, and capacity thresholds

Estimate full request cost, including retrieval, model calls, retries, moderation, storage, observation, and human review. Test realistic concurrency and provider limits. Decide what can be cached, queued, degraded, or rejected when the service is slow or over budget.

Tie thresholds to the workflow. A delayed background summary and a real-time approval decision have different operating requirements.

8. Make failure visible and recoverable

Track timeouts, malformed outputs, refusals, low-confidence cases, tool failures, duplicate actions, review overrides, and fallback use. Keep logs useful for investigation while excluding secrets and unnecessary personal data.

Define safe defaults, retry limits, idempotency, dead-letter handling, manual recovery, and a tested shutdown path.

9. Version releases and prove rollback

A release should identify the application code, model selection, prompts, policies, retrieval sources, evaluation results, and configuration. Use controlled environments and approval gates. Preserve the last acceptable configuration and verify that rollback restores the workflow rather than only the code.

10. Define incident, support, and data operations

• Who receives alerts and user reports?
• What constitutes a security, privacy, quality, or provider incident?
• How are affected records and downstream actions identified?
• What are the escalation, containment, notification, and recovery steps?
• How long are inputs, outputs, evaluations, feedback, and logs retained?

Support responsibilities and data lifecycle decisions belong in the production design, not in a handoff after launch.

11. Roll out in controlled stages

Begin with offline evaluation, then internal users, shadow mode, assistive suggestions, a limited cohort, and broader release only when the evidence supports each transition. The exact sequence depends on consequence and reversibility.

Define entry, success, failure, and rollback criteria for every stage. Do not let time elapsed substitute for acceptable results.

Production-readiness evidence

• Approved use case, exclusions, owners, and risk decisions.
• Representative evaluation set, thresholds, and current results.
• Architecture, data flow, access, retention, and threat review.
• Versioned prompts, policies, configuration, and dependencies.
• Integration, failure, load, and rollback test evidence.
• Monitoring, human-review, fallback, incident, and support runbooks.
• Phased rollout plan with explicit go and stop criteria.

If the workflow itself is not yet bounded, start with the AI Automation Readiness Checklist before extending the PoC.

The practical production rule

A demo proves an approach can produce an answer. Production evidence must show that the service can produce, constrain, review, observe, recover, and change that behavior responsibly.