AI Prototype to Production: A Roadmap That Ships

Posted: May 2, 2026 to AI.

Your AI prototype produced a go decision. The evaluation looked good, the executive sponsor signed off, and the production budget is approved. Now what.

The path from a working prototype to a running production AI capability is where most regulated organizations get stuck. The prototype lived inside a controlled boundary on a developer-friendly stack, integrated to a couple of representative systems, and was operated by the engineers who built it. Production has to be a different animal. It has to survive real concurrency, real on-call rotations, real change-management gates, real audit reviews, and the day a model provider ships a deprecation notice. None of that was the prototype's job. All of it is now yours.

This guide is the productionization roadmap Petronella Technology Group walks every regulated-vertical client through after a Stage 3 go decision. It covers the six workstreams that have to run in parallel, the most common reasons production stalls after a successful prototype, and the operational posture you need in place before users land on the system.

For the broader buyer's framework on prototyping itself, see the AI prototyping pillar. For the methodology that produces the prototype this guide picks up from, see our 3-stage AI proof of concept development page. This post starts where those end: the day the prototype is approved for production.

The Six Workstreams Between Prototype and Production

Productionizing an AI capability is not a single project. It is six workstreams that have to run in parallel, with a coordinator who can keep them aligned. Trying to run them serially adds months. Trying to run them without coordination produces a production system that fails its first audit, its first scale event, or its first incident.

The six workstreams are: hardware and infrastructure sizing, security and compliance review, integration hardening, observability and operations, change management and rollout strategy, and ongoing model and prompt governance. We will take each in turn.

Workstream 1: Hardware and infrastructure sizing

The prototype ran on whatever hardware was convenient. Production has to run on hardware sized for sustained concurrency, with capacity headroom, redundancy, and a documented growth path. If the prototype showed cost per transaction at projected production volume, this is where that projection turns into a bill of materials.

The decisions to make here. On-premises private cluster, hosted private cluster (operated by a partner inside your regulatory boundary), or hyperscaler enclave. GPU class and quantity. Storage tier for prompt and response logging. Network egress and ingress capacity. Backup and disaster recovery posture. Capacity for the next twelve months versus capacity for the next thirty-six.

For regulated workloads, this decision usually narrows quickly. HIPAA-covered data, CMMC controlled unclassified information, or contract clauses requiring data residency push toward private cluster (on-premises or partner-operated) and away from public AI APIs. The Petronella default for regulated-vertical clients is a private AI cluster operated inside a boundary aligned to the framework the data falls under, with prompt and response logging, scoped access, and audit trail from day one.

The deliverable of this workstream is a written sizing document with a one-year and three-year total cost of ownership model, the assumptions behind the projection, and a documented capacity-planning trigger that fires before headroom runs out.

Workstream 2: Security and compliance review

The prototype operated under a temporary scoped path that the security team granted for the engagement. Production needs a permanent access model, formal change management, audit logging that satisfies the regulatory framework, and review by the same team that signs off on every other production system in your environment.

The decisions to make here. Identity and access model (who can call the capability, with what scope, propagated from which identity provider). Prompt logging policy (what is captured, with what redaction, retained for how long, accessible to whom). Model and version pinning (which models are approved for production use, who approves new versions, what the rollback path looks like when a new version regresses). Data residency and egress controls (where can data go, who is notified when egress patterns change). Incident response plan specific to AI failures (model outage, runaway cost, integrity issue with retrieved context).

For HIPAA-covered work, the production capability has to operate under a Business Associate Agreement with every party that touches protected health information, including any external model provider if one is in the architecture. For CMMC-aligned work, the capability has to live inside an enclave aligned to the framework level (L1 under FAR 52.204-21, L2 under NIST SP 800-171, L3 under NIST SP 800-172). For regulated finance or legal work, the equivalent framework controls apply.

The deliverable is a written security review document, signed by the security team and the compliance officer, that lists the controls in place, the residual risks accepted, and the conditions under which the production approval would be revisited.

Workstream 3: Integration hardening

The prototype was integrated to representative upstream and downstream systems, but those integrations were almost always softer than production needs. Real auth tokens with appropriate scope. Real rate limiting. Real retry and circuit-breaker logic. Real handling of upstream failures (what does the AI capability do when the database is unavailable, when the document store returns stale data, when the identity provider rate-limits a burst of requests).

The decisions to make here. Synchronous versus asynchronous integration patterns. Idempotency guarantees for write-back to systems of record. Reconciliation when the AI capability and the system of record disagree. Schema versioning for the upstream sources the capability depends on. Test environments that mirror production integration topology closely enough to catch regressions.

The hidden cost. Integration hardening is almost always underestimated because the prototype made it look easy. The prototype called one endpoint with one auth token under cooperative load. Production calls dozens of endpoints across multiple identity contexts under adversarial load. Plan for integration hardening to be the longest of the six workstreams.

