Home Services Learning Insights About Contact Start a conversation

AUTOMATION & AI

The Government's AI adoption guidance, translated for a 30-person not-for-profit

The National AI Centre's guidance was not written with a 30-person community services organisation in mind. It still applies to you. Here is what each of the six essential practices means when you have no AI team, no legal counsel, and a board that meets six times a year.

Start from where you actually are

Before the framework, an honest observation. In every small organisation I have looked at, AI adoption had already happened. Not as a project - as individual staff quietly pasting case notes into a chatbot to turn them into a report, or using a meeting transcription tool nobody approved, or letting a fundraising volunteer draft grant applications with a free account.

That is the real starting position. The question is not whether to adopt AI. It is whether the adoption already under way is visible, and whether anyone has assessed what is being sent where. An organisation that believes it has not started is usually the one with the largest unmanaged exposure.

So the first exercise is not a policy. It is a conversation, without blame attached, about what people are already using and why. You will learn more about your risk in that hour than in a month of framework reading.

The framework

The National AI Centre, within the Department of Industry, Science and Resources, published the Guidance for AI Adoption in 2025. It replaced and consolidated the earlier Voluntary AI Safety Standard, condensing ten guardrails into six essential practices. It is voluntary. It is also the most likely reference point if a funder, an insurer, or a regulator ever asks how you govern this.

The six practices, and what each one means at your size:

1. Decide who is accountable

At a large organisation this produces a governance committee. At yours it produces a name. One person - realistically the GM, or whoever holds risk and compliance - is accountable for AI use across the organisation, and that accountability is written into a position description and minuted at board level.

What this is not: a committee, a charter, or a working group. Thirty people do not need a forum. They need to know whose door to knock on before they try something.

2. Understand impacts and plan accordingly

Do a use-case inventory. A single list with one row per AI use, real or proposed, capturing what it does, what data goes into it, who is affected if it is wrong, and whether a person checks the output before it is acted on.

That last column does most of the work. An AI that drafts a newsletter nobody relies on is a different animal from an AI that summarises a client's support needs into a document a support worker acts on. Sort your inventory by "who is harmed if this is wrong" and the priority order writes itself.

For most community services organisations, anything touching client records, incident information, or health data sits at the top and deserves a proper assessment. Anything touching marketing copy sits at the bottom and can be handled by a sentence in a policy.

3. Measure and manage risks

You already have a risk register. Do not build a second one for AI. Add the AI risks to the register you have, in the domains they belong to - privacy, service quality, workforce, reputational - so they get the same review cycle and land in front of the same board.

Separating AI risk into its own artefact is how it becomes a document nobody reads. The risks that will actually bite are ordinary ones: personal information disclosed to a third party, a decision made on inaccurate output, a record that should exist and does not.

4. Share essential information

In plain terms: tell people. Staff should know which tools are approved and which are not, and why. Clients should know if AI is involved in something that affects them. Your board should see AI use in the same reporting they see everything else.

A one-page internal statement covers most of this. It should name the approved tools, state what must never be entered into any AI tool - client identifiers, health information, incident detail, anything you would not email to a stranger - and say who to ask. Anything longer will not be read.

5. Test and monitor

The realistic version at your scale: before a tool goes live, run it on twenty real historical cases and have a competent person check every output. Not a demo, your actual data, your actual edge cases. Then re-check a sample periodically, because the vendor will update the model underneath you without telling you.

That last point catches organisations out. A tool you validated in March is not the same tool in November. Your monitoring commitment should have a frequency attached to it and an owner, like any other control.

6. Maintain human control

For every use case in your inventory, answer one question: can a person override this, and does anyone know how? If a tool triages, prioritises, or drafts anything that reaches a client, a named human signs off before it lands.

The failure to design for here is not a dramatic one. It is drift - a summary that was reviewed carefully in week one and rubber-stamped by week twelve because it has always been fine. Human oversight that is not resourced becomes human oversight in name only, and that is worse than no oversight at all, because it produces a signature.

The record-keeping problem nobody mentions

Here is the one that catches not-for-profits with statutory record-keeping obligations. If an AI tool summarises an incident, or drafts case notes, or produces something that ends up in a client's file, the output is a record. It needs to be retained, it needs to be findable, and you need to be able to say how it was produced.

Tools used outside your own tenancy - a personal chatbot account, a free transcription service - generally leave you unable to answer any of that. This is the single strongest argument for doing AI work inside the Microsoft 365 environment you already control, where the output lands in a system with retention, permissions and an audit trail, rather than in a browser tab belonging to a staff member.

A proportionate starting position

If you do four things this quarter, do these:

  1. Name the accountable person and minute it.
  2. Run the honest conversation about what is already in use, and write the inventory.
  3. Publish a one-page acceptable-use statement naming approved tools and prohibited data.
  4. Add the three or four real AI risks to your existing register with owners and review dates.

That is a defensible position. It is not a mature AI governance framework, and it does not pretend to be. But it is honest, proportionate to your size, and it is a great deal more than most organisations of thirty people can currently show. If a funder asks, you can answer.

The organisations that get into trouble are not the ones that adopted AI without a full framework. They are the ones that adopted it without knowing they had.

Want a second opinion on where your organisation actually sits? Start a conversation - the inventory conversation usually takes an hour and tells you most of what you need to know.