Een productteam bij een Nederlandse bank heeft de woningwaarde-API technisch aangesloten. De eerste testresultaten zien er goed uit, de hypotheekstraat kan sneller worden ingericht en de ontwikkelaars staan klaar voor productie. Dan houdt compliance de livegang tegen: er is nog geen verwerkersovereenkomst ondertekend.
Dat scenario komt vaak voor bij organisaties die AI-woningdata integreren. Niet omdat het contract onbelangrijk is, maar omdat teams de juridische afspraken pas bespreken nadat de architectuur al is gekozen. Bij woningdata gaat het bovendien niet alleen om een adres. Afhankelijk van de toepassing kunnen ook eigenaargegevens, WOZ-waarde, bouwjaar, energielabel en andere kenmerken worden verwerkt. De overeenkomst moet daarom aansluiten op de feitelijke API-keten, niet alleen op een standaardtemplate.
Wat een verwerkersovereenkomst is en waarom je deze nodig hebt
Een verwerkersovereenkomst bepaalt hoe een externe partij persoonsgegevens namens jullie organisatie verwerkt. Artikel 28, lid 3 AVG vereist deze schriftelijke afspraak wanneer een leverancier persoonsgegevens in opdracht verwerkt. De Autoriteit Persoonsgegevens beschrijft deze wettelijke eis voor verwerkersovereenkomsten expliciet.
Bij een AI-woningdata-API geeft een hypotheekverstrekker opdracht om woninggegevens te gebruiken voor onderpandbeoordeling. De leverancier kan die gegevens verrijken, valideren of woningkenmerken berekenen. De overeenkomst koppelt die technische verwerking aan duidelijke grenzen: welke gegevens de API ontvangt, welke instructies gelden en hoe de leverancier de verwerking beveiligt. Gebruik daarbij ook deze uitleg over AVG-compliance bij AI-integraties.
Wanneer de overeenkomst verplicht is
Zodra een externe partij persoonsgegevens namens jullie verwerkt, is een overeenkomst nodig. Dat geldt ook voor een API die de verwerking vrijwel volledig automatisch uitvoert. Automatisering verandert de juridische rolverdeling niet.
Leg minimaal het volgende vast:
- Doel en scope: waarvoor de API persoonsgegevens mag verwerken.
- Gegevenscategorieën: bijvoorbeeld adresgegevens, objectkenmerken en financiële woninginformatie.
- Instructies: welke endpoints, verrijkingen en modeluitkomsten zijn toegestaan.
- Beveiliging: welke technische en organisatorische maatregelen de leverancier toepast.
- Ketenbeheer: welke subverwerkers worden ingezet en hoe wijzigingen worden gemeld.
- Exit: wanneer data wordt verwijderd of teruggegeven.
Een ontbrekende of ondeugdelijke overeenkomst maakt de verwerking niet automatisch rechtmatig. Beide partijen kunnen aansprakelijk zijn wanneer vereisten niet zijn geregeld. De juridische uitleg over verantwoordelijkheden en sanctierisico's helpt om die risico's en contractuele taken scherp te beleggen.
Mijn advies: behandel de verwerkersovereenkomst als een productie-artefact. Zonder contractuele dekking, beschreven datastromen en een datalek-escalatie hoort een AI-woningdata-API niet in een live hypotheek-, verzekerings- of gemeentelijke keten.
De DPA is daarmee meer dan een handtekening aan het einde van het project. Ze vormt de operationele basis voor beheer, audits, subverwerkers en beëindiging. Wie deze onderdelen niet kan aanwijzen, beheerst de dataketen niet.
Verschil tussen verwerkingsverantwoordelijke en verwerker
De verwerkingsverantwoordelijke bepaalt waarom en hoe persoonsgegevens worden verwerkt. De verwerker voert die verwerking uit namens de verantwoordelijke en volgt diens schriftelijke instructies. Dat onderscheid bepaalt of jullie een verwerkersovereenkomst nodig hebben en welke partij welke acties moet uitvoeren.
Een hypotheekverstrekker is doorgaans verwerkingsverantwoordelijke wanneer die woningdata gebruikt voor risicobeoordeling of hypotheekacceptatie. Een gemeente heeft die rol wanneer ze bouwjaar- en energielabeldata analyseert voor verduurzamingsbeleid. Een AI-API-leverancier is verwerker wanneer die uitsluitend volgens de opdracht van de bank of gemeente woningkenmerken verrijkt, valideert of voorspelt.
| Criterium | Verwerkingsverantwoordelijke, bijv. bank of gemeente | Verwerker, bijv. AI-API-leverancier |
|---|---|---|
| Doelbepaling | Bepaalt waarom woningdata wordt verwerkt | Verwerkt data voor het afgesproken doel |
| Zeggenschap over data | Bepaalt welke gegevens en middelen nodig zijn | Handelt binnen gedocumenteerde instructies |
| Aansprakelijkheid bij datalek | Beoordeelt de gevolgen en neemt de regie | Beveiligt de verwerking en informeert de verantwoordelijke |
| Meldplicht | Beoordeelt of een melding aan de AP nodig is | Meldt incidenten volgens de contractuele escalatieafspraak |
| Bewaartermijn | Bepaalt hoe lang gegevens nodig zijn | Bewaart data niet langer dan geïnstrueerd en afgesproken |
Waar de grijze zone begint
De rol verandert wanneer de leverancier zelf beslist waarvoor gegevens worden gebruikt. Denk aan een AI-partij die klantdata inzet voor eigen modelverbetering, nieuwe commerciële analyses of een zelfstandig doel. Dan kan die partij voor dat deel zelfstandig of gedeeltelijk verwerkingsverantwoordelijke worden. Een standaard-DPA die alle activiteiten als opdrachtverwerking bestempelt, lost die rolvraag niet op.
Vraag daarom niet alleen: “Heeft de leverancier een DPA?” Vraag vooral:
- Wie bepaalt het doel van iedere verwerking?
- Wie bepaalt welke brondata en modelinputs nodig zijn?
- Mag de leverancier data voor eigen doeleinden gebruiken?
- Wie bepaalt de bewaartermijn en verwijdering?
- Wie draagt de regie bij een incident?
De vuistregel is eenvoudig: bepalen jullie welke data wordt verwerkt en waarvoor, dan zijn jullie verwerkingsverantwoordelijke. Voert de leverancier alleen jullie opdracht uit, dan ligt de verwerkersrol voor de hand. Bij gezamenlijke doelbepaling is een andere juridische inrichting nodig.
Verplichte clausules volgens artikel 28 AVG
Artikel 28, lid 3 AVG verlangt een concrete beschrijving van de verwerking en duidelijke verantwoordelijkheden. Bij een AI-woningdata-API vertaal je dat naar endpoints, datavelden, modelprocessen, logging en leveranciersketens. Leg vast welke instructies gelden, wie toegang krijgt en welke beveiliging de leverancier toepast. Een contract dat alleen “woningdata” noemt, geeft productteams en auditors onvoldoende houvast.
Welke bepalingen moet je uitwerken
Onderwerp, duur, aard en doel. Beschrijf welke woningdata de API verwerkt, voor welke toepassing en gedurende welke periode. Benoem bijvoorbeeld adresmatching, objectverrijking, waarde-inschatting of verduurzamingsanalyse. Leg ook vast welke endpoints en modelstappen binnen de opdracht vallen.
Instructies en vertrouwelijkheid. De leverancier gebruikt de data uitsluitend volgens gedocumenteerde instructies. Medewerkers met toegang zijn aan geheimhouding gebonden. Leg vast welke interne rollen verzoeken mogen indienen en hoe wijzigingen worden goedgekeurd en geregistreerd.
Beveiligingsmaatregelen. Neem encryptie, toegangscontrole, logging, back-ups en incidentrespons op in een beveiligingsbijlage. Koppel iedere contractuele eis aan een technische controle, zodat architecten kunnen vaststellen hoe de maatregel in de API-omgeving werkt.
Subverwerkers. Leg vast of voorafgaande specifieke of algemene schriftelijke toestemming geldt, hoe wijzigingen worden gemeld en hoe verplichtingen worden doorgegeven. Cloudhosting, monitoring, modelhosting en support kunnen allemaal onderdeel zijn van de verwerkingsketen. De toelichting op subverwerker-wijzigingsmeldingen verduidelijkt het verschil tussen de wettelijke informatieplicht en een afgesproken meldtermijn.
Ondersteuning bij rechten van betrokkenen. Spreek af hoe de leverancier helpt bij inzage, correctie, verwijdering en andere verzoeken. Request-ID's, bronverwijzingen en bewaakte datastromen maken die ondersteuning uitvoerbaar.
Medewerking aan DPIA en voorafgaande raadpleging. Vraag documentatie over datastromen, risico's, modelinputs en beveiliging. Beschrijf ook hoe automatische uitkomsten worden gebruikt, beoordeeld en gecorrigeerd.
Verwijdering of teruggave. Leg vast wat er gebeurt met ruwe inputs, verrijkte data, logs, back-ups en tijdelijke bestanden na beëindiging. Laat de afspraken aansluiten op jullie beleid voor dataretentie, inclusief verwijdering uit kopieën en herstelvoorzieningen.
Auditrechten en inspectie. Leg vast welke informatie beschikbaar is, hoe audits worden aangevraagd en wanneer assurance-rapporten of documentreview volstaan. Auditrechten hebben pas waarde als relevante logs, subverwerkersinformatie en incidentregistratie toegankelijk zijn.
Voor vergelijking met een bestaande privacy-inrichting kan ons privacybeleid van 1808 als praktisch referentiepunt dienen. Beoordeel daarna of de overeenkomst overeenkomt met de feitelijke verwerking van de AI-woningdata-API.
Praktische checklist voor AI-woningdata-integraties
Een goede checklist verbindt elke contractuele afspraak aan een technische controle. Laat product, architectuur, security en privacy hetzelfde intakeformulier gebruiken. Zo voorkom je dat legal een breed geformuleerde DPA goedkeurt terwijl de API-implementatie inmiddels meer data verwerkt dan het contract beschrijft.
Negen controles vóór productie
Beschrijf de use case. Noteer of de API wordt gebruikt voor desktop taxatie, hypotheekacceptatie, portefeuillewaardering, verzekeringsrisico of gemeentelijk beleid. Leg het doel vast in het verwerkingsregister en in de bijlage bij de overeenkomst.
Inventariseer de datavelden. Maak per endpoint zichtbaar welke persoonsgegevens worden verstuurd, welke gegevens terugkomen en welke velden optioneel zijn. Stuur geen eigenaarinformatie mee als een object-ID volstaat.
Bepaal de rollen. Laat privacy en product samen vaststellen wie doel en middelen bepaalt. Documenteer afwijkingen, vooral wanneer de leverancier modelverbetering of aanvullende analyses voorstelt.
Controleer de subverwerkersketen. Vraag naar hosting, monitoring, model-hosting, support en eventuele databronnen. Leg de actuele lijst, wijzigingsprocedure en doorgelegde verplichtingen vast.
Maak beveiliging toetsbaar. Koppel contractuele eisen aan architectuurcontroles. Denk aan versleuteling, least-privilege-toegang, sleutelbeheer, logging, scheiding van omgevingen en periodieke review van serviceaccounts.
Definieer bewaartermijnen. Bepaal hoe lang requestdata, responsegegevens, foutlogs en back-ups nodig zijn. Zorg dat verwijdering aantoonbaar werkt en niet alleen geldt voor de primaire database.
Richt datalek-escalatie in. Leg contactpersonen, meldkanalen, minimale inhoud en interne escalatie vast. Een meldprotocol binnen 24 uur kun je contractueel opnemen als operationele norm, zodat jullie tijd houden voor beoordeling en eventuele melding aan de AP. De termijn en procedure moeten aansluiten op de concrete afspraken in de overeenkomst.
Test betrokkenenverzoeken en audit. Simuleer hoe je een record terugvindt, corrigeert of verwijdert. Controleer ook of auditinformatie, verwerkingslocaties en incidentlogs beschikbaar zijn.
Maak een exit-test. Stop een testomgeving, verwijder de data en vraag bewijs van verwijdering of teruggave. Neem ook tijdelijke bestanden, back-ups en exportbestanden mee.
Acceptatiecriterium: de integratie is pas gereed wanneer elke contractuele verplichting gekoppeld is aan een eigenaar, technische controle en bewijsstuk.
De checklist werkt ook als onderhandelingsdocument. Vraag niet alleen om een handtekening, maar om de beveiligingsbijlage, subverwerkerslijst, verwerkingslocaties, incidentprocedure en exitprocedure. Een leverancier die deze informatie niet kan leveren, creëert een operationeel risico dat geen contractformule wegneemt.
Hoe een hypotheekverstrekker de overeenkomst inricht
Een geanonimiseerde Nederlandse hypotheekverstrekker wilde een AI-woningwaarde-API gebruiken voor de automatische beoordeling van onderpand. Het productteam had de functionele scope bepaald, terwijl de architecten de API-koppeling en monitoring voorbereidden. Compliance stelde één voorwaarde: geen persoonsgegevens naar productie voordat de rollen, keten en escalatie schriftelijk waren vastgelegd.
Van contracttekst naar controle
De instelling begon met een gegevensstroomdiagram. Daarin stonden de aanvraagapplicatie, de API, opslag voor tijdelijke responses, logging en de betrokken leveranciers. De juridische bijlage beschreef vervolgens het doel, de categorieën persoonsgegevens, de instructies en de bewaartermijnen. De technische bijlage vertaalde beveiliging naar concrete toegangs- en loggingmaatregelen.
De subverwerkersketen kreeg extra aandacht. Hosting, model-hosting en ondersteunende diensten werden afzonderlijk geregistreerd. Voor wijzigingen werd een voorafgaande meldprocedure afgesproken, met een duidelijk escalatiepad wanneer de bank bezwaar had tegen een nieuwe partij.
Auditrechten werden praktisch ingericht. De bank vroeg niet om onbeperkte toegang tot alle systemen, maar om controleerbare informatie: relevante assurance-documentatie, beveiligingsbeleid, subverwerkersgegevens, incidentrapportages en gerichte auditmogelijkheden. Daarmee bleef de controle uitvoerbaar zonder de leverancier een onbegrensde auditlast op te leggen.
Hoe de instelling snelheid beheerst
Het team maakte contractondertekening een go-live-criterium, niet een taak voor na de lancering. De sandbox gebruikte gescheiden testdata en beperkte toegang. Pas na goedkeuring van de verwerking, beveiliging, incidentmelding en exitprocedure kreeg de productieomgeving toestemming.
Aansprakelijkheid en financiële gevolgen werden niet als losse juridische bijlage behandeld. De partijen koppelden aansprakelijkheidsverdeling aan de feitelijke controle over instructies, beveiliging en subverwerkers. Ook werden contractuele gevolgen bij niet-naleving besproken, zodat een incident niet pas tijdens een crisis tot interpretatieverschillen zou leiden.
De belangrijkste les is praktisch: de doorlooptijd van een hypotheekaanvraag mag niet bepalen wanneer privacycontroles starten. Begin met de datastroom, leg daarna de contractuele verantwoordelijkheden vast en bouw de technische integratie pas af wanneer beide sporen op elkaar aansluiten.
Volgende stappen voor je compliance en API-integratie
De kern van een verwerkersovereenkomst voor AI-woningdata zit in drie punten:
- Subverwerkers: ken de volledige keten en leg wijzigingen vooraf vast.
- Auditrechten: maak controleerbare informatie en inspectie praktisch uitvoerbaar.
- Datalek-escalatie: definieer contactpersonen, inhoud, kanalen en interne reactietermijnen.
Plan daarna drie concrete acties. Controleer eerst in de API-documentatie van Altum AI welke endpoints persoonsgegevens verwerken en welke gegevens jullie werkelijk versturen. Vraag vervolgens toegang tot een sandbox om logging, foutafhandeling, dataminimalisatie en verwijdering technisch te valideren. Plan tot slot een compliance-scan met jullie privacyteam en leg afwijkingen vast als openstaande acceptatiecriteria.
Voor een maatwerkverwerkersovereenkomst moet je de juridische tekst laten aansluiten op de gekozen API, de interne verwerkingsregisters en de feitelijke subverwerkersketen. Dat voorkomt dat een ondertekend document een te algemene beschrijving bevat van een veel specifiekere woningdata-integratie.
Auteursprofiel: Altum AI adviseert productteams, IT-architecten en complianceprofessionals over herleidbare woningdata, woningwaardemodellen, energie-inzichten en API-integraties binnen de Nederlandse woningmarkt.
Laatst bijgewerkt: 23 augustus 2026.
Veelgestelde vragen
Wanneer heb je een verwerkersovereenkomst nodig?
Je hebt een verwerkersovereenkomst nodig wanneer een externe partij persoonsgegevens namens jullie verwerkt. Bepalend is niet of de verwerking via een API of handmatig gebeurt, maar wie het doel en de middelen bepaalt.
Is een standaard-DPA voldoende?
Niet automatisch. Controleer of de tekst onderwerp, duur, doel, instructies, beveiliging, subverwerkers, ondersteuning, verwijdering en auditrechten concreet regelt. Een generieke verwijzing naar passende maatregelen is voor een AI-integratie vaak onvoldoende.
Wie meldt een datalek?
De verwerker moet het incident volgens de contractuele afspraak snel melden aan de verwerkingsverantwoordelijke. De verantwoordelijke beoordeelt vervolgens de gevolgen en bepaalt welke externe melding nodig is.
Mag een leverancier woningdata gebruiken voor modelverbetering?
Alleen wanneer dat doel juridisch en contractueel is toegestaan. Als de leverancier zelf het doel van die verwerking bepaalt, kan de rol verschuiven van verwerker naar zelfstandig of gezamenlijk verwerkingsverantwoordelijke.
Altum AI biedt API's voor woningwaarde, WOZ- en PC6-waarde, Kadastertransacties, energielabels en verduurzamingsanalyses, zodat jullie de datastromen vooraf concreet kunnen toetsen. Bezoek Altum AI om de documentatie, sandbox en mogelijkheden voor een maatwerkverwerkersovereenkomst te bekijken.