RAG onder AFM-toezicht: playbook voor verzekeringsmakelaar

Het is 14:47 op een dinsdag in Gouda. Een schade-expert bij een verzekeringsmakelaar van 27 mensen neemt de telefoon op. De vrachtcontainer van een klant ligt op de bodem van het IJsselmeer. De hoofdpolis telt 84 pagina's, de small-print-module van de vervoerder nog eens 31, en de klant wil nu meteen weten of marine cargo doorloopt op binnenwater, en of de nieuwe overstromingsuitsluiting uit de herziene voorwaarden van 2025 geldt voor een vaartuig dat de haven verliet de dag voordat die herziening van kracht werd. Hij heeft zes minuten voordat de expert van de verzekeraar terugbelt. Op zijn tweede monitor heeft een RAG-agent al een antwoord opgesteld, met artikel, versie en ingangsdatum eronder.

Dat telefoontje komt 1.320 keer per week binnen bij dit kantoor. Vermenigvuldig dat met 18 verzekeraars, elk met eigen polisvoorwaarden, elk goed voor twee à drie herzieningen per jaar, en een dertien jaar oud dossierarchief in een custom CCS Insurance-installatie die niemand op kantoor nog volledig doorgrondt. De schade-experts zijn scherp. Het zijn geen zoekmachines.

Dit is het playbook voor de RAG-agent die we voor ze bouwden, met de focus op het stuk dat er echt toe doet: live gaan onder toezicht van de AFM zonder dat iemand wakker ligt van een Kifid-klacht.

Wat de toezichthouder echt wil

De korte versie is “een AI die zijn bronnen noemt.” De Wft eist in de praktijk iets specifiekers. Onder artikel 4:23 moet elk dekkingsadvies passend zijn, en elk passend advies moet reconstrueerbaar zijn. Zegt een schade-expert tegen een klant “je container is gedekt,” en betwist die klant dat later bij Kifid, dan moet het kantoor laten zien welke voorwaarde, in welke versie, op welke datum, die conclusie onderbouwt. Niet bij benadering. Exact.

Een LLM die een clausule hallucineert is in die context geen productiviteitstool. Dat is een toezichtsincident. De hele architectuur volgt uit die ene randvoorwaarde, en bijna elke interessante beslissing die we namen ging over het inperken van wat het model mag zeggen.

Waarom generieke RAG het laat afweten op Wft-documenten

Het standaardrecept voor RAG — knip elke PDF in stukjes van 512 tokens, embed met een meertalig model, cosine-similarity-zoekopdracht, prop de top acht in een prompt — werkt prima voor een customer-support-kennisbank. Op verzekeringscorpora valt het uit elkaar om drie redenen.

Ten eerste: polisvoorwaarden zijn geen lopende tekst. Het zijn geneste structuren: hoofdstuk → artikel → lid → sub. Een clausule over overstromingsschade kan acht niveaus diep zitten en gemodificeerd worden door een definitieblok 40 pagina's eerder. Knip op 512 tokens en je verliest de definities. Knip grotere chunks en de embedding wordt te vaag om iets terug te vinden. Hoe dan ook: de retrieval recall zakt en het model vult het gat met plausibele onzin.

Ten tweede: versies doen ertoe. De “Algemene Voorwaarden Transport 2022” en “Algemene Voorwaarden Transport 2024-Q3” van verzekeraar A delen 90% van hun tekst. Cosine similarity vindt ze allebei even leuk. De schade-expert heeft precies díe versie nodig die op de inceptiedatum van het lopende dossier aan de polis hing. Cosine heeft daar geen mening over.

Ten derde: het CCS-archief van dertien jaar staat vol vrije-tekst schadenotities, gescande PDF's en mailthreads waarin de bindende beslissingen feitelijk werden genomen. De helft daarvan is niet doorzoekbaar tot je het OCR't, en die OCR moet dossiernummer en datum bewaren, anders kun je een gevonden passage nooit meer terugkoppelen aan een echte zaak. De eerste OCR-ronde gaf ons 94% karakteraccuratesse en 31% dossier-koppelingsaccuratesse. De tweede ronde, met layout-bewuste extractie en een regex-lookup tegen de CCS-index, kwam op 99,6% bij de koppeling. Het eerste getal was onbruikbaar; het tweede was het enige getal dat ertoe deed.

Het corpus, gestructureerd

We modelleerden vier documentfamilies en gaven elk z'n eigen ingestion-pad:

