The Prototype Took 48 Hours. The Production Obligation Lasts Five Years.

The dangerous moment is not when an AI-built prototype fails in a demo. It is when the demo works, spreads quickly and becomes operationally invisible.

A usable interface appears in 48 hours. The workflow connects to real data. A director shares the link. Three teams start depending on it. Then the person who assembled it moves to another project, an API changes, a credential expires, or the first customer record lands in the wrong log.

Now the prototype is a production service, but nobody made the production decision.

I have spent more than 20 years in hosting and infrastructure. Code was never the full obligation. Production means somebody owns every night, upgrade, incident, access request, restore, audit and handover after launch. That remained true while scaling software from €600,000 to €240 million ARR, through 15-plus acquisitions and a €1.5 billion exit. AI makes building faster. It does not repeal operations.

Here’s what works: put an admission gate between “it runs” and “the business may rely on it.” The gate is not a 40-page committee ritual. It is a compact evidence package called the Production Admission Manifest.

The prototype has already created an obligation

Teams still classify software by who built it: product engineering, IT, an agency, a citizen developer or an AI coding agent. That is the wrong boundary. Classify it by consequence.

If other people depend on the output, if it touches sensitive data, if a failure blocks revenue or operations, or if it incurs recurring cost, the organization has a service obligation. The obligation exists even when the repository has only one contributor and the UI still says “beta.”

Google’s Site Reliability Engineering practice uses a Production Readiness Review before an SRE team accepts responsibility for a service. The review covers architecture and dependencies, instrumentation, emergency response, capacity, change management, availability, latency and efficiency.[3] The useful lesson is not that every internal tool needs Google-scale process. It is that production responsibility should be accepted explicitly, against evidence.

NIST’s Cybersecurity Framework 2.0 points in the same direction. It calls for established risk roles, lifecycle management of systems and software, tracked changes and exceptions, least-privilege access, monitored runtime environments, and backups that are created, protected, maintained and tested.[1] Those are not “security extras.” They are the minimum facts an operator needs before trusting a service.

The fastest builders therefore need a better finish line. “Deployed” is a technical event. Admitted is an operating decision.

The Production Admission Manifest

The manifest has ten fields grouped into four gates. Every field needs an owner, a piece of evidence and a pass/fail result. A paragraph of intent is not evidence.

Gate 1: Ownership

1. Accountable service owner. Name one person who can accept risk, prioritize fixes and approve retirement. “The innovation team” is not an owner. Neither is the vendor. A RACI chart can support the decision, but one accountable name must sit at the top.

2. Repository and change path. Record where source code, prompts, configuration, infrastructure definitions and deployment instructions live. Define who can merge, deploy and roll back. NIST’s Secure Software Development Framework recommends role coverage across the software lifecycle and version control that ties changes to accountable individual accounts.[2]

3. Support and retirement trigger. State who receives incidents, the support hours, the escalation route and the conditions that end the service. NIST explicitly includes advance notice of end of support and an end-of-life date in lifecycle policy examples.[2] A prototype without a retirement path becomes immortal shadow software.

Gate 2: Control

4. Identity and data boundary. List users, service identities, authentication method, roles, privileged actions, data classes and retention. Test one access revocation. A shared API key inside an automation tool is not an identity model.

5. Dependency and security record. Capture external models, packages, APIs, licences, data processors, secrets and known critical vulnerabilities. Define the patch owner and the response window. The goal is not perfect certainty. It is knowing what can change underneath the service and who reacts.

6. Audit and exception trail. Log material inputs, model or workflow version, actions, approvals, failures and overrides at the level needed to investigate an incident. Make exceptions visible. If a human bypasses the normal control, the system should preserve who did it, why and what happened next.

Gate 3: Reliability

7. Service level objective and observability. Define the user-visible outcome, an SLI and a target. Google’s SRE Workbook describes an SLO as a target reliability level and says it needs an owner empowered to trade feature velocity against reliability.[4] “The dashboard is green” is not an SLO. “At least 99% of approved requests produce a complete case pack within ten minutes” is testable.

Do not copy a fashionable target. Google’s worked example shows that a 99.9% success ratio across three million requests allows 3,000 errors; that is arithmetic, not a universal recommendation.[4] Pick a target from business consequence and current capability.

8. Backup, restore and degraded mode. Identify what must be recoverable: database, configuration, prompts, workflow state, object storage and access policy. Then restore it. A backup screenshot proves that a job ran, not that the service can return. Define the manual or reduced-service path when a model, vector store or upstream API is unavailable.

Gate 4: Economics

