Shadow AI Policy: The One Page I Would Write First

A shadow AI policy that works fits on one page, and an employee can read it in two minutes. I think most do not, and that is the main reason shadow AI risk keeps growing inside companies that already have a policy on paper.

This is the follow-up to item 8 in What Keeps CTOs Up at Night, where I said a ban will not work and gave the rules in a line each. Here is how I would turn those lines into the page itself.

As a CTO, I came across many cases where employees had uploaded confidential company information into public AI tools to get their work done. Nobody meant any harm. They wanted to finish the task faster. It was still not the right thing to do, and it is why I would start with a clear policy and not with blame.

The 30 second version

• A ban moves AI use out of sight. It does not stop it.
• Find out what people already use before you write a word.
• Name one approved tool per use, and sort data into red, amber and green.
• Apply the rules the same way to everyone, then measure how much work has moved onto approved tools.

Why most AI policies do not work

Two things go wrong. The policy is copied from a template before anyone has checked what staff use, so it describes a company that does not exist. And it says no without giving a yes.

The employee still has a deadline. So the tool moves to a personal phone or a home laptop, where your network blocks nothing and your logs show nothing.

A policy that only says no does not remove shadow AI risk. It removes your view of it.

What shadow AI risk looks like

It comes in two forms.

• Data going out. Customer records, source code, contracts, salary sheets and next quarter’s plan pasted into a personal account. Once there, you cannot see where it is stored or whether it is kept.
• Tools reaching in. Browser assistants, plugins and agents that someone connects to work email, files or code. They act with that person’s access. This includes AI features a vendor switches on inside a tool you already approved.

The first is a leak. The second is closer to an unvetted contractor holding a staff login. The UK’s NCSC makes the same point in its note on shadow AI: the aim is to reduce the risk, because it will not disappear completely.

Step 1: Find out what people already use

Spend two weeks on this before you draft anything. I would ask first and monitor second, because people tell you more when they are not worried about being caught.

Ask every team five questions:

1. Which AI tools do you use for work, including free ones and personal accounts?
2. What do you use them for?
3. What kind of data goes in?
4. Which one would you hate to lose?
5. What is missing from the approved tools that made you look elsewhere?

Then compare the answers with what you can see: single sign-on app lists, browser extensions on company laptops and expense claims for AI subscriptions. The gap between the two is your real starting point.

Step 2: Write the shadow AI policy on one page

Seven rules, a sentence or two each. If your draft needs more than a page, you have written a compliance document. Split it out and keep the page.

1. Approved tools. List them by name, with the use each one is for. Anything else needs a request first.
2. Data rules. Use the red, amber and green table below.
3. No personal accounts for work data. Even a good tool becomes shadow AI when it is used from a personal login.
4. Assistants, plugins and agents need approval before they touch work email, files, calendars or code. Give them the access of a new joiner, as I said in the CTO post.
5. How to ask. One route, one named person, an answer within five working days. A request that sits for a month teaches people to stop asking.
6. If you slipped. Report it the same day, without blame. A report today is cheaper than a leak found later.
7. Owner and review. One named owner, reviewed every quarter, because the tools change faster than the policy.

The data table

Put the table on its own page and pin it where people work. It is the part they will actually use.

I have not checked how each AI vendor treats data retention and model training today. Those terms change, so read the current terms of a tool before you clear it for amber or red data.

Step 3: Make the approved path the faster one

Pick one real task, such as summarising a long contract or debugging a function. Time it in the approved tool and in the personal one. If the personal tool wins, fix that before you write another rule. People take the faster path, and no policy changes that.

Name one approved tool for each common use, such as writing and coding. For each, ask what the company plan says about your data being used to train the vendor’s models, and get the answer in writing.

Step 4: Enforce it evenly, then measure

Apply the rules the same way to the CEO and the intern. One quiet exception for a senior person undoes the policy within a month.

Technical controls help at the point where data leaves. I would block a tool only after its approved replacement is ready, and use data-loss controls on the browser for red data.

Measure the gap you closed, not the tools you blocked:

• Share of AI use on approved tools. This should rise.
• Time to answer an approval request. This should fall.
• Incidents reported. Expect this to rise at first. It means people trust the route.

If someone already pasted something they should not have

1. Ask the person to stop, and to write down what went in, which tool, which account and when.
2. Tell the policy owner the same day, without blame.
3. If it was a password, key or token, rotate it and treat it as exposed.
4. Check whether the tool lets you delete the chat or the account data. I have not checked every vendor’s process, so confirm with the vendor.
5. If customer personal data was involved, bring in legal at once, because notification duties may apply.

If you hold personal data of people in India

The DPDP Act matters here. As I read section 8(5), a company must take reasonable security safeguards for personal data it holds or controls, and the maximum penalty for failing at that is ₹250 crore. A customer list pasted into a personal chatbot account is the kind of leak that section is about. Law firm summaries put the start of most duties, including security safeguards, at 13 May 2027. Confirm the date with counsel, since I am not a lawyer. I would still write the policy now.

My post on the DPDP Act for CEOs covers what compliance asks for. Singapore and the UAE have their own data rules. I have not mapped them here, so check them before you copy the table.

Frequently asked questions

What is a shadow AI policy?

A short document that says which AI tools staff may use for work, what data may go into them, how to ask for a new tool and what to do after a mistake. It is the AI counterpart of a shadow IT policy.

What is shadow AI risk?

The exposure that comes from staff using AI tools the company has not approved or cannot see. Company and customer data leaves through personal accounts, and assistants or agents get connected to work systems without review.

Should we ban public AI tools?

I would not start with a ban. Block a specific tool only once an approved alternative does the job. A ban on its own moves the use to personal devices, where you see nothing.

Is a shadow AI policy the same as an AI acceptable use policy?

Close, but not the same. An acceptable use policy usually covers more: how outputs are checked, disclosure and banned uses. A shadow AI policy is the short part about tools and data. I would write the one page first and let it sit inside the larger policy later.

My takeaway

If I had one afternoon, I would name the approved tool and write the red, amber and green table. Those two things change what people do tomorrow. The rest of the page can follow within a week.

Last reviewed: November 2026. Laws, vendor terms and tool features change, so check the current versions before you rely on them.

Related reading

• What Keeps CTOs Up at Night: Ten Pressures and What I Would Do First
• Navigating the DPDP Act: A CEO’s Guide to Personal Data Protection in India
• Why Tech-Savvy People Fall for Scams: Six Attacks Built for Smart Targets