Tag: Compliance

About Compliance

Subscribe Feeds

Hoe lang mag je persoonsgegevens bewaren voor compliancedoeleinden?

Geplaatst op in Ondernemingsvrijheid, Privacy, 3 reacties

Microsoft heeft toezeggingen gedaan over zijn chatdienst Teams aan de Europese Commissie, las ik bij Tweakers. Die zijn een reactie op een klacht van concurrent Slack dat MS mensen Teams zou opdringen via Office-integratie. Want dat is natuurlijk een stuk makkelijker dan een losse dienst verkopen. Over waarom de API hét sleutelpunt is van veel ict-juridische kwesties, dat lees je in ons nieuwste boek volgend jaar. Want ik zag de interessante vraag: het is wel zo veel handiger voor compliance. Hoe zit dat?

De vraag komt in de kern neer op “wat doe je dan om al je datastromen te integreren terwijl je wel complaint blijft met regulatory requirements?” Want dat gaat in Teams reuze handig: die maakt opnames en logs van chats en videogesprekken, dat komt in het juiste bakje in opslag en is eenvoudig te doorzoeken. Slack logt ook, maar dat koppelen met projectmanagementsoftware is dan weer een paar extra stappen. Wat dus indirect de discussie gaf, mág dat eigenlijk wel en hoe ver mag je daarbij gaan?

Een zorg is altijd, mag ik gegevens wel bewaren. Als het gaat om compliance doeleinden, dan zou dat geen probleem moeten zijn. Als het moet van wet X, dan mag het automatisch van de AVG en toestemming van de werkgever is volledig irrelevant. Ik bewaar van al mijn medewerkers een kopie paspoort met bsn, dat moet in het kader van zwartwerkbestrijding dus dat mag van de AVG. Medewerkers die dat niet willen, hebben pech.

Waar dit echter vaak naar vertaald wordt, is “ik laat alle data 7 jaar staan zodat het management/afdeling compliance erbij kan”. Dat mag niet. Die paspoorten zitten in een afgesloten kluis waar alleen HR erbij kan nadat ik zeg dat dat goed is (of als de arbeidsinspectie een inval doet). Als een manager een geboortedatum wil weten, dan mag hij niet op die kopieën kijken.

Alles loggen “voor compliance/regulatory” is dus een juridisch zinloze uitspraak die ik helaas vaak zie bij security-achtige types die te veel Amerikaanse bangmaakfilmpjes hebben gezien. Hoofdregel: je mag niets bewaren, alles moet weg na direct gebruik. Doet dat pijn? Motiveer je reden én geef aan tot hoe lang het pijn blijft doen, daarna moet het weg. Als je antwoord “oneindig” is dan is het fout. Als je motivatie bij meerdere soorten gebruik past dan is ie fout. Als de motivatie speculatief is dan is ie fout. Als de motivatie neerkomt op “het is een optie in Teams” dan is ie fout.

Arnoud

Hebben universiteiten nu een AVG-probleem met die Proctorio hack?

Geplaatst op in Privacy, 23 reacties

Vele tienduizenden Nederlandse studenten zijn maandenlang gemakkelijk te hacken geweest, omdat hun opleiding hen verplichtte onveilige antispieksoftware te installeren. Dat meldde RTL Nieuws onlangs. Criminelen kunnen de software van Proctorio misbruiken om mee te gluren met de webcam en opnames te maken, of om toegang te krijgen tot online accounts, zoals je e-mail, betaaldiensten of crypto (de zogeheten online wallet). Diverse studerende lezers vroegen me: heeft mijn universiteit of hogeschool nu een AVG probleem, en moeten ze nu stoppen met Proctorio?

We hebben het eerder gehad over proctoring-software, die sinds de coronacrisis breed ingezet werd. Het argument daarbij was klassiek het privacy argument: studenten moeten zichzelf digitaal blootgeven in hun huisomgeving om vermoedens van fraude uit te sluiten. De rechter is daarin niet meegegaan: fraude bij tentamens is ernstig, het gaat maar om enkele uren per tentamen dus hoe erg is dat nou helemaal. (Bovendien, hoe moet het dan bij tentamens van 300 man.)

