WEBVTT 00:00:00.000 --> 00:00:02.660 Uw leiderschapsteam denkt dat dit een uitholvraagstuk is. 00:00:02.880 --> 00:00:03.540 Dat is het niet. 00:00:03.760 --> 00:00:06.460 Dit is een governancebesluit met een zeer korte aanlooptijd... 00:00:06.460 --> 00:00:10.720 ...en de druk is hoog omdat Copilot niet wacht tot uw beleidsopschoning of interne afstemming klaar is. 00:00:10.940 --> 00:00:15.460 Zodra het in uw omgeving begint te werken, gebruikt het het systeem precies zoals het dat aantreft... 00:00:15.460 --> 00:00:16.240 ...en daar gaat het mis. 00:00:16.440 --> 00:00:21.920 De meeste organisaties met meerdere Microsoft 365 tenants gaan ervan uit dat ze één AI-beheerverhaal hebben... 00:00:21.920 --> 00:00:24.900 ...vooral omdat ze bij één leverancier kopen en één identiteitsbeheer voeren. 00:00:25.080 --> 00:00:29.240 Ze horen één strategisch verhaal van Microsoft en gaan ervan uit dat de realiteit overeenkomt met de pitch. 00:00:29.240 --> 00:00:31.520 Maar de operationele realiteit is heel anders. 00:00:31.740 --> 00:00:34.840 AI werkt binnen tenantgrenzen, terwijl risico's dwars over die grenzen heen bewegen. 00:00:35.040 --> 00:00:37.500 De vraag is dus niet, kunnen we Copilot overal inschakelen? 00:00:37.640 --> 00:00:42.640 De echte vraag is, welk governancemodel stelt ons in staat om veilig te schalen over tenants die zich onafhankelijk gedragen? 00:00:42.880 --> 00:00:45.700 Voordat we bij dat model komen, moeten we de valkuil definiëren. 00:00:45.880 --> 00:00:48.960 De valkuil, soevereine AI-eilanden binnen één onderneming. 00:00:49.160 --> 00:00:52.000 In de meeste organisaties begint de illusie met bekendheid. 00:00:52.160 --> 00:00:56.840 U opent Microsoft 365, u opent Purview, u opent Entra, u opent Power Platform. 00:00:56.840 --> 00:00:58.380 De huisstijl is hetzelfde. 00:00:58.380 --> 00:01:02.900 De taal voor beheerders voelt verbonden en de commerciële aanpak vertelt een heel helder verhaal. 00:01:03.060 --> 00:01:05.500 Eén ecosysteem, één strategie, één richting. 00:01:05.680 --> 00:01:09.540 Maar het controlemodel eronder is geen geheel en dat is belangrijker dan de huisstijl. 00:01:09.720 --> 00:01:17.160 Gebaseerd op het onderzoek hier is er geen enkel mondiaal AI-beheercentrum met volledige featurepariteit dat u één plek geeft om Copilot overzichtelijk te beheren voor alle tenants. 00:01:17.420 --> 00:01:20.200 Wat u in werkelijkheid heeft is een gefragmenteerde controle stack. 00:01:20.200 --> 00:01:26.000 Onderdelen van governance bevinden zich in Purview, andere in beheercentra en de rest is verspreid over Entra en Power Platform. 00:01:26.260 --> 00:01:33.220 Sommige functies verschijnen in nieuwere Microsoft-controlelagen, maar ze vormen nog geen compleet volwassen mondiaal vlak over elke tenantgrens. 00:01:33.420 --> 00:01:35.480 Dat gat creëert een vals gevoel van vertrouwen. 00:01:35.700 --> 00:01:41.480 Leiders kijken naar het ecosysteem en gaan uit van centralisatie, terwijl teams kijken naar gedeelde identiteit en uitgaan van consistentie. 00:01:41.480 --> 00:01:50.660 Inkoop ziet één overeenkomst en gaat uit van één operationeel model, maar elke tenant heeft nog steeds zijn eigen beleids- en datagrens, wat in de praktijk betekent dat elk zijn eigen versie van de waarheid heeft. 00:01:50.820 --> 00:01:52.800 Dus, wat er werkelijk aan de hand is, is simpel. 00:01:52.980 --> 00:01:54.980 U heeft geen enkel enterprise AI-omgeving. 00:01:55.180 --> 00:01:58.180 U heeft meerdere AI-omgevingen die toevallig bij dezelfde onderneming horen. 00:01:58.380 --> 00:01:59.880 Dat is een heel ander risicobeeld. 00:02:00.080 --> 00:02:05.820 De ene tenant heeft mogelijk een sterkere Purview-dekking, terwijl de andere een zwakkere labeladoptie of onvolledige addit-opname heeft. 00:02:05.820 --> 00:02:11.320 Op bestuursniveau lijkt dit misschien nog steeds één programma, maar vanuit addit- of incident-oogpunt is het absoluut geen enkel programma. 00:02:11.480 --> 00:02:14.180 Het is een verzameling van afzonderlijke operationele omstandigheden. 00:02:14.340 --> 00:02:17.180 En zodra die condities afwijken, begint de rapportage te liegen. 00:02:17.420 --> 00:02:18.960 Niet opzettelijk, maar structureel. 00:02:19.120 --> 00:02:21.300 Het essentiële team vraagt, zijn wij in controle? 00:02:21.560 --> 00:02:26.540 De ene tenant zegt ja omdat addit aanstaat, de andere zegt ja omdat er labels zijn, ook al is de dekking zwak. 00:02:26.660 --> 00:02:28.940 Een derde zegt ja omdat de identiteit gekoppeld is. 00:02:29.120 --> 00:02:32.020 Een vierde zegt ja omdat copilot technisch gezien is uitgerold. 00:02:32.200 --> 00:02:35.600 Elk antwoord klinkt op zichzelf redelijk, maar ze betekenen niet allemaal hetzelfde. 00:02:35.600 --> 00:02:36.720 Dat is de valstrik. 00:02:36.720 --> 00:02:42.820 Je denkt dat je naar een globaal controlepaneel kijkt, terwijl je in werkelijkheid naar een reeks soevereine AI-eilanden binnen één bedrijf kijkt. 00:02:43.000 --> 00:02:47.360 Ze zijn verbonden door merk en soms door identiteit, maar ze worden niet als één systeem bestuurd. 00:02:47.540 --> 00:02:50.820 En als je niets anders van dit gedeelte onthoudt, onthoud dan deze regel. 00:02:51.040 --> 00:02:54.300 Er is geen globaal AI-beheercentrum, alleen de illusie daarvan. 00:02:54.560 --> 00:02:57.920 Zodra die illusie doorbroken wordt, dient het volgende probleem zich snel aan. 00:02:57.920 --> 00:03:02.860 De meeste organisaties reageren door governance per tenant handmatig te doen, en ze noemen dat controle. 00:03:03.100 --> 00:03:05.800 Waarom handmatige governance per tenant faalt op grote schaal? 00:03:05.800 --> 00:03:09.220 Zodra leiders het grensprobleem zien, klinkt de gebruikelijke reactie logisch. 00:03:09.400 --> 00:03:11.620 Ze zeggen, prima, we gaan elke tenant goed besturen. 00:03:11.800 --> 00:03:15.040 Het ene beheerteam controleert hier de instellingen, een ander team herhaalt dat daar. 00:03:15.180 --> 00:03:17.820 Iemand houdt een spreadsheet bij, iemand anders maakt een checklist. 00:03:18.000 --> 00:03:21.600 Een stuurgroep komt één keer per maand bijeen en vraagt of de uithol op schema ligt. 00:03:21.760 --> 00:03:23.620 Op papier ziet dat er gedisciplineerd uit. 00:03:23.800 --> 00:03:26.700 In de praktijk is het handmatige herhaling vermond als governance. 00:03:26.700 --> 00:03:28.800 En de reden waarom het faalt is simpel. 00:03:29.020 --> 00:03:32.700 Herhaling leidt niet tot controle, het leidt na verloop van tijd tot variatie. 00:03:32.700 --> 00:03:37.800 Dit gebeurt omdat elke tenant in een ander tempo beweegt, elke beheerder standaarden net anders leest... 00:03:37.800 --> 00:03:43.120 ...en lokale uitzonderingen gerechtvaardigd lijken omdat de business nu vooruitgang wil, niet pas naar weer een centrale beoordeling. 00:03:43.360 --> 00:03:45.740 Dit oude model overleeft omdat het zichtbaar voelt. 00:03:45.960 --> 00:03:49.880 Mensen kunnen wijzen naar afgesloten tickets, gemaakte beleidsregels en gewijzigde instellingen. 00:03:50.040 --> 00:03:53.700 Ze kunnen activiteit tonen, maar zichtbare inspanning is niet hetzelfde als een stabiel bedrijfsmodel. 00:03:54.360 --> 00:03:57.220 En met Copilot in het spel wordt die kloof heel snel kostbaar. 00:03:57.220 --> 00:04:03.740 Het systeem begint de bestaande rechten, de bestaande inhoudsblootstelling en de bestaande labelingshiaat te gebruiken zodra gebruikers beginnen met prompten. 00:04:03.940 --> 00:04:05.380 Dat is wat de meeste mensen missen. 00:04:05.540 --> 00:04:07.660 Copilot wacht niet op governance volwassenheid. 00:04:07.840 --> 00:04:13.220 Het draait op de rechten die je al hebt, de inhoudshygiëne die je al tolereert en de auditpositie die je al niet hebt gestandardiseerd. 00:04:14.020 --> 00:04:16.220 Als de ene tenant de toegang heeft opgeschoond en de andere niet... 00:04:16.860 --> 00:04:21.220 ...of als de ene tenant nuttige auditdata streamt terwijl de andere nauwelijks genoeg vastlegt voor onderzoek... 00:04:21.740 --> 00:04:23.640 ...zal Copilot die verschillen direct blootleggen. 00:04:23.760 --> 00:04:26.260 Het gebeurt niet in theorie, het gebeurt door gebruik. 00:04:26.260 --> 00:04:31.880 Als de ene tenant brede SharePoint toegang controleert en de andere aanneemt dat het wel goed zit, vindt de AI de hiëten. 00:04:32.060 --> 00:04:38.460 En een niveau dieper vermenigvuldigt elke nieuwe tenant het probleem, niet omdat tenants slecht zijn, maar omdat onbeheerde verschillen zich opstapelen. 00:04:38.620 --> 00:04:43.400 Een nieuw pilotteam voegt een lokale uitzondering toe, een fusie brengt een andere tenant met andere labels... 00:04:43.400 --> 00:04:45.840 ...en een regionale beheerder kopieert een oude basislijn. 00:04:46.000 --> 00:04:50.320 Een business unit vraagt om snellere toegang en geen van die keuzes lijkt op zichzelf dramatisch. 00:04:50.520 --> 00:04:54.700 Combineer ze over een periode van maanden en je krijgt beleidsvervaging, toegangsvervaging en uitrolvervaging. 00:04:54.700 --> 00:04:59.080 Het resultaat is een governance team dat meer tijd besteedt aan het overbruggen van verschillen dan aan het voorkomen van risico's. 00:04:59.260 --> 00:05:01.180 Dat is waar handmatige controle tekort schiet. 00:05:01.340 --> 00:05:07.600 Het voelt veiliger omdat mensen de instellingen aanpassen, maar het vergroot juist in consistentie omdat elk contactpunt een kans is voor tenants om af te wijken. 00:05:07.780 --> 00:05:13.580 De uitkomst is een tragere uithol waar je snelheid wilt, meer audit-inspanning waar je bewijs wilt en meer herbewerking waar je standaarden wilt. 00:05:13.760 --> 00:05:17.360 Het ergste is dat het verborgen blootstelling creëert waar het management zekerheid verwacht. 00:05:17.560 --> 00:05:20.800 Dit dwong tot me door toen ik stopte met governance als een eenmalige installatietaak te zien. 00:05:20.800 --> 00:05:27.600 Dat is het niet. Het gedraagt zich meer als verval. Als je machtigingen één keer opschoont, maar geen controle voorkomt dat ze weer afwijken, keert de blootstelling terug. 00:05:27.760 --> 00:05:32.460 Als je een label taxonomie één keer definieert, maar tenants passen deze ongelijk toe, rodeert de basislijn. 00:05:32.640 --> 00:05:38.040 Als je copilot in golven goedkeurt zonder te controleren of de onderliggende controle nog stand houdt, schaal je niet veilig. 00:05:38.160 --> 00:05:40.920 Je breidt simpelweg sneller uit dan je governance kan bijhouden. 00:05:41.120 --> 00:05:43.660 Dus de statistiek die hier telt is toegangsvervaging. 00:05:43.660 --> 00:05:48.280 Niet alleen of je iets hebt hersteld, maar hoe snel machtigingen zich weer verspreiden na herstel. 00:05:48.500 --> 00:05:50.840 Dat vertelt je of je model standhoudt of verslapt. 00:05:51.040 --> 00:05:53.140 Want governance is geen project dat je afrondt. 00:05:53.220 --> 00:05:55.400 Het is een vervalprobleem dat je continu moet beheren. 00:05:55.520 --> 00:05:59.920 En wanneer schaalvergroting het oude model doorbreekt, grijpen de meeste leiders naar het meest bekende antwoord, identiteit. 00:06:00.140 --> 00:06:04.540 Ze nemen aan dat als gebruikers soepel tussen tenants kunnen bewegen, governance op de een of andere manier met hen meebeweegt. 00:06:04.760 --> 00:06:05.540 Dat gebeurt niet. 00:06:05.780 --> 00:06:07.660 Waarom identiteit governance niet oplost? 00:06:07.880 --> 00:06:12.320 Dit is waar veel programma's een verkeerde afslag nemen, omdat identiteit voelt als het zuivere antwoord. 00:06:12.320 --> 00:06:19.820 Als gebruikers zich tussen tenants kunnen verifiëren, als entra verbonden is en als cross-tenant instellingen aanwezig zijn, nemen leiders aan dat het moeilijke deel is opgelost. 00:06:19.960 --> 00:06:28.380 Toegang ziet er uniform uit, aanmelden ziet er uniform uit, het architectuurdiagram ziet er netjes uit, maar co-pilot governance wordt niet uniform alleen omdat identiteit kan bewegen. 00:06:28.640 --> 00:06:31.340 Die aanname faalt op het punt waar AI daadwerkelijk werkt. 00:06:31.520 --> 00:06:37.280 Co-pilot baseert antwoorden op de context van de tenant waar het verzoek wordt uitgevoerd en de eigen richtlijnen van Microsoft zijn hierover duidelijk. 00:06:37.280 --> 00:06:44.840 Microsoft 365 Co-pilot werkt binnen de beveiligings- en compliancegrenzen van de tenant en respecteert de machtigingen van de gebruiker in die specifieke tenantcontext. 00:06:45.000 --> 00:06:49.460 Een gebruiker kan als gast van context wisselen, ja, maar co-pilot is nog steeds beperkt tot één tenant per keer. 00:06:49.620 --> 00:06:53.400 Het voegt meerdere tenants niet samen tot één intelligente werkruimte voor één enkel antwoord. 00:06:53.660 --> 00:06:55.860 Identiteit kan dus oversteken, governance niet. 00:06:56.020 --> 00:07:00.340 En zodra je die twee scheidt, begint veel management taal gevaarlijk vaag te klinken. 00:07:00.340 --> 00:07:14.640 Die termen zijn misschien richtinggevend voor samenwerking, maar ze betekenen niet dat beleidshandhaving, data grounding, logging en controlevalidatie nu als één systeem werken. 00:07:14.880 --> 00:07:21.080 Dat gat wordt nog duidelijker wanneer je kijkt naar de multi-tenant modus van Co-pilot Studio, omdat de preview een heel specifiek verhaal vertelt. 00:07:21.080 --> 00:07:29.740 Ja, multi-tenant gebruik bestaat en een agent die in de ene tenant wordt gehost kan vanuit een andere worden gebruikt, maar authenticatie van eindgebruikers in multi-tenant modus wordt in de preview nog niet ondersteund. 00:07:29.740 --> 00:07:31.560 Gastgebruikers worden niet ondersteund. 00:07:31.820 --> 00:07:33.540 Aangepaste connectors worden niet ondersteund. 00:07:33.740 --> 00:07:36.960 Brev en Microsoft 365 standaard connectors worden niet ondersteund. 00:07:37.180 --> 00:07:38.680 Multi-geo wordt niet ondersteund. 00:07:38.880 --> 00:07:41.160 Verschillende analyse-mogelijkheden zijn niet beschikbaar. 00:07:41.820 --> 00:07:43.900 Gesprekstranscripties zijn in die modus eveneens uitgeschakeld. 00:07:44.100 --> 00:07:46.360 Dat is geen volwassen governance structuur voor meerdere tenants. 00:07:46.600 --> 00:07:48.740 Dat is een begrensde preview met duidelijke beperkingen. 00:07:48.740 --> 00:07:52.300 En die beperkingen doen ertoe omdat ze het verhaal doorbreken dat veel management teams zichzelf vertellen. 00:07:52.460 --> 00:07:54.740 Ze horen multi-tenant en gaan uit van operationele volwassenheid. 00:07:55.420 --> 00:07:58.380 Hun architecten horen cross-tenant en gaan uit van beleidsymmetrie. 00:07:58.380 --> 00:08:02.260 Hun controle-teams horen dezelfde leverancier en gaan uit van audit-consistentie. 00:08:02.420 --> 00:08:08.080 Dan begint de uitrol en ontdekken mensen ander gedrag, missende signalen en lastige gaten in authenticatie en analytics. 00:08:08.460 --> 00:08:09.980 Stel je het tweede scenario voor. 00:08:10.160 --> 00:08:16.300 Een internationaal bedrijf zet cross-tenant relaties op en gaat ervan uit dat de gebruikerservaring natuurlijk zal doorlopen in het co-pilot gebruik. 00:08:16.400 --> 00:08:21.500 De verwachting klinkt redelijk, met gedeeld directory vertrouwen, soepelere toegang en algemene identiteitspatronen. 00:08:21.620 --> 00:08:25.580 Maar wanneer teams daadwerkelijke co-pilot- en agentscenario's testen, is het gedrag ongelijk. 00:08:25.580 --> 00:08:28.200 Sommige gegevens verschijnen alleen in gewisselde contexten. 00:08:28.360 --> 00:08:30.280 Sommige verwachte connectors zijn niet beschikbaar. 00:08:30.520 --> 00:08:34.060 Sommige audit-verwachtingen komen niet overeen met wat preview-functies daadwerkelijk laten zien. 00:08:34.240 --> 00:08:37.800 Het management hoort nog steeds verbonden, terwijl het controle-team uitzonderingen begint te vinden. 00:08:38.020 --> 00:08:39.300 Dat is geen technisch randgeval. 00:08:39.480 --> 00:08:41.260 Het is een verkeerde interpretatie van governance. 00:08:41.480 --> 00:08:44.360 Want auditors controleren niet je architectuurverhaal, ze controleren bewijs. 00:08:44.500 --> 00:08:51.820 Ze vragen waar prompts zijn uitgevoerd, welke tenant het beleid handhaafde, welke lakser bestaan en of je controles daadwerkelijk vergelijkbaar waren in de omgevingen die je als gekoppeld beschreef. 00:08:51.820 --> 00:08:56.080 Als je operationele model identiteit als governance behandelde, heb je geen sluitend antwoord. 00:08:56.260 --> 00:08:58.620 Dus, als je één ding moet onthouden, laat het dan dit zijn. 00:08:58.980 --> 00:09:01.440 Cross-tenant identiteit is geen cross-tenant intelligentie. 00:09:01.760 --> 00:09:03.520 Identiteit helpt gebruikers toegang te krijgen. 00:09:03.760 --> 00:09:10.400 Het vertelt je niet of co-pilot-gedrag consistent wordt beheerd, goed wordt bewaakt of veilig is om op te schalen over alle plekken die jouw onderneming nu als één omgeving beschouwt. 00:09:10.480 --> 00:09:13.640 En zodra dat duidelijk wordt, kan het antwoord niet simpelweg meer tenant-verbindingen zijn. 00:09:13.820 --> 00:09:15.120 Het moet gaan om architectuur. 00:09:15.120 --> 00:09:17.900 Het governance-model dat echt werkt, hub-and-spook. 00:09:18.080 --> 00:09:24.920 Dus, hoe ziet een echt governance-model eruit als je platform gefragmenteerd is, identiteit slechts gedeeltelijk is en tenant-grenzen er nog steeds echt toe doen? 00:09:25.080 --> 00:09:27.100 Het ziet eruit als een hub-and-spook-systeem. 00:09:27.280 --> 00:09:33.700 Ik stel dit niet voor omdat het diagramma mooi uitziet op een slide, maar omdat het daadwerkelijk overeenkomt met de complexe werkomstandigheden waar je nu mee te maken hebt. 00:09:33.860 --> 00:09:38.980 Je hebt één centrale plek nodig waar governance-beslissingen worden ontworpen, gemeten en afgedwongen als één systeem, 00:09:39.180 --> 00:09:42.140 en daarna heb je lokale tenant-teams nodig om die beslissingen uit te voeren. 00:09:42.140 --> 00:09:48.940 Deze lokale teams moeten binnen hun eigen kaders werken zonder elke keer hun eigen versie van de regels uit te vinden zodra ze onder druk staan. 00:09:49.140 --> 00:09:50.420 We moeten beginnen bij de hub. 00:09:50.580 --> 00:09:58.160 De hub is geen admin-portal, geen glimmend dashboard en zeker geen heroïs centraal team dat in elke tenant handmatig bestanden moet opschonen. 00:09:58.380 --> 00:10:01.640 In plaats daarvan fungeert de hub als de ultieme governance-autoriteit. 00:10:01.940 --> 00:10:07.100 Deze groep beheert het beleidsontwerp, de audit-baselines, de label-standaarden en de uithoolcriteria. 00:10:07.100 --> 00:10:14.320 Zij bepalen wat klaar voor co-pilot echt betekent, welk bewijs stelt als validatie en hoe snel een beveiligingslek moet worden gedicht. 00:10:14.640 --> 00:10:16.720 Die verschuiving verandert het hele gesprek. 00:10:17.100 --> 00:10:23.520 Door deze structuur is, globaal, niet langer een term voor één magisch scherm, maar staat het voor één uniform governance-systeem. 00:10:23.680 --> 00:10:29.100 Je krijgt één standaard voor purview-controles, één standaard voor het verwerken van audits en één standaard voor je vertrouwelijkheidslabels. 00:10:29.880 --> 00:10:35.180 Er is één duidelijke lat voor wat er moet zijn bereikt voordat een specifieke tenant co-pilot toegang mag uitbreiden naar meer gebruikers. 00:10:35.180 --> 00:10:41.860 Dan heb je de spokes nodig. De spokes zijn je lokale tenant-uitvoeringsteams die die baseline nemen en toepassen op hun specifieke omgeving. 00:10:42.120 --> 00:10:46.520 Zij voeren de sanering uit, valideren de logboeken en controleren brede toegangsrechten. 00:10:46.780 --> 00:10:51.740 Ze doen dit werk echter binnen een zeer beperkte ontwerpruimte in plaats van in een vrijblijvende omgeving. 00:10:51.940 --> 00:10:56.020 Als een lokaal team moet afwijken van het plan, is er een formeel pad voor uitzonderingen. 00:10:56.140 --> 00:10:59.960 En als ze sneller willen werken, moeten ze nog steeds eerst aan de gedeelde controles voldoen. 00:10:59.960 --> 00:11:08.000 Wanneer regionale of juridische verschillen opduiken, worden die kwesties gedocumenteerd en goedgekeurd in plaats van stilletjes opgenomen in een lokale workaround waar niemand anders vanaf weet. 00:11:08.200 --> 00:11:16.040 Deze structuur is essentieel omdat volledig gecentraliseerde modellen meestal vastlopen in lokale details, terwijl volledig lokale modellen vrijwel direct in totale inconsistentie vervallen. 00:11:16.180 --> 00:11:18.800 Het hap- en spookmodel vermijdt beide faalpatronen. 00:11:18.960 --> 00:11:24.460 De hap biedt de consistentie die u nodig heeft, terwijl de spookste uitvoeringssnelheid leveren daar waar het werk daadwerkelijk plaatsvindt. 00:11:24.460 --> 00:11:31.600 Laten we dit concreet maken. Bij de hap definieert u de minimale sets per view-controles die elke tenant moet uitvoeren voordat co-pilot mag groeien. 00:11:31.740 --> 00:11:36.160 U definieert precies welke added events u verwacht te zien en hoe vaak u deze zult beoordelen. 00:11:36.360 --> 00:11:44.120 U creëert ook een gedeelde label-taxonomie voor gevoelige inhoud, zodat een vertrouwelijk label niet vijf verschillende dingen betekent in vijf verschillende tenants. 00:11:44.320 --> 00:11:51.540 U bepaalt het ritme voor reviews, misschien maandelijks voor uw algehele beveiligingsstatus en vaker in gebieden waar de uitrol momenteel actief is. 00:11:51.540 --> 00:11:56.300 Bij de spook vertaalt uw team die standaarden op hoog niveau naar de realiteit van die specifieke tenant. 00:11:56.580 --> 00:12:01.320 Zij zoeken uit welke sites nog steeds brede toegang hebben en welke bedrijfsonderdelen achterlopen met hun labels. 00:12:01.600 --> 00:12:05.540 Zij controleren of de added daadwerkelijk is ingeschakeld en of de juiste gegevens zichtbaar zijn voor het beveiligingsteam. 00:12:06.300 --> 00:12:10.600 Zij zoeken naar lokale beheerders die uitzonderingen hebben geïntroduceerd die nooit officieel zijn beoordeeld, 00:12:10.800 --> 00:12:14.900 en bepalen of een pilotgroep veilig kan uitbreiden of dat ze eerst moeten stoppen en de zaken moeten herstellen. 00:12:15.080 --> 00:12:20.000 En dit is de harde regel, want zonder regel is dit model slechts een suggestie in plaats van echte governance. 00:12:20.000 --> 00:12:24.120 Geen enkele co-pilot uitrol vindt plaats in een tenant zonder gevalideerde added logging, 00:12:24.340 --> 00:12:27.780 een voltooide scan op oversharing en een minimale basislijn voor label dekking. 00:12:27.940 --> 00:12:30.700 Ik heb het niet over zaken die geplant of gedeeltelijk besproken zijn. 00:12:30.940 --> 00:12:32.140 Ze moeten gevalideerd zijn. 00:12:32.360 --> 00:12:36.100 Als een tenant niet kan bewijzen dat aan die drie voorwaarden is voldaan, wordt de uitrol gepauseerd. 00:12:36.300 --> 00:12:40.140 Dat klinkt misschien streng totdat u het vergelijkt met de enorme kosten van het opruimen van een puinhoop 00:12:40.140 --> 00:12:43.300 nadat gebruikersgevoelige inhoud vinden die u nooit via AI had willen blootstellen. 00:12:43.460 --> 00:12:46.680 Als u het op die manier bekijkt, zijn deze regels gewoon gezond verstand. 00:12:46.680 --> 00:12:49.620 Een andere reden waarom dit model zo goed werkt, is de timing. 00:12:49.820 --> 00:12:53.660 Hoe langer u wacht met het opzetten hiervan, hoe meer opruimschuld u later voor uzelf creëert. 00:12:53.820 --> 00:12:58.300 Elke tenant die uitrolt voordat aan de basislijn is voldaan, wordt een nieuwe enorme achterstand aan uitzonderingen 00:12:58.300 --> 00:13:01.200 en ontbrekend bewijsmateriaal die uw team uiteindelijk zal moeten oplossen. 00:13:01.400 --> 00:13:04.960 Leiders behandelen governance vaak als iets dat kan rijpen nadat de adoptie is voltooid, 00:13:05.140 --> 00:13:08.520 maar in een wereld met meerdere co-pilot-tenants is die volgorde volledig achterstevoren. 00:13:08.760 --> 00:13:13.560 Governance moet de uitrol aansturen, anders zal de uitrol meer schuld creëren dan uw teams ooit kunnen absorberen. 00:13:13.560 --> 00:13:17.120 Als u dit op ondernemingsniveau leidt, is uw volgende stap heel duidelijk. 00:13:17.300 --> 00:13:19.900 Zet de hap nu op en bepaal vandaag nog die basislijn. 00:13:20.160 --> 00:13:23.780 Wijs je spokes toe en leg je proces voor uitzonderingen onmiddellijk vast. 00:13:24.240 --> 00:13:29.040 Je moet, globaal, zo invullen dat je beslissingen en uitholpoorten als één systeem werken, 00:13:29.280 --> 00:13:31.020 zelfs als de tenants zelf dat niet doen. 00:13:31.220 --> 00:13:35.240 Een model is alleen zinvol als het morgenochtend daadwerkelijk verandert wat wordt afgedwongen, 00:13:35.400 --> 00:13:37.480 wat leiders moeten meten voordat ze gaan schalen. 00:13:37.660 --> 00:13:41.600 Een governance model werkt alleen als het metingen oplevert die voor iedereen gelijk zijn. 00:13:41.600 --> 00:13:45.280 Anders zal elke tenant beweren voortgang te boeken in eigen bewoordingen 00:13:45.280 --> 00:13:48.380 en krijgt het leiderschap statusupdates zonder echte controle. 00:13:48.620 --> 00:13:51.840 Voordat je copilot verder schaalt, heb je een set statistieken nodig 00:13:51.840 --> 00:13:54.540 die aangeven of de architectuur zich gedraagt zoals je denkt. 00:13:55.240 --> 00:13:59.280 Activiteitsniveaus vertellen je niet de waarheid en adoptiecijfers tonen zeker de risico's niet aan. 00:13:59.440 --> 00:14:01.500 Je moet beginnen met het verminderen van oversharing. 00:14:01.760 --> 00:14:06.080 Dit is nog steeds een van de duidelijkste tekenen dat je omgeving daadwerkelijk veiliger wordt voor AI. 00:14:06.080 --> 00:14:12.940 Je moet kijken naar brede toegangsgroepen, open sharepoint sites en oude rechten die veel meer toegang geven dan de business nodig heeft. 00:14:13.140 --> 00:14:18.840 Het doel is niet om een perfect getal te halen, maar om aan te tonen dat je blootstelling daalt voordat je copilot bereik toeneemt. 00:14:18.960 --> 00:14:24.380 Als die twee lijnen in tegengestelde richting bewegen, breed je veel sneller uit dan dat je de onderliggende problemen oplost. 00:14:24.560 --> 00:14:27.340 De tweede metriek die je nodig hebt is observability dekking. 00:14:27.540 --> 00:14:31.940 Kun je daadwerkelijk zien wat copilot doet in al je tenants op een manier die echt onderzoek ondersteunt. 00:14:31.940 --> 00:14:40.160 Het meeste onderzoek wijst naar Microsoft Purview als de plek waar kerngegevens zoals copilot interacties worden opgeslagen, maar dat vereist dat audit overal aanstaat. 00:14:40.340 --> 00:14:43.100 Dekking is niet iets waarvan je zomaar kunt aannemen dat het werkt. 00:14:43.280 --> 00:14:48.820 Je moet precies weten welke tenants audit ingestieactief hebben en welke je nog steeds gedeeltelijk in het duister laten. 00:14:49.140 --> 00:14:52.180 Zonder logbestanden heb je geen governance en geen verantwoording. 00:14:52.460 --> 00:14:54.480 Dat klinkt bot, omdat het ook bot moet zijn. 00:14:54.680 --> 00:14:59.400 Als een tenant geen bruikbaar bewijs kan leveren van wat er gebeurt, is die tenant niet klaar om veilig te schalen. 00:14:59.400 --> 00:15:04.840 Je kunt niet besturen wat je niet mag inspecteren en je zult je actie zeker niet kunnen verdedigen als er later iets misgaat. 00:15:04.960 --> 00:15:07.820 De derde metriek is je time to policy voor alle tenants. 00:15:08.140 --> 00:15:12.460 Dit is waar het leiderschap ontdekt of het hap- en spookmodel echt is of slechts decoratief. 00:15:12.600 --> 00:15:18.540 Een centraal besluit betekent helemaal niets als de ene tenant het deze week afdwingt, terwijl de andere een maand wacht om erover na te denken. 00:15:18.760 --> 00:15:23.600 Je moet meten hoe lang het duurt vanaf het goedkeuren van een beleid tot het daadwerkelijk afdwingen ervan in elke tenant. 00:15:23.800 --> 00:15:28.400 Ik heb het niet over de tijd die het kost om het aan te kondigen of te documenteren, maar over de tijd totdat het echt live is. 00:15:28.400 --> 00:15:32.720 Voor een AI-programma dat zo snel beweegt, is dat soort vertraging gewoon een ander woord voor risico. 00:15:32.880 --> 00:15:37.060 Een praktisch doel voor de meeste organisaties is minder dan 72 uur voor standaardwijzigingen. 00:15:37.240 --> 00:15:40.240 Als je cyclus tijd veel langer is dan dat, heb je nog geen schaalbaar model. 00:15:40.520 --> 00:15:43.240 Je hebt gewoon een coördinatieprobleem dat opgelost moet worden. 00:15:43.520 --> 00:15:45.740 Vervolgens moet je kijken naar je dekkingsgraad van labels. 00:15:46.060 --> 00:15:50.280 Laat dit geen ijdelheidsmetriek worden waarbij één tenant hoge cijfers haalt terwijl de rest achterblijft. 00:15:50.460 --> 00:15:56.960 Wat echt telt is of je gevoelige inhoud consistent genoeg gelabeld is, zodat het gedrag van Copilot niet gebaseerd is op giswerk van gebruikers. 00:15:56.960 --> 00:16:02.480 Je streeft hier niet naar perfectie, maar naar een vergelijkbaar controleniveau in elke tenant binnen de organisatie. 00:16:02.640 --> 00:16:05.200 Tot slot moet je de excess drift rate bijhouden. 00:16:05.440 --> 00:16:08.940 Deze metriek laat zien of je opschoonacties op de lange termijn echt effect hebben. 00:16:09.100 --> 00:16:13.060 Hoe snel beginnen die rechten zich weer te verspreiden nadat je een herstelproject hebt afgerond. 00:16:13.220 --> 00:16:15.720 Hoe vaak sluipen die brede groepen weer terug in het systeem. 00:16:15.940 --> 00:16:20.220 Veel teams beseffen dit te laat omdat ze de oplossing in malig maten en aannamen dat het probleem voorgoedweg was. 00:16:20.440 --> 00:16:21.120 Dat was het niet. 00:16:21.120 --> 00:16:25.380 De enige metriek die ertoe doet is hoe snel het systeem verslapt zodra je er niet meer naar kijkt. 00:16:25.600 --> 00:16:27.220 Dat is je operationele dashboard. 00:16:27.420 --> 00:16:33.100 Je moet oversharing reduction, observability coverage, time to policy, label decking en excess drift bijhouden. 00:16:33.260 --> 00:16:36.380 Het ritme van je rapportage is net zo belangrijk als de cijfers zelf. 00:16:36.580 --> 00:16:41.760 Het centrale team moet het executive dashboard beheren, omdat de leiding één overzicht nodig heeft van de gehele status. 00:16:42.080 --> 00:16:47.380 Ondertussen moeten de decentrale teams het herstel beheren, omdat het eigenlijke werk moet gebeuren waar de tenant zich bevindt. 00:16:47.500 --> 00:16:50.080 Eén team leest het systeem en het andere team corrigeert het. 00:16:50.080 --> 00:16:53.180 Je moet deze cijfers bijhouden voordat je uitbreidt, niet achteraf. 00:16:53.300 --> 00:16:56.380 Het risico wacht niet op je volgende vergadering of governance workshop. 00:16:56.540 --> 00:17:01.340 Het is al actief in elke tenant waar Copilot precies kan vinden wat je huidige controles nog steeds toelaten. 00:17:01.540 --> 00:17:03.800 De twee patronen die leiders steeds over het hoofd zien. 00:17:04.000 --> 00:17:11.180 Ik zie in het veld voortdurend twee specifieke patronen en beide ontstaan omdat leiders Copilot behandelen als een software lancering in plaats van als een grote controle gebeurtenis. 00:17:11.340 --> 00:17:17.680 Het eerste patroon begint wanneer een organisatie Copilot uitholt zonder een echte Purview Baseline in te stellen of hun SharePoint toegang te controleren. 00:17:17.680 --> 00:17:19.900 Op de eerste dag ziet de uitrol er perfect uit. 00:17:20.140 --> 00:17:24.960 Licenties zijn toegewezen, gebruikers zijn enthousiast en de interne berichtgeving gaat volledig over productiviteit. 00:17:25.160 --> 00:17:31.900 Maar dan halen normale prompts materiaal naar boven dat technisch gezien altijd al toegankelijk was maar voor de gemiddelde werknemer in de praktijk onzichtbaar bleef. 00:17:32.100 --> 00:17:38.760 Voor AI bracht niemand zijn dag door met het doorklikken van oude sites, verouderde mappen of geërfde machtigingen om dingen te vinden die ze niet mochten zien. 00:17:38.760 --> 00:17:44.280 Maar nu hoeft dat niet meer. Een gebruiker stelt een basisvraag, er komt een samenvatting terug en er verschijnt een bestand. 00:17:44.480 --> 00:17:50.100 Misschien is het gevoelige oude inhoud, financiële gegevens of dealinformatie die binnen een zeer kleine kring had moeten blijven. 00:17:50.260 --> 00:17:54.200 Er was geen inbreuk, geen malware en geen doorbroken beveiligingsgrens in de traditionele zin. 00:17:54.360 --> 00:17:58.400 Het systeem gebruikte simpelweg de machtigingen en de inhoudelijke status die de tenant al toestond. 00:17:58.600 --> 00:18:01.160 Dat is het moment waarop veel teams het probleem eindelijk begrijpen. 00:18:01.320 --> 00:18:05.700 AI heeft de blootstelling niet gecreëerd. Het heeft alleen de wrijving weggenomen die het voorheen verborgen hield. 00:18:05.700 --> 00:18:09.940 Zodra dat in één tenant gebeurt, daalt het vertrouwen van het management meestal in de hele organisatie, 00:18:10.120 --> 00:18:13.440 omdat niemand met zekerheid kan zeggen waar datzelfde patroon zich de volgende keer zal voordoen. 00:18:13.560 --> 00:18:17.080 Het incident lijkt misschien lokaal, maar de schade aan het vertrouwen is bedrijfsbreed. 00:18:17.240 --> 00:18:19.980 Het tweede patroon is stiller, maar minstens zo gevaarlijk. 00:18:20.140 --> 00:18:24.640 Een bedrijf zet identiteitsrelaties tussen tenants op, hoort dat multitenant scenario's mogelijk zijn 00:18:24.640 --> 00:18:27.980 en gaat ervan uit dat een bedrijfsmodel volwassen genoeg is voor een brede uitrol. 00:18:28.140 --> 00:18:30.320 In een presentatie klinkt dat als een solide plan. 00:18:30.520 --> 00:18:32.680 In de werkelijkheid worden de operaties rommelig. 00:18:32.680 --> 00:18:36.360 Het ene team verwacht een soepele co-pilot ervaring in elke verbonden omgeving, 00:18:36.520 --> 00:18:41.400 terwijl het andere vergelijkbare zichtbaarheid verwacht en het derde aanneemt dat dezelfde controles de gebruiker overal volgen. 00:18:41.580 --> 00:18:44.060 Vervolgens legt het daadwerkelijke gebruik ongelijkmatig gedrag, 00:18:44.320 --> 00:18:47.320 hiaten in authenticatie en zwakke plekken in wat daadwerkelijk meetbaar is bloot. 00:18:47.440 --> 00:18:49.760 Het probleem is niet dat deze teams onzorgvuldig waren. 00:18:49.980 --> 00:18:53.120 Het echte probleem is dat ze connectiviteit hebben vertaald naar zekerheid. 00:18:53.320 --> 00:18:55.540 Die aanname creëert een vals beeld van compliance. 00:18:55.800 --> 00:18:59.800 Het management hoort het woord verbonden en gaat ervan uit dat de organisatie er klaar voor is. 00:18:59.800 --> 00:19:06.220 Maanden later blijkt uit controlebeoordelingen dat gedrag, bewijsvoering en handhaving veel meer varieerde dan iemand aan het begin wilde toegeven. 00:19:06.420 --> 00:19:08.180 Vergelijk dat nu eens met een beter patroon. 00:19:08.340 --> 00:19:11.300 Een andere organisatie kiest ervoor om te vertragen voordat ze opschalen. 00:19:11.500 --> 00:19:13.220 Ze bepalen eerst een basislijn voor labels, 00:19:13.460 --> 00:19:17.400 ze beoordelen eerst brede toegang en ze valideren hun adit zichtbaarheid voordat ze iets anders doen. 00:19:17.600 --> 00:19:20.900 Ze breiden co-pilot in golven uit, niet omdat ze bang zijn voor adoptie, 00:19:21.020 --> 00:19:24.540 maar omdat ze willen dat elke golf bruikbaar bewijs levert voordat de volgende begint. 00:19:24.540 --> 00:19:29.840 Die organisatie gaat op de lange termijn meestal sneller omdat ze niet constant hoeven te stoppen om verrassingen uit te leggen, 00:19:29.900 --> 00:19:33.960 blootgestolde inhoud op te schonen of te discussiëren over wat governance eigenlijk hoorde te betekenen. 00:19:34.180 --> 00:19:36.480 Dat is het voordeel dat de meeste leiders over het hoofd zien. 00:19:36.700 --> 00:19:38.540 Goede governance blokkeert je uitrol niet. 00:19:38.700 --> 00:19:42.100 Het haalt de vertraging uit de uitrol zodra die eerste golf is afgerond. 00:19:42.280 --> 00:19:43.880 De valkouw is niet de adoptie zelf. 00:19:44.120 --> 00:19:47.800 De valkouw is onbeheerde adoptie over tenants heen die van een afstand verbonden lijken, 00:19:48.000 --> 00:19:50.320 maar zich heel anders gedragen als je van dichtbij kijkt. 00:19:50.480 --> 00:19:52.900 De beslissing die je moet nemen is eigenlijk heel simpel. 00:19:52.900 --> 00:19:56.640 Je moet nu overstappen op een gefedereerd hap- en spook AI governance model 00:19:56.640 --> 00:20:00.120 en stoppen met het aanzien van tenant per tenant schakelen voor echte controle. 00:20:00.340 --> 00:20:03.660 Je moet je co-pilot uitbreiding pauseren in elke tenant die zijn logging, 00:20:03.960 --> 00:20:06.960 reviews op oversharing en label basisdekking niet kan aantonen. 00:20:07.160 --> 00:20:11.260 AI zal het systeem volgen dat je daadwerkelijk bouwt, niet het organigram waaraan je rapporteert. 00:20:11.420 --> 00:20:14.280 Als dit je kijk op multitenant co-pilot governance heeft veranderd, 00:20:14.540 --> 00:20:19.560 volg mij, Mirko Peters, op LinkedIn en deel dit met je team als je momenteel met deze problemen worstelt.