Twój zespół zarządzający uważa, że to kwestia wdrożenia. Tak nie jest. To decyzja dotycząca ładu korporacyjnego z bardzo krótkim czasem na reakcję, a presja jest ogromna, bo Kopilot nie poczeka, aż uporządkujesz polityki lub dopasujesz strukturę wewnętrzną. Gdy zacznie działać w Twoim środowisku, wykorzysta system dokładnie w takim stanie, w jakim go zastanie i właśnie tu pojawia się problem. Większość organizacji z wieloma dzierżawami Microsoft 365 zakłada, że mają jedną strategię kontroli, a i głównie dlatego, że kupują od jednego dostawcy i zarządzają jedną bazą tożsamości. Słyszą jedną strategiczną narrację od Microsoftu i zakładają, że rzeczywistość pokrywa się z prezentacją. Jednak warunki operacyjne są zupełnie inne, a i działa w granicach dzierżaw, podczas gdy ryzyko przenika między nimi. Zatem pytanie nie brzmi, czy możemy włączyć Kopilota wszędzie? Prawdziwe pytanie brzmi, jaki model ładu pozwoli nam bezpiecznie skalować działania w niezależnie funkcjonujących dzierżawach?

Zanim przejdziemy do tego modelu, musimy zdefiniować pułapkę. Pułapka, suwerenne wyspy, a i wewnątrz jednego przedsiębiorstwa. W większości organizacji iluzja zaczyna się od złudnego poczucia znajomości. Otwierasz Microsoft 365, Perview, Entra, Power Platform. Branding jest ten sam. Język administratorów wydaje się spójny, a przekaz handlowy tworzy bardzo przejrzystą historię. Jeden ekosystem, jedna strategia, jeden kierunek. Ale model kontroli leżący u podstaw to nie jest jedna całość, a to ma większe znaczenie niż sam branding. Z przeprowadzonego tu badania wynika, że nie istnieje jedno globalne centrum administracji, a i z pełną parzystością funkcji, które pozwoliłoby przejrzyście zarządzać Kopilotem we wszystkich dzierżawach. W rzeczywistości masz pofragmentowany stos kontrolny. Część zasad ładu znajduje się w Perview, inne w centrach administracyjnych, a reszta jest rozproszona między Entra a Power Platform.

Pojawiają się pewne funkcje w nowszych warstwach kontroli Microsoftu, ale nie tworzą one jeszcze jednej, pełnej i dojrzałej płaszczyzny globalnej przekraczającej granice dzierżaw. Ta luka tworzy fałszywe poczucie pewności. Liderzy patrzą na ekosystem i zakładają centralizację, a zespoły patrzą na wspólną tożsamość i zakładają spójność. Dział zakupów widzi jedną umowę i zakłada jeden model operacyjny, ale każda dzierżawa nadal ma własne granice polityk i danych, co w praktyce oznacza, że każda z nich posiada własną wersję prawdy. Więc to, co się dzieje, jest proste. Nie masz jednego środowiska, a i dla całego przedsiębiorstwa. Masz wiele środowisk, a i które przypadkiem należą do tego samego przedsiębiorstwa. To zupełnie inny obraz ryzyka. Jedna dzierżawa może mieć silniejsze zabezpieczenia Perview, podczas gdy inna ma słabsze wdrożenie etykiet lub niepełne zbieranie audytów. Z poziomu zarządu może to nadal wyglądać jak jeden program, ale z punktu widzenia audytu lub incydentów wcale tak nie jest.

To zbiór odrębnych warunków operacyjnych, a gdy te warunki się zmieniają, raporty zaczynają mijać się z prawdą. Nie celowo, lecz strukturalnie. Zespół do spraw. Podstawowych pyta, czy jesteśmy zarządzań. Jeden dzierżawca mówi tak, bo audyt działa, inny twierdzi to samo, bo istnieją etykiety, nawet jeśli pokrycie jest słabe. Trzeci odpowiada tak, bo tożsamość jest połączona. Czwarty twierdzi, że tak, bo kopilot jest technicznie wdrożony. Każda odpowiedź brzmi rozsądnie, ale żadna nie oznacza tego samego. To właśnie jest pułapka. Myślisz, że patrzysz na globalny panel kontrolny, a w rzeczywistości widzisz zbiór suwerennych wysp AI wewnątrz jednej firmy. Łączy je marka, a czasem tożsamość, ale nie są zarządzane jako jeden system. I jeśli masz zapamiętać tylko jedną rzecz z tej sekcji, zapamiętaj to zdanie. Nie ma globalnego centrum administracyjnego, a i istnieje tylko jego iluzja. Gdy ta iluzja pryska, szybko pojawia się kolejny problem.

