Ingrid is a department manager at a regional insurance company, overseeing a 12-person underwriting operations team. In early spring, her company rolled out an approved AI tool for document summarization. Three months later, she found out that two of her analysts had been using a separate consumer AI tool to draft coverage rationale documents - tools that were not on the approved list and were not covered by the company's data agreements. They were not trying to cause problems. They just found the approved tool clunky. Nobody had told them they couldn't use alternatives. Nobody had told them why. And Ingrid had not thought to ask what tools her team was actually using.

What Governance Actually Means for Managers

Governance - the rules, structures, and accountability systems that determine how AI is used in an organization - is often treated as something that happens above the manager level. Leadership sets policy. Legal approves tools. IT manages access. The manager's job is to comply.

That framing misses something important. The manager is where policy meets practice. Your team makes dozens of small AI decisions every week: which tool to reach for, what data to paste into a prompt, whether to use an AI draft or rewrite it, whether to mention in a meeting that AI helped with a document. None of those decisions shows up in your company's governance policy. They live in your team's habits - and you shape those habits.

This is also why waiting for guidance from above is a losing strategy. In most mid-sized organizations the first real governance work happens at the manager's level, not in the C-suite, and the gap between an executive AI principles memo and the daily question of whether an analyst may paste a claim history into a chatbot is exactly where unapproved tool use spreads. Ingrid's two analysts are the ordinary version of that: nobody malicious, just an unanswered question filled in by whatever was convenient. If your organization already has a Chief AI Officer, a formal AI governance committee, or a trust and safety function, your job is to interface with them competently. If it has none of those, your job is to build the manager-level equivalent, because something will fill the vacuum either way.

AI Governance Frameworks

A governance framework is the set of principles and structures an organization uses to make sure AI is used consistently, accountably, and safely. Most organizations are still building theirs. The major dimensions include: which tools are approved and for what purposes, what categories of data can be processed by external AI systems, who is accountable when AI output is used in a decision, and how errors or concerns are escalated.

As a manager, you do not need to build the framework. You need to understand it well enough to translate it for your team. That means knowing the answers to four questions your team will eventually ask:

1. Which tools can I use, and for what?
2. What data am I not allowed to put into an AI tool?
3. If I use AI to help with something and it turns out to be wrong, who is responsible?
4. If I'm unsure whether something is allowed, who do I ask?

If you cannot answer those questions for your team today, that is a gap. Your organization's governance policy may cover them. If it does not, you need to escalate the question until you get an answer - then document and share it.

It also helps to know the external landscape your organization is probably drawing from, because the framework it adopts sets the vocabulary everyone around you will use. Three come up repeatedly. The NIST AI Risk Management Framework organizes the work into four functions, Govern, Map, Measure, and Manage, and is the common reference point for organizations building risk practice from scratch. ISO/IEC 42001 is a certifiable AI management system standard, which matters when your organization needs to demonstrate its practices to auditors or customers rather than just run them. The EU AI Act takes a different approach, sorting AI uses into tiers, prohibited, high-risk, limited-risk, and minimal-risk, with obligations that scale with the tier. You are not being asked to become an expert in any of them. You are being asked to know which one your organization operates under and to be able to name its top-level controls without looking them up, because that is what lets you translate a corporate requirement into something your underwriting team can actually follow on a Tuesday.

Developing Team and Department Policies

Organizational governance policies are usually written at a level of generality that requires translation. "AI tools may only be used with non-confidential data" is a principle. Your underwriting team needs to know specifically: does that include applicant names? Policy numbers? Claim histories? Premium calculations?

Your job is to write those specifics down for your context. A team-level AI policy does not need to be a legal document. It needs to answer the specific questions your team will face. One to two pages is usually enough.

Ingrid drafts her team policy with three sections. The first lists the approved tools and what they are approved for. The second lists what data cannot go into any AI tool - for her team, that is applicant PII (personally identifiable information, such as names, dates of birth, and policy numbers) and any non-public financial data. The third describes the review expectation: any AI-assisted document must be read and attested to by the person submitting it. That last section exists because Ingrid has watched people forward AI output without reading it. She wants it explicit that the human signature means the human read it.

She shares the draft with her team in a 30-minute meeting, not as a lecture but as a conversation. Two of her analysts immediately flag a gray area she had not considered: they sometimes paste external market reports into AI tools to summarize them. That data is public, but the act of synthesizing it with internal pricing data creates something proprietary. She did not know that workflow existed. The conversation surfaces it, and they decide together how to handle it. The policy gets one more line.

