Jika Vendor AI Tumbang, Bisnis Bisa Ikut Lumpuh

Intinya: Risiko artificial intelligence (AI), atau kecerdasan buatan, bukan hanya jawaban salah. Jika penyedia model berhenti, menaikkan harga, membatasi akses, atau mengubah syarat data, proses bisnis yang sudah terotomasi bisa kehilangan fungsi inti. Solusinya bukan slogan multi-vendor, melainkan rencana keluar yang benar-benar pernah diuji.

Mengapa kontrak AI berbeda dari pembelian perangkat lunak biasa

Pada perangkat lunak tradisional, organisasi kerap menyimpan aplikasi, database, dan logika bisnis yang relatif stabil. Pada layanan model melalui API, sebagian kemampuan dapat berada di luar kendali pengguna: bobot model, konfigurasi keamanan, pemrosesan konteks, limit pemakaian, serta perilaku setelah pembaruan. Bahkan ketika antarmuka API tetap sama, kualitas keluaran dapat bergeser.

NIST AI Risk Management Framework 1.0 mengajukan fungsi Govern, Map, Measure, dan Manage. Profil khusus AI generatif NIST AI 600-1, terbit 26 Juli 2024, memperluas perhatian pada risiko teknologi generatif. Keduanya kerangka sukarela, bukan sertifikat yang membuktikan pemasok aman. AIGEO menerjemahkan kerangka tersebut menjadi pertanyaan operasional: pekerjaan apa yang berhenti jika layanan hilang, siapa bertanggung jawab, dan berapa lama bisnis bisa bertahan?

Masalah vendor lock-in muncul bukan semata karena satu merek. Integrasi prompt khusus, format function calling, embedding, alat pencarian, aturan keamanan, dan evaluasi internal dapat membuat perpindahan mahal. Organisasi yang menyimpan seluruh pengetahuan kerja sebagai instruksi tak terdokumentasi justru memperbesar risiko migrasi.

Peta kegagalan yang harus dibedakan

Kelima kegagalan ini membutuhkan respons berbeda. Failover otomatis masuk akal untuk layanan ringkasan dokumen berisiko rendah, tetapi tidak boleh diam-diam mengalihkan keputusan medis, kredit, atau layanan publik ke model lain tanpa validasi. Pergantian pemasok dapat mengubah karakter kesalahan dan dasar hukum pemrosesan data.

Untuk pekerjaan penting, organisasi harus menetapkan recovery time objective (RTO), batas waktu layanan boleh terhenti, dan recovery point objective (RPO), batas kehilangan data atau hasil kerja yang dapat diterima. Keduanya perlu disepakati pemilik proses, bukan ditentukan sepihak tim IT.

Simulasi biaya berhenti layanan

Contoh hipotetis: perusahaan memproses 12.000 tiket pelanggan per hari; 40% memerlukan bantuan AI; setiap tiket yang tidak diproses otomatis membutuhkan tambahan 4 menit tenaga manusia; biaya tenaga kerja efektif Rp75.000 per jam. Jika layanan AI hilang selama dua hari, tiket terdampak = 12.000 × 40% × 2 = 9.600. Tambahan jam kerja = 9.600 × 4/60 = 640 jam. Biaya kerja tambahan = 640 × Rp75.000 = Rp48 juta.

Rumus umum: biaya gangguan = volume harian × proporsi bergantung AI × hari gangguan × menit kerja tambahan/60 × biaya per jam. Angka Rp48 juta hanya biaya tenaga kerja pada asumsi contoh, belum termasuk penalti SLA, pelanggan hilang, kesalahan manual, atau biaya memulihkan antrean. Tidak boleh dipakai sebagai proyeksi perusahaan tertentu tanpa data operasionalnya.

Jika biaya membangun fallback Rp180 juta dan diperkirakan menghindari Rp48 juta setiap gangguan dua hari, ambang balik modal sederhana adalah 180/48 = 3,75 kejadian sebanding. Tetapi probabilitas kejadian, tingkat efektivitas fallback, dan nilai waktu uang perlu masuk keputusan investasi. Keamanan operasional bukan sekadar membandingkan dua angka.

Rencana keluar 90 hari yang dapat diuji

Hari 1–15: petakan proses, data, prompt, konektor, API, serta pemilik bisnis. Tandai mana yang benar-benar memerlukan model generatif dan mana yang dapat berjalan dengan aturan deterministik. Buat daftar 20 kasus uji yang mewakili tugas paling penting. Simpan data uji yang telah dianonimkan atau disintesis secara aman.

Hari 16–30: tentukan standar keluaran yang tidak bergantung vendor, seperti JSON Schema yang terdokumentasi, kode error, dan ambang mutu. Jangan menjadikan gaya bahasa model sebagai spesifikasi. Gunakan pemeriksaan otomatis untuk format dan pemeriksa manusia untuk ketepatan substantif.

Hari 31–60: uji pemasok kedua atau proses manual yang realistis. Ukur ketepatan, latency, biaya per tugas selesai, kesalahan berisiko tinggi, serta waktu memulihkan antrean. Lakukan simulasi perubahan model mendadak. Pastikan log audit tidak hanya tersedia di dashboard pemasok.

