Keterjelasan dan Auditabilitas AI di Bidang Keuangan

Oleh Jane Ha · Diperbarui 11 Oktober 2026

Keterjelasan (explainability) dan auditabilitas pada AI keuangan adalah dua janji yang berbeda: Anda dapat menyampaikan mengapa sistem menghasilkan suatu hasil tertentu (keterjelasan), dan Anda dapat membuktikan sesudahnya apa yang dilakukan sistem, dengan input apa, pada versi mana, dan siapa yang meninjaunya (auditabilitas). Regulator, auditor, dan pelanggan masing-masing bertumpu pada separuh yang berbeda. Pemohon kredit menginginkan alasan penolakan. Auditor menginginkan jejak bukti. Tim risiko model menginginkan keduanya, ditambah bukti bahwa pihak independen sudah menantang model tersebut.

Panduan ini ditujukan bagi CFO, controller (kepala akuntansi), kepala risiko, dan manajer keuangan yang sedang menerapkan AI pada pekerjaan kredit, penipuan, prakiraan, tutup buku, atau pelaporan. Jika Anda menginginkan definisi teknik itu sendiri dalam bahasa sederhana, bacalah Apa itu AI yang dapat dijelaskan?. Artikel ini membahas bagian yang khas keuangan: apa yang harus dijelaskan, kepada siapa, dan apa yang perlu Anda simpan sebagai arsip.

Fakta Utama

• Regulation B mewajibkan pernyataan alasan atas tindakan kredit yang merugikan "harus spesifik dan menyebutkan alasan utama", dan pernyataan yang hanya berdasar standar internal atau ambang skor kredit yang tidak terpenuhi belum memadai (12 CFR 1002.9).
• Panduan risiko model antarlembaga April 2026, SR 26-2, menggantikan SR 11-7 dan diperkirakan paling relevan bagi organisasi perbankan dengan total aset di atas $30 miliar (Federal Reserve).
• Panduan itu menempatkan model AI generatif dan agentik di luar cakupannya, sementara prinsip-prinsipnya berlaku untuk model statistik tradisional dan AI non-generatif serta non-agentik (lampiran SR 26-2).
• EU AI Act mengelompokkan sistem AI yang dimaksudkan untuk menilai kelayakan kredit orang perseorangan atau menetapkan skor kreditnya sebagai berisiko tinggi, dan mewajibkan sistem semacam itu secara teknis memungkinkan pencatatan peristiwa (log) otomatis sepanjang masa pakainya (Lampiran III, Pasal 12).
• NIST memisahkan kedua gagasan itu: keterjelasan adalah representasi mekanisme yang mendasari operasi sebuah sistem, sedangkan interpretabilitas adalah makna keluarannya dalam konteks tujuan perancangannya (NIST AI RMF 1.0).

Mengapa Keuangan Menerapkan Standar yang Lebih Tinggi untuk AI

Sebagian besar fungsi bisnis bisa hidup dengan model yang berfungsi tetapi tidak bisa menjelaskan alasannya. Keuangan pada umumnya tidak bisa, karena tiga alasan.

Keputusan membawa kewajiban hukum. Ketika pemberi pinjaman menolak pemohon, aturan di AS menuntut alasan yang spesifik. Alasan itu harus mencerminkan apa yang benar-benar mendorong keputusan, bukan label generik.

Angka mengalir ke laporan yang diandalkan banyak pihak. Jika sebuah model menetapkan cadangan, menyusun penjelasan analisis fluktuasi (flux), atau mencocokkan item buku besar, seseorang harus bisa menunjukkan kepada auditor bagaimana angka itu muncul. Sisi pengendaliannya dibahas di AI dan pengendalian internal. Artikel ini membahas lapisan di bawahnya: dokumentasi dan catatan yang membuat sebuah kontrol dapat diuji.

Kesalahan mahal dan lambat ditemukan. Prakiraan yang menyimpang atau model skoring yang bias dapat berjalan berbulan-bulan sebelum ada yang menyadarinya, dan satu-satunya cara merekonstruksi apa yang terjadi adalah dengan menyimpan catatannya.

Apa yang Sebenarnya Diharapkan Regulator dan Auditor

Harapan berbeda menurut yurisdiksi dan kasus penggunaan, jadi sebaiknya dipisahkan.

