Privasi Data Pelanggan dalam Dukungan AI: PII, Redaksi, dan Retensi

Oleh Linh Ngo · Diperbarui 11 Oktober 2026

Privasi data pelanggan dalam dukungan AI adalah kumpulan kontrol yang menentukan data pribadi apa yang dilihat sistem AI, berapa lama pihak mana pun menyimpannya, ke mana data itu pergi, dan siapa yang boleh membacanya. Dalam praktik, artinya enam hal: meredaksi data pribadi sebelum sampai ke model atau log, menetapkan periode retensi dan menegakkannya, menjauhkan data kartu pembayaran dari chat sepenuhnya, membaca ketentuan data vendor, memilih lokasi penyimpanan data, dan membatasi siapa yang boleh membuka transkrip.

Dukungan adalah tempat privasi bocor secara diam-diam. Pelanggan menempelkan nomor akun dan rincian medis ke kotak chat karena Anda bertanya apa yang bisa dibantu, dan dengan lapisan AI setiap pesan bisa mendarat di prompt, log penyedia, dataset QA, dan kolom ringkasan. Panduan ini ditujukan bagi pemimpin dukungan yang harus menjawab "ke mana data itu pergi?" tanpa gelar hukum. Ini bukan nasihat hukum, jadi mintalah penasihat privasi memastikan apa yang berlaku di wilayah Anda. Panduan ini melanjutkan menyiapkan data dukungan untuk AI, yang membahas pembersihan data. Di sini fokusnya melindungi data tersebut.

Fakta Utama

• GDPR Pasal 5(1)(c) mensyaratkan data pribadi "memadai, relevan, dan terbatas pada apa yang diperlukan" untuk tujuan pemrosesan, dan Pasal 5(1)(e) menyatakan data boleh disimpan dalam bentuk yang dapat diidentifikasi "tidak lebih lama dari yang diperlukan" (GDPR, EUR-Lex).
• PCI DSS tidak mengizinkan kode verifikasi kartu disimpan setelah transaksi diotorisasi, meskipun terenkripsi dan meskipun pelanggan menyetujui (FAQ PCI SSC 1280).
• Berdasarkan GDPR Pasal 28(3), prosesor hanya boleh bertindak atas instruksi terdokumentasi dari pengendali dan, atas pilihan pengendali, harus menghapus atau mengembalikan data pribadi saat layanan berakhir (GDPR, EUR-Lex).
• OpenAI menyatakan bahwa data yang dikirim ke API-nya tidak dipakai untuk melatih modelnya kecuali pelanggan memilih ikut, dan bahwa log pemantauan penyalahgunaan disimpan hingga 30 hari secara default (OpenAI).
• Pustaka sumber terbuka Presidio milik Microsoft memperingatkan bahwa deteksi otomatis tidak menjamin semua informasi sensitif ditemukan (Presidio).
• FTC menyatakan bahwa mengubah ketentuan secara diam-diam untuk mengizinkan pelatihan AI pada data yang dikumpulkan berdasarkan janji sebelumnya dapat dianggap tidak adil atau menipu (FTC).

Di Mana Data Pelanggan Mendarat dalam Tumpukan Dukungan AI

Sebelum memilih kontrol, petakan tempat data benar-benar berada. Penyiapan dukungan AI yang umum memiliki lebih banyak salinan daripada yang dibayangkan orang.

Jika permintaan privasi atau audit sampai ke meja Anda, Anda harus bisa mendaftar setiap baris untuk penyiapan Anda sendiri.

Contoh menurut Kanal

Risikonya tampak berbeda di setiap kanal, itulah sebabnya AI di berbagai kanal dukungan layak mendapat pemeriksaan privasi tersendiri.

Chat. Orang yang menanyakan pembayaran gagal sering menempelkan nomor kartu lengkap. Samarkan deretan digit yang menyerupai nomor kartu sebelum pesan disimpan atau dikirim ke model.

