Most organisations now build AI pilots faster than they build the habits needed to support them. A small team connects a model to a document store, shows something useful in a meeting, and within a few weeks a wider group of people is using it. Nobody decided to put it into production. It simply arrived there.
That pattern is not a story about reckless teams. Every step along the way is reasonable. The demonstration was good, people asked for access, the team obliged. The problem is that no step along that path was a decision to run a production service, so nothing a production service needs was ever put in place: an owner, approved data handling, a support promise, a cost ceiling, a recovery plan, a way to know whether it is actually helping.
CloudNala's view is simple. A pilot that works is the beginning of due diligence, not the end of it. Every material AI use case, internal platform and digital product should carry a visible maturity label, and moving to a higher level of trust should require evidence at a defined gate. Equally important, every gate should allow the initiative to be sent back for remediation or stopped, and retirement should be treated as a normal, governed outcome rather than an embarrassment.
This series sets out that lifecycle and how to run it. This first part introduces the four stages and the gates between them. Later parts look at what each stage promises, what "production-ready" should mean, why users are not the same as maturity, how due diligence works, how to graduate an internal developer platform, how to retire well, and how to report all of this to leadership.
Waterberg Mining Services is fictional, and its systems and figures are illustrative. It is a Mokopane-based contract miner that provides drilling, blasting and load-and-haul services at client mines across Limpopo and North West. When a new head of digital arrived, the executive committee handed over a list of "AI and platform projects" with one question: which ones could the company rely on? The list had 23 entries. None of them carried a label that answered the question.
Where the idea comes from
The Cloud Native Computing Foundation runs one of the clearest public maturity models in technology. Its project lifecycle places hosted open-source projects at one of four levels: Sandbox, Incubation, Graduated and Archived.
The descriptions are instructive. Sandbox projects are early and experimental, and the CNCF says plainly that "failure is a possibility". Incubating projects are gaining adoption and focusing on stability and maturity, with a slower rate of change. Graduated projects are mature projects whose adopters have demonstrated production readiness, which the CNCF describes as reaching "a reliable and trusted solution". Archived projects are inactive or low-activity projects no longer supported by the foundation's Technical Oversight Committee.
Movement between levels is not automatic. Applications for incubation and graduation go through due diligence led by a sponsor from the Technical Oversight Committee. That process includes interviews with adopters (the CNCF asks for five to seven), a period of public comment and a supermajority vote. The CNCF warns applicants to plan for months, not weeks. It also treats archiving as a defined process in its own right.
Two things in that model are worth borrowing directly. The first is that maturity has a name, and the name changes what people may expect. The second is that promotion requires evidence gathered by someone other than the project team, including the people who actually use the thing.
What should not be borrowed is the criteria. The CNCF model was built for open-source cloud-native projects. Its evidence is about maintainers from several organisations, community governance, licensing and ecosystem adoption. Those are not the right tests for an internal AI assistant that summarises shift logs at a mine. The enterprise version below is CloudNala's adaptation. It is inspired by the CNCF's discipline, but it is not a CNCF standard, and the CNCF has not reviewed or endorsed it.
The four enterprise stages
CloudNala uses different labels for enterprise portfolios, partly to avoid any suggestion that an internal system has passed a CNCF process.
| Stage | Purpose | Evidence expected | Decisions allowed |
|---|---|---|---|
| Experiment | Test a problem, hypothesis and approach in a controlled environment | Named sponsor, defined problem, restricted data, time and cost limit, documented assumptions, a simple evaluation | Continue, redesign or stop |
| Incubating | Prove repeatable use and operational feasibility | Product owner, user evidence, versioned interfaces, security review, evaluation baseline, basic observability, a support model, first unit costs | Expand carefully, remediate, or return to Experiment |
| Trusted production | Operate as a supported business capability | Stable release process, service levels, incident ownership, rehearsed recovery, access controls, audit trail, evidenced value, a cost owner, documentation, approved change process | Scale, maintain, or begin planning a replacement |
| Retiring or archived | Contain or remove a capability that should no longer grow | Retirement owner, user and dependency inventory, migration plan, data retention decision, support end date, residual risk acceptance | Decommission, preserve for reference, or replace |
Each label is a promise to everyone who encounters the system. An Experiment tells people that the data is restricted, the users are named testers, support is best effort and the whole thing may disappear. Trusted production tells them that someone will answer the phone at two in the morning and that the system has shown, with evidence, that it does what it claims.
The interactive version below lets you step through each transition, including the backwards ones.
What a gate is, and what it is not
A gate is a scheduled decision with a known list of evidence. It is not a committee that reviews slide decks, and it is not a formality that follows a decision already made in a corridor.
Three properties make a gate useful.
The evidence list is known before work begins. A team starting an Experiment should already know what it will need to show to become Incubating. Otherwise the organisation ends up evaluating enthusiasm rather than readiness, and teams reasonably feel ambushed when new requirements appear at the last minute.
Someone outside the team gathers or tests the evidence. The project team's confidence is not evidence. At Waterberg, the reviewer for each gate comes from a different part of the business, and interviews with users, the support desk and the security team are part of the pack.
Every outcome is legitimate. A gate that only ever says "promote" is a rubber stamp. Waterberg's monthly lifecycle review can promote, hold for remediation, return an initiative to an earlier stage or stop it entirely. Each decision is recorded with the evidence it relied on.
The promotion questions
Before any initiative moves up a level, the gate should get clear answers to eight questions:
- What problem is it solving, and is that problem still worth solving?
- Who owns the product, the operational service, the risk and the realised benefit?
- Which users or adopters have independently confirmed its value?
- What production evidence exists for quality, security, reliability and cost?
- Which interfaces and dependencies must remain stable for the people relying on it?
- Which blockers remain unresolved?
- What happens when the AI, or an external dependency, fails?
- What conditions will trigger redesign, rollback or retirement?
None of these questions are about the model. They are about whether an organisation has made the decisions that turn a working piece of software into a service people can depend on.
What Waterberg found
When the head of digital asked each initiative's sponsor to answer those questions, the 23 projects sorted themselves quickly. Eleven were honestly Experiments, including three that were already being used by more than a hundred people each. Six had enough evidence to call them Incubating. Three were genuinely Trusted production: the fleet telemetry platform, the payroll integration and the client reporting portal. Three more should not grow any further and were labelled Retiring.
The surprising part was not the count. It was that the three widely used Experiments had never been promoted by anyone. The shift handover assistant, the spares lookup chat and the toolbox talk generator had each been built quickly by a small team, shown to supervisors, and adopted. They had users, but no owner, no approved data handling, no support model and no cost ceiling. They were Experiments carrying the expectations of production services.
The label did not fix that, but it made the gap visible. Each of the three received a short list of blockers and a date for its first gate. Part 2 follows the shift handover assistant through that process.
Why the backwards arrow matters most
Most maturity models are drawn as a staircase that only goes up. That shape quietly teaches people that the only good outcome is promotion, and that anything else is failure.
A lifecycle that can send an initiative backwards, or stop it, protects the organisation in three ways. It stops known risks from being promoted with a promise to fix them later, which turns risk into operating debt. It frees teams to run honest experiments, because stopping one is a normal result rather than a career event. And it gives leaders a mechanism to retire systems that no longer earn their place, which is the subject of Part 7.
What to do this month
You do not need a new governance board to start. Three steps are enough.
- Inventory and label. List every AI use case, internal platform and digital product that people outside the build team are using. Give each one an honest label from the four above. Expect some uncomfortable results.
- Publish the evidence lists. Write down, on one page, what evidence each gate requires. Adapt the table above to your own risk appetite and data.
- Schedule the first gates. Start with the initiatives that have the most users and the least evidence. Those are where an incident, a data complaint or an unexpected invoice is most likely to come from.
For the operational side of running an AI product once it is promoted, see Production begins after deployment. For a checklist focused on AI-built software, see From prototype to production: the trust checklist.
Next: Part 2, Sandbox is a risk label, not a place to hide permanent systems. All parts are on the series page.
How CloudNala can help
CloudNala runs technology and AI maturity assessments. We inventory your current initiatives, classify their maturity and data exposure, identify the evidence missing for promotion, and recommend whether each one should scale, hold, be redesigned, consolidated or retired. We then help you set up a lightweight lifecycle process your own teams can run, with evidence lists and gate decisions recorded in a form leadership can read.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Technology and AI Maturity Assessment or write to us at consult@cloudnala.co.za