Ga naar inhoud
AI & Verzekeringen · 30 juli 2026 · 10 min leestijd

Verzekeringssoftware 2026:
de adviseur wordt de leverancier

Twee tussenpersonen bouwen zelf de software waar hun vakgenoten op wachten, en dat is volgens mij het begin van een bredere verschuiving.

Illustratie bij artikel: Verzekeringssoftware 2026: de adviseur wordt de leverancier

TL;DR

  • Twee adviseurs op de AM-voorpagina in zes weken. Henry de Cock en Mark van Maurik bouwen zelf AI-software voor advieskantoren — en de vakpers zet ze beiden op de cover.
  • De bouwdrempel is weggevallen. Gartner voorspelt dat in 2028 tachtig procent van techproducten door niet-professionals wordt gebouwd. Vakkennis telt zwaarder dan code.
  • Het voordeel dat een softwarehuis niet kan kopen: zelf de doelgroep zijn. Feedbackloop van nul dagen, op echte klanten en echte polissen.
  • Meeliften is geen gratis lunch. Stel dezelfde AVG-, security- en continuïteitsvragen als aan elk softwarehuis — ook aan een conculega.
  • De verschuiving komt van binnenuit. Niet big tech of insurtechs, maar het klantenbestand van de gevestigde pakketleveranciers zelf.

Twee tussenpersonen bouwen zelf de software waar hun vakgenoten op wachten, en dat is volgens mij het begin van een bredere verschuiving.

De afgelopen twee jaar heb ik meer werkende software gebouwd dan in mijn 35 verzekeringsjaren daarvoor, zonder team en zonder development-budget. Een scanner die websites toetst aan wettelijke eisen, een tool die schadeclaims beoordeelt op basis van foto's, een Chrome-plugin voor formulieren, mijn hele blogsite.

En deze zomer zag ik in AM (opent in nieuw venster) twee vakgenoten die hetzelfde doen, maar dan met een verdienmodel eraan vast.

Twee voorpagina's in zes weken

Op 18 juni 2026 portretteerde AM (opent in nieuw venster) Henry de Cock van Alblasserwaardsche Verzekeringen, naar eigen omschrijving een gemiddeld intermediairbedrijf. De Cock bouwt AI-agents bovenop zijn bestaande CRM-pakket. In naar eigen zeggen twee uur maakte hij een tool die betaalherinneringen omzet in gepersonaliseerde mails, en hij laat andere kantoren meeliften op wat hij bouwt. Zijn inschatting: tachtig procent van de advieskantoren lijkt op het zijne. Wat bij hem werkt, werkt daar dus ook.

Zes weken later, op 30 juli, stond de volgende bouwer in AM (opent in nieuw venster). Mark van Maurik, ruim dertig jaar financieel adviseur, bouwde met Advey.ai een intelligentielaag voor advieskantoren. Zijn tool schrijft klantmails na het gesprek, stelt adviesrapporten op, controleert documenten en vergelijkt polisvoorwaarden. Volgens het artikel gebruiken ruim 85 kantoren de oplossing, twee maanden na de livegang. Een tijdsbesparing van zo'n zeventig procent op dagelijkse routines bestempelt Van Maurik als reëel.

Ik schrijf er bewust "naar eigen zeggen" en "volgens het artikel" bij. Al deze cijfers komen van de bouwers zelf, opgetekend door één journalist. Dat maakt ze niet onwaar, maar wel ongeverifieerd, en dat verschil hoort benoemd te worden. Voor het punt van dit stuk doet de precieze tijdwinst er trouwens weinig toe. Wat ertoe doet is het patroon: twee mensen uit de adviespraktijk bouwen software voor hun eigen vakgenoten. En de vakpers zet ze binnen zes weken allebei op de voorpagina.

Uitzoomen: dit is breder dan twee kantoren

Twee cases zijn nog geen trend, dus laten we uitzoomen. Gartner voorspelt (opent in nieuw venster) dat in 2028 tachtig procent van techproducten gebouwd wordt door mensen die geen professionele developer zijn. Het aandeel bouwers met een niet-technische achtergrond stijgt volgens diezelfde voorspelling van twintig naar veertig procent. Bij v0 van Vercel is 63 procent van de ruim vier miljoen gebruikers geen developer, meldt Mercury (opent in nieuw venster). En bij Lovable zegt vier op de vijf gebruikers een niet-technische rol te hebben.

De verklaring is simpel: de bouwdrempel is weggevallen. Tools als Claude Code, Cursor en Lovable vertalen vakkennis rechtstreeks naar werkende software. Een informaticaopleiding hoeft er niet meer tussen te zitten. Ik schreef eerder al dat iedereen kan bouwen, maar niet iedereen iets te zeggen heeft. De Cock en Van Maurik zijn daarvan de sectorversie. Zij hebben wél iets te zeggen, omdat ze tientallen jaren zelf in de processen zaten waar hun software nu op ingrijpt.

