Prinsip UU PDP untuk Analis Data: 8 Hal yang Wajib Diketahui

UU PDP nggak ngelarang kamu analisis data pelanggan. Yang diatur itu dasar hukumnya, batas pemakaiannya, dan siapa yang boleh lihat kolom mana.

Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi disahkan Oktober 2022 dengan masa transisi dua tahun. Artinya sejak akhir 2024 aturannya berlaku penuh buat semua pihak yang memproses data pribadi warga Indonesia.

Buat analis data, ini delapan bagian yang paling sering nyentuh kerjaan harian. Aku tulis dari sisi praktik, bukan sisi hukum. Kalau kamu butuh kepastian hukum buat kasus tertentu, baca salinan resminya di JDIH Kementerian Sekretariat Negara atau tanya tim legal.

1. Data pribadi dibagi jadi umum dan spesifik

Data pribadi adalah data tentang orang perseorangan yang bisa diidentifikasi, sendiri atau digabung dengan informasi lain. UU PDP membaginya jadi dua kategori dengan perlakuan berbeda.

Kategori	Contoh	Perlakuan
Umum	Nama lengkap, jenis kelamin, kewarganegaraan, agama, status perkawinan	Perlu dasar pemrosesan yang sah
Spesifik	Data kesehatan, biometrik, genetika, catatan kejahatan, data anak, data keuangan pribadi	Pengamanan lebih ketat, biasanya wajib penilaian dampak

Bagian yang sering kelewat: kombinasi. Kolom kode pos, tanggal lahir, dan jenis kelamin sendirian kelihatan aman. Digabung, tiga kolom itu sering cukup buat nunjuk satu orang di kota kecil.

Jadi jangan menilai kolom satu per satu. Nilai tabelnya sebagai kesatuan.

2. Setiap pemrosesan butuh dasar yang sah

UU PDP nyebut enam dasar pemrosesan data pribadi. Persetujuan cuma salah satunya.

1. Persetujuan yang sah dan eksplisit dari subjek data.
2. Pemenuhan kewajiban perjanjian dengan subjek data.
3. Pemenuhan kewajiban hukum pengendali data.
4. Pelindungan kepentingan vital subjek data.
5. Pelaksanaan tugas untuk kepentingan umum atau pelayanan publik.
6. Pemenuhan kepentingan sah lainnya.

Analisis penjualan internal biasanya jatuh ke dasar nomor dua atau enam, bukan persetujuan. Ini penting, karena kalau kamu bersandar pada persetujuan, subjek data bisa menariknya kapan saja dan kamu harus berhenti memproses.

Tanya ke tim legal dasar mana yang dipakai perusahaanmu buat tiap jenis pemrosesan. Jawabannya harus tertulis, bukan asumsi.

3. Subjek data punya hak yang harus bisa kamu penuhi

Ini bagian yang bikin arsitektur data kamu perlu berubah, bukan cuma kebijakan.

Hak subjek data	Konsekuensi teknis
Minta akses ke datanya	Harus ada cara nyari semua data satu orang lintas tabel
Memperbarui atau melengkapi	Perubahan harus nyebar ke sistem turunan
Mengakhiri pemrosesan dan menghapus	Termasuk salinan di data warehouse dan backup
Menarik persetujuan	Butuh kolom penanda status persetujuan
Keberatan atas keputusan otomatis	Model scoring harus bisa dijelaskan dan ditinjau manusia

Baris terakhir langsung nyentuh model machine learning. Kalau skor otomatis kamu nentuin siapa dapat limit kredit atau siapa dapat promo, harus ada jalur peninjauan manusia.

Baris ketiga sering paling repot. Data pelanggan biasanya nyebar ke lima tempat: database produksi, warehouse, file ekspor di laptop analis, spreadsheet laporan, dan backup. Permintaan hapus harus nyentuh semuanya.

4. Tujuan pemrosesan harus dibatasi

Data yang dikumpulkan buat tujuan A nggak otomatis boleh dipakai buat tujuan B.

