3 promptregels die mijn AI lieten stoppen met gokken

Ik verloor een klant omdat GPT-4o me vol vertrouwen de verkeerde betalingsvoorwaarden van een contract vertelde.

Niet "een beetje fout." Niet "licht afwijkend." Het haalde een net-30 bedrag van pagina 8 van een 22 pagina's tellende leveranciersovereenkomst, terwijl het de gewijzigde net-45 op pagina 14 volledig negeerde. Ik bouwde het facturatieschema rond dat getal. De klant betaalde op tijd — volgens het verkeerde schema. De leverancier signaleerde de discrepantie. De klant vroeg waarom ik het niet had opgemerkt. Ik had geen goed antwoord.

De AI had gelijk bij 47 andere velden in dezelfde extractie. Adressen, datums, regelitems, btw-nummers — allemaal perfect. Dat maakte de fout in de betalingsvoorwaarden zo gevaarlijk. Wanneer een systeem 98% van de dingen goed doet, stop je met het controleren van de andere 2%. En die 2% is waar de schade zich verbergt.

Dat contractincident gebeurde in oktober 2025. Sindsdien ben ik geobsedeerd door één vraag: hoe voorkom je dat AI gokt wanneer het het niet weet?

Niet "hoe verminder je hallucinations" in de abstracte, academische zin. Ik bedoel specifiek — wanneer je een AI-model een document geeft en vraagt om gestructureerde data te extraheren, hoe voorkom je dat het een zelfverzekerd antwoord invult wanneer het echte antwoord dubbelzinnig, ontbrekend of tegenstrijdig is?

Ik vond drie regels die werken. Ze zijn doodeenvoudig. Ze vereisen geen fine-tuning, RAG-pipelines of aangepast modeltraining. Het zijn gewoon promptstrategieën — maar ze veranderen fundamenteel hoe de AI zich gedraagt. Ik draai ze al vijf maanden in productie voor contractreview, factuurverwerking en CRM-gegevensinvoer, en het verschil is als dag en nacht.

Dit is wat de meeste prompt engineering gidsen je niet vertellen: het probleem is niet dat AI-modellen intelligentie missen. Het probleem is dat ze er te veel van hebben — gecombineerd met nul eerlijkheid over wat ze niet weten.

Waarom slimmere modellen zelfverzekerder gokken (niet minder)

Er is een patroon waar ik steeds tegenaan loop waar niemand genoeg over praat. Naarmate AI-modellen capabeler worden, worden ze niet eerlijker. Ze worden overtuigender fout.

Ik noem dit de Intelligentie-Eerlijkheidskloof. En het onderzoek bevestigt dit.

MIT-onderzoekers ontdekten in januari 2025 dat wanneer AI-modellen hallucineren, ze 34% meer geneigd zijn om taal met hoog vertrouwen te gebruiken — woorden als "zeker," "absoluut" en "zonder twijfel." Het model aarzelt niet wanneer het gokt. Het verdubbelt de inzet.

Dit is geen bug in een specifiek model. Het is een structureel probleem dat ingebakken zit in hoe alle large language models worden getraind. Een studie uit 2025 gepubliceerd in Science legde het helder uit: LLM's leren bluffen omdat hun training zelfverzekerde antwoorden beloont en onzekerheid bestraft. De incentivestructuur is identiek aan een meerkeuzexamen waarbij een blanco antwoord nul punten oplevert, maar gokken een kans op punten geeft. Dus gokt het model altijd.

Onderzoekers van Carnegie Mellon bevestigden dit in juli 2025 — AI-chatbots blijven overmoedig, zelfs wanneer ze fout zitten, en gebruikers kunnen het verschil niet betrouwbaar detecteren tussen een zelfverzekerd juist antwoord en een zelfverzekerde hallucination.

De praktische implicatie trof me hard: reasoning-modellen — degene waarvoor ik premiumprijzen betaalde — hallucineren bij dubbelzinnige taken eigenlijk meer, niet minder. Recente benchmarks van begin 2026 tonen dat GPT-5, Claude Sonnet 4.5 en Gemini-3-Pro allemaal hallucination-percentages van meer dan 10% haalden op moeilijkere benchmarks. De hypothese? Reasoning-modellen "overdenken" — ze investeren rekenkracht in het construeren van plausibel klinkende antwoorden uit onvoldoende bewijs, in plaats van het bewijs als onvoldoende te markeren.

Toen ik Claude gebruikte om contractdata te extraheren, gaf ik in feite een briljante medewerker een document en zei "vul alle velden in." En zoals elke briljante medewerker die is getraind om nooit "ik weet het niet" te zeggen, vulde het elk veld in. Zelfverzekerd. Inclusief de velden waar het juiste antwoord was "dit document specificeert dit niet duidelijk."

Dat is de kloof. Intelligentie zonder eerlijkheid. Capaciteit zonder kalibratie.