Większość organizacji reaguje, wprowadzając zarządzanie ręcznie dla każdego dzierżawcy z osobna, nazywając to kontrolą. Dlaczego ręczne zarządzanie każdym dzierżawcą zawodzi na dużą skalę? Gdy liderzy zauważają problem granic, typowa reakcja wydaje się sensowna. Mówią, dobrze, będziemy zarządzać każdym dzierżawcą właściwie. Jeden zespół administratorów sprawdza ustawienia tu, inny zespół powtarza je tam. Ktoś prowadzi arkusz kalkulacyjny, ktoś inny tworzy listę kontrolną. Grupa sterująca spotyka się raz w miesiącu i pyta, czy wdrożenie przebiega zgodnie z planem. Na papierze wygląda to na zdyscyplinowane działanie. W praktyce to ręczna powtarzalność przebrana za ład korporacyjny. Powód, dla którego to zawodzi, jest prosty. Powtarzalność nie daje kontroli, prowadzi z czasem do rozbieżności. Dzieje się tak, ponieważ każdy dzierżawca działa w innym tempie, każdy administrator interpretuje standardy nieco inaczej, a lokalne wyjątki zaczynają wydawać się uzasadnione, bo biznes chce postępów teraz, a nie po kolejnym centralnym przeglądzie.

Ten stary model trwa, bo wydaje się widoczny. Ludzie mogą wskazać zamknięte zgłoszenia, utworzone zasady i zmienione ustawienia. Mogą wykazać aktywność, ale widoczny wysiłek to nie to samo, co stabilny model operacyjny. A z kopilotem w grze ta luka staje się bardzo szybko kosztowna. System zaczyna korzystać z istniejących uprawnień, ekspozycji treści i luk w etykietowaniu w momencie, gdy użytkownicy zaczynają wysyłać zapytania. To jest to, co większość ludzi pomija. Kopilot nie czeka na dojrzałość ładu korporacyjnego. Działa w oparciu o uprawnienia, które już masz, higienę treści, którą już tolerujesz i stan audytu, którego nie udało ci się ujednolicić. Jeśli jeden dzierżawca uporządkował dostęp, a drugi go usunął, lub jeśli jeden strumieniuje przydatne dane audytowe, podczas gdy drugi ledwo rejestruje wystarczająco dużo do analizy, kopilot natychmiast obnaży te różnice. To nie dzieje się w teorii, to dzieje się poprzez użytkowanie.

Jeśli jeden dzierżawca sprawdził szeroki dostęp do SharePoint, a drugi uznał, że to wystarczy, sztuczna inteligencja odnajdzie luki. A głębiej każdy nowy dzierżawca mnoży ten problem nie dlatego, że dzierżawcy są źli, ale dlatego, że niezarządzane różnice się kumulują. Nowy zespół pilotażowy dodaje lokalny wyjątek, fuzja wprowadza kolejnego dzierżawcę z innymi etykietami, a regionalny administrator kopiuje starą bazę. Jednostka biznesowa prosi o szybszy dostęp i żadna z tych decyzji nie wygląda dramatycznie w izolacji. Zestaw je razem na przestrzeni miesięcy, a otrzymasz dryw polityk, dryw dostępu i dryw wdrożenia. Rezultatem jest zespół do spraw. Ładu, który spędza więcej czasu na godzeniu różnic niż na zapobieganiu ryzyku. Właśnie w tym momencie kontrola ręczna zawodzi. Wydaje się bezpieczniejsza, bo ludzie dotykają ustawień, ale w rzeczywistości potęguje niespójność, bo każdy punkt styku to szansa na rozbieżność między dzierżawcami.

