Naledi Mokoena manages a seven-person customer-support team at a mid-size insurance brokerage. One morning a rep cheerfully showed her a free AI chatbot he had started using to summarize claim emails: paste the customer's message in, get a tidy summary out, reply in half the time. He was proud of it. Naledi felt her stomach drop. Those claim emails contained policy numbers, dates of birth, and medical details, and her rep had been pasting them into a free consumer tool that, for all anyone knew, kept every word to train its next model. Nobody had done anything malicious. Nobody had even known to ask the question. That afternoon Naledi realized that "is this tool okay for my team to use?" was a question she owned, and that she needed to know enough to answer it. This lesson is what she learned.

What This Lesson Covers

You do not need to become a security expert. You need to become an informed manager who knows which questions to ask before letting your team feed company or customer data into an AI tool. This lesson gives you exactly that: where your data goes when you use an AI tool, how to keep sensitive data out of the wrong places, what a handful of important terms (training-data opt-out, data retention, SOC 2, a DPA) actually mean in plain language, the very real risk of "shadow AI" tools nobody approved, and how to build a simple approved-tool list. We follow Naledi as she turns her panic into a calm, repeatable process, and we work through a real vendor checklist scoring two candidate tools. Along the way you will pick up the rest of the manager's toolkit for this work: how access and encryption are supposed to be handled, which regulatory frameworks might apply to your organization, why audit trails and breach notification are not optional, the red flags and green flags to watch for in a vendor conversation, and the standing questionnaire that makes every future evaluation faster than the last.

What Is Actually at Stake

It is tempting to treat this as a paperwork exercise, so it is worth being blunt about what you are protecting. Five things are on the line every time your team adopts a tool. There is data security: are the customer records your team handles genuinely protected once they leave your building? There is regulatory compliance: does this tool expose your organization to violations of the privacy rules that govern your industry? There is liability: if something goes wrong, who is actually responsible, you or the vendor? There is team trust: your own people are asking, quietly, whether their work and their data are being handled properly. And there is vendor dependency: once your team's daily work runs through a tool, are you locked in, and what happens when the price changes or the vendor is acquired?

Naledi's job, and yours, is to ask the hard questions before adoption rather than after a breach. The questions are not difficult. They are simply easy to skip when everyone is in a hurry.

Where Your Data Actually Goes

The single most important thing to understand is this: when someone on your team types into an AI tool, that text usually leaves your building. It travels over the internet to the vendor's servers, where it is processed and, depending on the tool, may be stored and may even be used to train future versions of the model. That is the heart of the risk. The words your rep pasted in are no longer only yours.

Three questions cut to the core of it, and Naledi now asks all three of every tool:

• Where is the data stored? On servers in your country or overseas? This matters because different regions have different legal rules, and some industries restrict where regulated data may live.
• Is the data retained, and for how long? Some tools delete your input after the session. Others keep it. "Keep it" is not automatically wrong, but you must know, and it must be in writing.
• Is your data used to train the model? This is the one that bit Naledi. If a tool trains on your inputs, your confidential text can, in principle, surface in answers given to other users later. You want the ability to turn this off.

Two follow-up questions turn those three from curiosity into control. The first is whether you can direct where your data goes and what happens to it: can you request deletion, can you require that your inputs are not used for model training, and can you verify where the data is being stored? Those are contract questions, not interface questions, and they belong in the service agreement rather than in a support-chat promise. Naledi learned to ask plainly, "Do you retain any of our data, for how long, and for what purpose?" and then to ask for the answer in writing. Cloud vendors also commonly copy data across several regions for redundancy, so "we are hosted in your country" and "your data only ever sits in your country" are not the same sentence.

The second is who else touches your data. Many vendors use subcontractors to run parts of their service. If yours does, you want to know who they are and what security standards they hold to; if the vendor says it shares data with nobody, it is fair to ask what happens to your data if the company is acquired. None of this makes a vendor untrustworthy. It makes the picture complete, which is the only state in which you can make a real decision.

Training-Data Opt-Out: The Setting That Matters Most

A training-data opt-out is a setting or contract term that tells the vendor: do not use what we type into your tool to train your models. This is the difference between a tool that treats your input as a private transaction and one that treats it as free training material. It is often the cleanest, fastest way to make a risky tool acceptable.

