Scenario 1. Enable AI within an existing vendor platform
This scenario examines how agencies can enable AI capabilities within an existing enterprise environment where much of the technology stack is predefined and vendor managed. A common example is Microsoft 365 Copilot (Copilot), where agencies assess whether and how to enable AI capabilities within an already deployed Microsoft ecosystem.
Key challenges
- Key challenges for practitioners: Enabling Copilot can appear simple at the user level, however it is complex. It depends on a stack of vendor-managed components, enterprise data sources, configuration settings and integration pathways.
- Key challenges for agencies: Agencies see potential gains in drafting, summarisation, analysis and information retrieval, but remain uncertain about what they are adopting, where control sits, how risk is shared between vendor and agency, what assurance evidence is available, what organisational and technical conditions need to be in place before rollout, whether the benefits will justify the costs, and how value for investment can be demonstrated.
How AIRA supports this scenario
AIRA can help structure broad AI adoption decisions into an architectural assessment. It articulates Copilot into layers and domains rather than treating it as a single black box. This helps agencies identify control boundaries, dependencies, assurance gaps and rollout conditions before enabling the service.
In summary, AIRA supports this scenario as follows:
- Map assurance evidence against AIRA: Copilot introduces capabilities, data flows and inference pathways that may not be fully covered in the existing assurance posture. Map available assurance evidence, such as the Infosec Registered Assessors Program (IRAP) assessment and vendor documentation, against the functional and communication stack. This helps agencies identify where assurance is strong, where it is partial and where additional assessment may be needed.
- Map safeguards against AIRA: Assess how Copilot's operational controls, such as content safety filters, scope constraints and access boundaries, align with trustworthiness and assurance domains across the functional and communication stack. Identify where vendor safeguards are present, where they are insufficient for the agency’s context and where additional agency controls are needed.
- Map agency control points across AIRA: Map agency control points across the functional and communication stack to reveal what agencies can and can’t control. For example, vendor model updates are outside agency control, and models are hosted outside agency tenancy. A primary control lever for agencies is in configuring the data sources that Copilot has access to. This may inadvertently expose existing weaknesses in permissions, classification, information architecture and records management. Data hygiene and permissions remediation may be required to control access of Copilot to existing systems or objects such as SharePoint, Outlook, shared drives and data backups.
- Map what can be monitored across AIRA: Map Copilot-provided telemetry, logs and administrative tools against AIRA layers and domains to identify gaps in what could be monitored. Some aspects of the service may not be sufficiently observable to validate whether Copilot is being used appropriately.
- Define additional controls or guidance to fill gaps: Copilot may influence official work products without automatically preserving the prompts, outputs or context for recordkeeping, audit, review or future retrieval. Agencies may need to define additional controls or guidance required to meet records obligations.
- Clarify responsibility split among vendor, agency and staff: Vendor safeguards do not remove agency and individual staff accountability. Identify the responsibility split across the trustworthiness and assurance domain to clarify how responsibility is distributed among vendor controls, agency governance and staff.
- Assess automation levels and integration pathways: Copilot operates across a range of automation levels, from advisory use to autonomous agents, Power Automate or custom connectors that can trigger actions or coordinate workflows. As the surface expands, stronger controls over the action scope may be needed. Each capability can be a separate enablement decision with its own risk assessment.
- Assess long-term architectural dependencies and their consequences: Copilot is deeply integrated into the Microsoft ecosystem. This built-in integration may deliver benefits such as time-to-value and reduced integration complexity. Agencies may also wish to consider the implications for long-term dependency as part of broader sustainability and investment decisions.
- Plan staged adoption before broad expansion: Use AIRA to perform gap analysis, define a feasible deployment scope, configure controls and identify exclusions before expanding adoption. This supports a more incremental and governed rollout approach.
- Surface cost-relevant factors: Use AIRA to identify cost drivers across the architecture, including licensing, dependencies, remediation effort, lock-in considerations and charging models associated with enabled capabilities.
Figure 1: Agency control levers across AIRA when enabling Copilot
Illustrates the distribution of agency control across AIRA for this scenario. Governance remains the baseline control throughout the architecture, while some areas can be configured by the agency.
Legend:
- (G) govern
- (C) configure and govern
- (D) design, configure and govern
Detailed scenario analysis
The analysis below is based on document versions identified in the References. The key takeaway is the architecture method rather than the vendor-specific findings. As Copilot and other products evolve rapidly, agencies should obtain current evidence directly from providers and periodically reassess the architecture.
Functional stack
The functional stack of Copilot has been articulated in Table 1. It demonstrates how Copilot could be understood as a service spread across several layers of the stack, with uneven distribution of vendor control and agency control.
| AIRA Layers | Capability groups (indicative) | Vendor-managed components | Agency-configurable components |
|---|---|---|---|
| Experience | User interaction |
| Copilot surfaces in desktop, mobile and web apps, including Word, PowerPoint, Excel and Teams |
| Application and orchestration |
|
|
|
| Intelligence and analytics | Model inference |
| Where additional model options are offered, clarify with vendor whether agencies may enable or select them |
| Data and metadata | Knowledge stores |
|
|
| Platform and infrastructure |
|
| Tenant configuration, policies and access controls |
For practitioners, the main implication is assessing whether the existing Microsoft 365 environment is ready to support this additional capability. That includes permissions hygiene, classification practices, identity and access settings, compliance controls, information architecture and tenancy configuration.
Communication
Microsoft 365 Copilot introduces new communication pathways into the agency’s enterprise systems and data, including:
- Microsoft-managed integrations with:
- Microsoft Entra ID
- Microsoft Purview
- Microsoft Defender
- Azure Backup
- Microsoft 365 apps and data
- web search
- Power Automate
- Plugins
- Copilot connectors
- custom connectors
- Copilot APIs
- MCP tools and servers.
These pathways define where information can flow, where controls are applied and where trust boundaries may shift. Some of these may be configurable, while others are vendor-provided as part of the service. In practice, agencies should pay particular attention to integrations that widen the action surface or data surface, such as connectors, plugins, web search, Power Automate or custom agent features. These may materially change risk posture.
Trustworthiness and assurance
In this scenario, the core T&A concern is whether Copilot assurance artefacts are sufficient for the agency’s actual use case. Agencies may have baseline assurance for Microsoft 365 already, but Copilot introduces additional components, data flows, inference pathways and product dependencies that may not be fully covered by that baseline.
In a typical Copilot enablement, safety, observability, privacy and security tend to surface first given the vendor-managed, embedded nature of the service; agencies enabling agentic features or processing more sensitive information may find traceability, validity and sustainability equally or more material.
The following table is illustrative only and not comprehensive. It shows examples of evidence that agencies may seek and assess for T&A. The relevant artefacts need to be analysed for how completely they cover the full functional and communication stack the agency intends to enable. Not all these artefacts may be available to agencies in practice.
| AIRA Group | Key assurance questions for Copilot | Examples of vendor evidence agencies may seek |
|---|---|---|
| Observability | What aspects of Copilot use and behaviour are visible to the agency and what remains opaque? | Usage analytics, audit logs, administrative reporting, service health information, integration activity logs Agencies could map available telemetry against the functional stack (Table 1) to identify which layers and capabilities are observable and which remain opaque |
| Traceability | What evidence exists about what informed outputs, what was processed and what can later be reconstructed? | Source citation behaviour, audit records, model/version change documentation, lineage or indexing information |
| Explainability and interpretability | What information helps staff understand how outputs were formed and where their limits lie? | Service descriptions, model documentation, source references, connector documentation, known limitations |
| Validity and reliability | What evidence exists that Copilot performs consistently enough for the intended use? | Service-level quality statements, model evaluation summaries, benchmark statements, dependability information, user feedback, service availability, data quality controls related to grounding or retrieval, communication during downtime |
| Safety | Are Copilot’s built-in safeguards and service constraints sufficient for the agency’s intended uses? | Service documentation on built-in guardrails, content safety controls, limitations and known failure modes |
| Fairness | Is there any evidence about how the service performs across relevant user groups, content types or use conditions? | Process descriptions, testing summaries, fairness statements where provided, user feedback |
| Sustainability | How will product, model and integration changes affect long-term use, dependency and supportability? | Product roadmap information, model update information, support lifecycle information, connector lifecycle information, licensing and consumption-based pricing models, per-user and capacity-based charging structures, cost implications of enabling additional capabilities such as agents or connectors, and cost comparison baselines for evaluating value for investment over time |
| Security and resilience | Does available security assurance, including IRAP evidence, cover the actual Copilot components and pathways in scope? | IRAP artefacts, service security design information, security baseline documentation, connector/integration security |
| Privacy | Where may personal or sensitive information be processed and are protections sufficient for the information classes involved? | Data handling documentation, privacy information, records of data access controls |
Agencies should distinguish between assurance evidence, artefacts that allow verification of vendor claims, and active safeguards, which are controls that constrain system behaviour in operation. Both should be assessed against the functional and communication stack, as gaps in either may leave residual risk.
A deeper analysis of T&A against Copilot’s functional components may reveal assumptions agencies need to verify with the vendor. For example, an Australian data centre commitment for Microsoft 365 data at rest does not necessarily indicate that all Copilot inference workloads are processed in Australia. Specifically, not all Copilot components listed in Table 1 process data in Australia. Some components may rely on inference infrastructure located outside Australian jurisdiction, and other factors may influence data processing, such as when the LLM is under high load. Architecture can help agencies verify the geographic scope of data processing for each Copilot component before enabling it to ensure that the resulting data residency posture is consistent with PSPF obligations for the classifications of information Copilot will access.
Similarly, available IRAP artefacts may not cover every Copilot component. Architecture can help agencies examine these distinctions more explicitly by mapping the scope of vendor-provided IRAP evidence against the full stack in Table 1.
An architecture-driven T&A analysis of this kind may be reusable across agencies as a common input to agency-specific risk assessment defined in the AI Impact Assessment Tool. Where evidence gaps remain against AIRA, architecture can help agencies assess the residual regulatory, compliance and trustworthiness risks.
Human agency, oversight and control
Copilot’s level of automation ranges from advisory use, where it offers suggestions or draft content for a human to accept, revise or discard, to more agentic use through features such as agents, Power Automate or custom connectors that can trigger actions, invoke tools or orchestrate downstream steps. Where Copilot remains advisory, the human retains full authority over the resulting work product. Where it can act on enterprise data or systems, the control surface changes materially. Agencies should identify where human intervention or override must remain possible, how action scope is constrained and which uses require explicit review or approval before enablement.
For advisory uses of Copilot, Table 3 illustrates how HAOC is split among vendor, agency and staff across T&A domains. For the vendor column, agencies may request information from the vendor about where and when humans are involved in operating the service, such as in safety monitoring, incident review and escalation handling. While many agency roles contribute to the agency responsibilities, the agency column focuses on the areas where architecture can most clearly inform agency responsibility for Microsoft 365 Copilot.
| AIRA Group | Vendor | Agency | Staff |
|---|---|---|---|
| Observability | Usage analytics and audit telemetry made available through Microsoft 365 administration and compliance tooling. |
| Use Copilot for permitted business purposes only. |
| Traceability | Audit logs may record prompts, outputs or referenced files, depending on service configuration and available tooling. Outputs are not necessarily reproducible from the same prompt. | Determine what audit evidence is available to the agency and what gaps remain. Define recordkeeping requirements for inputs and outputs. Define use cases of Copilot where reproducibility is required but cannot be supported through surrounding controls. | Keep records where agency policy requires it. Do not assume a Copilot output can be reproduced later in the same way. Capture outputs relied on for business purposes in line with agency recordkeeping rules. |
| Explainability and interpretability | Source citations may indicate which files or messages were referenced. Outputs grounded in retrievable Microsoft 365 data may support partial reconstruction of the basis for an answer. | Explain in plain language how Copilot works, what it can do and where its limitations lie so that staff can use it appropriately and with informed judgement. | Be able to explain, in plain language, how Copilot informed your work before using it in consequential contexts. |
| Validity and reliability | Microsoft’s internal testing and quality assurance at the service and model level may not be fully visible to customers. | Define test cases and validation approaches appropriate to intended use. Restrict use in contexts where output validity and reliability cannot be sufficiently validated. | Check sources. Apply additional validation where outputs may inform consequential decisions. |
| Safety | Content safety filters and built-in guardrails may reduce some harmful outputs, but they do not remove agency responsibility for safe use in context. | Identify which safety risks are addressed by vendor controls and which remain. Determine whether agency data or workflows require additional controls before Copilot is used with them. | Apply agency safety-related guidance when using Copilot and report unsafe outputs. |
| Fairness | Microsoft may conduct internal fairness testing, but agency visibility may be limited. | Define fairness test cases relevant to the agency context and consider whether agency data or usage patterns introduce additional fairness risks. | Apply judgement when interpreting outputs, be alert to prompts or inputs that may contribute to biased outputs and report outputs that appear biased. |
| Sustainability | Ongoing model updates, service improvements and product roadmap decisions are managed by Microsoft. | Plan for ongoing product changes, licence costs, support arrangements and change impacts arising from the vendor roadmap. Assess where agency dependencies on Copilot create lock-in or require contingency planning. | Adapt to updated guidance, features and limitations as the service changes over time. Use approved workflows rather than creating unmanaged dependence on Copilot for critical tasks. |
| Security and resilience | Microsoft provides security controls and service assurance artefacts, including IRAP-related evidence where applicable. | Configure access, permissions and relevant security controls. Assess residual security and resilience risks that remain after vendor controls are applied. | Follow agency security policies and approved access conditions. Do not use Copilot to process information or tasks outside approved security settings. |
| Privacy | Microsoft 365 controls such as labels, permissions and compliance features can help govern what Copilot can access and surface. | Identify privacy risks that remain outside vendor controls. | Apply agency privacy, classification and handling requirements when using Copilot. |
Across the functional, communication, assurance and oversight analyses above, the gaps inform a staged approach: enable first where agency control is direct, assurance evidence is adequate and use remains advisory; defer or constrain uses where the action surface is wider, evidence is partial, or oversight cannot yet be supported by available telemetry; and exclude uses where gaps cannot be remediated within acceptable risk.