Shadow AI in the workplace: make usage visible and set clear rules

What shadow AI means

In this article, shadow AI means AI services, accounts, integrated assistants or interfaces used for business tasks outside the agreed approval and operating process. This may be a personal chat account, an unnoticed AI feature inside an existing SaaS application, or a developer-provided API key.

Not every unapproved use is automatically a personal data breach. It does reveal a control gap, however: the organisation may be unable to say reliably what data was processed, whether prompts are retained or used for training, who has access, and how outputs are reviewed.

1. Record usage without monitoring employees

Start with tasks rather than product names. Ask teams where they summarise text, create translations, review code or search documents. Record the tool, account type, data involved, intended output and the person responsible for the business use. This provides a useful overview without monitoring prompt contents by default.

Complement these discussions with existing inventory, procurement and identity information. New technical monitoring is not a neutral first step: it must itself be assessed from legal and organisational perspectives and, where applicable, involve the data protection officer and employee representatives.

• Which specific workflow is the tool intended to improve?
• What prompts, attachments, connected data sources and outputs are involved?
• Is the account personal, shared or centrally managed?
• Who reviews the output and owns the business decision?

2. Use simple rules based on data class and purpose

A short data-and-use matrix is more useful in daily work than an abstract ban. Public material may be suitable for approved tasks when outputs are reviewed. Internal information belongs only in assessed tools and designated accounts. Personal data, trade secrets and particularly sensitive information require a documented review of purpose, legal basis, contract and safeguards before use. Credentials, private keys and other secrets do not belong in prompts.

Classification is not determined by the document alone. An apparently harmless text can become sensitive through names, metadata, conversation history or the combination of several details. Define approved purposes and data types as well as approved tools.

3. Assess tools and contracts using the same questions

An enterprise label is not a security guarantee, and a free service is not automatically unsuitable. What matters is what has actually been agreed and configured. Record the assessment with a version or review date because providers can change features, subprocessors and retention rules.

• Who is responsible for each processing activity, and is a data processing agreement required where applicable?
• Are prompts and outputs retained, used for training or reviewed by people, and can this be controlled contractually and technically?
• Where is data processed, which subprocessors are involved, and what deletion or export options are available?
• Does the tool support SSO, multi-factor authentication, roles, logs and limited access to connected data sources?
• How are changes to models, features and terms reviewed before they affect critical workflows?

4. Outputs still require review

Approved technology does not replace professional review. Define which tasks use AI only for a draft, when sources must be checked, and which decisions remain with a person. The review path should be visible and documented, especially for security configuration, customer communications, employment matters, and legal or financial content.

Training should reflect roles, prior knowledge and risk. In its current form, Article 4 of the EU AI Act requires measures to support the development of AI literacy; it does not prescribe one uniform training format for every organisation. Short examples from real workflows are often more useful than a single general presentation.

5. Capture facts first after an accidental disclosure

If sensitive information was entered accidentally, stop using that conversation and capture the necessary facts: service and account, time, affected prompt or file, potential recipients, relevant settings and any deletion feature already used. Do not circulate sensitive prompts or screenshots unnecessarily. Involve information security, privacy and the accountable business owner through the existing reporting process.

A delete button is a useful immediate step, but it does not prove that every copy has been removed. Review the provider's documented process and assess the actual impact. If personal data is involved, determine separately whether a personal data breach has occurred. Under Article 33 GDPR, the controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach, unless it is unlikely to create a risk to the rights and freedoms of those affected. Information that is still missing can be supplied in stages. Article 34 generally also requires affected individuals to be informed without undue delay when a high risk is likely. Document the decision and involve the data protection officer or legal counsel in the legal assessment.

A practical 30-day start

• Week 1: record use cases and tools already used by each team; do not create a repository of prompts.
• Week 2: describe data classes, approved purposes and initially restricted uses on one page.
• Week 3: assess two or three commonly used tools against the same contractual, privacy and security questions.
• Week 4: provide approved accounts, deliver role-based training and test a short reporting process for accidental disclosures.
• Afterwards: assign owners and a regular review date; reassess new features and connected data sources before enabling them.

Operate technology and policy together

Shadow AI cannot be solved by policy or filtering alone. A sustainable process combines clear rules with managed accounts, identity and access controls, limited data connections, documented settings and an open reporting channel. This turns informal use into a manageable workflow without blocking useful experimentation by default.

When an approved AI service requires infrastructure, identity integration or the secure operation of a self-hosted application, technical requirements can be assessed alongside the organisation's existing privacy and security process.