The CTO's guide to shadow AI: from invisible to governed

what shadow AI actually is inside a mid-market company

Shadow AI covers a handful of distinct channels that each leave a different trace, which is part of why it is hard to see as a whole.

Personal accounts used for work. Someone signs up for a consumer AI tool with their work email or a personal email, and uses it to draft, summarize, debug, or analyze company material. There is no install. There is often no record on your side at all. This is the largest and quietest channel.

AI features switched on inside SaaS you already own. Your CRM, your help desk, your document suite, your project tool. Many of them shipped AI features in the last two years, and many turned them on by default. The data those features process is your data, moving through a model path you did not separately approve. The tool was sanctioned. The AI feature inside it was not reviewed as its own thing.

Connectors and assistants granted access. An AI tool asks to connect to your Google Workspace or Microsoft 365 to read mail, files, or calendars. An employee clicks approve through the standard OAuth screen. The grant persists long after the trial ends. These are visible in your directory if you go looking, and most teams never look.

Browser-based tools and extensions. A tab, or an extension that sits in the browser and can read the content of open pages, capture typed text, and in some configurations reach session tokens. Extensions install in seconds and are almost never inventoried.

It accumulates because each addition is rational for the person who makes it. A deadline is close, a tool helps, the signup is free, the value is immediate. The accumulation is the sum of many small sensible decisions, none of which crossed your desk.

why bans fail

The reflex, when shadow AI first registers as a risk, is to prohibit it. Block the domains. Add a line to the policy. Wait for the exposure to recede. It does not recede. Three things happen instead.

Use goes underground. The tools are genuinely useful, so people keep using them, and they stop telling you. The activity that was at least partly visible becomes fully invisible. You end up with less of the thing you were trying to gain.

Productivity takes a hit you cannot measure. Work that was getting done faster slows down, or routes around the block through a personal device or a home network. The cost is real and it does not show up in any report.

You lose the visibility you need to govern. A ban removes your reason to build an inventory, because officially there is nothing to inventory. The data still flows. You just have no view of where. The risk in shadow AI lives in the data that moves into a tool and the access the tool holds. A ban does nothing about either. It only removes your line of sight to both.

the operating model

Four moves, in order. See, classify, guardrail, enable. The order matters. Each move depends on the one before it.

see

You cannot govern what you cannot see. Before any policy, build a view of what AI is actually in use. Three sources get you most of the way, and one limitation keeps you honest.

The directory. Your identity provider holds the record of OAuth grants. Pull the full list and filter for AI-related apps and connectors. This surfaces tools that asked for access to mail, files, or calendars, including the ones that never came near IT. It is the single highest-yield source because it shows not just that a tool is in use but what it can reach.

OAuth and connector signals more broadly. Beyond the headline AI apps, look at the assistants and integrations that bridge two systems. An AI tool wired into your CRM or your code host is part of your data path even if its name does not contain the word AI.

A short staff survey. Three or four questions, sent to the whole company, asking plainly which AI tools people use for work and what they use them for. No blame attached. People answer honestly when the framing is curiosity rather than enforcement, and the survey reaches the channel the directory cannot.

That last point is the honest one. A large share of shadow AI leaves no directory trace. A personal account opened in a browser, used to paste in a paragraph and copy out a rewrite, touches none of your systems in a way you can pull from a log. The directory sees grants. It does not see a tab. This is exactly why the survey matters, and why a written guideline matters even more. For the channels you cannot monitor, the policy and the shared understanding are the control. You give people a rule they understand and a sanctioned alternative they would rather use.

What you are building here is an inventory: a list of what is genuinely running, with the access each item holds, drawn from the directory, the connector signals, and the survey together. That inventory is the input for everything that follows. A policy written without it will have holes its author did not know were there.

classify

Once you can see what is in use, sort it by the data it touches and decide which tools are acceptable for which data. The sorting does not have to be elaborate. It has to be specific enough that an employee can look at the thing they are about to paste in and know whether it is covered. A useful starting set of categories:

• Personal data. Customer records, employee data, anything under GDPR. No consumer-tier tool without a data processing agreement.
• Confidential and NDA-covered material. Anything from a client or vendor relationship with confidentiality terms.
• Source code. The category that most often reaches an external model without anyone deciding it should.
• Non-public financial data. Projections, unreleased results, anything price-sensitive.
• Internal strategy. Roadmaps, org plans, competitive notes.

