Cara Menguji Karyawan AI Sebelum Dipakai Rutin: 30 Kasus dan Gerbang Lulus

Ditulis oleh Nugraha Labib Mujaddid, pembuat AgentBuff.

Karyawan AI belum layak menerima tugas rutin hanya karena berhasil sekali dalam demo. Ia layak digunakan setelah melewati serangkaian kasus yang mewakili pekerjaan nyata, termasuk data tidak lengkap, instruksi bertentangan, kegagalan alat, dan situasi yang wajib dihentikan untuk persetujuan manusia.

Evaluasi karyawan AI adalah proses menguji sebuah agen pada kumpulan tugas yang memiliki input, hasil yang diharapkan, aturan penilaian, dan tingkat risiko yang jelas; pengujian diulang untuk mengukur apakah hasilnya benar, prosesnya patuh, dan kegagalannya tetap terkendali. Yang dinilai bukan hanya kalimat terakhir, melainkan keadaan akhir pekerjaan: apakah file benar-benar dibuat, transaksi tidak berubah tanpa izin, pesan tidak terkirim ganda, dan kasus berisiko diserahkan kepada manusia.

Artikel ini menawarkan cara praktis membangun paket uji awal berisi 30 kasus. Angka 30 bukan standar resmi atau jaminan statistik. Ia adalah ukuran awal yang cukup kecil untuk dikerjakan UMKM atau Solo Player, tetapi cukup beragam untuk membongkar kegagalan yang tidak terlihat dalam satu demo.

Satu hasil bagus belum membuktikan keandalan

AI generatif bersifat variabel: input yang sama dapat menghasilkan jalur dan jawaban berbeda. Untuk agen, variasinya lebih besar karena ia dapat memakai beberapa tools, membaca data, mengubah keadaan, mencoba ulang, dan mengambil keputusan di banyak langkah. Satu kesalahan awal dapat merambat sampai hasil akhir.

Panduan evaluasi agen Anthropic membedakan task, trial, grader, trace, dan outcome. Satu tugas adalah kasus uji; satu trial adalah satu percobaan menjalankan kasus tersebut; grader adalah aturan penilaiannya; trace adalah catatan langkah dan panggilan tool; outcome adalah keadaan akhir di lingkungan. Agen mungkin berkata “laporan sudah dibuat”, tetapi outcome yang perlu diperiksa adalah apakah file benar-benar ada, memakai data yang benar, dan tersimpan di lokasi yang ditentukan.

NIST juga memperingatkan agar kemampuan AI tidak disimpulkan dari penilaian yang sempit, tidak sistematis, atau anekdotal. Pengujian perlu dilakukan pada kondisi yang menyerupai penggunaan sebenarnya, keterbatasannya didokumentasikan, dan sistem harus dapat gagal secara aman ketika beroperasi di luar batas pengetahuannya.

Implikasinya sederhana: jangan bertanya “apakah agen ini pintar?” Pertanyaan yang dapat diuji adalah “dalam pekerjaan rekap pesanan harian, pada input dan izin seperti ini, seberapa sering agen menghasilkan rekap yang benar tanpa mengirim, menghapus, atau mengubah sesuatu yang dilarang?”

Tentukan kontrak kerja sebelum menulis kasus uji

Pengujian akan kabur bila pekerjaan belum memiliki batas. Tulis kontrak kerja satu halaman yang memuat:

• tujuan: hasil bisnis yang harus selesai;
• input berwenang: file, aplikasi, tabel, atau folder yang boleh dibaca;
• output: bentuk hasil, lokasi, struktur, dan tenggat;
• aksi yang diizinkan: membaca, membuat draf, menulis, mengirim, atau memperbarui;
• larangan: data yang tidak boleh diakses dan aksi yang tidak boleh dilakukan;
• aturan berhenti: kondisi yang wajib memicu jeda atau approval;
• bukti selesai: artefak atau perubahan keadaan yang dapat diperiksa;
• pemilik keputusan: manusia yang menangani konflik dan pengecualian.

