Agent menampilkan pesan bahwa tugas sudah dibuat, tetapi koneksi terputus sebelum aplikasi menerima respons. Saat dicoba lagi, muncul dua tugas untuk pekerjaan yang sama. Jawaban AI mungkin terdengar masuk akal, namun transaksi di sistem operasional sudah bermasalah.
Uji aksi tulis AI agent perlu memeriksa perubahan yang benar-benar terjadi pada ERP, CRM, atau sistem tiket. Evaluasi bahasa dan ketepatan ringkasan tetap penting, tetapi tidak cukup untuk membuktikan bahwa agent aman diberi tool yang mengubah data. Panduan ini ditujukan kepada pemilik produk AI dan tim integrasi; contoh merupakan ilustrasi desain, bukan bukti kinerja produk Layana.ID.
Pisahkan Usulan Model dan Eksekusi Sistem
Model dapat mengusulkan tindakan, misalnya membuat tugas verifikasi dengan parameter tertentu. Lapisan aplikasi memvalidasi parameter, memeriksa identitas pengguna, memastikan hak akses, lalu memutuskan apakah permintaan dapat diteruskan. ERP atau CRM tetap menegakkan aturan bisnisnya sendiri.
Jangan menjadikan teks “sudah disetujui” sebagai izin. Persetujuan harus berupa catatan otoritatif yang terikat pada pengguna, objek, tindakan, parameter, dan versi data. Untuk workflow tetap, jalur eksekusi sudah ditentukan kode. Dalam agent, pemilihan langkah dapat dinamis, tetapi validasi dan kewenangan tidak boleh menjadi pilihan model.
Buat Kontrak Aksi yang Dapat Diverifikasi
Setiap tool tulis membutuhkan kontrak: tujuan, parameter wajib, objek sasaran, prasyarat status, hak minimum, dampak, hasil yang dikembalikan, dan cara membaca ulang. Bedakan tool “siapkan draf tugas” dari “kirim tugas kepada tim eksternal”. Nama yang terlalu umum seperti “proses permintaan” menyembunyikan akibat tindakan.
Kontrak juga memuat batas jumlah objek dan perilaku ketika sebagian gagal. Jika satu permintaan berisi beberapa cabang, jangan menganggap keberhasilan satu cabang berarti semuanya selesai. Hasil perlu menyatakan item berhasil, gagal, atau belum diketahui dengan identitas yang stabil.
Uji Timeout Setelah Transaksi Berhasil
Kasus penting adalah server berhasil menulis tetapi respons tidak sampai. Jalankan simulasi pada lingkungan uji yang terisolasi, lalu minta client memeriksa status melalui identitas permintaan sebelum mencoba kembali. Verifikasi jumlah objek aktual di sistem tujuan. Log agent yang mencatat satu rencana tidak membuktikan hanya satu transaksi tercipta.
Idempotensi berarti pengulangan permintaan yang sama mempertahankan efek yang dimaksud sebagaimana satu permintaan. RFC 9110 bagian 9.2.2 menjelaskan sifat ini pada semantik HTTP. Untuk operasi bisnis, tim tetap perlu merancang kunci permintaan, penyimpanan hasil, dan penanganan konflik; memakai HTTP saja tidak otomatis menyelesaikan duplikasi.
Kunci permintaan harus mencerminkan satu maksud bisnis yang sama. Permintaan berbeda tidak boleh disatukan hanya karena isi ringkasannya mirip. Sebaliknya, retry dengan kunci yang sama tetapi parameter berbeda harus terdeteksi, bukan diam-diam membuat transaksi baru atau mengembalikan hasil yang tidak sesuai.
Pastikan Approval Tidak Kedaluwarsa Secara Diam-Diam
Dalam ilustrasi, supervisor menyetujui tugas untuk pelanggan A dengan batas jumlah tertentu. Sebelum eksekusi, data pelanggan berubah atau model mengganti parameter. Sistem harus menolak approval lama jika perubahan tersebut material menurut kontrak, lalu meminta pemeriksaan ulang.
Uji perubahan objek, nilai, tanggal, penerima, dan versi sumber sesudah approval. Sertakan pula pengguna yang kewenangannya sudah dicabut. Persetujuan yang pernah valid tidak berarti selalu valid. Waktu pemeriksaan akhir perlu sedekat mungkin dengan aksi agar perubahan di antara review dan eksekusi tidak terlewat.
Periksa Salah Sasaran dan Kebocoran Antar-Entitas
Buat data uji dengan nama pelanggan serupa, nomor dokumen berulang pada perusahaan berbeda, serta cabang dengan format ID berlainan. Agent harus memakai identitas objek dan konteks entitas, bukan memilih hasil pencarian pertama. Hak akses perlu diperiksa pada server tujuan, termasuk ketika parameter disusun oleh model.
Pengujian negatif mencakup akses objek yang tidak dimiliki, tool yang tidak diizinkan, parameter tambahan, dan instruksi di dalam dokumen sumber. Lulus evaluasi jawaban tidak menutup risiko ini. Gunakan evaluasi hak akses RAG untuk lapisan pembacaan, lalu uji aksi tulis sebagai cakupan yang terpisah.
Rancang Matriks Kasus dan Bukti Kelulusan
- Permintaan valid: satu objek yang benar tercipta dan dapat dibaca ulang.
- Retry identik: tidak ada efek bisnis tambahan di luar kontrak.
- Kunci sama, parameter berubah: konflik terdeteksi dan tidak dieksekusi diam-diam.
- Approval lama: perubahan material memicu penolakan atau review ulang.
- Hak dicabut: aksi ditolak meskipun rencana model sudah disiapkan.
- Respons ambigu: status tetap belum diketahui sampai sumber tujuan memberikan bukti.
- Kegagalan sebagian: item yang belum selesai tetap terlihat dan dapat dipulihkan tanpa menggandakan item sukses.
Untuk setiap kasus, simpan input tersamarkan, identitas permintaan, versi tool, keputusan validasi, ID transaksi tujuan, serta hasil readback. Bukti perlu memungkinkan reviewer lain merekonstruksi kejadian. Hindari memasukkan token atau data pribadi ke log hanya demi kelengkapan audit.
Tentukan KPI dan Gerbang Perluasan
Ukur ketepatan sasaran, transaksi ganda, eksekusi tanpa approval sah, ketepatan pelaporan status, dan keberhasilan pemulihan setelah kegagalan. Durasi penyelesaian dan biaya dapat dipantau, tetapi tidak menggantikan kontrol tindakan. Satu aksi yang salah sasaran dapat lebih penting daripada banyak kasus sederhana yang berhasil.
Tentukan standar penerimaan bersama pemilik proses sebelum uji. Mulai dengan tool yang membuat draf atau tugas internal terbatas, bukan pembayaran atau komunikasi massal. Bandingkan perilaku dengan baseline workflow biasa agar kompleksitas agent memiliki alasan yang dapat dibuktikan.
Jika pilot masuk tahap operasional, sediakan pembatas volume, penghentian aksi, antrean review, dan prosedur pemulihan. Rollback tidak selalu berarti menghapus transaksi; beberapa proses memerlukan pembatalan resmi atau catatan koreksi. Tetapkan tindakan pemulihan bersama pemilik ERP sebelum membuka akses tulis.
Siapkan Pengujian sebagai Bagian dari Integrasi
Untuk implementasi AI bisnis, Layana.ID dapat diajak memetakan kebutuhan dan ruang lingkup pilot. Bawa daftar tool, contoh payload tersamarkan, aturan approval, batas entitas, serta akses lingkungan uji. Kaitkan kebutuhan itu dengan rancangan integrasi sistem.
Diskusikan pengujian aksi tulis AI agent sebelum tool memperoleh kewenangan operasional. Keluaran yang dicari adalah kontrak aksi, matriks uji, bukti readback, dan keputusan perluasan yang dapat diperiksa, bukan sekadar demo yang berjalan sekali.