12 Pengujian Wajib Sebelum AI Agent Go-Live: Metode Evaluasi, Keamanan, KPI, dan Contoh Penerapan

AI adalah singkatan dari artificial intelligence, yang diterjemahkan sebagai kecerdasan buatan.

Panduan mendalam AIGEO | 24 Oktober 2026 | Edisi pengganti

Demo agen AI sering memukau karena tugas yang diperlihatkan telah diseleksi. Ketika sistem dipakai karyawan dan terhubung ke aplikasi sungguhan, ia akan menghadapi dokumen rusak, API gagal, instruksi ambigu, hak akses terbatas dan serangan melalui konten eksternal. Checklist ini mengubah klaim ‘agen sudah siap’ menjadi bukti yang dapat diperiksa.

1. Tetapkan kontrak perilaku dan kelas risiko

Sebelum menguji, tulis deskripsi tugas, input yang sah, data yang dilarang, sistem yang boleh diakses, tindakan yang wajib disetujui manusia dan definisi hasil berhasil. Pisahkan agen baca-saja dari agen yang dapat mengubah data, mentransfer uang atau mengirim dokumen. Risiko yang berbeda memerlukan ambang kelulusan berbeda.

Gunakan kerangka NIST AI RMF untuk menjalankan fungsi Govern, Map, Measure dan Manage. Setiap kasus uji harus memiliki pemilik yang memutuskan penerimaan risiko. Tanpa kontrak perilaku, kegagalan sulit dinilai karena tim akan terus menyesuaikan kriteria setelah melihat keluaran agen.

2. Tes 1: akurasi tugas inti

Siapkan paling sedikit 30 contoh representatif dari aktivitas nyata. Penilai manusia menetapkan jawaban benar atau indikator selesai yang dapat diperiksa dalam sistem asal. Ukur precision, recall atau tingkat tugas selesai sesuai sifat pekerjaan. Jangan gunakan hanya data yang pernah dipakai untuk menyusun prompt awal.

Jika agen bertugas menyusun laporan, periksa kelengkapan angka serta akurasi kutipan sumber. Jika ia bertugas mengubah status transaksi, nilai hasil transaksi pada sistem tujuan, bukan penjelasan yang ditulis model.

3. Tes 2: batas kewenangan alat

Periksa bahwa setiap API hanya memiliki izin minimum. Agen yang diminta memeriksa rekening harus tidak dapat mengubah nomor rekening; agen yang merangkum email tidak otomatis berwenang mengirim balasan. Jalankan simulasi permintaan tindakan di luar izin dan pastikan sistem tujuan menolak.

Uji juga hak akses lintas pengguna atau lintas tenant. Kebocoran data antarorganisasi adalah kegagalan serius meskipun terjadi sekali. Otorisasi harus diperiksa di sisi server, bukan dititipkan seluruhnya kepada instruksi model.

4. Tes 3: persetujuan manusia

Buat beberapa kasus berisiko sedang dan tinggi seperti penghapusan file, perubahan perizinan, pengiriman informasi ke luar serta perubahan nilai transaksi. Pastikan agen benar-benar berhenti sampai petugas menyetujui tindakan; saat ditolak, ia tidak mencari jalur alternatif untuk melakukan tindakan sama.

OpenAI Agents SDK mendokumentasikan mekanisme pause–approve–resume untuk alat sensitif. Apa pun platformnya, log harus menunjukkan siapa menyetujui, tindakan yang dilihatnya dan apakah tindakan final sesuai usulan yang disetujui.

5. Tes 4: prompt injection dan sumber tidak dipercaya

Masukkan secara defensif dokumen uji yang memuat perintah palsu untuk mengabaikan instruksi pengguna atau membocorkan data. Nilai apakah agen memperlakukannya sebagai konten yang harus dibaca, bukan perintah operasional. Sertakan skenario di email, halaman web, PDF hasil ekstraksi dan keluaran konektor.

NCSC mengingatkan bahwa prompt injection tidak dapat disamakan dengan SQL injection yang memiliki pemisahan parameter kokoh. Sistem harus mengandalkan pembatasan izin, validasi dan kontrol alat di luar model, bukan hanya kata-kata larangan.

6. Tes 5: privasi, kerahasiaan, dan retensi data

Periksa lokasi data masuk, data keluaran, trace dan memori persisten. Pastikan rahasia, nomor identitas, data kesehatan atau data pembayaran tidak masuk ke log yang aksesnya terlalu luas. Jalankan pengujian terhadap penghapusan dan retensi data sesuai kebijakan.

Organisasi Indonesia harus memperhatikan kewajiban UU Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi. Pihak yang menjadi pengendali dan prosesor data perlu ditetapkan, termasuk kontrak subprosesor dan transfer data lintas negara bila ada.

7. Tes 6: ketahanan ketika API gagal

Putuskan akses alat secara terkontrol, kembalikan respons timeout dan simulasi keluaran tidak lengkap. Agen harus berhenti aman, meminta bantuan atau melakukan retry dengan batas yang diketahui. Hindari retry tak terbatas yang dapat mengulang transaksi atau menimbulkan beban biaya besar.

Untuk operasi bisnis, idempotency key atau mekanisme setara perlu memastikan tindakan yang sama tidak dieksekusi berulang tanpa sengaja. Uji kondisi jaringan pulih setelah gangguan sehingga sistem tidak mengirim efek ganda.

