Tim kepemimpinan Anda mengira ini masalah peluncuran. Bukan. Ini adalah keputusan tata kelola dengan waktu yang sangat singkat dan tekanannya besar karena Kopeo tidak menunggu pembersihan kebijakan atau penyelarasan internal Anda. Begitu ia mulai beroperasi di lingkungan Anda, ia menggunakan sistem apa adanya dan disitulah masalahnya. Kebanyakan organisasi dengan banyak tenan Microsoft 365 berasumsi mereka memiliki satu narasi kontrol AI terutama karena mereka membeli dari satu vendor dan mengelola satu aset identitas. Mereka mendengar satu narasi strategis dari Microsoft dan berasumsi realitasnya sesuai dengan promosi tersebut. Namun kondisi operasinya sangat berbeda. AI bekerja di batas tenan sementara risiko bergerak melintasinya. Jadi pertanyaannya bukan apakah kita bisa mengaktifkan Kopeo Timur. Pertanyaan sebenarnya adalah model tata kelola apa yang memungkinkan kita berskala dengan aman di tenan yang berperilaku secara mandi.

Sebelum kita sampai ke model tersebut, kita perlu mendefinisikan jebakannya. Jebakannya, pulau-pulau AI berdaulat di dalam satu perusahaan. Di sebagian besar organisasi, ilusi dimulai dengan keakraban. Anda membuka Microsoft 365, Anda membuka Purview, Anda membuka Entra, Anda membuka Power Platform. Brandingnya sama. Bahasa adminnya terasa terhubung, dan gerakan komersialnya menceritakan kisah yang sangat rapi. Satu ekosistem, satu strategi, satu arah. Tetapi model kontrol di bawahnya bukanlah satu hal, dan itu lebih penting daripada brandingnya. Berdasarkan penelitian di sini, tidak ada pusat admin AI global tunggal dengan fitur lengkap yang memberi Anda satu tempat untuk mengatur co-pilot dengan rapi di semua tenan. Apa yang sebenarnya Anda memiliki adalah tumpukan kontrol untuk fragmentasi. Sebagian tata kelola ada di Purview, bagian lain ada di pusat admin, dan sisanya tersebar di Entra dan Power Platform.

Beberapa fitur mulai muncul di lapisan kontrol Microsoft yang lebih baru, tetapi belum membentuk satu bidang global yang matang dan lengkap di setiap batas tenan. Kesenjangan itu menciptakan kepercayaan ini. Para pemimpin melihat ekosistem dan berasumsi sentralisasi, sementara tim melihat identitas bersama dan berasumsi konsistensi. Pengadaan melihat satu perjanjian, dan berasumsi satu model operasi, tetapi setiap tenan masih membawa batas kebijakan dan batas datanya sendiri, yang berarti dalam prakteknya masing-masing membawa versinya sendiri tentang kebenaran. Jadi apa yang sebenarnya terjadi itu sederhana? Anda tidak memiliki satu lingkungan e-perusahaan. Anda memiliki beberapa lingkungan AI yang kebetulan milik perusahaan yang sama. Itu adalah gambar risiko yang sangat berbeda. Satu tenan mungkin memiliki cakupan Purview yang lebih kuat, sementara yang lain memiliki adopsi label yang lebih lemah, atau penyerapan audit yang tidak lengkap.

Dari tingkat dewan, ini mungkin masih terlihat seperti satu program, tetapi dari sudut pandang audit atau insiden, ini sama sekali bukan satu program. Ini adalah kumpulan kondisi operasi yang terpisah. Dan begitu kondisi tersebut melenceng, pelaporan mulai tidak akurat. Bukan kena sengaja, tapi secara struktur. Tim ini bertanya apakah kita sudah diatur dengan baik. Satu penyewa bilang ya karena audit aktif penyewa lain, bilang ya karena label tersedia meskipun cakupannya lemah. Yang ketiga bilang ya karena identitas sudah terhubung. Yang keempat bilang ya karena co-pilot secara teknis sudah digunakan. Setiap jawaban terdengar masuk akal, tetapi tidak satu pun berarti hal yang sama. Itulah jebakannya. Anda mengira sedang melihat bidang kontrol global, padahal yang sebenarnya Anda lihat adalah sekumpulan pulau AI berdaulat dalam satu perusahaan. Mereka terhubung dalam merek dan terkadang dalam identitas, tetapi tidak dikelola sebagai satu sistem.

