10,000 m
The boardroom
Who drafts the policy matters
Most AI policies are written by legal, risk and a consultant, then handed to engineers who were already using the tools. The result bans things nobody does and misses the things everybody does. People follow a rule when they recognise their own work in it. So let the people who use AI every day draft the rules, and keep executives for the part only they can do.
That part is signing off the risk. Executives decide what data can leave the organisation, which vendors are acceptable, and who is accountable when an AI-assisted change goes wrong in production. Engineers can recommend all of that. Only leadership can own it.
3,000 m
The architecture
Classify the data, not the tool
A policy built around a list of approved products is out of date before it is published. Build it around data classification instead. Public and internal data can go to approved services under an enterprise agreement. Confidential data needs a tenant with no training on inputs and logging you control. Customer personal information stays inside the platform boundary, full stop.
Tools change every quarter. Data classifications change every decade.
300 m
The delivery team
Rules that fit on one screen
At team level, the policy should fit on one screen and live in the repository. Say which tools are approved, what must never be pasted into a prompt, and which changes need a human author rather than just a human reviewer. Keep examples short and specific, because engineers will read an example long before they read a principle.
Revisit it every quarter with the people who use it. The tools will have changed, some of the rules will already be wrong, and the engineers will know which ones before anybody else does. Treat the policy like code: version it, review changes in a pull request, and record why each rule exists so the next revision does not undo a lesson learned the hard way.
