Shadow AI: framing the AI uses nobody declared

What shadow AI covers

Shadow AI is every use of AI that the company has not chosen, approved or even spotted. A salesperson pasting a tender into a consumer assistant to get a summary. An executive assistant running a letter through an online translation service. A financial controller asking a chatbot to fix a formula and attaching the whole spreadsheet. A developer installing a code completion extension on their laptop. None of this is malicious. All of it starts from a good intention: go faster, write better, get unstuck.

The pattern is not new. What changes with generative AI is the nature of what moves. People are no longer just dropping a file into a storage space: they are handing a text, a spreadsheet or a contract to a service that will read it, process it and sometimes keep it.

The most common forms

• The personal account on a chat assistant, used from the work computer or from a phone.
• The browser extension that summarises pages, rewrites emails or fills in forms.
• The AI feature switched on by default in software you already use, with nobody having checked what it sends out.
• The connector linking an assistant to company email, calendar or document storage.

Why a ban on its own does not hold

When leadership discovers these uses, the first reflex is often to block everything. The memo goes out, domains are filtered on the network, and the issue seems closed. In reality it has only moved. Usage shifts to personal phones, home wifi, unmanaged laptops. It still exists, it has simply become invisible, and the person who talked about it openly has learned to stay quiet.

A pure ban has a second, more costly effect. It tells teams the company is not interested in the time savings they found. Yet these spontaneous uses are the best map of needs you will ever get. They show where work creates friction, which tasks weigh most, which documents keep coming back. Making them disappear throws away the most useful information for deciding where to invest.

Some uses do need to stop, and we will come to them. The position that lasts is to set clear limits on data, then offer an official route good enough that nobody wants to work around it.

The real risks, without the drama

ANSSI, the French national cybersecurity agency, puts the problem plainly in its security recommendations for generative AI systems published in April 2024: sending information to a consumer generative AI service amounts to storing it in a space that belongs to the provider. Separation between customers and confidentiality of the data then rest on trust in that provider alone. The agency also notes that in most offers, data sent to the service may be used to improve the models.

Its recommendation R34 is unambiguous: do not use online generative AI tools for professional purposes involving sensitive data. The guide lists personal data, contractual, legal or financial company data, and IT secrets such as passwords or API keys, among others.

Four families of risk to keep in mind

• Data leakage: a customer file, a price grid or a draft contract leaving the company's perimeter.
• Overly broad permissions: an assistant connected to email or document storage with permissions nobody has reviewed.
• Answer quality: an invented figure, a badly summarised clause, a faulty translation sent to a customer without review.
• Dependency: a process quietly relying on a personal account, which stops the day that person changes jobs.

None of this calls for panic. It calls for a framework. Most of the uses you will uncover touch no sensitive data and can carry on as they are, sometimes with a better tool.

Mapping usage without a witch hunt

You cannot frame what you cannot see. Mapping comes first, and it is the step that most often goes wrong. If teams think the exercise is about finding culprits, they will say what they think you want to hear, which is nothing.

Announce a no-blame declaration period

Leadership states clearly that the goal is to understand, and that no use declared during this period will be held against anyone. That promise must be kept, including when a declared use raises a real problem. You fix the use, you do not punish the person who reported it.

Ask concrete questions

A survey asking “do you use AI?” produces useless answers. Ask task by task instead: what do you use an AI tool for, which tool, what kind of document do you put into it, and what do you do with the result.

Add short workshops

Gathering a team around a simple request, “show us what you do with these tools”, often yields more than the survey. People readily show a trick they are proud of. It is the moment to spot the clever uses worth spreading, and the ones exposing data without the person realising it.

Look at technical signals, carefully

Your IT team can look, in aggregate, at the AI domains most visited from the network, the extensions installed on managed devices and the connectors authorised in your office suite. This overview supplements declarations; it is never for monitoring individuals. If you use it, say so, and involve staff representatives and your data protection officer from the start.

Sorting what you find

At the end of the mapping you have a list of real uses. Rather than deciding case by case, sort them into three groups.

• Encourage: the use touches no sensitive data and saves time. Rewording a generic text, drafting a presentation outline, explaining a concept. Document it and share it.
• Equip: the use is valuable but currently runs through an unsuitable tool or handles data that should not leave. Contract summaries, customer file analysis, translation of internal documents. Give it an official route.
• Stop: the use exposes sensitive data with no benefit to justify it, or hands the tool a decision that must stay human. Stop it and explain why.

This sorting has one advantage: it shows teams that most of what they do is accepted, and that the framework targets a small number of specific cases.

A short policy people actually read

CNIL, the French data protection authority, in its questions and answers on using a generative AI system published in July 2024, recommends framing these uses through internal policies or charters that clearly define authorised and prohibited uses. The key word is “clearly”. A thirty-page document drafted by legal will be read by nobody. A single double-sided page, written in the teams' own language, will be pinned up and reread.

What the policy should contain

• The list of authorised tools and how to access them.
• The list of data that never leaves, with examples drawn from your business.
• The review rule: any content produced by an AI tool and sent outside is checked by a person who answers for it.
• Decisions never handed to a tool: a price, a contractual commitment, an assessment of a person.
• How to propose a new use or a new tool.
• The name of a contact for questions.

