The playbook that no longer fits
Software governance was built on an assumption: that code is written by engineers, inside a controlled pipeline, with review gates you can stand at. So that is where the controls lived — at the gates. AI quietly invalidated the assumption. Now anyone can build, anywhere, outside any pipeline, and a policy that only governs the pipeline governs a shrinking share of what your organization actually ships.
In a regulated industry the stakes are not abstract. The same tools that let a clinician prototype a useful tracker let them paste protected health information into a service with no agreement covering it. Governance has to move from guarding a pipeline to zoning an activity — and it has to be short enough that people read it.
Three zones
Sort every AI-assisted build into one of three zones, defined by the data it touches and who depends on it.
- Green — build freely. Prototypes and personal-productivity tools on public or synthetic data, used by the builder or an immediate team, with no path to production or customer systems. No permission required. This is most of the activity, and the policy's first job is to bless it explicitly so careful people stop asking.
- Yellow — build with guardrails. Anything that touches internal or personal data, is used beyond the immediate team, or integrates with a system of record. Allowed, but registered in a central inventory and reviewed before others come to depend on it.
- Red — formal lifecycle only. Anything that authenticates users, moves money, faces external traffic, or touches regulated data. These cannot be vibe-coded into production; they enter the normal SDLC with code review, security sign-off, and a named owning team.
Calibrating to data and regulation
The zone boundaries move with your regulatory context, and naming the rules plainly is half the value:
- HIPAA (PHI). Protected health information never goes into a general-purpose AI tool, and no AI-built tool stores or transmits PHI without a business associate agreement and a completed review. PHI pushes a build straight to red.
- PCI-DSS (cardholder data). The cardholder data environment is out of scope for AI-assisted tooling, full stop.
- GDPR (EU personal data). Processing personal data of EU residents needs a lawful basis and a data-processing agreement with the tool vendor; default to data minimization and tokenized or sample data when building.
- SOX (financial reporting). Code touching financial-reporting systems requires change-control approval and segregation of duties — no exceptions.
- FedRAMP (federal data). Only authorized services may process federal data; consumer AI tools are prohibited for in-scope work.
The throughline is a single rule that is easy to remember: never paste regulated data into a tool that lacks an enterprise agreement with zero-data-retention terms.
The intake: registration plus amnesty
Governance that is harder than the workaround gets bypassed, so the sanctioned path has to be the easy one. Make registration a one-page form — name, purpose, owner, data touched, tool used — that takes minutes. Open with an amnesty: a window in which anyone can register an existing tool with no penalty, after which unregistered tools found in the wild are removed. The amnesty is what converts the shadow inventory you cannot see into a register you can.
Ownership rules
Most of the risk in vibe-coded software is not the code; it is the orphan. Require that every tool beyond the green zone has a single named owner accountable for its behavior and upkeep. Tools whose owner leaves or goes quiet are decommissioned within a set window unless someone re-adopts them. And when a tool graduates from experiment to dependency, it earns a real home — a repository, CI, and on-call — or it is retired. No tool gets to be load-bearing and ownerless at the same time.
Keep it to one page
The temptation in a regulated shop is to write the comprehensive version: every scenario, every exception, every signature. Resist it. A one-page policy that people read and follow protects you more than a forty-page one that lives in a wiki nobody opens. Lead with the three zones, list the data rules, name the intake, and stop. You can always tighten a clause; you cannot retroactively make people have read the long version.
Generate yours
The AI Coding Governance Policy Builder assembles this into a tailored draft — pick your industry, regimes, risk appetite, and the data classes in play, and it produces the tiered policy, the data-handling rules, the intake, and the ownership clauses, ready to circulate. Pair it with the Shadow AI Exposure Register to find what the policy now needs to cover.