Persetujuan dan Hak untuk Dilupakan

🌐 Juga tersedia dalam 28 bahasa

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Gambar dibuat dengan AI

Diterjemahkan dengan AI. Belum ditinjau oleh komunitas. Baca dalam bahasa Inggris

Modul 5 dari 6 dalam bab Kualitas dan Tata Kelola Data, bab 5 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Hukum Privasi Membentuk Desain · Berikutnya: Lindungi, Simpan, dan Buktikan

Pertanyaan yang dijawab modul ini: Bagaimana Anda merancang untuk persetujuan, dan untuk menghapus data seseorang?

Steve Trucking punya nomor telepon seorang Penerima. Pertanyaan sederhana: bolehkah kita mengirim SMS kepadanya? Mungkin. Tentang pengiriman hari ini? Besok? Bolehkah kita memakai nomor itu untuk promosi? Bagaimana jika ia bilang tidak mau SMS, atau mau pembaruan pengiriman tetapi tidak mau pemasaran, lalu berubah pikiran?

Sekarang ke arah sebaliknya. Penerima itu berkata: hapus informasi pribadi saya. Di mana informasi itu? Di Salesforce, kemungkinan besar, tetapi kita sudah belajar bahwa itu bukan seluruh jawabannya. Informasi itu datang dari Mitra Ritel. Ia mungkin ada di platform data pelanggan, riwayat bidang, arsip, catatan pengiriman, ekspor, log integrasi, percakapan agen. Persetujuan dan penghapusan terdengar seperti pertanyaan kebijakan, tetapi pada akhirnya sistemlah yang harus menjawabnya. Itulah arsitektur.

Persetujuan Adalah Data

Prinsip pertama: persetujuan adalah data. Jangan menyederhanakannya menjadi Has_Opted_In__c = true. Pertanyaan sebenarnya tidak pernah hanya “apakah ia setuju?” Pertanyaannya adalah persetujuan untuk apa, melalui kanal mana, di alamat atau nomor mana, untuk tujuan apa, kapan, apakah sudah berubah, dan bisakah kita membuktikannya? Jika bisnis mengambil keputusan berdasarkan jawaban-jawaban itu, semuanya harus disimpan sebagai data terstruktur. Satu paragraf di kebijakan privasi tidak cukup, begitu pula kotak centang di formulir web: kotak centang menangkap sebuah peristiwa; arsitektur harus menyimpan arti peristiwa itu.

Pakai Model yang Sudah Dibangun Salesforce

Posisi saya: pakai model persetujuan bawaan sebisa mungkin, alih-alih membangun ulang hal yang sama dengan bidang kustom. Model data persetujuan Salesforce mengelola persetujuan di empat tingkat, masing-masing pertanyaan yang lebih spesifik (Understand the Salesforce Consent Data Model (opens in a new tab)):

• Persetujuan global, pada Individu (Individual): siapa orang ini, dan apakah ia menolak segalanya?
• Persetujuan kanal keterlibatan (Contact Point Type Consent): bolehkah kita memakai jenis kanal ini, seperti SMS atau email?
• Persetujuan titik kontak: bagaimana dengan nomor telepon atau alamat email yang spesifik ini?
• Tujuan penggunaan data (Data Use Purpose): untuk alasan apa: notifikasi pengiriman, layanan, pemasaran?

Jika digabungkan, arsitektur bisa menjawab “bolehkah kita memakai informasi orang ini, melalui titik kontak ini, untuk tujuan ini?”, yang jauh lebih berguna daripada “persetujuan = ya.” Setiap rekaman yang terkait dengan seorang individu bisa ikut serta: prospek, kontak, akun pribadi, pengguna.

Click to enlarge

Empat pertanyaan, masing-masing lebih sempit daripada sebelumnya. Satu penanda opt-in tidak menjawab satu pun dengan baik.

Tujuan Itu Penting