Efektem jest wolniejsze wdrażanie tam, gdzie chcesz szybkości, większy wysiłek audytowy tam, gdzie potrzebujesz dowodów i więcej poprawek tam, gdzie chcesz standardów. Co najgorsze, tworzy to ukryte zagrożenie tam, gdzie kierownictwo oczekuje pewności. Dotarło to do mnie, gdy przestałem traktować ład korporacyjny jako zadanie konfiguracyjne. Tak nie jest. Zachowuje się to bardziej jak proces rozpadu. Jeśli raz wyczyścisz uprawnienia, ale żadna kontrola nie zapobiegnie ich ponownemu dryfowi, zagrożenie powraca. Jeśli raz zdefiniujesz taksonomię etykiet, ale dzierżawcy stosują ją nierówno, baza wyjściowa ulega erozji. Jeśli zatwierdzasz kopilota falami, nie sprawdzając, czy podstawowe mechanizmy kontroli nadal działają, nie skalujesz bezpiecznie. Po prostu rozszerzasz się szybciej, niż twój ład jest w stanie nadążyć. Zatem miarą, która się tu liczy, jest dryf dostępu nie tylko to, czy coś naprawiłeś, ale jak szybko uprawnienia ponownie się rozprzestrzeniają po naprawie.

To mówi ci, czy twój model się sprawdza, czy zawodzi. Ponieważ ład to nie jest projekt, który można ukończyć. To problem rozpadu, którym zarządzasz w sposób ciągły. A kiedy skala rozbija stary model, większość liderów sięga po najbardziej znane rozwiązanie – tożsamość. Zakładają, że jeśli użytkownicy mogą płynnie poruszać się między dzierżawcami, ład jakoś przeniesie się wraz z nimi. Nie przeniesie się. Dlaczego tożsamość nie rozwiązuje kwestii ładu? To punkt, w którym wiele programów obiera zły kierunek, ponieważ tożsamość wydaje się czystym rozwiązaniem. Jeśli użytkownicy mogą uwierzytelniać się między dzierżawcami, jeśli entra jest połączona i jeśli ustawienia między dzierżawcami są wdrożone, liderzy zakładają, że najtrudniejsza część jest rozwiązana. Dostęp wygląda na ujednolicony, logowanie na ujednolicone, schemat architektury wygląda schludnie, ale ład kopilota nie staje się jednolity tylko dlatego, że tożsamość może się przemieszczać.

To założenie zawodzi w punkcie, w którym AI faktycznie pracuje. Kopilot opiera odpowiedzi na kontekście dzierżawcy, w którym uruchomiono zapytanie, a wytyczne firmy Microsoft są w tej kwestii jasne. Microsoft 365 Kopilot działa w granicach bezpieczeństwa i zgodności dzierżawy oraz respektuje uprawnienia użytkownika w kontekście tej konkretnej dzierżawy. Użytkownik może zmienić kontekst jako gość, owszem, ale kopilot jest nadal ograniczony do jednej dzierżawy w danym czasie. Nie łączy on wielu dzierżaw w jeden inteligentny obszar roboczy w celu uzyskania jednej odpowiedzi. A więc tożsamość może być przenoszona, ale zarządzanie nie. A gdy oddzieli się te dwie kwestie, wiele wypowiedzi kierownictwa zaczyna brzmieć niebezpiecznie mgliście. Połączone dzierżawy, współdzielona tożsamość, ujednolicone doświadczenie. Te zwroty mogą być prawdziwe w odniesieniu do współpracy, ale nie oznaczają, że egzekwowanie zasad, ugruntowanie danych, logowanie i walidacja kontroli działają teraz jako jeden system.