De drie regels die ik ga delen maken de AI niet slimmer. Ze maken het eerlijk. En eerlijk, zo blijkt, is veel meer waard dan slim wanneer je productiesystemen bouwt.

Regel 1: Forceer lege antwoorden bij onzekerheid

Dit is de regel die alles voor me veranderde. Het is zo simpel dat het bijna voelt als valsspelen.

De instructie: Vertel de AI om een veld leeg te laten als de data dubbelzinnig, ontbrekend of tegenstrijdig is — en eis een uitleg van één zin waarom het leeg is gelaten.

Hier is de exacte promptstructuur die ik gebruik voor extractie van contractdata:

Extract the following fields from this document.

CRITICAL RULE: If any field's value is ambiguous, missing,
or if conflicting information exists in the document, leave
the field BLANK. Do not guess. Do not infer. Do not fill in
a "most likely" answer.

For every blank field, provide a one-sentence explanation of
why it was left blank.

Your job is to extract only what the document explicitly states.
If a value cannot be determined with certainty from the source
text, it must remain empty.

Fields to extract:
- Vendor name
- Payment terms
- Contract start date
- Contract end date
- Total contract value
- Renewal clause (auto-renew / manual / none)
- Governing law jurisdiction
...

De magie zit in wat er daarna gebeurt. In plaats van een volledig ingevulde extractie te krijgen met verborgen fouten willekeurig verspreid over 50 velden, krijg ik zoiets:

Vendor name: Meridian Supply Co.
Payment terms: [BLANK]
  → Two different payment terms found: "net 30" on page 8
    (Section 4.2) and "net 45" on page 14 (Amendment A,
    dated March 2024).
Contract start date: January 15, 2024
Contract end date: January 14, 2026
Total contract value: $847,500
Renewal clause: [BLANK]
  → Section 9.1 references "automatic renewal" but
    Amendment A, Section 3 states "renewal subject to
    mutual written agreement." These conflict.
Governing law jurisdiction: State of Delaware

Kijk wat er net is gebeurd. Het probleem met de betalingsvoorwaarden dat me een klant kostte? De AI ving het op. Niet omdat het slimmer werd — maar omdat ik het toestemming gaf om te zeggen "ik vond een conflict en ik ga geen partij kiezen."

Waarom dit psychologisch werkt

Deze regel werkt omdat het fundamenteel de taak van de AI verandert. Zonder de regel is de impliciete instructie van het model: "vul elk veld in." Dat is een voltooiingstaak. Het model is geoptimaliseerd voor voltooiing. Lege velden voelen als falen voor een op voltooiing gericht systeem.

Met de regel verschuift de taak naar: "vul in waar je zeker van bent, en markeer al het andere." Dat is een classificatietaak — zeker versus onzeker. Modellen zijn aanzienlijk beter in binaire classificatie dan in het genereren van accurate antwoorden uit dubbelzinnige invoer.

Ik vraag het model niet om slimmer te zijn. Ik vraag het om een andere, makkelijkere taak te doen.

De uitleg van één zin is niet onderhandelbaar

In het begin probeerde ik de regel zonder de uitleg te vereisen. Het model liet velden leeg, maar ik had geen idee waarom. Ontbraken de gegevens echt? Was er een conflict? Kon het model het gewoon niet vinden?

De uitlegvereiste lost dit volledig op. "Twee verschillende betalingsvoorwaarden gevonden op pagina's 8 en 14" vertelt me precies wat er is gebeurd en waar ik moet kijken. Ik kan de dubbelzinnigheid in 30 seconden oplossen door die twee pagina's zelf te lezen. Vergelijk dat met het opnieuw lezen van het hele 22 pagina's tellende contract om te achterhalen waarom een veld leeg is.

De uitleg fungeert ook als een grounding-mechanisme. Wanneer het model moet verwoorden waarom het onzeker is, wordt het gedwongen om specifiek bewijs (of het ontbreken van bewijs) in het brondocument te refereren. Dit voorkomt een faalmodus die ik vroeg zag, waarbij het model dingen leeg liet niet omdat de data echt dubbelzinnig was, maar omdat het te voorzichtig was. De uitlegvereiste creëert een natuurlijke kalibratie — het model moet zijn onzekerheid rechtvaardigen, wat de onzekerheid betekenisvol maakt.

Resultaten in de praktijk

Ik draai deze regel al vijf maanden in contractreview-workflows. Het patroon is consistent: in plaats van een schoon ogende extractie te krijgen met 2-4 verborgen fouten begraven in 50+ velden, krijg ik een extractie met 3-7 lege velden die duidelijk zijn gemarkeerd voor menselijke review.

