Uw leiderschapsteam denkt dat dit een uitholvraagstuk is. Dat is het niet. Dit is een governancebesluit met een zeer korte aanlooptijd... ...en de druk is hoog omdat Copilot niet wacht tot uw beleidsopschoning of interne afstemming klaar is. Zodra het in uw omgeving begint te werken, gebruikt het het systeem precies zoals het dat aantreft... ...en daar gaat het mis. De meeste organisaties met meerdere Microsoft 365 tenants gaan ervan uit dat ze één AI-beheerverhaal hebben... ...vooral omdat ze bij één leverancier kopen en één identiteitsbeheer voeren. Ze horen één strategisch verhaal van Microsoft en gaan ervan uit dat de realiteit overeenkomt met de pitch. Maar de operationele realiteit is heel anders. AI werkt binnen tenantgrenzen, terwijl risico's dwars over die grenzen heen bewegen. De vraag is dus niet, kunnen we Copilot overal inschakelen? De echte vraag is, welk governancemodel stelt ons in staat om veilig te schalen over tenants die zich onafhankelijk gedragen?

Voordat we bij dat model komen, moeten we de valkuil definiëren. De valkuil, soevereine AI-eilanden binnen één onderneming. In de meeste organisaties begint de illusie met bekendheid. U opent Microsoft 365, u opent Purview, u opent Entra, u opent Power Platform. De huisstijl is hetzelfde. De taal voor beheerders voelt verbonden en de commerciële aanpak vertelt een heel helder verhaal. Eén ecosysteem, één strategie, één richting. Maar het controlemodel eronder is geen geheel en dat is belangrijker dan de huisstijl. 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. Wat u in werkelijkheid heeft is een gefragmenteerde controle stack. Onderdelen van governance bevinden zich in Purview, andere in beheercentra en de rest is verspreid over Entra en Power Platform. Sommige functies verschijnen in nieuwere Microsoft-controlelagen, maar ze vormen nog geen compleet volwassen mondiaal vlak over elke tenantgrens.

Dat gat creëert een vals gevoel van vertrouwen. Leiders kijken naar het ecosysteem en gaan uit van centralisatie, terwijl teams kijken naar gedeelde identiteit en uitgaan van consistentie. 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. Dus, wat er werkelijk aan de hand is, is simpel. U heeft geen enkel enterprise AI-omgeving. U heeft meerdere AI-omgevingen die toevallig bij dezelfde onderneming horen. Dat is een heel ander risicobeeld. De ene tenant heeft mogelijk een sterkere Purview-dekking, terwijl de andere een zwakkere labeladoptie of onvolledige addit-opname heeft. Op bestuursniveau lijkt dit misschien nog steeds één programma, maar vanuit addit- of incident-oogpunt is het absoluut geen enkel programma. Het is een verzameling van afzonderlijke operationele omstandigheden.

En zodra die condities afwijken, begint de rapportage te liegen. Niet opzettelijk, maar structureel. Het essentiële team vraagt, zijn wij in controle? De ene tenant zegt ja omdat addit aanstaat, de andere zegt ja omdat er labels zijn, ook al is de dekking zwak. Een derde zegt ja omdat de identiteit gekoppeld is. Een vierde zegt ja omdat copilot technisch gezien is uitgerold. Elk antwoord klinkt op zichzelf redelijk, maar ze betekenen niet allemaal hetzelfde. Dat is de valstrik. Je denkt dat je naar een globaal controlepaneel kijkt, terwijl je in werkelijkheid naar een reeks soevereine AI-eilanden binnen één bedrijf kijkt. Ze zijn verbonden door merk en soms door identiteit, maar ze worden niet als één systeem bestuurd. En als je niets anders van dit gedeelte onthoudt, onthoud dan deze regel. Er is geen globaal AI-beheercentrum, alleen de illusie daarvan. Zodra die illusie doorbroken wordt, dient het volgende probleem zich snel aan.

