Ada satu ritual yang sangat familiar di organisasi besar.
Audit datang.
Dokumen disiapkan. Checklist diisi. Policy ditandatangani. Screenshot dikumpulkan. Semua terlihat rapi.
Lalu auditor pulang.
Enam bulan kemudian, cara sistem dipakai di lapangan sudah berbeda.
Untuk AI pemerintah, model audit seperti ini berbahaya.
Bukan karena dokumentasi tidak penting.
Dokumentasi justru wajib.
Masalahnya, AI adalah sistem yang perilakunya bisa berubah karena model, data, prompt, tools, vendor, konfigurasi, dan konteks penggunaan berubah.
Kalau audit hanya memeriksa apakah ada policy, kita belum benar-benar mengaudit AI.
Kita mengaudit folder.
Audit harus melihat sistem yang hidup.
Pertanyaan paling dasar bukan: “Apakah instansi punya pedoman AI?”
Tapi: “Apakah sistem yang dipakai hari ini benar-benar bekerja sesuai pedoman itu?”
Beda besar.
Dokumen bisa bilang keputusan high risk wajib human review.
Audit operasional perlu mengecek: apakah review benar-benar dilakukan, berapa lama reviewer membaca, berapa persen override, dan apakah manusia punya informasi cukup.
Kalau semua kasus otomatis approve karena workload terlalu tinggi, compliance di atas kertas tidak berarti apa-apa.
Audit AI harus melihat production behavior
Model yang diuji di lab belum tentu sama performanya di lapangan.
Data real lebih berantakan. Bahasa lebih variatif. User mencoba hal aneh. Integrasi gagal. Network timeout. Dokumen scan buruk.
Jadi audit perlu sampling kasus nyata.
Bukan data pribadi dibuka sembarangan.
Tetap harus ada prosedur keamanan.
Tapi auditor perlu evidence dari production.
Misalnya: berapa error rate, berapa failed tool call, berapa kasus eskalasi, berapa override manusia, berapa complaint, berapa incident.
Tanpa data operasional, audit hanya menilai desain.
Padahal risiko terbesar sering muncul di penggunaan nyata.
NIST AI Risk Management Framework juga menekankan monitoring produksi, evaluasi berkala, tracking risiko, feedback pengguna, dan incident response sebagai bagian lifecycle.
Sekali lagi, itu bukan kewajiban hukum Indonesia.
Tapi kerangka tersebut menunjukkan standar berpikir yang cukup matang: AI risk management harus ongoing.
Bukan sekali lulus audit lalu selesai.
Model version harus masuk scope
Bayangin audit dilakukan Januari.
Model versi 3.2.
Bulan Maret vendor update ke 3.5.
Bulan April instansi mengubah system prompt.
Bulan Mei retrieval source diganti.
Secara nama produknya tetap sama.
Secara perilaku, sistem bisa berbeda.
Kalau audit report hanya menulis: “menggunakan Sistem AI X,” itu terlalu dangkal.
Harus ada versioning.
Model version. Prompt version. Knowledge base version. Tool configuration. Data source. Threshold. Policy.
Perubahan material harus punya change log.
Kalau terjadi incident, instansi bisa tahu konfigurasi apa yang aktif saat itu.
Ini basic forensic capability.
Tanpa itu, investigasi berubah jadi tebak-tebakan.
Audit harus menguji failure, bukan hanya success
Vendor biasanya demo best case.
Pertanyaan audit seharusnya mencari worst case.
Apa yang terjadi kalau input salah? Kalau data source unavailable? Kalau user memasukkan prompt injection? Kalau model hallucinate? Kalau bahasa daerah tidak dipahami? Kalau seseorang mengunggah dokumen sensitif? Kalau API timeout? Kalau sistem confidence rendah?
Audit yang bagus sengaja mencoba membuat sistem gagal.
Bukan untuk menjatuhkan vendor.
Untuk mengetahui radius kerusakan.
Cybersecurity sudah punya mindset ini melalui penetration testing.
AI juga butuh red teaming.
Bedanya, failure AI tidak selalu berupa kebocoran.
Bisa diskriminasi. Salah rekomendasi. Fakta palsu. Overautomation. Keputusan tanpa dasar.
Scope audit harus lebih luas.
Fairness tidak cukup satu angka
Misalnya vendor bilang model punya accuracy 95 persen.
Bagus.
Tapi siapa 5 persen yang salah?
Kalau error tersebar random, mungkin manageable.
Kalau sebagian besar terjadi pada satu kelompok, serious.
Misalnya OCR lebih sering gagal untuk dokumen format tertentu. Speech recognition lebih buruk pada aksen tertentu. Classifier salah membaca bahasa campuran. Fraud model lebih sering menandai wilayah tertentu.
Audit perlu slice performance.
Berdasarkan kategori kasus. Bahasa. Wilayah. Jenis dokumen. Kelompok pengguna yang relevan.
Tidak semua atribut boleh atau perlu dipakai.
Privacy tetap penting.
Tapi prinsipnya: average bisa menyembunyikan harm.
Sistem publik harus diuji pada populasi yang benar-benar dilayani.
Bukan hanya dataset ideal.
Audit vendor harus sampai ke dependency
Banyak sistem AI pemerintah sebenarnya rantai panjang.
Instansi membeli aplikasi dari vendor lokal.
Vendor lokal memakai cloud global.
Cloud memakai foundation model.
Model memakai third-party tool.
Data mungkin melewati beberapa service.
Kalau audit cuma melihat vendor utama, supply chain risk hilang.
Pertanyaan perlu turun: model provider siapa, data region mana, subprocessor siapa, logging di mana, retention berapa lama, apakah data dipakai training, bagaimana credential dikelola.
Tidak semua detail harus publik.
Tapi instansi harus tahu.
Kalau vendor sendiri tidak tahu arsitektur dependencynya, itu red flag.
Pemerintah tidak boleh membeli black box yang tidak bisa dipetakan.
Audit harus mengecek hak pengguna
Kualitas AI pemerintah bukan cuma teknis.
Kalau warga terdampak, apakah ada mekanisme koreksi?
Misalnya sistem salah mengklasifikasikan permohonan.
Apakah warga bisa komplain? Apakah komplain sampai ke tim yang bisa memperbaiki? Berapa lama? Apakah keputusan lama dievaluasi ulang? Apakah root cause masuk evaluasi model?
Kalau mekanisme pengaduan terpisah total dari tim AI, feedback hilang.
Complaint sebenarnya valuable training signal.
Bukan berarti langsung dipakai melatih model.
Tapi dipakai untuk melihat failure.
Audit perlu mengecek feedback loop.
Masalah yang sama muncul berulang atau tidak?
Kalau iya, governance gagal belajar.
Audit juga harus menghitung manusia
Human in the loop sering ditulis sebagai kontrol.
Tapi manusia sendiri punya failure mode.
Capek. Undertrained. Overtrust. Deadline. Target volume.
Jadi audit harus melihat human factors.
Berapa kasus per reviewer? Apakah reviewer tahu limitation model? Apakah bisa override? Apakah perlu menulis alasan? Apakah override dianalisis? Apakah ada tekanan untuk mengikuti AI?
Ini penting.
Kalau sistem AI akurat 90 persen tetapi reviewer bagus menangkap sebagian besar error, outcome bisa kuat.
Kalau reviewer hanya stempel, outcome sama dengan automation penuh.
Human oversight bukan kotak checklist.
Ia adalah desain kerja.
Audit independen lebih valuable untuk sistem high risk
Self-assessment berguna.
Tim internal paling tahu sistem.
Tapi ada conflict of interest.
Tim yang membangun sistem mungkin terlalu optimistis.
Manager punya target deployment. Vendor ingin kontrak lanjut. Unit bisnis ingin KPI tercapai.
Untuk penggunaan high impact, independent assessment memberi nilai.
Bisa unit audit internal yang terpisah. Bisa lembaga pemeriksa. Bisa auditor eksternal dengan kompetensi teknis.
Yang penting independensinya cukup.
Auditor juga harus punya skill AI.
Kalau tidak, mereka hanya akan membaca dokumen vendor.
Ini tantangan Indonesia ke depan.
Kita butuh auditor yang ngerti hukum sekaligus teknologi.
Bukan harus satu orang.
Tim multidisciplinary.
Legal. Data science. Security. Domain expert. Public policy.
AI governance bukan pekerjaan satu profesi.
Continuous audit lebih masuk akal daripada tahunan
AI berubah lebih cepat daripada siklus audit tahunan.
Bukan berarti audit formal harus tiap minggu.
Tapi monitoring harus kontinu.
KPI tertentu bisa otomatis.
Error rate. Latency. Override. Incident. Data drift. Model change. Complaint.
Kalau metric melewati threshold, review dipicu.
Ini risk-based auditing.
Lebih efisien daripada memeriksa semuanya dengan frekuensi sama.
Low-risk chatbot internal tidak butuh intensitas seperti sistem yang memengaruhi bantuan publik.
Audit resources juga terbatas.
Prioritaskan berdasarkan impact.
Audit log harus aman dari manipulasi
Kalau sistem bisa mengubah log sendiri, evidence tidak kuat.
Untuk high-impact AI, log harus punya integrity control.
Siapa melakukan action. Kapan. Model version. Input category. Output. Human approval.
Tentu data personal harus diminimalkan.
Jangan log semua isi percakapan tanpa alasan.
Auditability dan privacy harus balance.
Pseudonymization. Access control. Retention schedule.
Yang dicari bukan surveillance total.
Yang dicari kemampuan merekonstruksi keputusan.
Audit tanpa remediation hanya menghasilkan report
Ini masalah klasik.
Temuan audit banyak.
Rekomendasi dibuat.
Tidak ada owner. Tidak ada deadline. Tidak ada follow-up.
Selesai.
Untuk AI, remediation harus operasional.
Temuan: model salah pada kategori dokumen tertentu.
Action: turunkan autonomy. buat human review. perbaiki data. retest.
Temuan: vendor tidak memberi model version.
Action: ubah kontrak atau kurangi dependency.
Temuan: complaint tidak masuk monitoring.
Action: integrasikan kanal.
Audit harus menghasilkan perubahan.
Kalau setiap tahun finding sama, audit menjadi ritual.
Publik tidak selalu perlu melihat semua detail, tapi perlu trust signal
Beberapa hasil audit bisa sensitif.
Ada security detail. Data pribadi. Confidential vendor information.
Tidak semuanya harus dipublikasikan.
Tapi untuk sistem yang memengaruhi publik, transparency summary berguna.
Misalnya: sistem sudah dievaluasi, scope penggunaan, kategori risiko, tanggal review, temuan utama, perbaikan, mekanisme pengaduan.
Public trust tidak butuh source code.
Butuh evidence bahwa sistem tidak berjalan tanpa pengawasan.
Audit AI pemerintah pada akhirnya bukan soal menghasilkan sertifikat “aman”.
Tidak ada sistem yang aman selamanya.
Audit adalah mekanisme untuk terus bertanya: apakah penggunaan masih sesuai tujuan, apakah risikonya berubah, apakah kontrol bekerja, dan apakah publik tetap terlindungi.
Kalau audit berhenti di dokumen, AI bisa terlihat compliant sementara realitasnya sudah jauh berbeda.
Pemerintah butuh sesuatu yang lebih sulit.
Ada satu area lain yang sering lolos: audit terhadap klaim manfaat. Pemerintah bukan hanya perlu membuktikan sistem aman, tetapi juga bahwa AI memang memberi nilai publik yang dijanjikan. Kalau proyek disebut memangkas waktu proses 40 persen, auditor perlu tahu baseline-nya apa, periode pengukurannya kapan, dan apakah percepatan itu datang dengan error baru. Kalau sistem disebut mengurangi beban pegawai, cek apakah pegawai benar-benar punya waktu lebih banyak atau justru mendapat pekerjaan tambahan untuk memperbaiki output model.
Ini penting karena proyek AI bisa lolos dari evaluasi risiko tetapi tetap gagal secara ekonomi. Pemerintah mengeluarkan anggaran, data dipindahkan, pegawai dilatih, vendor dibayar, tetapi layanan publik tidak membaik. Audit yang matang harus berani merekomendasikan penghentian use case yang tidak memberi manfaat cukup, bukan hanya meminta kontrol tambahan.
Audit juga perlu mengecek ketergantungan pada benchmark vendor. Angka akurasi yang diuji pada dataset demo tidak boleh diperlakukan sama dengan performa pada data Indonesia. Untuk sistem yang membaca dokumen lokal, uji dengan dokumen lokal. Untuk chatbot Bahasa Indonesia, gunakan variasi Bahasa Indonesia yang nyata. Untuk sistem di daerah, jangan hanya menguji data Jakarta. Evidence harus mencerminkan lingkungan deployment.
Dengan cara itu, audit tidak cuma bertanya apakah organisasi mengikuti prosedur. Audit ikut memastikan bahwa keputusan untuk terus menggunakan AI masih rasional.
Bukan paperwork.
Operational truth.
Bacaan terkait
Artikel ini berada dalam AI Governance dan mengikuti metodologi editorial Undercover.id. Format terkait tersedia di Reports dan analisis mendalam.