AI Strategy and Readiness for Australian Government and Public Sector

The gap between an AI mandate and an AI system

Most Australian government agencies now have a direction to use artificial intelligence. Very few have a clear line from that direction to a system running in production, inside the privacy, procurement and accountability rules the agency actually operates under.

The gap is not usually technical. Models work. Vendors demonstrate convincingly. What stalls the work is everything around the model: where the data is allowed to live, who is accountable when the system influences a decision about a citizen, whether the agency can explain an output to an ombudsman, and whether anyone internally understands the system well enough to challenge the vendor who built it.

An agency that cannot answer those questions does not have an AI problem. It has a readiness problem, and buying a platform will not solve it.

What readiness actually means in the public sector

Readiness in a government context is broader than the data-maturity checklists most vendors hand out. Four things have to hold at once.

Data. Not just whether the data exists, but whether it is lawfully usable for the purpose you have in mind. The Information Privacy Act 2009 (Qld) and the Commonwealth Privacy Act, as amended in 2024, place real constraints on secondary use and on transfer outside Australia. Data that is perfectly good for service delivery is often not available for training or inference without further work.

Accountability. In Australian administrative law the decision-maker is the officer, not the algorithm. If an AI system recommends and an officer signs without genuine scrutiny, the accountability framework may not protect either of them. That has design consequences: audit trails, contestability, and a human review step that is real rather than nominal.

Architecture. Public sector AI almost never runs in isolation. It has to reach systems that were designed decades before anyone used the term. The integration surface is usually the largest single cost in the programme and the one least represented in the business case.

Capability. An agency that depends entirely on a vendor to say whether its AI is working correctly has given away oversight it cannot afford to give away. Every serious procurement needs at least one internal person who can ask hard questions and understand the answers.

The questions that decide whether a business case survives

Business cases for AI in government fail at predictable points. Before writing one, it is worth being able to answer these in plain language.

• Where will the data be stored, processed and transmitted, and can the vendor commit to it never leaving Australian jurisdiction? "We use AWS" is not an answer; "ap-southeast-2 only, with no offshore staff access" is.
• If a citizen challenges an outcome, what exactly do you show them, and can it be produced without the vendor's assistance?
• What is the exit pathway if the vendor is acquired, fails, or triples its pricing at renewal?
• Which existing systems must this integrate with, and has anyone looked at their interfaces rather than assuming they have one?
• What is the honest cost per transaction at full volume, not at pilot volume?

An agency that can answer all five is ready to go to market. An agency that cannot is better served spending three weeks resolving them than six months running a procurement that will not survive scrutiny.

Where this has been done before

This is not theoretical work for me. I have spent thirty years building systems in Australian regulated environments, and most of it has been in exactly the places where getting it wrong matters.

At eHealth Queensland I built electronic referral management delivered across Queensland Health. The constraint there was that clinical criteria change faster than any release cycle can follow, so the forms were made metadata-driven: criteria held as XML and JSON in SQL Server, rendering clinician-facing forms at runtime. It integrates modern Angular and C# services with legacy clinical systems across both REST and SOAP boundaries. It is still supporting clinical operations.

At Magentus I spent three years on healthcare interoperability, including HL7-compliant FHIR APIs adopted across multiple client teams and the integration of Medicare Web Services and My Health Record into a patient management system. Claims processing cannot stop while you modernise it and the compliance surface is not negotiable, which makes that work as much regulatory precision as engineering.

Other work has run through the ATO, banking, and university identity infrastructure at the University of Queensland, where I delivered SAML-based federated authentication into production with an automated CI/CD pipeline on AWS.

Regulated environments teach a particular lesson: a system is not finished when it works. It is finished when it survives an audit, an outage, and the people who have to use it every day.

How an engagement runs

A readiness and strategy engagement is deliberately short. The aim is to get an agency to a defensible position quickly, not to produce a document that sits on a shelf.

It usually starts with two to three weeks of assessment: interviews with the officers who would use the system, a look at the data and the systems it would have to touch, and a review of the governance and privacy constraints that actually apply to your agency rather than the generic ones.

What comes out of it is a written position covering where you genuinely are against each of the four readiness dimensions, the two or three use cases most likely to survive contact with production, the integration work those use cases imply, evaluation criteria you can put into a procurement, and an honest statement of what is not ready and what it would take to get there.

Where it makes sense, the same engagement continues into delivery. That is the part most agencies find unusual: the architecture is written by the person who will implement it, so it is costed by someone who knows what implementation costs.

What you get, and what you do not

You get one senior engineer with a TOGAF practitioner qualification, an AWS Solutions Architect certification, an MBA, and thirty years of shipping. You do not get a team of juniors with an account manager in front of them, and you do not get a recommendation written by people who will never have to build it.

That is a deliberate constraint. It means I take on a small number of engagements, and it means I will tell you early if your problem is not one I am the right person for.

Related reading:

• AI procurement in the Queensland public sector
• the 2024 Privacy Act amendments
• writing an AI business case that gets approval
• what a low AI readiness score means
• how to write an AI strategy