What Does an AI Production Build Include? Scope, Phases and Gates

Q: When is a production build the wrong next step?

- The use case is not validated. Run a proof of concept first. - A pilot has stalled. Triage first: how to rescue a failing AI project and AI Rescue. - Several use cases compete. Prioritize them first. - The task is stable, rule-based and fully specified. In our judgment, conventional automation is cheaper to build and easier to audit, and AI is the wrong tool. - No one can grant access to real data or own the outcome. The data-integrity criteria cannot be proven without real data.

Last updated: October 2026. External figures are attributed and dated in the text.

In short: An AI production build takes one validated use case and turns it into a system that runs on live data, is monitored on outcomes, is verified by someone other than its builders, and can be operated by your team. It covers design, data integration, the build, an evaluation harness, guardrails, observability, verified deployment, evidence-gated rollout and handover. We recommend turning each risk in the OWASP Top 10 for LLM Applications 2026 into a requirement with an acceptance test, agreed at design sign-off. NewGenApps' AI Production Build starts from $40,000, phased and milestone-gated.

What is an AI production build?

An AI production build is the stage after validation: making one proven approach run reliably on live data, inside your systems, with an owner and a way to show it still works. It is not a larger demo. Our statement of work assumes an earlier stage, such as a proof of concept, an opportunity audit or an experiment, has already shown the use case is worth building.

The production readiness checklist is the pre-launch go or no-go; this page covers the build.

What does an AI production build include?

It includes eight workstreams, from solution design and data integration to deployment, verification and handover. Each ends in a deliverable you can inspect, not a status report.

The eight workstreams and their deliverables

Workstream	What it produces
Solution design	Architecture, data flows, model and agent topology, failure modes, decision log
Data integration	Per-source freshness guarantees and defined stale or unavailable behavior, under the data-integrity contract
Core build	The validated use case, implemented in your stack
Evaluation harness	A reference set, regression checks and guardrail tests, built from day one, blocking promotion on a missed threshold (how a harness works)
Guardrails and safety	Input and output validation, policy controls, escalation and fallback paths, human review where required
Observability	Tracing, outcome alerts, freshness alarms, cost and latency telemetry, an operator view
Deploy and verify	A production deployment and an acceptance record (deploy and verify AI)
Stabilize and hand over	Stabilization window, runbooks, ways of working, supervised operator dry-run

What are the phases of an AI production build, and what gates them?

There are six phases, each with an exit gate that needs evidence. Gates can collapse only explicitly.

Mobilize. Access, environments, targets, reference set. Gate: access verified; targets and reference set signed off.
Design. Solution design, data-integrity contract specification, risk register. Gate: signed off by your accountable architect or sponsor.
Build. Core build, harness, guardrails, observability. Gate: every must-have requirement passes, the harness gates promotion, evidence is presented.
Deploy and verify. Promotion to production, signed off by a verifier independent of the builder. Gate: the acceptance record is signed and the pilot criteria are met.
Operate. Run under observation as rollout advances from pilot to limited to full. Gate: stability, cost envelope and outcome criteria hold at each stage.
Hand over. Runbooks, ways of working and knowledge transfer. Gate: your named operators complete the runbook procedures unaided.

The rollout stages resemble canarying, which Google's Site Reliability Workbook defines as a partial, time-limited deployment of a change together with its evaluation, used to decide whether to proceed (Google, 2018).

How does the OWASP Top 10 for LLM Applications turn into build requirements?

We treat it as a source of acceptance tests, not a product checklist. The OWASP Gen AI Security Project released Version 2026 of its Top 10 for LLM Applications in August 2026, updating Version 2025 (November 2024). It names ten risk classes. We recommend turning each into a requirement with an acceptance test, agreed at design sign-off.

Two OWASP statements shape the tests. It says no reliable prevention mechanism for prompt injection exists today, so defense is architectural rather than interceptive: tests measure what a successful injection can do, not only whether one gets through. It also says hidden context, such as a system prompt, should not be considered a secret or relied on solely as a security boundary. The controls that matter sit outside the model. For a model that acts with tools and memory, OWASP points to its separate Top 10 for Agentic Applications.

OWASP Top 10 for LLM Applications 2026, mapped to build requirements

The mapping is our reading and our recommendation, not a fixed deliverable list. Which requirements apply, and their tests, are agreed per use case at design sign-off.

