Writing an AI coding assistant policy for a large engineering organisation

Why a policy before rollout?

Assistants spread faster than a security review. By the time someone asks for a policy, three teams may already be on three products, one of them on personal accounts. Writing the rules first gives the pilot something to bump into, so the snags show up while you can still change the text.

The policy is one control in an AI-enabled SDLC. An AI-enabled SDLC is a software delivery process where the use of AI assistants and agents is governed by policy, checked by quality gates and recorded for audit. The other four controls in the Comonad AI SDLC control model are approval, gates, records and rollout. The long version is How to set up an AI-enabled SDLC in a large organisation.

Keep this document separate from the organisation's AI policy if you have one, and point them at each other. The AI policy says how the organisation uses AI. This one says how engineers use coding assistants on company code. A single document that tries to cover both tends to be too vague for a pull request and too detailed for the board.

The ten clauses

Ten clauses cover the decisions a large engineering organisation actually argues about. The example wording is a starting point. Edit it. Do not publish it as if it were already yours.

Data and code exposure

Source code is the data. So are tickets, design notes and logs if people paste them in. Decide repository by repository, not with a slogan about confidential code. A prototype with no customer data is a different decision from a service that handles personal data or market operations.

If a prompt contains personal data, that is processing under UK GDPR. The ICO's guidance on AI and data protection (opens in new tab) covers lawful basis, minimisation and security. The practical rule in the policy can stay short: personal data does not go into prompts. The lawful-basis analysis, where you need one, sits with your privacy team.

Say what the provider keeps. Retention, training on customer content, and subprocessors are terms you read in the contract, not facts you can assume from the product name. When the terms change, the approval is reviewed.

Approval and procurement checks

A new assistant is requested by engineering and approved by security and procurement. The approval record names the product, the account type, the repositories it may see, where prompts are processed, what the provider retains, and the licence position your counsel has been asked about.

That record is the Approval control in the Comonad AI SDLC control model. Without it, the allow-list is a wiki page nobody updates. The same check applies when a team wants to move from a suggestion tool to an agent that can edit files on its own.

Review and gate rules

State the gates in the policy, and point at where they run. A person accepts the specification before generation. Review is independent of the model that wrote the change. Tests and the static and dependency checks already in CI still run. Release does not grow a special path for generated code.

The gate table, and what evidence each gate leaves, is in How to set up an AI-enabled SDLC in a large organisation. The policy does not need to repeat the pipeline diagram. It needs to say that skipping a gate is an exception, not a habit.

Records

Say where the mark lives. A label on the pull request is better than a spreadsheet, because the people doing incident review already open the pull request. Record the assistant, the person who accepted the change, and, if you know it, the model. Record when an agent opened the request.

Keep the records for as long as you keep other change records. Do not invent a shorter retention for AI-assisted work. If you cannot explain a change, the fact that a model wrote it will not help.

Exceptions

Someone will need one. A contractor on a fixed tool. A repository that cannot leave a network. An evaluation of a product that is not on the list yet. Name the person who can grant the exception, how long it lasts, and where it is written down. An exception with no expiry becomes the new policy.

The owner should not be the only person who benefits from the exception. Security sees the list. Engineering leadership sees how often the same clause is being waived, which is usually a sign the clause is wrong.

Agents versus assistants

An assistant that suggests a line is a different risk from an agent that reads the repository, runs commands and opens a pull request. More autonomy needs tighter permissions: which repositories, which commands, whether it may push, who may merge, and how you stop it without a deploy.

Those limits belong in the policy, and the enforcement belongs in the harness, where the model cannot edit them. The six-layer framework for governing AI agents is the control set for that runtime: identity, delegated authority, a policy check on each tool call, an audit trail and a way to suspend the agent. How to govern AI agents in production covers the operating side. Do not paste either document into the coding policy. Point at them, and say that an agent is approved on its own line.

Template outline

Copy this outline into the document you already use for engineering standards. Fill the names in. There is no email gate.

1. Purpose, scope, and the date of this version.
2. Owner, and the security and legal reviewers.
3. Approved assistants, with account type and the repositories each may see.
4. Data that must not be sent: secrets, production data, personal data.
5. Review and gate rules, including independent review.
6. What is recorded on an AI-assisted change, and where.
7. Licence and ownership: what is recorded for counsel, and that counsel decides.
8. Exceptions: who grants them, how long they last, where they are listed.
9. Agents that open pull requests: separate approval, permissions, and the switch-off.
10. How often the policy is reviewed, and what triggers a review early (a new assistant, a change of vendor terms, an incident).

How Comonad helps