Securing AI Initiatives: New Technology, Familiar Risk Work

Australia now has a clearer front door for AI guidance: ai.gov.au. It points teams at practical material - Guidance for AI Adoption, a screening tool, policy and register templates, training.

Most teams do not lack AI opinions. They lack boring operational clarity.

The methodology to identify, assess, and manage AI risk is the same as before AI. The scenarios changed. The discipline did not.

When we wrote about the gap between AI governance frameworks and real operating models, the pattern was: an agent doing something useful, and a vague hope that security or compliance had looked at it. Frameworks existed. Operating discipline did not. Clearer Australian guidance helps only if someone uses it.

Start with the use case

Not the model. Not the harness, API, agent framework, prompt library, or vector store.

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 - even on the same provider.

Ask:

what objective does this 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, or staff?

That is ordinary risk identification. AI does not excuse skipping it.

Write scenarios, not labels

"Prompt injection" is not a risk statement.

"A malicious support request causes the assistant to ignore its instructions and disclose another customer's information" is.

"Model hallucination" is not enough.

"A staff member relies on an inaccurate AI-generated compliance summary and gives a client the wrong advice" is.

Vague labels produce generic controls and generic owners. A clear scenario forces impact, likelihood, existing controls, treatment, and accountability into the open.

Then the same sequence you already know:

identify the inherent risk
assess impact and likelihood
review existing controls
reassess the current risk
decide the treatment
track actions, evidence, and review dates

What is different

AI does bring specific failure modes. Pretending otherwise is as bad as treating AI as mystical.

The OWASP Top 10 for LLM Applications 2025 maps them. I walked through that list in Securing Your LLM Applications with the OWASP Top 10. The short version: prompt injection, sensitive disclosure, excessive agency, and improper output handling are familiar instincts on a less familiar surface.

Some of it is old wine: treat untrusted input as untrusted, limit permissions, validate before another system acts, monitor abuse and cost, keep logs that support investigation.

Some of it is awkward. Prompt injection is not SQL injection with different punctuation. Retrieval can pull hostile instructions from a document the user never saw. An agent with tools turns a bad answer into a bad action. A vector store can quietly corrupt integrity. A polished summary can be wrong in exactly the way a busy person trusts.

Update the control catalogue. Keep the risk method.

Working with the Australian guidance

The Voluntary AI Safety Standard is background. The October 2025 Guidance for AI Adoption folds the old guardrails into six essential practices: accountability, impact, risk management, transparency, testing, monitoring, and human control.

It reads like an operating model, not a one-off approval ceremony. For each initiative I want 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 screening tool, policy template, and AI register help. None of that stops innovation. It stops avoidable harm being rebranded as experimentation.

The mistake to avoid

Do not invent a special AI risk process that lives outside security, privacy, procurement, architecture, incident response, and change management. Fold AI into that machinery - and update the machinery where AI breaks old assumptions: prompt retention in third-party risk, agent permissions in architecture review, non-deterministic behaviour in incident response, abuse detection in monitoring.

If the system already touches real data or real actions and you cannot answer who owns it, what it can access, and how you shut it down fast, you are not "late to governance". You are already running without it. Five things to get right before deploying AI agents is the practical checklist.

ai.gov.au and OWASP give shared language. They do not replace judgement. Treat AI initiatives like real business systems: identify, assess, treat, test, review as the use case and suppliers change.