Karyawan AI dan UU PDP: Kelola Data Pelanggan Tanpa Berlebihan

Ditulis oleh Nugraha Labib Mujaddid, pembuat AgentBuff.

Karyawan AI tidak perlu membaca seluruh arsip pelanggan untuk mengerjakan satu tugas. Prinsip yang lebih aman adalah memberikan data paling sedikit yang memang dibutuhkan, untuk tujuan yang sudah ditentukan, selama waktu yang dapat dijelaskan, lalu mencatat apa yang dilakukan terhadap data tersebut. Dengan desain ini, AI tetap berguna tanpa berubah menjadi salinan liar dari CRM, chat, formulir, dan dokumen identitas.

Karyawan AI untuk pengelolaan data pribadi adalah agen kerja yang membantu menginventarisasi, mengklasifikasikan, menggunakan, memperbaiki, menyimpan, dan menghapus data pelanggan berdasarkan aturan yang ditetapkan manusia. Ia bukan pihak yang menentukan dasar hukum, mengabulkan semua permintaan penghapusan, atau memutuskan sendiri bagaimana insiden dilaporkan.

Artikel ini merupakan panduan operasional, bukan pendapat hukum. Untuk pemrosesan berisiko tinggi, sengketa, transfer lintas negara, atau kewajiban sektoral, mintalah penilaian penasihat yang memahami konteks usaha Anda.

Masalahnya bukan hanya kebocoran

Risiko privasi sering dibayangkan sebagai peretas yang mencuri database. Padahal, masalah sehari-hari lebih sederhana: admin menyalin seluruh spreadsheet pelanggan ke ruang kerja AI; agen memperoleh akses ke lampiran yang tidak relevan; data lama tidak pernah dihapus; nomor telepon muncul di laporan internal; atau permintaan koreksi pelanggan tidak sampai ke semua sistem.

UU Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi mendefinisikan pemrosesan secara luas: pemerolehan dan pengumpulan, pengolahan dan penganalisisan, penyimpanan, perbaikan dan pembaruan, penampilan atau transfer, serta penghapusan atau pemusnahan. Undang-undang yang sama mensyaratkan pemrosesan yang terbatas, spesifik, sah, dan transparan.[1] Artinya, meringkas chat, mengekspor daftar pelanggan, membuat embedding, menampilkan profil, dan menghapus arsip sama-sama bagian dari siklus pemrosesan—bukan hanya tindakan mengumpulkan data.

Bedakan data, tujuan, dan kewenangan

Sebelum menghubungkan AI ke aplikasi usaha, buat tiga peta yang terpisah.

1. Peta data

Catat kategori data yang benar-benar ada, bukan yang menurut tim mungkin ada. Contohnya:

UU PDP membedakan data pribadi umum dan spesifik; antara lain, data kesehatan, biometrik, genetika, catatan kejahatan, data anak, serta data keuangan pribadi termasuk kategori spesifik.[1] Klasifikasi ini harus memengaruhi akses, logging, retensi, dan jalur approval.

2. Peta tujuan

Satu kategori data dapat memiliki beberapa tujuan, tetapi setiap tujuan perlu ditulis. Alamat pengiriman mungkin diperlukan untuk memenuhi pesanan, tetapi bukan otomatis untuk menyusun segmentasi pemasaran. Rekaman percakapan dapat dipakai menyelesaikan tiket, tetapi bukan otomatis menjadi materi pelatihan.

UU PDP mewajibkan pengendali memiliki dasar pemrosesan. Persetujuan eksplisit hanyalah salah satu dasar; undang-undang juga menyebut pemenuhan perjanjian, kewajiban hukum, kepentingan vital, tugas kepentingan umum, dan kepentingan sah lainnya dengan mempertimbangkan keseimbangan hak.[1] Karena itu, jangan membuat agen menggunakan label consent=true untuk semua kasus. Dasar pemrosesan harus ditentukan sesuai keadaan dan dicatat oleh pihak yang berwenang.

3. Peta kewenangan

Pisahkan kemampuan berikut:

• membaca data;
• mencari berdasarkan identitas;
• membuat ringkasan;
• memperbaiki nilai;
• mengekspor atau membagikan;
• menghapus dari sistem aktif;
• memusnahkan salinan dan cadangan;
• mengirim pemberitahuan kepada pelanggan.

Izin membaca tidak sama dengan izin mengirim. Izin mengusulkan penghapusan tidak sama dengan izin mengeksekusinya. Pemisahan ini mencegah satu instruksi keliru menghasilkan tindakan yang sulit dipulihkan.