• Polisvoorwaarden (31.600 documenten verdeeld over 18 verzekeraars). Structureel geparset, niet op tokenaantal. Elk artikel wordt één chunk, met de bovenliggende hoofdstuktitel, alle in-scope-definities en een metadata-header met verzekeraar, product, versie en ingangsdatumbereik.
• Wft, Bgfo en lagere regelgeving. Opgehaald van wetten.overheid.nl met de officiële artikel-ankers. Geversioneerd op wijzigingsdatum, met deep links terug naar de bron.
• Kifid-uitspraken. Gescraped, gededupliceerd, gelabeld op onderwerp en uitkomst. Alleen ingezet als ondersteunend precedent, nooit als primair advies.
• CCS-dossierarchief. Dertien jaar aan claims. Uitsluitend intern, nooit aan een klant geciteerd, alleen gebruikt als retrieval-signaal voor ‘hebben we dit eerder gezien’ en niets meer.

Elke chunk draagt een vetted: true | false-vlag. Het CCS-archief is nooit vetted. Polisvoorwaarden worden gevet door de compliance officer zodra er een herziening binnenkomt; dat kost hem ongeveer 40 minuten per verzekeraar per release, omdat de diffs getooled zijn. Wft en Kifid worden bij ingestion gevet tegen de officiële feeds, met een hashcheck bij elke refresh.

Retrieval in twee passes

De retrieval-pipeline draait in twee passes, omdat de tweede pass er is om de agent zijn mond te laten houden op het moment dat dat moet.

De eerste pass is hybride: BM25 over gestructureerde velden (verzekeraar, product, dossiernummer, dekkingscode) doorsneden met dense retrieval over de chunk-body. We gebruiken een Nederlands-getuned embedding-model en geven een kleine boost als het ingangsdatumbereik van de chunk de inceptiedatum van het dossier dekt. De resultatenset uit de eerste pass is maximaal 40 chunks; we dedupliceren op artikel en reranken met een kleine cross-encoder voordat we doorgaan.

De tweede pass is de citation gate. Voordat een chunk de draft-prompt bereikt, moet hij door drie checks komen:

def citation_gate(chunk, dossier):
    # 1. Version must match what was on the polis at inceptiedatum
    if chunk.doc_type == "polisvoorwaarden":
        if not chunk.effective_range.contains(dossier.inceptiedatum):
            return False, "version mismatch"

    # 2. Source must be vetted; CCS archive never reaches the draft
    if not chunk.vetted:
        return False, "unvetted source"

    # 3. Citation handle must resolve to a live URL or internal doc id
    if not resolve_citation(chunk.citation_handle):
        return False, "broken citation"

    return True, None

Een chunk die de gate niet haalt wordt gelogd met de reden en uit de prompt-context gehaald. Overleven er minder dan twee chunks, dan mag de agent helemaal geen dekkingsadvies opstellen; hij geeft een gestructureerd onvoldoende_onderbouwing-antwoord terug en stuurt de vraag door naar een menselijke schade-expert, met de top 40 uit de eerste pass als achtergrondlezing eronder. De verleiding bij de oplevering was om het model in zulke momenten terug te laten vallen op het CCS-archief: een vergelijkbare oude zaak patroon-matchen en het laten opschrijven. Dat hebben we niet gedaan. Het CCS-archief wordt nooit samengevat tot een antwoord. Precies díe failuremodus eindigt in een Kifid-uitspraak tegen het kantoor.

Concept opstellen met harde bronvermeldingen

De draft-prompt is saai. Met opzet. Hij krijgt de overgebleven chunks binnen, een system-instructie dat elke bewering getagd moet worden met het chunk-id waar hij vandaan komt, en een weigerclausule voor alles wat niet gedekt is.

You are drafting a dekkingsadvies for a schade-expert.
You may only state facts that are supported by one of
the provided passages. Tag every factual sentence with
the passage id in square brackets, e.g. [P-7].
If the provided passages do not cover a question,
write exactly: "Onvoldoende onderbouwing in de vetted bronnen."
Do not summarise, do not extrapolate, do not infer.

De output gaat vervolgens door een structurele validator: elke zin die eindigt op een feitelijke bewering moet minstens één [P-x]-tag bevatten. Zinnen zonder tag worden gestript voordat het concept zichtbaar wordt. De schade-expert ziet het concept met de passages als voetnoten, opent elke bron met één klik, en accepteert, bewerkt of verwerpt. Dat accept/edit/reject-signaal gaat terug de trainingsset van de reranker in.

Wat v1 fout deed

Deze vorm hadden we niet bij de eerste poging te pakken. De eerste build had drie problemen die we pas in week zes van de interne test opmerkten.

De cross-encoder die we eerst gebruikten was Engels-getuned, en bleef de Nederlandse polisvoorwaarden-chunks onderranken ten opzichte van Wft-referenties — precies omgekeerd aan wat de schade-experts nodig hadden. Overstappen op een Nederlandse reranker, gefine-tuned op zo'n 600 accept/edit/reject-signalen, fixte de volgorde binnen een week.

De citation handles in v1 wezen naar ruwe chunk-ID's. Bruikbaar voor het systeem, ondoorzichtig voor de compliance officer die een concept moet auditen. In v2 draagt elke handle de leesbare drie-eenheid (verzekeraar, documentversie, artikel), zodat één klik en één blik volstaan om ‘waar komt dit vandaan’ te beantwoorden.

De grootste misser zat in overmoed bij de gate. In het begin lieten we het model doorgaan als er maar één chunk overleefde. Dat leverde zelfverzekerd klinkend single-source-advies op dat technisch verdedigbaar maar praktisch te dun was. De drempel naar twee chunks tillen verlaagde het outputvolume met 9% en het klachtenpercentage van interne reviewers met meer dan de helft.

Het audit trail dat AFM ook echt leest

Elk gesprek schrijft één onveranderlijke rij weg: de vraag, de eerste-pass retrievalset, de overlevende chunks, de prompt die naar het model ging, de ruwe output van het model, het uiteindelijke advies van de schade-expert, en een hash over het geheel. Die hash haakt aan de vorige rij; geknoei wordt zichtbaar bij verificatie. De opslag is append-only; de applicatiegebruiker heeft geen DELETE-rechten op die tabel.

Toen AFM in maart binnenkwam voor een thematisch onderzoek, trok de compliance officer zes willekeurige gesprekken uit het vorige kwartaal en reconstrueerde de bronketen op een laptop binnen vijftien minuten. Dáár was het om te doen. Al het andere in het systeem is een middel tot die vijftien minuten.

Wat het in productie deed

In de eerste zestien weken handelde de agent 21.300 interne queries af. De cijfers waar het kantoor om gaf:

• De mediane tijd-tot-eerste-concept op een dekkingvraag daalde van 11 minuten naar 38 seconden.
• Van de getoonde concepten werd 71% door de schade-expert geaccepteerd zonder een enkele bewerking, 22% met bewerkingen, 7% rondweg verworpen.
• De onvoldoende_onderbouwing-weigering ging af op 6,4% van de vragen. Elke ervan ging meteen naar een mens, en niet in een verzonnen antwoord.
• Nul Kifid-klachten in de periode die terug te leiden waren naar een door de agent opgesteld advies.

Het interessante getal is die 6,4%. Dat is het percentage waarmee het systeem terecht toegaf dat het niet kon helpen. Een generieke RAG had die allemaal vrolijk beantwoord, en grofweg de helft was fout geweest op een manier die zes maanden later boven komt.

De bredere wind bij de toezichthouder

Dit soort architectuur blijft niet veel langer optioneel. Financiële toezichthouders in heel Europa kijken scherp naar AI in adviesketens, en de gepubliceerde prioriteiten van AFM wijzen steeds duidelijker op verklaarbaarheid als open vraag. Kan jouw RAG-systeem een toezichthouder niet vertellen welke clausule welke zin onderbouwde, dan zit je vroeg aan de verkeerde kant van een curve die steiler wordt, niet vlakker.

Wat je vandaag het kleinste kunt doen

Heb je een RAG-systeem in een gereguleerde context, doe vanmiddag dan één audit. Pak vijf antwoorden die het vorige week genereerde en probeer de bronketen terug te trekken naar een geversioneerde, gevetterde bron. Lukt dat niet voor alle vijf, dan staat je gate nog niet waar hij moet staan. Toen we dit voor de Goudse makelaar bouwden, was het ding waar we tegenaan bleven lopen het 13-jarige CCS-archief: de verleiding om het model ‘even daar te laten kijken naar vergelijkbare gevallen’ was constant, en zou precies de failuremodus zijn geweest. We hebben dat opgelost door het archief te behandelen als puur retrieval-signaal dat het concept nooit ingaat, gekoppeld aan een harde citation gate van de RAG-agent. De saaie randvoorwaarde is wat het kantoor uit Kifid hield.