AI Platform Engineering: Architecture, Golden Paths and Team Boundaries

AI platform engineering is the discipline of building a shared, self-service platform that enables AI teams to build, deploy and operate AI systems without reinventing infrastructure for every project. It applies platform engineering principles — golden paths, cognitive load reduction, the platform as a product rather than a helpdesk — to the specific capabilities that AI workloads require: model training, fine-tuning, serving, evaluation, observability, deployment, security, governance and cost control. A platform team builds the paved road; product teams walk it.

The platform exists to reduce the cognitive load of teams that ship products. Four team types commonly appear in organisations that have adopted a platform model: stream-aligned teams (own a product or user outcome), platform teams (build shared capabilities as a product), enabling teams (transfer capability temporarily) and complicated-subsystem teams (own deep specialised systems). On this model, stream-aligned teams should not have to build and maintain their own training pipelines, serving infrastructure or observability stack — they should consume these capabilities as a product with documentation, self-service provisioning and clear interfaces. When every stream-aligned team builds its own GPU provisioning, model registry and monitoring dashboard, the organisation is paying for the same work three or more times, and the quality of each implementation is lower than a centralised platform would produce.

AI platform engineering is not a single tool. It is a set of capabilities delivered as a product, with golden paths that make the right way the easy way. The platform team treats the platform as a product with users (the stream-aligned teams), a roadmap, versioning, deprecation policy and adoption metrics. A platform that no team uses is not a platform — it is a shelf. The measure of a platform's success is adoption: what proportion of new AI services use a golden path, how long it takes a new team to ship, and how many shadow-operations incidents the platform prevents.

AI platform engineering sits between two established disciplines: platform engineering (general infrastructure as a product) and MLOps (model operations lifecycle). Platform engineering owns general infrastructure — compute, storage, networking, deployment, observability — that any application team consumes. AI platform engineering extends this with AI-specific layers: model registries, training pipelines, serving engines, evaluation frameworks, token-level cost controls and AI governance. MLOps owns the model operations lifecycle — drift detection, retraining triggers, model promotion — but operates on top of the platform, not as it.

The distinction matters because the failure modes differ. A platform engineering team that builds generic infrastructure without AI-specific capabilities produces a platform that AI teams cannot consume without rebuilding the AI parts themselves — a model registry is not a container registry, a training pipeline is not a CI pipeline, and token-level cost is not a server cost. An MLOps team that owns model operations without a platform underneath builds bespoke infrastructure for each model, which does not scale beyond a handful of teams. AI platform engineering is the layer that makes MLOps scalable: the platform provides the reusable capabilities; MLOps consumes them for a specific model or system.

In practice, the boundary is fuzzy because organisations adopt these disciplines in different orders. A team that starts with MLOps often discovers it needs a platform when the third or fourth team rebuilds the same serving infrastructure. A team that starts with a platform often discovers it needs MLOps when the first model enters production without a retraining plan. The comparison table below maps the three disciplines across scope, focus, teams and artefacts so you can locate where your organisation's work belongs and what is missing.

A production AI platform has twelve layers, from raw infrastructure through developer experience. The layers are not a prescription — no standard mandates exactly twelve — but they cover the capabilities that every production AI system needs and that a platform team should centralise. The layers are: infrastructure provisioning, environment management, model registry and artefact storage, training and fine-tuning pipelines, serving and inference infrastructure, evaluation and quality measurement, observability and monitoring, deployment and release management, security and access controls, governance and audit, cost control and FinOps, and developer experience and self-service portal.

Each layer has an input (what enters it), a process (what the platform provides), an output (what artefact or capability is produced) and a decision (what choice the consumer makes at that layer). The navigator below maps each layer with these fields and a deeper-guide link to the page that owns the implementation detail. A layer may be owned by the platform team, owned by the product team, or shared — the responsibility matrix later in this page makes the boundary explicit.

The twelve-layer model is an editorial synthesis, not an industry standard. Validate it against your own implementation: if your organisation has a capability not listed here, add it; if a layer is absent, that is a maturity gap to document. The value of the model is not the exact count but the coverage check — it forces the platform team to ask, for each layer, who owns it, what its golden path is, and whether it is adopted.

The platform team should centralise capabilities where centralisation reduces shadow operations and where the capability is shared across multiple teams. Observability, evaluation, governance and cost control are the strongest centralisation candidates: every AI team needs them, building them bespoke produces inconsistent quality, and a central implementation benefits from network effects — more teams means more signals, more evaluation baselines, more cost data. When observability is centralised, a new team gets traces, metrics and quality dashboards on day one instead of building them over weeks.

Centralisation reduces shadow operations — the pattern where developers do DevOps and AI operations tasks ad hoc, without standards, documentation or ownership. Shadow operations is a hallmark of low-performing organisations: without a platform, every recurring task becomes improvisation, environments are assembled by hand, and deployment knowledge lives in the heads of a few senior engineers. A centralised platform with golden paths replaces improvisation with a supported, opinionated route that is faster than manual and safer than avoidance.

The threshold for centralisation is roughly 20–30 platform users. Below that, the coordination cost of a platform team may exceed the savings from centralisation — a small number of teams can share infrastructure informally. Above it, the coordination cost of manual work becomes unmanageable, and the shadow-operations tax — duplicated effort, inconsistent quality, on-call gaps — exceeds the platform investment. For AI platforms, the threshold may be lower because AI infrastructure is more complex and the failure modes (drift, hallucination, retrieval failure) are harder to debug without shared tooling.

