AI policy & audit

Your staff are probably already using these tools. The principal's real question isn't what productivity is available — it's how exposed the business is right now.

The audit half

A short, deliberately non-disciplinary look at what's actually happening: which tools, which accounts, which tasks, what's being pasted in. Done as a fact-finding exercise rather than an investigation, because the version where people feel accused produces unreliable answers.

Which tools and tiers are in use, including personal accounts.
Which tasks they're being used on, and which of those touch client material.
What vendors in your existing software stack have quietly added AI features.
Where your current obligations and your current practice don't match.

The policy half

One page, in your words, that answers which tools, which tier, which data, what must be checked, what must be disclosed, and who to ask. Written so the newest casual can follow it, not just the operations manager.

Where this is the right first engagement

Law firms and conveyancers, where staff use is usually unreported and the exposure question comes before any training.
Allied health clinics, where the privacy line is the product and trust on it unlocks everything else.
NDIS providers, where documentation and policy is both the biggest time sink and the first thing an auditor reads.

Not legal advice

We write the operational rule and map it to your obligations. Where a question is properly legal — a specific disclosure duty, an insurer's requirement, a jurisdiction's practice note — it goes to your adviser, and we'll tell you when we've hit that line.

What follows

Usually the training, which lands very differently once there's a written rule to teach against. Sometimes nothing for a quarter, which is a fine outcome.

What the audit actually establishes

Four facts, and most businesses can't currently answer any of them with confidence:

Which tools and which accounts are in use right now — named, and free versus paid, personal versus business.
What categories of information have gone into them. Not "was it confidential", which produces a defensive no, but what the documents were.
Whether any of it is recorded anywhere you could produce if someone asked.
Who decides what's permitted when something new comes up. A name, not a process.

We ask about the work rather than the tool, which is the difference between getting the truth and getting a clean sheet that means nothing. There's more on how that conversation goes in this article.

Where the line ends up

Fine, once the rule names it

Tenders, capability statements and scopes of works
Policies, procedures and position descriptions
Induction and training material
Standard letters explaining a process, with no client in them
Reports written from de-identified inputs
Job ads, inductions and internal summaries

Stays with a qualified person

Clinical judgement and anything diagnostic
Financial advice
Tax positions, as distinct from tax admin
Safety sign-off
Anything needing expertise nobody in the room holds
Any output nobody will check before it leaves

The line on the right doesn't move with the tool, the tier or the vendor. That's what makes the left side safe to teach quickly.

If the honest version of this conversation would go better with the questions coming from outside the business, that is exactly what this engagement is for.

Start an enquiry

What you get, and what it is not

You get: a written picture of current use, a policy short enough that people remember it without looking it up, the never list written in your own documents' terms, and the checking step named with an owner. Usually a page or two, not a manual.

It is not legal advice, and it isn't a compliance certification. Where your obligations turn on professional rules — a practice standard, a court's practice note, a regulator's guidance — we name what needs checking and who should check it, and we'll tell you plainly when something needs a qualified review rather than ours. In clinical settings the privacy content should be reviewed by someone qualified in your field, and we'd rather say that up front than have you discover it later.

Training after this is easier, faster and safer, which is why the two are usually sequenced rather than bundled. See the team workshop for what follows.

The questions we get asked about this

Is a ban not simpler?

Simpler to write, and it fails quietly. The use moves to personal phones, your visibility goes to zero, and the first you hear of it is when something has already gone out. A rule people can follow beats a rule that sounds strict.

What if we find something serious?

You deal with the exposure rather than the person. Which account, roughly when, what kind of information — then the setting gets fixed, the rule gets written, and everyone moves on. Treating it as misconduct guarantees you never hear about the next one.

We already have a policy. Is this worth doing?

Often yes, and it's faster. Most existing policies are either a one-line prohibition or a generic template that doesn't name a single document the business actually produces. Reviewing one is quicker than writing one.

Does the policy need updating as tools change?

The structure doesn't. The vendor-specific answers do, which is why the policy names the tool and the account type in one place where it can be changed, rather than throughout.

Not sure which of these you need first. The assessment asks nine questions and comes back with the modules in the right order for your work — including whether a policy should come before any training. Build your plan.