AI Is Rewriting the Data Centre Rulebook—And There’s No Going Back
Terry Keller, Chief Technology Officer at MRI Software, explains how AI is reshaping data centre architecture, why software-defined infrastructure is blurring the lines between operations and cybersecurity, and what enterprises should expect from the next generation of digital infrastructure.
How is the rise of AI workloads changing the design and architecture of modern data centers?
As someone who runs a global SaaS platform for the real estate industry, I don’t build data centers, but I consume them at scale across Azure, AWS, and co-location partners, and the shift is very visible from the buyer’s seat. The biggest change is that AI workloads break the assumptions traditional data center design was built on. Legacy facilities were designed around relatively uniform, moderate-density compute.
AI training and inference, especially anything touching GPUs, concentrates power and heat in a way that older raised-floor, air-cooled designs simply can’t support. What I’m seeing from my cloud and co-lo partners is a move toward modular, purpose-built AI zones within facilities rather than retrofitting the whole building. For a company like mine, that shows up as new SKUs, pricing models, and placement decisions I have to make when deciding where to run inference workloads that support our product features versus where we run standard transactional SaaS workloads.
I am also seeing my providers struggle a bit with power availability, which means I have to think about hosting my offerings differently. Markets like the UAE, where sovereign and hyperscale AI infrastructure investment is accelerating, are a good example of this shift playing out in real time, and it’s changing how global platforms like ours think about where and how we deploy workloads that touch this region.
What are the biggest challenges in scaling infrastructure to support high-density AI compute environments?
The challenge I feel most directly is availability and predictability. Regional GPU capacity, which should ideally be close to our client data for latency and compliance reasons, isn’t always there when we want it. That’s not unique to us – Computer Weekly reported in April 2026 that the Middle East’s operational third-party data centre capacity stands at roughly 500MW, forecast to triple to around 1.5GW by 2030, which shows just how constrained regional supply still is relative to demand.
That forces tradeoffs between waiting for capacity in a preferred region versus deploying where capacity exists and dealing with data residency or latency implications. The second challenge is cost predictability. High-density AI compute doesn’t behave like traditional infrastructure spend; an AI training rack can draw upwards of 100kW compared to 5-10kW for a traditional enterprise rack, and that order-of-magnitude jump in power and cooling needs is exactly the kind of variable that turns a predictable IT budget into a moving target.
We learned this firsthand with a couple of cost overrun incidents tied to AI tooling, which is part of why we built out a formal AI governance framework with spend caps and circuit breakers. The third challenge is skills. Provisioning and operating high-density environments requires infrastructure expertise that’s different from traditional IT ops, and that talent is scarce and expensive.
How are power, cooling, and networking requirements evolving with AI-driven infrastructure?
Power and cooling are the two areas where I’ve had to become a lot more literate as a buyer, even though I’m not the one designing the mechanical systems. Rack densities that used to be exceptional are becoming standard in AI environments, which means air cooling alone often isn’t enough anymore. Liquid cooling and direct-to-chip approaches are now part of almost every conversation with our providers.
Networking is evolving just as quickly. In the past, traditional enterprise data centers were designed to move data into and out of an application. AI changes that because it relies on constant communication between compute, storage and data services behind the scenes. That means the underlying network has to handle much more internal traffic while keeping it fast, resilient, and secure. For us, that influences how we architect our data pipelines and intelligence layer so they work efficiently with the cloud infrastructure our providers deliver.
Where do you see the convergence between physical infrastructure management and cybersecurity today?
This is a space I spend a lot of time in personally, since InfoSec and Technical Operations both sit inside my organization. The convergence is real and accelerating. Physical infrastructure used to be a separate discipline from cybersecurity, largely because the attack surface was static. Software-defined infrastructure collapses that separation.
When compute, storage, and networking are all provisioned through APIs and orchestration layers, a misconfiguration or compromised credential in that orchestration layer is now a security incident, not just an operations issue. Practically, this means my security team and my infrastructure team can’t operate in silos anymore. We’ve had to build shared visibility, such as our security risk governance dashboard that pulls from both vulnerability scanning and operational telemetry, so that infrastructure decisions and security decisions are made with the same data.
What new security risks emerge as data centers become more software-defined and AI-orchestrated?
A few things stand out. First, the expanded API attack surface. Every orchestration hook and automation pathway is a new entry point that needs the same rigor as a login screen. Second, identity and access sprawl. Automated systems provisioning resources on behalf of other automated systems creates chains of trust that are hard to audit.
Third, model and data poisoning risk, where AI systems making infrastructure decisions can be manipulated by feeding them bad signal. This is a big part of why we built a formal three-tier AI approval framework internally, because ungoverned AI decision-making, even in infrastructure contexts, needs guardrails before it needs speed.
How important is real-time simulation or digital twin technology in planning and managing AI infrastructure?
I think this is becoming essential, though adoption is uneven. For an organization like mine, digital twin concepts are less about physical facility modeling and more about being able to simulate capacity, cost, and failure scenarios before committing to a deployment. Given how expensive and scarce high-density AI capacity is, the cost of a wrong provisioning decision is much higher than it used to be.
Being able to model “what happens if this workload spikes 3x” or “what’s our blast radius if this region has an outage” before it happens rather than after is valuable. There’s an interesting parallel to our own industry here: real estate and facilities teams are moving in the same direction, using digital twins of buildings to model energy use, occupancy, and operational scenarios before committing capital.
Infrastructure and real estate are converging on the same principle: model first, commit second. I’d expect this to become table stakes the same way capacity planning tools did a decade ago, just with much higher stakes given how concentrated and expensive AI compute is.
How are vendors adapting to the need for faster deployment cycles in AI infrastructure environments?
Watching this from the customer side, I’m seeing three shifts. First, vendors are pre-packaging reference architectures for AI workloads rather than making customers design from scratch, which significantly speeds up my own evaluation and procurement cycles. Second, there’s a real push toward consumption-based and modular offerings so customers like us aren’t locked into long capacity commitments before we know our actual AI usage patterns.
That matters a lot to us because our AI adoption internally has been staged and governed rather than a big bang rollout. Third, and this is the one I care about most as a security and architecture leader, vendors are being pushed to compress their own security and compliance validation cycles to keep pace with deployment speed. That’s a tension I watch closely, because faster deployment can’t come at the cost of the control rigor we need for an enterprise SaaS platform serving a regulated, data-sensitive industry like real estate.



