Your Business Needs an AI Policy. Here's What Actually Belongs in It.

Most AI policies in Australian businesses right now are one of two things. A short, fear-based email from last year that tells people not to put company data into ChatGPT and stops there. Or nothing at all.

Both are useless.

I see this every week. A leadership team that knows it should have something. A document somewhere on SharePoint that nobody has opened since it was approved. A staff that has quietly decided the policy doesn't reflect how the work actually gets done, so they ignore it and use AI anyway.

That is not policy. That is theatre.

Why The Old Policy Already Failed

The first wave of AI policies, written in a panic in 2023 and 2024, almost all made the same mistake. They were defensive. The underlying message was, please don't do anything that could embarrass us.

The result was a list of forbidden behaviours. Don't put customer data in. Don't use it for legal work. Don't rely on it. Don't share output without checking it. The policy as a list of things not to do.

That kind of document does two things. It gives senior leaders something to point to when asked whether they have an AI policy. And it pushes everyone else into using AI privately, on personal accounts, away from any visibility or guardrail. I've written about that pattern before in the piece on shadow AI. The fear-based policy is a leading cause of it.

A policy that drives behaviour underground is worse than no policy. It gives you the illusion of control without any of the substance.

What An AI Policy Is Actually For

For me, the purpose of an AI policy is much simpler than most businesses make it. It exists to answer four questions, clearly, for someone who is about to use an AI tool to do real work.

Can I use this tool, and which one. What can I put into it, and what shouldn't I. What do I need to do with the output before it leaves my desk. And what do I tell the customer or client, if anything.

If your policy doesn't answer those four questions in plain language, it isn't doing the job. Everything else is decoration.

What Belongs Inside It

Here's the short version of what I think a serious AI policy looks like in 2026, based on what I see actually working inside businesses that have moved past the fear stage.

An approved tools list, with a path. Name the tools your team is allowed to use, with the kind of work each one is appropriate for. ChatGPT Enterprise for general drafting. Claude for longer analysis. Copilot inside Microsoft 365. Whatever the stack is. Just as important, name the route to add a new tool. People will want to try things, and pretending otherwise is delusional. A clear approval path beats a quiet rule-break every time.

Data classification, plainly stated. Spell out which categories of data can go into an AI tool and which can't. Customer personal information. Financial data. Legal documents. Pricing or commercial-in-confidence material. Internal HR data. You don't need a thirty-page taxonomy. A one-page guide with a green list, an amber list, and a red list is usually enough. The point is that the person at the keyboard can make a sensible decision in five seconds.

A human-in-the-loop standard. AI output is probability, not truth. Any output that touches a customer, affects a financial decision, or carries any legal weight needs a human reviewer who knows what they're looking at. State that clearly. Some teams formalise this with a sign-off step. Others rely on culture. The mechanism matters less than the expectation being explicit. The reviewer is the safety net, and they need to know they are one.

External disclosure rules. Decide, at the business level, when AI use needs to be disclosed to clients, customers, or partners. A consulting deliverable. A piece of marketing copy. A customer support response. The right answer varies by industry and by contract, but the wrong answer is leaving it to individual judgement with no shared standard. This one will get more important across the next twelve months as client procurement teams start asking the question directly.

A capability expectation. Policy without training is paperwork. Pair the rules with a clear statement that the business expects everyone to build working AI fluency, and back it with real training. I've written about why this matters in detail in the piece on building AI capability. A policy and a capability plan should live next to each other. Each one is half the answer.

A named owner with authority. Someone in the business owns the policy. They can change it. They review it regularly. They are the person other staff escalate to when a grey area shows up. Without that, the policy is an abandoned document, and grey areas become whatever the loudest person in the room decides.

The Quiet Part Most Policies Avoid

There's a section I rarely see in the first draft of an AI policy, and it's usually the most important one.

Where does the data go.

Every closed-source cloud AI tool you let your team use is another vendor sitting between you and your business information. The policy needs to take a position on that. Which vendors are acceptable. What contractual protections you need in place. Whether any work is sensitive enough that it shouldn't go through a third-party model at all.

This is the conversation that connects AI policy to the broader question of renting versus owning your AI. For some businesses, especially in legal, health, finance, or anything dealing with regulated data, the policy needs to allow for the option of running models on infrastructure you control. That feels like a long way from a policy document. It isn't. The decision about where data goes is a policy decision. Pushing it onto IT to figure out later is how policies become unenforceable.