En daarmee kantelt de machtsverhouding in de softwaremarkt. Twintig jaar lang was de volgorde vast: een softwarebedrijf bouwt een pakket, en de kantoren passen hun werkwijze daarop aan. Van Maurik benoemt dat mechanisme zelf in het AM-artikel. De meeste techbedrijven ontwikkelen eerst iets en vragen daarna aan kantoren om zich aan te passen. Zijn aanpak draait dat om, want zijn AI volgt de routines van de adviseur in plaats van andersom. Dat kan hij alleen omdat hij die routines zelf dertig jaar heeft uitgevoerd.

Het voordeel dat een softwarehuis niet kan kopen

Hier zit de kern van waarom ik denk dat dit groter wordt dan twee sympathieke pioniers. Een softwarehuis kan developers inhuren, productmanagers aannemen en klantpanels organiseren. Maar één ding kan het niet kopen: zelf de doelgroep zíjn. De Cock test zijn agents elke dag in zijn eigen kantoor, op echte klanten, echte polissen en echte betalingsachterstanden. Elke irritatie die hij voelt, is er een van tachtig procent van de markt, als zijn inschatting klopt. Zijn feedbackloop duurt nul dagen. Die van een traditioneel softwarehuis loopt via accountmanagers, tickets en releaseplanningen.

Daar komt iets bij wat volgens mij typisch is voor de verzekeringssector: de conculega-cultuur. In weinig sectoren is het zo normaal dat concurrenten samenwerken. Intermediairs delen al decennia serviceproviders, inkoopcombinaties en volmachtconstructies. Ze noemen elkaar conculega's, en dat woord bestaat in weinig andere branches. In die cultuur is software bouwen voor je directe concurrent geen taboe maar een logisch verdienmodel. Precies daarom kan een adviseur uit de Alblasserwaard andere kantoren laten meeliften zonder dat iemand dat vreemd vindt.

De sector heeft daarmee twee eigenschappen die deze beweging versnellen. Duizenden kleine kantoren draaien vrijwel identieke processen, en er bestaat een cultuur waarin je van elkaar afneemt. Voeg daar AI-tools aan toe die de bouwdrempel wegnemen, en je krijgt wat we nu zien gebeuren.

Twee bouwers, twee routes

Interessant genoeg kiezen de twee bouwers heel verschillende routes, en dat verschil vertelt iets over waar deze beweging heen kan.

De Cock bouwt agents bovenop de systemen die hij al heeft. Hij vervangt zijn CRM-pakket niet maar zet er een eigen laag overheen. Wat hij maakt deelt hij informeel met kantoren die erom vragen, terwijl zijn advieskantoor de hoofdactiviteit blijft. Het AM-artikel vat zijn ambitie samen onder de kop "verbeteren zonder afhankelijkheid van softwarebedrijven". Zijn model is dat van de bouwende vakman: de tool dient het eigen kantoor, en het meeliften van anderen is een bijproduct.

Van Maurik ging een stap verder en maakte er een productbedrijf van. Advey integreert met gangbare pakketten als Figlo en FasterForward, en werkt volgens het artikel ook stand-alone voor kantoren zonder CRM. Hij groeit richting de honderd aangesloten kantoren. Dat is geen bijproduct meer maar een softwareleverancier in wording. Daar hoort alles bij: releases, support, een prijsmodel en de plicht om door te ontwikkelen zolang er klanten betalen.

Beide routes zijn legitiem, maar ze stellen verschillende eisen. De vakman-route vraagt vooral nieuwsgierigheid en tijd. De productroute vraagt daarnaast alles waar softwarebedrijven hun bestaansrecht aan ontlenen: continuïteit, beveiliging, documentatie en de discipline om door te bouwen als de eerste lol eraf is. Mijn inschatting is dat we de komende jaren veel meer De Cocks dan Van Mauriks gaan zien. De eerste route is laagdrempelig, de tweede betekent een carrièreswitch. Voor de softwarehuizen is dat weinig geruststellend. Ook duizend bouwende vakmannen die hun eigen gaten dichten, betekenen duizend kantoren die minder afhankelijk worden van de releaseplanning van hun leverancier.

De gevestigde orde voelt het al

Het interessantste detail in het De Cock-artikel staat bijna terloops onderaan. Max Mouwen, CEO van ANVA, beloofde onlangs de aankomende drie jaar meer te innoveren dan de 25 jaar daarvoor. Ik heb die zin twee keer gelezen, omdat er zoveel in zit. Een gevestigd softwarehuis dat al decennia de administratie van het intermediair draagt, belooft in drie jaar meer te doen dan in de kwarteeuw ervoor.

Zulke uitspraken doe je niet als het lekker loopt. Je doet ze als je ziet dat je klanten om je heen beginnen te bouwen, en je weet dat elke maand vertraging weer een nieuwe Henry of Mark oplevert. De AM-redactie merkte er droogjes bij op dat die belofte niet alleen aan de softwaregiganten voorbehouden hoeft te blijven. Dat is precies het punt.