De tijdsbesparing stapelt snel op. Vóór deze regel was mijn reviewproces: controleer elk veld tegen het brondocument. Dat kostte 25-35 minuten per contract. Nu is mijn reviewproces: scan de ingevulde velden op voor de hand liggende problemen, besteed dan gerichte tijd aan de lege velden. Dat kost 8-12 minuten. Dezelfde nauwkeurigheid. Minder dan de helft van de tijd.

Maar hier wordt het nog interessanter — de regel verbeterde ook de nauwkeurigheid van de niet-lege velden. Wanneer het model weet dat het onzekere velden mag overslaan, stopt het met het forceren van dubbelzinnige data in schone antwoorden. De velden die het wel invult, zijn doorgaans echt schoon.

Regel 2: Verander de incentive — Maak foute antwoorden duur

Regel 1 geeft de AI toestemming om dingen leeg te laten. Regel 2 geeft het een reden om leeg boven fout te verkiezen.

De instructie: Vertel de AI expliciet dat een fout antwoord drie keer meer kost dan een leeg antwoord.

Zo formuleer ik het:

Scoring for this task:
- A correct extraction: +1 point
- A blank field with explanation: 0 points
- An incorrect extraction: -3 points

Your goal is to maximize your total score. A wrong answer is
three times worse than leaving a field blank. When in doubt,
leave it blank.

Dit lijkt bijna te simpel om te werken. Het is een regel tekst in een prompt. Het model wordt niet echt gescoord. Er is hier geen reinforcement learning loop. Dus waarom verandert het het gedrag?

De gedragsverandering is echt

Omdat taalmodellen het concept van incentivestructuren hebben geïnternaliseerd uit hun trainingsdata. Ze hebben miljoenen voorbeelden gezien van hoe mensen zich gedragen wanneer straffen asymmetrisch zijn — verzekeringspolissen, medische diagnoses, juridische documenten, kwaliteitsborgingsprocessen. Wanneer je de taak kadert met expliciete kosten voor fouten, activeert het model patronen die geassocieerd worden met risicovolle, strafmijdende besluitvorming.

Denk er zo over na. Als je een nieuwe aannemer inhuurt en zegt "vul dit spreadsheet in — ik heb elk veld nodig," zullen ze elk veld invullen. Sommige antwoorden zijn gokjes. Ze willen competent overkomen. Ze willen grondig lijken.

Stel je nu voor dat je diezelfde aannemer vertelt: "Vul in waar je zeker van bent. Laat de rest leeg en vertel me waarom. Oh, en nog iets — als ik een fout antwoord vind, telt dat drie keer zo zwaar tegen je als een leeg veld."

Ander gedrag. Onmiddellijk. Niet omdat de aannemer vaardiger werd. Maar omdat de incentivestructuur verschoof van "voltooiing belonen" naar "fouten bestraffen."

Dat is precies wat er met het model gebeurt. De -3 strafformulering triggert conservatieve, verificatiegerichte gedragspatronen. Het model wordt merkbaar voorzichtiger met grensgevallen en dubbelzinnige data.

Hoe ik deze regel ontdekte

Ik heb dit concept niet uitgevonden — ik heb het aangepast van hoe ik junior developers onboard voor klantprojecten.

Wanneer een nieuwe developer bij een van mijn projecten komt, vertel ik ze altijd hetzelfde tijdens de eerste week: "Als je niet zeker bent over een vereiste, vraag het. Gok niet en bouw het verkeerde. Verkeerde code afbreken kost het team drie keer meer dan de vertraging van een vraag stellen." Elke ervaren engineering lead zegt een versie hiervan. Het werkt bij mensen omdat het "ik weet het niet" herformuleert van een teken van incompetentie naar een teken van professionaliteit.

Het werkt bij LLM's om dezelfde reden. OpenAI's eigen onderzoek naar waarom modellen hallucineren wijst op precies deze dynamiek — huidige training stimuleert zelfverzekerd gokken boven eerlijke onzekerheid. De -3 strafprompt is een grove maar effectieve manier om die incentive om te keren tijdens inference, zonder de modelgewichten aan te raken.

Onderzoekers van de University of Maryland formaliseerden dit eind 2025 met een techniek die ze "Reinforced Hesitation" noemden — een trainingsmethode met ternaire beloningen (+1 correct, 0 onthouding, -lambda voor fouten). De bevinding? Modellen getraind met asymmetrische straffen produceerden onderscheidend gedrag langs wat ze een "Pareto-frontier" noemden — elk strafniveau leverde het optimale model op voor zijn risicoregime. Mijn promptbenadering is niet zo rigoureus als hertrainen, maar het duwt in dezelfde gedragsrichting op promptniveau.

Regel 1 en Regel 2 combineren

Regels 1 en 2 zijn ontworpen om gestapeld te worden. Regel 1 geeft het model toestemming om velden leeg te laten. Regel 2 geeft het motivatie om leeg boven fout te verkiezen.

