Analysts are already using generative AI to write formulas and queries, explain unfamiliar code, summarize results and draft commentary. Much of that is useful. Some of it means confidential figures pasted into tools nobody has reviewed, and AI-drafted numbers reaching a management report without anyone checking them.
A ban rarely works: the use continues, just out of sight. Silence is worse. What works is a short policy, written for the people who will follow it, that makes the safe path the easy one.
Keep it short enough to be read
A policy nobody reads protects nobody. Aim for a page or two that answers five questions: which tools are approved, which data may go where, what must be reviewed, what is logged and how to ask for something new. Write it for an analyst at their desk, not for the legal file, and link to your detailed security standards rather than repeating them. Illustrate each rule with an example from the team’s own work: asking an approved assistant to explain a formula is allowed; pasting a customer list into a free chat tool is not. Examples teach faster than definitions.
Name an owner, usually the head of analytics together with information security, and review the policy every quarter at first. The tools are changing quickly, and a policy that falls behind them will be ignored.
Name the approved tools
List the tools approved for work, and say what approval means: the tool is covered by the organization’s agreements and security review, people sign in with their work identity, and the vendor’s handling of the data has been checked. The list might start with an enterprise AI assistant and the AI features of your analytics platform, such as Copilot in Power BI where it has been enabled. Approval covers a tool and a purpose: an assistant approved for drafting text is not automatically approved for handling customer data.
Everything else, including free consumer chat tools, browser extensions and plug-ins, is not approved for work data. Say so plainly, and explain why: not because these tools are bad, but because nobody has checked where the data goes.
Decide which data may go where
The heart of the policy is a simple grid of data types against tools. Public information can go anywhere. Internal information, meaning anything not intended for publication, stays in approved tools. Confidential information, such as unreleased results, pricing and contracts, belongs in the AI features of the governed analytics platform, where access by role already applies, or in the approved assistant for a registered use with review. Personal and health information stays out of general AI tools entirely and is used only inside the governed platform, for an approved purpose.
When a request mixes types of data, the most sensitive item decides. A question that combines public market data with one customer’s contract terms is confidential.
Review AI-drafted content before it leaves the team
AI drafts; people sign. Inside the team, experiments and drafts are fine. Anything AI-drafted that leaves the team, such as commentary in a management report, a figure in a board pack, a message to a customer or a calculation in a production report, is reviewed by a named person who checks the numbers against the source and owns the result as if they had written it.
The review should look for the ways AI tends to fail: figures that are plausible but unsourced, definitions that differ subtly from the certified ones, and confident statements about causes that the data does not support. Scale the review to the stakes: a figure in a board pack deserves a full check against the certified report, while a first draft of an internal summary needs a careful read.
Log what you will need to explain later
Logging is about being able to answer questions later, not about watching people. Keep three records: a register of approved uses, with the tool, the data involved and the owner; the activity logs your platforms can provide for their AI features; and, for published outputs, the name of the reviewer. Keep these records as long as your other analytics audit records, and avoid storing sensitive prompts that nobody needs.
Tell people what is logged and why. Openness keeps logging from feeling like surveillance, and it makes people more willing to say how they actually use AI, which is exactly what the policy owner needs to know.
Make it easy to ask for a new use
A policy that only says no will be worked around. Offer a short request form: the task, the data involved, the tool, the expected benefit and who will review the output. A small group, typically the analytics lead, information security and privacy when personal data is involved, decides within days rather than months.
Approved uses go on the register and into the grid, often with conditions such as anonymized data or a mandatory reviewer. Declined requests get a reason and, where possible, an alternative. Over time, the register becomes the organization’s map of where AI is creating value.
The bottom line
A good AI use policy is short, specific and revised often. It names the tools, draws clear lines around sensitive data, keeps a person accountable for anything that leaves the team and gives people a quick way to ask for more. That is how analytics teams gain the benefits of generative AI while leaders keep control of their data and its use.