Priya Venkataraman manages an eight-person customer support team at a healthcare software company. One Tuesday she noticed an analyst pasting a spreadsheet of customer contact details into a free AI chatbot to clean up the formatting. Her stomach dropped. The analyst was not careless or malicious, she was just trying to finish a tedious task faster, and nobody had ever told her which tools were allowed or what data was off limits. That moment taught Priya something every manager learns eventually: if you have not told your team where the lines are, they will draw their own, and in a company that handles patient data, a single wrong guess can become a reportable breach with your name on the incident report.

What This Lesson Covers

Your organization almost certainly has some stance on AI tools, whether it is written down or not. As a manager you have two jobs here. The first is to know that stance and follow it. The second is to make sure your team knows it too, because if they violate it, the responsibility lands on you. This lesson covers the three situations you might find yourself in, where to look for the rules, how to ask when you cannot find them, what to do when no policy exists, and how to advocate for better rules without breaking the current ones.

Why This Matters For You Specifically

Working outside policy is not an abstract compliance issue. It creates problems that land on the manager. Share customer data with an unapproved tool and the breach is your responsibility. Use AI on regulated data without understanding the requirements and the auditor's finding becomes your company's fine. Cut a corner where your team can see it, and they conclude the rules are optional for them too, which is how a careful culture erodes one shortcut at a time. The flip side is just as real. When you know the policy and follow it visibly, you operate safely and legally, you can advise your team with confidence, and you build the kind of trust where people ask you before they guess.

The Three Policy Scenarios

Every manager lands in one of three situations. Knowing which one you are in tells you what to do next.

Scenario 1: A Formal Policy Exists

This looks like written documentation, an approved tool list, clear do's and don'ts, sometimes a training requirement, and some form of monitoring. Your job is straightforward but not optional. Find it, read it carefully, ask about anything unclear, follow it, and make sure your team follows it. When you read it, look specifically for: which tools are approved, which are prohibited, what data can and cannot be shared, how usage is monitored, what the consequences of a violation are, whether there is a request process for new tools, and whether any training is required before use.

Priya's company had exactly this. Approved tools were Microsoft Copilot for licensed employees and a custom internal assistant in pilot. Prohibited were free-tier public chatbots. The data rule was absolute: no employee, customer, or financial information in any external tool. Approved uses were drafting, summarizing, and brainstorming. Not approved were decisions, HR evaluations, and hiring. There was a required "Responsible AI Use" module for managers. The free chatbot her analyst used was on the prohibited list, and the customer data was exactly what the policy forbade. The policy was clear. The problem was that her analyst had never been walked through it.

Scenario 2: An Informal Or Evolving Policy

Here there is no official written policy yet. Leaders are still figuring it out, some teams use AI and others do not, and the guidance you do get is vague, the classic "use good judgment." Your job is to find whatever guidance exists by asking your manager, HR, IT, or leadership directly, understand the current thinking, follow even the informal guidance, and advocate for clarity. Crucially, do not fill the gap with assumptions. Ask the concrete questions: "Is this tool approved? Can we use AI on this kind of data?" Escalate the uncertainty rather than resolving it in your own favor: "We are unclear on AI policy here, can we get guidance?" And document what you decide to do in the meantime so your reasoning is on record.

Scenario 3: No Policy At All

The riskiest scenario looks like the freest. No official guidance, no approved tools, no rules about data, because leadership simply has not addressed it. The trap is assuming that the absence of a "no" amounts to a "yes." It does not. Apply conservative principles as if a sensible policy existed: use only well-established, widely trusted tools, never share employee, customer, or financial data, verify outputs carefully, restrict AI to lower-stakes tasks like drafting and summarizing, never use it for hiring or evaluation or sensitive decisions, keep records of what you use it for, and get explicit approval before putting anything confidential into a tool. Then advocate for an actual policy, stay transparent with your team about how you are approaching it, and be the first to adopt the formal rules once they exist.

Where To Find The Policy, And How To Ask

When Priya went looking for the formal policy she had vaguely heard about, she checked sources in order. HR or People Ops often owns employment and data policies. IT or Security usually owns technology policies and the approved tool list. Compliance handles anything legal or regulatory, which in a healthcare company is most things. Leadership communications sometimes announce policies that never made it into a handbook. Her own manager often knew what had been decided informally. The company intranet held the policy library. And when she still could not find a clear answer, she simply asked.

