Belajar ML Engineer - Privacy-Preserving ML

#Pendahuluan

Setelah di episode 19 kita membangun governance dan kepatuhan, ada dimensi berikutnya yang semakin menentukan di 2026: privasi data. Regulasi seperti GDPR, CCPA, dan UU PDP di Indonesia menjadikan penanganan data pribadi sebagai kewajiban hukum, bukan sekadar etika. Dan masalah privasi untuk ML lebih halus daripada sekadar "jangan bocorkan database".

Bahayanya sering tak terlihat: model yang dilatih pada data pengguna bisa mengingat dan mengeluarkan data pribadi (misal nomor telepon, kalimat unik pengguna). Artikel "kenapa model LLM bisa mengeluarkan data pribadi" menjadi headline berkali-kali. Episode ini membangun tiga teknik: differential privacy (jaminan matematis), federated learning (melatih tanpa memusatkan data), dan data minimization (prinsip desain).

#Differential Privacy: Jaminan Matematis

Differential privacy (DP) memberikan jaminan yang bisa diukur: output dari query (atau training) hampir tidak berubah apakah individu tertentu ada atau tidak dalam dataset. Dengan kata lain, informasi tentang individu tidak bisa dibedakan.

Idenya: tambahkan noise ke hasil komputasi. Parameter utama:

• Epsilon (ε): anggaran privasi. Semakin kecil, semakin privat (dan semakin bising hasilnya).
• Delta (δ): probabilitas kecil jaminan gagal.

import numpy as np
 
def laplace_mechanism(value: float, sensitivity: float, epsilon: float) -> float:
    scale = sensitivity / epsilon
    return value + np.random.laplace(0, scale)
 
 
true_mean = np.mean(salaries)          # nilai asli
noisy_mean = laplace_mechanism(true_mean, sensitivity=1.0, epsilon=1.0)
print(noisy_mean)                      # ± nilai asli, dengan noise terukur

Pada ML, DP diterapkan saat training — differentially private training menambahkan noise ke gradien (Opacus PyTorch adalah library yang umum dipakai). Harga yang dibayar: akurasi turun karena noise. Pertukaran ε ↔ akurasi adalah keputusan bisnis yang harus dievaluasi (episode 7).

#Kenapa DP Berbeda dari "Anonymization"

Anonymization sederhana (hapus nama, ID) sering gagal — data bisa di-re-identify dari kombinasi atribut unik. DP memberikan jaminan formal yang tidak bergantung pada kehebatan penyerang. Inilah sebabnya DP menjadi standar yang direkomendasikan regulator untuk statistik dan model yang dipublikasikan.

#Federated Learning: Melatih Tanpa Memusatkan Data

Federated learning membalik paradigma training: alih-alih mengumpulkan data ke pusat, model dikirim ke tempat data berada, dilatih secara lokal, dan hanya update model (bukan data) yang dikirim kembali.

Server                Devices
        ── model awal ──►
        ◄── update 1 ── device A
        ◄── update 2 ── device B
        ── agregat ──►
        ◄── update 3 ── device C
        (server mengagregasi update, data tetap di device)

Kasus penggunaan klasik: prediksi teks di keyboard (Google Gboard) dan prediksi kesehatan dari data perangkat. Data mentah tidak pernah meninggalkan perangkat — melanggar data residency menjadi tidak mungkin.

Tantangan federated learning di dunia nyata:

• Non-IID data: tiap device punya distribusi data berbeda — membuat training lebih sulit dan evaluasi lebih rumit.
• Orkestrasi: perangkat offline, tidak sinkron, dan jaringan tidak stabil.
• Komunikasi: transfer model berulang harus efisien.
• Serangan: update model bisa dicurigai (model poisoning); DP sering dikombinasikan untuk mengamankannya.

Framework yang bisa dipakai: Flower (Python, fleksibel), TensorFlow Federated, dan FedML. Federated learning bukan jawaban untuk semua masalah — tetapi untuk kasus di mana data pribadi tersebar dan tidak boleh dipusatkan, ia adalah solusi yang tepat.

#Data Minimization: Prinsip Desain

Data minimization (dari GDPR) sederhana tapi sering dilanggar: kumpulkan data seminimal mungkin yang cukup untuk tujuan. Untuk ML, terjemahan praktisnya:

• Kolom yang tidak dipakai tidak perlu disimpan — setiap kolom ekstra adalah kewajiban privasi ekstra.
• Pseudonymization sedini mungkin: ganti identitas langsung (user_id → hash) begitu tidak dibutuhkan untuk join.
• Retensi terbatas: data mentah tidak disimpan selamanya; tetapkan jadwal pemusnahan.
• Jangan menyalin dataset ke mana-mana: setiap salinan adalah permukaan kebocoran baru.

def build_training_dataset(raw_df: pd.DataFrame) -> pd.DataFrame:
    keep = ["age", "region", "event_count", "days_seen", "churned"]
    df = raw_df[keep].copy()
    df["user_id"] = hash_id(raw_df["user_id"])   # pseudonymization
    return df

Data minimization adalah design principle: ia harus diputuskan saat mendesain schema, bukan diselipkan di akhir.

#Menyusun Pipeline yang Privat

Kombinasi teknik menghasilkan pipeline privat yang solid:

1. Data minimization saat desain: simpan hanya yang dibutuhkan, pseudonymize identitas.
2. Kontrol akses & provenance: siapa bisa melihat data mentah; akses dicatat (episode 18).
3. Differential privacy saat statistik/model akan dipublikasikan atau dipakai lintas pihak.
4. Federated learning saat data tidak boleh meninggalkan lokasi.
5. Enkripsi: enkripsi saat transit & at-rest; pertimbangkan homomorphic encryption untuk kasus tertentu (komputasi pada data terenkripsi — mahal secara komputasi, jarang praktis di 2026).

#Common Pitfalls

#Penutup

Pada episode 20 ini, kalian telah menguasai privasi dalam ML:

• Differential privacy memberi jaminan formal dengan trade-off akurasi.
• Federated learning melatih tanpa memusatkan data — cocok untuk data terdistribusi.
• Data minimization menyusutkan kewajiban privasi dari desain schema.
• Pipeline privat = minimasi + akses terkontrol + DP/FL sesuai kebutuhan, dengan trade-off yang dievaluasi secara jujur.

Di episode 21 selanjutnya kita akan membahas Distributed Training — data parallelism, model parallelism, multi-GPU, dan framework Ray/TorchX untuk melatih model besar yang tidak muat di satu GPU. Sampai jumpa di episode 21!