COMILLAS

Technology is still marketed through breakthroughs, but real adoption is usually decided by the parts nobody wants to put on stage. In debates about infrastructure, AI, and digital systems, including those reflected on here, the missing question is often not what a tool can do, but whether people can still understand and control it after deployment. That matters because modern systems fail less often from a lack of capability than from a lack of visibility. When power, dependencies, access rules, and automated decisions become opaque, innovation turns fragile.

Compute Is Now an Energy Story

For years, the technology industry behaved as if computing capacity could expand almost independently from the physical world. That assumption is getting harder to defend. The International Energy Agency estimates that data centres consumed about 415 terawatt-hours of electricity in 2024, roughly 1.5% of global electricity use, and projects that figure to rise to around 945 terawatt-hours by 2030, with AI as the main driver of the increase. The same report stresses that the real pressure is often local rather than global, because data centre capacity is geographically concentrated and can overwhelm specific regional grids long before the world runs out of electrons.

That changes the meaning of technological scale. It is no longer enough to build a better model, a faster inference stack, or a more attractive interface. A system that depends on heavy compute also depends on transmission capacity, transformers, cooling systems, grid connection timelines, and local energy politics. The IEA warns that unless these bottlenecks are addressed, around 20% of planned data centre projects could face delays, while building new transmission lines in advanced economies can take four to eight years and wait times for critical grid components have doubled over the past three years.

This is why the most serious technology conversation today is not really about whether AI is powerful. It is about whether power systems, capital allocation, and physical infrastructure can keep up with what software is asking from the grid. Even the supply side tells a more constrained story than the usual futurist narrative: the IEA expects a mix of renewables, natural gas, and nuclear to meet rising data centre demand, which means the future of computing is tied not to a single clean abstraction but to a messy industrial stack with competing timelines and trade-offs.

In practical terms, this means the strongest technology organizations will stop treating energy as a background utility and start treating it as a design variable. Where a workload runs, when it runs, and how flexibly it can be shifted will matter more than a lot of product teams currently admit. The next decade of software will still look digital on the surface, but underneath it will be shaped by substations, cables, regional constraints, and the cost of physical expansion.

Software Has Become a Supply-Chain Problem

The second blind spot is software complexity. Many people still talk about software as though it were a coherent product made by a single company, but modern systems are assembled from open-source packages, APIs, cloud services, embedded libraries, identity providers, orchestration layers, and automated deployment pipelines. NIST defines cybersecurity supply chain risk management as the work of identifying, assessing, and mitigating risks across the full lifecycle of information and operational technology systems, from design and development to deployment, acquisition, maintenance, and destruction. It explicitly includes risks such as tampering, malicious software or hardware insertion, counterfeit components, theft, and poor development practices.

That definition matters because it replaces a comforting fiction with the real shape of the problem. A software failure is often not a single bug in a single application. It is a chain reaction across vendors, packages, permissions, and updates that were individually reasonable and collectively dangerous. CISA’s SBOM guidance captures the logic in blunt terms: software bills of materials illuminate the software supply chain so known risks can be addressed earlier and more consistently.

This is also why identity has become a structural issue rather than a login feature. NIST’s current zero trust guidance describes enterprise resources as distributed across on-premises and multiple cloud environments, while access now involves not just people but also non-person entities, applications, services, and devices. Once you accept that architecture, the trust question changes. The central problem is no longer “Who signed in?” but “Which entity is allowed to do what, under which conditions, and how do we verify that continuously?”

The useful shift here is conceptual. Instead of imagining a clean inside and outside, organizations need to think in terms of moving boundaries. Every connector widens the surface area. Every automation script becomes a policy decision. Every dependency becomes part of your operating reality, whether or not your customers ever see it. The technology teams that survive this environment are not the ones with the most impressive diagrams. They are the ones that can still explain, in plain language, what their systems depend on and what happens when one layer starts lying to another.

AI Is Becoming a Governance Problem Before It Is a Product Advantage

The public discussion around AI still leans too hard on capability: better reasoning, better coding, better search, better assistants. Capability matters, but deployment fails for other reasons first. NIST’s AI Risk Management Framework was built to help organizations manage risks to individuals, organizations, and society, and to make trustworthiness part of the design, development, use, and evaluation of AI systems. NIST later released a Generative AI Profile specifically to help organizations identify and manage risks that are unique to generative systems.

That is a signal worth taking seriously. Once a field needs dedicated risk-management profiles, it has moved beyond experimentation. It is no longer enough to ask whether a model can produce useful output. Teams need to ask whether the system can be audited, whether its failures can be classified, whether its data sources are stable, whether its permissions are too broad, and whether the people operating it understand where the model ends and surrounding software begins. These are governance questions, not just engineering questions.

The security community has reached the same conclusion from another direction. OWASP’s 2025 guidance for LLM applications explains that as large language models have become embedded more deeply in customer interactions and internal operations, new vulnerabilities have emerged across development, deployment, and management. That matters because it rejects the simplistic idea that AI risk begins and ends with the prompt. In real environments, the danger is often in what the model can access, which tools it can call, what data it can retrieve, what it is allowed to remember, and how confidently it can act while being wrong.

This is where a lot of organizations still get trapped in theatre. They buy or build AI features faster than they map their decision paths. They automate tasks before they define escalation rules. They connect models to sensitive systems before they define the outer limits of acceptable behavior. Then they act surprised when the real cost of AI turns out to be monitoring, policy design, internal education, fallback procedures, and incident response. None of that is glamorous, but all of it determines whether the system belongs in production.

Legibility Is Becoming a Competitive Advantage

The word that ties these problems together is legibility. A legible system is not necessarily simple, and it is not necessarily small. It is a system whose behavior can still be traced by the people responsible for it. They can identify what it depends on, who or what has access, where decisions are made, what failure modes exist, and how intervention works when conditions change. In a world of distributed software, heavy compute, and AI-assisted operations, that kind of visibility is not administrative overhead. It is the minimum requirement for scaling without drifting into blind risk.

A useful test is whether a team can answer five unfashionable questions before a system becomes business-critical:

1. What is this system allowed to do, and who approved that scope?
2. Which external models, libraries, services, or data sources can change its behavior without our noticing?
3. What happens to reliability, cost, and latency if usage doubles faster than expected?
4. Which human can override the system, and under what conditions?
5. If the system produces a harmful, false, or high-impact output, can we reconstruct why?

Teams that can answer those questions usually look slower in the short term and much faster over time. They spend less energy decoding surprises, less money paying for accidental complexity, and less reputation repairing trust after preventable failures. They also make better strategic decisions because they know the difference between a system that is genuinely robust and one that only appears robust while conditions remain favorable.

That is why legibility deserves more attention than hype. The strongest technology organizations in the next few years will not be defined only by model performance, feature velocity, or polished messaging. They will be defined by whether they can keep systems understandable as those systems become more interconnected, more automated, and more expensive to run. In many cases, the market will reward that discipline before it rewards brilliance, because users, buyers, regulators, and partners all eventually ask the same question in different words: can this thing be trusted when it matters?

Technology has entered a phase where power availability, dependency visibility, identity control, and AI governance shape outcomes as much as raw capability. The winners will not be the teams that make the boldest claims about the future, but the ones whose systems remain understandable under pressure. That is what makes technology truly useful: not just that it can act, but that people can still see what it is doing.