AI usage policy: framing shadow AI in 2 pages

As you read this sentence, someone in your company is pasting a contract clause, a prospect list or a snippet of code into an AI tool no one approved. Not out of bad intent: the tool saves time, no rule says otherwise, so they use it. You cannot put a guard behind every screen. What you can do fits on two pages: a usage policy that states what is allowed, what is not, and where to go when in doubt. Here is what it contains, what it actually solves, and where it stops.

Is shadow AI already inside your company?

Yes, and not by a little. A large majority of employees use generative AI at work, and nearly half do so on tools their company never approved. A reflex, not disobedience, and that is exactly what makes it invisible. The problem is not AI itself: it is that a live quote, a contract clause or a customer file can end up pasted into a free service whose terms sometimes allow it to reuse whatever you type. The leak is not hypothetical, it has already happened, you simply did not see it go by.

• A contract excerpt or a sensitive clause, pasted in to be reworded more clearly.
• A prospect or customer list, dropped in to draft a mailing.
• An interview write-up or an HR document, summarised in two lines.
• Internal code, debugged in a consumer tool.
• Unpublished figures, slipped into a request for analysis.

Why doesn't banning solve anything?

The natural reaction is to block everything. Except a ban does not remove the usage, it moves it: onto the personal phone, the personal account, the home connection. You then lose the little visibility you had left, and you still have no trace of what leaves. Technically, blocking a site does not block a behaviour: there are ten tools for every one you filter, and a new one every week. A policy does the opposite of a block. It assumes your teams will use AI, and it channels that use instead of denying it: what is allowed, what is not, and the safe tool to reach for when the urge is there. You can only frame well what you agree to see.

What actually goes into those two pages?

As little as possible, but the right little. A useful policy fits on two pages because it does not try to foresee everything: it settles the handful of cases that come up every day. Five building blocks are enough.

• What never leaves: the plain-language list of data never to paste into a public AI tool (customers, HR, contracts, unpublished figures, technical secrets).
• The approved tools: a short list of authorised tools, and for which use.
• The when-in-doubt rule: one line naming who to contact when you hesitate, rather than leaving everyone to decide alone.
• What we always reread: an AI answer is checked before it is sent to a customer or signed, because it is allowed to be wrong with full confidence.
• The minimum literacy: one page so everyone understands what an AI can make up, which already meets the spirit of the first AI Act obligation.

Notice what is not there: no legal jargon, no twelve-column risk matrix, no three-step approval flow. The policy settles the everyday, not the edge cases of a law firm.

How do you write a policy your teams will actually read?

Most policies fail not because they are wrong, but because they are unreadable. Thirty pages written by a lawyer end up filed in a shared folder no one opens. A policy that protects is one people read in five minutes and still remember the following Monday. A few concrete principles make all the difference.

• Two pages, not thirty: if it does not fit on two pages, no one reads it to the end.
• Examples over principles: a line like do not paste the customer list into a chatbot lands harder than preserve data confidentiality.
• One accountable owner: the policy has someone who answers questions and keeps it current, or it ages in silence.
• A living document: tools change every month, so does the approved list. A frozen policy is wrong within three months.
• Explained out loud: a two-hour workshop anchors the policy better than ten emails no one opens.

Does this policy make you compliant with the AI Act?

No, but it puts you on the right path right away. The first AI Act obligation already in force is about literacy: your teams must have a sufficient understanding of the AI they use. The policy's literacy page answers that in spirit, without launching a training plan. Be careful not to conflate two things, though: a policy lowers the risk of a leak and ticks an awareness box, it does not make you compliant on everything else. Depending on what you do with AI, other obligations apply, and it is worth knowing which ones touch you. I have laid out what the AI Act actually asks of businesses: the policy is the first step, not the summit.

Where does the policy stop, and what comes next?

Let us be clear: a policy sets rules, it does not enforce them for you. It rests on goodwill, and goodwill has its limits the day the banned tool is the most convenient one. Nor does it replace sovereign tools, where your data stays with you rather than with a third party. It is a starting point, deliberately light, and that is exactly right: you begin with the cheapest move that removes the most risk. Then, if the topic deserves it, the real answer to shadow AI is not to ban more, it is to offer better: an internal AI tool wired to your own data, good enough that no one wants to work around it anymore.

A policy no one reads protects no one. Two pages people understand beat thirty they file away.

Shadow AI is not fought with bans, it is framed. Two clear pages, a workshop to explain them, and you turn a blind spot into rules your teams can actually follow. It is short work, and I do it with you: we write the policy, we explain it to your teams, then we look at whether an internal tool is worth building. If your teams already use AI with no framework, let's talk: a first conversation is often enough to know where to start.