Essay
What a foundational platform for AI actually contains
An opinionated list of the capabilities a Nordic enterprise platform team needs to own to make AI work shippable — and the ones it should rent.
“Foundational platform” is a phrase that, like most platform phrases, can mean almost anything. This essay is my attempt to make it specific in the context of AI work inside a large enterprise. It is the lens I built during a decade leading enterprise platforms at the LEGO Group — identity, consent, AI-driven content moderation, engagement, analytics — and the work I find myself doing most often as an advisor.
The argument in one sentence: the platform team’s job is not to build AI capabilities, it is to make AI capabilities boring. Boring in the way databases are boring. Reliable, observable, governed, and out of the way of product teams who should be focused on customers.
Here is the list of capabilities I think a foundational platform for AI inside a Nordic enterprise in 2026 needs to own.
Owned by the platform
Model access and lifecycle
A single, audited path to every model the company uses — first-party, third-party, fine-tuned, hosted, on-premise. Versioning, deprecation policy, rate management, cost allocation. The platform team negotiates the model contracts. Product teams consume them through one interface. Without this, the company will end up with a hundred direct vendor contracts and zero leverage.
Agent management and governence
An overview of all the agentic solutions built inside the company. Tools that are allowed to invoke by agents and skills that can be re-used to automate workflows. Kill switch that can terminate agent/agent fleet when needed. The platform team will manage a curated tools/skills in the default allowed list and new tools/skills will be vetted against broad needs and security.
Evaluation
The platform owns the evaluation harness, the eval set registry, and the regression testing pipeline. Product teams contribute eval sets for their use cases. The platform provides the substrate that makes the evals run, comparable, and trustworthy. This is the single most underbuilt capability in 2026.
Observability for non-deterministic systems
Standard observability — logs, metrics, traces — extended for AI. Prompt and response capture, retrieval context capture, latency and token accounting, drift detection. Privacy-aware by default. The platform team has the only correct mental model for how to do this at scale; pushing it to product teams produces ten incompatible implementations.
Retrieval substrate
A vector store, a document indexing pipeline, a permission-aware retrieval interface. Not because every team will use the same one — they will not — but because the policies that govern what content can be retrieved by which surface need to live in one place.
Guardrails as primitives
Input filtering, output filtering, PII detection, jailbreak resistance — provided as platform features that product teams compose. Built once, audited once, applied everywhere.
Identity, access, and audit
Every AI call is attributable to a user, a system, and a use case. The audit trail is queryable. Access to higher-risk models is gated. This is not a feature you bolt on later.
Cost governance
Token spend, attributed to product team, to use case, to customer cohort. Budget alerts. Anomaly detection. Without this, AI costs are a black box and the CFO will eventually shut things down.
Rented from the market
Foundation models
Do not build them. Almost no enterprise should. The exceptions are companies whose product is a model.
Inference infrastructure for general-purpose models
Use the providers. Optimize at the platform layer. Build only for workloads where the economics force it, and even then, build narrowly.
Generic developer tooling
IDE plugins, code generation, scaffolding tools. Buy what works. Configure aggressively.
Annotation and data labeling
Specialized vendors. Internal teams should focus on quality oversight, not on building labeling tools.
Built on top of the platform, not in it
The platform team should resist the temptation to own product use cases. The customer support assistant, the product recommendation engine, the internal copilot — these belong to product teams. The platform makes them shippable.
The line between “platform owns” and “product owns” is the most important architectural decision a Chief AI Officer or VP of Platform makes. Get it wrong in one direction and the platform becomes a bottleneck. Get it wrong in the other and you end up with ten versions of every capability.
What this looks like in a Nordic enterprise
Three notes specific to the Nordic enterprise context.
First, the platform team is almost always smaller than it needs to be. The temptation is to delay platform investment until product use cases prove out. This is exactly backwards. The platform should lead by a quarter, not lag by two.
Second, governance work belongs on the platform team’s roadmap, not in a separate program. Risk classification, audit, oversight — these are platform features, treated as such.
Third, the platform team’s interface to product teams is the most important product the company builds. If it is painful, product teams will route around it. The platform’s internal NPS is a real KPI.
Where this comes from
Most of what I have written here comes from a decade inside the LEGO Group’s engineering organisation, where the platform-vs-product line was relitigated continuously across identity, consent, AI-driven content moderation, engagement, analytics, and the consumer products on top of them, and from conversations across the Nordic enterprise community. I expect to revise this essay as I learn more.
If you are building a platform like this and want a second pair of eyes, the advisory page explains how I work.