InfraLoka AcademyPathwayAI
PathwayAI

Modul 7 · Sambungkan dan otomasi

Kapan sebaiknya tidak mengotomasi

5 menit baca5 menit bacaDitinjau 26 Oktober 2026

Intinya

Otomasi cocok untuk tugas yang sering, murah bila salah, dan bisa dibatalkan. Sisanya: AI menyiapkan, manusia memutuskan. Taruh titik periksa sebelum efek yang tidak bisa ditarik, dan periksa hasil akhirnya. Laporan sukses belum membuktikan apa-apa.

Setelah pelajaran ini kamu bisa

  • Menilai tugas dari seberapa sering, akibat salah, dan bisa tidaknya dibatalkan
  • Menempatkan titik periksa manusia di alur otomasi
  • Mengenali tanda otomasi yang gagal tanpa suara

Istilah di pelajaran ini

Pahami

Otomasi artinya sebuah langkah berjalan sendiri tanpa kamu menekan tombol setiap kali: setiap email masuk dikategorikan, setiap formulir diringkas, setiap pagi laporan dibuat. Dengan AI, godaannya besar, karena hampir semua hal terasa bisa diotomasi. Sebelum memulai, nilai tugasnya dengan tiga pertanyaan:

  1. Seberapa sering? Tugas yang terjadi puluhan kali sehari menghemat banyak waktu bila diotomasi. Tugas yang terjadi dua kali setahun jarang sepadan dengan usaha membangun dan merawat otomasinya.
  2. Seberapa mahal bila salah? Salah memberi label folder pada email itu murah. Salah mengirim surat peringatan, salah menolak klaim, atau salah membayar vendor itu mahal, dan sering menyangkut orang.
  3. Bisa dibatalkan atau tidak? Label yang salah bisa diganti. Email yang sudah terkirim, uang yang sudah keluar, dan data yang sudah terhapus tidak bisa ditarik kembali.

Tugas yang sering, murah bila salah, dan bisa dibatalkan adalah calon otomasi yang baik. Begitu salah satu jawabannya buruk, ubah polanya menjadi AI menyiapkan, manusia memutuskan: AI membuat draf, kategori, atau usulan; manusia memeriksa dan menekan tombol. Untuk keputusan yang berdampak signifikan pada orang, ada juga hak hukum mereka yang perlu diperhitungkan; itu dibahas di pelajaran keputusan otomatis dan hak orang.

Satu tanda tambahan: kalau aturannya penuh pengecualian ("biasanya begini, kecuali klien lama, kecuali bulan Desember, kecuali ada surat dari direksi"), otomasi akan sering salah di tempat yang paling tidak terlihat. Mulailah dengan bagian yang aturannya jelas saja.

Kalau sebuah alur tetap diotomasi, tempatkan manusia di beberapa titik yang tepat. Titik periksa di setiap langkah membuat orang lelah, lalu mulai menyetujui tanpa membaca. Titik periksa paling penting ada tepat sebelum efek yang tidak bisa ditarik: sebelum email ke luar terkirim, sebelum pembayaran disetujui, sebelum data dihapus, sebelum keputusan tentang orang dicatat. Titik lain yang berguna adalah antrean pengecualian, tempat kasus yang tidak cocok dengan aturan atau yang membuat AI ragu masuk untuk ditangani manusia, dan pemeriksaan sampel, misalnya membaca sepuluh hasil acak setiap minggu.

Kegagalan yang berisik cepat ketahuan karena ada pesan error (galat) atau orang yang protes. Yang berbahaya adalah kegagalan yang diam: otomasinya tetap jalan, tetapi hasilnya tidak sampai. Tandanya:

  • Laporan selalu "berhasil", tetapi tidak ada yang memeriksa hasil akhirnya.
  • Jumlah yang diproses tiba-tiba turun ke nol, atau tidak berubah selama berhari-hari.
  • Tidak ada keluhan, karena orang yang seharusnya menerima hasilnya tidak menerima apa-apa.
  • Hasilnya persis sama setiap hari, padahal datanya berubah.

Periksa keadaan akhir: apakah email itu sampai di kotak masuk penerima, apakah angka di sistem tujuan berubah. Laporan prosesnya bisa saja bilang sukses. Catat setiap langkah otomasi dalam log audit supaya kamu bisa menelusuri apa yang terjadi, dan pasang peringatan bila dalam sehari tidak ada yang diproses.

Semua ini makin penting saat yang diotomasi adalah agen AI (AI agent), yaitu AI yang boleh memakai alat dan memutuskan langkah berikutnya sendiri. Agen bisa menjalankan puluhan langkah dalam beberapa menit, jadi satu salah paham di langkah awal bisa berlipat sebelum ada yang melihat. Prinsip manusia dalam kendali di sini berarti tiga hal yang konkret: agen berhenti dan meminta persetujuan sebelum tindakan yang tidak bisa dibatalkan, setiap langkahnya tercatat sehingga bisa ditelusuri, dan orang yang menyetujui membaca apa yang akan terjadi sebelum menekan tombol setuju. Persetujuan yang diberikan tanpa membaca sama saja dengan tidak ada titik periksa.

Contoh

Sebelum

Permintaan

Buat alur otomatis: setiap email keluhan pelanggan yang masuk dibaca AI, AI membalas dengan solusi, lalu tiketnya ditutup.

Hasilnya

Alur dibuat. Contoh balasan otomatis: "Mohon maaf atas ketidaknyamanannya. Kami akan mengembalikan dana Anda secara penuh dalam 3 hari kerja." Tiket ditutup.

