There is a particular kind of slide that has been showing up in enterprise architecture decks for about ten years. It shows the cloud as an abstract layer at the bottom, with applications stacked on top, and arrows running between them. The slide is useful for explaining what platform engineering does. It is also, quietly, a lie.

The lie is not that the cloud isn't real. The cloud is extremely real. The lie is that the slide shows the cloud as a layer, when it is actually a building, in a specific place, full of specific machines, run by specific people who get specific calls at three in the morning when the air conditioning fails. The abstraction was useful enough that for a decade we let ourselves forget the buildings existed. We outsourced the buildings to Microsoft and Amazon and Google, paid the bills, and watched the architecture diagrams stop including any layer below "cloud."

The AI moment is making the buildings visible again, and most enterprise architecture functions are not ready.

This is the second piece in a series about how the AI moment is reshaping the enterprise architecture discipline. The first piece argued that the platform you built (your Paved Road, your Internal Developer Platform, your Landing Zone factory) is now one of two delivery tracks rather than the whole story, with a Modern AI Workplace track running alongside it and five horizontal fabrics shared between them. That essay made an honest gesture toward a layer underneath the fabrics, called it "the operated substrate," and then moved on. This is the piece where I stop gesturing.

What re-physicalization actually means

Bringing AI compute on-premises means choosing between two kinds of hardware, and they pose different problems. The first kind is the one the industry has been talking about for the last few years: rack-mounted GPU clusters, H100s or H200s or B200s in proper server chassis, in proper rooms, with proper power and cooling. This is a specific NVIDIA configuration in a specific rack in a specific facility, the kind of thing every enterprise IT shop knew how to talk about ten years ago and, after a decade of cloud migration, mostly stopped being asked about.

The second kind is genuinely new, and most architecture conversations haven't caught up to it yet. Devices like NVIDIA's DGX Spark are workgroup-class machines that run 70-billion-parameter models locally, but in a desktop form factor, on standard power, at workstation noise levels, sitting on or under a desk. You can chain a few of them together and put the chain in a project room. They are not racked. They are not in a controlled facility. They are not, by their physical profile, infrastructure in any traditional sense.

These two classes of hardware re-physicalize the platform in different ways, and the work of governing them is different too. The rack-mounted cluster looks familiar to anyone who has run a data center, even if the muscle memory has atrophied. The Spark-class device doesn't look familiar to anyone, because the category didn't exist before. The cloud-only narrative made the first kind invisible. The second kind is something the narrative didn't anticipate at all.

The re-physicalization isn't only about workgroup compute. It runs through three things at once.

The first is the workgroup tier itself, in both of the forms discussed above. If you go the rack-mounted route (an H100 or H200 or B200 cluster in a proper room with proper handling), the challenge is mostly one of remembering disciplines that lapsed during the cloud era. The cabinet, the cooling, the access control, the hardware refresh cycle, all of it is recoverable knowledge for any organization that ran a serious data center within the last ten years, even if that knowledge has been allowed to atrophy. The work is real, but it's familiar work.

If you go the Spark-class route, the challenge is something else. The unobtrusive physical profile is exactly what makes governance hard. There is no straightforward argument for locking a Spark in a cabinet, racking it in a controlled space, or treating it as different from the standard-issue PC three desks away, because physically it isn't different. It doesn't demand special power. It doesn't demand special cooling. The network requirements matter (a 70B-class inference workload talking to remote clients at meaningful throughput is a different shape than office traffic), but even those don't force a particular physical placement. The hardware will sit, governably or ungovernably, wherever the team decides to put it.

Which means the governance has to come from somewhere other than physical handling. Identity-bound access, ACL-as-code, lifecycle vending, audit trails, classification-aware routing, all the disciplines from the platform side, have to extend to a thing that looks like a workstation but acts like infrastructure. The teams that historically governed infrastructure governed it partly through physical control. The teams that historically governed workstations governed them partly through Intune and endpoint policy. A Spark fits neither category cleanly, and the work of figuring out which governance disciplines apply to which aspects of its operation is the work nobody has been funded to do yet.

The two options are not mutually exclusive. A serious enterprise AI strategy will probably end up with rack-mounted clusters in central facilities for the heaviest workloads, and Spark-class devices distributed to project teams for closer-to-the-work scenarios. Each demands a different kind of operational attention. The architecture function has to recognize both, and the operating teams have to be set up to handle a hybrid that didn't exist five years ago.