De onderliggende aanname is dan – zoals wel vaker – dat de software an sich veilig is en doet wat ie belooft. IT’ers beginnen nu te lachen, en die snap ik ook want als er iets is dat we de afgelopen vijf jaar hebben geleerd dan is het wel dat alle software lek is, onbedoelde features heeft en als je niet uitkijkt wordt ingezet om persoonsgegevens te harvesten voor ontwikkeling van diverse AI’s.

Deze hack is in zoverre een AVG probleem dat de inzet van proctoring software onder de AVG gerechtvaardigd moet worden, en bekend onveilige software voldoet natuurlijk niet. Het Proctorio lek is ondertussen alweer gedicht zo lees ik, waardoor er dus eigenlijk geen AVG issue meer zou moeten zijn. Natuurlijk kunnen er meer lekken zijn (alle software is immers lek) maar zonder specifieke aanwijzingen denk ik niet dat je hier wat mee kunt.

Arnoud

Niet noemen open source licentie is auteursrechtinbreuk

Geplaatst op in Intellectuele rechten, 6 reacties

Apollo Fintech maakte inbreuk op het auteursrecht van Jelurida door een cryptomunt aan te bieden die is gebaseerd op de ‘Nxt software’, zonder daarbij de licentie van Jelurida (de Jelurida Public License of ‘JPL’) te verstrekken, zo meldde Rechtspraak.nl onlangs (via). Leuk dat dan ‘JPL’ tussen aanhalingstekens moet als kennelijk gekke term, terwijl cryptomunt gewoon ingeburgerd is. Maar dat terzijde: vrij uniek dat er rechtszaken komen over de naleving van open source licenties. Het is hier natuurlijk weer een speciaal geval, een ruzie tussen twee groepen die werken aan dezelfde software.

De Nxt software implementeert blockchains, en de organisatie Jelurida is ooit begonnen met de Nxt software te ontwikkelen. Zij gebruikt daarbij de Jelurida Public License, een zo te lezen van de GPL afgeleide eigen licentie met een paar opmerkelijke bepalingen. Of je de JPL écht open source kan noemen is  daarom de vraag: de licentie eist een betaling in jouw eigen cryptomunt als je met die software een alternatieve blockchain maakt die niet compatibel is met de originele. Dat is niet helemaal hoe we open source normaal bedoelen, namelijk dat alles mag en je nooit hoeft te betalen. Maar dat terzijde.

Een paar jaar later kwam er de club Apollo, die haar eigen cryptomunt aanbiedt. Daarbij dreef zij op de Jelurida software, iets dat in eerste instantie ook erkend werd in de Github, maar ergens in 2019 verdween de licentievermelding en de tekst van de JPL. Onduidelijk is waarom, en in augustus 2020 kwam die vermelding ook weer terug, maar (mogelijk vanwege een breder gevoel van onvrede) toch stapte Jelurida naar de Nederlandse rechter (vanwege de forumkeuze uit de JPL).

De uitspraak heeft toch de nodige pareltjes. Zo was er meteen ruzie over of de ontwikkelaars van de Nxt software hun rechten wel aan Jelurida hadden afgestaan. Die hadden dat wel toegezegd, maar in digitaal getekende tokens en niet in officiële aktes. Dat is wel héél hypermodern (ik weet dat digitale aktes ook kunnen, maar is een token op de blockchain een akte):

Of overdracht onder een pseudoniem, in een Nxt Token, voorzien van een GPG public key en een Nxt account nummer, voldoet aan het dan geldende aktevereiste zal in dat geval ook moeten worden beoordeeld naar buitenlands recht.
Gelukkig voor Jelurida bleken er ook ouderwetse ontwikkelaars te zijn, die keurig een overdrachtscontract getekend hadden. Daarmee had men de ruimte om de claim te doen.

De volgende stap was discussie of Jelurida de licentie wel van de GPL (geldend op versie 0) mocht omzetten naar hun eigen JPL, omdat niet alle developers daarmee ingestemd zouden hebben. De kortgedingrechter veegt dat snel van tafel: te weinig bewijs dat daar rechthebbenden op tegen waren.