Ingrid's three sections are a good start rather than a finished policy. A complete team-level policy covers six areas, and it is worth checking yours against all of them. Acceptable use names the approved tools and the purposes they are approved for. Data handling states which classes of data, personal information, intellectual property, client material, may enter which tool. Disclosure sets the standard for when you tell a client or a colleague that AI was involved in the work. Human-in-the-loop requirements say which decisions need a named reviewer rather than a general expectation that someone will check. Model and vendor change management covers what happens when your vendor pushes a new model version, because the tool you approved is not necessarily the tool you have next quarter. And incident reporting says what a person does in the first hour after the tool produces something harmful. Ingrid's draft covered the first, second, and fourth of these. The other three were the gaps she had not yet noticed.

One more artifact makes a policy enforceable rather than aspirational: a simple table of who approves what. Write down, for each kind of decision, who is responsible for doing it, who is accountable for the outcome, who must be consulted, and who merely needs to be informed. Adding a new tool, approving a new data class, and signing off on an AI-assisted client document all have different answers, and a policy that leaves those answers implicit will produce exactly the situation Ingrid found herself in, where nobody was wrong because nobody had been made responsible.

Risk Management and Escalation

Risk management sounds like an enterprise function. For a manager, it is simpler: identifying where things are most likely to go wrong before they do, and making sure there is a clear path when they do.

The risks most relevant to a team-level manager fall into three categories. Data risk is the most common - the wrong information gets into an AI tool that is not authorized to process it. Output risk is the second - AI produces something inaccurate, biased, or inappropriate, and someone acts on it without checking. Accountability risk is the third - something goes wrong and it is not clear who is responsible.

For each of your team's core AI use cases, it is worth running a two-minute risk scan: What is the worst thing that could happen here? How likely is it? What would catch it before it causes damage? If the answer to the third question is "nothing" or "it depends on luck," you have a gap.

When the scan stops fitting in your head, write it down as a risk register: a living list of the risks you have identified, each scored for how likely it is and how bad it would be, each with a named owner, a mitigation, and a trigger that says when it gets escalated. A register with eight entries specific to your team's actual AI use is worth more than a polished enterprise document that describes nobody in particular. Two ideas make the scoring honest. Inherent risk is what the tool could do wrong if nothing stood in the way. Residual risk is what remains after your controls are in place, and it is the number that should actually drive your decisions. A risk that looks alarming inherently but is caught reliably by a review step is not the one to lose sleep over; a modest-looking risk with nothing behind it is.

Escalation thresholds deserve the same care. If everything gets escalated, your security counterpart learns to ignore you, and the one incident that mattered arrives buried in noise. Decide in advance what separates a minor quality problem, which your team handles and logs, from a genuine governance incident, which travels upward immediately. Writing that line down before you need it is what makes the difference between a calm escalation and an argument in the middle of a bad week.

Escalation matters as much as prevention. Your team needs to know that bringing a concern to you is the right move, not a sign of incompetence. Ingrid makes this explicit after the unapproved tool situation. She tells her team directly: "If you're not sure whether something is allowed, ask me. If I don't know, I'll find out. That's not weakness - that's how we stay out of trouble."

Ethical Leadership in AI Adoption

The tone your team takes toward AI comes largely from you. If you use AI carelessly, they will. If you skip the verification step because you're busy, they will too. If you treat governance as bureaucratic box-checking, that is what it becomes for them.

Ethical leadership in AI adoption means two things in practice. First, you model the behavior you want. You check AI output before using it. You acknowledge when AI helped with something rather than presenting it as entirely your own thinking. You ask the uncomfortable question - "should we be doing this?" - even when no one else is asking it.

Second, you address workforce anxiety directly. Some of your team members are worried that AI makes them less necessary. That anxiety is real. The response is not false reassurance. It is honest engagement: this is what AI does well, this is where your judgment stays essential, this is how I see your role changing and not changing. People who understand the change can adapt to it. People who do not understand it just feel threatened by it. The distinction that makes this land is specificity: anxiety about displacement is answered by concrete commitments, what you will do, by when, and what you will not do, rather than by reassurances that everything will be fine.