Dan jika Anda tidak mengingat apapun dari bagian ini, ingatlah kalimat ini. Tidak ada pusat admin AI global, hanya ilusi tentang keberadaannya. Begitu ilusi itu pecah, masalah berikutnya muncul dengan cepat. Kebanyakan organisasi merespons dengan melakukan tata kelola perpenyewa secara manual, dan mereka menyebutnya kontrol. Mengapa tata kelola manual perpenyewa runtuh dalam skala besar? Begitu para pemimpin melihat masalah batasan ini tanggapan yang biasa terdengar masuk akal. Mereka bilang, baiklah kita akan mengulang setiap penyewa dalam. Satu tim admin memeriksa pengaturan di sini, tim lain mengulanginya di sana. Seseorang menyimpan spreadsheet, orang lain membuat daftar periksa. Grup pengarah bertemu sebulan sekali, dan bertanya apakah peluncurannya sesuai rencana. Di atas kertas itu terdisiplin. Dalam prakteknya, itu adalah pengulangan manual yang dipungkus sebagai tata kelola. Dan alas regagalannya sederhana.

Pengulangan tidak menghasilkan kontrol, itu menghasilkan variasi seiring waktu. Ini terjadi karena setiap penyewa bergerak dengan kecepatan berbeda, setiap admin membaca standar sedikit berbeda, dan pengecualian lokal mulai terasa dibenarkan karena bisnis menginginkan kemajuan sekarang, bukan setelah tinjauan pusat lainnya. Model lama ini bertahan karena terasa terlihat. Orang dapat menunjuk pada tiket yang diselesaikan, kebijakan yang dibuat, dan pengaturan yang diup. Mereka dapat menunjukkan aktivitas, tetapi upaya yang terlihat tidak sama dengan model operasi yang stabil. Dan dengan adanya kopilot, kesenjangan itu menjadi sangat mahal dengan cepat. Sistem mulai menggunakan izin yang ada, paparan konten yang ada, dan celah pelabelan yang ada saat pengguna mulai memberikan perintah. Itulah hal yang dilewatkan kebanyakan orang. Kopilot tidak menunggu kematangan tatak lol. Ia berjalan pada izin yang sudah Anda miliki, kebersihan konten yang sudah Anda toleransi, dan postur audit yang gagal Anda standarisasi.

Jika satu penyewa membersihkan akses dan yang lain tidak, atau jika satu penyewa mengadakan data audit yang berguna sementara yang lain hampir tidak menangkap cukup untuk investigasi, kopilot akan segera mengungkap perbedaan tersebut. Itu tidak terjadi dalam teori, itu terjadi melalui penggunaan. Jika satu penyewa meninjau akses sharepoint yang luas dan yang lain menganggapnya sudah cukup, Ia akan menemukan celahnya. Dan satu tingkat lebih dalam, setiap penyewa baru melipat kendakan masalahnya bukan karena penyewa itu buruk, tetapi karena perbedaan yang tidak terkelolah akan terakumulasi. Satu tim percontohan baru menambahkan pengecualian lokal, merger membawa penyewa lain dengan label berbeda, dan admin regional menyalin basis lama. Unit bisnis meminta akses lebih cepat, dan tak satu pun dari pilihan itu terlihat dramatis jika dilihat selain. Gabungkan semuanya selama perbulan-bulan dan Anda akan mendapatkan pergeseran kepicjakan, pergeseran akses, dan pergeser.

