AI Development Policy
Creating an AI Development Policy That Engineers Will Actually Follow
An AI development policy that engineers follow is short, specific and enforced by the tools they already use: context files such as AGENTS.md, CI gates and pull request checklists. It covers seven areas, from approved tools and data rules to review triggers and client IP, and it rolls out in phases. A policy that lives only in a wiki gets ignored.
Every engineering organization that adopts AI coding assistants eventually confronts the same uncomfortable question: what are people actually doing with these tools? In many companies, nobody knows. Developers copy proprietary code into ChatGPT, paste customer data into Claude prompts and commit AI-generated functions that nobody reviewed for license contamination or security vulnerabilities. The organization distributed licenses, held a hackathon and called it a strategy. That is not a policy. It is a liability waiting to surface.
AI policy should make good behavior easy, not bury developers in rules. The most effective policies are short, specific and embedded in the tools developers already use. They do not live in a wiki that nobody reads after onboarding. They live in Cursor Rules files, AGENTS.md instructions, CI gates and pull request checklists. Policy that exists where developers work gets followed. Policy that exists in a compliance portal gets ignored.
Why "License and Pray" Fails
The most common anti-pattern in AI adoption is what we call "license and pray." The organization buys Copilot or Cursor licenses for the engineering team, runs a lunch-and-learn or hackathon and then assumes adoption will sort itself out. It does sort itself out, just not in the way leadership intended.
Without organizational context, AI tools generate code that follows generic patterns rather than your architecture. Without data usage rules, developers paste sensitive information into third-party APIs. Without review requirements, generated code enters production without anyone verifying that it works correctly, handles edge cases or avoids introducing vulnerabilities. The hackathon produced impressive demos. The production codebase produced incidents.
The problem is not the tools. The problem is that isolated tools lack organizational and architectural context, the gap described in from sprint-centered to context-centered development. An AI assistant that does not know your team's conventions, security requirements or deployment constraints will produce code that looks correct but violates unstated assumptions. Policy bridges the gap between a general-purpose tool and your specific engineering environment.
What a Complete AI Development Policy Covers
A practical AI development policy addresses seven areas. Each should be specific enough that a developer can read it and know exactly what to do in any given situation.
The first area is approved tools and their boundaries. The policy should name which AI coding assistants are approved, which models are permitted and whether developers may use tools outside the approved list for personal experimentation versus production work. This matters because different tools handle data differently, and your security team needs to know which services are processing your code. If your organization has approved Cursor and Claude Code but not ChatGPT for code generation, say so explicitly. If developers may use unapproved tools for non-proprietary personal projects but not for client work, say that too.
The second area is data usage rules. This is where most policies either go too far or not far enough. Going too far means prohibiting any code from touching an AI tool, which effectively kills adoption. Not going far enough means letting developers paste customer PII, API keys or proprietary business logic into any prompt without restriction. The practical middle ground defines categories: public code and open-source patterns are unrestricted; internal proprietary code may be used with approved tools that have enterprise data agreements; customer data, credentials and security-sensitive code are never sent to external AI services. No exceptions.
The third area is codebase access and permission boundaries. When teams use agentic tools like Claude Code that can read entire repositories and execute commands, the policy must specify which repositories agents can access, what file system permissions they operate under and whether they may make network requests, install packages or modify infrastructure configuration. Encode these boundaries in the tool's configuration, not just in documentation. The chapter on building the AI-ready repository covers the context files that carry them, and the security chapter covers the surrounding architecture.
The fourth area is human review requirements. Not all AI-generated code needs the same level of scrutiny. A policy might specify that AI-generated utility functions get standard code review, AI-generated authentication or authorization code gets security-focused review, AI-generated database migrations need both code review and DBA sign-off, and AI-generated infrastructure changes need architecture review. The key is tying review requirements to risk, not to the mere fact that AI was involved.
The fifth area is security review triggers. Beyond standard code review, certain categories of AI-generated code should trigger formal security review: any code that handles authentication, processes user input, interacts with external services, modifies access controls or touches financial transactions. The policy should define how security reviews are requested and who conducts them, and these triggers should be encoded in CI pipelines where possible.
The sixth area is attribution and documentation. When AI generates a significant portion of a module or introduces a new architectural pattern, the team should know. This is not about blame; it is about context. When someone debugs that code six months later, knowing it was AI-generated helps them understand why certain patterns were chosen and where implicit assumptions might be hiding. A simple convention like a comment header or a commit message tag works better than an elaborate tracking system.
The seventh area is handling customer intellectual property and proprietary code. For organizations that do custom software development for clients, this area is non-negotiable. The policy must specify whether client code may be processed by AI tools, which tools have appropriate data processing agreements, how client IP is isolated from other projects and what disclosures client contracts require. Many enterprise clients now ask vendors directly about their AI usage policies. A clear, documented answer helps win their trust.
Encoding Policy in the Workflow
What separates effective AI policies from shelf-ware is where the policy lives. A policy document in Confluence tells developers what they should do. A Cursor Rules file, an AGENTS.md directive or a CI gate tells the AI tool what it must do. The difference is enforcement.
Consider a rule like "never commit code that includes hardcoded credentials." As a wiki page, it depends on developers remembering the rule. As a pre-commit hook that scans for credential patterns, it is enforced automatically. As an AGENTS.md directive that tells the AI agent never to generate hardcoded credentials and to use environment variables instead, it prevents the problem from occurring in the first place.
This layered approach works because it meets developers where they are. The AGENTS.md file and Cursor Rules encode policy as AI context, so the tool itself follows the rules. CI gates catch violations that slip through. Pull request checklists prompt human reviewers to verify compliance. The wiki page still exists for reference, but it is the last line of defense rather than the only one.
Practical examples of workflow-encoded policy include repository-level AGENTS.md files that specify security boundaries, forbidden patterns and required testing approaches; CI pipelines that run static analysis, dependency scanning and credential detection on every commit; and pull request templates with checkboxes for AI-specific review criteria: "I have verified that no customer data was used in AI prompts," "I have reviewed AI-generated code for correct error handling," "Security-sensitive changes have been flagged for security review."
The Azumo SDLC follows the same principle. It is a shared kit of workflows, skills, rules and review checklists, written down once and shared by every engineer, and the same setup loads in Claude Code, Qwen Code, OpenCode and Pi, so the rules do not depend on which agent a developer runs. Agents propose; people approve. Teams can add their own steps and checks, such as an accessibility check, without changing the shared kit.
Rolling Out Policy in Three Phases
Deploying AI tools and policy across an entire engineering organization at once is a recipe for confusion. A phased approach (crawl, walk, run) reduces risk and builds institutional knowledge.
The first phase targets senior engineers who know the system well, working on non-critical tasks. These developers understand the codebase deeply enough to evaluate AI output effectively. They work on internal tools, documentation, test coverage and refactoring, where errors have a smaller blast radius. During this phase, the team refines the policy based on real experience: which rules are too restrictive, which are too lax and which are missing entirely.
The second phase expands to the broader engineering team on production code with full review requirements. The senior engineers from the first phase become mentors and reviewers. The policy is updated based on the patterns and problems found in phase one. CI gates and context files are mature enough to enforce the policy automatically.
The third phase optimizes for velocity. By this point, the organization has enough experience to know where AI assistance is reliable and where it needs extra vigilance. Review requirements can be calibrated to risk rather than applied uniformly. Teams can adopt more autonomous agentic workflows for well-understood problem types while keeping strict oversight for new or security-sensitive work.
Governance for Compliance-Conscious Organizations
For organizations operating under regulatory requirements or serving enterprise clients, AI development policy must connect to formal governance frameworks. Three frameworks are particularly relevant.
ISO/IEC 42001 provides a management system standard for artificial intelligence, covering risk assessment, data governance and organizational controls. It is relevant for organizations that need to demonstrate responsible AI practices to clients or regulators. The NIST AI Risk Management Framework (AI RMF) offers a structured approach to identifying, assessing and mitigating AI-related risks. It is voluntary but widely recognized, particularly in government and defense contexts. SOC 2 audits already cover many relevant controls around data handling, access management and change management. Organizations should map their AI development policies to existing SOC 2 controls and identify gaps.
For outsourcing partners and services firms, demonstrating AI governance increasingly sets them apart. Clients want to know that their code is handled responsibly, that AI tools are not leaking proprietary information and that generated code meets quality and security standards. A documented, enforced AI development policy answers these questions before they are asked.
Keeping the Policy Current
An AI development policy is not a one-time deliverable. The tools change often. Model capabilities evolve. New risks emerge. Review the policy on a regular cadence, ideally quarterly, with input from engineering, security and legal. Version it in source control alongside the code it governs. Treat updates like any other engineering change: propose, review, merge, communicate.
The measure of a good AI development policy is not how comprehensive it is. It is whether developers follow it without thinking about it, because the right behavior is the easy behavior. That happens when the policy is embedded in the tools, enforced by automation and refined by experience.