On 8 October, Assistant Minister Andrew Charlton used a speech at the Sydney Trust and Safety Festival to set out how the government intends to regulate frontier AI, and he ruled out both of the obvious options. Voluntary codes, he said, "fail the incentive test", because firms cannot be asked to volunteer against their own competitive interest in a race worth trillions. Detailed prescriptive rules "could be out of date before the ink is dry". What he named instead is systems-based regulation: companies must build and run a rigorous process for finding, testing, reporting on and managing the risks of their systems, and are then held accountable for whether that process works. His precedents were workplace health and safety, critical infrastructure security, prudential supervision of banks and aviation safety. The ABC reported that the national standards are due by the end of the year, with legislation in 2027.
Most boards will file this as a frontier-lab story. The speech is aimed at the developers of the most capable models, and the typical Australian company is a deployer, not a developer, so the reading goes: interesting, not ours. That is literally accurate and strategically wrong. What the speech disclosed is not a rule. It is a regulatory philosophy, and Charlton was explicit that frontier regulation sits inside a whole-of-government response, with privacy and automated decision-making, a digital duty of care, workplace safety and agentic commerce all being worked on by other ministers. When a government tells you the test it will apply at the frontier, it is telling you how the regulators standing around the frontier think.
Australian boards do not need to imagine what a systems regime asks of them, because most already live under one. Officers carry a due diligence duty under work health and safety law that goes beyond having a safety policy to taking reasonable steps to verify that resources and processes are actually provided and used. Responsible entities under the critical infrastructure regime submit an annual report on their risk management program that the board approves. Regulated financial institutions answer to APRA's operational risk standard. In every one of those regimes, the question after an incident is never whether a policy existed. Charlton put it in one line: the question "isn't only 'did something go wrong'" but whether there is "a serious system in place to detect risks and prevent incidents occurring". That is an evidence test, and it is a different test from the one most AI governance has been built to pass.
Look at what sits in a typical board pack under the heading of AI governance. A policy. A set of principles. An approved-use list. Perhaps a register. Every one of those is a document of intent, and under a systems test a document of intent is an input, not proof. The proof is operational: what the process found, what it tested, what it escalated, what it stopped, and what it missed. An AI risk process that has run for a year and never produced a finding is not evidence of a clean environment. It is more likely evidence that nobody has looked. The duty of care a director owes is measured against the regulatory environment the company actually sits in, and that environment has just told every board, in plain language, what kind of evidence it values.
- If a regulator asked us tomorrow to show that our AI risk process works, not that it exists, what would we hand over, and has that process ever stopped, changed or delayed a single AI deployment?
- What has our AI risk process found in the last twelve months that management did not already know, and where in the board papers did we see it?
- When were our AI controls last tested by someone independent of the people who designed them, and what did that test find wrong?
- Which of our AI uses already fall inside a systems regime we answer to, whether safety, critical infrastructure or operational resilience, and are they reported through that program today or sitting in a separate framework beside it?
- Who owns the AI risk process end to end, and if that person left next month, would the process keep running or would we be left holding the policy?
- AI governance reporting that counts artefacts: policies approved, registers updated, staff trained. Those are measures of activity. None of them tells the board whether the process catches anything.
- An AI risk process with no findings, no exceptions and no rejected proposals. In a risk area this new and this fast-moving, a perfect record is far more likely to be a detection gap than a clean bill of health.
- Comfort taken from the word frontier. The legislation may name the developers, but the logic will reach deployers through the regulators already supervising them, through insurers and through customer contracts.
- AI risk run as a parallel framework, with its own committee and its own register, that never touches the safety, resilience or critical infrastructure programs the board already oversees and already has to answer for.
- Waiting for the text of the standard before acting. The shape of the obligation has been disclosed. The text will only set the height of the bar.
- Assurance that rests on vendor attestations. Charlton's entire premise is that the developers' incentives point toward speed, and that in the incidents he cited the labs neither detected nor prevented what their own systems did.
The opportunity is that a systems test rewards organisations that can show their working. Most of the machinery already exists. The safety, resilience and audit programs a board oversees today know how to test a control, record an exception and escalate a finding, and AI can be folded into them rather than given a new apparatus of its own. An organisation that arrives at the national standards with a year of evidence that its AI risk process has found real problems and fixed them will meet the regime with a track record, and that same record will speak to an insurer at renewal and a major customer in due diligence well before any regulator asks.
The risk is that boards conclude this is someone else's legislation and keep polishing the documents. Policy-heavy AI governance has been cheap to produce and comfortable to approve, and under a systems test it is close to worthless as evidence. If the first serious AI incident inside an organisation is investigated by a safety, privacy or prudential regulator that has absorbed this philosophy, the question will be what the process caught, not what the policy said. A board that can only produce the policy will have shown that it approved an intention and never checked whether anything happened as a result.
Change the evidence the board accepts before the standards land, not after. Do three things this quarter. Split the AI governance material in the board pack into two piles, documents of intent and evidence of operation, and ask management to report on the second pile from now on: findings raised, deployments changed or stopped, exceptions granted and the reasons. Commission an independent test of the AI risk process end to end against a live use case, run by internal audit or an outside party who did not design it, with the findings reported to the board unedited. And fold AI into the systems the board already oversees, so that safety due diligence, operational resilience and, where it applies, the critical infrastructure risk program carry AI explicitly instead of leaving it in a parallel framework that reports to nobody in particular. If the test finds the process has never caught anything, minute that as the finding it is. The government has told directors what it will ask for, and a board that still treats an approved policy as proof of control has been given fair warning.
Researched and drafted by Brad's agentic AI team. Edited and published by Brad Ferris.