Hasilnya adalah tim tetak lola yang menghabiskan lebih banyak waktu untuk menyelaraskan perbedaan daripada mencegah risiko. Disitulah kontrol manual menjadi rusak. Terasa lebih aman karena manusia menyentuh pengaturannya, tetapi sebenarnya ini meningkatkan ketidak konsistenan karena setiap titik sentuh adalah peluang bagi penyewa untuk berbeda. Hasilnya adalah peluncuran yang lebih lambat saat Anda menginginkan kecepatan, upaya audit lebih besar saat Anda menginginkan bukti, dan pengerjaan ulang saat Anda menginginkan... Paling buruk, hal ini menciptakan eksposur tersembunyi di mana pimpinan mengharapkan jamin. Hal ini baru saya sadari ketika saya berhenti memperlakukan tetak lola sebagai tugas pengatur. Bukan itu. Ini lebih berlaku seperti peluruang. Jika Anda membersihkan izin sekali, namun tidak ada kontrol yang mencegahnya bergeser lagi, eksposur tersebut akan kembali. Jika Anda mendefinisikan taksonomi label sekali, namun penyewa menerapkannya secara tidak merata, basisnya akan terkikis.

Jika Anda menyetujui co-pilot secara bertahap tanpa meriksa apakah kontrol dasarnya masih berlaku, Anda tidak melakukan pencegahan dengan amat. Anda hanya berekspansi lebih cepat daripada kemampuan tetak lola Anda untuk mengimit. Jadi, metrik yang penting di sini adalah pergeseran akses. Bukan hanya apakah Anda telah memperbaiki sesuatu, tetapi seberapa cepat izin tersebar kembali setelah perbaikan untuk memberitahu Anda apakah model Anda bertahan atau menurut. Karena tetak lola bukanlah proyek yang bisa Anda selesaikan. Ini adalah masalah peluruhan yang harus Anda kelola secara terus. Dan ketika skala merusak model lama, kebanyakan pemimpin mencari jawaban yang paling familiar, yaitu identitas. Mereka berasumsi jika pengguna dapat berpindai dengan bersih antar penyewa, tata kelola akan ikut bersama mereka. Mengapa identitas tidak menyelesaikan tata kelola? Di sinilah banyak program salah arah karena identitas terasa seperti jawaban yang rapi.

Jika pengguna dapat melakukan autentikasi antar penyewa, jika entera terhubung, dan jika pengaturan lintas penyewa sudah ada, pimpinan berasumsi bagian tersulit telah selesai. Akses terlihat terpadu, masuk terlihat terpadu, diagram arsitektur terlihat rapi, tetapi tata kelola copilot tidak menjadi terpadu hanya karena identitas bisa berpindah. Asumsi itu gagal pada titik di mana AI benar-benar bekerja. Copilot mendasarkan respons dalam konteks penyewa tempat permintaan dijalankan dan panduan Microsoft sendiri sudah jelas mengenai poin ini. Microsoft 3antar 5 Copilot beroperasi di dalam batasan keamanan dan kepatuhan penyewa serta menghormati izin pengguna dalam konteks penyewa spesifik tersebut. Seorang pengguna dapat berpindah konteks sebagai tamu, tetapi Copilot tetap terbatas pada satu penyewa-satu bang. Layanan ini tidak menggabungkan beberapa penyewa menjadi satu ruang kerja cerdas untuk sebuah jawaban.

Jadi identitas bisa berpindah namun tetap kalau tidak. Dan begitu Anda memisahkan keduanya, banyak bahasa eksekutif mulai terdengar samar dan berbahaya. Penyewa terhubung, identitas bersama, pengalaman terpadu. Frasa-frasa tersebut mungkin benar secara arah untuk kolaborasi, tetapi tidak sama dengan mengatakan penegatan kebijakan, dasar data pencatatan, dan validasi kontrol kini bekerja sebagai satu sistem. Kesenjangan itu menjadi lebih jelas saat Anda melihat mode multi penyewa Copilot Studio karena platinjo tersebut menceritakan kisah yang sangat spesifik. Ya, penggunaan multi penyewa memang ada. Dan agen yang dihosting di satu penyewa dapat digunakan dari penyewa lain. Namun autentikasi pengguna akhir dalam mode multi penyewa belum didukung dalam platinjo. Pengguna tamu tidak didukung. Konektor kustom tidak didukung. Konektor standar Grab dan Microsoft 3 and Android 5 tidak didukung. Tidak didukung.