Zonder Regel 1 heeft het model geen lege optie — het probeert alles te beantwoorden. Zonder Regel 2 heeft het model de optie om leeg te gaan, maar geen sterke reden om het te gebruiken. Samen creëren ze een systeem waarin het model actief eerlijke onzekerheid verkiest boven zelfverzekerd gokken.

In de praktijk merkte ik dat Regel 1 alleen extractiefouten met ongeveer 60% verminderde in mijn contractworkflows. Het toevoegen van Regel 2 duwde dat naar ongeveer 80%. De resterende fouten zijn doorgaans echt lastig — gevallen waarin de documenttaal duidelijk is maar misleidend, of waarbij domeinkennis nodig is om het probleem te herkennen. Die hebben nog steeds menselijke review nodig. Maar 80% foutreductie door twee regels in een prompt? Dat is een enorme winst.

De volgende regel behandelt de resterende randgevallen — en het is degene die dit van een leuke prompttruc in een productierijp auditsysteem verandert.

Regel 3: Bronvermelding — Het auditspoor dat alles verandert

Regels 1 en 2 behandelen de "moet ik antwoorden?"-beslissing. Regel 3 behandelt de "hoe kwam ik aan dit antwoord?"-vraag.

De instructie: Voeg voor elke geëxtraheerde waarde een kolom toe die aangeeft of de waarde "extracted" (direct vermeld in het document) of "inferred" (afgeleid uit context, berekening of interpretatie) is. Indien inferred, eis een uitleg van één zin over wat werd afgeleid en waaruit.

Hier is de prompttoevoeging:

For each field, include a "Source" column with one of two values:

EXTRACTED — The value appears verbatim or near-verbatim in the
source document. Include the page/section reference.

INFERRED — The value was derived from context, calculation, or
interpretation rather than directly stated. Include a one-sentence
explanation of what was inferred and the evidence used.

Examples:
- Total value: $847,500 | EXTRACTED | Page 3, Section 2.1
- Annual value: $423,750 | INFERRED | Calculated as total value
  ($847,500) divided by contract duration (2 years)
- Auto-renewal: Yes | INFERRED | Section 9.1 states "this agreement
  shall continue in effect unless terminated" — interpreted as
  auto-renewal language

Waarom het onderscheid Extracted/Inferred ertoe doet

Dit is de regel die het systeem controleerbaar maakt. En controleerbaarheid is wat een "leuke AI-truc" scheidt van iets waar je in een bedrijf daadwerkelijk op kunt vertrouwen.

Wanneer elk veld is getagd met zijn brontype, wordt je reviewworkflow chirurgisch. Zo ziet mijn daadwerkelijke reviewproces er nu uit met alle drie de regels actief:

Stap 1: Scan de EXTRACTED velden. Deze kwamen direct uit het document met paginaverwijzingen. Ik controleer steekproefsgewijs misschien 10-15% ervan. Fouten hier zijn zeldzaam — het model is goed in woordelijke extractie wanneer het niet wordt gevraagd om te interpreteren.

Stap 2: Review elk INFERRED veld. Dit zijn de velden waar het model een beoordeling heeft gemaakt. De uitleg vertelt me exact welke logica het gebruikte, zodat ik snel kan valideren of de afleiding redelijk is. Kost 2-3 minuten voor een typisch contract.

Stap 3: Review elk BLANK veld. Dit zijn de velden die het model heeft overgeslagen. De uitleg vertelt me wat dubbelzinnig of ontbrekend is, zodat ik precies weet waar ik in het brondocument moet kijken. Kost nog eens 2-3 minuten.

Stap 4: Klaar. Totale reviewtijd: 8-12 minuten voor een contract dat voorheen 30+ minuten regel-voor-regel verificatie kostte.

Het kernpunt: in plaats van alles te reviewen, review ik alleen lege velden en afleidingen. De EXTRACTED velden met paginaverwijzingen zijn verifieerbaar maar laag risico. Het systeem sorteert zichzelf in vertrouwensniveaus, en mijn aandacht gaat naar waar het het meest uitmaakt.

Het verborgen voordeel: "Correct maar afgeleid" antwoorden opvangen

Vóór Regel 3 had ik een blinde vlek waarvan ik niet eens wist. Het model gaf me soms het juiste antwoord — maar om de verkeerde reden. Het "extraheerde" een contractwaarde die eigenlijk was berekend uit regelitems, of het "extraheerde" een jurisdictie die eigenlijk was afgeleid uit het geregistreerde adres van het bedrijf.

Deze antwoorden leken correct. Ze waren vaak correct. Maar ze waren fragiel. Als de onderliggende aanname veranderde — andere regelitemstructuur, bedrijf geregistreerd in een andere staat dan het operationele adres — zou de afleiding stilletjes falen.