Two further habits round out the ethical side. Treat fairness as a measurable property of the outputs rather than an abstract value you endorse: ask whether the tool's results hold up equally across the kinds of cases and the kinds of people your team handles, and check rather than assume. And prepare for the moments when the policy is simply silent, because they will come, and judgment is all you have. Ingrid's market-report gray area was one of those; nothing in the policy addressed it, and the answer came from asking what could go wrong and deciding openly with the people doing the work. Policy without this kind of leadership produces compliant cynicism, where the rules are followed exactly as far as anyone is watching and no further.

The manager who sets the right tone on AI adoption does not need to be an AI expert. They need to be a consistent example of using AI thoughtfully - and a safe person to come to when the team is unsure.

The Tradeoffs Worth Naming Out Loud

Every governance decision is a tradeoff, and the managers who never name the tradeoff explicitly end up relitigating it every month with whoever is unhappy that week. Four of them come up constantly.

• Speed versus control. Tighter policy slows adoption; looser policy produces preventable incidents. Where you set the dial depends on two things: how bad the worst plausible mistake would be, and how quickly you would catch and correct it. A marketing team drafting internal memos should lean toward speed. A finance team drafting earnings commentary should lean toward control. Ingrid's underwriting work sits closer to the second, which is why her review-and-attest rule is not negotiable.
• Centralized versus federated. One corporate policy is consistent but blind to domain-specific risk. Per-team policies are specific but drift into gaps and contradictions. Most organizations land on a federated model: a corporate floor of things no team may do, with team-specific additions that apply only in your context. Ingrid's PII rule is her ceiling on top of the company's floor.
• Rules versus principles. Rules are easy to enforce and cannot anticipate everything. Principles flex and demand judgment. Strong policies use both: bright-line rules for the highest-risk behaviors, and principles illustrated with examples for the gray zones where a rule would only pretend to help.
• Transparency versus confidentiality. Disclosing AI use builds trust, but it can also reveal competitive detail or bump into contractual commitments. What you need is a disclosure standard that differentiates by stakeholder and by stakes, rather than a single blanket answer that will be wrong half the time.

How the Pieces Fit Together

It helps to see governance as a pipeline rather than four separate obligations. A framework sets the vocabulary and the scope. A policy converts that scope into rules people can follow on an ordinary Tuesday. A risk register tracks what those rules are protecting against and tells you when they have failed. Ethical leadership is what keeps the whole apparatus credible instead of decorative. Managers who implement only the first two build paperwork. Managers who implement all four build trust, and trust is the thing that actually changes what your team does when nobody is watching.

Related Lessons

AI Governance Frameworks goes deeper into the external landscape sketched above, how NIST, ISO/IEC 42001, and the EU AI Act tiering model overlap, where each applies, and what your specific role is inside them as a manager of a team rather than an author of the corporate constitution. The practical output is a one-page mapping of which framework governs your team and why.

Developing Team and Department Policies is the workhorse for the six policy areas covered here, turning general principles into enforceable operational rules. It leaves you with a reusable one-page policy template and the approval matrix that tells everyone who signs off on what.

Risk Management and Escalation builds out the risk register properly, including the inherent-versus-residual distinction and how to calibrate escalation thresholds so the serious cases get attention and the trivial ones do not consume it. The deliverable is a populated register with entries drawn from your team's real AI use.

Ethical Leadership in AI Adoption takes up the human side in depth: setting tone by modeling the policy yourself, meeting displacement anxiety with specific commitments, auditing fairness as a measurable property, and exercising judgment where the policy says nothing. The deliverable is a leadership stance you can articulate to your team in three minutes.

Key Takeaways

• Governance policy meets practice at the manager level. Your team's day-to-day AI habits are shaped more by what you model and what you say than by the policy document your organization publishes.
• Know the four questions your team will ask. Which tools are allowed, what data is off-limits, who is responsible for AI-assisted output, and who to ask when unsure. If you can't answer these, find out.
• Translate organizational policy into team specifics. General principles are not enough. Your team needs to know how the policy applies to the actual work they do with actual data.
• Draft policy with your team, not for them. Sharing a draft policy as a conversation, not a proclamation, surfaces real workflows and gray areas you would not have anticipated alone.
• Run a two-minute risk scan on each core AI use case. What could go wrong, how likely is it, and what catches it before damage happens? If nothing catches it, fix the process.
• Make escalation safe and expected. Your team should know that asking "is this allowed?" is the right instinct, not a sign they are behind on their AI skills.
• Address AI anxiety with honest specificity, not reassurance. Tell your team what changes, what does not, and where their judgment remains essential. Vague reassurance breeds more anxiety, not less.