Carmen Reyes manages a 14-person marketing team. When her company's legal department published a four-page AI governance framework, she printed it, read it twice, and still could not answer the question her copywriter asked the next morning: "Can I paste our draft press release into an AI tool to tighten it?" The framework spoke in principles like "protect confidential information" and "maintain human oversight." True, but useless at 9 a.m. on a Tuesday. Carmen realized governance was the skeleton; her team needed the muscle. Over the following week she wrote a one-page policy her team could actually use. This chapter walks through how she did it, and how you can write policies for your own team that people read, understand, and follow.

From Governance to Policy

It helps to be clear about the two layers. A governance framework is the broad set of principles the organization sets, usually owned by senior leaders, legal, or a central committee. A policy is the specific, practical rule that tells your team what is allowed, what needs review, and what is off-limits in their daily work. Governance without policy stays abstract. Policy without enforcement is just unenforced rules. Your job as a manager sits squarely in the middle: you translate the org's guardrails into rules your team lives by, and you keep your policies inside those guardrails rather than inventing your own enterprise strategy.

Good policy sets clear expectations, reduces the constant "is this okay?" question, protects the team from real risk, and lets people move quickly within known boundaries. Bad or missing policy produces inconsistent decisions, confusion, and resentment when one person's AI use is waved through and another's is blocked.

There is one more thing policy does that is easy to overlook until you need it. It creates accountability when something goes wrong. If an AI-assisted piece of work causes a problem, a team with a policy can say who was responsible for reviewing it, what the expectation was, and what happens next. A team without one has only opinions and hindsight, which is how a single mistake turns into a search for someone to blame.

Six Principles for Policy That Gets Followed

Carmen kept six principles taped above her desk while she wrote. They are the difference between a policy people use and a document that gathers dust.

• Clarity over comprehensiveness. Write something people will actually read. A clear paragraph beats a 50-page manual. "We use AI to draft, a human reviews and edits every final piece before it goes out, and we do not use AI for decisions about people" is a policy a team can remember.
• Principle-based, not list-based. "We only use tools that are transparent about how they work and do not require uploading sensitive data" adapts as new tools appear. A hard list of approved product names is out of date within a quarter.
• Enable, do not just restrict. Good policy says "yes, but" and "here is how," not only "no." "AI can assist in screening, but a manager reviews every recommendation and any candidate can request human review" enables responsible use instead of driving it underground.
• Risk-based. Match the rigor to the stakes. A writing assistant does not need the same controls as a tool touching customer decisions. Low risk gets a light touch; high risk gets full review.
• Specific, not generic. A policy that could belong to any company guides no one. Name the tools, data, and tasks that are real for your team.
• Enforceable. Only write rules you are actually willing to act on. Three policies you enforce beat ten you ignore, because the ignored ones quietly teach your team that policies are optional.

A Policy Template You Can Reuse

Carmen did not write from a blank page. She used a six-section template, and you can use the same one for any team. Each section answers one question her people kept asking.

1. Approved use cases. What can we use AI for, what needs review, what is off-limits?
2. Data handling. What data is fine to put into a tool, what needs review, what is never allowed?
3. Approval process. What requires sign-off, from whom, and how long does it take?
4. Responsible use guidelines. How do we use approved AI well day to day?
5. Monitoring and escalation. How do we know it is working, and what happens when something goes wrong?
6. Training and accountability. Who is competent to use these tools, and who is responsible when they do?

A Worked Example: Carmen's One-Page Marketing Policy

Here is how Carmen filled in that template for her marketing team. Notice how each section is concrete enough that her copywriter's Tuesday-morning question answers itself.

Section 1, approved use cases. "Approved: drafting copy, summarizing research, brainstorming headlines, and analyzing campaign data. Approved with manager review: anything customer-facing that goes out under the company name without a human edit, and any new tool we have not used before. Prohibited: feeding unreleased product details or customer lists into any external tool, and using AI to generate claims we cannot verify."

Section 2, data handling. "Fine to use: published material, anonymized or aggregated performance numbers, and our own public marketing. Needs review: customer personal data and anything under embargo. Never: passwords, API keys, contracts, or anyone's personal contact details."

Section 3, approval process. Carmen built a simple escalation ladder so people knew the cost of trying something new:

• Auto-approved (security check only): the writing and analytics tools already on our approved list.
• Manager review, about one week: a new AI tool for everyday work, after a quick data-handling check.
• Executive review, two to three weeks: anything that would touch customers directly or make a decision, with a fuller risk review.
• Committee review, three to four weeks: high-risk uses, with a bias check and compliance sign-off.

