Arsitektur pemulihan AI harus berubah, kata Gonen Stein

JAKARTA — Arsitektur pemulihan AI kini tak bisa lagi berjalan dengan pola lama. Saat agen kecerdasan buatan bisa menulis kode, menjalankan tugas, lalu menghapus data dalam hitungan detik, sistem cadangan yang masih bekerja secepat manusia jelas tertinggal jauh.

Gonen Stein, presiden sekaligus co-founder Eon, menyebut celah itu berbahaya karena waktu kehilangan data makin pendek, sementara waktu memulihkannya tetap panjang. Dalam obrolan Hot Seat bersama Tim Phillips, yang dikutip dari Eon, Stein menyoroti bahwa satu backup yang terlihat berhasil belum tentu bisa dipulihkan saat benar-benar dibutuhkan.

Arsitektur pemulihan AI tak bisa lagi mengandalkan pola lama

Masalah utamanya sederhana, tapi dampaknya besar. AI agent kini bisa bekerja pada kecepatan mesin. Ia bisa menulis kode, mengubah konfigurasi, menjalankan perintah, bahkan mengakses API yang sah. Kalau ada kesalahan, kerusakannya bisa terjadi sebelum tim manusia sempat membaca notifikasi.

Di sisi lain, banyak sistem recovery masih menunggu jadwal, pemeriksaan manual, atau proses restore yang memakan waktu. Gap inilah yang membuat data bisa hilang lebih cepat daripada data itu kembali. Dalam lingkungan cloud yang bergerak terus, model cadangan lama yang dibuat untuk server statis memang terasa semakin rapuh.

Stein menekankan bahwa cloud-native infrastructure berubah terus. Aplikasi naik-turun, konfigurasi bergeser, layanan baru muncul, lalu kebijakan backup tertinggal. Akibatnya, dashboard tampak hijau, tapi kenyataannya belum tentu aman. “Selesai backup” tidak sama dengan “restore sudah diuji,” begitu garis besar pesan yang ia sampaikan.

Kenapa angka percaya diri bisa menipu

Eon memaparkan satu temuan yang cukup menggigit: 98 persen eksekutif merasa yakin pada kemampuan pemulihan mereka, padahal sebagian besar mengaku mengalami tiga kegagalan atau lebih dalam setahun terakhir. Angka ini menunjukkan jurang lebar antara rasa aman dan kenyataan operasional.

Bagi perusahaan, jurang itu mahal. Saat insiden datang, tim biasanya baru sadar bahwa backup yang ada tak sesuai dengan kondisi sistem terbaru. Versi aplikasi berubah, dependensi bergeser, atau data yang harus dipulihkan ternyata tidak berada di titik waktu yang tepat. Urusannya jadi panjang. Dan mahal.