Shadow AI is an architecture signal

Fynbos Capital Bank, a fictional South African bank, had already settled its coding-assistant question once: after six months of broad access, an interim rule limited the tool to technology staff while access was redesigned around entitlements. While that redesign was under way, the bank looked properly at unsanctioned AI use for the first time. Its security team brought a list of findings to the architecture board. Personal chat subscriptions on expense claims. A browser extension that summarised web pages, installed on several hundred machines. Traffic to a transcription service from the treasury floor. A no-code automation tool connected to a shared mailbox by an operations team, with a consent grant nobody in technology had approved.

The security team's draft recommendation was a list of blocks. The chief architect asked a different question: what was each of these people trying to do that the bank's own platform did not let them do? The answers turned out to be more useful than the blocks. Each finding was a requirement the architecture had missed.

Everything about Fynbos in this article is invented. The pattern of reading shadow use as a design input is the point.

Two different responses to the same finding

Our article on shadow AI as a governance design problem covers the people and policy side: why careful professionals end up on unclear paths, how approval should be structured, and why disciplinary action is the wrong first response. This article does not repeat that. It takes the architect's view of the same evidence.

From that view, every instance of unsanctioned use is a data point with three parts: a job someone needed done, a data path they used to get information to the tool, and a route they took because the approved route did not serve them. Read together, those data points describe the shape of the gap between what the platform offers and what the work needs. A block closes one route. It does not close the gap, so the next route appears somewhere else.

Where the signal comes from

Fynbos did not need new monitoring to find shadow use. Most of the signal was already being collected for other reasons.

• Network and proxy records. Traffic to AI service domains, grouped by business unit. These show volume and which services, not content.
• Expense and procurement data. Personal or team subscriptions claimed back. These show who is paying for what.
• Endpoint and browser inventory. Installed extensions and desktop applications with AI features.
• Identity consent records. Third-party applications that users have authorised to access mail, files or calendars on their behalf.
• SaaS feature changes. AI features switched on inside products the bank already licenses, often by a vendor update.
• A no-blame survey. The only source that tells you why. The approach in From personal AI tools to a governed team toolchain is the right model.

Each source alone is partial. Joined by business unit and job, they give a usable map. Collecting and using this data is itself processing of employees' personal information, so the bank's privacy team defined its purpose and retention first. This is general information, not legal advice.

Five gaps the signal reveals

The governance article observes that discovered shadow use means the approved route is "missing, slow, unclear or less capable". The five gaps below refine that list for architects: a capability gap is the missing route, a latency gap the slow one, an entitlement gap the unclear one, and a data-path gap the less capable one. The route gap, where an adequate approved tool is simply in the wrong place, is new. When Fynbos sorted its findings by the reason behind them, nearly every case fell into one of these five. Each points to a different design fix.

1. Capability gap. The approved platform cannot do the job at all. The treasury team was using an external transcription service because nothing approved could turn recorded calls with counterparties into searchable notes. The fix is a capability decision: add it, or decide explicitly that the bank will not offer it and say why.

2. Route gap. An approved capability exists but is hard to reach. The general assistant could summarise web pages, but only inside a separate portal that required a fresh sign-in. The browser extension was one click. The fix is placement: put the approved capability where the work happens, as described in Good AI agents meet users where they already work.

3. Data-path gap. The approved tool works but cannot see the data the job needs, so people copy data to a tool that can. Operations staff connected the automation tool to the shared mailbox because the approved assistant had no governed connector to it. The fix is a governed data path: a connector with the right permissions, data-class rules and logging. Where the connector is an MCP server, The enterprise MCP gateway describes one place to enforce those rules.

4. Entitlement gap. The capability exists, but the person's role is not entitled to it and there is no request route for an exception. Analysts in the finance division used personal coding tools because the sandboxed coding capability from part 3 was only offered to technology staff. The fix is an entitlement design change: a role default, or a request route with a stated use case, as set out in part 1.

5. Latency gap. The person could get approved access, but not in time. An access request that takes six weeks loses to a personal subscription that takes six minutes. Tier 1 uses from part 2 are already approved once recorded, so the delay sits in entitlement requests and tier 2 approvals. The fix is a published turnaround for those, with a provisional entitlement while review completes.

The five gaps are worth separating because the fixes differ completely. Adding a capability does nothing for a route gap. A faster approval queue does nothing for a data-path gap. Treating all shadow use as one problem produces one response, usually a block, which fits none of them.

What Fynbos changed

The architecture board turned the findings into a short backlog, owned jointly by the AI platform team and the identity team.

The blocks came last, not first. Once each job had an approved route, the matching unsanctioned route was blocked or its consent grant revoked, with a notice telling people where the approved route was. Blocking after providing an alternative is enforcement. Blocking before is a guess about what people will do next.

Two of the five fixes were not technology changes at all. The route gap needed the existing assistant placed in a different part of the screen, and the latency gap needed a change to how access requests are approved. Both were cheaper than any block, and both removed more unsanctioned use than the blocks did. This is the practical case for asking the architect's question first: the most effective response to shadow AI is often a small change to the approved platform rather than a new control around it.

Signals to keep watching

Shadow use does not stop after one review. New tools appear, vendors switch on features, and new roles find new jobs to do. Fynbos now treats the signal as a standing input to the architecture, with three measures reviewed each quarter:

• Unsanctioned AI traffic by business unit, trended. A fall after a fix is evidence that the gap was the cause. A rise somewhere new is the next requirement.
• Approved capability usage against entitlements. Entitled people who never use a capability may have found it unusable, which is a route gap waiting to become shadow use.
• Time from request to entitlement. The shadow AI article lists time from a use-case request to a decision among its leadership measures. If the median creeps up, latency gaps will follow.

None of these measures is a count of policy breaches. They are measures of fit between the platform and the work. That is the architect's job, and it is why shadow AI belongs on the architecture board's agenda, not only on the security team's.

When the signal says no

Not every gap should be closed. When Fynbos found staff pasting restricted customer identity documents into a personal tool to extract fields, the answer was to route that job to the existing document-processing system, not to build a new AI path for it. Every signal deserves a deliberate answer, and a reasoned no is one of them; the approve-or-retire step in Shadow AI is a governance design problem is where that answer is published.

Key points

• Every instance of shadow AI is a data point: a job, a data path and a route that the approved platform did not serve.
• Most of the signal already exists in network, expense, endpoint, consent and SaaS records. A no-blame survey supplies the reasons.
• Sort findings into five gaps: capability, route, data path, entitlement and latency. Each needs a different fix.
• Provide the approved route first and block the unsanctioned one afterwards, with a notice pointing to the alternative.
• Track shadow use as a standing measure of fit between the platform and the work, and answer each signal deliberately, including with a reasoned no.

Next: Part 5, The hybrid role problem. All parts are on the series page.

How CloudNala can help

CloudNala helps organisations turn shadow AI findings into architecture work. We join the signals you already collect, sort them by the gap behind them, and produce a prioritised backlog of capability, route, data-path, entitlement and latency fixes, with a plan for retiring each unsanctioned route once the approved one is in place.

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