Email. Utas membawa tanda tangan, riwayat yang diteruskan, dan lampiran seperti KTP yang dipindai. Buang riwayat kutipan dan teks lampiran kecuali tugasnya membutuhkannya.

Suara. Data lisan paling sulit dibersihkan. PCI SSC membahas ini secara langsung: kode validasi kartu yang terekam dalam rekaman audio digital setelah otorisasi melanggar aturan penyimpanan, segala upaya harus dilakukan agar data itu tidak terekam, dan bila perekaman tidak bisa dicegah, data harus dihapus dengan aman segera setelah otorisasi (FAQ PCI SSC 1210).

Agent assist internal. Bahkan alat yang hanya menyarankan balasan kepada agen Anda sendiri melihat seluruh percakapan. Agent assist membutuhkan aturan redaksi dan retensi yang sama dengan bot yang berhadapan dengan pelanggan.

Enam Kontrol

Bagian-bagian berikut membahas satu per satu sesuai urutan penerapannya.

Redaksi: PII di Transkrip, Prompt, dan Log

GDPR Pasal 5(1)(c) adalah prinsip di balik redaksi: data pribadi harus "memadai, relevan, dan terbatas pada apa yang diperlukan" untuk tujuan pemrosesannya (GDPR, EUR-Lex). Untuk asisten AI, itu diterjemahkan menjadi aturan rancangan. Kirim ke model hanya yang minimum dibutuhkan untuk satu percakapan ini. Permintaan reset kata sandi butuh status akun, bukan riwayat penagihan. Lihat personalisasi layanan dengan AI untuk penalaran GDPR yang lebih lengkap.

Redaksi bisa dilakukan di tiga titik, dan biasanya Anda menginginkan ketiganya:

1. Sebelum model. Deteksi data pribadi di pesan masuk dan ganti dengan placeholder seperti [EMAIL] atau [CARD_NUMBER]. Model tetap bisa menjawab "Saya menemukan akun yang tertaut ke email itu" tanpa pernah memegang alamat aslinya. Jika balasan akhir membutuhkan nilai aslinya, sistem Anda bisa memasukkannya kembali setelah model merespons.
2. Sebelum penyimpanan. Terapkan penyamaran yang sama sebelum transkrip ditulis ke helpdesk, pipeline log, atau tabel analitik, sehingga nilai mentahnya tidak pernah mendarat di tempat yang awet.
3. Sebelum penggunaan ulang. Saat mengekspor percakapan untuk QA, coaching, atau penyetelan, redaksi lagi. Toolkit AI dari ICO menyarankan memakai informasi sintetis atau teranonimkan untuk melatih model bila memungkinkan (ICO).

Satu peringatan soal alat: Presidio, toolkit deteksi sumber terbuka milik Microsoft, menyatakan tidak ada jaminan ia menemukan semua informasi sensitif karena deteksinya otomatis (Presidio). Pencocokan pola menangani nomor kartu dan email dengan baik, tetapi nama dalam kalimat atau deskripsi penyakit dengan buruk. Ambil sampel transkrip yang sudah diredaksi setiap minggu dan cari yang terlewat.

Log debug, pelacak galat, dan rekaman sesi widget chat juga menyimpan teks mentah, jadi periksa masing-masing secara terpisah.

Retensi dan Penghapusan

Pasal 5(1)(e) GDPR menyatakan data pribadi boleh disimpan dalam bentuk yang dapat diidentifikasi tidak lebih lama dari yang diperlukan untuk tujuan pemrosesannya (GDPR, EUR-Lex). Konsiderans menambahkan bahwa pengendali harus menetapkan batas waktu untuk penghapusan atau peninjauan berkala. Pelanggan juga memiliki, dalam rumusan Pasal 17(1), "hak untuk memperoleh dari pengendali penghapusan data pribadi yang menyangkut dirinya" dalam keadaan yang tercantum di pasal itu.

Anda tidak perlu analisis hukum yang sempurna untuk memulai. Anda butuh jadwal yang ada pemiliknya:

• Tentukan tujuan tiap jenis data. Transkrip, rekaman, ringkasan AI, sampel QA, dan log penyedia masing-masing ada alasannya. Tulis di samping periode retensi.
• Tetapkan periode yang sesuai dengan alasannya. Garansi dan sengketa penagihan mungkin membenarkan penyimpanan tiket dalam waktu lama. Chat tentang jam buka tidak. Tim hukum dan keuangan Anda biasanya menetapkan batas terluar, karena undang-undang pencatatan berbeda-beda.
• Hapus juga produk sampingan AI. Ringkasan, skor sentimen, entitas yang diekstraksi, dan embedding yang dibangun dari percakapan adalah data turunan tentang orang yang sama. Penghapusan yang membuang tiket tetapi menyisakan ringkasan AI belum menghapus banyak.
• Otomatisasi. Jadwal yang bergantung pada ingatan seseorang akan gagal. Gunakan pengaturan retensi di helpdesk dan aturan siklus hidup penyimpanan di akun cloud Anda.
• Catat pengecualian. Toolkit AI dari ICO meminta jadwal retensi terdokumentasi, penghapusan informasi pribadi di sistem AI sesuai jadwal itu, dan pembenaran DPIA untuk retensi apa pun di luarnya (ICO).

Cadangan adalah jebakan yang biasa. Nyatakan dalam kebijakan Anda berapa lama data yang dihapus bertahan di sana, dan tanyakan hal yang sama kepada vendor.

Data Kartu Pembayaran: Jauhkan dari Chat dan Log AI

Data kartu adalah satu-satunya area dengan aturan industri yang keras, dan tim dukungan melanggarnya secara tidak sengaja lebih sering daripada siapa pun. Pembedaan kuncinya di PCI DSS adalah antara nomor kartu (PAN) dan data otentikasi sensitif, seperti kode keamanan yang tercetak di kartu.

Soal kode keamanan, FAQ PCI SSC tegas: tidak boleh menyimpan kode verifikasi kartu setelah transaksi diotorisasi, mengumpulkannya sebelum otorisasi diperbolehkan, dan persetujuan pelanggan tidak menjadi izin untuk menyimpannya (FAQ PCI SSC 1280). FAQ lain menambahkan bahwa data otentikasi sensitif tidak boleh disimpan setelah otorisasi meskipun terenkripsi, dan hal ini berlaku bahkan ketika tidak ada PAN (FAQ PCI SSC 1533).

Jika pelanggan mengetik nomor kartu dan kode ke chat dan platform menyimpan transkripnya, kode itu kini berada di basis data setelah pembayaran, dan bisa juga mengalir ke prompt, ringkasan, ekspor QA, dan log vendor. Panduan perekaman suara dari PCI SSC menetapkan perilaku terdekat yang diharapkan: cegah perekaman bila memungkinkan, dan hapus segera saat otorisasi bila tidak bisa dicegah (FAQ PCI SSC 1210).

Pendekatan praktisnya adalah pengurangan cakupan, yaitu menata agar data kartu tidak pernah menyentuh sistem dukungan Anda:

1. Jangan minta detail kartu di chat, email, atau kepada AI. Arahkan pelanggan ke halaman pembayaran yang di-host atau tautan aman yang dijalankan penyedia pembayaran Anda.
2. Samarkan apa pun yang menyerupai nomor kartu saat masuk. Lakukan sebelum penyimpanan dan sebelum model, dan beri tahu pelanggan bahwa Anda melakukannya.
3. Gunakan token bila AI perlu merujuk ke pembayaran. AI Principles dari PCI SSC menyarankan mempertimbangkan token pembayaran atau PAN sekali pakai untuk membatasi cakupan dan dampak sistem AI, dan menyatakan pengaman utamanya adalah membatasi data sensitif yang diberikan ke sistem AI sejak awal (blog PCI SSC).
4. Jauhkan juga kredensial. Prinsip yang sama menyebutkan token API, kredensial pengguna, dan kunci kriptografi harus berada di luar dataset AI.
5. Pastikan cakupan dengan acquirer atau asesor Anda. Tanyakan bagaimana penyiapan chat, suara, dan AI Anda cocok, dan sistem mana yang dianggap menangani data kartu.

