How this started…
I ask a security leader to see their AI security policy.
Much too often, it’s something like an acceptable use document about staff pasting customer data into public LLMs (like ChatGPT or Claude).
Now that’s a real policy. And it addresses a real risk.
But it isn’t an AI security policy. And the difference between those two things is where a lot of budget is quietly being drained right now.
Here’s the problem. “AI security” covers four separate disciplines. Different owners, different skills, different evidence, different regulators.
Squash them into one line item, and you end up approving spend that nobody can account for six months later.
Diving deeper into these four disciplines…
1. Securing AI systems
This is the AI estate treated as attack surface.
Data pipelines. Training environments. Model artifacts. Inference endpoints. The tool and connector layer. And agents that hold credentials and take actions with no human watching.
The question here is simple: can this be compromised?
The owner is the CISO.
This is also the one most people think they mean when they say AI security… and in my experience it’s the one with the least resourcing attached. Partly because it’s the only one of the four that requires you to have an inventory before you can do anything at all.
2. AI for security
Using AI in defence. Alert triage, detection engineering, investigation support, response automation.
The question: does this make the security function faster or cheaper?
The owner is security operations.
And it has almost nothing in common with the first discipline except the acronym. A vendor selling you an AI-powered SOC is not selling you anything that reduces your AI risk. (These two get conflated in procurement far more often than they should.)
3. AI safety
Whether the model behaves. Harmful output, unpredictable failure, doing things it was never meant to do – or refusing things it was.
Some of this you inherit from the model provider.
But some of it becomes yours the moment you fine-tune, ground the model in your own data, or let it act.
It usually sits with product or engineering. Security teams are typically the least equipped to assess this one… and often don’t realise they’ve been handed it.
4. AI governance
Fairness, transparency, explainability, contestability, human oversight, and every regulatory obligation attached to those.
The question: can you justify an automated decision to a customer, a court, or a supervisor?
The owner is risk, legal and compliance.
This is the discipline with the most published material and the most standards attached to it. Which is a big part of why it gets mistaken for the whole field.
So which one did you actually buy?
If your AI security program is a staff usage policy and a procurement questionnaire, you bought governance.
If it’s a gateway product, you bought a slice of the first discipline and none of the other three.
Neither is a mistake on its own.
Both become one the moment they’re described to a board as “AI security” without qualification. Because the board then believes a question has been answered that nobody has actually asked yet.
Worth noting: the Australian government drew this line years before most enterprises did.
ASD’s Australian Cyber Security Centre published Engaging with Artificial Intelligence back in January 2024, developed with CISA, the FBI, the NSA and the UK’s NCSC among others. And it’s scoped deliberately – it covers using AI systems securely, then points anyone actually building AI systems to a completely separate publication, the joint Guidelines for secure AI system development.
Two documents. Because they’re two problems.
ASD then followed up with an AI Data Security information sheet in May 2025, and Principles for the secure integration of AI in Operational Technology in December 2025. Each one narrower again.
The national cyber authority has been careful about scope from the beginning. Most of the enterprises reading its guidance… have not.
Where the four meet
There is one place all four converge. And it’s the reason I’m writing this series.
Assurance is the production of evidence that a stated risk is being managed within a stated tolerance, signed by someone who can be held to it.
Every one of the four disciplines eventually has to produce that evidence.
Securing the estate has to show the controls work. Defensive AI has to show the automation didn’t make things worse. Safety has to show the model behaves inside a defined envelope. Governance has to show the decision can be explained and contested.
APRA named assurance explicitly in its 30 April 2026 letter to industry – one of four themes where practice isn’t keeping pace with AI adoption.
That’s the word the supervisor used. And it is not a synonym for testing, or audit. I’ll take that apart properly later this week.
For now, the instruction is narrower than that.
Before you write an AI security strategy, name which of the four you own. Write it down. Then write down who owns the other three.
If you can’t fill in all four names, you’ve just found the actual finding. And it’s a governance gap.
A note on sources for this series: every figure I cite will link back to a primary source. There’s a lot of AI security statistics floating around that trace back through three vendor blogs to a report that turns out not to exist under that name. I’d rather publish fewer numbers than repeat those.