Sebuah Mitra Ritel mengirimkan nomor seorang Penerima kepada Steve Trucking agar kru bisa mengoordinasikan pengiriman. Itu tidak menjadikan Penerima itu prospek pemasaran. Data yang sama bisa punya pemakaian yang diizinkan secara berbeda: koordinasi pengiriman, tindak lanjut layanan, pemasaran, personalisasi AI. Jika kebijakan atau hukum memperlakukannya secara berbeda, model harus bisa membedakannya. Pertanyaannya bukan apakah kita punya nomor teleponnya? Pertanyaannya adalah apa yang boleh kita lakukan dengannya?

Dan persetujuan tidak selalu menjadi dasar hukumnya. Sebagian pemakaian bertumpu pada dasar lain yang disediakan hukum, dan itu ditentukan oleh tim Hukum. Jangan membangun arsitektur yang berasumsi setiap keputusan privasi adalah kotak centang opt-in. Dukung apa pun yang dinyatakan kebijakan: jika sebuah pemakaian bergantung pada persetujuan, modelkan dan tegakkan persetujuan; jika dasar lain yang berlaku, tetap simpan apa yang dibutuhkan untuk memutuskan apakah pemakaian itu diizinkan.

Persetujuan Punya Siklus Hidup dan Otoritas

Orang memberikan persetujuan, menariknya, mengubah preferensi, mengganti nomor. Bisnis menambah tujuan baru; hukum berubah. Jadi rancang siklus hidupnya: apa yang dipilih, kapan, bagaimana, untuk tujuan apa, dan apa yang terjadi saat ditarik. Dan di sinilah menariknya: ketika seorang Penerima menarik persetujuannya, Salesforce tahu. Apakah platform perpesanan tahu? Analitiknya? Agen? Persetujuan yang tinggal di satu sistem sementara sistem lain bertindak berdasarkan izin yang sudah basi bukanlah kontrol yang berarti.

Itu berarti bertanya sistem mana yang otoritatif untuk persetujuan. Salesforce, platform preferensi, atau tempat lain? Apa pun jawabannya, jangan biarkan lima sistem memutuskan secara terpisah apakah orang yang sama menyetujui pemakaian yang sama. Persetujuan butuh apa yang dibutuhkan setiap data yang dikelola: pemilik, rekaman otoritatif, cara sinkronisasi, dan penegakan.

Sekarang Orangnya Berkata: Lupakan Saya

Naluri pertamanya adalah menghapus kontaknya lalu menganggapnya selesai. Tetapi data orang itu mungkin ada di kontak, pengiriman, catatan pengiriman, kasus, foto, riwayat bidang, Snowflake, arsip, log integrasi, indeks pencarian, atau riwayat percakapan agen. Itulah sebabnya posisi saya tentang penghapusan dimulai lebih awal: penghapusan jarang terjadi dan sulit dalam praktiknya, jadi kendalikan lebih dulu ke mana data pribadi pergi. Rancang agar data itu mendarat di sesedikit mungkin tempat. Lalu, ketika permintaan datang, samarkan atau putuskan tautannya jika itu memenuhi kebijakan, dan buru setiap salinannya: riwayat bidang, arsip, Data 360, dan kini indeks pencarian dan percakapan agen.

Jangan memulai perburuannya ketika permintaan datang. Saat itu sudah terlambat untuk mulai memahami lanskapnya. Kamus, silsilah data, dan klasifikasi di modul 3 bukanlah urusan administrasi; semuanya yang membuat hal ini mungkin. Anda sudah tahu bidang mana yang menyimpan data pribadi dan ke mana salinan-salinannya pergi.

Click to enlarge

Permintaan “lupakan saya” adalah keputusan untuk setiap salinan.

Waktu Terus Berjalan

Permintaan-permintaan ini datang dengan tenggat waktu. Menurut GDPR, organisasi harus menindaklanjuti permintaan seseorang tanpa penundaan yang tidak semestinya dan dalam waktu satu bulan sejak menerimanya; untuk permintaan yang rumit atau banyak, waktunya bisa diperpanjang dua bulan lagi, tetapi orang itu harus diberi tahu dalam bulan pertama, beserta alasannya (Pasal 12 ayat (3), Regulation (EU) 2016/679 (opens in a new tab)). Hukum lain menetapkan tenggat waktunya sendiri; tim hukum akan memberi tahu Anda mana yang berlaku. Bagaimanapun, satu bulan tidak cukup lama untuk menemukan lanskapnya. Itulah tenggat yang harus dikalahkan oleh peta salinan Anda.