Hari 61–90: lakukan tabletop exercise yang melibatkan legal, keamanan, operasi, keuangan, dan komunikasi pelanggan. Putuskan siapa berwenang mengaktifkan fallback, kapan otomatisasi harus dihentikan, dan siapa menandatangani penerimaan risiko. Dokumen rencana keluar harus punya tanggal uji terakhir dan hasil yang dapat diaudit.

Klausul kontrak yang sering terlupakan

Perusahaan perlu mengatur pemberitahuan perubahan material, hak ekspor data, waktu penghapusan, lokasi pemrosesan, subprosesor, retensi log, insiden keamanan, dukungan migrasi, batas tanggung jawab, dan perlakuan data ketika kontrak berakhir. Ketersediaan SLA 99,9% sekalipun tidak menjawab apakah perubahan kualitas model bisa merusak proses bisnis.

Ukuran 99,9% berarti toleransi downtime teoritis sekitar 43,2 menit per 30 hari (30 × 24 × 60 × 0,1%). Itu hanya aritmetika persentase, bukan jaminan downtime akan tersebar merata atau berlaku pada semua komponen. SLA perlu diperiksa definisi pengecualian, cara klaim kredit, dan apakah kredit layanan sebanding dengan kerugian operasional.

Organisasi publik Indonesia juga perlu menilai ketentuan pengadaan, perlindungan data pribadi, dan kewajiban pengarsipan. Rencana keluar yang mengabaikan hak akses terhadap dokumen dan rekam keputusan dapat membuat organisasi terjebak sekalipun API teknis mudah diganti.

Uji konsentrasi yang lebih tajam daripada jumlah vendor

Satu perusahaan dapat mengontrak tiga penyedia model tetapi seluruhnya berjalan di cloud yang sama, menggunakan identity provider yang sama, atau mengandalkan satu database vektor. Dalam situasi itu kegagalan satu komponen bersama dapat menghentikan semua pemasok sekaligus. Karena itu inventaris dependensi perlu disusun dalam bentuk graf: proses bisnis → aplikasi → model → API gateway → cloud → jaringan → data. Setiap simpul diberi label pemilik, SLA, dan alternatifnya.

Misalkan terdapat empat proses kritis dengan kontribusi pendapatan masing-masing 40%, 30%, 20%, dan 10%. Jika dua proses pertama bergantung pada satu gateway, konsentrasi risiko pada gateway itu adalah 70% pendapatan terkait proses tersebut. Namun angka itu bukan peluang kehilangan 70% pendapatan; besarnya dampak nyata bergantung pada durasi gangguan, alternatif manual, dan kemampuan menunda pekerjaan. Jangan mencampur ukuran eksposur dengan kerugian yang pasti terjadi.

Indikator tambahan yang berguna ialah persentase proses yang berhasil diselesaikan tanpa model utama dalam uji 24 jam. Jika hanya 30 dari 100 kasus uji kritis dapat dituntaskan melalui fallback, tingkat kelangsungan tugas adalah 30%. Hasil ini harus dipisahkan menurut tingkat risiko, karena keberhasilan merangkum dokumen tidak setara dengan keberhasilan memproses transaksi bernilai tinggi.

Bagaimana dewan direksi membaca risiko AI

Laporan bulanan sebaiknya memuat lima indikator: persentase volume tugas pada pemasok terbesar, tingkat keberhasilan fallback, biaya per tugas yang selesai dengan benar, waktu pemulihan teruji, dan jumlah insiden perubahan model tanpa pemberitahuan yang memengaruhi mutu. Jangan berhenti pada uptime. Sistem dapat tersedia 100% tetapi menghasilkan keluaran salah yang tidak terdeteksi.

Audit kontrak perlu memastikan pelanggan memiliki hak atas hasil kerja dan log yang diperlukan untuk penyelesaian sengketa. Tim legal dan teknologi harus membedakan data yang dimiliki pelanggan dari data pelatihan atau telemetri milik pemasok. Penghapusan data setelah kontrak berakhir perlu disertai bukti proses, bukan hanya janji umum di halaman pemasaran.

Rencana keluar yang baik juga memperhitungkan komunikasi. Jika layanan AI dipakai untuk membalas pelanggan, sistem harus dapat mengalihkan ke antrean manusia dengan penjelasan yang tidak menyesatkan. Jika dipakai untuk rekomendasi keputusan internal, keputusan baru bisa dihentikan sementara sampai kontrol pulih. Tujuannya bukan memastikan AI selalu aktif, melainkan memastikan organisasi tetap dapat bertanggung jawab ketika AI tidak tersedia.

Simulasi risiko gangguan yang berbeda

