AI Prototype to Production: Launch Checklist

Taking an AI prototype to production means proving that it can handle the work customers will give it, with the right data access, controlled actions, and a way to recover when something fails. A working demo is useful evidence. It leaves several launch decisions open.

Your assistant might answer a question correctly using a document you uploaded yourself. What happens when two customers upload similar documents? When a policy changes? When a tool completes an action but the connection drops before the result comes back?

Those are the cases to test before customers depend on the product.

This guide is for founders and product teams launching AI-powered assistants, retrieval systems, and agents. If AI helped write your app but the app has no AI feature, most of the model and retrieval checks below will not apply. Ordinary application testing still will.

What changes between an AI prototype and a production product?

A prototype tests an idea under limited conditions. A production product has an explicit operating scope: who can use it, what it can do, how its behavior is measured, and who handles failures.

Production readiness also depends on the release. An internal assistant that drafts text for review has different requirements from an agent that can send customer emails or change account records.

Write down the scope of the next release before choosing infrastructure or replacing the model.

For a document assistant, a sensible first release might answer questions from approved product documentation and prepare support-ticket drafts. Sending replies or changing customer accounts can stay outside that release.

That scope gives your team something specific to evaluate.

1. Build an AI evaluation set around the actual task

An AI evaluation, often called an eval, is a test of the behavior you expect from your application. A model's public benchmark score cannot tell you whether your assistant handles your documents and workflows correctly.

Collect examples from intended users, with permission to use their data. Include ordinary requests, ambiguous questions, and cases where the product should decline or ask for clarification. Define the expected behavior before scoring the output. Keep a separate test set that you do not use to tune prompts.

OpenAI recommends task-specific evaluations, human calibration of automated scoring, and repeated evaluation as the application changes. Its evaluation best practices also warn against judging quality by whether a few outputs seem convincing.

Keep the results inspectable. Record the input, expected behavior, actual result, and reason for each judgment. Save the model identifier, prompt version, retrieval configuration, and document snapshot with the run.

For agents, check the final state in the connected system. A message saying that a ticket was created is insufficient evidence. Inspect whether the ticket exists, belongs to the right account, and contains the approved information. Anthropic's guide to agent evaluations makes this distinction between the execution record and the actual outcome.

Choose release criteria by failure type. Track unsupported answers separately from appropriate refusals. An assistant that refuses every question could avoid making false claims while being useless.

For the defined release, treat any observed cross-account disclosure or unapproved write as a blocker. Passing the tests does not prove that such failures are impossible; it gives you evidence about the cases you ran. Report the sample size and coverage alongside the result.

2. Test retrieval before trying to improve the prompt

Retrieval-augmented generation, or RAG, supplies the model with relevant material from your documents or other data sources. A wrong answer can begin with the wrong source material.

Review the retrieved passages alongside the response. Separate these questions:

• Did the search find the information needed to answer?
• Was that information current and applicable to this user?
• Did the answer stay within what those passages support?
• Did it address the user's question?

Microsoft's RAG evaluation documentation distinguishes retrieval quality from measures such as groundedness and response relevance. That separation helps you locate a failure before changing the system.

A grounded answer can still be wrong for the customer if its source is an obsolete policy. A correct document can also produce an incomplete answer if the relevant exception was lost during parsing or chunking.

Include missing documents, conflicting versions, scanned PDFs, and information spread across several passages in your tests. Check tables and footnotes if they contain rules users need.

Give the product a useful response when its sources do not support an answer. It can ask for a missing detail, explain the limitation, or direct the user to support. Avoid treating the model's self-reported confidence as a release criterion.

3. Enforce document permissions before information reaches the model

Signing in identifies the user. The application must still decide which documents and records that user may access.

Apply those permissions when retrieving information. A prompt that tells the model to hide private documents cannot substitute for access control. Microsoft's security-filter documentation describes filtering results by identity and warns that the filter itself does not authenticate the caller.

In practice, derive the user's identity and account scope from trusted server-side authentication. Do not accept an arbitrary account identifier from a chat message or browser request as permission to search that account.

Test with at least two accounts whose documents use similar wording. Ask one account about the other account's information. Inspect the retrieved context as well as the answer.

Extend the review to source previews, exported files, conversation history, and caches. A correct search filter is little help if a shared answer cache returns another customer's response. Test access revocation too: removing a document or a user's permission must affect the paths that can still expose that content.

4. Test prompt injection through the content your assistant reads

Prompt injection occurs when input attempts to redirect the model's behavior. The instruction may arrive in a user message or inside a document, webpage, or tool response.

OWASP documents both direct and indirect attacks in its prompt-injection guidance. Retrieved content is therefore part of the attack surface, even when it looks like an ordinary source document.

For a launch test, add an instruction to a test document that asks the assistant to ignore its task or send information to an external destination. Check whether the system follows it, requests a forbidden tool action, or exposes restricted data.

Use layered controls: restrict available tools, validate their arguments, limit destinations, and keep authorization outside the model. OWASP's prevention cheat sheet discusses these defenses and adversarial testing.

Inspect generated links and rendered output too. Your interface should not execute arbitrary HTML or quietly fetch an external URL containing private information. Passing a small attack set is evidence about that set, not a guarantee against prompt injection.

