AI code governance is an engineering system, not a policy document: written rules, named owners and automated checks that decide how code written with AI tools reaches production. The rules apply whether the code comes from an AI coding assistant in the editor, an AI app builder or a coding agent that opens pull requests on its own. The CTO owns that system, even when tool budgets and sign-off sit with the business.
In the Stack Overflow Developer Survey 2025, 84% of developers said they use or plan to use AI tools, and about 31% already use AI agents at work. This guide covers the components and policy decisions, the controls AI adds at each delivery gate and for coding agents, ownership by team size, the EU requirements that matter and a 30-day rollout. For the full route from AI-built prototype to live product, see our guide to AI-generated code in production.
TL;DR
AI code governance is the set of written rules, named owners and automated checks that control how code written with AI tools enters a product and is maintained there. AI code governance sits above code review and DevSecOps: it decides which tools, data, approvals and evidence apply to AI-written changes.
- AI code governance has five components, starting with the AI coding policy: the AI coding policy, automated controls, human review, provenance and monitoring with evidence; the AI coding policy makes six decisions on tools, prompt data, merge rights, review depth, dependencies and traceability.
- AI adds controls at six delivery gates and for every coding agent: editor, commit, pull request, CI, release and production, plus a separate identity, least privilege and a human approver for each agent.
- The CTO is accountable for AI code governance at every team size: a solo founder needs three rules, a team of 2–5 developers needs the six decisions on one page, and teams running coding agents need all five components.
- EU requirements set obligations, not a template: EU AI Act Article 4, GDPR Article 28 and NIS2 Article 20 apply depending on scope, while ISO/IEC 27001 is a voluntary standard customers can require by contract.
What is AI code governance?
AI code governance is the set of written rules, named owners and automated checks that control how code written with AI tools enters a product and is maintained there. The scope covers code, tests, configuration and infrastructure-as-code, prompts and the data in them, and coding agents that open changes on their own.
Google’s DORA research treats a written position on AI use as an engineering capability: “clear and communicated AI stance” is the first of seven capabilities in the DORA AI Capabilities Model, published on 10 December 2025, next to strong version control and working in small batches.
| Term | What it governs | Typical owner |
|---|---|---|
| AI code governance | How AI-written code enters the product, who approves it, what evidence is kept | CTO (accountable), management (policy sign-off) |
| AI governance | Which AI systems the company builds, buys or uses, and their business risks | Management team with legal or compliance |
| DevSecOps | Security built into every stage of the delivery pipeline, for all code | Engineering and platform teams |
| Code review | Whether one change is correct and safe — one control inside AI code governance | Developers and reviewers |
| EU AI Act compliance | Obligations for AI systems placed on the market or used, by risk category | Legal or compliance owner |
AI code governance is one part of a company’s wider AI governance. AI governance sets company-wide rules for every AI system the company builds, buys or uses; AI code governance applies them to AI tools that write the company’s own software and adds the engineering controls that use needs. On the engineering side, it is a layer on top of DevSecOps, not a replacement.
Why does AI-written code need its own rules?
AI-written code needs its own rules because AI tools change four assumptions a classic review process relied on: code volume, authorship, data flow and dependencies. In the Stack Overflow Developer Survey 2025, 46% of respondents said they distrust the accuracy of AI tools, against 33% who trust it, and 66% named “AI solutions that are almost right, but not quite” as their biggest frustration.
Volume. One developer with an AI assistant produces more diff per day than one reviewer can read with care. Without a rule on review depth by risk, review quality drops exactly where the code changes fastest.
Authorship. Six months later, nobody can tell which lines came from a prompt unless AI-assisted changes were marked at merge time.
Data flow. Where prompt data goes depends on the type of tool. A cloud AI assistant sends prompts and code context to the vendor’s servers, and the vendor’s plan and contract decide retention, storage region and whether the data may train its models. Business plans can add a data processing agreement and a training opt-out — check the terms, not the plan name. A local or self-hosted model keeps prompts in-house but still needs rules for logs, access and the model licence. Our guide to leaked API keys shows how keys end up in AI-built products and how to remove them.
Dependencies. AI tools suggest open-source packages nobody chose on purpose, and sometimes packages that do not exist. Without an approval step, the product collects licences and maintenance risk by accident.
What are the components of AI code governance?
AI code governance has five components: a written AI coding policy, automated controls that enforce it, human review where judgement is needed, provenance of AI-assisted changes, and monitoring that produces evidence. The components map onto the four practice groups of the NIST Secure Software Development Framework (SSDF), SP 800-218 version 1.1 — Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV) — so an existing SSDF or ISO-aligned process can absorb them.
| Component | What it does | Example control | SSDF group | Owner |
|---|---|---|---|---|
| 1. AI coding policy | States what is allowed and who decides | One page with the six decisions in the next section | PO | CTO drafts; management signs off |
| 2. Automated controls | Enforces the policy without relying on memory | Required approvers, secret scanning, dependency and licence checks | PW · PS | Platform or tech lead |
| 3. Human review | Judges what tools cannot: business rules, data boundaries, design | Second reviewer on payment, login and personal-data code | PW | Developers + independent reviewer |
| 4. Provenance | Records which changes AI tools or agents produced | AI-assistance line in every pull request; agent commits under their own identity | PS | Each developer; platform for agents |
| 5. Monitoring and evidence | Shows over time that the controls work | Monthly metrics, review records, merge history | RV · PO | CTO reports; management reviews |
Build the components in that order. Buying a governance tool before writing the policy means enforcing rules nobody agreed on.
Six decisions an AI coding policy must make
The AI coding policy — the first of the five components — must make six decisions: which tools are approved, which data may go into prompts, who may merge changes, how deep review goes by risk, how new dependencies are approved, and how AI-assisted changes are recorded. Six one-sentence rules fit on one page that a 10-developer team can follow from the next working day.
| Decision | What to decide | Example rule for a 10-developer team |
|---|---|---|
| 1. Approved tools | Which tools, where they process data, on which terms | “Only listed tools: cloud tools with a data processing agreement and training switched off; self-hosted models on company infrastructure only.” |
| 2. Data in prompts | Which data never goes into a prompt | “No personal data, production logs, keys or passwords in cloud tools; no client code without written permission.” |
| 3. Merge rights | Who approves production changes | “One human approver who did not write the change; agents never approve their own work.” |
| 4. Review depth by risk | Which code gets extra review | “Payments, authentication, permissions and personal data get a second reviewer.” |
| 5. Dependencies and licences | How new packages get in | “New packages need tech-lead approval, an existence check and a licence check.” |
| 6. Traceability | How AI-assisted changes are marked | “The pull request names the AI tool or agent used and for which part.” |
Decision 2 has a legal edge. When a cloud AI tool provider processes personal data on your behalf, GDPR Article 28 requires a contract with that processor; pasting customer data into a tool without such terms creates a processing relationship nobody signed.
Decisions 3 and 4 set two levels of human review. Baseline review applies to every change: one human approver who did not write it. Additional review applies only to high-risk code: a second reviewer for payments, authentication, permissions and personal data. How to review AI-generated code layer by layer, and what evidence a pull request needs before merge, is covered in our guide to AI code review.
None of the six rules bans AI tools; each one tells developers where AI use is safe. We’d recommend publishing all six before the first coding agent gets write access, because rules added after habits form are harder to enforce.
Which controls does AI-written code need at each delivery gate?
AI-written code needs one extra control at each of six delivery gates — editor, commit, pull request, CI, release and production — on top of the security checks an existing DevSecOps pipeline already runs. The base pipeline stays as it is; Table 4 lists only what AI changes.
| Gate | Add when AI writes the code | Why |
|---|---|---|
| Editor | Approved tool settings; a project rules file that gives the assistant the team’s conventions and forbidden patterns | AI output follows the codebase instead of generic examples |
| Commit | Secret scanning on AI-suggested configuration and example code | Assistants copy placeholder keys and real keys from context |
| Pull request | AI-assistance line; required human approver who is neither the author nor an agent | Provenance and separation of duties on every change |
| CI | Existence and licence check for newly added packages; tests for the change not written by the same AI session | Catches invented packages and tests that only confirm the code |
| Release | Change record that flags AI-assisted changes in high-risk areas | Release approver sees where review depth matters |
| Production | Change fail rate tracked separately for AI-heavy services | Shows whether the controls hold after release |
Google’s DORA AI Capabilities Model (10 December 2025) lists strong version control practices and working in small batches among its seven capabilities; both make gate controls cheap to run. Automate every rule a machine can test objectively — package existence, licence lists, required approvers — and keep human review for rules that need product context, such as whether customer A can see customer B’s data.
Before you scale AI tools and agents, know what is already in the codebase.
Controls govern the next change; they say nothing about the code AI tools have already written. An AI-built product review gives you that baseline: a reviewer who did not write the code checks it across code, product behaviour and technical set-up, and returns findings in plain English with a prioritised action plan — so you know which controls to switch on first.
How do you govern AI coding agents?
Govern AI coding agents as non-human contributors: each agent gets its own identity, the least privilege it needs, a limited scope and a human approver for every change. In the Stack Overflow Developer Survey 2025, 81% of respondents said they have concerns about the security and privacy of data when using AI agents, and 87% were concerned about the accuracy of agent output.
| Control | Rule |
|---|---|
| Identity | Each agent runs under its own service account, never a developer’s personal token. |
| Permissions | Least privilege on repositories and environments; no admin or bypass rights (ISO/IEC 27001:2022 Annex A 8.2, privileged access rights). |
| Scope | Allowed repositories and directories are listed; payment, authentication and permission code only with a human pairing. |
| Approval | An agent never approves or merges its own pull request; a named human approves. |
| Execution | Agents run in a sandbox without production secrets or production data. |
| Volume | A cap on open pull requests per agent keeps review queues within reviewer capacity. |
| Audit | Every agent action — branch, commit, tool call — is logged and kept with the merge history. |
Start agents on low-risk work such as test scaffolding, documentation and dependency updates. Widen their scope when agent pull requests show a change fail rate no higher than the team’s own over a review period you fix in advance. We’d recommend two monthly metric reviews as a starting point, because one month rarely holds enough agent changes to separate trend from noise; adjust the period to your release frequency. A failed agent change in payment, authentication or personal-data code is an incident, not a trend: roll it back and pause the agent in that area straight away.
Who owns AI code governance?
The CTO is accountable for AI code governance: management signs off the AI coding policy, team leads run the controls, a security lead advises where the company has one, each developer answers for their own changes, and an independent reviewer gives the verdict before major releases. The split follows segregation of duties in ISO/IEC 27001:2022 Annex A 5.3: whoever makes a change is not the only one who approves it.
| Activity | COO / founder | CTO | Security lead | Team leads | Developers | Indep. reviewer |
|---|---|---|---|---|---|---|
| Approve the AI coding policy | A | R | C | C | I | C |
| Keep the approved-tool list | C | A | C | R | I | – |
| Configure gate and agent controls | I | A | C | R | I | – |
| Approve changes to production code | – | I | – | A | R | – |
| Follow the data-in-prompt rule | I | A | C | C | R | – |
| Review before a major release | I | A | C | R | C | R |
| Answer customer security questionnaires | C | A | R | C | – | C |
When one person is founder, CTO and only developer, the independent reviewer is the only separation of duties available — schedule that review before the first paying customers, not after the first incident.
How much AI code governance does your team need?
The right amount of AI code governance follows three triggers: team size, customer type and data type. Move up a row in Table 7 when any one changes — a second developer, an enterprise customer, personal or payment data, or the first coding agent. In the Stack Overflow Developer Survey 2025, 13.8% of respondents used AI only in copilot or autocomplete mode, while 14.1% used AI agents daily.
| Stage | Typical set-up | Minimum governance | Move up when |
|---|---|---|---|
| Solo founder | One person, AI app builder or assistant | Approved tool, data-in-prompt rule, independent review before launch | First paying customers or personal data |
| 2–5 developers | Daily AI assistant use | Six decisions on one page, required approver, secret scanning | Enterprise customer or external team |
| 6–50 developers or an external team | Several teams or suppliers on one product | All five components, gate controls, ownership table, monthly metrics | First coding agent gets write access |
| Coding agents in production use | Agents open pull requests themselves | Agent controls from Table 5 on top of all five components | — |
Vibe coding governance for a solo founder
Vibe coding governance is the minimum rule set for a founder who builds with an AI app builder and does not read the code. Three rules cover it: a tool whose data terms you have checked, no customer data or keys in prompts, and an independent review before real users arrive — the only check that does not rely on the founder’s own judgement.
Common AI code governance challenges and how to solve them
Five challenges come up in most engineering teams that introduce AI code governance: shadow AI, developer friction, missing provenance, missing context in AI output, and agents that outpace review. Missing context is the most underestimated: in the Stack Overflow Developer Survey 2025, 45% of developers said debugging AI-generated code is more time-consuming.
| Challenge | Sign | Fix |
|---|---|---|
| Shadow AI | Tools in use that are not on the approved list; personal accounts on company code | Approve a tool developers want to use, on checked terms; a ban only moves use out of sight |
| Developer friction | Review queues grow; developers bypass checks to ship | Automate objective checks so the baseline reviewer can focus on logic; add the second, additional review only for high-risk code (decision 4) |
| Missing provenance | Nobody can say how a defect entered the code | AI-assistance line enforced by the pull request template; agents under their own identity |
| Missing context | AI code passes tests but breaks a business rule or an architecture boundary | Project rules file for the assistant; a reviewer who knows the domain checks business logic |
| Agents outpace review | Agent pull requests wait for days or are merged unread | Cap open pull requests per agent; limit agents to low-risk scope |
If two or more signs in Table 8 apply at once, fix shadow AI first: governance cannot cover tools the company does not know about.
Which EU requirements and security standards matter?
No EU law regulates AI-written code as such. Three EU laws and one voluntary standard are relevant to AI code governance, and whether each applies depends on your company’s role, sector and data, not on how the code was written. The laws set obligations but prescribe no evidence format; Table 9 keeps the requirement apart from the governance evidence companies often choose to keep.
| Requirement | Type | When it applies | What it requires | Governance evidence companies often keep |
|---|---|---|---|---|
| EU AI Act Article 4 (AI literacy) | EU regulation | Since 2 February 2025, for providers and deployers of AI systems; a company using AI tools at work is generally a deployer. Amended by the Digital Omnibus on AI in 2026 | Take measures to support the AI literacy of staff who use AI systems; no guaranteed competence level and no prescribed format | Record of training or instruction for AI-tool users; the AI coding policy |
| GDPR Article 28 | EU regulation | When an AI tool provider processes personal data on your behalf | A contract with the processor that sets the processing terms | Approved-tool list with data processing agreements; data-in-prompt rule |
| NIS2 Article 20 and Article 21(2)(d)–(e) | EU directive; in the Netherlands the Cyberbeveiligingswet | Essential and important entities in the sectors of NIS2 Annexes I and II, generally medium-sized and larger; suppliers outside scope meet it through customer contracts | Management approves and oversees cybersecurity risk measures; supply-chain security; security in development and maintenance | Management-approved AI coding policy; ownership table |
| ISO/IEC 27001:2022 | Voluntary standard — not a law | When your company is certified, or a customer contract requires it | An information security management system with Annex A controls selected by risk assessment | Policy and review records as input to the ISMS |
In the Netherlands, NIS2 applies through the Cyberbeveiligingswet, in force since 15 August 2026 (Staatsblad 2026, 187 and 189). Companies outside its scope still meet NIS2 through their customers, because in-scope customers must address supply-chain security under NIS2 Article 21(2)(d) and pass the questions on to their software suppliers.
Which ISO/IEC 27001 Annex A controls and OWASP standards apply to AI-written code, how GDPR Article 32 fits in, and which security evidence to show an auditor are covered in our guide to AI-generated code security. Sunbytes runs its own delivery under an ISO 27001-certified information security management system. Check scope with your legal adviser: Table 9 summarises requirements, it does not decide whether each one applies to your company.
Five metrics that show AI code governance is working
Five metrics show whether AI code governance works, and each comes from data the code host, the scanners or the last review report already produce.
- Independent-approval rate: the share of production changes approved by someone other than the author or an agent (baseline review), and the share of high-risk changes that also had a second reviewer (additional review). Target: 100% for both.
- Secrets reaching the main branch: keys or passwords found by scanning after merge. Target: zero per month.
- Tool gap: AI tools and agents in use compared with the approved list. Target: no gap.
- Change fail rate: one of the five metrics in DORA’s software delivery performance metrics, defined as “the ratio of deployments that require immediate intervention following a deployment”. Target: AI-heavy services no worse than the rest.
- Open review findings: high-priority findings from the last review that are still open. Target: closed before the next release.
Handle incidents and trends differently. An incident — a secret on the main branch, a change merged without an independent approver, an agent acting outside its scope — is fixed the same day and does not wait for a review meeting. Trends are reviewed monthly; we’d recommend tightening the matching rule when a metric moves the wrong way in two consecutive reviews, which filters out one-off spikes without letting a real decline run for a quarter. Teams with few releases can use a longer window. The business result is predictable maintenance cost, as our guide to AI app development cost shows.
How to roll out AI code governance in 30 days
An engineering team can roll out AI code governance in 30 days, one step per week, with the code host and scanners it already has. Weeks 1 and 2 cover the NIST SSDF practice group Prepare the Organization (PO); weeks 3 and 4 cover Protect the Software (PS) and Produce Well-Secured Software (PW).
| Week 1 — Inventory | List AI tools and agents in use, by team, repository and plan; record where prompts are processed. |
| Week 2 — Policy | Write the six decisions on one page; management signs it off; team leads brief developers and suppliers. |
| Week 3 — Controls | Switch on required approvers, secret scanning and package checks; add the AI-assistance line to the pull request template; create separate agent accounts. |
| Week 4 — Baseline | Have the code already written with AI tools reviewed by someone who did not write it; our guide to an AI code audit explains the scope. |
If week 4 finds problems in payment, authentication or personal-data code, fix those before widening AI or agent use.
How Sunbytes helps you put AI code governance into practice
AI code governance is only as strong as the evidence behind it: controls that run, review records a customer can read, and findings that were actually fixed.
Sunbytes produces the evidence side with an AI-built product review. We scope what was built and who uses it, review the agreed areas across code, product behaviour and technical set-up, and separate what needs attention now from what can wait. The reviewer did not write the code, and the findings come back in plain English with a prioritised action plan. Your team can use each finding to see where a policy rule is missing or a gate control did not catch a problem, and decide which of the six decisions to tighten first.
Where the findings touch access control or personal data, our cybersecurity team adds the security controls and the evidence that NIS2 and ISO 27001 supplier questionnaires ask for. Your team fixes the findings, or Sunbytes fixes the priority items and re-checks them. The work runs with Dutch-led client governance, backed by 15+ years in software delivery and 300+ projects delivered.
→ Discuss your AI-built product with us, and we will scope the review around the governance you are rolling out.
