Zoeken
← Terug naar Blog

GDPR en geolocatiediensten: onze privacy-first benadering

Hoe GeoPin GDPR-compliance bereikt door dataminimalisatie, in-memory verwerking en een privacy-first architectuur die je geüploade afbeeldingen nooit opslaat.

GDPR en geolocatiediensten: onze privacy-first benadering

Een geolocatiedienst exploiteren in de Europese Unie betekent werken onder de GDPR — de Algemene Verordening Gegevensbescherming die de wereldwijde standaard zet voor dataprivacy. Voor GeoPin is GDPR-compliance geen afvinklijstje dat achteraf op een bestaand systeem wordt geplakt. Het is een ontwerpprincipe dat onze architectuur vanaf het begin heeft gevormd. We verwerken afbeeldingen om locaties te bepalen, en we doen dat zonder de gegevens te bewaren die privacyschendingen in de eerste plaats mogelijk maken.

De privacyuitdaging van beeldverwerking

Afbeeldingen bevatten rijke persoonlijke gegevens. Een straatfoto kan gezichten, kentekens, gebouwadressen of andere informatie bevatten die personen kan identificeren. Onder de GDPR vereist het verwerken van afbeeldingen die persoonsgegevens bevatten een rechtmatige grondslag, en het opslaan van dergelijke gegevens brengt verplichtingen met zich mee rond inzagerecht, rectificatie, verwijdering en gegevensoverdraagbaarheid.

Wij kozen een andere weg. In plaats van de complexiteit te beheren van het verantwoord opslaan van persoonsgegevens, hebben we een systeem ontworpen dat ze helemaal niet opslaat.

Architectuur van dataminimalisatie

Het dataminimalisatieprincipe van de GDPR stelt dat persoonsgegevens “toereikend, ter zake dienend en beperkt moeten zijn tot wat noodzakelijk is voor de doeleinden waarvoor zij worden verwerkt.” Voor GeoPin is het doel geolocatie — bepalen waar een foto is genomen. Dit is wat daarvoor noodzakelijk is en wat niet:

Noodzakelijk: De afbeelding tijdelijk verwerken om een visuele embedding te extraheren (een 512-dimensionale numerieke vector). Die vector vergelijken met onze referentie-index. Coördinaten terugsturen naar de gebruiker.

Niet noodzakelijk: De originele afbeelding opslaan. De geëxtraheerde embedding opslaan. Loggen wat de afbeelding bevatte. Enig verband bewaren tussen de zoekopdracht van een gebruiker en de afbeelding die zij hebben ingediend.

Onze verwerkingspipeline weerspiegelt dit onderscheid:

  1. De gebruiker uploadt een afbeelding naar ons Cloudflare Worker-eindpunt.
  2. De Worker converteert de afbeelding naar base64 en stuurt deze naar onze GPU-backend op RunPod voor embeddingextractie.
  3. De GPU-backend verwerkt de afbeelding in het geheugen, extraheert de CosPlace-embedding en retourneert de vector. De afbeeldingsgegevens worden niet naar schijf of enige persistente opslag op de GPU-instantie geschreven.
  4. De Worker gebruikt de embedding om Cloudflare Vectorize te bevragen voor nearest-neighbour matches.
  5. De topkandidaten ondergaan geometrische verificatie, opnieuw verwerkt in het geheugen.
  6. Het eindresultaat — coördinaten en betrouwbaarheidsscores — wordt teruggestuurd naar de gebruiker.
  7. De geüploade afbeelding, de geëxtraheerde embedding en de tussentijdse kandidaatgegevens bestaan alleen in het werkgeheugen tijdens de verwerking van het verzoek. Zodra het antwoord is verzonden, komen ze in aanmerking voor garbage collection.

Er is geen afbeeldingentabel in onze database. Er is geen R2-bucket voor geüploade foto’s. Er is geen zoekgeschiedenis die vastlegt wat gebruikers hebben gezocht. Deze opslaglagen bestaan niet omdat we ze nooit hebben gebouwd.

Wat we wél opslaan

Transparantie vereist dat we duidelijk aangeven welke gegevens we wél bewaren:

Gebruiksregistraties. We houden API-sleutelidentificaties (of IP-adressen voor proefgebruikers) bij samen met tijdstempels en factureringsperioden voor snelheidsbeperking. Gebruiksregistraties bevatten geen informatie over de inhoud van zoekopdrachten — ze registreren dat er een zoekopdracht is uitgevoerd, niet wat er gezocht is.

