Most Australian enterprises now have at least one AI system in production. Very few have more than a handful, and fewer still have the platform underneath that would let them run dozens without the operating cost growing linearly. The gap between the teams shipping AI in production and the teams still stuck in pilot is almost never a modelling gap. It is a platform gap.
This piece sets out the reference patterns that separate the two. It is aimed at architects and engineering leaders who have delivered one or two AI systems the hard way and now need to make the tenth one cheaper than the second.
## The platform has to solve four problems
A production AI platform earns its keep by solving four problems that every use case would otherwise solve badly on its own.
**Model access.** Teams need a single, governed way to call foundation models, embedding models and any fine tuned variants, with cost, latency and quota visible per use case. Without this, every team wires their own credentials, pays list price, and has no idea what the organisation is spending until the bill arrives.
**Retrieval.** Teams need a shared way to build, evaluate and serve retrieval indexes over enterprise data, with permissions preserved end to end. Without this, every team stands up its own vector store, ingests its own copy of the same documents, and quietly leaks access controls in the process.
**Evaluation.** Teams need a shared harness to run evaluations against use case specific test sets, with results tracked over time and tied to model, prompt and retrieval versions. Without this, evaluation happens once at launch and never again, and behavioural drift is discovered by users.
**Guardrails and observability.** Teams need a shared layer that enforces content, safety and policy rules, and that produces the structured logs and traces required for incident response and governance review. Without this, guardrails are reinvented per use case, unevenly, and the observability needed to explain a decision six months later does not exist.
If your platform does not solve all four, it is not yet a platform. It is a collection of shared services that will be bypassed under delivery pressure.
## Reference patterns that scale
Four patterns show up repeatedly in the Australian enterprises that have moved past the pilot stage.
**A model gateway, not a model library.** The gateway sits between the applications and the underlying model providers. It applies authentication, quota, cost accounting, safety filtering and logging in one place. Applications call the gateway, not the providers directly. This one component pays for itself within a quarter in any organisation with more than three AI use cases in production.
**Retrieval as a product, not a project.** The retrieval team owns the ingestion pipeline, the chunking and embedding strategy, the index infrastructure and the query API. Use case teams request indexes over defined corpora, with defined permissions, and consume them through a stable API. They do not build their own. This inversion is uncomfortable for use case teams at first and indispensable at scale.
**Evaluation as continuous integration.** Every change to a prompt, a retrieval configuration or a model version triggers the evaluation harness against the relevant use case test sets. Results are stored, compared to baseline, and required to meet thresholds before promotion. This is the single highest leverage capability a platform can offer, and it is the one most often skipped.
**Observability designed for decisions, not requests.** Standard application observability captures requests, latencies and errors. AI observability has to also capture the inputs the model saw, the retrieved context, the output produced, the version stack in force, and the downstream action. Design the schema for this once, at the platform layer, and require every use case to emit it.
## What to build first
The order matters. Building the retrieval product before the model gateway leaves you with governed retrieval feeding ungoverned model calls, which is worse than the reverse. Building the evaluation harness before either leaves you with no stable interface to evaluate against.
The sequence that has worked in Australian environments is: gateway first, observability schema alongside it, evaluation harness next, retrieval product last. Guardrails are added incrementally at the gateway from day one and matured over the first year.
## Where teams get stuck
Two failure modes account for most of the stuck AI platform programmes I see in Australian enterprises.
The first is trying to build the platform in isolation from any use case. A platform team without a live, demanding tenant produces a platform that solves imagined problems and misses real ones. The correct posture is to build the platform in service of the first two or three use cases, with a clear plan for the next five.
The second is treating the platform as infrastructure rather than product. Infrastructure teams optimise for reliability and cost. Product teams optimise for adoption. An AI platform that is not adopted, no matter how reliable, is a sunk cost. The team that runs it needs product discipline: a roadmap, a user community, versioned APIs, and deprecation policies.
The teams that get this right ship AI systems at a rate their competitors cannot match, at a cost per use case that keeps falling. The teams that get it wrong ship one impressive pilot and then stall. The difference is almost never the model.