Juridische vragen bij R4M — batch 1

Valt onze attestatie ("achter deze actie zit één uniek, geverifieerd mens") onder eIDAS 2.0 als elektronische attestering van attributen (Verordening 2024/1183), en welk Belgisch regime geldt dan voor de aanbieder?

Waarom wij dit vragen. Dit is de kwalificatie van de kerndienst zelf. Ja betekent registratie- en toezichtseisen voor de BV en een demodatum op 1 oktober. Nee maakt de rest van deze lijst het volledige kader.

Ons eigen standpunt. Geen eigen standpunt. Het dossier noemt eIDAS 2.0 vermoedelijk het echte rechtskader, niet het betaalrecht.

Mag de vennootschap zonder vergund statuut factureren voor eigen attestaties en licenties (per factuur, later Stripe naar eigen rekening), zolang geen euro naar een derde doorstroomt, en zijn die fees op zich vergunningsplichtig?

Waarom wij dit vragen. Scharnier 1. Zonder dit geen factuur aan de eerste klant. Bewust in de laag-1-vorm gesteld: de tweezijdige Stripe-Connect-opzet (uitbetalen aan derden) is batch 2.

Ons eigen standpunt. Betalingen ontvangen voor je eigen dienst via een vergunde PSP (Stripe) is géén betaaldienst — starten met betalende bedrijven kan zonder vergunning. Kantelvoorwaarde: nooit één euro doorbetalen aan een derde. Bron: PSD2 Annex I + art. 4(22)/(44). Voor Nele: s Eigen stelling V41: fee = verkoop van een dienst, geen betaaldienst; prepaid credits is een restvraag e-geld (V11).

Is R4M een onderworpen entiteit onder de wet van 18-09-2017 (art. 5), ja of nee, vanaf welk moment, en wat is het restcategorie-risico? Beoordeeld op de werkelijke sleuteltoestand: vandaag alle sleutels in één .env op Fly.

Waarom wij dit vragen. Scharnier 2. Bepaalt of de BV een AML-organisatie nodig heeft en wat compliance bij steden en banken te horen krijgt. Leg de werkelijke toestand voor, niet de geplande.

Ons eigen standpunt. Attestaties verkopen staat niet in de limitatieve lijst (wet 18/9/2017 art. 5); ook onder de EU-AML-verordening (2027) niet. R4M is dus vermoedelijk géén onderworpen entiteit. Valt dit goed, dan vallen V13, V14 en heel G1/G3 automatisch mee. Voor Nele: schriftelijk bevestigen + restcategorie-risico.

BIJGEWERKT 12-09-2026 na de beslissing van Franky. De vorm en de naam liggen vast: een Belgische BV met de naam R4M, op te richten voor de eerste klant. Het i-DEPOT 161564 en de NDA stonden al op naam R4M, dus die hoeven niet over. Wat blijft er van deze vraag over: (1) wat mag Turbeau2Rock CommV intussen nog doen (verkoopgesprekken, pilot op testdata)? (2) hoe gaan het itsme/Signicat-contract en de privacyverklaring over naar de BV, en wat gebeurt er met de aansprakelijkheid voor de periode ervoor? (3) volstaat het i-DEPOT als bescherming van de naam R4M, of is een Benelux-merkinschrijving nodig voor de eerste echte klant?

Waarom wij dit vragen. De eerste twee delen van deze vraag zijn op 12-09-2026 door Franky zelf beslist en hoeven niet meer gesteld te worden. Wat overblijft is het overzetten van het enige contract dat er al is (itsme/Signicat) plus de privacyverklaring, en de vraag of een i-DEPOT volstaat. Een i-DEPOT is een bewijs van bestaan op datum, geen merkrecht: het houdt niemand tegen die dezelfde naam wil gebruiken.

Ons eigen standpunt. In de CommV ben je privé onbeperkt aansprakelijk; het klassieke omslagpunt naar een BV is precies "vóór er materieel risico ontstaat". Voor Nele: moet de BV er staan vóór de marktintroductie van de mail-app (PLD bepaalt de aansprakelijke fabrikant bij in-de-handel-brengen)?

