Enterprise AI infrastructure in Indonesia is running into physical constraints that look very different from a software pilot. High-density GPU racks put new pressure on power and cooling, while fragmented enterprise data can slow deployment even when compute is available.
In this TNGlobal Q&A, Ariawan, Director and Chief Operating Officer of LG Sinar Mas, discusses where AI infrastructure projects encounter bottlenecks, how enterprises should divide workloads across public cloud, private infrastructure and the edge, and why cooling is becoming a resilience issue rather than a facilities detail.
The discussion follows a recent TNGlobal INSIDER contribution on resilient digital infrastructure for Southeast Asia’s AI workloads. LG Sinar Mas is also involved in SMX01, an AI-ready data center in Jakarta that is targeting Ready for Service in the fourth quarter of 2026.

As enterprise AI moves from pilots into production, which infrastructure constraints tend to become visible first in Indonesia and Southeast Asia: connectivity, cloud or data center capacity, power, data availability, legacy-system integration, security, or something else?
Power and cooling, almost always. A typical colocation hall in Jakarta was designed for 5 to 10 kW per rack. Today one GPU training rack already needs 100 to 150 kW. You cannot solve that by adding more CRAC units. The floor slab, the busbar, the chiller, all of them were sized for a different generation of workload, so for most of the existing facilities the honest answer is they cannot host it. Direct-to-chip liquid cooling is now the baseline, and it must be considered from the civil design, not added afterwards.
The second constraint is less visible, and it is the data itself. Most large enterprises here have twenty years of proprietary data spread across systems that were never designed to talk to each other. There is no consistent schema, and a lot of the business context only exists in the head of certain people. Fixing this takes much longer than procuring hardware. At LGSM we are working on both sides. On the facility side, we are building SMX01 in Jakarta, ready for service in Q4 this year, designed for that density from day one. On the data side, we bring the systems-integration methodology LG CNS has developed for more than 30 years in Korea, to fix the layer underneath before we talk about models.
How should enterprises decide which AI workloads belong in public cloud, private cloud, on-premises infrastructure or at the edge? Which tradeoffs around latency, cost, data residency and operational control matter most in practice?
I don’t think there is one correct answer for everybody. If somebody tells you there is, usually they are selling something.
The decision changes as the workload becomes more mature. Public cloud makes sense at the beginning, especially for prototyping or bursty training where speed to start matters more than the hourly rate. Once the GPU usage becomes stable, the economics change. The bill becomes harder to justify, particularly with egress, and for core inference or fine-tuning on proprietary data I would normally look at private cloud or a dedicated facility in the metro area. Edge is different. I would use it where the latency itself matters, for example computer vision on a production line or in a retail store.
In Indonesia, regulation and cost then narrow the choices further. We have PP 71/2019 for public-sector systems, OJK regulation for banks and insurance, and the PDP Law governing transfers outside the country. In practice this is why many enterprises end up with hybrid infrastructure even when hybrid was not their original strategy. A local high-specification data center gives them control of the stable workload, and they can still use public cloud for the elastic part.
Resilient digital architecture is often discussed in broad terms. What failure modes are you actually seeing organizations prepare for, such as network disruption, single-region dependency, power constraints, vendor concentration or poor observability?
Most enterprises I talk to are preparing for two things: one region going down, and too much dependency on one vendor. So they go multi-cloud, and they route it through a carrier-neutral hub in the metro area, so that an outage or a contract dispute with one provider will not stop the whole business. This is sensible and well understood already. The one they are only starting to prepare for is thermal. When rack density goes from 10 kW to more than 100 kW, cooling is no longer a facility detail. It becomes the single point of failure for the whole cluster. A single-path chilled water design was acceptable for the old workload. It is not acceptable now. So we are seeing the demand shift to facilities with fully redundant power paths and cooling that can be maintained while it is running.
Data sovereignty, data residency and cybersecurity are often treated as the same issue. How should technology leaders distinguish among them when designing infrastructure for AI workloads across different Asia-Pacific markets?
In practice the confusion I see most is between residency and sovereignty. A bank puts its data in a data center in Jakarta, ticks the residency box, and assumes sovereignty is also done. It is not. Knowing where the data sits is only part of the question. You also need to know who owns and operates the platform, who can access it, and what the contract allows. That is where the sovereignty issue comes in. PP 71/2019 and the OJK requirements are part of the residency decision, but I would not treat compliance with the location requirement as the end of the discussion.
Cybersecurity is another issue again. The same requirements around zero trust, encryption and monitoring apply regardless of where the server is located. I would check the three questions separately rather than assuming that solving one solves the others.
AI workloads can increase compute density, storage demand and east-west network traffic. Which capacity-planning or performance metrics should enterprises establish before they scale AI beyond a pilot?
The one I would insist on before anything scales is GPU utilization, measured properly from the pilot, because that is where the money is. If a client is paying for 32 GPUs and they are busy less than half the time, I do not care yet how elegant the architecture diagram is. Then the pilot has to explain why. Almost always it is one of three things: the storage cannot feed the data fast enough, the network between the nodes is congested, or the pipeline in front of the GPU is badly written. So the two supporting metrics to have from the pilot are storage I/O and east-west throughput, and only to explain the first number. To be honest, the east-west problem is not something I see in Indonesian enterprises today. It only appears with distributed training or high-volume inference across many nodes, and very few organizations here are at that scale. The operators building GPU capacity as a service, including us, will hit it first. For a typical enterprise pilot the cause is almost always the storage or the pipeline.
I should qualify this. Not every enterprise goes down to the GPU level. Many in Indonesia consume AI through an API or a managed service and never see a GPU, and for them the metrics are simply cost per query and latency to the user. The GPU-level numbers are for the ones that run their own cluster or rent dedicated capacity. For those, the capacity-planning number is power density per rack, because that tells you whether the facility will hit a thermal ceiling before the project hits its targets. Tokens per watt is the number I would like every enterprise to track from the pilot, but honestly very few in Indonesia do, so I mention it as an aspiration. So the baseline I would want before scaling is short: GPU utilization with the two numbers that explain it, and power density per rack. The reason to have it before scaling is simple. When the AI budget is questioned by finance, and it will be, the technical team can answer in the same meeting instead of reconstructing the history afterwards.
For companies with substantial legacy systems, where do modernization projects most often get stuck: technical integration, data quality, process ownership, skills, budgeting or organizational resistance? What tends to unlock progress?
Usually it is the data, and then nobody wants to own it. The team connects the AI to the legacy core, finds that the same customer exists in four systems with four different definitions, and finds that the metadata which would make the data meaningful was never written down. Up to that point it is a technical problem. Then someone has to decide who owns the definition and who changes the workflow, and that is where it stalls, because it is nobody’s job.
I would not try to solve that by replacing the whole core system. Start with two or three use cases where the value is clear and fix the data needed for those. The modern layer can run in parallel and connect back to the existing systems through APIs and streaming. If there is no reason yet to migrate the core, leave it there.
This is also where previous implementation experience helps. LG CNS has done this kind of enterprise transformation in Korea for decades, and we use that experience to reduce the implementation risk and cover the local skills gap. The client does not need to build all of that capability before the project can start.
What infrastructure or operating challenges are particularly different in Indonesia and Southeast Asia compared with more mature digital markets? How much do geography, connectivity quality, regulation, cost sensitivity and skills availability change the architecture decisions?
The first thing is to let go of the idea that infrastructure is something you order and plug in. That works in more mature markets. It does not work across 17,000 islands. Connectivity is the part people underestimate the most. In a mature market there is dense terrestrial fiber everywhere and you take it for granted. Here, national backhaul depends on subsea cable, which means marine permits, landing stations, cable ships, and lead times measured in years. So the architecture becomes hub and spoke by necessity. A high-density facility in the metro area does the heavy processing, carrier-neutral interconnection goes out from there, and edge sites bring the low-latency access to the other islands. The design is not a preference. It is what the geography allows.
Power and cooling are the same story in a different form. Delivering 100 to 150 kW per rack in Jakarta, hot and humid the whole year, needs serious engineering, and it has to be in the civil and electrical design from the beginning. Talent I will not go into. Everyone knows the problem, and the practical answer for most enterprises is to not build the team themselves, which is why we run design, build and operate as one service.
Looking ahead two to three years, which developments do you expect to have the biggest practical effect on enterprise AI infrastructure in the region, such as sovereign cloud, edge AI, GPU and data center expansion, new fiber or subsea capacity, energy constraints or orchestration technologies? Which trends do you think are currently overhyped?
I would push back a little on the question. The list is what everyone talks about, and most of it will happen, but the biggest practical effect will come from something less exciting: purpose-built high-density data centers with proper thermal engineering. The physics of AI clusters is pushing the industry away from low-density halls, and what we have learned from delivering SMX01 is that if utility planning and cooling are not in the initial design, you hit a ceiling and there is no way out. Sovereign cloud and hybrid orchestration will grow with the regulation. Local interconnection with the domestic exchanges and carriers matters as much as new subsea capacity for latency.
On what is overhyped, I would name two things. The idea that every workload must go to public cloud, and the idea that every enterprise must train its own large model. If I look at what enterprises in Indonesia are actually deploying, almost all of it is a chatbot or a copilot of some kind, an assistant sitting on top of the company’s own documents and systems. That does not need a model trained from scratch. It needs fine-tuning, retrieval-augmented generation and inference that runs locally on hybrid infrastructure. I will not claim the ROI is proven. For most companies it is still unclear. But this approach is doable with the skills available here, and the business users actually use it, and at this stage that matters more than the ROI slide.
About Ariawan
Ariawan brings over 20 years of leadership experience across technology, fintech, venture building, and enterprise digital transformation. He currently serves as Director & COO of LG Sinar Mas, where he leads strategic business growth and enterprise IT initiatives, including digital infrastructure and AI-ready data center solutions such as SMX01. He is also Managing Director of Technology (CTO) at SMDV
Throughout his career, Ariawan has held executive and founding roles across leading technology companies, including Managing Partner at Hyperjump, CEO and Deputy CEO/Chief Product & Engineering at 1ENGAGE, CTO at Cashbac, and leadership positions at Dimo Pay Indonesia and Global Pay Indonesia, where he played key roles in scaling and exiting fintech businesses. His international experience includes founding startups in Tokyo and working with global organizations such as Bloomberg LP and NHK.
With deep expertise spanning product, engineering, operations, venture building, and strategic partnerships, Ariawan is recognized as a prominent voice in Indonesia’s evolving digital, cloud, and enterprise technology ecosystem
Editor’s note: This Q&A has been lightly edited for clarity and TNGlobal house style. The responses remain those of the interviewee.
Share your perspective: TNGlobal welcomes contributed insights and expert commentary from across Asia’s technology and innovation ecosystem. Submit a contribution for editorial consideration, or explore more conversations in our interview archive.
Resilient digital architecture and infrastructure will decide who wins with AI
Automation review notes
Source: https://lgsinarmas.com/
Emailed Q&A. Attribute to Ariawan, Director and COO, LG Sinar Mas. Headshot supplied. SMX01 Q4 2026 RFS and up-to-130 kW rack design are corroborated by LGSM project materials. Final edit should verify regulatory references to PP 71/2019, OJK requirements and PDP Law, plus the generalized 100–150 kW GPU-rack claim.

