The data policy your team actually needs

Eleven of Kavita's thirty people were pasting customer correspondence into a personal chatbot before any of this began. That is the normal starting position, and it means the policy question is not whether your team uses AI with company data — it is whether they do so with any guidance.

A policy nobody can recall is not a policy. This one fits on a page and can be recited after one reading.

The traffic light

Green — any approved tool. Public information. Internal drafts with no customer, employee, or financial detail. Your own notes, general questions, learning, and code you wrote that contains no secrets.

Amber — approved tools only, configured correctly, and only what the task needs. Customer correspondence with identifiers removed. Internal documents. Unreleased plans. Draft financials. The two settings that make a tool eligible: training on your data switched off, and a retention period you have actually read.

Red — no AI tool, ever. Personal data that identifies someone — names with policy numbers, health information, payment details. Credentials. Anything under a confidentiality obligation to a third party. Anything a regulator expects you to control, which in insurance is a long list.

Then the sentence that makes it usable: when in doubt, treat it as red and ask. Naming who to ask, and making asking safe, is what determines whether the policy is followed or routed around.

The five decisions behind the page

Which tools are approved. Name them specifically. "Approved AI tools" with no list means every tool is approved, and it is how a team ends up with eleven different products and no idea where its data is.

Training and retention. Business and enterprise plans generally do not train on your content by default and consumer ones may. Confirm rather than assume, in writing, and re-confirm when a vendor changes terms.

Personal accounts. The eleven people on personal phones are not doing anything wrong by your current rules, because you have no rules. The workable answer is almost never a ban — it is providing an approved tool that is at least as good, and then the rule sticks because following it costs nothing.

What a human must check. By task, not in general. "AI drafts customer correspondence; the person sending it is accountable for its content" is a rule someone can follow.

Who to ask. One named person. Not a mailbox.

Getting it adopted

Announce it as enabling rather than restricting, because that is what it is: here is what you may now do, with which tools, and here is the short list of what you may not.

Make the approved path the easy one. Every policy competing with a more convenient alternative loses, and shadow usage is a design failure rather than a discipline failure.

Include examples from your actual work — three green, three amber, three red, using real task descriptions. Abstract categories get misapplied in perfectly good faith.

And review it. This field moves; a policy written eighteen months ago names tools that have changed their terms.

The two questions to settle with legal, once

What does our regulator expect? In regulated sectors there is often existing guidance on automated processing, and it usually predates the current wave and applies anyway.

What have we told customers? Your privacy notice makes commitments about how their data is processed and who it is shared with. Sending customer correspondence to a third-party AI vendor is a processing activity, and whether your notice covers it is a question with a factual answer that somebody should have looked up before you deploy.

Neither is a blocker in most cases. Both are considerably cheaper to answer now than after an incident, and asking makes you the manager who checked rather than the one who did not.

Do this today: write your three lists — green, amber, red — with real examples from your team's work. One page. Then send it to whoever owns compliance and ask them to correct it, which is a much easier request than asking them to write it.