The second is endpoint NPUs. The current generation of laptops (the Copilot+ PCs, the M-series Macs, the AI-capable mobile workstations) have neural acceleration silicon that fundamentally changes what a corporate laptop can do. A 4-billion-parameter scout model running on an NPU is not the same animal as a Word document. It has performance characteristics, security implications, update cadences, and failure modes that the End User Computing team has not historically been responsible for. Whoever runs your endpoint estate is now operating an inference platform, whether they signed up for it or not.

The third is the network fabric between the two. A laptop in Lisbon talking to a Spark in Copenhagen needs latency that wasn't important when the laptop was just talking to Microsoft 365. The corporate WAN, the SD-WAN overlay, the VPN concentrator, the path through the carrier, all of it is suddenly part of the AI experience. If a remote worker's scout model takes 200 milliseconds to reach the heavy artillery in the office, the experience is fine. If it takes two seconds, the experience is broken, and the user finds a workaround that probably involves a SaaS chatbot and a copy-paste of NDA'd content.

None of these three are abstractions. All three are operated by specific teams who, in most organizations, were not consulted when the AI strategy was written.

The work that the slide hid

The cloud-only narrative had a particular cost that I want to name, because it has been sitting in the background of every "AI strategy" conversation I've been part of in the last year. The cost is that we trained two generations of architects to treat infrastructure as a resource you provision rather than as a substrate you operate. The platform engineering discipline, for all its real virtues, mostly inherited that framing. The Paved Road dispenses cloud subscriptions. The IDP automates pipeline configuration. The vending machine creates landing zones. All of these are provisioning activities, and they are all important, and none of them is the same thing as keeping the lights on.

The work that the slide hid is the operating work. It is the network engineer who notices that the path between two regions has degraded, and reroutes traffic before anyone files a ticket. It is the SRE who looks at the Splunk indexer cluster and realizes capacity will run out in six weeks unless something changes, and changes it. It is the storage admin who knows which array is approaching the end of its support life and quietly orchestrates the migration before it becomes a crisis. It is the identity team that, when the Entra ID outage hits a region, knows which downstream systems will fail and in what order. It is, in short, the work of making sure that the abstractions the architects rely on continue to be real.

This work has been undervalued for a long time. Some of that undervaluing was structural (the move from on-premises to cloud genuinely did automate a lot of routine operating tasks, and the people who used to do those tasks were retrained or moved on). Some of it was narrative (the platform engineering literature spent a decade celebrating the developer experience without spending much time on the operator experience that made the developer experience possible). And some of it was just generational, the way that every new layer of abstraction tends to forget the layer it sits on top of until something breaks.

The AI moment is the something that breaks.

What the AI moment specifically demands

The horizontal fabrics from the first essay (identity, data governance, observability, policy, vending) all sit on operated infrastructure that has to scale in new ways to support the second track.

The identity fabric has to handle a richer set of relationships. The IdP that used to answer "can Alice log in to Salesforce" now has to answer "can Alice's laptop reach the workgroup Spark, while running this specific model, on behalf of an agent that's calling another agent, right now". Same fabric, much more decision traffic. Not just user-to-application, but device-to-device, user-to-model, project-to-compute. A NetBird-style mesh with identity-bound ACLs is a different load on the IdP than a traditional VPN concentrator. Conditional Access policies have to evaluate posture for AI-related entitlements (is this laptop allowed to run a 7B model? is this device permitted to reach the workgroup Spark?) at a higher rate of decision than they did when the only question was "can this user log into Salesforce?"

The observability fabric has to ingest from new producers. Until recently the Splunk indexers had a predictable diet: sign-in logs, Defender alerts, application traces, the usual fare. They were sized for that. Now the same indexers are being asked to handle a firehose of new event types they weren't planned for. Endpoint inference logs, workgroup compute audit trails, model invocation telemetry, prompt provenance metadata. Capacity planning is a real conversation, not a slide.

The data governance fabric has to perform classification at a different latency. When a document is being classified for storage, classification can take seconds; nobody's waiting. When it is being classified for an inference routing decision (does this go to the endpoint scout, the workgroup heavy artillery, or the cloud LLM?), it has to take milliseconds, because the user is waiting on a response and the AI experience falls apart if the routing decision takes longer than the inference itself. The classification engine that lives comfortably in a batch pipeline now has to serve real-time queries. That's an operating problem, not a policy problem.