Workflow sembilan tahap yang dapat dipakai UMKM

1. Buat register pemrosesan sederhana

Mulai dengan tabel berikut:

activity_id | tujuan | kategori_data | subjek | sumber | sistem
dasar_pemrosesan | penerima | retensi | pemilik | agen_dengan_akses
risiko | kontrol | status

Register tidak harus menjadi dokumen hukum yang rumit. Fungsinya adalah menjawab: data apa yang masuk, mengapa dipakai, siapa yang bisa melihat, ke mana data bergerak, dan kapan nasibnya ditinjau.

NIST Privacy Framework menempatkan inventory dan mapping sebagai dasar untuk memahami pemrosesan serta risiko privasi. Kerangka tersebut juga menghubungkan kebijakan retensi, siklus hidup data, akses untuk koreksi atau penghapusan, audit log, dan minimisasi.[2]

2. Tetapkan kontrak data untuk setiap tugas

Jangan memberi agen mandat umum “akses data pelanggan”. Buat kontrak per workflow:

tujuan: mengelompokkan tiket retur untuk antrean admin
data_diizinkan: ticket_id, alasan, kategori_produk, tanggal_pembelian
data_dilarang: nomor_identitas, data_pembayaran_lengkap, percakapan_di_luar_tiket
output: kategori, tingkat_urgensi, alasan, locator_bukti
retensi_output: 30 hari setelah tiket ditutup
tindakan_eksternal: tidak diizinkan
approval: wajib sebelum refund atau pesan dikirim

Jika sebuah kolom tidak diperlukan untuk menghasilkan output, hapus sebelum data diberikan. Ini lebih kuat daripada berharap model mengabaikan kolom sensitif.

3. Minimalkan sebelum data mencapai model

Lakukan pembatasan di lapisan tool atau integrasi:

• pilih kolom yang relevan;
• gunakan rentang tanggal terbatas;
• ganti identitas dengan token bila identitas tidak diperlukan;
• potong bagian dokumen di luar kebutuhan;
• sembunyikan data pembayaran dan kredensial;
• berikan hasil pencarian, bukan seluruh database;
• batasi jumlah record per permintaan.

NIST merekomendasikan pengelolaan data yang mendukung minimisasi dan teknik yang membatasi keterhubungan atau identifikasi individu.[2] Untuk AI generatif, NIST juga menekankan governance, provenance, pengujian, dan penanganan insiden sepanjang siklus hidup.[3]

4. Simpan locator, bukan menyalin semuanya

Untuk banyak pekerjaan, agen cukup menyimpan customer_id, ticket_id, atau tautan ke sumber yang dikendalikan. Ia tidak perlu menempelkan nama, telepon, alamat, dan isi chat ke setiap ringkasan.

Gunakan dua lapisan:

• working record: data minimum untuk menyelesaikan tugas;
• source locator: penunjuk ke sumber resmi yang dapat diakses ulang sesuai izin.

Jika data sumber diperbaiki, working record harus ikut ditinjau. Salinan tanpa lineage membuat koreksi dan penghapusan sulit disebarkan.

5. Verifikasi identitas sebelum memenuhi permintaan

UU PDP memberikan hak kepada subjek data untuk memperoleh informasi, memperbarui atau memperbaiki ketidakakuratan, serta mengakses dan memperoleh salinan data tentang dirinya.[1] Namun agen tidak boleh langsung menyerahkan data hanya karena seseorang menyebut nama dan nomor telepon.

Buat alur:

1. terima permintaan tercatat;
2. verifikasi identitas dengan metode proporsional;
3. klasifikasikan permintaan: akses, koreksi, penarikan persetujuan, penghentian, penghapusan, atau keluhan;
4. cari sistem dan salinan terkait;
5. siapkan paket respons;
6. minta review manusia;
7. eksekusi dan simpan bukti penyelesaian.

Hindari mengumpulkan lebih banyak data identitas daripada yang diperlukan hanya untuk verifikasi.

6. Kelola koreksi sebagai perubahan berantai

Jika pelanggan mengganti nomor telepon, memperbaiki nama, atau menyatakan alamat salah, jangan hanya mengubah satu spreadsheet. Buat correction ticket dengan daftar sistem terdampak, nilai lama, nilai baru, sumber permintaan, verifikasi, pelaksana, dan waktu selesai.

Karyawan AI dapat menemukan salinan yang tertinggal dan membuat checklist. Manusia tetap memutuskan konflik—misalnya ketika catatan transaksi, dokumen identitas, dan permintaan baru tidak konsisten.

