Jane, a developer in one of your teams, has spent three days on an intermittently failing test. She suspects a race condition in the payment reconciliation module and wants a model to read the code, the stack traces and the last few commits, then suggest where to look.

The approved route:

  1. Raise a ticket.
  2. Wait for security to review the use case.
  3. Wait for architecture to confirm the model is on the approved list.
  4. Discover the approved endpoint is provisioned per project, and hers is not one of them.

Several weeks, give or take. The workaround:

  1. Create a personal account with a model provider.
  2. Generate an API key.
  3. Install the client library and paste in the module.

About ninety seconds.

(The timings are illustrative, not measured, but anyone who has worked in a large organisation will recognise the shape.)

Jane fixes the bug before lunch. Nobody would call it malicious, and her colleagues would probably call it initiative. The organisation, meanwhile, has no record of which code left the building, under whose identity, or to which provider on what retention terms. Nothing has necessarily gone wrong; there is simply no way of knowing.

The system didn't fail to stop her; it made the unmanaged route the easier one, and she simply took it.

Welcome to Shadow AI.

This isn't hypothetical. In 2023, Samsung engineers reportedly pasted internal source code into ChatGPT while trying to fix bugs. The company’s response was to ban generative AI tools altogether [1].

Shadow AI is a demand signal

The usual response to Shadow AI is to clamp down: block the websites, remind staff of the rules, tighten what the company is allowed to buy. All of that has its place. None of it explains why people go looking for these tools in the first place, and none of it gets Jane’s bug fixed any faster.

It helps to separate three things that tend to get lumped together:

  1. People wanting AI to help with their work. That is usually a good sign, and it is widespread: Microsoft and LinkedIn found that 78% of AI users were bringing their own AI tools to work [2].
  2. Use that is genuinely unacceptable, such as pasting client data into a public chatbot, deliberately leaking information, or using services the organisation has good reason to ban.
  3. Workarounds, where someone with a perfectly reasonable need goes elsewhere because the official option was missing, slow or not up to the job.

Better internal tools will not stop someone who is determined to misuse data. That still needs rules, monitoring and consequences. The third group is different, because the organisation created it.

Every unnecessary workaround leaves behind a personal account nobody is tracking, information going somewhere nobody can see, and more clutter for the security team to wade through before they find the cases that really matter.

Banning things makes AI use less visible; it doesn't make people need it any less. They just find a quieter way to do it.

The paved road should be a service, not a policy statement

Most organisations already have an answer: an approved AI service. But an approved service is not a paved road. The term comes from Netflix, where the paved road was a set of supported tools engineers chose to use rather than were forced to [3]. That is a much higher bar.

If access takes three sign-offs and a fortnight, or the model cannot cope with the job, or it only comes as a chat window when the developer needs to plug it into their code, then the approval exists on paper and the workaround exists in practice.

A paved road worth using:

  1. Lets staff get access themselves.
  2. Uses their normal work login, so every request is tied to a real person and team.
  3. Has the rules built in, so most requests go straight through and only risky ones are stopped.
  4. Offers a quick way to ask for exceptions.
  5. Is pleasant enough to use that nobody looks elsewhere.

None of this is about keeping developers happy. Each item turns a written rule into one the system enforces by itself. “Developers may use approved AI with internal code” is a rule on paper. A check on what is being sent, and a setting that only passes it to providers who have agreed not to keep it, is the same rule working.

It also doesn't all need to exist on day one.

Start with work logins for one or two approved models and record usage automatically, then add tighter controls as use grows. Heavy controls on low-risk work drive people away. Light controls on high-risk work are hardly controls at all.

Easy isn't the same as safe, though. A paved road removes the reason to go around the rules. Making sure the approved route actually enforces them is a separate job, and it belongs to the control plane: the layer that sets the rules and applies them wherever AI is used.

Measuring whether it works

If the paved road is a service, it can be measured like one. The measures fall into two groups.

Is anyone using it?

  1. How long it takes to get access.
  2. How long until someone actually gets a working answer out of it.
  3. How much of the organisation’s AI use goes through the approved route.
  4. How quickly exceptions are approved.
  5. Whether people would choose it if they had the option.

The second matters more than the first. Getting access in a day means little if it then takes another week to make it work.

Is the risk going down?

  1. Personal AI accounts and keys turning up on work systems.
  2. Teams connecting directly to AI providers outside the approved route.
  3. Rules being broken, or attempts to get around them.
  4. Confirmed cases of sensitive information leaking.

This isn't theoretical either. IBM’s 2025 breach study found that one in five organisations had suffered a breach linked to Shadow AI, and only 37% had policies to manage or detect it [4].

Neither group proves much on its own, and both depend on how well you are looking.

Fewer Shadow AI cases may simply mean people have switched to the approved route, or that they have just got better at hiding.

Finding it takes several sources: scanning code for stray keys, watching what traffic leaves the network, checking login and cloud records, and sometimes expense claims. None of them sees everything.

A falling count from a weak detector is not good news; it's simply an absence of news.

The same developer, a different platform

Let’s return to Jane’s failing test.

In an organisation with a working paved road, she logs in with her normal work account. Her team was given access to approved AI for internal code months ago, once, rather than every time someone needs it. When she sends her question, the system checks three things:

  1. How sensitive the code is,
  2. What her team is allowed to do, and,
  3. As far as it can tell, what she has actually pasted in.

It then sends the request only to a provider approved for that kind of material, and records who asked, where it went and which rule applied, without keeping a copy of the code itself.

She still has her answer before lunch.

The difference is what happens if a log file she pastes in turns out to contain customer records. If the system spots them, it blocks the request or strips them out, tells her why, and shows her how to ask for an exception.

These checks will not catch everything, but they catch a lot.

The restriction is still there. It now sits where the risk is, rather than at the front of the queue.

Prohibition isn't an architecture

AI governance used to live in documents. Increasingly, it has to live in the systems themselves, checking each request as it happens.

A rule that only exists on paper relies on people reading it, remembering it and choosing to follow it, usually under a deadline. Jane did not set out to break the rules. She set out to fix a bug.

The goal is not to let anyone do anything. It is an approved route so easy to use that going around it would just be more effort.

Until then, every workaround is a design review that the platform team wasn't invited to.

*Jason Southgate leads Parakletos AI, a London-based AI and cloud consultancy focused on production AI systems where governance, reliability, and accountability matter.*

He has completed a University of Cambridge programme in data science, machine learning and AI.

Parakletos AI helps organisations use AI without losing control. They put identity, permissions and an audit trail around AI models and tools, so teams can move quickly and the business can account for what happened. This makes the governed route easier than the unmanaged one.

If you would prefer to buy a product rather than build, they can also help you.

References

[1] The Register, “Samsung puts ChatGPT back in the box after ‘code leak’”, 2 May 2023. https://www.theregister.com/2023/05/02/samsung_generative_ai_ban/

[2] Microsoft, “Microsoft and LinkedIn release the 2024 Work Trend Index on the state of AI at work”, 8 May 2024. https://blogs.microsoft.com/blog/2024/05/08/microsoft-and-linkedin-release-the-2024-work-trend-index-on-the-state-of-ai-at-work/

[3] Dianne Marsh, “The Paved Road at Netflix: At the Junction of Freedom and Responsibility”. https://www.slideshare.net/slideshow/the-paved-road-at-netflix/75867013

[4] IBM, Cost of a Data Breach Report 2025.