The policy fabric has to cover more enforcement points. Yesterday the policy story was tidy: Azure Policy enforces against cloud resources, Intune CSPs enforce against endpoints, and that more or less covered the estate. Today it doesn't. There are network ACLs in a mesh fabric, model entitlements in an endpoint runtime, and ingress rules on a workgroup Spark. Each enforcement point is operated by a different team. The policy-as-code discipline that worked when there was one enforcement point per resource type now has to coordinate across enforcement points that are not in the same control plane.

The vending fabric has to dispense different things. Provisioning used to mean "spin up a subscription, attach the right tags, hand it off". Now it also means handing someone a laptop that arrives with the right scout model already on it, or standing up a project tenancy on a Spark with the ACLs and data lifecycle policy baked in from day zero. The SVM dispenses cloud landing zones. The endpoint vending machine dispenses laptops with the right scout bundle, the right ZTNA profile, the right managed entitlements. The workgroup vending machine dispenses Spark project tenancy with ACLs and data lifecycle policy. All three are vending pipelines, but the operators of the underlying pipelines are different teams, and the pipelines themselves are operated services that someone has to keep running.

In each case, the architecture is recognizable. The operating load is new. And the operating load is not absorbed by the platform team. It is absorbed by the network engineers, identity admins, endpoint operators, observability engineers, and SREs who have been quietly keeping the lights on while the platform discipline was busy celebrating itself.

The architecture implication

There is a temptation, when you notice that operations matters, to add an "Operations" box to the architecture diagram and call the problem solved. This is the wrong move, for the same reason that adding a "Track 0" to a Two-Track diagram would be the wrong move. Operations is not a peer to the delivery tracks. It is the substrate the tracks depend on. Putting it in the diagram as if it were a peer flattens a layering relationship that actually matters.

The right move is to acknowledge the substrate as a layer, with a name, and to make the contracts between the substrate and the layers above it explicit. The umbrella from the first essay had principles at the top, fabrics in the middle, tracks at the bottom, and seams between the tracks. The honest version has a foundation underneath all of it: the operated infrastructure that makes the fabrics real. Network. Datacenters and on-premises compute estate. Identity stores. Observability platforms as products rather than as capabilities. Hardware lifecycle. Power and cooling. The mundane things that the cloud allowed us to forget.

The contracts between the substrate and the fabrics are where most of the interesting architectural decisions actually live. What's the SLO of the identity provider, and what does the policy fabric assume about availability? What's the maximum latency budget for a real-time classification call, and what does that mean for where the classification engine is hosted? What's the failure mode of the workgroup Spark when the office network goes down, and does the scout-and-heavy-artillery model degrade gracefully or fail catastrophically? Each of these is a contract. Each contract is a conversation between a fabric owner and a substrate operator. Each conversation is the kind of thing that, if it doesn't happen, gets discovered as an incident report eighteen months later.

The architecture diagram should make these contracts visible. The org chart should make their owners namable. And the work of operating the substrate should be funded as a peer to the work of building the tracks, because if it isn't, the tracks won't run.

What this means for the people doing the work

There is a category of professional in most enterprises who has been told, implicitly or explicitly, for the last decade, that their work is becoming less central. The network engineer who watched the WAN architecture get abstracted into SD-WAN. The identity admin who watched directory services move into the cloud. The systems administrator who watched physical servers disappear into virtualization, and then virtualization disappear into containers, and then containers disappear into serverless. The story they were told was: your work matters less now, because the abstraction has eaten it.

This was always partially false (someone has to operate the abstraction, and that someone is them) but it was emotionally true enough that the professional category mostly accepted it. The center of gravity in IT moved to platform engineering, to cloud architecture, to security architecture, to AI strategy. Operations became the thing you did to support the interesting work, rather than the interesting work itself.

The AI moment changes this. The second track, the Modern AI Workplace, is built on physical hardware in physical buildings connected by physical networks. The work of operating that estate is the work of making AI in the workplace real. The network engineer who knows how to size the office WAN for inference traffic is not legacy support. They are the person whose work determines whether the corporate AI strategy actually functions for remote workers. The identity admin who can model device-to-device authorization in NetBird is not a supporting role. They are the one who makes Zero Trust enforceable at scale. The systems administrator who can operate a workgroup Spark with proper lifecycle and audit is the one who lets project teams work with NDA'd data without leaking it to a hyperscaler.

