Shadow AI and usage monitoring
All notes
Everything here, grouped by subject.
No products or models named. No adoption percentages. Nothing here is legal advice.
What this covers
From finding out what is happening to providing something people will switch to
Eight sections, in the order a programme actually runs: understanding why it happens, finding what is in use, sizing the risk, deciding what to monitor, writing rules people follow, providing a real alternative, and governing the result.
Why it happens
Every instance says the task was hard enough that somebody went looking, and the approved route did not cover it.
6 notes →Finding what is in use
Four sources, used in the right order. Ask first; the technical ones confirm rather than catch out.
7 notes →Sizing the risk
The risk sits in which classification of data goes where, not in which tool was used.
7 notes →What to monitor
A URL is a destination. A prompt is a draft, and people write things in them they would never send.
7 notes →Writing the rules
Rules about tools are obsolete within a quarter. Rules about information survive.
7 notes →Providing an alternative
The only intervention that reliably reduces shadow use, and the one most often done badly.
6 notes →Reference
The end state as a description, the twelve failures, and the order to do things in.
4 notes →Before writing any policy
Three things that cost two days and change the answer
Announce an amnesty
Say what you are doing and why: we want to know what is useful so we can provide it properly, and nobody is in trouble for what this finds. Then honour it, because the first person disciplined ends your ability to run another.
Ask before you look
Four anonymous questions: what tools, for what tasks, what would make you switch, and where was there nothing. The last two produce a requirements list rather than an inventory.
Check the extensions
Browser extensions can read page content by design. One on a machine used for a confidential system is sending that content somewhere regardless of intent, and it is invisible to network logs.
All 50 notes
All fifty notes, by subject
- What Shadow AI Actually Is
- Why People Use Tools You Did Not Give Them
- The Risks, Sorted by How Real They Are
- What Actually Leaves, and Where It Goes
- Why Blanket Bans Do Not Work
- What Is Different About AI Specifically
- Finding What Is Already in Use
- Network and DNS Evidence
- Browser and Endpoint Evidence
- Expense Claims and Card Data
- Asking People Directly
- The Inventory, and Keeping It Current
- What Discovery Will Not Find
- Data Classification Before Anything Else
- What the Provider Does With Your Input
- Retention, Training and the Terms That Matter
- Consumer Accounts Versus Enterprise Agreements
- Model Output Risk: Accuracy and Attribution
- Regulated Data and Where It Cannot Go
- Sizing the Risk Honestly
- What You Can Monitor, Technically
- Prompt Content: the Line You Should Think About
- Aggregate Versus Individual Visibility
- Detection Without Interception
- False Positives and What They Cost
- Telling People What Is Monitored
- Retention of Monitoring Data
- Writing a Policy People Will Follow
- The Approved List, and Keeping It Short
- Classification-Based Rules
- What to Prohibit Outright
- Exceptions and How to Grant Them
- Policy for Code and Developers
- Reviewing the Policy as Tools Change
- Providing a Good Enough Alternative
- Procurement That Keeps Up
- Training That Is Not a Video
- Champions and Where They Help
- Measuring Whether People Switched
- When the Approved Tool Is Worse
The short version
Provide before you restrict
Find out what people are doing and why, give them something good enough that the approved route is the easy one, write rules about information rather than tools, and monitor the destination rather than the content.