Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
What should an AI coding policy include?
Updated
An AI coding policy defines scope, approved tools, data and IP rules, review and provenance requirements, exceptions, and review cadence. Clauses below are marked mandatory or recommended. This template requires legal review — it is not legal advice.
AI coding policy template, last verified 10 September 2026 against ISO/IEC 42001:2023 organisational policy expectations, NIST AI RMF Govern function, NIST SSDF PO practices, OWASP GenAI risk guidance, and contractual IP considerations flagged for counsel. Alignment notes reference ISO 42001 and SSDF without claiming certification. Not legal advice.
Template — starting point, not legal advice
Audience: a CTO, CISO, or compliance owner drafting an internal AI coding usage policy for engineers using copilots, agents, and autonomous PR tools. This page is a template and commentary. It is not legal advice. Adapt every clause with counsel for your jurisdiction, sector, customer contracts, and employment law.
Mandatory versus recommended: mandatory clauses are labelled M — adopt unless counsel directs otherwise. Recommended clauses are labelled R — strong practice aligned with ISO/IEC 42001 and NIST SSDF, not statutes unless your regime makes them so. Using this template does not certify ISO 42001 or SSDF conformance. Last verified 10 September 2026. Not legal advice.
- Framework alignment without certification: ISO/IEC 42001 Clause 7.5 documented information and Clause 5 leadership map to policy ownership. NIST SSDF PO.1 organisation preparation maps to scope and roles. Neither standard certifies YOUR policy.
- The AI coding governance checklist guide on this site is the control map. The review-agent-generated-pull-requests guide on this site is the PR playbook. The AI governance policy template under guides is a broader umbrella document. The ISO 42001 framework guide on this site is standard education — not a substitute for this policy.
- Contractual and IP clauses flagged below require counsel — licence contamination, work-for-hire, and customer DPAs are not generic boilerplate.
Policy template — mandatory and recommended clauses
Copy and adapt the table into your policy library. Replace bracketed placeholders. M = mandatory for a defensible baseline; R = recommended. Not legal advice.
| Section | Clause text (adapt placeholders) | M/R | ISO 42001 / SSDF alignment note |
|---|---|---|---|
| 1. Purpose and scope | [Organisation name] allows AI-assisted coding only under this policy. Scope: employees, contractors, and agents acting on our repos in [list business units / repos]. | M | ISO 42001 Clause 4 context; SSDF PO.1.1. |
| 1. Purpose and scope | Out of scope: personal projects on personal devices unless separately approved. | R | Risk boundary clarity — best practice. |
| 2. Roles | Policy owner: [role]. Engineering approves tool allow-list changes. Security approves data-handling exceptions. | M | ISO 42001 Clause 5.3 roles; AI RMF Govern 1. |
| 3. Approved tools | Only allow-listed tools in Annex A may be used for [Organisation name] code. Requests for new tools go through [process]. | M | SSDF PO.3 toolchain control. |
| 3. Approved tools | Annex A lists vendor, model/version, data-processing terms, and approval date. | M | Documented information — ISO 42001 Clause 7.5. |
| 4. Data and IP | Do not paste secrets, credentials, customer PII, unreleased financials, or export-controlled data into AI tools. | M | OWASP LLM sensitive-data disclosure; counsel on sector rules. |
| 4. Data and IP | Do not submit third-party or open-source code whose licence forbids cloud processing without [legal] approval. | M | IP and licence risk — requires counsel. |
| 4. Data and IP | Assume vendor prompts may be logged or used for training unless vendor contract states otherwise. | R | Vendor due diligence — best practice. |
| 5. Provenance | AI-assisted commits must include [co-authored-by trailer / AI-assisted label / ticket reference]. Agent PRs must link to the initiating human owner. | M | SSDF PW.7 records; supports audit trail. |
| 5. Provenance | Retain agent session logs for [retention period] aligned with change records. | R | ISO 42001 Clause 7.5; incident investigation support. |
| 6. Review before merge | No direct push to protected branches. Human review per risk tier in [engineering standard / linked PR review guide]. | M | SSDF RV.1; DORA change-management practice. |
| 6. Review before merge | Author must be able to explain every merged line; unexplained AI output is rejected. | M | Human accountability — best practice; EU AI Act literacy concept if Act applies. |
| 7. Security | AI-touched changes run [SAST, secret scan, dependency scan] before merge. | M | SSDF PW.4–PW.8. |
| 8. Exceptions | Exceptions require written approver, scope, compensating controls, and expiry date in [ticket system]. | M | ISO 42001 risk treatment; AI RMF Manage 2. |
| 9. Training | Role-based training before first use; refresher on material policy change. | R | ISO 42001 Clause 7.2; EU AI Act Article 4 literacy if Act applies. |
| 10. Violations | Violations may result in [access revocation / disciplinary process per HR policy]. | M | Enforcement — counsel and HR review wording. |
| 11. Review cadence | Policy reviewed at least annually and when allow-list or vendor terms change materially. | M | ISO 42001 Clause 9.3 management review. |
| 12. Related documents | Cross-reference: security standards, SDLC, incident response, data classification. | R | Integrated management system — ISO 42001 Annex A. |
Annex A — approved tools (example structure)
Maintain Annex A as a living table in your policy library. Example columns only — not YOUR allow-list.
| Tool | Vendor | Approved use | Data handling note | Approval date | Owner |
|---|---|---|---|---|---|
| [IDE copilot example] | [Vendor] | Internal app repos only | Enterprise tier; training opt-out verified | [date] | [role] |
| [CLI agent example] | [Vendor] | Non-production branches | No customer data in prompts | [date] | [role] |
Mandatory versus recommended — how to read labels
M clauses are the minimum structure most organisations need before widening AI coding adoption. R clauses reduce operational and security risk but may be phased in. Neither label creates a legal obligation unless counsel or your sector says so. Last verified 10 September 2026. Not legal advice.
- Legal requirement versus framework guidance versus best practice: Union or state statutes beat this template. ISO 42001 and NIST SSDF inform structure — they are not automatic law. Customer contracts may make R clauses effectively mandatory.
- ShipReady Metrics recommendation: store the adopted policy in signed-in Compliance → Policies — tracking only, not legal review.
What you need to do now
Steps to go from template to adopted policy. Not legal advice.
- Copy the clause table; replace placeholders; attach Annex A with your real allow-list.
- Send mandatory clauses — especially data, IP, and violations — to counsel before publication.
- Align review tiers with the review-agent-generated-pull-requests guide on this site.
- Cross-check control coverage against the AI coding governance checklist guide on this site.
- Publish to your internal handbook; schedule annual review and tool-change triggers.
- Upload the signed version to Compliance → Policies if you use ShipReady Metrics for tracking.
Checklist
Pre-adoption checklist. Not YOUR signed policy. Not legal advice.
- Purpose, scope, and named policy owner filled in.
- Annex A allow-list complete with vendor data terms verified.
- Data and IP clauses reviewed by counsel.
- Provenance and review-before-merge clauses match engineering branch protection.
- Security scan requirements match your CI pipeline.
- Exception process tied to ticket system with expiry.
- Review cadence calendar invite sent to policy owner.
- Training plan linked for new hires.
- No claim of ISO 42001 or SSDF certification in the policy text.
Where this shows up in ShipReady Metrics
Shipped product surfaces only. The product does not draft or certify your policy.
- Signed-in Compliance → Policies holds policy documents you upload or maintain. It is a library — not legal advice, not auto-generation of mandatory clauses.
- Signed-in Compliance → AI governance AI risk register can reference which coding tools you recorded in inventory — not a legal classification.
- The bundled framework keys (including iso_42001 and eu_ai_act starter subsets on the obligation map) are illustrative control mappings — not certification that your policy satisfies those frameworks.
- The AI governance policy template under guides is a broader document pattern; this engineering policy is narrower and focused on coding workflows.
Primary sources (last verified 10 September 2026)
Framework and practice references for this template. Not legal advice.
ISO/IEC 42001:2023 — documented information, roles, operational planning, management review. NIST AI RMF 1.0 Govern function. NIST SP 800-218 Rev. 1 PO and RV practices. OWASP LLM Top 10 risk categories for data leakage and supply chain. Contractual IP and employment law require counsel — no primary URL substitutes for that review.
Frequently asked questions
Is this template legal advice?
No. It is an editable starting point. Mandatory and recommended labels are engineering governance guidance. Counsel must review data, IP, employment, and sector clauses before you adopt the policy.
Does adopting this template mean we are ISO 42001 certified?
No. Alignment notes reference ISO/IEC 42001 and NIST SSDF as structure hints. Certification requires an accredited audit programme — not copying a web template.
What is the difference between mandatory and recommended clauses?
Mandatory (M) clauses are the baseline most organisations need for a defensible AI coding policy. Recommended (R) clauses reduce risk but may be phased in unless your contracts or regulator expect them immediately.
Does ShipReady Metrics write our policy for us?
No. Compliance → Policies stores documents you provide. This page is the template content; the product does not generate legal text or certify compliance.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.