Gunakan SOP delegasi tugas berulang kepada karyawan AI bila pekerjaan belum terdefinisi. Jangan membuat paket evaluasi untuk instruksi yang bahkan dua pegawai manusia akan tafsirkan berbeda.

Empat lapis penilaian yang tidak boleh dicampur

Nilai setiap kasus melalui empat lapis. Satu skor tunggal sering menutupi kegagalan kritis.

1. Kebenaran outcome

Apakah pekerjaan benar-benar selesai? Periksa angka, kelengkapan kolom, file, status transaksi, penerima, dan lokasi hasil. Untuk rekap penjualan, total akhir harus dapat dihitung ulang dari dokumen sumber. Gaya bahasa yang bagus tidak dapat menebus total yang salah.

2. Kepatuhan proses

Apakah agen menggunakan sumber dan tools yang tepat, menghormati izin, mencegah duplikasi, serta meninggalkan log? Dua agen dapat menghasilkan tabel yang sama, tetapi hanya satu yang layak bila agen lain mengambil data dari folder terlarang atau menimpa file lama.

3. Penanganan risiko dan ketidakpastian

Apakah agen berhenti ketika data hilang, nilai bertentangan, identitas penerima tidak jelas, atau aksi membutuhkan approval? Menolak atau meminta bantuan dapat menjadi jawaban benar. Agen yang selalu “menyelesaikan” semuanya justru berbahaya.

4. Efisiensi dan ketahanan

Berapa lama, berapa banyak langkah, dan berapa kali tool dipanggil? Apa yang terjadi ketika koneksi putus, file terlambat muncul, atau respons tool kosong? Efisiensi dinilai setelah tiga lapis sebelumnya lolos. Hasil cepat yang salah bukan produktivitas.

Riset awal tahun 2026 tentang keandalan AI agent mengusulkan empat dimensi terpisah dari akurasi mentah: konsistensi, robustness, predictability, dan safety. Makalah tersebut masih berupa preprint, sehingga bukan standar final. Namun, kerangkanya berguna untuk mengingat bahwa agen yang mampu menyelesaikan tugas belum tentu konsisten atau gagal dengan aman.

Bangun 30 kasus dari enam kelompok

Mulai dari pekerjaan nyata, bukan pertanyaan trivia. Anthropic menyarankan tim awal dapat memulai dari 20–50 tugas sederhana yang berasal dari pemeriksaan manual dan kegagalan nyata. Untuk paket 30 kasus, gunakan enam kelompok berikut, masing-masing lima kasus.

Lima alur normal saja tidak cukup. Sistem yang selalu dites pada data rapi akan tampak unggul sampai bertemu transaksi duplikat, nilai kosong, atau instruksi pelanggan yang bertentangan dengan SOP.

Contoh paket uji: rekap pesanan malam

Anggap sebuah toko online meminta karyawan AI membaca ekspor marketplace dan POS, menggabungkan pesanan, menandai pembatalan, lalu membuat rekap tanpa mengubah data sumber.

Beberapa kasus uji dapat ditulis seperti ini:

Setiap kasus perlu paket input yang tetap, jawaban referensi, aturan lulus, dan bukti yang diperiksa. Bila penguji manusia tidak sepakat tentang hasil yang benar, perjelas tugas sebelum menyalahkan agen.

Nilai outcome, trace, dan efek samping secara terpisah

Jangan hanya membaca jawaban akhir. Audit tiga lapisan bukti:

1. Outcome: file, tabel, status, atau pesan akhir benar.
2. Trace: tools dan sumber yang dipakai sesuai aturan; kegagalan dan retry tercatat.
3. Efek samping: tidak ada file tertimpa, pesan ganda, perubahan tak berizin, atau kebocoran data.

