When an AI prototype needs production engineering

A demo can look complete while still depending on manual fixes, broad credentials, friendly test data, one model configuration, and the memory of the person who built it. None of that makes the prototype bad. It means the prototype has done a different job from the production system you may now need.

Prototype and production do different jobs

A prototype should reduce uncertainty quickly. It might answer whether users want an AI-assisted workflow, whether a model can extract the required structure, whether retrieval finds useful context, or whether an integration is technically possible. Fast changes and manual intervention are reasonable while the team is still learning.

A production system must continue working when the easy assumptions stop holding. Inputs become messy. Permissions differ by user. An upstream API slows down. A model version changes. A retry creates a duplicate action. Someone needs to explain why an output was produced and recover from an incident without reconstructing the system from chat history.

This is why “we have only 50 users” can still describe a production-critical application. If those 50 people use it to approve payments, handle patient information, route support escalations, or operate a core internal process, the cost of a wrong or unavailable system can be material.

The five readiness signals

Look for a cluster of signals. One signal may justify a targeted control. Several together usually mean the product needs explicit production ownership.

Ask consequence questions before scale questions

• What happens if the model is confidently wrong in the most important workflow?
• What happens if the same action runs twice, runs late, or never runs?
• Could one user retrieve another customer’s information through the feature?
• Can the team reproduce an output from the available logs and configuration?
• Can a human pause, override, or reverse a consequential action?
• What is the acceptable recovery time after an application, provider, or data failure?

These questions expose the operating requirements. They also keep the team from equating a polished interface with a dependable system.

Choose whether to harden, split, or rebuild

Moving to production does not automatically require discarding the prototype. Start with an assessment of the code, architecture, data boundaries, provider dependencies, testability, and delivery workflow. Then choose the smallest path that can meet the actual requirements.

A rewrite is a business decision, not a reaction to how the prototype was made. The team should be able to identify the specific requirement the current design cannot satisfy and explain why replacement is safer or cheaper than remediation.

Add the controls that reduce the biggest risk

“Production grade” is not one universal checklist. A private writing assistant and an agent that can issue refunds should not receive the same controls. Begin with the highest-consequence path and design outward from it.

1. Define the contract
   Document accepted inputs, expected outputs, failure behavior, user permissions, and which actions require human approval.
2. Build representative evaluations
   Collect real task examples, edge cases, adversarial inputs, and unacceptable outputs. Run them when prompts, models, tools, or retrieval logic change.
3. Separate model judgment from application authority
   Validate structured output, enforce permissions in code, limit available tools, and require confirmation for high-impact actions.
4. Make behavior observable
   Capture request IDs, model and prompt versions, retrieval results, tool calls, latency, token usage, errors, and user feedback without logging data the team should not retain.
5. Design recovery before launch
   Use controlled releases, rollback paths, idempotency for repeated operations, backups where state matters, and a documented fallback when a model or provider is unavailable.
6. Name the production owner
   Assign responsibility for releases, access, provider changes, evaluation quality, cost review, incidents, and user communication.

Security belongs around the model

Prompt instructions are product behavior, not an authorization layer. The application must still enforce identity, tenant boundaries, tool permissions, data access, and output handling. OWASP’s guidance treats prompt injection as an application risk that can influence downstream actions; retrieval or fine-tuning alone does not remove it.

For workflows with external content or tools, assume the model can receive hostile input. Keep credentials outside prompts, constrain the functions the model can call, validate arguments, apply least privilege, and add explicit approval where an action cannot be safely undone.

A practical first month

The goal of the first production sprint is evidence and control, not broad feature expansion.

Week 1: map the operating path

Trace one important user task from input through data access, model calls, tool use, stored state, output, and follow-up action. Mark trust boundaries, sensitive data, manual interventions, and single points of failure. Agree on the success criteria and the unacceptable outcomes.

Week 2: make behavior testable

Create a small but representative evaluation set. Add deterministic checks for schemas, permissions, citations, or business rules where possible. Record the model, prompt, retrieval, and tool configuration with each run so results can be compared rather than remembered.

Week 3: make change controlled

Establish development and production boundaries, code review, secret management, automated checks, deployment ownership, and rollback. Add limits and approval steps around write actions. Test what happens when dependencies time out or return malformed data.

Week 4: release narrowly and observe

Expose the workflow to a controlled user group. Watch task success, failure categories, latency, cost, overrides, and support requests. Feed production examples back into evaluation. Expand only when the team can explain both the result and the recovery path.

Reference points

This guide uses established production and AI risk principles as reference points. The recommendations above are Botmer’s practical synthesis for product teams.

• AWS Well-Architected Framework — operational excellence, security, reliability, performance, and cost as continuing workload concerns
• NIST AI Risk Management Framework — incorporating trustworthiness considerations throughout design, development, deployment, use, and evaluation
• OWASP Top 10 for LLM Applications 2025 — application risks including prompt injection, sensitive information disclosure, improper output handling, and excessive agency
• OpenAI evaluation guidance — using task-specific test criteria and evaluation data to compare system behavior