Multigio tidak didukung. Beberapa kemampuan analitik tidak tersedia. Klanskrip percakapan juga dimatikan dalam mode tersebut. Itu bukanlah struktur tata kewala lintas penyewa yang matang. Itu adalah platinjo terbatas dan jelas. Dan batasan tersebut penting karena merusak narasi yang sering diceritakan oleh banyak tim kepemimpinan kepada Dave. Mereka mendengar multi penyewa dan berasumsi adanya kematangan operasi. Arsitek mereka mendengar lintas penyewa dan berasumsi adanya simetri kebijakan. Tim kontrol mereka mendengar vendor yang sama dan berasumsi adanya konsistensi audit. Kemudian peluncuran dimulai dan orang-orang menemukan perilaku yang berbeda sinyal yang hilang dan kesenjangan yang janggal seputar autentikasi dan analitik. Bayangkan kasus kedua. Sebuah perusahaan global menyiapkan hubungan internal lintas penyewa dan berasumsi bahwa pengalaman pengguna akan secara alami meluas ke penggunaan copilot.

Harapan tersebut terdengar masuk akal dengan melibatkan kepercayaan direktori bersama, akses yang lebih lancar, dan pola identitas yang sama. Namun saat tim menguji skenario copilot dan agen yang sebenarnya perilakunya tidak merat. Beberapa data hanya muncul dalam konteks yang beralih. Beberapa konektor yang tidak tersedia. Beberapa ekspektasi audit tidak selaras dengan apa yang sebenarnya ditampilkan oleh fitur beratinjau. Pimpinan masih mendengar kata terhubung sementara tim kontrol mulai menemukan pengecualian. Bukan kasus teknis yang jarang terjadi. Itu adalah salam baca terakhir. Karena auditor tidak meniksa narasi arsitektur Anda, mereka meniksa. Mereka bertanya di mana perintah dijalankan, penyewa mana yang akan kebijakan log apa yang ada, dan apakah kontrol Anda benar-benar sebanding di seluruh lingkungan yang Anda gambarkan sebagai sering terkait. Jika model operasional Anda menganggap identitas sebagai tata kelola, Anda tidak akan memiliki jawaban yang jelas.

Jadi jika Anda mengingat satu baris di sini, ingat. Identitas lintas penyewa bukanlah kecerdasan lintas penyewa. Identitas membantu masuk. Hal itu tidak memberitahu Anda apakah perilaku copilot diatur secara konsisten, dipantau dengan benar, atau aman untuk ditingkatkan skalanya di seluruh tempat yang kini disebut perusahaan Anda sebagai satu lingkungan. Dan setelah hal itu jelas, jawabannya bukan lebih banyak koneksi penyewa. Jawabannya harus berupa arsitektur. Model tata kelola yang benar-benar berfungsi adalah hub and spoke. Jadi seperti apa model tata kelola yang nyata ketika platform Anda terfragmentasi? Identitas hanya sebagian, dan batasan penyewa masih sangat penting. Model tersebut terlihat semuanya hub and spoke. Saya menyarankan ini bukan karena diagramnya terlihat rapi di slide, tetapi karena model ini benar-benar sesuai dengan kondisi operasional yang rumit yang sedang Anda ada pisat ini.

Anda memerlukan satu pusat tempat keputusan tata kelola dirancang, diukur, dan ditegakkan sebagai satu sistem, lalu Anda penyewa lokal untuk mengeksekusi keputusan tersebut. Tim lokal ini harus bekerja dalam batasan mereka sendiri tanpa menciptakan aturan versi mereka sendiri setiap kali mereka merasa sedikit tertekan. Kita harus mulai dengan hub. Hub bukan laporta admin, bukan dashboard yang canggih, dan pastinya, bukan tim pusat heroik yang masuk ke setiap penyewa untuk membersihkan file secara manual. Sebaliknya, hub bertindak sebagai otoritas tata kelola utama. Kelompok ini memiliki desain kebijakan, tolak ukur audit, standar label, dan kriteria peluncuran. Mereka lah yang memutuskan apa arti sebenarnya dari siap untuk co-pilot, bukti apa yang dianggap valid, dan seberapa cepat celah keamanan harus ditutup. Perubah keseluruhan percakapan Karena struktur ini, global tidak lagi sekadar istilah untuk satu layar ajaib, melainkan berarti satu sistem tata kelola yang terpadu.