En dan de hamvraag: was het auteursrecht geschonden. Apollo had de software grondig herzien:

Niet in geschil is dat Apollo de Nxt Software heeft bewerkt en coderegels heeft toegevoegd bij het ontwikkelen van de Apollo Software. Jelurida heeft een rapport van 19 augustus 2020 van dr. A.K. Seewald overgelegd, waarin de code base van de Nxt public blockchain platform en de Apollo Foundation codebase met elkaar worden vergeleken. Seewald concludeert dat de Apollo Software een significant deel van de Nxt Software code bevat op bestand-, functie- en coderegelniveau. Tussen de 60% en 73% van de functies van de Nxt Software komen voor ten minste 50% overeen met functies van de Apollo Software. Driekwart van die overeenkomende functies is identiek. Van die overeenkomende functies kan 93% van de coderegels worden teruggevoerd op de core developers van de Nxt Software. Apollo stelt echter 400.000 regels aan eigen code te hebben toegevoegd en de code te hebben ge-refactored, met als resultaat dat de Apollo Software een wezenlijk ander product is dat voldoende van de Nxt Software verwijderd is om als zelfstandig werk te kunnen worden aangemerkt.
Dat laatste is geen argument: refactoring is juridisch gezien een vertaling of verfilming. Het betekent dat je het oude werk opnieuw weergeeft in een andere vorm, maar niet dat je alle brokjes creativiteit uit het origineel kwijt bent geraakt. En dat laatste is het enige argument dat je op tafel moet leggen. Iets is pas nieuw als al het oude (oké, al het creatieve oude) eruit verdwenen is.

Inbreuk dus. En in dit geval is dat een hele simpele: alleen al dat je de credit notice naar de originele licentie hebt verwijdert, maakt dat je deze schendt. En daarmee is de licentie automatisch vervallen, zij het dat het probleem natuurlijk wel in 2020 weer hersteld was. De rechtbank bepaalt dan ook (met dwangsom) dat Apollo zich netjes aan de licentie moet blijven houden, en al haar zakelijke klanten moet benaderen om ze de inbreukmakende versie te laten vernietigen. Schadevergoeding is niet aan de orde (het is een kort geding) maar wel moeten ze een kleine 40.000 euro proceskosten betalen.

Arnoud

 

Compliance en risicomanagement bij Artificiële Intelligentie leren? #legaltechtuesday

Geplaatst op in Iusmentis, 4 reacties

Steeds meer organisaties zetten Artificial Intelligence (AI) in. Dit versnelt beslissingsprocessen en schept nieuwe inzichten omtrent risico’s, klanteigenschappen en commerciële kansen. Deze techniek is zeer nieuw en haar inzet roept dan ook vele vragen op over de juridische en ethische randvoorwaarden. Mag dat wel, een computer laten beslissen? Welke kaders hanteer je om een verantwoorde inzet van AI te realiseren? Wordt het tijd voor een AI Compliance Officer?

De inzet van AI biedt nieuwe mogelijkheden. Bestaande processen kunnen fors worden versneld door menselijke tussenkomst te vervangen door een AI. Zo zou een AI-bewaker bagage van bezoekers kunnen screenen op ongewenste voorwerpen, en deze doet dat dan veel sneller dan een mens (en is bovendien om vijf uur niet moe en afgeleid). Een verzekeraar zou een AI in kunnen zetten om claims te kunnen analyseren.

Dergelijke analyses hebben echter ook diverse risico’s. Zo staan AI’s er om bekend dat zij bestaande vooringenomenheid (bias) uit de onderliggende data sterk uitvergroten, wat kan leiden tot ongewenst gedrag zoals discriminatie. Ook is het vaak lastig duidelijke uitleg te krijgen over hoe een AI tot zijn conclusie komt: dergelijke data-analyse is volkomen onvergelijkbaar met een menselijk gedachteproces.

