Mag je persoonsgegevens gebruiken om een AI mee te trainen?

ahmedgad / Pixabay

Een lezer vroeg me:

Wij willen in onze organisatie gaan experimenteren met AI oftewel machine learning voor tekstanalyse. Onze bronbestanden bevatten persoonsgegevens (denk aan ingevulde aanvraagformulieren en onze beoordeling daarvan). Mogen we die meenemen in het bouwen van ons systeem?
Het gebruik van persoonsgegevens is natuurlijk gereguleerd onder de AVG. In principe is het niet de bedoeling dat je persoonsgegevens voor andere doeleinden gebruikt, zie mijn blog over testen met persoonsgegevens* als voorbeeld.

Er is echter een specifieke route bij het gebruik van data voor trainen van AI. AI oftewel machine learning is immers “alleen maar” statistiek, je zoekt naar patronen met wiskundige algoritmes, bijvoorbeeld lijnen die een heleboel metingen in twee groepen (ja/nee, gevaarlijk/normaal, etc) verdeelt of een formule waarmee je een nieuwe meting kunt plaatsen. In AVG terminologie noemen we dit een verwerking voor statistische doeleinden.

Vanwege artikel 5 lid 1 sub a AVG is dat dan in principe verenigbaar met het oorspronkelijke doel, wat dat doel ook was. Je mag statistisch onderzoek doen op je rechtmatig verkregen persoonsgegevens, daar is geen aparte toestemming voor nodig. De voornaamste eis is dat wat daaruit komt, niet rechtstreeks terug wordt toegepast op de betrokken personen, en al helemaal niet als een geautomatiseerde besluitvorming (artikel 22 AVG).

Dat is bij een AI model totaal niet aan de orde. Sterker nog, persoonsgegevens zijn gewoonlijk niet meer dan ruis – die paar keer dat er “Jansen” in een veld staat, heeft geen enkel effect. De vele duizenden bedragen waartussen geïnterpoleerd kan worden, of de velden met geslacht, werkzame status et cetera zijn veel belangrijker. Het statistisch model (“de AI”) dat eruit komt, zal dus niet of nauwelijks beïnvloed zijn door die namen of adressen in het bronbestand.

Het risico dat ik wel zie, is dat je een bron-dataset hebt waarin al die Jansens met naam en toenaam staan. Dat bestand zal dus goed moeten worden bewaakt, want daarin zitten dus leesbare persoonsgegevens en die zouden kunnen lekken of voor niet-statistische doelen worden ingezet. Tegelijk zul je dit bestand wel steeds nodig hebben bij iedere update, dus dit direct weggooien is ook weer geen optie.

Arnoud * sed s/Wbp/AVG/g