Anda mendapatkan satu standar untuk kontrol purview, satu standar untuk cara masukkan audit, dan satu standar untuk label sensitivitas Anda. Ada satu tolak ukur yang jelas tentang apa yang harus dipenuhi sebelum penyewa tertentu diizinkan memperluas akses co-pilot ke lebih banyak pengguna. Kemudian membutuhkan SPOK. SPOK adalah tim eksekusi penyewa lokal andai yang mengambil tolak ukur tersebut dan menerapkannya pada lingkungan spesifik mereka. Mereka lah yang menjalankan remediasi, memvalidasi log, dan meninjau izin akses yang luas. Namun, mereka melakukan semua pekerjaan itu dalam ruang desain yang sangat sempit, bukan secara bebas tanpa aturan. Jika tim lokal perlu menyimpang dari rencana, ada jalur formal untuk pengecualian. Dan jika mereka ingin bergerak lebih cepat, mereka tetap harus memenuhi kontrol bersama terlebih dahulu. Ketika perbedaan regional atau hukum muncul, masalah tersebut didokumentasikan dan disetujui bukannya diserap secara diam-diam ke dalam solusi lokal yang tidak diketahui orang lain.

Struktur ini sangat penting karena model yang tersentralisasi penuh biasanya kewalahan dengan detail lokal, sementara model lokal penuh, sementara model lokal penuh langsung mengalamiin konsistensi total. Model hub dan SPOK menghindari kedua pola kegagalan tersebut. Hub memberikan konsistensi yang Anda butuhkan, sementara SPOK memberikan kecepatan eksekusi di tempat pekerjaan itu sebenarnya berlangsung. Mari kita buat ini menjadi ingat. Di hub, Anda menentukan kumpulan kontrol preview minimum yang harus dijalankan setiap penyewa sebelum copilot diizinkan untuk berkembang. Anda menentukan dengan tepat peristiwa audit mana yang ingin Anda lihat dan seberapa sering Anda akan meninjaunya. Anda juga membuat taksonomi label bersama untuk konten sensitif agar label rahasia tidak memiliki 5 arti berbeda di 5 penyewa yang berbeda. Anda mengatur ritme peninjauan, mungkin bulanan untuk postur keamanan Anda secara keseluruhan dan lebih sering di area di mana peluncuran sedang aktif.

Di SPOK, tim Anda memetakan standar tingkat tinggi tersebut ke realitas penyewa tertentu tersebut. Mereka menemukan situs mana yang masih memiliki akses luas terbuka dan unit bisnis mana yang tertinggal dalam pemberian label mereka. Mereka meriksa apakah audit benar-benar aktif dan apakah catatan yang tepat terlihat oleh tim keamanan. Mereka mencari admin lokal yang mungkin telah membuat pengecualian yang tidak pernah ditinjau secara resmi dan mereka memutuskan kenapa kegur percontohan dapat berkembang dengan aman atau apakah mereka harus berhenti dan memperbaiki keadaan terlebih dahulu. Dan inilah aturan tegasnya karena tanpa aturan, model ini hanyalah saran dan bukan tata kelola yang sebenarnya. Tidak ada peluncuran copilot yang terjadi di penyewa manapun tanpa pencatatan audit yang tervalidasi pemindahan berbagi berlebihan selesai dan garis dasar minimum untuk cakupan label. Saya tidak berbicara tentang hal-hal ini yang direncanakan atau dibahas bagian selanjutnya.

Hal tersebut harus divalidasi. Jika penyewa tidak dapat membuktikan bahwa ketika kondisi tersebut terpenuhi, peluncuran akan dijemput. Itu mungkin terdengar ketat sampai Anda membandingkannya dengan biaya besar untuk membersihkan kekacauan setelah pengguna mulai menemukan konten sensitif yang tidak pernah Anda maksudkan untuk diekspos melalui AI. Jika Anda melihatnya seperti itu, aturan ini hanyalah akal sehat yang mendasar. Alasan lain mengapa model ini bekerja dengan sangat baik adalah waktunya. Semakin lama Anda menunggu untuk mengaturnya, semakin banyak utang pembersihan yang Anda ciptakan untuk didis. Setiap penyewa yang muncul lebih dulu sebelum mencapai garis dasar

