Tim kecil hanya punya satu agen, perlukah memasang ini semua?

Lapis penelusuran perlu, evaluasi dan tata kelola bisa nanti. Minimalnya adalah menyimpan input, panggilan alat, dan output tiap eksekusi agen, memakai basis data atau log cloud pun bisa. Kalau ini tak dilakukan, pada hari terjadi masalah Anda tak punya petunjuk apa pun. Evaluasi dan control plane biasanya baru sepadan saat jumlah agen melampaui tiga, atau mulai menyentuh data pelanggan.

Kenapa tak bisa hanya mengandalkan panel back-end pemasok LLM?

Panel pemasok hanya melihat lapis "memanggil model", tak melihat keputusan apa yang dibuat agen Anda sebelum memanggil model dan alat apa yang dipicunya setelahnya. Masalah agen kemungkinan besar ada pada logika orkestrasi alih-alih respons model, jadi hanya melihat log model sama dengan hanya melihat puncak gunung es.

Berapa lama data penelusuran harus disimpan?

Bergantung industri Anda. Produk SaaS umum 30 sampai 90 hari cukup untuk sebagian besar kebutuhan debug; keuangan dan kesehatan yang terregulasi harus mengikuti tuntutan otoritas, bisa jadi beberapa tahun. Perhatikan bahwa data penelusuran sering mengandung data pribadi, jadi masa penyimpanan dan strategi de-identifikasi harus direncanakan bersamaan, tak boleh disimpan tanpa batas.

Bagaimana memulai evaluasi agar tak jadi formalitas?

Mulai dari satu kasus kegagalan nyata. Simpan input nyata dari agen yang salah menjawab minggu lalu, tambahkan jawaban yang benar, itulah data uji pertama Anda. Setelah terakumulasi 20 sampai 50, jalankan sekali tiap kali mengubah prompt atau mengganti model. Set uji yang tumbuh dari kegagalan nyata jauh lebih berguna daripada merancang 500 soal sejak awal.

Setelah Agen AI Naik Produksi, Siapa yang Mengawasinya? Dashboard Tiga Lapis: Observabilitas, Evaluasi, dan Control Plane

Perusahaan Indonesia tahun ini mulai mendorong agen AI ke lingkungan produksi, lalu menabrak masalah yang sama: saat terjadi masalah tak tahu cara menelusurinya. Tulisan ini membongkar tiga lapis alat yang terbentuk pada 2026 — penelusuran, evaluasi, tata kelola saat eksekusi — serta menjelaskan skala mana yang harus memasang lapis mana.

Pukul sembilan pagi, kepala teknologi sebuah e-commerce di Jakarta membuka Slack, melihat pesan yang dikirim divisi layanan pelanggan tadi malam: ada pelanggan berkata AI layanan pelanggan menjanjikan pengembalian penuh ongkos kirim, padahal kebijakan perusahaan jelas hanya potongan setengah. Ia ingin memeriksa catatan, lalu menemukan hal yang sangat memalukan — mereka hanya menyimpan balasan terakhir percakapan, sedangkan alat apa yang dipanggil agen di tengah, data apa yang dilihatnya, kenapa ia mengambil keputusan itu, semuanya tak tersimpan.

Ini bukan masalah satu perusahaan. Pada paruh pertama 2026, ada sekelompok perusahaan Indonesia yang mendorong agen AI dari POC ke lingkungan produksi, lalu bersama-sama menabrak tembok yang sama: agen sudah bisa mengambil keputusan, tetapi tak ada yang bisa melihat bagaimana ia memutuskan.

Latar Belakang

Dua tahun terakhir, bentuk aplikasi AI berubah. Pada 2024 yang dibuat orang adalah chatbot, masukkan satu kalimat keluar satu kalimat, salah tinggal tanya ulang, biayanya pengguna mengetik beberapa kata lagi. Pada 2026 yang dibuat orang adalah agen: ia memanggil API, menulis ke basis data, mengirim email ke pelanggan, membelanjakan uang untuk layanan.

Karena itu biaya kesalahan benar-benar berbeda. Chatbot salah menjawab itu memalukan, agen salah bertindak itu kerugian.

Pasar alat pun ikut terbelah. Product Hunt pada Agustus 2026 dalam sepekan saja memunculkan tiga produk terkait — Traccia membuat control plane agen, Lenz membuat API pemeriksa fakta independen, bitdrift membuat observabilitas real-time sisi mobile. Ini bukan kebetulan, melainkan kebutuhan yang sama mengapung di sudut-sudut berbeda.

Poin Utama: Dashboard Tiga Lapis

Mengamati sekelompok alat ini, bisa dirapikan menjadi tiga lapis. Masalah yang diselesaikannya berbeda, dan saat yang tepat untuk memasangnya juga berbeda.

