Perubahan Arsitektur yang Diperlukan untuk Mengatur Agen AI

AI tidak lagi hanya sebuah chatbot yang menghasilkan teks. Di lingkungan perusahaan, agen AI melakukan tindakan seperti mengambil data sensitif, memicu alur kerja, memanggil alat, dan mencatat aktivitas di seluruh sistem. Otonomi mengubah seluruh diskusi tentang pengaturan; kontrol dan prosedur yang awalnya dirancang untuk pengguna manusia dan aplikasi tradisional tidak dibangun untuk mengatur perangkat lunak yang dapat mengeksekusi tindakan multi-langkah pada waktu runtime.

Risiko ini tidak teoritis. Celah kecil dalam visibilitas, kontrol akses, dan auditabilitas dapat dengan cepat berkompromi, berubah menjadi kegagalan runtime yang sulit dideteksi dan bahkan lebih sulit untuk dibalik.

Untuk mengikuti era baru ini, mengatur agen AI tidak dapat dilakukan dengan menambahkan lebih banyak dokumen kebijakan. Ini memerlukan pengaturan oleh desain: pendekatan arsitektur di mana kontrol dibangun ke dalam control plane dan ditegakkan terus-menerus pada waktu runtime. Jika agen akan bertindak seperti rekan digital, mereka harus mewarisi guardrails perusahaan yang sama dengan manusia, plus pengawasan runtime yang lebih kuat.

Mengapa pengaturan rusak di era konvergensi

Arsitektur perusahaan telah memasuki era konvergensi. Data dan beban kerja sekarang meliputi beberapa cloud, pusat data pribadi, dan lingkungan edge.

Terdapat organisasi yang menjalankan platform mereka dalam sistem paralel karena mereka memiliki beberapa proses untuk dikelola secara bersamaan. Ini termasuk sistem identitas terpisah, pipa logging, katalog, dan proses yang disetujui. Hasilnya adalah apa yang disebut beberapa orang sebagai “platform Frankenstein,” di mana integrasi overhead meningkat dengan setiap alat atau lingkungan cloud baru. Faktanya, fragmentasi ini muncul dalam kenyataan sehari-hari.

Menurut survei terbaru, 47% responden menyebutkan persyaratan akses yang rumit dan proses, dan 44% menyebutkan visibilitas terbatas ke tempat data berada sebagai hambatan untuk menggunakan data secara efektif.

Inilah tempat di mana agen mengekspos celah antara sistem.

Untuk menjawab pertanyaan bisnis, agen mungkin perlu menarik data dari sistem ERP on-premises, CRM cloud, telemetri operasional di cloud lain, dan dokumen di suite kolaborasi. Jika organisasi menegakkan kebijakan secara berbeda di setiap tempat, agen akan gagal atau, lebih buruk, berhasil dengan cara yang tidak dapat dijelaskan atau dikendalikan.

Inilah saatnya ketika pemimpin perusahaan harus memperhatikan. Agen memaksa batang yang lebih tinggi yang menuntut konsistensi di seluruh lingkungan dan akuntabilitas pada waktu runtime.

Pengaturan, karena alasan ini, sedang ditarik ke sorotan oleh regulator dan lembaga keamanan. Contoh dari ini adalah NIST AI Risk Management Framework, yang menekankan pengelolaan risiko di seluruh siklus hidup AI, bukan hanya pada waktu build. Ini adalah pengingat bahwa kepatuhan dan kepercayaan adalah tanggung jawab operasional, bukan daftar periksa satu kali.

Dari kebijakan ke platform

Pengaturan oleh desain berarti bahwa pengaturan bepergian dengan beban kerja bukan diimplementasikan di setiap silo. Dalam praktek, ini bergantung pada tiga blok bangunan:

• Control plane yang terunifikasi

Satu tempat untuk mendefinisikan dan menegakkan identitas, akses, kebijakan, katalog, dan hak di seluruh cloud dan pusat data.

Tujuannya adalah untuk menulis kebijakan sekali dan menegakkannya di mana pun data dan model berjalan, bukan membangun kembali sistem kontrol sistem per sistem. Ini mencegah perilaku agen berubah, di mana agen yang sama berperilaku aman di satu lingkungan tetapi berbahaya di lingkungan lain.

Tes praktis yang sederhana adalah: jika pengguna tidak dapat mengakses kolom, verifikasi bahwa agen yang bertindak atas nama mereka tidak dapat mengaksesnya juga. Ini harus menunjukkan apakah kebijakan yang ditulis ditegakkan di seluruh pesawat.

• Kain data yang didasarkan pada standar terbuka

Agen memerlukan konteks untuk beroperasi. Ketika konteks tersebut tersebar di struktur yang berbeda dimiliki oleh tim yang berbeda, kain data membantu memstandarisasi semantik dan pola akses, sehingga agen tidak perlu mempelajari set aturan baru untuk setiap dataset.

Format tabel terbuka seperti Apache Iceberg mendukung ini dengan memungkinkan beberapa mesin untuk berbagi data yang dikelola tanpa menyalinnya ke silo baru. Ini penting karena duplikasi data adalah tempat di mana pengaturan biasanya gagal. Setelah tim mulai menyalin “hanya apa yang diperlukan agen,” Anda telah menciptakan lingkungan yang kurang dikelola.

