What Is Australia's AI Reference Architecture (AIRA)?

On 30 October 2026, the Digital Transformation Agency (DTA) published a blueprint that will shape how Australian Government AI systems are designed, bought and assured. It is called the AI Reference Architecture, or AIRA.

If it has just landed on your desk, this guide explains what it says, what it doesn't say, and where to start. It is the first post in our series on AIRA. The later posts go deeper into each part.

What is the AI Reference Architecture (AIRA)?

The AI Reference Architecture (AIRA) is a framework from the Digital Transformation Agency that gives Australian Government agencies a shared structure for designing, building, buying and governing AI systems. It turns government AI policy into reusable architectural patterns, so each agency doesn't have to interpret the same obligations on its own.

Think of it as a common map. It names the parts every AI system has, the qualities those parts must show, and the human controls that sit across all of them. Agencies then use that map to design their own systems.

AIRA is deliberately broad. It applies whether an agency uses a vendor-managed AI service, builds its own application, or develops its own models. It covers traditional machine learning, generative AI, agentic AI and emerging frontier capabilities.

What AIRA is not:

• Not a product list. It does not name or endorse any vendor, platform or tool.
• Not a finished design. Each agency still creates its own solution architecture.
• Not a substitute for problem framing. It is meant for use after the problem and the case for AI have been validated.

Put simply:

AIRA is a shared map of what every AI system needs. Each agency still draws its own design.

Why did the DTA publish AIRA now?

Australian Government agencies are being asked to adopt AI faster and govern it more carefully at the same time. AIRA is the first document that connects those two expectations at the level of system design.

Three developments set this up:

• The APS AI Plan (November 2025). It asked every agency to appoint a Chief AI Officer by July 2026 to drive adoption, and committed to tracking and reporting AI use across the public service.
• The Policy for the responsible use of AI in government, version 2.0 (effective 15 December 2025). It strengthened requirements on transparency, accountable ownership of AI use cases, risk assessment and incident management.
• A fragmented rulebook. Ethics principles, legislation, technical standards and security frameworks each say something about AI. Agencies were left to reconcile them alone.

AIRA acts as a translation layer between those rules and agency delivery. The DTA's stated aim is to make the consequences of design choices about data, models, integrations, vendors and human oversight visible before an agency commits to a solution. In the DTA's words, those consequences "are often not visible until after commitments have been made."

Is AIRA mandatory for government agencies?

No. The DTA says using AIRA is voluntary. It supports agencies to meet their existing requirements, such as the responsible use policy and the AI technical standard, but it does not replace those requirements or add new mandatory ones.

In practice, "voluntary" may not stay optional for long. AIRA gives architecture review boards, cyber assurance teams and procurement functions a shared checklist. Once a review board starts asking how a proposed system maps to AIRA, alignment becomes the expected answer.

AIRA is voluntary. Expect review boards to ask how your system maps to it anyway.

AIRA also does not mandate any product, platform or design pattern. It follows the Australian Government Architecture principle that each agency chooses the technology that fits its own needs, while using AIRA's shared structure and language.

What are the four parts of AIRA?

AIRA is built from four parts that work together: a functional stack, communication, trustworthiness and assurance, and human agency, oversight and control. The first two describe what an AI system is made of. The last two describe how it earns and keeps trust.

1. The functional stack. These are the working parts of an AI system, from the screens and channels people use down to the computers it runs on. It has five layers, explained in the next section.

2. Communication. This is the connective tissue. It covers how parts of the system talk to each other and to other systems, agencies and partners, securely and with clear trust boundaries. It includes identity, APIs, connections to legacy systems, and the protocols that let AI agents talk to other agents and tools.

3. Trustworthiness and assurance. These are nine qualities a trustworthy AI system needs, designed in from the start rather than checked at the end:

• observability
• traceability
• explainability
• validity and reliability
• safety
• fairness
• sustainability
• security and resilience
• privacy

4. Human agency, oversight and control. This covers how people stay in charge. It includes decision support, such as alerts, highlighting unusual results and routing hard cases to the right person. It also includes intervention, such as overriding the AI, pausing it automatically when limits are crossed, requiring approval before irreversible actions, and handing control back to a human.

Human oversight in AIRA doesn't mean a person approves every step. Pre-approved safeguards can act on their own, such as pausing a system or reversing a change when a risk appears. AIRA also asks designers to plan for how people really behave around automation. The DTA names "over-reliance on AI, reduced attention during prolonged monitoring and the gradual loss of human expertise" as risks to manage.

AIRA also recognises that every system sits inside four environments: the people and physical world it affects, the laws and policies it must follow, the business processes it supports, and the other hardware and software it connects to.

What are the five layers of the AIRA functional stack?