De INFERRED-tag brengt deze gevallen aan het licht. Wanneer ik zie "INFERRED: Berekend uit regelitems op pagina's 4-6," weet ik dat ik de berekening moet verifiëren. Wanneer ik zie "INFERRED: Jurisdictie aangenomen op basis van bedrijfsregistratieadres in Delaware," weet ik dat ik moet controleren of het contract expliciet toepasselijk recht specificeert.

Dit is het verschil tussen een extractie die vandaag klopt en een extractieproces dat in de loop van de tijd betrouwbaar klopt.

Een complete prompt met alle drie de regels

Hier is het volledige prompttemplate dat ik gebruik voor extractie van contractdata. Ik heb dit vijf maanden lang verfijnd over tientallen contracten:

You are extracting structured data from a legal document.
Follow these rules exactly:

RULE 1 — BLANK WHEN UNCERTAIN
If any field's value is ambiguous, missing, or if conflicting
information exists in the document, leave the field BLANK.
Provide a one-sentence explanation of why it was left blank.

RULE 2 — ERROR PENALTY
Scoring: Correct = +1, Blank with explanation = 0, Wrong = -3.
A wrong answer is three times worse than a blank. When in doubt,
leave it blank.

RULE 3 — SOURCE ATTRIBUTION
For each completed field, mark it as:
- EXTRACTED (value appears verbatim; cite page/section)
- INFERRED (value derived from context; explain the inference)

OUTPUT FORMAT:
| Field | Value | Source | Notes |
|-------|-------|--------|-------|
| Vendor | [value or BLANK] | EXTRACTED/INFERRED | [page ref or explanation] |

DOCUMENT:
[paste document here]

FIELDS TO EXTRACT:
1. Vendor legal name
2. Payment terms
3. Contract effective date
4. Contract end date
5. Total contract value
6. Currency
7. Renewal type (auto/manual/none)
8. Termination notice period
9. Governing law jurisdiction
10. Liability cap

Dat is het hele systeem. Geen fine-tuning. Geen vectordatabases. Geen aangepaste modeltraining. Drie regels in een prompt die fundamenteel veranderen hoe de AI de extractietaak benadert.

Voorbij contracten: Waar deze regels echt schitteren

Ik begon met contracten omdat de fout met betalingsvoorwaarden me daar had gebrand. Maar deze drie regels zijn van toepassing op elke workflow waarin AI gestructureerde informatie extraheert of samenvat uit ongestructureerde bronnen. Ik heb ze in vier andere gebruiksscenario's ingezet, en de resultaten zijn consistent.

Actiepunten uit vergadertranscripten

Vergadertranscripten zijn een mijnenveld voor AI-extractie. Mensen zeggen tegenstrijdige dingen. Ze wijzen taken mondeling toe en wijzen ze vijf minuten later opnieuw toe. Ze refereren informeel aan deadlines — "laten we proberen dat voor het einde van de week af te hebben" — wat vrijdag kan betekenen, of "wanneer dan ook."

Zonder mijn drie regels genereerde de AI een nette actiepuntenlijst met specifieke eigenaren en datums voor alles. Zag er geweldig uit. Was vaak fout over wie wat echt bezat en wanneer dingen af moesten zijn.

Met de regels toegepast:

Action item: Migrate staging database to new cluster
Owner: Sarah Chen | EXTRACTED | Timestamp 14:32 — "Sarah,
  can you handle the staging migration?"
Deadline: [BLANK]
  → No specific deadline stated. Jake mentioned "before the
    next sprint" at 22:15, but no date was confirmed.
Priority: High | INFERRED | Based on discussion context —
  team discussed this as blocking the release pipeline

De lege deadline is hier het juiste antwoord. Een verzonnen "vrijdag" of "einde van sprint" zou een valse verwachting creëren waar niemand daadwerkelijk mee akkoord ging.

Factuurverwerking

Factuurextractie deelt dezelfde faalmodi als contracten — leveranciersnamen die niet helemaal overeenkomen met inkooporderrecords, belastingberekeningen die verifieerbaar zouden moeten zijn, betalingsvoorwaarden die verwijzen naar een raamovereenkomst in plaats van ze direct te vermelden.

De INFERRED-tag vangt iets specifieks in factuurworkflows: berekende velden. Wanneer de AI een subtotaal en een totaal extraheert, kan het verifiëren of de belastingberekening intern consistent is. Wanneer het de cijfers niet kan afstemmen, markeert het dit:

Subtotal: $14,250.00 | EXTRACTED | Line items total, page 1
Tax (8.25%): $1,175.63 | EXTRACTED | Page 1, tax line
Total: $15,450.00 | EXTRACTED | Page 1, total line
Verification: [BLANK]
  → Calculated total ($14,250 + $1,175.63 = $15,425.63) does
    not match stated total ($15,450.00). Discrepancy of $24.37.

