ZDR di OpenRouter: Provider AI Gak Nyimpen, Tapi Bukan Berarti Aman

Bulan lalu, ada murid gw yang panik gara-gara kliennya nanya blak-blakan: "Prompt yang tim kalian kirim ke AI itu disimpen di server siapa aja?" Dia gak punya jawaban pasti — dan ternyata banyak developer di posisi yang sama.

Apa yang baru

• Zero Data Retention (ZDR) berarti provider AI memproses prompt kalian, ngasih balik jawabannya, terus gak nyimpen apa pun setelah itu — kayak nitip barang di loker stasiun yang otomatis kosong begitu barangnya diambil, dijelaskan OpenRouter sebagai jaminan retensi, bukan jaminan privasi total.
• Tiga cara aktivasi di OpenRouter: lewat account settings, guardrails, atau nambahin field provider.zdr langsung di request API — ketiganya dijelaskan di dokumentasi resmi mereka.
• Batas yang sering keliru dipahami: ZDR gak nyentuh logging aplikasi kalian sendiri, plugin atau tools pihak ketiga yang kalian sambungin ke request, metadata (jumlah token, latency, biaya), atau lokasi geografis pemrosesan data, sebagaimana dirinci OpenRouter.
• Caching juga beda perlakuan: in-memory prompt caching di sisi provider masih dianggap kompatibel dengan ZDR karena gak ditulis ke penyimpanan permanen, tapi response caching OpenRouter sendiri punya perilaku berbeda dan perlu dimatikan terpisah kalau kalian butuh nol penyimpanan total, seperti dijelaskan di halaman ZDR mereka.

Cara kerjanya

OpenRouter ngecek kebijakan tiap endpoint model satu per satu, bukan cuma kebijakan umum si provider — soalnya endpoint yang sama dari provider yang sama bisa punya aturan retensi berbeda. Kalau statusnya gak jelas, mereka pilih anggapan paling konservatif: dianggap menyimpan dan berpotensi dipakai buat training, begitu dijelaskan OpenRouter.

ZDR sebenarnya cuma jawab satu dari tiga pertanyaan terpisah: apakah data disimpen setelah selesai diproses, apakah data itu tetap "lewat" jaringan provider waktu diproses (ZDR gak mengubah ini), dan apakah data dipakai buat melatih model berikutnya, sesuai penjelasan resmi. Kebijakan "gak dipakai buat training" gak otomatis berarti ZDR — provider bisa aja tetap nyimpen sementara buat urusan lain kayak deteksi penyalahgunaan.

Kenapa ini penting

Buat kalian yang bikin aplikasi atau layanan buat klien di Indonesia — apalagi yang kena kewajiban UU PDP — ZDR ngasih kontrol konkret yang bisa langsung dicek dan diaktifkan, bukan sekadar janji marketing "kami menjaga privasi kalian." Kalian bisa nunjukin ke klien field mana yang diset dan endpoint mana yang eligible.

Tapi ZDR bukan solusi sekali klik yang beresin semua. Kalau aplikasi kalian sendiri nyimpen log error yang isinya prompt lengkap, atau kalian pasang plugin pencarian web yang punya kebijakan retensi sendiri, itu tetap jadi lubang yang gak ketutup cuma karena provider intinya ZDR. Ini sama persis kayak masalah ngelindungin data kantor atau klien waktu pakai tools AI — satu lapisan aman gak berarti seluruh alur kerja aman.

Buat kalian

• Yang harus peduli: kalian yang develop produk berbasis AI dengan data sensitif klien — finance, kesehatan, hukum — dan butuh jawaban konkret waktu klien nanya soal retensi data.
• Yang boleh santai: kalau produk kalian cuma proses data publik atau non-sensitif, ZDR nice-to-have tapi bukan prioritas mendesak.
• Langkah kecil pertama: buka dashboard OpenRouter kalian, cek endpoint model yang dipakai, nyalain provider.zdr di satu request test, terus audit juga logging aplikasi sendiri — jangan berhenti cuma di level provider.

Kontrol keamanan data itu bukan satu tombol, tapi tumpukan lapisan — provider, aplikasi, plugin, metadata — dan kalian cuma seaman lapisan yang paling lalai kalian abaikan. Prinsip ini yang gw tekenin ke murid-murid waktu mereka mulai bikin produk AI buat klien beneran, bukan cuma prototipe demo, di kelas gw.

Sumber primer: blog resmi OpenRouter (openrouter.ai/blog/insights/zero-data-retention/).