AI Coding Governance: A Policy Document Template

A governance framework is not the same thing as a governance document. The framework is what you believe. The document is what you publish to the intranet so that when someone asks “what’s the policy?”, there is something to link to.

Most posts about AI governance stop at the framework. This one gives you the document — the fill-in-the-blank policy language your VP Engineering can paste into Confluence, adjust the bracketed [PLACEHOLDERS], get signed off by Legal and Security, and ship within a sprint.

Copy everything between the horizontal rules. The bracketed fields are the only decisions you need to make. The structure, numbering, and language tracks what SOC 2, HIPAA, and the EU AI Act auditors expect to see in a software-development-use-of-AI standard.

---

[ORGANIZATION] — AI Coding Tools Standard

Document ID: POL-ENG-AI-001 Version: 1.0 Effective date: [YYYY-MM-DD] Owner: [CTO / VP Engineering] Reviewers: [CISO, Head of Legal, Head of Privacy] Review cadence: Annual, or on material tooling change Applies to: All engineering staff, contractors, and vendors with access to [ORGANIZATION]‘s source code repositories

1. Purpose

This standard defines the approved use of AI coding assistance tools within [ORGANIZATION]‘s software development lifecycle. It establishes which tools may be used, under what conditions, with what oversight, and how violations are handled. Its purpose is to enable safe, compliant use of AI coding tools — not to restrict adoption.

2. Scope

This standard applies to:

• All [ORGANIZATION] source code repositories, including production, staging, internal tooling, and research codebases classified as [INCLUDED_CLASSIFICATIONS].
• All engineering personnel and contractors with commit access to the above.
• All AI coding assistance tools, defined as any software that generates, completes, refactors, or reviews source code using a language model, whether cloud-hosted, self-hosted, or embedded in an IDE.

This standard does not apply to:

• AI use unrelated to source-code generation (e.g., documentation drafting, meeting summaries) — covered by [GENERAL_AI_USE_POLICY].
• Research code developed in isolated sandboxes not connected to production systems — covered by [RESEARCH_SANDBOX_POLICY].

3. Definitions

• Approved tool — An AI coding assistance tool that appears on the Approved Tools List maintained at [URL].
• AI-assisted commit — Any commit where an AI tool contributed to the code being committed, including commits where the developer prompted the tool but manually edited the output before committing.
• High blast radius path — A file path whose modification can affect authentication, authorization, payment processing, cryptographic primitives, or any component designated by CODEOWNERS as security-critical or platform-critical.
• Provenance metadata — The git trailer fields AI-Assisted, AI-Tool, AI-Model, AI-Prompt-Summary, AI-Review-Confidence, and Reviewed-by as defined in [ORGANIZATION]‘s commit convention documentation.

4. Approved Tools

4.1. Only tools on the Approved Tools List may be used for work on [ORGANIZATION] source code.

4.2. A tool is added to the Approved Tools List only after: (a) Security review by [SECURITY_REVIEWER_ROLE], evaluating vendor security posture, data handling, and retention commitments. (b) Legal review by [LEGAL_REVIEWER_ROLE], covering licensing, IP indemnification, and regulatory fit (SOC 2, HIPAA, GDPR, as applicable). (c) Executed data processing agreement (DPA) and, where the tool may process protected health information, business associate agreement (BAA). (d) Technical onboarding via [SSO_PROVIDER] — no personal-account access.

4.3. Removal from the Approved Tools List occurs immediately upon: (a) Material change in the vendor’s security posture. (b) Disclosure of a data handling incident affecting [ORGANIZATION] or comparable customers. (c) Termination of the DPA.

4.4. The list is reviewed quarterly by [GOVERNANCE_COMMITTEE].

5. Acceptable Use

5.1. Permitted. Using an approved tool to: (a) Generate boilerplate, scaffolding, or documentation. (b) Draft implementations that the developer reviews line-by-line before committing. (c) Explain, refactor, or debug existing code. (d) Generate tests, with the caveat in §5.3.

