India’s data centre capacity is on track to triple by 2027 — and nearly all of that growth is being pulled by one force: AI.
That’s not analyst speculation. AI data centres in India are showing up in capital expenditure filings, hyperscaler partnership announcements, and the very tangible problem of enterprises discovering their existing infrastructure can’t run the workloads they’ve already committed to. Across BFSI, e-commerce, and manufacturing, the question has shifted from should we adopt AI to can our infrastructure support it. This post breaks down what’s working, what isn’t, and where the real decisions get made.
Most enterprise data centres were never designed for what AI demands. That sounds obvious until you’re the IT director staring at a throttled GPU cluster running at 30% capacity because your colocation facility can’t deliver sustained power density.
A standard enterprise server rack draws somewhere between 5 and 10 kilowatts. An AI rack — dense with GPUs — can demand 40 to 100 kilowatts. That’s not a marginal gap you close by adding better cooling. It’s a fundamentally different power design problem from the ground up.
Beyond power, AI workloads need:
| Specification | Traditional Data Centre | AI-Ready Data Centre |
|---|---|---|
| Power per rack | 5–10 kW | 40–100 kW |
| Primary cooling | Air cooling | Direct liquid or immersion cooling |
| Compute type | CPU-based servers | GPU-dense clusters (NVLink/InfiniBand) |
| Storage architecture | SAN/NAS, standard IOPS | NVMe-over-fabric, high-throughput |
| Network design | North-south traffic orientation | East-west compute fabric |
| Energy sourcing | Grid power | Renewable/ESG-audited sourcing |
One situation I’ve seen repeated in financial services: a bank commits to an LLM-based document processing system, signs off on the GPU cluster purchase, and only then discovers their existing colocation facility can’t deliver the sustained power the cluster requires. The hardware sits there, throttled.
The “lift and shift” approach — moving everything to public cloud — doesn’t solve it either. Cloud burst capacity works for training spikes, but inference at scale for a bank handling millions of transactions needs something more deliberate.
According to JLL’s India Data Centre Report, investment in Indian data centre capacity exceeded $7 billion in 2024, with the majority earmarked for AI-capable facilities. That capital flowing into AI data centres in India is now stress-testing infrastructure assumptions built for a different era of computing.
But some enterprises are getting this right — and the approaches that work share a few common traits.
No Indian enterprise I’ve seen has gone fully on-premise or fully cloud-native for AI. The practical model is hybrid: sensitive inference workloads — anything touching customer data — stays on-premise or in local colocation with dedicated GPU clusters. Burst training and experimentation runs in public cloud, where you’re not paying for idle GPU time between training runs.
Microsoft, Google, and AWS have all opened India-specific AI infrastructure zones in the past two years precisely because this demand exists. Reliance Jio’s edge-AI strategy goes further — pushing inference all the way to the edge, closer to end users. That makes sense when you’re serving hundreds of millions of people across highly variable connectivity conditions.
Facilities going up in Hyderabad, Chennai, and Navi Mumbai that are purpose-built for AI aren’t retrofitting cooling. They’re starting with liquid cooling — direct liquid cooling or immersion cooling — as the baseline, because air cooling simply can’t handle the heat density of modern GPU clusters at any reasonable efficiency.
And renewable energy commitments are becoming less optional. Several enterprises have found that their MNC clients, running scope 3 emissions audits, are scrutinising the energy sources of their Indian vendors’ infrastructure. Green power is now a vendor qualification criterion, not an ESG talking point.
Here’s something that often gets missed in infrastructure conversations: the way software is being written for AI is changing what the hardware underneath needs to do.
AI software development trends in 2026 point heavily toward containerised model serving, real-time inference APIs, and MLOps pipelines that need persistent, high-speed storage to function properly. Infrastructure-as-code is no longer optional when you’re managing dynamic GPU allocation across multiple workloads. CtrlS and STT GDC have both announced capacity expansions explicitly supporting NVMe-over-fabric storage architectures designed to feed GPU clusters without bottlenecking on I/O.
This is where I’d argue most enterprise AI infrastructure plans are incomplete — sometimes dangerously so.
AI cybersecurity threats in 2026 look different from what most security teams were trained to handle. Adversarial model attacks, data poisoning during training, and prompt injection targeting deployed LLMs are not theoretical — they’re being exploited against production systems.
Every API endpoint exposing a model is an attack surface. Every training pipeline ingesting external data is a potential poisoning vector. Perimeter-based security thinking doesn’t map cleanly onto this. AI-powered threat detection is the practice of deploying behavioural ML models to monitor model endpoints and training pipelines for anomalous access patterns — in real time. It’s fast becoming the standard response for Indian enterprises running AI at scale. Several in the financial sector now run dedicated security models alongside production AI systems specifically to watch for this class of threat.
Beyond AI-specific threats, there’s a more mundane problem sitting inside AI-adjacent infrastructure: old application layers that haven’t been updated.
PHP security vulnerabilities in 2026 remain a significant risk for enterprises running internal tooling, dashboards, or middleware built years ago without systematic patching. These systems often sit on the same network segments as newer AI infrastructure, creating lateral movement opportunities a sophisticated attacker can exploit.
If your team is building or auditing AI infrastructure, a baseline website security checklist should include:
The enterprises pulling ahead aren’t building more capacity. They’re using AI to manage the infrastructure itself.
AI-powered software testing and operational monitoring have moved from optional to necessary for anyone running GPU clusters at scale. Automated fault detection, load simulation before deploying new model versions, and capacity forecasting that prevents over-provisioning — these separate a well-run AI data centre from one perpetually firefighting.
Dynatrace and Moogsoft are being deployed across several large Indian IT services firms for this purpose. Wipro and HCL have built internal AIOps tooling that applies machine learning to their own infrastructure telemetry, catching cooling anomalies or network saturation before they become outages.
Predictive maintenance for cooling systems, specifically, has measurable ROI in facilities where unplanned downtime costs are calculated in real time.
Here’s the constraint no tooling solves on its own: India has a significant supply of ML engineers. It has very few people who understand both GPU cluster management and the networking and storage architecture those clusters depend on.
Nasscom estimates the AI infrastructure talent gap in India could exceed 200,000 roles by 2026. The enterprises making progress treat upskilling as infrastructure investment — not as an HR initiative with a quarterly training budget. Network and storage engineers are learning GPU interconnect architecture. Security teams are running tabletop exercises specifically for AI threat scenarios. And DevSecOps is being enforced as a deployment gate, not a suggestion.
An AI-ready data centre is designed specifically for GPU-based workloads, with high power density support (typically 40–100 kW per rack), liquid or advanced cooling systems, high-bandwidth low-latency networking between compute nodes, and storage fast enough to continuously feed GPU clusters during training and inference. Most traditional data centres, optimised for CPU-based web and database workloads, require significant retrofitting — or full replacement — to support AI at scale.
Traditional threats focus on data theft and service disruption. AI-specific threats include model theft (extracting a trained model through repeated API queries), data poisoning (corrupting training data to degrade model outputs), and adversarial inputs that cause models to behave incorrectly. These require controls — like AI-powered threat detection and dedicated model endpoint monitoring — that most enterprise security teams haven’t historically needed to deploy.
Legacy PHP applications often run on internal networks shared with newer AI infrastructure. A vulnerability in an unpatched PHP application can give an attacker a foothold to reach AI systems, training data, or model endpoints through lateral movement. Including legacy web application patching as part of a comprehensive website security checklist is realistic defence, not pedantry, for enterprises running mixed-vintage infrastructure.
The practical answer for most is neither exclusively — a hybrid model works best. Public cloud provides flexible GPU capacity for training workloads that spike unpredictably. On-premise or local colocation GPU clusters handle sensitive inference where data sovereignty and latency matter. The right balance depends on workload sensitivity, data residency requirements, and the organisation’s realistic ability to manage GPU infrastructure internally.
The enterprises getting this right aren’t the ones that spent the most. They’re the ones that understood compute, security, and operations have to be designed together. A GPU cluster sitting on an unpatched network, managed by a team with no experience in AI-specific incident response, isn’t an AI capability. It’s a liability.
Start with an honest audit of three things:
Those answers will tell you more about your competitive position than any hardware procurement decision.