Mengapa demo belum berarti penerapan

Bayangkan demo yang membaca contoh faktur, mengambil nilainya, lalu mencatat ringkasan yang rapi dalam sistem persetujuan. Dalam proses sebenarnya, faktur datang melalui tiga saluran, sebagian milik badan hukum lain, dan sistem persetujuan hanya menerima pengguna dengan peran tertentu. Ekstraksinya tetap berfungsi. Alur kerjanya tidak. Ini contoh ilustratif, bukan laporan pelanggan.

Sebuah pembahasan tentang penerapan AI dalam sistem bisnis lama menyoroti data, perangkat lunak yang sudah ada, dan kebiasaan lokal sebagai bagian penerapan yang sulit. Narasumber menggambarkan praktik satu perusahaan, bukan tingkat keberhasilan umum. Pembedaan yang berguna adalah antara membuktikan satu komponen dan menggunakannya dalam pekerjaan.

Demo memilih lingkungannya sendiri

Demo dapat memilih masukan yang bersih. Akun bisa diberi izin lebih dahulu, antrean dilewati, proses yang gagal diulang dari awal, dan pembuatnya menjelaskan keluaran yang ambigu. Pilihan itu wajar untuk membuktikan kemampuan. Pilihan itu menjadi berbahaya saat tim menganggap uji kemampuan sebagai bukti kesiapan operasional.

Dalam contoh faktur, ekstraksi hanya satu langkah. Organisasi harus menentukan kotak masuk mana yang menjadi rujukan utama, cara mendeteksi duplikat, apakah nilai dapat berubah setelah diajukan, siapa yang boleh menyetujui, dan ke mana faktur yang gagal dicatat dalam sistem persetujuan diarahkan. Ringkasan yang dihasilkan tidak dapat menjawab pertanyaan tersebut hanya dengan bahasa yang lebih fasih.

Batasnya paling mudah terlihat jika satu item pekerjaan diikuti dari kedatangan hingga hasil yang diterima:

Kemampuan demo masukan yang disiapkan

Integrasi lokal data izin pemulihan

Alur kerja operator hasil yang diterima

Kemampuan yang didemonstrasikan baru menjadi pekerjaan yang berguna ketika data lokal, izin, dan pemulihan menghubungkannya dengan alur kerja operator yang nyata.

Tahap	Pertanyaan demo	Pertanyaan penerapan
Masukan	Bisakah model membaca contoh ini?	Bisakah model menerima semua format yang diizinkan dan menolak sisanya?
Konteks	Bisakah model menemukan nilainya?	Bisakah model mencocokkan pemasok, badan hukum, dan versi kebijakan yang tepat?
Tindakan	Bisakah model membuat ringkasan?	Bisakah model hanya melakukan tindakan yang diizinkan dan menghindari duplikat?
Kegagalan	Bisakah penyaji mencoba lagi?	Siapa yang melihat item macet, memperbaikinya, dan melanjutkan dengan aman?
Penggunaan	Apakah keluarannya tampak berguna?	Apakah penanggung jawab memakai dan mempercayainya dalam antrean nyata?

Perbandingan ini bersifat konseptual. Ini tidak menyiratkan angka kegagalan terukur bagi proyek AI.

Telusuri keadaan lokal

Integrasi data sering disebut tahap terakhir, seolah-olah hanya kabel yang dipasang setelah produk selesai. Model data lokal justru dapat mengubah makna produk. Satu bisnis mungkin menganggap faktur “diterima” saat tiba di kotak masuk; bisnis lain baru menganggapnya diterima setelah cocok dengan pesanan pembelian. Jika sistem bertindak berdasarkan keadaan yang salah, panggilan API yang sah secara teknis tetap dapat menjadi kesalahan bisnis.

Tanyakan dari mana setiap fakta berasal dan siapa yang bisa memperbaikinya. Lalu tanyakan apa yang dilakukan sistem ketika fakta-fakta bertentangan. Jika catatan sumber berubah setelah model menyusun draf persetujuan, haruskah draf itu dibatalkan? Jika izin dicabut saat tugas masih dalam antrean, apakah pekerja sistem memeriksanya lagi sebelum bertindak? Pertanyaan-pertanyaan inilah inti penerapan, bukan sekadar pemolesan.

Artikel tentang menemukan alur kerja memulai lebih awal dengan mengamati apa yang sungguh dilakukan operator. Di sini pertanyaannya adalah kondisi apa yang harus terpenuhi agar kemampuan dalam demo tetap bekerja saat bertemu alur kerja tersebut.

Buat prototipe kemampuan, lalu uji alur kerja

Prototipe kecil dapat menjadi cara tercepat untuk mengetahui apakah model mampu mengerjakan tugas intinya. Pada hari pertama, prototipe itu tidak harus memiliki seluruh pengendalian produksi. Kesalahannya adalah menjadwalkan pekerjaan sisanya sebagai penyelesaian kecil tanpa memeriksanya.

Prototipe yang berguna menyatakan batasnya. Misalnya: “Ini membaca contoh faktur yang disetujui, menyarankan kolom, dan tidak melakukan tindakan eksternal.” Pengujian berikutnya dapat memakai catatan langsung yang diizinkan, sementara pengiriman ke sistem persetujuan tetap dinonaktifkan. Baru setelah pencocokan data, izin, dan pemulihan dipahami, sistem boleh menulis ke sistem persetujuan. Setiap langkah menjawab pertanyaan berbeda.

Penerapan juga mempunyai sisi manusia. Orang yang sudah menangani faktur ambigu perlu cara untuk memperbaiki saran, melihat apa yang berubah, dan mengetahui apakah sistem akan mengulangi kesalahan yang sama. Jika alur kerja baru menambah lebih banyak pemeriksaan daripada yang dihilangkannya, pola penggunaan akan menunjukkannya. Jangan menyimpulkan adopsi hanya dari demo yang berhasil.

Gerbang rilis dapat dinyatakan sebagai pertanyaan operasional: bisakah operator lain yang berwenang menyelesaikan dan memulihkan satu item pekerjaan tanpa pembuat demo berada di ruangan? Operator itu harus bisa menemukan masukan asli, melihat tindakan yang diusulkan, mengidentifikasi dasar izinnya, dan mengarahkan kegagalan. Latihan pemulihan penting karena keberhasilan proses pertama tidak menjelaskan apa yang terjadi saat ada duplikat atau penulisan parsial. Panduan menerapkan AI dalam alur kerja yang sudah ada menawarkan kerangka penerapan yang lebih luas. Untuk gerbang ini, pertahankan pengujian yang sempit dan ulangi pada satu pengecualian yang paling mungkin merusak jalur normal.

Hasil yang perlu dihitung bukan keluaran yang dihasilkan. Hasilnya adalah item pekerjaan yang diterima dalam proses nyata, dengan jalur pengecualian yang diketahui. Hingga jalur itu berfungsi, demo tetap menjadi bukti berharga tentang satu komponen. Demo belum membuktikan bahwa pekerjaan telah selesai.