Ta luka staje się jeszcze bardziej oczywista, gdy spojrzymy na tryb wielodzierżawowy w Kopilot Studio, ponieważ wersja zapoznawcza opowiada bardzo specyficzną historię. Tak, korzystanie z wielu dzierżaw istnieje, a agent hostowany w jednej dzierżawie może być używany z innej, ale uwierzytelnianie użytkownika końcowego w trybie wielodzierżawowym nie jest jeszcze obsługiwane w wersji zapoznawczej. Użytkownicy typu gość nie są obsługiwani. Niestandardowe łączniki nie są obsługiwane. Standardowe łączniki Graph i Microsoft 365 nie są obsługiwane. Funkcja MultiGeo nie jest obsługiwana. Wiele możliwości analitycznych jest niedostępnych. Transkrypcje rozmów są również wyłączone w tym trybie. To nie jest dojrzała struktura zarządzania między dzierżawami. To ograniczona wersja zapoznawcza z wyraźnymi limitami. Te limity mają znaczenie, ponieważ burzą historię, którą opowiadają sobie zespoły kierownicze.

Słyszą wielodzierżawowość i zakładają dojrzałość operacyjną. Ich architekci słyszą między dzierżawami i zakładają symetrię zasad. Ich zespoły kontrolne słyszą ten sam dostawca i zakładają spójność audytu. Następnie rozpoczyna się wdrażanie i ludzie odkrywają odmienne zachowania, brakujące sygnały oraz niezręczne luki w uwierzytelnianiu i analityce. Wyobraźmy sobie drugi przypadek. Firma globalna tworzy relacje między dzierżawami i zakłada, że doświadczenie użytkownika naturalnie rozszerzy się na korzystanie z kopilota. To oczekiwanie brzmi rozsądnie, obejmując zaufanie do współdzielonego katalogu, płynniejszy dostęp i wspólne wzorce tożsamości. Jednak gdy zespoły testują rzeczywiste scenariusze kopilota i agentów, zachowanie jest nierówne. Niektóre dane pojawiają się tylko w zmienionych kontekstach. Niektóre oczekiwane łączniki są niedostępne. Niektóre oczekiwania audytowe nie pokrywają się z tym, co faktycznie oferują funkcję wersji zapoznawczej.

Kierownictwo nadal słyszy połączone, podczas gdy zespół kontrolny zaczyna znajdować wyjątki. To nie jest techniczny przypadek brzegowy. To błędna interpretacja zarządzania. Ponieważ audytorzy nie sprawdzają Twojej historii architektury, sprawdzają dowody, pytają, gdzie uruchomiono monity, która dzierżawa egzekwowała zasady, jakie istnieją logi i czy Twoje kontrole były faktycznie porównywalne w środowiskach, które opisałeś jako połączone. Jeśli Twój model operacyjny traktował tożsamość jako zarządzanie, nie będziesz mieć jasnej odpowiedzi. Więc jeśli masz zapamiętać jedno zdanie, niech to będzie to. Tożsamość między dzierżawami to nie to samo, co inteligencja między dzierżawami. Tożsamość ułatwia użytkownikom logowanie. Nie mówi Ci ona jednak, czy działanie kopilota jest spójnie zarządzane, właściwie monitorowane i bezpieczne do skalowania w całym środowisku Twojej firmy. Gdy stanie się to jasne, odpowiedzią nie mogą być kolejne połączenia między tenantami.

Odpowiedzią musi być architektura, model zarządzania, który rzeczywiście działa, hoop and spoke. Jak zatem wygląda prawdziwy model zarządzania, gdy platforma jest rozproszona, tożsamość tylko częściowa, a granice tenantów wciąż mają znaczenie? Wygląda jak system hoop and spoke. Nie sugeruję tego dlatego, że diagram ładnie wygląda na slajdzie, ale dlatego, że faktycznie pasuje do chaotycznych warunków operacyjnych, z którymi się teraz mierzysz. Potrzebujesz centralnego miejsca, gdzie decyzje dotyczące zarządzania są projektowane, mierzone i egzekwowane jako jeden system oraz lokalnych zespołów tenantów do ich wdrażania. Te lokalne zespoły muszą działać w ramach swoich granic, zamiast tworzyć własne wersje zasad za każdym razem, gdy czują presję. Musimy zacząć od hubu. Hub to nie portal administracyjny, nie błyszczący pulpit nawigacyjny i z pewnością niebohaterski centralny zespół, który ręcznie czyści pliki w każdym tenancie.

