Adapted from the Polish article, originally published on 19 June 2026. The English version was published on 01 October 2026.
The company has not announced an AI rollout. There is no approved tool register or project owner. Yet sales uses an assistant to draft replies, developers use coding tools, HR tests candidate summaries and someone uploads a customer contract to a personal account.
AI has arrived through everyday work. People want to finish tasks faster. The organisation may not know which tools they use, what leaves its systems or who checks the result.
Shadow AI is the use of AI outside the organisation’s effective visibility and governance. It does not mean every employee is using AI badly. It means the company cannot reliably explain the tools, data flow, account access and responsibility.
This is a cross-border operational problem. GDPR and the AI Act add a specific EU compliance layer where their scope is engaged; they do not explain every confidentiality, security or product risk on their own.
What you will learn
- How unapproved tools become part of routine work.
- Why accounts, prompts and connected sources matter as much as model choice.
- How to create a practical tool inventory and usage policy.
- Who should maintain governance across legal, security, HR and product.
- Which additional questions arise under GDPR and the AI Act.
- How a SaaS or development business should distinguish internal use from product features.
Adoption often happens without a deployment project
An employee summarises documents in ChatGPT. A developer uses a coding assistant. Another team analyses data in a third-party service, generates marketing images or connects an automation to the CRM.
The productivity gain can be real. But the company needs to know:
- Which tool and account are used.
- What information is entered or retrieved through an integration.
- Whether that information is personal, confidential or client-owned.
- Whether inputs or results are reused for training or another purpose.
- Where processing takes place and who has access.
- Who can view or delete conversation history.
- Who owns the final decision, message or code.
Without those answers, a workflow can become established before anyone has assessed it. An internal ban that staff work around provides little visibility either. The approval route needs to be usable enough for teams to bring tools into it.
The everyday examples carry different risks
A customer contract may contain confidential pricing, dispute details and personal data. A code snippet may reveal proprietary logic or credentials. A sales response may promise functionality the product does not have. An HR summary may affect a person’s job prospects. A marketing image may need copyright review or a transparency disclosure.
Those situations should not all receive the same rule. Identify the task, data and consequences before deciding whether to permit it, restrict it or require review.
The prompt often contains the most valuable context: negotiation strategy, customer history, a dispute, financial information or product know-how. The practical question is what may this team put into this tool for this purpose?
An approved use for drafting neutral copy does not automatically authorise uploading an entire client file. A business licence does not automatically answer which workspace settings and connected services apply.
Risk 1: personal accounts handling company information
The employee may be acting in good faith. A personal account is available immediately, and summarising a document takes seconds. The company then loses control over account access, applicable terms, retention and offboarding.
Recommendation: build an inventory of actual use
A simple maintained register is a useful starting point. Record:
- Tool and vendor.
- Business owner and team.
- Purpose and specific workflow.
- Data categories, including attachments and connected sources.
- Account, licence and administrator.
- Training, evaluation and other reuse settings.
- Whether a relevant data processing agreement exists.
- Access, retention and deletion arrangements.
- Approval status: permitted, restricted, under review or prohibited.
Ask teams what they really use, including experiments and browser extensions. The inventory should describe the whole flow, not only a list of well-known models.
For procurement, the AI vendor and GDPR checklist examines roles, retention, training, subprocessors, changes and exit in more detail.
Risk 2: nobody knows what can go into a prompt
Without boundaries, every employee makes their own decision. One team removes names; another uploads the full record. One treats source code as confidential; another assumes the coding tool’s popularity is enough.
Recommendation: write a short usage policy people can follow
The initial policy does not need forty pages. It should specify approved tools, permitted purposes, prohibited data, required removal or anonymisation of information, human-review triggers, final responsibility and a route for requesting a new tool.
For example, a company may permit brainstorming, neutral text editing, email drafts and checklists using non-sensitive material. It may restrict customer records, confidential contracts, source code, sensitive personal information and automated decisions about people to separately approved workflows.
Removing a name is not necessarily anonymisation. Context, identifiers, attachments and retrieved material can still identify a person. The EDPB’s Opinion 28/2024 also explains why an AI model should not simply be assumed anonymous because a vendor describes it that way.
Use examples that match the team’s work. “Do not enter confidential data” is easier to apply when the policy identifies client contracts, production logs, repository material and negotiation notes.
Risk 3: everyone has a part, nobody maintains the whole
IT reviews integrations. Security reviews access. Legal reviews contracts and regulatory duties. HR considers employee use. Product owns features. The business owner wants a faster process.
Those perspectives need coordination. Otherwise approval can cover the vendor while overlooking a new use case or a changed integration.
Recommendation: assign a governance owner
The owner need not make every decision personally. They maintain the inventory, route assessments, record approval and exceptions, coordinate the relevant teams and trigger review when something changes.
Define who updates the policy, who decides on a restricted use, where staff report a problem and who coordinates an incident. Keep the owner connected to actual deployment decisions. A policy without maintenance becomes inaccurate as tools and workflows change.
EU compliance: assess the use, data and role
The operational recommendations above are useful across markets. Where EU rules apply, add a specific legal assessment rather than treating every AI tool as subject to identical duties.
GDPR follows personal data processing
Where GDPR applies, identify the purpose, legal basis and relevant controller or processor roles. A vendor processing personal data on the company’s behalf needs an Article 28 arrangement; vendor processing for its own purposes needs a separate assessment.
Assess minimisation, retention, security, transparency and relevant transfers. A DPIA is required where the proposed processing is likely to create high risk to people’s rights and freedoms, not automatically for every AI tool.
If a decision is solely automated and has legal or similarly significant effects, assess Article 22. Adding a nominal human approval does not automatically take the process outside that framework. The reviewer needs a meaningful role in the actual decision.
AI Act duties depend on function and role
Identify whether the organisation is using an AI system as a deployer, providing it, or changing its intended purpose in a way that matters under the Act. Our deployer/provider recruitment example explains why a use-case change can matter.
Do not classify every workplace assistant as high-risk merely because it uses AI. Equally, do not assume a low-risk classification removes all duties. Article 50 transparency can apply to particular interactions or outputs independently of high-risk status.
As at 1 October 2026, Article 4, amended by Regulation (EU) 2026/1744, requires providers and deployers to take measures supporting the development of AI literacy. Those measures should reflect staff knowledge, experience, the use context and affected people. It does not require guaranteeing a specific literacy level for each individual.
Role-specific guidance is more useful than giving every employee the same generic course. A developer, HR reviewer and support agent need to recognise different mistakes and escalation triggers.
Development companies and SaaS need two separate views
Internal team use
Check whether developers may submit client code, whether logs contain personal data or secrets, whether an assistant can access a repository, and whether AI may be used on customer tickets or documentation.
Review the relevant confidentiality and client commitments. Approval of a tool does not automatically authorise using it on every customer’s material. Establish whether the customer needs information or consent under the actual contract and data arrangement.
AI within the product
If the product offers an assistant, scoring, recommendations, classifications, summaries or generated content, describe the feature and its intended use separately.
Map user data reaching the model, third-party services, outputs, review, transparency, logs and responsibility. Check how the feature is described in customer terms and technical documentation. Include the supplier and maintenance arrangements needed when the model or UI changes.
An internally approved assistant is not a complete assessment of an externally supplied product feature. The product may have different users, data, roles and effects.
A practical starting set
- A tool register with a purpose, business owner and data description.
- A short policy defining permitted, restricted and prohibited uses.
- Concrete prompt, attachment and integration rules.
- Company-controlled accounts and an offboarding process where appropriate.
- Defined human review and responsibility for final outputs.
- A route for proposing a new tool or use case.
- A governance owner coordinating legal, security, HR and product.
- Contract and product documentation matching the actual workflow.
This starting set does not replace a full compliance programme where one is required. It gives the company a practical point of control and evidence for deciding what needs deeper review.
Shadow AI becomes manageable when the organisation can explain which tool is used, on what data, under which terms, by whom and with what review. For help turning that map into usage rules, vendor documents and product responsibilities, see our technology legal services or contact us about the current workflow.
Primary sources for the EU compliance layer
- GDPR, Regulation (EU) 2016/679, particularly Articles 5, 6, 22, 28, 32 and 35 and the transfer framework.
- EDPB Opinion 28/2024 on AI models, official English version.
- AI Act, Regulation (EU) 2024/1689, read with its amendments.
- Regulation (EU) 2026/1744, Digital Omnibus on AI, including the amended Article 4.