# How to set team AI norms **An AI usage policy** should tell an engineering team which tools are approved, what information may be shared, who owns generated work, when usage must be disclosed, and what review evidence is required. Good team AI norms make safe action easier. They do not rely on vague instructions to use judgment while employees face pressure to move faster. ## Why do teams need explicit norms? Without a shared agreement, each person invents a private policy. One engineer pastes logs into a public assistant. Another refuses all tools because security rules seem unclear. A third uses an agent to draft most of a pull request but does not mention it because they expect ridicule. The team appears aligned until a review or incident reveals incompatible assumptions. Vague enthusiasm is also a policy. When leaders say “use AI everywhere” and reward visible speed, employees learn that caution is unwelcome. Vague prohibition creates a different problem: useful experimentation moves to personal accounts and becomes harder to support. Explicit norms give curiosity a safe path and define genuine boundaries. The aim is not to predict every use. A practical policy provides decision principles, examples, and an escalation route. If a new situation does not fit, employees should know whom to ask and should not be punished for raising the question before acting. ## Which rules belong at company level? Security, privacy, legal, procurement, and customer commitments need consistent organization rules. The company should name approved tools, account requirements, retention settings, restricted information, intellectual property guidance, and incident reporting. A team manager should not improvise exceptions to contractual or regulatory duties. The company should also explain the reason behind major limits. “Never enter production data” is easier to apply when employees understand retention and access risk. Examples should cover source code, logs, customer messages, credentials, employee information, and unreleased strategy. People need to recognize sensitive context even when it is not labeled. Access matters. If the approved option is slow to obtain while a personal tool is immediate, the policy competes with delivery pressure. Provide usable accounts, clear support, and a prompt answer path. Governance that ignores workflow will be bypassed. ## Which rules belong to the team? Teams should define how company boundaries apply to their engineering work. They can identify repositories where agents are suitable, changes that require domain review, expectations for generated tests, disclosure in pull requests, and situations where pairing is required. Local rules should reflect architecture and customer risk. A team that manages identity systems may require stronger review than a team editing an internal dashboard. Different rules are reasonable when the risk is different. Explain the distinction so variation does not look like favoritism or managerial taste. Teams can also agree on social norms. Engineers should be able to question generated code without questioning the author's competence. Authors should not overwhelm reviewers with large unexplained patches. Reviewers should not demand manual work merely to prove skill. These expectations protect trust as much as quality. ## What should the written policy contain? - **Purpose.** Name the problems AI may help solve and the outcomes that matter. - **Approved access.** List tools, accounts, models, and support contacts. - **Data boundaries.** Give concrete examples of permitted and prohibited information. - **Ownership.** State that a named human understands and accepts every output. - **Disclosure.** Explain when reviewers or customers need context about AI use. - **Review.** Match tests, expertise, and release controls to risk. - **Learning.** Provide safe practice, reporting, and a way to share useful patterns. - **Enforcement.** Describe how mistakes, concealment, and repeated violations differ. - **Review date.** Name who updates the policy and when evidence will be considered. Keep the main agreement short enough to use during work. Link to detailed security or legal guidance rather than copying it into a long document nobody can scan. A developer opening a pull request should be able to find the relevant rule in minutes. ## How should data boundaries be explained? | Information | Typical rule | Reason | | --- | --- | --- | | Public documentation | Allowed in approved tools | Already intended for public access | | Private source code | Only approved accounts and settings | Intellectual property and retention risk | | Customer data | Prohibited unless specifically authorized | Privacy and contract obligations | | Credentials | Never enter | Immediate security exposure | | Employee information | Restricted to approved business systems | Privacy, fairness, and access risk | | Incident details | Use sanitized context where approved | May contain secrets and customer information | Actual rules depend on tool terms and company obligations, so managers should not copy a generic table as legal advice. Work with responsible specialists, then translate the approved position into examples the team recognizes. Test understanding with scenarios instead of asking people to confirm that they read a document. ## When should AI use be disclosed? Require disclosure when it changes the information a reviewer needs. A generated implementation, security analysis, customer response, or evaluation summary may need context. A spelling suggestion usually does not. The standard should focus on consequence, not the percentage of words produced by a tool. Define a lightweight format. A pull request note might state that an agent drafted a specific module, the author reviewed all behavior, and named tests were added. This helps review without creating pages of prompt history. More detailed records may be appropriate for regulated or high risk work. Explain that disclosure protects learning. If teams can see where AI was used, they can compare review time, defects, and useful patterns. If disclosure triggers shame, the data becomes unreliable and unsafe usage moves out of sight. ## How do you involve the team without avoiding leadership? Bring a draft with fixed company boundaries clearly marked. Ask team members to identify ambiguous cases, likely workarounds, review pressure, and useful low risk experiments. Include different experience levels and invite private input. People who are cautious often see system risks, while active users know where rules create needless friction. Managers still decide. Consensus may be impossible, and legal constraints are not optional. Explain which suggestions changed the draft, which did not, and why. Participation earns trust when it influences reasoning, not when leaders pretend every choice is open. Run a scenario session before publishing. Discuss an agent that asks for a production log, a generated dependency with an unclear license, a junior engineer unable to explain a patch, and a customer asking whether AI touched their data. Ambiguity discovered in practice is cheaper than ambiguity discovered during an incident. ## How should mistakes be handled? Distinguish a good faith mistake from concealment or reckless disregard. If an employee uses an approved tool but misunderstands a new disclosure rule, correct the work, clarify the policy, and improve the example. If someone knowingly pastes credentials into a prohibited service, normal security and accountability processes apply. Make reporting safe and immediate. Employees should know how to report accidental data sharing or questionable output without first building a defense. Fast reporting can limit harm. A blame heavy response encourages delay, which makes technical and trust consequences worse. Review the system after mistakes. Was the approved tool difficult to access? Did a deadline conflict with the stated standard? Was the rule hidden in a long page? Individual choice matters, but management must remove predictable traps. ## How do norms stay current? Assign an owner and a regular review date. Gather a small set of evidence: workflows attempted, time saved, review effort, quality issues, security questions, and employee feedback. Update rules when evidence supports a change rather than following every product announcement. Retire rules that no longer serve a risk. Excessive controls teach people that governance is ceremonial. Add controls when a new capability or use creates meaningful exposure. Publish changes with examples and allow questions before enforcement. An AI usage policy works when employees can make a sound decision under pressure without guessing what leadership meant. Clear boundaries, human ownership, practical review, and honest learning turn AI norms from a compliance page into part of the team's engineering system. Put the agreement where people already work. A short page linked from the pull request template beats a slide that lives in a leadership folder. Include one example of allowed use, one example that needs disclosure, and one example that must stop. Review those examples in a team meeting and invite a case you did not anticipate. Update the page the same week so the written rule matches the conversation. Check the agreement again after a busy release. Pressure is when hidden workarounds appear. Ask whether anyone skipped disclosure to save time, and treat the answer as a design signal. If the rule only holds when the calendar is quiet, it is not yet a team norm. ## Frequently asked questions ### What should an AI usage policy include? It should cover approved tools, permitted data, prohibited uses, disclosure, human ownership, review standards, incident reporting, learning support, and a review date. ### Should every team use the same AI rules? Company wide security and legal boundaries should be consistent, while teams may add workflow rules based on their systems, customers, and risk. ### How often should an AI usage policy be updated? Review it after meaningful incidents, tool changes, or experiments, and on a regular schedule such as every quarter. The policy should evolve from evidence. ### How should managers enforce AI norms? Make expectations easy to find, provide approved access and training, correct mistakes consistently, and distinguish good faith learning from deliberate concealment or unsafe conduct. ### Should employees help write team AI norms? Yes. Employees closest to the work can identify practical risks and useful workflows. Leaders still own final decisions, especially for security, legal, and customer commitments. Related: [how AI changes the manager's job](https://isilta.com/blog/ai-changes-the-managers-job/), [AI code accountability](https://isilta.com/blog/who-owns-ai-generated-code/), [AI anxiety at work](https://isilta.com/blog/how-to-talk-about-ai-anxiety-at-work/).