AI Risk Assessment Harus Dilakukan Sebelum Sistem Dipakai, Bukan Setelah Bermasalah

Ada pola yang terlalu sering terjadi ketika organisasi mengadopsi teknologi baru.

Vendor datang. Demo bagus. Pimpinan tertarik. Pilot jalan. User mulai pakai. Baru setelah ada masalah semua orang bertanya: “Risikonya apa?”

Untuk AI, urutan seperti ini harus dibalik.

Risk assessment bukan dokumen yang dibuat setelah sistem bermasalah. Ia seharusnya dilakukan sebelum AI menyentuh data nyata, sebelum memengaruhi keputusan, dan sebelum diberi akses ke tools yang bisa melakukan tindakan.

Ini terdengar seperti common sense.

Tapi di banyak organisasi, excitement terhadap capability sering lebih cepat daripada governance.

Apalagi kalau AI yang dicoba kelihatannya ringan.

“Cuma chatbot.” “Cuma bantu screening.” “Cuma bikin summary.”

Masalahnya, kata “cuma” sering menyembunyikan konsekuensi.

Chatbot bisa memberi informasi salah. Screening bisa menciptakan bias. Summary bisa menghilangkan detail penting. Agent bisa melakukan action yang tidak dimaksudkan.

Risk assessment membantu organisasi bertanya lebih awal: kalau sistem ini salah, apa yang sebenarnya bisa terjadi?

Mulai dari use case, bukan nama model

Kesalahan pertama adalah menilai risiko hanya dari teknologi.

“Model ini aman nggak?”

Pertanyaan itu terlalu luas.

Model yang sama bisa punya risiko sangat berbeda tergantung pemakaian.

Dipakai untuk brainstorming internal: risiko relatif rendah.

Dipakai untuk menyaring penerima layanan publik: risiko jauh lebih tinggi.

Dipakai untuk menyusun draft email: masih terbatas.

Dipakai untuk mengirim email otomatis ke ribuan orang: risiko meningkat.

Jadi risk assessment harus berangkat dari use case.

Apa tujuan sistem? Siapa yang terkena dampak? Data apa yang masuk? Action apa yang bisa dilakukan? Seberapa mudah error diperbaiki?

Tanpa memahami konteks, label “AI high risk” atau “low risk” menjadi kosong.

Risk assessment juga bukan tes satu kali

AI berubah.

Model update. Data berubah. Prompt berubah. Tool ditambah. User behavior berubah.

Sistem yang low risk saat pilot bisa menjadi high impact enam bulan kemudian.

Misalnya awalnya AI hanya memberi rekomendasi.

Kemudian tim merasa akurasinya bagus.

Akhirnya output dipakai otomatis tanpa review.

Risk profile sudah berubah.

Makanya assessment harus punya trigger untuk dilakukan ulang.

Ketika model diganti. Ketika scope meluas. Ketika data baru masuk. Ketika autonomy naik. Ketika ada incident. Ketika regulasi berubah.

NIST AI Risk Management Framework sendiri menempatkan risk management sepanjang lifecycle, dari desain sebelum deployment sampai penggunaan dan evaluasi setelah sistem berjalan.

Itu bukan aturan Indonesia.

Tapi prinsipnya sangat relevan.

Risiko AI tidak berhenti ketika project go live.

Pertanyaan pertama: apa dampak terburuk?

Banyak tim terlalu cepat membahas probability.

“Kayaknya kecil kemungkinan salah.”

Sebelum itu, lihat impact.

Kalau AI salah, apakah cuma bikin draft jelek?

Atau orang bisa kehilangan akses layanan?

Apakah error mudah terlihat?

Atau terlihat meyakinkan sehingga manusia tidak sadar?

Apakah bisa dibatalkan?

Atau action-nya irreversible?

Risk assessment yang bagus memisahkan probability dan impact.

Ada kejadian low probability tetapi high impact.

Contoh: agent salah menghapus data.

Mungkin jarang.

Tapi kalau terjadi, serius.

Ada juga high probability tetapi low impact.

Contoh: AI salah memilih gaya kalimat.

Sering, tapi mudah diperbaiki.

Prioritas kontrol berbeda.

Kedua: siapa yang terkena dampak?

Jangan hanya melihat organisasi.

AI bisa merugikan pihak luar.

Customer. Warga. Karyawan. Pelamar. Vendor. Anak. Kelompok rentan.

Sistem internal pun bisa punya external impact.

Misalnya AI membantu menentukan shortlist kandidat.

Pelamar tidak melihat AI.

