Shadow AI

What Shadow AI means

Shadow AI is AI used for work that the business has never approved or reviewed. The usual picture is a personal account on a consumer chatbot, opened on a phone because the approved route is slower or does not exist. The term is wider than that. It also covers an AI feature switched on inside software the business already pays for, and a browser extension nobody signed off.

The word that matters is not “AI” and not “unauthorised”. It is “reviewed”. A tool the business approved on a business account, with its data terms read and an owner named, is not shadow AI. The same tool used through a personal login is, because nobody has looked at what goes into it or what the terms say about it. The definition is about visibility before it is about permission.

Why the site treats it as the bigger Exposure

A written policy covers the tools the organisation chose on purpose. Shadow AI is, by definition, everything else, so a policy built only around the approved list misses most of what is happening. The governance article reports that 81% of employees and 88% of security leaders say they use unapproved AI tools at work. That is a gap wide enough that the people responsible for enforcing a policy are, by their own account, working outside it.

The same article cites a separate survey of 302 cybersecurity leaders. It found that 69% of organisations suspect or have evidence that employees are using prohibited public generative AI tools, and 60% said they lacked confidence they could identify the unapproved tools already running in their own environment. The research behind it predicted that more than 40% of enterprises will experience a security or compliance incident tied to unauthorised shadow AI by 2030. That is a prediction, not a measurement, and the site reports it as one.

What it costs

The governance article cites a widely quoted breach study. Organisations with a high level of shadow AI averaged 4.74 million US dollars per breach, against 4.07 million for organisations with little or none. That is a gap of 670,000 US dollars. These are the study’s figures as the article reports them and the site has not measured anything itself.

The number matters less than what it points at. A breach that starts in a tool the business did not know about is harder to trace, harder to contain and harder to explain to a client. The business cannot say what was entered, because nothing it runs recorded it.

What staff actually enter

The banning article describes the same pattern from the staff side. A July 2026 survey of 500 employed US adults, run by a law firm, found that 38% admitted entering at least one type of work information into a personal AI account their employer does not control. Some 23% had pasted in internal emails, memos or documents. Another 11.8% had entered customer or client information, 11.4% contracts or legal documents, and 10.6% employee or HR information.

An accountancy firm’s survey of more than 1,000 employees found 60% of workers rely on consumer AI platforms and not tools their company provides, and 28% said they would use AI at work even if it were banned. Both surveys are self-reported and were run by commercial firms, so the banning article asks readers to take them as direction and not as precise measurement. The direction is the same in both. People use AI because it is useful, and without an approved option they use whatever is closest.

Why it starts: silence, not defiance

The picture most managers carry is a workforce that was told no and is quietly saying yes. The data describes something else. In the law firm’s survey only 6.6% said their employer bans AI tools outright, and only 35.8% said their employer has a clear written policy on what work information may be shared. Forty per cent said no such policy exists and another 24.2% were not sure. That leaves 64.2% improvising.

The accountancy survey points the same way. It found 36% of workers said their company has a formal AI policy, and only 22% said their employer actively monitors AI use. So the real choice in most workplaces is not between a ban and permission. It is between a rule and silence, and shadow AI is what fills the silence.

Training is part of the same gap. The governance article reports that only around 22% of UK businesses have given staff involved in AI deployment any AI-specific governance training. The training article reports that only 19% of workers have been through a formal programme, and that most staff are experimenting on their own, which it names as often how shadow AI starts.

Why a ban does not remove it

A ban removes a tool but not the task. The client email still needs an answer by five o’clock, and the forty-page report still needs summarising before tomorrow’s meeting. The person facing that deadline has a phone and a personal account already set up, so the work gets done there. The risk has not gone down. The visibility has.

A survey of 25,000 UK workers by a professional services firm, reported in the trade press, found that almost one in ten had used an AI tool their employer had banned or would disapprove of. The banning article says the reporting does not state how many of those workers were under a formal ban, so the figure is a floor for hidden use and not a full count. The same survey found half of AI users had received no formal guidance or training.

A ban also teaches the wrong lesson about reporting. When all use is prohibited, a person who pasted the wrong document into a personal account has every reason to stay quiet, and the business hears about it later, usually from a client. The article’s point is that a rule treating all use as misconduct makes the honest report the riskiest thing an employee can do.

Why AI is hard to list now

It is no longer one app that a manager can name and block. The banning article notes that generative AI now sits inside email clients, meeting software, document editors and browsers, often switched on by default in products the business already pays for. A rule written as “no AI tools” has no clear edge, and staff are left to guess where it stops.

That is also why the ownership article reports 70% of senior technology executives saying teams were deploying technology faster than IT could track. The same article says the missing owner is replaced by the users: when nobody sets the rules, people set their own. A sanctioned assistant then ends up alongside personal accounts and browser extensions the business never chose.