This isn't sentimentality. It's an architectural fact. The discipline that has been treated as legacy is the one the AI moment most directly depends on. Any enterprise architecture function that doesn't recognize this and recruit accordingly will discover, in the next eighteen months, that its AI strategy is a set of slides without a substrate.

The honest parts

Three things I'm not certain about, and want to test against other people's experience.

The first is whether the framing "operations as substrate" lands the way I want it to, or whether it accidentally reinforces the hierarchical thinking that put operations under the platform in the first place. The point is not that operations is below the tracks in some pejorative sense. The point is that the tracks depend on operations the way a building depends on its foundation. Foundations are not less important than the buildings on top of them. They are the thing that lets the buildings exist. I think the substrate framing captures this, but I'm willing to be told otherwise.

The second is whether the network fabric for the AI workplace is actually a meaningfully different problem than the network fabric for cloud applications, or whether I'm overstating the change. My instinct is that the latency budgets are different, the traffic patterns are different (inference workloads burst differently than HTTP), and the trust model is different (device-to-device matters in a way it didn't), but I haven't operated this at scale and I'd rather hear from people who has.

The third is whether the cultural recovery I'm describing (operations work being recognized as central again) is actually happening, or whether I'm projecting onto the situation what I'd like to see. The platform engineering discipline has been very good at writing manifestos about its own importance. Operations has, on the whole, been worse at this. The reframing has to come from somewhere, and there's no obvious reason it has to come from the operators themselves rather than from architects who notice that the substrate is what makes their architectures real.

If you are doing this work, in any of the disciplines I've named, I'd like to hear from you. The substrate isn't going to claim its own seat at the AI strategy table. Someone has to invite it. This essay is one such invitation. The next pieces in the series go into the fabrics one at a time (identity first, because it's where everything else starts), and after that into the ZTNA decision, where the network and identity teams are going to have to figure out together what shape the future actually takes.

Christoffer Silversparre Jørgensen is a cybersecurity architect based in Helsingør, Denmark, writing about the intersection of security architecture, platform engineering, and the AI-era enterprise. The first piece in this series, The Two-Track Enterprise, introduced the umbrella frame this essay extends.

A senior engineer is working from home on a Tuesday afternoon. She has a confidential project model open. Fifty gigabytes of structural design under NDA, the kind of thing the firm's reputation depends on keeping inside its own walls. She's stuck on a load calculation she knows an LLM could help her think through, if only she could ask it the right question with the right context.

Her options, today, are these. She can paste excerpts into ChatGPT and pretend the DPA covers it. She can use the corporate Copilot license, which is fine for drafting emails and useless for the actual model. She can wait until tomorrow and ask a colleague. Or she can do without.

Notice what's missing from that list: the platform her company spent five years building.

The Paved Road, the Internal Developer Platform, the Landing Zone factory, whatever it's called locally. That platform was built to make shipping cloud-resident applications fast, secure, and governed. It is, by every measure that mattered when it was scoped, a success. But it was never built for her. She isn't shipping an application. She's trying to do her job, on her laptop, on a Tuesday afternoon, with the tools the AI moment has put within reach but governance has not yet caught up to.

This essay is about that gap. It is about why the platform you built is now one of two delivery tracks your enterprise architecture function needs to run, rather than the whole story. And it is about the specific seams between those tracks, which most organizations will have to make explicit before the gap turns into something worse.

The frame that no longer fits

For most of the last decade, "platform engineering" has meant a particular thing. It meant building the substrate on which application teams ship software: vended subscriptions, infrastructure-as-code modules, CI/CD templates, security scanning gates, observability stacks, policy engines. The Netflix-inspired Paved Road. The Spotify-inspired golden paths. Whatever the local dialect, the shape is recognizable. A small platform team builds opinionated defaults. A large application population consumes them. Governance is enforced by making the right way the easy way.

This frame works. It is, arguably, the most successful pattern enterprise IT has produced in twenty years. The reason it works is that it solves a real problem (the friction between what developers want to build and what compliance, security, and operations need to be true) by automating the controls rather than gating them. Guardrails, not gates. Comply or explain.

But the frame has an unstated scope, and the scope is starting to bind.