Contoh nyata: nomor HP yang dikumpulkan buat konfirmasi pengiriman barang. Dipakai buat kirim promo mingguan? Itu tujuan baru dan butuh dasar sendiri.

Praktik yang aku sarankan: bikin satu tabel pemetaan sederhana yang isinya kolom data, tujuan pengumpulan, dan tujuan pemakaian sekarang. Baris yang dua kolom terakhirnya beda itu daftar kerjaan buat tim legal.

5. Ambil secukupnya, bukan semuanya

Prinsip minimalisasi data. Kumpulin dan proses data seperlunya buat tujuan yang dinyatakan.

Kebiasaan SELECT * langsung bertabrakan dengan prinsip ini. Kalau kamu cuma butuh total belanja per kota, kamu nggak perlu narik NIK, nomor HP, dan alamat lengkap ke laptopmu.

-- Jangan begini
SELECT * FROM pelanggan WHERE kota = 'Surabaya';

-- Begini
SELECT kota, COUNT(*) AS jumlah, SUM(total_belanja) AS omzet
FROM pelanggan
WHERE kota = 'Surabaya'
GROUP BY kota;

Cara paling praktis nerapin ini: bikin view analitik yang udah di-masking, terus kasih akses analis ke view itu, bukan ke tabel asli.

CREATE VIEW v_pelanggan_analitik AS
SELECT
    id_pelanggan,
    CONCAT(LEFT(nama, 1), '***') AS nama_masked,
    CONCAT(LEFT(no_hp, 4), '****', RIGHT(no_hp, 2)) AS hp_masked,
    kota,
    DATE_TRUNC('month', tanggal_daftar) AS bulan_daftar,
    segmen
FROM pelanggan;

Kolom id_pelanggan tetap ada supaya kamu bisa gabung ke tabel transaksi. Yang hilang cuma kolom yang nggak dibutuhin buat analisis.

6. Data punya masa simpan

Data pribadi disimpan selama masih dibutuhkan sesuai tujuan pemrosesan, terus dihapus atau dimusnahkan.

UU-nya nggak nyebut angka hari yang seragam, jadi kamu yang harus nentuin dan menuliskannya. Contoh kebijakan masa simpan yang masuk akal buat ritel:

Jenis data	Masa simpan	Alasan
Data transaksi	10 tahun	Kewajiban dokumen perpajakan dan akuntansi
Nomor HP pelanggan aktif	Selama akun aktif	Pemenuhan perjanjian layanan
Data pelamar kerja yang nggak diterima	1 tahun	Bahan rekrutmen berikutnya, dengan persetujuan
Log akses sistem	2 tahun	Kebutuhan audit keamanan

Angka di tabel itu contoh yang lazim dipakai, bukan ketentuan yang tercantum di UU PDP. Sesuaikan dengan kewajiban sektormu dan mintakan persetujuan tim legal.

Bikin query pemantau supaya kamu tau data mana yang udah lewat masa simpan:

SELECT id_pelanggan, tanggal_transaksi_terakhir,
       CURRENT_DATE - tanggal_transaksi_terakhir AS umur_hari
FROM pelanggan
WHERE CURRENT_DATE - tanggal_transaksi_terakhir > 1825
ORDER BY umur_hari DESC;

7. Kebocoran data wajib dilaporkan cepat

Kalau terjadi kegagalan pelindungan data pribadi, pengendali data wajib memberitahukan ke subjek data dan lembaga terkait dalam waktu paling lambat 3x24 jam.

Tenggat sependek itu artinya kamu nggak punya waktu buat mulai investigasi dari nol. Yang harus udah siap sebelum kejadian:

1. Daftar sistem yang nyimpen data pribadi, beserta jenis kolomnya.
2. Log akses yang cukup detail buat tau siapa narik data apa dan kapan.
3. Nomor kontak penanggung jawab yang jelas, bukan "nanti dicari".
4. Draf surat pemberitahuan yang tinggal diisi.

Poin dua sering nggak ada. Kalau semua analis pakai satu akun database bersama, kamu nggak akan pernah bisa jawab pertanyaan siapa yang ngunduh tabel itu.

8. Sanksinya nggak kecil

