← Blog · Industry · 9 min read
AI lapar data, tapi UU PDP menetapkan batas. Panduan ini menerjemahkan kewajiban perlindungan data pribadi menjadi praktik rekayasa untuk proyek AI Anda.
A 30-minute scoping call. We listen, ask three questions, tell you if we can help.
Book a callAda ketegangan mendasar di jantung setiap proyek AI: model belajar dari data, dan semakin banyak data yang relevan, semakin baik hasilnya. Tetapi sebagian besar data paling berharga di perusahaan Indonesia adalah data pribadi—nama nasabah, NIK, riwayat transaksi, rekam medis, perilaku belanja. Sejak UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi (UU PDP) berlaku penuh, dengan masa transisi yang telah lewat dan sanksi yang nyata di depan mata, kelaparan data AI berhadapan langsung dengan kewajiban hukum yang tegas.
Kabar baiknya, kepatuhan UU PDP dan AI yang berkinerja baik bukan dua hal yang saling meniadakan. Sebaliknya, tata kelola data yang rapi justru menghasilkan sistem AI yang lebih andal, lebih mudah diaudit, dan lebih dipercaya. Artikel ini menerjemahkan kewajiban UU PDP menjadi praktik rekayasa konkret—bukan teori hukum—agar tim teknis dan pemimpin produk bisa membangun proyek AI yang tidak hanya pintar, tetapi juga patuh.
Sistem AI memunculkan tantangan kepatuhan yang tidak ada pada aplikasi biasa. Memahaminya di muka mencegah kejutan mahal di kemudian hari.
Penggunaan sekunder data. Data yang dikumpulkan untuk satu tujuan—katakanlah memproses transaksi—lalu dipakai untuk melatih model. UU PDP menekankan prinsip pembatasan tujuan: data pribadi diproses sesuai tujuan yang sah dan telah diberitahukan. Memakai data lama untuk melatih AI tanpa dasar yang sesuai adalah risiko nyata.
Sifat model yang sulit "melupakan". Begitu data pribadi terserap ke dalam bobot model hasil fine-tuning, mencabutnya kembali jauh lebih sulit daripada menghapus baris di basis data. Ini berbenturan langsung dengan hak subjek data untuk meminta penghapusan.
Inferensi sebagai data pribadi baru. Model bisa menyimpulkan atribut sensitif—kondisi kesehatan, orientasi, kemampuan finansial—dari data yang tampak biasa. Hasil inferensi ini sendiri bisa menjadi data pribadi yang harus dilindungi.
Aliran data ke pihak ketiga. Mengirim prompt berisi data nasabah ke API LLM eksternal berarti memindahkan data pribadi ke prosesor lain, kerap lintas negara—memicu kewajiban kontraktual dan, untuk transfer keluar Indonesia, persyaratan tambahan.
Setiap pemrosesan data pribadi dalam proyek AI harus berdiri di atas salah satu dasar yang sah menurut UU PDP. Ini bukan formalitas hukum yang bisa ditambahkan belakangan; ia menentukan apa yang boleh dan tidak boleh dilakukan model Anda.
Persetujuan (consent) adalah dasar yang paling dikenal, tetapi sering disalahgunakan. Persetujuan yang sah harus spesifik, terinformasi, dan dapat ditarik—bukan kotak centang samar di syarat dan ketentuan yang tak pernah dibaca. Jika Anda mengandalkan persetujuan, Anda harus mampu menunjukkan persetujuan untuk tujuan AI yang spesifik, bukan sekadar persetujuan umum penggunaan layanan.
Pertanyaan pertama untuk setiap proyek AI bukanlah "model apa yang kita pakai", melainkan "atas dasar apa kita sah memproses data ini, dan untuk tujuan apa". Jika tim teknis tidak bisa menjawabnya, proyek belum siap dimulai.
Untuk konteks bisnis tertentu, dasar lain seperti pelaksanaan kontrak atau kepentingan yang sah mungkin lebih tepat daripada persetujuan—dan kadang lebih kokoh, karena tidak bisa ditarik sewaktu-waktu. Memilih dasar yang tepat sebaiknya melibatkan tim hukum atau Pejabat Pelindungan Data sejak fase desain, bukan setelah sistem dibangun.
Salah satu prinsip inti UU PDP—memproses data seperlunya dan sesuai tujuan—ternyata sejalan dengan rekayasa AI yang baik. Model jarang membutuhkan seluruh data; ia membutuhkan fitur yang relevan.
Dalam praktik, minimisasi data berarti beberapa disiplin konkret. Sebelum data masuk ke pipeline pelatihan atau inferensi, tanyakan field mana yang benar-benar diperlukan untuk tujuan model, dan buang sisanya. NIK lengkap jarang dibutuhkan model rekomendasi; tanggal lahir presisi sering bisa diganti rentang usia. Semakin sedikit data pribadi yang mengalir, semakin kecil permukaan risiko, semakin ringan beban kepatuhan, dan—sering kali—semakin bersih sinyal yang dipelajari model.
Prinsip retensi mengikuti logika yang sama: data tidak disimpan lebih lama dari yang diperlukan. Ini menuntut kebijakan retensi yang eksplisit dan mekanisme penghapusan otomatis, bukan sekadar niat baik. Data pelatihan yang menumpuk tanpa batas bukan aset—ia liabilitas yang menunggu menjadi insiden.
Dalam praktik, banyak tim AI tergoda menyimpan segalanya "untuk berjaga-jaga"—log prompt lengkap, riwayat percakapan, dataset mentah—dengan keyakinan bahwa data lebih banyak selalu lebih baik untuk perbaikan model di masa depan. Keyakinan ini perlu ditantang. Setiap potongan data pribadi yang Anda simpan adalah kewajiban yang harus dijaga keamanannya, dipertanggungjawabkan saat audit, dan dihapus saat diminta. Pertanyaan yang sehat bukan "apakah data ini mungkin berguna nanti", melainkan "apakah nilai menyimpannya melebihi risiko dan beban kepatuhan yang ditimbulkannya". Sering kali jawabannya tidak—dan disiplin membuang lebih cepat justru membuat sistem lebih ringan dan lebih aman.
Dua teknik ini sering dianggap sama, padahal konsekuensi hukumnya berbeda jauh, dan kesalahpahaman di sini adalah sumber risiko yang umum.
Pseudonimisasi mengganti pengenal langsung dengan token atau alias, sementara kunci untuk mengembalikannya tetap disimpan terpisah. Data pseudonim masih dianggap data pribadi menurut UU PDP, karena masih bisa dikaitkan kembali ke individu. Pseudonimisasi mengurangi risiko dan merupakan praktik keamanan yang baik, tetapi tidak membebaskan Anda dari kewajiban perlindungan data.
Anonimisasi sejati membuat data tidak dapat lagi dikaitkan ke individu mana pun, bahkan dengan upaya wajar dan data tambahan. Data yang benar-benar anonim berada di luar cakupan UU PDP. Masalahnya, anonimisasi sejati jauh lebih sulit dari dugaan—kombinasi beberapa atribut "tidak sensitif" (kode pos, usia, jenis kelamin, tanggal kunjungan) sering cukup untuk mengidentifikasi ulang seseorang. Klaim anonimisasi harus diuji terhadap risiko re-identifikasi, bukan diasumsikan.
Untuk proyek AI, pseudonimisasi pada data pelatihan dan inferensi adalah praktik pertahanan berlapis yang sangat dianjurkan—kurangi paparan pengenal langsung sebanyak mungkin, bahkan ketika Anda tetap memperlakukan datanya sebagai data pribadi.
Kesalahan klasik yang berulang adalah tim menghapus kolom "nama" dan "NIK" dari dataset, lalu mendeklarasikannya "anonim" dan merasa bebas dari kewajiban UU PDP. Padahal data yang tersisa—tanggal lahir, kode pos, riwayat transaksi spesifik, pola perilaku—sering kali masih cukup unik untuk menunjuk satu individu bila digabung dengan sumber lain. Anonimisasi sejati menuntut pengujian risiko re-identifikasi yang serius, bukan sekadar menghapus beberapa kolom yang jelas. Bila ragu, perlakukan data sebagai data pribadi dan terapkan kontrol yang sesuai; asumsi yang salah ke arah sebaliknya adalah asumsi yang mahal.
UU PDP memberi subjek data sejumlah hak yang harus bisa Anda penuhi secara operasional. Ini sering menjadi titik buta proyek AI karena hak-hak ini sulit dipenuhi jika tidak dirancang sejak awal.
Hak akses dan informasi. Subjek data berhak tahu data apa yang Anda proses dan untuk apa. Sistem Anda perlu mampu menelusuri data seorang individu di seluruh pipeline.
Hak koreksi. Data yang salah harus bisa diperbaiki—termasuk memengaruhi keluaran model yang dibangun di atasnya.
Hak penghapusan. Inilah yang paling menantang untuk AI. Menghapus data dari basis data mudah; "menghapusnya" dari model hasil pelatihan tidak. Strateginya: hindari menanam data pribadi langsung ke bobot model bila memungkinkan—gunakan pendekatan berbasis pengambilan (RAG) di mana data tetap berada di sumber yang bisa dihapus, alih-alih fine-tuning yang menyerap data ke model.
Hak terkait keputusan otomatis. Untuk keputusan yang sepenuhnya otomatis dan berdampak signifikan—persetujuan kredit, penilaian klaim—subjek data berhak atas perlindungan tambahan, termasuk penjelasan. Ini menuntut explainability dan jejak audit yang memadai.
Implikasi arsitektur yang penting: desain RAG sering lebih ramah kepatuhan daripada fine-tuning untuk data pribadi, justru karena data tetap berada di luar model dan dapat dikelola, dikoreksi, serta dihapus secara terpisah.
Kepatuhan yang hanya hidup di dokumen kebijakan akan gagal di lapangan. Tata kelola yang efektif tertanam dalam cara tim bekerja sehari-hari.
Tunjuk dan libatkan Pejabat Pelindungan Data (DPO). UU PDP mewajibkan DPO untuk kategori pengendali tertentu. Lebih dari kepatuhan formal, DPO yang dilibatkan sejak desain mencegah kesalahan mahal sebelum kode ditulis.
Lakukan penilaian dampak pelindungan data. Untuk pemrosesan berisiko tinggi—dan banyak proyek AI termasuk di dalamnya—nilai risiko terhadap subjek data sebelum membangun, bukan setelah insiden.
Catat aliran data secara menyeluruh. Petakan dari mana data pribadi berasal, ke mana ia mengalir, siapa yang memprosesnya, dan ke mana ia keluar—termasuk ke API pihak ketiga. Peta ini adalah fondasi dari hampir semua kewajiban lain.
Atur transfer ke pemroses pihak ketiga dengan kontrak. Setiap penyedia API LLM atau cloud yang memproses data Anda adalah prosesor yang menuntut perjanjian pemrosesan data, jaminan keamanan, dan—untuk transfer ke luar Indonesia—pemenuhan syarat transfer lintas batas.
Bangun jejak audit sejak awal. Catat keputusan otomatis, data yang dipakai, dan campur tangan manusia. Jejak ini melindungi Anda saat regulator atau subjek data bertanya.
Salah satu jalur kebocoran kepatuhan paling umum—dan paling tidak disadari—adalah pengiriman data pribadi ke API LLM pihak ketiga di dalam prompt. Saat sebuah aplikasi membangun prompt yang berisi nama nasabah, riwayat transaksi, atau keluhan kesehatan, lalu mengirimnya ke layanan LLM eksternal, data pribadi itu telah berpindah ke prosesor lain—sering kali di luar yurisdiksi Indonesia.
Ini menuntut beberapa kontrol konkret yang harus dirancang ke dalam sistem, bukan ditambahkan belakangan.
Redaksi dan minimisasi prompt. Sebelum data dikirim ke model eksternal, tanyakan field mana yang benar-benar diperlukan untuk tugasnya. Nama lengkap dan NIK jarang dibutuhkan untuk merangkum keluhan; ganti dengan token atau hilangkan. Bangun lapis redaksi otomatis yang menyaring pengenal langsung sebelum data meninggalkan kendali Anda.
Perjanjian pemrosesan data dengan penyedia. Setiap penyedia API adalah prosesor yang menuntut kontrak yang mengatur tujuan pemrosesan, larangan penggunaan untuk pelatihan ulang, kewajiban keamanan, dan ketentuan penghapusan.
Jaminan residensi dan transfer lintas batas. Untuk data yang diproses di luar Indonesia, pastikan syarat transfer lintas batas UU PDP terpenuhi—atau pilih opsi residensi data domestik bila tersedia.
Pertimbangkan self-hosting untuk data paling sensitif. Untuk beban kerja yang menyentuh data pribadi spesifik, menjalankan model open-weight di infrastruktur sendiri menghilangkan seluruh kelas risiko transfer ini sekaligus.
Keputusan arsitektur di sini—seberapa jauh data pribadi boleh mengalir, dan kontrol apa yang menyertainya—seharusnya menjadi bagian dari penilaian dampak pelindungan data, bukan keputusan teknis yang diambil diam-diam oleh seorang engineer di tengah sprint.
Mudah memperlakukan UU PDP sebagai daftar hambatan. Tetapi tim yang paling matang melihatnya sebaliknya. Tata kelola data yang baik menghasilkan data yang lebih bersih, pipeline yang lebih terdokumentasi, dan sistem yang lebih mudah diaudit—semuanya membuat AI Anda lebih andal, bukan kurang. Di pasar di mana kepercayaan nasabah semakin langka, kemampuan menunjukkan bahwa Anda memperlakukan data pribadi dengan serius adalah pembeda kompetitif yang nyata, bukan sekadar perisai hukum.
Sanksi atas pelanggaran UU PDP—administratif maupun finansial—cukup signifikan untuk membuat pengabaian menjadi taruhan yang buruk. Tetapi membangun dengan kepatuhan sejak awal jauh lebih murah daripada menambalnya setelah sistem berjalan, apalagi setelah insiden terjadi.
Menyeimbangkan kebutuhan data AI dengan kewajiban UU PDP No. 27/2022 bukan persoalan yang bisa diserahkan ke tim hukum di akhir proyek—ia harus tertanam dalam arsitektur, pilihan teknik (RAG versus fine-tuning), dan aliran data sejak hari pertama. Kesalahan tata kelola yang ditemukan setelah peluncuran jauh lebih mahal dan berisiko daripada yang dicegah saat desain.
Sainskerta Solusi Nusantara membantu perusahaan Indonesia merancang dan membangun sistem AI yang patuh UU PDP sejak fondasinya—dari pemetaan aliran data, pemilihan arsitektur yang ramah hak subjek data, hingga penyiapan jejak audit dan tata kelola yang operasional. Hubungi tim kami melalui halaman Kontak untuk menjadwalkan sesi konsultasi, dan kami akan bantu menilai kesiapan kepatuhan proyek AI Anda serta menyusun langkah perbaikan yang konkret.