The deliverable is a written integration map with each system rated for production readiness, the gaps closed, the gaps explicitly accepted, and the contracts (interface specifications, SLAs, rate-limit ceilings) in place with each upstream owner.

Workstream 4: Observability and operations

The prototype produced telemetry as evaluation evidence. Production has to produce telemetry as ongoing operational signal. The two are related but not the same.

Operational telemetry has to support on-call response. That means alerting on latency regressions, error rate spikes, cost anomalies, and integration failures, with runbooks the on-call engineer can execute in the middle of the night. It has to support capacity planning, which means dashboards trending throughput and cost over time so the team can see the curve before it bends past the budget. It has to support post-incident review, which means structured logging of prompts, responses, and retrieval context, with redaction and retention aligned to the compliance framework.

The decisions to make here. Alerting thresholds and on-call rotation. Dashboard ownership (who looks at the trend lines and how often). Runbook coverage (every alert that pages the on-call engineer must have a runbook, no exceptions). Post-incident review process specific to AI failures. The model and prompt change-log workflow that ties production behavior changes back to the version of code, prompt, and model that was running.

The deliverable is an operations runbook with named owners, an on-call rotation, a defined paging policy, and dashboards in production. If the team running the capability is not the team that built it, this is the workstream where the handover happens.

Workstream 5: Change management and rollout strategy

You almost never want to ship the production capability to all users on day one. The healthiest pattern is a phased rollout behind a feature flag or in front of a small user cohort, with explicit exit criteria for each phase and a documented rollback path.

The decisions to make here. The cohort strategy (internal first, then friendly customers, then general availability; or some other staged path). The exit criteria for each phase (what metric, at what threshold, holds for how long, before the next phase opens). The rollback trigger (what would cause you to revert, and how fast can you do it). Communication plan to the user cohort (what they should expect, what to do when the capability misbehaves, where to file feedback).

For AI capabilities specifically, the rollout strategy has to plan for behavior drift. Foundation models change. Prompts that worked yesterday can produce different output tomorrow if the underlying model is updated, or if your retrieval index drifts. The rollout strategy has to include regression testing tied to your evaluation set, not just a one-time launch test.

The deliverable is a written rollout plan with phases, exit criteria, rollback triggers, and a named owner for each phase decision.

Workstream 6: Model and prompt governance

The most overlooked workstream. The prototype ran against a specific model version with a specific prompt template. Production has to assume that both will change over time and have a governance process for when and how.

The decisions to make here. Who owns the prompt and the prompt change process. How prompt changes are tested before they reach production (against the same evaluation set the prototype was graded on, ideally). How model upgrades are evaluated (regression testing against the evaluation set, with a defined acceptance bar). What happens when a model is deprecated by its provider and the team has to migrate (this will happen, plan for it). How prompt and model changes are logged in the audit trail so that a production output can be tied back to the exact configuration that produced it.

For regulated workloads, this workstream is non-negotiable. The compliance team needs to be able to answer the question "what model and what prompt produced this output for this user on this date" in audit. Without governance discipline, that answer does not exist.

The deliverable is a governance document covering prompt change process, model upgrade process, deprecation response plan, and audit trail design.

The Most Common Reasons Production Stalls After a Successful Prototype

A prototype that produces a clear go decision and then stalls indefinitely is more common than it should be. The patterns are predictable.

Hardware was not budgeted

The prototype ran on shared development hardware. The production sizing exercise produced a real number with a real lead time. Capital approval, procurement, and hardware delivery add a quarter to a quarter and a half before any production work can start. Teams that did not budget for this in the prototyping phase end up either cutting corners on hardware or waiting on procurement.

The fix. Surface the hardware sizing as part of the Stage 3 deliverable, not a follow-up. Petronella's Stage 3 includes a bill of materials with one-year and three-year total cost of ownership for this reason.

Security review was not scheduled

The prototype operated under a temporary security exception. The production review starts from scratch and follows the standard timeline for new capabilities at the organization. If that timeline is six to twelve weeks and was not scheduled in parallel with the prototype, the production launch is now bottlenecked on the security review the team did not start.

The fix. Schedule the production security review at the start of the prototype, not at the end. The prototype's evaluation evidence is exactly what the security team needs, so they can do the review as the prototype produces results rather than after.

Operations was not consulted

The team that built the prototype is not the team that will operate it in production. Operations finds out at the handover meeting, by which time decisions have been made they would have weighed in on differently. The capability ships and operations either pushes back or accepts a system they would not have approved.

The fix. Bring the operations team into the prototyping phase as a stakeholder of the evaluation, not as the recipient of a finished build. The operations team owns workstream 4 from day one.

The integration map had gaps

The prototype's integration map said "real" for the integrations that were straightforward and "stubbed for the prototype" for the integrations that were hard. Production needs all of them real. The integrations that were hardest to stub are now the integrations that are hardest to harden, and the production timeline absorbs that work.