Deze risico’s maken organisaties nog steeds huiverig over de inzet van AI. Ook de wetgever heeft niet stilgezeten: in de Europese privacywet GDPR is een expliciet verbod opgenomen om mensen aan besluiten te onderwerpen die door een AI zijn genomen. Hoe dan ook grip te krijgen op AI, en te zorgen voor een nette, ethisch verantwoorde inzet, is een lastige vraag voor veel organisaties.

In 2019 publiceerde de Europese Commissie de Ethics Guidelines for trustworthy AI. Onder “ethisch” verstaat men niet alleen het voldoen aan wettelijke regels, maar ook aan meer algemene ethische principes. Ethische AI bestaat uit drie componenten, waaraan gedurende de volledige levenscyclus van het systeem moet worden voldaan: de AI moet

  1. wettig zijn, door te voldoen aan alle toepasselijke wet- en regelgeving,
  2. ethisch zijn, door naleving van ethische beginselen en waarden te waarborgen, en
  3. robuust zijn uit zowel technisch als sociaal oogpunt, aangezien KI-systemen ongewild schade kunnen aanrichten, zelfs al zijn de bedoelingen goed.
Uitgaande van deze drie componenten komen de richtsnoeren tot zeven vereisten voor AI-systemen:
  1. Menselijke controle en toezicht
  2. Diversiteit, non-discriminatie en rechtvaardigheid
  3. Technische robuustheid en veiligheid
  4. Transparantie en verklaarbaarheid
  5. Privacy en datagovernance
  6. Maatschappelijk en milieuwelzijn
  7. Verantwoording en controleerbaarheid
Het toetsen aan deze vereisten komt in de praktijk neer op het welbekende proces van compliance: formuleer criteria waarmee naleving kan worden gemeten, zorg dat mensen doordrongen zijn van het belang van naleving en toets op de criteria. Dat dan ook nog eens op een positieve manier; nee zeggen is altijd makkelijk, maar technologie op een compliant en werkbare manier de markt op krijgen is een stuk lastiger.

Omdat het hier ook nog eens gaat om geavanceerde technologie en vaak vele partijen betrokken zijn, is AI compliance een uitdagende kwestie. Een AI compliance officer moet dan ook behoorlijk thuis zijn in wetgeving, techniek en de toepassingspraktijk.

Ik vond dit zo’n leuke dat ik de afgelopen weken eigenlijk alleen heb gewerkt aan mijn nieuwe leergang AI in de praktijk: compliance & governance. Deze online leergang is speciaal ontwikkeld voor informatieprofessionals, juristen en compliance officers die aan de slag moeten of willen met AI en de toetsing daarvan. Geen blokkades opwerpen, maar zorgen dat bedrijven en instanties aan de slag kunnen. Weten wat er wel kan en hoe dat wordt bereikt.

De stof wordt volledig online aangeboden. Met geavanceerde vormen van elearning kan de cursist eenvoudig werken en effectief de stof tot zich nemen. De docent is online beschikbaar voor 1-op-1 overleg, en via een discussieforum kunnen cursisten met elkaar overleggen en brainstormen.

Met dat forum is trouwens iets bijzonders: het wordt aangeboden door een fictief Nederlands dorp. De leergang kent namelijk een serious game element, waarbij deelnemers optreden voor bedrijfsleven en overheid in dat dorp om te zorgen dat AI-initiatieven volledig compliant én bruikbaar worden. Hoe beter men het spel speelt, hoe hoger het dorp scoort in de wereldwijde competitie van de Most AI-focused city in the world, bijgehouden door het fictieve United Nations Office for Global AI (UNOGAI). Bij pittige onderwerpen als deze is serious gaming een bewezen techniek om leren effectiever te maken.

Durf jij de uitdaging aan? Op 1 februari gaat de eerste ronde van start. Meer informatie en de inschrijfmogelijkheid vindt u bij ICTRecht.

Arnoud

 

 

 

Mijn klanten eisen dat mijn ontwikkeltraject AVG proof software geeft, kan dat wel?

Geplaatst op in Ondernemingsvrijheid, Privacy, 17 reacties

Een lezer vroeg me:

Als softwareontwikkelaar krijg ik steeds vaker vragen of mijn software wel AVG proof is. Ik begrijp die vraag en wil mensen ook best tegemoet komen, maar het voelt wel als een hellend vlak omdat ik dan ineens aansprakelijkheden op me neem. Stel ik bouw een exportfunctie van persoonsgegevens niet in, moet ik dan de boete betalen als mijn klant daarop aangesproken wordt?

Heel formeel sprekend heeft een softwareontwikkelbedrijf géén plicht om te zorgen dat hun software aan de AVG voldoet. De AVG stelt regels voor de verwerking van persoonsgegevens, en dat gaat pas spelen bij het in productie nemen van die software. Er is dus niets mis met software waarbij persoonsgegevens niet kunnen worden geëxporteerd, het enige is dat een afnemer die niet in kan zetten in situaties waarin de AVG op hem van toepassing is.

Praktisch gezien ontkom je er niet aan om rekening te houden met de AVG, precies om die reden. Een softwarebedrijf met Nederlandse klanten kan het niet maken om zo’n exportfunctie weg te laten, want zijn klanten voldoen dan gewoon niet aan de wet en hebben dus een groot probleem als ze deze software in gebruik zouden nemen.

De discussie zal dus meer gevoerd worden op hoe ver je moet gaan als developer, en ook waar de kosten komen te liggen. Want dat er een exportfunctie moet zijn is één ding, welke gegevens er wel en niet onder vallen is een heel ander. Daar zijn ook de juristen het nog niet helemaal over eens, bijvoorbeeld. En er zijn nog veel meer dingen: hoe vraag je precies toestemming en hoe makkelijk moet deze in te trekken zijn?

Ik denk dat je er op dit moment dan ook niet aan ontkomt om hier in detail over te spreken met je klant. Dit kan mijn software, dit wil jij erbij, ik weet van de AVG en wat zie jij? (/juf Ank). En dat dan vastleggen in functionele specificaties of test cases, en in het contract opnemen dat jouw verantwoordelijkheid is dat het zal werken zoals vastgelegd.

In de toekomst zie ik meer mogelijkheden. De AVG kent de optie om technologieën voor gegevensbescherming of -verwerking te certificeren. Je zou dan als developer zo’n certificaat kunnen halen, en daarmee je klanten gerust stellen dat ze jou prima kunnen kopen. Eventuele aansprakelijkheid zou dan zeer mee moeten vallen (je bent immers gecertificeerd) en zou wellicht ook nog te verhalen zijn op de certificaatverstrekker. Maar dit zal nog wel een jaar of vijf duren, minstens.

Arnoud

Je hebt nog 32 dagen om de AVG te implementeren #32totavg

Geplaatst op in Privacy, 30 reacties

Vandaag zijn er nog precies 32 dagen te gaan tot 25 mei 2018, de datum waarop de Algemene Verordening Gegevensbescherming (AVG, ook wel General Data Protection Regulation oftewel GDPR) van kracht wordt. Er is nog steeds veel onzekerheid over de AVG, die van alles zou verbieden of onwerkbaar maken. De AVG noem ik altijd vooral een compliance-wet: de nadruk ligt op formele procedures, documentatie en stappen die moeten worden genomen om aan de wet te voldoen. En minstens zo belangrijk: om aan te kunnen tonen dat je aan de wet voldoet, want de AVG bepaalt expliciet dat de bewijslast bij jou ligt dat je alles op orde hebt. Een hele kluif, maar zeker niet onoverkomelijk of fundamenteel onwerkbaar.

Een van de grootste mythes rond de AVG is dat deze nieuwe wet vooral voor juristen van belang is. Dat is niet zo. De AVG is zó breed van toepassing en stelt zó veel regels dat het iedereen aangaat. Van groot bedrijf tot kleine vereniging en van eenmansdokterspraktijk tot goed doel met duizenden donateurs. Voldoen aan de AVG is geen kwestie van nieuwe juridische documenten en een mooie toestemmingsverklaring laten tekenen door uw klanten.

