Een IT-beheerder bij een ingenieursbureau krijgt van de directie de vraag hoeveel AI er in huis wordt gebruikt. Hij heeft de proxylogs: elke URL, elke gebruiker, elk tijdstip, een jaar terug. Hij kan de vraag beantwoorden. Alleen doet hij dat met een bestand dat veel meer prijsgeeft dan waar iemand om vroeg.
Voor die vraag heb je vier velden nodig: het domein van de dienst, de dag, een telling en een categorie. De gebruiker hoort daar niet bij. Alles wat verder in de proxylog staat, is meer dan overbodig: het maakt er een ander soort meting van.
Welke vraag beantwoord je eigenlijk?
Stel eerst de vraag scherp, voordat je gegevens kiest. In de praktijk zijn het er drie. Welke AI-diensten worden in de organisatie geopend? Is daar een besluit over genomen? En verschuift het gebruik naar de tools die we hebben aangewezen, of juist ervan weg?
Alle drie gaan over diensten en over de organisatie als geheel. In geen van de drie komt een persoon voor. Dat is geen toeval van de formulering, maar precies de reden dat meten en volgen twee verschillende dingen zijn, zoals ons artikel over AI-monitoring versus medewerkersmonitoring uitlegt. Welke cijfers daaruit de moeite waard zijn voor een bestuur, staat in AI-gebruik meten.
Er is één vraag waarvoor je wel een persoon nodig hebt: wie deed dit, bij een concreet incident? Dat is een onderzoek, met een eigen procedure en een eigen grondslag. Houd het buiten de meting, anders gelden de eisen van dat onderzoek voortaan ook voor de meting.
Wat betekent dataminimalisatie bij een meting?
De AVG vraagt in artikel 5 lid 1 onder c dat persoonsgegevens toereikend, ter zake dienend en beperkt zijn tot wat noodzakelijk is voor het doel. Meestal wordt dat gelezen als een rem: verzamel minder. Bij een meting werkt het beter andersom. Begin bij het doel, bepaal welke velden je daarvoor nodig hebt en leg alleen die vast.
Dat heeft een prettig gevolg. Een meting die alleen domein, dag, aantal en categorie bevat, zegt niets over een persoon. Je hoeft hem niet te beveiligen als een personeelsdossier, niet kort te bewaren en niet te verantwoorden als gedragsregistratie. Wat je niet vastlegt, kan ook niet lekken of worden opgevraagd.
Welke gegevens heb je nodig, en welke niet?
| Gegeven | Nodig? | Waarom |
|---|---|---|
| Registreerbaar domein van de dienst | Ja | Zegt welke tool het is en koppelt de waarneming aan een besluit in het register |
| Dag van de waarneming | Ja | Laat een trend zien: deze week, vorige maand, sinds een besluit |
| Aantal (telling) | Ja | Laat zien hoe breed een tool wordt gebruikt en of dat groeit |
| Categorie: gebruiksdoel of frequentieklasse | Ja, als telling | Laat zien waar AI in het werk wordt ingezet en of het om uitproberen of routine gaat |
| Status van de tool in het register | Ja | Komt niet uit de meting maar uit het besluit; samen geven ze het aandeel via toegestane tools |
| Gebruikers-id of e-mailadres | Nee | Voegt niets toe aan de drie vragen en maakt van een telling een gedragsregistratie |
| Inhoud van de prompt | Nee | Zegt iets over de persoon en de klant, niets over de tool |
| Pad achter het domein | Nee | Bevat vaak een gespreks-id of een stuk van de vraag |
| Tijdstip op de seconde | Nee | Een dag volstaat voor de trend; seconden maken een kleine groep herleidbaar |
| Afdeling | Alleen met een ondergrens | Handig voor gerichte hulp, maar een afdeling van drie is zo goed als één persoon |
Om de rechterkolom draait het. Bij elk veld dat je toevoegt, moet je kunnen zeggen welke van de drie governancevragen je er beter mee beantwoordt. Is het antwoord "geen", dan gaat het veld eruit.
Waarom is het pad erger dan het lijkt?
Het domein chatgpt.com zegt dat iemand ChatGPT opende. Het volledige adres bevat bij veel AI-tools ook een gespreks-id, en bij zoekgerichte tools soms de vraag zelf. Wie "alleen de URL" logt, logt daarmee welk gesprek iemand voerde, en soms waarover.
Dat is het verschil tussen een telling en een dossier, verpakt in één veld dat er onschuldig uitziet. Het registreerbare domein is genoeg om te weten of een dienst wordt gebruikt. De rest van het adres zegt iets over de persoon.
Hoe ziet dat eruit in de praktijk?
Het ingenieursbureau kiest voor de vier velden. Na een maand ziet het beeld er zo uit: Copilot is de meest geopende tool, maar niet de enige. ChatGPT en Perplexity komen dagelijks voor, en er staan drie gespecialiseerde tools tussen die niemand kende: een tool die tekeningen samenvat, een vertaaltool en een transcriptietool voor vergaderingen. Over twee daarvan is nog geen besluit genomen, simpelweg omdat ze in geen enkel overzicht stonden.
Niemand hoeft te weten wie ze opende. De tekeningentool verwerkt tekeningen van klanten, dus daar komt een besluit over. De transcriptietool verwerkt stemmen en namen, dus daar ook. De rest kan wachten. Over drie maanden kijkt de beheerder of het gebruik naar de aangewezen tools is verschoven. En dat allemaal zonder één naam in het bestand.
Het laat ook zien waarom een eenmalige inventarisatie snel achterloopt: de drie onbekende tools stonden in geen enkele vragenlijst, omdat niemand wist dat hij ernaar moest vragen.
Hoe past dit bij de manier waarop BeeSensible is gebouwd?
De extensie ziet wanneer iemand een AI-tool opent en geeft alleen het registreerbare domein door, hooguit één keer per dag per apparaat, zonder gebruikers-id, zonder pad en zonder pagina-inhoud. Hoe vaak iemand AI gebruikt (dagelijks, wekelijks, af en toe), wordt op het apparaat zelf bepaald en één keer per maand als anonieme telling per categorie doorgegeven. Om te zien waarvoor AI wordt gebruikt, deelt de cloudmodus alleen de eerste prompt van een gesprek in bij een van zeven categorieën. Daarna wordt de tekst weggegooid en telt alleen de categorie.
In het dashboard zie je dat terug als cijfers over de organisatie: welke tools, hoeveel, welk aandeel via toegestane tools en wat er gebeurde na een melding. Een uitsplitsing per medewerker staat er nergens in.