Ben ik verwerker (art. 28 AVG) of eigen verwerkingsverantwoordelijke als ik een klant alleen een gepseudonimiseerde code teruggeef? Schriftelijk standpunt.

Waarom wij dit vragen. Bepaalt het contractpakket van elke eerste klant: verwerkersovereenkomst, auditrecht, meldplicht, subverwerkers, DPIA-rol, wie tekent. Het dossier spreekt zichzelf tegen; dit herhaalt zich bij elke klant.

Ons eigen standpunt. Eigen standpunt neemt "verwerker" aan; de privacyverklaring presenteert R4M als verantwoordelijke. Vandaar de vraag.

Welke rechtsgrond per verwerking (verificatie, hash-opslag, attestatie aan afnemer, heropening onder bevel)? Kan de pseudonieme attestatie op gerechtvaardigd belang of contract, of is uitdrukkelijke toestemming nodig? In de rol die uit V61 volgt.

Waarom wij dit vragen. Bouwkeuze die je na de lancering niet omgooit: toestemming betekent een extra scherm en intrekbaarheid per afnemer. Input voor de DPIA en de productie-privacyverklaring. Samen met V61 gesteld zodat rol en grondslag in één antwoord komen.

Ons eigen standpunt. Grondslag per verwerking: verificatie = contract of gerechtvaardigd belang; hash-opslag = gerechtvaardigd belang; attestaties aan derden = vermoedelijk uitdrukkelijke toestemming; heropening onder bevel = wettelijke plicht. Voor Nele: kan de pseudonieme attestatie op gerechtvaardigd belang i.p.v. to

Bevestig dat "gepseudonimiseerd persoonsgegeven, technisch en organisatorisch afgeschermd" de juiste publieke wording is, en dat "geen PII in de payload" en "pseudoniem/verzegeld" niet mogen suggereren dat het anoniem is.

Waarom wij dit vragen. Publieke claims worden contractuele garanties bij echte klanten. Nele hoeft alleen de zin af te tekenen; de claim-audit op de site doet Franky zelf.

Ons eigen standpunt. Een salted hash blijft een persoonsgegeven (EDPB 01/2025); "pseudoniem, verzegeld…" mag geen anonimiteit suggereren. Correcter: "gepseudonimiseerd persoonsgegeven, technisch en organisatorisch afgeschermd" . → claim-audit-beslissing voor Franky.

Welk plafond (jaarcontractwaarde, uitsluiting gevolgschade) houdt naar Belgisch recht stand in een B2B-contract als mijn attestatie fout is bij een klant met veel gebruikers, en hoe verhoudt dat zich tot de rechtsvorm?

Waarom wij dit vragen. Het bezwaar dat elke inkoopafdeling stelt. Dit is de tekst voor de eerste algemene voorwaarden en de pilotovereenkomst. Zonder afdwingbaar plafond teken je met privévermogen.

Ons eigen standpunt. Geen eigen standpunt.

DPIA is verplicht (Belgische GBA-lijst). Is daarbovenop een voorafgaande raadpleging van de GBA (art. 36 AVG) nodig, en in welke rol (hangt af van V61)?

Waarom wij dit vragen. Een voorafgaande raadpleging heeft een adviestermijn van 8 weken, verlengbaar met 6. Speelt dat, dan zijn echte registraties op 1 oktober uitgesloten. Daarom nu vragen, niet na de DPIA.

Ons eigen standpunt. DPIA verplicht (staat op de Belgische GBA-lijst). Zelf al in te plannen. Voor Nele: ook voorafgaande raadpleging (art. 36)?

Welk nummer mogen wij afleiden voor "één mens, één keer": volstaat de itsme-sub, en is een hash van het rijksregisternummer verboden? Ja of nee op het voorbereide standpunt.

Waarom wij dit vragen. Bepaalt het uniciteitsontwerp en de sleutelmigratie die vóór de eerste echte gebruiker moet gebeuren. Verkeerd nummer nu is een tweede migratie later, mét klanten. Of de sub pairwise per dienst is, vraagt Franky zelf aan Signicat.