De meeste organisaties reageren door governance per tenant handmatig te doen, en ze noemen dat controle. Waarom handmatige governance per tenant faalt op grote schaal? Zodra leiders het grensprobleem zien, klinkt de gebruikelijke reactie logisch. Ze zeggen, prima, we gaan elke tenant goed besturen. Het ene beheerteam controleert hier de instellingen, een ander team herhaalt dat daar. Iemand houdt een spreadsheet bij, iemand anders maakt een checklist. Een stuurgroep komt één keer per maand bijeen en vraagt of de uithol op schema ligt. Op papier ziet dat er gedisciplineerd uit. In de praktijk is het handmatige herhaling vermond als governance. En de reden waarom het faalt is simpel. Herhaling leidt niet tot controle, het leidt na verloop van tijd tot variatie. Dit gebeurt omdat elke tenant in een ander tempo beweegt, elke beheerder standaarden net anders leest... ...en lokale uitzonderingen gerechtvaardigd lijken omdat de business nu vooruitgang wil, niet pas naar weer een centrale beoordeling.

Dit oude model overleeft omdat het zichtbaar voelt. Mensen kunnen wijzen naar afgesloten tickets, gemaakte beleidsregels en gewijzigde instellingen. Ze kunnen activiteit tonen, maar zichtbare inspanning is niet hetzelfde als een stabiel bedrijfsmodel. En met Copilot in het spel wordt die kloof heel snel kostbaar. Het systeem begint de bestaande rechten, de bestaande inhoudsblootstelling en de bestaande labelingshiaat te gebruiken zodra gebruikers beginnen met prompten. Dat is wat de meeste mensen missen. Copilot wacht niet op governance volwassenheid. 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. Als de ene tenant de toegang heeft opgeschoond en de andere niet... ...of als de ene tenant nuttige auditdata streamt terwijl de andere nauwelijks genoeg vastlegt voor onderzoek... ...zal Copilot die verschillen direct blootleggen.

Het gebeurt niet in theorie, het gebeurt door gebruik. Als de ene tenant brede SharePoint toegang controleert en de andere aanneemt dat het wel goed zit, vindt de AI de hiëten. En een niveau dieper vermenigvuldigt elke nieuwe tenant het probleem, niet omdat tenants slecht zijn, maar omdat onbeheerde verschillen zich opstapelen. Een nieuw pilotteam voegt een lokale uitzondering toe, een fusie brengt een andere tenant met andere labels... ...en een regionale beheerder kopieert een oude basislijn. Een business unit vraagt om snellere toegang en geen van die keuzes lijkt op zichzelf dramatisch. Combineer ze over een periode van maanden en je krijgt beleidsvervaging, toegangsvervaging en uitrolvervaging. Het resultaat is een governance team dat meer tijd besteedt aan het overbruggen van verschillen dan aan het voorkomen van risico's. Dat is waar handmatige controle tekort schiet. 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.

De uitkomst is een tragere uithol waar je snelheid wilt, meer audit-inspanning waar je bewijs wilt en meer herbewerking waar je standaarden wilt. Het ergste is dat het verborgen blootstelling creëert waar het management zekerheid verwacht. Dit dwong tot me door toen ik stopte met governance als een eenmalige installatietaak te zien. 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. Als je een label taxonomie één keer definieert, maar tenants passen deze ongelijk toe, rodeert de basislijn. Als je copilot in golven goedkeurt zonder te controleren of de onderliggende controle nog stand houdt, schaal je niet veilig. Je breidt simpelweg sneller uit dan je governance kan bijhouden. Dus de statistiek die hier telt is toegangsvervaging. Niet alleen of je iets hebt hersteld, maar hoe snel machtigingen zich weer verspreiden na herstel.

Dat vertelt je of je model standhoudt of verslapt. Want governance is geen project dat je afrondt. Het is een vervalprobleem dat je continu moet beheren. En wanneer schaalvergroting het oude model doorbreekt, grijpen de meeste leiders naar het meest bekende antwoord, identiteit. Ze nemen aan dat als gebruikers soepel tussen tenants kunnen bewegen, governance op de een of andere manier met hen meebeweegt. Dat gebeurt niet. Waarom identiteit governance niet oplost? Dit is waar veel programma's een verkeerde afslag nemen, omdat identiteit voelt als het zuivere antwoord. 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. 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.

