Platform roadmap

The problem this quarter

Most AI platform decisions in Australian enterprises this year were never decided. They were defaulted. A team needed a model, so it called whatever the incumbent hyperscaler shipped. A business unit wanted a copilot, so it switched one on inside the productivity suite already under contract. Six months later, the architecture review discovers that sensitive data is flowing through inference endpoints nobody mapped, fine-tunes live in a provider format nobody can export, and the monthly inference bill has a slope no one modelled.

The cheap mistakes in AI platforms are reversible. The expensive ones are structural, and they all compound the longer you wait:

• Sovereignty and residency baked into the wrong layer, so classified or sensitive workloads sit where they shouldn’t.
• Model lock-in, where prompts, fine-tunes and orchestration are welded to one provider’s proprietary surface.
• No exit, because nobody asked the portability question while there was still leverage to ask it.
• Runaway run-cost, where token consumption scales with adoption and no one owns the meter.
• AI-native security gaps — prompt injection, model integrity, agent identity — that the existing security stack was never designed to see.

None of these show up in a proof-of-concept. All of them show up at scale, which is exactly when they’re hardest to unwind. The discipline this quarter is to sequence the platform decisions deliberately, before adoption removes your options.

The method

Treat the AI platform as five decisions, made in order, each one written down. The sequence matters: residency constrains model choice, model choice constrains portability, and security and cost wrap around all of it.

1. Data residency and sovereignty

Decide this first, because it gates everything downstream. The real question is not “which cloud” but “which workload sits where”. Segment by data sensitivity and, for government, by security classification:

• Hyperscaler-native AI services — fastest to stand up, broadest model catalogue, but you inherit the provider’s regional and operational boundaries. Confirm where inference actually runs, not just where data is stored at rest.
• Sovereign-hosted — AI services operated under Australian control, for workloads where residency and operational sovereignty are non-negotiable.
• On-premises / self-hosted open-weight — for the most sensitive or classified material, where the model runs inside your own boundary.

Residency and sovereignty obligations vary by sector and by an agency’s security classification. Map your workloads against your own obligations rather than against a single instrument — and design so a residency requirement landing later forces a configuration change, not a re-platform.

2. Model strategy

A single frontier model is a single point of commercial and technical failure. Posture for choice:

• Proprietary frontier for capability-led work where the best available reasoning earns its premium.
• Open-weight where transparency, self-hosting or cost control matters more than the last increment of capability.
• Self-hosted for sensitive workloads that can’t leave the boundary.

The goal is a multi-model posture: an abstraction layer between your applications and any given model, so swapping a provider is a configuration change rather than a rebuild. The model that wins your benchmark this quarter will not be the one that wins next quarter.

3. Portability and exit

The portability question has to be asked while you still have leverage — at selection, not at renewal. For each provider, know whether you can actually move:

• Prompts and prompt logic — portable, or entangled in provider-specific features?
• Fine-tunes — exportable as weights or adapters, or trapped in a managed format you can’t extract?
• Embeddings — re-usable, or locked to one provider’s embedding model and vector dimensions?
• Orchestration and agents — built on portable patterns, or on one provider’s proprietary agent framework?

An exit plan you’ve never tested is a hope, not a plan.

4. AI-native security

The AI platform introduces threats the existing security stack does not model. Treat it as its own control surface:

• Prompt injection — untrusted input reaching a model with tools or data access.
• Model integrity — provenance of weights, protection against tampering and poisoning.
• Secrets — keys and credentials inside prompts, context windows and tool calls.
• Agent identity and authorisation — what an autonomous agent is allowed to do, on whose authority, and how that’s logged.

The NIST Cyber AI Profile (draft released December 2025) gives you a cybersecurity-for-AI scaffold to map controls against, and the NIST AI Agent Standards Initiative (opened February 2026) is the reference to watch for agent identity and authorisation as autonomous agents enter production.

5. FinOps for AI

Inference cost behaves unlike anything in your existing cloud bill: it scales with usage, per token, often without a ceiling. Build the controls before adoption, not after the invoice:

• Token and inference cost visibility, attributed to team and use case.
• Budgets, rate limits and circuit-breakers per application.
• A standing review of cost-per-outcome, because a cheaper model at good-enough quality often wins.

A worked example

