Agent Pintar Belum Tentu Bisa Dipercaya

Demo AI Agent hampir selalu dimulai dari kondisi yang rapi. Ujian sebenarnya muncul ketika satu sumber kosong, tool gagal, atau dua sistem memberi jawaban berbeda.

Demo biasanya menunjukkan alur ideal: masukan bersih, tool bekerja, pertanyaan jelas, lalu agent memberi hasil yang mengesankan. Pekerjaan nyata lebih berantakan. Data bisa kurang, dua sumber dapat bertentangan, tool bisa gagal, dan satu tindakan mungkin berdampak ke pelanggan atau data produksi.

Kemampuan menjawab pertanyaan sulit belum berarti agent tahu data mana yang boleh dibaca, tindakan mana yang boleh dijalankan, kapan harus berhenti, kapan harus meminta persetujuan, dan seperti apa hasil yang dianggap benar.

Di situlah kepercayaan diuji. Bukan hanya saat agent menjawab dengan benar, tetapi saat ia tahu aksesnya, batas tindakannya, dan kondisi yang mengharuskannya berhenti.

Kepercayaan juga bukan pilihan biner antara menyerahkan semuanya atau tidak memakai agent sama sekali. Tim dapat memberi tingkat kewenangan berbeda untuk pekerjaan berbeda. Agent mungkin dipercaya membaca sumber tertentu dan membuat draft, tetapi belum dipercaya mengirim, menghapus, atau mengambil keputusan akhir.

Jawaban Bagus Bukan Kontrak Perilaku

Bayangkan Invoice Reminder Agent yang biasanya menyiapkan draft dengan rapi. Pada satu invoice, status pembayaran di sistem belum diperbarui sementara pelanggan sedang dalam proses sengketa. Agent tetap mengirim reminder karena jadwal tindak lanjut sudah tiba.

Secara format, pesannya terlihat benar. Secara operasional, agent baru saja menjalankan tindakan yang menyentuh pelanggan tanpa memeriksa kondisi yang seharusnya menahan pengiriman.

Contoh lain: agent content dapat menulis draft dengan cepat, lalu diberi akses publish langsung. Atau agent operations diberi izin mengubah spreadsheet meski pekerjaannya hanya membaca data untuk laporan.

Di contoh-contoh itu, titik lemahnya bukan kemampuan menyusun bahasa. Masalahnya ada pada desain kewenangan dan kondisi gagal. Agent tidak memiliki batas yang cukup eksplisit untuk membedakan “bisa dilakukan” dari “boleh dilakukan”.

Izin Akses Harus Mengikuti Pekerjaan

Izin menentukan sumber apa yang boleh diakses dan tindakan apa yang tersedia.

Gunakan prinsip akses minimum. Kalau agent hanya membutuhkan daftar invoice yang jatuh tempo, jangan otomatis memberi akses ke seluruh data pelanggan. Kalau tugasnya membuat draft reminder, akses baca ke status pembayaran mungkin cukup. Kalau tugasnya mengklasifikasikan ticket, izin menghapus ticket tidak relevan.

Bedakan read dan write. Membaca kalender berbeda risikonya dari membuat atau membatalkan jadwal. Membaca data CRM berbeda dari mengubah status deal. Menghasilkan preview email berbeda dari mengirimkannya ke pelanggan.

Izin yang sempit mengurangi luas dampak ketika agent salah memahami instruksi, menerima masukan yang buruk, atau mengalami kegagalan tool. Ini bukan jaminan bahwa hasil selalu benar. Ini cara membatasi konsekuensi ketika sesuatu tidak berjalan sesuai rencana.

Untuk setiap tool, dokumentasikan:

• data yang dapat dibaca;
• tindakan yang dapat dijalankan;
• input yang dibutuhkan;
• kegagalan yang mungkin muncul;
• apakah tindakan dapat dibatalkan;
• dan apakah manusia perlu memberi approval.

Persetujuan: Manusia Masuk di Titik yang Tepat

Persetujuan bukan berarti manusia harus memeriksa setiap langkah kecil. Kalau semua tindakan berhenti untuk ditinjau, alur kerja dapat kehilangan manfaatnya.

Tempatkan approval sebelum tindakan yang punya konsekuensi lebih besar atau sulit dipulihkan. Contohnya:

• mengirim pesan kepada pihak eksternal;
• mempublikasikan konten;
• mengubah atau menghapus data penting;
• membuat transaksi;
• memberikan akses kepada pengguna lain;
• atau mengambil keputusan yang berdampak pada pelanggan.

Agent dapat mengerjakan persiapan secara otomatis: membaca masukan, menyusun draft, menandai informasi yang belum tersedia, dan membuat pratinjau. Manusia kemudian memeriksa bagian yang membutuhkan tanggung jawab atau pertimbangan.

Permintaan persetujuan juga harus membawa konteks yang cukup. Tombol “setujui” tidak banyak membantu kalau pemeriksa tidak bisa melihat sumber, perubahan, serta tindakan yang akan dijalankan. Pratinjau yang baik menjelaskan apa yang terjadi setelah persetujuan diberikan.

Keterlacakan: Bikin Perilakunya Bisa Ditelusuri

