An AI-use policy people will actually follow
Most AI guidelines fail the same way: written by someone who is not shipping, for a team that is.
The usual state of play inside a team: half of it is generating features with AI tooling at speed, the other half does not trust any of it, and there is no shared standard for what is safe to ship. Nobody is wrong, exactly. They are just operating on different unwritten rules.
The reflex is to write a policy. The reflex after that is to write the wrong one — a document about which tools are permitted, drafted by someone who is not in the codebase, that everybody nods at and nobody consults again.
Policies about tools age badly
A list of approved tools is out of date within a quarter, and it answers a question your team was not really asking. What they want to know is narrower and more urgent: I have generated this thing — can I ship it, and who is responsible if it is wrong?
So write the policy about outputs and accountability instead. That version survives the next model release.
The four questions worth answering
- What may leave the building? Be explicit about what can go into a third-party tool — customer data, unreleased work, credentials, anything under NDA. This is the one part that should read as a hard line, not a preference.
- What has to be reviewed by a human who understands it? Generated code that touches auth, payments, personal data, or migrations should never merge on the strength of "it looked right".
- Who owns the output? The person who merged it. Not the tool, not the person who prompted it. Naming this once removes most of the ambiguity people are actually anxious about.
- What has to be disclosed, and to whom? Clients, users, and in some cases regulators have different answers here. Decide it deliberately rather than per-incident.
Keep it to a page
A policy nobody can hold in their head is a policy nobody follows. One page, written in the language your team actually uses, is worth more than a thorough document that lives in a folder. If it cannot be summarised in a standup, it is too long.
The goal is not to slow your team down. It is to make the fast path the safe one, so that nobody has to choose.
Then revisit it on a schedule — twice a year is plenty. The tools will have changed. The four questions will not have.
Sound like something you're in the middle of?
If any of the above is uncomfortably familiar, that's usually the moment a conversation is worth having.