← Blog · Comparison · 9 min read
Menjalankan LLM di infrastruktur sendiri terdengar aman, tapi mahal dan rumit. Perbandingan ini membantu memutuskan antara on-prem, cloud, dan hibrida untuk data sensitif.
A 30-minute scoping call. We listen, ask three questions, tell you if we can help.
Book a call"Kami tidak boleh mengirim data ini ke OpenAI." Kalimat itu sering menjadi titik di mana proyek LLM di perbankan, asuransi, atau instansi pemerintah Indonesia berhenti dan bercabang. Pertanyaan berikutnya selalu sama: kalau begitu, haruskah kita menjalankan model sendiri di infrastruktur kita? Dan jawabannya jauh lebih bernuansa daripada yang diharapkan kedua kubu—baik yang ingin "aman dengan on-prem" maupun yang ingin "cepat dengan cloud".
Menjalankan LLM di infrastruktur sendiri terdengar seperti benteng keamanan yang sempurna: data tidak pernah keluar, kendali penuh, tenang menghadapi audit. Tapi di balik citra itu ada biaya GPU yang menguras, kompleksitas operasional yang serius, dan model open-source yang—meski makin baik—masih tertinggal di tugas tertentu. Sebaliknya, API cloud menawarkan kualitas frontier dan kemudahan luar biasa, tetapi memindahkan data sensitif ke luar kendali Anda. Artikel ini membedah keputusan on-prem vs cloud vs hybrid untuk data sensitif, dengan kacamata regulasi dan ekonomi Indonesia.
Hal pertama yang harus dijernihkan: lokasi fisik bukan penentu keamanan secara otomatis. Banyak penyedia cloud LLM kini menawarkan opsi enterprise dengan jaminan kontraktual—data tidak dipakai untuk pelatihan, dihapus setelah pemrosesan, diproses di region tertentu, dan tersertifikasi standar keamanan. Sebaliknya, deployment on-prem yang dikonfigurasi buruk—tanpa enkripsi, kontrol akses lemah, patching tertinggal—bisa lebih rawan daripada API cloud yang dikelola profesional.
Yang sebenarnya menjadi pertimbangan inti bukan "aman atau tidak", melainkan:
Kedaulatan dan kendali data. Siapa yang secara hukum dan teknis bisa mengakses data Anda, dan di yurisdiksi mana ia diproses?
Permukaan kepercayaan. Berapa banyak pihak ketiga yang harus Anda percayai, dan apakah jaminan mereka memadai untuk regulator Anda?
Persyaratan kontraktual dan regulasi. Apa yang secara eksplisit diwajibkan oleh OJK, BI, atau kebijakan internal Anda?
Pertanyaan yang benar bukan "di mana model berjalan", melainkan "siapa yang bisa menyentuh data saya, dan apakah saya bisa membuktikannya kepada regulator".
Untuk sektor diatur di Indonesia, keputusan ini bukan sekadar preferensi teknis. Beberapa kerangka yang relevan:
UU PDP No. 27/2022 mengatur pemrosesan data pribadi, termasuk kewajiban saat melibatkan prosesor pihak ketiga dan ketentuan transfer data ke luar wilayah Indonesia. Mengirim data pribadi ke API LLM yang memproses di luar negeri memunculkan kewajiban yang harus dipenuhi—bukan otomatis terlarang, tapi perlu dasar dan perlindungan yang tepat.
Regulasi sektor keuangan (OJK) menekankan manajemen risiko, kendali atas data nasabah, dan tata kelola vendor. Penyelenggara perlu memastikan kendali yang memadai atas pihak ketiga yang memproses data nasabah.
Klasifikasi data internal. Tidak semua data sama. Data publik (FAQ produk) bisa diproses di cloud tanpa kekhawatiran; data nasabah, dokumen rahasia, dan informasi yang diatur butuh perlakuan ketat.
Implikasi praktisnya: jangan memperlakukan seluruh organisasi sebagai satu keputusan biner. Klasifikasikan data dan beban kerja, lalu petakan tingkat sensitivitas ke pilihan deployment yang sesuai.
Untuk membuat keputusan ini operasional, banyak organisasi yang berhasil mengelompokkan data ke dalam tiga tingkat sederhana. Tingkat publik mencakup informasi yang sudah atau bisa dipublikasikan—FAQ produk, materi pemasaran, dokumentasi umum. Tidak ada hambatan memprosesnya di cloud mana pun. Tingkat internal mencakup data bisnis yang tidak rahasia tapi tak ingin tersebar—catatan operasional, draf dokumen internal; umumnya aman di cloud enterprise dengan jaminan kontraktual yang tepat. Tingkat terbatas/diatur mencakup data nasabah, informasi pribadi yang diatur UU PDP, rahasia dagang, dan dokumen yang regulator harapkan tetap dalam kendali Anda.
Dengan klasifikasi sesederhana ini, keputusan deployment menjadi jauh lebih jelas: sebagian besar volume biasanya jatuh di tingkat publik dan internal yang cocok untuk cloud, sementara hanya irisan tingkat terbatas yang benar-benar menuntut self-hosting. Tanpa klasifikasi, organisasi cenderung memaksakan standar paling ketat ke semua beban kerja—membayar mahal untuk melindungi data yang sebenarnya tak butuh perlindungan itu.
Argumen ekonomi sering dipakai serampangan oleh kedua belah pihak. Mari hitung jujur.
Model biaya cloud bersifat *pay-per-use*: Anda membayar per token. Kelebihannya, tidak ada biaya tetap di muka—ideal untuk volume rendah hingga menengah dan untuk eksperimen. Kekurangannya, pada volume sangat tinggi, biaya per token menumpuk dan bisa melampaui biaya menjalankan model sendiri. Titik impas bergantung pada volume Anda.
Self-hosting menukar biaya variabel dengan biaya tetap besar:
Hardware GPU. GPU kelas inferensi LLM mahal, dan untuk model besar Anda butuh beberapa unit. Ini investasi modal signifikan.
Utilisasi. Inilah jebakan tersembunyi: GPU yang menganggur tetap menelan biaya. Ekonomi self-hosting hanya masuk akal jika utilisasinya tinggi dan konsisten. Beban kerja yang berfluktuasi tajam (sibuk siang, sepi malam) memboroskan kapasitas yang sudah dibayar.
Operasional. Tim yang mengelola serving, scaling, monitoring, dan pembaruan model. Biaya SDM ini nyata dan sering diremehkan.
Aturan praktis: untuk volume rendah hingga menengah, cloud hampir selalu lebih murah dan lebih cepat. Self-hosting menjadi ekonomis pada volume tinggi yang stabil, atau ketika kepatuhan—bukan biaya—yang menjadi pendorong utama.
Penting juga menghindari kesalahan menghitung hanya biaya hardware. *Total cost of ownership* self-hosting mencakup listrik dan pendinginan data center, redundansi untuk ketersediaan tinggi, kapasitas cadangan untuk lonjakan trafik, biaya rekrutmen dan retensi insinyur MLOps yang langka di pasar Indonesia, serta waktu yang hilang untuk operasi alih-alih membangun fitur. Banyak organisasi menemukan, setelah menjumlahkan semuanya secara jujur, bahwa "menghemat biaya API" ternyata jauh lebih mahal daripada yang terlihat di permukaan. Sebaliknya, ketika kepatuhan mewajibkan data tetap di dalam kendali Anda, biaya ini bukan lagi pilihan melainkan konsekuensi yang harus diterima—dan di sanalah self-hosting menjadi keharusan, terlepas dari ekonominya.
Beberapa tahun lalu, jarak kualitas antara model proprietary frontier dan open-source sangat lebar. Kini celah itu menyempit cepat—model open-source modern sudah sangat kompeten untuk banyak tugas enterprise: ekstraksi, klasifikasi, ringkasan, dan RAG atas dokumen Anda sendiri.
Namun untuk tugas penalaran kompleks, instruksi berlapis, atau kualitas bahasa terbaik, model frontier proprietary masih sering unggul. Pertanyaan praktisnya: apakah tugas Anda *butuh* kemampuan frontier, atau apakah model open-source yang di-host sendiri sudah "cukup baik"?
Untuk banyak kasus enterprise—copilot internal atas dokumen perusahaan, ekstraksi data, otomasi dokumen—model open-source yang di-fine-tune pada domain Anda sering lebih dari cukup, dan keunggulan kendali data menjadi pemenang. Untuk produk yang menuntut kualitas penalaran tertinggi, frontier proprietary lewat jalur yang patuh mungkin lebih masuk akal.
Pertimbangkan juga latensi dan kedaulatan operasional: self-hosting memberi kendali penuh atas latensi dan ketahanan, tanpa risiko perubahan harga mendadak, *deprecation* model, atau *rate limit* dari vendor.
Yang juga sering terlupakan adalah laju perubahan. Model frontier proprietary diperbarui terus oleh penyedianya—Anda otomatis mendapat peningkatan kualitas tanpa kerja tambahan. Sebaliknya, model self-hosted membeku pada versi yang Anda deploy; untuk mengejar kemajuan, Anda harus secara aktif mengevaluasi, mengunduh, dan men-deploy model baru, lalu menguji ulang seluruh pipeline. Untuk organisasi tanpa tim yang berdedikasi, ini bisa berarti tertinggal beberapa generasi model dari waktu ke waktu. Pertimbangkan apakah Anda punya kapasitas untuk merawat keunggulan model self-hosted, atau apakah membiarkan penyedia menanggung beban riset itu lebih masuk akal untuk kasus Anda.
Bagi banyak enterprise Indonesia, jawabannya bukan murni on-prem atau murni cloud, melainkan hybrid yang sadar-data. Pola yang umum:
Routing berdasarkan sensitivitas. Beban kerja dengan data sensitif (dokumen nasabah, informasi rahasia) diarahkan ke model self-hosted; beban kerja non-sensitif (FAQ publik, drafting umum) ke cloud yang lebih kuat dan murah dioperasikan.
Redaksi sebelum cloud. Untuk kasus yang butuh kualitas frontier tapi menyentuh data pribadi, redaksi/anonimisasi PII terlebih dahulu sebelum mengirim ke API cloud, sehingga data yang keluar sudah tidak teridentifikasi.
RAG dengan retrieval lokal. Simpan dan indeks dokumen sensitif di infrastruktur Anda; hanya kirim potongan konteks yang sudah disaring (atau diredaksi) ke model—bahkan, untuk kasus paling ketat, gunakan model lokal untuk seluruh alur.
Fallback berlapis. Pakai model lokal sebagai default; eskalasi ke cloud hanya untuk kasus yang model lokal tak mampu, dengan kontrol ketat.
Arsitektur hybrid memberi Anda yang terbaik dari dua dunia: kepatuhan dan kendali untuk yang sensitif, kualitas dan efisiensi untuk yang tidak.
Hybrid bukan tanpa harga. Mengelola dua jalur—infrastruktur self-hosted dan integrasi cloud—menambah kompleksitas operasional: dua sistem untuk dipantau, logika routing yang harus benar, dan permukaan keamanan yang lebih luas. Lapisan redaksi PII sendiri adalah komponen kritis yang harus diuji ketat; redaksi yang bocor satu nomor NIK saja sudah merupakan insiden kepatuhan.
Karena itu, jangan memilih hybrid hanya karena terdengar canggih. Pilih hybrid ketika Anda benar-benar memiliki campuran beban kerja sensitif dan non-sensitif yang signifikan. Untuk organisasi yang nyaris seluruh bebannya sensitif, self-hosting penuh mungkin lebih sederhana. Untuk yang nyaris seluruhnya non-sensitif, cloud penuh lebih masuk akal. Hybrid bersinar di tengah—dan justru di sanalah mayoritas enterprise Indonesia berada.
Untuk memilih, jalankan beberapa pertanyaan secara berurutan:
Apakah data yang diproses tergolong sensitif/diatur? Jika tidak, cloud hampir selalu pilihan terbaik—lebih cepat, lebih murah, kualitas tinggi. Selesai.
Jika sensitif, bisakah diredaksi/dianonimkan secara andal sebelum diproses? Jika ya, pertimbangkan cloud dengan redaksi, atau hybrid.
Apakah regulator/kebijakan internal secara eksplisit melarang pemrosesan eksternal? Jika ya, on-prem/self-hosted untuk beban kerja tersebut menjadi keharusan.
Apakah volumenya tinggi dan stabil? Jika ya, ekonomi self-hosting membaik. Jika berfluktuasi atau rendah, cloud lebih hemat.
Apakah tugasnya butuh kualitas frontier, atau cukup model open-source yang baik? Jawaban ini menentukan apakah self-hosting realistis tanpa mengorbankan hasil.
Hasil dari latihan ini biasanya bukan satu jawaban untuk seluruh perusahaan, melainkan peta: beban kerja A ke cloud, beban kerja B ke on-prem, beban kerja C ke hybrid dengan redaksi.
Dalam praktik, beberapa pola berulang membuat organisasi mengambil keputusan yang mahal atau tidak patuh:
Standar paling ketat untuk semua. Karena takut, organisasi memaksakan on-prem ke seluruh beban kerja termasuk yang sepenuhnya publik. Akibatnya, mereka membayar mahal dan bergerak lambat untuk melindungi data yang sebenarnya tak butuh perlindungan—sambil tertinggal dalam kualitas model.
Asumsi "open-source pasti lebih murah". Tanpa memperhitungkan utilisasi GPU, biaya operasional, dan biaya SDM, banyak yang terkejut menemukan self-hosting justru lebih mahal daripada cloud pada volume mereka.
Mengabaikan jalur cloud yang patuh. Beberapa tim menolak cloud secara refleks padahal opsi enterprise dengan jaminan pemrosesan di region tertentu dan komitmen tidak-melatih-pada-data Anda mungkin sudah memenuhi syarat regulasi mereka—dengan biaya dan kualitas yang jauh lebih baik.
Melupakan exit strategy. Baik memilih cloud maupun on-prem, rancang agar tidak terkunci. Abstraksikan akses model di balik lapisan internal sehingga Anda bisa berpindah penyedia atau model tanpa menulis ulang aplikasi.
Tidak melibatkan legal dan keamanan sejak awal. Keputusan ini bukan murni teknis. Tim yang menundanya hingga akhir sering harus mengulang arsitektur saat audit menemukan masalah.
Menghindari jebakan ini menghemat biaya dan, lebih penting, melindungi Anda dari insiden kepatuhan yang jauh lebih mahal daripada selisih infrastruktur apa pun.
Keputusan on-prem vs cloud untuk data sensitif bukan pertarungan ideologi infrastruktur, melainkan latihan klasifikasi data, ekonomi yang jujur, dan pemahaman regulasi. Jebakan terbesar adalah memperlakukannya sebagai pilihan biner untuk seluruh organisasi, padahal jawaban terbaik hampir selalu berupa arsitektur hybrid yang mengarahkan setiap beban kerja ke tempat yang tepat berdasarkan sensitivitasnya.
Sainskerta Solusi Nusantara membantu enterprise—termasuk perbankan, asuransi, dan instansi pemerintah—merancang arsitektur LLM yang menyeimbangkan kepatuhan UU PDP dan ekspektasi OJK dengan ekonomi dan kualitas. Mulai dari klasifikasi data, perhitungan TCO self-hosting vs cloud, hingga desain hybrid dengan redaksi PII dan RAG lokal. Jika Anda sedang menimbang keputusan ini, hubungi tim kami lewat halaman Kontak untuk menjadwalkan sesi konsultasi. Kami akan membantu Anda memetakan beban kerja ke pilihan deployment yang tepat—tanpa membayar lebih, dan tanpa mengorbankan kepatuhan.
