Fynbos Capital Bank, a fictional South African bank, had put the model on its AI gateway through a thorough review. Everything about the bank in this article is illustrative. Its security team had assessed the provider's contract, the hosting region, the retention terms and the way prompts were handled. The model had been tested on summarisation, drafting and question answering. It went onto the approved list with a green tick.
Four months later, Thabo, a credit analyst in the business banking division, showed his manager a time-saver. He pasted a borrower's management accounts into the general assistant, asked for a summary of liquidity and debt service cover, and asked it to suggest a risk grade on the bank's internal scale. The suggested grade went into his credit memo, lightly edited. His manager liked it and told the team.
Nothing in that sequence used an unapproved tool or an unapproved model. Every step was, technically, allowed. And yet a model approved for summarising policy documents was now contributing to credit decisions about real businesses, using confidential financial information, with no one having asked whether it was fit for that purpose. The approval had been given to the wrong thing.
What a model approval actually covers
Model approval is necessary. It answers questions that every use of the model inherits: who the provider is, what the contract says about data use and retention, where processing happens, how the model behaves on general tasks, and what the known limitations are. Identity before intelligence covers several of these at the platform level, including why a resource region does not settle where inference runs.
What model approval cannot cover is the use. The same model can draft a staff newsletter and propose a credit grade. Its general summarisation quality says little about whether it reads a set of management accounts correctly, whether it applies the bank's grading scale as the credit policy intends, or what happens when it is wrong.
The NIST AI Risk Management Framework makes this distinction structurally. Its MAP function "establishes the context to frame risks related to an AI system", and its first category is simply "Context is established and understood": intended purpose, the people involved, business value and risk tolerance. A model on its own has no context. A use case does.
Three approvals, not one
Fynbos now separates three approvals. Each is a precondition for the next, and none substitutes for the others.
Model approval. Owned by the AI platform team with security and procurement. Covers the provider, contract, data handling, region, general evaluation and known limitations. Reviewed when the provider changes the model or the terms.
Capability approval. Owned by the platform team. Covers how the model is wrapped for a capability: the gateway configuration, data-class rules, connected sources and tools, logging and the environment. Part 1 of this series described the four capabilities Fynbos offers. Each has its own approval, because the general assistant and the restricted change agent may share a model but differ entirely in what they can reach.
Use-case approval. Owned by the business owner of the process, with risk and privacy input scaled to the tier. Covers the purpose, the data used, what the output is used for, who reviews it, how quality is checked for this task, and what happens when it is wrong.
The credit memo case failed because Fynbos had the first two approvals and treated them as if they implied the third.
Our article on shadow AI as a governance design problem makes a related point from the practitioner's side: available, approved and suitable are different decisions. This article is about the organisation's side, specifically the use-case approval as a record the bank owns and maintains.
Tier the use case by what the output is used for
Not every use needs a committee. Fynbos tiers use cases on three questions, and the highest answer sets the tier.
- Where does the output go? Personal working notes are lowest. Output shared inside the team is higher. Output that reaches a customer, a regulator or a system of record is highest.
- What does it influence? A draft someone rewrites is lowest. A recommendation a person relies on is higher. A decision about a customer, an employee or a financial position is highest.
- What data does it use? Fynbos's four classes (public, internal, confidential, restricted) map directly.
Tier 1, registered. Personal productivity on public or internal information. The person records the use case in a short form, and it is approved by default under the general assistant's entitlement. Most uses sit here.
Tier 2, reviewed. Shared outputs or confidential data. The business owner approves, the platform team confirms the capability fits, and a simple task-specific check is agreed: for example, a sample of outputs reviewed each month against the source.
Tier 3, assessed. Customer-affecting decisions, regulated outputs or restricted data. Risk, compliance and privacy review the use case, a task-specific evaluation is run before launch, and the review step is designed into the workflow rather than assumed.
Thabo's use was tier 3 on where the output went (a credit memo) and what it influenced (a credit decision). The confidential data alone would have made it tier 2.
Readers of Shadow AI is a governance design problem will recognise a related five-level risk lens. The two fit together: its levels 1 and 2 broadly correspond to tier 1 and tier 2 here, and its levels 3 to 5, from advice on confidential information to autonomous action, all fall within tier 3, where the action authority recorded in the entitlement does the remaining work.
The credit memo case, redesigned
Fynbos did not ban the practice. The time saving was real, and a ban would have sent it to personal tools. Instead the credit risk owner sponsored a tier 3 use-case approval, and the result looked quite different from what Thabo had been doing.
- Purpose narrowed. The model extracts and summarises figures from management accounts into a fixed template. It does not suggest a risk grade. Grading stays with the analyst and the credit policy.
- Data path changed. The approval added a document-extraction path to the analytics workspace, separate from its read-only data products. Statements are uploaded there rather than pasted into a chat window, so the source document and the extracted figures are kept together.
- Task-specific evaluation. Before launch, the team ran the extraction against fifty historical sets of accounts whose figures had already been checked, and recorded the error rate per field. Two fields that were often wrong were removed from the template.
- Review designed in. The memo template shows each extracted figure beside a link to its source page. The approving credit manager signs off with the source visible.
- Owner named. The credit risk owner, not the AI platform team, owns the use case and its annual review.
There is a regulatory reason for the narrower purpose. Section 71 of the Protection of Personal Information Act restricts decisions with legal consequences, or that affect a person to a substantial degree, that are "based solely" on automated processing intended to provide a profile of that person, including their "credit worthiness". POPIA's data subjects include juristic persons, and the section refers to a decision about "him, her or it", so it can apply to business borrowers as well as individuals. Keeping the grade with a human analyst, who sees the source, is a design choice that respects the intent of that section rather than one that tests its exceptions. This is general information, not legal advice.
The use-case register
The record that holds all of this is a use-case register. Fynbos keeps it deliberately short: one row per approved use, with the tier, the owner, the capability it runs on, the data class, the review step, the evaluation evidence, and the next review date. Entitlements from part 1 point to a use-case row, so access can be traced back to an approved purpose.
The register also solves a problem that model approval alone creates. When a provider changes or retires a model, the platform team needs to know which uses depend on it. With a register, that is a query. Without one, it is a staff survey.
Common mistakes
| Mistake | What it looks like | The fix |
|---|---|---|
| Treating the model list as the use-case list | "It is on the approved list, so it is fine" | Three approvals, each with its own owner |
| One process for every use | A committee for a meeting summary, or no review for a credit grade | Tier by output destination, influence and data |
| Evaluating the model, not the task | General benchmark results quoted for a specific extraction job | A small, labelled test set for the task itself |
| Platform team owns every use case | The people who run the gateway approve credit practice | The business process owner owns the use case |
| No link from access to purpose | Entitlements granted for "AI" | Every entitlement points to a register row |
The evaluation point deserves emphasis. Evals that gate real work sets out how to build a task-specific test set, and the fifty-set test Fynbos ran is a small example of it. A use-case approval without task evidence is an opinion.
Key points
- Model approval covers the provider, contract, data handling and general behaviour. It cannot cover what the model is used to decide.
- Separate three approvals, model, capability and use case, each with its own owner and each a precondition for the next.
- Tier use cases by where the output goes, what it influences and what data it uses. The highest answer sets the tier.
- For high-tier uses, narrow the purpose, design the review into the workflow and test the specific task before launch.
- Keep a use-case register and link every entitlement to a row, so access traces back to purpose and model changes trace forward to affected uses.
Next: Part 3, Coding agents are execution environments. All parts are on the series page. For a broader governance frame, see AI governance: the framework your organisation needs before scaling AI.
How CloudNala can help
CloudNala helps regulated organisations separate model, capability and use-case approval. We design the tiering questions with your risk and privacy teams, stand up a use-case register linked to your entitlements, and run task-specific evaluations for the high-tier uses that matter most, so that approval follows the work the model is actually doing.
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 Access Review or write to us at consult@cloudnala.co.za