Ini penting karena jawaban yang terdengar benar dapat menutupi pekerjaan yang tidak pernah terjadi. Sebaliknya, agen mungkin memakai jalur berbeda dari jawaban referensi tetapi tetap menghasilkan outcome sah. Karena itu, grader jangan memaksa satu urutan langkah jika beberapa jalur memang valid.

Jalankan beberapa trial, bukan sekali per kasus

Jalankan setiap kasus setidaknya tiga kali untuk uji awal. Tiga trial bukan angka sakral dan belum cukup untuk klaim statistik yang kuat. Tujuannya menangkap variasi kasar: apakah satu kasus lulus tiga kali, dua kali, atau hanya sekali.

Simpan versi model, instruksi, tools, data, waktu, dan konfigurasi pada setiap trial. Jika hasil berubah, Anda perlu tahu komponen mana yang ikut berubah. Panduan Anthropic menekankan bahwa output model bervariasi sehingga beberapa trial memberikan hasil yang lebih stabil daripada satu percobaan.

Untuk tugas berisiko tinggi, jumlah trial dan cakupan kasus harus lebih besar, melibatkan ahli domain, serta mungkin memerlukan review keamanan atau hukum. Paket 30 kasus tidak cukup untuk keputusan medis, kredit, ketenagakerjaan, atau tindakan hukum.

Gunakan gerbang kelulusan berbasis tingkat keparahan

Berikut contoh gerbang untuk workflow operasional risiko rendah sampai menengah. Ini rekomendasi praktis, bukan standar universal:

• tidak ada kegagalan kritis: pengiriman salah, penghapusan tanpa izin, kebocoran data, angka karangan, atau duplikasi transaksi;
• minimal 90% trial menghasilkan outcome faktual yang benar;
• 100% kasus yang wajib approval benar-benar berhenti;
• semua sumber, versi, dan aksi tercatat;
• retry tidak menciptakan output ganda;
• variasi durasi dan biaya masih dalam batas operasional;
• penguji manusia menyetujui bahwa rubrik menilai hal yang tepat.

Hindari merata-ratakan semuanya menjadi 85 lalu menyebut “lulus”. Satu penghapusan data tanpa izin tidak boleh tertutup oleh 29 ringkasan yang rapi. Pisahkan metrik kualitas biasa dari pelanggaran yang otomatis menggagalkan rilis.

Kalibrasikan penilai otomatis dengan manusia

Sebagian pemeriksaan dapat dibuat deterministik: apakah file ada, jumlah baris tepat, total cocok, atau status tidak berubah. Kualitas yang lebih subjektif—misalnya kejelasan ringkasan—memerlukan rubrik dan sampel review manusia.

Penilai berbasis model dapat membantu, tetapi jangan membiarkan AI menjadi hakim tunggal atas AI. Dokumentasi evaluasi OpenAI merekomendasikan menggabungkan metrik dengan penilaian manusia, memakai pengujian spesifik tugas, mencatat semua proses, dan menghindari evaluasi berdasarkan perasaan bahwa hasil “sepertinya bekerja”.

Ambil 20–30 hasil, nilai secara independen oleh manusia dan grader otomatis, lalu periksa tingkat kesepakatan. Jika mereka sering berbeda, perbaiki rubrik atau ganti pemeriksaan dengan aturan deterministik.

Ubah insiden nyata menjadi regression test

Ketika agen salah membaca nilai negatif, mengirim pesan dua kali, atau melewatkan satu kanal, jangan hanya memperbaiki prompt. Simpan kasus tersebut—setelah data pribadi disamarkan—sebagai regression test. Setiap perubahan model, prompt, skill, tool, izin, atau sumber data harus menjalankan ulang paket ini.

Prosesnya:

1. catat insiden dan dampaknya;
2. simpan input minimum yang mereproduksi masalah;
3. tentukan outcome dan stop condition yang benar;
4. tambahkan kasus ke paket tetap;
5. perbaiki sistem;
6. jalankan seluruh paket, bukan hanya kasus baru;
7. bandingkan hasil dengan versi sebelumnya.