Hapus, Hilangkan Identitas, atau Simpan?

Sebuah permintaan tidak selalu berarti semuanya di mana-mana lenyap. Sebagian rekaman harus atau boleh disimpan; sebagian rekaman operasional boleh tetap ada tetapi berhenti mengidentifikasi orangnya; sebagian data bisa dihilangkan identitasnya. Kebijakan dan hukum yang berlaku yang memutuskan; arsitektur mendukung setiap hasilnya, lokasi demi lokasi: hapus, hilangkan identitasnya, atau simpan berdasarkan persyaratan yang disetujui (lalu siapa yang boleh melihatnya, berapa lama, mengapa?).

Ingat pembedaan di modul 4. Memutuskan tautan hanya dihitung sebagai melupakan jika orangnya tidak bisa secara wajar diidentifikasi kembali. Data yang dipseudonimkan tetaplah data pribadi. Jangan memakai penyamaran sebagai jalan pintas untuk menghindari persyaratan hukum.

Anda Tidak Bisa Menghapus Apa yang Tidak Bisa Anda Temukan

Sebelum Anda bisa menghapus data seseorang, Anda harus menemukannya. Permintaan datang dari sebuah alamat email. Satu Mitra Ritel mengirim “Jane Smith,” mitra lain “J. Smith,” dan nomor teleponnya sudah berganti. Penerima itu sama sekali bukan kontak; detailnya ada di setiap pengiriman. Orang yang sama menerima pengiriman untuk dua mitra yang berbeda. Satu sistem mengenalnya dari email, sistem lain dari ID eksternal. Penghapusan bergantung pada identitas, dan Anda tidak ingin menghapus data orang lain karena pencocokan Anda terlalu agresif. Arsitektur identitas adalah bagian dari arsitektur privasi.

Steve Trucking membuatnya lebih sulit lagi. Satu Mitra Ritel tidak boleh pernah melihat pengiriman atau Penerima milik mitra lain. Jika orang yang sama menerima pengiriman untuk dua mitra, operasional harus menjaga hubungan-hubungan itu tetap terpisah, sementara privasi mungkin tetap perlu menemukan orang itu di keduanya. Jangan menyelesaikan privasi dengan merusak batas keamanan, dan jangan melindungi batas itu dengan membuat permintaan privasi menjadi mustahil. Arsitekturnya harus melakukan keduanya.

Foto dan Teks Bebas Juga Data

Mudah sekali memikirkan privasi sebagai bidang-bidang: nama, email, telepon, alamat. Tetapi Steve Trucking mengambil jutaan foto pengiriman per tahun, dan sebagian memperlihatkan orang atau bagian dalam rumah. Kebijakan retensi atau penghapusan yang hanya melihat bidang terstruktur belumlah lengkap; begitu pula kebijakan yang mengabaikan file, dokumen, transkrip, log, serta prompt dan respons AI.

Dan teks bebas itu berbahaya. Anda menghapus nama, telepon, dan alamat, lalu menemukan catatan pengiriman ini: “Telepon Jane di 602-555-0198. Kode gerbang 4821. Ada anjing di halaman.” Itu dia. Mengklasifikasikan catatan pengiriman sebagai sensitif memberi tahu Anda bahwa mungkin ada masalah; itu tidak menemukan dan menghapus data pribadi di dalam teksnya. Kadang jawaban terbaiknya adalah mencegah detail pribadi yang tidak perlu mendarat di sana sama sekali. Kendalikan lebih dulu ke mana data pribadi pergi.

Privacy Center Adalah Alat, Bukan Seluruh Arsitektur

