AI Strategy27 October 20266 min read

The Boardroom AI Test — Part 5 of 8

What an AI value dashboard should show the board

A board does not need prompt counts. It needs, for every material AI use case, the investment, the value realised, how confident the organisation is in that value, the risk and the next decision. Part 5 sets out a one-page view and the evidence levels behind it.

#AI Value Realisation#AI Governance#Leadership#Risk Management

Board packs are designed for decisions. A financial report tells directors where money came from and went, a risk report tells them which exposures are rising, and a strategy update tells them whether major initiatives are on track. Each one is built around a question the board needs to answer.

AI reporting often is not. It tends to arrive as a collection of things the AI team can measure: users, use cases launched, models in production, a few success stories and perhaps a chart of spend. Directors are left to infer the answer to the question they actually have, which is whether to keep funding this, and where.

CloudNala's position is that an AI value dashboard should be designed backwards from the board's decisions. Those decisions are few: which use cases to scale, which to hold, which to redesign, which to stop, and whether the overall portfolio is producing enough value to justify its cost and risk. Everything on the page should help with one of those.

Indigo Mutual is fictional, and its systems and figures are illustrative. Over the previous four parts it discovered that its benefits had no owners, that three business cases double-counted the same contact-centre saving and that its usage dashboard was being read as a value report. This part shows what replaced it.

One page, one row per material use case

A board view of the AI portfolioINDIGO MUTUAL AI PORTFOLIO, ILLUSTRATIVEUse caseInvestedForecastEvidencedVerifiedRiskNext decisionClaims extractionR6mR14mR9mR7mLowScaleAgent assistR11mR22mR5mNot yetMediumRedesignStaff assistantR18mR30mR2mNot yetLowHold, measureCollections nudgesR3mR8mR4mNot yetMediumVerifyForecast R74m, evidenced R20m, verified R7m: the board sees all three, not one blended number
Four of Indigo Mutual's fourteen use cases, with forecast, evidenced and independently verified benefit kept in separate columns. Fictional organisation, illustrative rand values over two years.

Indigo Mutual's board view is a single table. Each material use case gets one row. The columns are:

ColumnWhat it shows
Use casePlain-language name the board recognises
InvestedCumulative cost to date, delivery plus run
ForecastBenefit promised in the business case, adjusted for any approved scope change
EvidencedBenefit supported by operational data against the baseline
VerifiedBenefit tested independently by finance or internal audit
RiskCurrent risk rating against the use case's agreed boundary
Next decisionScale, hold, redesign, stop or verify, with the date

"Material" matters. Indigo Mutual has fourteen use cases, but the board sees nine. Five small tools under a threshold of R2 million a year are reported as a single line, managed by the AI platform owner as a cost of doing business, as discussed in Part 4.

The decision column is the reason the table exists. Every row ends with a recommendation and its date. A row without a next decision is a row the board cannot act on.

Keep forecast, evidenced and verified apart

The single most useful design choice is keeping three benefit columns rather than one.

Three levels of confidence in a benefitLEVEL 1ForecastWho says so:the sponsorin the business caseLEVEL 2Operational evidenceWho says so:the owner, fromsystem data vs baselineLEVEL 3Independently verifiedWho says so:finance or internalaudit, after testing
Each step up needs different evidence and a different signatory. A board report that blends the three into one figure hides which level the organisation has actually reached.

A forecast is what the sponsor said would happen. It is a planning assumption, signed by someone with an interest in approval.

Operational evidence is what the benefit owner can show from system data against the baseline. It is stronger, but the person presenting it still owns the outcome and may read the data generously.

Independently verified benefit has been tested by someone without a stake in the result: finance, internal audit or an external reviewer, who has checked the baseline, the measurement method, the confounders and the arithmetic.

When Indigo Mutual first reported this way, the four use cases in the diagram showed R74 million forecast, R20 million evidenced and R7 million verified. That gap was not a scandal. Most of the use cases were young, and verification takes time. But it changed the conversation completely. Before, the board had been told about R74 million. Now it knew R7 million was solid, R13 million more was probable and R54 million was still a promise.

Blending the three into one figure hides exactly the information a director needs. The temptation to blend is strong, because a single large number makes the programme look good. Resist it.

Show cost honestly

The invested column should include everything the use case consumes, not just the AI line:

  • delivery cost, internal and external;
  • model, platform and cloud consumption;
  • licences;
  • the share of shared platform cost the use case uses, allocated on a stated basis;
  • human review and exception handling, where the use case created new work; and
  • change management and training.

Human review is the line most often missed. If a use case requires assessors to check every AI output, their time is part of its cost. Leaving it out flatters cost per outcome and can make a use case look profitable when it has moved effort from one team to another. The cost per accepted outcome view handles this properly.

Show risk as a boundary, not a colour

A traffic-light risk rating on its own tells the board little. Indigo Mutual reports risk against the boundary agreed at approval, the "risk boundary" control from Part 1: which failures, incidents or control breaches would force a pause. The dashboard shows whether any of those have occurred and how close the use case is to the limits.

For a claims extraction model, the boundary might be an error rate above an agreed threshold on payment-critical fields, or any incident where an incorrect extraction led to a wrong payment. For a customer-facing assistant, it might be any instance of advice outside the approved scope. The board sees the boundary, the current position and the trend, not a colour chosen by the team being reported on.

What stays off the page

As important as what is on the board view is what is not:

  • Raw usage figures. Active users, prompts and tokens appear only where they inform a decision, typically as adoption against target. The full usage dashboard stays with management.
  • Success stories. Anecdotes about a delighted user are pleasant and occasionally useful as colour. They are not evidence, and they should not sit beside figures as if they were.
  • Model and vendor detail. Which model a use case runs on matters to engineering. It rarely matters to a board unless it changes cost, risk or a dependency the board must understand.
  • Unbounded promises. "Transformational potential" without a forecast, owner and date belongs in a strategy discussion, not in the value report.

Behind the page

A one-page view only works if the data behind it is disciplined. Each row is drawn from the benefit records described in Part 2, updated quarterly by the benefit owner, with finance testing the evidence before the figures move from forecast to evidenced, and from evidenced to verified. Part 3's journey instrumentation produces the operational evidence. Part 8 assembles these into a portfolio ledger.

The page is also a timeline. Indigo Mutual keeps the previous four quarters available so a director can see whether a use case's evidenced benefit is rising, whether its cost per outcome is falling and whether a "hold" has become a habit. A use case that sits on "hold" for three quarters is, in practice, a use case nobody wants to stop. Part 6 addresses that directly.

A test for any AI board report

Before an AI report goes to a board, the person sending it can apply a short test:

  1. Does every material use case have a row with a next decision?
  2. Are forecast, evidenced and verified benefit shown separately?
  3. Does cost include run cost, shared platform cost and human review?
  4. Is risk shown against an agreed boundary rather than as an opinion?
  5. Could a director who reads only this page make the funding decision?

If the answer to the last question is no, the report is an update, not a decision instrument.

Next: Part 6, When should an organisation stop funding an AI use case?. All parts are on the series page.

How CloudNala can help

We design AI portfolio reports for executive committees and boards, from the benefit records and evidence levels underneath to the one-page view itself. That includes setting the materiality threshold, the cost allocation basis and the risk boundaries, so the first report the board sees is one it can decide from.


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