Zamiast tego hub pełni funkcję nadrzędnego organu zarządzającego. Ta grupa odpowiada za projektowanie polityk, podstawy audytu, standardy etykiet i kryteria wdrażania. To oni decydują, co faktycznie oznacza gotowość na kopilota, co stanowi dowód i jak szybko należy załatać lukę w zabezpieczeniach. Ta zmiana przekształca całą dyskusję. Dzięki tej strukturze pojęcie globalny przestaje być tylko nazwą magicznego ekranu, a zaczyna oznaczać jeden ujednolicony system zarządzania. Zyskujesz jeden standard kontroli per view, jeden standard przesyłania audytów i jeden standard etykiet wrażliwości. Istnieje jeden jasny próg wymagań, który musi zostać spełniony, zanim dany tenant otrzyma zgodę na rozszerzenie dostępu do kopilota. Potem potrzebujesz SPOX, czyli szprych. Szprychy to lokalne zespoły wykonawcze tenantów, które przejmują wytyczne i stosują je w swoim środowisku. To oni zajmują się naprawą, weryfikacją logów i przeglądem szerokich uprawnień dostępu.

Wykonują jednak te prace w ramach ściśle określonego obszaru, a nie dowolnie. Jeśli lokalny zespół musi odstąpić od planu, istnieje formalna ścieżka dla wyjątków. A jeśli chcą działać szybciej, najpierw muszą spełnić wspólne wymogi kontrolne. Gdy pojawiają się różnice regionalne lub prawne, kwestie te są dokumentowane i zatwierdzane, zamiast być cicho włączanymi do lokalnych rozwiązań, o których nikt inny nie wie. Ta struktura jest kluczowa, ponieważ w pełni scentralizowane modele zazwyczaj gubią się w lokalnych szczegółach, podczas gdy w pełni lokalne modele niemal natychmiast popadają w całkowity brak spójności. Model Hub & Spoke pozwala uniknąć obu tych schematów porażki. Centrum zapewnia niezbędną spójność, podczas gdy oddziały dają szybkość działania tam, gdzie faktycznie odbywa się praca. Przejdźmy do konkretów. W centrum definiujesz minimalny zestaw kontroli per view, które każdy tenant musi wdrożyć, zanim kopilot będzie mógł się rozwijać.

Określasz dokładnie, jakie zdarzenia audytowe chcesz widzieć i jak często będziesz je przeglądać. Tworzysz również wspólną taksonomię etykiet dla treści poufnych, aby tak poufne nie oznaczał pięciu różnych rzeczy w pięciu różnych tenantach. Ustalasz rytm przeglądów, być może co miesiąc dla ogólnego stanu bezpieczeństwa, a częściej w obszarach, gdzie wdrożenie jest aktualnie aktywne. W oddziale Twój zespół dopasowuje te standardy wysokiego poziomu do realiów konkretnego tenanta. Sprawdzają, które witryny wciąż mają zbyt szeroki dostęp i które jednostki biznesowe mają zaległości w etykietowaniu. Weryfikują, czy audyt jest faktycznie włączony i czy odpowiednie rekordy są widoczne dla zespołu do spraw bezpieczeństwa. Szukają lokalnych administratorów, którzy mogli wprowadzić wyjątki bez oficjalnej weryfikacji i decydują, czy grupa pilotażowa może bezpiecznie się rozszerzyć, czy najpierw trzeba się zatrzymać i naprawić błędy.

A oto twarda zasada, ponieważ bez niej ten model jest tylko sugestią, a nie rzeczywistym zarządzaniem. Żadne wdrożenie kopilota nie może odbyć się w żadnym tenancie bez zweryfikowanego logowania audytowego, zakończonego skanowania nadmiernego udostępniania i minimalnego poziomu pokrycia etykietami. Nie mówię tu o rzeczach planowanych, czy częściowo omówionych. One muszą zostać zweryfikowane. Jeśli tenant nie może udowodnić spełnienia tych trzech warunków, wdrożenie zostaje wstrzymane. Może to brzmieć surowo, dopóki nie porównasz tego z ogromnymi kosztami sprzątania bałaganu, gdy użytkownicy zaczną znajdować poufne treści, których nigdy nie chciałeś udostępniać przez AI. Kiedy spojrzysz na to w ten sposób, te zasady są po prostu podstawowym zdrowym rozsądkiem. Innym powodem, dla którego ten model działa tak dobrze, jest czas. Im dłużej zwlekasz z jego konfiguracją, tym więcej długu technicznego tworzysz sobie na przyszłość.

