Australia's Guidance for AI Adoption: the six essential practices explained

What is the Guidance for AI Adoption?

The Guidance for AI Adoption is the Australian Government’s voluntary framework of six essential practices for using and building AI responsibly, published by the National AI Centre (NAIC) on 21 October 2025. It is the current answer to “what does good AI governance look like in Australia?” You may see the six practices called “AI6” for short; the official title is the Guidance for AI Adoption.

It didn’t appear from nowhere. The Department of Industry, Science and Resources says it “evolves” both the 2024 Voluntary AI Safety Standard and the 2019 AI Ethics Principles. The National AI Plan of 2 December 2025 then said the six practices will underpin new NAIC tools and resources, describing them as a coherent framework adaptable to different audiences. There is no Australian AI Act, so this guidance is the closest thing to a national standard. See is there an AI Act in Australia for the wider legal picture.

What happened to the Voluntary AI Safety Standard?

The Voluntary AI Safety Standard (VAISS), published in September 2024 with 10 voluntary AI guardrails, is still available but is no longer the recommended starting point; the Guidance for AI Adoption evolves it into six practices. The timeline below shows how the Australian Government’s AI guidance has changed.

Date	Publication	Status in September 2026
7 November 2019	Australia’s AI Ethics Principles (8 principles)	Still published; the values the practices align with
5 September 2024	Voluntary AI Safety Standard (10 guardrails)	Still published for reference; superseded as the starting point
21 October 2025	Guidance for AI Adoption (6 essential practices), foundations and implementation versions	Current
2 December 2025	National AI Plan says the six practices will underpin new NAIC tools and resources	Current policy
5 May 2026	Implementation guidance on ai.gov.au shows this publication date	Current

If you built a governance process around the 10 guardrails, you haven’t wasted the effort. The six practices cover the same ground with less repetition, and the table further down shows where each guardrail landed.

Foundations or implementation guidance?

Choose by what you do with AI, not by company size. The NAIC publishes two versions of the same six practices.

	Foundations	Implementation guidance
Written for	Organisations starting out, low-risk use, new to AI governance	Teams that build or customise AI, complex use, higher-risk use cases
Structure	”Getting started” and “next steps” actions per practice	Numbered, detailed actions (for example 4.1.1), some tagged by role
Role tags	None	DEV (developers), DEP (deployers), GPAI (general-purpose AI)
Typical user	A firm rolling out Microsoft Copilot or a chatbot tool	A company building an AI product or using AI in hiring, lending or claims

The guidance makes a point worth repeating: the same tool can carry very different risks depending on use. Using AI to draft marketing emails is not the same as using it to assess job applications, so assess each use case, not each product.

The six practices, translated into engineering work

Each practice produces concrete artefacts. The table below lists what a software team would typically build or maintain for each one. The action numbers refer to the implementation guidance.

1. Decide who is accountable

The guidance asks organisations to name accountable people for the AI management system and for each AI system, clarify responsibilities across the AI supply chain, and train people for their roles. For engineering, that means an owner field on every AI component, a documented split of responsibilities between you, your model provider and your customers, and release approval by a named person. Action 1.2.2 asks developers to document their obligations to downstream organisations, including changes to models and expected behaviour.

2. Understand impacts and plan accordingly

Identify who an AI system affects, including vulnerable groups, and give them a way to raise concerns and challenge outcomes. Action 2.2.2 asks for system-level mechanisms that let people understand, challenge and appeal AI decisions, available at the right point in the interaction. In a product, that is a visible “question this result” path, a reason shown with each outcome, and a queue where a human picks up the challenge.

3. Measure and manage risks

Set risk tolerance, assess each use case, apply controls and handle incidents. The foundations version starts with a risk screening process to flag unacceptable or high-attention uses. Engineering contributes the threat model: prompt injection, data leakage, tool misuse by agents, and failure under unexpected inputs. Action 3.1.3 suggests data sheets, model cards or system cards to report risk outcomes.

4. Share essential information

Keep an AI register, tell people when they are dealing with AI, and be transparent across the supply chain. Action 4.1.1 lists what the register should hold, including accountable people, purpose, capabilities and limitations, datasets and provenance, acceptance criteria and test results, risk assessments and review dates. That is mostly engineering information, so generate it from the repository rather than maintaining it by hand.

5. Test and monitor

Define acceptance criteria, test before deployment, obtain documented deployment authorisation from the accountable person (action 5.1.5), monitor performance in production, and apply data governance and cybersecurity controls, including the Essential Eight. This is where an LLM evaluation suite, regression tests on every model or prompt change, and production dashboards for accuracy, drift and complaints belong.

