Ваша керівна команда вважає, що це питання впровадження. Це не так. Це управлінське рішення з дуже обмеженим часом, і тиск зростає, бо Coopilot не чекатиме, поки ви наведіть лад у політиках чи внутрішніх процесах. Як тільки він починає працювати у вашому середовищі, він використовує систему такою, якою її бачить, і саме тут усе ламається. Більшість організацій з кількома орендарями Microsoft 365 вважають, що мають єдину стратегію контролю щі, переважно тому, що купують продукти в одного постачальника та керують однією структурою ідентифікації. Вони чують єдиний стратегічний наратив від Microsoft і припускають, що реальність відповідає обіцянкам. Але фактичні умови роботи зовсім інші. Щі працює в межах орендаря, тоді як ризики вільно переміщуються між ними. Тож питання не в тому, чи можемо ми ввімкнути Coopilot всюди. Справжнє питання в тому, яка модель управління дозволить нам безпечно масштабуватися між орендарями, що діють незалежно.

Перш ніж перейти до цієї моделі, нам потрібно окреслити пастку. Пастка «Суверенні острови» щі всередині одного підприємства. У більшості організацій ілюзія починається з відчуття знаємості. Ви відкриваєте Microsoft 365, ви відкриваєте Perview, ви відкриваєте Entra, ви відкриваєте Pava Platform. Брендинг однаковий. Мова адміністрування здається цілісною, а комерційна пропозиція виглядає дуже привабливо. Одна екосистема, одна стратегія, один напрямок. Але модель контролю під капотом не єдина, і це важливіше за брендинг. Згідно з нашими дослідженнями, не існує єдиного глобального центру адміністрування ще з повною функціональністю, який дав би вам одне місце для зручного керування Co-Pilot в усіх орендарях. Насправді у вас фрагментований стек контролю. Частини управління знаходяться в Perview, інші – в центрах адміністрування, а решта розкидані між Entra та Pava Platform. Деякі функції з'являються в нових рівнях контролю Microsoft, але вони ще не утворюють єдину повноглобальну площину через межі всіх орендарів.

Цей розрив створює хибне почуття впевненості. Керівники дивляться на екосистему і припускають централізацію, тоді як команди дивляться на спільну ідентифікацію і припускають послідовність. Закупівлі бачать одну угоду і припускають одну модель роботи, але кожен орендар все одно має власні межі політик і даних, а це означає, що на практиці кожен має свою власну версію істини. Отже, те, що відбувається насправді, дуже просто. У вас немає одного корпоративного середовища щі. У вас є кілька середовищ щі, які просто належать до одного підприємства. Це зовсім інша картина ризиків. Один орендар може мати краще покриття перв'ю, тоді як інший, слабше впровадження міток або неповне збирання аудиту. На рівні ради директорів це все ще може виглядати як одна програма, але з точки зору аудиту чи інцидентів це зовсім не одна програма. Це набір окремих операційних умов. І як тільки ці умови змінюються, звітність починає брехати.

Не навмисно, а структурно. Керівна команда запитує, чи ми здійснюємо управління. Один орендар каже, так, бо ввімкнено аудит, інший, бо є мітки, навіть якщо охоплення слабке. Третій каже, так, бо підключена ідентифікація. Четвертий каже, так, бо Coopilot технічно розгорнуто. Кожна відповідь звучить слушно сама по собі, але жодна з них не означає одне й те саме. Ось у чому пастка. Ви думаєте, що дивитеся на глобальну панель управління, а насправді бачите набір суверенних щі-островів усередині однієї компанії. Вони пов'язані брендом і іноді ідентифікацією, але ними не керують як єдиною системою. І якщо ви нічого більше не запам'ятаєте з цього розділу, запам'ятайте цей рядок. Немає глобального центру адміністрування щі, є лише ілюзія такого. Як тільки ця ілюзія розбивається, наступна проблема з'являється швидко. Більшість організацій реагують на це ручним управлінням для кожного орендаря окремо і називають це контролем.

Чому ручне управління для кожного орендаря не працює в масштабах? Як тільки лідери бачать проблему меж, зазвичай відповідь звучить розсудливо. Вони кажуть, добре, ми будемо керувати кожним орендарем належним чином. Одна команда адміністраторів перевіряє налаштування тут, інша команда повторює їх там. Хтось веде електронну таблицю, хтось інший створює чек-лист. Керівна група збирається раз на місяць і запитує, чи йде впровадження за планом. На папері це виглядає дисципліновано. На практиці це ручне повторення, замасковане під управління. І причина, чому це не працює, проста. Повторення не забезпечує контроль, воно породжує варіативність з часом. Це стається тому, що кожен орендар рухається з різною швидкістю, кожен адміністратор трактує стандарти трохи по-різному, а локальні винятки починають здаватися виправданими, бо бізнесу потрібен прогрес зараз, а не після чергового центрального огляду.

