AI policy
How to write an AI coding assistant policy for your team
Engineers are already using AI assistants, whether or not a policy exists. A short, clear policy tells them what is allowed, protects code and data, and makes review expectations explicit. This guide gives you an outline you can adapt, section by section.
Not legal advice. Licensing, privacy, security and export-control obligations depend on your contracts, products and jurisdiction. Involve your security, legal and compliance functions before publishing a policy.
Why a clear stance matters
DORA's 2025 AI Capabilities Model, published by Google Cloud's DORA research program, lists a "clear and communicated AI stance" as one of seven capabilities that shape whether AI adoption helps teams. The others are healthy data ecosystems, AI-accessible internal data, strong version control practices, working in small batches, a user-centric focus, and quality internal platforms. The practical lesson for a lead: ambiguity is not neutral. When engineers guess what is allowed, some avoid useful tools and others paste in things they should not.
Who writes it and who owns it
- Owner: one named person or role, usually an engineering leader, responsible for keeping it current.
- Contributors: security, legal, privacy, and, where relevant, export compliance and quality.
- Reviewers: a few engineers who use the tools daily. A policy nobody can follow gets ignored.
- Review cycle: tools change quickly. Set a regular review date, for example each quarter, and review sooner when a new tool or capability is requested.
The policy outline
- Purpose and scope. Who it applies to (employees, contractors, consultants), and which tools: editor assistants, chat assistants, command-line tools, code review bots and autonomous agents.
- Approved tools. A list of approved tools, the account or contract type that must be used, and how to request a new one. Personal accounts on consumer plans are often excluded because their data terms differ.
- Data rules. What each tool may see, by data class (see the table below).
- Permitted and prohibited uses. For example: permitted for drafting code, tests and documentation; prohibited for generating security-sensitive code without additional review.
- Ownership and review. The engineer who submits a change owns it. AI-assisted changes go through the same review as any other, with the additions in reviewing AI-generated code.
- Disclosure. Whether and how AI assistance is noted: a pull request template checkbox, a commit trailer, or nothing. Choose what your review and audit needs actually require.
- Agents and automation. What agents may do without a person approving it. See AI agents in the software lifecycle.
- Licensing and provenance. How the team checks that generated code and suggested dependencies do not create license or supply-chain problems.
- Security. Keeping secrets out of prompts, checking suggested packages exist and are trustworthy, and running the same scanning on AI-assisted code as on any other.
- Records and retention. What is logged, for how long, and who can see it.
- Training. What people must complete before they get access.
- Exceptions and reporting. How to request an exception, and how to report a mistake, such as sensitive data pasted into the wrong tool, without fear of blame.
A data classification table to adapt
| Data class | Approved enterprise assistant | Other tools |
|---|---|---|
| Public code and documentation | Allowed | Allowed |
| Internal source code | Allowed | Not allowed |
| Customer or personal data | Not allowed unless approved for that data | Not allowed |
| Secrets, keys, credentials | Never | Never |
| Export-controlled technical data | Only a deployment approved by export compliance | Never |
| Unreleased business information | Case by case | Not allowed |
The entries above are an example, not a recommendation for your organization. Fill the table in with your security and compliance teams, based on each tool's actual contract and data handling. Teams in aerospace, defense and other regulated work should read AI in regulated engineering first.
Sample clauses
Ownership. "The engineer who opens a pull request is responsible for every line in it, however it was produced, and must be able to explain what it does and how it can fail."
Data. "Do not enter secrets, credentials, customer data or controlled technical data into any AI tool unless that specific tool and deployment is listed as approved for that data class."
Dependencies. "Before adding a dependency suggested by an AI tool, confirm the package exists in the expected registry, is maintained, and is under an approved license."
Agents. "Agents may open pull requests and run tests in approved environments. They may not merge, deploy, change infrastructure or access production data without a named person approving the action."
Reporting. "If you think data was shared with a tool in breach of this policy, report it to security the same day. Early reports are treated as a learning event."
Rolling it out
- Start with what people already do. Ask engineers which tools they use and for what. Write the policy around real usage.
- Publish it where engineers work, linked from the repository, the onboarding guide and the pull request template.
- Train before access. A short session with examples of what not to paste.
- Enforce with tooling where possible: single sign-on for approved tools, secret scanning, dependency checks.
- Measure the effect with team-level delivery and quality measures, not acceptance rates. See DORA, SPACE and DX Core 4.
Common questions
Should we ban AI coding assistants?
A ban is a policy too, and it needs enforcement. Where engineers find the tools useful, a ban tends to push use onto unapproved personal accounts, which is harder to control. Many teams find an approved tool with clear data rules easier to manage.
Do we need to label AI-generated code?
Only if you will use the label. Regulated teams may need it for traceability. Other teams may find that a pull request description explaining the approach is more useful than a per-line label.
How long should the policy be?
Short enough to read in a few minutes. Put the rules engineers must remember on the first page and keep detail in linked sections.
Who approves new tools?
Name one route, usually a combined security and engineering review, and publish how long it takes. A slow or unclear route encourages workarounds.
Last reviewed 2026-09-17