• Observabilitas waktu nyata dan garis keturunan

Agen hanya dapat dikelola jika Anda dapat melihat apa yang mereka lakukan pada waktu runtime.

Observabilitas di sini tidak hanya “nice-to-have,” tetapi adalah dasar untuk kontrol waktu runtime dan respon insiden.

Secara khusus, perlu ada bukti tindakan agen dari ujung ke ujung. Agen harus dapat membuktikan tindakan, seperti data mana yang diakses dan alat mana yang dipanggil, dan dari sana, garis keturunan dapat menghubungkan output kembali ke input. Ini memungkinkan tim untuk mengaudit keputusan dan memecahkan kegagalan, jika perlu, sehingga membuktikan kepatuhan secara keseluruhan.

Perlakukan agen seperti “rekan digital”

Salah satu model mental yang paling berguna adalah memperlakukan agen sebagai rekan digital.

Perbandingan yang memecahkan ini adalah: sama seperti karyawan memiliki kartu akses yang memberikan akses ke beberapa bangunan dan ruangan, tetapi tidak lain, pengaturan memungkinkan agen untuk memiliki akses dengan pembatasan. Satu tambahan kunci adalah bahwa agen harus menyadari situasional apa yang mereka izinkan untuk mengungkapkan.

Pertimbangkan agen dukungan. Mungkin perlu mengakses kasus dukungan sebelumnya untuk memecahkan masalah, tetapi tidak dapat bocor detail pribadi pelanggan lain saat melakukannya. Dengan kata lain, agen dapat menggunakan pengetahuan yang terbatas untuk bernalar, tetapi masih perlu menegakkan batas pengungkapan. Ini bukanlah “masalah penulisan prompt” yang telah kita kenal sebelumnya; ini adalah masalah identitas dan penegakan waktu runtime.

Apa yang berubah pada 2026: agen berpindah dari eksperimen ke produksi

2026 adalah tahun ketika eksperimen berakhir, dan agen mengambil tempat duduk produksi.

Perubahan ini memaksa perusahaan untuk beroperasi pada dua kecepatan. Satu adalah kecepatan inovasi, di mana tim menguji model, alat, dan alur kerja agen baru untuk mendapatkan keunggulan kompetitif. Dan yang lain adalah kecepatan aman, di mana sistem harus memenuhi persyaratan kepatuhan dan operasional, yang dapat termasuk kontrol akses yang ketat dan blind spot.

Tanpa arsitektur pengaturan yang ditetapkan, dua kecepatan ini akan bertentangan.

Jika tim mengirimkan agen ini sebelum mereka dikelola, akan ada patchwork kontrol satu per satu dan kegagalan operasional. Dan jika sebaliknya terjadi, Anda akan mendapatkan mode kegagalan di mana keamanan memblokir semua, dan inovasi pindah ke shadow IT, melemahkan pengaturan.

Tujuan bukanlah memilih kecepatan. Ini adalah membangun arsitektur yang mendukung keduanya.

Daftar periksa praktis untuk mengatur agen pada waktu runtime

• Jika Anda membangun atau menskala agen, sangat penting untuk bertanya pada diri sendiri pertanyaan berikut untuk menunjukkan apakah pengaturan benar-benar arsitektural: Apakah Anda dapat menjelaskan, dari ujung ke ujung, data apa yang diakses agen untuk menghasilkan jawaban atau mengambil tindakan?
• Apakah keputusan akses konsisten di seluruh lingkungan hybrid, atau apakah mereka berbeda berdasarkan platform?
• Apakah Anda memiliki telemetri untuk tindakan agen, termasuk panggilan alat, pemeriksaan kebijakan, dan eskalasi manusia?
• Apakah Anda dapat mengurangi, menghentikan, atau mengkarantina agen pada waktu runtime jika agen berperilaku tidak terduga?
• Apakah Anda memiliki rencana pemantauan pascapenyebaran yang sesuai dengan kewajiban regulasi dan nafsu risiko Anda?

Jika Anda tidak dapat menjawab ini, perlakukan penerapan agen Anda seperti insiden produksi yang menunggu untuk terjadi.

Perubahan pengaturan perlu menjadi arsitektural, atau tidak ada

Agen akan menjadi tambahan standar untuk operasi perusahaan. Pertanyaannya adalah apakah mereka akan menjadi bagian yang dapat diandalkan dari operasi perusahaan.

Jika agen tidak dikelola setidaknya dengan keyakinan yang sama seperti manusia dan perangkat lunak kritis misi, konsekuensinya akan nyata. Kita akan melihat akibatnya dalam kebocoran data, kegagalan kepatuhan, gangguan operasional, dan kehilangan kepercayaan pada program AI.

Pemimpin perlu berhenti memperlakukan pengaturan agen sebagai latihan dokumentasi. Ketika kemampuan platform berkembang, pengaturan agen harus menjadi salah satu yang mengambil alih pengawasan peran lain. Ini berarti membangun kontrol ke dalam control plane, membuat tindakan dapat diamati dan keputusan dapat diaudit. Dan kemudian skala.

Itulah cara Anda mendapatkan agen yang bergerak cepat tanpa merusak perusahaan.