deliveryL2 GuidedGovernance & Compliance

Official AI tool policy

An official AI tool policy is the organization's first structured governance response to AI in the delivery pipeline.

·Official AI tool policy exists and is communicated to all developers
·Basic audit tracking is in place (which developers use which AI tools)
·EU AI Act awareness training or briefing has been conducted

·AI tool policy is reviewed at least annually
·Approved tool list is maintained and accessible

Evidence

·Published AI tool policy document with distribution records
·AI tool usage tracking dashboard or report
·EU AI Act training completion records

What It Is

An official AI tool policy is the organization's first structured governance response to AI in the delivery pipeline. It replaces the L1 state - either nothing (everyone uses whatever they want) or a blanket ban (nobody uses anything officially) - with a written policy that specifies which AI tools are approved, under what conditions they can be used, what data handling rules apply, and what disclosure is required.

At L2 (Guided), the policy is primarily document-based: a policy document, a list of approved tools, and a disclosure requirement in PR templates. It's not yet enforced by automation - compliance depends on developers reading and following the policy. That's a real limitation, but it's dramatically better than L1. A documented policy creates a shared reference point, gives compliant developers explicit protection, and gives the organization something concrete to show auditors.

The critical design decision in an official AI policy is scope. Too narrow (only covers code generation in IDE) and developers legitimately use AI tools that fall outside the scope without any governance. Too broad (covers any AI assistance including reading documentation) and the policy becomes unenforceable and developers ignore it entirely. The right scope is the set of AI use cases where the data handling and auditability requirements are materially different from traditional development - primarily: code generation, code review assistance, AI-driven debugging, and AI agents acting autonomously in the codebase.

A well-designed official policy does four things: it specifies approved tools with enterprise data handling agreements (not consumer-grade tools), it defines what data can be sent to AI systems (code: yes; customer PII: no; secrets: never), it requires disclosure of AI use in pull requests, and it identifies who is accountable for each tool's governance. Everything else is detail that can be added later.

Why It Matters

Creates a defensible compliance position - an organization with a documented AI tool policy, even an imperfect one, is in a fundamentally better position in a SOC2 audit than one with no policy. "Here is our policy and here is evidence we follow it" is an audit response; "we don't have a policy" is a finding
Reduces shadow AI - approved tools with enterprise data handling agreements, made available through official procurement, give developers a better alternative to personal subscriptions. The policy legitimizes official use and delegitimizes shadow use
Establishes the data handling baseline - specifying which data can and cannot be sent to AI systems is the most important risk control in an AI policy. This prevents the most common high-risk AI misuse: developers sending customer data or secrets to consumer AI interfaces
Gives developers clear guidance and protection - developers who want to use AI tools appropriately need to know what's allowed. A policy gives them permission, guidance, and organizational cover. Without it, every developer makes their own risk assessment, which leads to inconsistent behavior
Creates the foundation for L3 automation - policy-as-code (L3) requires a policy to automate. An organization that skips L2 and tries to jump to L3 will automate ad-hoc rules rather than a coherent policy

Getting Started

Draft a one-page policy first - resist the temptation to build a comprehensive policy from the start. Write one page: approved tools list, data classification rules, disclosure requirement, who to contact with questions. Circulate it for comment, improve it, publish it. One page that gets read is better than ten pages that don't.
Start the approved tools list with what developers already use - identify the AI tools with the highest existing adoption through the shadow AI census (or through developer surveys) and get enterprise agreements for those tools first. Starting with tools developers already use maximizes adoption of the official policy immediately.
Create the data classification section carefully - this is the highest-risk section. Work with security to define: what repository content can go to AI tools (generally: yes), what data from databases can go to AI tools (generally: no without review), whether any production access is permitted for AI tools (generally: read-only, no secrets). Get explicit sign-off from the CISO on this section.
Build the PR disclosure requirement into the template - update the pull request template in your repositories to include an AI disclosure section: "AI tools used (if any): [list tools and purpose]." This is your earliest form of audit trail and requires no new tooling. Make it a required field, not optional.
Identify a policy owner - a policy without an owner becomes stale. Assign someone (typically a security architect or engineering manager) to own the policy with a quarterly review responsibility. The policy owner's name and contact should be in the document.
Publish the policy with a grace period - announce the policy, give developers 30 days to review it, and communicate what happens at the end of the grace period (PR template changes take effect, shadow AI use is expected to migrate to official tools). Don't enforce against developers who were using approved tools before the policy existed.

