How to Build an AI Policy for Your Team

Most teams are using AI without a policy. That's not inherently reckless — for small teams or individual users, the risks are manageable. But as AI becomes embedded in daily workflows, as junior staff start reaching for it automatically, and as more sensitive work touches AI tools, the absence of a clear framework creates real exposure.

A good AI policy isn't a 40-page compliance document. It's a clear, practical set of guidelines that your team actually refers to — that answers the questions they're already asking, and gives them the confidence to use AI productively without second-guessing whether they're doing something wrong.

Here's how to build one.

Why Teams Need an AI Policy Now

The two most common arguments against AI policies are "we already have a general technology policy" and "we don't want to slow things down with bureaucracy." Both arguments miss the point.

A general technology policy was written for a world where tools were relatively static and controlled by IT procurement. AI tools are different: they're accessible to individuals without IT involvement, they involve data you put in, and the outputs they produce may carry your organisation's name. The risks are different in kind, not just degree.

As for bureaucracy: a good AI policy removes ambiguity and therefore speeds things up. When people don't know what's permitted, they either ask (slowing things down) or avoid AI entirely (missing the productivity benefits) or use it without boundaries (creating real risk). A clear policy eliminates all three problems.

There's also a data point worth noting: a 2024 survey by Oliver Wyman found that 52% of employees were using AI tools at work without their employer's knowledge. A policy doesn't stop that — but it does channel that usage into safer patterns.

What to Include: The Core Elements

1. Data privacy and input rules

The most critical element of any AI policy is clear guidance on what data can and cannot be entered into AI tools. This needs to be specific, not vague.

What most policies should prohibit from entering public AI tools:

• Personally identifiable information about clients or customers
• Confidential client materials (contracts, financial data, strategies)
• Employee personal data
• Unpublished proprietary information (product roadmaps, unreleased financials)
• Legally privileged information

The positive framing matters: make clear what is permitted, not just what isn't. Internal drafts that contain no sensitive data, publicly available information you're researching and synthesising, your own work you want to refine — all fine.

If your organisation has enterprise agreements with AI providers (Microsoft Copilot, Anthropic Claude for Enterprise), specify which tools have appropriate data handling for more sensitive use cases.

2. Tool approval process

You need a clear, lightweight process for evaluating and approving AI tools. "Lightweight" matters — a process that takes six months to approve a tool will be ignored. A process that takes two weeks and covers basic security and privacy criteria will be used.

At minimum, the evaluation should check: where does user data go, is it used for training, what are the data retention terms, what security certifications does the provider hold. IT and legal should be involved, but the process should have a defined timeline.

3. Output review requirements

AI outputs require human review before being used, published, or shared. This needs to be stated explicitly, because the temptation to send AI-drafted content without review is real — especially under time pressure.

The review requirement should be calibrated to risk. An internal brainstorm draft doesn't need the same rigour as a client-facing proposal or regulatory filing. Your policy should give people a mental model for calibrating the review they apply.

4. Attribution and disclosure

When does AI use need to be disclosed? Internally? To clients? In published work? Norms are evolving, but your policy should take a position rather than leaving it ambiguous. Many organisations are landing on: disclose AI use to clients where material, don't need to specify every tool used for internal drafts, and follow any sector-specific disclosure requirements (which are emerging in legal, finance, and publishing).

Rollout: Making the Policy Stick

A policy that lives in a SharePoint folder that nobody reads isn't a policy — it's liability documentation. For a policy to actually change behaviour, the rollout matters as much as the content.

Involve the people it affects

Bring team leads and power users into the drafting process. People support what they help create. A policy developed by legal and IT and handed down to the team will be resented and ignored. A policy developed with input from the people doing the actual work will reflect real scenarios and feel legitimate.

Make the key points scannable

Most people will never read the full policy document. A one-page summary of the key rules — what you can do, what you can't do, who to ask — is more important than the comprehensive version. Both should exist, but the one-pager is what gets used day-to-day.

Train, don't just publish

A 30-minute team session walking through the policy and answering real questions is worth more than any written document. Use real scenarios. Ask "what would you do if..." Give people a chance to surface the grey areas the policy doesn't fully resolve.

Handling the Grey Areas

No policy covers every situation. The most common grey areas you'll encounter:

Client deliverables: If AI drafts 60% of a report the client pays for, should that be disclosed? Your policy should give clear guidance rather than leaving individuals to guess.

AI-generated images and creative content: Copyright questions around AI-generated images are unresolved in most jurisdictions. Your policy should at minimum acknowledge this and advise caution for commercially sensitive uses.

Personal use on company devices: Where does work use end and personal use begin? If an employee uses ChatGPT on their work laptop to draft a personal email, what are the rules? This is less critical than data security but worth addressing.

Keeping the Policy Current

This is where most AI policies fail. They're written once, published, and never updated — becoming obsolete within months as the AI landscape shifts.

Build a review cadence into the policy itself. Quarterly reviews are appropriate in the current environment — the landscape is changing fast enough that a policy more than six months old is likely to be missing something important.

Assign ownership. Someone needs to be responsible for monitoring developments, flagging when the policy needs updating, and managing the update process. Without a named owner, the policy becomes orphaned.

Create a feedback mechanism. Team members who encounter situations the policy doesn't cover well should have an easy way to flag them — not to expose themselves, but to improve the policy. A shared document where questions can be submitted and answered creates an evolving FAQ that supplements the formal policy.

The Mindset: Enabling, Not Restricting

The framing of your AI policy matters. A policy written in a spirit of restriction — "here's all the things you can't do" — will be resented and worked around. A policy written in a spirit of enablement — "here's how we use AI well, safely, and effectively" — will be embraced.

The goal is a team that uses AI confidently and responsibly. Confidence comes from clarity. Responsibility comes from understanding why the rules exist, not just what they are. Your policy should explain the reasoning, not just the requirements.