Pilot AI dapat memiliki banyak akun aktif, tetapi tetap tidak membantu pekerjaan. Pengguna mungkin membuka aplikasi karena diminta, menyalin jawaban tanpa memeriksa, atau kembali ke cara lama ketika menemukan satu kesalahan. Adopsi pilot AI perlu dinilai dari perilaku penggunaan yang sesuai tugas, termasuk keberanian mengoreksi dan menolak saran, bukan hanya jumlah login.
Bagi sponsor transformasi dan kepala unit bisnis, pertanyaan utamanya adalah apakah orang dapat memakai bantuan AI dengan tepat dalam alur kerja yang sebenarnya. Akurasi model merupakan prasyarat penting, tetapi tidak menjelaskan seluruh hambatan adopsi. Letak tombol, sumber yang sulit dibuka, ketidakjelasan tanggung jawab, dan waktu review dapat menentukan apakah hasil AI benar-benar dipakai.
Definisikan Perilaku Yang Ingin Dilihat
Mulailah dari satu pekerjaan: menyusun ringkasan rapat, memeriksa kelengkapan dokumen, atau menyiapkan respons layanan. Tetapkan apa yang harus dilakukan pengguna sebelum menerima keluaran. Jika tugas mensyaratkan pemeriksaan sumber, klik “terima” tanpa membuka bukti bukan indikator keberhasilan, meskipun jawaban kebetulan benar.
Bedakan empat perilaku: menerima saran yang benar, memperbaiki saran yang sebagian benar, menolak saran yang salah, dan meminta bantuan ketika bukti tidak memadai. Adopsi yang sehat tidak selalu meningkatkan tingkat penerimaan. Pada tugas berisiko, penolakan yang tepat dapat menunjukkan bahwa mekanisme review dipahami.
Pisahkan Hambatan Produk, Data, Dan Organisasi
Pengguna bisa meninggalkan pilot karena jawaban salah, tetapi juga karena harus masuk ke aplikasi tambahan dan menyalin data berulang. Sumber yang tidak dapat dibuka menimbulkan masalah berbeda dari bahasa jawaban yang terlalu panjang. Tanggung jawab yang kabur dapat membuat orang enggan menekan tombol approval meskipun antarmukanya mudah dipakai.
Catat hambatan menurut lapisan: mutu hasil, ketersediaan data, integrasi, antarmuka, pelatihan, dan kebijakan kerja. Tanyakan apa yang terjadi pada tugas terakhir yang gagal, bukan hanya apakah pengguna “suka AI”. Jawaban umum seperti “kurang percaya” perlu ditelusuri ke kejadian yang dapat diperbaiki, misalnya kutipan salah, tanggal kedaluwarsa, atau status transaksi yang berbeda.
Jelaskan Batas Sistem Dengan Bahasa Tugas
Pengguna tidak harus mempelajari seluruh arsitektur untuk bekerja dengan aman. Mereka perlu mengetahui apakah sistem hanya menyarankan, mencari sumber, atau dapat menyiapkan aksi. Chatbot adalah antarmuka percakapan. Workflow automation mengikuti tahapan tetap. AI agent dapat memilih langkah dan tool dalam batas tertentu. Orkestrasi agentic lintas sistem menambah kebutuhan melihat status tindakan dan titik approval.
Penjelasan produk harus konkret: “draf ini belum terkirim”, “saldo dibaca pada waktu ini”, atau “persetujuan diperlukan sebelum perubahan diterapkan”. Label “AI cerdas” tidak memberi petunjuk apa yang masih harus diperiksa. Pastikan penolakan atau pembatalan mudah dilakukan dan tidak menimbulkan kesan bahwa pengguna harus menerima saran untuk dianggap kooperatif.
Amati Tugas, Jangan Hanya Mengirim Survei
Rancang sesi observasi dengan contoh data yang telah disamarkan atau sintetis. Minta peserta menyelesaikan tugas seperti biasa, lalu jelaskan bagian yang mereka periksa. Fasilitator mencatat keraguan, pencarian sumber, koreksi, dan jalan keluar yang dipakai. Hindari memberi petunjuk sebelum peserta mencoba, karena bantuan fasilitator dapat menyembunyikan masalah antarmuka.
Pendekatan yang memperhatikan manusia dan konteks pemakaian sejalan dengan NIST AI Risk Management Framework, yang menempatkan pertimbangan kepercayaan dalam desain, penggunaan, dan evaluasi sistem AI. Kerangka tersebut bersifat sukarela; menyebutnya bukan bukti sertifikasi atau kepatuhan. Rancangan sesi dan metrik di artikel ini adalah usulan operasional yang perlu disesuaikan.
Masukkan Saran Yang Harus Ditolak
Jika seluruh contoh benar, sesi hanya membuktikan pengguna mampu menerima keluaran. Sertakan kasus uji aman dengan sumber tidak cukup, kesalahan kecil yang berdampak, dan permintaan di luar kewenangan. Gunakan lingkungan uji, bukan transaksi nyata. Jelaskan adanya evaluasi serta penggunaan data observasi sesuai kebijakan internal, tanpa menjadikannya penilaian kinerja individual tersembunyi.
Contoh Temuan Yang Mengubah Rancangan
Skenario ilustratif, bukan hasil proyek Layana: tim administrasi menguji asisten pemeriksa dokumen. Peserta dapat menemukan kekurangan dengan benar, tetapi harus membuka tiga layar untuk melihat bukti. Mereka akhirnya menyalin draf ke spreadsheet dan mengerjakan review di luar aplikasi. Dashboard menunjukkan aktivitas tinggi, sedangkan jalur kerja utama belum dipakai.
Respons yang masuk akal adalah memperbaiki akses bukti dan pencatatan koreksi sebelum menambah fitur generatif. Pada sesi berikutnya, ukur apakah pengguna dapat meninjau dokumen dan menyimpan alasan koreksi tanpa membuat catatan terpisah. Jangan menyimpulkan pelatihan kurang hanya karena peserta memilih alat yang lebih praktis untuk menyelesaikan tugas.
Pilih Metrik Dengan Penyebut Yang Jelas
- Penggunaan pada tugas yang sesuai: jumlah tugas layak yang memakai bantuan AI dibagi seluruh tugas layak dalam cakupan pilot.
- Ketepatan review: keputusan menerima, mengoreksi, atau menolak dibandingkan dengan acuan reviewer.
- Beban koreksi: waktu dan jumlah langkah untuk memperbaiki keluaran, dipisahkan menurut jenis kesalahan.
- Keluar dari alur: kasus yang dipindahkan ke alat lain beserta alasan dan konsekuensinya.
- Pelaporan masalah: apakah pengguna bisa melaporkan kesalahan dan memperoleh status tindak lanjut yang jelas.
Laporkan jumlah observasi dan kelompok tugas, bukan persentase tanpa konteks. Pilot kecil dapat memberi sinyal perbaikan, tetapi belum membuktikan adopsi seluruh organisasi. Pisahkan pengguna baru dari yang sudah terlatih, serta tugas rutin dari exception. Target perlu disepakati sebelum evaluasi agar keberhasilan tidak didefinisikan ulang setelah melihat hasil.
Jangan Menjadikan Koreksi Sebagai Hukuman
Jika setiap penolakan dianggap menghambat inovasi, pengguna dapat menerima keluaran untuk memenuhi target. Buat jalur feedback yang menjelaskan apa yang diperbaiki, siapa pemiliknya, dan kapan peserta dapat mencoba kembali. Sponsor perlu menyampaikan bahwa melaporkan kesalahan merupakan bagian dari penggunaan yang bertanggung jawab.
Batasi data observasi pada kebutuhan evaluasi. Hindari merekam informasi pribadi atau layar di luar tugas yang disepakati. Catatan penggunaan tidak otomatis layak menjadi dasar keputusan ketenagakerjaan. Nilai temuan pada desain proses, produk, dan dukungan kerja; keputusan individual yang berdampak harus mengikuti kebijakan serta kewenangan tersendiri.
Gunakan Gerbang Perluasan Yang Bisa Diperiksa
Sebelum memperluas pilot, pastikan pengguna mampu menemukan bukti, memahami batas aksi, dan mengoreksi kesalahan material. Pastikan pula tim dukungan dapat menanggapi laporan. Penggunaan tinggi dengan review yang lemah belum layak diperluas. Sebaliknya, penggunaan rendah akibat integrasi yang merepotkan mungkin membutuhkan perbaikan alur, bukan penggantian model.
Temuan adopsi melengkapi pengukuran manfaat AI dengan baseline dan gerbang keputusan untuk menghentikan pilot. Ketiganya menjawab pertanyaan berbeda: apakah dipakai dengan tepat, apakah bermanfaat, dan apakah masih layak dilanjutkan. Jangan mengganti salah satunya dengan metrik login.
Brief Untuk Menguji Adopsi
Siapkan satu tugas prioritas, kelompok pengguna, contoh keluaran yang benar dan salah, sumber bukti, serta batas tindakan sistem. Tetapkan fasilitator dan reviewer acuan. Jadwalkan pengujian ulang pada masalah yang diperbaiki, sehingga laporan tidak berhenti pada daftar keluhan tanpa bukti perubahan.
Rancang evaluasi adopsi pilot AI bersama Layana.ID dengan memetakan pekerjaan, integrasi, dan perilaku review yang dibutuhkan. Diskusi implementasi AI bisnis sebaiknya mencakup cara pengguna bekerja serta ukuran penerimaan, selain pilihan model dan teknologi.
Gambar utama merupakan ilustrasi AI, bukan dokumentasi sesi riset atau proyek klien Layana.ID.