Here is the practical landscape, in plain terms. Free consumer versions of many AI tools train on your input by default, and the opt-out may be buried, limited, or absent; this is what Naledi's rep had been using. Paid business and enterprise versions of those same tools very often do not train on your data by default, and say so in their terms. So one of the most effective moves a manager can make costs almost nothing: stop the team from using the free consumer tier for any work data and move them to the business tier, where the data-handling terms are stronger. Naledi's first action was exactly that.

Same tool, same interface, completely different data-handling terms. The free tier may train on your input; the business tier usually does not. For a manager, that one distinction prevents most of the everyday risk.

A Data-Sensitivity Tier System Your Team Can Actually Use

Your reps cannot carry a security policy in their heads while answering customers. They need a simple rule they can apply in two seconds. So Naledi built a three-tier system, wrote it on one slide, and made it the heart of her team's AI guidance. The question for any piece of text becomes: "which tier is this, and is the tool I am about to use approved for that tier?"

• Tier 1, Green, safe to paste into an approved tool: public or non-sensitive material. Marketing copy, public product descriptions, general "how do I phrase this" questions, anything already published. No personal or confidential data.
• Tier 2, Yellow, only in an approved business-tier tool with training opt-out: internal but non-regulated information. Internal process notes, draft team communications, non-sensitive project details. Fine in the company-approved tool, never in a random free one.
• Tier 3, Red, never paste, no exceptions without explicit sign-off: personal or regulated data. Customer names tied to records, dates of birth, policy or account numbers, health details, anything covered by privacy law. This is the tier that nearly burned Naledi.

The power of this system is that it replaces a vague "be careful" with a concrete decision. Her rep's claim emails were obviously Tier 3, and the rule made that instantly clear to everyone, no judgment call required in the moment.

The Few Terms a Manager Needs to Recognize

You will meet a handful of acronyms when you talk to a vendor or your own IT team. You do not need to master them; you need to recognize them and know what to ask. In plain language:

• Data retention: how long the vendor keeps your input after you use the tool. Shorter is generally safer. Ask: "Do you retain our inputs, for how long, and can we shorten or disable it?"
• Training opt-out: covered above, the term that stops your data being used to improve the vendor's model.
• SOC 2: an independent audit of a vendor's security controls (how they protect data, manage access, and respond to incidents). A current SOC 2 Type II report means an outside auditor checked these controls over a period of months, not just on one day. It is reasonable to ask a vendor for theirs; a serious vendor will have one.
• DPA (Data Processing Agreement): a contract that spells out how the vendor will handle data on your behalf, often required when personal data is involved. If your team will ever put personal data through a tool, you want a DPA in place, arranged with your legal team.
• PII (Personally Identifiable Information): any data that identifies a specific person, such as a name, email, address, or ID number. This is the data that triggers most of your Tier 3 rules.

You are not expected to negotiate these yourself. Your job is to recognize when one is needed and to loop in IT or legal before the tool goes live, not after.

Who Can Get In, and Is It Locked

Data handling is one half of the technical picture. The other half is access: who can open the tool, and is the information protected while it moves and while it sits. You do not need to evaluate any of this yourself, but you do need to know that it has been evaluated, because these are the questions your IT colleagues will thank you for having already asked.

On access, the things that matter to a manager are practical. Does the tool support strong passwords, multi-factor authentication, and single sign-on through your company's existing login? Can you control who in your organization has an account, and can you revoke someone's access immediately when they leave the team or the company? Naledi thought about her own turnover: a departing rep who still has a live account on a tool holding customer summaries is a problem she would rather never have. Session behaviour belongs here too. How long before an idle user is logged out, can you set that timeout yourself, and are sessions encrypted while they are open? A shared support desk where someone walks away from a logged-in screen is exactly the case these settings exist for.

Encryption is simply the practice of encoding data so that only authorized parties can read it, and it needs to happen in two places. In transit means while the data travels between your team and the vendor's servers, which should always be over a secure connection; the question to ask is literally "Is data encrypted between our team and your servers?" At rest means while it sits on the vendor's storage. Even a vendor with good intentions is storing your text somewhere, and you want that storage encrypted. It is also fair to ask who controls the encryption keys. Control is the strongest answer; transparency about who holds them is the minimum acceptable one.

