The Slice Underneath the AI Layer

Few months ago, arguing that AI was commoditizing its own application layer still counted somewhat as a contrarian position. By late June 2026 it reads as a summary of the month’s news, with SpaceX buying Cursor for $60 billion , an AI-infrastructure selloff erasing more than a trillion dollars of market capitalization over Capex sustainability, and OpenAI filing a confidential S-1 at an $852 billion valuation that depends on exactly the economics the rest of the market has started to question. The layer argument was solid, publicly and expensively, and it is public opinion.

What interests me is the gap between agreeing and doing. Most engineering organisations accept the argument in principle, and their roadmaps still read as pure application layer. So the useful question is no longer whether the layers commoditize; it is what a defensible AI business looks like once they have. I believe that does not live on any single layer at all. It is a vertical slice through the stack, fused to something a competitor cannot copy. At least easily.

What the Layer Diagram Misses

The consensus diagram uses has three horizontal layers: infrastructure, model, application (Andreessen Horowitz’s version ). I have argued before that there is a fourth, data and workflow, which is usually folded into “application” or dismissed as “plumbing”. What I think is this were the most of the durable value actually is. By now that last point is barely disputed. “Data is the moat” has moved from insight to slide template, and every serious analysis of AI economics lands in the same place: the model is becoming a commodity, and the advantage belongs to whoever owns the data and the workflows the model plugs into.

The part that remains under-appreciated is structural. Owning data, by itself, is a static claim; data can be licensed, scraped, replicated, or regulated into openness. The AI businesses that look defensible in 2026 are the ones that cut vertically across the layer diagram and fuse the data-and-workflow layer to something structurally non-copyable: physics, law, or an operational loop that took years of production to accumulate. A deployed device fleet, a legal jurisdiction, a regulatory regime. The horizontal diagram cannot draw those bindings, which is one reason the market keeps surprising itself when an application-layer company turns out to be worth more inside an infrastructure owner than standing alone. Three such slices are already clearly visible.

That is not the complete list. The same structural pattern shows up in industrial installed bases, ontology-driven verticals, user-behaviour loops, and identity and credentialing plays, and each deserves its own treatment. The three below are the ones I take on here.

The Three Slices

The Regulated Edge

Start from the edge that is not a regional data centre. Billions of devices are already installed in customer premises: Gateways, Wi-Fi access points, set-top boxes, residential and industrial CPEs. Each of them runs in a memory envelope of a few gigabytes with a power budget single-digit watts, so the inference a device can host locally is small and heavily constrained. Per device, that is a limitation. At fleet level it becomes the opposite, because the operator of a saturated fleet owns two things nobody outside it can reconstruct: the telemetry loop and the control plane.

The telemetry loop is every connection event, every Wi-Fi quality dip, every firmware combination and device-side anomaly across millions of homes and industrial sites, accumulated over years of production operation. The control plane is the over-the-air management path, in the broadband world standardized as USP (TR-369) , succeeding the older TR-069 , through which the fleet is configured, observed, and updated. The model that interprets all of this can be rented from anyone, and probably should be, since the price per token keeps falling. The telemetry and the control plane are owned by exactly one party, and they were expensive to build in the only currency that matters here, which is years of operating a fleet in production. Managing millions of devices carries its own operational demands: staged rollouts, rollback paths, version drift across hardware generations. That operational layer is part of the slice, and it does not appear on the layer diagram either, so maybe some “applications” and management interfaces fall into the Infrastructure category simply because of their criticality and operational load.

Underneath all of that sits another layer: the CPE software platform that carries the fleet’s standards conformance (BBF USP on the management plane), its structured telemetry pipeline, and its OTA campaigns across generations of hardware. It is unglamorous, structurally hard to build, and the substrate every operator’s slice compounds on.

This is also why hyperscalers cannot follow into the slice, and the reason is structural rather than technical. You cannot ship Azure to a customer’s living room, and no quantity of GPUs reconstructs a decade of fleet behaviour from outside the fleet. I made the longer version of this argument in the service-defined broadband edge , and the same logic holds wherever a fleet is saturated and inference has to survive without the cloud: industrial automation, several classes of medical devices, the in-vehicle stack.

Sovereign

The second slice binds to jurisdiction instead of hardware. A sovereign cloud is not a data center in a specific country; it is a contract that fixes three things at once: where the data physically lives, who holds the encryption keys, and which court can order either handed over. That contract is why OVHcloud and Scaleway in France, Bleu (the Microsoft-Capgemini-Orange venture for European public-sector workloads), and StackIT from Germany’s Schwarz Group are winning enterprise AI deals against providers whose models are objectively better. The model is somebody else’s, chosen so it can be hosted in-region, and the deal closes on the contract rather than on the model.

