Home / Insights / The AI Industrial Stack

Insight · AI as industrial infrastructure

The AI Industrial Stack

Artificial intelligence has stopped behaving like a software product and started behaving like an industrial system. Six layers now sit between a model and a result: intelligence, enterprise, physical AI, compute, energy and society. Deployed capability is governed by the weakest of the six, and the weakest one is usually not the model.

WAJD Group · AI and infrastructure · 16 minute read

Executive summary

For a decade the governing question in artificial intelligence has been how capable the model is. That question is becoming the wrong one, not because capability stopped mattering, but because it stopped being scarce relative to everything else a deployment needs.

A model that can reason about a production schedule still requires an organisation willing to change the schedule, a plant instrumented well enough to execute it, accelerators to run on, a substation to power them, and a community that has not blocked the building they sit in. Each of those is now a live constraint somewhere in the world, and each moves on a different clock.

This paper sets out the AI Industrial Stack: six layers, the dependencies between them, and one central claim. Realisable AI capability is not the sum of the layers. It is governed by the weakest of them, and the weakest layer is usually the one with the longest lead time. That reframing is what turns a diagram into something a board can act on.

What is already established, and what is not

Layered models of AI infrastructure are not new, and any framework that pretends otherwise deserves to be dismissed. NVIDIA's AI factory framing already unifies five layers, running energy, chips, infrastructure, models and applications into a single system whose output is measured in tokens. Recent academic work has proposed cross layer taxonomies spanning energy systems, facility engineering, computing hardware, cluster design and workload execution. Industry versions of the five layer stack are abundant.

What every one of these has in common is that it is an infrastructure stack. It runs from the electricity to the application and stops at the machine. It describes what is required to produce intelligence, and says almost nothing about what is required to use it.

The existing stacks explain why compute gets built. They do not explain why most of it, once built, fails to change anything inside a company. WAJD Group

The contribution here is the two layers those models omit, and both are load bearing. Above the machine sits the enterprise, the organisational apparatus that converts a capability into a changed process. Below and around everything sits society, which has recently become a hard constraint on infrastructure rather than a soft context for it. Adding those two turns a supply chain diagram into a socio-technical one, and changes what the framework predicts.

The six layers

Each layer is briefly defined by what it contributes and, more usefully, by how it fails.

  • 1. Intelligence. Foundation models, multimodal and reasoning models, vision language action models, world models, agents and domain specific models. Failure mode: the model is wrong, or is right about something nobody needed. This is the only layer most AI strategies actually address.
  • 2. Enterprise. AI strategy, the Chief AI Officer and the leadership structure around them, operating model design, data strategy, process ownership, portfolio management, risk, security and the workforce. Failure mode: the capability is real and the organisation cannot absorb it. This is where most spend currently dies.
  • 3. Physical AI. Robots, autonomous mobile platforms, vehicles, drones, machine perception, tactile sensing, manipulation, digital twins, edge inference and cyber-physical systems generally. Failure mode: the model transfers poorly to a physical environment it was never grounded in. Recent work on physics informed embodied intelligence identifies exactly this gap between foundation models and complex manufacturing manipulation.
  • 4. Compute. Accelerators, host processors, interconnect, memory, storage, cloud and edge capacity, the buildings and the cooling. Failure mode: capacity exists but is not available to you, at a price you can pay, in a jurisdiction you can use.
  • 5. Energy. Generation, transmission, distribution, grid connection, firm capacity, storage, cooling and water. Failure mode: the power arrives four years after the business case expired.
  • 6. Society. Employment and skills, regulation, planning consent, water and land, electricity prices paid by everyone else, and public trust. Failure mode: the project is legal, funded, powered, and refused.

A useful discipline when reading that list is to notice how the failure modes change character as you descend. The first is a question of accuracy. The last is a question of consent. Nothing in a model evaluation suite tests for either of the two at the bottom.

The stack is a loop, not a ladder

Drawn as six boxes, the framework invites the wrong reading: that intelligence sits on top and everything below serves it. The real structure is circular, and the loop closes in a way that has already started to bite.

More capable models raise demand for compute. Compute raises demand for electricity. Electricity demand pulls forward infrastructure investment, which lands physically in specific communities. Those communities respond, and the response becomes regulation. Regulation constrains where data centres can be built. That constrains available compute, which constrains the intelligence layer that started the sequence.

This is not a forecast. Every step of it has now happened. The International Energy Agency expects global data centre electricity consumption to more than double, from 415 TWh in 2024 to around 945 TWh by 2030, and to reach roughly 1,200 TWh by 2035. In the United States, data centres account for nearly half of all electricity demand growth to 2030. And in August 2026 Reuters catalogued the response: New York became the first American state to impose a full construction moratorium, covering data centres drawing 50 MW or more; Pennsylvania now requires environmental safeguards, transparency and local community approval, and has removed data centres from its fast track permitting; Texas paused new approvals through grid interconnection; Monterey Park in California enacted a permanent ban by ballot measure. Outside the United States, Amsterdam has extended restrictions on new development to at least 2030, Dublin froze grid connections from 2021 to 2025 and lifted the freeze only on condition of on-site generation, and Denmark has drafted legislation prioritising other sectors for connection.