Ketentuan Vendor: Data Pelatihan, DPA, dan Sub-prosesor

Vendor AI biasanya adalah prosesor yang bertindak untuk Anda. GDPR Pasal 28(3) menyatakan bahwa pemrosesan oleh prosesor diatur oleh kontrak yang mewajibkan prosesor "memproses data pribadi hanya atas instruksi terdokumentasi dari pengendali" dan, atas pilihan pengendali, "menghapus atau mengembalikan seluruh data pribadi kepada pengendali" saat layanan berakhir (GDPR, EUR-Lex). Kontrak itu adalah perjanjian pemrosesan data, atau DPA. Tandatangani sebelum data pelanggan apa pun mengalir.

Dua hal yang kerap menjebak tim.

Ketentuan berbeda menurut produk. Baca dokumentasi tiap vendor untuk produk persis yang Anda beli. OpenAI, misalnya, menyatakan bahwa data API tidak dipakai untuk melatih modelnya kecuali Anda memilih ikut, bahwa log pemantauan penyalahgunaan disimpan hingga 30 hari secara default, dan bahwa Zero Data Retention mengecualikan konten dari log tersebut tetapi memerlukan persetujuan sebelumnya (OpenAI). AI bawaan helpdesk Anda, vendor chatbot, dan platform suara masing-masing punya ketentuan sendiri.

Ketentuan berubah. FTC telah memperingatkan bahwa perusahaan yang mengadopsi praktik data yang lebih longgar, seperti memakai data untuk pelatihan AI, dan memberi tahu pelanggan hanya lewat perubahan ketentuan yang diam-diam dan berlaku surut, dapat dianggap tidak adil atau menipu. FTC juga menyatakan bahwa bisnis yang mengumpulkan data berdasarkan satu set komitmen privasi tidak boleh secara sepihak mengingkarinya (FTC). Itu melindungi pelanggan, tetapi juga mengingatkan Anda untuk memperlakukan ketentuan vendor sebagai dokumen yang hidup. Masukkan kontak pemberitahuan perubahan ke kalender seseorang dan tinjau ketentuan saat perpanjangan.

Daftar periksa pertanyaan untuk vendor

Tanyakan kepada setiap vendor AI dan alat dukungan, dan dapatkan jawabannya di kontrak atau DPA, bukan dalam panggilan penjualan:

• Apakah data kami dipakai untuk melatih atau memperbaiki model Anda atau model pihak ketiga mana pun? Apakah itu nonaktif secara default atau harus dipilih?
• Berapa lama Anda menyimpan prompt, keluaran, dan log, dan bisakah kami memperpendeknya atau menetapkan retensi nol?
• Apa yang terjadi pada data kami saat kontrak berakhir, dan bagaimana penghapusan dikonfirmasi?
• Sub-prosesor mana yang menyentuh data kami, di negara mana, dan bagaimana kami diberi tahu saat berubah?
• Bisakah kami memilih wilayah penyimpanan dan pemrosesan? Apakah staf dukungan mengakses dari wilayah lain?
• Log dan kontrol akses apa yang ada di sisi Anda untuk data kami?
• Bagaimana Anda akan memberi tahu kami tentang pelanggaran, dan dalam waktu berapa lama?
• Apakah produk menyamarkan atau mengecualikan nomor kartu, dan apakah perekaman suara ditangani secara berbeda?

Residensi Data dan Transfer Lintas Batas

GDPR Bab V, yang dibuka dengan Pasal 44, mengatur transfer data pribadi ke negara ketiga (GDPR, EUR-Lex). Bagi pemimpin dukungan, pertanyaan kerjanya sederhana: di negara mana data pelanggan kami disimpan, dan negara mana yang bisa membacanya?