5. Make agent actions reviewable and safe to retry

An agent that can change another system needs explicit action boundaries. List its tools and the permissions attached to each one.

For the initial release, decide which tools can read data, which can prepare drafts, and which can execute changes. Require approval where the consequences justify it. OWASP's excessive-agency guidance recommends limited permissions, approval for high-impact actions, and authorization enforced in downstream systems.

An approval screen should show the destination and exact change. Record the approver and bind their decision to that payload. If the recipient or content changes, the earlier approval should not authorize the new action.

Test approval rejection, expiry, and a server restart while an action is waiting. LangGraph supports persisted workflow state, but its persistence documentation notes that an in-memory checkpointer loses checkpoints on restart. Its interrupt documentation also explains that code before an interrupt may run again when execution resumes.

Retries need their own tests. A request can succeed in the receiving system while your application fails to receive confirmation. Retrying it blindly can create a duplicate.

Use a stable operation identifier and a duplicate-prevention mechanism appropriate to the integration. Stripe's idempotent-request documentation gives a concrete example of safely retrying supported requests with the same key. Check each provider's semantics and retention limits; one provider's guarantees do not apply to your whole workflow.

When an outcome is unknown, reconcile it with the receiving system. Tell the user that confirmation is pending rather than reporting success or failure without evidence.

6. Measure cost and response time across the complete workflow

A single model request can be cheap while the customer task requires retrieval, several model calls, tool requests, and retries.

Measure the path the user actually completes. Include failed attempts and human review when calculating the cost of a successful task.

Use two views:

• **Variable cost per completed task:** attributable model, retrieval, tool, and review costs divided by completed tasks.
• **Total operating cost:** those variable costs plus hosting, storage, monitoring, maintenance, and support.

You can start with estimated values, but label them as estimates. Replace them with measurements from representative usage. Our guide to AI operating costs covers the budget inputs in more detail.

Set limits on input size, output length, retries, tool steps, and concurrent work. Decide what the user sees when a limit is reached.

Test under expected concurrent load. Record both the time until useful feedback appears and the time until the task finishes. Inspect slow requests rather than relying only on an average. If you report p95 latency, explain that 95% of measured requests completed within that time and state the workload used.

Choose the response-time target around the task. A background document analysis has different expectations from a support chat. Streaming may improve the waiting experience, but it does not establish that the eventual answer or action is correct.

7. Test failure recovery and the ordinary application around the AI

Force failures in a staging environment. Disconnect a dependency, return a rate-limit error, and stop a worker during a task. Verify what the user sees and what state remains afterward.

The application should distinguish work that is queued, running, awaiting approval, completed, or failed. If the outcome is uncertain, represent that uncertainty explicitly.

For diagnosis, retain enough information to connect the request with its retrieval and tool steps. Useful fields include a request identifier, configuration versions, source-document identifiers, action status, timings, and error categories. Decide which content to redact, who can inspect it, and when it is deleted. Debugging should not create an unrestricted copy of customer data.

Also test sign-in, file uploads, billing, backups, and deployment configuration where those features exist. Restore a backup into a test environment. Verify that production credentials remain server-side and that development settings have not carried into the release.

An AI evaluation cannot replace these checks. A good answer is irrelevant if the customer cannot access the product or loses their work after a restart.

A worked AI production-readiness checklist

Consider a hypothetical document assistant for a B2B software product. It reads approved help articles and account-specific documents. It can draft a support ticket, but a user must approve submission.

The following table is a proposed test plan. It contains no results from a Prograsec deployment.

Attach an owner and an evidence link to each row in your release review. A row without evidence is an unresolved item. It should not count as a pass.

Should you harden the prototype or rebuild it?

Review the components individually. A working interface may be reusable even if its permissions or workflow execution need replacement.

Compare the work required to reach the same release scope. Include migration, retesting, and maintenance in both estimates. Neither a new framework nor a larger model removes the need to verify permissions and actions.

If orchestration is the uncertain part, our LangChain vs LangGraph guide explains the distinction. Choose around the workflow you need to support.

Release to a limited audience with clear stop conditions

After the launch checks pass, start with a controlled pilot. Name the users, supported tasks, and person responsible for reviewing failures.

Decide in advance which events stop the rollout. Examples include unauthorized data exposure, an unapproved write, repeated duplicate actions, or operating costs exceeding the agreed budget. Make the affected capability easy to disable.

Google's SRE guidance on canary releases describes limiting exposure while comparing a candidate release with the existing version. For an AI product, monitor answer quality and action outcomes alongside request errors and latency.

Version prompts, models, retrieval settings, and workflow rules. Re-run the relevant tests when they change. Rolling back code does not undo a message already sent or a record already changed, so plan how to reconcile those effects.

Prograsec's AI development work includes retrieval fallbacks in Cause Systems and human approval steps in a confidential workplace-procedures platform. The latter remains in final development according to our published portfolio. Those are different delivery stages, and each needs its own release evidence.

If you are assessing an outside team, ask for the failed cases and operating limits as well as the demo. Our AI agency hiring guide lists the evidence to request.