Writing an AI usage policy that engineering will actually follow

Most AI usage policies get ignored because they were written by lawyers, live in Notion, and were last updated six months ago. Engineers never read them. Auditors read them and immediately see the gap between the policy and the shipped system. This post is about writing a usage policy that engineering will actually follow because it lives where they already work.

Why policy documents in Notion get ignored

The failure mode is predictable. Legal or compliance writes a 12-page document. It gets emailed once. It is stored in a Notion page nobody has bookmarked. Six months later, engineering has shipped four AI features that violate three sections of the policy, and nobody knew because nobody re-read the document. When the audit comes, the policy is a piece of paper that describes a system that does not exist.

The problem is not the policy — it is the format. A document that lives outside the engineering workflow will always drift out of sync with the engineering reality.

The policy-as-code pattern

Treat the AI usage policy the same way you treat the security policy in a mature engineering org: a checked-in Markdown file in the repository, versioned in git, updated by pull request, and referenced by a CI/CD gate. When a policy section changes, it is a PR review with named approvers. When code touches an area covered by the policy, the CI job blocks the merge until the policy check passes.

This gives you three things a Notion doc cannot. First, an actual history of who changed what and why. Second, a review process that forces the change to be considered by the right people. Third, a hook point where the policy becomes enforceable — a failing CI job is far more attention-grabbing than a paragraph in a doc.

The 8 sections every AI usage policy should have

• →Scope — which teams, products, and AI systems the policy covers, and what is explicitly out of scope
• →Acceptable use — what the organization will and will not use AI for, with concrete examples on both sides of the line
• →Data classification — which data classes may be sent to which model providers, with a table mapping classes (public, internal, confidential, restricted) to allowed destinations
• →Model approval — the process for adding a new model or provider to the approved list, including the owner, the review checklist, and the sign-off record
• →External-service-only rules — restrictions on sending customer or employee data to external AI services, including any required contract terms and data-processing agreements
• →Human oversight requirements — for each risk tier, what level of human review is required before AI output reaches users or triggers actions
• →Incident response — what counts as an AI incident, how it is reported, who is on the response rota, and what the post-incident review must produce
• →Review cadence — how often the policy is re-read against the current shipped system, who owns the review, and what evidence the review produces

Template outline

Your file, checked into the repo root or a governance folder, should follow this structure. Keep it short — a two-page policy that engineers read beats a twelve-page policy they ignore.

• →Header — policy name, owner, last reviewed date, next review date
• →Section 1: Scope
• →Section 2: Acceptable use
• →Section 3: Data classification
• →Section 4: Model approval
• →Section 5: External-service rules
• →Section 6: Human oversight
• →Section 7: Incident response
• →Section 8: Review cadence
• →Footer — change log and named reviewers

Make it enforceable

A checked-in policy is still a document unless something enforces it. Two lightweight hooks close the loop. First, a CI check that fails when a PR touches any AI-related code and no accompanying policy review record is attached. Second, a scheduled job that opens a review ticket every quarter and blocks approvals from lapsing.

How Zilonex Govern helps

Zilonex Govern includes a starter AI usage policy template mapped to ISO 42001 and the EU AI Act, an approval workflow for adding new models and providers, and an audit-evidence trail that captures every change with reviewers and dates. Instead of writing a policy from scratch and hoping engineering follows it, you get a policy that ships with the framework and stays in sync as your systems evolve.