Die aanname faalt op het punt waar AI daadwerkelijk werkt. Co-pilot baseert antwoorden op de context van de tenant waar het verzoek wordt uitgevoerd en de eigen richtlijnen van Microsoft zijn hierover duidelijk. Microsoft 365 Co-pilot werkt binnen de beveiligings- en compliancegrenzen van de tenant en respecteert de machtigingen van de gebruiker in die specifieke tenantcontext. Een gebruiker kan als gast van context wisselen, ja, maar co-pilot is nog steeds beperkt tot één tenant per keer. Het voegt meerdere tenants niet samen tot één intelligente werkruimte voor één enkel antwoord. Identiteit kan dus oversteken, governance niet. En zodra je die twee scheidt, begint veel management taal gevaarlijk vaag te klinken. Die termen zijn misschien richtinggevend voor samenwerking, maar ze betekenen niet dat beleidshandhaving, data grounding, logging en controlevalidatie nu als één systeem werken.

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. 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. Gastgebruikers worden niet ondersteund. Aangepaste connectors worden niet ondersteund. Brev en Microsoft 365 standaard connectors worden niet ondersteund. Multi-geo wordt niet ondersteund. Verschillende analyse-mogelijkheden zijn niet beschikbaar. Gesprekstranscripties zijn in die modus eveneens uitgeschakeld. Dat is geen volwassen governance structuur voor meerdere tenants. Dat is een begrensde preview met duidelijke beperkingen. En die beperkingen doen ertoe omdat ze het verhaal doorbreken dat veel management teams zichzelf vertellen.

Ze horen multi-tenant en gaan uit van operationele volwassenheid. Hun architecten horen cross-tenant en gaan uit van beleidsymmetrie. Hun controle-teams horen dezelfde leverancier en gaan uit van audit-consistentie. Dan begint de uitrol en ontdekken mensen ander gedrag, missende signalen en lastige gaten in authenticatie en analytics. Stel je het tweede scenario voor. Een internationaal bedrijf zet cross-tenant relaties op en gaat ervan uit dat de gebruikerservaring natuurlijk zal doorlopen in het co-pilot gebruik. De verwachting klinkt redelijk, met gedeeld directory vertrouwen, soepelere toegang en algemene identiteitspatronen. Maar wanneer teams daadwerkelijke co-pilot- en agentscenario's testen, is het gedrag ongelijk. Sommige gegevens verschijnen alleen in gewisselde contexten. Sommige verwachte connectors zijn niet beschikbaar. Sommige audit-verwachtingen komen niet overeen met wat preview-functies daadwerkelijk laten zien.

Het management hoort nog steeds verbonden, terwijl het controle-team uitzonderingen begint te vinden. Dat is geen technisch randgeval. Het is een verkeerde interpretatie van governance. Want auditors controleren niet je architectuurverhaal, ze controleren bewijs. 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. Als je operationele model identiteit als governance behandelde, heb je geen sluitend antwoord. Dus, als je één ding moet onthouden, laat het dan dit zijn. Cross-tenant identiteit is geen cross-tenant intelligentie. Identiteit helpt gebruikers toegang te krijgen. 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.

En zodra dat duidelijk wordt, kan het antwoord niet simpelweg meer tenant-verbindingen zijn. Het moet gaan om architectuur. Het governance-model dat echt werkt, hub-and-spook. 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? Het ziet eruit als een hub-and-spook-systeem. 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. Je hebt één centrale plek nodig waar governance-beslissingen worden ontworpen, gemeten en afgedwongen als één systeem, en daarna heb je lokale tenant-teams nodig om die beslissingen uit te voeren. 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.

We moeten beginnen bij de hub. De hub is geen admin-portal, geen glimmend dashboard en zeker geen heroïs centraal team dat in elke tenant handmatig bestanden moet opschonen. In plaats daarvan fungeert de hub als de ultieme governance-autoriteit. Deze groep beheert het beleidsontwerp, de audit-baselines, de label-standaarden en de uithoolcriteria. Zij bepalen wat klaar voor co-pilot echt betekent, welk bewijs stelt als validatie en hoe snel een beveiligingslek moet worden gedicht. Die verschuiving verandert het hele gesprek. Door deze structuur is, globaal, niet langer een term voor één magisch scherm, maar staat het voor één uniform governance-systeem. Je krijgt één standaard voor purview-controles, één standaard voor het verwerken van audits en één standaard voor je vertrouwelijkheidslabels. Er is één duidelijke lat voor wat er moet zijn bereikt voordat een specifieke tenant co-pilot toegang mag uitbreiden naar meer gebruikers.