It is tempting to file all of that under procurement rather than architecture, and that is exactly a common mistake. Data residency, key custody, and court authority are not clauses the legal team owns at the end of a deal; they are the constraints that decide which cloud the workload can run on in the first place. Leaving a sovereign provider is not a vendor change; it is a full architecture migration under regulatory pressure, on a deadline set by someone outside the buyer’s organisation. A competitor with a somewhat better model has no answer to that, which is what makes the slice defensible.

Compliance as Architecture

The third slice, most of the times, binds to the same regulatory regimes as the second, but at the system level rather than the contract level. Sovereign guarantees are written into the deal; compliance guarantees are written into the data plane. Consider the record-keeping obligation in Article 12 of the EU AI Act¹. A system that has logging, traceability, and retention designed into the data plane produces audit evidence as a by-product of normal operation. A system that bolts logging onto the API gateway afterwards produces a slide about compliance, and compliance teams have learned to tell the difference. The practical gap shows up in the sales cycle: the vendor with Article 12 in the data plane is one a German tier-one manufacturer can buy without a two-quarter legal review, while the vendor without it loses the deal quietly, several polite meetings after the technical evaluation went well.

Anyone who has taken a cloud service through FedRAMP authorization knows this very well. The Moderate baseline requires audit logging, key management, session-boundary controls, and continuous monitoring evidence that only produces clean output if the data plane was built for it. Vendors that try to retrofit those controls typically double their authorization timeline, and many abandon the process before the 3PAO² signs off.

The engineering point is about timing. Re-architecting an inference pipeline for full-lifecycle auditability after it is in production is the most expensive moment to do that work, because it means rewriting the data plane and re-validating every consumer downstream of it. Designed in from the start, it is a few months of platform work. And Article 12 is only the first such regime binding at scale: GDPR enforcement is turning its attention to AI inference, US federal AI procurement rules are moving through OMB, and Japan and Singapore are drafting equivalents on roughly the same timeline.

Naming the Slice

None of this is worth much unless it changes a decision, so here is the operational version. Add a required field to your design-doc template, call it Slice, put it next to Owner and Production Readiness, and make it un-skippable. Every AI initiative on the roadmap names the slice it is building inside:

• Edge: bound to a device fleet you operate, with the telemetry and the control plane on your side.
• Sovereign: bound to a jurisdiction, with data residency, key custody, and audit authority fixed in the contract.
• Compliance: bound to a regulatory regime, with the evidence produced by the data plane itself.
• None of the above: a legitimate answer, provided the team states plainly that the initiative is buying capability rather than building a slice.

Quite a lot of good AI work belongs in that last bucket. The failure mode is not consuming commodity AI; it is consuming commodity AI while telling yourselves you are building a slice.

Making a slice real is mostly unglamorous platform work: a data catalog with lineage, policy enforced at the data plane rather than scattered through application code, evaluation gates in CI so a rented model can be swapped with evidence instead of hope. Nobody volunteers to fund this, and the teams that build it anyway end up with the only part of the AI stack that appreciates over time.

The architectural proposition is what gives the field its strength. If a slice is genuinely yours, the integration surface toward the model and the infrastructure stays on your side of the boundary, regardless of whose model you happen to rent this quarter. Model Context Protocol (MCP) is the current standards label for that discipline in the AI case: you expose your tools, your data, your retrieval, and your authorisation as MCP servers that you operate, and the model becomes a client connecting to them through a stable interface. That pattern is old in every mature API domain, but it is new in the model layer, where cross-vendor integration has been unusually painful until MCP arrived. Swapping Anthropic for OpenAI, or running both side by side, becomes a configuration change. The model is rented, the integration surface is owned, and the slice underneath is fused to something nobody can buy at any price.

The Structural Winners

The market spent $60 billion on the layer lesson. The slice lesson will be paid for over the coming year, mostly in deals that never reach the front page, and there is a quietly encouraging pattern in who stands to collect. Some of the players best positioned to own real slices are the ones the AI press writes about least: telcos with saturated CPE fleets, regulated industries whose data planes were built for auditors, regional cloud operators holding the right pieces of paper signed by the right ministries, and device manufacturers whose fleet telemetry has been compounding for a decade. These organisations have always lived in vertical slices, because their businesses never gave them another option; Conway observed as early as 1968³ that any system’s architecture ends up mirroring the organisation that built it, and their architectures were shaped by owning a fleet, a jurisdiction, or an auditable data plane long before AI arrived. They can be the structural winners of the next cycle, on one condition: that they recognise what they already own before they go shopping for an AI strategy.

So take into consideration this in your next roadmap plan, which AI Initiatives build inside a slice you own, and which ones are paying rent inside a slice that belongs to someone else?