Tapi outcome memengaruhi mereka.

Atau AI menentukan prioritas complaint.

Customer tidak tahu ada model di belakang layar.

Risk assessment harus memasukkan affected population.

Bukan hanya user yang mengklik aplikasi.

Ini penting untuk fairness.

Kalau model salah pada Bahasa Indonesia informal, kelompok tertentu mungkin terdampak lebih besar.

Kalau sistem membutuhkan smartphone terbaru, kelompok dengan perangkat lama bisa terpinggirkan.

Impact sosial sering tersembunyi di desain teknis.

Ketiga: data apa yang dipakai?

AI sangat bergantung pada data.

Jadi assessment harus mengecek: sumber data, kualitas, legal basis, sensitivity, retention, access.

Apakah datanya akurat? Apakah outdated? Apakah ada bias? Apakah boleh dipakai untuk tujuan ini?

Model bagus dengan data buruk tetap menghasilkan keputusan buruk.

Bahkan model tidak perlu “bias” secara teknis untuk menciptakan unfairness.

Cukup datanya tidak representatif.

Contoh sederhana.

Sistem speech-to-text dilatih terutama pada suara urban.

Kemudian dipakai layanan nasional.

Aksen tertentu bisa lebih sering salah.

Kalau transkrip hanya untuk catatan, dampaknya mungkin rendah.

Kalau transkrip menentukan apakah laporan diterima, risikonya naik.

Data assessment harus muncul sebelum deployment.

Bukan setelah complaint.

Keempat: seberapa besar autonomy?

AI yang hanya memberi suggestion berbeda dengan AI yang bertindak.

Level autonomy menentukan risk control.

Suggestion: manusia melihat dulu.

Semi-automatic: AI mengerjakan sebagian, manusia approve.

Automatic: AI menjalankan action sendiri.

Untuk high impact, autonomy harus dibenarkan.

Kenapa perlu otomatis? Apa manfaatnya? Apakah human review terlalu lambat? Apa rollback?

Jangan memberi autonomy hanya karena teknologinya bisa.

Capability bukan justification.

Mobil bisa melaju 200 km/jam.

Tidak berarti semua jalan harus mengizinkan itu.

Kelima: bagaimana kalau AI tidak tahu?

Ini salah satu test paling penting.

Sistem AI harus punya uncertainty handling.

Kalau confidence rendah, apa yang terjadi?

Model menjawab saja? Eskalasi? Minta data tambahan? Berhenti?

Risk assessment harus menguji unknown case.

Karena dunia nyata penuh hal yang tidak ada di training.

Dokumen aneh. Bahasa campur. Situasi baru. Rule baru.

Sistem berbahaya adalah sistem yang selalu merasa harus punya jawaban.

Kadang response paling aman: “tidak cukup informasi.”

Organisasi harus memberi ruang untuk itu.

Keenam: bagaimana manusia mengoreksi?

Human oversight bukan formalitas.

Assessment perlu mengecek apakah manusia benar-benar punya kontrol.

Apakah bisa override? Apakah punya informasi cukup? Apakah punya waktu? Apakah hasil override dilog?

Kalau manusia cuma klik approve karena volume terlalu tinggi, oversight palsu.

Ini harus dinilai sebelum production.

Hitung workload.

Misalnya AI menghasilkan 5.000 kasus sehari.

Kalau reviewer cuma dua orang, review meaningful mustahil.

Jangan menulis “human in the loop” di policy kalau kapasitasnya tidak ada.

Ketujuh: apakah ada exit strategy?

Sistem bisa gagal bukan hanya karena model.

Vendor bisa tutup. Harga naik. API down. Kontrak berakhir.

Risk assessment perlu lihat dependency.

Bisakah pindah vendor? Apakah data bisa diexport? Apakah ada format proprietary? Apakah model diganti tanpa notice?

Vendor lock-in adalah operational risk.

Untuk pemerintah, lebih serius karena layanan publik harus berlanjut.

Exit plan seharusnya sudah ada sebelum kontrak ditandatangani.

Bukan ketika hubungan dengan vendor bermasalah.

Risk assessment harus menghasilkan keputusan

Ini bagian yang sering gagal.

Tim mengisi tabel.

Risk: high. Likelihood: medium. Mitigation: monitor.

Selesai.

Itu bukan assessment yang useful.

Output harus actionable.

Contoh: risiko data sensitif terlalu tinggi.

Keputusan: gunakan deployment private atau hilangkan field tertentu.

Risiko false rejection tinggi.

