Enterprise AI projects rarely fail because of model answer quality. They fail at the seam between prototype and service: a team has an interesting prototype and no service that can be supported, reviewed, and safely operated. What closes that gap is a sequence of decisions, each with its own acceptance criterion. [7] The practical instrument for that is a 30/60/90 plan with explicit gates between phases. Why projects break at exactly that seam is covered in Why AI Delivery Fails After the PoC — and What Leaders Should Do.
Why a phased structure works
This field note describes a three-phase path from pilot to production. The goal is a sequence of decisions that can be defended in architecture review, security review, legal review, and operations handoff. [8] Every decision in that sequence has to survive the move to production. The organizational side of the same gap is covered in From AI Demo to Production: What Enterprise Teams Actually Need.
A 30/60/90 structure matches how enterprise teams absorb risk. The first month is for scope, controls, and proof that the problem is worth solving. The second month is for hardening the path from model to system. The third is for rollout and ownership transfer.
The three-phase plan
The table collects four things per phase: goal, key activities, the Go/No-Go gate, and the owner role. [6]
| Phase | Goal | Key activities | Go/No-Go gate | Owner role |
|---|---|---|---|---|
| Phase 1: 0–30 days | Prove the use case, define the operating boundaries, and confirm the system is worth taking forward | Validate business problem, identify data sources, define user journey, map security and privacy constraints, choose deployment pattern, document failure modes, identify human review points | A documented use case, an agreed scope, known data sources, and an explicit list of unresolved risks; unknowns must be visible and owned | Product owner with architecture and security leads |
| Phase 2: 31–60 days | Turn the prototype into a controlled service path | Build the service wrapper, add authentication and authorization, implement logging and traceability, define prompts and guardrails, create evaluation sets, test rollback paths, prepare support model | The system can be tested repeatably, the team can explain observed behavior, and security/privacy concerns have mitigations or accepted exceptions | Engineering lead with platform and security partners |
| Phase 3: 61–90 days | Operationalize the release and hand it to steady-state ownership | Complete runbooks, on-call paths, support escalation, incident response steps, access reviews, governance checks, release notes, and rollout plan | The service is supportable, monitored, and owned; operational risks are accepted by the right approvers | Delivery manager with operations and service owner |
Why 30/60/90 works
30/60/90 is useful because it creates decision points instead of open-ended work.
- By day 30, the team should know whether the use case is real, the data is available, and the risk profile is manageable.
- By day 60, the team should know whether the initiative can be engineered into a controlled service rather than a demo.
- By day 90, the team should know whether the service can be supported after launch.
This cadence also helps avoid a common enterprise pattern: a strong prototype that never gets a clear operational owner. The plan forces ownership to move from exploration to delivery to operations.
What if Phase 1 gate fails
If Phase 1 does not pass the gate, continuing to build in the hope that the answer will become clearer later usually does not help. The workable move is to stop, document the blocker, and either narrow the use case or close the initiative.
Common reasons for a Phase 1 failure include:
- the business problem is not specific enough,
- the required data is not available or not authorized for the intended use,
- the risk profile is too high for the current controls,
- the proposed workflow still depends on manual work that has not been acknowledged,
- the team cannot name a credible owner for production support.
If the gate fails, the initiative can still be valuable as a learning artifact. It may become a research note, a reference architecture, or later a gated asset once the missing controls exist. But it should not be presented as a production path until the blocker is removed.
What governance means concretely
The word "governance" is often used as a vague label. In practice, it is a set of named decisions and controls that answer a few direct questions:
- Who approved the use case?
- What data is allowed?
- Who can change prompts, models, and policies?
- How are outputs reviewed when the cost of an error is high?
- What is logged, retained, and reviewed?
- Who owns incident response and rollback? [3]
In an enterprise AI initiative, governance takes the form of a record of decisions, approval points, and operational controls. [1] Concretely, governance usually includes:
- a decision log,
- named approvers for privacy, security, legal, and architecture, [2]
- an access model for model endpoints and data sources,
- evaluation criteria for release decisions,
- a change process for prompts and model versions, [9]
- a support model for incidents and user reports.
Practical checklist
Use this as a working checklist before moving from pilot to production: [4]
- The business use case is specific and owned.
- Data sources are identified and approved for the intended use.
- Failure modes are documented.
- Human review is defined where required.
- Authentication, authorization, and logging are in place.
- Evaluation is repeatable and tied to release decisions.
- Rollback and escalation paths are documented.
- A production owner is named.
- Governance approvals are recorded.
Conclusion — stopping a project before release
A 30/60/90 plan does not guarantee success, but it does make failure earlier, clearer, and cheaper. That is often the difference between an experiment that consumes attention and an initiative that can actually enter production.
To apply the structure to an initiative of your own, spend the coming week laying the current pilot out by phase: write down scope, data sources, and acceptance criteria for the first thirty days, name an owner for each phase, and put the gate review date on the team calendar.
If an initiative is heading to production, check the transition criteria before a launch date is promised, and revisit scope, controls, and ownership at every phase rather than only at the end.
The diagnosis of where exactly the transition breaks is in Why AI Delivery Fails After the PoC — and What Leaders Should Do.
Sources
- AI Risk Management Framework — NIST — The risk management framework that governance work is built on
- AI RMF: Generative Artificial Intelligence Profile — NIST AI 600-1 — The risk profile specific to generative systems
- AI RMF Playbook — NIST AIRC — Concrete actions per framework function: Govern, Map, Measure, Manage
- Launch Checklist — Google SRE Book — A launch checklist: what must be ready before production
- Postmortem Culture — Google SRE Book — Incident reviews as a source of improvement rather than blame
- DevOps — Google Cloud Architecture Center — DevOps capabilities as a reference point for a 30/60/90 plan
- DORA metrics — The five DORA metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate, deployment rework rate
- Azure Well-Architected Framework — AI workloads — Architecture requirements for AI systems in an enterprise landscape
- Model Cards for Model Reporting — Google Research — A model card as a Phase 3 handoff artifact, documenting the model and its limits