The Regulations That Might Apply to You

Which rules govern your team depends on your industry, your location, and the kind of data you touch. Naledi works with insurance claims, so more than one framework applies to her at once. You do not need to become a lawyer; you need to know which names to raise with your own legal team and what each one asks of a vendor.

• GDPR (General Data Protection Regulation) is the European Union's data protection and privacy regulation. It applies if you do business with EU customers or have EU employees. In practice you are asking three things: does the vendor comply, do you have a Data Processing Agreement in place, and can individuals exercise the right to be forgotten by requesting that their data be deleted?
• HIPAA (Health Insurance Portability and Accountability Act) governs medical records and applies if you work in healthcare or handle health information. The questions are whether the tool is HIPAA-compliant, whether the vendor will sign a Business Associate Agreement, and whether they are willing to document their security practices for you.
• SOC 2 Type II is not a law but a security auditing standard many vendors undergo voluntarily. Type II means an independent auditor examined the vendor's security controls over a period of time, typically six months or more, rather than on a single day. Ask whether the vendor has completed an audit, whether they will provide the report during evaluation, and what it actually covers, such as authentication, encryption, uptime, and audit trails.
• CCPA and similar state privacy laws apply if you operate in California, Colorado, or other states with their own privacy statutes. The practical questions are whether the tool meets the state-specific requirements and whether you can export a user's data on request.
• Industry-specific requirements sit on top of the general ones. Finance brings PCI DSS for payment processing. Education brings FERPA for student data. Healthcare brings HIPAA for medical records. The only reliable move is to verify what applies to your organization rather than assuming your industry's headline rule is the whole list.

Naledi did not research all of this alone. She took the list to her legal and compliance colleagues and asked which ones governed her team's data, then wrote the answer down so the next tool evaluation would start from a known baseline rather than from scratch.

Audit Trails: Knowing Who Did What

An audit trail is a record of who did what and when. It is the least glamorous item on this list and one of the most important, because it is what lets you answer a question after the fact instead of guessing. Most enterprise-grade AI tools provide audit logs, and you should be able to see who accessed the tool, when they used it, what they did, and what data they viewed. That record matters for two very different situations: proving compliance to a regulator or auditor, and investigating a suspected misuse inside your own team.

Two properties make logs worth having. They should be immutable, meaning nobody can quietly delete or alter an entry, and they should be retained long enough to be useful. Retention periods vary widely with the regulation involved, anywhere from ninety days to seven years, which is another question for your compliance colleagues rather than a number you should guess. You also want to be able to export the logs, since a compliance review that cannot get the evidence out of the vendor's dashboard is not much of a review.

When Something Goes Wrong

Every vendor will tell you they take security seriously. The useful question is what happens on the worst day. Does the vendor have a security incident response team? Will they notify you within twenty-four hours if your data is compromised? Will they give you forensic detail about what happened, how, and when, or only a vague apology? Naledi wanted the notification commitment specifically, because in her world the clock on telling a customer that their claim data was exposed starts the moment she learns of it.

Ask, too, about breach insurance, about their documented incident response plan, and about whether they conduct penetration testing and independent security audits. Reputable vendors publish an annual transparency or security report detailing breaches, security improvements, and law enforcement requests for data; request one and read it before you sign. It is reasonable to ask who their security officer or chief information security officer is, whether they run regular penetration testing, whether they operate a bug bounty programme that invites outside researchers to find flaws, and whether they have had publicized breaches. A vendor that has had an incident and handled it openly is often a safer bet than one that has never said anything at all.

Shadow AI: The Risk You Cannot See

Shadow AI is any AI tool your team adopts on its own, without approval or oversight, exactly what Naledi's rep had done. It is rarely malicious; it is usually a well-meaning person trying to work faster. But it is dangerous precisely because it is invisible: you cannot assess the risk of a tool you do not know is being used, and you cannot tell your team a safe way to work if half of them are quietly using tools you have never heard of.

