Agent AI untuk klaim biaya: Otomasi yang tetap taat kebijakan
Klaim biaya karyawan tampak seperti pekerjaan administrasi sederhana: unggah bukti, isi nominal, pilih kategori, lalu tunggu persetujuan. Dalam praktiknya, tim keuangan harus membaca struk dengan format beragam, memeriksa kebijakan perjalanan, mencocokkan transaksi kartu, menandai duplikasi, dan mengejar informasi yang belum lengkap. Ketika volume bertambah, antrean makin panjang sementara pemeriksa menghabiskan waktu pada transaksi rutin yang seharusnya mudah.
Agent AI dapat membantu mengelola alur tersebut, tetapi bukan berarti ia boleh membayar atau menolak klaim sesuka hati. Desain yang baik membatasi agen pada tugas yang dapat diverifikasi, memberi akses hanya pada data yang diperlukan, dan memisahkan rekomendasi dari keputusan yang berdampak pada karyawan. Artikel ini membahas rancangan praktis yang menjadikan kebijakan perusahaan sebagai kendali, bukan sekadar instruksi dalam prompt.
Pembahasan berikut adalah usulan desain, bukan laporan sistem yang sudah diterapkan atau bukti penghematan. Contoh nominal dan kejadian bersifat ilustratif. Dalam Building effective agents, Anthropic membedakan alur yang diatur kode dari agen yang menentukan langkahnya sendiri, serta menyarankan solusi paling sederhana yang memadai. Artikel tersebut dipakai untuk prinsip desain, bukan rekomendasi produk atau API terkini.
Peta proses sebelum memilih otomasi
Mulailah dengan menggambar proses saat ini, bukan langsung memilih model atau platform. Catat siapa mengirim klaim, sistem mana yang menjadi sumber data resmi, pemeriksaan yang dilakukan, siapa yang menyetujui, dan bagaimana pembayaran dijalankan. Pisahkan pekerjaan membaca dokumen dari keputusan kebijakan. Agen dapat mengekstrak tanggal, merchant, mata uang, pajak, dan nilai total; aturan deterministik atau sistem keuangan kemudian memvalidasi format serta batas angka.
Buat inventaris pengecualian. Misalnya, struk buram, mata uang tidak dikenal, transaksi tanpa bukti, klaim setelah tenggat, atau pengeluaran yang melebihi plafon. Kasus semacam ini harus diarahkan ke manusia, bukan dipaksa menjadi kategori yang tampak meyakinkan. Pengukuran dasar juga penting: waktu pemrosesan median, rasio klaim yang perlu koreksi, jumlah duplikasi yang ditemukan, serta lama antrean persetujuan. Tanpa baseline, tim tidak dapat membuktikan bahwa otomasi memperbaiki proses.
Arsitektur: ekstraksi, pemeriksaan, dan tindakan terpisah
Alur yang aman dapat dibagi menjadi beberapa tahap. Pertama, layanan penerimaan menyimpan berkas dan memberi setiap klaim ID unik. Kedua, komponen OCR atau model visi mengambil kandidat informasi dari struk, disertai lokasi atau cuplikan bukti yang mendukung setiap nilai. Ketiga, agen menghubungkan klaim dengan kebijakan yang relevan dan transaksi kartu perusahaan bila tersedia. Keempat, mesin aturan memeriksa batas nominal, kategori yang diperbolehkan, tanggal, kelengkapan bukti, serta kemungkinan klaim ganda.
Jangan mengandalkan jawaban bebas model sebagai catatan resmi. Minta hasil terstruktur, misalnya nilai, mata uang, tanggal, tingkat keyakinan, dan referensi sumber. Validasi skema sebelum informasi diteruskan. Apabila total yang dibaca tidak sama dengan jumlah baris atau mata uang tidak konsisten, tandai sebagai pengecualian. Perhitungan dan pencocokan sebaiknya dilakukan oleh kode biasa, bukan diserahkan pada kemampuan berhitung model bahasa.
Agen dapat membuat ringkasan untuk pemeriksa: “Makan malam perjalanan dinas; nilai Rp420.000; batas kebijakan Rp500.000; struk cocok dengan transaksi kartu; tidak ditemukan klaim identik.” Ringkasan harus menyertakan tautan ke bukti, aturan yang digunakan, dan alasan bila ada ketidakcocokan. Dengan demikian, pemeriksa tidak perlu menerima kesimpulan tanpa jejak.
Kebijakan sebagai aturan yang dapat diuji
Dokumen kebijakan sering berisi istilah ambigu seperti “wajar” atau “sesuai kebutuhan”. Jangan meminta model menafsirkan seluruh dokumen secara spontan untuk setiap klaim. Terjemahkan ketentuan yang jelas menjadi aturan terkelola: plafon berdasarkan kota atau jenis perjalanan, kategori terlarang, tenggat pengajuan, dan dokumen pendukung. Simpan versi kebijakan beserta tanggal berlakunya agar keputusan lama dapat dijelaskan berdasarkan aturan yang benar pada waktu klaim dibuat.
Untuk ketentuan yang membutuhkan penilaian, agen sebaiknya menyatakan alasan dan ketidakpastian, lalu meminta pemeriksaan. Contohnya, makan malam tim mungkin sesuai plafon tetapi daftar peserta belum dicantumkan. Agen dapat meminta pelengkapan data tanpa mengarang nama. Ambang keyakinan bukan pengganti risiko: klaim bernilai besar tetap memerlukan persetujuan berwenang sekalipun ekstraksi dokumennya sangat yakin.
Akses juga perlu dibatasi. Agen pemroses klaim tidak memerlukan hak mengubah rekening bank karyawan atau mengelola kebijakan. Berikan akses baca pada kebijakan dan transaksi yang relevan; izinkan membuat draf hasil pemeriksaan; tahan hak persetujuan final dan pelepasan pembayaran pada peran yang berwenang. Pembatasan teknis ini harus ditegakkan di lapisan aplikasi, bukan hanya disebutkan dalam prompt.
Prinsip ini sejalan dengan OWASP tentang Excessive Agency: batasi fungsi dan izin alat, minta persetujuan untuk tindakan berdampak tinggi, dan tegakkan otorisasi pada sistem tujuan. Penerapannya pada klaim biaya di sini adalah rekomendasi desain penulis, bukan jaminan kepatuhan atau sertifikasi keamanan.
Contoh penggunaan: klaim perjalanan dinas
Bayangkan seorang karyawan mengirim dua struk hotel dan satu tagihan makan malam setelah perjalanan. Agen mengekstrak tanggal, nama merchant, nilai, dan pajak dari masing-masing bukti. Sistem mencocokkan hotel dengan reservasi dan transaksi kartu. Satu struk makan malam ternyata diajukan dua kali dengan gambar berbeda tetapi merchant, waktu, dan nilai yang sama.
Agen tidak langsung menghapus salah satunya atau menolak seluruh klaim. Ia menandai pasangan yang mungkin duplikat, menampilkan bukti, dan meminta pemeriksa memilih tindakan. Dua klaim hotel berada di bawah plafon, tetapi satu tanggal transaksi berada di luar rentang perjalanan. Sistem dapat meminta karyawan mengklarifikasi tanggal tersebut. Bagian lain yang lolos pemeriksaan rutin tetap berjalan, sehingga satu anomali tidak harus menahan semua item.
Jika jumlah klaim kecil dan risikonya rendah, sistem dapat mengotomatisasi klasifikasi dan pencocokan, sambil mengambil sampel untuk audit. Klaim di atas batas tertentu, klaim tanpa bukti, atau perubahan rekening tetap membutuhkan persetujuan manusia. Keputusan akhir dan pembayaran dilakukan melalui sistem keuangan yang sudah ada, dengan identitas pelaksana serta nomor klaim tercatat.
Pengukuran dan peluncuran bertahap
Mulai dari mode bayangan: agen membaca klaim dan menyusun rekomendasi, tetapi hasilnya belum mengubah proses. Bandingkan ekstraksi dan penandaan pengecualian dengan hasil pemeriksa. Kumpulkan jenis kesalahan, bukan hanya skor akurasi rata-rata. Salah membaca digit pada nominal berdampak berbeda dari salah mengenali kategori, sehingga setiap kelas kesalahan perlu bobot risiko.
Setelah hasil cukup stabil, aktifkan bantuan untuk tugas yang mudah dibatalkan, seperti pengisian draf kategori atau permintaan dokumen tambahan. Perluas cakupan hanya setelah pengujian menunjukkan perilaku yang dapat diterima pada kasus normal dan kasus tepi. Pantau tingkat koreksi manusia, klaim yang terlambat, duplikasi yang terlewat, waktu penyelesaian, serta jumlah eskalasi. Lonjakan salah satu metrik harus dapat menghentikan otomasi atau mengembalikan alur ke pemeriksaan manual.
Log yang berguna mencatat ID klaim, versi kebijakan, sumber data, nilai yang diekstrak, aturan yang dipicu, rekomendasi agen, keputusan manusia, dan hasil akhirnya. Hindari menyalin seluruh isi struk atau data pribadi ke log yang tidak perlu. Tetapkan masa simpan dan akses sesuai kebutuhan audit dan privasi perusahaan.
Menjaga keputusan tetap dapat diperiksa
Agent AI paling bernilai ketika mengurangi pekerjaan membaca dan mencocokkan, bukan ketika menyamarkan keputusan penting sebagai keluaran model. Untuk klaim biaya, fondasi yang kuat adalah aturan yang eksplisit, bukti yang dapat ditelusuri, hak akses minimum, jalur eskalasi, serta evaluasi berdasarkan hasil nyata. Otomatiskan proses berisiko rendah lebih dahulu; pertahankan persetujuan manusia untuk pengecualian dan tindakan finansial yang berpengaruh.
Perlakukan agent sebagai penyusun rekomendasi yang dapat diaudit. Sebelum memperluas aksesnya, pastikan pemeriksa dapat membuka bukti, memahami aturan yang dipakai, dan mengoreksi hasilnya. Sistem kebijakan dan manusia tetap memegang kendali atas persetujuan serta pembayaran.
Referensi
- Anthropic — Building effective agents: pemisahan workflow dan agen, pemeriksaan per tahap, serta pengujian sebelum memperluas otonomi.
- OWASP — LLM06:2025 Excessive Agency: pembatasan fungsi, izin minimum, persetujuan manusia, dan otorisasi sistem tujuan.