The asking is a skill worth getting right. Vague questions get vague answers, so Priya asks specific ones: "Does our organization have a policy on AI tool use? Which AI tools are approved for employees? What is the guidance on using AI with customer or employee data? If I want to use a new AI tool, who approves it?" Specific questions also create a paper trail that protects you later.

The Conservative Default: Assume No Unless You Know Yes

If you remember one rule from this lesson, make it this one. The absence of a prohibition is not permission. Policies are very often written after a problem occurs, which means if you are operating in a gap, you may be the problem the future policy gets written to prevent. The conservative default is to assume "no" until you have confirmed "yes." Use well-known tools over niche ones, keep sensitive data out entirely, verify outputs, and document what you are doing. This is not timidity. It is the posture that keeps you and your team out of the incident report.

Worked Vignette: Priya Audits Her Team's Tools

After the spreadsheet incident, Priya did not send an angry email. She ran a simple audit. She wrote down her company's approved list (Microsoft Copilot, the internal assistant in pilot) and the hard data rule (no patient, employee, or financial data in any external tool). Then she asked each of her eight team members, without blame, to list every AI tool they currently used and what they used it for. Here is what came back.

• Three people used Microsoft Copilot to draft internal emails and summarize meeting notes. Approved tool, approved use, no sensitive data. Green.
• Two people used a free public chatbot to rephrase customer-facing replies, pasting in the customer's name and account issue. Prohibited tool, and worse, customer data leaving the company. Red, and the urgent one.
• One person used a free grammar-checking browser extension that quietly sent typed text to an outside server. Nobody had ever classified it, and it was touching support tickets. Unknown, needs a ruling from IT.
• One person used the internal pilot assistant to analyze ticket trends. Approved tool, but she had been pasting in full ticket exports that included patient identifiers, assuming "internal" meant "anything goes." Internal does not mean unrestricted. Amber, a data-governance fix rather than a tool ban.
• One person used no AI tools at all and was quietly worried she was falling behind. Worth a coaching conversation, not a compliance one.

The audit turned a vague anxiety into a concrete action list. For the two red cases, Priya stopped the customer-data leakage that day and showed both analysts how to do the same rephrasing in Copilot without pasting customer details. For the unknown extension, she filed an IT review rather than guessing. For the amber internal-tool case, she clarified that even the approved internal assistant must not receive patient identifiers, which surprised the analyst who genuinely believed "ours" meant "safe." That last case is the one most managers miss, so it deserves its own point.

Internal Tools Still Need Data Governance

"It is our internal AI tool, so I can put anything into it" is one of the most common and dangerous assumptions. Internal does not mean unrestricted. An internal tool still has to follow data governance, security, and privacy practices, and its security is sometimes weaker than a vetted external product, not stronger. The questions to ask about any internal tool are concrete: Who can access the data I put in here? Where is it stored? How is it protected? If the answer is unclear and the data is sensitive, the same conservative default applies. Confirm it is approved for that data before you use it.

Communicate The Policy To Your Team

Knowing the policy yourself is only half your job. If your team does not know it, they cannot follow it, and you are still on the hook when they slip. After her audit, Priya wrote a one-page reference for her team: here are our approved tools, here is what they are for, here is the data that never goes into any external tool, and here is the one rule that covers the rest, "if you want to use something not on this list, ask me first." She walked the team through it in fifteen minutes at a stand-up, explained the why behind each line rather than just the rule, and modeled it herself by talking openly about how she used Copilot. The point is not to police people. It is to make the safe path the obvious path, so nobody has to guess the way her analyst did.

Advocate For Change Through Channels, Not Circumvention

Sometimes a policy really is outdated or wrong. The temptation is to follow "the spirit, not the letter" and quietly do what you think is right. Resist it. Unilateral circumvention creates organizational risk, and you rarely know all the reasons a policy exists. A tool might be banned not because someone is being cautious but because Security found a specific vulnerability they never publicized. If you think a policy should change, advocate formally: document your reasoning, make the business case to the people who own the policy, and follow the current rule until it actually changes. If you genuinely cannot follow it, escalate and ask for clarification, not for permission to break it. Changing the rule the right way protects you; breaking it the convenient way exposes you.

Judgment Checkpoints

As you navigate policy day to day, pause on these questions. Do I actually know the policy, or am I assuming? Am I following it, or rationalizing an exception? Is something unclear that I should ask about rather than guess? Is there a legitimate reason to advocate for change, and am I doing it through the right channel? Is my team following the policy, and am I modeling that or quietly creating exceptions? And before any risky action: what is the real downside if this goes wrong, and is it worth it?

How This Goes Wrong In Practice

