‘The AI did it’ should never be a defence: our submission to Parliament’s AI inquiry

In August 2026, Parliament established a new Joint Select Committee on Artificial Intelligence to look at the opportunities, risks and regulation of AI in Australia. MDR Security made a submission to the inquiry, which has now been published as Submission 137. This post sets out the main arguments; the full submission is linked at the end.

One principle runs through all of it: AI is a tool built and operated by people, and the people and organisations who build and use it remain responsible for what it does.

Design for AI being wrong, and for AI being unavailable

AI systems will always make some mistakes. We use AI precisely when we don’t have a definitive model of how to turn inputs into correct outputs; if we did, we would just write conventional software. Instead we train a model on examples, and it generalises – imperfectly – to inputs it hasn’t seen. Errors can be reduced but never eliminated.

So every process that relies on AI needs an answer to two questions: what happens when the AI is wrong, and what happens when it isn’t there at all – because the software fails, the connection drops, or the supplier withdraws access. We recommended that Commonwealth agencies and critical infrastructure operators be required to document how errors are detected and corrected, and how the service continues without the AI system.

Sovereignty means assured access, trust and leverage – not self-sufficiency

“Sovereign AI capability” means different things to different people. It shouldn’t mean every component made in Australia and every line of code written here, and it shouldn’t be used to justify support for uncompetitive businesses. Australia doesn’t have the scale to be self-sufficient across the whole technology stack. Instead, investment should follow comparative advantage: building capabilities others depend on, so that we have leverage over the capabilities we depend on them for. Economists, technical experts and end-users should work together to identify where those opportunities lie.

Security of supply is no longer a hypothetical concern. In June 2026, to comply with US export controls, Anthropic suspended access to two of its most advanced models for all customers, Australians included, for almost three weeks. Anyone who had built a critical process on those models had to find out the hard way what their continuity plan was.

Where data is stored is only part of the story

“Data sovereignty” usually refers to the physical location of data. That matters for which laws apply, but it only constrains people who care about complying with Australian law. Hackers don’t care where a server sits, and a multinational operating a facility in Australia may still be compelled by its home government to hand over data or cut off service. Assessments of foreign interference risk should ask who operates the system, which foreign governments can compel access or withdrawal, and whether the function could keep running if a foreign supplier walked away.

Don’t overlook smaller, narrower models

Large general-purpose language models in big data centres dominate the conversation, but they are only part of the field. For critical applications, narrow, domain-specific models can be more predictable, more auditable and far more efficient in their use of computing power, energy and water. They can also run on infrastructure under Australian control – and a model running on your own hardware can’t be switched off by someone else. These options deserve equal consideration, judged on reliability and resilience, not just benchmark scores.

Training on Australian data makes sense where it makes the model cheaper to build or more accurate in the context where it will be used – Australian law, flora, fauna or geology, for example – but not as a matter of national pride at the expense of access to the most effective systems.

“The AI did it” should never be a defence

Debates about whether AI can “think” are a distraction, and the language of autonomous systems is dangerous because it lets people deflect responsibility. AI is not a regulatory vacuum: existing laws already do much of the work. Because every AI system makes mistakes, no operator can claim ignorance of the risk, and anyone who fails to supervise their system effectively should not be able to evade liability for the harm it causes.

Protect genuine experimentation

No-one can reliably predict which AI applications will deliver value for a particular organisation with its own data and processes; that has to be discovered by trying. Critics who count the AI pilots that “fail” are missing the point. But pilots should be designed as real experiments, with a clear hypothesis, success and stop criteria set in advance, an accountable business owner and a realistic path to production.

The same applies to the public service. Government policy already exempts early-stage experimentation from impact assessment, so the barrier is cultural rather than regulatory. We urged the committee to draw a clear line between experiments, where some failure is expected, and production systems that make or inform decisions about people, which must meet strict standards of lawfulness, accuracy, transparency and human accountability. Robodebt is the cautionary tale – and it wasn’t AI at all, but a simple automated calculation applied unlawfully and at scale. Its lessons are about accountability, not technology. Agencies also need independent technical expertise so they can be intelligent customers, rather than relying on suppliers to assess their own products.

AI security is cyber security

AI will help attackers find and exploit weaknesses faster and at greater scale. But most successful attacks today exploit failures of basic configuration and hygiene, so the answer isn’t reflexively buying “AI to defend against AI”. It’s getting better at the basics: configuring systems correctly, patching promptly, not exposing systems to the internet unnecessarily, and segmenting networks. Where AI helps defenders most is in doing those basics faster – finding and fixing vulnerabilities before attackers do.

Deepfakes and voice cloning are another example. Detection tools will always lag behind generation, so the durable answer is security architecture: robust digital identity and out-of-band verification of payments and access requests.

We welcome the Australian AI Safety Institute, but “AI safety” is too often treated as a separate discipline focused on the capabilities of frontier models. For most organisations, the risk lies in deployment: connecting AI to business systems and giving agents permission to act opens new routes for data leakage and manipulation, such as prompt injection, where instructions hidden in a document or email hijack the AI that reads it. That is a security engineering problem, and cyber security teams – once seen as the “department of no” – should be at the centre of managing it.

Policy needs to be grounded in how the technology works

AI has broad social and economic impacts, but it is a technical subject, and policy that isn’t grounded in how the technology actually works will miss its mark. It’s good to see industry, government, academia and civil society engaged in this debate – but alongside technical experts, not instead of them.

The committee is due to report by 30 November 2026. Dr Rajiv Shah has offered to give evidence at its hearings.

Read our full submission to the Joint Select Committee on Artificial Intelligence (Submission 137)