Ця стара модель виживає, бо вона виглядає помітною. Люди можуть вказати на закриті тікети, створені політики та змінені налаштування. Вони можуть показати активність, але видимі зусилля – це не те саме, що стабільна операційна модель. А з появою Coopilot цей розрив стає дуже дорогим за лічені миті. Система починає використовувати існуючі дозволи, існуючий доступ до контенту та існуючі прогалини в мітках, щойно користувачі починають надсилати запити. Ось що більшість людей випускає з уваги. Coopilot не чекає на зрілість управління. Він працює на дозволах, які ви вже маєте, гігієні контенту, яку ви вже толеруєте, і стані аудиту, який ви вже не змогли стандартизувати. Якщо один орендар упорядкував доступ, а інший видалив його, або якщо один орендар передає корисні дані аудиту, а інший ледве збирає достатньо для розслідування, Coopilot негайно виявить ці відмінності. Це відбувається не в теорії, це відбувається в процесі використання.

Якщо один орендар переглянув широкий доступ до SharePoint, а інший вирішив, що цього достатньо, ще знайде прогалини. І на рівень глибше, кожен новий орендар примножує проблему не тому, що орендарі погані, а тому, що не керовані відмінності накопичуються. Одна нова пілотна команда додає локальний виняток, злиття привносить іншого орендаря з іншими мітками, а регіональний адміністратор копіює стару базу. Бізнес-підрозділ просить швидшого доступу, і жодне з цих рішень не виглядає критичним окремо. Зберіть їх разом протягом місяців, і ви отримаєте відхилення політик, доступу та впровадження. Результат – команда з управління, яка витрачає більше часу на узгодження відмінностей, ніж на запобігання ризикам. Саме тут ручний контроль, де є збій. Це здається безпечнішим, бо люди змінюють налаштування, але насправді це масштабує неузгодженість, бо кожна точка втручання – це шанс для орендарів розійтися.

Результат – повільніше впровадження там, де потрібна швидкість, більше аудиторських перевірок, де потрібні докази, і більше переробки, де потрібні стандарти. Найгірше те, що це створює приховану вразливість там, де керівництво очікує гарантій безпеки. Я зрозумів це, коли перестав сприймати управління як одноразове налаштування. Це не так. Це більше схоже на розпад. Якщо ви очистили дозволи один раз, але ніякий контроль не стримує їх від повторного відхилення, вразливість повертається. Якщо ви визначили таксономію міток один раз, але орендарі застосовують її нерівномірно, базова лінія руйнується. Якщо ви схвалюєте коопайлот хвилями, не перевіряючи, чи діють базові засоби контролю, ви не масштабуєтеся безпечно. Ви просто розширюєтеся швидше, ніж ваше управління може за цим встигати. Отже, показник, який тут важливий, це відхилення доступу. Не просто, чи виправили ви щось, а як швидко дозволи, знову поширюється після виправлення.

Це показує, чи тримається ваша модель, чи вона слабша є. Бо управління – це не проєкт, який можна завершити. Це проблема деградації, якою ви керуєте постійно. І коли масштабування ламає стару модель, більшість лідерів звертаються до найбільш знайомої відповіді ідентичності. Вони припускають, що якщо користувачі можуть легко переміщатися між орендарями, управління якось переміщатиметься разом з ними. Це не так. Чому ідентичність не вирішує питання управління? Саме тут багато програм роблять хибний крок, бо ідентичність здається простою відповіддю. Якщо користувачі можуть автентифікуватися між орендарями, якщо Entra підключена, а налаштування між орендарями встановлені, лідери вважають, що найважче вирішено. Доступ виглядає єдиним, вхід виглядає єдиним, архітектурна діаграма виглядає охайною, але управління Coopilot не стає єдиним лише тому, що ідентичність може переміщатися. Це припущення зазнає краху там, де ще реально працює.