Water is following the same path. The National Conference of State Legislatures has documented the emergence of state level regulation of data centre water use, with reporting and disclosure requirements introduced across a growing number of states and Virginia's provisions taking effect from January 2027.

The conclusion for anyone planning AI capacity is uncomfortable and simple. Social licence is now an input to the compute budget.

The central claim: capability is governed by the weakest layer

It is tempting to express industrial AI capability as a function of its six components and leave it there. That is a notation, not a model, and it cannot be tested. The framework only becomes useful when it commits to a shape.

The claim made here is that realisable capability behaves like a minimum rather than a sum:

Deployed AI capability approximates the weakest layer, not the average of the six. The binding constraint proposition

This is the agricultural law of the minimum applied to an industrial system, and it is falsifiable in a way a weighted sum is not. It predicts something specific and testable: investment in a layer that is not currently binding produces no measurable increase in deployed capability. Buy better models for an organisation whose constraint is process ownership and nothing happens. Add accelerators to a site whose constraint is a grid connection and nothing happens. If that prediction fails in the field, the proposition is wrong and should be abandoned. That is the point of stating it this way.

It also implies a diagnostic that is far more actionable than a maturity score. Before any AI investment, name the binding layer. Most organisations, asked to do this honestly, do not name the model.

The AI deployment gap

The first construct the framework generates is the distance between the capability an organisation could use and the capability it can actually run.

This gap already has a rough measurement in the literature, which is a point in its favour rather than against it. Boston Consulting Group's 2024 work found that 74% of companies had yet to show tangible value from AI, that only 26% had built the capabilities to move beyond proofs of concept, and that just 4% were generating significant value across functions. Subsequent work has put the more contested figure that the overwhelming majority of generative AI pilots produce no measurable return, a claim worth treating carefully but not worth dismissing.

What the stack adds is an explanation with a location. The gap is not a general failure of ambition. It is the height of the binding layer, and it can be attributed. An organisation whose pilots stall for lack of clean master data has an enterprise layer constraint. One whose vision models work in the lab and fail on the line has a physical AI constraint. One that cannot get capacity in its own jurisdiction has a compute constraint. These require entirely different remedies, and are routinely treated as though they were the same problem.

AI infrastructure elasticity is a lead time, not a capacity

The second construct concerns response rather than level. How quickly can an organisation, or a country, increase AI capability when demand for intelligence rises?

The instinct is to answer in capacity: available megawatts, available accelerators, available capital. That is the wrong unit. Elasticity is set by the slowest thing in the chain, and the layers differ from one another by orders of magnitude.

  • Fine tuning or deploying a model: days to weeks.
  • Re-engineering a process and retraining the people who run it: months to a couple of years.
  • Building a data centre shell: roughly eighteen to twenty four months.
  • Procuring a large substation transformer: Wood Mackenzie tracked lead times rising from around 50 weeks in 2021 to about 120 weeks in 2024, with substation transformers now exceeding 160 weeks in 2026. That is over three years for a single component.
  • Getting a grid connection in a congested market: PJM reported that projects entering service in 2025 had taken on average more than seven years to reach operational status, three of those before an interconnection agreement was even signed.
  • Winning planning consent and public acceptance: unbounded, and increasingly a hard no.

Set those side by side and the strategic picture inverts. The layer that everyone competes on moves in weeks. The layer that actually gates deployment moves in years, and cannot be accelerated by capital in the way software can. Two countries holding identical models will diverge sharply in industrial AI capability, and the divergence will be explained almost entirely by the bottom three layers.

This is the practical reason energy strategy and AI strategy have quietly become the same document. Not because electricity is interesting, but because it is the longest pole in the tent.

What this means in manufacturing

Manufacturing is the cleanest test environment for the framework, because all six layers are present on one site and can be observed at once.

An intelligent factory in the sense meant here is not an automated one. Automation executes a fixed sequence. What the stack describes is a closed loop that perceives, reasons, predicts, acts, senses the outcome and updates: a foundation model reasoning over production, grounded in a twin that stays true to the plant, executing through vision and manipulation, feeding maintenance, energy and supply decisions, and learning from what actually happened.

The shift is from automation to adaptive autonomy, and it changes the risk profile completely. A software agent fails by returning a wrong answer. A physical agent fails by damaging a machine, injuring someone, scrapping a batch or tripping a site. That difference is why the enterprise layer cannot be skipped in industrial settings: the governance, the guardrails and the audit trail are not compliance overhead, they are the precondition for letting the system act at all. We have written separately on twins that assemble themselves and degrade loudly, on the rules an agent works inside, and on the record it has to leave behind. Each is a component of layer two, without which layer three cannot be trusted with anything that moves.

