Use case AI mana yang sebaiknya dibangun lebih dulu?

Use case yang dipilih hampir selalu yang paling mengesankan orang di ruang rapat, padahal itu pertanyaan berbeda dari yang bisa dikirim. Tim mengambil proyek yang ambisius, terlihat, dan ambigu — lalu mendapati tidak ada bagian yang bisa diuji: tidak ada catatan atas jawaban yang akan diberikan manusia, tidak ada kesepakatan tentang seperti apa hasilnya yang bagus, dan satu kesalahan akan mahal.

Saya mendekati ini dari sisi dukungan, bukan dari lab. Di customer support aplikasi keuangan konsumen, daftar tugasnya sudah tertulis, aturan eskalasinya sudah ada, dan definisi hasil buruk bersifat hukum dan finansial — bukan selera. Itu titik awal yang jujur.

Pertama: apakah manusia sudah mengerjakan ini setiap hari? Kalau tugasnya bukan bagian dari rutinitas seseorang, itu bukan alur kerja — itu ide. Tugas harian menghasilkan bahan bakunya sendiri: tiket, keputusan, koreksi, catatan yang saling dikirim antar tim. Anda tidak perlu mengumpulkan apa pun, dan ini sangat penting untuk proyek pertama yang tidak punya anggaran pekerjaan data.

Kedua: apakah jawaban yang benar mudah dikenali? Tidak harus terbukti benar — cukup jelas bagi orang yang sekarang mengerjakan tugas itu. "Masalah pelanggan ini pemblokiran kartu atau masalah KYC?" mudah dikenali. "Apakah pelanggan ini berisiko churn?" tidak, dan perbedaan pendapat soal jawabannya akan muncul setelah Anda membangun sesuatu, bukan sebelumnya.

Ketiga: apakah jawaban yang salah murah dibatalkan? Syarat ini yang paling sering dilewati tim. Kalau model mengirim tiket ke antrean yang salah, manusia mengambilnya lima menit kemudian — murah. Kalau model memberi tahu pelanggan bahwa transaksinya gagal padahal berhasil, Anda punya insiden dukungan dan masalah kepercayaan — mahal. Kesalahan yang murah adalah yang memungkinkan Anda meluncurkan sistem yang belum sempurna dengan sengaja, dan sistem pertama selalu belum sempurna.

Susun tiga sampai lima kandidat sebagai baris dan tiga syarat sebagai kolom, lalu beri skor nol sampai dua. Dua artinya syaratnya terpenuhi dan Anda bisa menunjukkan buktinya. Apa pun yang skornya di bawah empat dari enam bukan untuk proyek pertama, betapapun bagusnya sisi lain proyek itu. Gunanya melakukannya di atas kertas: perdebatan selera berubah menjadi daftar fakta bersama, dan orang yang mempertahankan proyek ambisius bisa melihat persis kotak mana yang kosong, bukan sekadar diberi tahu idenya buruk.

Lalu tulis kriteria penerimaan sebelum ada yang membangun. "Draf yang dihasilkan dipakai tanpa perubahan atau hanya disunting ringan, minimal tujuh dari sepuluh kali" adalah kriteria. "Akurasi di atas 91%" biasanya bukan, karena belum ada yang melabeli cukup contoh untuk tahu arti akurasi di konteks ini, dan angkanya akan dipilih agar cocok dengan hasil apa pun yang keluar. Kriteria yang baik adalah kalimat yang bisa diperiksa orang operasional minggu depan, dengan pekerjaan nyata di depan mereka.

Kalau Anda bisa menyebut orang yang akan memeriksa kriteria itu, dan minggu kapan ia memeriksanya, use case-nya sudah terlingkupi. Kalau tidak bisa, kembali ke daftar kandidat. Di pekerjaan saya sendiri di FINETIKS, proyek yang lolos saringan ini adalah proyek yang keputusan manusianya tetap berada di dalam loop sejak hari pertama — otomasi yang menghapus mengetik, bukan menghapus penilaian.