Ons eigen standpunt. Rijksregisternummer: verboden zonder machtiging — ook een hásh ervan. De itsme-sub is de veilige route. Voor Nele: is de sub per dienst verschillend (pairwise), en is hash-van-RRN ooit formeel beoordeeld?

Volstaat AWS KMS in een EU-regio juridisch voor de afleidingssleutel gezien de CLOUD Act, of moet het een EU-provider zijn? En wordt die provider dan een (sub)verwerker met verwerkersovereenkomst?

Waarom wij dit vragen. Vandaag is er geen KMS: de salt is een gewone omgevingsvariabele. Na het antwoord volgt minimaal vier tot zes weken bouwen en migreren vóór de eerste echte registratie. Elke dag zonder antwoord schuift die datum op.

Ons eigen standpunt. Geen eigen standpunt. De provider-onafhankelijke identity-adapter kan intussen zonder Nele gebouwd worden.

Wil ARTES één sleuteldeel (2-van-3) van de bewijssleutel houden, is dat verenigbaar met haar rol als raadsman, en bij welk soort bevel geeft zij vrij? Zo nee, wie beveelt zij aan?

Waarom wij dit vragen. Alleen Nele kan dit beantwoorden, het gaat over haar eigen kantoor. Tweede helft van dezelfde poort als V58/V59. Blokkeert laag 1 niet.

Ons eigen standpunt. Geen eigen standpunt. De site beloofde "2-van-3 gebouwd" terwijl er geen KMS is: die zin gaat weg vóór verzending.

De poort schrijft per aanvraag één regel weg (soort, user-agent, pad, tijdstip — geen IP, geen naam): voor één kleine site ~9.500 regels per 30 dagen, voor een uitgever met een miljoen pageviews ongeveer een miljoen per maand. Daarnaast staan er twee kleine, blijvende sporen: de verzegelde bewijsketen (attestaties en gate_log met hash-keten) en de financiële stukken. Ons voorstel is gelaagd bewaren: ruwe poortregels 30 tot 90 dagen en daarna alleen dagtotalen per soort; de bewijsketen lang; de boekhouding 7 jaar (of 10 als de witwaswet van toepassing blijkt, zie V12). Klopt die indeling? Bestaat er voor de bezoekregels van een website-poort enige wettelijke bewaarplicht die wij over het hoofd zien (dataretentie, bewijs bij misbruik, gerechtelijk onderzoek), en zo ja welke termijn? En volstaat het voor een onderzoek dat wij de verzegelde keten bewaren in plaats van de ruwe logs?

Waarom wij dit vragen. Twee problemen in één antwoord. Juridisch: langer bewaren dan nodig is zelf een inbreuk, korter dan verplicht ook. Praktisch: de motor draait op één machine met een schijf van 1 GB; drie grote klanten vullen die in twee maanden. Zonder deze termijn kunnen we de opruiming niet bouwen en kunnen we een grote klant niet aannemen.

Ons eigen standpunt. Eigen stelling: voor de ruwe poortregels bestaat geen bewaarplicht; 30–90 dagen daarna verdichten is verdedigbaar onder dataminimalisatie. De bewijsketen is klein genoeg om lang te bewaren en is wat een onderzoeker werkelijk nodig heeft. Niet getoetst.

Elke verificatie verzegelt het door de provider getekende ID-token in de bewijskluis (aparte sleutel, alleen open bij audit of gerechtelijk bevel). Vraagt R4M de leeftijdsclaims, dan zit de geboortedatum in dat verzegelde token. Maakt dat R4M alsnog verwerker/verantwoordelijke van de geboortedatum (bewaartermijn, DPIA, inzagerecht), en verandert dat het antwoord op V89 en V90? Moeten de leeftijdsclaims vóór het verzegelen uit het token, of volstaat "verzegeld, niet operationeel"?

Waarom wij dit vragen. Dit is de eerlijkheidsnoot uit de opdracht van 15-09: "datum weggooien" geldt operationeel, niet voor het zegel. Zo staat het ook in ARCHITECTURE.md van de motor.