Section 4, responsible use. "Review every AI output before it leaves your hands. Treat the draft as a starting point, not a finished product. Personalize and fact-check; never ship generic output. If a result feels off in tone or accuracy, rewrite it. Report anything that looks biased."

Section 5, monitoring and escalation. "We spot-check a random 5 percent of AI-assisted work each week for quality. If you spot bias or a factual problem in an AI output, flag it that day. When an incident happens, we pause that use, investigate, fix, and only then resume."

Section 6, training and accountability. "Everyone using AI for client work completes the two-hour Responsible AI for Marketing session. We review what is working at the monthly team meeting. You remain responsible for the quality of anything you ship, AI-assisted or not."

The whole thing fit on one page. When the copywriter asked about the press release, the answer was now obvious: a draft is an approved use, but because it is customer-facing and goes out under the company name, a human edits it before it ships, and embargoed details never go into the tool. Question answered in fifteen seconds, not three meetings.

Four Areas Worth Naming Explicitly

Carmen's six sections cover most teams, but four topics are important enough that burying them inside another section tends to mean they get skipped. Depending on what your team does, write each of these out on its own.

Testing and validation. Say what has to be tested before an AI use goes live. A reasonable baseline: anything customer-facing is tested for accuracy and fairness before launch; any data used to train or tune a model is assessed for quality and representativeness; outputs are spot-checked regularly through random sampling rather than only when someone complains; and anything affecting hiring, service quality, or pricing includes explicit bias testing. Without this section, "we tested it" means whatever the person who built it felt was enough.

Human oversight. Say plainly where human judgment stays mandatory. In practice that usually reads like a short list: every AI-drafted customer response is reviewed and approved by a person before it is sent; every AI hiring recommendation is reviewed by the hiring manager; every AI pricing recommendation is reviewed by the pricing owner; and customers or users can always request human review of a decision that affected them. That last clause is the one people forget, and it is often the one that matters most to the person on the other end.

Transparency and disclosure. Say when you have to tell people that AI is involved. Customers using AI-powered support should know they are talking to AI from the start. Job candidates being evaluated even partly by AI should be notified. Recommendations generated by AI should be labeled as such. And be clear about what transparency actually requires, because teams often over-imagine it: you are not obliged to explain the algorithm, you are obliged to say "this was suggested by AI and a human has reviewed it." That is what builds trust and what most regulatory expectations are reaching for.

Reporting and improvement. Say how people raise concerns and how the policy itself gets better. A quarterly review of incidents, escalations, and near-misses, plus a policy review every six months that folds in what you learned, is enough for most teams. Writing the improvement loop into the policy is what makes it a learning instrument rather than a punitive one.

Two lists are worth being unambiguous about while you are here. On the approved-use side, some things belong in a flat prohibited column rather than a review queue: fully autonomous decisions about hiring, medical care, or criminal justice; bulk surveillance; and anything designed to manipulate people emotionally. On the data side, the never column should name the categories that carry the most harm if they leak: passwords, authentication tokens, and credentials, along with medical records, biometric data, and genetic data. Carmen's marketing team was unlikely to touch most of those, but a team in a regulated setting will, and a policy that leaves them unstated leaves them to individual judgment on a busy afternoon.

Adapting the Template to Different Teams

The same six-section skeleton flexes to fit any team; only the specifics change. Carmen compared notes with two peers.

A product development team kept the template but tuned the sections to code. Approved: code generation, test-case creation, documentation drafts, and review assistance. Reserved for humans: architecture, security, and database design decisions. Data handling: synthetic and anonymized test data are fine, but never production customer data, credentials, or secrets. Their responsible-use section added a hard rule that all AI-generated code is reviewed by a developer, with two-reviewer sign-off for anything touching authentication or access control.

A data and analytics team shaped the same template around analytical rigor. Their data-quality section required a 5 percent human spot-check of anything AI cleaned, and an investigation (not silent acceptance) of any unusual pattern the tool flagged. Their model section required holdout validation and fairness testing for any model affecting people. Their insights section made the key cultural point in one line: AI-discovered insights are starting points, not conclusions, and an analyst still has to understand causation before anything is published.

