Hak untuk Dilupakan Menjadi Lebih Rumit saat Data Sudah Masuk Sistem AI

Ada ekspektasi yang sangat manusiawi ketika menekan tombol Delete.

Hilangkan.

Selesai.

Kita sudah terbiasa begitu.

Foto dihapus dari galeri.

File masuk recycle bin.

Chat dibuang.

Akun ditutup.

Di sistem AI, tombol delete bisa punya arti lebih banyak daripada yang kelihatan.

Karena satu informasi mungkin tidak lagi berada di satu tempat.

Ia bisa hidup sebagai chat.

Saved memory.

File.

Embedding.

Vector index.

Cache.

Log.

Backup.

Derived profile.

Atau sudah ikut menjadi bagian proses training tertentu.

Maka “hak untuk dilupakan” di era AI terdengar sederhana sebagai prinsip, tetapi engineering-nya makin rumit.

Indonesia punya dasar hukum yang cukup jelas soal hak penghapusan.

UU Pelindungan Data Pribadi memberi subjek data hak untuk mengakhiri pemrosesan, menghapus, dan atau memusnahkan data pribadi tentang dirinya sesuai ketentuan peraturan perundang-undangan.

Pasal 43 juga mewajibkan pengendali menghapus data dalam beberapa kondisi, antara lain ketika data tidak lagi diperlukan untuk tujuan pemrosesan, persetujuan ditarik, ada permintaan subjek data, atau data diperoleh atau diproses dengan cara melawan hukum.

Jadi haknya bukan konsep asing.

Yang berubah adalah bentuk sistem tempat data berada.

Dulu kita bisa menunjuk record

Database customer.

Row 98213.

Delete.

Tentu real system tetap punya backup dan log, tapi data lineage lebih mudah dibayangkan.

Sekarang user upload satu PDF ke AI knowledge base.

Apa yang terjadi?

File disimpan.

Dipecah menjadi chunk.

Chunk dibuat embedding.

Embedding masuk vector database.

Teks mungkin masuk cache.

Query menghasilkan output.

Output disimpan di conversation.

AI mungkin membuat memory atau derived attribute tergantung sistem.

Satu data punya banyak keturunan.

Kalau user minta: “hapus data gue,”

yang mana?

Original?

Derived?

Log?

Memory?

Semua?

Ini bukan alasan untuk menyerah.

Ini alasan perusahaan harus tahu arsitektur sendiri.

Deletion yang tidak punya data map cuma janji.

Chat dan memory bisa menjadi dua benda berbeda

Contoh paling gampang dilihat pada produk personal AI.

Dokumentasi ChatGPT saat ini menjelaskan bahwa saved memories dapat disimpan terpisah dari chat history. Menghapus chat tidak otomatis menghapus memory tersimpan yang berasal dari chat tersebut.

Untuk menghapus sesuatu sepenuhnya dari personalisasi, pengguna bisa perlu menghapus memory dan chat tempat informasi itu dibagikan, serta sumber lain yang relevan seperti file atau connected app jika informasinya ada di sana.

Ini contoh product-specific, bukan hukum umum untuk semua AI.

Tapi ia menunjukkan satu realita: “data” yang dirasakan user sebagai satu percakapan bisa direpresentasikan sistem dalam beberapa layer.

UX delete perlu mengikuti mental model user.

Kalau ada tombol delete chat tetapi memory tetap hidup, product harus jelas.

Jangan bikin user berpikir sesuatu sudah hilang padahal konteks masih digunakan.

Embedding bikin penghapusan tidak kelihatan

RAG menyimpan vector.

User tidak pernah melihat.

Data scientist melihat.

Embedding bukan copy teks biasa, tetapi tetap derived from source.

Dan vector store punya fungsi untuk menemukan informasi source.

Kalau file asli dihapus tetapi embedding dan chunk masih ada, assistant mungkin masih bisa retrieve.

Maka deletion pipeline harus cascade.

Source removed.

Chunk removed.

Embedding removed.

Cache invalidated.

Access revoked.

Audit recorded.

Satu tombol di UI harus memicu banyak action di belakang.

Itulah engineering hak penghapusan.

Bukan sekadar query DELETE FROM users.

Backup selalu membuat kata “hapus” punya timing