Banyak penyedia AI menawarkan pengaturan wilayah. OpenAI mendokumentasikan residensi data sebagai opsi tingkat proyek yang menyimpan konten pelanggan dalam keadaan diam di wilayah yang dipilih untuk endpoint yang didukung, dengan data sistem dikecualikan (OpenAI). "Dalam keadaan diam" lebih sempit daripada "tidak pernah meninggalkan wilayah", jadi tanyakan kepada tiap vendor soal cadangan, log, dan akses staf dukungan.

Kontrol Akses

Insiden privasi yang paling umum dalam dukungan bukanlah serangan. Melainkan orang yang punya akses terlalu luas membaca apa yang tidak ada alasannya untuk dibaca. GDPR Pasal 32(1)(a) menyebut pseudonimisasi dan enkripsi di antara langkah teknis yang perlu dipertimbangkan (GDPR, EUR-Lex). Tambahkan dasar-dasarnya:

• Akses berbasis peran. Agen melihat antrean mereka sendiri. Peninjau QA melihat sampel. Hanya kelompok kecil yang melihat ekspor mentah dan log AI.
• Hak akses minimum untuk AI itu sendiri. AI Principles dari PCI SSC merekomendasikan memberi AI hanya akses yang dibutuhkannya, dengan kredensial sendiri yang bisa dicabut, dan mencatat tindakannya agar bisa dilacak ke orang yang bertanggung jawab (blog PCI SSC). Bot yang bisa membaca setiap catatan pelanggan karena lebih mudah disiapkan, cepat atau lambat akan ditanyai tentang salah satunya.
• Log audit. Ketahui siapa yang membuka transkrip mana dan kapan.
• Offboarding dan penyamaran. Cabut akses pada hari seseorang pergi, dan tampilkan hanya digit terakhir ID atau nomor telepon secara default.

Cara Menerapkannya dalam Delapan Langkah

1. Inventarisasi setiap tempat data pelanggan berada, memakai tabel di dekat bagian atas.
2. Klasifikasikan setiap jenis data: data pribadi biasa, data sensitif, data pembayaran, kredensial.
3. Keluarkan data pembayaran dari jalur dukungan dengan halaman pembayaran yang di-host dan penyamaran.
4. Tambahkan redaksi sebelum model, sebelum penyimpanan, dan sebelum penggunaan ulang, dan ambil sampel setiap minggu.
5. Tulis jadwal retensi dengan pemilik dan otomatisasi penghapusan di seluruh transkrip, ringkasan, rekaman, log, dan ekspor.
6. Tandatangani DPA dan telusuri daftar periksa vendor.
7. Tetapkan wilayah dan akses di setiap alat dan tinjau daftar pengguna.
8. Ujilah dengan memasukkan data kartu dan data pribadi palsu melalui chat, lalu coba temukan setiap salinannya. Lihat menerapkan AI dalam layanan pelanggan untuk peluncuran yang lebih luas.

Jebakan yang Perlu Dihindari

Hanya meredaksi masukan model. Pesan mentah sering tetap ada di transkrip, log, dan ekspor. Redaksi di mana pun data itu dituliskan, dan jangan percaya satu kotak centang "penyamaran PII" untuk mencakup gudang data, perekam panggilan, dan vendor AI Anda.

Mengenkripsi, bukan menghapus. Untuk kode keamanan, PCI SSC menyatakan larangan penyimpanan berlaku meskipun terenkripsi (FAQ PCI SSC 1280).

Membiarkan ekspor sekali pakai hidup selamanya. Spreadsheet yang dibuat untuk tinjauan QA di bulan Maret masih ada di drive bersama pada bulan Desember. Beri ekspor tanggal kedaluwarsa.

Melupakan sudut pandang pelanggan. Beri tahu orang saat mereka berbicara dengan AI dan apa yang terjadi pada pesan mereka. Risiko AI dalam layanan pelanggan membahas masalah yang lebih luas yang diperparah oleh kegagalan privasi.