Most organisations with more than a handful of AI initiatives keep a list of them. It might be a spreadsheet owned by the AI team, a register maintained by enterprise architecture or a slide in the strategy deck. It records names, sponsors, status and perhaps spend.
That list is useful, but it is not a portfolio. A portfolio is a set of investments managed against each other: money moves from weaker ones to stronger ones because of evidence, and the whole set is judged against the objectives it was meant to serve. For that to happen, each investment needs to be recorded in a way that allows comparison.
CloudNala's position is that an AI portfolio is managed through a benefits ledger: one row per use case, linking strategic objective, investment, owner, baseline, target, evidence source, realised benefit, risk exposure and next decision, and updated on a fixed rhythm. The previous seven parts built each piece. This part puts them together.
Indigo Mutual is fictional, and its systems and figures are illustrative. Over this series its fourteen AI use cases have gained owners, baselines, instrumented journeys, a board dashboard, stop criteria and a transfer test for vendor claims. The ledger is where all of that lives.
One row, ten fields
Each row of Indigo Mutual's ledger has ten fields, in two groups.
The first five are fixed at approval and change only by a recorded committee decision:
- Objective: which strategic objective the use case serves, from a short controlled list, not free text.
- Use case: its plain-language name and scope.
- Investment: approved budget, with delivery and run costs separated.
- Owner: the business executive who owns the benefit, as described in Part 2.
- Baseline: the measured starting value, its date and the system it came from.
The second five are updated every quarter, each with the date of the update:
- Target: the expected value and date, adjusted only if scope changed by decision.
- Evidence source: the instrumented events or reports that measure progress, as built in Part 3.
- Realised benefit: split into evidenced and verified, as in Part 5.
- Risk exposure: position against the agreed risk boundary.
- Next decision: scale, hold, redesign or stop, with its date, as set out in Part 6.
The split matters. Fixed fields stop the goalposts moving: a use case cannot quietly lower its baseline or change its objective to look better. Dated quarterly fields create a history that shows direction, not just position.
Linking use cases to objectives
The objective field is the one that turns a list into a portfolio. When every use case is tied to one of a small number of strategic objectives, the board can ask questions that a list cannot answer:
- How much are we spending on AI against each objective?
- Which objectives have no AI investment at all, and is that deliberate?
- Where are several use cases pursuing the same objective, and do their benefits overlap?
That third question is how Indigo Mutual found its double-counted contact-centre savings in Part 2. Three use cases, one objective ("reduce cost to serve"), one benefit pool. Grouping the ledger by objective made the overlap obvious.
It also showed an imbalance. Of R96 million committed, nearly 60% served cost reduction, and very little served the group's stated growth objective in its lending book. That was not wrong in itself, but nobody had decided it. The ledger made it a decision.
Portfolio-level measures
Rolled up, the ledger produces a small number of portfolio measures that the board tracks over time:
| Measure | What it tells the board |
|---|---|
| Total invested vs total verified benefit | The honest return to date |
| Evidence ratio (verified ÷ forecast) | How far promises are being kept |
| Share of investment with an active owner | Governance health |
| Share of use cases with a decision due this quarter | Whether the portfolio is actually being managed |
| Stops and redesigns in the last year | Whether the organisation can change course |
| Spend by strategic objective | Whether the portfolio matches strategy |
The last-but-one measure may seem odd. A portfolio with no stops or redesigns in a year is not a healthy portfolio; it is one where nobody is looking. Indigo Mutual's committee now expects some movement every year and asks why if there is none.
The quarterly rhythm
A ledger that is opened only for the annual report decays into an archive of forecasts. What keeps it alive is a fixed quarterly cycle:
- Owners submit evidence. Each benefit owner updates their rows, with the evidence source attached, two weeks before the committee.
- Finance tests confidence. Finance checks new evidence, decides whether each figure stays at evidenced or moves to verified, and flags any rows where the evidence does not support the claim.
- The committee decides per row. Every material row gets a decision, recorded with its reason. Holds get a deadline.
- Funding is reallocated. Money released by stops and redesigns is moved, by decision, to use cases that have earned scale or to new proposals that pass the approval controls from Part 1.
Step four is the one most organisations skip, and it is the one that makes the rest worthwhile. If no money ever moves because of what the evidence said, the ledger is a reporting exercise. When money moves, owners start to care about their evidence, because it affects their funding.
What the ledger is not
A few boundaries keep the ledger useful:
- It is not a project tracker. Delivery status, milestones and issues belong in delivery governance. The ledger records investment and value.
- It is not a full business case. Each row points to the business case and benefit record, but stays one row.
- It is not only for AI. Indigo Mutual started with AI because the board asked about it, but the same ledger structure works for any discretionary technology investment. AI is often a good trigger for fixing benefits management across the whole technology portfolio.
- It is not a precision instrument. Benefits are estimated with honest ranges. The point is consistent, comparable evidence that supports decisions, not accounting-grade certainty.
Where to start
An organisation with an existing AI portfolio can build a first ledger in a few weeks:
- List every AI use case above a materiality threshold.
- Fill the ten fields for each from what exists today, marking gaps honestly as gaps.
- Assign an owner to every row that lacks one, or flag it for a stop decision.
- Hold the first quarterly review with the gaps visible, and give each gap a deadline.
The first ledger will be embarrassing in places. That is its value. The board will see, perhaps for the first time, which parts of its AI investment are evidenced, which are forecast and which nobody owns. Every quarter after that, the picture should get clearer and the money should follow it.
That is what the Boardroom AI Test comes down to. Not whether an organisation has an AI strategy, or how many people use its AI tools, but whether it can show, use case by use case, what its AI investment has produced, and whether it acts on the answer.
This is the final part of the series. Start again at Part 1, AI's boardroom honeymoon is over. Now prove the value, or see all parts on the series page.
How CloudNala can help
We help organisations build their first AI benefits ledger from the portfolio they already have: inventorying use cases, filling and validating the ten fields, assigning owners, setting materiality thresholds and running the first quarterly review alongside the committee. We then hand over a rhythm the organisation can run itself.
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 an AI Value Review or write to us at consult@cloudnala.co.za