Shadow AI: when banning AI leaves a company blind

A company does not always get to choose between allowing artificial intelligence and banning it. In many organisations, the real choice is becoming something else: governed AI or clandestine AI.

Imagine a situation that is becoming less hypothetical by the day.

A lawyer has to review an eighty-page contract. A financial analyst needs to compare three reports. An HR employee has to sort fifty CVs. A salesperson wants to prepare a proposal using emails, notes and client documents.

They all know that an artificial intelligence tool can turn hours of work into minutes.

But the company has no approved solution. Or it does, but it performs far worse than the tools the employee uses in their personal life. Or its policy is so restrictive that any reasonable use requires authorisation, forms or procedures that are incompatible with the normal pace of work.

So the employee opens their personal ChatGPT, Claude, Gemini or other account, pastes in the document and carries on.

The company believes it has banned artificial intelligence.

In reality, it has simply lost sight of it.

Shadow AI

The term Shadow AI refers to the use of artificial intelligence tools outside the systems an organisation has approved, supervises or even knows about.

This is not an entirely new phenomenon. For decades, there has been shadow IT: employees who start using applications, cloud storage or external services because they solve a problem better than corporate tools do.

The difference is that AI can turn that behaviour into a direct transfer of knowledge.

The user is no longer simply installing an application.

They may feed it a contract, a database, a business strategy, a piece of code, a client file, a financial report, an internal communication or personal information.

And they can do it in seconds.

The figures change. The pattern does not.

The available surveys do not use exactly the same populations or definitions, so their percentages should not be conflated.

But they point fairly consistently in the same direction.

The 2025 international study led by the University of Melbourne in collaboration with KPMG, based on more than 48,000 participants across 47 countries, found that almost half of employees who used AI admitted doing so in ways that contravened their organisation's policies. In Norway, the published figure was 47%. The same study also found high levels of undisclosed use and reliance on AI output without checking its accuracy.

An international PagerDuty survey conducted in 2026 among 1,250 office professionals outside IT roles at large companies in the United States, the United Kingdom, Australia and Japan found that 66% of those who had used AI at work had done so even though they believed company policy did not permit it. Some 39% said they would rather use it without telling anyone than risk being told they could not. Another 30% said they would hide that use because of restrictive policies or fear of being judged by their colleagues.

The precise percentages matter less than the phenomenon.

When a tool offers a sufficiently large productivity advantage, a ban does not guarantee that people will stop using it. It may simply push that use out of the organisation's field of vision.

The security paradox

This is where the central problem emerges.

A company may adopt an extremely restrictive policy precisely because it wants to protect sensitive information.

The intention may be entirely reasonable.

But if, in practice, complying with the policy means spending three hours on a task a professional knows they could complete in twenty minutes, there is an enormous incentive to find another way.

And that alternative will be precisely the one over which the company has the least control.

The security team may thus have created an apparently very secure environment and, at the same time, an organisation that is actually less secure.

Because it no longer knows which tool is being used, which account controls it, what information goes into it, where that information is processed, how long it is retained, which integrations are enabled, which third-party services are involved or what output subsequently finds its way into professional work.

The risk is not simply that “the model will learn from our data”

This debate is often reduced to a simple warning:

“Do not put confidential information into ChatGPT because it could be used for training.”

That depends on the provider, the product, the settings and the contractual terms. Many enterprise solutions offer safeguards that differ considerably from those applicable to personal accounts or free services.

The problem is broader.

When an employee enters company information into an external system, they are changing the path that information takes.

There may be storage, technical logs, supporting providers, connectors, tools invoked by agents, processing in different environments or temporary copies.

PagerDuty found in its survey that 43% of participants had entered professional correspondence into public AI tools; 34%, customer information; 31%, financial information; and another 31%, confidential documents or business strategies. Its sample does not represent every worker in the world, but it illustrates quite clearly the kind of risk this phenomenon creates.

It does not take a major database leak.

A single document may be enough.

Legal obligations do not disappear because the tool is personal

At this point, the problem ceases to be purely technological.

The specific rules vary by country, but using a personal account does not automatically remove a company's legal obligations or an employee's professional duties.

In the European Union, for example, the GDPR requires controllers to implement appropriate technical and organisational measures and be able to demonstrate compliance. It also requires a level of security appropriate to the risk and expressly includes unauthorised access or disclosure among the risks that must be managed.

If Shadow AI use causes a personal data breach, the organisation must also determine whether the notification requirements apply. Where a breach is notifiable, the GDPR generally requires notification to the authority without undue delay and, where feasible, within 72 hours of the controller becoming aware of it. Not every unauthorised use of AI automatically constitutes a notifiable breach, but an organisation that cannot establish where its data is circulating will clearly have greater difficulty detecting, investigating and assessing an incident.

And there are other layers of obligations beyond data protection.

Lawyers, doctors, financial institutions and other regulated professions may be subject to specific duties of professional secrecy, confidentiality, safekeeping or care. The rules differ between jurisdictions, but the practical principle is similar: moving a document into a tool the organisation does not control does not remove the duty that protected that document beforehand.