Tim perlu bisa melihat apa yang dibaca agent, aturan mana yang dipakai, tindakan apa yang dicoba, dan kegagalan apa yang muncul. Tanpa jejak ini, hasil yang salah terlihat seperti kejadian acak dan sulit ditelusuri penyebabnya.

Untuk alur pengingat invoice, catatan sistem dapat memuat invoice yang diproses, status pembayaran saat pengecekan, template yang dipilih, persetujuan yang diterima, dan status pengiriman. Kalau pesan tidak jadi dikirim karena data bertentangan, alasan berhentinya juga perlu terlihat.

Keterlacakan bukan berarti menyimpan semua data selamanya. Catat informasi yang cukup untuk pemeriksaan dan penelusuran masalah, lalu kelola akses serta masa simpannya sesuai kebutuhan alur kerja.

Evaluasi: Definisikan Hasil yang Benar

Evaluasi menjawab bagaimana tim memeriksa hasil dan perilaku agent. Untuk alur pengingat invoice, daftar pemeriksaannya dapat memastikan invoice berasal dari sumber resmi, statusnya sudah diperiksa, akun yang sedang bersengketa ditahan, pesan mengikuti template, dan persetujuan diperoleh sebelum pengiriman.

Evaluasi tidak harus selalu berupa skor otomatis. Daftar periksa, pemeriksaan sampel secara manual, perbandingan dengan sumber, dan tinjauan manusia tetap valid. Yang penting, tim tidak baru menentukan standar setelah melihat hasil.

Selain kualitas hasil, evaluasi perilakunya. Apa yang agent lakukan ketika tool melewati batas waktu? Bagaimana ia merespons masukan kosong? Apakah ia berhenti ketika dua sumber bertentangan? Apakah persetujuan benar-benar ditunggu sebelum tindakan dilakukan?

Agent yang menghasilkan output bagus pada kondisi ideal tetapi bertindak sembarang saat terjadi kesalahan belum dapat dianggap andal.

Pemulihan: Siapkan Cara Membatasi Dampak

Instruksi “jangan melakukan hal berbahaya” terlalu abstrak. Agent membutuhkan aturan operasional.

Kalau data kurang, minta informasi tambahan atau tandai kolom sebagai belum tersedia. Kalau tool gagal, catat kegagalan dan tawarkan percobaan ulang. Kalau sumber bertentangan, tampilkan pertentangannya untuk diperiksa. Kalau tindakan membutuhkan persetujuan, buat pratinjau lalu berhenti.

Batas perilaku yang hanya berisi larangan dapat membuat alur kerja buntu. Batas yang baik juga menjelaskan langkah aman berikutnya. Dengan begitu, agent tidak dipaksa memilih antara melanggar aturan atau mengarang jalan keluar.

Desain juga perlu mempertimbangkan kemampuan pemulihan. Draft yang salah mudah dibuang. Pesan yang telanjur dikirim ke pelanggan lebih sulit ditarik kembali. Perubahan data sebaiknya memiliki riwayat perubahan atau cara mengembalikan keadaan ketika sistem mendukungnya. Makin sulit sebuah tindakan dipulihkan, makin kuat titik pemeriksaan yang dibutuhkan sebelum tindakan itu berjalan.

Tim juga perlu menentukan penanggung jawab eskalasi. Ketika agent berhenti, siapa yang menerima pemberitahuan? Informasi apa yang harus disertakan supaya orang tersebut bisa mengambil keputusan tanpa mengulang penelusuran dari nol?

Kepercayaan Datang dari Desain yang Bisa Diperiksa

Kepercayaan bukan bonus otomatis dari model yang makin pintar. Ia tumbuh ketika batasnya jelas, hasilnya bisa diperiksa, dan perilakunya tetap masuk akal saat kondisi tidak ideal.

Sebelum memberi agent akses baru, tanyakan:

1. Apakah akses ini benar-benar dibutuhkan untuk job-nya?
2. Apa dampaknya kalau tindakan salah?
3. Bisakah tindakan tersebut dibatalkan?
4. Apakah manusia perlu melihat preview?
5. Apa success criteria-nya?
6. Apa yang harus dilakukan agent ketika data atau tool bermasalah?

Pertanyaan ini membuat keputusan akses lebih dipertimbangkan. Tim tidak menambah permission hanya karena integrasinya tersedia.

Mulai dari alur kerja dengan akses sempit dan hasil yang bisa diperiksa. Amati kegagalan, perbaiki instruksi dan evaluasi, lalu perluas kewenangan hanya ketika ada alasan yang jelas.

Riwayat review juga berguna untuk melihat pola: kesalahan apa yang berulang, kondisi apa yang sering memicu eskalasi, dan bagian mana yang sudah cukup stabil. Data itu membantu tim memperbaiki workflow tanpa mengandalkan kesan dari satu demo atau satu output yang kebetulan bagus.

Sebelum Menambah Akses

Sebelum menambah akses, audit empat hal: izin, keterlacakan, persetujuan, dan kemampuan pemulihan. Kalau satu saja belum jelas, agent belum membutuhkan kewenangan baru; alur kerjanya masih membutuhkan desain.

Kelas Building AI Employees mengajak lo menerapkan batas-batas itu dalam satu workflow praktis.

Detail kelas ada di https://goakal.com/ai-builders-id/building-ai-employees