Maturity models have a poor reputation in technology, and mostly deserve it. Many describe five levels with confident names, map them to dozens of criteria and produce an assessment that is out of date by the time it reaches the steering committee. Organisations score themselves at level three, plan to reach level four and change very little.
A maturity model is still useful if it does one thing well: helps leaders recognise where they actually are, so they invest in the next constraint rather than the most fashionable one. That needs few levels, each recognised by something you can see in the work.
Kalahari Assurance is fictional, and its systems and figures are illustrative. This last part uses Kalahari's journey through the series to illustrate the levels, and closes with the mechanism that keeps a programme current after its first year.
Four levels, recognised by signals
CloudNala uses four levels. This is our working model, built from the argument of this series, not an industry standard, and the levels are less important than the signals that identify them.
Level 1: individual experimentation
Individuals use AI tools in their own way. Some are highly productive. The organisation counts licences and usage.
The signal: usage is high and nobody can say what changed in delivery. Kalahari in 2025, with 80 per cent weekly active licences and a lead time that barely moved, was at level 1.
The next constraint: shared conventions and a safe toolchain. Without them, nothing individuals learn can be reused, and data handling depends on each person's judgement in the moment.
Level 2: team practice
Teams share instruction files, agree on approved tools and review agent output in a consistent way. A data rule exists and people know it.
The signal: shared instructions and approved tools per team, and the next person on a team inherits a working setup. Practices still vary between teams.
The next constraint: specification literacy, evaluation and ownership across teams. This is where Parts 3 and 5 do their work.
Level 3: governed delivery
Specifications with testable criteria and agent boundaries are normal. Agent changes run inside harnesses. MCP servers, skills and evaluation sets are registered and owned. The platform enforces the data rule and attributes cost.
The signal: specs, evaluations and registries are used in every change, not only in the teams that care most. Kalahari reached this level for its claims and broker teams during 2026.
The next constraint: learning from production. Governed delivery can be very consistent and still be consistently wrong if nothing feeds back from what happens after release.
Level 4: evidence-led improvement
Production evidence (incidents, escaped defects, cost per case, review effort, user corrections) flows back into standards, harnesses and training. Standards are revised on schedule. The curriculum changes when the work changes.
The signal: you can point to a standard, a harness check or a training module that changed because of something production taught you, with a date and an owner.
What it is not: a finishing line. Level 4 is a habit of improvement, and it can be lost if the people or mechanisms that sustain it are removed.
Using the levels honestly
Three rules make the model useful rather than decorative.
Assess teams, not the organisation. Kalahari's claims team was at level 3 while two integration teams were still at level 1. An organisation-wide average would have hidden both facts.
Use the signals, not self-assessment. "Do you follow the specification standard?" invites yes. "Show me the last three specifications and the tests their criteria map to" does not.
Invest in the next constraint only. A level 1 team does not need an advanced evaluation framework. It needs conventions and a safe toolchain. Skipping levels produces tools and documents that nobody can use.
The curriculum must change as fast as the toolchain
The other failure of most AI capability programmes is age. Material written for one tool version, one model generation or one way of working becomes wrong within months, and wrong training is worse than none, because it teaches people the wrong defaults with the organisation's authority behind it.
Kalahari's answer is a quarterly loop, owned by the guild described in Part 6:
- Toolchain or model changes. The platform team keeps a monthly log of material changes: new tool versions, model changes, new capabilities, retired features.
- Impact check. Each quarter the guild maps those changes to the standards and modules they affect. Most changes affect nothing. Some invalidate a whole module.
- Update standard and module together. A standard and the training that teaches it are changed in the same release, so people are never taught one thing while the platform enforces another.
- Retire stale material. Modules and examples that describe tools or practices no longer in use are removed, not archived where people can still find them. This is the step most programmes skip.
The loop also takes input from production evidence. If escaped defects keep tracing back to the same kind of ambiguous criterion, the specification module changes. That connection is what makes level 4 real.
A first year for a level 1 organisation
For an organisation where most teams sit at level 1, a realistic first year looks something like Kalahari's, adjusted to its own size.
First quarter. Run the no-blame tool inventory. Publish the one-page data rule. Measure one typical change end to end to find the absorbing stage. Reframe the existing workshop as the first hour of the shared foundations.
Second quarter. Stand up the approved toolchain with single sign-on and cost attribution. Build the registry and run server discovery. Rebuild the guild's core group with protected time. Run the specification module with two pilot teams, analysts, testers and engineers together.
Third quarter. Take the first three standards through the guild pipeline into platform defaults. Run the first capstones on real low-risk backlog items. Start the quarterly measures from Part 7.
Fourth quarter. Extend the role paths and capstones to more teams. Run the first full curriculum loop, including retiring material. Reassess each team against the level signals and plan the next year per team.
None of this requires a large budget. It requires a sponsor who will stop reporting usage as success, a platform team with time to build defaults, and the patience to measure the work rather than the training.
Bringing the series together
Across eight parts this series has made one argument from several directions: AI engineering capability belongs to the delivery system, and you build it by changing the system, not only by training the people in it.
| Part | The shift |
|---|---|
| 1 | From a prompting workshop to shared foundations with role depth |
| 2 | From training developers to training the whole path a change travels |
| 3 | From analysts' specifications to specification literacy in every role |
| 4 | From personal tools to a governed platform that is safe by default |
| 5 | From a server catalogue to a registry that records ownership |
| 6 | From a guild of enthusiasts to a guild that produces standards |
| 7 | From attendance and certificates to evidence in work products |
| 8 | From a static curriculum to one that keeps pace with the toolchain |
None of these shifts requires a large transformation programme to begin. Each can start with one team and one piece of real work, which is how Kalahari began. For the individual side of the same story, the Build Your Way into AI Engineering series describes how one practitioner builds credible skill, one system at a time.
Back to Part 1, AI literacy is not a prompting workshop. All parts are on the series page.
How CloudNala can help
We help technology leaders assess their teams against observable signals rather than self-assessment, identify the next constraint for each team and design a capability programme with a curriculum and standards loop that stays current. The assessment is short and evidence-based, and its output is a prioritised plan per team rather than a single organisational score.
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.
Plan an AI Capability Programme or write to us at consult@cloudnala.co.za