Dan heb je de spokes nodig. De spokes zijn je lokale tenant-uitvoeringsteams die die baseline nemen en toepassen op hun specifieke omgeving. Zij voeren de sanering uit, valideren de logboeken en controleren brede toegangsrechten. Ze doen dit werk echter binnen een zeer beperkte ontwerpruimte in plaats van in een vrijblijvende omgeving. Als een lokaal team moet afwijken van het plan, is er een formeel pad voor uitzonderingen. En als ze sneller willen werken, moeten ze nog steeds eerst aan de gedeelde controles voldoen. 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. Deze structuur is essentieel omdat volledig gecentraliseerde modellen meestal vastlopen in lokale details, terwijl volledig lokale modellen vrijwel direct in totale inconsistentie vervallen.

Het hap- en spookmodel vermijdt beide faalpatronen. De hap biedt de consistentie die u nodig heeft, terwijl de spookste uitvoeringssnelheid leveren daar waar het werk daadwerkelijk plaatsvindt. 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. U definieert precies welke added events u verwacht te zien en hoe vaak u deze zult beoordelen. U creëert ook een gedeelde label-taxonomie voor gevoelige inhoud, zodat een vertrouwelijk label niet vijf verschillende dingen betekent in vijf verschillende tenants. U bepaalt het ritme voor reviews, misschien maandelijks voor uw algehele beveiligingsstatus en vaker in gebieden waar de uitrol momenteel actief is. Bij de spook vertaalt uw team die standaarden op hoog niveau naar de realiteit van die specifieke tenant. Zij zoeken uit welke sites nog steeds brede toegang hebben en welke bedrijfsonderdelen achterlopen met hun labels.

Zij controleren of de added daadwerkelijk is ingeschakeld en of de juiste gegevens zichtbaar zijn voor het beveiligingsteam. Zij zoeken naar lokale beheerders die uitzonderingen hebben geïntroduceerd die nooit officieel zijn beoordeeld, en bepalen of een pilotgroep veilig kan uitbreiden of dat ze eerst moeten stoppen en de zaken moeten herstellen. En dit is de harde regel, want zonder regel is dit model slechts een suggestie in plaats van echte governance. Geen enkele co-pilot uitrol vindt plaats in een tenant zonder gevalideerde added logging, een voltooide scan op oversharing en een minimale basislijn voor label dekking. Ik heb het niet over zaken die geplant of gedeeltelijk besproken zijn. Ze moeten gevalideerd zijn. Als een tenant niet kan bewijzen dat aan die drie voorwaarden is voldaan, wordt de uitrol gepauseerd. Dat klinkt misschien streng totdat u het vergelijkt met de enorme kosten van het opruimen van een puinhoop nadat gebruikersgevoelige inhoud vinden die u nooit via AI had willen blootstellen.

Als u het op die manier bekijkt, zijn deze regels gewoon gezond verstand. Een andere reden waarom dit model zo goed werkt, is de timing. Hoe langer u wacht met het opzetten hiervan, hoe meer opruimschuld u later voor uzelf creëert. Elke tenant die uitrolt voordat aan de basislijn is voldaan, wordt een nieuwe enorme achterstand aan uitzonderingen en ontbrekend bewijsmateriaal die uw team uiteindelijk zal moeten oplossen. Leiders behandelen governance vaak als iets dat kan rijpen nadat de adoptie is voltooid, maar in een wereld met meerdere co-pilot-tenants is die volgorde volledig achterstevoren. Governance moet de uitrol aansturen, anders zal de uitrol meer schuld creëren dan uw teams ooit kunnen absorberen. Als u dit op ondernemingsniveau leidt, is uw volgende stap heel duidelijk. Zet de hap nu op en bepaal vandaag nog die basislijn. Wijs je spokes toe en leg je proces voor uitzonderingen onmiddellijk vast.

Je moet, globaal, zo invullen dat je beslissingen en uitholpoorten als één systeem werken, zelfs als de tenants zelf dat niet doen. Een model is alleen zinvol als het morgenochtend daadwerkelijk verandert wat wordt afgedwongen, wat leiders moeten meten voordat ze gaan schalen. Een governance model werkt alleen als het metingen oplevert die voor iedereen gelijk zijn. Anders zal elke tenant beweren voortgang te boeken in eigen bewoordingen en krijgt het leiderschap statusupdates zonder echte controle. Voordat je copilot verder schaalt, heb je een set statistieken nodig die aangeven of de architectuur zich gedraagt zoals je denkt. Activiteitsniveaus vertellen je niet de waarheid en adoptiecijfers tonen zeker de risico's niet aan. Je moet beginnen met het verminderen van oversharing. Dit is nog steeds een van de duidelijkste tekenen dat je omgeving daadwerkelijk veiliger wordt voor AI. Je moet kijken naar brede toegangsgroepen, open sharepoint sites en oude rechten die veel meer toegang geven dan de business nodig heeft.