API-sleutels en abonnementsgegevens. Betalende gebruikers hebben een API-sleutel met standaard accountinformatie (e-mailadres, plantype, abonnementsstatus).

Referentiebeeldmetadata. Onze index bevat metadata over straatbeelden op referentieniveau: bronplatform, afbeeldings-ID, coördinaten, opnamedatum en kompashoek. Dit zijn geen gebruikersgegevens — het is metadata over openlijk gelicentieerde beelden.

Dat is de volledige lijst. We kunnen niet opzoeken wat een gebruiker heeft gezocht, omdat die informatie nooit wordt vastgelegd.

GDPR-rechten en onze architectuur

De GDPR verleent betrokkenen specifieke rechten. Zo verhoudt onze architectuur zich tot elk recht:

Recht op inzage (Artikel 15). We beschikken uitsluitend over accountinformatie en gebruiksaantallen. We kunnen geen zoekgeschiedenis verstrekken omdat we die niet hebben.

Recht op verwijdering (Artikel 17). We kunnen account- en factureringsgegevens verwijderen. Er zijn geen geüploade afbeeldingen om te verwijderen omdat deze nooit zijn opgeslagen.

Recht op gegevensoverdraagbaarheid (Artikel 20). We kunnen accountinformatie en gebruiksstatistieken exporteren. Er zijn geen afbeeldingsgegevens om te exporteren.

Recht op beperking van verwerking (Artikel 18). Het deactiveren van een API-sleutel voorkomt onmiddellijk elke verdere verwerking.

De referentiegegevensvraag

De referentiebeelden zelf worden niet door GeoPin opgeslagen. We slaan alleen metadata (coördinaten, bron-ID’s) en CosPlace-embeddings op — 512-dimensionale floating-point vectoren die ruimtelijke en architectonische kenmerken coderen, geen biometrische of persoonlijk identificeerbare informatie. De originele afbeeldingen bevinden zich op hun respectieve platforms (Mapillary, KartaView, enz.), die hun eigen privacyprocessen hebben, waaronder het onherkenbaar maken van gezichten en kentekens. Een embedding kan niet worden teruggedraaid om de originele afbeelding te reconstrueren.

Internationale gegevensoverdrachten

Onze infrastructuur draait op het wereldwijde netwerk van Cloudflare met GPU-verwerking op RunPod, beide onder passende gegevensverwerkingsovereenkomsten. Aangezien afbeeldingen tijdens de overdracht worden verwerkt en nooit worden bewaard, wordt de jurisdictionele complexiteit die veel cloudgebaseerde beeldverwerkingsdiensten treft, aanzienlijk verminderd.

Verantwoordelijkheden als verwerker versus verwerkingsverantwoordelijke

Wanneer een bedrijf de API van GeoPin integreert, is het verwerkingsverantwoordelijke-verwerker raamwerk van de GDPR van toepassing. Het integrerende bedrijf is de verwerkingsverantwoordelijke; GeoPin treedt op als verwerker. We bieden een standaard Verwerkersovereenkomst (DPA) aan voor zakelijke klanten die onze werkelijke architectuur weerspiegelt: in-memory verwerking, geen beeldopslag, uitsluitend coördinaten als resultaat.

Waarom privacy-first goed engineering is

Een privacy-first systeem bouwen was geen opoffering — het was een vereenvoudiging. Door geen afbeeldingen op te slaan, hebben we complete categorieën van technische problemen geëlimineerd: beeldopslagkosten, back-upbeheer, toegangscontrole voor gevoelige gegevens, bewaarbeleid, anonimiseringspipelines en verzoeken van betrokkenen met betrekking tot beeldinhoud.

Ons systeem is eenvoudiger, goedkoper en sneller omdat het niet de last draagt van het beheren van een steeds groeiend beeldarchief. De GDPR leidde ons naar een beter ontwerp.

Dataminimalisatie is niet alleen een wettelijke vereiste. Het is een principe dat schonere systemen oplevert. Als je de gegevens niet nodig hebt, verzamel ze dan niet. Als je ze niet verzamelt, kun je ze niet lekken, verliezen of gedwongen worden ze over te dragen. Dat is een privacygarantie die geen beleidsdocument kan evenaren — het wordt afgedwongen door architectuur.