The platform you built was scoped to applications. It assumed that the unit of governance is a service running in a cloud subscription, that the customer is a development team, that the artifacts are code and configuration, and that the failure mode is shadow IT, where a team goes off-platform to ship faster.

The AI moment has produced a different unit of governance, a different customer, different artifacts, and a different failure mode, all at once. The unit is now compute proximity to the user: endpoint, workgroup, cloud. The customer is every employee, not just developers. The artifacts are models, prompts, and inference traffic, not code and configuration. And the failure mode is shadow AI, where engineers paste NDA'd content into ChatGPT because the corporate alternative doesn't help them.

None of these are subsets of the original platform problem. They are a peer to it. Treating them as a peer rather than as an annex to the platform changes how you have to think about the architecture function as a whole.

Two tracks, sharply defined

The first track is the one you already have. Call it the Paved Road if you like, or whatever you call yours. Its scope is cloud-resident applications and the data products that run on them. Its mental model is "I have an idea for a thing the company should be running. Vend me a place to run it, and I'll bring code." Its primary customer is the engineering organization. Its primary failure mode if neglected is unmanaged cloud spend and uncatalogued application sprawl.

The second track is the one most organizations are now improvising into existence under labels like "AI strategy" or "Modern Workplace" or "Copilot rollout." Done deliberately, it is the Modern AI Workplace. Its scope is employee-proximate compute and AI: laptops and the local models on them, workgroup-class compute (DGX Spark-class machines, or their equivalents, sitting in offices), the network fabric that connects employees to that compute, and the productivity AI tools they use day-to-day. And increasingly, the user of all of this isn't only the human employee. Agents running on the laptop, agents invoked from the workgroup Spark, agents chained across multiple services to complete a task on the employee's behalf, all of these are themselves consumers of the compute, the identity, and the data the track provides. "Employee-proximate" has to be read with that in mind. The track is built around where the work happens, not solely around who or what is doing it. And increasingly, the user of all of this isn't only the human employee. Agents running on the laptop, agents invoked from the workgroup Spark, agents chained across multiple services to complete a task on the employee's behalf, all of these are themselves consumers of the compute, the identity, and the data the track provides. "Employee-proximate" has to be read with that in mind. The track is built around where the work happens, not solely around who or what is doing it.

Its mental model is borrowed from a useful metaphor. Think of the AI a remote worker carries on their laptop as a scout: a small, fast model (in the 4B to 8B parameter range, something like Gemma or Phi or a quantized Llama variant) that handles real-time work locally. Drafting, autocomplete, summarization, search over local files. The scout works offline. It works on the train. It works without a stable connection. When the work demands more, the scout can call back to the heavy artillery: a workgroup-class machine in the office that runs a 70B-class model with the full project context loaded, or a cloud AI service for tasks that warrant it. The remote worker isn't cut off from intelligence. They carry the scout, and they call in the heavy artillery when the connection allows.

So the mental model becomes "I have a job to do. Give me a working laptop with the right scout on it, the right access to the heavy artillery when I need it, no matter where I'm sitting." Its primary customer is every employee. Its primary failure mode is shadow AI, and the cottage industry of unmanaged tools that fills the vacuum when the corporate offering doesn't meet the moment.

These tracks are not subsets of each other. They have different customers, different cadences, different ownership in any sensible org chart. The Paved Road typically lives in Platform Engineering. The Modern AI Workplace, if it exists at all, usually lives somewhere between the End User Computing team, the Identity team, and an AI Center of Excellence that nobody reports to cleanly.

What the two tracks share is governance fabric. They share principles. They share the comply-or-explain philosophy. The same identity system underwrites both. The same data classification scheme should drive policy in both. The same observability stack should ingest telemetry from both. If you build the Modern AI Workplace as a fully separate program with its own identity provider, its own classification taxonomy, its own logging pipeline, you've solved the immediate problem and created a much worse one in eighteen months when the two diverge.

The frame that fits, then, is not "platform plus annex." It is two tracks under one umbrella, sharing horizontal fabric.

The horizontal fabric

When you look hard at what the existing platform actually contains, most of it isn't really platform-specific. The identity system, the data governance capability, the observability stack, the policy engine, the vending pattern. These are enterprise capabilities that the platform happens to consume. They were built inside the platform program because that's the program that needed them first. They don't belong to the platform. The platform consumes them, and so does the second track, and so will any third track that comes along in five years.

