How activIT’s Managed AI Services Responds to the Australian Government’s Questions to Ask AI Suppliers in 2026

The Australian Government has published a checklist through ai.gov.au titled Questions to ask AI suppliers. It’s designed to help organisations think through what actually matters before adopting an AI product or service – safety, accountability, data handling, human oversight, exit, and continuity.

The checklist was produced by the Department of Industry, Science and Resources to help Australian businesses – particularly those without in-house AI or legal expertise – make informed decisions when engaging AI suppliers.

We think the checklist is a fair test of a supplier. So we’ve written up how we answer each of the nine sections in the checklist for our Managed AI Services offering, which is designed to help small and medium businesses adopt increasingly advanced AI capabilities responsibly without having to do it all in house. We become the outsourced AI department, in effect. Where our position is clear, we’ve stated it. Where our approach is still developing, we’ve said so.

This is the plain-English version to help break down a complex topic into answers that are easy to digest. If you want the position captured against our contract clauses (for procurement, risk, or compliance review), see the reference table at the end of this article.

1. Managing risks and potential harms

Risks we’ve identified as a supplier

The main risks in delivering managed AI services aren’t just technical. They are behavioural, regulatory, and vendor-driven. We’ve thought about the ones that matter for small and medium businesses.

1. AI unpredictability. No amount of governance eliminates the possibility of an AI model producing an incorrect, biased, or unexpected output. It’s a fundamental characteristic of the technology. We manage it through Risk-Based Governance and human-in-the-loop requirements.
2. Client-side accountability gaps. Clients sometimes underestimate that they remain accountable for AI-supported decisions in their own business. Our Acceptable Use Policy and governance training address this directly.
3. Third-party vendor changes. Microsoft, OpenAI, and Anthropic all update capabilities frequently. Those changes can undo or invalidate delivered work. We monitor vendor release notes and reassess affected use cases.
4. Regulatory drift. The Australian AI regulatory landscape is moving fast. We build governance updates into the ongoing service and align to Australian standards and Five Eyes cyber guidance.
5. Client-driven risk pressure. Clients occasionally request use cases that exceed acceptable risk. We collaborate first, and where necessary, we decline.
6. AI licensing consumption. Consumption-based Copilot Studio credit models can accumulate cost quickly. We recommend prepaid capacity and monitor usage on your behalf.
7. Reputational risk. We start with deliberately low-risk use cases and expand capability in staged, evidence-based steps.
8. Novelty as an emerging service. Managed AI Services is an emerging capability, and elements will continue to evolve. We’re transparent when they do.

How we monitor and respond to emerging risks

Ongoing Managed AI Services runs on a quarterly cadence. We monitor AI tool and agent usage patterns, monitor billing limits, and update the Governance Framework and Acceptable Use Policy as capability, risk, and regulatory expectations evolve.

Safeguards for high-impact failures

1. Documented kill-switch procedures for delivered agents.
2. In-agent scoping to deny out-of-scope requests.
3. For critical use cases, a manual or documented fallback procedure so the business is not crippled if AI is unavailable.
4. Emergency response for unexpected AI behaviour, including disablement.

Incident reporting and escalation

We don’t provide 24/7 monitoring of every AI agent, prompt, or output. Staff are trained through the Acceptable Use Policy to recognise incidents and escalate them. Escalation flows to the AI Governance Owner and then to us via our standard intake, where it’s triaged internally according to impact.

Critical incidents (cyber-related or data leak) are triaged and processed under our existing cyber incident response, which follows established playbooks. AI-specific incident playbooks are in development.

2. Transparency and explainability

Why the AI produced a particular output

Every AI agent we deliver is designed to cite sources during operation where the capability supports it. Where logs are available, they can be pulled up for review. Not every model or use case supports full traceability – some models are inherently harder to interrogate – but where the capability exists, you can see it.

Documentation on capabilities and limitations

1. The AI Tool Register documents every AI capability delivered – including intended use, sensitivity classification, model or platform, assessment outcome, and required human oversight.
2. The Build Blueprint captures the technical design, model dependencies, integrations, guardrails, and known limitations of each agent.
3. Staff can query the AI Safety Advisor for guidance, and the Safety Advisor escalates to the AI Governance Owner if required.

How we help users avoid overreliance

Our overriding design principle is that AI should amplify the user, not diminish them. To keep the human meaningfully in the loop:

1. We design for proportionate oversight – heavier controls where impact and privacy risk are higher.
2. We require agents to cite sources where the capability supports it.
3. We position AI as coaching and mentoring the user, not producing outputs the user rubber-stamps.
4. We explicitly require human review of outputs that affect decisions, people, safety, or rights.

We want the AI to help a team member become better, not to dumb them down. That principle sits behind every governance decision we make.

Review or complaint process for affected persons

Managed AI Services is designed so that AI does not make decisions affecting people, safety, or rights without human approval. Where a person believes they’ve been affected by an AI-supported outcome, the client’s own policies and complaints processes apply – because the client is the accountable entity for the use of the tool. We’re the service provider that helps design, govern, and refine the use case; we’re not the decision-maker. Where a complaint reveals a governance gap, we help reassess the use case, update the agent, or adjust the AI Register entry.

3. Accountability, roles and integration

Who is accountable once the system is live

The client is the accountable entity for the use of AI in their business. We are a service provider assisting with governance and delivery.

In many engagements we effectively operate as an outsourced AI Governance Owner function, with a client-side Liaison who is involved in a similar capacity to a nominated IT liaison – attending quarterly reviews, communicating governance decisions internally, and coordinating internal approvals.

Our responsibilities across the lifecycle

Who built the AI model or components

Managed AI Services predominantly uses Microsoft Copilot and Copilot Studio. The underlying foundation models come from OpenAI and Anthropic, licensed and operated by Microsoft. Model versions, capabilities, and training data are controlled by the model vendors. Every agent’s underlying model and version is captured in the AI Tool Register and Build Blueprint.

Where Microsoft updates or replaces an underlying model, we track those changes through Microsoft’s public release channels. Material changes are communicated as soon as practical; non-material changes are covered in the quarterly review cadence.

Named contacts and escalation

Managed AI Services is delivered by a team, ultimately led by the Managing Director. Client-facing accountability sits with the assigned governance or delivery lead. If you’re unhappy with a decision or outcome, the escalation path leads to the Managing Director.

4. Data training, use and security

Where our AI is trained and what data was used

We don’t train foundation models. Training of the models that power Copilot and Copilot Studio is performed by their vendors (OpenAI, Anthropic, and Microsoft), not by us.

Data collected, stored, or processed

1. Client Data – your operational data, documents, records, and interactions used inside Managed AI Services – is processed within your Microsoft 365 tenant, including Azure Container Apps and, where used, on-premise MCP relays.
2. Where data sovereignty cannot be maintained for a specific use case, only low-risk use cases that do not carry a risk of breaching the Privacy Act 1988 may involve overseas processing. That decision is documented in the AI Tool Register.
3. We collect governance metadata, reporting artefacts, and monitoring logs as part of delivery, stored internally. We do not currently expect to retain this data beyond seven years.

Whether client data is used to train AI models

Client data is not used by us to train, tune, improve, benchmark, or develop AI models, AI agents, or any commercial AI service we offer to other clients. That position is contractually captured.

Data shared with third parties

We don’t share Client Data with third parties as part of our own AI processing, and we don’t run it through any AI system on our end. Delivery happens on Microsoft-hosted infrastructure under Microsoft’s terms; our AI tools, including Microsoft Copilot and Copilot Studio agents, only ever process operational metadata — things like filenames, source identifiers, usage, and delivery status — never Client Data itself.

Where consultation or configuration work requires it, you may send us specific Client Data directly (for example, a policy document or knowledge source). This is reviewed manually by our personnel and is never passed through an AI system.

Where data is stored or processed, including offshore

Client Data is normally processed within your own Microsoft 365 tenant, governed by your tenant’s configuration and data residency settings, and any on-premise systems you operate.

Where consultation or configuration work requires you to send us specific Client Data directly, it’s reviewed manually — never through an AI system — and retained only as long as needed to complete that work. Where overseas processing occurs for a low-risk use case, that’s decided at the assessment stage and documented in the AI Register.

Ability to limit, configure, or turn off AI features

Clients don’t have direct access to modify AI capabilities we deliver. This is intentional – we want the controls under proper governance, not adjusted informally. You can request changes at any time, and we action them.

Ownership of inputs and outputs

You own the data you input into AI capabilities delivered under Managed AI Services, and you own the outputs produced by those capabilities from your inputs. We retain ownership only of the Governance Documents, methodology, and underlying intellectual property used to deliver the service.

How personal and sensitive data is protected