Die discrepantie van $24,37 zou door een standaard extractie zijn geglipt. Het drieregelsysteem ving het op omdat Regel 3 het model dwong zijn rekenwerk te laten zien, en de berekening klopte niet.

Juridische documentreview

Juridische documenten zijn waar de INFERRED-tag het meest dramatisch zijn waarde bewijst. Juridische taal zit vol implicaties, kruisverwijzingen en gedefinieerde termen die iets anders betekenen dan hun gewone betekenis. "Redelijke inspanningen" heeft een ander juridisch gewicht dan "beste inspanningen." "Materiële nadelige verandering" is een gedefinieerde term in de meeste M&A-overeenkomsten, maar de definitie verschilt per contract.

Wanneer de AI iets als INFERRED markeert in een juridische context, markeert het precies de velden waar een jurist naar moet kijken. De extractie behandelt het eenvoudige werk — namen, datums, bedragen — terwijl het expliciet de interpretatieve velden tagt voor expertreview.

CRM-gegevensinvoer en leveranciersbeoordeling

CRM-data uit e-mails, formulieren en vergadernotities is notoir rommelig. Een prospect zegt "ongeveer 200 medewerkers" — is dat 200? Is het 150-250? De taak van de AI is om de data op te halen; mijn drie regels zorgen ervoor dat het niet stilletjes afrondt naar een precies getal dat nooit is genoemd.

Company size: ~200 | INFERRED | Contact stated "around 200"
  in email dated March 3 — exact figure not confirmed
Annual revenue: [BLANK]
  → Revenue not disclosed. Contact mentioned "eight-figure
    range" in call notes but declined to specify.

Die tilde en dat lege veld zijn eerlijk. Een CRM gevuld met verzonnen precisie is erger dan een met eerlijke leemtes, omdat verzonnen data wordt gebruikt voor segmentatie, scoring en forecasting — en de fouten stroomafwaarts cumuleren.

Als je AI-gedreven workflows bouwt voor contractreview, data-extractie, of een van deze gebruiksscenario's, en je wilt liever dat iemand het volledige promptsysteem opzet en in je pipeline integreert, ik neem dit soort projecten aan op Fiverr.

Wat deze regels niet oplossen (en wat je eraan kunt doen)

Ik wil eerlijk zijn over de beperkingen, want te veel beloven is precies het soort probleem waar dit hele artikel over gaat.

Kennislacunes in het domein

De drie regels helpen bij dubbelzinnigheid en ontbrekende data. Ze helpen niet wanneer het model de domeinkennis mist om te herkennen dat iets fout is. Als een contract zegt "betalingsvoorwaarden: net 30 vanaf factuurdatum" en de industriestandaard voor die leverancierscategorie is net 60, zal het model vrolijk "net 30" extraheren en het als EXTRACTED markeren. Het zal het niet als ongebruikelijk markeren omdat het niet weet wat gebruikelijk is.

Voor domeinspecifieke validatie heb je nog steeds een menselijke expert of een referentiedataset nodig die het model kan raadplegen. De drie regels maken het werk van de mens sneller, maar ze elimineren de mens niet.

Opzettelijk misleidende documenten

Als een document is ontworpen om te misleiden — tegenstrijdige voorwaarden verbergen in bijlagen, gedefinieerde termen gebruiken die de gewone betekenis overschrijven — zal het model het misschien niet opvangen, zelfs met deze regels. De regels helpen bij onopzettelijke dubbelzinnigheid (wat 90%+ van de extractiefouten in de echte wereld is). Ze helpen niet bij opzettelijke verdoezeling.

Het resterende foutpercentage van 2-3%

Zelfs met alle drie de regels actief, zie ik nog een klein resterend foutpercentage — ruwweg 2-3% van de velden over grote batches. Dit zijn doorgaans gevallen waarin de documenttaal duidelijk en ondubbelzinnig is, maar de AI het anders interpreteert dan een mens zou doen vanwege subtiele context die het mist. Ongebruikelijke datumformaten, branchespecifieke afkortingen, of verwijzingen naar externe documenten die het model niet heeft.

De regels verminderden mijn foutpercentage van ruwweg 12-15% (zonder enige mitigatie) naar 2-3%. Dat is een enorme verbetering. Maar het is niet nul. Plan dienovereenkomstig.

Modelselectie blijft belangrijk

Ik heb deze regels getest met GPT-4o, Claude Sonnet 4, Claude Opus 4 en Gemini 2.0 Pro. Ze werken op allemaal, maar het gedrag is niet identiek. Claude-modellen zijn doorgaans conservatiever met lege velden — ze laten meer velden leeg, zelfs wanneer de data redelijk duidelijk is. GPT-4o is agressiever in het afleiden — het markeert dingen als INFERRED in plaats van BLANK in grensgevallen.