17 reacties

  1. Dat lijkt me een beetje kort door de bocht. Bij hergebruik voor statistische doeleinden geldt de verplichting zo veel mogelijk te anonimiseren/pseudonimiseren. Als ‘de paar keer ‘Jansen’ in een veld’ niet nodig is voor de statistiek, moet je zulke direct identifiers uit je bestand halen.

    Dat maakt de dataset nog niet anoniem. Zeker in AI-context moet je al snel van indirecte herleidbaarheid uitgaan.

    En waarom zou het bestand nodig zijn ‘bij iedere update’ Dat is dan toch geen statistisch doel?

    1. Het is niet zozeer “niet nodig”; een ML systeem filtert zulke gegevens er zelf uit. Het genereren van het model zelf is dus het anonimiseren van de data, wat mij betreft.

      Ik zie niet hoe je een persoon uit de dataset indirect kunt herleiden. Die gegevens worden zo gereduceerd tot statistische uitspraken dat je niet terug kunt naar de brondata.

      Het bestand is nodig omdat je bij een update geheel opnieuw moet gaan trainen. Je kunt niet drie regels toevoegen aan een ML model, je moet opnieuw alle tienduizend plus drie nieuwe erin stoppen.

      1. Maar dan heb je na 10 jaar toch nog steeds meneer Jansen in een verzameling staan (om ML te trainen) terwijl meneer Jansen 10 jaar geleden alleen heeft gevraagd of de gestoofde peren op voorraad zijn. Door de bron forms niet te anonimiseren rek je het steeds verder op.

      2. Fijne blog, dank Arnoud!

        Wat kanttekeningen (tot mijn spijt, ik vind “kan best” persoonlijk een erg fijn uitgangspunt ?): – Je kunt in sommige gevallen best drie regels toevoegen aan een ML model (bekend als incremental/online learning), en; – (helaas) is het ook niet ongebruikelijk om individuele datapunten terug te kunnen herleiden uit getrainde modellen (staat bekend als memorization )

        Maar goed, ik weet niet in hoeverre (met name het laatste) een fundamentele eigenschap is van het gebruik van ML modellen, of een edge case is.

        1. Terecht punt, bij GNN kan er inderdaad invoer in de uitvoer belanden. Zie daarover mijn blog van juli over de GNN-gedreven codehulp van Github, die andermans open source code reproduceert als dat zo uitkomt.

          Ik had de focus op classifiers en dergelijke, ML die labels plakt (of getallen inschat) om input ergens in te delen. Groot/klein, 1/2/3, wel/niet, 0..100. Dan is het volgens mij niet mogelijk dat iemands naam in de uitvoer terecht komt?

          1. Het is fundamenteel mogelijk met elk model de train data terug te krijgen. Sommige modellen lukt dat beter, omdat deze beter zijn met memoriseren, en heel veel paramaters hebben om de kleinste gevonden patronen ook op te slaan. Zulke patronen, zeker met text-data, zijn dan bijvoorbeeld burger-service nummers, telefoon nummers, namen, en adressen. En heb je 15GB aan service desk data, dan kun je dat er maar lastig automatisch of manueel uitvissen.

            Maar vaak is dit niet eens een probleem. Een model neemt een beslissing (deze advertentie heeft meer kans op klik voor deze bezoeker) en een kwaadwillige kan dat nooit gebruiken om terug te rekenen. Die heeft het hele model op de harde schijf of via een API nodig, en vaak honderden tot duizenden input-output tests.

            Naast memorizatie is herleidbaarheid een (groter) probleem. Er zijn combinaties van legale features mogelijk (bijvoorbeeld “postcode” en “geboortedatum”) die vaak genoeg herleidbaar zijn tot een enkele persoon. Of zeg, jij anonimiseert wel de ratings (Netflix), maar kun je soortgelijke ratings vinden op IMDB, en dan via de gebruikersnaam en forumposts de persoon herleiden.

            Train sets, ook met periodiek hertrainen, zijn vaak dynamisch. Dit is een technisch dingetje (je wil een training set kunnen genereren voor enkel een bepaald type, of accuraatheid over tijdsspanne meten). Een training set is dus vaak in de praktijk niets dan een JSON instructie bestandje. Dan zit je ook niet met bewaartermijnen. Die CSV bestaat zo lang als de test of training nodig is.

            Die bovenstaande gangbare praktijk maakt het ook mogelijk om AI los te koppelen van data infra (waar train data een onderdeel van is). Zie het gewoon als een database en alle juridische kennis daarover kan direct toegepast worden. Wordt dit een train set (uitdraai) en ga je die ergens anders opslaan dan wordt dit snel een lastig probleem, over het kopieren van een database. Hertrainen van een analyse dan niets anders dan kijken met SQL naar de laatste maand vanaf nu, ipv 2 maanden terug.

            Ik zou zelfs zeggen, gegeven memorisatie, het model en voorspelling is niets dan een voorgeprepareerde SQL query uitvoerbaar door je medewerkers of breed publiek. Geeft je database dan persoonsgegevens en is dit een probleem? Dan automatisch ook voor alle intelligente analyse die daarop volgt: Een SQL query niets meer dan een SQL-query die aangepast wordt of degene die de query uitvoert bij deze of deze afdeling werkt. Dan heb je toch ineens 20-30 jaar aan bestaande jurisprudentie?

          2. Dan is het volgens mij niet mogelijk dat iemands naam in de uitvoer terecht komt?

            Niet direct in de uitvoer, maar nog steeds herleidbaar. Ik snap er ook het fijne niet van, want dit staat echt gelijk aan het ontwerpen van encryptie protocollen.

            Stel een sentiment analyse voor text heeft de persoonsnaam “Alice” in de train data gezien, maar de persoonsnamen “Bob” en “Clarice” niet. Als je dan een invoer geeft met “Bob” of “Clarice” dan zal de voorspelling nooit veranderen, omdat het model hier nooit van geleerd heeft en het dus niet in haar berekening gebruikt. Verander je dan “Bob” in “Alice” en wordt de voorspelling aangepast van 95.55% positief sentiment, naar 95.56% positief sentiment, dan weet je dat dit in de berekening wordt meegenomen (kan alleen als dit in de training data zat).

            Zelfde soort techniek kun je gebruiken om aan te tonen dat vrijwel alle text-modellen ongewenste bias hebben (“ik ga eten bij de Italiaan” vs “ik ga eten bij de Chinees” vs “ik heet Linda” vs “ik heet Antwon”).

          3. Ik zie niet waarom je in een GNN iemands naam aan de invoer zou toevoegen. En als je dat niet doet kan geen enkel model die naam als uitvoer geven. Zelfs al gebruik je een te groot model dat de trainingsdata reproduceert (dat zal doorghaans heel slecht presteren op je test zet, dus ik kan me niet voorstellen dat je dat ooit in productie neemt), Dan heb je toch eigenlijk geen bewerking van de data meer gedaan, maar een andere manier gevonden om de data die je toch al mocht hebben op te slaan?

  2. Arnoud, dank. Bij complexere AI’s met medische gegevens speelt dit tevens een rol. Zie jij ook de volgende bezwaren (art. 22 GDPR)

    The data subject shall have the right not to be subject to a decision based solely on automated processing , [This] …shall not apply if the decision: (a) is necessary for entering into a contract… or (c) is based on the data subject’s explicit consent.

    1. Valt AI onder automated decision-making of is de AI-beslissing terug te leiden tot menselijke interventie?
    2. Is er inderdaad expliciete toestemming voor EU-verwerking nodig van individu?
    3. Kan medisch AI-onderzoeker vanuit huis inloggen op het bronbestand met medische data of kan dit zelfs uit worden besteed aan derde partij?
    1. AI op zich is niet meer dan een analyse: een statistisch model concludeert dat de invoer het beste past bij de categorie “afgewezen”. En als je geluk hebt, kan het model ook aangeven welke factoren op welke manier wogen in die conclusie. (Voorbeeld: BigML hun decision tree.)

      Het wordt pas automated processing als je de conclusie van zo’n AI zonder betekenisvolle menselijke tussenkomst vertaalt naar een besluit, bijvoorbeeld door de visumaanvraag dan direct af te wijzen. Wanneer je de conclusie betrekt in een eigen redenering, is er geen sprake van het verbod. “Uw visumaanvraag laat zien dat u geen vaste baan heeft in Nederland. Ook geeft ons ML model aan dat xyz, en daarnaast heeft u geen handtekening gezet. Daarom wijzen wij af.”

      Je kunt werken met consent inderdaad, maar dat is dus niet verplicht als je het via de andere gronden speelt.

      Je vraag 3 is iets te complex maar zo kort door de bocht vind ik dit te spannend: wat gebeurt er met dat bronbestand, hoe is dat beveiligd op die thuis-pc en wie controleert dat de bestanden allemaal tijdig worden gewist, en niet voor andere doeleinden aangewend?

  3. “Het genereren van het model is het anonimiseren” is nog weer iets anders dan verwerking ten behoeve statistiek. Als je datagebruik voor AI-ontwikkeling framet als ‘om statistiek te bedrijven’ hoort daar de verplichting om de benodigde data eerst zoveel mogelijk te anonimiseren gewoon bij. Anders was die hele AVG-bepaling overbodig geweest: het resultaat van statistiek is immers altijd statistische informatie, niet persoonsgegevens.

    Herleidbaarheid in de dataset lijkt me daarnaast zeer goed mogelijk. De techniek ontwikkelt zich ook op dat vlak razendsnel. Belangrijk is dat ‘herleidbaarheid’ niet per se het op naam brengen van een individu hoeft te betekenen. ‘Singling out’ is al voldoende. Zie bv. het recente artikel ‘Anonieme telefoongegevens zijn niet zo anoniem’.

    En ik ben het eens met franc: data die je rechtmatig hebt mag je voor statistiek gebruiken, maar dan moet je die data dus nog steeds voor een ander legitiem doel nodig hebben, zonder dat de voor dat doel geldende bewaartermijn is verstreken. Je mag data voor speciaal voor statistiek ook langer bewaren, maar dan moet je oa. eerst zoveel mogelijk anonimiseren.

  4. Het risico dat ik wel zie, is dat je een bron-dataset hebt waarin al die Jansens met naam en toenaam staan. Dat bestand zal dus goed moeten worden bewaakt, want daarin zitten dus leesbare persoonsgegevens en die zouden kunnen lekken of voor niet-statistische doelen worden ingezet. Tegelijk zul je dit bestand wel steeds nodig hebben bij iedere update, dus dit direct weggooien is ook weer geen optie.

    “Je mag data niet langer bewaren dan nodig voor de doeleinden waar je het voor verzamelt”.

    “Oh maar we willen er in 2030 statistiek op doen en dat mag van art 5 lid 1 sub a”.

    “Oh oke dan bewaar maar zo lang als je wil.”

    Giechel.

  5. AI lijkt mij hier een afleiding. De database verword een training set, en dan ga je ineens allemaal regulatie krijgen bedoeld voor AI. “Zo veel mogelijk anonimiseren” is een stapje terug doen: Zo veel mogelijk vermijden om persoonsgegevens te registreren. Heb je die gegevens reeds, dan is anonimiseren vrijwel onmogelijk en een wassen neus: Dit staat gelijk aan de hoogste vorm van cryptografie, en zelfs de experts krijgen dit dus niet voor elkaar.

    Heb je dus reeds een database met persoonsgegeven daarin, en een SQL query die daaruit een training set maakt, dan is de training set en de database tabel feitelijk gelijk. Je gaat toch ook niet persoonsnamen uit de database halen alvast?

    Ik zie het dus maar als die tabel die elke Apache installatie standaard aan heeft staan en IP addressen, referers, en user agents opslaat. Die mag je verwerken voor statistische doeleinden en om de veiligheid van je systeem te waarborgen.

    Ingevulde formulieren zijn geen persoonsdata. En je wil niet met persoonsnamen trainen (Ik kan geen legitiem leerdoel daarvoor vinden, inderdaad dus ongewilde ruis).

    Voor een intelligent security systeem (de legitieme medewerkers onderscheiden van de hackers) heb je veel persoonsgegevens nodig. En dan gaat volautomatisch die laptop op slot, bij een confidente detectie. Voor fraude-bestrijding wil je vaak de opgegeven persoonsgegevens vergelijken met persoonsgegevens eerder verkregen.

    Verder is trainen met persoonsdata natuurlijk een probleem als het systeem de train data bloot kan geven. Afhankelijk van wie bij de output van het model kan, kan dan alsnog alle train data worden hersteld (een neuraal netwerk als een soort database met tabellen die patronen herkennen). Dit staat dan feitelijk gelijk aan het publiek aanbieden van je database met persoonsgegevens.

    Je kan vaak AI of ML vervangen door een SQL-script of een LIKE query die random resultaat teruggeeft. Je kan ook het hele neurale netwerk in de database opslaan. Eisen dat een scriptje wat de database checked voor buitenlandse inlog IPs ook haar training data anonimiseert is beiden technisch onmogelijk, en een bureacratische rompslomp gemaakt door mensen die wel om privacy geven, maar dit nooit in context plaatsen zodra de woorden AI vallen.

  6. Als train set = database te eenvoudig is, dan kijken naar de grootste train set ter wereld: Het internet. Daarom Google zo populair, en waarom Rusland en China hun eigen crawlers willen. Google kan wel het grootste taalgeneratie model ter wereld bouwen, maar waarom zou het dit willen openstellen aan een breed publiek? Dat gebruik je zelf, om je AI te verbeteren. Dezelfde geldstromen die 10-20 jaar geleden spraken over databankenrecht en illegale muziek-mashups, investeerden in het potentieel van big data en lieten banken en zoekmachines alles opslaan. Omdat men de toekomst had ingeschat: dan kunnen ze er wat mee, en verlies je van concurrenten als je het nooit had opgeslagen. Dus denk ik dat de “train set = database” en de (verouderde) intellectueel eigendom wetten tegengas gaan krijgen van het grote geld. Zelfde bedrijven die blafbrieven stuurden over het kopieren van een aantal database-records, trainen nu op al haar concurrenten en het brede publiek. Wie wordt er een betere Python programmeur? De mens met 6 maanden opleiding met 1 begeleider? Of een AI die compleet Github door kan spitten in 1 nacht? Wil je dat mogelijk maken, en de grote bedrijven en landen willen dat, dan moet je dus wel bloemige AI spraak doen, omdat je in werkelijkheid gewoon grootschalig inbreuk pleegt op auteursrechten. Dan natuurlijk niet van illegale muziek-mashups spreken.

  7. Dat je AI trainen “statistisch onderzoek” noemt lijkt mij creatief bedacht maar niet juist. Het trainen van AI /gebruiken van persoonsgegevens voor machine learning is geen onderzoek maar gewoon gebruik van gegevens voor behartiging van een (potentieel) gerechtvaardigd belang. Ten tweede wordt statistisch onderzoek in de AVG in één adem genoemd met andere verwerkingen in het algemeen belang (wetenschappelijk en historisch onderzoek en archivering in het algemeen belang). Overweging 50 geeft over deze verwerkingen expliciet aan: De Unierechtelijke of lidstaatrechtelijke bepaling die als rechtsgrond voor de verwerking van persoonsgegevens dient, kan ook als rechtsgrond voor verdere verwerking dienen. Oftewel: er moet een wettelijke grondslag zijn (lees: wet die dat algemeen belang bevestigt, denk aan de Wet op het CBS). Zie ook overweging 162: Bepalingen betreffende statistische inhoud, toegangscontrole, blabla … statistische geheimhouding dienen < in het Unierecht of het lidstatelijke recht te worden vastgesteld. Oftewel: alleen als we met z’n alleen hebben besloten dat we statistisch onderzoek belangrijk vinden en daar wettelijke kaders voor hebben geschapen kan dat onderzoek met persoonsgegevens plaatsvinden. En zelfs dan geldt nog (zoals je zelf ook aangaf) dat het resultaat ervan niet mag worden gebruikt “als ondersteunend materiaal voor maatregelen of beslissingen die een bepaalde natuurlijke persoon betreffen.”. Is dat laatste niet precies wat je met trainen van AI uiteindelijk probeert te realiseren, dat het systeem maatregelen of beslissingen kan nemen die een natuurlijk persoon betreffen?

    1. Los van de rest van je post waar ik mij verder niet in heb verdiept is AI trainen statistisch onderzoek noemen helemaal niet zo creatief en onjuist.

      Verschillende klassieke statististieken en methoden kunnen met ML/AI worden uitgevoerd. Wat maakt het voor verschil of je een regressie op de ouderwetse manier doet of met een ML algoritme? Helemaal niets.

      Wat maakt het voor een verschil of je met klassieke statistiek verbanden legt en een werknemer hier een beslisboom mee opstelt of dat je een ML algoritme gebruikt die direct een beslisboom opstelt die door een medewerker wordt gecontroleerd (op ongewenste/verboden onderscheiden bijvoorbeeld). Je verlegt hoogstens het moment van de noodzakelijke controle door een mens.

      Onderscheid maken tussen klassieke statistiek en machine learning is het nieuwe schoppen tegen de Bayesianen. Het is verzet tegen verandering uit conservatism en, naar mijn menining in ieder geval, net zo ongegrond als voorgenoemde kruistocht tegen Bayes.

      1. Ik zou de meeste ML zonder schroom als toegepaste statistiek kunnen classificeren. AI trainen heeft raakvlak, maar staat op zich compleet los van, de beslissingswetenschap. Hoe de toegang tot de resultaten, of de maatregelingen geregeld zijn, is uit mijn handen. Je bouwt als engineer de meest robuuste brug. Hoe men het vrachtverkeer daaroverheen gaat sturen is niet aan jou.

        Breiman (uitvinder van het beslisbomenbos), ooit als toegepast statisticus gezien, schreef hier ooit over:

        There are two cultures in the use of statistical modeling to reach conclusions from data. One assumes that the data are generated by a given stochastic data model. The other uses algorithmic models and treats the data mechanism as unknown. The statistical community has been committed to the almost exclusive use of data models. This commitment has led to irrelevant theory, questionable conclusions, and has kept statisticians from working on a large range of interesting current problems. Algorithmic modeling, both in theory and practice, has developed rapidly in fields outside statistics. It can be used both on large complex data sets and as a more accurate and informative alternative to data modeling on smaller data sets. If our goal as a field is to use data to solve problems, then we need to move away from exclusive dependence on data models and adopt a more diverse set of tools.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.