On decisions and commitments, the policy can borrow from what we apply in our own projects: anything that commits the company is calculated and checked by a controlled system, never produced freely by a model. For the regulatory side, our article on what the AI Act already requires of an SMB details the obligations that sit alongside the policy.

Official tools that measure up

A policy that forbids without offering an alternative leads straight back to square one. If the official tool is slower, weaker or more awkward than the personal assistant, teams will go back to the personal assistant. The official route has to be at least as practical as what it replaces.

Choose the tool from the mapped uses

This is where the mapping pays off. You know which uses are most frequent and which touch sensitive data. They drive the choice: a chat assistant on a business plan whose terms exclude reuse of your data, a translation tool whose hosting is known, or a business tool built for a specific case when the need justifies it. Hosting in France versus with a hyperscaler is covered in our article on hosting an AI project in France.

Review permissions at activation

Many business tools offer connections to email, calendar or shared documents. ANSSI recommends (R35) reviewing the access rights of generative AI tools as soon as they are activated, to make sure default settings are not too open, then repeating the review regularly, since product updates can change access. Our AI security and compliance team checks this systematically before go-live.

Track the spend

Official access has a cost, and that cost drifts quickly if nobody follows it. Unused licences, usage-based billing and overlaps between departments deserve oversight from day one. Our framework for managing AI costs starts from a map of uses, the same one you have just built.

Data rules in practice

The most important rule in the whole setup fits in one sentence: some data never leaves the company for a tool you do not control. Everyone still needs to be able to recognise it.

Give examples from your own business

“Sensitive data” means nothing to a busy salesperson. “The file of discounts granted to customers”, “a payslip”, “a draft contract before signature”, “a login” means something straight away. Each department can draw up its own short list of examples, approved by management.

Teach anonymisation where possible

Many uses remain useful once names, amounts and references are removed. Getting help to structure a reply to an unhappy customer needs neither the customer's name nor the amount in dispute. The reflex is quick to learn and greatly widens what can be done safely.

Plan for the mistake

Someone will eventually paste the wrong file. The policy must say what to do then: who to tell, how quickly, and without fear of sanction for reporting. A mistake declared straight away can be handled, especially if it involves personal data and a notification may be required. A hidden mistake becomes an incident.

Train, then come back regularly

CNIL recommends familiarising end users with how the tools work and where their limits lie, and encouraging them to check both what they put in and the quality of what comes out. Training is therefore not an extra: it is what makes the policy understood and applied.

Good training on this topic does not look like a lecture on AI. It starts from the uses mapped in the department, shows the right way to do them with the official tool, and spends time on edge cases: what to do with an answer that looks right but cannot be checked, how to spot data that must not leave. That is how our training programmes work, built on each team's real cases. For how a team progresses over time, our article on bringing your teams up to speed on AI describes the stages we see.

Finally, mapping is not a one-off. Tools evolve, new features appear in existing software, teams find new uses. Coming back to the topic at regular intervals, with the same no-blame promise, keeps an accurate picture of what is really happening.

Common mistakes

• Publishing the policy before the official tool. Teams read a list of bans with no alternative, and shadow AI comes back stronger.
• Leaving the topic to IT alone. The framework touches business teams, legal and HR. Without a relay in each department it stays on paper.
• Sanctioning the first declared use. One example is enough for nobody to declare anything again.
• Forgetting AI features built into existing software. They arrive with an update, often switched on by default, and escape the mapping if you only think of standalone tools.
• Treating it purely as compliance. The mapping also reveals time savings the company can spread. Ignoring them wastes the best part of the exercise.

Where to start

If you only did three things this quarter, they would be these: announce a no-blame declaration period and map the uses, write a one-page policy with examples from your business, and provide at least one official tool covering the most frequent uses. The rest, training, permission reviews, cost tracking, builds on that sound base.

This work is as much change management as security. It fits into a broader approach, described on our responsible AI page.

If you want to know where your organisation stands, which uses are already circulating and which deserve a dedicated tool, our AI diagnostic starts with exactly this mapping, with your teams and on their real tools.

Sources

• ANSSI, Security recommendations for a generative AI system (April 2024, French version)
• CNIL, Questions and answers on using a generative AI system (July 2024, in French)

Frequently asked questions

Should we block consumer AI assistants on the company network?

Blocking can make sense for certain services or certain devices, but it is never enough on its own. Usage then moves to personal phones or laptops, where you see nothing. Block what needs blocking after you have offered an official alternative, not before.

Who should own the topic in the company?

A pair works well: someone from the business side who knows the uses and speaks the teams' language, and someone from IT or security who knows the tools and permissions. The data protection officer and HR are involved from the start. Leadership publicly carries the no-blame declaration promise.

Can an employee be sanctioned for using an unauthorised AI tool?

That depends on your internal rules and your legal counsel. In practice, sanctioning uses that predate any written rule backfires: the trust the mapping needs disappears. Once the policy is published and explained, breaches are handled like any other internal rule.

Do vendors' business plans solve the data problem?

They often reduce it, because their terms may exclude reuse of your data to train models. You still need to read those terms, check where the data is hosted and review the permissions granted to connectors. A badly configured business plan can expose more than a personal account used carefully.

How do we know our policy is working?

Two signals help. First, teams spontaneously propose new uses through the agreed route instead of hiding them. Second, the official tool is genuinely used, which IT can check in aggregate. If either is missing, the policy is probably too restrictive or the tool not practical enough.