The Policy Isn't The Work

I want to be honest about something. Writing a policy is the easy part. Most businesses can put together a reasonable draft in a couple of weeks if they take it seriously.

The harder part is making it real. Walking it through the team. Pairing it with training people will actually attend. Updating it every time the technology shifts, which is roughly every quarter at the moment. Building a culture where people raise grey areas before they become incidents, instead of after.

The policy is the scaffolding. The capability is the building. You need both, and most businesses are trying to live in the scaffolding.

A Practical 30-Day Starting Point

If your business doesn't have an AI policy yet, or has one that you suspect nobody is using, here's a way to start in the next month.

• Find out what people are already doing. Before you write a single line, talk to staff across three or four functions about how they're using AI today. Personal accounts included. You need the real picture, not the official one. Make it clear nobody is in trouble. You're building a policy that works in their reality, not yours.
• Draft the four answers. Write a one-page version that answers the four questions, in plain English. Which tools, what data, what review, what disclosure. Get it to the point where a new staff member could read it once and know what to do next time they open ChatGPT.
• Pressure-test it on three real scenarios. Pick three situations from the actual work. A sales rep drafting a proposal. A finance analyst summarising a contract. A customer support agent writing a response. Walk each one through the policy and see whether it answers their questions. If it doesn't, fix the policy, not the scenario.
• Pair it with one training cycle. Release the policy alongside a real piece of training, not as a standalone document. A policy people see once during onboarding is furniture. A policy referenced inside live training sticks.
• Set a review date. Pick a date 90 days out and put it in the calendar. That review is non-negotiable. Things will have changed. Your policy needs to reflect them.

What This Looks Like Done Well

The businesses I work with who get this right have something in common. Their AI policy isn't a separate artifact. It sits next to their data policy, their security guidelines, and their brand standards, and it is updated with the same regularity. It is short, specific, and openly debated. It says yes more often than it says no.

Staff can quote it from memory, in rough terms, because they actually use it. Leaders can defend it under questioning from a regulator, a client, or a board, because it reflects how the business genuinely operates. The policy and the practice are the same thing.

For me, that is the bar. A policy nobody can describe is a policy nobody is following. If yours fails that test, the fix isn't a longer document. It's a shorter, sharper one that earns the right to be remembered.

I would massively challenge any leader reading this to look at their current AI policy, if one exists, and ask whether three random staff could explain it back to you accurately. If the answer is no, you don't have a policy. You have a file.

If you'd like help writing a policy that actually fits how your team works, that's part of the work I do through AI consulting and structured business coaching. If you want a quick read on where your business currently stands, the quiz will point you at the right first move in a few minutes.

Frequently Asked Questions

What should a business AI policy actually include?

Six things, at minimum. An approved tools list with a path for adding new ones. Clear data classification, so people know what information can and can't go into an AI tool. A human-in-the-loop standard for AI output that touches customers, finance, or legal. A disclosure rule for when AI is used externally. A capability expectation, so policy and training move together. And a named owner with authority to update the policy as the technology shifts.

Who should write the AI policy in a small or mid-sized business?

Not legal, working alone. A useful policy is written by a small group that includes someone who actually uses AI day-to-day, someone responsible for data and risk, and someone senior enough to make decisions stick. In a smaller business, that might be the founder, an operations lead, and an outside advisor. Legal review at the end is sensible. Legal driving it from the start almost guarantees a document people ignore.

How often should an AI policy be updated?

Treat the first version as a 90-day draft, not a final document. AI tools, vendor terms, and what your team is actually doing will all shift inside a quarter. After the first review, every six months is a reasonable cadence, with a flagged update any time a major new tool is introduced or a significant incident occurs. A policy that hasn't been touched in a year is almost certainly stale.

Do I need separate AI policies for different teams?

One central policy is usually enough, with practical guidance layered underneath for teams whose AI use is genuinely different. Marketing, sales, finance, and customer support all have different risk profiles, but the underlying rules around data, disclosure, and review are largely the same. The mistake is writing a separate policy for each team and ending up with contradictions nobody notices until something breaks.

Is a template AI policy enough for my business?

A template is a starting point. It is not a finished policy. The parts that actually matter are the ones specific to your business. Which tools are approved, what data you handle, what your customers expect, who owns it inside your team. Templates get those parts generically wrong because they have to. A policy that nobody can name three real-world examples from in their own business isn't being used.