AI coding policy template for software teams.

1. 01

   Which tools are allowed

   Most teams already have an answer in practice. Writing it down is what turns shadow usage into something you can support.

   • Approved AI coding tools are: [list tools, e.g. GitHub Copilot, Cursor, Claude Code].
   • They are used through accounts provisioned by [team or person], never personal accounts.
   • Using an unapproved tool on company code is not a disciplinary matter; it is a signal that this list is wrong. Raise it with [person] and we will review it.
   • This list is reviewed every [quarter / six months].
2. 02

   Where code and customer data may go

   The question is not whether a tool is trustworthy in general, but which of your data it is allowed to see.

   • Approved tools may see: source code in [repositories or scope].
   • No AI tool may be given: customer personal data, production database contents, credentials, or [anything else].
   • Where a tool offers a setting that excludes your data from model training, that setting is on. Responsibility for confirming it sits with [person].
   • Repositories excluded from AI tooling entirely: [list, or "none"].
3. 03

   Secrets

   A secret pasted into a prompt has left your control, whatever the vendor policy says. Treat it as published.

   • Never paste credentials, API keys, tokens, certificates or connection strings into a prompt, including as part of a larger paste.
   • A secret that reaches a prompt is treated as leaked: rotate it and tell [person or channel]. There is no penalty for reporting this.
   • Secret scanning runs in CI on every pull request. See [link to the check].
4. 04

   Review of AI-written code

   This is the clause that does the most work. Everything else is scope; this is practice.

   • Generated code is a draft until a person has read and understood it. "It passed the tests" is not understanding.
   • A pull request containing substantially AI-generated code is labelled [label, e.g. ai-assisted] so the reviewer knows what they are reading.
   • The author can explain, in their own words, why each non-obvious change is there. A reviewer may ask, and "the model wrote it" is not an answer.
   • Pull requests stay small enough to review properly: target under [n] changed lines. Split anything larger.
   • AI review tools may comment on a pull request. They do not approve one.
5. 05

   Testing

   Generated code is usually locally plausible, which is exactly the failure mode tests are worst at catching and most needed for.

   • AI-written code meets the same coverage and test requirements as hand-written code. There is no lighter path.
   • New behaviour arrives with a test that fails without the change.
   • Generated tests are reviewed as carefully as generated code; a test that asserts the current behaviour rather than the intended behaviour is worse than no test.
   • Required checks before merge: [list, e.g. unit tests, lint, type check, secret scan].
6. 06

   Licence and IP

   The commercial exposure is small but real, and it is the question your customers’ procurement teams ask.

   • We do not knowingly ship AI-generated code that reproduces a third-party work.
   • Where a tool offers a filter for suggestions matching public code, that filter is on.
   • Dependencies suggested by an AI tool are checked for licence compatibility like any other dependency, before they are added.
   • Questions about ownership of generated code go to [person].
7. 07

   Accountability

   Without this clause, "the AI wrote it" becomes an answer. With it, nothing changes: the person who merged it owns it.

   • The engineer who opens a pull request is the author of every line in it, whatever wrote the first draft.
   • The reviewer who approves it is accountable for having understood it.
   • When an incident involves AI-generated code, that fact is recorded in the postmortem — not to assign blame, but so we can see the pattern.
   • Incidents are reviewed blamelessly. This clause exists to keep ownership clear, not to find someone to hold responsible.
8. 08

   Data protection and regulation

   Short, and worth having a real answer to before someone asks for it in a security questionnaire.

   • Where an AI tool processes personal data, applicable data-protection law applies as it would to any other processor: lawful basis, a record of processing, and a data processing agreement with the vendor.
   • We review this policy when relevant regulator guidance on AI and automated decision-making is updated.
   • If our product puts AI output in front of users in a regulated market, applicable transparency duties apply. Owner: [person].
   • This is not legal advice. Have [your counsel] read this before it becomes policy.
9. 09

   Keeping this honest

   A policy nobody measures is a document, not a control.

   • Owner of this policy: [person]. Last reviewed: [date]. Next review: [date].
   • We track [PR cycle time, review time, test coverage, change failure rate] and look at them together every [month / quarter].
   • If a clause here is slowing people down without preventing anything, it is wrong. Say so.

Before you paste this into the handbook.

A policy is the easy half.

Writing the rules down takes an afternoon. Knowing whether they are being followed, and whether they changed anything, takes a baseline. That is the work we do.