6. Maintain human control

Keep people able to oversee, intervene and switch off. Action 6.1.2 asks developers to build mechanisms for human control and intervention, and 6.2 covers decommissioning, including keeping alternative pathways for critical functions if the AI is taken offline. In practice: approval steps for consequential actions, a kill switch or feature flag per AI feature, and a tested manual fallback.

Engineering artefacts by practice

Practice	Artefacts a software team produces
1. Accountability	Owner per AI component, RACI across vendor, builder and customer, release sign-off record
2. Impacts	Stakeholder impact notes, contest and appeal flow in the UI, complaint queue with SLA
3. Risk	Risk screening result, threat model, model or system card, incident runbook
4. Information	AI register generated from code and config, AI disclosure in UI, supplier documentation pack
5. Test and monitor	Acceptance criteria, evaluation suite and results, deployment approval, monitoring dashboards
6. Human control	Human approval gates, per-feature kill switch, fallback process, decommissioning plan

Voluntary AI Safety Standard guardrails mapped to the six practices

This mapping is our reading of the two documents, offered to help teams migrate. It is not an official crosswalk.

Voluntary AI Safety Standard guardrail	Closest essential practice
1. Accountability process, governance and compliance strategy	1. Decide who is accountable
2. Risk management process	3. Measure and manage risks
3. Protect AI systems and data governance	5. Test and monitor (5.4 data and cybersecurity)
4. Test models and monitor systems	5. Test and monitor
5. Human control or intervention	6. Maintain human control
6. Inform end users about AI decisions, interactions and content	4. Share essential information
7. Processes to challenge use or outcomes	2. Understand impacts and plan accordingly
8. Supply chain transparency	4. Share essential information (4.3)
9. Keep records for third-party assessment	4. Share essential information (AI register) and records across all practices
10. Engage stakeholders, focus on safety, diversity, inclusion and fairness	2. Understand impacts and plan accordingly

Worked example: an AI agent that issues refunds

Walking one feature through all six practices shows how little of this is paperwork and how much is ordinary engineering. Suppose an online retailer adds an AI agent to its support chat that can look up orders and issue refunds up to $100.

1. Accountability. The head of customer operations owns the feature; a named engineer owns the integration; the contract with the model provider records who handles model faults. Nobody ships a prompt change without the owner’s sign-off.
2. Impacts. Customers are the affected group, including people with limited English or accessibility needs. Every refund refusal shows a plain reason and a “talk to a person” option that reaches a human within a set time.
3. Risk. The risk screen flags financial actions as needing extra controls. The threat model covers customers trying to talk the agent into larger refunds and injected instructions hidden in order notes. Controls: a hard limit enforced in code, not in the prompt, and tool permissions that can’t touch other customers’ orders.
4. Information. The chat window says it is an AI assistant. The feature has an entry in the AI register, generated from the repository, listing the model, prompt version, tools, test results and review date.
5. Test and monitor. Before launch, the agent is tested against several hundred real support conversations, including adversarial ones, with acceptance criteria for correct refunds and zero over-limit payouts. In production, a dashboard tracks refund totals, escalation rate and complaints, with alerts on unusual spikes.
6. Human control. Refunds near the limit queue for staff approval. A feature flag turns the agent’s refund tool off instantly, reverting to the old manual process, which is tested each quarter.

Almost every item above is something a careful team would build anyway. The guidance adds the discipline of writing it down and giving each piece an owner.

Adoption checklist for a software team

• Decide which version applies: foundations or implementation guidance.
• Name an accountable owner for every AI feature and model integration.
• Document the split of responsibilities with your model provider and customers.
• Run a risk screening on each AI use case and record the outcome.
• Build or generate an AI register with the fields in action 4.1.1.
• Show users when they are interacting with AI or receiving AI-generated content.
• Give affected people a way to question or appeal AI outcomes, with a human behind it.
• Set acceptance criteria and run an evaluation suite before every release.
• Record deployment approval from the accountable person.
• Monitor accuracy, drift, incidents and complaints in production.
• Put a kill switch and manual fallback on each AI feature, and test them.
• Check decisions that affect people against the Privacy Act automated decision-making rules starting 10 December 2026.

How All Webbed Labs approaches this

We use the six practices as a design checklist on AI projects, so the register entries, evaluation results, approval records and kill switches are built alongside the feature rather than written up afterwards. For organisations that want a starting point, our AI readiness assessment maps current AI use against the practices and identifies the engineering gaps. The governance decisions and any statement of conformance remain yours. See our AI governance and responsible AI engineering service, and the values behind the practices in Australia’s AI Ethics Principles in practice.