9. Full operating cost and ceiling. Include model calls, hosting, storage, observability, retries, third-party APIs, human exceptions, support and an incident reserve. Assign the cost to a team or service. The FinOps Foundation treats allocation, budgeting, forecasting and unit economics as distinct capabilities, and frames engineering responsibility as both operational and financially viable.[5]

10. Measurable value and renewal decision. Name the accepted business outcome: cases processed, support resolutions accepted, proposals approved, deployment lead time reduced. Set a 30-day value hypothesis and a review date. If value cannot cover the operating obligation, do not widen access because the demo was impressive.

This is the hidden leverage: admission forces the organization to price the obligation before usage makes the service politically difficult to stop.

Three admission outcomes—not one bureaucratic queue

A manifest should accelerate decisions, not create paperwork theatre. Use three outcomes.

Admit when all consequence-critical fields pass and residual gaps have funded owners and dates. The service can enter the supported catalogue.

Constrain when the value is promising but the evidence is incomplete. Limit users, data classes, transaction values or operating hours. Keep a manual approval boundary. Constrained production is legitimate when the boundary is explicit and monitored.

Retire or rebuild when no accountable owner exists, recovery cannot be demonstrated, the access model is unsafe, or the full cost exceeds measurable value. A working prototype can still be the wrong production asset.

The hard stop matters. Most shadow systems survive because every reviewer can recommend improvements but nobody has authority to say, “This is not entering production.”

What to reject immediately

Four patterns should fail the gate without debate.

• The founder credential: a personal account or shared token is required for the service to run.
• The invisible dependency: nobody can list the models, APIs, packages and data stores on the critical path.
• The backup assumption: backups exist, but no restore has been timed and observed.
• The orphaned value claim: users like the tool, but no accepted-output, cycle-time, quality or cost measure has an owner.

These are not edge cases. They are signals that the organization has confused access to software with ownership of software.

A 30-day proof path

Do not launch an enterprise-wide production governance program. Pick one AI-built tool already used by at least two people and prove the gate in 30 days.

Days 1–5: Expose the real service

Inventory the users, data, dependencies, credentials, deployment path, current support behavior and monthly cost. Interview the builder and one real user separately. Record where their answers disagree.

Classify consequence across four dimensions: business interruption, data sensitivity, irreversible action and external commitment. This decides how much evidence the service needs. A meeting-summary helper and a pricing approval agent should not face the same gate.

Days 6–10: Build the manifest

Name the accountable owner. Put source, prompts, configuration and deployment instructions under organizational control. Map identities and privileged actions. Define one user-visible SLI, one value metric and one cost ceiling.

Keep the artifact short. Ten rows are enough: requirement, owner, evidence link, pass/fail, remediation date and approver. If a field needs a policy essay, the operating fact is probably still unclear.

Days 11–20: Run the ugly tests

Revoke a real user. Rotate a credential. Restore from backup into an isolated environment. Break one upstream dependency. Roll back one change. Trigger a cost alert. Trace one output from request through model or workflow version to approval.

The test is not whether the team can explain what should happen. The test is whether the service behaves as claimed and the evidence is retrievable.

Days 21–25: Measure accepted work

Compare the service with the pre-AI baseline on complete outcomes, not generation speed. Measure accepted-output rate, median and P95 cycle time, human exception minutes, defect severity, failed requests and full cost per accepted outcome.

A fast average can hide an operationally lethal tail. P95 review time and repeated exception classes often reveal where the prototype is consuming senior attention.

Days 26–30: Decide

Hold a 45-minute admission review with the service owner, operator, security or data representative and finance owner where material. Choose admit, constrain, or retire/rebuild. Do not leave with “continue monitoring.”

Set the next review trigger: material dependency change, new data class, wider user group, incident, cost breach or six months—whichever arrives first.

30 days to proof means a decision backed by observed evidence. It does not mean every weakness disappears in a month.

What good looks like after the first month

The output is not a governance deck. It is an owned service record the next operator can use at 02:00 during an incident.

You should be able to answer, in under five minutes:

• Who can stop or change this service?
• Which identities and data does it use?
• What user-visible outcome is promised?
• What happened during the last restore and rollback tests?
• What does one accepted outcome cost?
• When will the service be reviewed or retired?

If those answers live only in the builder’s head, you do not own the system. You are renting continuity from one person.

AI-assisted engineering compresses creation. The operator advantage comes from compressing the path from prototype to accountable production without deleting the controls that make scale survivable.

Build quickly. Admit deliberately. Retire aggressively when the obligation outruns the value.

Book a 30-minute strategy call

Sources

[1] NIST, Cybersecurity Framework 2.0

[2] NIST, Secure Software Development Framework 1.1

[3] Google SRE, Evolving the SRE Engagement Model

[4] Google SRE Workbook, Implementing SLOs

[5] FinOps Foundation, Framework Capabilities