Een belangrijk instrument daarbij is het verwerkingsregister, de centrale plaats waarin iedere verwerking van persoonsgegevens moet zijn gedocumenteerd. Het formeel vastleggen van verwerkingen is een van de weinige echt nieuwe eisen uit de AVG. Doel hiervan is vooral organisaties te dwingen goed na te denken over wat zij doen met persoonsgegevens en waarom. Het register is daarvan de verslaglegging. Tevens biedt registreren van een verwerking de mogelijkheid te checken of deze inhoudelijk voldoet, omdat je in het register ook zaken als grondslag en bewaartermijn uitwerkt en verwijst naar gepast beveiligingsbeleid. Dan moet je daar wel over nagedacht hebben, natuurlijk.

Kort en goed neem je in het register per verwerking het volgende op:

  • Naam en contactgegevens van de verantwoordelijke entiteit; dit is niet alleen de bedrijfsnaam maar ook de concrete afdeling en de verantwoordelijke manager of business owner.
  • De doeleinden, zoals “Salarisadministratie” of “Beveiliging van pand en goederen middels camera’s met geluidssensoren” met een omschrijving van de grondslag (toestemming, overeenkomst, et cetera).
  • De grondslag voor deze verwerking, zoals toestemming of een eigen belang, inclusief onderbouwing daarvan.
  • Een omschrijving van betrokkenen, zoals personeel, klanten, bezoekers of passanten.
  • Een omschrijving van ontvangers, zoals de afdeling die het uitvoert, het beveiligingsbedrijf dat de camerabeelden uitkijkt en de politie in geval van strafbare feiten. Ontvangers in landen buiten de EU moeten apart worden genoemd (inclusief land).
  • De bewaartermijnen, inclusief motivatie waarom deze termijnen en niet korter.
  • Een beschrijving van de beveiligingsmaatregelen voor deze verwerking, u mag hierbij verwijzen naar het algemene beveiligingsbeleid.
  • Een inschatting van het risico voor betrokkenen; als u meent dat dit hoger is dan normaal dan moet je een privacy impact assessment (PIA) uitvoeren (zie hoofdstuk 5).

Vaak wordt gezegd dat de AVG van alles en nog wat gaat verbieden. Niets is minder waar. De regels worden veel strenger, maar zijn vooral gericht op verantwoording afleggen. Toestemming vragen kan prima, maar kunt u bewijzen welke toestemming is gegeven, zijn mensen adequaat voorgelicht en kennen zij hun rechten? Gegevens tien jaar bewaren: oké, maar onderbouw eens waarom dat nodig is en niet een jaartje minder? Wij noemen de AVG daarom vooral een compliance-wet. Er moet veel geregeld en gedocumenteerd worden. Wat precies en hoe, dat leest u in ons Praktijkboek AVG Compliance.

Arnoud

GPL compliance engineering guide uitgebracht

Geplaatst op in Intellectuele rechten, 4 reacties

lolcat-im-in-ur-cvs.jpgVorige week verscheen versie 1 van de GPL Compliance Engineering Guide, geschreven door Armijn Hemel die u waarschijnlijk wel kent van het GPL-Violations project. Dit is een handleiding over hoe GPL-schendingen op te sporen. Een mooie aanvulling dus op de gids van SFLC waarin algemene stappen staan over hoe je je als bedrijf aan de GPL moet houden.

Wie zin heeft om eens wat apparaatjes open te schroeven en te kijken welke GPL software hij kan vinden, moet zeker eens met deze gids aan de gang gaan. Van nmap commando's tot soldeerinstructies om een apparaat aan je PC te kunnen hangen zodat je het kunt inspecteren.

Veel schendingen blijken in de CE industrie voor te komen. Niet zo gek gezien de zeer lage marges en hoge volumes: het gaat om snelheid en kostenbesparingen bij veel dozenschuivers, en de kosten van het volledig compliant zijn met open source licenties wegen daar niet altijd tegenop. Met gidsen als deze kunnen mensen gemakkelijker violations aantonen, en bedrijven die dit doen onder druk zetten zodat iedereen, ook de low-margin CE industrie, zich netjes aan de licenties houdt.

Via The Inquirer.

Arnoud