blog

Blog: 5 Vuistregels om de toepasbaarheid van de GDPR op AI trainingsdata te herkennen

21.04.2020

Ook AI systemen moeten voldoen aan de GDPR en dat is de verantwoordelijkheid van elke persoon betrokken bij de ontwikkeling en training van het systeem.

Het doel van deze blogpost is om een aantal referentiepunten te geven aan de teamleden die de algoritmes ontwikkelen en effectief de gegevens verzamelen en verwerken. Zo kunnen ze een aantal juiste reflexen aanleren en wordt het gemakkelijker om in te schatten of ze de data op een GDPR-conforme manier moeten verwerken. In geval van twijfel moet de compliance officer worden geraadpleegd om te zien of er verdere actie nodig is.

Binnen je organisatie bestaan waarschijnlijk regels die je moet toepassen wanneer je dataset persoonsgegevens bevat, waardoor de GDPR (in het Nederlands de Algemene Verordening Gegevensbescherming of AVG) van toepassing is en je bewegingsvrijheid met die gegevens beperkt wordt.

In de eerste plaats is het aan de compliance officer in je organisatie om hierover te waken en om maatregelen te nemen die GDPR-compliancy van een AI-systeem garanderen. Maar de compliance officer is niet rechtstreeks betrokken bij de dataverzameling, bij de ontwikkeling van de algoritmes en bij de systeemtests. Om juist in te schatten welke elementen van het systeem onderheving zijn aan de GDPR, is de compliance officer dan ook afhankelijk van de onderzoekers, programmeurs, productontwikkelaars en datascientists.

Dit betekent dat jijzelf en je collega's persoonsgegevens moeten herkennen om te beslissen welke interne regels van toepassing zijn op een dataset. Dit zorgt in de praktijk vaak voor problemen. Aan de ene kant ben je geen privacy expert en word je ook niet verondersteld dat te zijn. Aan de andere kant kan je niet met elke dataset naar de compliance officer lopen.

De onderstaande vuistregels helpen je bij het identificeren van persoonsgegevens in de data die je gebruikt om je algoritmes te trainen en dus bij het ondersteunen van het GDPR-beleid binnen je organisatie. Dit zonder dat je zelf eerste een privacy expert moet worden en zonder legalese (geen verwijzingen naar wetsartikelen, beloofd!).

Deze vuistregels zijn gebaseerd op echte cases die vermeden hadden kunnen worden indien deze principes gekend waren door de betrokkenen.

1. Ken je data

Het eerste en belangrijkste punt is het (leren) kennen van je data.

Niet oppervlakkig leren kennen op een post-corona "social distancing" manier, maar echt door-en-door leren kennen. De herkomst van de data, de kenmerken, de eigenschappen, de samenstelling, enz. Dit lijkt voor de hand liggend, maar dat is het in de praktijk allerminst.

Je data door-en-door kennen is niet alleen de beste garantie op een hoge datakwaliteit en kwalitatieve resultaten, maar het helpt je ook om de data GDPR-conform te gebruiken. Als je je data onvoldoende kent, kom je in de problemen. En je zal niet in staat zijn om de volgende vuistregels toe te passen, die allemaal een goede kennis van je data vereisen.

2. Vertrouw niet op de voorziene categorisering

De GDPR is van toepassing op de verwerking van "persoonsgegevens". Datasets worden vaak (vooraf) gecategoriseerd als "persoonsgegevens", "geanonimiseerde gegevens", "technische gegevens", "open data", enz.

Het kan verleidelijk zijn om op deze categorieën te vertrouwen om te beslissen dat je dataset geen persoonlijke gegevens bevat en de GDPR dus niet van toepassing is, maar:

  1. deze categorieën kunnen onjuist zijn, en
  2. deze categorieën sluiten elkaar niet uit.

Dat een dataset wordt gecategoriseerd als technische gegevens of open data betekent niet dat deze set geen persoonsgegevens kan bevatten, waardoor de GDPR (toch) van toepassing is.

Dit kan zelfs wanneer de gegevens verondersteld worden "geanonimiseerde gegevens" te zijn. Als de gegevens naar behoren werden geanonimiseerd, dan zijn het geen persoonsgegevens meer. Tenzij wanneer heridentificatie mogelijk is, wat vaak het geval is. Bovendien betekent het feit dat persoonsgegevens openbaar beschikbaar zijn, niet per se dat ze vrij mogen worden gebruikt.

Houd er dus rekening mee dat je dataset, ongeacht het label, (nog) steeds persoonsgegevens kan bevatten.