Against those categories, decide tool by tool. A tool on an enterprise plan with training disabled and a signed DPA can handle more than a free consumer account that uses inputs to train. The output of this move is a short table: which tools are acceptable for which data classes, with the conditions named. Think of it as an acceptability map rather than a ban list.

guardrail

With the map in hand, set the rails. Five pieces, none of them heavy.

A data-classification rule for AI. The one-page version of the categories above, written so a person can follow it. The rule that does the most work is the simplest one: which data classes never go into any external AI tool, with plain examples.

An approved-tools list. A named set of AI tools cleared for work, each with its conditions, for example an enterprise tier required, no personal data, internal use only. A living list, reviewed on a cadence, not a one-time artifact.

A request-and-review path. What an employee does when they want a tool that is not on the list. Name who receives the request and how fast they will hear back, even if the first answer is just that it is being looked at. Requests that vanish into a queue are what drive informal adoption in the first place.

Enterprise tiers with no-training terms. Where a tool is genuinely useful, get the business or enterprise plan rather than tolerating the free tier. The enterprise plan is typically where training on your inputs is switched off and a DPA is available. Approving a tool without specifying the tier leaves the data exposure open.

Tighter control over AI connectors and their scopes. The OAuth grants you found in the see step deserve ongoing attention. Review what each AI connector can reach, prefer narrow scopes over broad ones, and revoke grants tied to tools no longer in use. A connector with broad read access to your mail and drives is a standing data path, whether or not anyone is actively using the tool today.

enable

The last move is the point of the first three. Let the team move fast inside the guardrails. Governance done well makes confident, fast AI use possible, because people no longer have to guess whether a given tool and a given paste are acceptable. They know. The map told them.

The piece that makes enable real is AI literacy. Not a long course. A short, clear explanation of the data rules and why they exist. A rule that says do not paste personal data into AI tools lands better when it comes with the reason. Consumer tools commonly use inputs to train their models. Personal data entered without a DPA creates a GDPR exposure for the company and for the customer whose data it was. People follow guidance they understand, and they make better calls at the edges when they grasp the mechanism rather than just the prohibition. The aim across all four moves is a company where AI use is visible, classified, guard-railed, and fast, in that order, rather than one where it is banned and invisible.

the CTO operating rhythm

A model is only as good as the rhythm that keeps it current. Vendor terms shift, features ship, and grants go stale, so a one-time project ages fast. Three things to settle.

Who owns it. One named owner for the AI inventory, the approved-tools list, and the request path. In a 50-to-500-person company this is usually the Head of IT or the CTO directly, sometimes shared with whoever holds security as part of a wider role. The job is routing: every AI question lands with this person, even when someone else does the work.

The review cadence. A quarterly look at the approved-tools list and the inventory keeps pace with how fast tools and terms move, and in this size of company the teams are usually active adopters. Stretch the gap much past that and the list stops matching reality.

How new tools get added. The request-and-review path is the mechanism, and it works only if it is fast and visible. Someone asks. The owner runs the tool through the vetting questions. A decision comes back within a defined window, with the tool either added to the list with its conditions or declined with a reason. The decision and the reason get recorded, which is what turns the list into an audit trail you can show later. This rhythm is light on purpose. A named owner, a quarterly look, and a working request path are enough to keep the inventory honest and the list current.

a few numbers worth keeping in view

These describe the general pattern; your own picture comes from the see step.

• 78% of employees who use AI at work bring their own, unapproved tools, a pattern Microsoft calls Bring Your Own AI (Microsoft Work Trend Index, 2024). The tools are in use whether or not they were approved.
• When shadow AI was involved in a breach, it added an average of USD 670,000 to the cost of the incident (IBM Cost of a Data Breach, 2025). The additional cost tracks the loss of visibility more than the tool itself.
• 87% of organizations cite AI-related vulnerabilities as one of their fastest-growing concerns (World Economic Forum, 2026).

a note on the EU AI Act

This is context, not the reason to act. The EU AI Act expects an inventory of the AI systems in use, and it places an AI-literacy duty on deployers, meaning organizations that use AI in a professional context. That duty sits in Article 4 and has applied since 2 February 2025. The practical read is that two of the four moves above are already what the Act asks for. The see step is the inventory. The literacy part of the enable step is the duty. Doing the operating model well puts you most of the way toward the deployer obligations as a side effect, which is a better position than treating the Act as a separate compliance exercise.