The instinct to ban all AI tools backfires. A blanket ban does not stop shadow AI; it drives it further underground, because the work pressure that made people reach for the tool does not disappear. The reliable cure is to remove the reason people go around you: give them a good, approved tool that genuinely helps, make the rules simple, and make it easy to ask "can I use this?" without fear of a lecture. Naledi told her team plainly: "I am not angry that you wanted to work faster. I want to give you a safe way to do it. From now on, ask me before using a new tool, and I promise a fast yes or no." Shadow AI dropped because the safe path became the easy path.

Building an Approved-Tool List

The simplest, most effective governance artifact a manager can maintain is a short approved-tool list: the small set of AI tools your team is cleared to use, and for which data tier. It does not need to be a formal document. Naledi's lived on a single shared page and named, for each tool, what it was approved for and what was off-limits. For example: the company business-tier assistant, approved for Tier 1 and Tier 2 work, never Tier 3 customer records; a specific transcription tool, approved for internal meetings only. Anything not on the list requires a quick check with her before use. The list turns a hundred small daily judgment calls into one clear reference, and it is the backbone of stopping shadow AI without resorting to a ban.

A Worked Example: Scoring Two Tools on a Security Checklist

Naledi needed to choose a summarization tool for her team and had two candidates. Rather than going on reputation, she scored each against a short checklist, rating every item Pass (2 points), Partial (1 point), or Fail (0 points). She used seven questions that map to everything above. Tool A was a popular free consumer chatbot; Tool B was a paid business-tier assistant her company could license.

• Does it offer a training-data opt-out? A: Fail (trains on input on the free tier, 0). B: Pass (no training on business data by default, 2).
• Is data retention disclosed and adjustable? A: Partial (disclosed, not adjustable, 1). B: Pass (disclosed and configurable, 2).
• Current SOC 2 Type II report available? A: Fail (not for the free tier, 0). B: Pass (provided on request, 2).
• Will the vendor sign a DPA? A: Fail (0). B: Pass (2).
• Access controls: MFA and the ability to revoke a leaver's access? A: Partial (basic login only, 1). B: Pass (MFA and admin control, 2).
• Clear breach-notification commitment in writing? A: Fail (0). B: Pass (2).
• Where is data stored, and is it disclosed? A: Fail (undisclosed, 0). B: Pass (named regions, 2).

The scores were not close: Tool A scored 2 out of 14, Tool B scored 14 out of 14. Naledi chose Tool B. But the number was not really the point; the pattern was. Tool A failed on every item that protects customer data, which made it unsafe for anything beyond Tier 1 even though it was free and her rep already liked it. The checklist gave her a defensible answer she could show her director in thirty seconds, and a fair, consistent way to judge the next tool that comes along. She saved the checklist as her team's standard, so every future tool gets scored the same way.

Red Flags and Green Flags in the Vendor Conversation

The checklist scores a tool. The conversation tells you about the company behind it, and the signals are surprisingly consistent. Treat it as a red flag when a vendor refuses to answer security questions, when they claim they are too small to have security practices, when they resist putting any commitment in writing, when they do not offer data protection or encryption at all, or when they will not agree to service level commitments for uptime or incident response. Any one of those is a reason to slow down; two of them together is usually an answer.

The green flags are just as legible. A vendor worth working with provides security documentation and certifications such as SOC 2 or ISO 27001 without a fight, offers a Data Processing Agreement, publishes a security contact and an incident response plan, updates their security practices regularly, and allows audits or provides transparency reports. Naledi noticed that the vendor behind Tool B answered every question on her checklist within a day and volunteered documentation she had not asked for. That behaviour is itself information.

When it comes to the contract, five items are worth insisting on, and your legal team will handle the wording. A service level agreement is a commitment about uptime and performance, typically somewhere between 99.5 and 99.99 percent; a 99.9 percent guarantee means no more than about forty-three minutes of downtime in a month, which is the kind of number worth translating before you accept it. A Data Processing Agreement sets out how your data will be handled, and is often required where personal data is involved. A breach notification clause fixes the timeline for telling you when your data is compromised. A data deletion clause settles what happens to your data if you cancel. And explicit encryption and security commitments pin down the specific practices the vendor will maintain, so that "we take security seriously" becomes something you can point at later.

The Questionnaire You Reuse Every Time