3. Elk gegeven kan een persoonsgegeven zijn

Persoonsgegevens zijn:

  • alle gegevens die je in staat stellen om een persoon (in)direct te identificeren

EN

  • alle gegevens die aan een identificeerbare persoon kunnen worden gekoppeld.

Dit betekent dat letterlijk elke informatie als persoonsgegeven beschouwd wordt, wanneer je deze aan een persoon kan koppelen.

Neem een eenvoudig object, zoals bijvoorbeeld een stoel, en beschrijf het in een bestand.

Zodra je weet wiens stoel het is, wordt die informatie een persoonsgegeven. Want deze informatie vertelt je meer over die persoon. Bijvoorbeeld over diens consumptiegedrag, rijkdom, gezondheid, enz. Het kan een goedkope stoel zijn, een standaardstoel of een designstoel. Of het kan een ergonomische stoel zijn, aangepast aan personen met rugklachten, enz.

Kortom, alle gegevens kunnen persoonsgegevens zijn, zelfs als ze enkel betrekking lijken te hebben op voorwerpen en technische aspecten. Zorg er dus voor dat je dit uitzoekt, voor je ermee de keuken intrekt.

4. Herken “gevoelige gegevens” en behandel deze extra voorzichtig

De persoonsgegevens in je dataset kunnen gevoelige aspecten blootleggen van degenen op wie ze betrekking hebben, waardoor ze met extra zorgvuldigheid moeten worden verwerkt. "Gevoelig" moet hier worden geïnterpreteerd in brede zin. Niet alleen de (bekende) "bijzondere categorieën" gegevens in de zin van de GDPR vallen hieronder (zoals gezondheidsgegevens, vakbondslidmaatschap, seksualiteit, etc.), maar alle gegevens die als "gevoelig" kunnen worden beschouwd omdat ze inzicht geven in de persoonlijke aspecten van iemands leven, boven de redelijke verwachtingen van die persoon.

Voorbeelden hiervan zijn locatiegegevens, audiobestanden van persoonlijke gesprekken en beelden van personen die zich niet bewust zijn van het feit dat ze gefotografeerd worden.

Als je dataset gevoelige gegevens bevat, zal je strengere regels moeten toepassen bij de verwerking hiervan. Als er binnen je organisatie geen specifieke regels bestaan voor het verwerken van gevoelige gegevens, informeer dan steeds je compliance officer over de aanwezigheid van dergelijke gevoelige gegevens voordat je ze gebruikt.

5. Vermijd “tech debt” door Privacy by Design toe te passen

Waarom zou je je zorgen maken over de bescherming van persoonsgegevens?

In de eerste plaats omdat jij en je organisatie belang hechten aan de privacy van de personen wiens gegevens je verwerkt. En ook omdat het niet naleven van deze regels je organisatie een slechte reputatie kan bezorgen en kan leiden tot het moeten betalen van zware boetes.

Dit betekent dat het van groot belang is om in elke fase rekening te houden met de GDPR-vereisten, ook in de designfase en bij het selecteren, opschonen en gebruiken van trainingsdata.

Als je dit niet doet, zal dit leiden tot niet-conforme AI-systemen. Vervolgens zullen deze systemen alsnog in overeenstemming met de GDPR gebracht moeten worden. Als het al mogelijk is om dit nog te doen, zal dit vaak grote(re) inspanningen en kosten met zich meebrengen.

Houd daarom vanaf het begin rekening met deze vereisten en vermijd het opbouwen van (privacy) tech debt in je AI-systeem.

Dit zijn praktische aandachtspunten. Ze zijn bedoeld om je te helpen om te identificeren of je trainingsdata onderworpen zijn aan de GDPR. In geval van twijfel moet je altijd bij de verantwoordelijke persoon binnen je organisatie nagaan hoe je een dataset moet behandelen.

Andere wetgeving, zoals het burgerlijk recht, het contractenrecht en het IP-recht, kunnen ook beperkingen opleggen aan wat je met een dataset kan doen. En ook de Europese Unie momenteel werkt aan specifieke wetgeving die van toepassing is op AI-systemen. De al-dan-niet toepasselijkheid van de GDPR geeft dus geen vrijgeleide voor eender welk gebruik van een dataset!

An English version of this blogpost has previously been published on the CiTiP KU Leuven website.

Auteur:

Auteur:

Brahim Bénichou

Legal researcher bij het Kenniscentrum Data & Maatschappij, verbonden aan het Centre for IT and IP Law (KU Leuven)