Sovereign AI in Health
The board test for trust, accountability and adoption
It was a privilege to speak and participate as a panellist at today's Building AI Without Boundaries: Data, Sovereignty and Scale workshop, hosted by QUT, the Australian Academy of Technological Sciences and Engineering (ATSE) and the ARC Industrial Transformation Training Centre — Joint Biomechanics, at QUT's Garden Point Campus in Brisbane.
My sincere thanks to the organising team — Distinguished Professor Yuantong Gu, Professor Clinton Fookes, Dr Laith Alzubaidi and Professor Mel Bridges — for pulling together a genuinely outstanding program and for the invitation to contribute.
The breadth and depth of thinking in the room was remarkable. Session 1 examined how AI can learn across distributed organisations without moving sensitive data — and what governance, accountability and sovereignty conditions have to be in place before that is truly safe to do. Session 2 tackled the question of how we build and scale AI systems efficiently and affordably. The panel discussions across both sessions were candid, rigorous and practically grounded.
My own contribution explored what I am calling the Board Test for Sovereign AI — five conditions boards should require to be satisfied before approving a federated AI project — with health as the primary example but the governance principles applying well beyond it.
#SovereignAI #AIGovernance #FederatedLearning #DigitalHealth #BoardGovernance #AustralianAI
I want to start with a problem landing on health officials’ desks right now.
Within a period of twelve months, a state health department is approached by three separate research groups — a cancer team, a mental health outcomes group, and a rare genetic disease consortium. Each wants patient data. Each is told no — because the data cannot be shared.
Then someone says: “What if the data never has to leave? What if the AI model travels to the data, learns from it locally, and the hospitals share only what the model learned — never the underlying patient records?”
Questions are asked. The technology team says it is possible. The research teams say it will save lives. So, the Secretary says yes.
Eighteen months later, a patient in a regional hospital receives a negative result from the AI-assisted screening tool. Six months after that they are diagnosed with stage three colorectal cancer the tool missed.
The question that lands on the board's desk is not a technical question. It is: who is responsible? The hospital that used the tool? The university that built it? The consortium of hospitals whose data trained it? The offshore vendor whose platform it ran on?
In most current federated AI deployments — the answer is: we don't know. Not because nobody thought about it. Because the governance architecture was never built.
That is what I want to talk about today.
The infrastructure behind this scenario is being built right now, and it is genuinely significant.
The NINA project — led by UQ, involving QUT, Monash and CSIRO — is building national federated learning infrastructure for cancer, diabetes and arthritis research across state boundaries. The ARDC launched a major capacity-building project in April, bringing together Australia's three largest federated learning initiatives. Globally, the Cancer AI Alliance has built the first scalable platform training across more than a million cancer patients — without centralising a single record.
This is real. It is accelerating. And let’s be clear: I am not here to slow anything down.
What I want to argue is that the technical architecture and the governance architecture need to be built at the same pace — and right now, they are not.
Before I get to the Board Test, I want o make one critical point. The data not moving does not mean the privacy risk disappears. There are three documented ways it can be compromised — and they are on your screen.
Gradient leakage: when the model learns from a hospital's data, it sends back a mathematical update. Researchers have demonstrated those updates can be used to reconstruct individual patient records. The data did not move — but a fingerprint of it did.
Membership inference: an attacker can probe the trained model to determine whether a specific person's records were used in training. In healthcare, confirming someone participated in a mental health AI dataset is itself a breach — it tells you they were receiving treatment.
Model poisoning: a single compromised institution in a twelve-hospital consortium can inject corrupted updates that propagate to everyone. Detection typically takes six to twelve months. The same privacy rules that prevent data from being shared also prevent anyone from detecting the corruption early.
These are not hypothetical. They are well researched and the findings are generally accepted. I think they also define exactly what a governance architecture must protect against.
So what does a governance architecture actually require? I want to give you a practical test — five conditions a board should require to be satisfied before approving a federated AI project.
Legal authority. Technical assurance. Clinical accountability. Multi-party governance. And public legitimacy.
Each addresses a specific documented risk. Condition four — multi-party governance — is the hardest to satisfy in practice, and I want to spend the most time there.
Let me take you through them briefly.
The first condition is legal authority. This is more urgent than most organisations realise. Australia's Privacy and Other Legislation Amendment Act, which received royal assent in December 2024, requires organisations to disclose automated decision-making in their privacy policies by December 2026. A federated AI model influencing clinical referrals is automated decision-making. I suspect most organisations building federated AI systems right now do not have this documentation in place. The board question: are we on track?
The second condition is technical assurance. A QUT-co-authored study in npj Digital Medicine last year examined 39 federated learning healthcare projects and found comprehensive governance frameworks are currently lacking across the field. This is not a theoretical gap — it is documented by researchers in this institution. Technical assurance means independent audit of model performance across all sites and active defences against the three risks I described. The board question: who independently audits performance across every participating institution?
The third condition is clinical accountability. Australia's Department of Health and Aged Care review found professional liability for AI use in health is a cause of concern for health professionals and insurers. The AMA made the same point: liability cannot dissolve across a consortium. The board question: when this model influences a decision that causes harm — which clinician or institution is accountable, and do they know it?
This is the condition I want to spend the most time on, because it is the one most often glossed over.
Most consortia building federated AI agree on the technical architecture — which software platform, which aggregation method, which compute infrastructure — before they agree on who is responsible when it fails. The accountability question gets deferred. The research confirms this is the norm, not the exception.
What multi-party governance architecture actually requires is unglamorous but essential. Legal contracts between all consortium members before deployment — not after harm occurs. Designated stewardship for data quality and model performance, so someone is monitoring drift, bias and degradation. Agreed incident response procedures, including who has the authority to suspend the model. And independent audit arrangements across every site.
The Governance Institute of Australia's 2025 survey found 93% of Australian organisations cannot effectively measure AI return on investment, and 72% cite data privacy as a major regulatory challenge. The infrastructure for governing AI in complex multi-party settings simply does not yet exist at scale in this country.
There is also a legal dimension building from offshore. The EU's new Product Liability Directive, in force from December 2024, makes AI system providers and supply-chain participants strictly liable when a defective AI system causes harm. Australia has no tested case law on AI liability in healthcare yet — but Australian health organisations procuring from EU-regulated vendors are already operating in that liability environment.
The accountability chain on this slide is not decorative. It is the governance document a board should require to exist before approving a project. If you cannot name who is accountable at each link — data custodians, model developer, consortium governance, deploying organisation, clinician — you are approving a system with an unquantified legal and reputational tail.
Board question: if harm occurs, can we produce documentation of who was responsible for each decision in that chain? (By the way, in terms of liability, the Courts will focus on the entities with the deepest pockets and the poorest documentation.)
The fifth and final condition is public legitimacy — and the Australian data here is striking.
The University of Melbourne and KPMG's 2025 global AI trust study surveyed 48,000 people across 47 countries. Thirty-six per cent of Australians are willing to trust AI. That is the lowest of any country surveyed. Thirty per cent believe the benefits outweigh the risks. Fifty-three per cent are worried specifically about how their health data is used by AI systems.
Federated AI in health will not be adopted at scale simply because the technology works. Public trust is the binding constraint. And public trust requires visible governance — not just technical architecture.
I will make one broader point about sovereignty. Australia's National AI Plan, released in December, makes a significant investment in AI infrastructure. But most of the foundation models used in Australian health and government were built and governed offshore, under conditions Australian regulators cannot verify. Not moving the data is necessary — but it is not sufficient for sovereignty. Sovereignty requires governing the whole system.
I want to close with the frame I hope you take from this talk.
The five conditions I have described are not obstacles to federated AI. They are the architecture that makes federated AI adoptable — by boards, by clinicians, by regulators, and by the Australian public who are currently the least trusting AI population in the world.
The technical community in this room will determine whether federated learning works. The governance community will determine whether it gets used.
Three things worth remembering:
The technical architecture and the governance architecture are not the same thing — and they are not being built at the same pace.
Not moving the data solves one problem. It creates a different set of problems that require governance, not engineering.
And: sovereign AI is not declared. It is built deliberately — in the governance architecture, not just the compute infrastructure.
The promise of sovereign AI is that we can learn from distributed data without surrendering control. The governance promise has to be stronger: that we can do it with accountability, clinical safety, and public legitimacy visible from every point in the system — not just the point where the data sits.
D.J. Green Advisory · djgreenadvisory.com · QUT/ATSE Building AI Without Boundaries · 18 May 2026