Ons eigen standpunt. Verzegeld bewijs is verwerking (opslag) met een ander doel en toegangsregime; dezelfde vraag speelt al voor het hele ID-token (V60/V12). Niet getoetst.

Is de cookie r4m_kaartje (10 minuten, alleen om niet per pagina opnieuw te controleren) "strikt noodzakelijk" zodat geen toestemming nodig is, en is de vingerafdruk hash(IP + user-agent + dag) op gerechtvaardigd belang (botafweer) te verantwoorden? Wat moet de privacyverklaring van www.turbeau2rock.com vanaf nu zeggen?

Waarom wij dit vragen. Weblock staat op een echte site met echte bezoekers. De motor bewaart geen IP en geen naam, maar de hash en de cookie zijn er wel. Dit blokkeert de lancering van Weblock als product.

Ons eigen standpunt. Eigen stelling: functioneel en gerechtvaardigd belang, geen banner nodig; de privacyverklaring krijgt een alinea. Niet getoetst.

R4M leest bij verificatie de ja/nee-drempelclaims van itsme en — alleen als een bron die niet levert — kortstondig in geheugen een geboortedatum, en bewaart uitsluitend drie booleans over_13/over_16/over_18 (of "onbekend"). Is dat een verwerking van de geboortedatum in de zin van de AVG, welke grondslag past (gerechtvaardigd belang van de afnemer onder DSA art. 28, uitvoering overeenkomst, wettelijke plicht van het platform), en houdt het dataminimalisatie-argument "booleans in plaats van een datum" stand?

Waarom wij dit vragen. Dit draait live. De vlaggen zitten in motor v0.46.0 (16-09) en de motor staat op v0.50.0, waar v0.46.0 in zit — nagemeten op 20-09-2026 op r4m-franky.fly.dev. Graag uw oordeel of er iets uit moet tot uw antwoord er is. Zonder grondslag geen leeftijdsproduct.

Ons eigen standpunt. Drie booleans zijn persoonsgegevens (gekoppeld aan de gezouten code) maar minimaal; de datum verlaat het geheugen niet. Grondslag: gerechtvaardigd belang van de afnemer + noodzaak voor de dienst. Niet getoetst.

Telt een R4M-attest ("16+ = ja", geworteld in itsme/eID, met uniciteit erbij) als toegelaten leeftijdsverificatie voor een platform onder DSA art. 28 en de richtsnoeren van juli 2025, of alleen de EU-leeftijdsverificatie-app / een EUDI-wallet-attest? Welke erkenning, certificering of registratie (eIDAS 2.0, nationale toezichthouder) zou R4M nodig hebben?

Waarom wij dit vragen. Bepaalt of R4M dit als product mag verkopen aan platforms, of alleen als aanvulling op de EU-app.

Ons eigen standpunt. Waarschijnlijk aanvulling: de richtsnoeren noemen de EU-app als referentie maar sluiten andere accurate, betrouwbare, niet-intrusieve methoden niet uit. Niet getoetst.

Mag R4M een attest van de EU-leeftijdsverificatie-app (bewust onlinkbaar) als input accepteren en er zijn eigen uniciteitsattest (pairwise persoonscode) naast zetten, zonder de onlinkbaarheid die de EU beoogt juridisch te breken? Onder welke voorwaarden: aparte flows, geen opslag van het EU-attest, alleen de drie booleans?

Waarom wij dit vragen. De stekker AgeAttestationProvider is gereserveerd in de motor (stub); vóór er een echte bron aan hangt moet dit beantwoord zijn.

Ons eigen standpunt. De koppeling gebeurt bij R4M, niet bij het platform; het platform ziet alleen de pairwise code en de vlaggen. Onlinkbaarheid richting platform blijft, richting R4M ontstaat een koppeling. Niet getoetst.