dari sesuatu yang bisa matang setelah adopsi selesai. Tetapi di dunia copyout multi penyewa, urutan itu benar-benar terbalik. Tata kelola harus memimpin peluncuran atau peluncuran tersebut akan menciptakan lebih banyak utang dari banyak utang dari teman. Jika Anda memimpin ini di tingkat perusahaan, langkah Anda selanjutnya sangat celah. Segera siapkan hub tersebut dan tentukan garis dasar itu hari. Tunjuk sepok Anda dan tuliskan proses penanganan pengecualian Anda segera. Anda harus membuat istilah global berarti bahwa keputusan dan gerbang peluncuran Anda bekerja sebagai satu sistem bahkan saat penyewa tidak melakukannya. Sebuah model hanya berarti jika benar-benar mengubah apa yang diberlakukan besok pagi. Apa yang harus diukur pemimpin sebelum mereka pensekala? Model tata kelola hanya akan bertahan jika menghasilkan pengukuran yang dibagikan oleh semua orang. Jika tidak, setiap penyewa akan mengklaim mereka membuat kemajuan dengan bahasanya sendiri dan pimpinan akan mendapatkan pembaruan status tanpa melikai kendali nyata.

Sebelum Anda mensekalkan copyout lebih jauh, Anda memerlukan serangkaian metrik kecil yang memberitahu Anda jika arsitektur berperilaku seperti yang Anda kira. Ikat aktivitas tidak akan memberitahu Anda kebenaran dan angka adopsi jelas tidak akan menunjukkan risiko kepadaku. Anda harus mulai dengan pengurangan berbagai berlebih. Ini masih menjadi salah satu tanda paling jelas bahwa lingkungan Anda benar-benar menjadi lebih aman untuk AI. Anda perlu melihat grup akses luas, situs sharepoint terbuka, dan izin lama yang memberikan akses jauh lebih banyak daripada yang sebenarnya dibutuhkan bisnis. Tujuannya di sini bukan untuk mencapai angka yang sempurna tetapi untuk membuktikan bahwa eksposur Anda menurun sebelum jangkauan copyout Anda menik. Jika kedua garis tersebut bergerak ke arah yang berlawanan, Anda berekspansi jauh lebih cepat daripada memperbaiki masalah mendasar. Metrik kedua yang Anda perlukan adalah cakupan observabilitas.

Bisakah Anda benar-benar melihat apa yang dilakukan copilot di semua penyewa Anda dengan cara mendukung investigasi nyata? Sebagian besar riset menunjuk Microsoft Purview sebagai tempat utama penyimpanan catatan inti seperti interaksi copilot. Tetapi itu mengasumsikan Anda telah mengaktifkan audit di mana-mana. Cakupan bukanlah sesuatu yang bisa Anda asumsikan begitu saja berhasil. Anda perlu mengetahui dengan pasti penyewa mana yang telah mengaktifkan penyerapan audit dan mana yang masih menyisakan visibilitas parsial. Jika Anda tidak memiliki tata kelola dan tidak ada akuntabilitas, itu dengar belak-belakan karena mengarus emik. Jika penyewa tidak dapat memberikan bukti yang dapat digunakan tentang apa yang terjadi, penyewa tersebut tidak siap untuk melakukan pesekalan dengan apa. Anda tidak dapat mengatur apa yang tidak diisikan untuk diperiksa dan Anda pasti tidak akan dapat mempertahankan tindakan Anda jika sesuatu terjadi di kemudian.