Momenteel gebruik ik Claude Sonnet 4 voor het meeste extractiewerk. Het raakt de sweet spot tussen kosten, snelheid en gepaste voorzichtigheid. Voor contracten met hoge inzet waar ik maximale voorzichtigheid wil, stap ik over naar Opus 4. Als je geïnteresseerd bent in het optimaliseren van je modelselectie voor verschillende taaktypes, heb ik een gedetailleerde gids geschreven over kostengeoptimaliseerde agent-architecturen die precies dit behandelt.

Het grotere plaatje: Waarom dit framework nu belangrijk is

Een multi-model studie uit 2025 vond dat eenvoudige promptgebaseerde mitigatie het hallucination-percentage van GPT-4o terugbracht van 53% naar 23%. Dat is een significante reductie door alleen promptwijzigingen — geen architecturale veranderingen, geen fine-tuning, geen RAG.

Mijn drieregelsysteem gaat verder omdat het het model niet alleen vertelt om "nauwkeuriger te zijn." Het herstructureert de taak zelf. Het model wordt niet gevraagd om harder te proberen. Het wordt gevraagd om een fundamenteel ander soort werk te doen — classificatie (zeker versus onzeker), bronvermelding (extracted versus inferred), en uitleg (waarom is dit leeg gelaten?). Dit zijn taken die LLM's goed aankunnen, wat verklaart waarom de foutpercentages zo dramatisch dalen.

Dit is wat ik denk dat er op een dieper niveau gebeurt. Het standaardgedrag van deze modellen — zelfverzekerd gokken, elk veld invullen, nooit "ik weet het niet" zeggen — komt voort uit hun training. Zoals het Science-artikel over de oorsprong van hallucinations uitlegt, worden LLM's in feite getraind op een examen waarbij blanco antwoorden nul scoren. Gokken is altijd de rationele strategie.

Mijn drie regels creëren een ander examen. Een waarin blanco antwoorden nul scoren (neutraal), maar foute antwoorden -3 scoren (actief slecht). Dat is de asymmetrische straf die de Reinforced Hesitation-onderzoekers aan Maryland ontdekten die het modelgedrag verandert op trainingsniveau. Ik pas dezelfde logica toe op promptniveau, en het werkt — onvolmaakt, minder rigoureus, maar praktisch en direct.

Het opwindende deel? Anthropic, OpenAI en Google doen allemaal actief onderzoek naar kalibratiegewaarde training — het inbouwen van het equivalent van deze regels direct in modelgewichten. Maar dat is een meerjarig onderzoeksprogramma. Mijn drie regels werken vandaag, in productie, nu meteen.

En eerlijk gezegd, zelfs wanneer modellen beter worden in zelfkalibratie van nature, zal ik waarschijnlijk expliciete promptregels blijven gebruiken. Riem en bretels. De kosten van een incorrecte extractie in een bedrijfscontext — een factuur betaald op het verkeerde bedrag, een contractvoorwaarde gemist, een complianceveld niet aangevinkt — zijn altijd hoger dan de kosten van iets te voorzichtig zijn.

Hoe je dit morgen in je workflow implementeert

Als je zo ver bent gekomen, begrijp je het framework al. Hier is het praktische implementatiepad dat ik zou volgen als ik vandaag vanaf nul zou beginnen.

Stap 1: Kies één extractieworkflow

Probeer niet alles tegelijk te vernieuwen. Kies de workflow waar incorrecte AI-uitvoer de meeste pijn heeft veroorzaakt. Voor de meesten is dat een van: contractreview, factuurverwerking, vergaderactiepunten of CRM-gegevensinvoer.

Stap 2: Schrijf je prompttemplate

Begin met mijn contracttemplate hierboven en pas het aan voor jouw gebruiksscenario. De drie regels blijven hetzelfde — leeg bij onzekerheid, -3 straf voor fouten, extracted/inferred bronvermelding. Wat verandert is de veldenlijst en het uitvoerformaat.

Stap 3: Draai 10 documenten met en zonder de regels

Zo heb ik de aanpak gevalideerd. Ik draaide 10 contracten door standaard extractie (zonder regels) en 10 door het drieregelsysteem, en verifieerde daarna elk veld handmatig. De standaard extractie had 14 fouten over 10 documenten. De drieregel-extractie had er 3 — en alle drie vielen in de restcategorie (duidelijke taal, subtiele misinterpretatie).

Stap 4: Kalibreer de drempelwaarde voor lege velden

Verschillende modellen hebben verschillende gevoeligheden voor lege velden. Als je model te veel velden leeg laat (meer dan 20% bij schone documenten), moet je de taal misschien iets verzachten: "Laat alleen leeg wanneer je oprecht de waarde niet met redelijk vertrouwen kunt bepalen." Als het nog steeds te agressief gokt, verscherp het dan: "Bij ook maar de geringste twijfel, verkies leeg boven een gok."

Stap 5: Bouw de reviewworkflow rond de uitvoer