Keputusan kredit (AS). Regulation B, yang menerapkan Equal Credit Opportunity Act, mewajibkan kreditur menyampaikan kepada pemohon yang ditolak alasan utamanya dalam istilah yang spesifik. Aturan ini memberi kreditur waktu 30 hari setelah menerima permohonan lengkap untuk memberi tahu pemohon tentang tindakan yang diambil (12 CFR 1002.9). Konsekuensi praktisnya bagi AI: jika model Anda tidak dapat menghasilkan alasan yang bisa Anda pertanggungjawabkan, Anda punya masalah kepatuhan, seakurat apa pun modelnya. Alat penjelasan pascakejadian mengaproksimasi model alih-alih mereproduksinya, sehingga tim harus bisa memeriksa bahwa aproksimasi itu setia.

Manajemen risiko model (bank di AS). Panduan tahun 2011, SR 11-7, telah digantikan oleh SR 26-2, yang menerapkan pendekatan berbasis risiko dan menyatakan bahwa tantangan yang efektif (effective challenge) adalah analisis kritis oleh pakar objektif, dilakukan oleh orang dengan keahlian yang tepat, independensi yang cukup, dan kedudukan untuk mewujudkan perubahan. Panduan itu juga menyatakan bahwa inventaris model yang efektif memuat informasi yang cukup untuk memahami risiko model pada tingkat individual dan agregat, dan bahwa dokumentasi yang memadai mendukung manajemen risiko model yang efektif (SR 26-2). Panduan itu mengecualikan AI generatif dan agentik dari cakupannya, tetapi juga menyatakan bahwa praktik tata kelola milik bank sendiri sebaiknya memandu kontrol untuk alat yang tidak tercakup. Jika Anda lembaga yang lebih kecil atau tim keuangan korporat, perlakukan panduan ini sebagai templat yang teruji, bukan buku aturan.

Model dari vendor. Panduan yang sama menyatakan bahwa praktik yang baik mencakup memahami kesehatan konseptual, desain, data pengembangan, dan kinerja model vendor, serta memantau hasilnya, bahkan ketika vendor menahan kode atau data (SR 26-2). "Vendor bilang akurat" bukanlah dokumentasi.

Uni Eropa. Penilaian kredit orang perseorangan merupakan penggunaan berisiko tinggi menurut Lampiran III AI Act, dan sistem berisiko tinggi secara teknis harus memungkinkan pencatatan log otomatis sepanjang masa pakainya (Lampiran III, Pasal 12). Jadwal Act tersebut telah diubah, dan teks konsolidasi saat ini mencantumkan 2 Desember 2027 sebagai tanggal penerapan untuk sistem Lampiran III (Pasal 12). Tim hukum sebaiknya memastikan statusnya untuk situasi masing-masing, tetapi pelajaran rekayasanya sama saja: bangun pencatatan log sekarang, karena memasangnya belakangan lebih sulit.

Auditor pelaporan keuangan. Auditor eksternal tidak meminta bagian dalam model secara abstrak. Mereka ingin tahu bahwa langkah AI adalah bagian yang dikenal dan dimiliki dari proses yang terdokumentasi, dengan bukti bahwa seseorang memeriksa keluarannya.

Keterjelasan menurut Fungsi: Apa Arti "Terjelaskan" dalam Praktik

"Dapat dijelaskan" bukan satu hal tunggal. Penjelasan yang tepat bergantung pada siapa yang bertanya dan apa taruhannya.

Pola di seluruh tabel sama. Penjelasan menyangkut pendorong dan dasar, sedangkan auditabilitas menyangkut catatan. Sebuah model bisa memiliki yang satu tanpa yang lain: penilai berbasis aturan yang sederhana mudah dijelaskan, tetapi tetap tidak berguna bagi auditor jika tidak mencatat apa pun.

Perangkat Penjelasan dan Keterbatasannya

Dua teknik terus muncul untuk model yang kompleks. SHAP "memberikan nilai kepentingan pada setiap fitur untuk suatu prediksi tertentu" (Lundberg dan Lee). LIME menjelaskan satu prediksi individual dengan memasang model sederhana yang dapat diinterpretasi di sekitar lingkungan prediksi itu, dengan memperlakukan model di baliknya sebagai kotak hitam (Ribeiro et al.).

Keduanya berguna untuk pertanyaan "mengapa hasil ini". Tidak satu pun menggantikan tata kelola, karena tiga alasan:

• Keduanya menjelaskan prediksi, bukan kelayakan model. Penjelasan yang rapi atas skor yang bias tetaplah skor yang bias.
• Keduanya aproksimasi. Perlakukan keluarannya sebagai bukti yang harus divalidasi, bukan sebagai penalaran sebenarnya dari model.
• Keduanya tidak menghasilkan alasan siap-pelanggan dengan sendirinya. Seseorang harus memetakan kontribusi faktor ke alasan utama yang dapat dinyatakan secara akurat dalam sebuah pemberitahuan.