The fix. The Stage 3 production-readiness checklist has to grade every integration, with the hard ones explicitly scoped for production work in the post-prototype roadmap.

The model was deprecated

Six months after the prototype shipped, the model the prototype was built against is deprecated by its provider. The production team has to migrate to a successor model, validate it against the evaluation set, and ship the migration. This is not a hypothetical. Foundation model providers update and deprecate frequently, and the migration cost is real every time.

The fix. Workstream 6. Treat model upgrade as an ongoing operations responsibility, not a one-time launch task, and budget engineering time for it.

How Long the Prototype-to-Production Path Actually Takes

The honest answer is "it depends," and the dependencies are predictable. A regulated-vertical AI capability with a clean prototype, a named production owner, hardware that is already budgeted or can be expedited, and a security review scheduled in parallel typically reaches production in three to six months from go decision.

Capabilities missing one or more of those preconditions take longer, often nine to twelve months from go decision to production.

The variable is almost never the engineering work. Hardening a prototype into production is usually six to twelve weeks of focused engineering. The variable is the parallel non-engineering work: procurement, security, operations, change management, governance. Organizations that run those workstreams in parallel with the engineering ship faster.

The Petronella Productionization Engagement

For clients who want a partner to run the productionization, Petronella picks up from the Stage 3 go decision and runs the six workstreams in parallel. Engineering happens on our private AI cluster or in your environment, depending on data class. The security workstream runs against your existing review process, or we help build one aligned to the framework the data falls under. Operations is co-owned with your internal team or fully outsourced to Petronella as a managed AI service.

The engagement model and deliverables are documented at our AI prototyping services page. The full 3-stage methodology that produces the prototype this engagement picks up from is at our AI proof of concept development page.

Petronella Technology Group is a Raleigh, North Carolina regulated-vertical engineering practice founded in 2002 and BBB A+ since 2003. We are CMMC-AB Registered Provider Organization #1449, the whole team is CMMC-RP certified, and founder Craig Petronella holds CMMC-RP, CCNA, CWNE, and DFE #604180. Production AI for HIPAA, CMMC, and other regulated workloads runs inside our private AI cluster, never on a public AI API.

Frequently Asked Questions

How long does it take to go from AI prototype to production?

For a regulated-vertical capability with a clean prototype, named production owner, budgeted hardware, and a security review scheduled in parallel, three to six months is typical. Capabilities missing one or more of those preconditions take longer, often nine to twelve months. The variable is almost always the parallel non-engineering work, not the engineering work itself.

Can we keep using the prototype hardware in production?

Almost never. Prototype hardware is sized for a small number of evaluation runs at low concurrency. Production hardware has to be sized for sustained load, with capacity headroom, redundancy, and a documented growth path. Treating prototype hardware as production-ready is a common cost-saving instinct that produces incidents.

Do we need a different team for production than for the prototype?

Not necessarily, but the team has to expand. The prototype team understood the engineering. Production also needs operations, security, and governance disciplines the prototype team probably did not own. Keep the prototype team involved through productionization and add the operational disciplines around them.

What if a model gets deprecated after we ship?

Plan for it. Workstream 6 (model and prompt governance) treats model upgrade as an ongoing operations responsibility, with engineering time budgeted for migrations. The first time a deprecation lands without a process is the most painful migration. The second time is routine if the process exists.

How do we keep the production system aligned to the prototype's success criteria?

Continuous regression testing against the evaluation set the prototype was graded on. The evaluation set itself has to be maintained as production data drifts, which is the model and prompt governance workstream's responsibility. Capabilities that pass at launch and never re-test tend to drift away from their success criteria within a few months.

What is the single most underestimated workstream?

Integration hardening. The prototype made it look easy because the prototype called one endpoint under cooperative load. Production calls many endpoints across multiple identity contexts under adversarial load, and the gap between those two realities is where most production launch delays come from.

What if the prototype produced a no-go and we still want to ship?

Treat the no-go as a signal that the use case as scoped is not ready, and revisit the assumptions that broke. A smaller scope, different data class, different latency target, or different cost model can turn a no-go into a go. Shipping a capability the prototype told you would fail surfaces the failure in production, which is the most expensive place to find it.

Where to Go Next

If you have a prototype with a go decision and need help scoping the productionization engagement, the AI prototyping services page covers the engagement model and deliverables. If you have a prototype but have not yet graded it, see how to evaluate an AI prototype. If you are still mapping prototype to MVP, see AI prototyping vs MVP. The AI prototyping pillar walks the buyer's framework, and the 3-stage AI proof of concept development page details the methodology.

To talk through your situation with a Petronella engineer, call (919) 348-4912 or visit our contact page. We will help you map the six workstreams and identify the bottlenecks most likely to stall the path between go decision and production.