Shadow AI Is Not an AI Problem. It Is a Visibility Problem.

A department leader says the company has no AI in production. Ten minutes later, the identity console shows eleven AI applications connected to employee accounts. One can read mail. Another can open files. Two were authorized with personal accounts. Finance has been paying for three subscriptions on individual cards.

Nobody lied. Leadership was answering a different question from the one employees were living.

This is what shadow AI looks like in practice. It is less dramatic than a secret robot running the company. People found tools that helped with proposals, meeting notes, spreadsheets, code, and customer research. The organization had no workable way to see the use, evaluate it, or move the useful pieces into a safer operating model.

Chapter 12 of my book walks industry by industry through the same scene with different costumes. The attorney drafting motions. The CPA pasting a tax return "to find deduction patterns faster." The medical assistant uploading a treatment history for a pre-auth letter.

"The associate attorney feeds case details into an AI tool 'to draft motions more efficiently.' Client names. Case strategies. Settlement negotiations. Privileged communications. All of it now sitting in an AI company's servers... Attorney-client privilege doesn't survive a trip through ChatGPT."

One number from the research in that chapter: 11% of what employees type into ChatGPT is confidential company data. None of these people is careless. Every one of them is efficient. That is the visibility problem in a sentence: the risk wears the face of your best employee.

From The 3AM Test by Steve Copeland.

The ban creates the blind spot

When the organization’s only message is no, employees do not stop finding useful tools. They stop discussing them.

The finance manager who saves four hours a week with an AI assistant is unlikely to volunteer that information if approval takes six weeks and the expected answer is prohibition. A blanket ban may create the appearance of control while removing the evidence needed to make a good decision.

That is why shadow AI should be treated first as a visibility problem.

What needs to become visible

An AI inventory needs more than product names. For each use, determine:

• who uses the tool,
• which business workflow it supports,
• what information enters it,
• whether the account is personal or company-managed,
• what identity or OAuth permissions it has,
• whether the vendor uses inputs for training,
• who reviews the output,
• and what would happen if the tool produced a confident error.

This turns a vague fear into a decision register.

Some use cases will be stopped. Some will be moved to an enterprise tier. Some will become approved pilots because they are already producing value. The company cannot make those distinctions when every use is hidden under the same label.

Identity is the underappreciated risk

AI tools are not only websites where someone pastes text. They increasingly connect to email, files, calendars, code repositories, CRM records, and collaboration platforms.

That connection is an identity relationship. OAuth grants can persist. AI agents may receive service accounts or API credentials. A former employee’s automation may continue moving data after the employee leaves.

The AI inventory belongs beside the application inventory and identity review. It should not sit in a separate innovation slide deck.

Governance should create a path

A workable model has four parts.

First, publish a short approved-tool list that distinguishes consumer and business tiers. Second, name the data that may never enter any AI service. Third, assign human review for outputs that affect customers, money, hiring, code, or regulated decisions. Fourth, provide a request path with a real response time.

The fourth part is where most policies fail. If employees can get a credible answer in five business days, they have a reason to ask. If requests disappear for a month, the unofficial process wins.

Discovery without punishment

Start with an anonymous survey and make the purpose explicit: discover useful work and risk, not build a list of violators. Pair the survey with technical evidence such as enterprise application grants, browser extension inventories where available, expense data, and vendor records.

Then publish what you learned in aggregate. Employees should see that honest disclosure produced clearer rules and approved options.

The leadership question

Leaders should ask how to make valuable AI use visible, governed, reviewable, and measurable.

Organizations that answer that question will find risk. They will also find people who have already discovered where AI creates value. Both are useful. Hidden confidence is not.

What a tenant walk-through actually finds

Start with enterprise applications and user consent. In a representative 120-user Microsoft 365 tenant, the first export might show 460 application registrations and service principals. Most belong to Microsoft or known business systems. The useful work is reducing the list to applications with employee consent, meaningful permissions, recent sign-ins, and unclear ownership.

Suppose the review finds 23 AI-related applications. Seven have been used in the last 30 days. Three can read basic profile information. Two can read files the user can access. One requests mail permissions. Four use individual consumer accounts and never appear in company billing.

That is not a breach report. It is a decision list.

The mail-connected tool moves first because access and consequence are higher. The file tools need vendor and data review. A writing assistant with no connected business data may fit an approved low-risk tier. Dormant grants should be removed after confirming the owner and purpose.

Technical discovery gives you evidence, yet it does not explain the work. Interview users next.

Ask people to show the useful part

An anonymous survey should ask which tool, which task, which data, how often, and what review occurs. Then invite volunteers to demonstrate a real use with safe sample information.

You may find a proposal manager who built a prompt that cuts first-draft time from three hours to forty minutes. You may find an analyst pasting customer exports into a consumer chatbot. You may find a coordinator using an approved enterprise tool in a sensible way leadership never knew about.

Treat those cases differently. Move the valuable workflow to an approved environment. Stop the unsafe data handling. Capture the working method and share it where appropriate.

I have found that employees become much more candid when the conversation includes value. If the only question is "Who broke the rule?" people protect themselves. If the question is "What work did you improve, and what would make it safe?" the company learns.

Follow the identity trail