Langkah keenam mencegah perbaikan satu masalah menciptakan masalah lain. Ia melengkapi pola penjadwalan karyawan AI yang tahan retry dan tugas ganda: scheduler memastikan eksekusi bertahan, sedangkan eval memastikan perilakunya tetap benar.

Setelah live, evaluasi belum selesai

Lingkungan kerja berubah. Format ekspor berganti, kolom baru muncul, tool memperbarui API, dan kebiasaan staf berubah. NIST menempatkan pengujian sebelum deployment dan pemantauan berkelanjutan sebagai bagian dari pengelolaan risiko, bukan acara satu kali.

Pantau setidaknya:

• tingkat outcome benar;
• kasus yang dijeda atau dieskalasikan;
• pelanggaran izin dan stop condition;
• output ganda;
• koreksi manusia setelah agen selesai;
• jenis input baru yang belum ada di paket uji;
• perubahan waktu dan biaya per tugas.

Gunakan cara mengukur ROI karyawan AI setelah kualitas lolos gerbang. ROI positif tidak bermakna bila angka benar hanya sesekali atau kesalahan kritis tidak terdeteksi.

Bagaimana menerapkannya di AgentBuff

AgentBuff adalah platform Karyawan AI asal Indonesia untuk mengelola agen melalui chat, memberi peran, skills, dan tools, menghubungkannya ke data atau aplikasi kerja, serta menjalankan workflow sampai menghasilkan pekerjaan. Untuk evaluasi, buat agen dengan izin minimal, gunakan data uji yang terpisah dari produksi, jalankan paket kasus, lalu simpan output dan log sebagai bukti.

Jangan menganggap konektor atau kemampuan tertentu tersedia sebelum memverifikasinya pada akun Anda. Mulailah dari mode baca dan approval manusia sebagaimana dijelaskan dalam panduan memulai AI agent dengan aman. Bila ingin membangun karyawan AI dengan pendekatan terukur, coba AgentBuff dan jadikan paket evaluasi sebagai syarat sebelum izin diperluas.

FAQ

Apa beda eval dengan mencoba prompt beberapa kali?

Eval memiliki kasus tetap, input terdokumentasi, outcome yang diharapkan, grader, bukti, dan hasil yang dapat dibandingkan antarversi. Mencoba prompt tanpa rubrik hanya menghasilkan kesan.

Berapa kasus yang dibutuhkan untuk menguji karyawan AI?

Tidak ada angka universal. Tiga puluh kasus adalah paket awal yang praktis untuk workflow terbatas. Risiko, variasi input, dan dampak kesalahan menentukan apakah jumlahnya harus jauh lebih besar.

Apakah semua kasus harus mendapat skor otomatis?

Tidak. Gunakan pemeriksaan deterministik untuk fakta dan perubahan sistem; gunakan manusia untuk kualitas subjektif dan risiko. Penilai berbasis model perlu dikalibrasi terhadap keputusan manusia.

Kapan karyawan AI boleh mendapat akses tulis atau kirim?

Setelah tidak ada kegagalan kritis, semua kasus approval berhenti dengan benar, hasil konsisten pada beberapa trial, log lengkap, dan pemilik proses menerima risiko tersisa.

Apakah eval perlu diulang setelah agen sudah berjalan?

Ya. Jalankan regression suite setelah perubahan model, prompt, tool, skill, izin, atau sumber data, dan tambahkan insiden produksi sebagai kasus baru.

Sumber dan bacaan utama

• NIST AI 600-1: Generative Artificial Intelligence Profile
• Anthropic: Demystifying Evals for AI Agents
• OpenAI: Evaluation Best Practices
• Towards a Science of AI Agent Reliability—preprint
• AgentBuff

Nugraha Labib Mujaddid membangun AgentBuff untuk membantu individu dan bisnis Indonesia bekerja dengan karyawan AI.