Manajer yang bertanggung jawab atas sistem layanan pelanggan itu melihat email eskalasi tersebut sepuluh menit sebelum jam pulang kerja.
Seorang pelanggan bertanya lewat chat, "Bisakah saya sekaligus mengecek pesanan teman saya?" AI customer service Agent yang baru saja diluncurkan perusahaan langsung membalas dengan riwayat pesanan lengkap dan informasi kontak pelanggan lain. Tim keamanan siber langsung mematikan fitur ini dalam dua jam, dan bagian legal meminta laporan insiden: siapa yang menyetujui peluncuran Agent ini? Kenapa Agent ini bisa "melihat" data yang seharusnya tidak boleh diakses?
(Skenario di atas adalah ilustrasi untuk menjelaskan pola umum yang sudah muncul di industri, bukan kasus klien nyata tertentu.)
Ini bukan spekulasi yang dibuat-buat. Bernard Marr, pengamat strategi bisnis, secara langsung menyebutkan dalam podcast tren bisnis dan teknologi yang dipandunya bahwa kejadian semacam ini sudah terjadi di dunia nyata: "Kita sudah melihat AI Agent menghapus data bisnis penting, membocorkan rahasia dagang yang seharusnya tidak dibagikan, hanya karena beberapa mekanisme pengaman belum terpasang, lalu menyerahkan data pelanggan begitu saja." Dalam episode itu, dia mengundang Masimo Merlo dari Elastic untuk membedah akar masalah sebenarnya di balik rentetan kejadian ini โ bukan karena modelnya kurang pintar, melainkan karena perusahaan pada umumnya melewatkan satu bagian penting bernama "context engineering".
Kamu Kira Masalahnya Ada di Model, Padahal Ada di "Fondasi"
Masimo langsung ke intinya: fase eksperimen AI perusahaan sudah berakhir. Kebanyakan organisasi sudah menjalankan pilot, dan sekarang mereka berhadapan dengan kesenjangan yang tidak nyaman antara hasil yang dijanjikan AI dan hasil yang benar-benar diberikan.
Dia menarik penyebabnya ke rentang waktu yang lebih panjang: software perusahaan dibangun berlapis-lapis selama empat puluh sampai lima puluh tahun terakhir โ lapisan data, lapisan context, lapisan logika aplikasi, lapisan pengalaman pengguna. Dan kali ini, AI mengacak dan menyusun ulang semua lapisan itu sekaligus. Kalau perusahaan berpikir cukup "menyambungkan model ke sistem yang sudah ada" lalu duduk menunggu keajaiban terjadi, mereka akan segera sadar bahwa alur data memang tidak pernah dirancang untuk AI, dan mekanisme tata kelola pun tidak bisa mengejar kecepatan ini. Menyambungkan model yang sangat mumpuni ke fondasi yang belum dirapikan bukan menghasilkan transformasi, melainkan โ meminjam istilah Masimo โ "versi masalah lama yang lebih percaya diri". Satu hal yang sangat dikuasai AI adalah memberikan jawaban salah secara sangat efisien ketika diberi informasi yang salah.
Kalau AI Adalah Otak, Context Adalah Ingatannya
Jadi sebenarnya apa yang diselesaikan context engineering? Masimo mengajukan sebuah analogi yang pernah dia dengar dan menurutnya sangat pas: kalau AI adalah otak, context adalah ingatannya. Secepat apa pun otak memproses sesuatu, tanpa ingatan โ tanpa pengalaman, tanpa jalan yang pernah dilalui โ ia tidak bisa memutuskan apa yang harus dilakukan pada momen tertentu.
Hal yang sama berlaku untuk perusahaan: model yang dilatih dengan data publik dari seluruh dunia tidak akan otomatis memahami perusahaanmu โ tidak memahami pelangganmu, kebijakanmu, hal-hal yang pernah terjadi di masa lalu, toleransimu terhadap risiko, atau tujuan yang ingin kamu capai. Ia hanya memproses data dan memberikan jawaban yang terdengar cukup masuk akal, tapi sebenarnya sangat generik. Yang dikerjakan context engineering justru mengubah "menghubungkan data yang tepat, model yang tepat, pada waktu yang tepat" menjadi sebuah disiplin: mendefinisikan apa yang bisa dilihat model, sekaligus membangun guardrail supaya keluarannya layak dipercaya dan bisa langsung dieksekusi.
Dari "Menyebalkan" Menjadi "Berbahaya": Begitu AI Mulai Mengambil Keputusan Sendiri
Masimo secara khusus menyoroti satu titik balik: ketika AI cuma menjawab pertanyaan, jawaban yang salah paling banter jadi masalah kecil yang bisa langsung kamu koreksi; tapi begitu AI berubah menjadi Agent yang bisa merekomendasikan, memutuskan, dan bertindak secara mandiri, sifat dari kesalahan yang sama itu berubah total โ bisa langsung menjelma jadi risiko bisnis, eksposur regulasi, atau insiden keamanan.
Dia memberi dua contoh konkret. Pertama, Agent di Security Operations Center (SOC): Agent ini perlu melihat data ancaman real-time, riwayat insiden masa lalu, dan alur eskalasi yang jelas โ kalau salah satu saja hilang, penilaiannya akan meleset. Kedua, Agent pendeteksi fraud: ia tidak bisa hanya melihat satu transaksi yang sedang terjadi, tapi juga harus tahu riwayat transaksi pelanggan tersebut, kebijakan yang berlaku, ambang batas risiko yang bisa diterima organisasi, siapa yang punya wewenang untuk bertindak, dan jejak bukti seperti apa yang harus ditinggalkan setelahnya. Kalau semua itu dihilangkan tapi Agent tetap diberi wewenang penuh untuk bertindak, yang kamu dapat bukan Agent dengan "kemampuan terpotong", melainkan benar-benar sebuah liabilitas โ inilah logika yang mendasari insiden Agent customer service di pembuka artikel ini.
Kenapa "Memindahkan Semua Data ke Sebelah Model" Itu Jebakan
Mengikuti logika ini, wawancara berlanjut membahas peran data real-time. Pernyataan Masimo sangat lugas: sebuah sistem AI hanya sesegar data yang bisa ia lihat. Kalau keputusan didasarkan pada gambaran dunia dari dua tahun lalu, atau bahkan lebih lama, jawaban yang dihasilkan bukan sekadar "kurang berguna", tapi benar-benar salah.
Reaksi refleks banyak perusahaan adalah memindahkan semua data secara terpusat ke dekat model, tapi menurut Masimo ini tidak realistis dalam praktiknya โ volume data perusahaan terlalu besar, terlalu sensitif, dan terlalu tersebar untuk terus-menerus dipindah-pindahkan. Cara yang lebih cerdas adalah membiarkan AI mendapatkan akses real-time yang diatur dan bisa dipercaya di tempat data itu aslinya disimpan, bukan memindahkan datanya sendiri.
Ini juga menjelaskan kenapa search/retrieval bukannya jadi usang setelah kemunculan generative AI, tapi justru menjadi semakin krusial. Pasar sempat meragukan di awal: kalau model sudah bisa langsung menghasilkan jawaban, buat apa masih perlu retrieval? Masimo bilang kenyataannya justru sebaliknya โ retrieval dan lapisan context adalah infrastruktur yang "menemukan informasi yang tepat, memahami maknanya, dan menyediakannya secara real-time saat AI membutuhkannya". Infrastruktur inilah yang menentukan apakah hasil AI benar-benar layak dipercaya, atau cuma "terdengar meyakinkan".
Hal Pertama yang Dilakukan Context Engineering yang Baik Bukan Memilih Model
Lalu bagaimana penerapannya secara praktis? Masimo mengajukan tolok ukur yang sangat konkret: kesalahan pertama yang paling sering dilakukan proyek AI adalah memperlakukan peluncuran produksi sebagai "masalah model", padahal hampir selalu ini adalah "masalah workflow dan data". Organisasi yang benar-benar melakukannya dengan tepat tidak akan bertanya "model apa yang harus dipakai" terlebih dahulu, melainkan bertanya "apa yang perlu dilihat model ini" โ mulai dari workflow, memahami data apa saja yang dibutuhkan alur kerja tersebut, mendefinisikan izin akses dengan jelas, dan meninggalkan jejak yang bisa dilacak di sepanjang proses, sehingga kamu bisa melihat apa yang sebenarnya dilakukan AI di lingkungan produksi. Tanpa fondasi ini, kata Masimo dengan blak-blakan, yang kamu punya cuma "chatbot yang kelihatan keren".
Bernard dan Masimo sepakat pada poin ini: model itu sendiri tidak membawa keunggulan kompetitif, karena semua orang bisa mengakses model yang kurang lebih sama; yang benar-benar membuat perbedaan adalah kualitas data yang terakumulasi di dalam organisasimu sendiri, dan kemampuanmu untuk merancang ulang workflow. Ini persis menggemakan analogi cloud computing yang disebutkan Masimo sebelumnya โ dulu banyak perusahaan "memindahkan" sistem lama mereka apa adanya ke cloud, berharap masalah selesai dengan sendirinya, tapi hasilnya justru menciptakan lebih banyak masalah. Jebakan yang sama sekarang terulang pada AI: menyambungkan model yang sangat mumpuni ke workflow yang berantakan, lalu menyebutnya sebagai strategi, biasanya hanya berakhir gagal.
Titik Balik: Kamu Sudah Menyelesaikan "Apakah Akan Terjadi Masalah", tapi Mungkin Belum Sadar Sedang Membayar Ongkos Lain
Sepanjang wawancara ini kata "token" sama sekali tidak muncul, tapi di balik cara berpikir context engineering ini tersembunyi sebuah realitas yang tidak bisa dihindari perusahaan mana pun yang mengadopsi generative AI โ ini adalah pengamatan yang kami perluas dari sudut pandang tata kelola Token, bukan perkataan asli narasumber.
Semakin lengkap context yang diberikan โ riwayat, dokumen kebijakan, jejak audit, data real-time โ semakin besar pula jumlah konten yang harus diproses di sisi input pada setiap kali AI dipanggil, dan inilah sumber pemakaian serta biaya Token. Inilah kenapa tata kelola tidak bisa berhenti hanya di dua lapisan "keamanan" dan "akurasi": context yang tidak dirapikan sering kali sama saja dengan menjejalkan semua data yang terpikirkan ke dalamnya, sehingga hasilnya adalah input yang besar dan berantakan, dan setiap kali dipanggil kamu membayar untuk informasi yang berulang, kedaluwarsa, dan tidak relevan; sementara context yang benar-benar dikelola dengan baik โ hanya menyisakan bagian yang benar-benar dibutuhkan tugas saat itu โ biasanya justru lebih ringkas sekaligus lebih presisi. Dengan kata lain, mengerjakan context engineering dengan matang biasanya sekaligus menyelesaikan dua masalah: "apakah jawaban ini bisa dipercaya" dan "berapa biaya yang dikeluarkan untuk pemanggilan ini" โ hanya saja yang kedua lebih mudah terabaikan, karena tagihannya baru dilihat bagian keuangan bulan berikutnya.
Lain Kali Mengevaluasi Proyek AI, Tanyakan Dulu "Apa yang Perlu Dilihat Model Ini"
Perkiraan Masimo untuk tiga sampai lima tahun ke depan: AI perusahaan akan menjadi lebih "agentic", tertanam lebih dalam ke berbagai workflow seperti keamanan siber, observability, customer service, bahkan lini depan dan pengembangan software. Tapi organisasi yang benar-benar akan unggul bukanlah yang paling cepat men-deploy, melainkan yang punya disiplin untuk membangun fondasi โ dasar data, lapisan context, arsitektur tata kelola โ lebih dulu. Dia mengamati pasar sudah terbelah menjadi dua jalur: satu jalur "brute force", terus-menerus memakai pemanggilan model yang mahal dan berulang untuk memaksa menyelesaikan masalah yang sebenarnya bisa diselesaikan dengan lebih cerdas lewat infrastruktur context yang lebih baik; jalur lainnya mencurahkan upaya untuk menggali makna dari data, menjadikan context engineering sebagai prioritas utama, sehingga sistem menjadi lebih akurat dan lebih bernilai seiring waktu, tanpa harus mengulang semuanya dari nol setiap kali. Fondasi jalur kedua ini akan terus mengumpulkan keunggulan seiring waktu, membuat pesaing yang datang belakangan semakin sulit mengejar.
Kembali ke skenario pembuka artikel ini: kalau manajer customer service itu, sebelum fitur diluncurkan, bertanya bukan "apakah Agent ini pintar", tapi "apa yang bisa dilihat Agent ini? Siapa yang menyetujui ia bisa melihat data ini? Apakah hal ini sudah diuji?" โ email eskalasi itu mungkin tidak akan pernah muncul. Pertanyaan ini jauh lebih krusial daripada memilih model yang mana, dan lebih langsung menentukan seperti apa tagihan bulan depan, dibanding yang dikira kebanyakan orang.
Pertanyaan yang Sering Ditanyakan (FAQ)
Q1: Apa itu Context Engineering? Menurut Masimo Merlo dari Elastic dalam wawancara ini, ini adalah disiplin untuk "menghubungkan data yang tepat, model yang tepat, pada waktu yang tepat": mendefinisikan data perusahaan apa saja (riwayat pelanggan, kebijakan, kejadian masa lalu, dan lain-lain) yang bisa dilihat model AI, sekaligus membangun guardrail supaya keluarannya layak dipercaya dan aman untuk langsung dieksekusi.
Q2: Apakah Context Engineering sama dengan RAG (Retrieval-Augmented Generation) yang biasa dibicarakan? Keduanya sangat berkaitan tapi tidak sepenuhnya sama. Retrieval dan lapisan context yang disebutkan dalam wawancara adalah salah satu infrastruktur kunci yang memungkinkan AI mendapatkan data yang tepat secara real-time; tapi cakupan context engineering jauh lebih luas, termasuk desain izin akses, tata kelola data, pemantauan proses, dan pembangunan guardrail โ ini adalah disiplin engineering di level organisasi, bukan sekadar satu teknik tunggal.
Q3: Kenapa AI Agent lebih perlu memperhatikan context dibanding chatbot biasa? Karena kalau chatbot salah jawab, pengguna bisa langsung menyadari dan mengoreksinya saat itu juga, paling banter jadi masalah kecil; tapi ketika AI bisa merekomendasikan, memutuskan, dan bertindak secara mandiri, kesalahan yang sama bisa langsung berubah jadi risiko bisnis, eksposur regulasi, atau insiden keamanan โ dalam wawancara ini disebut sebagai titik balik dari "menyebalkan" menjadi "berbahaya".
Q4: Kalau perusahaan mau mengadopsi Context Engineering, apa langkah pertamanya? Berdasarkan tolok ukur yang diajukan Masimo dalam wawancara, langkah pertama bukan memilih model, melainkan mulai dari workflow: memperjelas data apa saja yang dibutuhkan alur kerja tersebut, mendefinisikan izin akses dengan jelas, dan membuat seluruh prosesnya bisa dilacak, sehingga kamu selalu bisa melihat apa yang sebenarnya dilakukan AI di lingkungan produksi.
Q5: Apakah Context Engineering akan menaikkan atau menurunkan biaya Token AI? Wawancara ini sendiri tidak membahas biaya Token, tapi kalau diperluas, kedua efek sama-sama mungkin terjadi: kalau kamu hanya menjejalkan semua data yang terpikirkan ke dalam context, jumlah konten setiap pemanggilan akan membengkak dan biayanya ikut naik; tapi kalau mengikuti logika di artikel ini โ hanya menyisakan data yang benar-benar dibutuhkan tugas saat itu โ biasanya justru membuat setiap pemanggilan lebih ringkas dan lebih presisi, sekaligus memperbaiki kredibilitas jawaban dan efisiensi biaya.
Pernyataan Sumber Data: Artikel ini ditulis ulang dan diinterpretasikan dari podcast tren bisnis dan teknologi yang dipandu Bernard Marr, episode berjudul "Why Context Is The Missing Piece In Enterprise AI", dengan tamu Masimo Merlo dari Elastic, dipublikasikan pada 2 Juli 2026, dengan jumlah tayangan 79.830 (sumber data: diverifikasi lewat pengujian nyata platform Apify saat transkrip artikel ini diambil, viewCountVerified). Tautan video asli: https://www.youtube.com/watch?v=mNSJC7UEbxc. Deskripsi mengenai definisi "context engineering", studi kasus perusahaan, dan tren masa depan dalam artikel ini semuanya ditulis ulang berdasarkan transkrip wawancara; bagian "Hubungan antara Context Engineering dan Biaya Token" dalam artikel ini merupakan sudut pandang yang diperluas oleh tim editorial AI Token King berdasarkan isi wawancara, bukan perkataan asli narasumber, dan hal ini kami tegaskan di sini.
Bacaan Lanjutan: Kalau kamu penasaran apa itu OpenAI Codex, bedanya dengan ChatGPT atau Claude Code, dan apakah orang non-teknis bisa langsung memakainya, kami pernah membahasnya secara khusus. Ada juga pembahasan tentang kenapa Token AI bisa semahal itu, ditelusuri dari cara kerja "autoregressive" yang membuat coding agent boros biaya. Kalau kamu tertarik pada tren yang lebih besar, ada artikel tentang kenapa software mulai beralih ke skema harga berbasis Token, serta logika pengadaan dan tata kelola biaya di era AI Agent. Dan kalau kamu ingin memahami risiko jangka panjang dari sisi produk, ada juga pembahasan tentang moat AI dan pertanyaan hidup-mati soal produk yang "dimakan" oleh model yang makin kuat.
Memahami "apa yang perlu dilihat model" hanyalah langkah pertama. Pertanyaan berikutnya yang sering terlewat: berapa sebenarnya biaya di balik semua pemanggilan itu? Coba AI Token King gratis (https://aitokenking.com.tw/home) untuk merapikan pemakaian dan biaya berbagai model AI yang kamu gunakan lewat satu API key yang sama ke dalam satu dashboard, supaya kamu tidak perlu menunggu tagihan bulan depan untuk pertama kalinya melihat angka sebenarnya.
