)){kind=logo}
DCAA INSIGHTS · RESEARCH & ANALYSIS
Research & Analysis ·
As high-density AI infrastructure begins appearing in the Philippines, liquid cooling is moving from an industry concept into a practical operating requirement. But bringing coolant directly into server racks introduces a deceptively simple question: if something leaks, who is responsible?
At a glance
AI servers can concentrate enormous amounts of computing power — and heat — into a single rack.
Traditional data centres have largely relied on moving cool air through server rooms to remove that heat. But as rack densities increase, air alone can become increasingly difficult to use efficiently.
This is where direct liquid cooling comes in.
In simple terms:
Instead of relying mainly on air, liquid cooling brings coolant much closer to the processors generating the heat.
That can make cooling high-density AI systems more effective.
But it also connects two worlds that have traditionally been easier to separate:
the building infrastructure operated by the data centre
and
the IT equipment operated by the customer.
Between them often sits a Coolant Distribution Unit, or CDU.
Think of the CDU as the bridge between the data centre's cooling system and the specialised cooling loop serving the servers.
And that raises an increasingly important operational question:
Where does the data centre operator's responsibility end — and the customer's begin?
Liquid cooling is already relevant to the Philippines
This is no longer only a discussion about overseas hyperscale facilities.
In March 2025, STT GDC Philippines, together with Vertiv, Dell Technologies and Novare Technologies, opened what it described as the Philippines' first liquid-cooling technology showroom at its Makati headquarters.
The facility, originally called the AI Synergy Lab and subsequently renamed the AI Innovation Centre, demonstrates direct-to-chip cooling using high-density computing equipment and a coolant distribution unit.
STT GDC says the centre is intended to support organisations testing and deploying AI workloads on AI-ready infrastructure.
More recently, YCO Cloud and Aolani announced plans to deploy one of the Philippines' first NVIDIA GB300 NVL72 clusters, with the first phase scheduled for launch in the first quarter of 2027.
The announcement states that the initial deployment is intended to include more than 10,000 NVIDIA Blackwell Ultra GPUs.
That is relevant to the cooling discussion because NVIDIA's GB300 NVL72 is a fully liquid-cooled rack-scale architecture, integrating 72 Blackwell Ultra GPUs and 36 Grace CPUs in each system.
NVIDIA's technical reference architecture indicates that a complete rack may require up to approximately 142 kW, with integrated tray-level and rack-level liquid-leak detection.
As systems of this density begin entering the Philippine market, cooling is no longer simply a background facilities function.
It becomes an operational interface between the data-centre facility and the computing equipment.
The two sides of liquid cooling
ASHRAE separates a typical liquid-cooled environment into two important systems.
The Facility Water System, or FWS, belongs to the wider building cooling infrastructure.
The Technology Cooling System, or TCS, carries coolant towards the IT equipment itself.
A CDU commonly sits between them.
The unit can transfer heat from the technology cooling loop into the facility cooling system while also controlling characteristics such as coolant flow, temperature and pressure.
A typical CDU may contain:
- pumps;
- heat exchangers;
- valves;
- sensors;
- controls; and
- monitoring systems.
This separation is technically useful because the requirements of the facility water system and those of sensitive IT cooling equipment may differ.
But the physical interface also creates an organisational one.
Open Compute Project guidance identifies the CDU as a logical point at which service and responsibility boundaries may be established between the facility, the technology cooling system and the IT equipment.
The complication is that this boundary is not necessarily identical in every data centre.
So who owns the leak?
Consider a simplified colocation environment.
The data-centre operator may provide:
Cooling plant → Facility water → CDU
while the customer provides:
Rack → Manifold → Hoses → Cold plates → AI servers
That seems straightforward.
But real deployments can divide responsibility differently.
The CDU might belong to the data-centre operator.
It might be supplied by the customer.
In some designs, the CDU could even be located inside or beside the rack itself.
Responsibility for pipework, manifolds, connectors, controls and sensors may also be divided across different organisations.
Now imagine that one cooling component fails and coolant begins escaping.
The first question might be:
Who owns the failed component?
But operationally, that is only the beginning.
The facility also needs to know:
- Who receives the leak alarm?
- Who investigates it?
- Who can isolate the affected cooling loop?
- Who maintains the CDU?
- Who manages coolant quality?
- Who can disconnect or shut down affected IT equipment?
- Who pays for remediation?
- Who is responsible if neighbouring equipment or another customer is affected?
NVIDIA's current rack-scale architectures show how seriously leak management needs to be considered. The GB300 platform incorporates liquid-leak detection within the equipment, while wider management systems can integrate cooling alarms into data-centre monitoring.
But detecting a problem is different from deciding who must act.
Those responsibilities need to be established before an incident occurs.
Commissioning the complete cooling path
Liquid cooling also changes what needs to be tested before AI infrastructure goes live.
Commissioning is the structured process of checking and proving that systems perform as designed before they are relied upon in operation.
A conventional data-centre commissioning programme may already test:
- electrical systems;
- generators;
- UPS systems;
- cooling equipment;
- controls;
- alarms;
- failover conditions; and
- operating procedures.
Liquid cooling adds more interfaces.
Testing an individual CDU or server rack does not necessarily prove that the complete cooling system will perform correctly once everything is connected.
The full heat-removal path matters:
Cooling plant → Facility water → CDU → Technology cooling system → Rack manifold → Cold plate → Processor
Open Compute Project guidance treats liquid cooling as an integrated system involving CDUs, distribution pipework, connectors, cold plates and related controls.
If different organisations are responsible for different sections of that chain, commissioning also needs to prove that the interfaces between those sections work correctly.
The question is therefore not simply:
Does the CDU work?
It is:
Does the complete system remove heat reliably under the operating conditions the AI equipment will actually create?
Maintenance creates the same responsibility problem
Commissioning occurs before operation.
Maintenance continues throughout the life of the infrastructure.
A liquid-cooling system is not installed once and then left untouched.
Over time:
- filters may be changed;
- pumps serviced;
- valves exercised;
- coolant inspected or replaced;
- hoses disconnected;
- racks replaced;
- manifolds modified;
- cooling capacity expanded; and
- newer generations of IT hardware introduced.
Every intervention creates another opportunity for leakage, contamination, incorrect reconnection, trapped air, reduced flow or human error.
This means responsibility cannot be defined only for the day the system is commissioned.
It must remain clear during normal maintenance and future upgrades.
If the customer owns the rack but the operator maintains the CDU, who coordinates maintenance?
If a customer replaces equipment, who verifies that the revised cooling connections are correct?
If coolant chemistry falls outside acceptable limits, who is responsible for monitoring and correcting it?
These are operational questions as much as engineering questions.
What happens to redundancy and resilience?
Data-centre resilience is often discussed in terms of redundant generators, UPS systems, power paths and cooling equipment.
Liquid cooling introduces another dependency chain.
If a high-density AI rack depends on continuous coolant flow, resilience can also depend on:
- CDU redundancy;
- pump redundancy;
- coolant distribution paths;
- controls;
- sensors;
- isolation valves;
- manifolds; and
- the ability to maintain components without interrupting cooling.
This creates an important distinction:
A data centre can have a highly resilient central cooling plant while still having a vulnerable liquid-cooling path further downstream.
If one non-redundant CDU or distribution component serves critical AI equipment, the resilience of the building's chillers alone does not solve that problem.
The complete path between heat generation and heat rejection needs to be understood.
This is why liquid-cooling design must consider not only efficiency but also:
failure modes, maintainability, isolation and recovery.
The colocation and SLA question
The issue becomes particularly interesting in a colocation environment.
A colocation provider may promise defined levels of availability for power, cooling and environmental conditions.
But what happens if customer-owned cooling equipment affects shared infrastructure?
Consider a simplified example:
- Customer A owns an AI rack;
- one of Customer A's cooling components fails;
- coolant escapes;
- shared infrastructure is affected;
- Customer B experiences disruption.
Who owns the incident?
Does the operator's service-level agreement apply?
Is Customer A responsible because its equipment caused the event?
Was the operator responsible for monitoring or isolating the affected equipment?
Who carries the remediation cost?
Open Compute Project guidance specifically considers service-level agreements, risk and reliability in the design of advanced cooling facilities.
That is important because the engineering boundary and the contractual boundary should tell the same story.
A diagram may show exactly where facility infrastructure ends.
But if operating procedures, maintenance responsibilities and contracts do not align with that physical boundary, responsibility can still become unclear during an incident.
Five questions that should be answered before energisation
Before liquid-cooled AI infrastructure becomes operational, the organisations involved should be able to answer at least five questions clearly.
1. Where is the physical demarcation point?
Is responsibility divided at:
- facility pipework;
- CDU inlet;
- CDU outlet;
- branch pipework;
- rack manifold;
- quick disconnect; or
- IT chassis?
2. Who owns, operates and maintains each component?
Ownership and operational responsibility are not necessarily the same thing.
3. Who commissions the complete cooling path?
Testing individual components does not necessarily prove that the integrated system will operate correctly.
4. Who responds to leaks or loss of coolant flow?
Alarm ownership, escalation, isolation and shutdown procedures should be defined before operation.
5. Do the engineering design and contractual responsibilities agree?
SLAs, operating procedures, maintenance obligations and liability arrangements should reflect the actual physical system.
Why this matters for Philippine data centres
Philippine data-centre discussions understandably focus heavily on large infrastructure questions:
Is sufficient electricity available?
Can the grid support AI-scale loads?
Is international connectivity resilient enough?
Where should new facilities be located?
Those questions remain fundamental.
But the emergence of AI-ready infrastructure means operators will increasingly need to address what happens inside the data centre as well.
High-density AI environments can require capability across:
- mechanical cooling;
- thermal management;
- coolant distribution;
- controls and monitoring;
- commissioning;
- maintenance;
- leak detection and response;
- emergency procedures;
- reliability;
- risk management; and
- coordination between facilities and IT teams.
The technology does not eliminate the need for skilled people.
It changes the skills — and the organisational responsibilities — required.
DCAA perspective
Liquid cooling demonstrates how AI is changing traditional data-centre operating boundaries.
Cooling is no longer confined to the room around the server.
It can extend directly into the computing equipment itself.
That means a cooling issue can quickly become an issue involving:
Design → Commissioning → Operations → Maintenance → Resilience → Responsibility → Assurance
For Philippine operators preparing for increasingly dense AI infrastructure, the question is therefore not simply whether a facility can support liquid cooling.
It is whether everyone involved understands:
who owns each component, who monitors it, who maintains it, who responds when something fails, and where responsibility ultimately sits.
The ownership boundary may be easy to draw on an engineering diagram.
The operational consequences may not stop at that line.
As AI infrastructure develops in the Philippines, defining those responsibilities before equipment is energised may prove just as important as selecting the cooling technology itself.
BUILD THE INFRASTRUCTURE. BUILD THE WORKFORCE.
Selected sources
- ASHRAE — Water-Cooled Servers: Common Designs, Components, and Processes →
- ASHRAE Handbook — Data Centers and Telecommunication Facilities →
- Open Compute Project — ACF Reference Design Guidance →
- Open Compute Project — Coolant Distribution Unit →
- Open Compute Project — Cooling Environments →
- NVIDIA — GB300 NVL72 →
- NVIDIA — NVL72 AI Factory System Hardware & Components →
- STT GDC Philippines — Liquid Cooling Showroom / AI Synergy Lab →
- STT GDC Philippines — AI Innovation Centre →
- YCO Cloud — YCO Cloud and Aolani NVIDIA GB300 NVL72 Deployment →
Editorial Notice
DCAA Insights is provided for general industry information and professional education. Sourced information and third-party statements are attributed to their original publishers. DCAA commentary and analysis are identified as such. References to companies, projects or external resources do not constitute endorsement. External publications remain the intellectual property of their respective owners. Readers should refer to the original sources for the latest information.