Unauthorised AI tools in the workplace: why shadow AI is a governance problem

Translated with AI. This article was translated by an AI model from an article by Twentynext in another language, and the translation was checked automatically against the original. Verify figures and sources before acting on them. See our disclaimer.

A policy officer pastes a draft memo into a free chatbot to make it “a bit sharper”. A project manager uses an AI note-taker in Teams that nobody in IT has seen. A developer works with a code assistant on a private account. None of them does this to get around the rules. They want to be done faster.

Yet K2 Integrity describes this as a widespread pattern that is rarely malicious. Without oversight, it grows into a problem that nobody has a clear picture of. Below you can read why unauthorised AI tools pose a different kind of risk than the familiar shadow IT, why a ban alone is not enough and which governance steps actually prove sustainable in practice.

What shadow AI is and why it differs from shadow IT

SentinelOne describes shadow AI as the unapproved use of AI tools by employees, without IT approval or security oversight. Think of public chatbots, browser extensions, AI note-takers, code assistants and the AI features that vendors add to existing software.

It resembles shadow IT, the old problem of unapproved SaaS and USB sticks. The difference lies in what the tool does with your data. With an unauthorised storage service, deletion is not always straightforward either, but there it concerns a file that sits somewhere. According to SentinelOne, AI tools process your data through inference and may retain it in training data, which further limits what you can control afterwards.

Sources such as Acronis and Adaptive Security point out that the core risk lies in data that leaves via prompts and may end up in training data, something that is harder to reverse than deleting a file. The Thomson Reuters Institute adds that these tools produce content, draw conclusions and influence decisions, often without any record of how.

The figures on scale given in the publications consulted here come mainly from security vendors and vary; we have not assessed the underlying methodology for this article. Adaptive Security and WitnessAI also state that many organisations have little insight into how those tools are used. What happens in your own organisation, you only know after your own inventory.

Why employees acquire tools themselves

The reflex is to see this as a behavioural problem. That is the wrong diagnosis. Part of the causes lie within the organisation itself. Zylo cites the accessibility of AI tools, decentralised procurement and the rapid growth of AI features in existing software. In addition, three circumstances play a role that relate directly to governance.

There is no approved offering. If the organisation does not provide a usable alternative for summarising, rewriting or completing code, people look for one themselves. SentinelOne therefore advises offering approved alternatives for common tasks first, before you ban unauthorised tools.

The approval process is too slow. A request that sits in an approval process for a long time quickly loses out to a tool that works immediately. Employees weigh that up, usually unconsciously, and opt for speed.

The risks have not been explained. Not every employee stops to think about what it means to enter personal data into an external tool, or that an AI note-taker may, depending on the service, send the conversation to an external party. Strikingly, according to SentinelOne, it is precisely security professionals and executives who show high adoption of unapproved tools: they know the risks and believe they can manage them individually.

That last point is a governance signal. If even the people who should be guarding the policy circumvent it, that indicates that policy, offering or execution are not properly aligned.

The risks that really matter

Not every use of a public chatbot is an incident. For the assessment it makes a difference whether someone has an already public text rewritten or enters a case file, although even with public text questions remain about copyright and the reliability of the output. The risks that should keep an executive awake fall into four groups.

Data leaves the organisation via prompts

This is the core risk. Personal data of citizens or customers, draft decisions, contract texts, source code: whatever goes into a prompt to an unmanaged, external tool escapes your own security measures. Adaptive Security points out that such input can be absorbed by external models and may be retained or used for training, depending on the terms and configuration of the service.

Decisions without traceability

The Thomson Reuters Institute points out that these tools draw conclusions and influence decisions, often without any record of how. If an AI tool helps write an assessment, a piece of advice or a selection, the question you have to ask yourself is: can you show afterwards which part comes from the human and which part from the model? If you work in a context in which decisions must be reasoned and capable of being reconstructed, this is a question to answer in advance.

