In the first part of this we said: draft an AI acceptable use policy this week. A lot of organisations did. We have since read a good number of them, and in most of those companies the behaviour has not changed at all. The document exists, it is signed, it is in the intranet, and the marketing team is still pasting client material into whatever is fastest. This piece is about why, and what a policy that survives contact with a deadline looks like.

Three reasons the policy on your intranet is not working

It was written as a prohibition. A list of things employees may not do, produced by people who do not do their jobs, creates exactly one incentive: do not get caught. The organisations where this works least well are the ones where the policy is strictest, because an absolute ban on a useful tool is understood by everybody as theatre, and a rule that is visibly theatre teaches people that the other rules might be too.

It names tools instead of classifying data. A policy that lists approved and forbidden products was out of date the week it was signed. Tools change names, get acquired, add AI features, and appear inside software you already own. The only durable rule is about what may leave, not about which door it leaves by.

It made the right path slower than the wrong one. This is the big one. If using the sanctioned tool means a request, a wait and a justification, while the unsanctioned one is a browser tab, the policy is competing against convenience and it will lose every time, including with your best people, especially with your best people, because they are the ones under the most time pressure.

The invisible half nobody surveys

When we run an AI usage review, the tools employees tell us about are rarely the interesting part. The interesting part is the AI that arrived inside software the company already pays for: meeting transcription and summarisation in the collaboration suite, drafting assistance in the mail client, summarisation in the CRM, suggested replies in the support desk, code completion in the development environment.

Nobody adopted these. They appeared in a release note, enabled by default, and they process exactly the material your policy is supposed to protect. Any policy that does not have a section on features inside existing products is covering the smaller half of the problem. The practical step is unglamorous: go through the admin console of every major platform you own, list the AI features, and record for each one whether it is on, what it processes and whether anyone decided that.

The rule that has to fit on one page

If your staff cannot recall the rule while looking at a deadline, you do not have a rule. Three tiers is the most anyone retains.

  • Open. Material that is already public or would cause no harm if it became public: published marketing copy, public documentation, generic drafting and brainstorming, code that contains no credentials and no business logic you would not show a competitor. Any sanctioned tool, no approval needed.
  • Internal. Non-public but not sensitive: internal procedures, anonymised analyses, draft plans. Enterprise or self-hosted tools only, meaning the ones where your contract or your own hardware governs the data.
  • Restricted. Personal data, client material under confidentiality, credentials, security configurations, unpublished financials, anything covered by a specific contractual duty. Self-hosted only, or not at all, with a named approver.

Then the part that makes it work: fill each tier with three or four examples from your own business, in your own vocabulary. "Client material" means nothing. "The scanned survey report for a named vessel" means something to the person holding it.

What else has to be in it

A sanctioned tool register with an owner and a date. Not an appendix in a signed PDF. A living page, reviewed quarterly, that says for each tool: what it may be used for, which data tier, who owns the relationship, when it was last reviewed. If it has not been reviewed in a year, it is not a register, it is a historical document.

A fast approval path, with a deadline on you. Our recommendation is five working days: a request describes the tool, the task and the data tier, and if nobody has answered within five working days it is approved for a limited pilot by default. This makes a lot of security people uncomfortable, which is the point. Most unsanctioned use is not defiance, it is impatience. A binding deadline on the approver is the single strongest anti-shadow control we know, and it costs nothing.

Output rules, not just input rules. Every policy we read governs what goes in. Almost none governs what comes out. Three provisions belong here: the person who used the tool owns the accuracy of what it produced and cannot attribute an error to it; synthetic image, audio and video content must be labelled, as must AI-generated text published to inform the public, unless a named person has reviewed it and holds editorial responsibility; and no decision about a person is made by a model alone.

The labelling clause is no longer a matter of taste. Article 50 of the AI Act has applied since 2 August 2026, and the literacy duty in Article 4 has been supervised by national authorities since the same date. Putting the labelling convention in the policy converts a repeated judgement call into a habit, which is the only form in which it will actually happen. We set out what the Act asks of ordinary users in The EU AI Act If You Only Use AI.

Monitoring, proportionate and announced. If you inspect proxy logs for traffic to AI platforms, say so in the policy. Covert monitoring of staff is a separate legal problem that you do not want layered on top of this one, and announced monitoring works better anyway, because deterrence is the point.

A no-blame disclosure lane. Somewhere in your organisation, this month, someone will paste something into the wrong window. What happens next determines whether you find out in an hour or in a regulator's letter. Write it explicitly: report it, here is the address, and reporting promptly and honestly will not by itself lead to disciplinary action. Then honour it the first time, in public, because the first case sets the precedent for every case after it.

An owner and a review date. One named person, a quarterly review, and a rule that any new AI feature in an existing platform triggers a review rather than waiting for the next one.

Make the compliant path the fast path

Everything above is process. The thing that actually moves behaviour is making the sanctioned option genuinely better. Whatever you approve has to be at least as fast, at least as capable and at least as available as the free consumer alternative, or your people will keep the free one and simply stop telling you.

This is the practical argument for an enterprise agreement with real data protection terms, and increasingly the argument for a private assistant on your own hardware, which removes the data question entirely for the tier of work that was never going to be allowed off the premises. We set out what that costs and where it hurts in The Private AI Assistant. Either way the principle is the same: you cannot police your way out of a usability problem.

What to measure

Four numbers, reviewed with the policy each quarter: how many approval requests came in and what the median response time was; how many tools are on the register and when each was last reviewed; how many self-reported incidents you received, where a rising number early on is a good sign rather than a bad one; and what proportion of staff in each function completed the literacy session, with dates, since that is now evidence you may need.

The number you will not get is the true volume of shadow use, and you should stop trying. The useful proxies are whether people are asking, and whether they are telling you when something goes wrong.

The point of the exercise

A policy is not a document, it is the behaviour it produces, and the behaviour you want is narrow: people should know what may leave the building, have a fast way to ask when they are unsure, own what the machine produced in their name, and be able to say so without fear when they got it wrong. Everything else in the policy exists to support those four sentences.

If the version on your intranet cannot be summarised in those terms, it is not protecting you. It is documenting, in writing and with a signature, that you knew what was supposed to happen.

This is the second part of Shadow AI: The Hidden Security Risk Lurking in Your Organisation. Related reading: The EU AI Act If You Only Use AI, The Private AI Assistant and You Trained Your Employees. Who's Training Your AI Agents?