Every organisation that has tried to slow down personal AI tool adoption has learnt the same lesson. People use the tool that helps them finish today's work. If the approved option is slower, harder to reach or less capable, they will use something else and stop mentioning it.
That is not a discipline problem. It is a design problem. The organisation has made the unsafe path the convenient one.
Kalahari Assurance is fictional, and its systems and figures are illustrative. In Part 1 a Kalahari analyst pasted policy wording, including a real policyholder's details from an example, into a personal chat tool to produce a cleaner summary. The acceptable-use policy prohibited it. The analyst knew that. The approved tool did not summarise long documents well at the time, and the deadline was that afternoon.
Kalahari's response was not to write a stricter policy. It was to make the safe tool good enough, and the default, so the choice disappeared.
Four steps, each adding one property
CloudNala describes the path from personal tools to a governed toolchain as four steps. Each keeps what made the previous one useful and adds one property.
Step 1: personal tools. Individuals choose and configure their own tools. This is fast and often where the useful discoveries happen. It is also invisible: nobody knows which data went where, what it cost or which practices worked.
Step 2: shared conventions. Teams agree on repository instruction files, prompt patterns, review rules and a small set of tools. Work becomes consistent within a team and reusable by the next person. It is still not safe by design, because conventions are voluntary.
Step 3: approved toolchain. The organisation selects tools against criteria (data handling, contract terms, logging, identity integration, cost model) and publishes which tools may touch which data. This makes the toolchain safe by policy.
Step 4: governed platform. The approved tools are integrated into the paved road. Single sign-on, data-class rules, cost attribution, audit logs, approved MCP servers and harness templates are configured once by the platform team, so the safe way is also the easy way. This makes the toolchain safe by default.
Most organisations jump from step 1 to a policy document that describes step 3, and never build step 4. The policy then competes with convenience and loses.
The one-page data rule
Kalahari's approved toolchain starts with a single table. It is deliberately short, because people need to remember it in the moment:
Three things make this table work in practice.
First, the "if assessed" cell is real work. Approved enterprise tools may process personal information only where the organisation has assessed the processing, the contract and the transfer, consistent with POPIA. CloudNala's traffic-light guide explains the reasoning in plain language. This article is not legal advice, and that assessment belongs with your privacy and legal people.
Second, the table is enforced by the platform as well as published. Kalahari's approved tools sit behind single sign-on, apply data-loss rules to obvious patterns such as identity numbers and policy numbers, and log usage against a cost centre. The table tells people the rule. The platform makes the rule hard to break by accident.
Third, "tolerated personal tools" exists as a row. Banning every personal tool outright pushes use underground. Allowing them for public information keeps experimentation visible and gives the platform team a source of ideas for what to approve next.
What the platform team builds
Step 4 is platform engineering, and it is easiest to describe by what a new team gets on its first day:
| Capability | What it gives the team | Why it matters |
|---|---|---|
| Approved assistants with single sign-on | Access without a separate account | Identity, offboarding and audit come for free |
| Repository instruction templates | A starting AGENTS.md and skill set per solution shape | Conventions are inherited, not reinvented |
| Harness defaults | Linting, tests, secret scanning and structural checks wired into the agent loop | Agent output is checked before a human sees it |
| Registered MCP servers | Owned, reviewed integrations into core systems | No orphaned servers (Part 5) |
| Cost attribution | Usage tagged to team and product | The bill has an owner, as in FinOps for AI |
| Data-class enforcement | Rules applied at the gateway and in the tools | Policy is a default, not a memory test |
This is the same pattern described in platform engineering for the citizen-and-agent era: the platform team's job is to make good practice the path of least resistance.
The trade-off
A governed platform is not free. It takes platform engineering time, it narrows tool choice and it can lag behind the newest tools by weeks or months. Some engineers will find it frustrating.
Kalahari manages the trade-off in three ways. New tools enter as "tolerated" for public data while they are assessed, so people can try them without waiting. The platform team publishes an assessment queue with target dates, so the lag is visible and bounded. And the guild (Part 6) can propose a tool for fast-track assessment if two or more teams need it.
The alternative, an open landscape of personal tools, has costs too. They are simply harder to see: data that left the organisation, conventions that cannot be reused, spend that nobody can attribute and practices that walk out of the door with the people who invented them.
Start by finding what people already use
No organisation starts at step 1 with a clean slate. By the time a toolchain programme begins, people are already using a mix of personal subscriptions, browser extensions, free tiers and features switched on inside SaaS products the organisation already pays for.
Kalahari began with a two-week, no-blame inventory. Every team was asked one question: which AI tools do you actually use for work, for what, and with which kinds of data? The head of engineering stated in writing that answers would not lead to disciplinary action. The platform team added what it could see from network and expense data.
The inventory found 31 distinct tools across about 400 people. Most were used only with public or internal information. A handful touched confidential or personal information, and those became the first priority, not for punishment but for replacement: the platform team asked what each tool did well enough that people chose it, and made sure an approved option did the same job.
Two lessons came out of it. First, the reasons people choose tools are usually specific and fixable, such as a long-document summary or a particular code language. Second, the inventory is not a one-off. Kalahari repeats a lighter version every six months, because new tools arrive faster than any approval process.
Training follows the toolchain
The toolchain and the curriculum have to move together. Kalahari's shared foundations (Part 1) teach the data table, the reasons behind it and how the platform enforces it. Role paths then teach each role to use the approved tools well. When the toolchain changes, the training material changes in the same release, which Part 8 returns to.
Next: Part 5, Why an internal MCP registry needs ownership. All parts are on the series page.
How CloudNala can help
We help organisations move from scattered personal AI tools to a governed toolchain: tool assessment criteria, a one-page data rule, the platform defaults that enforce it and a visible assessment queue so new tools are not simply blocked. We work with your platform, security and privacy teams so the safe path ends up being the easy one.
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