Fynbos Capital Bank, a fictional South African bank, had given staff broad access to coding agents for six months, then put an interim technology-only rule in place while it redesigned access around entitlements. When the redesign was finished, someone had to tell people the outcome, and the first draft of the staff notice was two sentences long. The interim rule would become permanent for non-technology staff from Friday. Questions should go to the service desk.
Lerato, who leads AI enablement at the bank, asked for a week to rewrite it. Her concern was partly the decision, which she thought could be narrower, and mostly what the notice would teach. Over those six months, several hundred people in markets, credit and finance had learnt to work with coding agents, mostly on their own time and initiative. Some of what they built was risky. Much of it was the most practical AI learning in the bank. A two-sentence withdrawal would tell all of them that experimenting had been a mistake, and the next time the bank wanted people to try something new, fewer would.
Fynbos, its people and its figures are invented. The trade-off is real in every regulated organisation that has let people try AI tools and now needs to tighten access.
Restriction has a cost that does not appear in the risk register
When a tool is withdrawn, the risk register records a reduction in exposure. It does not record three other effects.
Lost capability. The people who used the tool well lose a skill they were building. Some of that skill transfers to the approved tools. Some does not.
Stranded work. Tools, scripts and notebooks built with the withdrawn access still exist. Without a plan, they either stop working, which may break something someone depends on, or keep running with nobody able to change them.
A lesson about initiative. The people who experimented first learn that early adoption is punished. The organisation's next pilot recruits from a smaller and more cautious group.
None of these is a reason not to restrict. All of them are reasons to restrict carefully. AI literacy is not a prompting workshop argues that capability is built in real work. Withdrawing access to the work, without an alternative, withdraws the learning too.
Narrow before you revoke
Most restrictions do not need to be a switch from on to off. The entitlement record from part 1 has several fields, and each can be narrowed separately. Fynbos calls this the restriction dial.
- Data class. Allow the tool with internal or synthetic data only, instead of confidential or restricted data.
- Environment. Allow it only in the tier A sandbox from part 3, instead of on any workstation.
- Action authority. Allow drafting and running code in the sandbox, but not opening pull requests to shared repositories.
- Output destination. Allow personal analysis and team tools (levels 1 and 2 from part 5), but not business-critical or production tools.
- Duration. Allow it until a fixed date while a use-case approval completes, instead of indefinitely.
Turning one dial usually removes the specific risk that prompted the restriction while leaving most of the learning intact. In Fynbos's case the risk was coding agents reaching production data and producing tools that others relied on without review. Narrowing the environment to the sandbox and the destination to levels 1 and 2 removed both. So the bank did not make the interim rule permanent. Non-technology staff got the coding agent back in the sandbox, and lost only the ability to point it at production data from a laptop.
Some restrictions do need to be complete: a tool with an unacceptable contract, a feature that sends data somewhere the bank cannot accept, a product that cannot be configured safely. In those cases the dial is not available, and the rest of this article matters more. Even a narrowing needs some of it: at Fynbos, work built during the six months of broad access still had to be inventoried and sorted.
Run the withdrawal as a transition
Where access does end, or narrows significantly, Fynbos runs it as a transition with five steps rather than as a cut-off.
1. Explain the decision. The notice says what is changing, why, and which risk it addresses, in plain language. It names the person accountable for the decision. It does not imply that anyone did anything wrong, unless someone did, in which case that is handled separately and privately.
2. Inventory what was built. Before access changes, each affected person lists what they built with the tool that anyone else uses. Fynbos gave people a two-week window and a simple form. This is the same no-blame approach used to find shadow use in part 4.
3. Triage the built work. Each item goes to one of four outcomes: keep it at its current level under the new entitlement; register it as a business-critical tool with an owner and review; hand it to engineering as described in part 5; or retire it with notice to its users. Retirement is a legitimate outcome, and some tools deserve it.
4. Change access on a published date. The date comes after triage, not before, so nothing anyone depends on stops without warning.
5. Publish the route back. The notice ends with how someone regains wider access: the practical competence task from part 5, a use-case request from part 2, or the next intake into a pilot.
Fynbos's illustrative numbers: 140 items were inventoried. 60 stayed as personal or team tools, 35 were registered, 15 went to engineering and 30 were retired. None of the 140 stopped working without its users being told first.
Keep a place to practise
The most effective step Fynbos took was not about the restricted tool at all. It opened a practice environment that anyone in the bank can use after a short foundation module.
The practice environment is a variant of the tier A sandbox with three differences: it holds only synthetic data built to resemble the bank's real data structures; it has a set of exercises based on real problems people had brought to the AI enablement team, rebuilt with synthetic data; and it is explicitly a learning space, not a delivery environment, so nothing built there may be used for real work without going through the normal route. A zero-rand AI architecture is for learning makes the same distinction between a learning environment and a production promise.
The practice environment absorbs much of the curiosity that would otherwise become shadow use. It also produces evidence. The practical task from part 5 runs there, so people can show competence without first being given access to anything sensitive.
What managers should say
The staff notice is only part of the communication. Most people hear about a restriction from their line manager, and what the manager says shapes how it is received. Fynbos gave managers three short points to make, in their own words:
- What changes and why. The specific risk the restriction addresses, not a general statement about AI being dangerous.
- What stays. The capabilities and environments people keep, which in most cases is most of what they used.
- How to get more. The practice environment, the competence task and the use-case request route, with a named contact.
Managers were also asked to avoid one thing: describing the people who had used the tool most as the reason for the restriction. Several of them had been the bank's most useful early adopters, and part 4 of this series explains why their use was a signal about the platform, not a fault in them.
Measure whether learning survived
A restriction that kills learning does not announce itself. Usage of the restricted tool falls, which is the intended effect, and nobody measures what else fell with it. Fynbos tracks four signals for two quarters after any significant restriction:
- Practice environment use among the affected group. If it is low, the alternative is not reaching them.
- Requests for wider access through the published route. Zero requests may mean nobody wants it, or that nobody believes the route is real.
- Shadow use signals from part 4 in the affected business units. A rise means the restriction displaced the work instead of governing it.
- Completion of the practical task. The number of people who regain access by showing competence is the clearest evidence that learning continued.
Measure learning, not just activity covers the general principle. Here the specific question is whether the restriction changed what people can do, not only what they are allowed to do.
The series in one table
This is the final part of the series, so it is worth putting the eight parts side by side. One note on numbering first, because the series uses several scales: use-case tiers 1 to 3 (part 2) rate what an output is used for; environment tiers A to C (part 3) say where a coding agent runs; output levels 1 to 4 (part 5) say where a builder's work ends up; and the five risk levels in Shadow AI is a governance design problem rate a single use by information and autonomy. They measure different things and are meant to be read together, not converted into one score.
| Part | Decision it supports | Core artefact |
|---|---|---|
| 1 | Who may do what with AI | Capability-and-authority matrix; eight-field entitlement |
| 2 | Whether a use is approved | Three approvals; use-case tiers; use-case register |
| 3 | Where coding agents run | Execution surface; three environment tiers |
| 4 | What shadow use is telling you | Five gaps: capability, route, data path, entitlement, latency |
| 5 | Access for hybrid builders | Output-destination ladder; controls at the crossings |
| 6 | What happens after a pilot | Conversion review; entitlement lifecycle |
| 7 | What to log | Five log layers; capture by capability |
| 8 | How to tighten without losing capability | Restriction dial; withdrawal transition; practice environment |
Key points
- Restriction removes risk and can also remove capability, strand work and teach people that initiative is punished. Plan for all three.
- Narrow before you revoke: data class, environment, action authority, output destination and duration can each be turned separately.
- When access ends, run a transition: explain, inventory, triage, change on a published date and publish the route back.
- Keep a practice environment with synthetic data, so curiosity has a safe place to go and competence can be shown.
- Measure whether learning survived, using practice use, access requests, shadow signals and competence task completions.
This is the final part of Governed AI Tool Access in Regulated Enterprises. For role-based learning design, see Learning paths by role, not by tool.
How CloudNala can help
CloudNala helps organisations tighten AI access without losing what their people have learnt. We design the restriction using the narrowest dial that addresses the risk, run the inventory and triage of work built under the old access, set up a synthetic-data practice environment with exercises from your own problems, and measure whether capability survived the change.
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