Untuk keputusan berisiko tinggi, ada baiknya menguji apakah model yang lebih sederhana hanya mengorbankan sedikit akurasi, karena model yang dapat Anda periksa langsung lebih mudah dipertahankan daripada model yang harus Anda aproksimasi.

Dokumentasi yang Andal: Kartu Model dan Inventaris

Kartu model (model card) adalah dokumen singkat yang menyertai sebuah model. Usulan aslinya menggambarkan kartu sebagai dokumentasi kinerja yang diuji pada berbagai kondisi, konteks penggunaan yang dimaksudkan, dan cara evaluasi dijalankan, agar pengguna tahu di mana model bekerja dan di mana tidak (Mitchell et al.). Para penulis berfokus pada visi dan bahasa, dan menyatakan bahwa gagasan ini berlaku untuk setiap model yang dilatih. Bagi tim keuangan, gagasan itu dapat langsung diterapkan. Lihat kartu model AI untuk format umumnya.

Versi keuangan dapat mencakup:

1. Tujuan dan pemilik. Keputusan atau proses apa yang didukung, dan pemilik bisnis yang ditunjuk.
2. Penggunaan yang dimaksudkan dan di luar cakupan. Misalnya, "menilai permohonan konsumen tanpa agunan; tidak untuk pinjaman usaha kecil."
3. Data. Sumber pelatihan, rentang waktu, celah yang diketahui, dan pengecualian yang Anda terapkan.
4. Metode dalam satu paragraf. Jenis model, fitur utama, dan bagaimana keluaran diubah menjadi keputusan.
5. Kinerja. Ukuran akurasi, toleransi, hasil per segmen, dan backtest (uji historis) terhadap realisasi.
6. Metode penjelasan. Bagaimana alasan atau pendorong dihasilkan, dan seberapa setia keduanya terbukti.
7. Batasan dan mode kegagalan yang diketahui. Di mana ia lemah, dan apa yang memicu penanganan manual.
8. Kontrol. Peninjau, ambang batas, cadangan jika sistem mati, dan riwayat perubahan.
9. Validasi. Siapa yang menantangnya, kapan, dan apa temuan mereka.

Padukan kartu dengan inventaris: satu daftar setiap model dan alat AI yang dipakai, lengkap dengan pemilik, tujuan, tingkat, dan lokasi kartu. SR 26-2 sendiri mencatat bahwa inventaris yang efektif memuat informasi yang cukup untuk memahami risiko model, dan itulah ujian yang perlu diterapkan pada inventaris Anda. Untuk alat dari vendor, kartunya akan sebagian kosong. Tuliskan hal itu alih-alih membiarkannya kosong, lalu putuskan apakah celahnya dapat diterima untuk tingkat risikonya.

Jejak Audit: Catatan tentang Apa yang Sebenarnya Terjadi

Dokumentasi menyatakan apa yang seharusnya dilakukan sebuah sistem. Jejak audit menunjukkan apa yang dilakukannya pada hari tertentu. Prinsip pencatatan log dalam aturan Uni Eropa adalah standar umum yang baik: catat peristiwa sepanjang masa pakai sistem, dengan cara yang mendukung pemantauan dan penyelidikan (Pasal 12). Untuk pembahasan lebih dalam tentang jejak ketika AI mengambil tindakan di dalam sistem, lihat jejak audit untuk tindakan AI.

Jejak audit keuangan yang berguna mencatat, untuk setiap item material yang dipengaruhi AI:

• Input: data atau dokumen yang diterima sistem, atau penunjuk ke sana
• Versi: model, prompt atau kumpulan aturan, dan konfigurasi yang berlaku saat itu
• Keluaran: skor, entri, penanda, atau teks yang dihasilkan
• Penjelasan: pendorong atau alasan yang dihasilkan bersamanya
• Tindakan manusia: siapa yang meninjau, apa yang diubah atau dibatalkan, dan kapan
• Hasil lanjutan: keputusan, posting, atau pemberitahuan yang mengikutinya

Masa retensi harus sesuai dengan catatan yang didukungnya. Tanyakan kepada tim arsip dan hukum Anda berapa lama berkas kredit, dukungan jurnal, dan kertas kerja harus disimpan, lalu pastikan log AI tidak dihapus lebih cepat. Penanganan data untuk log ini adalah topik tersendiri, dibahas di keamanan data keuangan untuk AI.