Ada dua jalur sanksi. Administratif dan pidana.

Sanksi administratif bertingkat: teguran tertulis, penghentian sementara pemrosesan, penghapusan atau pemusnahan data pribadi, sampai denda administratif dengan batas 2 persen dari pendapatan tahunan.

Jalur pidana menyasar perbuatan seperti mengumpulkan, mengungkapkan, atau menggunakan data pribadi milik orang lain secara melawan hukum. Ancamannya penjara beberapa tahun dan denda sampai miliaran rupiah, tergantung jenis perbuatannya.

Angka pastinya per pasal sebaiknya kamu cek langsung di teks undang-undangnya, jangan bersandar pada ringkasan artikel siapa pun termasuk yang ini.

Contoh kasus: audit akses data di toko_berkah

Aku pernah bantu ngecek pola akses database di lingkungan mirip toko_berkah dengan 1.842 baris pelanggan dan 7 orang yang punya akses baca.

Hasil rekap log tiga bulan:

Jenis query	Jumlah	Porsi
SELECT * ke tabel pelanggan	284	61%
SELECT kolom tertentu	112	24%
Agregasi tanpa kolom identitas	68	15%

Dari 284 query SELECT * itu, cuma 9 yang beneran butuh kolom nomor HP di hasil akhirnya. Sisanya berakhir jadi grafik agregat.

Artinya 275 kali data kontak pelanggan keluar dari database tanpa alasan yang bisa dipertanggungjawabkan. Bukan karena ada yang jahat, tapi karena SELECT * itu kebiasaan jari.

Setelah view masking dipasang dan akses tabel asli dicabut buat 5 dari 7 orang, angka itu turun ke nol tanpa ada satu pun laporan analisis yang jadi terhambat.

Kesalahan umum analis soal UU PDP

1. Ngira menghapus kolom nama sama dengan anonim. Kombinasi tanggal lahir, kode pos, dan jenis kelamin sering cukup buat nunjuk satu orang.
2. Nyimpen ekspor CSV di laptop tanpa batas waktu. Folder Downloads adalah tempat paling sering bocor, dan hampir nggak pernah masuk daftar sistem penyimpan data.
3. Pakai data produksi buat lingkungan uji coba. Bikin data sintetis, atau minimal acak ulang kolom identitasnya.
4. Kirim hasil analisis lewat chat pribadi. Riwayat chat nggak bisa dihapus menyeluruh waktu ada permintaan penghapusan data.
5. Ngeluarin agregat dengan kelompok kecil. Baris "kelompok usia 55-60 di Kabupaten X: 1 orang, rata-rata belanja Rp 4,2 juta" itu praktis nyebut satu orang. Pakai ambang minimal 5 di klausa HAVING.
6. Ngerasa ini urusan tim legal doang. Kolom mana yang ikut kesedot ke laporan itu keputusan analis, bukan keputusan legal.

Poin kelima punya solusi teknis yang gampang:

SELECT kota, kelompok_usia,
       COUNT(*) AS jumlah,
       ROUND(AVG(total_belanja)) AS rata_belanja
FROM v_pelanggan_analitik
GROUP BY kota, kelompok_usia
HAVING COUNT(*) >= 5;

Satu baris HAVING nutup celah identifikasi ulang yang paling sering muncul di laporan segmentasi.

Ringkasnya

Tiga kebiasaan yang bikin kamu aman di 90% situasi harian.

Pertama, kerja dari view yang udah di-masking, bukan dari tabel asli. Kedua, ambil kolom secukupnya dan agregasi sedini mungkin di query, bukan setelah data sampai spreadsheet. Ketiga, kasih ambang minimal jumlah baris di tiap kelompok sebelum angka keluar dari database.

Sisanya urusan kebijakan yang harus disepakati bareng tim legal, dan itu obrolan yang lebih enak dimulai sebelum ada insiden.

Mau latihan bikin view masking dan agregasi aman? Coba mulai dari query cek kualitas data di NgulikSQL, terus lanjut ke konsep data quality buat nyusun pemeriksaan rutinnya.