Aisha Mwangi manages a 12-person market research team at a consumer goods company. She did not have a dramatic AI incident. She had a slow drip of small ones. An analyst pasted a client's unreleased survey data into a free chatbot to summarize it. A junior researcher shipped a competitor brief with a confidently invented statistic the AI had hallucinated. A third quietly used AI to write a sensitive client recommendation and never disclosed it. None of these people were reckless. They had no rules, so they each made up their own. Aisha's job was not to catch and punish them. It was to write guidelines clear enough that the right behavior was the obvious one, and then to manage the few who still crossed the line.

What This Lesson Covers

Team AI usage guidelines are the written rules that tell your team what AI use is encouraged, what requires care, and what is off limits. Writing them is half the job. The other half is the harder management work: handling the person who misuses AI after the rules exist. Both are team-level operational leadership, distinct from enterprise policy.

This lesson covers why guidelines beat both bans and free-for-alls, how to structure usable guidelines around a simple risk tier, how to make disclosure the norm, how to handle genuine AI misuse as a performance issue rather than a witch hunt, and how to keep the guidelines alive as the tools change. We follow Aisha from a string of small incidents to a team that polices itself.

It also walks the full drafting process: how to assess what your team actually needs before you write a word, the nine sections a complete set of guidelines covers, how to make each section specific enough to act on, how to build the guidelines with your team rather than at them, how to own and version them over time, and how to scale the approach if you are responsible for more than one team.

Why Guidelines Beat Both Bans and Free-for-Alls

Aisha could have done one of two easy things, and both would have failed. She could have banned AI, which simply pushes usage into the shadows where the unreleased-survey-data incident becomes invisible instead of preventable. Or she could have left it a free-for-all, which is what produced the incidents in the first place. The absence of rules is itself a rule, and it is a bad one.

Guidelines occupy the productive middle. They keep AI in the open, where good use is encouraged and risky use is visible, and they give people a clear standard so the conscientious majority know what right looks like. Most of Aisha's incidents were not defiance. They were people improvising in a vacuum. A clear standard converts most of that improvisation into compliance for free, before any enforcement is needed.

The absence of guidelines is not freedom. It is every person quietly inventing their own rules, and you finding out which ones were wrong only after the damage.

What Written Guidelines Actually Buy You

The mistake underneath Aisha's slow drip was a common managerial assumption: that people will remember conversations and make consistent decisions from them. They will not, and as AI use spreads through a team, the inconsistency compounds and the risk grows with it. Writing things down is how you scale responsibility past the reach of your own attention.

Guidelines buy five things specifically. Consistency, so everyone uses AI the same way rather than twelve ways. Risk management, because a written rule prevents the misuse that a hallway conversation does not. Onboarding, because new people can learn the standard quickly instead of absorbing it by osmosis from whoever sits nearest. Accountability, because expectations that are written down can be held to, and expectations that are not cannot. And continuous improvement, because a written guideline is something you can revise deliberately as the team learns, where an unwritten norm just drifts.

Assess Before You Write

Aisha's first draft was better than it would have been because she spent a week finding out what was actually going on before she wrote anything. Five questions gave her the picture.

Which AI tools does the team use, including the ones nobody has mentioned in a meeting? Which of our processes already involve AI? What good practices already exist, and where are they applied inconsistently? What risks or problems have already emerged, whether or not anyone escalated them? And what does the team itself say it needs guidance on?

That last question is the one managers skip, and it is the most valuable. Do not assume you know. Aisha asked her team directly what guidance would help them use AI better, and the answers reframed her draft. Two people wanted to know whether they were allowed to use AI for client-facing writing at all, a question she had not realized was open. One wanted a rule about what counted as verification, because she had been checking every AI-stated fact against three sources and suspected she was wasting time. The improvisation was not only risky, it was anxious, and people were relieved to be told where the lines were.

Structuring Guidelines Around Risk Tiers

Aisha's guidelines fit on one page, because a policy nobody reads governs nobody. She organized them around three risk tiers, which is far more usable than a long list of specific dos and don'ts that go stale the moment a new tool ships.

Green, encouraged: using AI on non-sensitive tasks with no confidential data, like brainstorming, drafting internal summaries from public sources, or reformatting your own notes. Yellow, use with care and verification: AI for client-facing drafts and any factual claims, with a hard rule that every AI-stated fact gets verified against a real source before it leaves the team, aimed straight at the hallucinated-statistic incident. Red, prohibited: pasting any client or confidential data into a tool without an approved data agreement, and using AI to make a final client recommendation without human judgment and disclosure. The unreleased-survey-data incident was a clear red. By sorting actions into three tiers rather than enumerating every tool, the guidelines stay true even as the specific tools change.

The Nine Sections a Complete Set Covers

The one-page tiers are the front door. Behind them sits a fuller document, and complete guidelines tend to cover nine sections. Aisha's ran to a few pages in the team wiki, with the tiers reproduced at the top.

Purpose and principles. A short statement of what the guidelines are for and what the team believes. Aisha's said that these guidelines help the team use AI responsibly, effectively, and consistently; that AI should enhance human capability rather than replace human judgment; and that the team prioritizes transparency, accuracy, and ethical use. Principles matter because they let people reason about situations the rules did not anticipate.

Approved tools. Which AI tools the team has approved, and the fact that using others requires approval. For each tool, name it, state the approved use cases, and record its security and compliance status. Aisha listed a general-purpose assistant approved for writing, analysis, and brainstorming, and a transcription tool approved for internal interviews under stated conditions.

Use case guidance. For each major use case, whether that is drafting client emails, summarizing interview transcripts, or building competitor briefs, answer seven questions. What is this use case? When is AI appropriate here? When should AI not be used here, meaning what the limits are? How do we verify the output, as an actual review checklist? Who reviews, by role? What data may be put in, given privacy constraints? And how do we document that AI was used? This is the longest section and the one people actually consult.

Data protection. What data is safe to put into AI tools and what is not. Safe: public information and internal non-sensitive work. Not safe: customer or client personal data, financial information, credentials, and proprietary methods. Aisha wrote the unreleased-survey-data case into this section almost verbatim, anonymized, because a real example lands harder than a category.

Quality standards. How the team ensures the quality of AI output: the verification requirement for each use case, who is responsible for verification, the common error types to watch for, and the escalation process when something is wrong. The hallucinated statistic belongs here, as a named error type people are told to expect.

Ethical boundaries. What uses are off limits regardless of convenience. No using AI to make high-stakes decisions about people. No analyzing employee data without consent. No generating deceptive content. No using AI for discriminatory purposes. And a standing instruction that ethical concerns get escalated to the manager rather than resolved privately by whoever noticed.

Transparency and disclosure. When AI use is disclosed. Aisha's rule was that AI assistance in a client deliverable is always disclosed to the client.

Support and escalation. Who to ask when you have a question. Obvious, frequently omitted, and the difference between someone checking and someone guessing.

Evolution and feedback. How the guidelines themselves get improved, which is covered in more detail below.

Making Disclosure the Norm

The quietest incident, the undisclosed AI-written recommendation, pointed to the cultural keystone of any usage policy: disclosure. Aisha set a simple expectation that AI assistance on client deliverables is noted, not hidden. The point is not bureaucratic credit-tracking. It is that hidden AI use is where verification fails and accountability disappears.

She made disclosure safe rather than punitive, which is the only way it sticks. Disclosing that you used AI to draft something was explicitly fine and encouraged; what was not fine was passing AI work off as fully human and unverified. By rewarding honesty instead of punishing AI use itself, she removed the incentive to hide. A team that discloses freely is a team where the manager can actually see where AI is in the workflow, which is the precondition for catching problems early.

Making the Guidelines Actionable

Generic guidance is not guidance. "Review all AI outputs" tells a researcher nothing they did not already know and gives them no way to tell whether they have done it. The actionable version names the work, the criteria, the time, and the person: for client emails, review for factual accuracy, tone appropriateness, and completeness; verification should take two to three minutes per email; a senior researcher reviews before anything goes out. Likewise, "use AI responsibly for writing" becomes: for status updates to leadership, use AI to draft, verify every fact against source documents, and review for tone, which should be confident without overstating, usually about five minutes of review.

Give examples and anti-examples. For each major use case, show what good looks like and what bad looks like, because people calibrate off instances far better than off categories. A good use: a researcher asks AI to brainstorm ten ideas for improving client onboarding, reviews them, keeps three, and brings those to the team. A bad use: a manager asks AI to rank which team members are the highest-risk performers and uses the ranking to decide who goes onto a performance improvement plan. And a short anti-use list, stated flatly: do not use AI to make hiring or firing decisions, to analyze employee communications without consent, or to generate deceptive or synthetic content.

Integrate the guidelines into the workflow. A twenty-page document nobody opens is not a policy, it is a filing exercise. Aisha put a one-page summary in the team's chat channel where it stayed pinned, kept the detailed guidelines in the wiki linked from that summary, added a short checklist to the project tool that had to be completed before submitting AI-assisted work, and used real examples in team meetings so the guidelines stayed a live conversation rather than a document. Guidelines have to be visible where people actually work.

Ownership, Updates, and Version Control

Someone owns the guidelines. Usually the manager, though it can be delegated to a senior team member who has the credibility to make judgment calls. The owner is responsible for four things: keeping the content accurate, updating it as the team learns, answering questions about it, and running the periodic review, quarterly or at least semi-annually.

The update process needs to let guidelines evolve without letting them churn, because rules that change constantly are rules nobody bothers to learn. A workable rhythm has five parts: a quarterly review asking whether this is still accurate and what has been learned; a standing feedback loop so the team can propose changes at any point in the quarter; a clear decision-making rule, where the owner decides with input from the team; a communication step where major changes are announced and minor clarifications simply noted; and version control, so the document moves from 1.0 to 1.1 to 2.0 and people can tell which version they read.

The timeline looks like this in practice. Months one through three run on version 1.0 while feedback accumulates. At month three, review and publish 1.1. Months four through six run on 1.1 with feedback continuing. At month six, a larger revision produces 2.0. And onward, at whatever pace the tools and the team's experience demand.

Building the Guidelines With the Team

Guidelines are most effective when the team helps make them, for the plain reason that people follow rules they helped write. Aisha ran the drafting in six steps.

First, propose an initial framework: tell the team you want to create guidelines for the team's AI use and show them the structure you are proposing, so the conversation starts from something concrete rather than a blank page. Second, gather input: ask which use cases should be covered, what rules the team thinks are needed, and what questions people already have. Third, draft together where you can, involving team members directly in writing sections they know best, and at minimum share the draft for feedback with a genuine invitation: what is missing, and what do you disagree with? Fourth, refine, incorporating the feedback and re-sharing with the changes visible, so people see that their input moved something. Fifth, finalize and launch. Sixth, train and support, because you cannot assume anyone read it. Aisha walked her team through the guidelines in a team meeting, took questions, and worked two live examples.

Performance-Managing Genuine Misuse

Guidelines do not eliminate misuse; they make it identifiable. After the rules existed, one analyst again pasted client data into an unapproved tool, a clear red-tier violation. This is where many managers fail, either ignoring it to avoid conflict or overreacting into a public punishment that scares the whole team back into shadow use. Aisha treated it as an ordinary performance issue, handled the way she would handle any standards lapse.

Her approach had four parts. First, distinguish the cause: was this a knowledge gap, carelessness, or willful disregard? Hers turned out to be carelessness, not defiance, which calls for correction, not a hammer. Second, address it privately and specifically, naming the exact behavior and the exact rule, not a vague "be more careful." Third, make the standard and the consequence clear: the expectation is no client data in unapproved tools, and a repeat would become a documented performance concern. Fourth, document the conversation, which protects both of them if a pattern develops. Handling it privately and proportionately corrected the behavior without terrorizing the rest of the team into hiding their AI use again. The contrast matters: a public overreaction would have undone the disclosure culture she had just built.

Keeping the Guidelines Alive

A static policy decays as fast as the tools. Aisha kept hers current with almost no overhead. She reviewed the one page quarterly, asking the team what had changed and where the rules now felt wrong or unclear, and she updated the tiers as new tools and new failure modes appeared. When a genuinely useful new tool emerged, she added it to the green or yellow tier explicitly, so the guidelines were seen as enabling good AI use, not just forbidding bad use.

She also onboarded new hires on the guidelines in their first week, because the slow drip of incidents always starts with someone who never learned the rules. A living, taught, one-page standard is what turned her team from twelve people improvising into a team that self-corrected, leaving her to handle only the rare real violation rather than a constant stream of small ones.

Scaling Guidelines Across Several Teams

When Aisha's director asked her to help three sibling teams do the same thing, the question became how much to standardize. Three approaches are available, and the right one depends on your organization's structure and culture rather than on any general rule.

Centralized guidelines with local adaptation. You write organizational guidelines, allow each team to adapt them for its context, and run a central review to keep the adaptations consistent. This works where the teams are similar and the risk profile is shared.

Framework plus local ownership. You create a template or framework, each team writes its own guidelines inside it, and learning is shared across teams. This suits teams whose work differs enough that a common rulebook would fit none of them well.

Federated governance. Central, principle-based guidelines cover the things that must not vary, such as ethical boundaries and data protection, while each team writes its own use case guidance, with a regular sync across teams to keep everyone current. This is the middle path and the one most large organizations converge on.

Five Ways Guidelines Fail

Written without team input. You write the guidelines and announce them. The team never bought in, adoption is slow, and the document becomes something people are aware of rather than something they use. Collaborate on creation instead, and let the team shape what they will be held to.

Too vague to act on. "Use AI responsibly. Apply good judgment." Nobody knows what they are actually supposed to do, so everyone continues doing what they were doing. Give specific guidance for specific situations, with named criteria and named reviewers.

Too restrictive to be credible. "Never use AI, it is too risky." Teams ignore guidelines they consider unreasonable, and once they ignore one rule they treat the rest as optional too. Write guidelines that permit responsible use while preventing misuse, which is the whole logic of the tiers.

Left to go stale. Guidelines written two years ago and never touched no longer describe the tools or the work, so the team stops consulting them and starts improvising again, which is where you came in. Review at least quarterly.

No support structure. Here are the guidelines, figure it out. People will have questions, and without somewhere to take them they will either ignore the guidelines or guess. Name the escalation path and the support channel explicitly.

Practice and Reflection

Assess your use cases. List five AI use cases active on your team right now. For each, write down what guidance the team actually needs: when to use AI, how to verify the output, what data may be involved, who reviews.

Sketch the framework. Using the nine sections above, outline the main sections of guidelines for your team. You are not writing the content yet, only deciding what has to be covered and roughly how much of the document each part deserves.

Write one use case in full depth. Choose your most common or highest-risk use case and write the detailed guidance: when to use AI, when not to, how to verify, who reviews, and how long review should take. If you cannot answer the last two, you have found a real gap rather than a documentation gap.

Ask your team. Draft the actual message you would send: you want to create AI guidelines, and what do they think should be covered? Send it, and capture what comes back. Expect at least one question you did not know was open.

Design the evolution plan. Decide how you will update and evolve the guidelines over time. What specifically happens in a quarterly review, who is in the room, and how do changes get communicated and versioned?

Then spend two minutes on this reflection. If you were writing AI guidelines for your team today, what would be the three most important things to cover, and what does your team most need guidance on? Those three things are where your first version should focus, and everything else can wait for version 1.1.

Key Takeaways

• Guidelines beat both bans and free-for-alls. Bans push AI into the shadows; no rules let everyone invent their own. A clear standard keeps usage open and visible.
• Organize around risk tiers, not tool lists. Green-encouraged, yellow-verify, and red-prohibited stays valid as tools change, where a list of specific dos and don'ts goes stale.
• Make disclosure safe and expected. Reward honesty about AI use rather than punishing the use itself, so you can actually see where AI sits in the workflow.
• Treat real misuse as a performance issue. Distinguish gap from carelessness from defiance, address it privately and specifically, set the standard, and document it.
• Do not overreact in public. A public punishment scares the whole team back into hidden use and undoes your disclosure culture.
• Keep the guidelines living. Review quarterly, add useful new tools to the encouraged tiers, and onboard every new hire on the one-page standard.
• Assess before you write. Find out which tools are already in use, which practices are inconsistent, and what the team says it needs guidance on; do not assume you know.
• Be specific enough to act on. Name the review criteria, the reviewer, and the realistic time it takes, because generic instructions change nothing.
• Build the guidelines with the team. People follow rules they helped write, and training on them beats assuming anyone read them.
• Put them where the work happens. A pinned one-page summary, a linked detailed version, and a checklist in the tool people already use beat a document in a folder.
• Name an owner and version the document. Someone maintains accuracy, answers questions, and runs the review, and version numbers tell people whether they have read the current rules.