7. Retensi harus berbentuk aturan yang bisa dijalankan

“Simpan selama diperlukan” tidak cukup untuk workflow otomatis. Gunakan aturan berbasis peristiwa:

tiket_layanan: hapus 24 bulan setelah ditutup, kecuali ada sengketa aktif
prospek_tidak_aktif: tinjau 12 bulan setelah kontak terakhir
output_ringkasan_ai: hapus 30 hari setelah tugas selesai
log_akses: simpan sesuai kebijakan keamanan dan kebutuhan audit

Angka tersebut hanya contoh desain, bukan tenggat universal. Retensi aktual harus mengikuti tujuan, dasar pemrosesan, kewajiban hukum, kebutuhan pembuktian, dan aturan sektor. UU PDP meminta informasi mengenai jangka waktu retensi ketika pemrosesan didasarkan pada persetujuan, serta mewajibkan penghapusan dalam kondisi tertentu, termasuk ketika data tidak lagi diperlukan untuk tujuan pemrosesan.[1]

8. Penghapusan memerlukan receipt

Tombol “delete” pada satu aplikasi belum membuktikan data selesai ditangani. Buat deletion manifest:

request_id | identitas_terverifikasi | scope | sistem_aktif
arsip | cache | indeks_pencarian | embedding | ekspor | backup
pengecualian_dan_dasar | operator | waktu | bukti | pemberitahuan

Bedakan penghapusan dari sistem aktif, pemusnahan, anonimisasi, dan pembatasan pemrosesan. Catat bagian yang belum bisa dihapus serta alasannya. UU PDP mengatur kewajiban penghapusan dan pemberitahuan kepada subjek data; NIST menyarankan agar elemen data dapat diakses untuk penghapusan dan dimusnahkan sesuai kebijakan.[1][2]

9. Siapkan jalur insiden sebelum insiden terjadi

Jangan meminta agen menyimpulkan sendiri bahwa suatu kejadian “bukan kebocoran”. Buat pemicu eskalasi untuk akses tak sah, pengiriman ke penerima salah, hilangnya perangkat, kredensial terekspos, ekspor berlebihan, atau data muncul di output publik.

Paket awal insiden sebaiknya berisi:

• waktu deteksi dan rentang kejadian;
• sistem, akun, dan data terdampak;
• tindakan pembatasan;
• sumber bukti dan log;
• pihak yang perlu dilibatkan;
• keputusan yang belum dibuat;
• catatan pemulihan.

Pasal 46 UU PDP menetapkan pemberitahuan tertulis paling lambat 3 × 24 jam kepada subjek data dan lembaga ketika terjadi kegagalan pelindungan data pribadi, dengan isi minimum tertentu.[1] Karena konsekuensinya tinggi, penilaian dan komunikasi insiden harus melalui penanggung jawab manusia dan penasihat yang sesuai.

Contoh: toko online menangani permintaan penghapusan

Seorang pelanggan meminta semua datanya dihapus setelah pesanan selesai. Agen menemukan nama dan telepon di CRM, tiket komplain, ekspor promosi, ringkasan percakapan, indeks pencarian internal, serta catatan transaksi.

Agen tidak langsung menghapus semuanya. Ia:

1. membuat tiket dan meminta verifikasi identitas;
2. memetakan tujuan serta dasar setiap salinan;
3. menandai data yang tidak lagi diperlukan;
4. memisahkan catatan yang mungkin wajib dipertahankan berdasarkan kewajiban usaha;
5. menyiapkan daftar tindakan dan pengecualian untuk review;
6. setelah approval, menjalankan penghapusan sesuai kewenangan;
7. memeriksa indeks, ekspor, dan ringkasan turunan;
8. menghasilkan receipt dan draf pemberitahuan.

Nilai AI bukan keputusan hukum otomatis. Nilainya adalah membuat tidak ada salinan yang diam-diam terlewat.

Instruksi kerja siap pakai

Kerjakan hanya untuk tujuan yang tercantum pada task. Gunakan data minimum dari field yang diizinkan dan jangan membuka sumber lain tanpa approval. Pertahankan source locator dan jangan menyalin identitas ke output bila tidak diperlukan. Untuk permintaan akses, koreksi, penghapusan, transfer, atau insiden, buat tiket tercatat dan verifikasi identitas sesuai prosedur. Jangan menentukan dasar pemrosesan, pengecualian retensi, atau kewajiban pemberitahuan sendiri. Tandai konflik dan data yang belum ditemukan. Semua tindakan eksternal, perubahan permanen, ekspor, dan penghapusan wajib melewati approval manusia serta menghasilkan audit receipt.

