Jam istirahat siang tadi, saya mengetik satu kalimat perintah ke sebuah agen coding AI: buatkan visualisasi digital twin utilitas air yang dinamis, 3D, dan bikin yang melihatnya kagum. Lima menit kemudian, dengan biaya token 0,75 dolar Amerika, saya punya kota 3D yang berputar pelan di layar: replika virtual jaringan air minum lengkap dengan sungai, instalasi pengolahan, menara air, dan tiga distrik kota yang menyala dalam warna berbeda. Air mengalir di sepanjang pipa sebagai partikel cahaya. Angka produksi, tekanan, dan level reservoir bergerak halus, naik turun seperti sistem yang benar-benar hidup. Saya bahkan bisa memicu simulasi kebocoran, dan dasbor akan mencatatnya sebagai kejadian dengan waktu kejadian sungguhan.
Saya menaruhnya di alamat publik: twin.fdiskandar.com . Sebagai eksperimen pribadi di luar jam kerja, hasilnya memuaskan saya sendiri.
Rekaman langsung twin.fdiskandar.com: rotasi kamera, zoom ke instalasi pengolahan, dan simulasi kebocoran yang memicu perubahan pada dasbor.
Lalu saya membuka lagi kode di baliknya, dan menemukan pengingat yang lebih penting daripada demonya. Setiap angka yang bergerak di dasbor itu, produksi, tekanan, level reservoir, semuanya berasal dari satu baris rumus trigonometri: Math.sin(). Bukan dari sensor. Bukan dari model hidraulik. Bukan dari data historis satu liter air pun. Kebocoran yang saya “picu” tidak menghitung apa pun; ia hanya mengganti warna sebuah titik menjadi merah dan mengurangi sebuah angka secara terjadwal.
Twin itu meyakinkan untuk dilihat. Ia tidak tahu apa-apa tentang air.
Kecepatan yang berubah, dan kecepatan yang tidak
Ada dua jenis kecepatan dalam membangun digital twin, dan minggu ini saya baru sadar betapa jauh keduanya sudah berpisah.
Kecepatan pertama adalah kecepatan membuat sesuatu terlihat benar: merender kota 3D, menganimasikan aliran, menyusun dasbor yang enak dipandang. Laporan tren agentic coding 2026 dari Anthropic mencatat pergeseran pola produktivitas: bukan sekadar mengerjakan tugas yang sama lebih cepat, melainkan lonjakan volume keluaran, lebih banyak fitur dikirim, lebih banyak eksperimen dijalankan, dalam rentang waktu yang sama [1]. Kecepatan jenis ini nyaris gratis sekarang. Tim yang dulu perlu berminggu-minggu dan seorang perancang antarmuka, sekarang perlu satu malam dan satu orang yang tahu apa yang ingin diminta.
Kecepatan kedua adalah kecepatan membuat sesuatu memang benar: mengumpulkan data sensor, mengkalibrasi model hidraulik sampai ia cocok dengan perilaku jaringan sungguhan, memvalidasinya lagi dan lagi sampai simulasinya bisa dipercaya untuk mengambil keputusan operasional. Kecepatan ini nyaris tidak bergerak.
Bahkan yang menarik, riset yang lebih ketat justru menunjukkan bantuan AI bisa memperlambat pekerjaan jenis kedua ini. METR, lembaga riset yang mengkhususkan diri menguji klaim kemampuan AI, menjalankan uji acak terkendali pada enam belas pengembang perangkat lunak berpengalaman yang mengerjakan basis kode mereka sendiri, rata-rata di atas satu juta baris. Sebagian tugas boleh memakai AI, sebagian tidak, dibagi secara acak. Hasilnya berlawanan dengan ekspektasi semua orang: para pengembang itu 19 persen lebih lambat ketika memakai AI, padahal mereka merasa 20 persen lebih cepat [2]. Celah antara perasaan dan kenyataan itu, sekitar 39 poin persentase, adalah alasan kenapa “AI mempercepat semuanya” adalah kesimpulan yang tergesa-gesa. AI mempercepat pekerjaan yang mirip templat. Ia tidak otomatis mempercepat pekerjaan yang menuntut ketelitian pada sistem yang sudah rumit dan sudah berjalan.
Digital twin sebuah utilitas air persis berada di kategori kedua.
Apa yang sebenarnya membuat sebuah twin bisa dipercaya
Untuk memahami kenapa kalibrasi tidak bisa dipercepat dengan cara yang sama seperti rendering, ada baiknya melihat apa yang sebenarnya terjadi di balik sebuah model hidraulik. Saya membedah arsitektur konkretnya, termasuk batas memori dan batas tulis-serentak yang harus dihormati, secara terpisah di catatan teknis arsitektur digital twin murah untuk utilitas air kecil ; bagian ini cukup menyoroti kenapa kalibrasi itu sendiri adalah pekerjaan yang berbeda skalanya dari rendering.
Jantung dari kebanyakan digital twin jaringan air adalah EPANET, mesin simulasi hidraulik yang dikembangkan Badan Perlindungan Lingkungan Amerika Serikat dan sudah jadi standar tidak resmi di seluruh dunia. Yang jarang disadari orang di luar bidang teknik air: EPANET, sebagus apa pun rumusnya, hanya akan seakurat data yang memberi makan kepadanya. Sebuah tinjauan akademik tentang arsitektur dan proses kalibrasi digital twin di sektor air mencatat bahwa keakuratan tinggi (nilai R kuadrat sampai 0,972 untuk estimasi kecepatan pompa) hanya tercapai lewat kombinasi model hidraulik, teknik asimilasi data, dan algoritma pembelajaran mesin yang bekerja bersamaan, bukan lewat model statis yang dijalankan sekali [3]. Ini proses berlapis, bukan satu langkah render.
Kota Lakewood di California adalah contoh nyata betapa beratnya proses ini bahkan ketika keinginannya jelas dan anggarannya ada. Model hidraulik jaringan air mereka sudah lama ada dalam bentuk EPANET statis, tetapi berkali-kali gagal dikalibrasi oleh pihak ketiga karena penyimpangan besar antara hasil model dan data lapangan tetap bertahan dari upaya ke upaya [4]. Yang akhirnya berhasil bukan model baru yang lebih canggih, melainkan lebih banyak data hidup yang dialirkan masuk secara bertahap, dipadukan dengan pengetahuan spesialis tentang jaringan itu sendiri, sampai model dan kenyataan akhirnya saling mendekat.
Bandingkan dengan twin yang sudah benar-benar dipercaya untuk mengambil keputusan sehari-hari: fasilitas pengolahan air limbah Bresso-Niguarda milik Gruppo CAP di Milan. Twin ini menyerap data otomatis dari lebih enam puluh sensor, termasuk delapan belas meter energi, dan memakai simulasi proses untuk memprediksi kinerja instalasi dua puluh empat jam ke depan. Operator dan insinyur proses memakai prediksi itu sungguhan untuk menentukan strategi operasional harian, di instalasi yang melayani seperempat juta penduduk [5]. Yang membedakannya dari demo bukan tampilan visualnya, melainkan enam puluh sensor yang terus mengalirkan data nyata ke dalamnya, setiap hari, tanpa henti.
Tabel 1. Twin yang meyakinkan secara visual dan twin yang bisa dipercaya secara operasional bertumpu pada fondasi yang sama sekali berbeda.
| Yang bisa dipercepat AI hari ini | Yang belum ikut berubah |
|---|---|
| Rendering 3D dan animasi aliran | Kalibrasi model hidraulik dengan data sensor bertahun-tahun |
| Dasbor dan visualisasi telemetri | Validasi berulang sampai model cocok kenyataan |
| Prototipe untuk didemokan | Integrasi dengan sistem pemantauan lapangan yang sudah berjalan |
| Narasi dan proposal presentasi | Akuntabilitas ketika model salah dan keputusan diambil berdasarkan itu |
Kenapa ini bukan sekadar soal teknologi, melainkan soal pengadaan
Ada yang keberatan di titik ini: “Itu kan cuma demo internal saya, bukan sistem yang dijual ke siapa pun.” Betul, dan justru di situ letak persoalannya. Risiko sebuah demo yang terlalu meyakinkan bukan pada demo itu sendiri, melainkan pada apa yang dibenarkan olehnya. Demo yang dipakai untuk membangun keyakinan pribadi berisiko rendah. Demo yang dipakai untuk meyakinkan pengambil keputusan bahwa “teknologinya sudah matang, tinggal beli,” berisiko tinggi, terlepas dari siapa yang membuatnya, konsultan, vendor, atau tim internal sendiri yang bersemangat.
Data tentang nasib proyek AI perusahaan pada umumnya seharusnya membuat siapa pun yang mengevaluasi proposal semacam ini lebih berhati-hati, bukan lebih tergesa-gesa. Riset gabungan dari sejumlah lembaga analis global menemukan bahwa 88 sampai 95 persen proyek percobaan AI di perusahaan tidak pernah sampai ke tahap produksi [6]. Satu studi lain, kolaborasi IDC dengan Lenovo, menghitung lebih presisi: dari setiap tiga puluh tiga uji coba yang dimulai, hanya empat yang sampai produksi, sekitar satu dari delapan [6]. Istilah yang dipakai untuk kondisi ini adalah pilot purgatory, sebuah proyek yang tidak dibatalkan, tidak dilanjutkan, dan tidak diberi sumber daya yang cukup, tetapi terus menghabiskan anggaran dan kepercayaan pemangku kepentingan sambil menggantung di tengah.
Bagi utilitas air Indonesia, taruhannya lebih berat daripada bagi perusahaan pada umumnya. Data terakhir Badan Peningkatan Penyelenggaraan Sistem Penyediaan Air Minum mencatat tingkat kehilangan air nasional pada level 33,9 persen [7]. Setiap rupiah yang salah alokasi ke proyek yang berhenti di tahap demo adalah rupiah yang seharusnya bisa menambal kebocoran yang sudah jelas ukurannya, bukan membiayai visualisasi kebocoran yang belum tentu presisi.
Tiga pertanyaan sebelum terpukau
Sebelum sampai ke satu langkah konkret, ada tiga pertanyaan singkat yang bisa langsung dipakai saat duduk di depan demo vendor mana pun, bukan hanya digital twin.
Pertama, dari mana angka di layar ini berasal? Kalau jawabannya “simulasi berbasis parameter yang kami tentukan,” itu belum data. Mintalah vendor menunjukkan satu grafik yang membandingkan hasil model dengan pembacaan sensor sungguhan pada tanggal yang sama, bukan hanya grafik model berdiri sendiri.
Kedua, berapa lama proses kalibrasinya, dan siapa yang mengakui kalau meleset? Model hidraulik yang jujur akan punya cerita tentang versi awal yang salah dan cara memperbaikinya, seperti pengalaman Lakewood di atas. Model yang diklaim “langsung akurat sejak hari pertama” biasanya belum pernah diuji melawan kenyataan yang cukup keras.
Ketiga, apa yang terjadi kalau sensornya mati atau datanya kosong? Twin yang sungguhan bergantung pada aliran data yang hidup akan punya jawaban jelas soal ini, karena mereka pernah mengalaminya. Twin yang isinya rumus matematika di baliknya, seperti punya saya, tidak akan pernah kehabisan data, karena tidak pernah benar-benar memilikinya.
Ketiga pertanyaan ini tidak butuh latar belakang teknik hidraulik untuk diajukan. Yang dibutuhkan hanya kesediaan untuk bertanya sebelum kagum.
Satu langkah konkret
Ini satu langkah yang bisa dimulai besok, sebelum tanda tangan kontrak digital twin berikutnya: minta vendor mengkalibrasi modelnya dengan tiga puluh hari data dari satu zona nyata, bukan seluruh sistem dan bukan data sintetis, sebelum membicarakan skala penuh.
Tiga puluh hari cukup untuk melihat pola harian dan mingguan yang wajar. Satu zona cukup kecil agar biayanya masuk akal bagi kedua pihak, tapi cukup nyata untuk mengungkap apakah model itu benar-benar bisa dikalibrasi terhadap jaringan yang sesungguhnya, atau hanya bisa dijalankan di atas data yang sudah dirapikan sejak awal. Kalau vendor keberatan dengan permintaan ini, itu sendiri sudah jadi jawaban. Kalau mereka setuju dan berhasil, Anda baru punya alasan sungguhan untuk percaya, bukan sekadar terkesan.
Preseden untuk pendekatan bertahap ini sudah ada, dan bukan cerita sukses instan. Lakewood butuh beberapa kali percobaan sebelum modelnya benar-benar cocok dengan kenyataan [4]. Itu justru kabar baik: kalibrasi yang sungguhan memang butuh iterasi, dan vendor yang jujur akan mengatakannya di depan, bukan menyembunyikannya di balik demo yang sempurna.
Penyangkalan kecil: saya tidak sedang mengatakan visualisasi itu tidak berguna. Twin yang saya bangun tetap punya nilai, sebagai alat komunikasi, sebagai cara memvisualisasikan bagaimana sebuah jaringan air bekerja kepada orang yang belum pernah melihatnya. Yang saya coba tegaskan adalah batas antara nilai komunikasi dan nilai operasional. Keduanya berharga. Keduanya tidak boleh disamakan.
Kecepatan membuat sesuatu terlihat benar sudah menyalip kecepatan membuat sesuatu memang benar. Selama kita ingat bedanya, itu bukan masalah. Yang berbahaya adalah lupa bahwa keduanya pernah berjalan seiring, dan diam-diam berasumsi mereka masih begitu.
FD Iskandar menulis tentang tata kelola teknologi, AI, dan utilitas air. Kontak: [email protected] .
Disclaimer: Tulisan ini adalah pandangan pribadi penulis dan tidak mewakili pandangan organisasi mana pun. Informasi yang disajikan bersifat edukatif dan tidak dimaksudkan sebagai nasihat profesional; implementasi teknis harus disesuaikan dengan kondisi spesifik masing-masing utilitas.
Referensi
- Anthropic, "2026 Agentic Coding Trends Report," 2026. https://resources.anthropic.com/hubfs/2026%20Agentic%20Coding%20Trends%20Report.pdf
- METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," 2025. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- "Digital Twins for Water Utilities: Architectures, Calibration Workflows and Measured Benefits," International Journal of Mechanical and Electrical Engineering. https://wepub.org/index.php/IJMEE/article/view/5696
- Qatium, "Real World Accuracy for Lakewood's Digitally Twinned Water Distribution System." https://qatium.com/blog/real-world-accuracy-for-lakewoods-digitally-twinned-water-distribution-system
- H2O Career Pro, "Digital Twin Software for Water Treatment (2026)." https://www.h2ocareerpro.com/blog/ai-digital-twins
- SoftwareSeni, "The Enterprise AI Pilot Purgatory Problem: What the Statistics Actually Tell Us," 2026. https://www.softwareseni.com/the-enterprise-ai-pilot-purgatory-problem-what-the-statistics-actually-tell-us
- PERPAMSI, "Buku Kinerja BUMD Air Minum 2023," Kementerian PUPR. https://www.perpamsi.or.id/storage/assets/upload/3m4pBwREtq7nSEIsaguDMgwnROX5h7pwqOuw7HD2.pdf