Het doel is niet om een perfect getal te halen, maar om aan te tonen dat je blootstelling daalt voordat je copilot bereik toeneemt. Als die twee lijnen in tegengestelde richting bewegen, breed je veel sneller uit dan dat je de onderliggende problemen oplost. De tweede metriek die je nodig hebt is observability dekking. Kun je daadwerkelijk zien wat copilot doet in al je tenants op een manier die echt onderzoek ondersteunt. Het meeste onderzoek wijst naar Microsoft Purview als de plek waar kerngegevens zoals copilot interacties worden opgeslagen, maar dat vereist dat audit overal aanstaat. Dekking is niet iets waarvan je zomaar kunt aannemen dat het werkt. Je moet precies weten welke tenants audit ingestieactief hebben en welke je nog steeds gedeeltelijk in het duister laten. Zonder logbestanden heb je geen governance en geen verantwoording. Dat klinkt bot, omdat het ook bot moet zijn. Als een tenant geen bruikbaar bewijs kan leveren van wat er gebeurt, is die tenant niet klaar om veilig te schalen.

Je kunt niet besturen wat je niet mag inspecteren en je zult je actie zeker niet kunnen verdedigen als er later iets misgaat. De derde metriek is je time to policy voor alle tenants. Dit is waar het leiderschap ontdekt of het hap- en spookmodel echt is of slechts decoratief. 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. Je moet meten hoe lang het duurt vanaf het goedkeuren van een beleid tot het daadwerkelijk afdwingen ervan in elke tenant. 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. Voor een AI-programma dat zo snel beweegt, is dat soort vertraging gewoon een ander woord voor risico. Een praktisch doel voor de meeste organisaties is minder dan 72 uur voor standaardwijzigingen. Als je cyclus tijd veel langer is dan dat, heb je nog geen schaalbaar model.

Je hebt gewoon een coördinatieprobleem dat opgelost moet worden. Vervolgens moet je kijken naar je dekkingsgraad van labels. Laat dit geen ijdelheidsmetriek worden waarbij één tenant hoge cijfers haalt terwijl de rest achterblijft. Wat echt telt is of je gevoelige inhoud consistent genoeg gelabeld is, zodat het gedrag van Copilot niet gebaseerd is op giswerk van gebruikers. Je streeft hier niet naar perfectie, maar naar een vergelijkbaar controleniveau in elke tenant binnen de organisatie. Tot slot moet je de excess drift rate bijhouden. Deze metriek laat zien of je opschoonacties op de lange termijn echt effect hebben. Hoe snel beginnen die rechten zich weer te verspreiden nadat je een herstelproject hebt afgerond. Hoe vaak sluipen die brede groepen weer terug in het systeem. Veel teams beseffen dit te laat omdat ze de oplossing in malig maten en aannamen dat het probleem voorgoedweg was.

Dat was het niet. De enige metriek die ertoe doet is hoe snel het systeem verslapt zodra je er niet meer naar kijkt. Dat is je operationele dashboard. Je moet oversharing reduction, observability coverage, time to policy, label decking en excess drift bijhouden. Het ritme van je rapportage is net zo belangrijk als de cijfers zelf. Het centrale team moet het executive dashboard beheren, omdat de leiding één overzicht nodig heeft van de gehele status. Ondertussen moeten de decentrale teams het herstel beheren, omdat het eigenlijke werk moet gebeuren waar de tenant zich bevindt. Eén team leest het systeem en het andere team corrigeert het. Je moet deze cijfers bijhouden voordat je uitbreidt, niet achteraf. Het risico wacht niet op je volgende vergadering of governance workshop. Het is al actief in elke tenant waar Copilot precies kan vinden wat je huidige controles nog steeds toelaten. De twee patronen die leiders steeds over het hoofd zien.

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. Het eerste patroon begint wanneer een organisatie Copilot uitholt zonder een echte Purview Baseline in te stellen of hun SharePoint toegang te controleren. Op de eerste dag ziet de uitrol er perfect uit. Licenties zijn toegewezen, gebruikers zijn enthousiast en de interne berichtgeving gaat volledig over productiviteit. 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. 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. Maar nu hoeft dat niet meer. Een gebruiker stelt een basisvraag, er komt een samenvatting terug en er verschijnt een bestand.

