Gemini data-classificatie in Google Drive: labels automatisch toepassen
Gemini past in Google Drive automatisch classificatielabels toe op basis van jouw instructies. Open beta sinds augustus 2026, z...
Sinds september 2026 combineer je in de admin console publieksgerichte deelregels en datacondities in een enkele regel. Zo stel je sharing boundaries in en beperk je data-exfiltratie.

Sinds 14 september 2026 kun je in de Google Workspace admin console publieksgerichte deelregels en datacondities combineren in een enkele regel. Met die unified data protection rules stel je sharing boundaries in: harde grenzen aan met wie bestanden in Google Drive gedeeld mogen worden. Je kiest daarbij uit drie modi, van alles blokkeren tot een allowlist of een denylist. In dit artikel lees je wat de regels doen, hoe je ze instelt en waar je op moet letten bij de uitrol.
Sharing boundaries zijn de grenzen die bepalen met wie gebruikers binnen jouw organisatie bestanden mogen delen. Zonder zulke grenzen kan iedere medewerker in theorie een document openzetten voor iedereen met de link, naar een persoonlijk Gmail-adres sturen of een externe leverancier toegang geven tot een map vol klantgegevens. Dat is precies het moment waarop data-exfiltratie plaatsvindt: niet altijd kwaadwillig, vaak per ongeluk, maar het effect is hetzelfde.
Tot nu toe moest je zo'n grens opbouwen uit losse onderdelen. Je stelde iets in op het niveau van delen buiten de organisatie, en daarnaast werkte je met DLP-regels en classificatielabels om gevoelige inhoud te beschermen. Die twee werelden stonden naast elkaar. Vanaf 14 september 2026 komen ze samen in een enkele regel, binnen de unified data protection rules. Je combineert dan een publieksgerichte voorwaarde, wie mag dit wel of niet zien, met een dataconditie, om welk soort inhoud het gaat. Een regel kan bijvoorbeeld zeggen: delen buiten de organisatie is toegestaan, behalve wanneer het bestand een classificatielabel voor vertrouwelijk draagt.
De kracht zit in de drie modi waarin je een sharing boundary kunt zetten. Je kiest de modus die past bij hoe streng je organisatie wil zijn, en je kunt per regel verfijnen.
De eerste modus blokkeert alle externe sharing. Niemand deelt nog iets met een partij buiten je organisatie. Dit is de strengste stand en werkt goed voor organisaties die volledig gesloten willen werken, bijvoorbeeld bij zeer gevoelige dossiers of in een tijdelijk crisisscenario.
De tweede modus blokkeert alles behalve een allowlist. Externe sharing staat standaard uit, maar je maakt gerichte uitzonderingen. Je kunt specifieke organisatie-eenheden (OU's), specifieke groepen of specifieke externe domeinen op de allowlist zetten. Zo mag de afdeling Inkoop wel delen met het domein van een vaste leverancier, terwijl de rest van de organisatie dicht blijft. Dit is in de praktijk de modus die de meeste organisaties willen: standaard dicht, gericht open.
De derde modus werkt met een denylist. Hier staat externe sharing standaard aan, maar blokkeer je specifieke interne OU's, groepen of externe partijen. Je kunt bijvoorbeeld een leverancier blokkeren waarmee je net een samenwerking hebt beëindigd, of een interne groep die met gevoelige persoonsgegevens werkt volledig afschermen, terwijl de rest van de organisatie normaal blijft samenwerken.
Het verschil tussen allowlist en denylist is een keuze in risicohouding. Een allowlist is veiliger, omdat je expliciet toestemming geeft en de standaard dicht is. Een denylist is soepeler en grijpt alleen in waar nodig. Kies de strengste variant die je werkprocessen nog toelaten.
De instelling vind je in de admin console bij de data protection rules. Je kiest daar de app Google Drive en vervolgens de optie om sharing te blokkeren. Binnen die regel stel je de modus in en bepaal je welke organisatie-eenheden, groepen of domeinen wel of niet mogen delen.
De logische opbouw is als volgt. Eerst bepaal je de scope: geldt de regel voor de hele organisatie of alleen voor een specifieke OU of groep. Daarna kies je de modus: alles blokkeren, allowlist of denylist. Vervolgens voeg je de uitzonderingen toe, de interne OU's, groepen of externe domeinen die je wel of juist niet wilt toestaan. Tot slot koppel je zo nodig een dataconditie, bijvoorbeeld een classificatielabel of een DLP-conditie, zodat de regel alleen geldt voor inhoud met een bepaald gevoeligheidsniveau.
Wat de regels sterk maakt, is dat je ze kunt stapelen. Je kunt een brede regel neerzetten die extern delen beperkt, en daarbovenop een fijnmazige regel die voor vertrouwelijke bestanden nog strenger is. Omdat publieksgerichte regels en datacondities nu in een en dezelfde regel samenkomen, houd je het overzicht. Je hoeft niet meer te reconstrueren welke losse instellingen samen welk effect hebben.
De unified data protection rules met sharing boundaries zijn beschikbaar voor Enterprise Standard en Plus, Education Standard en Plus, Enterprise Essentials, en Frontline Standard en Plus. Werk je in een kleinere licentie, dan kun je deze specifieke combinatie niet gebruiken, maar de onderliggende deelinstellingen blijven uiteraard wel bestaan.
Data-exfiltratie klinkt als iets voor grote concerns, maar het begint klein. Een medewerker die een export deelt met een privé-adres, een projectgroep die een map openzet voor een externe partij die later afhaakt, een leverancier die toegang houdt na het einde van een contract. Sharing boundaries pakken dat patroon bij de bron aan: niet door achteraf te zoeken wat er is weggegaan, maar door vooraf te bepalen wat er weg mag.
Dat sluit aan op een zero trust-gedachte. Je vertrouwt niet standaard dat elke gebruiker de juiste afweging maakt op het moment dat hij op delen klikt, maar je legt de grens centraal vast. De gebruiker merkt daar meestal weinig van, zolang zijn normale werk maar binnen de regel past. Alleen de uitzondering, het delen met een partij die niet is toegestaan, wordt geblokkeerd.
Het mooie is dat je dit kunt combineren met andere beschermingslagen. Denk aan context-aware access, dat toegang afhankelijk maakt van identiteit, locatie, apparaatstatus en IP, en aan client-side encryption voor de gevoeligste bestanden. Samen vormen die lagen een verdediging in de diepte: zelfs als een grens ergens niet dicht is, vangt een andere laag het op.
Begin niet met de strengste stand voor de hele organisatie. Dat levert onnodig veel supportvragen op en ondermijnt het draagvlak. Werk in stappen.
Breng eerst in kaart met wie nu wordt gedeeld. Kijk welke externe domeinen en groepen veel voorkomen. Dat zijn de partijen die je waarschijnlijk op een allowlist wilt, of bewust niet.
Kies daarna een pilotgroep. Een afdeling die met gevoelige gegevens werkt en tegelijk openstaat voor feedback is ideaal. Zet daar de strengere modus aan en meet wat er gebeurt.
Communiceer vervolgens vooraf. Leg medewerkers uit wat er verandert, waarom, en hoe ze een uitzondering aanvragen. Een grens zonder uitleg voelt als een blokkade, met uitleg voelt het als bescherming.
Breid daarna uit naar de rest. Zet de allowlist of denylist organisatiebreed aan zodra de pilot stabiel loopt, en combineer de regel met classificatielabels voor de gevoeligste bestanden.
Monitor tot slot en stel bij. Bekijk welke blokkades optreden en of die kloppen. Een grens is geen eenmalige instelling, maar iets dat je met de organisatie mee laat groeien.
Stel dat een organisatie een map heeft met vertrouwelijke klantdossiers. Medewerkers mogen intern samenwerken, maar de inhoud mag het bedrijf niet verlaten. Met een denylist-regel op de betrokken groep, gekoppeld aan een classificatielabel voor vertrouwelijk, wordt delen buiten de organisatie geblokkeerd zodra een dossier dat label draagt. De rest van de organisatie blijft gewoon samenwerken.
Die combinatie is de kern van de unified regels: je kijkt niet alleen naar wie deelt, maar ook naar wat wordt gedeeld. Een regel die alleen op publiek stuurt, zou te grof zijn en te veel normale samenwerking blokkeren. Een regel die alleen op inhoud stuurt, laat de vraag open met wie iets mag worden gedeeld. Door beide te combineren, krijg je een grens die precies past bij de gevoeligheid van de inhoud.
Elke organisatie heeft uitzonderingen nodig. Een vaste accountant, een samenwerkingspartner of een moederbedrijf moet bereikbaar blijven. De kunst is om die uitzonderingen expliciet te maken in plaats van de hele grens open te zetten.
Gebruik daarvoor de allowlist-modus: standaard dicht, gericht open voor specifieke organisatie-eenheden, groepen of domeinen. Leg vast wie een uitzondering mag aanvragen en wie die goedkeurt. En herzie de lijst periodiek, want samenwerkingen veranderen. Een leverancier die vorig jaar is toegevoegd, is misschien niet meer relevant. Zo blijft de allowlist een levend instrument en geen vergeten lijst.
Naast de technische stappen is er een organisatorische kant. Denk vooraf na over de communicatie naar gebruikers, over wie supportvragen opvangt en over hoe je omgaat met werkprocessen die door de nieuwe grens niet meer vanzelf gaan.
Test de regel daarom eerst op een kleine groep, meet welke blokkades optreden en los de terechte uitzonderingen op voordat je uitbreidt. Zo wordt de grens niet ervaren als een storing, maar als een bewuste bescherming van de gegevens waar het om gaat.
Gemini past in Google Drive automatisch classificatielabels toe op basis van jouw instructies. Open beta sinds augustus 2026, z...
Device Bound Session Credentials bindt sessiecookies aan het apparaat. Sinds mei 2026 staat het standaard aan in Chrome op Wind...
Stap-voor-stap handleiding voor Google Workspace beheerders: wat te doen bij een gehackt account, van onmiddellijke maatregelen...
Wij reageren binnen 1 werkdag met een eerlijk en concreet antwoord.
Vraag over het artikel.
Prijsindicatie ontvangen.
Hulp bij toepassing.
Vraag of melding indienen.