Australia’s current AI adoption guidance is the National AI Centre’s Guidance for AI Adoption, published October 2025 and updated May 2026. It names six practices: decide who is accountable, understand impacts and plan accordingly, measure and manage risks, share essential information, test and monitor, and maintain human control.
They are guidance. They are not six new AI laws. Privacy, consumer law, and discrimination law still apply. The Voluntary AI Safety Standard’s ten guardrails sit underneath if you need more detail later. This page is the delivery version: what each practice means when you put AI into a project you already run.
Quick answer
Treat the six practices as questions inside the build, not a separate governance workstream. Name a person who owns the outcome when the system is wrong. Assess who is harmed before go-live. Put a control next to each named failure. Tell staff and customers that AI is in the process. Score a sample before launch and keep watching after. Match human oversight to the cost of being wrong. If you cannot show owner → impact → risk → controls → testing → approval → monitoring, you cannot prove you governed it.
Best for: Australian GMs, ops leads, and engineering leads who already have Copilot, a chatbot, or a model scoring cases, and need the six practices in language a delivery team can use. Honest limit: this is not legal advice, not a VAISS certification path, and not an ISO 42001 AIMS. Clear Direction AI (Cipher Projects) builds the evidence layer. We do not certify you.
Last updated: 15 September 2026. Source for the practice names: National AI Centre, Guidance for AI Adoption. The walkthrough below is the teaching system from Cipher’s Hour 1 workshop: AI drafts customer replies; staff review and send.
What are Australia’s six AI practices in 2026?
The six practices are:
- Decide who is accountable — a named person owns the outcome when it is wrong.
- Understand impacts and plan accordingly — who is harmed if it fails, then design for that.
- Measure and manage risks — name the failure; put a control next to it.
- Share essential information — people can see that AI is in the process, and its limits.
- Test and monitor — prove it before go-live; keep watching after.
- Maintain human control — oversight matches the cost of being wrong.
Older Cipher copy still listed a 2024-era six-practice wording (accountability, risk, data quality, human oversight, transparency, stakeholder engagement). Use the list above. The longer VAISS implementation path remains in our framework guide.
Why do the six practices matter if AI is already in the business?
The risk is not that you might adopt AI. The risk is that it is already acting without a named owner. Copilot in email, a helpdesk draft model, a case-scoring feature inside SaaS — those are AI systems. Losing control looks like a wrong refund promise, a privacy leak in a prompt, a staff member rubber-stamping a draft, or a workflow that fires with nobody able to stop it.
The question we use in the room: how do we introduce AI without losing control? The six practices answer that as delivery controls, not a policy PDF.
What does “decide who is accountable” mean on a project?
Do not only ask who built the AI. Ask who is accountable for what happens when it is wrong.
Three seats work in practice. The business owner owns the outcome, answers for the customer, and can stop the system. The technical owner owns the implementation, the data access, and how it is changed. Risk, legal, and security provide assurance. They do not run it day to day.
A vendor is not the owner. A committee is not the owner. Write a person’s name. If you cannot, you do not have accountability yet. Every AI system should have that name on the row before go-live. Inventory fields: AI inventory.
How do you understand impacts before you switch the system on?
Ask who the AI could affect: customers, employees, the organisation, and third parties including vendors. Then ask what happens if the system works badly: privacy, financial loss, incorrect decisions, discrimination, security issues, reputational damage.
Helpdesk example: the customer gets a wrong answer, staff send it under their name, the brand wears it, and the vendor may have seen the ticket text. High impact does not mean do not build it. It means more planning before you switch it on. Assess impact before deployment, not after the incident.
How do you measure and manage AI risks like an engineer?
Name the failure. Put a control next to it. The control should match the harm.
| Risk | Control | Helpdesk example |
|---|---|---|
| AI leaks data | Access restrictions | Ticket text stays in a scoped prompt. No whole-CRM dump. |
| AI gives bad answers | Validation / testing | Ground drafts on approved policy. Score a sample before go-live. |
| AI takes the wrong action | Human approval | No send without a human. No auto-refund. |
| User manipulates AI | Security testing | Prompt-injection test on ticket text. |
| Model changes | Monitoring | A provider update triggers a re-score of the sample set. |
What information must you share about the AI?
People need to understand what the AI is doing: who is using it, what for, what information it uses, what its limits are, and when a human is involved.
Three audiences. Staff need it on the screen: AI draft, check before send. Customers need it if the channel uses AI. Operators need the limits written down: it does not approve refunds, and it does not see other customers’ tickets. If staff cannot see that it is an AI draft, they will treat it as their own words. Do not hide the AI inside the process.
When do you test, and what do you monitor after go-live?
AI is not tested once. Before deployment, test accuracy, security, privacy, safety, and reliability. Does it draft the right kind of reply? Can ticket text jailbreak it? Will it promise a refund or a legal outcome? Does it fail closed, or fail silently?
After deployment, watch performance, incidents, user behaviour, model or provider changes, and new risks. Watch the edit rate. If it collapses to zero, staff have stopped reading. A model update is not the same system. Re-run the sample set. Deployment is the beginning of monitoring, not the end of testing.
Where should human control stay in the loop?
Not every system needs a human on every output. The question is where human judgement needs to remain.
- AI drafts, human approves — default for customer-facing text: helpdesk replies, email, policy summaries.
- AI recommends, human decides — a case score or suggested refund; the human still clicks.
- AI detects, human investigates — a fraud flag; the model does not close the case.
- AI acts automatically — only with defined limits and a way out: small, reversible, logged, and an escalation path when it is unsure.
A wrong helpdesk reply is recoverable if a human still sends it. An auto-refund or an auto-legal answer is not the same class of system. Match oversight to the consequences of failure.
How do the six practices look on a helpdesk reply-drafting AI?
Default teaching system: AI drafts customer replies from the helpdesk. Staff review and send. Swap in a live system if you have one. Same questions.
| Question | Helpdesk answer |
|---|---|
| Who owns it? | Service lead owns the outcome. Engineering owns the build. Legal / privacy assure. Not the vendor. |
| Who could be affected? | Customers get the reply. Staff send it under their name. The brand is on the line. The vendor may see ticket text. |
| What can go wrong? | Wrong refund or legal promise. Privacy leak into the prompt. Discriminatory tone. Staff rubber-stamp. |
| What controls? | Ground on approved policy. Ticket data scoped. Prompt-injection test. No send without a human. |
| What do we share? | Staff see “AI draft — check before send.” Limits on screen. Tell customers if the channel uses AI. |
| How will we test it? | Score a sample of drafts before go-live. After: edit rate, complaints, model-change re-score. |
| Where is the human? | AI drafts. Human approves and sends. No auto-send. No auto-refund. |
| After deploy? | Monitor, then reassess when the model, the data, or the use changes. |
Unique insight from the workshop: the six practices are not another compliance document. They are questions you should build into the way you deliver AI. Teams that treat them as a separate workstream produce a policy nobody updates. Teams that put them on the go-live checklist leave an evidence chain.
What evidence chain should you be able to show?
For every AI project you should eventually be able to show this chain: a named owner, a written impact assessment, a written risk assessment, controls mapped to those risks, the testing you scored, who approved go-live, and what you are monitoring this month.
If you cannot show the chain, you cannot prove you governed it. That is the bridge from principles to the living register. Buying the day that fills the register: Power Day. Why the register exists: Can you prove it?
FAQ
Are the six practices law? No. They are National AI Centre guidance. Existing law still applies. Timeline of what is binding vs announced: 2026–2027 regulation.
How do these relate to the Voluntary AI Safety Standard’s ten guardrails? The six practices are the adoption layer. The ten guardrails are the deeper checklist boards and tenders often ask for. Evidence checklist for the ten is still queued; the implementation guide is the VAISS page.
Do we need a separate AI governance project? Prefer not. Put the six questions on the project that ships the AI. A separate workstream usually produces slides. A delivery checklist produces owners and controls.
What if staff stop editing the AI drafts? Treat a collapsed edit rate as an incident signal. Re-train, re-score, or pull autonomy until people are reading again.
Can a Power Day cover this? A Power Day fills the inventory and evidence record. Hour 1 of the workshop teaches the six as project controls. Same company, different artefact. What the day produces.
Related: Prove it · AI inventory · Power Day · VAISS guide · Regulation timeline · Book a Power Hour