Voorstel (16-09, Franky): een afnemer kiest élke minimumleeftijd (13, 15, 17, 21 …) en de motor rekent bij elke pas-stap opnieuw — de itsme ja/nee-drempel als die volstaat, anders de geboortedatum één keer in geheugen, meteen weg; bewaard wordt alleen ja (attest ageNplus). Is dat kortstondig lezen van een geboortedatum — nu niet als terugvalweg (V89) maar als gewone weg voor elke niet-drempelleeftijd, bij elke opstart van een app, ook van minderjarigen — een verwerking die een grondslag, een DPIA of een vermelding in de privacyverklaring vraagt? En mag de motor de persoon zelf tonen "over 107 dagen kan je binnen" (alleen op zijn eigen scherm, nooit aan de afnemer)? Welke scope vragen we itsme dan: alleen age-verification (drempels) of ook birthdate?

Waarom wij dit vragen. Dit draait live sinds 16-09, in motor v0.47.0; de motor staat op v0.50.0 — nagemeten op 20-09-2026. Franky wil dit wereldwijd verkopen: elke bron die een geboortedatum levert (EUDI, mDL) werkt zo zonder eigen drempeltabel; Aadhaar alleen mits toelating, want privaat gebruik is daar beperkt tot toegelaten partijen. Graag uw oordeel of dit zo mag blijven draaien tot uw antwoord er is.

Ons eigen standpunt. Eigen stelling: vluchtige verwerking in geheugen zonder opslag is wél verwerking (AVG art. 4.2), maar met dataminimalisatie als kern: alleen ja/nee overleeft, de afnemer ziet nooit datum of dagen. Het aantal dagen aan de persoon zelf is teruggeven aan de betrokkene, geen doorgifte. Niet getoetst.

Om niet bij elke opstart een itsme-ronde te moeten doen, bewaart de motor per mens (gezouten code, niet pairwise) alleen "minstens N jaar, bewezen op datum D" (voor de N die een klant vroeg) en, voor wie te jong bleek, versleuteld "voor N opnieuw vanaf datum X", gewist zodra X voorbij is. Die datum X is de N-de verjaardag van een minderjarige in vermomming. Mag dat bewaard worden (grondslag, bewaartermijn, DPIA), ook al is het versleuteld en alleen voor de motor leesbaar? En de pas-cookie (één jaar, HttpOnly) die de browser aan die code koppelt: is dat een identificerende cookie waarvoor toestemming nodig is, of strikt noodzakelijk voor de dienst die de mens zelf vroeg?

Waarom wij dit vragen. Dit draait live sinds 17-09, in motor v0.48.0; de motor staat op v0.50.0 — nagemeten op 20-09-2026. Zonder dit geheugen kost elke opstart een itsme-scan en is het product onbetaalbaar voor een populaire app (verdienmodel blok 7). Graag uw oordeel of dit zo mag blijven draaien tot uw antwoord er is.

Ons eigen standpunt. Eigen stelling: "minstens N" is een afgeleide boolean zoals de vlaggen in V89 (dataminimalisatie). "Vanaf X" is gevoeliger: één datum van een minderjarige, versleuteld, met een bewaartermijn die zichzelf opheft; grondslag = de dienst die de mens zelf vroeg (uitvoering overeenkomst) plus gerechtvaardigd belang van de afnemer onder DSA art. 28. De cookie is strikt noodzakelijk (zelfde redenering als V81 voor r4m_kaartje). Niet getoetst.

Om een kind onder de grens binnen te laten met toestemming van een volwassene, vraagt de pas-stap van het kind ook zijn adres, bewaart de motor 15 minuten alleen een gezouten hash van {straat, postcode, gemeente, land}, en vergelijkt die met de hash van het adres van de volwassene (18+, verse itsme). Bewaard blijft alleen "toestemming gegeven op D" op de code van het kind — geen adres, geen ouder-code, geen verwantschap. Is het adres van een minderjarige, ook als hash en ook 15 minuten, een verwerking die een grondslag of DPIA vraagt? Volstaat "een volwassene van hetzelfde huishouden" als ouderlijke toestemming in de zin van DSA art. 28 / de KIDS Act, of moet het aantoonbaar de ouder of voogd zijn? En mogen we dit verkopen als "ouderlijke toestemming" als het strikt "toestemming van een volwassene van het huishouden" is?

