Banyak diskusi AI agent sering dimulai dari kalimat yang terlalu luas: “kami ingin semua proses bisnis dibantu AI.” Kalimat itu berguna untuk tahap ide, tetapi belum cukup untuk meeting implementasi. Vendor, tim IT, dan owner bisnis membutuhkan brief yang lebih operasional: masalah apa yang mau diselesaikan, data apa yang boleh dipakai, aksi apa yang boleh dilakukan AI, dan kapan manusia harus mengambil alih.
Artikel ini membantu tim bisnis menyiapkan brief awal yang ringkas. Tujuannya bukan mengganti dokumen teknis, melainkan membuat scope lebih jelas sehingga proposal lebih mudah dibandingkan dan risiko terlihat sebelum pilot berjalan.
Mulai dari satu keputusan bisnis
Pilih satu alur kerja yang sering terjadi, bukan daftar fitur. Contohnya: mengkualifikasi lead dari WhatsApp, merangkum permintaan pelanggan sebelum dibuatkan penawaran, mengecek status order lintas sistem, atau menyiapkan draft follow-up untuk sales. Tulis use case dalam empat jawaban: siapa pengguna utamanya, situasi apa yang memicu AI bekerja, output apa yang dianggap berguna, dan keputusan apa yang tetap dipegang manusia.
Dengan format ini, tim tidak terjebak meminta “chatbot lengkap” tanpa tahu pekerjaan spesifik yang perlu dibantu. Semakin jelas momen kerjanya, semakin mudah menguji apakah AI benar-benar membantu operasional.
Petakan data yang boleh dipercaya
AI agent membutuhkan konteks dari FAQ, katalog, SOP, histori chat, CRM, spreadsheet, invoice, atau sistem internal. Namun data yang tersedia belum tentu siap dipakai. Ada dokumen yang usang, harga yang berubah tanpa riwayat, nama produk yang tidak konsisten, atau percakapan pelanggan yang mengandung informasi sensitif.
Dalam brief, pisahkan data menjadi tiga kelompok: sumber utama yang paling dipercaya, sumber pendukung yang hanya memberi konteks, dan data terlarang yang tidak boleh masuk ke prompt, log, atau output AI. Prinsip ini sejalan dengan NIST AI RMF yang mengelompokkan pengelolaan risiko AI ke fungsi Govern, Map, Measure, dan Manage (NIST AI RMF). Untuk bisnis, artinya sederhana: tentukan sumber kebenaran dan pemilik data sebelum sistem dipakai pelanggan.
Bedakan saran dan eksekusi
Perbedaan penting antara chatbot biasa dan AI agent adalah kemampuan mengambil langkah: membuat draft, memanggil API, mengubah status CRM, mengirim notifikasi, membuka tiket, atau menyiapkan penawaran. Karena itu, brief harus menjelaskan mana yang boleh disarankan dan mana yang boleh dieksekusi otomatis.
Contoh batas aksi yang sehat: AI boleh merangkum kebutuhan pelanggan, tetapi manusia menyetujui harga akhir; AI boleh mengisi draft CRM, tetapi tidak menghapus data pelanggan; AI boleh membaca status order, tetapi tidak mengubah status pembayaran tanpa bukti dari sistem billing. Batas ini membantu owner bisnis menentukan risiko operasional dan pertanggungjawaban saat ada pengecualian.
Pilih integrasi minimum untuk pilot
Brief yang matang tidak harus memetakan semua integrasi sejak hari pertama. Versi pertama sebaiknya memilih integrasi minimum yang cukup untuk membuktikan nilai. Jika use case-nya kualifikasi lead, mungkin cukup mulai dari WhatsApp, form website, CRM, dan notifikasi internal. Jika use case-nya status order, sumber kebenarannya mungkin sistem order dan dashboard operasional.
Untuk setiap integrasi, tuliskan sistem sumber dan tujuan, data yang dibaca atau ditulis, frekuensi sinkronisasi, apa yang terjadi saat API gagal, dan siapa yang menerima alert. Bagian “saat gagal” sering dilewatkan, padahal inilah pembeda antara demo yang terlihat bagus dan sistem operasional yang bisa dipercaya.
Siapkan guardrail sebelum prompt
Prompt penting, tetapi prompt bukan satu-satunya pengaman. Aplikasi berbasis LLM memiliki risiko khusus seperti instruksi berbahaya dari input pengguna, kebocoran informasi sensitif, atau output yang dipakai sistem lain tanpa validasi. OWASP GenAI Security Project merangkum risiko seperti prompt injection dan sensitive information disclosure dalam OWASP Top 10 for LLM Applications (OWASP LLM Top 10).
Tuliskan guardrail sebagai aturan operasional: topik yang harus dijawab dari knowledge base saja, topik yang harus fallback ke tim, data yang harus disamarkan, kondisi yang langsung memicu handoff, dan log yang perlu disimpan untuk audit internal. Dengan begitu vendor tidak hanya diminta “buat prompt yang bagus,” tetapi diminta membangun alur yang aman ketika prompt tidak cukup.
Ukur pilot dengan metrik yang dekat dengan pekerjaan
Ukuran sukses jangan berhenti di “AI lebih pintar.” Untuk lead qualification, ukur kelengkapan data lead, waktu respons awal, rasio lead yang siap dihubungi sales, dan jumlah kasus yang perlu dikoreksi. Untuk customer service, ukur resolusi, handoff yang tepat, pengulangan pertanyaan, dan kepuasan setelah interaksi.
Hindari menjanjikan angka sebelum baseline tersedia. Lebih aman menulis kondisi saat ini, target pembelajaran pilot, metrik yang akan dipantau, periode evaluasi, dan keputusan setelah pilot: lanjut, revisi, atau hentikan.
Struktur brief satu halaman
Gunakan format ini sebelum meeting vendor: masalah bisnis, pengguna utama, use case versi pertama, data dan knowledge base, integrasi minimum, batas aksi AI, guardrail dan handoff, metrik pilot, serta keputusan rollout. Brief seperti ini cukup untuk membuat meeting pertama lebih produktif karena semua pihak menilai scope yang sama.
Jika use case melibatkan banyak sistem, data pelanggan sensitif, keputusan finansial, atau proses yang berdampak langsung pada pengalaman pelanggan, brief awal sebaiknya dilanjutkan menjadi desain implementasi. Tim MY-AICUSTOM dapat membantu memetakan alur, integrasi, guardrail, dan pilot yang realistis melalui halaman layanan implementasi AI atau diskusi awal di kontak.
