AI Reference Architecture

Appendix A: Key roles in AIRA

AIRA is intended to support a broad range of stakeholders across government, from executives and governance bodies to architects, engineers, designers and operational teams. While different roles engage with the architecture in different ways, it provides a common frame of reference for planning, building, assuring, operating and governing AI systems. By establishing shared terminology, patterns, expectations and controls, the architecture helps align decisions across organisational boundaries, improve consistency, reduce duplication and ensure AI initiatives are delivered in a way that is secure, interoperable, trustworthy and aligned with whole-of-government objectives.

A1. Using AIRA from different practitioner perspectives

AIRA provides multiple levels of abstraction, allowing practitioners to engage at the level of detail appropriate to their needs.

The foundational view provides a common entry point to the architecture and, for some audiences, may be the primary level of engagement with AIRA. It supports conceptual alignment and decision-making across disciplines. Each concept is elaborated in the sub-sections and further decomposed in the detailed architecture. Readers can use Figure 1 to locate the parts of AIRA relevant to their work, and to understand how those parts relate to the whole before engaging with them in detail.

Over time, practitioners may use AIRA to explore concerns from their area of responsibility across the architecture. A cyber assurance practitioner may start with Security and resilience to see how security risks can arise across the Functional stack and Communication, then explore architectural approaches that may help mitigate those risks. Similarly, an Experience designer may do a deep dive on the Experience layer to examine how Trustworthiness and assurance can be implemented in user-facing capabilities.

The abstraction levels allow practitioners to engage with the architecture at the level of detail most relevant to their role while working from a shared architectural model.

A2. Leadership, governance and enabling functions

1. AI leadership and accountability. This includes Chief AI Officer (CAIO), Accountable Officials (AO) and relevant roles such as Chief Information Officer (CIO), Chief Technology Officer (CTO), Chief Data Officer (CDO), Chief Information Security Officer (CISO) and Chief Risk Officer (CRO). They use the reference architecture to inform AI strategy, governance, investment and risk conversations with IT business leaders, subject matter experts and technical leaders. Their sponsorship provides the authority and funding that empowers IT teams to implement the architecture while confident that AI initiatives align with whole-of-government expectations. Relevant chief roles engage with AIRA through their subject matter expertise. For example:
   • CIOs and CTOs use AIRA to align AI initiatives with enterprise architecture, integration patterns and platform strategy across the functional stack
   • CDOs use AIRA to ensure data governance, quality, provenance and access controls are embedded in the data and metadata layer
   • CISOs use AIRA to assess security, resilience and trust boundaries across the functional and communication stack
   • CROs use AIRA to understand how risks are distributed across the architecture, including dependencies, assurance gaps and systemic risk across trustworthiness domains
2. Product managers/delivery leads use AIRA to translate whole-of-government expectations into scoping and delivery decisions. They use it to plan and govern delivery in a way that avoids bespoke one-off solutions, clarifies what can be reused or sourced as shared capability and ensures that assurance, operational readiness and change management activities are built into delivery plans from the start.
3. Governance, assurance and compliance. This includes architecture review board, cyber assurance body, privacy officers, legal counsel, and internal audit and risk committees. They use AIRA as a common evaluation baseline when assessing AI solutions seeking agency approval or Authority to Operate. Architecture review and cyber assurance bodies assess technical conformance and security posture. Privacy officers, legal counsel, internal audit and risk committees use AIRA to review governance and control expectations consistently across AI systems. Each agency will have its own review and assurance processes. AIRA is designed to support, not replace, those processes.
4. Operations and service reliability functions use AIRA as a benchmark to assess the suitability of their existing control infrastructure, run and operate practices, identify capability gaps and prioritise improvements for AI-enabled services.
5. Procurement and sourcing functions use AIRA to compare and evaluate products and services. This helps agencies make informed sourcing decisions and align solutions with government standards and architectural objectives.
6. Information management functions use AIRA to articulate and apply consistent information‑management expectations for AI systems, clarifying how recordkeeping, retention, provenance and archival obligations should be met across the AI lifecycle, including for AI‑generated artefacts and AI outputs used in decision-making

A3. Technical and specialist practitioners

7. Architects, including enterprise, domain, solution and security architects, use AIRA as a whole-of-government baseline for structuring AI solutions. They use it to align on common terminology and boundaries, select and compose capabilities across layers, identify required assurance evidence early and document solution designs in a way that is comparable across agencies.
8. User experience (UX) and service designers use AIRA to connect ‘responsible AI’ obligations to concrete service design considerations. They use it to identify where transparency, user understanding, accessibility, contestability and human oversight should be designed into user journeys.
9. Application engineers, software engineers and AI engineers use AIRA for integration and implementation guardrails when incorporating AI capabilities into applications. They use it to understand expected patterns for AI service consumption, orchestration boundaries and the operational and assurance considerations that need to be built into the application layer.
10. ML engineers use AIRA to standardise how models are packaged, deployed and operated in production environments. They use it to align on model serving and run-time patterns, performance and reliability expectations, integration points with application/orchestration and the cross-cutting requirements for monitoring, traceability, security and safe model replacement.
11. Data scientists and AI model developers use AIRA to understand the assurance and governance expectations that should be addressed during problem framing, model selection, experimentation and evaluation. They use it to align evaluation methods and artefacts so that downstream deployment, review and audit activities are easier and more consistent across agencies.
12. Data engineers use AIRA to design and operate the data foundations that AI systems depend on. They use it to align data pipeline and platform patterns with whole-of-government expectations for data governance, quality, metadata, lineage, access control and sharing – supporting interoperability and reducing one-off interpretations of privacy, sovereignty and retention requirements across agencies.
13. MLOps, DevOps and platform operations engineers use AIRA to operationalise AI systems consistently. They use it to implement repeatable pipelines for deployment and change management of models, prompts, configurations and code, establish observability and incident response practices suited to adaptive systems and produce evidence needed for reliability, traceability and lifecycle assurance.
14. Infrastructure and platform engineers use AIRA to understand workload patterns and baseline controls for hosting and operating AI systems. They use it to assess deployment models, enforce tenancy and trust boundaries, align with cyber and privacy requirements, and provide shared platform capabilities that multiple AI services and teams can reuse.