Shadow AI: When Employees Secretly Work With ChatGPT

Ask around openly in your company sometime: who has ever copied a customer email, an error message, or a draft contract into a freely accessible AI tool? If nobody raises their hand, that’s probably not because it doesn’t happen — it’s because the question was asked in front of management.

The phenomenon has a name: shadow AI. It means using AI services that haven’t been approved, procured, or documented. It’s the direct successor to shadow IT, where departments got hold of their own cloud storage or project tools without authorization. Only this time the lever is bigger, because getting started is free, requires no installation, and the benefit is felt immediately.

Why employees do it

It’s worth taking the motivation seriously, because it determines the right response. Shadow AI rarely arises from carelessness and almost never from bad intent. It arises because someone wants to do their job well and quickly, and has found a tool that helps.

The typical cases are well-meaning. A salesperson has an English reply to a customer drafted. A technician copies an error message along with a log excerpt into a chat to get to the root cause faster. Someone in accounting has a formula explained. A manager has meeting minutes summarized.

If the company has no approved tool, this is the only way. And that’s the crucial point: shadow AI is a symptom, not a character flaw. It signals that there’s a need for which there’s no offering.

The actual risks — a sober look

Leakage of confidential information

The most obvious risk. Whatever is entered into a third-party service leaves your company. Depending on the provider and plan, this input can be used to improve the models, stored for a certain period, or viewed by the provider’s staff. Free offerings are typically far less careful with your data than paid ones.

It becomes critical with pricing calculations, draft contracts, design documents, source code, and anything that would benefit a competitor. A single instance is rarely dramatic. The problem is the sum total: if a team feeds its pricing logic into an external system for months, a substantial part of your business knowledge ends up mapped out there.

Data protection violations

As soon as personal data is involved — customer names, job applications, sick notes, salary data — an annoyance becomes a legal violation. Transferring data to a service provider requires a legal basis and, as a rule, a data processing agreement. Neither exists with a privately used free account.

It’s not the employee who’s liable here, but the company. That’s why this topic belongs in the executive suite, not just in IT.

Lack of traceability

If a quote, a calculation, or a customer response was produced with AI assistance, it should be possible, if in doubt, to trace what it’s based on. With shadow AI, that’s impossible: there are no logs, no versions, no access to the history once the person involved leaves the company.

Legal obligations go unmet

Since February 2025, Article 4 of the EU AI Act has required adequate AI competence from people operating such systems on the company’s behalf. You can’t meet that obligation if you don’t know who’s using which system. The same applies to the transparency obligations that have been in force since August 2026.

Why bans don’t work

Many companies’ first reaction is a ban — by company-wide email, by works agreement, by network block. That’s understandable, and in its effect, usually counterproductive.

A ban doesn’t remove the need. It only shifts it to where you’re not looking: to the personal laptop, to the smartphone, to a private browser. That way you lose the last chance to guide how it’s used. A network block helps against access from the office Wi-Fi, not against a screen photographed with a mobile phone.

On top of that, there’s a cultural effect that costs more than the original risk: a ban signals that working productively with new tools is unwelcome. The employees most likely to drive improvements stop talking about it. They don’t stop doing it.

The approach that actually reduces risk

Step 1: Take stock without assigning blame

Ask — but in a way that makes honest answers possible. An announced amnesty period works wonders: “We want to know which tools are in use so we can make them secure. There will be no consequences.” In addition, a look at the proxy or firewall logs provides a realistic picture of the services being accessed.

Expect surprises, in both directions: more services in use than assumed, but also more sensible use cases than assumed.

Step 2: Offer an approved alternative

This is the most effective lever, and it’s more effective than any rule. If there’s an internal tool that works at least as well as the private one, the incentive to work around it disappears on its own. “At least as good” is the benchmark here — a clunky in-house system with worse results won’t be adopted, no matter how often its use is mandated.

An approved platform has three advantages a private account can’t offer: it can be connected to your own documents and thereby deliver better answers. It respects existing access permissions. And it runs on a contractually regulated basis, ideally hosted in Germany with a data processing agreement.

Step 3: A policy that fits on one page

Long policies don’t get read. What works is a short, concrete policy that answers four questions:

• Which tools are approved? By name, not in the abstract.
• What data may go in? Best organized into categories: general information — yes; customer data — only in the approved system; HR and health data — only after consultation; access credentials and passwords — never.
• What should be done with the result? A subject-matter check by the person using it. No unchecked release to the outside.
• Who can help? A named point of contact.

Step 4: Build competence instead of fear

Most misuse comes from a lack of awareness, not intent. Anyone who’s never been told that their input can end up with the provider simply doesn’t think about it. Two hours of training on real tasks from everyday work changes behavior more lastingly than any signature on a policy — and it fulfills the competence obligation under Article 4 at the same time.