For each connected application, record the publisher, verified status, consent type, permissions, users, last activity, owner, account tier, and revocation path. High-risk permissions deserve direct review. So do applications using broad file access, mail, calendars, CRM records, code, or administrative scopes.

User consent policy matters. Many tenants still allow employees to authorize applications without a practical approval workflow. Tightening consent without adding a quick request path creates support tickets and workarounds. Pair the control with a review queue and a service target the team can meet.

Agents and automations need stronger ownership than chat tools. Record the service identity, credential location, allowed systems, approval points, log location, emergency stop, and person responsible for its output. Offboarding the employee who created an automation should trigger an ownership review.

These controls are ordinary identity management applied to a new class of software.

A seven-day discovery sprint

Day one: publish the purpose and open the anonymous survey. Explain that the company wants to find useful work and protect sensitive information.

Day two: export enterprise applications, OAuth grants, known browser extensions, expense records, and approved vendor lists. Filter for AI-related names and permissions.

Days three and four: interview volunteers and owners of higher-risk grants. Demonstrate workflows with sanitized data. Record benefit, frequency, input data, output consequence, and review.

Day five: classify each use as approve, move to a managed tier, redesign, pause pending review, or stop. Give the user a reason and an alternative when possible.

Day six: remove dormant access, document approved tools, and create the request path. Escalate any evidence of exposure through the incident process.

Day seven: report aggregate findings and decisions. Show employees that disclosure produced safer options and clearer rules.

The sprint will not find every use. It creates a repeatable inventory and proves the company can respond without turning governance into a month-long committee.

Data boundaries people can remember

Long classification tables rarely help someone facing a deadline. Give people concrete examples.

Public material can enter an approved tool. Internal drafts may enter a company-managed tool when the vendor terms and access are approved. Customer data, employee data, credentials, protected health information, payment information, contract-restricted material, and confidential source code require explicit rules and often a dedicated environment.

Teach the boundary with the workflow. "Do not paste customer exports into consumer AI" is easier to act on than "use AI responsibly." Show the approved way to summarize the same data, or say that no approved path exists yet.

Keep a named reviewer for uncertain cases. A boundary with nobody available to interpret it will be ignored under pressure.

Measure adoption and risk together

Track approved active users, reviewed use cases, request turnaround, revoked stale grants, high-risk permissions, training completion, incidents, and measured workflow outcomes. These numbers show whether governance is creating visibility.

Avoid treating low usage as the goal. A company may want more approved AI use in low-risk workflows and less unmanaged use around sensitive data. The direction matters.

Revisit the register quarterly. Vendors change terms and features. Permissions expand. Employees leave. A tool approved for drafting may later connect to the CRM. Approval belongs to the use and configuration, not the logo alone.

The field mistake: announcing a ban before looking

A sudden ban feels decisive. It can also erase the chance to learn which workflows already depend on AI. Teams move to personal devices, personal accounts, or renamed features inside products the company already uses.

If an immediate stop is required for specific sensitive use, be direct and narrow. Name the data or permission at risk. Give a reporting path. Preserve logs and evidence when exposure may have occurred.

For the broader program, discover first. Leadership needs a map before it can choose where to build roads and where to put guardrails.

Shadow AI shrinks when the official path is faster, safer, and useful. Visibility is the first operating capability. Trust grows from what the organization does with it.

Review the vendor as well as the use

An approved use case can still sit on a weak vendor. Check who owns the company, how it secures data, whether prompts and files train models, where data is processed, how long records remain, which subprocessors participate, and whether administrators can see and remove accounts.

Ask what happens when a feature changes. An assistant that begins as a writing surface may later add connectors or autonomous actions. The approval should name the tested tier, configuration, and permissions.

For material workflows, confirm logs, export, incident notice, support, continuity, and contract exit. Small pilots can receive proportionate review. Production systems handling sensitive data need more.

Give managers a simple conversation

Managers do not need to become AI security specialists. Give them five questions for a team member who wants a tool:

What work are you trying to improve? What information enters the tool? Which systems can it reach? Who checks the result? What happens if it is wrong or unavailable?

Those questions surface most of the routing decision. Low-risk drafting can move quickly. Connected or consequential use goes to technical, privacy, legal, or security review.

The manager should also ask how success will be measured. A useful tool can still fail to produce enough value for its cost and attention.

Handle discoveries with care

If the review finds sensitive data in an unapproved service, preserve the facts and use the incident process. Determine what entered, who could access it, vendor retention, contractual duties, and whether notification or legal review is required.

Avoid public blame. Employees often followed an unclear path under pressure. Correct the exposure, improve the control, and make the approved method easier to find.

When the review finds a strong use case, recognize the employee who found it. Move the workflow into a governed environment and let others learn from it.

What leadership should see each quarter

Report approved use cases and their results beside unmanaged discoveries and risk work. Show request turnaround, connected applications, high-risk permissions, ownerless automations, and decisions due.

One useful page might say: 14 approved workflows, six measured; three new connected applications reviewed; two stale grants removed; one data-handling issue corrected; average request decision in four business days; two vendor reviews due next month.

That view treats AI as an operating portfolio. It gives leadership a way to discuss adoption and risk in the same meeting.

Visibility should lead to choices people understand. That is what turns shadow use into managed capability.