The functional stack has five layers: experience, application and orchestration, intelligence and analytics, data and metadata, and platform and infrastructure. Together they describe everything an AI system needs to run, from the conversation a citizen has with it down to the servers it runs on.

The DTA's own analogy is a building. Every building needs foundations, utilities, entrances and safety overrides. Those look very different in a cottage, a skyscraper and a warehouse. AIRA works the same way: the same layers, built to different depths depending on the job.

One detail is worth noting. AIRA says imperfect data does not automatically block AI work. It expects safeguards instead, such as tracking where data came from, signalling low confidence, adding human review points and having fallback paths.

Same layers for every AI system. The depth of each one depends on the job.

How does AIRA fit with the AI policy, the technical standard and the impact assessment?

AIRA sits between government AI policy and an agency's own solution design. The policy, standards and impact assessment say what must be achieved. AIRA shows where in the system each requirement is built and evidenced.

Here is how the main pieces relate:

• Policy for the responsible use of AI in government sets agency obligations such as accountable officials, transparency statements and risk management. AIRA helps agencies build them into system design.
• AI technical standard sets system-level requirements, including evaluation before deployment and throughout the lifecycle. AIRA helps trace each requirement to a component and a control.
• AI Use Case Impact Assessment identifies the risks of a specific use case. AIRA shows where that risk sits in the architecture and which controls reduce it.
• Australia's AI Ethics Principles describe the outcomes government expects. AIRA's trust qualities describe the system characteristics that demonstrate them.
• Security, privacy and records frameworks, such as the Information Security Manual, the Privacy Act and the Archives Act, still apply in full. AIRA defers to existing guidance where it exists.

For enterprise architects, AIRA sits at the "class of systems" level in TOGAF terms. It can be used inside TOGAF or Zachman work, then turned into a specific solution architecture for each system.

Who should use AIRA, and how?

AIRA is written for everyone who designs, builds, buys, runs or oversees AI in government, and each role uses it differently. Leaders use the four-part foundation to frame decisions. Practitioners use the detailed capabilities to design and assure systems.

AIRA itself notes that small agencies can lean on common patterns and shared services, while large agencies can use it to manage complexity and reuse components at scale.

Does AIRA matter for private-sector companies?

Yes, even though it was written for government. AIRA is a free, public, well-structured benchmark for what a trustworthy AI system should include. That makes it useful to any Australian organisation that has to justify its AI decisions to a board, a regulator or its customers.

It matters most in three situations:

• Regulated industries such as insurance, financial services and healthcare can point to AIRA as an independent reference when explaining their AI controls.
• Suppliers to government will increasingly be asked how their AI maps to AIRA. Contractors are already expected to disclose their own use of AI.
• Any organisation choosing an AI vendor can use AIRA's structure to compare offerings on the same terms.

The same principle applies outside government: the controls should match the risk. An internal productivity assistant needs far less than an AI that makes decisions about customers.

Where should you start with AIRA?

Start with one real use case, not the whole framework. AIRA itself recommends beginning with the four-part foundation and adding detail only as the problem, requirements and constraints become clear.

A practical first pass looks like this:

1. Pick one use case that has already passed problem framing and an impact assessment.
2. Set its risk tier. A drafting assistant and an eligibility decision need very different depth.
3. Decide how you will evaluate it before choosing technology, including against today's human process.
4. Design the human oversight for that tier: who reviews what, what pauses automatically, and what can never happen without approval.
5. Check traceability. Could you reconstruct any decision months later? An audit log built for reviewers, not just engineers, is what makes that possible.
6. Map your dependencies: where data goes, which models you rely on, and how you would exit.
7. Then choose your path: build, buy or blend. Score every vendor with the same criteria.

Each of these steps gets its own post in this series.

Start with one use case and the four-part foundation. Add detail only when the problem needs it.

AIRA's oversight patterns already run in production

AIRA's oversight patterns are not theoretical. Production agent platforms already run them: agents that escalate to a human queue when a threshold is crossed, approvals required before irreversible actions, and a full activity trail of who decided what.

This is how Avesta AgentOS runs AI agents for our clients today, with Relay as the human oversight layer. We've written about the pieces in detail: which agent actions need human approval, what an agent audit log should record and how guardrails limit what agents can do.

If you're mapping an AI use case to AIRA, or need to show how your AI product maps to it, book a discovery call and we'll work through it with you.

Sources

• Digital Transformation Agency, AI Reference Architecture: A new blueprint to help government agencies design AI systems, 30 October 2026
• Digital Transformation Agency, AI Reference Architecture, Version 1.0, 2026 (CC BY 4.0), available at digital.gov.au
• ACS, Version 2.0 Policy for the Responsible Use of AI in Government, December 2025
• GovAI, Establishing Chief AI Officers across the APS