Australia now has a new front door for AI guidance.
The newly launched ai.gov.au is useful because it gives Australian organisations one obvious place to start. Not in the abstract, either. The site now points teams to practical material such as the Guidance for AI Adoption, its AI screening tool, the AI policy guide and template, the AI register template, and training resources.
That matters, because most teams do not suffer from a shortage of AI opinions. They suffer from scattered guidance, breathless vendor claims, and not enough boring operational clarity.
But the most important AI security message is still not new.
When we wrote about the gap between AI governance frameworks and real operating models, the observation was blunt: most organisations experimenting with AI had an agent doing something useful and a vague hope that someone in security or compliance had looked at it. The frameworks existed. The operating discipline did not.
Nothing about that has fundamentally changed since then. What has changed is that Australian organisations now have clearer public guidance and more practical tools to close the gap. The question is whether anyone uses them.
Start With The Use Case
Do not start with the model. The harness. The API. The agent framework. The prompt library. The vector store. Or whatever fancy new technology you are using.
Start with the business activity you are changing. A customer-support chatbot, an internal knowledge assistant, an underwriting helper, a code-generation tool, and an autonomous remediation agent are not the same risk. They may all use similar model providers, but the business exposure is completely different.
The questions are familiar:
- what objective does this initiative support?
- what data will it read, generate, store, or disclose?
- who will rely on the output?
- what decision or action could it influence?
- what could go wrong in a way that materially hurts the organisation, customers, staff, or other affected people?
That is ordinary risk identification. AI does not excuse skipping it.
The Risk Register Still Needs Plain Language
An AI risk should be written as a scenario, not as a technology label.
"Prompt injection" is not enough.
"A malicious support request causes the AI assistant to ignore its instructions and disclose another customer's information" is a risk scenario.
"Model hallucination" is not enough.
"A staff member relies on an inaccurate AI-generated compliance summary and gives a client the wrong advice" is a risk scenario.
This matters because vague AI labels make treatment decisions worse. They encourage generic controls, generic owners, and generic optimism. A clear scenario forces the room to discuss impact, likelihood, existing controls, treatment options, and accountability.
That sequence has not changed:
- identify the inherent risk
- assess impact and likelihood
- review existing controls
- reassess the current risk
- decide the treatment
- track actions, evidence, and review dates
If that sounds familiar, good. It should.
What Is Different
AI does introduce specific failure modes, and pretending otherwise is just as dangerous as treating AI like a mystical exception.
The OWASP Top 10 for LLM Applications 2025 is a good practical map of those failure modes. I wrote a fuller walkthrough in Securing Your LLM Applications with the OWASP Top 10, so the important point here is narrower: prompt injection, sensitive information disclosure, excessive agency, and improper output handling all show how familiar security instincts now meet a less familiar surface.
Some of those are new names for old instincts.
Treat untrusted input as untrusted. Protect sensitive data. Keep suppliers visible. Software should not get more permission than it needs, and AI output should not be allowed to trigger another system without validation. Monitor cost, abuse, and failure. Keep logs that can actually support an investigation.
Other parts are genuinely awkward. Prompt injection is not SQL injection with different punctuation. A retrieval system can pull hostile instructions from a document the user never saw. An agent with tool access can convert a bad answer into a bad action. A vector store can become a quiet integrity problem. A beautiful summary can be wrong in exactly the way that makes a busy person trust it.
So yes, the control catalogue needs updating but the risk management method does not.
Working With The Australian Guidance
The Australian Government's earlier Voluntary AI Safety Standard still matters as background, but it has been evolved by the October 2025 Guidance for AI Adoption. The current guidance condenses the old 10 guardrails into six essential practices around accountability, impact, risk management, transparency, testing, monitoring, and human control.
That matters because the Guidance and the broader ai.gov.au material do not frame safety as a one-off approval ceremony. The "staying safe and responsible" material points teams toward knowing the risks, understanding AI impact, using essential AI practices, and managing unapproved AI use. That sounds much more like an operating model than a launch checklist.
For each AI initiative, I would want to see at least:
- a named business owner
- a documented use case and approved boundaries
- data, supplier, and model due diligence
- risk and impact assessment
- security, privacy, and data governance controls
- human review for consequential decisions
- testing and monitoring
- a way to pause, roll back, or narrow the system quickly
The practical tools help here. The AI screening tool helps decide how much governance oversight a use case needs. The AI policy guide and template gives staff a common baseline for responsible use. The AI register template records approved tools, owners, purposes, risks, and controls. None of that stops innovation. It stops avoidable harm being rebranded as experimentation.
The Mistake To Avoid
Don't reinvent the risk management wheel. Don't treat AI risk as a special case that needs a special process. Don't let the newness of the technology distract from the fundamentals of risk management.
Add the AI-specific questions where they belong: prompt retention in third-party risk, agent permissions in architecture review, non-deterministic behaviour in incident response, and abuse detection in monitoring.
We made this point when writing about agentic AI governance gaps: the frameworks exist, but the operating discipline is still missing in most organisations. If your AI initiative can already touch real systems and you cannot answer who owns it, what it can access, and how you shut it down fast, you are not late to the governance conversation. You are already operating without one. For the practical checklist, five things to get right before deploying AI agents goes deeper.
That is the work.
AI.gov.au and the Guidance for AI Adoption are useful because they give Australian organisations clearer public guidance, practical templates, and shared language. OWASP is useful because it gives practitioners a concrete security vocabulary for LLM applications.
But none of those resources remove the need for judgement.
The sensible path is simple: treat AI initiatives like real business systems. Identify the risk. Assess it. Treat it. Test the controls. Keep reviewing as the use case, model, supplier, data, and threat environment change.
New technology. Familiar discipline.