Rolling out AI without a policy vacuum

Almost every organisation that thinks it is deciding whether to adopt AI has already adopted it. Someone is pasting a draft contract into a personal account this afternoon. The live question is whether that happens on accounts you chose, under terms someone has read.

That reframing changes the order of the work, which is the point of this page.

Provision before you restrict

A policy forbidding confidential material, issued without a compliant place to put that material, produces exactly the behaviour it prohibits. People find the tool useful, the tool is a browser tab away, and the prohibition mainly teaches them to stop mentioning it.

Consumer and commercial plans are different contracts, and the difference is the one your data-protection assessment turns on: consumer plans carry a training toggle with retention measured in years, while commercial terms prohibit training on inputs. See What data may go into a model.

So the sequence that works: provide accounts, say what may go in them, then restrict everything else. Reversing it produces shadow usage and no visibility.

Shadow AI is where you are starting from

Plans tend to be written as though adoption begins when the project does. It began earlier. Some proportion of your staff has been using a personal account for months, and the number is reliably higher than the one people volunteer in a survey with their name on it.

Treat that as the baseline you are working from. Calling it a violation to stamp out changes nothing except what people tell you.

What it costs you while it continues. Work sits in accounts you have no agreement with, on consumer terms someone accepted without reading. You cannot answer where company material went, you have no deletion route, and none of it appears in any log you hold. That exposure is running now, and it grows with every week the compliant option does not exist.

Why asking does not measure it. Nobody reports a policy breach on a form. Ask instead about the work: which tasks feel repetitive, where people paste between tools, what they would automate. Answers arrive because nothing is being confessed.

What ends it. A better option. Prohibition alone has never managed it, because shadow use persists exactly where the sanctioned tool is absent, slower, or more restricted than the personal one. A rollout that provisions first converts that use; one that restricts first relocates it somewhere you cannot see.

A useful thing to say out loud at the start: we are not asking what you have been using, and from today here is the account to use. Amnesty costs nothing and buys the visibility the next twelve months depend on.

A worked sequence, to adapt

An example for an organisation of ten to a few hundred people. Yours will differ; the reasoning is the transferable part.

1. Find out what is already in use. Ask, without consequences attached. A survey that threatens discipline returns a picture of what people are willing to admit.
2. Provide accounts under commercial terms for the groups where the value is obvious. Start narrow.
3. Publish the data rules in the place people are when they need them, so the decision is answerable in ten seconds. A PDF in a policy folder is a scheme that functionally does not exist.
4. Run a real pilot with a measurement, before the enthusiasm decides. See below for why this step usually goes wrong.
5. Handle participation and privacy obligations early — literacy under the AI Act, and in Germany and Austria the works council, which turns partly on whether you generate usage data per person.
6. Widen, then review on a date you set now. Systems change faster than policies, and a policy nobody revisits is a policy that describes last year.

Measure something, because the feeling lies

The one place a rollout most reliably fools itself.

In the best-measured study available, experienced developers using AI tooling were slower on real tasks while reporting that they had been substantially faster. The measured and felt results pointed in opposite directions by a wide margin. Details and its limits are in Does it actually make you faster?

The practical consequence: "the team loves it" is not an evaluation. Pick a crude measure you can take before and after — cycle time on a recurring task, review load, defect rate, tickets closed. Crude and consistent beats sophisticated and abandoned.

Expect the answer to be uneven across roles. That is a useful finding rather than a disappointing one: it tells you where to widen next.

What a rollout owner actually owns

Someone has to hold these, and in most organisations nobody does:

• Which plans and which groups, and why those groups first
• Where the data rules live and who keeps them current
• What is measured, and when it gets looked at
• Who reviews an incident and what happens after
• The review date

If a governance framework is on the table, the choice between them is its own question: which framework, if any, and whether to certify.

None of that requires a programme. It requires a name against each line.

What goes wrong

Restricting before providing. Creates shadow usage and removes your visibility into it.

Rolling out to everyone at once. No pilot, no measurement, and a support burden that arrives all at once.

Evaluating on enthusiasm. Self-reported productivity has been shown to diverge sharply from measured productivity.

Treating it as a tooling decision. Data handling, participation and literacy obligations arrive whether or not anyone planned for them.

Writing the policy last. By then the habits are set and you are asking people to give something up.

How to check it worked

Three months in, ask a handful of people in different roles what they may put into the tool and where they checked. If the answers differ, the rules exist as a document rather than as a practice, and the fix is placement rather than more policy.