Tip

The fastest way to get developer buy-in for an AI policy is to make it visibly better than the status quo. If the policy comes with access to Claude Enterprise or GitHub Copilot Enterprise that developers didn't have before, it will be welcomed. If it only restricts without enabling, expect resistance.

6 steps to get from here to the next level

Common Pitfalls

Writing a policy that prohibits more than it enables. An AI policy that says "you may not use AI tools except in the following narrow circumstances" will not be followed because it's more restrictive than what developers need. Policies that succeed describe what's allowed broadly and what's prohibited specifically, with the approved list being expansive enough to cover real use cases.

Not getting the data handling section right. The most important part of the policy is what data can go to AI systems. If this section is vague or missing, developers will make their own judgments, and some of those judgments will be wrong in ways that create real risk. "Code files from non-regulated repositories: OK; files containing secrets or tokens: never; customer data: requires security review" is the right level of specificity.

Forgetting about agentic AI. Most first-generation AI policies were written for copilot-style tools where a developer explicitly queries the AI. As teams adopt agent tools (Claude Code, Cursor with agent mode, GitHub Copilot Workspace), the policy needs explicit rules for AI systems that take autonomous actions: what actions can agents take without approval, what requires human confirmation, what is prohibited entirely.

No exceptions process. A policy with no exceptions process will either be ignored (when the exceptions are obvious and the stakes are low) or create blockers (when legitimate use cases are excluded and there's no path to approval). Build a lightweight exceptions process: a specific person to contact, a target response time of 48 hours, and a list of what information is needed for an exception request.

Treating publication as completion. Publishing the policy is the start of governance, not the end. You need to communicate it, train developers on it, answer questions about it, and update it as tools and practices evolve. Schedule the first policy review at the time of publication, not when a problem forces your hand.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob needs to deliver an AI governance framework to the CISO within 30 days as a condition of getting budget for official AI tool procurement. He has done a shadow AI census and knows what tools developers are using and what data handling risks exist. Now he needs to turn that knowledge into a policy document.

What Bob should do: Bob should start with the one-page draft approach. In a single document: approved tools list (those with enterprise DPAs that address the CISO's concerns), data classification table (what can and cannot go to AI systems), PR disclosure requirement (text for the PR template), and policy owner designation. Bob should review this draft with the CISO and the legal team before publishing - one round of feedback with a one-week turnaround. The output of that review is the v1 policy. Bob should publish it with a 30-day grace period and use the grace period to get enterprise licenses procured and deployed. Policy without tooling is ineffective; they need to ship together.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah needs to start measuring AI adoption and productivity impact, but she can't measure reliably until there's an official policy that defines what AI use is legitimate. Right now, any measurement she does captures only the fraction of AI use that happens through official tools, which dramatically understates real adoption.

What Sarah should do: Sarah should treat the official policy publication as a measurement milestone. On day one of the official policy, she sets a baseline: here is the current state of official AI tool adoption, here are the disclosure rates in PR templates, here is the current throughput baseline. She then tracks these metrics over 90 days: how did adoption change, did throughput change, what's the quality trajectory? The policy creates the measurement infrastructure she needs - every PR with an AI disclosure field gives her a data point she didn't have before. Sarah should use the first policy review meeting to present these first 90 days of data, which gives the policy review a quantitative foundation rather than being a purely process conversation.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor wants the policy to enable the advanced workflows he's using - multiple parallel agents, MCP server integrations, autonomous code generation - but he worries that a conservative first policy will prohibit these patterns and create friction for the team's most sophisticated AI use.

What Victor should do: Victor should participate actively in the policy drafting, not just the review. He should bring specific use cases that need to be explicitly in scope: "AI agents that can run CLI tools in sandboxed environments," "MCP servers that provide codebase context to AI tools," "AI-generated PRs that are reviewed and merged by human developers." For each use case, he should also bring a proposed governance control: what approval is needed, what gets logged, what's off-limits. Victor as policy co-author rather than policy critic produces a document that actually enables sophisticated use rather than inadvertently prohibiting it.

What Victor should do - role-specific action plan