Waarom wij dit vragen. Dit draait live sinds 17-09, in motor v0.49.0; de motor staat op v0.50.0 — nagemeten op 20-09-2026. Dit is de eerste van de drie compliance-cases die Franky op 17-09 koos; het lost een verplichting op waar platformen vandaag een gezinsdossier voor aanleggen. Dit raakt minderjarigen, dus graag met voorrang uw oordeel of dit zo mag blijven draaien tot uw antwoord er is.

Ons eigen standpunt. Eigen stelling: ja, verwerking (art. 4.2 AVG), met dataminimalisatie als kern (hash, 15 min, alleen ja/nee overleeft); grondslag = de dienst die kind en volwassene zelf vragen plus het gerechtvaardigd belang van het platform onder art. 28 DSA. "Zelfde huishouden, 18+" is een sterk maar geen sluitend bewijs van ouderlijk gezag — daarom verkopen we het als "een volwassene van het huishouden stemde toe". Niet getoetst.

Bevestig dat "de klant betaalt zijn mensen zelf uit zijn eigen systeem en meldt het kenmerk terug, R4M verzegelt alleen" (weg 2) geen betaaldienst en geen bewaring van klantgeld is, en dat "pot bij de motor, motor betaalt uit" (weg 1) dat wel is. Mag weg 2 het model van laag 1 zijn, ook met een factuur per verzegeling?

Waarom wij dit vragen. Dit beslist welke van de twee gebouwde wegen we aan de eerste klant tonen — een actie of wedstrijd die buiten een vergund spelersaccount draait. Weg 2 vraagt geen wallet van de klant en geen geld bij R4M.

Ons eigen standpunt. Eigen stelling: weg 2 is laag 1, weg 1 is laag 2. Niet getoetst.

De motor draait bij Fly.io in Parijs (EU-grond, Amerikaans bedrijf). De poort vóór een klantsite draait bij Cloudflare (idem). In de keten zitten verder Signicat en itsme, en straks Stripe. Volstaat 'EU-servers bij een Amerikaanse leverancier' voor onze soort gegevens (pseudonieme codes, verzegelde identiteitsbewijzen, bezoekregels), of is een Europese leverancier nodig voor bepaalde categorieën — zeker bij een overheid of een aanbesteding? Welke overdrachtsmechanismen en welke beoordeling moeten wij documenteren, en hoe ziet de lijst van subverwerkers eruit die wij aan elke klant moeten geven? Dit vult V61 aan: niet wie verantwoordelijk is, maar wie er onderaan de keten bij kan.

Waarom wij dit vragen. De eerste grote klant of aanbesteding stelt deze vraag vóór hij tekent, en het antwoord bepaalt of wij van hostingpartij moeten veranderen — een keuze die achteraf duur is. Het raakt ook de verwerkersovereenkomst die bij elke deal hoort.

Ons eigen standpunt. Eigen stelling: EU-regio volstaat voor wat wij bewaren, omdat er geen namen in staan en de identiteitsbewijzen versleuteld en verzegeld zijn. Niet getoetst; de vraag wie bij de sleutels kan, loopt via V58+V59.

Was de dashboard-inbreuk van 04-08-2026 (naam, adres, e-mail van twee NDA-tegenpartijen, kort publiek) meldingsplichtig (art. 33/34 AVG), hoe melden we alsnog na de verstreken termijn van 07-08, en wat moet minimaal in het inbreukenregister?

Waarom wij dit vragen. Dringender dan de rest. Elke inkoopvragenlijst en elke verwerkersovereenkomst vraagt naar incidenten. De inbreuk valt op naam van de CommV en moet benoemd zijn vóór de BV overneemt. Eerste agendapunt.

Ons eigen standpunt. Geen record in het dossier (alleen in "gaten"). Franky legt het inbreukenregister zelf aan, wacht niet op advies.

Neemt ARTES dit dossier zelf, of komt er co-counsel voor het financieel-regulatoire luik (G1–G5)? Wie factureert en blijft ARTES eindverantwoordelijk? Voorstel: batch 1 zonder confrater, co-counsel pas voor batch 2.

