Als verzekeringmakelaar staat u voor uw cliënt. U bent geen agent van één verzekeraar — u werkt in het belang van de persoon tegenover u. Dat maakt uw positie bijzonder, en uw dataverwerkingsrisico ook. U beschikt over een combinatie van informatie die bij weinig andere beroepen zo samen voorkomt: een financieel profiel, schadehistorie, en — bij leven- en inkomensverzekeringen — gezondheidsinformatie.
Die laatste categorie heeft een eigen juridische status. Het is artikel 9 GDPR: bijzondere persoonsgegevens in de strengste zin. En het is precies die data die onbedoeld buiten uw kantoor belandt zodra u een cloud AI-platform inzet — vaak zonder geldige grondslag, en vaak zonder dat u het door hebt.
De data die u elke dag verwerkt
Uw cliëntdossier is rijker dan het op het eerste gezicht lijkt. Naam, adres, financieel profiel — dat is de laag die iedereen ziet. Maar bij leven- en inkomensverzekeringen gaat het dieper: de medische voorgeschiedenis, aandoeningen, medicatiegebruik, soms ook de invaliditeits- of arbeidsongeschiktheidsstatus. Al die informatie valt onder artikel 9 van de GDPR — de categorie bijzondere persoonsgegevens voor wie de strengste verplichtingen gelden.
De verwerking van artikel 9-data is in principe verboden. Uitzonderingen bestaan, maar ze zijn specifiek omschreven. Voor makelaars is de meest gebruikte grondslag de expliciete toestemming van de cliënt: artikel 9, lid 2, sub a. Maar die toestemming is niet ruim. Ze geldt voor de verwerkingsactiviteit die op het aanvraagformulier beschreven staat — doorgaans het indienen van een offerte bij een verzekeraar. Ze dekt niet het laden van diezelfde antwoorden in een extern AI-analyseplatform. Dat gebruik vereist een aparte grondslag en een aparte transparantieplicht.
Het argument dat de verzekeraar verantwoordelijk is, gaat niet op. U bent de verwerkingsverantwoordelijke voor de gezondheidsvragen die u aan uw cliënt stelt. De verzekeraar is een afzonderlijke verwerkingsverantwoordelijke voor wat hij daarna met die data doet. Die twee verwerkingsactiviteiten zijn juridisch gescheiden — uw verantwoordelijkheid eindigt niet bij overdracht.
Wat er misgaat bij cloud AI
Stel: u gebruikt een cloud AI-platform voor cliëntadvisering en risicoanalyse. De interface is vlot, de resultaten zijn bruikbaar, en de aanbieder heeft een GDPR-vermelding op zijn website. Maar wat gebeurt er feitelijk?
Een cliënt vult een medische vragenlijst in voor een levensverzekeringsofferte. U laadt die antwoorden — samen met zijn financieel profiel en schadehistorie — in het platform. De artikel 9-data verlaat zo de beveiligde omgeving van uw kantoor. Ze wordt verwerkt op servers van de cloudaanbieder, mogelijk buiten de EU. Het platform kan zijn risicomodellen trainen op geaggregeerde cliëntdata van alle aangesloten makelaars. De gezondheidsgegevens van uw cliënt dragen zo bij aan het model van een concurrent.
Wanneer die cliënt vraagt hoe zijn gezondheidsdata is gebruikt, hebt u geen antwoord dat de volledige verwerkingsketen bij de cloudaanbieder dekt. Wanneer de GBA of de AP een onderzoek instelt na een klacht, blijkt de verwerkersovereenkomst de artikel 9-verwerking niet expliciet te omvatten. Dat is een overtreding.
Een GDPR-certificering van het AI-platform lost dit niet op. Certificering zegt iets over de beveiligingsmaatregelen voor dataopslag. Het zegt niets over of u een geldige grondslag hebt voor het insturen van artikel 9-data naar die tool. Dat moet u aantonen — de tool kan dat niet voor u doen.
De architectuur die wél werkt
“Jij verwerkt gezondheidsinformatie. Dat is artikel 9 GDPR — de strengste categorie. Die informatie mag je niet naar een cloud AI-platform sturen zonder expliciete grondslag en een waterdichte verwerkersovereenkomst. En dat doet bijna niemand goed.”
De oplossing zit niet in het vermijden van AI. Ze zit in de keuze waar de AI draait. Een lokaal ingezette AI verwerkt het volledige cliëntdossier — financieel profiel, schadehistorie en gezondheidsinformatie — op uw eigen systeem. U blijft als enige verwerkingsverantwoordelijke. Verwerkingsdoeleinden zijn controleerbaar en aantoonbaar. Er verlaat geen artikel 9-data uw kantoor.
Die architectuur ondersteunt ook uw IDD-zorgplicht. De Insurance Distribution Directive verplicht u tot een adviesproces dat aantoonbaar in het belang van de cliënt is. AI die het advies mede bepaalt maar niet auditeerbaar is, voldoet niet aan die verplichting. Lokale AI genereert een documenteerbaar adviesproces: elke stap traceerbaar, elke afweging vastgelegd — iets wat u aan de FSMA of de AFM kunt tonen.
Daarmee is lokale AI niet alleen een privacykeuze. Het is een argument voor de kwaliteit en de aantoonbaarheid van uw advies. Voor makelaars die al jaren bewijzen dat ze zorgvuldig en onafhankelijk werken, sluit dat naadloos aan bij hun werkwijze.
Drie stappen om mee te beginnen
Stap 1 — Breng uw artikel 9-data in kaart. Welke dossiers bevatten gezondheidsinformatie? Leven-, hospitalisatie- en inkomensverzekeringen zijn de meest voor de hand liggende categorieën. Die dossiers hebben een aparte behandeling nodig in uw register van verwerkingsactiviteiten — met een expliciete grondslag per verwerkingsdoel.
Stap 2 — Controleer uw AI-tools. Welke tools verwerken cliëntdata? Bestaat er een verwerkersovereenkomst? Dekt die overeenkomst expliciet de verwerking van bijzondere persoonsgegevens? Als het antwoord niet onmiddellijk helder is, stuurt u er voorlopig geen artikel 9-data naartoe — totdat u dat hebt uitgeklaard.
Stap 3 — Documenteer uw adviesproces. De IDD verplicht u tot transparantie en aantoonbare zorgplicht. Zorg ervoor dat de AI-tools die u inzet in het adviesproces een audittrail genereren die u aan de toezichthouder kunt tonen. Een lokaal systeem dat het adviesverslag automatisch opbouwt, is daarvoor de solide basis.
Als FSMA-geregistreerde makelaar hebt u al bewezen dat u vertrouwen en zorgvuldigheid serieus neemt. Uw cliënten geven u hun meest gevoelige informatie — inclusief informatie over hun gezondheid. De architectuur van uw AI-tools moet die vertrouwensrelatie ondersteunen, niet ondermijnen.
Lokale AI is geen compromis. Het is de enige oplossing die GDPR artikel 9 en de IDD-zorgplicht tegelijkertijd ondersteunt — zonder dat u hoeft te kiezen tussen efficiëntie en compliance.