Belajar AI Engineer - Privacy & Compliance AI

#Pendahuluan

Episode 18 dan 19 mengamankan sistem dari serangan dan kegagalan. Episode ini mengamankan manusia: data pribadi pengguna yang mengalir melalui produk AI kalian. Di era regulasi seperti GDPR dan EU AI Act, privasi bukan lagi nilai tambah — ia syarat untuk beroperasi.

Mengapa penting? Karena produk AI menangani data yang dulu tidak pernah disentuh aplikasi biasa: riwayat percakapan, dokumen pribadi, rekaman suara, hasil ekstraksi. Data ini mengalir ke penyedia LLM, tersimpan di database, dan masuk log observability. Tanpa disiplin privasi, satu kebocoran kecil = denda besar + kepercayaan yang hilang selamanya.

#Data Governance: Tahu Data Apa yang Kalian Simpan

Prinsip pertama governance: kalau tidak perlu, jangan simpan. Sebelum menyimpan apa pun, tanyakan:

1. Data apa ini? (percakapan, dokumen, audio, hasil LLM)
2. Kenapa kita menyimpannya? (produk, analitik, pelatihan?)
3. Berapa lama wajib disimpan? (retensi)
4. Siapa yang berhak mengakses? (authorization)

Jawaban itu menjadi data map — dokumen hidup yang menjadi dasar compliance dan security. Tanpa data map, kalian tidak tahu apa yang harus dilindungi dan dihapus saat pengguna minta.

{
  "percakapan": {
    "sensitive": true,
    "retention_days": 365,
    "encrypted": true,
    "third_party": ["openai"],  // dikirim ke penyedia LLM
    "purpose": "melayani percakapan"
  },
  "log_observability": {
    "sensitive": true,
    "retention_days": 30,
    "encrypted": true,
    "pii_redacted": true
  }
}

#GDPR dan EU AI Act: Yang Perlu AI Engineer Tahu

Dua regulasi yang paling berdampak pada produk AI:

• GDPR (semua produk yang menangani data warga Eropa): wajib lawful basis, data minimization, hak akses, koreksi, dan penghapusan data ("right to be forgotten"), dan DPIA untuk pemrosesan berisiko.
• EU AI Act (mulai berlaku bertahap, 2025-2026): mengklasifikasikan sistem AI berdasarkan risiko — prohibited, high-risk, limited, dan minimal. Banyak produk AI (chatbot, rekomendasi) masuk kategori limited/minimal dengan kewajiban transparansi: beri tahu pengguna bahwa mereka sedang berbicara dengan AI.

#Redaction PII: Sensor Data Sebelum Keluar

Data pribadi (nama, email, NIK, nomor kartu) tidak boleh keluar ke penyedia LLM tanpa keperluan. Praktik standar: redaksi PII sebelum request, restorasi sesudahnya bila diperlukan.

Redaksi PII dengan regex + Presidio

import re
 
def redact_pii(text: str) -> str:
    text = re.sub(r"\b[\w.+-]+@[\w-]+\.[\w.]+\b", "[EMAIL]", text)
    text = re.sub(r"\b08[0-9]{8,12}\b", "[HP]", text)      # nomor HP ID
    text = re.sub(r"\b\d{4}\s?\d{4}\s?\d{4}\s?\d{4}\b", "[KARTU]", text)
    return text
 
# Untuk skala besar: Presidio (Microsoft) mendeteksi PII via model
from presidio_analyzer import AnalyzerEngine
analyzer = AnalyzerEngine()
 
def redact_presidio(text: str) -> str:
    hasil = analyzer.analyze(text=text, language="en")
    # ganti tiap entity dengan [TIPE]
    for e in sorted(hasil, key=lambda x: -x.start):
        text = text[:e.start] + f"[{e.entity_type}]" + text[e.end:]
    return text

Dua level: regex untuk pola jelas (murah, cepat), Presidio untuk deteksi kontekstual (lebih lengkap, lebih mahal). Terapkan sebelum data dikirim ke LLM.

#Hak Pengguna: Akses dan Penghapusan

Regulasi mewajibkan hak pengguna atas data mereka. Secara teknis ini berarti:

1. Export: endpoint yang mengembalikan semua data pribadi pengguna (percakapan, preferensi, memori).
2. Deletion: endpoint yang menghapus semua data pengguna lintas penyimpanan — database, vector DB, cache, dan log.

Hapus data pengguna lintas penyimpanan

def delete_user(user_id: str) -> None:
    # 1. database relasional
    db.execute("DELETE FROM messages WHERE user_id = ?", (user_id,))
    db.execute("DELETE FROM conversations WHERE user_id = ?", (user_id,))
    # 2. vector DB (memori / dokumen pribadi)
    mem_col.delete(where={"user": user_id})
    kb_col.delete(where={"owner": user_id})
    # 3. cache
    cache.flush_user(user_id)
    db.commit()

Perhatikan: penghapusan harus menyeluruh — keliru satu penyimpanan berarti data "terhapus" tapi masih ada di tempat lain. Ini bug compliance yang serius.

#Data Minimization: Desain untuk Tidak Mengumpulkan

Desain paling aman adalah tidak memiliki data yang tidak perlu:

• Jangan simpan raw audio jika transkrip cukup — simpan transkrip, hapus audio setelah diproses.
• Jangan kirim seluruh dokumen ke LLM — kirim chunk relevan saja (episode 7), dan jangan log isinya.
• Pseudonimisasi: ganti user_id asli dengan ID internal di log dan observability — jika log bocor, data tidak langsung tertaut ke individu.

Pseudonimisasi di observability

def emit_without_pii(user_id: str, **fields):
    emit_metric("qa.faithfulness", fields, {"user_pseudo": hash(user_id)})

#Common Pitfalls

• Menyimpan semua yang lewat: raw audio, prompt penuh, output penuh di log — bom PII. Simpan minimal, pseudonimisasi sisanya.
• Menghapus di satu tempat saja: penghapusan user harus menjangkau semua penyimpanan termasuk vector DB dan cache.
• Mengabaikan retensi: data lama yang tidak perlu = tanggung jawab tambahan. Tetapkan retensi dan bersihkan berkala.
• PII masuk prompt tanpa keperluan: redaksi dulu; jika model butuh konteks nama, beri pseudonim.

#Penutup

Inti yang harus dibawa pulang:

• Data governance: petakan data, minimalkan penyimpanan, tetapkan retensi.
• GDPR & EU AI Act: dukung hak akses/penghapusan dan transparansi AI; konsultasikan legal untuk produk berisiko.
• Redaction PII sebelum data keluar ke LLM — regex untuk cepat, Presidio untuk lengkap.
• Penghapusan menyeluruh lintas database, vector DB, dan cache.

Di episode 21 selanjutnya kita membawa model ke infrastruktur sendiri: serving & deploying LLMs — vLLM, TGI, Ollama, llama.cpp, dan deploy model open-weight di produksi. Sampai jumpa di episode 21!