Coopilot обґрунтовує відповіді в межах контексту орендаря, де виконується запит, і власні настанови Microsoft чітко вказують на це. Microsoft 365 Coopilot працює в межах кордонів безпеки та відповідності орендаря Tenant і дотримується прав доступу користувача в контексті цього конкретного орендаря. Користувач може змінити контекст як гість, так, але Coopilot все одно обмежений одним орендарем одночасно. Він не об'єднує кілька орендарів в один інтелектуальний робочий простір для отримання єдиної відповіді. Отже, ідентичність може переміщуватися, а управління – ні. І як тільки ви розділяєте ці дві речі, багато мови керівників починає звучати небезпечно розмито. Підключені орендарі, спільна ідентичність, уніфікований досвід. Ці фрази можуть бути вірними в загальному напрямку для співпраці, але вони не означають, що застосування політик, обґрунтування даних, ведення журналів і перевірка контролю тепер працюють як єдина система.

Цей розрив стає ще очевиднішим, коли ви дивитесь на багатоорендарний режим Coopilot Studio, оскільки попередня версія розповідає дуже конкретну історію. Так, багатоорендарне використання існує, і агент, розміщений в одному орендарі, може використовуватися з іншого, але автентифікація кінцевого користувача в багатоорендарному режимі поки що не підтримується у попередній версії. Гостьові користувачі не підтримуються. Користувацькі конектори не підтримуються. Стандартні конектори Graph та Microsoft 365 не підтримуються. Multi-Geo не підтримуються. Декілька аналітичних можливостей недоступні. Стенограми розмов також вимкнені в цьому режимі. Це незріла структура управління між орендарями. Це обмежена попередня версія з чіткими межами. І ці межі важливі, тому що вони руйнують історію, яку багато керівних команд розповідають самі собі. Вони чують багатоорендарний і припускають операційну зрілість.

Їхні архітектори чують між орендарями і припускають симметрію політик. Їхні команди контролю чують той самий постачальник і припускають узгодженість аудиту. Потім починається впровадження і люди виявляють іншу поведінку, відсутні сигнали та незрочні прогалини в автентифікації та аналітиці. Уявіть, другий випадок. Глобальна компанія встановлює міжкорпоративні відносини між орендарями і припускає, що користувацький досвід природно пошириться на використання Co-Pilot. Очікування звучить розумно, спільна довіра до каталогів, легший доступ і загальні моделі ідентифікації. Але коли команди тестують реальні сценарії Co-Pilot та агентів, поведінка є нерівномірною. Деякі дані з'являються лише при перемиканні контекстів. Деякі очікувані коннектори недоступні. Деякі очікування щодо аудиту не збігаються з тим, що насправді пропонують функції попереднього перегляду. Керівництво все ще чує, як підключено, тоді як команда контролю починає знаходити винятки.

Це не технічний граничний випадок. Це хибне розуміння управління. Тому що аудитори не перевіряють вашу історію архітектури, вони перевіряють докази. Вони запитують, де виконувалися запити, який орендар забезпечував виконання політики, які існують журнали, і чи були ваші елементи контролю дійсно порівняними в середовищах, які ви описували як пов'язані. Якщо ваша операційна модель трактувала ідентичність як управління, ви не матимете чіткої відповіді. Отже, якщо ви запам'ятаєте лише один рядок тут, хай це буде цей. Ідентичність між орендарями. Це не інтелект між орендарями. Ідентифікація допомагає користувачам увійти. Вона не скаже вам, чи поведінка CowPilot контролюється належним чином, чи вона правильно моніториться, і чи безпечно її масштабувати там, де ваше підприємство тепер має єдине середовище. І коли це стає зрозумілим, відповіддю не можуть бути нові підключення клієнтів Tenant. Це має бути архітектура.

Модель управління, яка справді працює, хаб і спиці. Отже, як виглядає реальна модель управління, коли ваша платформа фрагментована, ідентифікація лише часткова, а межі клієнтів все ще мають значення. Вона виглядає як система, хаб і спиці. Я пропоную це не тому, що діаграма має гарний вигляд на слайді, а тому, що вона відповідає складним операційним умовам, з якими ви стикаєтеся зараз. Вам потрібне одне центральне місце, де рішення щодо управління розробляються, вимірюється та впроваджується як єдина система, а потім потрібні локальні команди для виконання цих рішень. Ці локальні команди повинні працювати у своїх межах, не вигадуючи власні правила щоразу, коли відчувають тиск. Ми повинні почати з хабу. Хаб – це не портал адміністратора, неприваблива панель керування і точно не героїчна центральна команда, що власноруч втручається в кожного клієнта, щоб очистити файли. Натомість хаб діє як вищий орган управління.