System backup diperlukan.

Ransomware.

Disaster recovery.

Data yang dihapus hari ini mungkin masih ada di immutable backup untuk periode tertentu.

Apakah berarti perusahaan melanggar?

Tidak bisa dijawab generik.

Retention dan kewajiban lain perlu dilihat sesuai hukum dan konteks.

Yang penting perusahaan jujur: kapan data hilang dari active system, kapan backup expire, apakah backup dapat digunakan untuk production biasa, bagaimana deletion diterapkan jika restore terjadi.

Good architecture memiliki tombstone atau deletion ledger.

Kalau backup lama dipulihkan, data yang sebelumnya diminta hapus tidak tiba-tiba hidup kembali permanen.

Restore process harus replay deletion.

Otherwise zombie data.

Mati, hidup lagi.

Derived inference lebih susah

User pernah menulis: “gue vegetarian.”

Sistem menyimpan preference.

Delete source chat.

Memory dihapus.

Simple enough.

Bagaimana kalau AI menyimpulkan: “user kemungkinan investor konservatif”

dari 20 percakapan?

Tidak ada satu kalimat source.

Itu derived profile.

Kalau user minta hapus data, apakah inference juga harus hilang?

Dari perspektif fairness dan privacy, pertanyaan ini sangat relevan jika inferensi dihubungkan ke individu dan digunakan untuk personalization atau decision.

UU PDP mendefinisikan data pribadi sebagai data tentang orang yang teridentifikasi atau dapat diidentifikasi, termasuk ketika dikombinasikan dengan informasi lain.

Ia juga memasukkan pengolahan dan penganalisisan sebagai bagian pemrosesan.

Tapi penerapan hak penghapusan pada tiap bentuk model-derived inference perlu analisis hukum spesifik.

Jangan overclaim.

Secara governance, perusahaan sebaiknya tidak menjadikan derived profile sebagai loophole.

Kalau profile tentang user tidak lagi punya basis atau user berhak meminta penghapusan, architecture harus mampu menanganinya.

Training adalah bagian paling rumit

Ini topik yang sering disederhanakan.

“Kalau data sudah masuk model, tinggal hapus?”

Model training bukan database lookup biasa.

Informasi dipakai bersama data lain untuk menyesuaikan parameter.

Mencari dan menghapus kontribusi satu record bisa jauh lebih sulit dibanding menghapus row.

Ada research tentang machine unlearning.

Ada dataset filtering.

Ada retraining.

Tetapi praktik dan feasibility bergantung sistem.

Karena itu data minimization sebelum training sangat penting.

Lebih mudah tidak memasukkan data yang tidak perlu daripada berusaha mengeluarkannya setelah model selesai.

Untuk product, jangan memberi janji delete yang secara teknis tidak bisa dilakukan sesuai wording.

Explain scope.

OpenAI, misalnya, menyediakan control agar pengguna personal dapat mematikan penggunaan percakapan baru untuk peningkatan model, sementara Temporary Chat tidak digunakan untuk training dan dihapus dari sistem setelah periode yang dinyatakan di dokumentasi saat ini.

Itu contoh control preventif.

Pencegahan sering lebih manageable daripada unlearning.

“Right to be forgotten” bukan “right to rewrite history”

Ini penting.

Ada data yang mungkin harus dipertahankan karena kewajiban hukum.

Transaksi.

Fraud investigation.

Legal claim.

Archival rule.

UU PDP sendiri memberi hak penghapusan sesuai ketentuan peraturan perundang-undangan dan memiliki pengecualian tertentu pada pelaksanaan hak dalam konteks yang diatur.

Jadi jangan menjual narasi: “user minta, semua harus hilang saat itu juga tanpa exception.”

Hak perlu dibaca bersama kewajiban lain.

Yang harus jelas adalah purpose.

Data dipertahankan karena kewajiban apa?

Berapa lama?

Bukan: “kami simpan siapa tahu berguna.”

“Siapa tahu berguna” adalah retention policy paling malas.

Perusahaan perlu deletion inventory

Sama seperti data inventory.

Untuk setiap AI system:

source file ada di mana?

chunk?

embedding?

chat?

memory?

cache?

log?

backup?

analytics?

third party?

