Australia’s AI architecture becomes useful at the control points

A common model across four views

Australia’s AI Reference Architecture gives government agencies a shared model for designing and assessing AI systems. It separates four constructs: the functional stack; communication among components; trustworthiness and assurance; and human agency, oversight and control.

The companion guide applies the model to four scenarios: a vendor AI platform, an in-house AI service, procurement of an agentic call-centre system and AI in case management. It also distinguishes levels at which an agency may govern, configure or design a component.

That separation is useful in procurement. A buyer may govern a vendor platform without controlling its model training, configure a workflow without designing the underlying service, or operate an interface while another party holds the logs. The diagrams can expose where responsibility and evidence cross organisational boundaries.

The DTA describes the architecture as voluntary and says it does not replace existing policy, legal, privacy, security or assurance obligations. A box in the blueprint is therefore not proof that a control exists or works.

Reference models are maps, not evidence

The US National Institute of Standards and Technology AI Risk Management Framework provides an independent comparison. Its Govern, Map, Measure and Manage functions organise risk work throughout the lifecycle. Like the Australian architecture, it is a voluntary framework intended to improve how organisations reason about AI risk rather than certify a product by itself.

The two models use different structures. NIST emphasises risk-management functions; Australia emphasises system and control views for government use. Neither eliminates the need to define the actual system boundary, data, users, suppliers and consequences.

Turn components into control-point tests

Start with one use case and draw only components that can affect a decision or state change. For every boundary, record who can configure it, who can inspect it, which evidence is retained and who can stop the flow. Mark claims that depend entirely on a supplier.

For a vendor platform, request evidence for model and data provenance, access control, evaluation, monitoring, incident handling, subcontractors and change notification. Test whether logs contain the context needed to reconstruct a consequential action. Verify that contract language preserves access to evidence after termination.

For an agentic workflow, define the authority envelope: allowed tools, data, transaction values, duration and escalation. Exercise expired credentials, changed permissions, partial failures and a supplier model update. Human oversight is effective only if the person can see the relevant evidence, understands the decision and can intervene before harm is irreversible.

Assign a control owner and a stop condition to every high-consequence component. A stop condition might be missing trace data, evaluation regression, unapproved data use or inability to reverse an action. Record whether the agency can stop the component itself or must ask a supplier.

This builds on the Netherlands public-service baseline: architecture choices become capability requirements when named owners must operate, challenge and evidence them.

Keep procurement and assurance distinct

Use the reference architecture to structure questions, not to award compliance points for diagram similarity. A supplier may present every box while leaving test results, failure modes and change controls undefined. Conversely, a system can meet an obligation through a different architecture if the evidence and accountability are sound.

Legal, privacy, security and records specialists should review the local obligations. The architecture can coordinate their questions, but it cannot decide the legal basis, acceptable risk or final authority for them.

Decision rule

Do not approve a system because its proposal resembles the reference architecture. Approve only when every material component has an evidence request, accountable owner, representative test, supplier dependency and stop condition tied to the real operating boundary.