Lapis pertama: penelusuran (Tracing)

Mencatat setiap langkah eksekusi agen — input apa yang diterima, penalaran apa yang dilakukan, alat mana yang dipanggil, hasil apa yang didapat, berapa kali mencoba ulang, dan output akhirnya apa.

Kata kunci lapis ini adalah "lengkap". Hanya mencatat hasil akhir tak berguna, karena masalah agen kemungkinan besar ada di tengah. SDK Traccia dibangun di atas OpenTelemetry, justru agar data ini bisa menyambung ke sistem observabilitas yang sudah dimiliki tim, alih-alih menambah satu pulau lagi.

Lapis kedua: evaluasi (Evaluation)

Punya satu set data uji tetap dan penilai, dijalankan sekali setiap ada perubahan, lalu didapat skor yang bisa dibandingkan.

Lapis ini menyelesaikan "saya mengubah prompt, jadi lebih baik atau lebih buruk". Tim tanpa evaluasi mengubah prompt sepenuhnya berdasarkan feeling, dan saat mengubah sampai versi kelima sudah tak ada yang ingat versi kedua sebenarnya lebih baik.

Lapis ketiga: tata kelola saat eksekusi (Runtime Governance)

Mencegat tepat saat agen bertindak: melarang memanggil layanan eksternal tertentu, menghentikan bila melampaui batas biaya, output harus lolos pemeriksaan baru dilepas, aksi berisiko tinggi butuh persetujuan manusia.

Beda lapis ini dari dua lapis sebelumnya adalah "sebelum kejadian" versus "sesudah kejadian". Penelusuran dan evaluasi sama-sama melihat ke belakang, sedangkan tata kelola mencegat saat itu juga. Agen yang menyentuh uang dan data pelanggan, lapis ini tak boleh dihemat.

Analisis Dampak Pasar

Bagi pengguna di Indonesia

Pengguna umum tak akan langsung menyentuh alat-alat ini, tetapi akan merasakan bedanya. AI layanan pelanggan yang punya lapis tata kelola tak akan asal menjanjikan hal yang tak bisa dipenuhi perusahaan; yang tidak punya, Anda akan melihat sengketa "AI layanan pelanggan menjanjikan refund tetapi perusahaan tak mengakui" seperti di berita.

Konsumen Indonesia bisa memperhatikan satu sinyal: saat layanan AI perusahaan bermasalah, seberapa cepat ia bisa memberi Anda penjelasan konkret. Yang bisa menjawab "kami menemukan sistem salah menilai pada suatu langkah" berarti back-end-nya menyimpan catatan; yang hanya berkata "ini masalah sistem" kemungkinan besar tak menyimpan apa pun.

Bagi penerapan di perusahaan

Urutan perusahaan Indonesia menerapkan tiga lapis ini, menurut saya seharusnya begini:

Penelusuran didahulukan, dan kerjakan sekarang. Biaya lapis ini paling rendah — cara paling sederhana adalah menulis konteks lengkap tiap eksekusi agen ke satu tabel data, alat pun tak perlu dibeli. Yang benar-benar mahal adalah tak punya catatan pada hari terjadi masalah.

Evaluasi dibangun sebelum agen ketiga naik produksi. Satu-dua agen masih tertahankan dengan pemeriksaan manual, tiga ke atas mustahil. Dan set data evaluasi harus tumbuh dari kasus kegagalan nyata, ini butuh waktu terakumulasi, jadi terlalu telat memulai akan tak keburu.

Tata kelola diterapkan saat menyentuh uang atau data pribadi. Kalau agen Anda hanya membantu merapikan dokumen internal, lapis tata kelola adalah investasi berlebihan; kalau ia mengirim pesan ke pelanggan, mengoperasikan pesanan, mengakses data pribadi, maka itu biaya wajib.

Soal biaya harus siap secara mental: penelusuran lengkap menghasilkan volume data yang cukup besar, dan penyimpanan serta kueri sama-sama butuh uang. Dalam praktik kebanyakan tim memakai strategi berlapis — eksekusi normal hanya menyimpan ringkasan, eksekusi anomali menyimpan konteks lengkap.

Ada satu hal yang khususnya harus diperhatikan perusahaan Indonesia: data penelusuran biasanya mengandung data pribadi. Isi pertanyaan pelanggan, informasi pesanan, dan kontak semuanya tercatat lengkap. Masa penyimpanan, region penyimpanan, dan strategi de-identifikasi harus direncanakan saat penerapan, bukan ditambal belakangan.

Bagi pengembang

Dalam pemilihan alat ada dua titik penilaian.

