Fynbos Capital Bank, a fictional South African bank, ran its general-assistant pilot the way most organisations do. A sponsor in each division nominated people, the platform team added their names to a group, and the group was given access. Six hundred people joined over three months. The pilot was declared a success, the budget was approved, and the group stayed exactly as it was.
A year later, an internal audit sample found that the group still included people who had moved to roles with access to restricted data, contractors whose contracts had ended but whose group membership had not been cleaned up because it sat outside the normal access process, and, in the sample alone, a few dozen people who had not opened the tool since the pilot's first fortnight. Nobody could say what any of them were entitled to use it for. The pilot list had become the access model by default.
Fynbos, its people and its figures are invented. The pattern is routine.
Experimentation is legitimate. Its access model is not durable.
There is nothing wrong with broad access during an experiment. It is how an organisation discovers which uses are valuable. When Bloomberg reported on 2 November 2026 that Goldman Sachs had narrowed access to some AI coding tools, the report carried a statement from a Goldman spokesperson to the effect that tools are made available to find the best uses and, after a period of experimentation that weighs productivity and risk management, go to the people best placed to use them long term. Read as reported, that describes exactly the transition this article is about: from experimental access to deliberate entitlement.
The problem is that most pilots never make the transition explicitly. Every AI pilot needs a graduation path and Sandbox is a risk label cover how the system itself should mature. This article is about the people's access to it, which tends to mature much later, if at all.
Five defects of pilot access
Pilot access differs from durable entitlement in five ways, and each is a defect once the pilot ends.
- Granted by list. Membership comes from a nomination, not from a role or a request with a purpose. Nothing ties it to the person's job.
- No scope. The pilot group gets the whole capability. There is no data class, use case or action authority attached to the individual.
- No owner. The pilot sponsor owned the group during the pilot. After it, nobody does.
- No expiry. The group has no end date, so it lasts until someone deletes it.
- Outside the normal lifecycle. Because the group was created by the platform team, not through the identity governance process, joiner, mover and leaver events do not touch it.
Any one of these would be a finding in a normal access review. Pilots routinely have all five.
The conversion review
Fynbos now ends every AI pilot with a conversion review. Each participant's access is decided individually, using evidence the pilot already produced.
Every participant falls into one of four outcomes.
- Convert. The person used the capability regularly, for a use that fits a role default or a registered use case. They receive a durable entitlement with the eight fields from part 1.
- Convert narrower. The person used it, but only for part of what the pilot allowed, or their role does not support the full scope. They receive a narrower entitlement, for example a lower data class.
- Lapse. The person stopped using it. Access ends on the pilot's close date. They can request it again through the normal route if a need appears.
- Refer. The person used it for something no existing entitlement covers. Their use goes to a use-case approval, as described in part 2, and access continues provisionally for a fixed period while that happens.
In Fynbos's general-assistant pilot, the illustrative result was 310 people converted, 90 converted narrower, 170 lapsed and 30 referred. The referred cases were the most valuable output of the review: thirty uses nobody had anticipated, each now going through a deliberate decision.
The evidence used is usage telemetry and a short form from each participant stating what they used it for. Volume alone is not the test. Someone who used the tool twice a month for a well-defined task converts. Someone who used it daily for something outside any approved use is referred, not rewarded.
The lifecycle after conversion
A converted entitlement then enters a lifecycle that the identity team already runs for other access. The point is to stop treating AI access as special.
Catalogue. Each capability has entries in the access catalogue, one per role default and one per requestable variation. Each entry names the capability owner, the data class, the environment and the approval route.
Request. Outside the role defaults, a person requests access with a use case. Low-tier requests are approved by the line manager within a published turnaround. Higher tiers add the capability owner and, where needed, risk.
Provision. Approval adds the person to a group managed by the identity governance system, never by hand.
Use. Usage telemetry is recorded against the entitlement, which part 7 covers.
Recertify. On a fixed cycle, the line manager and the capability owner confirm each entitlement is still needed. Fynbos gives reviewers the usage evidence beside each name, so that "approve all" is visibly a choice to ignore it. Entitlements with no use in the period are removed by default unless the reviewer records a reason.
Change or end. A role move triggers review of every AI entitlement against the new role. A departure removes them all on the same day as other access. An entitlement's expiry date removes it unless recertified.
Cost belongs in the record
Durable entitlements usually carry a licence or consumption cost, and in a pilot that cost sits in a central budget. After conversion, Fynbos attaches a cost centre to each entitlement. This is not mainly about recharging. It gives the line manager a reason to look at the entitlement during recertification, and it makes the cost of unused access visible to someone who can act on it. Governing the AI bill covers the broader cost ownership question.
Common mistakes
| Mistake | Consequence | Better practice |
|---|---|---|
| Keeping the pilot group as the production group | Access with no scope, owner or end | A conversion review that decides each person |
| Converting by volume of use | Heavy unapproved use is rewarded | Convert on use-case fit; refer unanticipated uses |
| Managing AI groups outside identity governance | Movers and leavers keep access | Provision only through the normal process |
| Recertification without evidence | Reviewers approve everything | Show usage beside each name; unused access lapses by default |
| No cost attribution | Nobody notices unused licences | A cost centre on every entitlement |
Start the conversion before the pilot begins
The conversion review is far easier if the pilot was set up for it. Fynbos now requires four things of any AI pilot before the first person is given access.
- A close date. Written into the pilot charter and set on the group itself, so membership expires automatically unless the conversion review extends it.
- A stated use per participant. One line on the nomination form: what this person expects to use the capability for. It costs a minute and gives the conversion review something to compare usage against.
- Telemetry from day one. Session metadata recorded against each person, as described in part 7, so that the review has evidence rather than recollection.
- A named owner for the group. The pilot sponsor owns it until the close date, and the capability owner owns whatever survives conversion.
None of these slows a pilot down. Each one removes a question that would otherwise be argued about in the final week, when the pressure is to declare success and move on. They also change the tone of the pilot. Participants know from the start that access is for a period and a purpose, so the conversion outcome is a decision they expected, not a surprise.
A word on fairness
Narrowing access after a pilot can feel like a penalty to the people who took part, especially those who built something useful. Fynbos reduced that in two ways. Every participant received their outcome with a reason and the route to request more. And the thirty referred uses were reported back to the people who discovered them, with a decision date, so that the discovery was credited rather than lost. Part 8 of this series returns to this: restriction is accepted far more readily when the route back is visible.
Key points
- Broad access is appropriate during an experiment. It is not an access model for afterwards.
- Pilot access has five defects: granted by list, no scope, no owner, no expiry and outside the normal lifecycle.
- End every pilot with a conversion review: convert, convert narrower, lapse or refer, decided per person on use-case fit, not volume.
- Run durable AI entitlements through the same lifecycle as other access: catalogue, request, provision, use, recertify, change or end.
- Show usage evidence and cost beside each name at recertification, and let unused access lapse by default.
Next: Part 7, What must be logged when staff use AI. All parts are on the series page. For the adoption evidence behind a conversion decision, see Your pilot has users. That does not make it mature.
How CloudNala can help
CloudNala helps organisations close AI pilots properly. We design the conversion review, define the catalogue entries and approval routes for each capability, connect AI entitlements to your identity governance lifecycle, and set up recertification with usage evidence, so that the access left behind after a pilot is access someone decided on.
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