5.2. Prohibited. Under any circumstances: (a) Pasting customer personal data, protected health information, payment card data, or cryptographic secrets into a tool prompt. (b) Pasting proprietary code from a prior employer, a customer codebase, or an unlicensed source. (c) Using a non-approved tool for work on [ORGANIZATION] code, including personal-tier accounts of otherwise-approved tools. (d) Committing AI-generated code without the provenance metadata required by §7. (e) Disabling the CI checks that enforce this standard.

5.3. Restricted. Permitted only with additional controls: (a) AI-generated tests for AI-generated code require a human-written assertion set in addition, per [TEST_POLICY]. (b) AI-assisted changes to high blast radius paths require two reviewers, per §6. (c) Any commit touching [DESIGNATED_HIGH_RISK_SYSTEMS] requires sign-off by [SECURITY_ROLE] before merge.

6. Review Requirements

6.1. Every AI-assisted commit must be reviewed by a human who is not the commit author, except for commits that pass the gating criteria in §6.3.

6.2. Review of AI-assisted commits requires the reviewer to confirm: (a) The code does what the commit message claims. (b) The code does not contain secrets, injection-susceptible patterns, or permissive security defaults. (c) Dependencies introduced by the commit do not appear on the [VULNERABILITY_REGISTRY]. (d) Tests are present at the level specified in [TEST_POLICY].

6.3. Fast-path merge (single-approval) is permitted for AI-assisted commits meeting all of: (a) AI-Review-Confidence: high (b) Blast radius low (no files in paths marked security-critical or platform-critical) (c) No SAST findings at ERROR severity (d) Test coverage delta non-negative

6.4. Two-reviewer path is required for any AI-assisted commit to high blast radius paths, or any commit with AI-Review-Confidence: low.

7. Provenance

7.1. Every commit to a [ORGANIZATION] repository must include provenance metadata in the commit message, in the git trailer format:

AI-Assisted: true | false
AI-Tool: [tool-name]           # required if AI-Assisted: true
AI-Model: [model-identifier]   # required if AI-Assisted: true
AI-Prompt-Summary: [one-line summary]  # required if AI-Assisted: true
AI-Review-Confidence: high | medium | low  # required if AI-Assisted: true
Reviewed-by: [reviewer-email]

7.2. Provenance metadata is retained in git for the duration of the regulatory retention period applicable to the repository, which is: (a) 12 months minimum for SOC 2–scope repositories. (b) 6 years minimum for HIPAA-scope repositories. (c) 3 years minimum for PCI-DSS–scope repositories. (d) 10 years minimum for EU AI Act high-risk system repositories.

7.3. Enforcement of §7.1 is automated via a commit-msg hook distributed with [ORGANIZATION]‘s developer environment and a CI check on every pull request. Commits failing these checks cannot be merged.

8. Security Controls

8.1. An AI-tuned static analysis ruleset is enforced on every pull request. The ruleset, its rules, and their severity are maintained by [APPSEC_ROLE] and documented at [SAST_RULESET_URL].

8.2. Findings are routed per the CI/CD gating tree documented at [GATING_TREE_URL]. ERROR-severity findings block merge; WARNING-severity findings require reviewer acknowledgement.

8.3. Exceptions to §8.2 require a written override recorded in the commit message under a Gate-Override-By: trailer, naming the overriding engineer. The overriding engineer assumes on-call responsibility for the affected commit for 48 hours.

9. Training

9.1. All personnel in scope must complete the [ORGANIZATION] AI Coding Safety Module within 30 days of gaining commit access or within 30 days of this standard becoming effective, whichever is later.

9.2. Refresher training is required annually and upon material change to this standard.

9.3. Training completion is recorded in [LMS] and audited [QUARTERLY|ANNUALLY] by [COMPLIANCE_ROLE].

10. Monitoring and Metrics