There are five of these horizontal fabrics, and naming them as horizontal rather than as platform Building Blocks is the move that lets the umbrella frame hold.

Identity and access. This is the fabric that answers the question "is this person, device, or service allowed to do this thing right now?" Entra ID or its equivalent, federated to whatever device posture system you use, with privileged access management for the high-risk tier. The Paved Road consumes this for application identity: workload identity federation, RBAC on cloud resources, conditional access for admin paths. The Modern AI Workplace consumes the same fabric for device-to-device authorization (which laptop is allowed to reach which workgroup compute), endpoint AI model entitlement (who is allowed to run which model locally), workgroup compute access (which project teams can address which Spark), and increasingly model-to-model authentication. When the scout on a laptop calls back to the heavy artillery in the office, or an agent running locally invokes a tool exposed by a cloud service, those calls are themselves identities that have to be authorized, audited, and revocable. One identity system, multiple consumption patterns, and the model-to-model case is the one most organizations haven't started thinking about yet.

Data governance and privacy. This is the fabric that answers "what is this data, who's allowed to handle it, and where is it allowed to go?" Classification, lineage, privacy enforcement. The Paved Road consumes this for data assets in cloud storage and databases, the usual kind of thing you'd expect a data catalog to track. The Modern AI Workplace consumes the same classification metadata for a different purpose: it uses it to route AI workloads to the appropriate compute tier. A document classified as Restricted is not allowed to leave the laptop, period. An Internal document can flow to a workgroup Spark. A Public document can hit a cloud LLM. The classification scheme is the same in both cases. The decision it informs is different.

Observability and detection. This is the fabric that answers "what is happening across our estate right now, and would we know if something were going wrong?" Splunk, Sentinel, whatever your stack is. Security telemetry to one place, application telemetry to another. The Paved Road has been feeding this for years; sign-in logs, audit logs, application traces, all routed to the right indexes. The Modern AI Workplace adds new event sources (endpoint inference logs, workgroup compute audit trails, network ACL hits from whatever ZTNA fabric you settle on) but they flow into the same indexes with the same retention policies. The fabric doesn't change. The producers do.

Policy and compliance. This is the fabric that answers "what are we required to do, what are we forbidden from doing, and how do we prove either?" Azure Policy enforces against cloud resources. Intune CSPs enforce against endpoints. Network ACLs enforce against connectivity. The implementations are different, and the teams operating each enforcement point are different. The governance pattern, though, is identical: policy as code, comply-or-explain exceptions, a ServiceNow-backed exception process, a designated architect-of-the-gate role. Both tracks live under the same governance discipline, even though the levers each track pulls are different.

Vending and lifecycle. This is the fabric that answers "how do we provision a new thing in a way that's compliant from the moment it exists?" It's the one most organizations underrate, because the unglamorous work of automating the first day of a resource's life is what determines whether everything that follows is governed or not. The Paved Road has a Subscription Vending Machine that dispenses cloud landing zones in twenty minutes, fully tagged, identity-bound, policy-assigned, ready for a development team to start using. The Modern AI Workplace needs an endpoint vending machine (laptop plus AI scout bundle plus ZTNA profile, dispensed via Intune) and a workgroup vending machine (Spark project tenancy with ACLs and data lifecycle policy). All three use the same pattern: a request comes in, an automated pipeline does the provisioning, identity gets bound, policy gets assigned, an audit trail starts. If you have built one of these vending machines, you can build the other two. But you have to decide to build them, and you have to decide who owns them.

These five fabrics are the umbrella. They are described once, owned by named teams, consumed by both tracks. Anything you find that lives in only one track is a candidate to be promoted upward. Anything you find duplicated between the tracks is a sign the umbrella isn't doing its job.

The substrate beneath the substrate

There is a layer underneath the fabrics that I want to acknowledge directly, because if the essay stopped at "five horizontal fabrics" it would describe the architecture as if it floats. It doesn't.

The fabrics are not principles. They are operated services. The identity provider is software running on infrastructure, with operators on call when authentication goes down. The Splunk indexers have capacity planning problems and storage costs. The ZTNA gateways have hardware refresh cycles and patch windows. The vending pipelines are themselves applications that have to be deployed, monitored, and maintained by someone whose pager goes off when they break. None of this is incidental to the architecture. It is the architecture, in the sense that the architecture only exists when the substrate beneath it works.