Literacy is also becoming an obligation

Legislation is also beginning to recognise something that, for years, was treated simply as internal training.

In the European Union, Article 4 of the AI Act requires providers and deployers to take measures to support the development of AI literacy among their staff and others operating the systems on their behalf. The provision began to apply in February 2025 and was revised in 2026 by the Digital Omnibus to clarify that the obligation is to take supporting measures, rather than to guarantee that every individual achieves a particular level.

This is a European rule, not an international one. Its incorporation in the EEA EFTA countries follows its own procedure; for example, in late September 2026, both the AI Act and its amendment were still awaiting incorporation into the EEA.

But the direction is significant.

Teaching people to use AI properly is ceasing to be solely an HR initiative. It is becoming part of governance.

The counterargument: some things should be prohibited

None of this means a company should allow every tool or every use.

Some information must not leave particular systems.

It may be entirely reasonable to block services, use DLP, restrict domains, prevent certain connectors from operating or prohibit specific categories of data in external models. In highly regulated sectors, some restrictions may be essential.

A small company may not have the budget to deploy the most advanced enterprise platform on the market, either.

But that does not contradict the argument.

Technical controls and a useful alternative complement each other; neither replaces the other.

A company needs to prevent certain behaviours while also providing a reasonable route for the legitimate professional needs that drive those behaviours.

If it builds only the wall and not the door, someone will eventually look for a window.

Not all data needs the same architecture

One of the most common mistakes is to apply the same policy to everything.

A question about publicly available legislation does not pose the same risk as a client file. A generic sales draft is not equivalent to a confidential corporate transaction.

A policy can be far more useful if it classifies information and tasks.

For example, an organisation could establish an architecture along these lines:

• Public or low-risk information: previously approved external models.
• Routine internal information: enterprise accounts procured and configured by the organisation.
• Sensitive information: specifically approved tools, additional controls, logging and connector restrictions.
• Confidential client information or trade secrets: local processing, pseudonymisation or minimisation before using external services.
• Extremely sensitive information: processing exclusively within controlled infrastructure where the risk justifies it.
• Consequential outputs: human review and sufficient traceability to establish what information went in, which system was involved and which output was used.

This is governance.

It is not a matter of declaring that “AI is allowed”.

It means deciding which AI, for which task, with which data and under which conditions.

An example: there is no need to send the case file

Suppose a law firm wants to use a powerful external model to analyse a confidential case file.

The choice need not be between sending the entire PDF and banning AI.

The original document can remain within a controlled environment.

OCR or text extraction takes place there. Names, addresses, identification numbers and other sensitive elements can then be removed or replaced. The system keeps the mapping between real identities and pseudonymous identifiers locally.

The external model receives, for example:

CLIENT_01, COUNTERPARTY_02, PROPERTY_01.

It can analyse facts, arguments, clauses and relationships without necessarily needing to know the real identities of the people involved.

The result then returns to the controlled environment and, where necessary, the mapping is restored.

Not every case allows a perfect separation, and pseudonymisation does not automatically make data anonymous. But the example illustrates a fundamental idea:

the alternative to sending everything to the external model need not be to forgo the external model.

Architecture can stand between the two.

A page in the staff handbook no longer puts the company in control

A useful AI policy should answer a very simple question:

What should an employee do tomorrow if they want to use AI for a legitimate task?

If the answer is confusing, slow or impractical, the governance system already has a problem.

The organisation needs competitive tools, information classification, practical training, permissions, traceability and a straightforward way to resolve uncertain cases.

And it needs to review that system frequently.

A policy written eighteen months ago may describe a technological ecosystem that has all but ceased to exist.

Security and productivity are now the same design problem

That may be the most interesting lesson of Shadow AI.

Security and productivity can no longer be designed in separate departments.

If the secure solution is too poor to work with, employees will spontaneously build another one.

If the productive solution lacks controls, the company will take unnecessary risks.

The right architecture has to deliver both.

That is why, when an organisation discovers Shadow AI, its first response should not be only:

“How do we block it?”

It should also ask:

“What professional need are our employees meeting with these tools that we are failing to meet?”

That question may reduce more risk than ten new pages of prohibitions.

Governed AI or clandestine AI

Artificial intelligence raises real issues of confidentiality, data protection, intellectual property, accuracy, traceability and accountability.

That is precisely why it needs governance.

But governing a technology that multiplies productivity is not simply a matter of banning it. It means building a system in which using it correctly is easier than breaking the rules.

In some organisations, there will be tasks for which the right answer remains “no”.

In many others, the answer will be an enterprise account, a private model, a pseudonymisation layer, a local system, specific permissions or a combination of all of these.

What matters is that there is a legitimate route.

Because across much of knowledge work, companies are beginning to face a different choice from the one they thought they had:

not between artificial intelligence and no artificial intelligence, but between governed AI and Shadow AI.