Murrumbidgee Water (fictional) is a state-owned utility planning two AI workloads: an internal assistant over operational and asset-maintenance records, and a public-facing customer-service agent. The operational data includes critical-infrastructure detail the board treats as sensitive; the customer data is ordinary PII.

The default path was obvious and wrong: switch on the AI services already bundled with the incumbent hyperscaler contract and ship both. Run through the five decisions instead.

Residency. Murrumbidgee splits the workloads. The customer-service agent — ordinary PII, lower sensitivity — goes hyperscaler-native in-region, after confirming inference runs onshore, not just storage. The operational assistant, touching critical-infrastructure data, goes to a sovereign-hosted option under Australian operational control. One platform decision, two placements, driven by sensitivity rather than convenience.

Model strategy. Both workloads sit behind an internal model-abstraction layer. The customer agent uses a proprietary frontier model for quality; the operational assistant uses an open-weight model the sovereign host can run inside the boundary. Because both call through the same abstraction, the team can re-benchmark and swap either without touching application code.

Portability. At selection, Murrumbidgee requires that fine-tunes be exportable as weights, embeddings be regenerable on a second provider, and orchestration use a provider-neutral framework. The exit plan for the customer agent is tested once before go-live — a dry-run cutover to a second model — so “we can move” is a fact, not a slide.

Security. Both agents get input treated as untrusted (prompt-injection controls), secrets kept out of context windows, and — for the operational assistant’s ability to action work orders — explicit agent identity and authorisation, mapped against the NIST Cyber AI Profile.

FinOps. Per-workload token budgets, rate limits and a cost-per-resolved-query metric go in from day one. When the customer agent’s volume spikes, the circuit-breaker trips instead of the invoice.

The deliberate path cost a few weeks more upfront. The default path would have put critical-infrastructure data on the wrong platform with no way back — a finding the board would have met at the worst possible time.

The template

Copy this. Keep one record per material AI platform decision, in version control alongside your architecture.

AI platform decision record

Field	Content
Decision	The single platform/compute choice being made
Date / owner	When, and the accountable architect
Options considered	Hyperscaler-native / sovereign-hosted / on-prem; proprietary / open-weight / self-hosted
Choice	What was selected
Rationale	Why — tied to data sensitivity, residency, capability, cost
Residency posture	Where inference and data actually run
Exit plan	How to move providers — prompts, fine-tunes, embeddings, orchestration — and whether it’s been tested
Security controls	Injection, integrity, secrets, agent authorisation (mapped to a profile)
Cost controls	Budget, rate limits, cost-per-outcome metric
Review date	When this decision is re-opened on purpose

Roadmap sequencing

Sequence the decisions in this order, and don’t let a later one quietly pre-empt an earlier one:

1. Residency and sovereignty — segment workloads by sensitivity and classification first.
2. Model strategy — establish the abstraction layer and multi-model posture before the first production model.
3. Portability and exit — write and test the exit plan at selection.
4. AI-native security — stand up the control surface before agents touch real tools or data.
5. FinOps for AI — meters and circuit-breakers live before broad adoption.

What changes when the regulation moves

Australia’s settled position — the National AI Plan (2 December 2025) — is technology-neutral laws enforced by existing sector regulators, with no standalone AI Act. That makes your platform record more important, not less: when no single instrument tells you what “compliant” looks like, the burden falls on you to show deliberate decisions.

Watch four fronts and design so each is a configuration change, not a rebuild:

• Sovereignty and residency expectations may tighten by sector and classification. A clean residency posture per workload means absorbing that, not re-platforming.
• Sector security rules will increasingly name AI-specific duties. Your AI-native security surface is where those land.
• EU high-risk security duties — accuracy, robustness and cybersecurity (timing affected by the Digital Omnibus, not yet formally adopted) — apply if you have EU exposure, and reward the same portability and security discipline.
• Maturing AI-security standards — the NIST Cyber AI Profile and Agent Standards Initiative, and ISO/IEC 42001 appearing in procurement. The Australian AI Safety Institute (announced 25 November 2025, operational early 2026; working with the Australian Signals Directorate and CSIRO) is the domestic technical-testing reference to track.

The organisations that sequenced these decisions on purpose will treat each regulatory move as a parameter change. The ones that defaulted will treat it as a migration.

Where this connects

• Score your platform position on the Technology axis with the maturity assessment.
• Triage a specific workload with the risk classifier.
• Check the obligations behind these decisions in the regulatory canon.
• See how platform sits in the wider picture in the model.