Inconsistent processes

If ten employees use ten different tools and prompts for the same task, the uniformity of your services and the control over them come under pressure; the Thomson Reuters Institute names that process consistency as one of the consequences of shadow AI. Quality control presupposes that you know what needs to be checked.

Legal obligations you cannot demonstrate

Island points out that regulated data in an unvetted AI tool may, depending on processing, legal basis, security and transfer, conflict with the AVG (Algemene verordening gegevensbescherming, the GDPR), regardless of the employee’s intention. The employee’s good intention is therefore no answer to the question of whether the organisation is in the clear here. Which contractual arrangements suit a service is a question to answer per tool and per use with your privacy officer. Without insight into which tools are being used, you cannot make that assessment and therefore cannot demonstrate that you have made it. The AI Act, moreover, sets requirements in Article 4 for the AI literacy of staff working with AI systems; Dastra describes that obligation and cites insufficient AI literacy as a breeding ground for shadow AI. How you give substance to this depends on your context, but an organisation that does not know which AI its people are using will find it difficult to take and substantiate targeted, appropriate measures here.

Three risks that hit harder in the public sector

Data leaves your control without anyone noticing

CompTIA describes it aptly with a scenario: a buyer has a contract containing supplier and pricing data summarised by a generative AI tool. The work goes faster, but the original document may now exist outside the organisation’s control. No report, no data breach in the classic sense, but an unknown processing operation.

Vectra AI points out that the AVG requires, among other things, lawful and transparent processing (Article 5) and data processing agreements with processors (Article 28), and that an organisation can hardly comply with that for tools whose existence it does not know of. The same source cites the example of a free chatbot account with which employees process customer data, and states that no data processing agreement exists between the organisation and the provider in that case. Whether that applies in your situation depends on the account type, the contract terms, the processing roles and the provider concerned; therefore include it as a checkpoint per tool and do not assume a fixed answer.

What this means for your organisation depends on your role in the processing and must be checked per tool. Have these passages in your own policy reviewed by your FG (Functionaris Gegevensbescherming, data protection officer).

Output that looks right but is not

Celerity notes that AI does not always get it right: answers can be off or biased, and anyone who bases decisions on them without checking risks unfair service delivery. In a commercial marketing department, a fabricated detail is annoying. In a document that feeds into a decision about a citizen or in advice to an executive, it weighs more heavily.

The risk lies less in the error itself than in its invisibility. An employee who has had a draft decision partly written by a model does not note that in the file. The reviewing colleague therefore does not know that they need to read extra carefully.

Decisions are influenced without the trail being traceable

Which requirements for reasoning and record-keeping apply to your decisions differ per act, decision and procedure and are something to check with legal affairs. CompTIA names as a risk that documents processed via an external AI tool may fall under public disclosure obligations without the organisation being aware of it. Which review and which disclosure rules apply to your decisions and documents differ per type of decision and procedure. If an AI tool has influenced an assessment without this being recorded, a link in the reasoning may be missing.

This may also affect your archiving. Check whether prompts and answers in an unapproved external tool fall within your own information management and, if they played a role in a document, whether and how they must be retained; that is a question for legal affairs and your records management. Have the Awb (Algemene wet bestuursrecht, General Administrative Law Act), Woo (Wet open overheid, Open Government Act) and Archiefwet (Archives Act) passages of your policy reviewed by legal affairs.

Why a ban alone does not work

An obvious response is to block on the proxy and send a memo. On its own that is insufficient. Cyberhaven observes that organisations with a published AI usage policy, approved lists and training see the adoption of shadow AI continue; how representative that observation is, the source does not show.

A block on the proxy or on the endpoint mainly works against the use that those controls recognise. How far that reaches depends on your device, identity and SaaS management. WitnessAI states that IT teams generally only have part of the AI tools in use in view, particularly when use is spread across desktop applications, development environments, built-in copilots and the browser, and that many teams are technically unable to stop uploads to AI systems, even when they do see the risky use. Part of the use then mainly disappears from your view.