Wie de afgelopen jaren voorspelde wie de markt voor verzekeringssoftware zou opschudden, keek vrijwel altijd naar buiten. Naar big tech die de markt zou binnenkomen, naar insurtechs die de distributie zouden kapen. Ik denk dat we naar de verkeerde kant keken. De verschuiving komt van binnenuit, uit het klantenbestand van de softwarehuizen zelf. De klant die twintig jaar lang releaseplanningen afwachtte, wacht niet meer maar bouwt zelf.

Wat dit betekent als jij zo'n kantoor runt

Betekent dit dat je morgen je pakketleverancier moet opzeggen en moet meeliften op de tool van een vakgenoot? Nee, en hier neem ik even afstand van mijn eigen enthousiasme.

Software van een collega-adviseur is nog steeds software, met alles wat daarbij hoort. Het GenAI Code Security Report van Veracode (opent in nieuw venster) stelde vast dat 45 procent van AI-gegenereerde code beveiligingslekken bevat. Een adviseur die in twee uur een tool bouwt, heeft zelden een securityteam, een testprotocol of een uitwijkplan.

En dan de kant die in dit vak het zwaarst weegt: de data. Zo'n tool verwerkt klantgesprekken, polisgegevens en soms medische of financiële informatie, en dat maakt het geen handigheidje meer maar een verwerking onder de AVG. Dan wil je precies weten waar die data staat, in de EU of daarbuiten, en of er een verwerkersovereenkomst ligt. Je wilt weten welk AI-model het transcript van een klantgesprek maakt, welk model de vertaling of samenvatting doet, en of die aanbieder jouw klantdata gebruikt om zijn modellen te trainen. En je wilt dat ook aan je klant kunnen uitleggen, want die zit tegenover jou in het adviesgesprek en niet tegenover de bouwer van de tool. Kan de bouwer die vragen niet beantwoorden, dan voldoet de tool per definitie niet aan de eisen van deze branche, hoe goed hij ook werkt. Jij blijft als kantoor verantwoordelijk voor de verwerking, en hoe sympathiek de bouwer is, doet er dan niet toe.

Er is ook een continuïteitsvraag die ik in beide artikelen mis. Wat gebeurt er met de 85 kantoren van Van Maurik als hij over drie jaar verkoopt aan een partij die de prijzen verdrievoudigt? En wat doen de meelifters van De Cock als hij er ooit mee stopt? Wie een pakket van ANVA afneemt, ruilt bewegingsvrijheid in voor zekerheid. Wie meelift op de tool van een conculega, doet precies het omgekeerde. Ik schreef eerder over vendor lock-in bij AI-leveranciers, en die analyse geldt onverkort als je leverancier toevallig ook je concurrent is. Sterker nog: je nieuwe leverancier kijkt dan mee in de processen waarmee jij je klanten bedient.

Dus stel de vragen die je aan elk softwarehuis zou stellen. Waar staat mijn data, wie heeft er toegang toe, wat gebeurt er bij een datalek, wat is het exit-scenario, en wie onderhoudt dit over vijf jaar? Die vragen voelen ongemakkelijk richting een vakgenoot die je op een congres tegenkomt. Dat is geen reden om ze niet te stellen.

En als je zelf die bouwer wilt zijn

De omgekeerde les is minstens zo interessant. Een naar eigen zeggen doodgemiddeld kantoor uit de Alblasserwaard kan dit dus, en een adviseur met dertig jaar praktijkervaring bindt binnen twee maanden 85 kantoren aan zich. Dan is dit de vraag voor elke tussenpersoon met een beetje technische nieuwsgierigheid: welk probleem los jij elke week handmatig op waar duizend andere kantoren ook mee zitten?

Mijn eigen ervaring is dat het bouwen zelf het makkelijke deel is geworden. Mijn tool die schadeclaims beoordeelt op foto's kostte me maximaal vier uur werk. De scanner die websites toetst aan wettelijke eisen was met zo'n zestien uur een stuk bewerkelijker, maar bespaart me minimaal 300 euro per maand vergeleken met wat ik zou betalen als ik dit extern inkoop. Helemaal vanzelf gaat het overigens niet. Je moet een API opzetten, een database inrichten en grofweg volgen wat er gebeurt. AI neemt dat werk grotendeels uit handen, maar het helpt als je begrijpt wat er wordt gebouwd. En snap je iets niet, dan vraag je AI gewoon om het uit te leggen.

Ik beschreef eerder al een wereld van software on demand, waarin je software vraagt en het bestaat. Schaars is niet meer de code, maar de vakkennis die bepaalt wát er gebouwd moet worden. En laat dat nou net het enige zijn waar jij na tientallen jaren in dit vak meer van hebt dan elke developer in Amsterdam of San Francisco.

De twee heren uit de AM-artikelen begrepen dat eerder dan de rest. Zij worden nu de softwareleveranciers van hun eigen sector, terwijl de gevestigde huizen 25 jaar innovatie in drie jaar beloven te proppen. Let de komende twaalf maanden maar op wie er nog meer opstaat. De derde en de vierde bouwer zitten nu ergens polisvoorwaarden te vergelijken en denken: dit moet toch handiger kunnen.

Dat dacht ik twee jaar geleden ook. Het kostte me een laptop en een abonnement.

Bronnen