Keputusan: mandatory human review.

Risiko vendor lock-in.

Keputusan: wajib data portability.

Risiko prompt injection.

Keputusan: batasi tool permission dan gunakan allowlist.

Assessment bukan laporan.

Ia alat desain.

Kalau tidak mengubah arsitektur atau keputusan, kemungkinan hanya compliance theatre.

Risk acceptance harus punya owner

Tidak semua risiko bisa dihilangkan.

Akhirnya organisasi perlu menerima sebagian risiko.

Pertanyaannya: siapa yang berhak menerima?

Engineer? Project manager? Direktur?

Untuk sistem high impact, acceptance harus berada di level yang punya authority dan accountability.

Jangan biarkan risk acceptance terjadi diam-diam melalui default.

Misalnya tim tahu model salah 3 persen tetapi tetap launch karena deadline.

Itu sebenarnya keputusan risiko.

Harus tercatat.

Siapa setuju. Kenapa. Mitigation apa.

Kalau incident terjadi, organisasi tahu reasoning-nya.

Risk assessment juga melindungi inovasi

Sebagian orang menganggap governance memperlambat.

Kalau dilakukan buruk, iya.

Kalau dilakukan benar, justru mempercepat.

Tim tahu batas.

Use case low risk bisa jalan cepat.

Use case high risk mendapat review lebih dalam.

Tanpa framework, semua project bisa diperlakukan sama.

Akibatnya dua kemungkinan.

Semua lambat. Atau semua liar.

Risk-based approach lebih efisien.

Tidak semua AI perlu komite besar.

Chatbot internal sederhana mungkin cukup checklist.

Sistem yang menentukan eligibility perlu assessment formal.

Proportionality adalah kuncinya.

Indonesia sedang bergerak ke arah tata kelola AI yang lebih kuat

Sepanjang 2026, pemerintah Indonesia berulang kali menekankan mitigasi risiko, keamanan data, transparansi, dan akuntabilitas dalam pembahasan tata kelola AI.

RPerpres Etika AI dan Peta Jalan AI Nasional juga telah selesai dibahas lintas kementerian dan menunggu penetapan.

Artinya, organisasi yang baru mulai memikirkan risk assessment setelah aturan final keluar sudah terlambat secara operasional.

Governance dasar bisa dibangun sekarang.

Tidak perlu menunggu kewajiban legal spesifik.

Karena risk assessment pada dasarnya bukan ritual compliance.

Itu cara memastikan teknologi tidak menciptakan kerugian yang sebenarnya bisa diprediksi sejak awal.

Kalau incident terjadi, pertanyaan pertama publik biasanya sederhana:

“Apakah risiko ini sebenarnya sudah diketahui?”

Kalau jawabannya iya tetapi tidak ada yang bertindak, masalahnya bukan AI.

Masalahnya governance.

Satu alat sederhana yang berguna adalah risk register. Tidak perlu software mahal. Untuk setiap use case, tulis risiko, pihak terdampak, likelihood, impact, kontrol, owner, residual risk, dan tanggal review. Dari sini tim bisa melihat apakah satu risiko benar-benar sudah ditangani atau hanya disebut dalam rapat.

Risk register juga membantu ketika beberapa sistem saling terhubung. Misalnya agent customer service membaca CRM, mengambil data pembayaran, lalu mengirim email. Risiko bukan hanya pada model. Ada dependency ke CRM, identity, API, dan email gateway. Satu kelemahan permission bisa lebih berbahaya daripada hallucination.

Lalu lakukan pre-mortem sebelum launch. Bayangkan enam bulan dari sekarang proyek masuk berita karena gagal. Apa kemungkinan headline-nya? Data bocor? Warga salah ditolak? Agent salah kirim? Vendor outage? Dari skenario itu, cek apakah kontrol sudah ada.

Teknik seperti ini membuat risk assessment lebih manusiawi. Orang lebih mudah membayangkan incident konkret daripada membaca tabel abstrak.

Terakhir, jangan hanya mengundang engineer. Legal melihat kewajiban, security melihat attack surface, operations tahu workflow nyata, dan user frontline tahu exception yang tidak ada di slide. Risk assessment AI yang hanya dilakukan tim AI akan kehilangan sebagian besar risiko organisasi.

Sistem hidup di organisasi, bukan di benchmark. Karena itu penilaiannya juga harus lintas fungsi.

Karena itu risk assessment harus muncul sebelum sistem menyentuh manusia.

Bukan setelah semua orang sibuk menjelaskan kenapa sistemnya gagal.