What shrinks it

The banning article gives five steps in place of a ban. The first is an approved tool that is good enough, set up on a business account where data-handling and retention settings are under the business’s control, which a personal account never gives. If the approved option is slower or weaker than the personal one, people keep using the personal one.

The second is a one-page rule drawn by data, not by tool. It lists what may never be entered into any AI tool, such as client names and contact details, contracts, HR records, credentials and anything under a confidentiality agreement. It lists what is fine in the approved tool, and it says anything else goes to one named person first. Client and HR data is what the business’s data protection duties already cover, so the page adds no new principle. It makes an existing one usable on a busy afternoon.

The third is to explain the reason behind each line, because a rule people understand gets followed in cases it did not anticipate. That is where AI literacy does the work. The fourth is to ask each team before auditing, and the fifth is to set an owner and a review date. A rule filed once goes stale within months because new tools and features keep arriving.

Finding it without a witch hunt

The ownership article’s week one is the practical start. List what is in use by asking people and not by scanning accounts, and make it plain that the aim is to understand use and not to punish it. Include tools staff pay for themselves and AI features inside software the business already has. The result is a single page of tool, user and purpose, usually the first time anyone has seen the whole picture. That page is the AI tool inventory.

The banning article adds the tone. Open with the reassurance that nobody is being disciplined for an honest answer, and mean it. The answers are a list of needs the approved tool has to meet. A team that says it uses a personal account for meeting summaries has told you what the approved tool is missing, which is more useful than a scan and reaches the accounts a scan cannot.

A worked example

This is an illustration, not a real client. A 25-person professional services business finds that two people are summarising client calls in a personal AI account. Under a ban, the owner sends a warning email and the summaries carry on, now on phones where nobody can see them.

The owner asks the two people what the summaries are for and learns that follow-up notes take an hour after every call. The business then picks an approved tool with a meeting-summary feature and data terms that suit client material, and the one-page rule says call content goes in only through that tool. The approved route is now faster than the workaround, and the business can see what is used because it runs through an account the business controls. None of it needs a policy manual. It needs a conversation, a tool and a page.

When a Narrow ban is Right

None of this argues against ever prohibiting anything. The banning article says a specific tool can be unacceptable for a specific kind of data. If a consumer service’s terms let it retain and reuse what you enter, and the business handles client material under confidentiality obligations, that tool should be off the table for that material, and the rule should say so by name.

Regulated data is another case. Where GDPR applies to the personal data involved and no approved tool with suitable terms exists yet, the honest answer is not to use AI on that data until one does. The article says a good narrow ban has four parts: it names the tool or the data, gives the reason in a sentence, points to the approved alternative and says who to ask when a case is unclear. It also keeps the list short and dated, because the reason often expires.

How it connects to the rest of Governance

Shadow AI is the reason the order of governance work matters. The governance article puts the AI tool inventory first, because a policy written before anyone checks what staff use is a guess. Each listed use is then sorted by what could go wrong under risk classification, and each tool gets a named person under AI ownership. Where a person must check the output before it goes out, that is human in the loop.

The rules that result sit in AI governance. The briefing article adds one habit that stops shadow AI at the source. Say what is out of bounds, even though nobody has asked yet, such as client data and anything under an NDA. If it is not said in the briefing, it gets decided informally in the training room, and a vague answer in that moment is remembered as permission.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is treating shadow AI as a discipline problem. The banning article’s advice is to treat it as a gap in what the business has provided. The second is treating it as a list of banned products, when the exposure is the unreviewed use and a personal login on an approved product counts.

The third is assuming a policy exists because a ban does. Most staff in the surveys are working with no clear rule at all. The fourth is assuming a scan will find it. A scan reaches the accounts a business controls and not a personal account on a personal phone.

Where it goes wrong

One failure is the blanket ban with a quiet exception. A ban that managers bend because a deadline needs the work done teaches everyone the rule is optional, and that the way to ignore it is to say nothing. Another is an approved tool nobody tested on real work, so staff go back to the personal one within a week.

A third is the honest conversation held once and never repeated. New tools and features appear faster than a written rule gets updated, so the team conversations need the same review date as the page. The last is treating a rule as a control. A rule with nobody responsible for enforcing it is a document, and the governance article says so in terms.

Where it appears in an Audit

Shadow AI is what an audit tends to bring into view. The audit maps what is actually in use across the teams in scope and classifies each use against the rules that apply, which is the inventory and the sort described above done across every function and not just one. The AI audit page sets out what it checks. No audit substitutes for advice from a qualified lawyer on what applies to your organisation.

Training is the other half. The all-staff briefing on responsible and compliant use covers approved against third-party tools, data privacy and incident reporting, which are the three things shadow AI undermines. If you want every team’s actual use mapped, every audit begins with a discovery call, and you can get an audit to start one.