Ця група відповідає за розробку політик, базові показники аудиту, стандарти міток і критерії впровадження. Саме вони вирішують, що насправді означає готовність до Co-Pilot, які докази вважаються підтвердженням і як швидко потрібно закрити прогалину в безпеці. Цей сув змінює всю розмову. Завдяки цій структурі «глобальний» перестає бути словом для одного чарівного екрана і починає означати єдину систему управління. Ви отримуєте один стандарт для засобів контролю Perview, один стандарт для збору аудиторських даних і один стандарт для міток конфіденційності. Існує чіткий поріг того, що має бути виконано, перш ніж будь-якому окремому клієнту дозволять розширити доступ до Co-Pilot для більшої кількості користувачів. Потім вам потрібні спиці. Спиці – це ваші локальні виконавчі команди, які беруть ці базові вимоги та застосовують їх до свого середовища. Саме вони проводять виправлення, перевіряють журнали та переглядають дозволи на широкий доступ.

Однак вони виконують всю цю роботу в межах дуже вузького простору, а не як завгодно. Якщо локальна команда має відхилитися від плану, існує офіційний шлях для винятків. І якщо вони хочуть рухатися швидше, вони все одно повинні спочатку відповідати спільним вимогам контролю. Коли виникають регіональні або юридичні розбіжності, ці питання документуються та затверджуються, замість того, щоб тихо поглинатися локальними обхідними шляхами, про які ніхто не знає. Ця структура є важливою, оскільки повністю централізовані моделі зазвичай не справляються з локальними деталями, тоді як суто локальні моделі майже одразу стають непослідовними. Модель «Концентратор і спиці» дозволяє уникнути обох цих невдач. Концентратор забезпечує потрібну послідовність, а спиці – швидкість виконання там, де безпосередньо ведеться робота. Перейдемо до конкретики. У центрі ви визначаєте мінімальний набір засобів контролю, які кожен орендар повинен запустити, перш ніж коупайлат зможе розширюватися.

Ви чітко визначаєте, які події аудиту очікуєте бачити і як часто ви їх переглядатимете. Ви також створюєте спільну таксономію міток для конфіденційного контенту, щоб одна мітка не означала п'ять різних речей у п'яти різних орендарів. Ви встановлюєте ритм перевірок, можливо, щомісяця для загального стану безпеки та частіше там, де розгортання відбувається зараз. На рівні спиць ваша команда адаптує ці високорівневі стандарти до реалій конкретного орендаря. Вони виявляють сайти з відкритим широким доступом і підрозділи, які відстають із маркуванням. Вони перевіряють, чи активовано аудит і чи бачить служба безпеки відповідні записи. Вони шукають локальних адміністраторів, які могли ввести винятки без офіційного погодження і вирішують, чи може пілотна група розширюватися, чи потрібно зупинитися і спочатку все виправити. І ось головне правило, адже без нього ця модель лише порада, а не реальне управління.

Жодне розгортання Coopilot не проводиться без підтвердженого журналу аудиту, завершеного сканування на надмірний доступ та базового рівня покриття мітками. Я не кажу про те, що це має бути лише в планах чи на стадії обговорення. Це має бути підтверджено. Якщо орендар не може довести виконання цих трьох умов, розгортання призупиняється. Це може здатися суворим, доки ви не порівняєте це з величезними витратами на виправлення наслідків, коли користувачі знайдуть конфіденційні дані, які ви не планували відкривати через щі. Якщо поглянути на це так, то ці правила – просто елементарний здоровий глузд. Ще одна причина ефективності цієї моделі – своєчасність. Чим довше ви чекаєте, щоб це налаштувати, тим більше технічного боргу накопичуєте на майбутнє. Кожен орендар, що впроваджує систему безбазового рівня, створює величезний список винятків і відсутніх доказів, які вашій команді доведеться розгрібати.

Керівники часто вважають, що управління дозріє після впровадження, але у світі Co-Pilot з багатьма орендарями ця послідовність є хибною. Управління має випереджати розгортання, інакше впровадження створить більше боргу, ніж ваші команди зможуть опрацювати. Якщо ви керуєте цим на рівні підприємства, ваш наступний крок очевидний. Створіть хаб прямо зараз і визначте цей базовий рівень сьогодні. Призначте свої споки та негайно зафіксуйте процес обробки винятків у письмовому вигляді. Ви маєте зробити так, щоб глобальний означав, що ваші рішення та етапи впровадження працюють як єдина система, навіть якщо самі орендарі – ні. Модель має значення лише тоді, коли вона дійсно змінює те, що буде застосовано завтра вранці, що керівникам слід вимірювати перед масштабуванням. Модель управління тримається купи лише тоді, коли вона надає показники, зрозумілі всім. Інакше кожен орендар буде стверджувати, що досягає прогресу своєю власною мовою, а керівництво отримуватиме звіти, не маючи реального контролю.