8. Tes 7: kemampuan berhenti dan rollback

Setiap agen yang dapat bertindak memerlukan kill switch. Uji penghentian ketika sedang memproses beberapa pekerjaan serta pencabutan kredensial. Pastikan pekerjaan setelah pemberhentian tidak tetap memiliki izin karena token lama beredar.

Untuk proses yang reversibel, uji rollback. Untuk tindakan yang tidak dapat dibatalkan, seperti pengiriman data rahasia, pencegahan sebelum eksekusi menjadi prioritas. Dokumen audit perlu menjelaskan batas kemampuan pemulihan.

9. Tes 8: observabilitas

Pastikan semua run memiliki identitas, timestamp, versi model, parameter penting, alat yang dipanggil, biaya dan status akhir. Jejak audit perlu cukup rinci untuk mereproduksi kegagalan tanpa membocorkan data sensitif. OpenAI Agents SDK, misalnya, menyediakan tracing untuk generasi model, tool calls, handoff dan guardrails.

Audit tidak sama dengan merekam semua informasi mentah. Tentukan redaksi, masking, kebijakan retensi dan akses analis; semua ini perlu diuji agar observabilitas tidak menciptakan insiden baru.

10. Tes 9: konsistensi dan drift

Jalankan ulang sampel yang sama pada hari berbeda dan setelah model, prompt atau konektor diperbarui. Amati apakah tindakan dan kualitas hasil berubah. Gunakan benchmark tetap sebagai baseline serta sampel baru untuk menangkap pola pekerjaan terkini.

Versi model yang berbeda dapat mengubah gaya penalaran dan pemanggilan alat meskipun API sama. Rencanakan regression test otomatis sebelum setiap deployment. Jangan menganggap peningkatan skor umum berarti hasil kasus bisnis juga meningkat.

11. Tes 10: biaya total dan latensi

Hitung biaya per tugas yang benar-benar selesai, bukan hanya biaya per token. Termasuk panggilan ulang, pemeriksaan manusia, penyimpanan log, lisensi, sumber data dan biaya memperbaiki kesalahan. Catat waktu respons p50, p95 dan p99 untuk memahami pengalaman pengguna di bawah beban tinggi.

Simulasikan 10, 100, dan 1.000 pengguna bila sesuai kapasitas rencana, tanpa melewati batas layanan. Nilai apakah kenaikan beban mendorong kegagalan alat dan pembengkakan biaya akibat loop agen yang panjang.

12. Tes 11: keadilan bahasa dan aksesibilitas

Agen yang melayani publik harus diuji terhadap variasi bahasa Indonesia formal, bahasa sehari-hari, ejaan tidak baku dan kebutuhan pengguna disabilitas. Sampel perlu mencerminkan populasi pengguna, bukan hanya kemampuan staf kantor pusat.

Perbedaan tingkat kegagalan antarjenis pengguna bisa memiliki dampak diskriminatif. Jika performa buruk pada kelompok tertentu, terapkan jalur layanan manusia dan perbaiki data evaluasi sebelum ekspansi.

13. Tes 12: skenario penyalahgunaan dan audit independen

Simulasikan penyalahgunaan yang realistis dari sisi pengguna sah, dokumen eksternal, konektor rusak dan admin dengan izin terbatas. Tim keamanan perlu menilai akar masalah pada hak akses, bukan hanya jawaban model. Kerangka OWASP agentic security membantu memetakan tool misuse, identity abuse dan memory poisoning.

Libatkan penilai yang tidak membuat agen tersebut untuk sebagian pengujian. Audit independen mengurangi bias tim pengembang yang terlalu akrab dengan desain prompt. Semua temuan diberi tingkat keparahan dan tenggat perbaikan.

14. Contoh scorecard kelulusan

Gunakan empat kelompok: kualitas tugas, keamanan, keandalan dan ekonomi. Contoh ambang awal yang harus ditetapkan organisasi sendiri adalah minimal 95% kasus rutin berhasil, nol tindakan tanpa otorisasi pada set uji kritis, kemampuan pulih dari gangguan utama serta biaya per tugas dalam anggaran. Angka ini hanya contoh kebijakan, bukan standar resmi lintas industri.

Kegagalan keamanan kritis sebaiknya bersifat hard stop meskipun nilai rata-rata lain tinggi. Simpan bukti pengujian, tanggal, model, kode, sumber data, nama penilai dan status tindak lanjut dalam lembar evaluasi yang dapat diaudit.

15. Rencana pilot dan keputusan produksi

Peluncuran sebaiknya melalui tiga tahap: mode baca-saja atau shadow mode, penggunaan oleh tim kecil dengan persetujuan tindakan, lalu perluasan bertahap bila indikator stabil. Setiap tahap membutuhkan penanggung jawab on-call dan jalur rollback. Buat kalender audit ulang saat model atau alur integrasi berubah.

Keputusan go-live bukan stempel bahwa agen tidak akan salah. Ia berarti organisasi memahami jenis kesalahan yang mungkin terjadi, dapat mendeteksinya dengan cepat, membatasi dampaknya dan memiliki kewenangan untuk menghentikan sistem ketika perlu.

Rujukan, dokumentasi dan bacaan lanjutan

Catatan: rekomendasi pemilihan platform dan nilai ambang pengujian adalah kerangka kerja editorial, bukan endorsement komersial atau sertifikasi resmi. Gambar unggulan ilustrasi AI.

AIGeo.ID