Dalam skenario sebelumnya, biaya dua hari gangguan dihitung Rp48 juta. Tetapi gangguan selama empat jam pada hari biasa mungkin tidak setara dengan gangguan empat jam saat puncak transaksi. Untuk menguji sensitivitas, misalkan 70% volume harian terjadi dalam delapan jam sibuk. Jika empat jam gangguan tepat menimpa separuh periode sibuk dan volume merata dalam delapan jam itu, transaksi terdampak sekitar 35% volume harian. Bila terjadi di luar jam sibuk, dampaknya bisa jauh lebih kecil. Distribusi trafik nyata harus digunakan sebelum menghitung kerugian.

Organisasi perlu memisahkan tiga biaya: biaya pekerjaan yang tertunda, biaya koreksi akibat keluaran salah, dan kerugian pelanggan atau reputasi. Biaya pekerjaan tertunda bisa dihitung dari jam kerja. Biaya koreksi memerlukan data insiden. Kerugian reputasi tidak boleh diberi angka semaunya lalu dijumlahkan seolah-olah fakta. Lebih baik menampilkan rentang dan asumsi yang dapat diuji.

Perusahaan juga dapat menghitung maximum tolerable downtime untuk tiap proses. Jika layanan harus dipulihkan dalam dua jam, rencana migrasi model selama tiga hari bukan fallback yang memadai. Solusinya mungkin antrean manual, pembatasan fitur, atau sistem aturan sederhana. Rencana cadangan tidak selalu harus berupa model AI kedua.

Rancangan drill satu hari

Pilih hari uji dengan persetujuan pemilik layanan. Matikan akses model utama pada lingkungan staging, bukan produksi tanpa mitigasi. Jalankan 50 kasus yang mewakili variasi tugas, termasuk input tidak lengkap, permintaan berbahasa Indonesia, format dokumen panjang, dan kasus yang harus dieskalasi kepada manusia. Ukur waktu hingga layanan alternatif aktif, persentase kasus selesai, serta jumlah hasil yang memerlukan koreksi.

Gunakan tabel dengan kolom ID kasus, risiko, waktu masuk, waktu selesai, metode fallback, hasil verifikasi, dan catatan kegagalan. Jika 40 dari 50 kasus selesai tetapi seluruh 10 kegagalan berada pada transaksi bernilai tinggi, tingkat keberhasilan 80% tidak cukup untuk menyebut drill sukses. Laporkan distribusi dampak menurut tingkat kritikalitas.

Setelah drill, perbarui daftar ketergantungan dan kontrak. Tetapkan tanggal uji ulang setelah perubahan model atau vendor besar. Jangan menganggap dokumen business continuity selesai hanya karena sudah ditandatangani. Ketahanan adalah kemampuan yang dibuktikan lewat latihan, bukan jumlah halaman kebijakan.

Peran data dan hak kekayaan intelektual dalam exit plan

Model cadangan mungkin bisa menjalankan prompt yang sama tetapi tidak memiliki konteks organisasi karena data retrieval, embedding, atau dokumen pengetahuan berada di layanan pemasok utama. Karena itu backup harus mencakup data sumber, metadata, hak akses, dan prosedur membangun ulang indeks. Jika perusahaan tidak memiliki hak mengunduh data pelanggan dalam format terbuka, strategi migrasi dapat gagal sebelum model kedua diaktifkan.

Perhatikan juga siapa memiliki prompt yang dikembangkan karyawan, fine-tuning, evaluasi internal, dan output yang dipakai sebagai dokumen bisnis. Ketentuan kontrak harus diperiksa untuk tiap artefak. Jangan berasumsi bahwa seluruh artefak otomatis menjadi milik pelanggan atau seluruhnya milik penyedia. Hukum dan kontrak menentukan pembagian hak.

Latihan pemulihan sebaiknya menguji bukan hanya ‘API alternatif menjawab’, tetapi apakah jawabannya bisa ditelusuri ke sumber, memenuhi format sistem, dan tidak mengubah keputusan yang sudah diambil. Satu tugas berhasil dalam demo tidak cukup membuktikan kontinuitas proses. Untuk kasus berisiko tinggi, hasil perlu diperiksa pemilik proses dan petugas kepatuhan sebelum dinyatakan pulih.

Keputusan akhir bagi manajemen

Direksi sebaiknya menetapkan batas maksimum eksposur pemasok dan tenggat uji fallback yang disesuaikan dengan risiko bisnis. Jika proses kritis tidak bisa dipulihkan dalam RTO yang disepakati, jangan memperluas otomasi sebelum kontrol tambahan tersedia. Ukur kembali setelah perubahan model, kontrak, atau infrastruktur. Hasil drill harus masuk daftar risiko korporasi dengan pemilik tindakan yang jelas, bukan berhenti sebagai laporan teknis.

Kesimpulan

Ketahanan AI bukan ditentukan banyaknya logo pemasok dalam presentasi. Ukur ketergantungan per proses, hitung biaya gangguan dengan asumsi terbuka, dan uji perpindahan sebelum krisis. Vendor yang bagus tetap perlu rencana keluar.

Sumber dan bacaan terkait

• NIST AI RMF 1.0
• NIST AI 600-1 Generative AI Profile
• Bacaan AIGEO: Tujuh KPI balik modal AI
• Bacaan AIGEO: Monokultur AI dalam sektor keuangan