Hoe je AI-output verifieert vóór je hem verstuurt of publiceert

Een AI-model levert zijn antwoord met precies dezelfde zelfverzekerde toon, of het nu klopt of niet. Dat is het venijnige aan de fout: een verzonnen bronvermelding, een net-niet-kloppend bedrag of een niet-bestaand wetsartikel leest even overtuigend als de waarheid. Zolang die output binnen je eigen muren blijft, is dat hooguit vervelend. Op het moment dat je hem verstuurt naar een klant of publiceert onder je eigen naam, wordt het jouw verantwoordelijkheid en jouw risico.

Dat risico is geen theorie meer. KPMG moest een onderzoeksrapport intrekken nadat er verzonnen bronnen in werden gevonden, het soort fout dat inmiddels 'vibe citing' heet. Het patroon erachter is dat hallucinaties geen incidentele bug zijn maar een structureel bedrijfsrisico: zolang een taalmodel woorden voorspelt in plaats van feiten opzoekt, hoort het verzinnen er gewoon bij.

Deze handleiding is voor iedereen die teksten, rapporten, offertes of klantantwoorden met AI maakt en ze daarna de deur uit doet: marketeers, juristen, finance, klantenservice, en de ondernemer die zelf even snel iets laat opstellen. Het idee is simpel: je vertrouwt de output niet, je verifieert hem, en je richt dat zo in dat het een vaste stap wordt in plaats van een toevallige controle. Ik loop het protocol stap voor stap door, met de valkuilen en een eerlijke afweging tussen een kant-en-klare oplossing en maatwerk.

Wat je nodig hebt

Je hoeft hier geen heel apparaat voor op te tuigen, maar een paar bouwstenen moeten op orde zijn voordat het protocol werkt:

• Je bronnen op een rij. De documenten, prijslijsten, contracten of databases waarop het antwoord gebaseerd hoort te zijn, in een vorm die je aan het model kunt voeren (een AI-chatbot op je eigen data via RAG is hiervoor de gangbare aanpak).
• Een model of API met bronvermelding. Niet alleen een chatvenster, maar een functie die claims aan brondocumenten koppelt (zie stap 1).
• Een schema-validator. Een stukje code (Pydantic in Python, Zod in TypeScript, of kale JSON Schema) dat de output op vorm en waarden controleert.
• Een review-plek. Een wachtrij, een gedeeld document of een tab in je tool waar een mens de output naast de bronnen ziet voordat hij akkoord geeft.
• Een logboek en versiebeheer. Ergens om vast te leggen wat erin ging, wat eruit kwam en wie akkoord gaf, plus een manier om gepubliceerde tekst terug te draaien (een CMS met versies, of git).

Het vijf-staps verificatieprotocol

Het doel: elke AI-output die je extern gebruikt, doorloopt vijf vaste controles, van bronverificatie tot een rollback-plan, zodat een fout wordt gevangen voordat hij bij een klant landt in plaats van erna. De stappen bouwen op elkaar voort; sla er geen over voor publicaties met juridische of financiële lading.

Doorloop deze vijf stappen in volgorde:

Stap 1 - Claim-check met bronverwijzing

Laat het model niet zichzelf controleren uit zijn losse pols. Vraag je een tweede AI om de tekst te 'fact-checken' zonder bronnen, dan krijg je simpelweg een tweede zelfverzekerde gok. De enige betrouwbare claim-check koppelt elke bewering aan een echte bron die jij hebt aangeleverd.

Geef het model dus de brondocumenten mee en dwing het te citeren. De Citations-functie van Anthropic koppelt elke bewering in het antwoord aan de exacte zin of pagina in je brondocument, en garandeert dat die verwijzing daadwerkelijk naar de aangeleverde tekst wijst, niet naar iets verzonnens. Werk je met OpenAI of Gemini, dan doen grounding-met-zoeken en vergelijkbare bron-features hetzelfde principe: geen claim zonder vindplaats. Alles wat het model beweert zonder bron, behandel je als onbevestigd en markeer je voor stap 3.

Denk niet dat dit overbodig is zodra je een bron meegeeft. Uit de hallucinatie-ranglijst van Vectara blijkt dat zelfs de best scorende modellen nog enkele procenten van de feiten verkeerd weergeven wanneer ze niets anders doen dan een aangeleverd document samenvatten.

Stap 2 - Structured output validatie

Een gegeven dat een machine verder verwerkt, hoort nooit als losse zin uit een model te komen. Voor een bedrag, een datum, een IBAN, een productcode of een blok JSON dat je doorgeeft aan een ander systeem, gebruik je structured outputs. Met strikte structured outputs van OpenAI (strict: true) dwing je het model in een vast JSON-schema, zodat de uitvoer altijd de juiste velden en types heeft en je niet hoeft te hopen dat het netjes parseert.

Maar let op: een geldig schema garandeert de vorm, niet de waarheid. Daarom volgt na het schema je eigen validatie. Controleer met je validator de inhoudelijke regels die het model niet kent: valt het bedrag binnen een logische bandbreedte, telt het factuurtotaal op uit de regels, ligt de leverdatum in de toekomst, bestaat het ordernummer echt in je database? Het schema bewaakt de vorm, jouw validatie bewaakt de betekenis. Wat door beide komt, mag door naar de mens.

Stap 3 - Het menselijke review-moment

