Most engineering organizations do not have an AI adoption problem. They have an AI visibility problem.
By the time leadership sits down to design an AI policy, engineers have usually been using AI tools for months: a personal coding assistant, a browser-based chat for debugging, an agent wired into a side project, a model called from a script no one reviewed. None of it is sanctioned. None of it is forbidden. It simply exists, outside the org chart.
That is shadow AI. And it is the real starting point for governance, whether leadership likes it or not.
What shadow AI actually is
Shadow AI is the use of AI tools and models in real work without organizational approval, visibility, or review.
It is the AI version of shadow IT, and it shows up for the same reason: people adopt what helps them do their job, faster than any central process can evaluate it. The difference is that AI tools touch source code, customer data, and decision-making, so the blind spot is more consequential than an unsanctioned file-sharing app.
The important reframing is this: shadow AI is not the failure. It is the information. It tells you which workflows were painful enough that engineers reached for help on their own.
Why it shows up in engineering first
Engineering is usually where shadow AI concentrates, and that is not an accident.
Anthropic's Economic Index, published February 10, 2025, showed AI usage concentrated in software development and technical writing tasks. GitHub's enterprise survey from August 20, 2024, updated April 15, 2025, found AI coding tools already broadly used across enterprise software teams, including in Germany.
In other words, by the time a formal policy is drafted, the baseline assumption should be that engineers are already using AI, not that they are waiting for permission. A governance effort that begins with should we allow this is usually answering a question reality has already settled.
The risk is not the tool. It is the invisibility
A sanctioned tool with clear rules can be a smaller risk than an unsanctioned one used carefully, because you can see it, review it, and improve it.
The danger of shadow AI is that the organization cannot answer basic questions about it.
| Question | Why invisibility makes it dangerous |
|---|---|
| What data is being shared with which tools? | Secrets or customer data may be leaving controlled boundaries |
| Which workflows depend on AI output? | A model change could silently degrade work no one is tracking |
| What review applies to AI-assisted changes? | Quality and security standards fragment per individual |
| Who is accountable if something goes wrong? | Nobody, because the workflow was never acknowledged |
None of these risks require malicious intent. They are simply what happens when useful behavior runs ahead of visibility.
How to find shadow AI without a witch hunt
The instinct to audit is right. The instinct to punish is not. If discovery feels like surveillance, engineers route around it and the visibility problem gets worse.
We would approach discovery as a survey of reality, not an investigation:
- ask teams directly and without penalty which AI tools they already use, and for what
- look at expense and subscription data for individually purchased tools
- check which tools have access to repositories, CI, and internal systems
- include contractors and service providers, who are easy to forget and explicitly in scope under AI literacy expectations
The framing matters. Help us understand what is already working surfaces far more than confess what you have been doing.
What to do once you can see it
Once shadow AI is visible, you have three honest options for each use, and the goal is to make a decision rather than to ignore it.
| Decision | When it fits |
|---|---|
| Bring into scope | The workflow is valuable and can be supported, reviewed, and standardized |
| Replace | A safer or better-supported tool path can do the same job |
| Retire | The risk outweighs the value, and the use should stop with a stated reason |
The most common right answer is the first one. Most shadow AI exists because it was genuinely useful. Bringing it into scope means giving it the things an approved workflow has: a boundary, a preferred tool path, a review rule, and a named owner.
That is the same operating model we apply to any AI workflow. Shadow AI just means the workflow already exists and now needs to be made legible.
The mistake of leading with a ban
The most damaging response to shadow AI is a broad ban issued before any approved alternative exists.
A ban without a path does not remove the behavior. It removes the visibility of the behavior. Engineers who were using AI in the open move to using it quietly, and the organization trades a manageable risk for an invisible one.
If you must restrict something, restrict it while naming what people should do instead. A boundary with a sanctioned path is governance. A boundary with no path is just a new reason to hide.
A discovery checklist
If we were helping an engineering organization get visibility this quarter, we would want answers to a short list.
| Question | Why it matters |
|---|---|
| Which AI tools are individuals already using? | You cannot govern what you have not inventoried |
| What data and systems can those tools reach? | This is where exposure risk actually lives |
| Which real workflows already depend on AI? | These are your first candidates to bring into scope |
| Do contractors and partners fall into the same picture? | They are in scope and easy to overlook |
| Is there a sanctioned path for the most common needs? | Without one, a ban only buys silence |
That is not a full governance program. It is the honest first inventory that everything else depends on.
How this connects to the AI Act
Shadow AI is also a regulatory blind spot, not only an operational one.
The EU AI Act, Regulation (EU) 2024/1689, expects deployers to ensure a sufficient level of AI literacy among staff and others acting on their behalf, and the European Commission's literacy guidance ties that obligation to the systems an organization actually uses. You cannot demonstrate appropriate literacy or human oversight for tools you have not acknowledged exist.
In that sense, surfacing shadow AI is not just good hygiene. It is a precondition for being able to claim, credibly, that AI use in the organization is governed at all.
Our view
We do not think the goal is to eliminate shadow AI. The goal is to end the invisibility.
Engineers reaching for AI on their own is not a discipline failure. It is a map of where the work is hard and where the official process was too slow to matter. The organizations that handle this well treat discovery as listening, bring the genuinely useful uses into scope, and only restrict what they have given people a real alternative to.
That turns shadow AI from a liability into the most useful adoption signal a leader has: a list of the workflows that mattered enough for people to improve them without being asked.
Sources
- Anthropic,
The Anthropic Economic Index, February 10, 2025 - GitHub,
Survey: The AI wave continues to grow on software development teams, August 20, 2024, updated April 15, 2025 - European Commission,
AI Literacy - Questions & Answers, accessed 2026-06-10 - EUR-Lex, Regulation (EU) 2024/1689, Article 4
Frequently asked questions
- What is shadow AI and why does it concentrate in engineering teams?
- Shadow AI is the use of AI tools and models in real work without organizational approval, visibility, or review. It concentrates in engineering because software development and technical writing are exactly where AI usage clusters most — Anthropic's Economic Index (February 2025) and GitHub's enterprise survey (August 2024) both confirm AI coding tools are already broadly in use across enterprise software teams. By the time a formal policy is drafted, the realistic baseline is that engineers are already using AI, not waiting for permission.
- Why is a broad ban on shadow AI the wrong first response?
- A ban without a sanctioned alternative does not remove the behavior — it removes the visibility of the behavior. Engineers who were using AI in the open simply move to using it quietly, trading a manageable risk for an invisible one. If a restriction is necessary, it must name what people should do instead: a boundary with a sanctioned path is governance, while a boundary with no path is just a new reason to hide.
- How should an organization discover shadow AI without triggering a witch hunt?
- Treat discovery as a survey of reality, not an investigation. Ask teams directly and without penalty which tools they already use, review expense and subscription data for individually purchased tools, check which tools have access to repositories and CI, and include contractors and service providers — who are easy to overlook but explicitly in scope. The framing matters: 'help us understand what is already working' surfaces far more than 'confess what you have been doing.'
- Does shadow AI create regulatory risk under the EU AI Act?
- Yes. The EU AI Act (Regulation (EU) 2024/1689, Article 4) requires deployers to ensure a sufficient level of AI literacy among staff and others acting on their behalf, and the European Commission's literacy guidance ties that obligation to the systems an organization actually uses. You cannot demonstrate appropriate literacy or human oversight for tools you have not acknowledged exist, so surfacing shadow AI is a precondition for credibly claiming that AI use in the organization is governed at all.