Step 5: Check back regularly

The tool landscape changes quickly. A brief repeat of the stock-take once or twice a year is enough to avoid slipping back into the same situation.

A question of sequence

The decisive difference between companies that have this under control and those that don’t is the sequence. Those who ban first and offer an alternative at some point later carry the risk without the benefit for months. Those who provide a good alternative first and regulate afterward get the benefit immediately and the risk under control.

Ultimately, shadow AI is uncomfortable but honest feedback from your workforce: there’s a need here that the company hasn’t met so far. Read it that way, and you have the basis for a rollout carried by employees, rather than imposed against them.

If you’d like to provide an approved alternative that’s hosted in Germany and respects your existing access permissions, talk to us — we’ll show you what that could look like in your environment.

A model policy that fits on one page

So the policy doesn’t disappear into a folder, it should be short, concrete, and free of legalese. The following structure has proven itself and can be adapted to your company in an hour.

Purpose. One sentence stating that AI tools are welcome and that this policy is meant to enable their safe use. Tone matters: a policy that sounds like a ban gets treated like a ban — that is, worked around.

Approved tools. Listed by name, with a note on where to request access.

Traffic light for data. Green: general, non-confidential information, publicly available content, your own drafts with no customer reference. Yellow: internal documents and customer data — only in the approved system. Red: health and HR data, access credentials, pricing calculations, documents relating to ongoing legal disputes — only after consultation, or not at all.

Review requirement. Results are checked by a subject-matter expert before use. Nothing goes out unchecked.

Point of contact. By name, with contact details.

Nothing more is needed to start. A policy that gets read is better than a complete one nobody knows about.

What the stock-take typically reveals

Companies that take this step almost always report the same surprises. There are more tools in use than assumed, often ones embedded in other software and therefore not even perceived as AI — translation functions, summaries in meeting software, assistant features in industry-specific solutions.

The second recurring finding: the use cases are more sensible than expected. What starts out as a policy violation is often, in substance, a good idea — and therefore the best template for the first official use case.

Frequently asked questions

Can we technically block private AI accounts?

Technically possible, permissible under labor law only within limits — and usually disappointing in effect, because usage just shifts to private devices. It makes more sense to combine a good approved alternative with a clear rule. Where a block is being considered, works council co-determination also needs to be taken into account.

What do we do if confidential data has already leaked out?

First, calmly establish what’s affected. If personal data is involved, check the notification obligations together with your data protection officer — short deadlines apply here. Check with the provider whether and how histories can be deleted. And treat the incident as a reason to take stock, not as a disciplinary matter; otherwise you won’t hear about the next incident at all.

How often should we repeat the stock-take?

Once or twice a year is enough if an approved alternative exists. Without that alternative, you’d have to check more often — and would still be playing catch-up.

Does the works council need to be involved?

As soon as a system is introduced that’s capable of monitoring behavior or performance, yes. What matters is the capability, not the intent. Involve the employee representatives early — the points that need clarifying there are ones you should clarify anyway.

Taking stock in practice

Two approaches complement each other, and together they take less than a day.

Technical. A look at the firewall or proxy logs shows which services are being accessed from the company network. This doesn’t capture use on private devices or from home offices, but it provides a solid lower bound. Also include the overview of approved applications in your directory service — this often reveals services that someone once granted access to company data.

Also watch out for what nobody perceives as AI: translation services, summary features in meeting software, assistant functions in industry-specific solutions, writing aids in browsers. Numerically, these cases are often the majority.

In conversation. The technical path shows what is being used; the conversation shows why — and that’s the more valuable part, because that’s where the use cases for the approved solution come from.

A conversation guide that gets answers

What matters is that the questions don’t sound like control. This sequence has proven effective, in small groups of four to six people:

• “Which task in your day-to-day work regularly costs time without being professionally demanding?” — a harmless question that sets the frame.
• “Have you already tried anything for that?” — this is where the tools come up on their own.
• “What worked, what didn’t?” — delivers the realistic assessment that no product demo can replace.
• “What would you wish for if there were no restrictions?” — delivers the shortlist of candidates for the next use cases.

Explicitly announce beforehand that there will be no consequences, and stick to it. A single exception is enough for you to learn nothing the next time.

The transition to the approved solution

Once the stock-take is done, the most effective next step isn’t the policy, but the offering. Take the use case mentioned most often in the conversations, and provide an approved solution for it — even if it initially covers only part of it.

Two things need to be right here. The solution must be at least as good as what people use privately; a clunkier substitute won’t be adopted no matter how often its use is mandated. And access must be easy — if a request has to go through three stages, people go back to their private account.

Only after that comes the policy, and it turns out considerably shorter: when there’s a good alternative, you need to ban less.