Misschien is het gevoelige oude inhoud, financiële gegevens of dealinformatie die binnen een zeer kleine kring had moeten blijven. Er was geen inbreuk, geen malware en geen doorbroken beveiligingsgrens in de traditionele zin. Het systeem gebruikte simpelweg de machtigingen en de inhoudelijke status die de tenant al toestond. Dat is het moment waarop veel teams het probleem eindelijk begrijpen. AI heeft de blootstelling niet gecreëerd. Het heeft alleen de wrijving weggenomen die het voorheen verborgen hield. Zodra dat in één tenant gebeurt, daalt het vertrouwen van het management meestal in de hele organisatie, omdat niemand met zekerheid kan zeggen waar datzelfde patroon zich de volgende keer zal voordoen. Het incident lijkt misschien lokaal, maar de schade aan het vertrouwen is bedrijfsbreed. Het tweede patroon is stiller, maar minstens zo gevaarlijk. Een bedrijf zet identiteitsrelaties tussen tenants op, hoort dat multitenant scenario's mogelijk zijn en gaat ervan uit dat een bedrijfsmodel volwassen genoeg is voor een brede uitrol.

In een presentatie klinkt dat als een solide plan. In de werkelijkheid worden de operaties rommelig. Het ene team verwacht een soepele co-pilot ervaring in elke verbonden omgeving, terwijl het andere vergelijkbare zichtbaarheid verwacht en het derde aanneemt dat dezelfde controles de gebruiker overal volgen. Vervolgens legt het daadwerkelijke gebruik ongelijkmatig gedrag, hiaten in authenticatie en zwakke plekken in wat daadwerkelijk meetbaar is bloot. Het probleem is niet dat deze teams onzorgvuldig waren. Het echte probleem is dat ze connectiviteit hebben vertaald naar zekerheid. Die aanname creëert een vals beeld van compliance. Het management hoort het woord verbonden en gaat ervan uit dat de organisatie er klaar voor is. Maanden later blijkt uit controlebeoordelingen dat gedrag, bewijsvoering en handhaving veel meer varieerde dan iemand aan het begin wilde toegeven. Vergelijk dat nu eens met een beter patroon.

Een andere organisatie kiest ervoor om te vertragen voordat ze opschalen. Ze bepalen eerst een basislijn voor labels, ze beoordelen eerst brede toegang en ze valideren hun adit zichtbaarheid voordat ze iets anders doen. Ze breiden co-pilot in golven uit, niet omdat ze bang zijn voor adoptie, maar omdat ze willen dat elke golf bruikbaar bewijs levert voordat de volgende begint. Die organisatie gaat op de lange termijn meestal sneller omdat ze niet constant hoeven te stoppen om verrassingen uit te leggen, blootgestolde inhoud op te schonen of te discussiëren over wat governance eigenlijk hoorde te betekenen. Dat is het voordeel dat de meeste leiders over het hoofd zien. Goede governance blokkeert je uitrol niet. Het haalt de vertraging uit de uitrol zodra die eerste golf is afgerond. De valkouw is niet de adoptie zelf. De valkouw is onbeheerde adoptie over tenants heen die van een afstand verbonden lijken, maar zich heel anders gedragen als je van dichtbij kijkt.

De beslissing die je moet nemen is eigenlijk heel simpel. Je moet nu overstappen op een gefedereerd hap- en spook AI governance model en stoppen met het aanzien van tenant per tenant schakelen voor echte controle. Je moet je co-pilot uitbreiding pauseren in elke tenant die zijn logging, reviews op oversharing en label basisdekking niet kan aantonen. AI zal het systeem volgen dat je daadwerkelijk bouwt, niet het organigram waaraan je rapporteert. Als dit je kijk op multitenant co-pilot governance heeft veranderd, volg mij, Mirko Peters, op LinkedIn en deel dit met je team als je momenteel met deze problemen worstelt.