Setelah Tombol Hapus:
Jejak Data yang Masih Dipegang AI
Sebuah eksperimen pada objek uji milik sendiri memperlihatkan perbedaan penting antara menghapus objek dari produk, menutup akses melalui antarmuka, dan mencabut konteks yang telah diberikan kepada sistem AI.
Tombol Hapus terlihat seperti akhir sebuah alur. Bagi pengguna, objek menghilang dari daftar, halaman lama tidak bisa dibuka, dan produk kembali ke keadaan seolah objek itu tidak pernah ada. Namun pada sistem modern, terutama produk yang menghubungkan aplikasi utama dengan asisten AI, satu tindakan dapat menyentuh beberapa penyimpanan dan beberapa model kewenangan sekaligus. Menghapus objek utama belum tentu menghapus percakapan, indeks pencarian, cache, ringkasan, embedding, log, atau capability yang sebelumnya dibuat untuk mengakses konteks tersebut.
Itulah pertanyaan yang kami uji menggunakan objek disposable milik peneliti sendiri. Tujuannya bukan mencari data pihak lain dan bukan memaksa sistem menghasilkan dampak besar. Eksperimen dirancang untuk menjawab pertanyaan yang sempit: setelah objek utama benar-benar dihapus melalui alur normal, apakah konteks AI yang terhubung kepadanya ikut kehilangan akses, atau tetap hidup sebagai objek terpisah?
Satu tombol, beberapa state
Pada aplikasi sederhana, operasi hapus mungkin berarti satu baris database berubah atau dihilangkan. Pada produk berbasis AI, objek yang terlihat pengguna dapat memiliki banyak turunan. Aplikasi menyimpan objek bisnis. Layanan percakapan menyimpan pesan dan ringkasan. Sistem pencarian mungkin membentuk indeks. Orchestrator menyimpan referensi untuk melanjutkan percakapan. Analitik dan audit log memiliki kebijakan retensi sendiri.
Karena itu, kata “hapus” harus diterjemahkan menjadi kontrak yang lebih presisi. Apakah yang dihapus hanya kartu dari daftar? Apakah rute langsung dinonaktifkan? Apakah data tidak lagi digunakan untuk personalisasi? Apakah salinan untuk pemulihan masih disimpan? Apakah percakapan AI tetap tersedia? Apakah identifier lama masih berfungsi sebagai capability baca? Tanpa jawaban yang eksplisit, UI dan backend dapat menyampaikan dua makna yang berbeda kepada pengguna.
Eksperimen yang kami jalankan
Kami memulai dari baseline yang berhasil. Pemilik membuka objek uji melalui sesi terautentikasi dan mengirim pesan benign kepada fitur AI. Permintaan hanya meminta kata kontrol dan secara eksplisit melarang perubahan, pemesanan, pembelian, atau tindakan lain. Respons normal membuktikan bahwa jalur percakapan aktif.
Berikutnya kami memisahkan autentikasi akun dari capability percakapan. Struktur permintaan yang sama, tanpa cookie akun tetapi dengan capability valid milik peneliti, masih menghasilkan respons. Ketika capability diganti dengan nilai sentinel yang bentuknya cocok tetapi tidak pernah diterbitkan sistem, respons tidak membawa konteks. Kontrol pembanding ini penting: perbedaan bukan sekadar endpoint publik yang selalu menjawab apa pun.
Setelah baseline dan kontrol tersedia, pemilik menghapus objek disposable melalui menu resmi produk. Aplikasi mengalihkan pengguna keluar dari halaman objek. Daftar milik akun tidak lagi menampilkannya. Navigasi langsung ke alamat lama juga kembali ke halaman pembuatan tanpa memuat isi objek yang dihapus. Dari sudut pandang UI dan objek bisnis utama, transisi hapus berhasil.
Kemudian kami mengulangi pembacaan dengan capability lama. Dua reproduksi menghasilkan konteks terstruktur yang berhubungan dengan objek yang sudah hilang dari sisi aplikasi. Sentinel tetap menghasilkan respons “tidak ada” yang berbeda. Dengan kata lain, perbedaan bertahan setelah transisi lifecycle dan dapat dibaca dari data server, bukan hanya dari teks yang dikarang model.
Apa yang benar-benar terbukti?
Eksperimen membuktikan hasil operasional yang spesifik: lifecycle objek utama dan lifecycle konteks AI tidak identik. Penghapusan objek berhasil pada antarmuka dan rute pemilik, sedangkan capability yang sudah ada masih dapat membaca konteks terstruktur setelahnya. Hasil ini dapat direproduksi menggunakan data milik sendiri dan kontrol yang sesuai.
Namun hasil tersebut belum menjawab apakah perilakunya melanggar kebijakan produk. Sistem mungkin sengaja mempertahankan percakapan sebagai catatan terpisah. Capability mungkin dirancang seperti tautan bearer yang tetap valid sampai kedaluwarsa. Pengguna mungkin memiliki hak untuk membuka histori AI meskipun objek bisnisnya sudah dihapus. Retensi juga dapat diperlukan untuk keamanan, sengketa, atau pemulihan.
Perbedaan lifecycle adalah fakta teknis. Menyebutnya kelemahan keamanan membutuhkan satu langkah tambahan: membuktikan bahwa pemegang capability tidak semestinya masih berwenang, atau menunjukkan jalur realistis yang membuat capability tersebut tersedia di luar konteks pemilik.
Apa yang tidak kami klaim
Kami tidak memperoleh data pengguna lain, tidak menebak identifier, tidak membuktikan capability bocor ke pihak luar, dan tidak menemukan pernyataan produk yang menjamin bahwa penghapusan objek juga mencabut percakapan AI. Karena itu, hasil ini tidak dipublikasikan sebagai laporan kerentanan. Nilainya berada pada bukti desain lifecycle yang sering luput dari pengujian biasa.
Batas klaim ini bukan kelemahan analisis. Justru pemisahan antara perilaku yang teramati dan kesimpulan yang belum terbukti mencegah tim memperbaiki hal yang salah. Jika retensi memang disengaja, perbaikannya mungkin berupa komunikasi produk dan kontrol privasi. Jika retensi tidak disengaja, perbaikannya berada pada lineage dan revocation. Jika capability dapat bocor, barulah prioritasnya berubah menjadi kontrol akses dan kerahasiaan.
Lifecycle graph yang seharusnya dimiliki tim
Tim produk perlu menggambar hubungan antarobjek, bukan hanya tabel penyimpanan. Mulailah dari objek utama lalu ikuti seluruh turunannya: percakapan, attachment, ringkasan, embedding, cache, export, token berbagi, capability internal, audit log, dan backup. Untuk setiap node, tentukan siapa yang dapat membuatnya, bagaimana memperoleh akses, berapa lama ia hidup, dan transisi apa yang mencabutnya.
objek pengguna → sesi AI → konteks tersimpan → capability baca
Setiap panah membutuhkan aturan parent-child. Jika parent dihapus, pilih secara eksplisit: cascade-delete, cascade-revoke, detach dengan retensi yang dijelaskan, atau pertahankan sebagai arsip dengan akses baru yang terpisah.
Desain yang baik tidak selalu menghapus semua turunan secara fisik pada detik yang sama. Yang penting adalah konsistensi antara janji UI, kontrol akses, penggunaan data, dan jadwal penghapusan. Pengguna harus memahami apakah “hapus” berarti tidak terlihat, tidak dapat diakses, tidak lagi digunakan, dijadwalkan untuk penghapusan permanen, atau kombinasi dari semuanya.
Lima pengujian untuk fitur AI Anda
- Baseline akses. Buktikan bahwa pemilik dapat membaca konteks saat objek dan sesi aktif.
- Kontrol capability. Bandingkan capability valid dengan nilai sentinel agar respons generik tidak disalahartikan sebagai akses.
- Transisi lifecycle. Hapus, tutup, cabut, keluar dari organisasi, atau nonaktifkan akun melalui alur normal.
- Readback terpisah. Periksa UI, API objek utama, histori, dan penyimpanan AI secara independen.
- Cleanup dan expiry. Pastikan capability lama ditolak sesuai kontrak dan data disposable tidak tertinggal.
Untuk pengujian yang aman, gunakan objek milik sendiri, canary tidak sensitif, dan satu perubahan per eksperimen. Jangan menggunakan identifier pengguna lain untuk membuktikan masalah lifecycle. Jika capability tidak memiliki jalur akuisisi yang sah, jangan menebaknya. Catat hasil negatif karena ia menentukan kontrol mana yang sebenarnya bekerja.
Keputusan produk yang tidak boleh diserahkan kepada kebetulan
Engineering tidak dapat menentukan semantik penghapusan sendirian. Product, privacy, security, legal, dan support perlu menyepakati bahasa yang sama. Jika histori AI tetap tersedia, tampilkan sebagai objek tersendiri dan sediakan kontrol untuk menghapusnya. Jika capability memiliki masa berlaku, dokumentasikan dan terapkan expiry. Jika penghapusan berjalan asynchronous, berikan status dan batas waktu. Jika salinan backup tidak langsung terhapus, jelaskan penggunaannya dan pastikan ia tidak kembali ke sistem aktif tanpa kontrol.
Observability juga penting. Sistem perlu mencatat kapan capability diterbitkan, parent mana yang melahirkannya, kapan parent berubah state, dan alasan capability tetap diterima atau ditolak. Tanpa lineage tersebut, tim insiden akan kesulitan membedakan retensi yang disengaja dari akses yatim yang tidak terkelola.
Pelajaran terpenting dari hunt ini
Pengujian AI yang berguna tidak berhenti pada prompt. Pertanyaan keamanan berada pada hubungan antara tindakan pengguna, keputusan model, tool, API, dan state yang bertahan setelah percakapan selesai. Dalam eksperimen ini, keluaran model bukan bukti utama. Bukti utamanya adalah perbedaan lifecycle yang terlihat pada pembacaan server terstruktur, kontrol capability yang gagal secara tepat, dan perubahan objek utama yang terverifikasi dari sisi pemilik.
Hasil akhirnya bukan judul sensasional. Hasilnya adalah pertanyaan desain yang dapat ditindaklanjuti: ketika pengguna menekan Hapus, objek mana yang benar-benar mati, capability mana yang ikut dicabut, data mana yang dipertahankan, dan apakah produk menjelaskan semua itu dengan jujur?