Every use case is assessed for sensitivity at the beginning of its lifecycle. Sensitivity is captured in the AI Register, Build Blueprint, and referenced in the Governance Framework and Acceptable Use Policy.

Where a use case involves personal or sensitive data, additional controls are applied. These are case-dependent, and may include:

1. Reducing the capability of the AI (favouring lower-risk Reader or Advisor classes rather than Operator).
2. Clear labelling of data source and sensitivity.
3. In-agent scoping and refusal behaviour for out-of-scope requests.
4. Human review and approval requirements.
5. Privacy Impact Assessment where sensitive personal information is involved.

No single control is infallible; the aim is layered protection matched to the impact of the use case.

Reviewing what data the AI is using

1. Use case assessment: what data will the AI access, and for what purpose.
2. Build stage: captured in the Build Blueprint and Knowledge Sources.
3. Operation: cited in responses where the capability supports it.
4. Retrospective: logs, where the underlying capability supports them.

What happens to data on exit

1. Delivered artefacts remain available for continued use.
2. Delivered agents remain in place on your systems. They end up “abandoned” from our support perspective but remain usable.
3. Client data is purged from our systems within 12 months of termination, or sooner where reasonable.

Licensing agreements to be aware of

1. AI-related licensing (Copilot per-user, Copilot Studio credits, other AI vendor products) is quoted and billed separately, subject to the vendor’s own terms.
2. Governance Documents delivered by us are subject to a non-exclusive, non-transferable, perpetual internal-use licence.

5. Testing, monitoring and performance

How AI capabilities are tested before deployment

Every AI capability moves through a defined lifecycle before deployment:

1. Assessment under Risk-Based Governance.
2. Design captured in the Build Blueprint.
3. Build.
4. Testing, including pilot use, edge case testing, red teaming, and human sign-off.
5. Client testing – you’re actively encouraged to test the capability before it enters controlled use.

Testing is iterative. AI capabilities are refined based on what surfaces during testing.

How performance is monitored once live

1. Governance cadence: quarterly review of AI tool use, agent use, and usage patterns.
2. Client feedback: automated and verbal/written, captured through the quarterly rhythm and via direct escalation.
3. Model tooling: results from Copilot Studio, Power Platform, and other underlying tools are reviewed as part of ongoing management.

How performance degradation is detected

Through the governance cadence and through client feedback. Formal automated performance measurement is under development.

How updates are managed and communicated

1. Governance Framework and Acceptable Use Policy updates are version-controlled, run through our labs first, and communicated via email and the quarterly cadence.
2. Agent-level updates are open to client feedback and iterative development. Changes are captured in the Build Blueprint.
3. Material vendor changes (Microsoft, OpenAI, Anthropic) are communicated as soon as practical if the change affects a client capability.

Reviewing or rejecting changes

1. Governance Framework and Acceptable Use Policy updates are supplied under licence. You can accept an update or terminate the service. Updates aren’t individually rejectable.
2. Agent-level changes are under your control through iterative development. Feedback is welcomed and applied.

6. Human oversight and control

Where people review or approve AI outputs

Every AI use case is classified as Reader, Advisor, or Operator. Operator capabilities are the highest-impact class and require explicit human approval before an action is applied. Human-in-the-loop is a core design requirement of the service.

Ability to pause, override, or switch off

1. Documented kill-switch procedures.
2. In-agent scoping to deny out-of-scope requests.
3. We retain pause/stop rights where governance, risk, or safety concerns require it.
4. Advisory and Delivery Support includes emergency response for unexpected AI behaviour, including disablement.
5. Direct client access to modify AI capabilities isn’t provided. You can request pause, override, or disablement at any time, and we action it.

Training and guidance provided to staff

1. Instructor-led AI acceptable use training and quiz during onboarding.
2. Practical AI governance and adoption training for department heads, managers, admin, and directors.
3. Periodic training refresh through the quarterly cadence.
4. Additional targeted training for high-risk use cases, proportionate to capability.

If the AI fails or produces unexpected results

1. Documented kill-switch procedures.
2. In-agent scoping and refusal behaviour.
3. Manual or documented fallback procedures for critical use cases.
4. Reassessment under Risk-Based Governance when unexpected behaviour is identified.
5. Emergency response as part of Advisory and Delivery Support.

7. Fairness, inclusion and broader impacts

Bias and fairness at the assessment stage