Naledi wrote her scoring checklist once and then went one step further: she wrote a standing list of questions she sends to every vendor before an evaluation even starts. Standardizing it means she compares tools on the same ground instead of on whatever each salesperson chose to volunteer. Her list runs to ten questions:

• Where is data stored, and in which regions or countries?
• Is data encrypted in transit and at rest?
• Do you retain our data after sessions, and if so for how long and why?
• What compliance certifications do you hold, such as SOC 2, ISO 27001, GDPR, or HIPAA?
• Do you offer a Data Processing Agreement?
• What is your incident response plan, and what is your notification timeline?
• Can we request deletion of our data?
• How are access controls managed, and do you support multi-factor authentication and single sign-on?
• Can we audit who accessed our data and when?
• Have there been any public security breaches?

Use the same questions consistently. A serious vendor answers them clearly and quickly. If a vendor cannot, that difficulty is itself the finding, and you should weight it accordingly.

Four Beliefs That Get Managers Into Trouble

Naledi held at least two of these herself before her bad morning, and they are worth naming because each one feels reasonable until you look at it directly.

The first is "everyone uses it, so it must be secure." Popularity is not security. Widely used tools have different security models, different retention policies, and different certifications, and a large user base also makes a larger and more attractive target. The only question that matters is whether the tool meets your organization's standards, not how many other organizations use it.

The second is "the vendor said it is GDPR-compliant, so we are fine." Compliance is not a binary property of a tool. It depends on how you use the tool, how you configure it, and whether the right agreements are in place. A vendor can be entirely GDPR-capable while your team uses it in a non-compliant way. This is a conversation to have with your legal team, not a checkbox to tick.

The third is "we are a small team, so security does not really matter." Breaches do not discriminate by company size, and attackers often target smaller organizations precisely because they assume the defenses are weaker. The practices scale down neatly; the consequences do not.

The fourth is "we signed the contract, so we are protected." A contract allocates liability. It does not prevent a breach. You remain responsible for the data you handle, which means the goal is to choose vendors you actually trust, not vendors whose paperwork gives you someone to blame afterwards.

Three Ways This Goes Wrong in Practice

Beyond the beliefs, there are three habits that reliably undo good intentions.

The first is skipping the security evaluation because you are in a hurry, with a plan to sort it out after launch. It fails because breaches are expensive, disruptive, and corrosive to trust, and because they are far harder to fix once data is already flowing through the system. The fix is to build the security check into the adoption timeline from the beginning. Done with a standing questionnaire and a checklist, it is a week or two of work, not months.

The second is handing the whole thing to IT and forgetting it. IT should absolutely vet the tool, but you are the person accountable for how your team uses it day to day. Work with IT, understand the constraints they identify, then carry those constraints back to your team in language they will actually follow. Naledi's three-tier rule is precisely that translation step.

The third is assuming compliance is the vendor's job. That one deserves its own section, and it gets one next.

Compliance Is Shared, and Your Half Is Real

The most dangerous misconception is "the vendor said they are compliant, so we are covered." Compliance is shared. The vendor's job is to provide a tool capable of being used safely; your job is to actually use it safely. A perfectly compliant, SOC 2-audited, DPA-backed tool becomes a compliance breach the moment a rep pastes Tier 3 health data into a feature it was never approved for. The certifications protect the vendor's side of the line. The data-tier rules, the approved-tool list, and your team's habits protect yours. Naledi keeps this front of mind: choosing a good tool was step one; teaching her team how to use it responsibly was the step that actually closed the risk.

Put This to Work This Week

Security stops being abstract the moment you apply it to your own team, so give yourself four short exercises. Start by drafting your own vendor questionnaire: pick an AI tool you are considering and write the five to ten questions you would actually ask, weighted toward whatever matters most for your industry and your data sensitivity. Naledi's list leans heavily on retention and notification because she handles claims; yours may lean elsewhere.

Then run a risk assessment on your own data. Think about what your team handles every day, and ask what the impact would be if it were exposed. Regulatory violations? Lost customer trust? The answer tells you how strict your evaluations need to be, and it is the difference between a proportionate process and a performative one.

Next, have the conversation with IT. Book fifteen minutes with your IT or security colleagues and ask one question: what are the non-negotiables for any AI tool we adopt, and which certifications or agreements do we require? Write down the answer. That document saves you the same conversation four more times this year.