A customer service team of fifty, using AI to draft responses and piloting a chatbot, filled the same skeleton differently again. Their approved-use section read: "We use AI to draft customer responses, which agents review and personalize before sending. We are piloting a chatbot for routine inquiries, with escalation to a human agent for anything complex. We do not use AI to make decisions about a customer's value or service level." Their responsible-use section told agents to check every draft for accuracy, to personalize rather than send generic output, to rewrite anything whose tone or facts were wrong, and to stay away from AI drafting on genuinely sensitive situations such as complaints unless they were confident in the result. They added a short chatbot section that is easy to overlook: monitor conversation completion and satisfaction, read the full chatbot history before picking up an escalation so the customer does not repeat themselves, treat the bot's work as a starting point for your own judgment, and if a customer arrives confused or upset, apologize and help rather than blaming the tool. Their monitoring section named four measures explicitly, chatbot completion rate, customer satisfaction with AI-drafted responses, fairness across different customer groups, and agent satisfaction with the tool, so that a rise in efficiency could never quietly hide a fall in quality or morale. Escalation was a single line, that suspected bias in AI responses is reported immediately, and training was a two-hour Responsible AI for Customer Service session plus a monthly tip and a quarterly review of what was and was not working.

Five Ways Policies Fail

Carmen had seen each of these fail at other companies, so she designed against them.

Too restrictive to follow. Fear-driven policies that prohibit nearly everything push people into shadow use of unapproved tools, and the real risks then go completely unmanaged. The fix is proportional rules: light touch for low risk, a clear path for trying new things.

Written but never enforced. A beautifully worded rule that nobody audits is worse than no rule, because when something goes wrong you cannot honestly say you had a policy. Pair every policy with an enforcement plan: a quarterly audit of what tools are in use, and a known, humane response when someone steps outside the lines.

Out of step with reality. A policy that demands a two-week approval for a tool a manager needs in two days will be worked around, and your credibility goes with it. Co-create policies with the team: ask how they actually use AI today, what frustrates them, and what rules would genuinely work.

Published without training. Emailing an eight-page document and assuming everyone absorbed it guarantees inconsistent application and "I didn't know that was the rule." Run a short workshop, give a one-page quick reference, practice a scenario or two, and keep a safe channel open for "can I run this by you?"

Frozen in time. A policy written once and never revisited drifts from reality as new tools and risks appear. Treat it as a living document: a quarterly review of incidents and near-misses, an annual deeper look, and version notes recording what changed and why.

Enforcement deserves one more sentence, because managers often write policies without deciding what enforcement actually means. Decide in advance what happens when someone uses AI outside the policy. Is the first response coaching, escalation, or a consequence? And make it safe to report, with a message as plain as "if you notice someone using AI in a way that crosses a line, tell me, and nobody gets punished for raising it." An enforcement plan that people find fair gets you far more compliance than one they find frightening, because the frightening version simply moves the behavior out of sight.

Quick Checkpoints Before You Publish

Before Carmen sent her policy to the team, she ran it through five fast tests, and you should too.

• Clarity test. Hand it to a team member and ask, "What can you do with AI, and what needs approval?" If they have to ask you to explain, it is not clear enough.
• Enforcement test. For each rule, ask whether you would actually act if someone broke it. If not, cut it.
• Completeness test. Does it cover what AI is for, what it is not for, the gray-zone decision, data limits, who approves, what happens when problems occur, and how the policy evolves?
• Reality test. Does it match how the work actually happens, or how you wish it happened?
• Fairness test. Will it be applied consistently across people, with no quiet double standards?

Rolling It Out So It Sticks

A policy only works once people internalize it, and a document sitting in an inbox internalizes nothing. Carmen treated the rollout as its own small project. She ran a 45-minute workshop where she walked through each section with a real example her team recognized, then handed out a one-page quick reference they could pin near their desks. She practiced two gray-zone scenarios aloud: "You want to try a new AI tool a vendor demoed, what do you do?" and "A client wants copy by end of day and you are tempted to ship an AI draft unedited, what is the rule?" Working through those out loud taught more than any paragraph could.

She also opened a safe channel for questions, with an explicit message: "If you are unsure whether something crosses a line, ask me first, and there is no penalty for asking." That single sentence prevented more violations than any threat would have, because the alternative to asking is usually guessing wrong in private. To keep the policy alive she scheduled a five-minute slot in the monthly team meeting for AI tips and a quarterly review of incidents and near-misses, and she kept a short change log so the team could see the policy was living rather than frozen. Within two months, the "is this okay?" pings to her dropped by more than half, not because people stopped caring, but because they finally knew the answer.

Building Fairness and Accountability In