Privacy Center Salesforce membantu menjalankan proses-proses ini. Kebijakan hak untuk dilupakan di dalamnya dibangun per objek, untuk menangkap semua yang ingin Anda hapus, lalu dijalankan terhadap rekaman pelanggan tertentu (Delete Data with Right to Be Forgotten Policies (opens in a new tab)). Itu berguna. Tetapi “kami sudah membeli Privacy Center, jadi kami sudah selesai” bukanlah arsitektur. Data orang itu mungkin tinggal di luar jangkauan satu alat mana pun: Data 360, data warehouse, sistem mitra, arsip, log, pencarian, file, percakapan agen. Perusahaan tetap butuh jawaban tingkat perusahaan, dan Anda perlu memeriksa apa yang benar-benar dicakup setiap alat sebelum mengandalkannya.

Portabilitas dan Bukti

Sebagian hukum juga memberi orang hak untuk mendapatkan salinan datanya. Perhatikan bahwa ini masalah penemuan yang sama: penghapusan bertanya di mana data orang ini, agar kita bisa bertindak atasnya? Portabilitas bertanya di mana data itu, agar kita bisa menyediakannya? Keduanya bertumpu pada identitas, klasifikasi, silsilah data, inventaris sistem, dan kepemilikan.

Lalu: bagaimana Anda membuktikan bahwa Anda sudah melakukannya? Permintaan diterima, identitas diverifikasi, sistem-sistem ditelusuri, tindakan diambil, pengecualian dicatat, data yang disimpan diberi pembenaran, penyelesaian dicatat. Ada ketegangan nyata di sini: Anda menghapus data pribadi seseorang sambil menyimpan cukup bukti untuk menunjukkan bahwa Anda menangani permintaannya dengan benar. Justru itulah sebabnya arsitek tidak seharusnya mengarang aturan retensi sendiri. Tim hukum dan kepatuhan memutuskan bukti apa yang harus tersisa; arsitektur menyimpannya tanpa menyimpan data yang seharusnya dihapus.

Di luar ujian: apa yang diubah AI. AI menciptakan tujuan-tujuan baru dan salinan-salinan baru. Izin memakai data untuk menyediakan layanan tidak otomatis mencakup grounding agen, personalisasi, atau pelatihan model; Data Use Purpose adalah tempat yang wajar untuk membedakannya. Dan data pribadi bisa bertahan di prompt, konteks grounding, percakapan, ringkasan, indeks pencarian dan vektor, serta log. “Kami sudah menghapus rekaman sumbernya” bukanlah jawaban yang lengkap jika lapisan AI masih mengingatnya.

Yang Diputuskan Arsitek di Sini

• Bagaimana persetujuan dan pemakaian yang diizinkan dimodelkan, agar sistem bisa menjawab siapa, kanal mana, titik kontak mana, dan tujuan apa.
• Sistem mana yang otoritatif untuk persetujuan, dan bagaimana penarikan persetujuan sampai ke setiap sistem yang bertindak berdasarkannya.
• Ke mana data pribadi bisa menyebar: bidang, teks bebas, file, riwayat, analitik, arsip, integrasi, pencarian, dan AI.
• Bagaimana sebuah permintaan menemukan orang yang tepat dan menggerakkan penghapusan, penghilangan identitas, atau retensi yang disetujui di setiap lokasi.
• Bukti apa yang tersisa untuk membuktikan bahwa persetujuan dan permintaan privasi sudah ditangani.

Persetujuan dan penghapusan terlihat seperti dua hal yang berlawanan (bolehkah kita memakai data ini? bisakah kita berhenti dan menghapusnya?) tetapi keduanya bertumpu pada fondasi yang sama: identitas, tujuan, klasifikasi, silsilah data, kepemilikan, penegakan, dan bukti. Pakai model persetujuan standar, kendalikan ke mana data pribadi pergi, ketahui di mana salinan-salinannya, dan rancang proses penghapusannya sebelum permintaan pertama datang. Ketika seseorang bertanya “bisakah Anda melupakan saya?”, arsitekturnya butuh jawaban yang lebih baik daripada “sepertinya bisa.”

Jelajahi

• Bantuan Salesforce, Understand the Salesforce Consent Data Model (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab), Pasal 12 ayat (3), tenggat untuk menindaklanjuti permintaan, dicek 2026-10-14.
• Bantuan Salesforce, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center), dicek 2026-10-14 (bahasa Inggris).