Governance Before Scale
Start governance before broad rollout, not after AI use has already spread through the org. Retroactive policy lands after habits have formed, so it is harder to enforce and costs more - in friction, in rework, and in the shadow AI it fails to catch.
Why Governance Comes First
Order matters more than content here. A policy written after developers have already picked their own tools, pasted code into whatever chat window was open, and decided for themselves what counts as acceptable use is competing with habits, not preventing them. The same rule, published before tool access is granted, is a condition of access instead of a correction.
The five pillars below are not a one-time document. They form a cycle: policy sets the boundaries, ownership assigns who enforces them, logging and data classification make enforcement possible, vendor evaluation decides which tools are even allowed near the data, and the resulting rollout gets measured against a baseline that feeds back into the next policy review.
None of this requires a mature AI program first. A small team can write the policy outline below in an afternoon, name one owner, and turn on the logging its existing tools already provide. The pillars scale down as easily as they scale up - what does not scale is skipping them.
The Five Pillars
1. Policy Before Rollout
- Approved tools defined by context: IDE, CI, chat, and agents.
- Acceptable use documented for code generation, data handling, review, and agent delegation.
- Policy communicated before tool access is granted, not after.
- An exception process for uncovered tools and use cases, with a turnaround SLA, so it does not become the shadow AI on-ramp.
- A review cadence - quarterly is realistic - as tools and usage evolve.
2. Ownership Model
- One named owner of the AI operating model - usually a Director or VP of Engineering - accountable for policy, measurement, and the vendor relationship.
- Platform or DevEx owns agent identity, CI integration, budgets, and the shared instruction and skill libraries.
- Security owns data classification, the threat model, and vendor review.
- Each team lead owns review standards and tier assignments for their own codebase.
- Every merged PR has a human approver willing to own the outcome - this is not delegable to an agent.
3. Logging and Auditability
- Every agent action reconstructible after the fact: which identity, which model version, which prompt or task, which files, which PR.
- Agent commits attributed to a bot identity carrying the ticket ID; co-authorship trailers on human commits that used AI materially.
- One control plane, centralized where possible - three CI systems means three audit trails and an agent that cannot see the whole pipeline.
- Know which logs your vendor tier actually provides. Team tiers commonly lack audit logs, so the source-control audit log becomes the fallback system of record.
- Retention posture documented, not assumed.
4. Data Classification
- Four tiers are enough: Public, Internal, Confidential, and Restricted (PII, PHI, secrets, customer data).
- Each tier mapped to what may enter a prompt, an IDE context, an agent's working tree, or an MCP server.
- Restricted data never enters a prompt - synthetic fixtures only, enforced with secret scanning and PII detection on the agent's input side, not only on commits.
- Training opt-out confirmed in writing per vendor and per tier. Business and Enterprise tiers are typically opted out by default; consumer accounts are not - that gap is the shadow AI exposure in one sentence.
5. Vendor Evaluation
- Data handling: training opt-out, retention window, region, sub-processors, and BAA availability if you handle PHI.
- Identity: SSO, SCIM, per-user spend caps, and service accounts or workload identity for CI.
- Auditability: audit log export, and usage and cost export by user and by workflow.
- Controls: model allowlist, org-level policy enforcement, and IP indemnity terms.
- Behavior: evaluated on your own codebase and your own review rules, not the vendor's demo.
- Exit: how you get your data, prompts, and rules back out - see the vendor evaluation checklist below.
The Governance Cycle
The five pillars in the order they need to run, closing back on itself every quarter
AI Usage Policy Outline
Twelve sections. Copyable templates for this and the checklists below live on Templates and Checklists.
- Purpose and scope (who, which systems, which data).
- Approved tools by context: IDE, chat, CI agent, connectors. Anything not listed is not approved; exception process and SLA.
- Accounts: company-managed only; consumer accounts prohibited for Internal tier and above.
- Data rules by tier - see Security and Compliance for the four data tiers. Restricted data never enters a prompt or agent context.
- Code generation: instruction files required; plan approval for non-trivial work; PR template disclosure.
- Review: AI-authored code meets the human bar; tiered review; human approver on every merge; no agent self-approve.
- Agents in CI: identity, permissions, and budgets - see Agents in the Pipeline for the hard rules.
- Attribution: bot identity for agent commits; co-authorship trailer for material AI assistance.
- Security: dependency review for new packages; SAST required; secrets never in context.
- Incidents: how to report suspected data exposure or an agent acting outside scope.
- Measurement: what is tracked and that it is used for team health, not individual performance.
- Ownership and review cadence.
Eight Vendor Questions With Binary Answers
Ask these before you sign, not after. Each one should get a yes-or-no answer in writing, not a sales deck slide.
- Is your data used for training? Confirmed in writing for your tier?
- What is the retention window for prompts and outputs? Can you set it? Is zero-retention available?
- Region of processing? Sub-processors?
- BAA available? At which tier?
- Audit log export? Usage and cost export by user and by workflow?
- SSO and SCIM available at your tier?
- IP indemnity for generated code? Conditions (a duplicate-detection filter turned on, for example)?
- Model version pinning available on the API?
Vendor Evaluation Checklist
The same ground as the eight questions above, reshaped as a sign-off checklist for the procurement file. The full copyable version lives on Templates and Checklists.
- Training opt-out confirmed in writing for your tier.
- Retention window; zero-retention option.
- Processing region and sub-processors.
- BAA availability and tier.
- SSO, SCIM, per-user spend caps.
- Service accounts or workload identity for CI.
- Audit log export; usage and cost export by user and workflow.
- Model allowlist and version pinning.
- IP indemnity terms and conditions.
- Evaluated on your fixture set with your rules, not the vendor's demo.
- Data export on exit.
Where It Fits in AIDLC
Governance is not a sixth phase - it is the boundary that has to exist before any phase touches an agent. Analyze and Ideate only produce a usable spec inside the data tiers the policy allows; Develop runs inside the logging, identity, and approval rules the ownership model set up; Launch gates on the human-approver rule before anything ships; Curate is where the quarterly measurement against baseline happens and feeds back into the next policy review.
Frequently Asked Questions
One named owner, usually a Director or VP of Engineering, is accountable for policy, measurement, and the vendor relationship. Platform or DevEx owns agent identity, CI integration, budgets, and the shared instruction and skill libraries. Security owns data classification and vendor review. Each team lead owns review standards and tier assignments for their own codebase.
Twelve sections: purpose and scope, approved tools by context with an exception process, account rules, data rules by tier, code generation requirements, review standards with a mandatory human approver, agent permissions in CI, commit attribution, security requirements, incident reporting, measurement used for team health rather than individual performance, and named ownership with a review cadence.
Retroactive policy arrives after habits have formed, so it costs more to enforce and meets more resistance. Without policy in place first, teams default to whatever is easiest, often consumer accounts handling confidential work with no logging, no data tier rules, and no named owner - the shadow AI exposure that a policy written after the fact can only partially undo.
Write the Policy Before the Tools Arrive
Get the copyable templates, then sequence the rollout with exit criteria at every phase.