Four failure patterns account for most policy trouble, and each of them begins with a sentence that sounds perfectly reasonable when you say it to yourself. It is worth walking through how they typically end.

• "The policy is outdated and I disagree with it, so I will follow the spirit rather than the letter." The usual ending is that you use a tool which seemed entirely fine, there is a data incident, and it turns out the tool was prohibited precisely because Security had found a vulnerability they never publicized. The reasoning you were not told is the reasoning that now makes you liable. Advocate to change the rule, document why, and follow it until it changes. If you truly cannot follow it, escalate and ask for clarification rather than for permission to break it.
• "Nobody has explicitly told us we cannot use this, so it is fine." You are rarely the only person reasoning this way. Ten managers each conclude independently that an unapproved tool is acceptable, and the company ends up with ten tools handling data ten different ways, none of them reviewed. The audit that eventually surfaces that is unpleasant for everyone in the chain. Policies are frequently written after a problem, and operating in the gap makes you a candidate for being that problem.
• "It is our internal tool, so I can put anything into it." Salary records or patient identifiers go into an internal system that turns out to have weaker access controls than the vetted external product, because internal tools are often built quickly and reviewed lightly. When something leaks, "it was our own system" is no comfort to the people whose data it was. Confirm that sensitive data is approved for a given tool, internal or not.
• "I know the policy, my team will work it out." They will work out something, and it may not be the policy. Someone uses a prohibited tool in good faith because they assumed they had flexibility, and the distance between what you knew and what you said becomes the whole incident. You are accountable for your team's compliance whether or not you ever briefed them, so give them a plain reference, tell them why each line exists, and make asking you the easy default.

Practice and Reflection

Policy knowledge is not something you can absorb by reading about it. These prompts take an hour or two and leave you with something usable: a documented understanding of where you stand and what you would tell your team tomorrow.

• Run the policy search. Go and find your organization's AI policy, or establish conclusively that none exists. Note where you found it and how long it took. If it was hard to locate, that is itself a finding worth raising, because your team will have an even harder time.
• Summarize it in one paragraph. Write what the policy actually says in plain language: approved tools, prohibited tools, data restrictions, approved uses, and any training requirement. If you cannot write that paragraph from the document, you have not finished reading it.
• Do a clarity and gap check. Which parts are ambiguous, and which realistic situations does the policy simply not address? For each gap, decide what you would do and, more importantly, who you would ask. Write the question you would send.
• Audit your own compliance. Are you personally following the policy right now, in every tool you use? Is your team? If the honest answer is no anywhere, list what has to change and by when.
• Draft your team communication. Write how you would explain the policy to your team in plain language, in under a page. Then predict the three questions they will ask, and make sure your page answers them before they have to.
• Make a conservative decision. Pick a situation your policy is silent on. What is the most conservative defensible approach, and how would you justify it to your manager or an auditor if asked six months later?
• Build an advocacy case. If you believe a policy should change, sketch the business case: what the current rule costs, what you propose instead, what risk your proposal introduces, and how it would be controlled. Then identify who actually owns the policy, because advocacy aimed at the wrong person is just complaining.

Key Takeaways

• Find your policy before you do anything else. It may be formal, informal, or nonexistent, but you cannot follow rules you have not located. Check HR, IT or Security, Compliance, your manager, leadership communications, and the intranet, then ask directly if you still cannot find it.
• Ask specific questions early. "Which tools are approved, and what data can I put in them?" gets a usable answer where "is AI okay?" does not. Clarity is cheap and a paper trail protects you; mistakes are expensive.
• Default to no unless you know yes. The absence of a prohibition is not permission. When policy is silent or vague, use well-established tools, keep sensitive data out entirely, and document your approach.
• Never put employee, customer, or financial data into an unapproved tool. This is the bright line. In Priya's audit, the customer data leaking into a free chatbot was the one issue she fixed the same day.
• Internal does not mean unrestricted. Even an approved internal tool needs data governance. Ask who can see the data, where it lives, and how it is protected before you trust it with anything sensitive.
• Communicate the policy to your team in plain language. Give them a short reference, explain the why, and make "ask me before you use something new" the simple catch-all. You are responsible for their compliance, so make the safe path the obvious one.
• Advocate through proper channels, never circumvent. If a policy is wrong, make the business case to the people who own it and follow the current rule until it changes. You do not always know the reason behind a rule.
• Model the behavior you expect. Your team watches what you do far more than what you say. Follow the rules visibly and they will too; cut corners and they will learn that corners are there to be cut.