Metrik ketiga adalah waktu menuju kebijakan di semua penyewa. Di sinilah pimpinan mengetahui apakah model hub and spoke itu nyata atau hanya dekoratif. Keputusan pusat sama sekali tidak berarti jika satu penyewa berlakukannya minggu ini sementara yang lain menunggu sebulan untuk memikirkannya. Anda harus mengukur waktu yang dibutuhkan sejak kebijakan disetujui hingga kebijakan tersebut diberlakukan secara efektif di setiap penyewa. Saya tidak sedang membicarakan waktu untuk mengumumkan atau mendokumentasikannya tetapi waktu hingga benar-benar aktif. Untuk program AI yang bergerak secepat ini penundaan semacam itu hanyalah nama lain dari risiko. Target praktis bagi sebagian besar organisasi adalah di bawah 7-2 jam untuk perubahan standar. Jika waktu siklus Anda jauh lebih lama dari itu Anda perlu memiliki model yang dapat disekalakan. Anda hanya memiliki masalah koordinasi yang perlu diselesaikan.

Selanjutnya Anda perlu melihat rasio cakupan labelan. Jangan biarkan ini menjadi metrik kesombongan di mana satu penyewa mencapai angka tinggi sementara yang lain tertinggal. Yang terpenting adalah apakah konten sensitif Anda diberi label secara konsisten sehingga perilaku kopelo tidak hanya berdasarkan tebakan pengguna. Anda tidak mencari kesempurnaan di sini tetapi Anda mencari tingkat kendali yang sebanding di setiap penyewa dalam organisasi. Terakhir Anda perlu melacak tingkat penyimpangan akses Anda. Metrik ini memberi tahu Anda apakah upaya pembersihan Anda benar-benar berataan seringlah. Setelah Anda menyelesaikan proyek remediasi seberapa cepat izin tersebut mulai menyebar kembali. Seberapa sering kelompok luah tersebut merayap kembali ke dalam sistem. Banyak tim menyadari hal ini terlambat karena mereka mengukur perbaikan sekali saja dan menganggap masalahnya hilang selama. Ternyata tidak.

Satu-satunya metrik yang penting adalah seberapa cepat sistem mulai menyimpang begitu Anda berhenti mengawasinya. Itulah dasbor operasional Anda. Anda perlu melacak pengurangan berbagi berlebih cakupan observabilitas, waktu kebijakan, cakupan label, dan penyimpangan akses. Irama pelaporan Anda sama pentingnya dengan angka-angka itu sendiri. Pusat harus memiliki dasbor eksekutif karena pimpinan membutuhkan satu tampilan tunggal dari seluruh postur. Sementara itu, jabang harus menangani remediasi karena pekerjaan sebenarnya harus dilakukan di tempat batasan penyewa berada. Satu tim membaca sistem dan tim lain yang memperbaikinya. Anda harus melacak angka-angka ini sebelum melakukan ekspansi, bukan setelahnya. Risikonya tidak menunggu rapat atau loka karya tata kelola Anda berikutnya. Risiko itu sudah aktif di setiap penyewa, di mana copilot dapat menemukan dengan tepat apa yang masih diizinkan untuk dilihat oleh kendali Anda saat ini.

Dua pola yang terus dilewatkan oleh para pemimpin. Saya terus melihat dua pola spesifik di lapangan dan keduanya terjadi karena para pemimpin memperlakukan copilot seperti peluncuran perangkat lunak bukan peristiwa kendali besar. Pola pertama dimulai ketika organisasi meluncurkan copilot sebelum menetapkan garis dasar purview yang nyata atau meninjau akses sharepoint mereka. Pada hari pertama, peluncurannya tampak sembuh. Lisensi ditetapkan, pengguna bersemangat, dan pesan internal semua yang tentang produktivitas. Namun kemudian, perintah biasa mulai memunculkan materi yang secara teknis dapat diakses sejak awal namun praktis tidak terlihat oleh rata-rata karyawan. Sebelum adanya AI, tidak ada yang menghabiskan waktu mereka mengeklik situs lama folder usang atau izin yang diwariskan untuk menemukan hal-hal yang tidak boleh mereka lihat. Namun sekarang mereka tidak berumur. Pengguna mengajukan pertanyaan dasar, ringkasan muncul, dan sebuah file pun terlihat.

