Ask a business team why their AI pilot took nine months, and you will rarely hear “the model was hard.” You will hear about the six weeks waiting for security review, the bespoke integration with the data warehouse, the evaluation harness they wrote from scratch, the procurement cycle for a vector database, and the monitoring dashboard someone built in a spreadsheet because nothing else existed. The model took a fortnight. The scaffolding took the rest.
Now multiply that scaffolding by every team in the enterprise, each building its own version, badly, in parallel. That multiplication is the single largest hidden cost in most AI programs, and the cure has a name: a platform team that treats shared AI infrastructure as a product.
The last article argued that a Center of Excellence should embed its control in the platform rather than in approval queues. This article is about what that platform actually contains, who builds it, and the mindset shift that separates platforms teams love from platforms teams route around.
What “the platform” means in 2026
PwC’s 2026 predictions describe the pattern that front-running companies have converged on: a centralized hub, which they call an AI studio, bringing together reusable tech components, frameworks for assessing use cases, a sandbox for testing, deployment protocols, and skilled people. Strip the branding and you get a concrete bill of materials. A serious enterprise AI platform in 2026 has seven layers.
The model gateway. One governed door to all approved models: commercial APIs, open-weight deployments, and fine-tuned internal variants. The gateway handles authentication, logging, cost attribution, rate limiting, and failover. Teams call one interface; the enterprise gets one audit trail and one bill.
The data access layer. Governed connections to enterprise data: retrieval pipelines, embedding services, and the permissions plumbing that ensures an AI system sees only what its user is entitled to see. This is where the Data & AI Strategy track’s data products meet the operating model.
The sandbox. A safe environment where any team can prototype with real capabilities and synthetic or approved data, without a procurement cycle or a security exception. The sandbox is the single most effective shadow-AI prevention tool ever invented, because it makes the official path the fastest path.
Reusable components. Prompt templates for common patterns like summarization, classification, and extraction. Agent scaffolds. Evaluation datasets. Connector libraries. Every reused component is a build that did not happen and a mistake that did not get repeated.
The evaluation harness. Shared tooling to test AI systems before and after deployment: accuracy benchmarks, safety checks, regression suites, and the risk-tier-specific gates that standards require. Evaluation as a service is what makes standards enforceable without a human gate.
The orchestration layer. New to the stack and rising fast: the command-center view of agents and workflows in production. PwC’s framing is apt, a unified view that helps you catch mistakes, track performance, and operationalize ideas that bubble up from end users. As agents proliferate, this layer becomes the difference between a managed workforce and a swarm.
Observability and FinOps. Monitoring, drift detection, incident alerting, and per-team cost visibility. Tokens are the new cloud spend, and the platform is where they get counted.
Figure 1 stacks these layers, from the model gateway at the foundation to orchestration and observability at the operational surface. The point of the picture is what sits on top: business applications that are thin, fast to build, and consistent, because everything heavy lives below the line.
Platform as product, not project
Here is the mindset shift that decides whether any of that stack gets used. A project ships and ends. A product has customers, a roadmap, support, and a reason to improve. Platform teams that think in projects build technically impressive infrastructure that nobody adopts. Platform teams that think in products obsess over one metric: how fast can an internal team get from idea to working prototype on our rails?
Treating internal teams as customers changes daily behavior in specific ways. You write documentation as if adoption were optional, because it is. You measure onboarding time in hours, not weeks. You run office hours and actually staff them. You maintain a public roadmap and let consuming teams vote on it. You deprecate gracefully. And you resist, forever, the temptation to make the platform mandatory by decree rather than superior by design.
The paved road metaphor earns its popularity here. The platform is the paved road: smooth, fast, guardrails included. Teams can still go off-road when they genuinely need to, but they carry the full weight of security review, integration, and operations themselves. When the paved road is truly faster, compliance stops being a policy problem, because the guardrails travel inside the pavement.
Figure 2 makes the economics visible: the cost-and-time curve of a bespoke build versus the same use case on the platform. Bespoke looks cheaper for the first team, is marginally defensible for the second, and becomes indefensible from the third onward, which is exactly when most enterprises are making the decision.
Staffing the platform team
A platform team is not a research lab and not a help desk, and hiring for it goes wrong in both directions. The core profile is the engineer who has run production systems and enjoys making other engineers faster. For a mid-sized enterprise, the roster looks like: a platform product manager (the single most underrated hire in enterprise AI), infrastructure engineers who own the gateway and serving stack, an evaluation engineer who treats test harnesses as first-class software, a security and identity specialist, and increasingly an agent-operations engineer who owns the orchestration layer.
Size it deliberately small. A platform team’s output is leverage, not features, and the discipline of a small team forces the ruthless prioritisation that keeps a platform coherent. Ten excellent people running a paved road beat forty building a theme park.
One boundary worth policing: the platform team should almost never build business use cases. The moment it does, it acquires favorites, its roadmap gets hijacked by whoever shouts loudest, and the product discipline dissolves. Embedding platform engineers with business teams for short rotations is healthy; absorbing delivery work is not.
The build-versus-buy question, again
Should you build this stack or buy it? The honest 2026 answer is: you will do both, and the design skill is choosing the seams. Model gateways, observability, and orchestration tooling are maturing vendor categories; building them from scratch is rarely justified. Your data access layer, your evaluation datasets, and your reusable domain components are where your context lives, and no vendor ships those.
The trap to avoid is buying a platform-in-a-box and declaring the job done. A platform is one third technology and two thirds product operations: onboarding, support, standards, and the feedback loop with consuming teams. Vendors sell the first third. The rest is the team, which is why this article is about the team.
How you know it is working
The platform’s success metrics are adoption metrics, and they should be reported with the same seriousness as any revenue line. Percentage of enterprise AI workloads on-platform. Median time from idea to prototype, and from prototype to production. Component reuse counts. Cost per use case, trending down. Incident rates on-platform versus off, which quantifies the guardrail value. And the simplest one: do teams choose the platform when they do not have to? Voluntary adoption is the only vote that counts, and as Figure 2 shows, the economics are on your side if the product is any good.
There is a compounding effect here that deserves a closing note. Every layer in Figure 1 makes the next use case cheaper, faster, and safer than the last one. Organizations without a platform pay full price for every AI initiative forever. Organizations with one watch the marginal cost of intelligence fall quarter after quarter. That falling curve, more than any single flagship use case, is what an AI-native organization looks like on a balance sheet.
The platform gives your people rails to build on. The next question is who those people are: the roles, the hiring sequence, and the team shapes that turn infrastructure into outcomes. That is where we go next.