Every AI use case is assessed for sensitivity, use context, and potential impact before it’s built or deployed. Where a use case involves outcomes that may affect people, we apply enhanced controls, human review requirements, and proportionate oversight. Where sensitive information or personal information is involved, a Privacy Impact Assessment may be conducted.

Fairness monitored over time

Formal, ongoing fairness monitoring for individual agents is under development. Today, fairness is reassessed when an agent is materially changed or when concerns surface through client feedback or the quarterly cadence.

Who could be negatively affected

Impact assessment considers customers, staff, and third parties. Higher-impact use cases attract stronger controls, tighter boundaries, or restricted approval. Where a use case cannot demonstrate acceptable fairness controls, we may decline to proceed.

Feedback and complaints processes

1. Clients raise feedback and complaints directly to us. We work with you to resolve them. Because AI is unpredictable, our approach is best-effort and iterative – outcomes need tweaking to get right.
2. Affected persons (customers, staff, third parties) escalate via your own complaints and review processes. We support you in reassessing the use case if a complaint reveals a governance gap.

8. Exit, decommissioning and continuity

What happens if you stop using the service

1. Managed AI Services may be terminated with 30 days’ notice aligned to the end of a calendar month.
2. You retain a perpetual, non-transferable, internal-use licence to the last delivered version of the Governance Documents.
3. You retain the AI Register, use case specifications, and agent specifications.
4. Delivered agents remain in place on your systems and remain available for continued use.
5. Unused AI Services Blocks at the effective date of termination are forfeited.

Exporting delivered artefacts

Delivered artefacts remain in place on your systems and are provided in commonly used formats. There’s no requirement to “export” them because they never left your environment.

Data deletion after exit

Client data associated with Managed AI Services is purged within 12 months of termination, or sooner where reasonable, subject to legal, regulatory, backup, audit, security, or professional retention obligations.

If the product is retired or stops working unexpectedly

Delivered artefacts continue to operate under your own environment and licences. Where a specific AI capability becomes unavailable – for example, because Microsoft has retired the underlying model – the fallback or manual process documented at build time takes effect.

Continuing to operate without the AI

Higher-risk or higher-capability use cases are only approved for use if there’s a suitable fallback or manual method that doesn’t rely on the AI tool. It would be folly for a business to rely on any AI tool 100%.

9. Environmental sustainability

Managed AI Services is designed with token efficiency in mind:

1. Token-efficient prompts.
2. Appropriate model selection – we avoid using large models where a smaller model is sufficient.
3. Reducing the need for AI to reason over everything by using automation first – for example, handling 80% of data via pattern matching or regex before passing the remainder to AI.

Environmental sustainability metrics for AI usage aren’t currently formalised in the service. The overall design principle is to reduce unnecessary consumption and match the model to the task.

Regulatory and standards alignment

Managed AI Services is designed to align with:

1. Privacy Act 1988 (Cth), including reforms taking effect from December 2026.
2. The Australian Government’s Voluntary AI Safety Standard and Introducing the National Framework for Assurance of AI in Government.
3. SMB1001:2026 requirements for AI governance systems.
4. Five Eyes cyber agencies’ joint guidance on AI risk and adoption.

Our approach is deliberately proportionate for small and medium businesses.

Auditability and attestation

Your auditors, insurers, regulators, or advisors may inspect the AI Register, review Build Blueprints, see governance framework version history, and obtain a written attestation from us confirming your engagement, delivered artefacts, and operating cadence. Attestations don’t warrant specific outcomes or compliance positions – they confirm what’s been delivered and how the service operates.

Up to two attestations per calendar year are included in Ongoing Managed AI Services. Additional attestations are delivered from AI Services Blocks.

Where these positions are captured in our contract

For the diligent reader, here is the traceability table linking positions in this article back to specific clauses in our Managed AI Services Terms and Conditions.

This document is current as at the date of publication. It reflects our current service model, delivery approach, and governance framework, all of which continue to evolve. Reviewed annually or sooner where a material change occurs. Contact your activIT contact or info@aitsys.com.au to raise questions or request further detail.

Want to see how this applies to your business?

Managed AI Services is designed for small and medium businesses that want to adopt AI responsibly, without having to build the governance function in-house. If you’d like to see how we’d apply this approach to your organisation, we’re happy to walk through it – no obligation, and we’re happy to spitball on any AI ideas you already have in mind.

Book a conversation or call us on 1300 228 480.

If you’d like more of our thinking first, our Resource Hub has practical guides on AI governance, agent adoption, and what to look for when choosing an AI approach for your business.