Governed AI Tool Access in Regulated Enterprises
The useful question is not whether staff may use AI, but what each role is authorised to do with it, against which data and systems, with what supervision and evidence. This eight-part series sets out a capability-and-authority model for regulated enterprises: why an approved model is not an approved use case, why coding agents are execution environments, what shadow AI reveals about missing routes and entitlements, the hybrid roles that sit between business and engineering, how pilot access becomes durable entitlement, what must be logged, and how to restrict a tool without killing learning. It follows Fynbos Capital Bank, a fictional South African bank; its systems and figures are illustrative. Regulatory references are general information, not legal advice. Research claims were checked on 5 November 2026.
8 articles
- Part 1The question is not whether staff may use AI. It is what they are authorised to do with it.Blanket access and blanket bans are both crude answers to AI tools in a regulated firm. Part 1 of Governed AI Tool Access in Regulated Enterprises replaces the yes-or-no tool list with a capability-and-authority matrix, and shows what a single entitlement must record.9 min read
- Part 2An approved model is not an approved use caseApproving a model answers questions about a provider, a contract and general behaviour. It says nothing about what the model is being used to decide. Part 2 of Governed AI Tool Access in Regulated Enterprises separates three approvals and shows how to tier use cases by what the output is used for.8 min read
- Part 3Coding agents are execution environmentsA coding agent reads files, runs commands, uses credentials and reaches networks under someone's identity. Governing it like a chat window misses most of the risk. Part 3 of Governed AI Tool Access in Regulated Enterprises maps the execution surface and sets out three environment tiers with their boundaries.8 min read
- Part 4Shadow AI is an architecture signalUnsanctioned AI use tells you where the approved architecture does not reach: a missing capability, a route that is too slow, a data path that does not exist or an entitlement nobody designed. Part 4 of Governed AI Tool Access in Regulated Enterprises shows how to read the signal and turn it into design work.8 min read
- Part 5The hybrid role problemQuants, analysts and actuaries write code, but they are not engineers, and their tools rarely stay personal. Job titles cannot decide their AI entitlements. Part 5 of Governed AI Tool Access in Regulated Enterprises bases access on where the output goes, and pairs hybrid builders with engineering at the point of promotion.8 min read
- Part 6From pilot access to durable entitlementAI pilots hand out access by list, with no scope, no owner and no end date, and the list quietly becomes the permanent access model. Part 6 of Governed AI Tool Access in Regulated Enterprises sets out a conversion review for the end of a pilot and the lifecycle a durable entitlement needs after it.7 min read
- Part 7What must be logged when staff use AILogging every prompt creates a sensitive data store and still misses what an agent did. Logging nothing leaves an investigation blind. Part 7 of Governed AI Tool Access in Regulated Enterprises sets out five log layers, which questions each one answers, and how capture should vary by capability and use-case tier.7 min read
- Part 8How to restrict a tool without killing learningWithdrawing an AI tool removes risk, and often removes the habit of experimenting along with it. Part 8 of Governed AI Tool Access in Regulated Enterprises shows how to narrow access instead of revoking it, run a fair withdrawal, and keep a practice environment and a visible route back.8 min read
Working through any of this in your own organisation?
These articles come out of delivery work rather than theory. If the problems in this series look familiar, a short scoping conversation is usually the quickest way to work out what is worth doing first.
Talk to CloudNala