Mungkin itu konten HR yang sensitif, materi keuangan, atau informasi kesepakatan yang seharusnya tetap berada dalam lingkaran yang sangat ketat. Tidak ada pelanggaran, tidak ada malware, dan tidak ada batasan keamanan yang rusak dalam pengertian tradisional. Sistem hanya menggunakan izin dan status konten yang memang sudah diizinkan oleh tenan. Itulah momen di mana banyak tim akhirnya memahami masalahnya. Aya tidak menciptakan papanan tersebut. Aya menghilangkan hambatan yang selama ini menyembunyikan. Begitu terjadi di satu tenan, kepercayaan eksekutif biasanya menurun di seluruh organisasi karena tidak ada yang bisa memastikan di mana pola yang sama mungkin muncul berikutnya. Insiden itu mungkin terlihat lokal, tetapi kerusakan pada kepercayaan berdampak di seluruh perusahaan. Pola kedua lebih tenang, tetapi sama berbahayanya. Sebuah perusahaan menyiapkan hubungan identitas lintas tenan, mendengar bahwa skenario multi tenan dimungkinkan dan mengasumsikan model operasi mereka cukup matang untuk peluncuran yang luas.

Pada slide presentasi itu terdengar seperti rencana yang solid. Kenyataannya operasionalnya menjadi berantak. Satu tim mengharapkan pengalaman copilot yang lancar di setiap lingkungan yang terhubung sementara yang lain. Mengharapkan visibilitas yang sebanding dan tim ketiga berasumsi kontrol yang sama akan mengikuti pengguna kemanapun. Kemudian penggunaan sebenarnya mulai menunjukkan perilaku yang tidak merata, kesenjangan dalam autentikasi dan titik lemah dalam hal yang sebenarnya dapat diubung. Masalahnya bukan karena tim-tim ini ceroboh. Masalah sebenarnya adalah mereka menerjemahkan konektivitas menjadi jaminan. Asumsi itu menciptakan cerita palsu tentang kepatuhan. Pimpinan mendengar kata terhubung dan berasumsi organisasi sudah siap. Berbulan-bulan. Kemudian tinjauan kontrol menemukan bahwa perilaku, bukti, dan penegakan sangat bervariasi dari yang ingin diakui siapapun di awal. Sekarang bandingkan itu dengan pola yang lebih baik.

Organisasi yang berbeda memilih untuk melambat sebelum mereka meningkatkan.

Mereka memperluas kopelot secara bertahap bukan karena mereka takut pada adopsi, tetapi karena mereka ingin setiap gelombang menghasilkan bukti yang dapat digunakan sebelum gelombang berikutnya dimulai. Organisasi tersebut biasanya bergerak lebih cepat dalam jangka panjang karena mereka tidak terus-menerus berhenti untuk menjelaskan kejutan, membersihkan konten yang terpapar, atau berdebat tentang apa yang sebenarnya yang terpapar, atau berdebat tentang apa yang sebenarnya dimaksud dengan tata kelola. Itulah sisi positif yang terawatkan pemimpin. Tata kelola yang baik tidak menghalangi peluncuran. Hal ini menghilangkan hambatan peluncuran setelah gelombang pertama selesai. Jebakannya bukan dapat adopsi itu sendiri. Jebakannya adalah adopsi yang tidak terkelola di seluruh penyewaan terlihat terhubung dari jauh, namun berperilaku sangat berbeda saat dilihat dari dekat. Keputusan yang harus Anda buat sebenarnya sangat sederhana.

Anda perlu beralih ke modal tata kelola AI Klee Federated Hub and Spock aja sekarang dan berhenti menganggap pengaturan kealitlan sesungguhnya. Anda harus menghentikan sementara ekspansi kopilot di penyewa manapun yang tidak dapat membuktikan pencatatan tinjauan berbagi berlebih dan cakupan dasar labelnya. AI akan mengikuti sistem yang benar-benar Anda bangun bukan bahkan organisasi tempat Anda melapor. Jika ini mengubah cara Anda memikirkan tata kelola kopilot multi penyewa, ikuti saya, Mirko Peters, di Liget Inn dan bagikan ini kepada tim Anda jika Anda sedang menghadapi masalah ini saat ini.