Shadow AI reaches companies as a security incident: somebody pasted something into a chat window, and now it has to be blocked. That is the wrong framing. The list of tools your staff reached for on their own is the cheapest process audit a company can run — it points at exactly the places where somebody decided the work was too tedious and did something about it themselves. Blocking removes the list, not the reason for it.
This is a piece about engineering and organisation, not about law. Data classification, the lawful basis and any impact assessment belong to the controller and to their lawyer or data protection officer — we flag that below everywhere the boundary runs close.
The scale has been measured. Cyberportret polskiego biznesu 2026, a Polish survey of people who work at a computer, found that 62 per cent of respondents use AI tools in their day-to-day work duties, that 35 per cent of AI users say they would try to get around company blocks if their employer cut off access to their favourite tool, and that 26 per cent say that in such a situation they would generate what they needed on personal equipment and send it to their work address. That last figure is the strongest measured argument against blocking as a first response, with the caveat that it measures a declaration rather than behaviour. The fieldwork was carried out by the ARC Rynek i Opinia institute using CAWI in March 2026 on a sample of 1,026 people who work at a computer at least three days a week; the publishers are ESET and DAGMA, a security-software distributor, so we read it as vendor material.
Shadow AI — what it is, and how it differs from shadow IT
The definition that makes most sense in Polish conditions comes from PARP, the state agency for enterprise development: shadow AI is any use of artificial intelligence tools and solutions in the course of work without the knowledge and consent of managers or the IT department (material dated 11 April 2025; the English wording is ours, translated from the Polish original). What the definition does not contain: there is no ISO standard for shadow AI and no NIST or ENISA definition, so every vendor describes the term in whatever way suits its own offer.
It differs from shadow IT in two ways, both of them practical. Nothing has to be installed — a browser tab is enough — so conventional software inventory tools find nothing at all. And the risk is not an unknown system sitting inside the company; it is what leaves the company inside the text of a prompt.
One warning: the figures in circulation in Poland measure different things and cannot be set against one another. The 62 per cent quoted above measures use. The 55 per cent from the KPMG Poland and University of Melbourne study (fieldwork from November 2024 to mid-January 2025, 1,082 respondents in Poland) measures concealment — presenting a model’s output as one’s own. And the 95.9 per cent from the Strategic Report published by UODO, the Polish data protection authority, on 28 January 2026 (n = 492 organisations) measures organisational readiness, not use. In that report UODO itself uses the phrase shadow AI — and that is a stronger signal than any of these numbers.
Two tiers of inventory: what you can count without a console, and what needs one
How you detect shadow AI comes down to a single question: whether the company has an admin console. An inventory of AI tools therefore has two tiers. The first — statements, mailboxes, the text of support tickets, conversations — needs nothing beyond access to the accounts department and to the systems you already run. The second needs Microsoft 365 or Google Workspace with an administrator, and a fair share of firms employing between twenty and fifty people do not have that.
The test is simple: open the admin console and look for the section covering access to data and control over it. If there is none, tier two is out of your reach — and it is better to say so plainly than to promise a complete picture. If there is one, the two platforms still will not give you the same thing: exactly what separates them is visible in the table below.
How to spot shadow AI without an admin console: three sources and one conversation
For each of the four, write down two things: what it proves and what it will not show. Without that second column you get a false sense of completeness, and that is worse than having no inventory.
Card statements and expense claims. Search for vendor names rather than for fixed transaction descriptors: the description on a statement is set by the acquirer, differs between banks, and no vendor publishes it. Go through company card statements, PayPal and Stripe records and expense claims, typing in the names of the tools people actually buy, one after another. The amounts are small and recur every month, so they vanish into the cost ledger — and the exercise often turns up a company paying several times over for near-identical tools. Proves: that somebody is paying, since when, and on whose card. Will not show: anything free — and free is the rule. In the KPMG Poland and University of Melbourne study (fieldwork over the turn of 2024 and 2025), close to 90 per cent of people using AI at work reach for publicly available tools, and 77 per cent of those for free ones.
Mailboxes. Account confirmations, invoices and welcome messages arrive from vendor domains, so search by domain rather than by sender address — addresses change. This is the one source of the three where you have to stop and think: searching an employee’s correspondence is a form of monitoring, and its basis and scope are set by the employer with their lawyer, not by whoever is running the inventory. Proves: that an account was created on a work address, and roughly when. Will not show: an account on a private address — a tool that issues the company no invoice does not force anyone onto work email.
The text of tickets, CRM notes and documents. A full-text search for tool names and for phrases along the lines of “generated”, “translated” or “I pasted”, across the ticketing system, the CRM and the company drive, in whatever language your people write. This is the most underrated source, because it is the only one that shows not a tool but a process: the point at which somebody decided there was a faster way. Proves: which tasks are already partly automated, and by whom. Will not show: tools used quietly, leaving no trace in the text.
One conversation with each department head. Not “own up”, but “what do you do faster today than a year ago, and what with?” Asking about the tool produces evasive answers; asking about the task produces a list. Proves: the purpose — why anybody reached for a tool in the first place. Will not show: whatever nobody wants to name — and if the company has no approved tool and no written rules, that gap on the company’s side is part of the reason.
One limitation runs through all four: a browser session on a personal phone over mobile data leaves no line on a statement, no OAuth consent and no entry in an extension report. The exercise gives you a lower bound, not a census — and that is how it has to be signed off.
Four sources inside the console: Google Workspace and Microsoft 365 (as of 8 September 2026)
| Source | Path in the console | What it proves | What it will not show |
|---|---|---|---|
| Google Workspace — apps with access to your data | Menu → Security → Access and data control → API controls → Manage App Access → Accessed apps → View list; export the list to CSV | the app name, its verification status, the number of users, the organisational unit and the OAuth scopes | tools nobody ever connected — copying and pasting in a browser tab leaves nothing here |
| Google Workspace — OAuth log events | Menu → Reporting → Audit and investigation → OAuth log events; works on every edition | who authorised an external application to reach company mail or drive, and when | use without any authorisation; the default view covers the last seven days and the range has to be widened by hand |
| Chrome — extension report | Menu → Devices → Chrome → Reports → Apps and extensions usage; exports to CSV | which extensions, on how many browsers, and with how many permissions | extensions in Edge and Firefox and in private profiles; needs browsers enrolled in Chrome Enterprise Core, reporting switched on, and up to 24 hours for the data to appear |
| Microsoft Entra — enterprise applications and consent | Entra ID → Enterprise apps → All applications, filtered by Application Type; consent settings under Enterprise apps → Consent and permissions → User consent settings | every application that has a service principal object in the tenant — including one somebody merely signed into with a work account | anything on a private account; sign-in logs on Entra ID Free cover seven days, and moving to a paid plan does not recover the older ones |
We checked the paths and the conditions on 8 September 2026 directly against the vendors’ own documentation: Google Workspace Admin Help, OAuth log events, Chrome Enterprise Help, log retention in Entra and user consent settings. Microsoft’s menu labels keep shifting while the portal is rebuilt — on some documentation pages the same path begins at Identity, on others at Entra ID; the destination is the same.
Agree the permissions before you start. On the Google side you need the service settings administrator privilege plus a separate audit and investigation privilege. On the Microsoft side, the Cloud Application Administrator role to review applications and Privileged Role Administrator to change consent settings — and if you do this in the Entra portal rather than through Graph, Microsoft additionally requires the Global Administrator role. These four sources are enough for an inventory, and they require you to buy nothing beyond what the company already has.
One thing does not fit in that table. Microsoft documents a route of its own for discovering AI tools — the cloud app catalogue in Defender for Cloud Apps, filtered by the app category Generative AI. Which variant of Defender your subscription covers depends on your licence, and Microsoft does not settle that on the feature page: it refers you to the licensing datasheet. The difference is large — the full Defender for Cloud Apps discovers more than 34,000 applications and collects logs automatically, while the narrower Office 365 Cloud App Security covers more than 750 applications with functionality similar to Office 365, and only from logs uploaded by hand. That is a question for your licensing agreement, because the inventory itself does not need this route.
A composite drawn from several projects, anonymised, shows the proportions between the sources: a card statement usually reveals two or three subscriptions nobody approved; the list of apps with access, a few entries holding drive permissions; the extension report, one tool on a dozen or so browsers that nobody remembers any more. Conversations add the fewest entries and the most context. That is an illustration of proportions, not a forecast of how many tools you will find in your own company.
The reconciliation table: one sheet of paper, six columns
The output of an inventory is not a report but a single table you can print and sign. Six columns are enough and six is the ceiling — a seventh turns a working document into a project.
| Tool | Who | Since when | Data class | Private or company account | Decision |
|---|---|---|---|---|---|
| — | — | — | — | — | — |
Filled in, it looks roughly like this:
| Tool | Who | Since when | Data class | Private or company account | Decision |
|---|---|---|---|---|---|
| ChatGPT | two people in marketing | May 2026 | internal, proposal copy | private | move to a company account |
| Perplexity | one person in sales | February 2026 | public | private | stays, no client data |
| a meeting-summary extension | eleven browsers | not established | personal data, call recordings | private | switch off pending a decision |
| an online translator | the accounts team | not established | client data under NDA | private | replace with a tool on a company account |
| Copilot Chat | the whole team | August 2026 | internal | company | approved |
A composite from several projects, anonymised — an illustration of the method, not a measurement.
Empty fields are information in their own right. No date in the “since when” column means the tool arrived outside any process whatsoever; no entry under “who” means you have a trace but not an owner, and that you need to go back to the console or back to the conversation.
Triage by data class, not by tool
Whether a particular tool is safe is a question with no answer. Whether client material covered by a non-disclosure agreement is going into it is a question with one. So the triage runs down the data-class column, not down the names in the first column.
In a company of this size, five classes are enough: public, internal, client data under NDA, personal data, and special categories of data. These are values in a table, not a legal classification — whether a given flow involves personal data at all, what the lawful basis is, and whether an impact assessment is needed, are settled by the controller with their lawyer or data protection officer. We set out what follows technically from a decision like that in our piece on what to settle before data reaches the model. The output of the triage is a configuration decision: approve the tool on a company account, replace it with something that can be attached to one, or switch it off.
One trap at the end, and it is an easy one to fall into: a business plan does not automatically mean the data stays in the European Union. OpenAI lists data residency at rest in Europe for ChatGPT Enterprise, Edu, Healthcare and the API platform, and ChatGPT Business does not appear on that list (OpenAI, “Business data privacy, security, and compliance”, as of 8 September 2026). A business plan does not settle the region by itself, and it has to be checked separately, in the terms of the particular service.
The sanctioned door: what to configure before you write the rules
The order matters: the door first, the rules afterwards. Rules without an approved tool are a ban by another name. Each of the four items below points onwards instead of repeating what we have already described elsewhere:
- A company account instead of a private one, with a data processing agreement signed before you start. What exactly to check in the terms of a particular service — training settings, retention, the provider’s role — is in our piece on the seven GDPR decisions to take before a model rollout.
- Six questions for the provider. The full list is on our page about data security and GDPR.
- An entry in the register. We come back below to what that register actually rests on.
- A thirty-minute briefing on the tools you have genuinely approved, with a date and a list of those present, recorded during the rollout.
Before you buy anything, check one thing. Firms on Microsoft 365 Business Basic, Standard or Premium have Copilot Chat at no extra charge, and when people sign in with a work Entra account it is covered by enterprise data protection (Microsoft Learn, Manage Microsoft Copilot Chat, checked 8 September 2026). Two caveats that are easy to forget. This variant draws on the web rather than on the company’s documents — to talk about a file of your own you have to upload it or have it open in Teams or Outlook, and broader access to documents goes through agents billed on a metered basis. And web search queries go to the Bing service, where — as Microsoft itself writes — Microsoft acts as an independent data controller, which puts those queries outside the enterprise data protection boundary.
We treat the briefing the way the regulation names it: as a measure, not as a course. Article 4 of the AI Act, in the wording given to it by Regulation (EU) 2026/1744 of 8 July 2026 and in force since 27 July 2026, states plainly that the obligation does not require any particular level of AI literacy to be guaranteed in any given person; we cover the rest of that obligation under the AI Act technical compliance sprint. We do not sell training as a separate service.
A 30-day plan: four weeks, four outcomes
Week one — the raw list. Three sources that need no console, and one conversation with each department head. Outcome: tool names with people attached to them, no decisions yet.
Week two — the table. A pass through the console, if there is one, and the six columns filled in. Without a console this week is shorter and the list less complete — and that has to be written down next to the table rather than passed over.
Week three — decisions. Triage by data class, configuration of what stays, switching off what does not. Every decision with the name of the person who took it; a decision without a name is not a decision.
Week four — closing it out. A briefing on the approved tools, an entry in the record of processing activities for those uses that actually process personal data — Article 30 of the GDPR covers the processing of personal data, not every AI tool — and a decision about what you will record so that repeating this next quarter goes faster.
Four weeks is a calendar, not a workload — the exercise spends its time waiting for people to answer and for exports to come out of the console. There is one condition: nobody tries to write the policy along the way. The policy is the output of this exercise, not a part of it.
From the list to a register, and to a shortlist of pilot candidates
The list has two continuations. The first is a register of AI systems — but its basis is not the AI Act, it is the GDPR. Article 49 of the AI Act places the duty to register in the EU database on providers and, on the deployer side, on public authorities using high-risk systems; a private company using an ordinary chat tool is not the addressee there. The ordinary home for a list like this is the record of processing activities under Article 30 of the GDPR. Whether the exemption for organisations employing fewer than 250 people applies in your case, and whether the company is even the deployer of a tool it never authorised, are questions for a lawyer rather than for an implementer, and that is where we leave them. Our page on the register of AI systems covers what goes into such a register and how it is kept in order.
The second continuation is the more interesting one. The processes that came out of the conversations and out of the text of the tickets are a ready-made shortlist of candidates for a first pilot — usually a better list than one invented in a workshop, because somebody has already established that the problem is real. We described how to choose a single process from it in our piece on how to implement AI in a business, and how to recognise a good candidate in our round-up of AI automation examples that genuinely work.
When a ban is the right answer
Polish-language writing on this is unanimous that banning is not worth doing, and almost nobody says when switching a specific tool off is simply the right call. There are five such situations.
- There is no business variant. A tool that cannot be bought on anything other than a private account cannot be configured.
- The terms do not let you turn off training on your data. If opting out is a setting the user can reverse with one click, it is not a safeguard.
- Client material under NDA goes into it. The contract with the client decides that, not a risk assessment made internally.
- Special categories of data go into it. Health, beliefs, trade union membership — the threshold is markedly higher, and it is not one you cross in passing.
- The tool cannot be attached to a company account. Without that there is no log, no owner and no way out when the data has to be deleted.
The difference between a ban that works and one that does not lies in its scope and in its reasons. A ban on one tool, or on one class of data, stated with a reason, can be enforced. A ban on a whole category moves part of the usage onto personal equipment — 26 per cent of AI users say as much in the March 2026 survey quoted above.
What to do next
There is only one sequence, and it does not change from one company to the next: count, put things in order, and only then write the rules down. This piece does not produce an AI usage policy — it produces the material a policy is written from: the list of tools, the data classes, the decisions and the people who took them. Without that, a policy is a set of sentences with nothing to check them against.
To make the exercise faster to repeat next quarter, record alongside the table:
- the date of the run and the person who ran it;
- which sources you checked, and which you skipped and why;
- which tools have appeared since last time;
- which decisions you changed, and for what reason;
- which settings you verified in the console, and when.
And an honest note to close on. If the inventory ends with four people using a translator and one summarising extension, that is not material for a programme — one sheet of paper and one approved tool will do. A programme is for the company that finds a process on that list rather than a tool: repeatable work somebody has already tried to shorten on their own. What a project then looks like, from diagnosis through to keeping it running, is set out on our page about AI implementation for businesses.