More importantly: a ban that stands as the only measure can turn shadow AI into a taboo. Reporting a mistake then amounts to a confession. Securiti points out that gaining insight into unauthorised use also runs through open communication and the trust of employees; you put that channel at risk with a bare ban.

A ban without an alternative can also send an undesirable signal: that the organisation has little regard for employees’ need to work faster. K2 Integrity therefore argues for governance that channels and guides use rather than banning it.

How you do get shadow AI under control

Governance that works channels use rather than suppressing it. That requires five components, and they belong together.

First inventory what is happening

Start with visibility. Securiti cites detection tooling, manual checks on company devices and open communication with which you win employees’ trust as ways to get unauthorised use in view; how complete that picture becomes and how long it takes depends on how your management is set up. Bear in mind, too, that monitoring employees itself requires an assessment in terms of privacy, employment law and employee participation: is the measure proportionate, are you transparent about it towards employees, and has the works council been involved in time? Involve privacy and HR before you deploy detection tooling. Be prepared for the outcome to be larger than expected. Treat that as information, not as evidence against employees.

Give every tool a status

A list of tools is only useful once a decision is attached to it. A working model described by, among others, Acronis works with four statuses: approved, under monitoring, permitted with restrictions (for example only for public information) and blocked. The status list itself does not enforce anything; that requires ownership, technical controls and follow-up. But with a status, a static inventory at least becomes an agreement you can steer by.

Offer an approved alternative before you ban anything

Make sure a managed variant is available for the most common tasks, with appropriate contractual arrangements, including a data processing agreement where necessary, and clear terms on the reuse of data. Only then does a ban on the public alternative make sense. Which category you choose (a business chatbot licence, your own environment with a cloud provider, an open model on your own infrastructure) depends on data classification, budget and management capacity.

Make approval tiered

Have a tool that only processes public information approved within days. Reserve the heavy review for applications that process personal data or influence decisions. One slow route for everything invites circumvention. SentinelOne therefore advises a tiered process in which low-risk tools are approved quickly and high-risk applications receive a thorough review.

Explain what may and may not go into a prompt

A workable form is a decision rule that employees can remember, alongside the policy document; Cyberhaven observes that a usage policy on its own does not appear to slow the adoption of shadow AI. An example of such a rule: no personal data, no non-public decisions and no source code in tools without the status “approved”. This is a working model, not a proven standard; the precise rule depends on your data and processes. An approved tool does not automatically widen that rule: there too, data classification, purpose, legal basis and authorisation determine what someone may enter. Repeat this in onboarding and team meetings.

What this asks of the organisation

Be realistic about the lead time. Taking inventory and assigning statuses is the manageable part. A working, approved offering with appropriate contractual arrangements, data classification and a tiered approval process generally takes more time and involvement from procurement, privacy, security and the process owners themselves.

Appoint one owner. Shadow AI falls between IT, security, privacy and the business, and precisely for that reason nobody picks it up. An information manager or CDO with the mandate to assign the inventory and the status process is a workable form; have the statuses themselves determined in consultation with privacy, security, procurement and the process owner concerned. Which position the owner holds matters less than that the mandate exists to organise that consultation and record the outcome.

And accept that this is maintenance, not a project. Vendors keep adding AI features to software you already use; Zylo names precisely those built-in integrations as one of the routes by which shadow AI arises. So do not assume that an inventory will stay current for long. Schedule a periodic review.

Your first step

This week, ask three team leads which AI tools their people actually use and for what. No survey, no policy tone, just an ordinary conversation. Put the answers next to what IT has formally approved.

The difference between those two lists gives a first indication of your shadow AI. The picture will be incomplete, but with it you have the agenda for the conversation with the board, privacy and security, and a realistic starting point instead of an assumption.