Każdy tenant, który wdroży rozwiązanie przed osiągnięciem punktu odniesienia, staje się ogromnym backlogiem wyjątków i brakujących dowodów, które twój zespół będzie musiał ostatecznie wyjaśnić. Liderzy często traktują zarządzanie jako coś, co może dojrzeć po zakończeniu adopcji, ale w świecie kopilota z wieloma tenantami ta kolejność jest całkowicie błędna. Zarządzanie musi wyprzedzać wdrożenie, w przeciwnym razie wdrożenie wygeneruje więcej długu, niż twoje zespoły będą w stanie udźwignąć. Jeśli kierujesz tym na poziomie przedsiębiorstwa, twój kolejny ruch jest bardzo jasny. Uruchom centrum już teraz i zdefiniuj te bazy dzisiaj. Wyznacz oddziały i natychmiast spisz proces obsługi wyjątków. Musisz sprawić, by globalne podejście oznaczało, że twoje decyzje i etapy wdrażania działają jako jeden system, nawet jeśli same dzierżawy tak nie działają. Model ma znaczenie tylko wtedy, gdy faktycznie zmienia to, co będzie egzekwowane od jutra rana, co liderzy powinni mierzyć, zanim przejdą do skali.

Model zarządzania jest spójny tylko wtedy, gdy dostarcza pomiary, z którymi wszyscy się zgadzają. W przeciwnym razie każdy najemca będzie twierdził, że robi postępy we własnym zakresie, a kierownictwo otrzyma raporty bez realnej kontroli. Zanim bardziej przeskalujesz kopilota, potrzebujesz zestawu wskaźników sprawdzających, czy architektura działa tak, jak zakładasz. Poziomy aktywności nie powiedzą ci prawdy, a liczby adopcji z pewnością nie pokażą ryzyk. Powinieneś zacząć od ograniczenia nadmiernego udostępniania. To wciąż jeden z najbardziej oczywistych sygnałów, że twoje środowisko staje się bezpieczniejsze dla AI. Musisz przyjrzeć się szerokim grupom dostępu, otwartym witrynom SharePoint i starym uprawnieniom, które dają znacznie więcej dostępu niż biznes potrzebuje. Celem nie jest osiągnięcie idealnej liczby, ale udowodnienie, że narażenie maleje, zanim zasięg kopilota wzrośnie. Jeśli te dwie linie poruszają się w przeciwnych kierunkach, rozwijasz się znacznie szybciej niż naprawiasz podstawowe problemy.

Drugim wskaźnikiem, którego potrzebujesz, jest pokrycie obserwowalnością. Czy faktycznie widzisz, co robi kopilot we wszystkich dzierżawach w sposób umożliwiający prawdziwe dochodzenie? Większość badań wskazuje Microsoft Perview jako główne miejsce przechowywania rekordów interakcji kopilota, ale to zakłada włączony wszędzie audyt. Pokrycie nie jest czymś, co możesz po prostu założyć, że działa. Musisz dokładnie wiedzieć, które dzierżawy mają aktywną ingestię audytu, a które zapewniają tylko częściową widoczność. Jeśli nie masz logów, nie masz zarządzania ani odpowiedzialności. Brzmi to brutalnie, bo musi tak brzmieć. Jeśli dzierżawa nie może dostarczyć użytecznych dowodów działań, nie jest gotowa na bezpieczne skalowanie. Nie możesz zarządzać tym, czego nie możesz kontrolować i z pewnością nie obronisz swoich działań, jeśli później coś pójdzie nie tak. Trzecim wskaźnikiem jest czas wdrożenia polityki we wszystkich dzierżawach.