Finally, build your compliance checklist. Identify the regulatory frameworks that actually apply to your organization, and for each one work out what an AI tool would need in order to satisfy it. Keep that checklist alongside your questionnaire, and every future evaluation starts halfway done.

Before you move on, spend two quiet minutes on a reflection. Think about the data your team handles right now: where does it come from, who should have access to it, and what would happen if it were exposed? Write your answer down. Then pick one AI tool you are using or considering and ask what you would need to know about it to feel genuinely confident it is safe. Those questions are your questionnaire, in your own words, for your own team.

Related Lessons

Evaluating AI Tools for Your Team comes before this one for a reason. It teaches you to judge a tool on capability and fit, which is the question of whether it is any good. Security and compliance is the second half of that judgment: whether a good tool is also safe for your team to use on your data. Neither answer is sufficient alone.

Building a Team AI Tool Evaluation Framework is where the two halves come together. It takes the capability assessment, the fit assessment, and the security checklist you built here and turns them into one repeatable process your team applies to every new tool, so the work you did with Naledi's checklist becomes a permanent asset rather than a one-off effort.

Key Takeaways

• Data leaves the building. When your team types into an AI tool, that text usually goes to the vendor's servers and may be stored or used for training; that movement is the core of the risk you manage.
• Move off the free consumer tier for any work data. The same tool's paid business tier usually does not train on your input; switching tiers is the cheapest, highest-impact security move a manager can make.
• Give the team a three-tier data rule. Green for public, Yellow for internal in an approved tool, Red for personal or regulated data that never gets pasted; a two-second rule beats a long policy nobody reads.
• Recognize the few terms that matter. Retention, training opt-out, SOC 2, DPA, and PII; you do not negotiate them, you recognize when one is needed and bring in IT or legal before launch.
• Cure shadow AI by replacing it, not banning it. A ban drives unapproved tools underground; a good approved tool plus simple rules and a fast, judgment-free yes/no removes the reason people go around you.
• Keep a short approved-tool list. Name each cleared tool and the data tier it is allowed for; it turns a hundred daily judgment calls into one clear reference.
• Know which regulations apply to you, and get vendor coverage in writing. GDPR, HIPAA, CCPA and state privacy laws, PCI DSS, FERPA; verify with legal which ones govern your data rather than assuming, then make sure the vendor agreements cover them.
• Audit trails and breach notification are non-negotiable. You need an immutable, exportable record of who accessed what and when, and a written commitment on how fast the vendor tells you when your data is compromised.
• Security evaluation takes a week or two; breach recovery takes far longer. Build the check into your adoption timeline from the start, because it is much harder to fix once data is already flowing through the system.
• Compliance is shared. A vendor's certifications protect their side of the line; your data rules and team habits protect yours, and a compliant tool used carelessly is still a breach.

Frequently Asked Questions

Isn't security really IT's job, not mine? IT vets the tool's technical security, and you should absolutely involve them. But as the manager, you are accountable for how your team actually uses the tool day to day, what data they put in, which tier it falls in, and whether they reach for unapproved tools. IT can certify that a tool is safe to use; only you can make sure your team uses it safely.

We're a small team. Do we really need all this? Yes, and the lightweight version costs you almost nothing: move off free tiers for work data, write a one-slide three-tier rule, and keep a short approved-tool list. Breaches and privacy violations do not care about headcount, and a single pasted customer record can cause real harm regardless of company size. You are not building an enterprise program; you are putting three simple guardrails in place.

How do I know if a tool trains on our data? Check the tier and the terms. Free consumer versions often train on input by default; paid business and enterprise versions usually do not and will state so in their data-handling terms or documentation. When in doubt, ask the vendor directly: "Do you use our inputs to train your models, and can we opt out?" A clear, confident answer is itself a good sign; evasiveness is a red flag.

What do I do right now if I find someone using an unapproved tool? Stay calm and curious, not punitive; they were almost certainly trying to work faster, not to cause harm. Find out what data they have been putting in, stop any Tier 3 use immediately, and give them an approved alternative the same day so the work does not stall. Then make the safe path easy going forward with an approved-tool list and a standing offer of a fast yes or no, so the next person asks first.