Kalau satu komponen tidak bisa dihapus, note.

Legal evaluate.

Engineering fix if needed.

Deletion request adalah test paling jujur atas data architecture.

Kalau tim membutuhkan dua minggu hanya untuk mencari ke mana data menyebar, data map belum matang.

Connected apps bikin lifecycle tambah panjang

AI terhubung ke Gmail.

Drive.

Calendar.

User disconnects.

Apa yang hilang?

Access token.

Good.

Bagaimana dengan summary yang sudah dibuat?

Memory?

Indexed data?

Cached content?

Product behavior berbeda-beda.

User perlu tahu.

Disconnect should not be vague.

At minimum, provider harus menjelaskan apa yang berhenti dan apa yang tetap.

Untuk enterprise, admin perlu offboarding procedure.

Employee resign.

Revoke connector.

Transfer files.

Delete personal memory.

Retain records yang legally required.

Identity lifecycle.

Jangan sampai mantan karyawan masih punya AI workspace yang terus menyimpan company context.

Data deletion juga perlu supplier cooperation

Perusahaan Indonesia memakai AI vendor.

Customer minta data dihapus.

Company menghapus database sendiri.

Vendor?

Subprocessor?

Vector database cloud?

Backup provider?

Contract harus mendukung deletion request.

SLA.

Confirmation.

Flow-down obligation.

UU PDP mengatur relasi pengendali dan prosesor serta kewajiban pengendali mengawasi pihak yang terlibat dalam pemrosesan di bawah kendalinya.

AI supply chain membuat ini practical.

Tidak cukup kirim email: “tolong delete.”

Need evidence.

User experience harus sederhana meskipun backend rumit

Ini prinsip paling penting.

User tidak perlu tahu embedding.

Vector.

Cache.

Tombstone.

Mereka perlu control yang masuk akal.

Delete this memory.

Delete this chat.

Delete file.

Delete account.

Request all data deletion.

Dan product menjelaskan efek.

Backend complexity adalah problem perusahaan.

Jangan dipindahkan ke user.

Kalau memang ada data yang tidak dapat langsung dihapus karena legal retention atau security log, jelaskan.

Clear.

Specific.

No legal fog.

Hak untuk Dilupakan Menjadi Lebih Rumit saat Data Sudah Masuk Sistem AI bukan berarti hak itu jadi kurang penting.

Justru makin penting.

AI membuat satu informasi lebih mudah disalin, diturunkan, dihubungkan, dan dipakai kembali.

Maka delete harus dirancang sejak awal sebagai lifecycle, bukan feature kosmetik di settings.

Kalau perusahaan membangun AI hari ini, pertanyaan “bagaimana data masuk?” memang penting.

Tapi ada pertanyaan yang lebih sering ditunda:

Ada satu gap yang sering muncul antara legal dan engineering: definisi “deleted” tidak sama.

Legal berpikir data tidak boleh lagi diproses.

Engineer mungkin berkata: “row sudah soft-delete.”

Tapi row masih ada.

Atau flag `deleted=true` tetapi index belum dibersihkan.

Atau UI tidak menampilkan, tetapi analytics pipeline masih membaca.

Karena itu perusahaan perlu deletion specification yang bisa diuji.

Bukan sekadar SOP.

Contohnya: setelah request valid, record hilang dari active database dalam X waktu, vector index dihapus, cache invalidated, connector access dicabut, dan backup mengikuti retention schedule.

Kemudian audit sample.

Request dummy.

Lihat apakah data masih bisa muncul.

Deletion testing harus menjadi bagian QA.

Mirip restore testing.

Kalau kita hanya percaya bahwa tombol bekerja tanpa pernah mencoba end-to-end, itu faith, bukan governance.

AI juga membuat kebutuhan “proof of deletion” makin relevan untuk hubungan B2B. Customer enterprise mungkin ingin confirmation bahwa file dan derived index sudah dihapus setelah contract berakhir.

Vendor yang bisa menunjukkan workflow ini akan punya trust advantage.

Especially untuk legal, finance, dan health use case.

“kalau besok orang meminta data itu pergi, apakah kita benar-benar tahu jalan keluarnya?”

Sistem yang matang punya jawaban sebelum permintaan pertama datang.