To tutaj kierownictwo dowiaduje się, czy model hoop and spoke jest realny, czy tylko dekoracyjny. Centralna decyzja nic nie znaczy, jeśli jeden najemca wdroży ją w tym tygodniu, a inny czeka miesiąc, by się nad tym zastanowić. Powinieneś mierzyć czas od zatwierdzenia polityki do jej skutecznego wyegzekwowania w każdej dzierżawie. Nie mówię o czasie potrzebnym na ogłoszenie czy udokumentowanie, ale o czasie do momentu, gdy rozwiązanie faktycznie zacznie działać. W przypadku programu AI, który rozwija się tak szybko, takie opóźnienie to po prostu inne określenie na ryzyko. Praktycznym celem dla większości organizacji jest czas poniżej 72 godzin dla standardowych zmian. Jeśli twój czas cyklu jest znacznie dłuższy, nie masz jeszcze skalowalnego modelu. Masz po prostu problem z koordynacją, który wymaga rozwiązania. Następnie musisz przyjrzeć się wskaźnikowi pokrycia etykietami. Nie pozwól, aby stało się to tylko wskaźnikiem dla poprawy samopoczucia, gdzie jeden najemca osiąga świetne wyniki, a reszta zostaje w tyle.

Liczy się to, czy twoje wrażliwe treści są etykietowe i na tyle spójnie, by działanie kopilota nie opierało się na domysłach użytkowników. Nie szukasz tu perfekcji, ale porównywalnego poziomu kontroli w każdym najemcy w organizacji. Na koniec musisz śledzić współczynnik dryftu uprawnień. Ten wskaźnik pokazuje, czy twoje wysiłki związane z porządkowaniem przynoszą trwałe efekty w czasie. Jak szybko po zakończeniu projektu naprawczego uprawnienia zaczynają się ponownie rozszerzać? Jak często szerokie grupy dostępowe przenikają z powrotem do systemu? Wiele zespołów orientuje się zbyt późno, bo zmierzyły poprawkę raz i założyły, że problem zniknął na zawsze. Nie zniknął. Jedynym liczącym się wskaźnikiem jest to, jak szybko system zaczyna tracić kontrolę, gdy przestajesz go obserwować. Oto twój panel operacyjny. Musisz śledzić redukcję nadmiernego udostępniania, zasięg obserwowalności, czas wdrożenia polityk, pokrycie etykietami i dryft uprawnień.

Rytm raportowania jest równie ważny, co same liczby. Centrum powinno zarządzać panelem wykonawczym, ponieważ kierownictwo potrzebuje jednego, spójnego widoku na całość działań. Tymczasem oddziały powinny odpowiadać za działania naprawcze, ponieważ rzeczywista praca musi odbywać się tam, gdzie znajdują się granice najemcy. Jeden zespół odczytuje system, a drugi zespół go poprawia. Musisz śledzić te liczby przed rozszerzeniem skali, a nie po fakcie. Ryzyko nie czeka na kolejne spotkanie czy warsztaty z ładu informacyjnego. Jest już aktywne w każdym najemcy, gdzie kopilot znajduje dokładnie to, na co pozwalają mu twoje obecne zabezpieczenia. Dwa wzorce, które liderzy wciąż pomijają. Dostrzegam w terenie dwa konkretne wzorce i oba wynikają z tego, że liderzy traktują kopilota jak premierę oprogramowania, a nieważne wydarzenie kontrolne. Pierwszy wzorzec pojawia się, gdy organizacja wdraża kopilota przed ustaleniem realnej linii bazowej w perwiu lub przeglądem dostępu do SharePointa.

Pierwszego dnia wdrożenie wygląda perfekcyjnie. Licencje są przypisane, użytkownicy podekscytowani, a wewnętrzna komunikacja skupia się tylko na produktywności. Jednak w pewnym momencie zwykłe zapytania zaczynają wyciągać materiały, które technicznie były dostępne od zawsze, ale praktycznie niewidoczne dla przeciętnego pracownika. Przed erą sztucznej inteligencji nikt nie spędzał dnia na przeszukiwaniu starych witryn, nieaktualnych folderów czy odziedziczonych uprawnień, by znaleźć coś, czego nie powinien widzieć. Teraz jednak nie muszą tego robić. Użytkownik zadaje proste pytanie, otrzymuje podsumowanie i pojawia się plik. Może to być poufna treść z HR, materiały finansowe lub informacje o transakcji, które miały pozostać w bardzo wąskim kręgu osób. Nie doszło do włamania, nie było złośliwego oprogramowania ani naruszenia granic bezpieczeństwa w tradycyjnym sensie. System po prostu wykorzystał uprawnienia i stan zawartości, na które dzierżawca już wcześniej zezwolił.

