How do I know if my business needs AI governance?

AI governance is the set of decisions about who may use which AI tools, on what data, and who answers for the result.

It is not a framework, a certification or a standing committee. In a business under a few hundred people it is usually three artefacts: a list of approved tools, a short policy saying what staff may and may not put into them, and a named person who owns the topic. Everything beyond that is elaboration you can add when the business needs it.

The reason it gets overcomplicated is that most published guidance is written for enterprises with legal teams and dedicated risk functions. Scaled down, the substance is the same and the paperwork is not. If your governance cannot be explained to a new starter in about ten minutes, it will not be followed, and governance nobody follows is worse than none, because it creates a record of control that does not exist.

The realistic risks are data leaving your control, decisions you cannot explain, and an obligation you did not know you had taken on.

Data first. Staff paste customer records, contracts and pricing into consumer AI tools because those tools are useful and nobody told them not to. Depending on the tier they signed up to, that data may be retained and used for training, and you will not find out through a breach notification, because it is not a breach.

Second, explainability. If an AI-assisted decision affects a customer, a supplier or an employee, you need to be able to say how it was made. Reconstructing that after a complaint is far harder than recording it as you go.

Third, obligations you already carry. Australian privacy obligations do not pause because a tool is new, and client contracts increasingly carry AI clauses. The realistic exposure is rarely a penalty. It is a client asking a question during a renewal that you cannot answer.

Three artefacts and one owner, achievable in about a fortnight of part-time effort by your tech function or MSP.

An approved tool list that names the specific tier or plan, because data handling differs between the free and business versions of the same product. A one-page usage policy staff will actually read. A named owner with the authority to add and remove tools from the list.

Add a register of where AI is used in a customer-facing process, even if it runs to three lines. That register is the thing you will eventually be asked for, and it is the thing almost nobody has.

Deliberately not on the list: a committee, a maturity model, a vendor risk questionnaire for every tool, or a policy longer than two pages. Those belong to a larger business than yours. Starting there is how this work stalls, and a stalled programme leaves you exactly where you started while feeling like progress.

Five things: what staff may use, what they must never input, when AI use must be disclosed, who approves new tools, and what happens when the policy is breached.

Be specific about inputs. An instruction not to enter confidential information is unenforceable, because no two people draw that line in the same place. An instruction not to enter customer records, contracts, pricing, credentials or unreleased financials into any tool outside the approved list is enforceable, because a person can check their own behaviour against it.

Disclosure is the clause most policies miss. Decide whether AI-assisted work needs flagging internally, to clients, or not at all, and write the answer down. Clients increasingly ask, and an inconsistent answer across your team is worse than either policy would have been.

Keep it to two pages, in the language your staff use rather than the language a template uses. Then have it reviewed by someone who will be honest about whether it is followed, not just whether it exists.

Accountability sits with the business, execution sits with your tech function or MSP, and the review should sit with someone independent of both.

The distinction matters. Your MSP can write the policy, configure the tooling and maintain the approved list, and they are often the right people to do it. What they cannot credibly do is assess whether their own configuration is adequate. That is not a criticism of any particular provider. It is the structural problem of marking your own homework, and it applies just as much to an internal team asked to review the thing it built.

So name an owner inside the business, ideally someone who already carries risk or operations, and give them authority to say no to a tool. Have your tech function or MSP implement from a clear brief. Then have the result reviewed independently, on a cycle, by someone with no stake in the answer and no commission riding on which tools you end up using.