AI coding governance: how teams use AI in development in a controlled way

Most organisations face the same uncomfortable choice about AI in development: a ban that cannot actually be enforced, or a laissez-faire approach in which nobody can say any more which tools touch which data. Neither is a decision; both postpone one.

1. Ban or free-for-all – both are costly

A ban fails on availability: AI features sit inside editors, terminals, browsers and ticket systems. What remains is unrecorded use – privately installed, privately paid for, without a data protection review and without a trace in the process. That is the worst of all options, because it keeps the risk and gives up the control.

The unregulated opposite is no better. Without guidance, each team builds its own tool chain, its own data flows and its own idea of what has to be checked. At the latest with the first client question – “was AI used in our project, and how do you assure quality?” – there is no solid answer.

2. What governance means in this context

Governance sounds like committees and forms, but here it is simply a set of decisions taken once and then enforced. The scope is modest: in many organisations the policy fits on two pages if it sticks to the essentials.

Three properties separate a policy from paper:

• Decidable. Every rule answers a question that comes up in daily work – not one that could theoretically arise.
• Checkable. It can be established whether it was followed.
• Enforced. Technically wherever possible, not by appeal.

3. The four fields to regulate

In practice, AI coding governance comes down to four fields. Everything else follows from them:

1. Tools and operating model. Which tools are approved, and in which form of operation – public service, dedicated environment, self-hosted? A short allow-list is more effective than a long list of criteria.
2. Data. Which content may go into which tool? That is the core question, resolved in section 4.
3. Review duties. What has to happen before generated code goes to production? Ideally exactly the same as for hand-written code – plus the points that come up more often with generated code.
4. Documentation and responsibility. What is recorded, and who is responsible for the result? The answer to the second question is always a person, never a tool.

4. Data classes as the anchor

The most common design error is one rule per tool. Tools change faster than policies. The reverse anchoring is more stable: rules per data class, with tools assigned to those classes.

The table is a pattern, not a prescription. Which classes and assurances apply to your organisation depends on contracts, sector and data protection assessment.

The practical benefit: a new tool does not have to be debated from scratch. It is assessed, assigned to a class – done. And developers get a rule they can remember.

5. Technical enforcement: what is in the pipeline is what counts

The most effective part of an AI policy is not in the policy. It is in the pipeline and in the repository settings:

• Quality gates as a merge precondition: build, tests, contract tests, lint, SAST, dependency and secret scanning. Details in the pillar article AI in software development.
• Dependency policy: only packages from curated sources, automated licence checks, new dependencies visible in review.
• Mandatory review by a second person, driven by ownership rules on the directory tree.
• Limited agent permissions where tools access systems – see MCP and permission boundaries.
• No production credentials in development environments where agents run.

These measures are remarkably unspectacular: almost all of them belong to a solid development process anyway. AI does not make them new, only indispensable.

6. Labelling and responsibility

Whether substantial AI use is labelled is a deliberate decision. For regulated and client-facing projects there is a lot in favour – not as a vote of no confidence, but because it lets the depth of review be assessed later. A lightweight form is enough:

# Pull request template (excerpt)

## Requirement
Requirement: REQ-____

## AI assistance
- [ ] No AI assistance
- [ ] AI-assisted (single files / small changes)
- [ ] Substantially AI-generated (reviewed and adjusted manually)

## Verification
- [ ] Tests derived from the requirement, not from the implementation
- [ ] Error and permission paths covered
- [ ] New dependencies reviewed

What matters is the separation behind it: the tool produces a suggestion, the person adopts it. Whoever submits a change set is fully responsible for it – regardless of how much of it they typed. That sentence belongs in the policy, because it ends any discussion about “the model's fault”.

7. Provenance and licences

The legal treatment of generated code differs by jurisdiction and contract and continues to evolve. Independently of that, three practical precautions help in any constellation:

• Automate licence scanning for dependencies and maintain an allow-list of permitted licences.
• Question conspicuously long, unusually specific blocks of code in review instead of adopting them unchecked.
• Document the vendors' contractual assurances – what happens to inputs, whether they are used for training, which indemnities are promised.

For client projects, a clear position in the proposal is also advisable: whether AI is used, in what form and with which checks. That avoids the more awkward variant of settling the question mid-project.

8. Who decides what

• Management / CTO: approves the policy and decides on permitted operating models.
• Security / data protection: assesses tools and assigns them to data classes.
• Engineering: implements the review duties technically and maintains the gates.
• Project or team lead: decides on use in the specific project within the policy – and obtains client consent where needed.
• Every person submitting: is responsible for the change set they submit.

Organisations with a management system can dock this onto it instead of building a parallel structure: ISO 9001 for the process side, ISO/IEC 27001 for information security, ISO/IEC 42001 as a management system for AI. These standards certify organisations and processes – not a tool and not the resulting software product.

9. What to keep an eye on

Productivity figures are notoriously unreliable in this field, and bought-in metrics do not help. What is meaningful are the measures you already collect – compared before and after within your own organisation:

• Change volume per review – as it grows, real review depth falls.
• Lead time of review and merge – shows whether the bottleneck has moved.
• Gate failures by category – where do defects really arise?
• Defects after release, relative to the size of the change.
• Rework share: how much of the generated code was substantially changed in review?

These measures belong in internal analysis and should not be communicated externally while they are not solid. Invented percentages are a risk in a proposal, not an argument.

10. A rollout in three stages

Common mistakes

• A blanket ban – produces unrecorded use.
• Rules per tool instead of per data class; outdated within months.
• A policy without technical enforcement – ineffective under deadline pressure.
• A special process for AI code that weakens the regular checks instead of using them.
• Productivity promises to the outside world before your own figures exist.
• Settling client consent mid-project instead of in the proposal.

Checklist: AI coding governance

Conclusion

Good AI coding governance is unspectacular. It consists of a short policy, a handful of data classes, the quality gates that make sense anyway, and a clear allocation of responsibility. What makes it effective is not its size but that it takes hold where the work actually happens – in the repository, in the pipeline, in review.

The side effect is the real gain: a team with clear rules can use AI far more assertively than one that debates every individual case. Control here is not a brake but the precondition for allowing speed at all.