Pertama, "terikat vendor atau tidak". Kalau hari ini Anda memakai OpenAI dan tahun depan mungkin ganti Anthropic atau model open source, memilih alat yang netral-vendor lebih aman. Traccia mengunggulkan vendor-neutral inilah nilai jualnya, dengan konsekuensi ia baru diluncurkan pada 2026 dan kematangannya belum menyamai pelopor seperti Langfuse dan LangSmith.

Kedua, "open source atau tidak". SDK open source berarti sebelum menerapkan Anda bisa melihat sendiri kolom apa saja yang dikumpulkannya dan dikirim ke mana. Bagi industri yang audit keamanannya ketat (keuangan, kesehatan), ini sering jadi kunci lolos atau tidak.

Cabang lain yang patut dicermati adalah verifikasi output. Pemikiran API pemeriksa fakta independen seperti Lenz sangat menarik — ia bukan membiarkan model yang sama memeriksa dirinya sendiri, melainkan memakai model vendor pesaing untuk berdebat silang. Ini menyelesaikan titik buta mendasar dari pemeriksaan-diri: model tak bisa melihat kesalahannya sendiri, karena kesalahan itu adalah kognisinya sendiri.

Tren Perkembangan ke Depan

Menurut saya setahun ke depan tiga hal akan terjadi.

Penelusuran akan jadi standar, bukan item tambahan. Seperti setelah 2015 tak ada yang bertanya "perlu memasang APM atau tidak", framework agen itu sendiri akan menyertakan penelusuran bawaan, dan persaingan vendor alat beralih ke lapis analitik dan tata kelola.

Evaluasi akan bergeser dari "mengejar skor" menjadi "menjalankan kasus nyata". Sekarang banyak alat evaluasi punya bank soal bawaan yang umum dan akademis, yang tak bermakna dalam praktik. Yang benar-benar berguna adalah 50 kasus komplain pelanggan Anda sendiri. Alat akan bergerak ke arah "membantu Anda otomatis mengubah kasus kegagalan menjadi set uji".

Tata kelola akan didorong regulasi. Kewenangan penegakan Undang-Undang AI Uni Eropa resmi aktif pada Agustus 2026, dan aturan di wilayah lain juga menyusul. Ketika "Anda harus bisa menjelaskan kenapa AI berbuat begitu" menjadi tuntutan hukum, control plane berubah dari nilai tambah menjadi infrastruktur kepatuhan. Otoritas keuangan dan otoritas data pribadi Indonesia cepat atau lambat akan punya tuntutan serupa, dan persiapan sekarang tak akan sia-sia.

Kesimpulan & Komentar TheAI Academy

Sikap saya soal topik ini sangat langsung: penelusuran itu kewajiban, tata kelola itu pilihan.

Bagaimana akhirnya kepala teknologi e-commerce itu menanganinya? Ia menghabiskan dua hari menulis sepotong program, menulis konteks lengkap tiap eksekusi agen ke PostgreSQL, termasuk input pengguna, parameter dan nilai balik tiap panggilan alat, penalaran tengah model, dan output akhir. Tak membeli alat apa pun, biayanya dua hari kerja.

Sebulan kemudian terjadi lagi sengketa serupa, dan kali ini ia sepuluh menit menemukan akar masalahnya: dokumen kebijakan yang dibaca agen adalah versi lama tiga bulan lalu. Masalah selesai, dan ia tahu yang harus diperbaiki adalah sinkronisasi dokumen, bukan model.

Inilah poin yang ingin saya sampaikan — Anda tak perlu langsung membeli solusi terlengkap sejak awal, tetapi Anda wajib mulai menyimpan data sejak hari pertama. Terlalu banyak tim yang selama tiga bulan menilai alat tak memasang apa pun, lalu pada bulan keempat saat terjadi masalah menemukan tangannya kosong.

Komentar: simpan dulu log-nya, baru bicara mau membeli alat mana. Daripada sempurna tanpa berbuat apa-apa, lebih baik kasar tetapi mulai meninggalkan bukti.

Saran konkret untuk pembaca Indonesia: kalau perusahaan Anda tahun ini punya agen yang akan naik produksi, minggu ini lakukan satu hal — pastikan konteks lengkap tiap eksekusi tersimpan, dan Anda tahu di mana memeriksanya. Hal ini tak butuh anggaran, tak butuh rapat, satu sore selesai. Menunggu sampai membutuhkannya baru mengerjakannya, sudah tak keburu.

Untuk memahami alur pembangunan agen secara lebih lengkap, baca Panduan pembangunan AI Agent; soal sisi keamanan aplikasi LLM, Daftar cek keamanan aplikasi LLM punya item pemeriksaan yang lebih rinci. Untuk mencari alat yang bisa dipakai, kategori framework pengembangan dan infrastruktur di halaman alat sudah dirapikan.

Sumber

Dirangkum dari informasi publik, fitur produk dan harga mengacu pada pengumuman resmi.