An AI governance framework template for Australian businesses
Roles, an AI use register, risk tiers, approvals, data rules, vendor checks, incidents and review dates, as tables you can copy, mapped to the six practices.
AI governance is the set of decisions about who may use AI, for what, with which data, and who answers when it goes wrong. In Australia the current reference is the National AI Centre's Guidance for AI Adoption, published October 2025. The template below maps to its six practices and fits a business of 20 to 200 people.
Most businesses already have the first page of this. If you have a one-page AI policy your team actually reads, keep it. That page tells staff the rules. This framework is what the person who owns those rules runs behind it: the register, the risk tiers, who approves what, the vendor questions and the review dates. Every table below is written to be copied into a document or a spreadsheet and filled in. Where the law sits around it, including the Privacy Act change on 10 December 2026, is set out in our guide to AI governance in Australia.
This is general information written by people who build AI systems. It is not legal advice, so have your lawyer read the finished version.
Which Australian AI frameworks does this template follow?
Three government documents carry the same thinking in three generations. You will still meet all three in board papers and procurement questionnaires, so it helps to know which is which.
| Document | Published | What it is | Status in October 2026 |
|---|---|---|---|
| Australia's AI Ethics Principles | 2019 | Eight voluntary principles: wellbeing, human-centred values, fairness, privacy protection and security, reliability and safety, transparency and explainability, contestability, accountability | Still published. The department's page now says the newer guidance evolves them |
| Voluntary AI Safety Standard | September 2024 | Ten guardrails for organisations that develop or deploy AI, from an accountability process through to engaging the people affected | Still published, with a notice that the Guidance for AI Adoption evolves it |
| Guidance for AI Adoption | 21 October 2025. Implementation guidance revised 5 May 2026 | Six essential practices, in two versions: Foundations, for organisations starting out, and Implementation guidance, for teams that build, customise or run higher-risk AI | The current advice from the National AI Centre. Voluntary |
The six practices are: decide who is accountable, understand impacts and plan accordingly, measure and manage risks, share essential information, test and monitor, and maintain human control. If you configure AI inside HubSpot, Microsoft 365 or Google Workspace, Foundations is your document. If you build agents that act on customer data, you are in Implementation territory. Our post on whether the 10 guardrails or the 6 practices apply to you covers that choice in detail.
The National AI Centre also publishes an AI policy guide and template, an AI register template and an AI screening tool alongside the guidance. They are good starting files. What follows is the version we would hand a mid-sized Australian business, with the decisions already filled in where we have a view.
One line on ISO/IEC 42001: it is the international standard for an AI management system, the Implementation guidance is broadly in line with it, and you only need certification if a customer contract asks for it.
How does the framework run, start to finish?
Every AI use goes through the same six steps. The register sits at the centre because every other question gets answered from it.
The dashed path only runs when something goes wrong. The shaded box is the register, which every other step reads from and writes back to.
The template is in nine parts, one for each box plus the people and the vendors. Fill them in order. A business of around 100 people usually finds the first two parts take the longest, because nobody has listed every AI use on a single list before.
Part 1: Who owns AI governance, and who does what?
Write a person's name against every role. A role that belongs to "IT" or "the leadership team" belongs to nobody. In a business under 50 people, one person often holds the first two rows, and that is fine as long as it is written down.
| Role | Who it usually is | What they do | Name |
|---|---|---|---|
| Accountable director | A director or the CEO | Owns the framework, approves high-risk uses, signs off the annual review, takes the call when something goes badly wrong | [name] |
| AI lead | Operations, RevOps or IT lead | Keeps the register, answers new tool requests within two business days, runs the quarterly review | [name] |
| System owner | The manager whose team uses it | One named person for each AI use. Knows what it reads, checks it still works, can turn it off | One per register row |
| Privacy owner | Whoever already handles privacy complaints | Checks any use that touches personal information, keeps the privacy policy honest about automated decisions | [name] |
| Contract owner | Whoever signs supplier agreements | Runs the vendor checks in Part 7 before anything is bought or connected | [name] |
| Users | Everyone with an approved tool | Follow the one-page policy, check output before it leaves, report problems the same day | All staff |
This is practice 1 of the guidance, decide who is accountable, and it is the part buyers' security questionnaires ask about first. The guidance is specific that accountability covers contractors and third-party systems too, so an agent a supplier built for you still needs a system owner on your side.
Part 2: What goes in an AI use register?
One row per use. The same tool can appear on five rows, because Claude drafting a blog post and Claude reading a customer's complaint are different risks. The guidance makes the same point with its own example: an internal chatbot carries a different risk from AI used in hiring or customer decisions, even on the same software.
| Column | What to write | Example row |
|---|---|---|
| Use | What it does, in one sentence a new starter would understand | Summarises sales calls and writes the summary to the HubSpot deal |
| Tool and plan | The product and the plan type, because consumer and business terms differ | Meeting note taker, business plan, connected to HubSpot |
| System owner | One name | Head of Sales |
| Data it reads | Every source, including the ones it reaches through a connector | Call audio, attendee names and emails, deal properties |
| Personal information? | Yes or no, and whose | Yes: prospects and staff |
| Where it is processed | Country or region, from the vendor | United States |
| Decides something about a person? | Yes if it scores, routes, prices, declines or ranks people | No |
| Output goes to | Internal only, the CRM, a customer, the website | The CRM |
| Risk tier | From Part 3 | Medium |
| Approved by and date | From Part 4 | AI lead and privacy owner, [date] |
| Controls | The human check point, logging, test set, how to stop it | Rep reviews the summary before the deal stage changes. Owner can disconnect the integration |
| Next review | A date | [date, three months on] |
Two columns do most of the work. "Decides something about a person" finds the uses the Privacy Act change on 10 December 2026 covers, which we explain in what has to go in your privacy policy from 10 December. Lead scoring is the one that surprises people. "Where it is processed" finds your cross-border disclosures under Australian Privacy Principle 8.
Start the register by asking each team lead what they use, then check the answers against what the business actually pays for and what is connected to your CRM. The second list is always longer than the first.
Part 3: How do you set a risk tier for each AI use?
Three tiers are enough. More than three and people argue about the boundary instead of doing the work. Any single trigger puts a use in that tier, and the highest trigger wins.
| Tier | Triggers (any one is enough) | Typical examples |
|---|---|---|
| Low | Internal output only. No personal information beyond the user's own. A person edits everything before it is used | Drafting internal documents, summarising public research, writing first-draft code that a developer reviews |
| Medium | Reads customer or staff personal information. Writes to the CRM or another system of record. Output reaches a customer, even after a person checks it. Data is processed outside Australia | Call summaries into HubSpot, drafting customer emails, a support assistant that suggests replies to an agent |
| High | Makes or shapes a decision that could significantly affect a person: credit, pricing, eligibility, hiring, who gets contacted or declined. Takes actions that cannot be undone without a person approving each one. Touches health or other sensitive information. Sits inside a regulated process | AI lead scoring that sets lifecycle stage, an agent that sends emails or issues refunds, screening job applications |
| Not permitted | Anything on the never list in your one-page policy, or a use the accountable director has ruled out | Personal AI accounts with customer data, monitoring staff performance with AI |
The high tier triggers come from the same tests we use to decide where a human belongs in the loop: can it be undone, will a customer see it unedited, does being wrong cost more than being slow, and does it decide something about a person. The National AI Centre's screening tool asks similar questions if you want a second opinion on a borderline case.
For every medium and high use, write a short impact note before it is approved: who could be affected, what goes wrong if the output is wrong, and how anyone would notice. Half a page is enough. That note is practice 2 of the guidance, understand impacts and plan accordingly.
Part 4: Who approves an AI use at each tier?
The point of tiers is that most requests get a fast yes. If every request waits for a director, people stop asking and start using whatever they like.
| Tier | Approved by | What they check | Evidence kept | Turnaround |
|---|---|---|---|---|
| Low | AI lead | The tool is on the approved list, on a business plan, and the use stays inside the one-page policy | The register row | Two business days |
| Medium | AI lead and privacy owner | Vendor checks passed, data in the register is complete, the human check point is named, the use can be switched off | Register row, impact note, vendor answers | One to two weeks |
| High | Accountable director, after the privacy owner and AI lead | Everything above, plus a test set run before launch, a tested way to stop or override it, and the privacy policy updated where it decides things about people | All of the above, test results, legal review where needed | Agreed per use |
The two business day figure is the same promise the one-page policy makes to staff, so the framework keeps it. A slow approval process is the most common reason staff go around one.
HubSpot Breeze agents start at medium, because they read your CRM. One that sends, updates records or replies to customers without a person checking first is high. Anything that builds or customises AI, rather than switching on a feature, starts at medium as a minimum. Before a high-tier agent goes live, read how we test an AI agent before it goes near a customer, because the test set is the evidence the approver is signing against.
Part 5: What data can go into which AI tool?
This is the table staff will actually look at, so it needs to be readable in ten seconds. It sorts tools into three kinds and data into six.
| Data | Personal or free AI accounts | Approved business tools (no training on your data) | Purpose-built systems with scoped access |
|---|---|---|---|
| Public information | Yes | Yes | Yes |
| Internal business information | No | Yes | Yes |
| Customer personal information | No | Only tools approved for it in the register, and only what the task needs | Yes, within the scope recorded in the register |
| Material under a client NDA | No | No, unless the client agrees in writing | No, unless the client agrees in writing |
| Employee records, health information, unreleased financials | No | No | No |
| Passwords, API keys, credentials | Never | Never | Never |
The no answers are the same restricted list the one-page policy carries. The "only what the task needs" line comes from the Australian Privacy Principles: APP 6 limits what you can use and disclose personal information for, and a prompt sent to a third-party tool is a disclosure. APP 11 keeps you responsible for securing it once it has left. The OAIC's guidance on privacy and commercially available AI products is the plain-English version.
Two more privacy reads sit behind this table. Privacy Act tranche 2 and your marketing database covers what is likely to change next, and where your data goes when you use AI covers which plans and regions do what. If the tool in question is Claude connected to HubSpot, where your data goes when Claude reads your CRM traces it step by step.
One pattern from our client work is worth copying. Split the data rules by type of tool: free-text tools, where a person types or pastes, get the strict rules above, and purpose-built systems get their own rules written into the register row, because their access is fixed by how they were built. Without the split, a policy either blocks the systems you deliberately built or lets anyone paste anything into a chat window.
Part 6: Where does a human check, and who gets told?
A human check point only counts if someone is named and knows what they are looking for. The one-page policy sets the minimum: a person checks AI output before it goes to a customer, changes a CRM record, goes on the website, or informs a decision about a person. The framework adds what each tier needs on top.
| Tier | Human control | Telling people |
|---|---|---|
| Low | The user edits before using it | Nothing extra |
| Medium | A named role approves before output reaches a customer or a system of record. Spot checks on a sample each month | Tell customers when they are talking to AI. List the vendor in your privacy policy if it stores their personal information |
| High | A person approves every irreversible action. A documented way to override or stop it, used at least once before launch. Logs someone reads | Describe the automated decision in your privacy policy from 10 December 2026. Give people a way to ask for a human review |
This covers practice 4, share essential information, and practice 6, maintain human control. The telling-people column also covers the older contestability principle: if AI significantly affects someone, they need a way to challenge it. If you run agents that take actions, the Australian Cyber Security Centre's May 2026 guidance on careful adoption of agentic AI asks for human control points throughout the agent's workflow, which we unpack in how to secure AI: what the ACSC actually says.
Part 7: What should you ask an AI vendor before you sign?
Ask before anything is bought or connected, and keep the answers with the register row. A vendor that cannot answer these in writing is a vendor that has not thought about them.
| Question | Why it matters | What a good answer looks like |
|---|---|---|
| Do you train models on our data? | Prompts and files can end up in a future model | No, in the contract, with no opt-out you have to remember to set |
| Where is our data processed and stored? | APP 8 cross-border disclosure | Named countries or regions, and the subprocessors in each |
| How long do you keep inputs and outputs, and who can see them? | APP 11 security, and what is exposed in a breach | A stated retention period and a named reason for any human access |
| Is this a business or consumer plan, and is there a data processing agreement? | Consumer terms often allow more use of your data | Business terms with a DPA you can read before signing |
| What independent certifications do you hold? | Saves you auditing them yourself | Current SOC 2 Type II or ISO/IEC 27001 reports you can request |
| How fast will you tell us about an incident? | Your own notification clock starts when you find out | A number of hours, written into the contract |
| Can we export our data and switch it off? | You need a way out that does not lose records | A documented export and deletion on exit |
For smaller vendors that will not hand you their DPA, give them yours. On client governance work we include one clause most older agreements miss: nobody trains an AI model on the client's data without written consent. If you are APRA regulated, CPS 230 turns some of this into obligations; whether your AI vendor is a material service provider under CPS 230 covers the contract terms. If a large customer is about to ask you the same questions, the AI security questionnaire your buyer's CTO is about to send shows what they look like from the other side.
Part 8: What happens when AI gets something wrong?
Write the incident path before you need it. The one-page policy already tells staff to report the same day and promises they will not be in trouble for reporting. This part tells the AI lead what happens next.
| Step | Who | When | What |
|---|---|---|---|
| Report | Whoever notices | The same day | Tell the AI lead what happened, what data was involved and what went out. No blame, including for past use of personal accounts |
| Contain | System owner | Immediately | Stop or disconnect the AI use, revoke any credentials it held, pull back anything still in a queue |
| Assess | AI lead and privacy owner | Within days, and no later than 30 days | Decide whether personal information was involved and whether it is an eligible data breach under the Notifiable Data Breaches scheme |
| Notify | Accountable director | As soon as practicable once it is eligible | Notify affected people and the OAIC where the scheme requires it. Tell affected clients on whatever timeline your contracts promise |
| Fix and record | System owner | Before it is switched back on | Fix the cause, add the case to the test set, update the register row and the tier if it was wrong |
The OAIC's Notifiable Data Breaches pages set out what counts as an eligible breach and the 30-day assessment window. An AI incident is not always a data breach. A wrong answer sent to a customer, an agent stuck in a loop or a tool that went quiet still goes through the same five steps, minus the notification. The last of those is easy to miss; whether you can undo what an AI agent just did is worth reading before you need it.
One from our own work. In October 2026 an AI assistant we use to run client partnerships drafted emails that relied on tasks which had failed earlier in the run, and put an offer into an email before anyone had checked it. A review of the run found both. We changed three things the same day: a failed task is reported straight away, an email only promises what is done or checked, and a person sees the exact wording before it goes into a client's systems.
Part 9: How often should you review AI governance?
Different parts go out of date at different speeds, so give each its own date. Tying them all to one annual review is how an approved tools list ends up naming a product that no longer exists.
| What | How often | Who | Also review when |
|---|---|---|---|
| Approved tools list | Quarterly | AI lead | A vendor changes its terms or plans |
| Register, every row | Quarterly | AI lead with each system owner | A use starts reading new data or acting on its own |
| High-tier uses: test set and logs | Monthly, and after every model change | System owner | Output quality drops or an incident occurs |
| One-page policy | Every six months | AI lead, signed by the director | An incident shows a gap |
| This framework | Annually | Accountable director | The law or the national guidance changes |
Two external dates are already on the calendar. The Privacy Act automated decision rules start on 10 December 2026, and legislation for national AI standards is expected in early 2027, aimed at frontier AI developers. Our read of what that means for businesses that buy AI is in AI safety standards are coming: what changes for buyers.
How does the template map to the six practices and the ten guardrails?
This is the table to hand a board, an auditor or a procurement team that asks what your framework is based on.
| Template part | Guidance for AI Adoption (2025) | Voluntary AI Safety Standard (2024) | AI Ethics Principles (2019) |
|---|---|---|---|
| 1. Roles | 1. Decide who is accountable | 1. Accountability process | Accountability |
| 2. Register | 1. Decide who is accountable, 3. Measure and manage risks | 1. Accountability process, 9. Records | Accountability |
| 3. Risk tiers and impact notes | 2. Understand impacts and plan accordingly, 3. Measure and manage risks | 2. Risk management | Wellbeing, human-centred values, fairness |
| 4. Approvals by tier | 3. Measure and manage risks, 5. Test and monitor | 2. Risk management, 4. Testing | Reliability and safety |
| 5. Data rules | 3. Measure and manage risks | 3. Data governance | Privacy protection and security |
| 6. Human control and telling people | 4. Share essential information, 6. Maintain human control | 5. Human oversight, 6. End-user information, 7. Contestability | Transparency and explainability, contestability |
| 7. Vendor checks | 1. Decide who is accountable (third parties), 4. Share essential information | 8. Supply chain transparency | Privacy protection and security, accountability |
| 8. Incidents | 5. Test and monitor, 6. Maintain human control | 4. Testing, 5. Human oversight | Reliability and safety, contestability |
| 9. Review cadence | 5. Test and monitor | 9. Records, 10. Stakeholder engagement | Accountability |
The mapping is ours. The government documents do not publish a crosswalk in this form, so treat it as a reasonable reading. The Foundations version of the guidance is enough for most businesses that configure AI inside tools they buy. If you build or customise AI, the Implementation guidance asks for more under each practice, and the same nine parts still cover it.
The guardrails and principles are also not a security standard. The Essential Eight does not cover AI either, which we explain in does the Essential Eight cover AI? and in the Essential Eight explained.
How does Neighbourhood govern its own AI?
Our own rules for AI are public. Our AI Security and Governance Overview is version 1.1, effective 8 June 2026, owned by our director Trav White, and reviewed every year or sooner on a material change. It sits beside our Information Security Policy, which binds AI agents acting on our behalf in the same way it binds staff.
- Accountability. A director owns the AI action policy and reviews the queue of actions waiting for approval.
- Tiers for actions. Every agent acting for us runs under a Green, Amber and Red policy. Green actions run and are logged, Amber actions notify a person first, and Red actions, anything risky or irreversible, wait for a person to approve them.
- Data rules. Client data stays in the client's own systems unless an engagement needs otherwise. Agents get credentials scoped to the task, granted per engagement and revoked at the end.
- Vendors. The overview names every AI provider we use, what each is used for and where each processes data, including the parts that run in the United States.
- Incidents. Affected clients are told within 24 hours of a confirmed incident, alongside the statutory notification duties.
On client work we write the governance before the build touches anything sensitive. This year that has meant a short use policy everyone signs, a longer annexe carrying the reasoning for the client's lawyer, a vendor data terms template with a processor register, and a quarterly review of the approved tools list.
The Neighbourhood Trust Centre has the public summary. If you want the same structure built around your own tools, it is part of our AI engineering work.
Frequently asked questions
Is AI governance a legal requirement in Australia? There is no AI Act in force, and the Guidance for AI Adoption is voluntary. Existing law still applies to AI: the Privacy Act, consumer law, anti-discrimination and work health and safety law. From 10 December 2026 your privacy policy must describe automated decisions that could significantly affect people, which is the first dated obligation for most businesses.
What is the difference between an AI policy and an AI governance framework? An AI policy is the one page staff read: approved tools, what never goes into a prompt, when a person checks, who to tell. A framework is what the owner runs behind it: the register, risk tiers, approvals, vendor checks, incident steps and review dates.
Should we follow the 6 practices or the 10 guardrails? The 6 practices in the Guidance for AI Adoption, published 21 October 2025. The department describes them as evolving the 10 guardrails of the 2024 Voluntary AI Safety Standard. Procurement questionnaires still quote the guardrails, so keep a mapping table that answers both.
Who should own AI governance in a mid-sized business? A director should be accountable for it, with an operations, RevOps or IT lead running it day to day. Each AI use also needs its own named owner who knows what it reads and can turn it off.
Do we need ISO/IEC 42001 certification? Only if a customer or contract requires it. ISO/IEC 42001 is the international standard for an AI management system. The Implementation guidance is broadly in line with it, so a business following the six practices is building towards it either way.
Read next
- AI governance in Australia: the 2026 guide
- A one-page AI policy your team will actually use
- The 10 guardrails or the 6 practices: which applies to you
- Where do you put a human in the loop?
- The Privacy Act change on 10 December 2026
- How to secure AI: what the ACSC says
Sources
- National AI Centre, Guidance for AI Adoption, 21 October 2025, Implementation guidance revised 5 May 2026: the six essential practices, in Foundations and Implementation guidance versions, with the AI policy guide and template, AI register template and AI screening tool.
- Department of Industry, Science and Resources, Voluntary AI Safety Standard, September 2024: the ten guardrails, now carrying a notice that the newer guidance evolves it.
- Department of Industry, Science and Resources, Australia's AI Ethics Principles, 2019: the eight principles.
- OAIC, Guidance on privacy and the use of commercially available AI products.
- OAIC, APP guidelines, chapter 8: cross-border disclosure.
- OAIC, Notifiable Data Breaches scheme.
- Australian Signals Directorate's ACSC and partners, Careful adoption of agentic AI services, 1 May 2026.
- NIST, AI Risk Management Framework, the reference many enterprise procurement teams use alongside the Australian guidance.
- Neighbourhood, AI Security and Governance Overview, version 1.1, updated 21 October 2026.
Neighbourhood builds AI systems on Claude for Australian businesses, with the governance written down before the build starts.
Want this framework filled in for your business?
Book 15 minutes and tell us which AI tools your team uses today. We will tell you which uses land in the high tier, which ones the Privacy Act change on 10 December covers, and what your register needs first. Your lawyer still signs it off.