AI Governance Policy
for Engineering Teams
The document you write before anyone opens an AI tool. Copy the template, map it to your directory structure, and you have working rules by the end of the afternoon.
Quick Take
A policy that says "use AI responsibly" changes nothing. What works is a written classification of your own files: which ones an AI may draft, which ones it may scaffold under review, and which ones it never touches. Three tiers, mapped to real directories, checked in next to the code. Everything else in this guide is detail around that one decision.
Why the Rules Come First
Teams usually get this backwards. The tool arrives, developers start using it, and the policy gets written six months later after something goes wrong in review. By then you are negotiating with habits instead of setting them.
Writing the rules first also costs almost nothing. An hour of argument between your senior engineers about which files are off limits will tell you more about your codebase risk than a fortnight of pilot data.
Classify Every File as GREEN, AMBER or RED
The classification is the policy. Everything else is procedure.
The dividing line is consequence, not complexity. If a defect in a file could cost money, expose data, or take the system down, that file is RED. A clever regex parser is fine for AI to draft. A twelve-line function that decides whether a refund is authorised is not.
Copy-Paste: AI Governance Policy
Create docs/AI_GOVERNANCE.md in your repository. This is the template we use with clients, written against the TaskFlow sample project.
# TaskFlow AI Governance Policy
# Version: 1.0
# Last reviewed: <date>
# Owner: Engineering Lead
## 1. Tool Allowlist
Only the following AI coding tools are approved for use on the TaskFlow codebase:
| Tool | Use Case | Approved By | Date |
|------|----------|-------------|------|
| GitHub Copilot | Autocomplete, inline suggestions | CTO | 2026-05-16 |
| GitHub Copilot Chat | Explaining error messages, generating docstrings | CTO | 2026-05-16 |
Unapproved tools include, but are not limited to: ChatGPT web interface for code generation, Claude web interface for production code, Cursor (pending data governance review).
## 2. File Classification
Every file in the repository is classified by risk level. AI assistance rules differ by level.
### GREEN - AI-assisted generation allowed
Directories:
- `tests/` (unit tests for existing code)
- `app/schemas/` (Pydantic request/response schemas)
- `docs/` (README, API documentation)
- Migration stubs in `alembic/versions/` (boilerplate only)
Rules:
- Developer must review every generated line before commit.
- Generated code must pass existing linting and type checking.
- Pull request description must flag which files contain AI-generated code.
### AMBER - AI-assisted with mandatory human review
Directories:
- `app/handlers/` (HTTP route handlers)
- `app/repositories/` (database access layers)
Rules:
- AI may generate scaffolding, but business logic branches (if/else, loops, calculations) must be written by a human.
- Every AI-generated block must be marked with a comment: `# AI-generated - reviewed by <name> on <date>`.
- Requires approval from a senior engineer (not the author) before merge.
### RED - Human-only authoring
Files and directories:
- `app/config.py` (environment variable handling, secrets)
- `app/dependencies.py` (authentication, authorization)
- `app/services/task_service.py` (core business logic)
- `docker-compose.yml` (infrastructure, database credentials)
- Any file containing:
- Authentication or authorization logic
- Cryptographic operations
- Payment processing or financial calculations
- PII handling or data export logic
- Environment variable parsing or secret management
Rules:
- No AI-generated code in RED files.
- No exceptions without written sign-off from the CTO.
- RED files marked with a header comment: `# HUMAN-ONLY - see AI_GOVERNANCE.md`.
## 3. Data Sovereignty
Proprietary code and business logic must not leave the company's network.
- Cloud AI tools (GitHub Copilot) may only be used on GREEN files.
- AMBER and RED files must be edited with local-only tooling or with cloud AI features disabled.
- Developers must confirm in their pull request that no RED files were processed by cloud AI.
- Violation: first offence = warning. Second offence = tool access revoked.
## 4. Pull Request Requirements
Every PR containing AI-generated code must include:
1. **AI Usage Summary** - list every file with AI-generated code and the tool used.
2. **Verification Checklist** - the author ticks:
- [ ] I reviewed every line of AI-generated code for correctness.
- [ ] I ran the full test suite and all tests pass.
- [ ] I confirmed no RED files were sent to cloud AI.
- [ ] I added `# AI-generated` comments where required.
3. **Review Standard** - AI-generated code gets the same scrutiny as code from a junior developer on their first day.
## 5. Review Escalation
A senior engineer may block any PR that:
- Contains AI-generated business logic in AMBER files without clear justification.
- Modifies RED files without the `HUMAN-ONLY` header intact.
- Fails to answer "why this approach is correct" when asked in review.
No blame, no delay - just a request to rewrite the flagged section manually.
## 6. Incident Response
If AI-generated code causes a production incident:
1. Revert the change immediately (do not debug in production).
2. Root cause: was the tool, the prompt, or the review at fault?
3. Update this policy if the gap is structural.
4. Communicate learnings to the team within 24 hours.Adapting It to Your Codebase
Replace the project name. Map your own directories to the three tiers. Keep the version number and review date, because you will change this document within a month of switching a tool on and you want to know which version people agreed to.
One warning about the tool allowlist: name the tool and the surface, not just the vendor. "Copilot" covers inline completion, chat, and agent modes that behave nothing alike. A policy that approves the first and silently permits the third is not a policy.
Where Policies Fall Over
Four failures we see repeatedly, in rough order of how expensive they are to unpick.
The policy lives in Confluence
If the rules are not in the repository, they are not in the review. Engineers check the file classification when it sits two directories away from the code they are editing, and never when it sits behind a wiki search.
Nobody defined what "reviewed" means
Ticking a box that says "I reviewed the AI output" is worthless if the reviewer only checked that the tests pass. State the standard: the author must be able to explain why the code is correct, and a second engineer must be able to follow the explanation.
The classification never changed
A policy written before your first pilot is a guess. After sixty days you will know that one AMBER directory should have been RED and that two RED files were only there out of nervousness. Version it, revisit it quarterly, and record why each tier changed.
Data rules assume one tool
Most incidents we have looked at involved a developer using a personal account on an unapproved tool because the approved one was slow that day. Write the rule about where code may be sent, not about which brand is installed.
What the Rules Actually Require
Worth separating the compliance you have from the compliance you imagine.
For most teams, using an AI assistant inside your own IDE is not the regulated activity. What you ship is. The EU AI Act is structured around the AI systems you place on the market or put into service, with transparency duties for systems that interact with people or generate content, and a separate, heavier regime for high-risk uses. Those transparency obligations apply from 2 August 2026. The high-risk obligations for the Annex III use cases now apply from 2 December 2027, with product-embedded high-risk AI following in August 2028.1 If your product has a chatbot or generates content for users, that is the part of your roadmap to check, not your autocomplete.
In the UK there is no equivalent statute. Existing regulators apply existing law, which in practice means the ICO if personal data is involved anywhere in your pipeline.2 The relevant question for a coding policy is narrow but real: does any customer data end up in a prompt, and can you show what happened to it.
Two frameworks are worth knowing by name because buyers and investors now ask about them. ISO/IEC 42001 is the AI management system standard, and certification against it is voluntary.3 The NIST AI Risk Management Framework is also voluntary and is the common reference point in US deals.4 Neither is aimed at your coding assistant. Both are increasingly cited in due diligence questionnaires, so a governance document with version history is a cheap thing to be able to hand over.
For the security side of the argument, the NCSC guidelines for secure AI system development are the clearest free reference, organised across design, development, deployment, and operation.5
Sources
- European Commission - Regulatory framework for AI, and the full text of Regulation (EU) 2024/1689 on EUR-Lex.Application dates checked 28 July 2026. The staged timeline has been amended since the Act entered into force, so verify before relying on any date.
- Information Commissioner's Office - Guidance on AI and data protection.
- ISO - ISO/IEC 42001:2023, AI management systems.
- NIST - AI Risk Management Framework (AI RMF 1.0).
- National Cyber Security Centre - Guidelines for secure AI system development.
Want the Policy Written for Your Codebase?
We spend two days mapping your repository, classify every module, and hand back a policy your senior engineers have already argued over and agreed to.