Perubahan Arsitektural 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 diskusi tata kelola secara keseluruhan; 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 runtime.

Risikonya 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 tata kelola oleh desain: pendekatan arsitektural di mana kontrol ditanamkan dalam kontrol plane dan ditegakkan terus-menerus pada runtime. Jika agen akan bertindak seperti rekan digital, mereka harus mewarisi guardrails perusahaan yang sama dengan manusia, plus pengawasan runtime yang lebih kuat.

Mengapa tata kelola rusak di era konvergensi

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

Ada 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 overhead integrasi 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 keterbatasan visibilitas ke mana data berada sebagai hambatan untuk menggunakan data secara efektif.

Ini adalah 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.

Ini adalah saat ketika pemimpin perusahaan harus memperhatikan. Agen memaksa batang yang lebih tinggi yang menuntut konsistensi di seluruh lingkungan dan akuntabilitas pada runtime.

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

Dari kebijakan ke platform

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

• Plane kontrol 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 yang berbeda-beda, di mana agen yang sama berperilaku aman di satu lingkungan tetapi berbahaya di lingkungan lain.

Tes praktisnya sederhana: 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.

• Fabric data yang didasarkan pada standar terbuka

Agen memerlukan konteks untuk beroperasi. Ketika konteks tersebut tersebar di struktur yang berbeda yang dimiliki oleh tim yang berbeda, fabric 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 tata kelola biasanya gagal. Setelah tim mulai menyalin “hanya apa yang dibutuhkan agen,” Anda telah menciptakan lingkungan baru yang kurang dikelola.

Jika agen dapat beroperasi di seluruh dataset tanpa memperkenalkan celah izin baru, tata kelola bekerja sebagaimana mestinya.

• Observabilitas waktu nyata dan garis keturunan

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

Observabilitas di sini tidak hanya “nice-to-have,” tetapi merupakan dasar untuk kontrol 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 memeriksa keputusan tersebut dan memecahkan kegagalan, jika perlu, sehingga membuktikan kepatuhan secara keseluruhan.

Mengobati agen seperti “rekan digital”

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

Perbandingan ini memecahnya: sama seperti karyawan memiliki kartu akses yang memberikan akses ke beberapa bangunan dan ruangan, tetapi tidak lain, tata kelola memungkinkan agen untuk memiliki akses dengan pembatasan. Salah 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 bocorkan rincian 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 secara historis kita kenal untuk dinavigasi; sebaliknya, ini adalah masalah identitas dan penegakan runtime.

Apa yang berubah pada 2026: agen pindah 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 mencakup kontrol akses yang ketat dan blind spot.

Tanpa tata kelola arsitektural yang ditetapkan, dua kecepatan ini akan bertentangan.

Jika tim mengirimkan agen-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 IT bayangan, melemahkan tata kelola.

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

Daftar periksa praktis untuk mengatur agen pada runtime

• Jika Anda membangun atau menskalakan agen, sangat penting untuk bertanya pada diri sendiri pertanyaan-pertanyaan berikut untuk menunjukkan apakah tata kelola 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-beda tergantung platform?
• Apakah Anda memiliki telemetri untuk tindakan agen, termasuk panggilan alat, pemeriksaan kebijakan, dan eskalasi manusia?
• Apakah Anda dapat membatasi, menghentikan, atau mengkarantina agen pada runtime jika agen berperilaku tidak terduga?
• Apakah Anda memiliki rencana pemantauan pascapengiriman yang selaras 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 tata kelola 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 dengan manusia dan perangkat lunak kritis misi, konsekuensinya akan nyata. Kami akan melihat akibatnya dalam kebocoran data, kegagalan kepatuhan, gangguan operasional, dan kehilangan kepercayaan pada program AI.

Pemimpin perlu berhenti mengobati tata kelola agen sebagai latihan pendokumentasian. Ketika kemampuan platform berkembang, tata kelola agen harus menjadi salah satu yang mengambil alih pengawasan peran lain. Ini berarti menanamkan kontrol dalam kontrol plane, membuat tindakan dapat diamati dan keputusan dapat diaudit. Dan kemudian skala.

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