This is the layer that the cloud-only narrative of the last decade has been quietly allowed to forget. The Modern AI Workplace track makes that forgetting unsustainable, because workgroup compute and endpoint NPUs and the network fabric that connects them are all physical things in physical buildings. A DGX Spark in a Copenhagen office is not a cloud abstraction. But it isn't a traditional server either. It's a desktop-form-factor device that draws roughly what a gaming PC draws, plugs into a normal outlet, and sits on or near a desk. It needs network, lifecycle planning, identity binding, an audit trail, and a person who knows what to do when the GPU degrades. What it doesn't need is a cabinet or a controlled facility, which is precisely what makes it harder to govern than infrastructure that demanded those things. The hardware is unobtrusive enough that none of the existing handling categories quite fit. The work of figuring out which disciplines apply to it, and who owns each one, is the work the AI moment has put back on the table for people who had stopped being asked.

I'll write more about this in a follow-up piece, because it deserves more space than a section. The short version, for the purposes of this frame, is that the umbrella has a foundation, and the foundation is operated by people whose contribution to the AI conversation has been systematically undervalued because the dominant narrative pretended infrastructure was a cloud bill. It isn't, and the second track will make that obvious in a way the first track was allowed to obscure.

A picture of the whole thing

The principles never move. The fabrics are described once and consumed by both tracks. The tracks describe their own delivery mechanisms but only insofar as they're track-specific. The seams are explicit, named, and owned. And the substrate underneath is acknowledged as the thing that makes any of it real.

The seams

The umbrella frame works only if the seams between the tracks are explicit and owned. Most "two-track strategy" documents fail here, because they describe the tracks in isolation and never specify the contracts between them.

A seam is the place where two tracks have to agree on something for either of them to function. A contract is the document, written down somewhere, that records what they've agreed. "We will represent classification labels in this format, refresh them at this cadence, and treat them as authoritative" is what a contract sounds like in practice. It's mundane. It's also what separates an architecture that holds together from one that quietly fragments while everyone insists it's working.

Three seams, in my experience so far, are the ones that matter.

The first seam is classification flowing across. When the data governance fabric classifies a document (Public, Internal, Confidential, Restricted) that classification has to be readable by the Modern AI Workplace's tier-routing logic, so that the routing logic can refuse to send a Restricted document to an endpoint LLM and require workgroup-tier processing instead. The Paved Road produces this classification (Purview, sensitivity labels, whatever your stack uses). The Modern AI Workplace consumes it as a routing input. The contract between the two would say something like: classification labels are stable strings drawn from a defined vocabulary, exposed via a documented API the routing logic can call, refreshed within seconds when a label changes, and never redefined per track. If a track invents its own classification scheme, the umbrella has failed.

The second seam is governance instrumentation extending to non-cloud compute. A workgroup Spark sitting in your Copenhagen office needs the same governance treatment as an Azure Kubernetes cluster: identity binding, policy assignment, observability hookup, lifecycle management. But it isn't in Azure. The Paved Road's Terraform patterns don't apply directly. The contract here is that the patterns (declarative configuration, policy as code, vended provisioning, audit trail) extend to workgroup compute even though the implementations differ. The workgroup Spark is governed by the Paved Road's instrumentation patterns even though it is operationally owned by the Modern AI Workplace track. Without this seam, you end up with a Spark in the office that nobody's actually responsible for, configured by whoever set it up, with no audit trail and no lifecycle plan.

The third seam is model and prompt provenance as a shared service. A fine-tuned Llama variant might run on a Spark, an Azure OpenAI deployment, or, eventually, with quantization, be shipped down to laptops as a scout. The model itself, with its training data, evaluation results, and prompt lineage, is a data product with provenance. It cannot belong to one track. If the Paved Road's LLMOps function tracks prompts and models for cloud-tier inference, and the Modern AI Workplace tracks them separately for endpoint and workgroup tiers, you have two registries, two truths, and a guarantee of drift. The contract is that model and prompt provenance is a horizontal capability. Neither track owns it alone, but both depend on it.

There is probably a fourth seam, which I'm less confident about and which I'd like to test against other people's experience. It's the portability seam: the requirement that data and models crossing track boundaries use open formats and standard interfaces, so that an organization isn't locked into a particular track's vendor choices when the technology shifts. This matters more in the AI domain than it did for cloud applications, because the model and inference runtime landscape is moving fast and last year's defaults are this year's lock-in. Operationalizing this is hard, and I haven't seen anyone do it well yet.