Application teams — stream-aligned teams in the four-team-type model — own user outcomes, not infrastructure. They decide which model to use for their use case, how to design the prompt, what the agent's tools are, what the business logic is, and what SLO their users need. The platform provides the capabilities; the stream-aligned team makes the product decisions within those capabilities. Centralising infrastructure does not mean centralising product judgement — a platform that prescribes which model every team must use has overreached.

Stream-aligned ownership of user outcomes keeps the feedback loop short. The team that owns the user outcome owns the SLO, the incident response and the iteration decisions. When the platform team owns these, the team closest to the user is no longer the team that acts when the user is unhappy — and the handoff between platform and product adds latency to every decision. The boundary is: the platform owns the how (infrastructure, golden paths, tooling); the product team owns the what (model choice, prompt, business logic, user-facing SLO).

Enabling teams provide temporary help for adoption. An enabling team is one of the four team types that transfers capability to stream-aligned teams — it helps a team adopt evaluation practices, set up observability or implement governance controls, then exits. The enabling team does not own the capability long-term; it seeds it. This is distinct from the platform team, which owns the capability permanently. Organisations that confuse enabling and platform teams end up with enabling teams that never leave, becoming a permanent dependency rather than a capability transfer.

A golden path is a supported, opinionated route through recurring work that is faster than doing it manually and safer than avoiding it. The term, shaped by Netflix and Spotify practitioners, captures the platform's value proposition: the platform team builds and maintains the path; teams that follow it get speed and safety for free; teams that deviate accept the cost of doing so. A golden path is not a mandate — teams can leave it — but the path is good enough that most teams choose it.

For AI workloads, golden paths take specific shapes. A golden path for a new LLM application: provision environment from a template, register the model in the registry, deploy with canary release, wire observability with quality metrics, set an SLO with error budget. A golden path for a new agent system: provision environment, configure the tool registry, deploy with durable checkpoints, wire tracing for tool calls and loop counts, set a tool-call SLO. Each path encodes the lessons the platform team has learned — the canary default, the checkpoint requirement, the quality SLO — so teams that follow it inherit that knowledge without relearning it.

Platform engineers discover and productise emergent paths. Not every golden path is designed up front — many emerge from a stream-aligned team's bespoke solution that turns out to be reusable. The platform team watches for patterns: when three teams build similar evaluation pipelines, the platform team productises the pattern into a golden path. This is how the platform evolves: emergent practice becomes productised path becomes platform capability. A platform that only has designed-up-front paths misses the innovations that teams discover in production.

An organisation needs an internal AI platform when the coordination cost of manual work exceeds the investment of building one. The rule of thumb from platform engineering is 20–30 platform users: below that threshold, a small number of teams can share infrastructure informally; above it, the shadow-operations tax — duplicated effort, inconsistent quality, on-call gaps, slow onboarding — exceeds the platform cost. For AI platforms the threshold may be lower because AI infrastructure is more complex and the failure modes are harder to debug without shared tooling.

The signal that a platform is needed is shadow operations. When developers are doing DevOps and AI operations tasks ad hoc — provisioning their own GPUs, building their own model registries, writing their own evaluation scripts — the organisation is paying for the same work multiple times and getting lower quality than a centralised platform would produce. Shadow operations is the antipattern that platform engineering exists to eliminate: without a platform, every recurring task is improvisation, and knowledge lives in the heads of a few senior engineers who become bottlenecks.

Most platform initiatives that fail start too big, build too long without testing, or optimise for stakeholder narratives rather than team adoption. A platform that is built for a year without shipping a golden path that a team uses is a shelf, not a platform. The successful pattern is to start with one golden path that one team needs, ship it, measure adoption, then expand. A platform that is adopted by the first team and grows from there is a product; a platform that is designed in a vacuum and launched as a finished thing is a project that no one asked for.

AI platform maturity is demonstrated by four artefacts: a platform capability map, golden-path documentation, self-service adoption metrics and a documented responsibility matrix. The capability map shows which of the twelve layers exist and their maturity — absent, emerging, mature — so the platform team and its consumers can see what is available and what is missing. A layer marked absent is not a failure; it is a prioritisation decision. A layer marked mature with zero adoption is a failure: the capability exists but no one uses it.

Golden-path documentation is the evidence that the path is real. A golden path that is not documented does not exist for the teams that would use it — documentation is the interface between the platform team and its consumers. The documentation must be tested: a new team following the documented path should be able to ship without asking the platform team a question. If every team needs help, the documentation is incomplete and the path is not self-service. Adoption metrics close the loop: what proportion of new AI services use a golden path, how long does onboarding take, and how many shadow-operations incidents were prevented.

The responsibility matrix — platform team vs product team vs enabling team across the twelve layers — is the artefact that prevents boundary disputes. When a layer has no owner, work either falls through the cracks or is duplicated by two teams. The matrix makes ownership explicit: who centralises, who consumes, who assists temporarily. The matrix below is the primary decision artefact on this page — it answers the question that brings most readers here: what should the platform team own, and what should remain with application teams?