Het hele punt van deze regels is om te veranderen hoe je AI-uitvoer reviewt. Train je team (of jezelf) om de drielaagse review te volgen: steekproef EXTRACTED, review alle INFERRED, onderzoek alle BLANK. Zodra deze workflow een gewoonte wordt, zijn de tijdsbesparingen permanent.

Pro-tip: Versiebeheer je prompts

Ik bewaar elk prompttemplate in een versiebeheerd markdown-bestand. Wanneer ik de formulering aanpas — de gevoeligheid voor lege velden bijstellen, nieuwe velden toevoegen, het uitvoerformaat wijzigen — commit ik de wijziging met een notitie waarom. Over drie maanden, wanneer je je afvraagt waarom je "dubbelzinnig" hebt veranderd in "onduidelijk" in de leegregel, zul je jezelf dankbaar zijn.

De vraag die niemand stelt totdat het te laat is

Ik besteedde het eerste jaar van werken met AI aan een fundamenteel foutieve aanname: dat nauwkeurigheid de metric was die ertoe deed. Zorg dat het model meer correcte antwoorden produceert. Fine-tune voor precisie. Optimaliseer voor het juiste antwoord.

Dat contractincident leerde me dat de echte metric niet nauwkeurigheid is. Het is betrouwbaarheid. Een systeem dat 98% nauwkeurig is maar je geen manier geeft om de 2% die fout is te identificeren, is minder nuttig dan een systeem dat 95% nauwkeurig is maar elke onzekere uitvoer duidelijk markeert.

Mijn drie regels maken AI niet nauwkeuriger (hoewel ze dat als neveneffect wel doen). Ze maken AI betrouwbaarder. Ze creëren een systeem waarin je precies weet waar het model zeker van is, wat het heeft afgeleid, en wat het niet kon bepalen. Die transparantie verandert AI van een black box die je volledig moet verifiëren in een medewerker wiens werk je efficiënt kunt auditen.

De vraag waarmee ik je achterlaat: op dit moment, vandaag, in welke AI-workflow je ook draait — weet je welke uitvoer je model zeker van is en welke het heeft gegokt?

Want als je het verschil niet kunt zien, zit je in dezelfde positie als ik vóór dat contract ontplofte. Je hebt alleen je verkeerde betalingsvoorwaarden nog niet gevonden.

Veelgestelde vragen

Werken deze promptregels met alle AI-modellen?

Ja — ik heb ze getest met GPT-4o, Claude Sonnet 4, Claude Opus 4 en Gemini 2.0 Pro met consistente resultaten. Claude-modellen neigen naar conservatiever leeg laten, terwijl GPT-4o agressiever afleidt. Pas de drempelwaarde voor lege velden aan om te kalibreren voor je voorkeursmodel.

Hoeveel verminderen deze regels AI hallucination bij data-extractie?

In mijn contractreview-workflows verminderde het drieregelsysteem extractiefouten van ruwweg 12-15% naar 2-3% — ongeveer 80% foutreductie. Een multi-model studie uit 2025 vond dat promptgebaseerde mitigatie alleen het hallucination-percentage van GPT-4o terugbracht van 53% naar 23%. Resultaten variëren per documentcomplexiteit en modelkeuze.

Kan ik deze regels gebruiken voor taken buiten documentextractie?

Het framework is van toepassing op elke workflow waarin AI ongestructureerde invoer verwerkt tot gestructureerde uitvoer — vergadertranscripten, factuurverwerking, CRM-gegevensinvoer, juridische review en leveranciersbeoordeling. De drie regels (leeg bij onzekerheid, foutstraf, bronvermelding) vertalen direct. Pas de veldenlijst en het uitvoerformaat aan voor jouw gebruiksscenario.

Beïnvloedt de -3 strafscoring het gedrag van AI-modellen daadwerkelijk?

Dat doet het, meetbaar. Taalmodellen hebben incentivestructuren geïnternaliseerd uit trainingsdata. Het kaderen van asymmetrische kosten in de prompt triggert conservatieve, verificatiegerichte gedragspatronen. Onderzoekers van de University of Maryland formaliseerden dit concept als "Reinforced Hesitation" eind 2025, en bevestigden dat asymmetrische straffen het modelgedrag verschuiven langs een risico-nauwkeurigheidsgrens.

Hoe lang duurt het om AI-uitvoer te reviewen met deze drie regels?

Mijn contractreviewtijd daalde van 25-35 minuten (elk veld controleren) naar 8-12 minuten (steekproefsgewijs extracted velden controleren, inferred en lege velden reviewen). De drielaagse reviewworkflow — scan extracted, verifieer inferred, onderzoek blank — elimineert de noodzaak om brondocumenten regel voor regel opnieuw te lezen.

Laten we samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je tech-infrastructuur opschalen? Ik help graag.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io