Practical AI governance

Shadow AI: Risks and Controls for European Teams

Updated 23 August 2026

Shadow AI is already part of everyday work. The useful response is not a blanket ban, but a clear route from unknown tools and risky prompts to approved, controlled use.

Shadow AI means employees use AI tools, accounts, browser extensions, meeting bots, or built-in assistants without the organisation having approved—or sometimes even knowing about—the use. The employee is usually trying to work faster, not bypass security. The risk appears when business data enters a service whose contract, retention, training settings, integrations, and access permissions have not been assessed.

Typical examples are easy to recognise: a salesperson pastes CRM notes into a free chatbot to draft an email; HR uploads candidate CVs for comparison; a developer shares source code or production logs to debug an error; legal asks an assistant to summarise a contract; or an employee invites an unapproved AI meeting bot to a customer call. An AI browser extension can create the same problem if it can read page content or form fields beyond the task the employee intended.

The main risks are broader than whether a provider trains its model. Personal data may be processed without a documented purpose, lawful basis, processor terms, retention decision, or transfer assessment. Confidential strategy, credentials, source code, or customer material may leave the organisation’s controlled environment. Outputs can also be wrong, biased, or reveal data from connected sources, while plugins and AI agents can act with excessive permissions. OWASP therefore recommends input sanitisation, access controls, restricted data sources, and user education for sensitive-information risks.

A workable prompt rule is: public or deliberately synthetic information may go into an approved tool; internal information may only go into a tool explicitly approved for that data class and use case. Employees should not enter names paired with contact details, identifiers, health or HR data, payment data, customer cases, credentials, private contracts, non-public financials, source code, or incident logs into consumer AI services. Removing a name is not always enough: context, rare job titles, case details, or combinations of fields can still identify a person. When real data is necessary, minimise it and use an approved environment with the required contract and controls.

A policy creates a shared rule, but it cannot inspect every prompt or stop a rushed copy-and-paste. Technical controls cover that execution gap: managed accounts and single sign-on, an allowlist of approved services, browser and endpoint controls, least-privilege connectors, retention and training settings, data-loss prevention, prompt-level detection or redaction, and usage logs that avoid recording the sensitive content itself. Use these controls to support employees, then review exceptions and incidents so the approved route remains easier than shadow use.

What regulators and security guidance show

In 2025, the Danish Data Protection Agency completed inspections of 15 trade unions and unemployment funds using generative AI. It found widespread organisational measures such as policies and training, but substantial variation in the technical measures used to address risk. Source
The Spanish data protection authority recommends keeping an inventory of generative AI systems and putting mechanisms in place to prevent personal, sensitive, or confidential information from entering systems that are not explicitly authorised for it. Source
The European Commission says AI literacy should reflect the systems, risks, context, and staff involved. Simply asking people to read a tool’s instructions may be ineffective. Source

Shadow AI checklist: nine controls to put in place

Discover actual use: survey teams, review authorised SaaS and browser extensions, and create a non-punitive channel for reporting tools and use cases.
Maintain an AI register with owner, purpose, users, data categories, provider, deployment mode, integrations, retention, training use, and review date.
Classify use cases, not just vendors: the same assistant may be acceptable for public marketing copy but unsuitable for customer or employee records.
Publish a one-page input guide with concrete examples of allowed, conditional, and prohibited data, plus a named route for exceptions.
Provide approved business accounts and disable provider training or unnecessary history where the service supports those settings.
Apply least privilege to connectors, plugins, meeting bots, and retrieval sources; do not give an assistant access it does not need for the task.
Detect or redact personal data and secrets before submission, and block clearly prohibited destinations when the residual risk justifies it.
Train by role with real prompts, including how to minimise data, verify outputs, report mistakes, and respond if sensitive data was submitted.
Measure adoption and incidents, reassess vendors and configurations, and update the register whenever the service or use case changes.

A 30-second decision rule for employees

Before sending, ask three questions: Is this tool approved for this exact task? Am I authorised to share every piece of data in the prompt and attached files? Could I remove, generalise, or replace anything and still get a useful answer? If any answer is unclear, stop and use the approved route. If information was already sent by mistake, preserve the facts and report it through the normal security or data-protection process—do not hide or repeat the exposure while trying to fix it.

Where AIamigo fits—and where it does not

AIamigo can add a practical pre-send layer in everyday browser-based AI chats: it detects common personal identifiers, lets the employee review each match, and can replace detected data with clear labels before submission. That helps reduce accidental disclosure at the moment it happens. It complements rather than replaces vendor assessment, approved-account configuration, access control, staff training, legal review, incident response, and controls for confidential information that is not personally identifiable.

Add to Chrome Sign up for free Book a demo

Related resources

Frequently asked questions

What is shadow AI?

Shadow AI is the use of AI tools, accounts, extensions, agents, or integrations for work without the organisation’s approval or visibility. It includes unapproved tools and approved tools used for an unapproved purpose or data type.

Why do employees use shadow AI?

Usually because an AI tool solves an immediate problem faster than the approved process, or because no approved option is clear. Discovery should therefore focus on useful workflows and friction, not only on enforcement.

Can employees enter personal data into generative AI?

Only where the organisation has approved the tool and use case for that data, established the required GDPR basis and safeguards, and limited the input to what is necessary. Personal data should not be entered into an unapproved consumer AI service.

Is an AI policy enough to control shadow AI?

No. A policy and role-based training set expectations, but technical controls are needed at the point of use. Useful layers include managed accounts, service allowlists, least-privilege integrations, retention settings, and pre-send detection or redaction.

Should a company block all generative AI tools?

A temporary block can be justified for a specific high-risk service, but a blanket ban often leaves the business need unresolved. A safer long-term approach is to provide approved tools and use cases, clear data rules, and proportionate technical controls.

Does AIamigo solve every shadow AI risk?

No. AIamigo helps employees catch and replace common personal identifiers before sending prompts in supported browser-based AI chats. It does not replace an AI inventory, vendor due diligence, access control, legal assessment, or incident response.