What this means for the Chief AI Officer

The Chief AI Officer is a genuinely under examined role. The peer reviewed information systems literature on it is thin, and the major conferences have only recently opened tracks covering AI leadership and the governance of C-suite AI roles. Practice is running well ahead of research.

The stack suggests the role is being scoped too narrowly wherever it is defined as senior ownership of AI procurement. Six questions, one per layer, describe the actual mandate.

  • Intelligence. Which model capabilities create advantage here, and which are commodities we should rent?
  • Enterprise. Which processes change, who owns them afterwards, and what does the operating model look like when they have?
  • Physical AI. Which of our physical processes can become autonomous, at what risk, behind which guardrails?
  • Compute. What capacity do we need, where must it sit legally, and what happens if it becomes unavailable?
  • Energy. Can the workload be powered, at what price, on what timescale, and who else is bidding for the same connection?
  • Society. Is the deployment acceptable to our workforce, our regulator and the community around the site?

A CAIO who can answer the first two and none of the last four is running a software function. The role the stack implies is an integrator, and the first act of integration is naming which layer currently binds.

What this means for governments

Governments separate technology policy, industrial policy, energy policy, environmental policy and labour policy into different departments with different timescales and different ministers. The stack cuts across all five.

A national AI strategy that does not model electricity availability is a press release. An energy plan that does not model AI load will underestimate demand. An industrial strategy that ignores physical AI will misjudge productivity. A skills plan that ignores autonomous systems will train for the wrong decade. An environmental policy that ignores data centre growth will be overtaken by it. The moratoria and water reporting requirements now appearing across jurisdictions are what it looks like when these are governed separately and collide in public.

The single line worth taking from this section is that AI policy has become industrial policy, and the countries that recognise this first will be the ones whose grid connection queues are short enough to matter.

What would make this testable

A framework that only organises vocabulary is worth little. This one generates a research programme with a falsifiable core, and the sequence matters.

  • Instrument first. Build a six layer maturity assessment that can be applied to a single site in a day: experimental, digital, connected, physical, autonomous, and fully industrial where all six layers are integrated.
  • Test the binding constraint proposition. Across a sample of sites, check whether investment in non-binding layers produces measurable gains. This is the study that decides whether the framework is real.
  • Attribute the deployment gap. For each organisation, identify which layer accounts for the distance between potential and realised capability, and test whether the distribution of binding layers differs by sector.
  • Measure elasticity as time. Record actual lead times per layer rather than stated capacity, and test whether the slowest layer predicts time to deployment better than budget does.
  • Then interview and case study. Chief AI Officers, plant directors, robotics engineers, data centre operators, grid planners and regulators, to explain the patterns the instrument finds rather than to generate hypotheses in the first place.

Validation would test whether higher stack maturity correlates with return on AI investment, productivity, resilience, energy efficiency and time to deployment. The construct most likely to survive contact with data is the lead time one, because it is measured in public records rather than in self reports.

How to apply this

  • Name your binding layer, in one sentence, before approving any AI spend. If nobody in the room can name it, that is the finding.
  • Ask what your organisation would do with a model twice as good as today's. If the answer is nothing, your constraint is layer two and no procurement fixes it.
  • Put a lead time, not a budget, against each of the six layers for your next deployment. Take the largest number. That is your schedule.
  • For anything physical, write the failure mode down in the language of the plant rather than the language of the model: what gets damaged, who gets hurt, what stops.
  • If your plan depends on new power, find out what the connection queue actually is in that location before the business case is signed, not after.
  • Treat community acceptance as a design input with a cost, in the same way you treat security. It is now cheaper than a moratorium.

Common pitfalls

  • Evaluating AI capability at the model layer and reporting it as organisational capability
  • Assuming compute is a purchasable commodity rather than a sited, powered and permitted asset
  • Planning AI capacity on a software timescale when the binding component is on an infrastructure timescale
  • Treating the society layer as communications work rather than as a constraint with a delivery date attached
  • Scoping the Chief AI Officer as a buyer of models, then holding them accountable for enterprise outcomes
  • Investing in the layer that is easiest to improve rather than the one that is binding

How WAJD Group helps

Most of our work sits in layers two and three, which is where industrial clients tend to be constrained: the operating model, the data backbone, the twin, the agents and the guardrails around them. The value of the wider framework is that it stops those engagements from being scoped in isolation, and forces the question of whether the constraint is really where the client believes it is.

If you are planning AI capacity, or you have models that work and a deployment that does not, the useful conversation starts with which of the six layers is actually holding you.

References

Which of the six layers is holding you?

Tell us where your AI deployment stalls today. We will tell you which layer is binding, and what it costs in time rather than budget.

Start a conversation