Sesudah

Permintaan

Saya ingin merancang alur keluhan pelanggan yang memakai AI, dengan manusia tetap memutuskan. Tujuan: tim layanan menjawab lebih cepat tanpa menjanjikan hal yang tidak boleh dijanjikan. Alur yang saya mau: AI membaca email keluhan, memberi kategori, dan menulis draf balasan berdasarkan panduan layanan yang saya tempel. Draf masuk antrean; petugas membaca, mengubah bila perlu, lalu mengirim. Batas: draf tidak boleh menjanjikan pengembalian dana, kompensasi, atau tanggal. Keluhan yang menyebut pengembalian dana, hukum, atau kesehatan masuk antrean khusus tanpa draf. Cek: setiap hari ada laporan jumlah email masuk, jumlah draf, dan jumlah yang dikirim petugas. Tulis alurnya langkah demi langkah dan tandai setiap titik periksa manusia.

Hasilnya

1. Email masuk, AI memberi kategori (pengiriman, produk, tagihan, lainnya). 2. Bila menyebut pengembalian dana, hukum, atau kesehatan: masuk antrean khusus, tanpa draf. [TITIK PERIKSA: petugas senior] 3. Selain itu: AI menulis draf dari panduan layanan, tanpa janji dana atau tanggal. 4. Draf masuk antrean. [TITIK PERIKSA: petugas membaca, mengubah, mengirim] 5. Tiket ditutup oleh petugas setelah pelanggan menjawab atau tujuh hari tanpa jawaban. 6. Laporan harian: masuk, draf, terkirim. Peringatan bila draf ada tetapi terkirim nol.

Yang berubah

  • Versi pertama menjanjikan pengembalian dana penuh atas nama perusahaan, terkirim tanpa dibaca siapa pun, dan tidak bisa ditarik.
  • Alur yang lebih baik mengotomasi bagian yang murah bila salah (kategori, draf) dan menaruh manusia sebelum efek yang tidak bisa dibatalkan (mengirim).
  • Laporan harian dan peringatan "terkirim nol" menangkap kegagalan yang diam.

Kesalahan umum

Kesalahan
Menganggap otomasi berjalan baik karena statusnya selalu "berhasil".
Kenapa merugikan
Status hanya berarti proses selesai tanpa error yang terdeteksi. Hasilnya belum tentu benar atau sampai. Langkah bisa terlewat, data bisa kosong, dan pesan bisa tidak terkirim sementara status tetap hijau, seperti di kasus pelajaran ini, berminggu-minggu sebelum ada yang sadar.
Lakukan ini
Tambahkan satu pemeriksaan keadaan akhir di ujung setiap otomasi: hitung yang sampai atau berubah di sistem tujuan, bandingkan dengan yang masuk, dan baca beberapa hasil acak setiap minggu.

Coba

Kartu pilah

Untuk setiap tugas, pola mana yang paling tepat?

  1. Membuat ringkasan notulen rapat untuk diperiksa

  2. Mengirim surat teguran ke karyawan

  3. Memasukkan diagnosis ke rekam medis pasien

  4. Mengingatkan tenggat tugas tim setiap Senin

  5. Menyetujui pembayaran tagihan vendor

  6. Memberi label kategori pada email masuk

6 kartu lagi

Ini alur otomasi pengiriman tagihan bulanan. Baca setiap langkah dan pikirkan di mana titik periksanya.

Langkah 1 dari 5

AI menyusun tagihan dari data pemakaian

Murah bila salah selama belum terkirim. Belum perlu titik periksa.

Bawa pulang

Sebelum mengotomasi satu langkah

  • Tugas ini sering, murah bila salah, dan bisa dibatalkan
  • Aturannya jelas, tanpa banyak pengecualian
  • Ada titik periksa manusia sebelum setiap efek yang tidak bisa ditarik
  • Ada antrean pengecualian untuk kasus yang tidak cocok
  • Keadaan akhir diperiksa dan dicatat; status "berhasil" saja tidak cukup

Yang salah di tempat kami

Insiden, Oktober 2026

Pipeline hijau yang tidak mengganti apa pun

Konteks
Pipeline deploy kami mencadangkan database, lalu mengganti kontainer aplikasi dengan versi baru.
Yang terjadi
Langkah cadangan salah membaca input dan ikut menelan sisa skrip. Langkah penggantian kontainer tidak pernah berjalan, tetapi pipeline tetap melapor sukses.
Dampaknya
Beberapa rilis yang dianggap sudah live ternyata belum terpasang.
Akar masalah
Skrip tidak berhenti saat satu langkah gagal, dan tidak ada yang memeriksa versi yang sedang berjalan setelah deploy.
Yang kami lakukan
Langkah cadangan diperbaiki agar tidak membaca input skrip, dan rilis yang tertunda dipasang ulang. Satu aplikasi diserahkan ke pemiliknya untuk di-deploy ulang.
Pengaman yang kami pasang
Setiap langkah memeriksa kode keluarnya, dan pipeline diakhiri dengan memeriksa versi image yang sedang berjalan.

PelajarannyaHijau berarti skrip selesai; periksa sendiri bahwa perubahannya terpasang.

Artinya untuk kerjamuLaporan "berhasil" dari otomasi belum tentu berarti hasilnya sampai. Periksa hasil akhirnya sendiri, misalnya apakah email sampai ke kotak masuk penerima.