· AI & infrastructure
AI's Bottleneck is Physical
AI is often described in terms of models, parameters, tokens and prompts, but a deployed model lives inside a chain of physical transformations. Electricity becomes computation; computation becomes a decision; a decision becomes an action; an action changes a physical process; sensors observe the change.
The next bottleneck in AI is not only better algorithms. It is whether this loop can be made reliable, efficient, and observable (and, if one can dream, even closed and self-improving).
Trace one prediction
A model is one component in a closed physical loop, not the loop itself. Select a stage to see the constraint that actually governs it.
A different scaling law
The usual scaling law is implicit: more compute plus more data yields a more capable model. For deployment, the relevant relationship is closer to a product of interfaces:
A frontier model can be extraordinarily capable yet operationally useless for a millisecond-sensitive control loop, a disconnected production line, or a process whose sensors cannot identify the state that matters.
Capability is not deployability
Set model capability to 100% while keeping sensor quality or data context low. The deployable intelligence score stays low, because the system is a chain: the weakest interface, not the strongest component, sets what you can actually run. Industrial AI fails at interfaces, not just in neural networks.
The data centre becomes a factory
Training has dominated the public imagination. While a training run is a discrete event, inference makes AI permanent infrastructure. A production model is a standing load that serves users, machines, or agents with predictable latency and availability. That requires power, networking, cooling, redundancy, and operational discipline.
The International Energy Agency projects global data-centre electricity demand to increase from roughly 415 TWh in 2024 to about 945 TWh by 2030, driven substantially by AI-oriented accelerated computing.[IEA, 2025] For scale, the projected increase alone (about 530 TWh) is close to Germany's entire annual electricity consumption of roughly 500 TWh, and the 945 TWh 2030 total would rank among the largest national electricity demands on the planet (national comparisons are estimates).
That electricity is not spent on one thing. In a typical facility the largest share powers the servers and accelerators doing the actual computation, much of the rest goes to cooling and power conversion, and within the compute portion the balance is shifting from training toward inference as models move into production. Cooling also has a second bill that rarely appears in FLOP counts: water. Evaporative and chilled-water systems consume large volumes of it, which turns selecting a location into a question of water availability as much as grid capacity, especially in dry regions and hot summers.
Storage sits inside this picture. Data centres already use batteries for uninterrupted power and, increasingly, for buffering volatile loads, and distributed sensing and edge computing depend on them directly: wireless nodes, mobile inspection systems, robots, remote assets, and local backup. For a battery-powered sensor, communication, inference, and sampling become interchangeable energy expenditures, and the design question has no universal answer: is it cheaper to transmit raw data, extract features locally, infer locally, or transmit only an event?
The important unit is therefore not only FLOPs. It is reliably delivered power. A model does not run on annual electricity statistics. It runs on megawatts, now, at a particular place on a particular grid.
Germany: the industrial AI paradox
Germany has an exceptional position in the application layer of AI: machinery, automation, precision sensors, industrial software, process engineering, electrochemistry, and manufacturing expertise. But it also exposes a simple tension: AI capacity cannot be deployed independently of power and grid infrastructure.
Where does that stand today? German data centres were projected to consume 21.3 TWh of electricity in 2025, roughly 4% of the country's ~500 TWh annual demand. Installed capacity was expected to grow from nearly 3,000 MW to more than 5,000 MW by 2030, with AI-specific capacity projected to rise almost fourfold, from 530 MW to 2,020 MW.[Bitkom, 2025] The status quo is modest; the trajectory is steep, and it is concentrated in exactly the AI-specific, high-density load that is hardest to site.
The question is not whether Germany has annual electricity generation. The question is whether a high-density load can connect where fibre, cloud ecosystems, industrial demand, cooling options, and skilled operators already exist. A site optimised for connectivity does not necessarily coincide with one optimised for grid availability or waste-heat reuse.
Sensors will close the AI loop
The data centre is only one end of the AI system. At the other end, AI encounters the world through instruments. For an electrode-production line, the relevant observations might include material-lot identity, powder moisture, torque, temperature, pressure, roll speed, gap, thickness, mass loading, density, defect images, electrical resistance, and later electrochemical performance.
There are crutches. Physics simulations, digital twins, and generative surrogates can, in theory, supply data where instrumentation is missing and even stand in for integration by producing labelled examples on demand. They are genuinely useful for pre-training and for exploring regimes that are expensive to measure. But a simulation is only ever as trustworthy as the physical assumptions inside it; at some point the loop still has to close against a real sensor, or the model is optimising a world that does not exist.
Yet none of these observations is inherently a learning signal. A number becomes usable data only when it carries context:
The factory, in the optimal case, produces measurements with intent and meaning. A bare temperature = 65 is not evidence until it carries its unit (65 °C, not 65 K), its location (drying zone 3, not ambient air), its time alignment (the correct electrode segment), its process state (recipe version 12, line speed 4 m/min), its provenance (sensor calibrated 18 days ago), and its quality flag (valid signal, no fault). Remove the timestamp alignment alone, and every analysis that links this reading to a specific electrode becomes invalid.
Data harmonisation is the missing layer
Most industrial AI efforts are not blocked by a lack of raw measurements. They are blocked because data cannot be reliably connected across the process. An electrode's eventual cell performance may depend on upstream material history, mixing, coating, drying, calendering, sampling location, cell assembly, formation protocol, and test conditions:
If those records do not reference the same physical lineage, a model cannot learn process–property–performance relationships, no matter how sophisticated its architecture is. Break one identifier, shift one timestamp, or change one unit, and the graph forms false links: spurious correlations that a model will happily fit. Harmonisation is the interface between physical history and statistical learning. It is also where the causal question from my CausalPFN reading note becomes concrete: without lineage, you cannot even define the intervention whose effect you want to estimate. A sufficiently capable model could recover part of that structure on its own — probabilistic entity resolution to stitch fragmented lot and batch identifiers, learned alignment of asynchronous timestamps across logs, and causal-discovery constraints to reconstruct the process graph from weak signals — but each of these substitutes an inferred lineage for a recorded one, and inherits its uncertainty rather than removing it.
Edge AI: compute where it matters
The industrial answer is rarely "send every signal to the cloud." High-frequency camera streams, acoustic monitoring, and vibration signals can be costly to transfer and too delayed for a remote decision. Edge AI moves selected computation closer to the source: on a sensor, machine controller, local gateway, or factory server. Fraunhofer IPMS integrates signal processing and AI near sensors so that data can be processed where it is generated.[Fraunhofer IPMS, 2025]
The point is not "cloud bad, edge good." It is compute locality: send upward when global context is valuable; decide locally when time, bandwidth, or resilience matters. A physically realistic AI system uses models at several scales, each matched to what its layer can observe and afford.
| Layer | Typical function | Appropriate intelligence |
|---|---|---|
| Sensor | Filtering, event detection, compression | Rules, DSP, tiny neural network |
| Machine | Defect detection, anomaly scores, state estimation | Compact vision or time-series model |
| Factory | Process coordination, multimodal prediction | Site-level ML model |
| Cloud | Training, fleet learning, optimisation, simulation | Large model or distributed compute |
| Human | Accountability, intervention, goal-setting | Operator and engineer |
The allocation is a budget problem. More cloud processing adds global context but communication cost; more edge processing improves responsiveness but limits model capacity; more sensing improves observability but adds calibration and integration burden. There is no single optimum, only a trade-off surface.
Detecting a problem is not the same as being able to fix it
Whether an AI intervention is useful depends on more than the prediction. It depends on the actuators: their authority and precision, the process dead time before an action takes effect, the saturation limits that cap how far a setpoint can move, whether the transformation is reversible at all, and which variables can genuinely be manipulated rather than merely observed.
In battery manufacturing this is decisive. Detecting a defect after coating or drying may already be too late to save that electrode: the material has passed through an irreversible step, and no downstream actuator can undo it. The useful question is therefore not "can the model detect the problem?" but "does the system detect it early enough, at a stage where an available actuator can still change the outcome?"
A good predictor is not a good controller
A highly accurate predictor can still produce poor control. It happens when measurements arrive late, when several controllers react to the same signal, when the model repeatedly overcorrects, when actuators respond more slowly than assumed, or when predictions are fed back as future inputs. The result is oscillation, overshoot, drifting setpoints, or competing optimisation loops that work against each other.
Deployment therefore needs more than predictive validation. It needs shadow-mode testing, where the model runs alongside the process without acting; explicit stability margins; rate limits on how fast a setpoint may change; actuator constraints encoded into the policy; and a conservative fallback controller to hand back to when confidence drops.
Causation needs intervention, and intervention must be safe
A model cannot reliably learn the effect of changing temperature, pressure, composition, or line speed from passive correlations alone. At some point it needs interventions: deliberate changes whose consequences it can observe. In manufacturing, though, exploration is expensive. It can produce scrap, damage equipment, reach unsafe operating states, yield unqualified product, or wait weeks for delayed electrochemical results before the outcome is even known.
This is a safe-exploration problem: how does the system choose experiments that are informative without violating process constraints? The tools are known — constrained Bayesian optimisation, value-of-information scheduling, digital-twin screening followed by limited physical validation, and experiment designs that account for delayed downstream measurements — but each trades information against risk, and none removes the hard constraint that some regions of the process simply must not be entered.
The model changes the world it learns from
Once predictions influence operators or machine settings, the data stops being passive. The deployment policy changes which states are observed. Successful prevention makes certain failures disappear from the dataset entirely. Operator trust decides whether recommendations are followed at all. Optimisation can push the process into regions absent from the training data, and measured performance can become misleading precisely because the model altered the conditions under which it is judged.
The model is no longer learning from a passive world; it is learning from a world partly created by its own previous decisions. That introduces feedback-selection bias and Goodhart-type effects, and it is why deployment needs policy-aware evaluation, counterfactual logging (recording what the model would have done alongside what was actually done), and carefully maintained control groups. It is the causal discipline from the harmonisation section again, now turned on the system's own actions.
The edge case: failure
Benchmarks assume stable inputs, stable hardware, and stable connectivity. Factories do not. A mature system needs to remain intelligible under sensor drift, network outages, version mismatches, power disturbances, and process changes. That means local buffering, explicit fallbacks, calibrated uncertainty, model-version tracking, and deterministic safety paths. Under a network loss or an edge-device failure, a fault-tolerant architecture routes around it: local inference continues, a rule-based fallback activates, data is buffered, or a human is alerted. A fragile architecture simply stops producing a decision. Reliability emerges from the architecture surrounding the model, not from the model alone.
Lessons learned
AI is becoming more entangled with the physical world. The next competitive advantage will not belong only to whoever trains the largest model. It will belong to those who can close the loop: build trustworthy sensors, preserve data lineage, place computation where it matters, manage energy and heat, maintain storage and power quality, and deploy models that fail safely.
For battery manufacturing, that is not a distant analogy. Batteries can power the distributed intelligence that improves battery production; manufacturing quality can determine the reliability of the storage supporting that intelligence. AI and advanced manufacturing are no longer separate sectors. Each increasingly defines the feasible scale, efficiency, and reliability of the other.