A few responsibilities belong in every team policy. Fairness: any AI that affects people (screening, routing, pricing) needs a bias check, and disparities get escalated, not buried. Transparency: where AI is involved, the people affected should know, and they should have a path to a human if they disagree. Human dignity: AI assists, humans decide, and escalation paths exist for edge cases. Accountability: the policy should name who is responsible when an AI output causes a problem and who is watching for it. Carmen wrote one plain sentence on each. It was enough, because the point of a policy is not to cover every contingency. It is to be clear, fair, enforceable, and actually used.

Terms Worth Keeping Straight

• Policy. A specific rule or guideline governing AI use in a particular area, such as data handling, approvals, or monitoring.
• Escalation framework. Clear rules about what gets escalated, to whom, and what happens next.
• Bias testing. Assessment of whether an AI system treats different groups fairly.
• Risk-based governance. Applying different levels of review and control according to the potential for harm.
• Transparency. Making clear to people when AI is involved and, in broad terms, how it is being used.
• Human oversight. The requirement that a person stays in the decision-making loop rather than rubber-stamping an output.
• Enforcement. Actually following through: audits, accountability, and adjustments, not just publication.

Practice and Reflection

Policies are written by managers who know their own team's reality, which means these exercises only work if you do them about your team rather than in the abstract.

Assess the current state. Document what is actually happening today. Which AI tools are in use, for what purposes, and under what policies if any? Where are the gaps, and what is currently causing friction or confusion? Most managers discover at least one tool in regular use that they did not know about, and that discovery is the real starting point.

Assess the risk. For each tool or use case, place it in one of three bands: low risk, meaning internal productivity work with minimal data; medium risk, meaning it affects business operations and touches some data; and high risk, meaning it affects people, customer decisions, or a regulated domain. The band tells you how much policy detail that area actually needs, which is how you avoid writing a heavyweight rule for a spell-checker.

Draft the core policies. Using the template, write your first pass at approved use cases, data handling, approval process, responsible use guidelines, monitoring and escalation, and training and accountability. Keep it to a page. If it runs longer, you are probably writing a manual rather than a policy.

Refine it with your team. Share the draft and ask four questions directly: do these make sense, are they practical, what is missing, and what would change your thinking? Then actually change the draft based on what you hear. Policies your team helped shape get followed; policies that arrive fully formed get worked around.

Plan the rollout and enforcement. Write down how you will communicate the policy, whether through a workshop, a written summary, or worked examples; how you will enforce it, including audits, the escalation path, and consequences; how you will keep it relevant through quarterly reviews, team feedback, and incident learning; and how people will ask questions, whether through office hours, a channel, or simply you.

Then take two minutes on a smaller reflection. Think about the past week and find one moment where a clear policy would have changed what you or someone on your team did. What would have been different, and what would the outcome have been? That connection between the rule and the real Tuesday morning is what makes policy work stick.

Related Lessons

Policy work sits between the frameworks above it and the practices around it, so several lessons connect directly.

• AI Governance Frameworks supplies the principles your policies implement. If you are unsure where your authority to write a rule ends, that is the lesson that draws the line.
• Risk Management and Escalation goes deeper on the escalation and incident response processes your monitoring section points at, including what happens in the hours after something goes wrong.
• Ethical Leadership in AI Adoption covers the leadership modeling that gives a policy its force, because a rule the manager visibly bends is a rule the team learns to bend.
• Building an AI Roadmap matters because policy development belongs on the roadmap itself, often as an early-phase prerequisite rather than something you write after the tools arrive.
• Building Organizational AI Culture is what makes policies stick. Culture is why people ask before guessing, and no amount of drafting substitutes for it.

Key Takeaways

• Clarity beats comprehensiveness. Write a policy people will read and remember, not a 50-page manual nobody opens.
• Be principle-based, not list-based. Principles adapt as tools change; lists of product names go stale within a quarter.
• Match rigor to risk. Light controls for low-risk uses, full review for high-risk ones. Proportional governance keeps people inside the rules.
• Enable, do not just restrict. "Yes, but here is how" beats a flat "no" and keeps AI use out of the shadows.
• Only write rules you will enforce. Three enforced policies beat ten ignored ones, because ignored rules teach the team that policy is optional.
• Use a reusable template. Approved uses, data handling, approval process, responsible use, monitoring, and training cover any team; only the specifics change.
• Co-create and keep it alive. Policies built with the team and reviewed quarterly fit reality and stay credible far longer than rules handed down once and forgotten.