Waarom wij dit vragen. Procedurele vraag voor de begeleidende mail. Bepaalt kosten, doorlooptijd en wie V57+V41 en V12 tekent. Voor laag 1 is het financiële luik klein.

Ons eigen standpunt. Co-counsel onder regie van het eigen kantoor is standaardpraktijk. Voor Nele: wie factureert, en blijft ARTES eindverantwoordelijk?

Sinds v0.50.0 nodigt elk 402-antwoord van de poort de AI-agent uit om in één woord te zeggen waarom hij niet betaalt (te duur, geen wallet, geen mandaat, beleid …), met optioneel een bedrag dat hij wél zou betalen en een vrije tekst van maximaal 200 tekens. Het is vrijwillig, geeft geen toegang, vraagt geen sleutel, en bewaart alleen wat de agent zelf meestuurt — geen IP. De site-eigenaar ziet de tekst, publiek tonen we alleen aantallen per reden. Is dit een verwerking van persoonsgegevens wanneer de agent-operator een natuurlijke persoon kan zijn, en zo ja op welke grondslag? Moeten wij die vrije tekst modereren of bewaren met een termijn? En mag een site-eigenaar deze cijfers publiek tonen?

Waarom wij dit vragen. Het staat live en is uniek in de markt: niemand vraagt vandaag aan een agent waarom hij afhaakt. Het is ook de eerste plek waar iemand van buiten vrije tekst in onze database kan zetten. Klein risico, maar het hoort beoordeeld te zijn voor wij het als verkoopargument gebruiken.

Ons eigen standpunt. Eigen stelling: geen persoonsgegeven — het is een machine die iets over zichzelf meldt, zonder IP en zonder identificator, en de vrije tekst blijft bij de site-eigenaar. Zelfde bewaartermijn als de poortregels (zie V96). Niet getoetst.

Sinds 22-09 toetsen wij één richting: een naamloos register waarin fase-1-onderzoekscentra (SGS Edegem, CHDR Leiden, universitaire ziekenhuizen) vragen "mag deze mens vandaag in een studie?" en alleen ja/nee terugkrijgen — geen naam, geen dossier, alleen een pseudonieme code per mens plus de datum van de laatste deelname. Is "deze mens nam op datum X deel aan een klinische studie" een gegeven over gezondheid in de zin van art. 9 AVG, ook als wij niet weten welke studie, welk middel of welke uitkomst? Zo ja: welke uitzondering van art. 9 lid 2 draagt dit (h, i of j — onderzoek — of uitdrukkelijke toestemming onder a), wie is dan verwerkingsverantwoordelijke (elk centrum, de kring van centra, of wij), en volstaat een centrum-onafhankelijke pseudonieme code als passende waarborg (art. 89)? Zo nee: is het een gewoon persoonsgegeven onder art. 6 en gelden de antwoorden op V20 en V61 onverkort?

Waarom wij dit vragen. Dit is de enige richting die itsme alleen niet kan (Brugge-verdict 22-09): één mens tellen óver organisaties heen die elkaars namen niet mogen delen. Valt het onder art. 9 zonder bruikbare uitzondering, dan sterft de richting vóór de eerste mail aan SGS; valt het eronder mét uitzondering, dan is dat juist de rechtsgrond waarmee wij bij elk centrum binnenkomen. In de VS bestaat TOPS (124.806 proefpersonen), in Nederland het VRB met naamfragmenten en documentnummers; ons ontwerp bewaart minder dan beide. Nog geen centrum aangeschreven; deze vraag gaat vóór die mail.

Ons eigen standpunt. Eigen inschatting, niet getoetst: "nam deel aan een klinische studie" zegt dat iemand proefpersoon was, niet wat hem scheelt — maar deelname aan een geneesmiddelenstudie impliceert vaak een gezondheidstoestand (inclusiecriteria), dus wij rekenen voorzichtig mét art. 9. Voorkeur: art. 9 lid 2 j (wetenschappelijk onderzoek) met pseudonimisering als waarborg uit art. 89; elk centrum verwerkingsverantwoordelijke, R4M verwerker. Wij bewaren nooit de studie, het middel of de uitkomst — alleen "deelnemer, tot datum".