Most engineering teams already use AI tools. Far fewer have written down what is allowed, what is not, and who decides. The gap between those two facts is where the risk lives.
When we are brought in to help a team get AI under control, the first thing we ask for is the policy. Usually one of two things is true. Either there is no policy, and individual engineers are making case-by-case judgement calls with company code and customer data. Or there is a policy, but it was written by legal, it is four pages of "the employee shall," and no engineer has read past the first paragraph.
Both leave you exposed. A good AI usage policy is not a legal shield. It is a working document that tells an engineer, at the moment they reach for a tool, what they can do without asking and what they need to check first.
What a usable policy actually decides
A policy that engineers follow answers concrete questions they have during real work. Not principles, decisions. There are five that matter most.
| Decision | The question it answers | What "undefined" costs you |
|---|---|---|
| Approved tools | Which AI tools may I use for company work? | Shadow AI: engineers pick their own, with no review of terms or data handling |
| Data boundaries | What may I put into a prompt, and what must never leave? | Secrets, customer data, or proprietary code sent to an unvetted endpoint |
| Review obligations | What checking do I owe before AI output ships? | Unreviewed AI code in production, owned by no one |
| Accountability | Who is responsible when AI-assisted code fails? | Diffusion of responsibility; "the model wrote it" as a defence |
| Escalation | When something is unclear, who do I ask? | Engineers guessing, or quietly doing the risky thing |
If your policy leaves any of these undefined, it is not governing the behaviour that creates risk. It is describing an aspiration.
Start from approved tools, not banned ones
The instinct is to write a list of prohibitions. It does not work, because new tools appear faster than you can ban them, and a list of what is forbidden tells an engineer nothing about what is safe.
Invert it. Name the tools that are approved for company work, the data tier each is cleared for, and the route to get a new one added. An allowlist with a fast intake process beats a denylist that is permanently out of date.
A practical structure:
- Approved for any company data, including proprietary code: tools you have a data processing agreement with and have reviewed.
- Approved for non-sensitive use only: tools acceptable for public information, scaffolding, or learning, but never for customer data or secrets.
- Not approved, request review: everything else, with a named owner and a target turnaround so the answer is not "no" by default, it is "not yet."
The fast intake matters more than the list. If getting a tool approved takes three weeks, engineers will route around you, and you are back to shadow AI.
Make the data rules concrete
"Do not share confidential information with AI tools" is not a rule an engineer can apply. They will, in good faith, disagree with you about what counts.
Replace it with tiers and examples they can match against in seconds.
| Data tier | Examples | Rule |
|---|---|---|
| Public | Open-source code, public docs, generic questions | Any approved tool |
| Internal | Internal code, architecture, non-personal config | Approved tools with a data agreement only |
| Restricted | Secrets, credentials, keys, customer PII, regulated data | Never pasted into any prompt, no exceptions |
The Restricted row is the one that prevents the incident that ends up in a post-mortem. Make it unambiguous, and pair it with tooling, secret scanning on commits, masked logs, so the rule is not the only thing standing between a tired engineer and a leaked key.
Tie the policy to the workflow, not a training slide
A policy read once during onboarding and never again is not a control. The teams that make this stick connect the policy to the moments where the decision is actually made.
- The approved-tools list lives where engineers configure their tools, not in a wiki nobody opens.
- The review obligation is part of the pull request template, so "did a human own this change" is a checkbox, not a memory test.
- The data tiers show up in the secret-scanning and pre-commit tooling, so the policy enforces itself where it can.
This is the same principle we apply to approved AI workflows: governance that lives next to the work gets followed, governance that lives in a document gets forgotten.
Name accountability explicitly
The single most important sentence in the policy is the one about ownership. AI assistance does not transfer responsibility. The engineer who submits the change owns it, the same as if they had typed every character. "The model suggested it" is not a defence, and the policy should say so in plain words.
This is not about blame. It is about preserving the one assumption that makes review and quality work at all: that a named human understands and stands behind each change. The moment that assumption is allowed to dissolve, every other control downstream weakens with it.
Keep it short enough to read
A policy that engineers will follow is one or two pages, written in language they use, with examples from their actual work. If it reads like a contract, it will be treated like one: signed, filed, ignored.
Write it for the engineer at the keyboard, not the auditor in the meeting. The auditor can be satisfied by a short, clear, enforced policy far more convincingly than by a long one nobody follows.
Our view
An AI usage policy is not paperwork you produce to look governed. It is the set of decisions that let an engineer act quickly and safely without asking permission for every routine choice, and that tell them clearly when they do need to ask.
The teams that get this right write less, not more. They decide the five things that matter, approved tools, data boundaries, review, accountability, escalation, put those decisions where the work happens, and keep the document short enough that people actually read it. Everything else is detail you can add once the core is followed.
A policy nobody reads governs nothing. Start from what an engineer needs to know at the moment they reach for a tool, and you will write one that does.
Sources
- EU Artificial Intelligence Act, Article 4, on AI literacy obligations, accessed 2026-06-10
- OWASP,
OWASP Top 10 for Large Language Model Applications, accessed 2026-06-10 - NIST,
AI Risk Management Framework (AI RMF 1.0), accessed 2026-06-10
Frequently asked questions
- What are the five things an AI usage policy for engineers must actually decide?
- A policy that engineers follow must answer five concrete questions: which AI tools are approved for company work, what data may go into a prompt and what must never leave, what review is required before AI output ships, who is responsible when AI-assisted code fails, and who to ask when something is unclear. Leaving any of these undefined means the policy is not governing the behaviour that creates risk.
- Why use an allowlist of approved AI tools instead of a list of banned ones?
- New tools appear faster than a denylist can be updated, and a list of forbidden tools tells an engineer nothing about what is safe to use. An allowlist names the tools cleared for company work, specifies the data tier each is approved for, and provides a fast intake route for adding new ones. The intake speed matters more than the list itself: if approval takes three weeks, engineers will route around the process and shadow AI returns.
- How should data tiers in an AI policy be defined so engineers can apply them in the moment?
- Replace vague rules like "do not share confidential information" with three concrete tiers engineers can match against in seconds. Public data (open-source code, public docs) may go into any approved tool. Internal data (internal code, architecture, non-personal config) may only go into approved tools that have a data processing agreement. Restricted data (secrets, credentials, customer PII, regulated data) must never be pasted into any prompt, with no exceptions. Pair the Restricted rule with secret scanning on commits and masked logs so the policy enforces itself where it can.
- Who is responsible when AI-assisted code turns out to be wrong or causes a production incident?
- The engineer who submits the change owns it, exactly as if they had typed every character. AI assistance does not transfer responsibility, and "the model suggested it" is not a valid defence. The policy must state this in plain language because the moment that assumption is allowed to dissolve, every downstream control, including code review and quality gates, weakens with it.