To moment, w którym wiele zespołów wreszcie rozumie, na czym polega problem. Sztuczna inteligencja nie stworzyła tego zagrożenia. Po prostu usunęła barierę, która wcześniej je maskowała. Gdy wydarzy się to w jednym środowisku, zaufanie kierownictwa w całej organizacji zazwyczaj spada, ponieważ nikt nie jest w stanie przewidzieć, gdzie podobny schemat pojawi się ponownie. Incydent może wydawać się lokalny, ale szkoda wyrządzona zaufaniu obejmuje całe przedsiębiorstwo. Drugi schemat jest cichszy, ale równie niebezpieczny. Firma konfiguruje relacje tożsamości między dzierżawcami, dowiaduje się, że scenariusze wielodzierżawowe są możliwe i zakłada, że jej model operacyjny jest gotowy na szerokie wdrożenie. Na prezentacji brzmi to jak solidny plan. W rzeczywistości operacje stają się chaotyczne. Jeden zespół oczekuje płynnego działania kopilota w każdym połączonym środowisku, inny oczekuje porównywalnej widoczności, a trzeci zakłada, że te same kontrole będą podążać za użytkownikiem wszędzie.

Wtedy rzeczywiste użytkowanie zaczyna ujawniać nierówne zachowanie luki w uwierzytelnianiu oraz słabe punkty w tym, co faktycznie można zmierzyć. Problem nie polega na tym, że te zespoły były niedbałe. Rzeczywistym problemem jest to, że zrównały łączność z zapewnieniem bezpieczeństwa. To założenie tworzy fałszywą historię na temat zgodności z przepisami. Kierownictwo słyszy słowo połączone i zakłada, że organizacja jest gotowa. Miesiące później przeglądy kontrolne wykazują, że zachowanie dowody i egzekwowanie przepisów różniły się znacznie bardziej niż ktokolwiek chciał przyznać na początku. A teraz porównajmy to z lepszym modelem postępowania. Inna organizacja decyduje się zwolnić, zanim zacznie skalować działania. Najpierw ustalają podstawowe etykiety, przeglądają szeroki dostęp i sprawdzają widoczność audytową, zanim zrobią cokolwiek innego. Rozszerzają korzystanie z kopilota falami nie dlatego, że boją się adaptacji, ale dlatego, że chcą, aby każda fala dostarczała użytecznych dowodów przed rozpoczęciem kolejnej.

Taka organizacja zazwyczaj rozwija się szybciej w dłuższej perspektywie, ponieważ nie musi ciągle się zatrzymywać, by wyjaśniać niespodzianki, czyścić ujawnione treści, czy spierać się o to, co właściwie miało oznaczać zarządzanie. To korzyść, którą większość liderów pomija. Dobre zarządzanie nie blokuje wdrożenia. Eliminuje to opór podczas wdrażania, gdy pierwsza fala dobiega końca. Pułapką nie jest sama adopcja. Pułapką jest niezarządzana adopcja w dzierżawach, które z dystansu wyglądają na połączone, ale z bliska zachowują się zupełnie inaczej. Decyzja, którą musisz podjąć, jest w rzeczywistości bardzo prosta. Musisz przejść na sfederowany model zarządzania AI typu Hub & Spoke i przestać mylić włączanie poszczególnych dzierżaw z realną kontrolą. Powinieneś wstrzymać rozszerzanie kopilota w każdej dzierżawie, która nie jest w stanie wykazać logowania, przeglądów nadmiernego udostępniania i pokrycia etykietami.

A i będzie podążać za systemem, który faktycznie zbudujesz, a nie za schematem organizacyjnym, któremu podlegasz. Jeśli zmieniło to twój sposób myślenia o zarządzaniu kopilotem w środowisku wielodzierżawowym, obserwuj mnie, Mirko Petersa, na LinkedIn i udostępnij to swojemu zespołowi, jeśli obecnie mierzysz się z takimi wyzwaniami.