What is shadow AI?
Shadow AI is AI that people use in a company without the company knowing it. The term comes from shadow IT, the older name for software that people adopt without IT’s approval. What puts the use in the shadow is missing visibility. Nobody responsible for technology, data or risk has a record of it, and nobody has decided whether it is acceptable.
It takes several forms, and the chat window is only one of them:
- Personal subscriptions. A person pays for an AI assistant and uses it on company work. In a small manufacturer we interviewed, the accountant has her own paid subscription, and the owner does not know whether or how she uses it on the books. He trusts her. Trust stands in for a policy.
- Features inside approved products. A vendor adds AI to software the company already owns, and a department switches it on.
- Things people build. Scripts, spreadsheet automations and small applications written with a coding assistant. One small manufacturer runs orders through spreadsheets and a webhook that the owner built and refines with a coding assistant.
- Agents. The next section covers them.
The people involved usually have a real task and found a faster way to do it.
What is a shadow agent?
A shadow agent is an AI agent that works in the company without being registered, reviewed or owned. An AI agent takes a goal, uses tools and business systems and carries work forward. It acts, where a chat assistant only answers.
Access decides the damage. A wrong answer in a chat window costs a correction. An agent connected to a spreadsheet, a mailbox or a customer system can change records. Read access and write access are different problems, and a shadow agent holds whatever its builder gave it. Nobody decided which of its actions are allowed, which need approval and which are blocked.
In one current case, a small manufacturer’s owner connected an agent to the company’s documents and order spreadsheets and placed it in the managers’ chat to answer where an order stands. It was in test when we spoke. The idea is sensible. The agent still needs defined limits and a named owner.
In a design we are building now, the agent owns the execution of its work, and people own business authority, governance decisions and approvals. The agent cannot change its own instructions, sources or permissions without approved change control. A shadow agent has no such rule.
Why do people use AI the company has not approved?
The shortest path to a result runs around the process. Four patterns recur in the interviews we run.
- The tool is faster than the process. A machining firm’s owner uses a paid chat assistant for reference calculations and quotes, and a desktop coding assistant to write simple lathe programs. He started with permit letters for imported equipment. No project was needed, and none was approved.
- Capability arrives with products the company already owns. In a specialty retailer, vendors add AI features that a department switches on by adding a subscription tier. A full AI system goes through IT’s approval cycle. Only the second path has a gate.
- Nobody owns the whole picture. In the same retailer, IT handles governance only where audits force it. Each department handles the rest, and no one is tasked with the overall strategy.
- Building has become fast. AI coding tools generate code very quickly, and people outside IT now build small tools of their own. In an engineer’s hands the result is good, because the engineer brings what the tool cannot: an understanding of what the system must do, how it should be built and how to check it. A tool built on the side often has neither that input nor a place on any list.
Solutions built this way sit outside the strategy and the rules. Tools arrive first. Rules arrive later, if at all.
What are the risks of shadow AI?
Governance exists to keep the use of AI predictable and safe, with a clear view of what it does. Shadow AI puts that at risk in four real ways:
- Legal and data exposure. Information can leak, data can be misused and the company can face legal exposure. An owner who does not know what the accountant enters into her own subscription cannot rule any of it out.
- Unchecked output. The machining firm’s owner verifies lathe programs in a toolpath simulation and keeps three-dimensional work out because it is too hard to check. Shadow use gets such a check only when its user thinks of it.
- Automation that depends on its builder. When the technology changes or the person leaves, the automation can fall apart and cause a business problem.
- Authority nobody decided. Exposure grows with authority. AI that drafts can be wrong cheaply. AI that acts in your systems cannot.
Two fears are overstated:
- That all unapproved use carries the same risk. Drafting permit letters with a chat assistant and letting an agent update order records belong in different tiers.
- That the answer is a ban. Governance that tightens until it brakes progress is one of the three ways governance fails, described below.
Shadow AI vs shadow IT
Shadow AI belongs to the same family as shadow IT, and in our governance scope it falls under technology selection and control. The differences are practical:
| Shadow IT | Shadow AI | |
|---|---|---|
| What appears | An application or service nobody approved | An assistant, an AI feature inside an approved product, or an automation or agent a person built |
| How it is found | Review of applications and infrastructure scans that flag what appears undeclared | The same scans find what is deployed. A personal subscription or a switched-on feature is not a deployment |
| What it does with company data | Stores or moves it | Reads it and produces output from it. An agent also acts on it |
| What goes wrong | Data sits in an unapproved place | Output nobody checked, actions nobody limited and automation nobody can maintain |
Because AI can arrive as a subscription, a feature or a script, no single discovery method covers it. The next section combines several.
How do you find shadow AI?
Governance starts with an inventory: which AI systems are in use, shadow AI first, in which areas and how. It is the first step of the governance cycle we use. Five moves build it.
- Ask each function. Ask what technology and business systems it uses. When someone mentions a bypass, ask what triggers it, who authorizes it and how the result is recorded. Ask without blame, because hard probing reduces trust.
- Ask how work arrives. One operations inventory, compiled from a website and from memory, missed the telephony platform and the team messenger, the two systems through which work entered and moved. Check how people reach each other before trusting a list.
- Check the products you already own. Find out which vendors added AI features and which a department switched on.
- Combine declaration with detection. In the specialty retailer, a builder submits what he will deploy, and the infrastructure team’s software flags anything that goes up undeclared. Detection finds what was deployed. Declaration brings the purpose and the owner.
- Add technical monitoring where it pays. Systems can monitor AI use, track which models are in use and keep audit trails.
Record each use by area, way of use and owner. Repeat the exercise, because new uses keep appearing.
How do you govern shadow AI without stopping the work?
What AI governance is in general is answered on the AI Validation & Control page.
Governance fails in three ways:
- None. Use of AI is chaotic, and the risks are large.
- For show. Policies exist, and practice has moved on without them.
- Clamped. The screws are tightened until governance becomes a brake on progress.
The cycle has four steps:
- Take the inventory of AI in use, shadow AI first.
- Assess the risk of each use.
- Set rules, constraints and standards from those risks, assign accountability and monitor.
- When practice and rules diverge, decide which one is wrong. Change the rule, or bring the practice back in line.
Control is tiered by risk. Sensitive areas get tighter limits, and low-sensitivity areas stay relaxed. Actions fall into tiers too, as in this brief for a coding assistant:
| Action tier | Control | Example |
|---|---|---|
| Allowed | Within the assistant’s authority | Read the workspace, edit drafts locally, run tests |
| Approval required | A named person approves | Install packages, delete files, run scripts that reach external networks |
| Blocked | Not possible | Push directly to a remote branch, bypass compiler checks |
Guardrails come in two kinds. Hard barriers block what must not happen: permission gates, data masking, stop conditions. Soft guides steer the work toward the right outcome: role and goal instructions and written quality standards. Barriers alone keep AI inside the lines but do not help it reach the destination. Use barriers for sensitive data and sensitive actions and guides for the rest.
What should a shadow AI policy say?
A policy that people can follow is short. It names who decides, says how to register a use and tells people what to do as well as what to avoid. It covers five points:
- Both entry paths. AI features switched on in products the company owns, and new AI systems. A policy aimed only at new systems misses the first.
- Owners. Each area has a named owner. A working structure has no area with unknown, unclear or overlapping responsibility.
- Registration and tiers. How a use is declared, what needs approval, what needs registration only and what is blocked.
- Gates and evidence. An industrial technology company regulates outcomes and gates: defect reporting, root-cause analysis and named milestones. How a team works between gates is its own business. Applied to AI, check sensitivity and authority at the gates and leave the method to the people doing the work.
- Waivers. A request to deviate gets a decision: refuse it, change the rule or grant a documented waiver. A deviation is allowed when it is known and recorded.
A policy made only of barriers leaves a gap. In one software division, security and compliance are enforced in the pipeline, the rest is left to each team and there are no reference implementations to follow. Guides fill that gap.
Do you need an AI governance team?
Not as a separate body to start with. A specialty retailer we interviewed governs AI without one. IT handles only what audits force, such as who has access to what, and each department handles the rest. Three mechanisms carry the load:
- Declaration plus detection. Builders declare what they deploy, and infrastructure software flags anything undeclared.
- Audits twice a year. For the financial systems, each code change must trace to an approved ticket.
- A steering committee. Executives decide which initiatives go ahead.
This works for what is deployed and audited. It misses what nobody declares, such as a switched-on feature or a personal subscription. Named owners and a working loop matter more than a team.
Much of the governance work itself can be automated by agents, because it happens in digital systems: discovery, monitoring and checking uses against the rules. Accountability stays with a named person, who owns the rules, the acceptance of risk and the exceptions. Our working rule is that execution is automated by AI and controlled by people, with as much of the control as possible automated.
What do you do with the shadow AI you find?
Sort each use into one of three outcomes:
| Outcome | When | What happens |
|---|---|---|
| Keep | Low-sensitivity use that helps one person | It stays and is registered with an owner |
| Connect | The use is valuable, repeated or touches company data or systems | It gets a place in the strategy and is rebuilt or connected to company knowledge, systems and access rules |
| Stop | The use sends sensitive information where the company cannot allow it, or acts in systems without limits | It is retired, and where the need behind it is real, an approved path to the same result replaces it |
The strategy is the filing structure that makes this possible. Teams keep building ad-hoc automations. If each has a known slot in the model, it can later be rebuilt or connected without breaking anything. Pilots already running become evidence of what works and what the company still has to prepare. AI Organization Strategy builds that structure: the target state first, then the current state, which includes the AI already running, then the path between them.
The same idea applies to applications that employees build with AI. Such an application suits well-structured work that no business system covers. Building it properly is software development, which our software lifecycle practice runs in five steps: requirements in one short document, user experience, architecture, generation of the application with its tests, and packaging and release. The process stays the asset while the AI coding tool can change.
How EIC builds governance into AI execution
Governance is part of how we build AI execution. AI Validation & Control builds validation gates, action controls, correction and escalation into execution. Control does not sit in a policy next to the system. The rules that decide what AI may do sit where the AI works, and only exceptions that need judgment or authority reach a person. We define governance early, with roles, responsibilities and rules, using reference models from AI strategy engagements for several companies.
AI Organization Strategy supplies the structure: the current state, including the AI people already use, the target state and a phased roadmap in which each use has a place.
We do not certify against frameworks such as the NIST AI RMF or the EU AI Act, and we do not give legal advice. We build the operational side they ask for: quality criteria, logged actions, permissions on sensitive functions, oversight at defined points, escalation and records. Short answers on governance and guardrails are in the FAQ on the AI Validation & Control page.
