Awalnya saya pikir etika AI itu urusan manajemen atau pengacara. Salah besar. Semakin jauh saya belajar, semakin jelas bias dan risiko keamanan lahir dari keputusan teknis sehari-hari: dataset apa yang dipakai, fitur mana yang dibuang, bagaimana model diuji. Episode ini catatan saya tentang tiga hal: bias data, keamanan AI, dan regulasi — khususnya EU AI Act yang mulai mengubah cara kita membangun produk AI.
Bias Data: Sampah Masuk, Bias Keluar
Model belajar pola dari data latih. Kalau datanya timpang, modelnya timpang. Contoh klasik yang sering dikutip: sistem rekrutmen yang dilatih dari data perekrutan historis cenderung mereplikasi ketimpangan historis itu. Analogi programmer sederhana: garbage in, garbage out — tapi versi berbahaya karena output-nya keputusan tentang manusia. Jenis bias yang perlu diwaspadai:
- Sampling bias: data latih tidak mewakili populasi pemakai.
- Label bias: label historis sudah memuat prasangka (keputusan manusia masa lalu).
- Measurement bias: cara mengukur fitur berbeda antar kelompok.
- Feedback loop: output model memengaruhi data baru yang melatih model berikutnya.
Cara mengecek secara teknis: pecah evaluasi per subkelompok. Akurasi rata-rata 95% bisa menyembunyikan 99% untuk kelompok mayoritas dan jauh lebih rendah untuk minoritas. Metrik seperti accuracy per group, equalized odds, atau demographic parity ratio membantu memunculkan ketimpangan yang tersembunyi di balik angka agregat:
import pandas as pd
from sklearn.metrics import accuracy_score
df = pd.DataFrame({
"y_true": y_test,
"y_pred": y_pred,
"group": df_test["gender"], # kolom atribut sensitif
})
for g, sub in df.groupby("group"):
print(g, accuracy_score(sub["y_true"], sub["y_pred"]))Kasus Nyata: Ketika Bias Menjadi Berita
Konsep bias terdengar abstrak sampai saya melihat dampaknya di dunia nyata. Tiga kasus yang mengubah cara saya memandang data latih:
Amazon Hiring Tool (2018): Amazon mengembangkan sistem rekrutmen berbasis AI yang dilatih dari resume pelamar selama 10 tahun terakhir. Karena sebagian besar pelamar teknis adalah laki-laki, model mempelajari pola bahwa kata-kata seperti “women’s” (misalnya “women’s chess club”) adalah sinyal negatif. Sistem aktif menurunkan ranking resume yang mengandung kata terkait perempuan. Amazon akhirnya membuang tool tersebut. Pelajaran utama: data historis bukan netral — ia membawa artefak ketimpangan masa lalu.
COMPAS Recidivism (2016): Sistem COMPAS digunakan di pengadilan AS untuk memprediksi kemungkinan terpidana melakukan kejahatan lagi. Investigasi ProPublica menemukan model ini dua kali lebih sering salah mengklasifikasikan orang kulit hitam sebagai risiko tinggi dibandingkan orang kulit putih. Ironisnya, Northpointe (pembuat COMPAS) membantah dengan metrik yang berbeda — menunjukkan bahwa definisi “fairness” itu sendiri masih diperdebatkan secara teknis.
Apple Card Gender Bias (2019): Apple Card, diluncurkan bekerja sama dengan Goldman Sachs, dituduh memberikan limit kredit yang jauh lebih rendah kepada perempuan dibandingkan pasangan mereka meskipun memiliki skor kredit gabungan yang sama. Steve Wozniak sendiri mengungkapkan istrinya mendapat limit 10 kali lebih rendah. Kasus ini menyoroti masalah proxy variable — model tidak menggunakan gender secara langsung, tetapi variabel lain yang berkorelasi dengan gender menghasilkan dampak diskriminatif.
Ketiga kasus ini mengajarkan satu hal: tidak cukup hanya menghapus kolom “gender” dari dataset. Bias bisa menyusup melalui jalur proxy yang tidak terlihat tanpa analisis yang cermat terhadap distribusi data dan dampaknya terhadap kelompok yang berbeda.
Keamanan AI: Permukaan Serangan Baru
LLM membuka kelas serangan yang tidak ada di aplikasi web tradisional. Yang wajib saya catat:
- Prompt injection: instruksi tersembunyi di konteks eksternal (email, halaman web, dokumen RAG) yang membajak perilaku model.
- Data leakage: model bocor data latih sensitif saat diminta dengan cara tertentu.
- Jailbreak: rekayasa prompt untuk melewati guardrail.
- Insecure tool use: agen AI yang boleh eksekusi perintah tanpa sandbox adalah resep bencana.
Prinsip mitigasinya familiar: treat all external content as untrusted input. Konteks RAG, hasil pencarian web, isi email — semuanya setara user input berbahaya. Validasi, sanitasi, batasi hak akses tool, log semua aksi.
Deepfake dan Disinformasi AI
Selain serangan teknis langsung, ada ancaman yang lebih luas: kemampuan AI untuk membuat konten palsu yang semakin sulit dibedakan dari aslinya. Deepfake — video atau audio hasil sintesis — kini bisa menghasilkan wajah dan suara yang sangat meyakinkan hanya dengan beberapa detik sampel. Saya pernah mencoba tool face swap dan terkejut betapa mudahnya membuat video palsu yang tampak realistis.
Dampaknya melampaui sekadar prank. Deepfake telah digunakan untuk penipuan finansial (CEO palsu yang memerintahkan transfer dana), pelecehan seksual (menempelkan wajah korban ke konten pornografi), dan manipulasi politik (video kandidat yang mengatakan sesuatu yang tidak pernah diucapkan). Di Indonesia sendiri, hoaxes berupa audio WhatsApp palsu — yang mengklaim suara pejabat tertentu — sudah beredar luas, meskipun teknologinya belum sepenuhnya deepfake melainkan voice cloning sederhana.
Tantangan pertahanannya: deteksi deepfake masih berpacu dengan kemampuan pembuatnya. Model deteksi bisa dilatih, tetapi penjahat bisa membuat varian baru yang mengalahkan detektor. Solusi yang lebih menjanjikan adalah watermarking kriptografik pada konten AI-generated dan jurnalisme investigasi yang memverifikasi provenance rekaman. Sebagai developer, jika produk kita memfasilitasi distribusi konten video atau audio, penting untuk mempertimbangkan bagaimana mencegah penyalahgunaan di tingkat platform.
EU AI Act: Regulasi Berbasis Risiko
EU AI Act adalah hukum AI pertama yang komprehensif di dunia. Pendekatannya berbasis tingkat risiko: praktik AI tertentu dilarang (misalnya social scoring), sistem high-risk (misalnya AI di rekrutmen, kredit, pendidikan) menanggung kewajiban ketat — dokumentasi, pengujian, pengawasan manusia — sedangkan risiko terbatas hanya menuntut transparansi, misalnya memberi tahu user bahwa mereka berinteraksi dengan AI. Bagi developer Indonesia dampaknya tetap terasa kalau produk menyentuh pasar Eropa; pola dokumentasi dan risk assessment-nya layak diadopsi sebagai engineering practice baik.
| Tingkat risiko | Contoh | Konsekuensi |
|---|---|---|
| Dilarang | Social scoring oleh pemerintah | Praktik dilarang |
| High-risk | Screening CV, skoring kredit | Kewajiban dokumentasi & pengawasan |
| Terbatas | Chatbot | Transparansi ke user |
| Minimal | Filter spam, game | Bebas |
AI Safety Research: Alignment, RLHF, dan Constitutional AI
EU AI Act mengatur regulasi eksternal, tetapi ada riset di tingkat teknis yang sama kritisnya: bagaimana memastikan AI bertindak sesuai niat manusia. Ini dikenal sebagai alignment problem — gap antara apa yang kita maksudkan dan apa yang model optimalkan secara literal.
RLHF (Reinforcement Learning from Human Feedback) adalah pendekatan utama saat ini. Intinya: beri model beberapa opsi jawaban, biarkan manusia menilai mana yang lebih baik, latih reward model dari penilaian itu, lalu gunakan reward model untuk fine-tune LLM dengan PPO (Proximal Policy Optimization). Ini cara ChatGPT dan Claude menjadi lebih helpful — bukan sekadar melatih pada data lebih banyak, melainkan melatih berdasarkan preferensi manusia. Tapi RLHF punya keterbatasan: reward hacking (model menemukan cara curang memaksimalkan reward tanpa benar-benar memenuhi niat) dan skala — diperlukan ribuan labeler manusia untuk memberikan feedback yang representatif.
Constitutional AI (CAI), dipopulerkan oleh Anthropic, mengurangi ketergantungan pada feedback manusia langsung. Model diberi seperangkat prinsip (konstitusi) dan diminta mengevaluasi serta merevisi responsnya sendiri berdasarkan prinsip-prinsip itu. Prosesnya dua tahap: pertama, model menghasilkan respons tanpa batasan lalu mengkritik diri sendiri menggunakan konstitusi; kedua, model dilatih dari versi yang sudah direvisi. Keuntungannya: lebih scalable, lebih konsisten, dan prinsipnya bisa diaudit secara transparan. Kekurangannya: kualitas konstitusi sangat menentukan kualitas output, dan ada risiko over-correction — model menjadi terlalu defensif sehingga menolak permintaan yang sebenarnya sah.
Sebagai developer yang bekerja dengan LLM, memahami teknik-teknik ini membantu saya membuat keputusan yang lebih baik saat mengkonfigurasi safety guardrails untuk produk sendiri — bukan sekadar mengandalkan default settings dari API provider.
Tips Praktis untuk Developer
Setelah mempelajari kasus-kasus dan konsep di atas, saya menyusun daftar praktik yang bisa langsung diterapkan dalam proyek sehari-hari:
Fairness-Aware Machine Learning: Gunakan library seperti Fairlearn dari Microsoft atau AIF360 dari IBM. Library ini menyediakan metrik fairness (demographic parity, equalized odds) dan algoritma mitigasi (reweighing, adversarial debiasing) yang bisa diintegrasikan ke pipeline ML tanpa harus mengimplementasikan dari nol. Langkah pertama yang paling sederhana: selalu tambahkan evaluasi fairness per subkelompok di samping metrik akurasi umum.
Model Cards: Dokumentasikan model dengan model cards — format standar yang menjelaskan tujuan model, data yang digunakan, keterbatasan yang diketahui, dan kinerja per kelompok demografis. Google merintis format ini dan sekarang sudah menjadi best practice di banyak organisasi. Model card yang baik bukan sekadar dokumentasi — ia memaksa tim untuk berpikir tentang edge case dan dampak sosial sebelum model diproduksi.
Datasheets for Datasets: Mirip dengan model cards, tetapi untuk data. Dokumentasikan asal-usul data, proses pengumpulan, siapa yang memberi label, berapa banyak, dengan instruksi apa, dan keterbatasan yang diketahui. Google Again merilis framework “Datasheets for Datasets” yang menjadi acuan. Tanpa dokumentasi data, sangat sulit menelusuri asal bias saat masalah muncul di production.
| Pendekatan | Alat/Framework | Kapan Digunakan |
|---|---|---|
| Fairness-aware ML | Fairlearn, AIF360 | Saat training model klasifikasi/regresi |
| Model Cards | Google Model Card Toolkit | Saat model akan diproduksi |
| Dataset Documentation | Datasheets for Datasets | Saat menggunakan dataset pihak ketiga |
| Red Teaming | Manual + automated prompts | Saat model sudah jadi, sebelum deploy |
| Monitor & Audit | Custom dashboards, Evidently AI | Setelah model live di production |
Yang Berubah Setelah Memahami Etika AI
Jujur, sebelum menyelami topik ini saya termasuk tipe developer yang fokus pada akurasi model. Kalau F1 score bagus, saya anggap selesai. Sekarang pandangan itu berubah total. Beberapa hal yang kini saya lakukan berbeda:
Pertama, saya selalu menanyakan siapa yang dikecualikan dari dataset. Setiap kali menggunakan dataset publik — terutama yang dibangun dari data scraping — saya bertanya: populasi mana yang underrepresented? Jika data hanya dari Twitter Inggris, apa implikasinya untuk user Indonesia? Pertanyaan sederhana ini mengubah cara saya memilih dan membersihkan data.
Kedua, saya memperlakukan fairness evaluation sebagai bagian dari definition of done, bukan optional extras. Sama seperti saya tidak akan merilis fitur tanpa unit test, saya tidak akan merilis model tanpa evaluasi fairness per subkelompok. Ini memang memakan waktu tambahan, tetapi jauh lebih murah daripada memperbaiki bias setelah produk sampai di tangan user.
Ketiga, saya mulai mendokumentasikan model dan data secara rutin. Model card dan datasheet mungkin terdengar berat, tetapi dokumen singkat dua halaman pun sudah jauh lebih baik daripada tidak ada dokumentasi sama sekali. Ketika tim harus memutuskan apakah model lama masih aman untuk dipertahankan, dokumentasi itu menjadi penyelamat.
Penutup episode ini kesannya klise tapi nyata: model yang bias bukan cuma masalah moral, ia bug fungsional yang membuat produk gagal untuk segmen user tertentu. Mengukur fairness per kelompok harus jadi rutinitas seperti menulis unit test.
Komentar Terbaru