Instruksi ini harus diterapkan bersama kontrol tool. Prompt tidak dapat menggantikan pemisahan izin, pembatasan kolom, autentikasi, logging, dan prosedur insiden.

Cara menguji sebelum diberi data nyata

Gunakan data sintetis, lalu uji setidaknya kasus berikut:

• tugas hanya membutuhkan kota, tetapi sumber berisi nomor identitas;
• dua pelanggan memiliki nama sama;
• permintaan penghapusan datang dari akun yang belum terverifikasi;
• data sudah dihapus dari CRM tetapi masih ada di ekspor;
• koreksi harus menyebar ke tiga sistem;
• record berada dalam sengketa aktif;
• agen mencoba memasukkan data pribadi ke laporan publik;
• integrasi mengembalikan kolom lebih banyak daripada kontrak;
• lampiran berisi instruksi untuk mengekspor database;
• terjadi akses dari akun yang tidak seharusnya.

Nilai keberhasilan berdasarkan minimisasi, akurasi pencarian salinan, penolakan tindakan tanpa kewenangan, kelengkapan bukti, dan kualitas eskalasi—bukan sekadar kecepatan respons.

Peran AgentBuff yang proporsional

AgentBuff adalah platform Karyawan AI asal Indonesia, bukan sekadar chatbot. Pengguna mengelola agen lewat chat, memberi peran, skills, dan tools, menghubungkannya ke aplikasi atau data kerja, menjalankan workflow dan tugas terjadwal, lalu menerima hasil kerja nyata.

Untuk data pelanggan, mulai dari akses baca terbatas: menyusun inventaris, menemukan duplikasi, menyiapkan tiket koreksi atau penghapusan, dan membuat receipt. Jangan mulai dengan izin ekspor massal atau penghapusan permanen.

Bangun fondasinya melalui akses baca dan approval manusia, jejak kerja yang dapat diperiksa, dan pengujian sebelum tugas rutin.

FAQ

Apakah semua penggunaan data pelanggan harus memakai persetujuan?

Tidak selalu. UU PDP mencantumkan beberapa dasar pemrosesan, bukan hanya persetujuan. Dasar yang tepat bergantung pada tujuan dan konteks; jangan meminta agen menentukannya tanpa kebijakan dan review yang berwenang.

Bolehkah AI membaca seluruh CRM agar hasilnya lebih bagus?

Jangan secara default. Berikan record dan field minimum untuk tugas tertentu. Akses luas meningkatkan dampak kesalahan, kebocoran, dan penggunaan di luar tujuan.

Apakah menghapus chat sudah memenuhi permintaan penghapusan?

Belum tentu. Data dapat tersisa di CRM, ekspor, indeks, ringkasan, cache, arsip, atau sistem pihak ketiga. Scope penghapusan perlu dipetakan dan dibuktikan.

Apakah data anonim bebas risiko?

Anonimisasi harus benar-benar mencegah identifikasi kembali dalam konteks yang wajar. Menghapus nama tetapi mempertahankan telepon, alamat rinci, atau kombinasi atribut unik bukan anonimisasi yang memadai.

Workflow pertama apa yang paling aman?

Minta agen membuat inventaris read-only dari satu proses, misalnya tiket pelanggan, tanpa mengekspor isi sensitif. Cocokkan peta tersebut dengan sistem asli dan kebijakan usaha sebelum menambah kewenangan.

Penutup

Karyawan AI yang menghormati privasi bukan agen yang “tidak pernah melihat data”. Ia adalah agen yang mengetahui batas: data apa yang boleh dipakai, untuk tujuan apa, dari sumber mana, sampai kapan, dan tindakan mana yang harus menunggu manusia.

Mulailah dengan satu register pemrosesan dan satu workflow read-only. Jika ingin membangunnya, coba AgentBuff untuk mengatur pekerjaan agen secara bertahap—dengan keputusan hukum dan akuntabilitas tetap berada pada manusia.

Tentang penulis: Nugraha Labib Mujaddid membangun AgentBuff untuk membantu individu dan bisnis Indonesia bekerja dengan karyawan AI.

Sumber dan bacaan utama

[1] JDIH Kementerian Komunikasi dan Digital, Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi — https://jdih.komdigi.go.id/produk_hukum/view/id/832/t/crc32/

[2] NIST, Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0, Januari 2020 — https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf

[3] NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, Juli 2024 — https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf