De stille pilotkerkhoven: waarom de meeste AI-projecten niet door de pilotfase komen

In LinkedIn-posts en op congressen klinkt de verzekeringssector enthousiast over AI. Pilots, proofs of concept, succesverhalen. Wat je zelden hoort: hoeveel van die pilots stilletjes verdampen voordat ze ooit productie raken.

Brancherapporten van grote consultancies — Gartner, McKinsey, BCG, IBM — hebben de afgelopen jaren herhaaldelijk percentages gepubliceerd in de orde van 70 tot 85 procent van enterprise AI-initiatieven die de pilotfase niet ontgroeien. De exacte definitie verschilt per onderzoek, en de cijfers moeten met enige voorzichtigheid worden gelezen, maar het patroon is consistent: het overgrote deel van de AI-projecten levert geen blijvende productiewaarde op. RAND Corporation publiceerde in 2024 een aparte analyse over waarom AI-projecten falen, met grotendeels dezelfde conclusies.

In de Nederlandse verzekeringssector zien we vier oorzaken keer op keer terugkomen.

Oorzaak 1: legacy die geen API kent

De polisadministraties van veel Nederlandse verzekeraars en volmachten draaien op systemen die in de jaren 90 of vroege 2000 zijn gebouwd. Anva, CCS, Coveryou, Quinity, en in de grotere huizen vaak nog mainframe-systemen of oudere AS/400-architecturen. Ze functioneren prima voor het werk waar ze voor gebouwd zijn, maar ze zijn niet ontworpen om real-time door externe agents bevraagd te worden.

In pilots wordt dat probleem omzeild door met geëxporteerde datasets te werken — een Excel-export van vorige week, een testomgeving met een statische subset. De agent presteert daar goed. Bij overgang naar productie blijkt dat de aansluiting op de live administratie een integratieproject van maanden vereist, met bijbehorende kosten en risico’s. Veel pilots stranden op dat punt — niet omdat de AI niet werkt, maar omdat de business case na de integratiekosten ineens minder aantrekkelijk is.

Oorzaak 2: datakwaliteit die er handmatig nog mee door kon

Mensen zijn buitengewoon goed in het opvangen van slechte data. Een schadebehandelaar die “wnh.verz.” in een veld leest, weet dat woonhuisverzekering wordt bedoeld. Een acceptant die een dubbel klantrecord ziet, voegt het mentaal samen. Een AI-agent doet dat niet — die behandelt het als twee aparte gevallen of slaat aan op de afwijking en escaleert.

Het gevolg: data die jarenlang “goed genoeg” was, blijkt voor automatisering ontoereikend. De keuze die dan voorligt is hard. Of je investeert eerst in een data-opschoning die zes tot twaalf maanden duurt voordat je überhaupt iets met AI kunt, of je accepteert dat de agent een aanzienlijk percentage uitzonderingen genereert die alsnog handmatig moeten worden behandeld — wat een groot deel van de beoogde tijdwinst opeet.

Oorzaak 3: de demo versus de lange staart

Een AI-agent presteert in demo’s vaak indrukwekkend, vooral op zorgvuldig gekozen voorbeelden. Productie is anders. Daar komt de lange staart binnen: half ingevulde formulieren, ongebruikelijke schadepatronen, polisconstructies die door overnames en herstructureringen niet meer in één systeem passen, klanten die op vier verschillende manieren in de administratie staan.

Pilots die niet expliciet op die staart testen, halen voorspelbaar de productie niet. Een eerlijke pilot werkt niet met 200 zorgvuldig geselecteerde cases, maar met een willekeurige steekproef uit de echte instroom — inclusief het rommelige derde. Als de agent daar zakt, is dat geen reden om de pilot uit te breiden, maar om eerst de processen die de rommel veroorzaken aan te pakken.

Oorzaak 4: change management dat altijd te laat komt

Dit is de minst technische en meest onderschatte oorzaak. Een AI-agent in claimverwerking verandert het werk van schadebehandelaars fundamenteel. Hun rol verschuift van uitvoeren naar toetsen, van behandelen naar uitzonderingen oplossen. Als de organisatie dat traject niet parallel inricht — met herziene functieprofielen, training, en heldere communicatie over wat er met capaciteit gebeurt — gaat het team de implementatie passief of actief tegenwerken.

Dat is geen kwade wil. Het is rationeel gedrag van mensen die onzeker zijn over hun positie. De implementatie wordt ondergesneeuwd door “ja, maar in dit geval kan het toch niet” en “ik vertrouw het systeem niet”, uitgesproken door precies de mensen die het systeem moeten ondersteunen.

Wat onderscheidt projecten die wél productie halen

Vier dingen, in onze ervaring. Eén: ze beginnen klein en duidelijk afgebakend — één proces, één productlijn, één gedefinieerde groep cases — in plaats van een transformatieprogramma. Twee: ze hebben vanaf dag één een integratie-engineer aan tafel, niet alleen een data scientist, zodat de aansluiting op de bestaande systemen onderdeel is van de scope. Drie: ze testen vroeg met willekeurige steekproeven uit productie, niet met geselecteerde demonstratiecases. Vier: ze betrekken het uitvoerende team niet als ontvanger maar als mede-ontwerper — degenen die het werk straks moeten doen, kennen de uitzonderingen die anders pas in productie worden ontdekt.

Hoe Table Duck hiernaar kijkt

De grootste fout die we partijen zien maken is het verwarren van een geslaagde demo met een werkend systeem. Een demo bewijst dat AI iets kán; productie bewijst dat het iets doét, dag in dag uit, voor de echte instroom inclusief de rommelige randen. Dat onderscheid bepaalt of een investering uiteindelijk de moeite waard was of in een rij eerdere proefballonnen verdwijnt.

Wij beginnen onze trajecten daarom met een eerlijke procesmapping waarin we juist de uitzonderingen en legacy-knelpunten zoeken, voordat er ook maar een lijn code wordt geschreven. Soms is de conclusie dat een proces niet rijp is voor automatisering. Dat is een ongemakkelijk gesprek aan het begin van een traject, maar oneindig veel goedkoper dan datzelfde gesprek na zes maanden bouwen.