Cara Membangun Keterjelasan dan Auditabilitas, Langkah demi Langkah

1. Inventarisasi setiap model dan alat AI di keuangan. Sertakan fitur vendor yang diaktifkan di dalam sistem yang sudah ada. Anda tidak bisa mendokumentasikan apa yang belum Anda temukan.

   

2. Kelompokkan ke dalam tingkat menurut konsekuensi. Model yang menentukan hasil kredit pelanggan atau sebuah cadangan masuk ke tingkat yang lebih ketat daripada alat yang menyusun ringkasan internal.

3. Tetapkan persyaratan penjelasan per tingkat. Sebutkan siapa yang harus bisa mendapatkan penjelasan, seberapa cepat, dan dalam bentuk apa (pemberitahuan pelanggan, tampilan analis, kertas kerja auditor).

4. Pilih model dengan mempertimbangkan persyaratan itu. Untuk penggunaan tingkat teratas, uji apakah model yang lebih transparan hampir seakurat model kotak hitam sebelum menerima yang terakhir.

5. Tulis kartu model sebelum go-live. Jadikan persetujuan peluncuran bergantung pada kartu yang lengkap dan pemilik yang ditunjuk.

6. Dapatkan tantangan independen. Seseorang dengan keahlian dan independensi yang tepat meninjau model beserta metode penjelasannya, dan dapat menuntut perubahan.

7. Aktifkan pencatatan log sejak hari pertama. Catat input, versi, keluaran, penjelasan, dan tindakan manusia. Uji bahwa Anda dapat merekonstruksi satu keputusan dari ujung ke ujung berdasarkan log.

8. Jalankan latihan rekonstruksi. Pilih sepuluh keputusan lama secara acak dan minta orang di luar tim pembangun menjelaskan masing-masing hanya dari catatan. Celah akan cepat terlihat.

9. Pantau dan dokumentasikan ulang. Lacak akurasi, drift model, dan tingkat pembatalan. Perbarui kartu dan tantang kembali ketika model, data, atau penggunaannya berubah. Lihat kontrol akurasi AI di keuangan untuk gagasan pemantauan.

Kesalahan Umum

• Menjelaskan model tetapi bukan keputusannya. Kepentingan fitur secara global tidak menjawab mengapa pemohon ini ditolak atau mengapa entri ini ditandai.
• Alasan yang generik. Mengirim alasan daftar periksa terdekat padahal pendorong sebenarnya hal lain gagal memenuhi uji kespesifikan dalam Regulation B.
• Memercayai alat penjelasan secara membabi buta. Metode pascakejadian hanya mengaproksimasi perilaku. Ujilah terhadap kasus yang diketahui.
• Kartu model sebagai PDF sekali jadi. Kartu yang tidak berubah ketika modelnya berubah menjadi catatan palsu.
• Log tanpa versi. Mengetahui apa keluarannya tidak berguna jika Anda tidak bisa memastikan model atau prompt mana yang menghasilkannya.
• Ketidakterbukaan vendor diterima begitu saja. "Proprietari" adalah alasan untuk memantau hasil lebih ketat, bukan untuk melewatkan dokumentasi.
• Tinjauan tanpa bukti. Peninjau yang menyetujui tetapi tidak meninggalkan catatan tentang apa yang diperiksanya tidak memberi auditor apa pun untuk diuji.
• Keterjelasan dibangun setelah peluncuran. Memasang log dan dokumentasi belakangan jauh lebih mahal daripada merancangnya sejak awal.

Apa yang Perlu Diukur

• Cakupan: porsi model dan alat AI yang memiliki pemilik, tingkat, dan kartu terkini
• Tingkat rekonstruksi: porsi keputusan sampel yang dapat dijelaskan sepenuhnya hanya dari log
• Kualitas penjelasan: seberapa sering peninjau atau validator menolak alasan yang dihasilkan karena tidak akurat atau terlalu samar
• Tingkat pembatalan: seberapa sering manusia mengubah keluaran, dan mengapa
• Kesegaran: waktu sejak setiap kartu dan validasi terakhir diperbarui, dibandingkan dengan log perubahan
• Penutupan temuan: waktu untuk menyelesaikan temuan validasi dan audit

Langkah Selanjutnya

Mulailah dengan inventaris dan pengelompokan tingkat, lalu tulis kartu untuk tingkat teratas Anda dan jalankan satu latihan rekonstruksi. Jika Anda masih memetakan di mana AI cocok, AI di bidang keuangan dan akuntansi memberikan gambaran yang lebih luas.