The honest part

I should name what's hard about this, because the architecture diagram makes it look cleaner than it is.

The first hard thing is organizational. The umbrella frame requires a role that owns the umbrella. Someone whose job description includes the five fabrics and the seams between tracks. In most enterprises, that role doesn't exist cleanly. It's the Principal Enterprise Architect on a good day, the CTO's office on a better one, and nobody on a typical day. Without that ownership, the two tracks will drift apart in eighteen months because each track's day-to-day pressures will pull them apart and there will be nobody whose job is to enforce coherence. If you draw the umbrella on a whiteboard and there is no name attached to it, you have not solved the problem. You have documented it.

The second hard thing is political. The Modern AI Workplace track, in most organizations today, doesn't have a sponsor. The Paved Road usually has Platform Engineering or a CIO/CTO sponsor. The Modern AI Workplace has aspirations and Copilot licenses. Standing it up as a peer to the platform, which is what the umbrella frame requires, means convincing leadership that AI in the workplace is not a feature of the existing platform but a parallel program with its own roadmap, its own budget, and its own governance commitments. That conversation is harder if the existing platform isn't fully anchored either, which it often isn't. There is no clean answer to this. The best I can offer is: name the gap honestly, and don't pretend the umbrella exists when it doesn't.

The third hard thing is technical and unresolved. The ZTNA fabric question (what actually carries identity-bound traffic between laptops, workgroup compute, and cloud) is open. Cisco Secure Access, Entra Private Access, NetBird (an open-source WireGuard-based mesh with a self-hostable control plane that addresses a lot of the data-sovereignty objections SaaS-only ZTNA faces), something else. Each has trade-offs and none is obviously right for every organization. Endpoint AI model governance (which models employees can run locally, how those models are updated, how their behavior is observable) is a problem nobody has solved well at enterprise scale yet. Workgroup compute capacity planning, when the unit cost is six figures and the demand pattern is project-driven, is a finance question masquerading as an architecture question. I don't have clean answers to any of these, and I'm suspicious of anyone who claims to.

The frame doesn't solve these problems. It does something narrower but more useful: it puts them in the right place. The ZTNA fabric is an open decision at the umbrella level, not a per-track decision, because both tracks consume the answer. Endpoint AI model governance is part of the policy fabric, not the Modern AI Workplace track in isolation. Workgroup compute capacity is a vending and lifecycle problem inheriting Paved Road patterns. The frame turns scattered "things that are hard" into named architectural decisions with owners.

What this is for

I am not arguing that every organization needs to formally split into two tracks tomorrow. I am arguing that the second track exists whether you've named it or not, and that the cost of leaving it unnamed is paid in the form of shadow AI, scattered governance, divergent identity flows, and an architecture function that loses coherence faster than it can publish documents.

If you are an enterprise architect looking at an existing platform program and wondering why the AI conversation doesn't fit into it, this is the frame I'd suggest trying. If you are a security architect, which is where I'm writing from, the frame matters because the controls you care about (identity, data classification, observability, policy) are exactly the horizontal fabric that has to stretch across both tracks. If those controls only enforce against the platform, they don't actually enforce. They enforce against half the compute estate and miss the other half.

If you've worked through this in your own organization, I'd genuinely like to hear how. The question I'm most interested in isn't whether the second track exists. It does. The interesting question is who in the org chart ends up owning it, and how the seams get specified in practice. The architectural framing is the easy part. The naming of an owner, and the standing up of the governance discipline that makes the umbrella real, is the part where most organizations are still improvising.

The next piece in this series goes underneath the umbrella, into the substrate the fabrics depend on. It's called The Substrate Beneath the Substrate: Why AI Re-Physicalizes the Platform, and it argues that the AI moment has quietly done something the platform-engineering discipline wasn't ready for: it has put physical hardware back into the architecture conversation, and made the work of the people who keep that hardware alive central again. After that I'll work through the five fabrics in turn, the ZTNA decision specifically, and how the security architect role itself is shifting under our feet. For now, this is the frame.

Christoffer Silversparre Jørgensen is a cybersecurity architect based in Helsingør, Denmark, writing about the intersection of security architecture, platform engineering, and the AI-era enterprise.