Voor alles met gewicht zet een mens de laatste handtekening. Dat hoeft geen rem te zijn als je het slim inricht: toon de output naast de geciteerde bronnen uit stap 1, en markeer elke bewering zonder bron in een opvallende kleur. De reviewer leest dan niet de hele tekst opnieuw, maar controleert gericht de onbevestigde punten.

Werk met een drempel op basis van risico. Een interne samenvatting mag automatisch door; een offerte, een juridisch advies of een publieke publicatie krijgt altijd een mens. Dat de prijs van overslaan reëel is, lieten zowel de Duitse rechter die Google aansprakelijk stelde voor onjuiste AI-overzichten als Tesla, dat de RDW misleidende cijfers over zijn rijhulp gaf zien: een onjuiste, naar buiten gebrachte claim wordt jouw probleem, ongeacht of een model of een leverancier hem produceerde.

Stap 4 - Audit-trail voor de AI Act

Leg van elke uitgaande output vast hoe hij tot stand kwam. Een bruikbaar logboek bevat per item: de prompt, het model en de versie, de gebruikte bronnen, de ruwe output, wie akkoord gaf en wanneer, en het besluit. Dat is niet alleen netjes, het wordt voor een groeiende groep systemen verplicht: artikel 12 van de AI Act eist dat hoog-risico AI-systemen gebeurtenissen automatisch loggen gedurende hun hele levensduur, zodat de werking achteraf te herleiden is.

Ook als jouw toepassing niet onder 'hoog risico' valt, is dit logboek je bewijslast op het moment dat iemand een claim betwist: je laat zien op welke bron een uitspraak rustte en wie hem goedkeurde. Wil je weten of jouw systemen onder de verplichtingen vallen, loop dan de AI Act-nalevingschecklist voor het MKB langs. Bewaar de logs met een vaste bewaartermijn en zonder onnodige persoonsgegevens, anders ruil je het ene risico in voor een AVG-risico.

Stap 5 - Rollback bij een gepubliceerde fout

Bedenk de terugdraai-procedure voordat je hem nodig hebt. Er glipt er ooit eentje door, en dan telt hoe snel en compleet je hem rechtzet. Zorg voor drie dingen: versiebeheer op je content (een CMS met versies of git), zodat je de vorige versie terugzet; een manier om te traceren waar een claim allemaal terechtkwam (welke mailing, welke pagina, welk document); en een vast correctie-format zodat de rechtzetting niet zelf weer een improvisatie is.

Sluit de lus door de oorzaak aan te pakken: pas de bron, de prompt of het schema aan zodat dezelfde fout niet terugkomt. KPMG moest een heel rapport intrekken; met een rollback-plan was dat een procedure geweest in plaats van een crisis.

Valkuilen

• AI die AI controleert zonder bron. Een tweede model dat 'meekijkt' zonder toegang tot de echte bronnen levert geen controle op, maar een tweede mening die net zo goed verzonnen kan zijn. Controle bestaat alleen tegen een bron, niet tegen een ander model.
• Citaties en strikt schema in één call. Bij Anthropic kun je de Citations-functie en structured outputs niet combineren in dezelfde aanroep; dat geeft een 400-fout, omdat citaten tussen de tekst worden geweven en een strikt JSON-schema dat juist uitsluit. Splits het daarom in twee passes: eerst de inhoudelijke claim-check met bronnen, dan een aparte call die het resultaat in je schema giet.
• Geldig schema verward met juiste inhoud. Een perfect geformatteerd bedrag dat gewoon fout is, komt moeiteloos door de schema-check. De vorm zegt niets over de waarheid; daarvoor heb je stap 2's inhoudelijke validatie en stap 3's mens nodig.
• Review-moeheid. Als alles even zwaar gereviewd moet worden, gaan mensen blind aftekenen. Differentieer naar risico, zodat de aandacht naar de stukken gaat die ertoe doen.
• Logs zonder beleid. Een audit-trail vol persoonsgegevens zonder bewaartermijn is zelf een datalek-in-wording. Log wat je nodig hebt voor herleidbaarheid, niet meer.

Kant-en-klaar vs. maatwerk

Moet je hiervoor zelf bouwen, of kan een bestaand pakket het? Dat hangt af van wat er op het spel staat als een fout doorglipt.

Voor het gros van de interne tekst is een kant-en-klaar pakket met een vaste reviewstap ruim voldoende, en zonde om voor te gaan bouwen. Zodra de output je organisatie verlaat met juridische, financiële of merkrisico's eraan, win je met een eigen pijplijn precies de controle die je bij een leverancier mist: jouw bronnen, jouw schema, jouw bewaarbeleid. De meeste organisaties belanden op een mix: kant-en-klaar voor het dagelijkse werk, maatwerk-verificatie om de stukken die de deur uit gaan.

Tot slot

De vraag is niet langer of je AI mag inzetten voor je teksten, maar of je de uitkomst kunt verdedigen op het moment dat iemand ernaar vraagt. Een model dat overtuigend klinkt, geeft je geen enkele garantie; een protocol dat elke bewering aan een bron koppelt, in vorm en waarde controleert, langs een mens leidt, vastlegt en kan terugdraaien, geeft die garantie wel. Verificatie is geen rem op AI. Het is precies wat AI bruikbaar maakt voor het werk dat ertoe doet.