OWASP risk (2026)	Build requirement	What must hold before sign-off
LLM01:2026 Prompt Injection	Guardrails on every model input and output, plus the LLM03 limits, so a successful injection can do little	Out-of-policy and hostile inputs in the harness are refused or escalated, and none gets an action past the permission limits. Passing is evidence, not immunity
LLM02:2026 Sensitive Information Disclosure	Data classification, residency, retention and access rules, including whether the provider may train on your data	Sampled prompts, outputs and logs hold nothing outside the classification
LLM03:2026 Excessive Agency	Least privilege: a short tool list, minimum permissions, actions checked in code outside the model, human approval for high-impact actions	A call outside the list or the permissions is refused by code outside the model, whatever the model decided
LLM04:2026 Supply Chain	Every model, library and tool is approved and licensed by you, and a model change re-runs the harness	Production holds nothing off the approved list, and a swapped model passes the harness first
LLM05:2026 Data and Model Poisoning	Retrieval, embedding and fine-tuning use approved sources only, each with an accountable owner, a declared origin and write access limited to that owner	An unlisted source is refused, and a person without write rights cannot change a source that feeds retrieval or fine-tuning. This bounds who can introduce data; it does not detect poisoned content inside an approved source
LLM06:2026 Unbounded Consumption	A cost envelope per unit of work and per period; limits on input size, request rate, runtime and agent steps; an alert on breach, and a hard cap where a stop is acceptable	Overload, oversize-input and runaway-loop tests stay within the envelope, raise the alert and degrade or stop as specified
LLM07:2026 Misinformation	A reference set and agreed correctness bar in the harness, human review for high-risk results, and a plain statement of the system's limits to users	The agreed correctness bar is met on the reference set before promotion, high-risk results go to human review, and users are told the system's limits
LLM08:2026 Hidden Context Exposure	No credentials or access rules in hidden context (system prompt, injected policy text, tool schemas), and authorization enforced outside the model	All hidden context could be published without exposing a credential or weakening an access rule
LLM09:2026 Vector and Embedding Weaknesses	Where retrieval is used, source-system access rights are enforced inside the query and tenants are kept apart (RAG in production)	A user without access to a document cannot retrieve its content through a query
LLM10:2026 Improper Output Handling	Model output is treated as untrusted and validated before it reaches a database, interface or other system	A deliberately malformed output is rejected by the receiving component

The 2026 edition moves Unbounded Consumption up four places, to sixth, and says spending caps should halt work rather than only alert. The entry is framed around attackers; we read the cost envelope as covering abuse and ordinary runaway usage, such as an agent that keeps calling a model.

What non-functional requirements does a production build have to meet?

In our view, four matter most because a prototype can defer them: auditability, cost guardrails, outcome monitoring and a defined failure behavior for every dependency. Each requirement comes from our statement of work; the acceptance tests show the form we recommend and are agreed at design sign-off. Numeric targets are agreed at design sign-off. Retries suit only operations that can be repeated without repeating their effect, so we recommend setting failure behavior per dependency and, where retries are involved, per operation.

Four non-functionals as requirements and acceptance tests

Non-functional	Requirement	Acceptance test
Auditability	Each transaction is logged well enough to reconstruct what happened, what data was used and what was returned, for the agreed retention period	A person other than the builder picks a production transaction and reconstructs those three things from the records alone
Cost guardrails	An agreed cost envelope per unit of work and per period, with cost telemetry and an alert on budget breach	Cost shows on the operator view, and the envelope holds under real load at the limited-rollout gate
Outcome monitoring	Alerts fire on whether the work completed and the right result was delivered, not on whether a process is up	An injected outcome failure raises an alert, a liveness-only blip does not pass as success, and an injected stale input raises a freshness alarm
Failure behavior per dependency	Every dependency (model endpoint, source system, integration) has a specified behavior on failure: retry, fall back, degrade, or fail closed with a notice. Never a confident wrong answer	Each dependency is made to fail in turn, and the specified behavior is what you observe, including an explicit unavailable state

Who verifies the build, and what counts as done?

Someone other than the builder verifies it against the running system. Done means evidence from production, not a merged pull request or a demo. In the statement of work, the independent verifier, not the builder, is accountable for the acceptance record. It holds the four-layer proof (source, environment, running process, real outcome) with timestamps, plus your sign-off. See deploy and verify AI and liveness versus outcome.

What is not included in an AI production build?

These are out of scope unless added through change control:

Further use cases and re-validating the use case.
Training or fine-tuning from scratch. Bespoke training enters only as a change, if evaluation proves it necessary.
Fixing data quality in your source systems. We flag problems; the fix is yours unless scoped separately.
New platform infrastructure, such as a cloud landing zone.
Organization-wide change management or large-scale end-user training.
Running the system beyond the stabilization window, offered under Your AI Team.
Regulatory certification or legal sign-off. We build to the compliance requirements you supply and produce the evidence.

When is a production build the wrong next step?

The use case is not validated. Run a proof of concept first.
A pilot has stalled. Triage first: how to rescue a failing AI project and AI Rescue.
Several use cases compete. Prioritize them first.
The task is stable, rule-based and fully specified. In our judgment, conventional automation is cheaper to build and easier to audit, and AI is the wrong tool.
No one can grant access to real data or own the outcome. The data-integrity criteria cannot be proven without real data.

How long does an AI production build take, and what does it cost?

The AI Production Build starts from $40,000 and is phased, with milestone gates (NewGenApps engagements page, 2026-09-29). We publish no duration; the calendar is agreed at scoping. The figure is a floor, not a quote; the fee is set at scoping, after a free 30-minute call. AI Compass and AI Rescue fees are credited toward a subsequent build. Model usage, third-party licenses and cloud infrastructure are separate, billed at cost or paid directly by you. How much AI consulting costs explains how to read any quote.