An AI policy your engineers will actually follow

The fastest way to lose control of AI in your engineering organization is to ban it. We keep meeting companies that officially do not allow coding assistants and, a few interviews later, turn out to be full of engineers using them anyway: personal accounts, consumer tools, company code pasted into chat windows with no logging, no data agreement and no review trail. The ban did not stop the usage. It stopped the visibility.

A workable AI coding policy for an engineering team is written as enablement with limits, not prohibition. It fits on a page, and it answers four questions: which tools on which accounts, what data can go where, what gets reviewed and how, and who owns the result. Everything else is commentary.

Prohibition produces shadow AI

The failure mode deserves to be stated plainly because it is so common. A blanket ban, or a policy so restrictive it amounts to one, moves usage underground rather than to zero. Engineers are evaluated on delivery, the tools help them deliver, and the tools are one browser tab away. The predictable result is the worst configuration available: unapproved tools, unmanaged accounts, no telemetry, and code entering your product that nobody dares attribute honestly, since admitting it means admitting a violation.

A policy nobody follows also does damage beyond AI. It teaches the team that policies are theater, which you will pay for on the next one.

The four sections an AI coding policy needs

Approved tools and accounts. Name the tools the company sanctions and require the business tier: SSO, training on your data disabled, audit logs on. The point is that where your code goes when developers use AI is controllable, but only through accounts you administer. Personal accounts on company code are the one prohibition worth keeping, and it is enforceable precisely because you offered a sanctioned alternative.

Data boundaries. Say what can reach which tool. In most companies, source code can flow to the approved tools by default. Secrets and credentials never leave, and secret scanning enforces that mechanically. Customer data, personal data and regulated material need an explicit legal decision per tool, not per developer per day. Write the boundaries as short lists; a matrix nobody can memorize will not survive contact with a deadline.

Review. AI-written code goes through the same review as human code, with no fast lane. Then scale scrutiny with risk, not with authorship: authentication, payments, data deletion, anything security-sensitive gets a second reviewer regardless of who or what wrote it. The policy states the rule; guardrails in CI enforce the parts a document cannot.

Attribution and ownership. Engineers must be able to say "an agent wrote most of this" without penalty, because honesty about provenance is what makes calibrated review possible. In exchange, ownership is absolute: whoever opens the pull request owns every line in it, whatever produced it. Accountability stays with people. This trade, honesty for safety, is the cultural core of the policy, and teams feel the difference within weeks.

Rules that scale with risk, not blanket rules

Most policy failures we see come from flatness: one rule for all code. A README fix and a change to payment routing are different activities, and engineers know it, which is why flat rules read as unserious. Tier the risk explicitly. Low-risk paths get the default flow. High-risk paths get named in the policy (the list is shorter than people expect) and carry extra review and restricted autonomy for agents. This is also what keeps the policy short: you only write special rules where risk earns them.

Make it checkable, or watch it drift

Every rule should point at a mechanism: SSO gating for tool access, secret scanning for credentials, CI checks for the review gates, audit logs for usage. A rule with no mechanism is a wish, and wishes drift within a quarter. The corollary is useful in the other direction too: if you cannot imagine a mechanism for a rule, that is a sign the rule is vague, and vague rules are where shadow usage restarts.

Ship the policy as part of enablement, not as a memo from legal. It lands best inside a proper rollout, introduced in the same session where people learn the workflows the policy governs, then revisited quarterly, because the tools change fast enough to make an annual policy wrong by month six. Writing this document with engineering leadership, and wiring the mechanisms behind it, is standard scope in our agentic engineering engagements. The teams that get it right spend a day on the policy and a quarter on the habits, which is the correct ratio.