EY asked 975 C-suite leaders about responsible AI for its Responsible AI Pulse survey. One finding stands out: 32% of companies prohibit employees from building their own AI agents, and among those companies, 12% admit they cannot see whether it happens anyway. Among the companies that allow it, only 60% have a formal framework covering the whole organization, and only half say they have good visibility into what people actually do.
So even among companies with a ban, one in eight admits it cannot tell whether the ban is followed. A ban is a statement of intent, and on its own it tells you nothing about what people actually do.
The same applies to the wider case, usually called shadow AI: AI tools people use at work without the company’s approval. Shadow AI follows the work. People rarely reach for an unapproved tool out of curiosity alone; they reach for it because a job is taking too long. Picture someone in sales with several proposals due by the end of the week, someone in support working through long email threads, or someone in finance trying to understand a contract clause. Each of those is a job that needs help and is not getting it from anything the company has bought.
ServiceNow and ThoughtLab, in a survey of 4,500 executives, found that only 20% have testing, auditing and risk-assessment processes in place for AI. Most governance today covers part of the ground, and unapproved use grows in the part it misses.
before you count anything
As soon as you start recording which AI tools each named person uses, you have a record of how someone works. In the EU that is personal data under the GDPR, and in countries with works councils, such as Germany, employee representatives usually have a say before a system like that starts. The details differ by country, so settle them with your data protection officer, your employment counsel and, where you have one, your works council.
The agreement does not need to be long, and four terms are usually enough:
- Purpose: the record exists to govern AI use, and is not used for performance evaluation.
- Access: who may look at the data, and in which situations.
- Content: what people type is not read, and names are replaced by codes by default.
- Time: how long the record is kept, and the date it is deleted.
Settling those four before you pull any data is faster than settling them afterwards, when the data already exists and positions have hardened. It also makes the exercise easier to explain to the people whose usage you are about to count, and that decides whether they keep using the tools in the open.
what the records already show
Once that is agreed, you can look at what people actually use. A survey is the obvious way to ask, but it asks people to report the tools they think they are not allowed to use, so the answers will be incomplete. The records your company already keeps are more reliable.
Two sources cover most of what you need, and neither requires a project. The first is the log your internet connection keeps of which outside websites and services company devices connect to. Whoever runs your network, one person internally or the provider on your support contract, can export that list with how often each was reached. The second is the list of apps people have connected to their company accounts. Every time somebody clicks “sign in with your work account” to try a new tool, that permission is stored, and the administrator of your company’s email and office platform (Microsoft 365 or Google Workspace, for most companies) can list them all. Both exports are usually a short job.
The list will be longer than you expect. Read it before you act on it, and read it for repetition. One person who tried a tool once tells you little. Three people in the same team using the same tool every week tell you which job is underserved and roughly how much it matters to them.
answer the request
For each of those groups, the response is one approved tool that does that job at least as well, and the measurement is how many people use it in a given week, not how many licences you bought or training sessions you ran. If that number does not move within about four weeks, your approved option is slower or clumsier than what people found themselves, and they will keep using their own. You can mandate it anyway, and you will end up with the same blind spot you started with.
For tools still under review, blocking is usually the wrong move for a mid-sized company. It is better to offer the tool in a controlled way: an account the company pays for and manages, with the setting that keeps your data out of the provider’s model training switched on, plus a plain rule about what may be pasted in. That gives you visibility and most of the protection while the review runs.
A hard block is still right in one place, and it should be enforced by the system, not just written into a policy document. There is data you are contractually or legally not allowed to put into an outside system: client files under a confidentiality clause, personnel records, and anything covered by a data processing agreement (the contract that lists which outside providers may handle personal data for you). Keep that data behind technical controls that stop people from copying it out in bulk or uploading it to tools outside the approved list.
Write the result on one page: which tools are approved for which jobs, what may never be pasted anywhere, who to ask about a tool that is not on the list, and how quickly they will get an answer. Keep that answer fast, because a slow approval teaches people to skip the question and use the tool without permission.
Start this week with the export of apps connected to your company accounts, and before anyone attaches a name to a line in it, agree on purpose, access, content and time with the people who need to be involved.