Writing an AI Policy Your Team Will Actually Follow

AI policies fail in a characteristic way: they arrive as twelve earnest pages, get skimmed once at a staff meeting, and are never opened again — while the organisation's actual practice develops in group chats, one improvisation at a time. The failure isn't a lack of diligence. It's a category error about what a policy is for. A policy isn't a fence around every possible situation; it's a shared answer to the handful of questions people actually face.

The five things a usable policy names

Strip away the preamble and a working AI policy has to settle five questions. Everything else is commentary. These are the questions staff and volunteers are already answering for themselves, tool by tool and evening by evening; the policy's job is to answer them once, out loud, for everyone.

• 01Which tools are approved for organisational work, and who has the authority to approve a new one — so experimentation has a front door instead of a back channel
• 02What data may be submitted to those tools, and what may never be — with member personal information, donor records and electoral roll data named explicitly, not implied
• 03What review each kind of output needs before it ships — a supporter email, a media statement and an internal summary carry different stakes, and the policy should say so
• 04When the organisation discloses that AI was involved — the transparency norms for published material, imagery and correspondence
• 05How staff and volunteers raise a concern about an AI use they've seen or been asked for, and who is responsible for hearing it

Short beats comprehensive

A policy competes for attention with everything else in a busy organisation, and it loses to almost all of it. The version that wins is the one a coordinator can hold in mind at nine o'clock at night while deciding whether to paste something into a chat window. That argues for a single page — two at most — written in the organisation's own voice, with the five answers findable in ten seconds. Comprehensiveness is what the review rhythm is for; the document itself should be small enough to be known.

There's a second advantage to brevity: a short policy is falsifiable. When it's wrong, people notice, and it gets fixed. A long one is simply routed around.

Sign-off and the six-month rhythm

The policy should go to the management committee not as a courtesy but because the committee owns the risk it governs — under the ACNC's governance standards, the duty to see the organisation's resources handled responsibly sits with them, and member data is a resource. Then put a date on it. Six months is the right interval: long enough to gather real experience, short enough that the document doesn't fossilise while the tools it describes change underneath it. The six-month review isn't a rewrite. It's three questions — what did we approve, what went wrong, what does the policy not cover — and a dated amendment.

Fold it into how people arrive

A policy that lives in a drive folder governs nobody. It starts working the moment it's woven into how people join: a five-minute segment in volunteer induction, a line in staff onboarding, a copy attached to the welcome email. New people are the ones most likely to improvise, and the most receptive to being told how things are done here. A ten-minute refresher at a team meeting whenever the six-month review lands closes the loop for everyone who arrived before the policy did.

Where staff are covered by an enterprise agreement, consult the union delegates before the policy lands, not after. AI use touches workload, surveillance anxieties and job design, and delegates will surface the practical objections a management committee can't see from where it sits. A policy negotiated in daylight gets followed; one announced by email gets tested.