Перш ніж масштабувати Coopilot далі, вам потрібен невеликий набір метрик, які покажуть, чи працює архітектура так, як ви очікуєте. Рівні активності не скажуть вам правди, а показники впровадження точно не покажуть ризиків. Вам варто почати зі зменшення надмірного надання доступу. Це все ще одна з найбільш очевидних ознак того, що ваше середовище стає безпечнішим для щі. Вам потрібно переглянути широкі групи доступу, відкриті сайти SharePoint і старі дозволи, що надають значно більше доступу, ніж потрібно бізнесу. Мета тут не в тому, щоб досягти ідеальної цифри, а в тому, щоб довести, що ваша вразливість знижується до того, як зросте охоплення Coopilot. Якщо ці дві лінії рухаються в протилежних напрямках, ви розширюєтеся набагато швидше, ніж виправляєте основні проблеми. Друга метрика, яка вам потрібна, це охоплення з постережуваністю. Чи можете ви насправді бачити, що робить Coopilot у всіх ваших орендарях так, щоб це дозволяло провести реальне розслідування?

Більшість досліджень вказують на Microsoft Перв'ю як на основне місце зберігання ключових записів, таких як взаємодія з Coopilot, але це припускає, що аудиту увімкнено всюди. Охоплення – це не те, що можна вважати таким, що працює саме по собі. Вам потрібно точно знати, у яких орендарях активовано збір даних аудиту, а які все ще залишають вам лише часткову видимість. Якщо у вас немає логів, у вас немає управління та підзвітності. Це звучить різко, тому що так і має бути. Якщо орендар не може надати корисні докази того, що відбувається, такий орендар не готовий до безпечного масштабування. Ви не можете керувати тим, що не можете перевірити, і ви точно не зможете захистити свої дії, якщо щось піде не так пізніше. Третя метрика – це час впровадження політики для всіх орендарів. Тут керівництво дізнається, чи є модель HubSpock реальною чи лише декоративною. Центральне рішення не означає абсолютно нічого, якщо один орендар впроваджує його цього тижня, а інший чекає місяць, щоб подумати про це.

Вам слід вимірювати час від затвердження політики до її ефективного застосування в кожному окремому орендарі. Я говорю не про час на оголошення чи документування, а про час до моменту реального запуску. Для щі програми, що розвивається так швидко, така затримка є просто іншим словом для ризику. Практична ціль для більшості організацій менше 72 годин для стандартних змін. Якщо ваш цикл значно довший, у вас ще немає масштабованої моделі. У вас просто є проблема з координацією, яку потрібно вирішити. Далі вам потрібно звернути увагу на коефіцієнт охоплення мітками. Не дозволяйте цьому перетворитися на показник для галочки, де один орендар має високі результати, а інші відстають. Важливо те, чи ваш конфіденційний контент позначений достатньо послідовно, щоб робота Co-Pilot не залежала від здогадок користувачів. Ви не шукаєте досконалості, але шукаєте порівнянні рівень контролю для кожного орендаря в організації.

Нарешті, вам потрібно відстежувати рівень відхилення доступу. Цей показник демонструє, чи дають результати ваші заходи з очищення з часом. Після завершення проєкту з виправлення, як швидко ці права доступу починають поширюватися знову. Як часто широкі групи користувачів знову проникають у систему. Багато команд усвідомлюють це запізно, бо виміряли результат один раз і вирішили, що проблему вирішено назавжди. Це не так. Єдиний важливий показник, як швидко система починає сповзати, коли ви перестаєте за нею стежити. Це і є ваша робоча панель керування. Вам потрібно відстежувати зменшення надмірного доступу, рівень спостережності, швидкість впровадження політик, охоплення мітками та відхилення доступу. Ритм вашої звітності має таке ж значення, як і самі цифри. Центральний офіс має відповідати за звітність для керівництва, оскільки йому потрібен єдиний огляд загального стану. Тим часом підрозділи мають відповідати за виправлення, бо реальна робота має відбуватися на рівні орендарів.

