Bagaimana tim fintech seharusnya menilai vendor AI?
Nilai perilaku vendor saat gagal, bukan klaim akurasi mereka. Mintakan sepuluh panggilan terburuk yang bisa mereka tunjukkan, apa yang sistem lakukan saat salah, dan siapa yang menyadarinya. Vendor yang bisa menjawab itu telah membangun sesuatu; vendor yang menjawab dengan angka benchmark telah membangun demo.
Demo adalah produk yang berbeda dari sistem
Demo vendor adalah versi berperforma tertinggi dari sistem mereka yang pernah ada, dipilih oleh orang yang paling tahu cara menyuapinya. Setiap jam evaluasi Anda setelahnya dipakai untuk menemukan jarak antara versi itu dan lalu lintas hari biasa. Jadi pertanyaan yang berguna semuanya tentang jarak itu, bukan tentang demonya.
Lima pertanyaan yang layak ditanyakan
"Tunjukkan sepuluh contoh terburuk Anda." Tim yang pernah mengirim punya kegagalan yang bisa diputar ulang. Kalau terburuk yang bisa mereka tunjukkan adalah transkrip yang agak canggung, mereka belum pernah menjalankannya dalam keadaan nyata.
"Apa yang sistem lakukan saat ia salah?" Ada jawaban yang benar di sini dan biasanya membosankan: ia mengenali batasnya, ia berhenti, ia menyerahkan ke manusia, ia mencatat. Jawaban yang buruk adalah ia menyelesaikan tugasnya dengan percaya diri dan baru diketahui seseorang belakangan.
"Siapa yang menyadarinya?" Kesalahan yang ditemukan tim operasional Anda sendiri sebelum pelanggan itu tertangani. Kesalahan yang ditemukan pelanggan adalah kejadian hubungan, dan di keuangan konsumen juga kejadian kepatuhan.
"Integrasinya benar-benar menyentuh apa?" Petakan jalur tulis. Apa pun yang menulis ke ledger, memindahkan uang, mengubah status pelanggan, atau mengirim pesan atas nama merek Anda butuh batas yang bisa Anda tunjuk di dokumentasi mereka dan di kontrol Anda sendiri.
"Apa yang terjadi saat Anda mengubahnya?" Pergantian model, suntingan prompt, perubahan harga. Di fintech perubahan AI yang terlihat kecil adalah peristiwa UAT, karena kriteria penerimaannya milik proses bisnis, bukan milik catatan rilis vendor. Kalau vendor tidak punya jawaban, Anda sendiri yang menanggung seluruh risiko regresi — diam-diam, setiap kali mereka rilis.
Jalankan satu skenario nyata dari awal ke akhir
Sebelum tanda tangan apa pun, ambil satu skenario pelanggan nyata dan jalankan lewat sistem vendor dengan data Anda sendiri, agen Anda sendiri, dan definisi hasil baik Anda sendiri. Satu saja cukup, dan pilih yang membosankan — bukan yang mengesankan; tugas harian yang saat ini dikerjakan tim ratusan kali seminggu. Yang Anda uji adalah integrasi dan penyerahannya, di situlah kesepakatan gagal, bukan modelnya, yang sudah menang di demo.
Disiplin yang sama saya terapkan pada kesiapan peluncuran di proyek saya sendiri: skenario nyata, batas sistem, dan kesiapan operasional sebelum pengguna menyentuhnya. Membeli sistem AI dan membangun sistem AI gagal di tempat yang sama — dan bukan di modelnya.
Filbert Henrico adalah Technical Customer Success Lead di FINETIKS, Tangerang, sejak Juni 2025, dengan lebih dari tujuh tahun customer success dan technical sales di fintech Asia Tenggara, termasuk Xendit, Peakflo, dan Brick. Fokusnya mencakup integrasi API, AI agen, otomasi alur kerja, conversational AI, UAT, dan kesiapan peluncuran. Sarjana Marketing, Victoria University, Bandar Sunway, Malaysia, 2016–2019.
Sedang menghadapi hal serupa?
Halaman-halaman ini menjelaskan cara saya mendekati pekerjaannya, bukan metodologi baku. Kalau Anda sedang menelaah hal serupa dan butuh pandangan kedua atas pilihan-pilihannya, kirimkan masalahnya dalam keadaan apa adanya — yang belum rapi justru lebih berguna.
Baca lagi
Semua pertanyaanUse case AI mana yang sebaiknya dibangun lebih dulu?
Bangun yang manusianya sudah mengerjakan tugasnya setiap hari, jawaban benar mudah dikenali, dan jawaban salah murah untuk dibatalkan. Tiga syarat itulah yang membuat proyek bisa selesai: alur kerjanya memberi data, jawaban yang jelas memberi alat uji, dan kesalahan yang murah memberi izin untuk rilis.
Bagaimana mengotomasi customer support tanpa merusak eskalasi?
Petakan setiap aturan eskalasi yang sekarang diterapkan manusia, lalu otomasi hanya pekerjaan yang berada di atas aturan itu. Eskalasi bukan fitur yang ditambahkan ke alur otomatis — eskalasi adalah batas alurnya, jadi batasnya harus ada dan tertulis sebelum apa pun diotomasi. Tim yang mengotomasi dulu dan mendefinisikan eskalasi kemudian berakhir dengan sistem yang menangani semuanya dengan percaya diri, termasuk hal-hal yang tidak boleh disentuhnya.
Apa arti kesiapan produksi untuk agen AI suara?
Agen suara siap produksi ketika ia bisa mengakhiri panggilan dengan aman tanpa perlu pernah pintar. Artinya empat hal diuji dengan audio nyata, bukan transkrip: ia mengenali ucapan penelepon yang sebenarnya, ia menangani saat dipotong, ia punya tempat untuk menyerahkan ke manusia, dan setiap tindakan ke sistem nyata punya batas yang tidak bisa dilampaunya.