A short version. The decision is fit, between the firm's delivery model and the regulator, the data, and the operating posture the buyer needs to keep after the consultant leaves. This article is the framework: five evaluation axes, eight questions to ask before the statement of work, and three archetype-workload walk-throughs (APRA-supervised bank, AHPRA-bound clinical operator, Commonwealth agency on PROTECTED data) that show how the framework resolves in practice.
For a chief risk officer, chief data officer, or head of digital making a defensible engagement decision, the binding question is structural: which firm's delivery model produces the audit trail, the accountability transfer, the operational posture, and the exit clauses that hold under the regime the workload actually runs under. Reputation, head count, and category rank are signals, but they are the wrong starting variables. The right starting variables are regulator-fit and operating-posture.
The five axes below are not new. They are the same questions any chief risk officer at an APRA-supervised entity already asks about every third-party provider, applied to the AI consulting category. The framework is intentionally firm-agnostic because the fit question (between delivery model and regulation) is decision-critical in ways that reputational ranking is not.
The five axes
Axis 1: Regulatory framework fluency
The Australian AI regulatory landscape is layered, not unitary. A production AI system in a bank touches three separate regimes simultaneously (CPS 234's information-asset perimeter, CPS 230's supplier-risk inventory, and APRA's Financial Accountability Regime linkage to CPS 234 obligations), each with its own control points and its own audit trail. Real fluency means a delivery partner who can name the control test each regime expects and map it onto the engagement before the first hour of build, not list the regulator names as marketing keywords. The regimes that matter, verified against primary sources as of 19 May 2026 (every regulator URL below resolves to that regulator's authoritative page, and a buyer should verify each at the moment of contracting since regulatory updates are continuous):
APRA CPS 234 Information Security is in force since 1 July 2019. No formal amendments to CPS 234 itself, but the regulatory environment has tightened: APRA's June 2025 letter to RSE (superannuation) licensees required identification of FAR Accountable Persons for CPS 234 compliance by 31 August 2025 [primary-source], a sharpening of individual-accountability expectations the wider APRA-regulated industry should read for direction. AI systems are not carved out of CPS 234's information-asset perimeter. The implementation pattern is covered in detail in the APRA CPS 234 AI implementation checklist.
APRA CPS 230 Operational Risk Management has targeted amendments finalised 30 April 2026, in force from 1 July 2026. For AI deployments, CPS 230 brings resilience and supplier-risk expectations alongside CPS 234's information-security ones. AI failures can involve both standards, not one or the other.
OAIC AI guidance covers the October 2024 publications on commercially-available AI products and on developing and training generative AI models. The Privacy and Other Legislation Amendment Act 2024 introduced amendments around substantially-automated decision-making that commence 10 December 2026; from that date, privacy policies will need to set out the types of personal information used in such decisions where they have a legal or similarly significant effect.
AHPRA's AI guidance, "Meeting your professional obligations when using Artificial Intelligence in healthcare", published August 2024, applies to medical practitioners, dentists, optometrists, nurses, pharmacists, psychologists, and the rest of the registered health professions. Five key principles, with the binding one being accountability: the registered practitioner remains responsible for clinical decisions assisted by AI.
IRAP and the Information Security Manual (ISM): the current ISM edition is March 2026; the ISM is updated quarterly so the cited edition rotates between contracting cycles. For Commonwealth data classified at PROTECTED and above, IRAP assessment of the underlying environment is the threshold expectation. State-government workloads increasingly cite IRAP alignment even where not strictly mandated.
Privacy Act APP 8 (cross-border disclosure) is the accountability principle. The November 2024 Privacy and Other Legislation Amendment Act introduced a certification-style cross-border mechanism for prescribed countries; the principle that the disclosing entity remains accountable for the overseas recipient's handling of the information remains intact.
The AU AI Ethics Framework comprises the eight voluntary principles published by CSIRO's Data61 with the Department of Industry, Science and Resources. Updated 21 October 2025 with the Department's "Guidance for AI Adoption" introducing six essential practices that evolve the framework and the ten guardrails in the Voluntary AI Safety Standard.
A delivery partner who treats all of these as marketing keywords is a different proposition from one who can describe the control-test plan each regime expects, with sample artefacts. "We're APRA-aligned" is a marketing answer. "Here are the CPS 234 information-asset register entries we would build for this workload, here is the three-lines-of-defence model we would apply, and here is the 72-hour incident-notification posture we would recommend for the AI system" is a delivery answer. Ask the question. Listen for the answer-shape.
Axis 2: Data residency posture
For most Australian regulated workflows, the data-residency question is not "is it in Australia" but "where in Australia, on whose infrastructure, under whose operational control". The choice the consulting partner has made for their own working infrastructure is informative: a firm whose own production environment runs in a hyperscaler region they do not control is unlikely to architect tighter for the client than they are for themselves.
Three postures appear in practice: hyperscaler-hosted in an AU region (the default for most large consultancies), dedicated infrastructure on AU soil (a smaller cohort), and on-premise or on-territory dedicated inference under direct operator control (a smaller cohort still). None is universally superior; each has cost, control, and assurance trade-offs that a CPS 234-grade hosting decision should make explicit. The jurisdictional-specificity dimension (and why "in Queensland, on infrastructure operated by a named party, with the model weights under our direct control, with an audit trail you can inspect" is a different answer from "in Australia") is covered in Sovereign AI in Australia: Queensland Data Residency.
Axis 3: Talent model
Two models dominate the market. The in-house-team model puts a named delivery team alongside the buyer's team for the engagement's duration; the people who scope the work are the people who do the work. The talent-network model matches the buyer with independents drawn from a vetted pool, often optimised for specific skills.
The in-house-team model is generally more accountable for outcomes; the talent-network model is generally more elastic on scarce-skills supply. A bank, insurer, or government department whose engagement runs across multiple regulatory cycles usually wants the in-house-team model: the same faces at the audit-evidence conversation in month twelve as at the scope-of-work conversation in month one. A startup or product team running a contained pilot may prefer the elasticity of the network model.
Axis 4: Engagement scale
The engagement-scale axis is whether the firm's smallest sensible engagement matches the workload's size. The Big-3 strategy firms can engineer an AI-led transformation across a 13,000-employee organisation; their smallest sensible engagement is usually multi-month and multi-stream. A specialist-focused consultancy can engineer a single-workflow build with an operator-in-the-loop, sized for a ten-person team: the smallest sensible engagement runs in weeks rather than quarters, with a small dedicated team that stays through implementation (the RyderAI build sequence is one such shape). For a regional bank, insurance group, clinic, or government workstream whose target workload is specific rather than enterprise-wide, the specialist model eliminates the cost drag of large-firm overhead and the timeline drag of multi-stream-engagement structure. Both shapes are legitimate; mismatched scale produces frustration on both sides. A focused single-workflow build inside an engagement model priced for multi-stream transformation is unhappy for both buyer and seller.
Axis 5: Technology stack neutrality
Some firms are deeply embedded in a particular cloud or model vendor's stack and earn partner-tier recognition for that depth. Others are stack-neutral and design around the workload's constraints rather than a hyperscaler's product catalogue. The choice has a multi-year cost and sovereignty signature, not just a delivery preference. A buyer whose strategy is "deepen our existing hyperscaler investment" (already committed, switching cost prohibitive, model choice already constrained by the partner stack) wants a stack-aligned partner. A buyer whose strategy is "keep optionality on model vendor, hosting location, and pricing curve" (particularly where the workload runs five-plus years, where the API-vs-self-host break-even is in view, or where supplier-risk under CPS 234 is binding) wants a stack-neutral partner whose default is open-weight self-host on infrastructure the buyer controls.
Stack-lock is itself an information-security risk under CPS 234's supplier-risk dimension. Two consequences follow. First, an APRA-supervised buyer cannot delegate the supplier-assurance work to the consultant; the obligation stays with the regulated entity. Second, a vendor-deep consulting partner who is excellent at their stack may be structurally unable to advise on the migration off that stack when the supplier-risk conversation eventually requires it. Open-weight-first delivery sidesteps both, but produces a different cost shape (more infrastructure capability needed in-house, less reliance on partner-tier credits).
The 2026 open-weight model landscape, covered in the Nemotron 3 Super vs GPT-OSS 120B comparison, has shifted the economics of stack-neutrality. A delivery partner who defaults to proprietary APIs is making a different long-term cost and sovereignty bet than one who defaults to open-weight self-hosting on infrastructure the buyer controls.
The eight questions to ask before the statement of work
The shortlist conversation is where the five axes become contractual. The eight questions below surface the answers that matter for an Australian regulated workload, before the contract rather than during the audit.
1. Where will the AI run, end-to-end? Specifically: the inference compute, the model weights, the prompt and inference logs, the human-approval records, any vector store, any knowledge base. "In the cloud" is not an answer. The location and the operator are the answer.
2. Who owns the trained model, fine-tuning data, deployment-specific configuration, audit records, and operating artefacts after handover? The answer should separate client-owned deployment artefacts from any retained platform, orchestration, or tooling IP, and that boundary belongs in the statement of work, not implied.
3. What regulatory framework is the design audited against, and what is the evidence trail? A consulting partner who treats this as a marketing question (the answer is a list of regulator names) is a different proposition from one who treats it as a delivery question (the answer is a control-test plan with sample CPS 234 information-asset register entries, the three-lines-of-defence model that will be applied, and the named owner of each test in the engagement).
4. What audit-trail evidence will be retained, and for how long? Per the human-in-the-loop framework for Australian regulated industries, the minimum log fields are: input received, model identifier and version, output produced, confidence signal if available, human reviewer identity, time of review, decision taken, and the artefact actually sent or stored, with tamper-evidence on the log. Retention is set by the longest of APRA, OAIC, and any sector-specific regulator.
5. What happens if accuracy degrades in production? Every model deployment drifts. The question is whether the engagement model includes monitoring, retraining, and human-intervention paths, and on whose budget.
6. What is the exit posture if the engagement ends mid-project? Which artefacts come with the buyer (training data, fine-tuning pipelines, deployed model weights, infrastructure configuration, audit logs), and which are retained by the consultant. Engagements rarely need to invoke this clause; the ones that do reveal whether the contract was written for the buyer or the seller.
7. Who carries accountability for the system after handover? A regulated workload requires a named accountable person under the operator's framework (APRA's FAR, AHPRA's individual practitioner accountability, the agency head under Commonwealth governance). The consultant cannot be that named person. The engagement contract should make clear when the accountability transition happens and what evidence accompanies it.
8. How does the consultant handle data on infrastructure they do not own? If the consultant's working environment is in a hyperscaler region the buyer does not control, the data-residency conversation needs to extend to the consultant's own operational footprint, not just the buyer's deployment target.
How the framework resolves: three archetype workloads
The same five-axis framework produces different shortlists for different workload archetypes. Three of the most common in Australian regulated practice:
Archetype 1: APRA-supervised bank, customer-facing AI workflow
A retail bank deploying an AI system handling customer PII at scale (whether customer-facing or internal, decision support or transaction processing) under continuous prudential review. Regulator: APRA. Standards: CPS 234, CPS 230, FAR-linked accountability. Data: customer PII at scale. Operating posture: production AI under continuous prudential review.
Framework resolution: regulatory framework fluency in CPS 234 + CPS 230 + FAR is non-negotiable; the delivery partner must name the FAR Accountable Person identification trigger and the 72-hour incident-notification posture without prompting. The engagement contract should name the three-lines-of-defence test owner for the AI system (first line is the operational AI team, second line is risk and information security, third line is internal audit) and the evidence each line produces on a stated cadence. Data residency posture should be at minimum on-territory dedicated inference; hyperscaler regions in AU are workable for some workloads but the supplier-assurance overhead is non-trivial. Talent model should be in-house-team for the duration of the prudential audit cycle, not network-elastic: the same faces in month twelve as in month one. Engagement scale matches the bank's risk-tier; for a tier-1 deployment the engagement is multi-stream and multi-quarter. Technology stack neutrality matters more here than anywhere else because vendor lock-in is itself an information-security risk under CPS 234's supplier-risk dimension. The consultant's own stack choice is itself evidence of whether they design for that constraint or against it.
Archetype 2: AHPRA-bound clinical operator, decision-support deployment
A hospital, clinic, or specialist practice deploying AI that assists clinical decisions (imaging, triage, documentation, diagnostic support). Regulator: AHPRA + state health departments. Standards: AHPRA's August 2024 AI guidance, My Health Records Act for patient-record-touching workflows. Data: PHI under strict provenance expectations. Operating posture: practitioner-accountable AI with audit-trail-rich evidence.
Framework resolution: regulatory framework fluency includes AHPRA's five principles (accountability, understanding, transparency, plus the remaining two), the My Health Records Act, and the AU AI Ethics Framework's principles around human-centred values and contestability; the binding constraint is that the registered practitioner remains responsible for the clinical decision regardless of AI assistance. Data residency posture is typically on-territory; hyperscaler regions in AU are workable but the residual-risk conversation is heavier than for most non-clinical workloads. Talent model needs to include clinical-domain literacy alongside engineering: pure AI delivery without clinical understanding produces decision-support tools that practitioners distrust. Engagement scale matches the clinic's risk tier; many clinical pilots start narrow. Technology stack neutrality matters where downstream EMR or clinical-decision-support integration is required.
Archetype 3: Commonwealth agency, internal AI workflow on PROTECTED data
A federal department deploying an internal workflow assistant, document-classification tool, or analytical capability on data classified at PROTECTED or above. Regulator: ASD (via IRAP), agency head under Commonwealth governance. Standards: ISM (March 2026 edition, refreshed quarterly), IRAP, AU AI Ethics Framework's eight principles plus the October 2025 DISR Guidance for AI Adoption with six essential practices.
Framework resolution: regulatory framework fluency includes ISM controls and the IRAP assessment process; the delivery partner must understand that IRAP is an assessment of an environment, not a transferable certification held by a consultancy. A non-IRAP-assessed consultancy's role is to design for deployment inside an IRAP-assessed environment; the claim is design fit, not certification holding. Data residency posture for PROTECTED-grade workloads is on-territory dedicated; multi-tenant hyperscaler regions are typically excluded by the agency's own assurance posture before the consultant arrives. Talent model is usually in-house-team with appropriate clearances; engagement scale follows agency tier; technology stack neutrality is especially valuable here because Commonwealth procurement is sensitive to single-vendor dependency.
Where the framework leads
The five axes and the eight questions together produce a shortlist of three. The three is rarely the three a category-name search returns; the difference is the regulator, the data, and the operating posture the buyer needs to keep after the consultant leaves.
For an APRA-supervised bank designing a customer-facing AI workflow, an AHPRA-bound clinical operator deploying decision support, or a Commonwealth agency standing up an internal workflow on PROTECTED data, the conversation that produces the right shortlist usually starts with the framework, not with a list of firms. The shortlist that survives the framework is rarely the one a category-name search returns.
The four disciplines through which the right partner delivers the resulting workload (strategy, machine learning, integration, and governance) are what the next-step conversation engages.