Він чекає на вашу наступну нараду чи семінар із управління. Він уже діє в кожному орендарі, де Coopilot бачить саме те, що дозволяють ваші поточні налаштування контролю. Дві моделі поведінки, які ігнорують лідери. Я постійно бачу два спеціфічні підходи, і обидва виникають через те, що керівники ставляться до Coopilot як до запуску софту, а не як до серйозного заходу з контролю. Перша модель виникає, коли організація впроваджує Coopilot, не встановивши базових рівнів контролю або не перевіривши доступ до SharePoint. У перший день впровадження виглядає ідеально. Ліцензії призначені, користувачі в захваті, а внутрішні комунікації зосереджені лише на продуктивності. Але потім звичайні запити починають видавати матеріали, які технічно були доступні весь цей час, проте фактично залишалися непомітними для пересічного працівника. До появищі ніхто не витрачав свій день, переглядаючи старі сайти, застарілі папки чи успадковані дозволи, щоб знайти те, чого вони не повинні бачити.

Але тепер їм і не потрібно. Користувач ставить просте запитання, отримує резюме і з'являється файл. Можливо, це конфіденційний контент HR, фінансові матеріали або інформація про угоди, які мали залишатися у дуже вузькому колі. Це не було зломом, не було шкідливого пези чи порушенням меж безпеки у традиційному розумінні. Система просто використала ті дозволи та стан контенту, які вже були налаштовані в орендарі. Це той момент, коли багато команд нарешті розуміють проблему. Ще не створив цю вразливість. Він просто прибрав перешкоди, які її приховували. Коли це стається в одному орендарі, довіра керівництва зазвичай падає в усій організації, оскільки ніхто не може впевнено сказати, де наступного разу виникне такий самий сценарій. Інцидент може виглядати локальним, але шкода для довіри завдається в масштабах усієї компанії. Другий шаблон тихіший, але він так само небезпечний. Компанія налаштовує ідентифікаційні зв'язки між орендарями, чує, що багато орендарні сценарії можливі і припускає, що їхня операційна модель достатньо зріла для широкого впровадження.

На слайдах презентації це виглядає як надійний план. Насправді ж операційна діяльність стає безладною. Одна команда очікує безперебійної роботи Coopilot у кожному підключеному середовищі, інша – порівнянної видимості, а третя припускає, що ті самі елементи керування будуть слідувати за користувачем всюди. Потім реальне використання починає виявляти нерівномірну поведінку, прогалений в автентифікації та слабкі місця в тому, що насправді можна виміряти. Проблема не в тому, що ці команди були недбалими. Справжня проблема полягає в тому, що вони ототожнили можливість підключення з гарантією безпеки. Це припущення створює фальшиву історію про відповідність вимогам. Керівництво чує слово «підключено» і вважає, що організація готова. Через місяці перевірки контролю виявляють, що поведінка, докази та виконання правил відрізнялися набагато більше, ніж хтось хотів визнати на початку. Тепер порівняйте це з кращим шаблоном.

Інша організація вирішує сповільнитися, перш ніж масштабуватися. Вони спочатку встановлюють базовий рівень міток, перевіряють широкий доступ і підтверджують видимість аудиту, перш ніж робити щось інше. Вони розширюють Coopilot хвилями не тому, що бояться впровадження, а тому, що хочуть, щоб кожна хвиля надавала корисні докази до початку наступної. Така організація зазвичай рухається швидше в довгостроковій перспективі, тому що їм не потрібно постійно зупинятися, щоб пояснювати сюрпризи, очищати розкритий контент або сперечатися про те, що насправді мало означати «керований». Це перевага, яку більшість лідерів ігнорують. Належне управління не блокує ваше впровадження. Це усуває гальмування процесу впровадження після завершення першої хвилі. Пастка полягає не в самому прийнятті технології. Пастка – це некероване впровадження в орендарях, які здаються пов'язаними здалеку, але поводяться зовсім інакше, якщо придивитися ближче.

Рішення, яке вам потрібно прийняти, насправді дуже просте. Вам слід негайно перейти до федеративної моделі управління ЩІ за принципом «Хаб» і «Споки» і перестати плутати поокреме налаштування орендарів із реальним контролем. Вам варто призупинити розширення Coopilot у будь-якому орендарі, який не може підтвердити ведення логів, перевірку надмірного доступу

середовищі, підписуйтесь на мене, Мірко Петерса, у LinkedIn і поділіться цим зі своєю командою, якщо ви зараз стикаєтесь із цими проблемами.