Suggesties voor Metadatastandaard #18
Conversation
Onduidelijk wat het toevoegt voor zowel burger als toezichthoudende partijen. Uiteindelijk gaat de overheid die het gebruikt over de inzet. Wanneer dit wel echt afwijkt, geeft "leverancier” meer informatie over wie het ontwikkeld heeft.
De inhoud hiervan kan aan bod komen in de velden “Impact” en “Risico’s”. Het huidige veld stelt teveel het middel centraal in plaats van wat het probeert te bereiken. In de handleiding zullen we expliciet aandacht besteden aan het IAMA mbt die twee velden, en ook voegen we hierboven een link naar IAMA/mensenrechtentoets toe.
Past prima onder het veld “bronnen”. Basisregistraties kunnen zelfs daar uitstekend gelinkt worden met de datacatalogus.
Onduidelijk wat dit toevoegt. Dit kan beter beschreven worden in “Doel”.
Hierdoor wordt duidelijk wie de maker is, wanneer dit afwijkt van de organisatie zelf. Dit kan bijvoorbeeld als een organisatie een algoritme 'huurt' of koopt van een commerciële derde partij. Toegezegd tijdens sessie met NGO’s.
Toevoegen van tags naar keuze van de aanleverende overheidsorganisatie, zodat algoritmeregistraties makkelijker gevonden kunnen worden.
Algoritmes gaan regelmatig gepaard met AVG-verwerkingen, waarvoor reeds een register bestaat. Dit kan aanvullende informatie bieden voor burgers en toezichthouders.
Indien er een mensenrechtentoets zoals een IAMA gepubliceerd is, kan hier naar verwezen worden in dit veld. Als deze niet is gepubliceerd, maar wel uitgevoerd, kan een organisatie dit alsnog aangeven met "Ja".
Momenteel beperkt het veld zich tot namen van gemeenten en provincies. In de nieuwe versie zouden we coördinaten van het geografische gebied mee kunnen geven. In veel gevallen zal dit overeenkomen met bestuursgrenzen, waar deze coördinaten reeds makkelijk toegankelijk zijn. Op lange termijn maakt dit het voor burgers dus mogelijk om op basis van geografie de relevante algoritmes te krijgen, zonder expliciet de gemeente, provincie, waterschap, omgevingsdienst e.d. aan te vinken.
ICTU wijst zelf betekenisloze ID’s toe aan registraties. Als er geen ID zit bij de aanlevering, dan wordt er vanuit gegaan dat het een nieuwe registratie is, en krijgt het door het Algoritmeregister een ID aangewezen. Bij het updaten van een registratie kan de bestaande ID meegegeven worden om ze de registratie te overschrijven. Deze ID’s kunnen ook helpen bij permanente urls. Dit is een tijdelijke oplossing.
Organisatienamen beperken tot de namen zoals deze voortkomen in organisaties.overheid.nl of TOOD. Gebruik maken van linked data naar die databases.
Beperken tot een nog nader te bepalen ISO-standaard. Dit maakt het wat simpeler en kleinere kans op fouten.
|
Het is lastig om meerdere ongerelateerde wijzigingen in één pull request te discussiëren. Maar door het verwijderen van de DPIA omschrijving mis je dingen die anders niet gevraagd worden in het formulier. DPIA's bevatten vaak ook een rechtmatigheidstoets, een analyse van de noodzaak en proportionaliteit (zie ook #9) en een inventarisatie van de maatregelen om de rechten en vrijheden van natuurlijke personen te beschermen. Deze aanpassing komt neer op het verwijderen van cruciale velden en schaden de controlefunctie van het register. De volgorde van eerst zoeken naar oncontroversiële aanpassingen en daarna pas een meer fundamentele discussie aangaan komt zeer onlogisch op mij over. Ik ben benieuwd naar de logica daar achter. Nog wat losse opmerkingen: De link naar het verwerkingenregister verwijst naar informatie die niet verplicht publiek is en dat vaak ook niet is. De opmerking dat een mensenrechtentoets is uitgevoerd maakt het gebruik van een algoritme niet toetsbaar. Daarvoor is de onderbouwing van de toets noodzakelijk. |
|
Ha Floor, we zullen volgende keer de wijzigingen proberen niet in één pull request te doen. Wat betreft de DPIA, de relevante vragen worden ook al gesteld in andere velden, zoals het veld over "proportionaliteit". Daarbij zou dat veld nog opgesplitst kunnen worden naar subsidariteit en noodzakelijkheid, zoals je voorstelt in pull request 9. Die aparte velden geven eigenlijk veel specifieker aan wat we uit een DPIA willen zien. En daarmee zetten we gelijk ook de vraag centraal, in plaats van het middel (DPIA). In de handleiding kunnen we dan bij velden specifiek verwijzen naar de DPIA, dat daaruit geput kan/moet worden. Met deze toelichting, is er dan informatie uit de DPIA die je denkt dat wegvalt? We hebben ervoor gekozen om een aantal "oncontroversiële" wijzigingen door te voeren, omdat we een aantal lessen getrokken hadden na de lancering. Die wilden we doorvoeren op korte termijn om te kijken of dat bevalt. Dat neemt niet weg dat we die fundamentele discussie nog steeds aangaan, ik kom daar op korte termijn op terug. Wat betreft bevoegde autoriteit, is het dan niet voldoende om te verwijzen naar de contactpersoon danwel de bezwaarprocedure? De link naar het verwerkingenregister zal er wellicht niet altijd zijn, maar als deze er wel is, lijkt het me alleen maar goed dat die wel opgenomen wordt. Voor de mensenrechtentoets geldt eigenlijk hetzelfde als de DPIA. De (relevante) resultaten moeten verwerkt worden in het register, via algemene velden. Als het goed is, is dan een omschrijving van de toets zelf minder relevant. |
|
Voor zowel de DPIA als de mensenrechtentoets heb ik een vrij fundamenteel bezwaar: Door niet expliciet de afwegingen mee te nemen maar alleen de resultaten maak je de resultaten oncontroleerbaar. Deze discussie is waarom ik vanaf het begin heb gepleit voor een helder statement over waarop precies gecontroleerd moet kunnen worden en door wie. Ik voel regelmatig dergelijke controles uit en ik kan uit ervaring vertellen dat dat zo is, maar het doel van het register is niet helder genoeg geformuleerd om dit voorstel naast een heldere norm te leggen en het zo te onderbouwen. Met betrekking tot de DPIA: Als de prop/sub aanpassing onderdeel is van de onderbouwing dat de noodzakelijke informatie al in het register staat stel ik voor om #9 te accepteren voordat een wijziging wordt besproken die daar afhankelijk van is. Overigens dekt het register daarmee nog steeds niet de lading van een DPIA omdat bijvoorbeeld de rechtmatigheidstoets en de maatregelen nog steeds ontbreken. Met betrekking tot de bevoegde autoriteit: als het goed is spreek je als betrokkene een bestuursorgaan aan en niet een contactpersoon. Wat als de contactpersoon op vakantie is? En niet elke vorm van contact is een bestuursrechtelijk bezwaar. Je kan bijvoorbeeld ook inzage vragen. Wel eens met het idee dat je niet teveel verschillende loketten zou moeten benoemen. Maar degenen die overblijven dekken de lading niet. Begrijp ik goed dat de informatie uit het verwerkingenregister voor dit register als optioneel wordt gezien? Een keuze om het verwerkingenregister niet openbaar te maken leidt daarmee automatisch tot gereduceerde transparantie in het algoritmeregister. |
|
Veld maatregelen komen we zsm inderdaad op terug. Verder kan ik me ook voorstellen dat we subsidiariteit, rechtmatigheid en noodzakelijkheid verwerken in het veld proportionaliteit. Ik weet namelijk niet of het per se nodig is om dat allemaal op te splitsen in verschillende velden. Zolang die aspecten maar wel benoemd worden inderdaad. Wat betreft contactpersoon, volgens mij verwijzen de meeste niet naar één persoon, maar naar een algemene inbox. Naar mijn mening zou via dit contactpunt naar elk recht gevraagd kunnen worden. Als dat uiteindelijk niet via dat contactpunt loopt, kunnen zij dat denk ik het beste doorsturen. Zoals je zegt, meerdere loketten werpen alleen drempels op. |
Proportionaliteit is één van de eisen voor de rechtmatigheid, maar rechtmatigheid is geen onderdeel van een proportionaliteitstoets. Iets kan onrechtmatig maar proportioneel zijn. Juist om die verwarring te voorkomen stel ik voor om ze appart te benoemen. Mijn ervaring is dat er te vaak niet gestructureerd over nagedacht wordt en dat het noodzakelijk is om het expliciet te benoemen om te zorgen dat het opvalt als relevante informatie ontbreekt. Edit: kijk voor illustratie van mijn punt maar eens naar het huidige register en tel hoeveel een onderbouwing van subsidiariteit en noodzakelijkheid bevatten.
Ik zou het dan geen contactpersoon noemen, maar bijvoorbeeld 'contactinformatie'. Ik ben het niet eens met de commit, wel met de intentie erachter. |
|
In reactie op je edit, op dit moment staat dat ook nog niet expliciet in de handleiding. Dat wil ik ook explicieter maken, waardoor het bij de volgende aanlevering in register wél meegenomen wordt. Stel dat we er voor kiezen om het niet op te splitsen in verschillende velden, is het dan wellicht beter om het "rechtmatigheid" te noemen? Wat betreft contactpersoon, mee eens dat we dat beter kunnen verwoorden. Dat gaan we meenemen :) Dank voor het kritische meedenken! |
|
Mijn ervaring is dat dat niet gaat werken als je er niet gestructureerd om vraagt zodat het ontbreken van de informatie opvalt. Misschien goed om eerst te specificeren welke informatie nodig is om de rechtmatigheid controleerbaar te onderbouwen en op basis daarvan de standaard in te richten. |
|
Hi! Ik zie een aantal keren voorbijkomen dat het doel van het Algoritmeregister niet duidelijk is. Ik denk echter dat we het over verschillende dingen hebben. Het doel, het expliciet maken van zaken en de verschillende manieren om daar te komen. Doel
Het Algoritmeregister valt onder spoor 3 (Regie op het Digitale Leven) van de Werkagenda Waardengedreven Digitaliseren. Hierbinnen zijn een aantal doelen geformuleerd en bijbehorende activiteiten (instrumenten) die aan deze doelen moeten bijdragen. Werkwijze Met het Algoritmeregister lopen we voorop. We zijn gestart met het transparant maken van Algoritmes. Dit doen we zonder dat al die andere zaken al helemaal uitgekristalliseerd zijn. Waar exact de transparantieverplichtingen en het toezicht op zal komen zal de komende jaren steeds duidelijker moeten worden. Tot die tijd proberen we in een aantal iteraties de metadatastandaard steeds meer af te stemmen op de behoeften. Dit doen we door het uitvoeren van doelgroepenanalyses, het gesprek aan te gaan met de aanleverende partijen en in open sessies input op te halen. We zitten momenteel middenin dit proces. Dank voor het actief meedenken bij deze ontwikkeling! Ook fijn om deze discussie op Pleio te voeren, zodat meer mensen kunnen meelezen. |
|
Deze omschrijving conflicteert met commit d7ddd1b en maakt het bijzonder lastig om te toetsen welke informatie nodig is voor het bevorderen van de controleerbaarheid. |
|
Ik denk dat er momenteel onvoldoende rekening gehouden wordt met al bestaande verplichtingen en de verplichtingen die al wel duidelijk in de AI Act staan. Dat gaat straks dubbel werk opleveren als het register niet voldoende informatie bevat om aan die verplichtingen te kunnen voldoen. Een deel (zeker van de AI Act) kan nog verder uitkristalliseren. Maar Ik heb in een aantal pull requests ook verwezen naar concrete verplichtingen die al helder zijn. Vanuit de behoeftes gesproken: ik heb suggesties gedaan vanuit het perspectief van een burger die het register wil gebruiken om te kunnen controleren op de afwezigheid van onrechtmatige discriminatie en de rechtmatigheid van verwerkingen onder de AVG. Vanuit dat perspectief zie ik cruciale informatie uit het register verdwijnen. Misschien is het goed om te documenteren welke behoeftes tegen elkaar afgewogen worden en waarom andere behoeftes prevaleren op het moment dat de controleerbaarheid beperkt wordt. |
|
Met #19 is het hierboven omschreven conflict verholpen. |
Voor de volgende versie van de metadatastandaard is ons voorstel om de volgende wijzigingen aan te brengen. Deze willen wij op korte termijn delen met overheidsorganisaties, met maatschappelijke partijen en via Pleio of hier. Zij krijgen ruimte om feedback te geven, waarna wij nog aanpassingen aan dit voorstel doen.
Uitgangspunt van deze wijziging is dat het relatief oncontroversieel moet zijn en niet tot een significante verzwaring van de uitvoerbaarheid moet leiden. Voorstellen die daar niet aan voldoen, kunnen in een latere wijziging aangebracht worden, waar meer tijd voor genomen kan worden. Input daarvoor wordt ook op korte termijn gevraagd.
Netto: 4 toevoegingen, 5 verwijderingen, 4 functionele aanpassingen.