10.1. [GOVERNANCE_COMMITTEE] reviews, at least quarterly: (a) Provenance trailer coverage (target: [X]% of commits). (b) SAST finding rate per 1,000 AI-assisted commits (target: trending down quarter-over-quarter). (c) Override rate per 1,000 AI-assisted commits (target: < [Y]%). (d) Training completion rate (target: [Z]%). (e) Incidents attributed to AI-generated code, aggregated by root cause.

10.2. Metrics are reported to the [AUDIT_COMMITTEE | EXECUTIVE_RISK_COMMITTEE] quarterly as part of the broader engineering risk dashboard.

11. Enforcement

11.1. Violations of this standard are handled according to the [ORGANIZATION] Code of Conduct enforcement matrix: (a) §5.2(a) — Category A (potentially sanctionable up to termination). (b) §5.2(b) — Category A. (c) §5.2(c) — Category B (formal warning; repeat offenses escalate). (d) §5.2(d), §5.2(e) — Category C (informal correction on first occurrence; Category B on repetition).

11.2. Violations must be reported to [COMPLIANCE_CONTACT_ADDRESS] within 24 hours of discovery. Good-faith self-reporting is a mitigating factor in the enforcement decision.

12. Exceptions

12.1. Exceptions to any provision of this standard require written approval by both [CTO_OR_DELEGATE] and [CISO_OR_DELEGATE]. Exceptions are time-bound (maximum [N] months) and reviewed before renewal.

12.2. A registry of active exceptions is maintained at [EXCEPTION_REGISTRY_URL].

13. Revision History

Version	Date	Change	Author
1.0	[YYYY-MM-DD]	Initial version	[AUTHOR]

---

Filling In the Placeholders

The 25+ bracketed placeholders above are every decision you need to make. Grouped:

Organizational identity (one-time fill): [ORGANIZATION], document ID numbering, [CTO / VP Engineering], [CISO, Head of Legal, Head of Privacy].

References to existing policy (one-time, reuse URLs): [GENERAL_AI_USE_POLICY], [RESEARCH_SANDBOX_POLICY], [TEST_POLICY], [LMS], [EXCEPTION_REGISTRY_URL].

Role names (one-time, match your org chart): [SECURITY_REVIEWER_ROLE], [LEGAL_REVIEWER_ROLE], [APPSEC_ROLE], [COMPLIANCE_ROLE], [GOVERNANCE_COMMITTEE].

Technical references (one-time, link to implementation): [URL] for the Approved Tools List, [SAST_RULESET_URL], [GATING_TREE_URL] — these link to the artifacts from the SAST ruleset post and the gating tree post.

Thresholds (calibrated per your environment): [X]% trailer coverage target (90% is a reasonable starting point), [Y]% override rate ceiling (5% signals a well-tuned gate), [Z]% training completion (100% for engineers in scope).

Regulatory scope (depends on what you do): Strike or keep the retention durations in §7.2 based on which regulations apply to each repository class.

Where This Sits in the Stack

The document above is the policy layer. It is not self-implementing. Four other artifacts make it operational:

1. Provenance trailer convention — concrete spec for §7.
2. SAST ruleset — concrete rules for §8.1.
3. CI/CD gating tree — concrete decision logic for §6 and §8.2.
4. Risk assessment — the inputs that justify §10 metrics and their targets.

A policy that references these artifacts is auditable. A policy that is those artifacts (mixing “thou shalt” and “here’s how”) is unmaintainable — when the SAST ruleset changes, the policy needs to not change. Keep the layers separate.

What to Change on Review

Every year (or on material tooling change), update:

• The Approved Tools List and DPA status — tool vendors change often.
• §7.2 retention periods — regulations shift; stay current.
• §10.1 thresholds — calibrate as your baseline moves.
• Revision history — most commonly forgotten; auditors notice when it’s blank.

For the compliance mapping that demonstrates each clause above meets specific audit requirements, see the compliance requirements table.