AI Coding Governance Policy Builder
Generate a tiered, board-ready acceptable-use policy for AI coding tools — calibrated to your industry, risk appetite, and the data your teams touch. Nothing leaves your browser.
Calibrate
The policy updates live as you change these.
Executive Summary
This policy lets technical staff move fast with AI coding tools while keeping customer trust, and production systems out of harm's way. It sorts every AI-assisted build into a green, yellow, or red zone by the data it touches and who depends on it — so the safe 80% needs no permission, and only the risky few require review. Calibrated for General / Cross-industry at a balanced risk appetite, under SOC 2.
Internal-only tools and automations touching public or internal (non-personal) data, used by you or your immediate team, with no path to production customer systems.
- — A script that reformats a spreadsheet you own
- — A local prototype to test an idea before pitching it
- — An internal dashboard over public or synthetic data
Anything that touches personal data (PII), or is used beyond your immediate team, or integrates with a system of record or another team's service. Must be registered in the central AI-build inventory and reviewed by engineering or security before others depend on it.
- — A team tool that reads from a shared internal database
- — An automation that processes a list of customer names/emails
- — A workflow other people will start to rely on
Anything that authenticates users or handles credentials, processes payments or moves money, is exposed to external or customer traffic. These must go through the formal SDLC with code review, security sign-off, and a named owning team — they cannot be vibe-coded into production.
- — A customer-facing login or sign-up flow
- — Anything in the payment path
- — Anything exposed to the public internet
Acceptable Use
- Permitted builders: any technical staff (engineers, analysts, technical PMs).
- Sanctioned tools: GitHub Copilot, Cursor, Claude Code. Using non-sanctioned AI coding tools for company work — or on company data — is prohibited.
- Treat AI output as a draft from a fast but unaccountable junior: you own, review, and are responsible for every line you ship.
- SOC 2: AI-built tools that touch in-scope systems must inherit the same access controls, logging, and change management as any other system.
Data Handling
- Public / synthetic data: no restriction.
- Internal data: only in sanctioned tools with enterprise terms; never in a personal account.
- PII: minimise, never paste raw identifiers into prompts, and prefer tokenised or sample data when building.
Intake & Registration
- Open with a 30-day amnesty: anyone may register an existing AI-built tool with no penalty. Tools found unregistered after the window are removed.
- Register any yellow-zone tool before others depend on it: name, purpose, owner, data touched, and build tool.
- Registration takes minutes and is a one-page form — the goal is visibility, not friction.
- Stand up a minimal review gate (one reviewer + a security checklist) for anything leaving the green zone.
Ownership & Maintenance
- Every tool beyond the green zone has a single named owner accountable for its behaviour and upkeep.
- Tools whose owner leaves or goes unmaintained are decommissioned within 60 days unless re-adopted.
- When a tool graduates from experiment to dependency, it gets a real home (repo, CI, on-call) or it gets retired.