Vraagtypes die denken aanscherpen

Wanneer “een vraag” eigenlijk een risico is

Je krijgt een conceptnotitie van een collega en moet snel beoordelen of de redenering klopt. Of je moet in Copilot opties laten verkennen voor een beleidsafweging, maar je wilt géén suggesties die stiekem op aannames leunen. In zulke situaties is het verleidelijk om één brede vraag te stellen (“Wat is het beste advies?”), omdat dat snel voelt en vaak ook een vloeiend antwoord oplevert.

Alleen: in een DNB-context is vlot niet hetzelfde als controleerbaar. Een brede vraag nodigt Copilot uit om gaten te vullen, causaliteit te suggereren, en nuance glad te strijken. En precies daar ontstaat risico: stakeholders lezen vervolgens een tekst die overtuigend klinkt maar onvoldoende herleidbaar is naar input, definities of onzekerheden.

Daarom gaat deze les over vraagtypes: verschillende soorten vragen die je denken aanscherpen en Copilot dwingen om explicieter, toetsbaarder en zorgvuldiger te werken. Je gebruikt vraagtypes als “rails”: je houdt snelheid, maar je voorkomt dat je output onbedoeld gaat drijven.

Wat bedoelen we met vraagtypes (en waarom werken ze)?

Een vraagtype is een herkenbare vorm van vragen stellen met een specifiek denkdoel, zoals: verhelderen, afbakenen, toetsen, falsificeren, vergelijken of structureren. In plaats van “één perfecte prompt” kies je bewust een vraagtype dat past bij je fase: eerst scherp krijgen wát je vraagt, dan pas antwoord laten formuleren.

Het onderliggende principe is simpel: Copilot optimaliseert op plausibiliteit en volledigheid binnen de kaders die jij geeft. Als jouw vraagtype die kaders niet expliciet maakt, vult het model ze impliciet in. Vraagtypes zijn dus niet een taaltruc, maar een manier om je prompt-anatomie (doel, inputkader, rol, outputvorm, checks) te activeren met minder tekst en meer sturing.

Een bruikbare analogie: zie Copilot als een slimme collega die graag helpt, maar die pas zorgvuldig kan zijn als je hem een inspecteerbare opdracht geeft. “Geef advies” is oninspecteerbaar; “zet claims in een tabel met bronpassage en label onzekerheden” is inspecteerbaar. Vraagtypes helpen je precies die inspecteerbaarheid systematisch af te dwingen.

Belangrijk: vraagtypes vervangen geen menselijke verantwoordelijkheid. Ze maken vooral zichtbaar waar je nog moet verifiëren en waar de AI interpretatie toevoegt. Dat ondersteunt kernwaarden als zorgvuldigheid, transparantie en verantwoord handelen—en het maakt de samenwerking tussen archetypes (Offloader, Critical Verifier, AI-Assisted Editor, etc.) veel consistenter.

De belangrijkste vraagtypes die AI-denken scherp zetten

1) Afbakeningsvragen: “Waar gaat dit precies wél en níet over?”

Afbakeningsvragen dwingen je om scope, definities en verboden zones expliciet te maken. Dit is het meest onderschatte vraagtype, omdat het “bureaucratisch” kan voelen. In de praktijk voorkom je ermee dat Copilot generaliseert of stilzwijgend een andere context kiest dan jij bedoelt, zeker bij termen die intern beladen zijn zoals risico, materialiteit of mitigatie.

Goede afbakening gaat verder dan “maak het kort”. Je vraagt bijvoorbeeld om: doelgroep, besluitmoment, tijdshorizon, en gebruik van input (“alleen document X”). Daarmee reduceer je de ruimte voor hallucinaties en onbedoelde aanvulling. Dit sluit direct aan op de bouwsteen Context en inputkaders uit de vorige les: als je geen grenzen trekt, neemt het model ze voor je aan.

Veelvoorkomende valkuil is te vaag afbakenen: “maak een neutrale analyse”. Copilot kan “neutraal” interpreteren als “symmetrisch” en daardoor kunstmatig twee kanten overwaarderen, of juist als “zonder onzekerheden” en dan te stellig schrijven. Een betere afbakening gebruikt concrete regels: “geen externe feiten”, “markeer aannames”, “geen beleidsadvies, alleen opties en criteria”.

Typische misvatting: “Als ik scope beperk, mis ik inzichten.” In werkelijkheid win je betrouwbaarheid: je ontdekt sneller welke inzichten niet uit je input volgen en dus apart gevalideerd moeten worden. Afbakening is daarmee ook een Self-Checker-instrument: het helpt je onderscheiden tussen samenvatten, interpreteren en adviseren.

2) Verhelderingsvragen: “Welke info ontbreekt om dit goed te kunnen beantwoorden?”

Verhelderingsvragen zetten Copilot in als denkpartner die gaten en onduidelijkheden detecteert, zonder ze meteen op te vullen. Je vraagt dus niet om een eindantwoord, maar om: ontbrekende variabelen, ambigue termen, impliciete aannames, en noodzakelijke input. Dit vraagtype is vooral sterk wanneer je bronmateriaal rommelig is (overlegbullets, conceptteksten, e-mails) en je eerst wilt weten wat je níet weet.

Het krachtige effect is dat je Copilot expliciet vraagt om onzekerheden zichtbaar te maken—iets wat het model anders vaak juist wegpoetst om een “mooie” tekst te leveren. Daarmee operationaliseer je de bouwsteen Kwaliteitscriteria en checks: je maakt “open vragen” een vereist outputonderdeel en voorkomt dat je later verrast wordt door ontbrekende randvoorwaarden.

Een best practice is om verheldering te laten structureren als lijst met categorieën: definities, data/bronverwijzing, besluitcriteria, uitzonderingen, en stakeholders. Zo krijg je geen willekeurige vragenlijst, maar een check die past bij professionele besluitvorming. Dit werkt ook goed met archetypes: de Creative Director kan verheldering gebruiken om richting en criteria scherp te krijgen, terwijl de Critical Verifier het gebruikt om bewijsbehoefte expliciet te maken.

Valkuil: verhelderingsvragen per ongeluk laten omslaan in “vul de gaten maar in”. Dat gebeurt wanneer je zinnen toevoegt als “als je iets mist, verzin een plausibele invulling”. In DNB-werk is het meestal beter om aan te sturen op: “als info ontbreekt, noteer het als open punt en geef aan wat het effect is op de conclusie.” Zo houd je transparantie over onzekerheid.

3) Toetsvragen (Self-Check): “Wat in dit antwoord is feit, wat is interpretatie?”

Toetsvragen zijn bedoeld om output controleerbaar te maken door claims te ontleden. In plaats van “is dit goed?”, vraag je om een expliciete scheiding: welke uitspraken komen letterlijk uit input, welke zijn afleidingen, en welke zijn vermoedens. Dit vermindert het grootste AI-risico in kenniswerk: onzichtbare interpretatie verpakt als feit.

Een sterke toetsvraag vraagt om een vaste weergave, zoals: claim → bronpassage → label (onderbouwd/onvoldoende onderbouwd/interpretatie) → onzekerheid. Daarmee dwing je traceerbaarheid af, wat aansluit op de bouwsteen Output-specificatie en traceerbaarheid. Je krijgt niet alleen een oordeel, maar ook een auditspoor dat jij (of een collega) kan nalopen.

Best practice: laat Copilot ook de eigen “toevoegingen” opsommen. Dit sluit aan bij de vorige les waarin werd benadrukt dat een check geen waarheidsgarantie is, maar wel een structuur die menselijke review versnelt. Je maakt de review efficiënter: je leest niet alles opnieuw, je inspecteert vooral de labels “onvoldoende onderbouwd” en “toegevoegd/afgeleid”.

Misvatting: “Als Copilot zegt dat iets onderbouwd is, dan is het zo.” Binnen een bronkader betekent “onderbouwd” alleen: “er staat iets in de aangeleverde tekst dat erop lijkt.” Laat daarom bij toetsvragen altijd specificeren waar het staat (citaat/fragment) en vraag om terughoudende formuleringen bij causaliteit (“kan wijzen op”, “voor zover uit de tekst blijkt”). Valkuil is ook dat je te veel checkcriteria tegelijk opstapelt; kies er 3–5 die passen bij de situatie (consistentie, scope, aannames, bronverankering, onzekerheid).

4) Tegenvraag- en falsificatievragen: “Welke redenering zou dit onderuit halen?”

Falsificatievragen zijn een vorm van kritisch denken waarbij je niet zoekt naar bevestiging, maar naar mogelijke weerlegging. Je vraagt Copilot om tegenargumenten, failure modes, alternatieve verklaringen, en randgevallen. Dit is bijzonder effectief tegen “AI-zelfvertrouwen”: overtuigende teksten die één lijn mooi rond maken.

Het doel is niet om alles kapot te relativeren. Het doel is om je besluitvorming robuuster te maken door te testen waar de redenering kwetsbaar is. Dit sluit aan bij de rol Critical Verifier uit de vorige les: je laat Copilot handelen als kwaliteitsbewaker die inconsistenties en gaten zichtbaar maakt voordat ze reputatie- of besluitrisico worden.

Best practice: falsificatievragen koppelen aan een concrete claim of conclusie en vragen om expliciete voorwaarden. Bijvoorbeeld: “Onder welke aannames klopt deze conclusie wél, en welke aanname is het meest riskant?” Zo krijg je geen losse kritiek, maar een lijst met toetsen: welke aanname moet je valideren, welke data heb je nodig, en welke formulering moet voorzichtiger.

Valkuil: Copilot laten “winnen” in debatmodus. Dan krijg je retorisch sterke tegenargumenten die niet relevant zijn voor jouw bronkader. Beperk daarom ook hier de context: “baseer tegenargumenten op inconsistenties in de tekst” of “verzin geen externe feiten; formuleer het als risico’s en open vragen.” Zo blijft de falsificatie toetsbaar en passend bij zorgvuldige communicatie.

5) Vergelijkings- en trade-offvragen: “Welke opties zijn er, en op welke criteria verschillen ze?”

Vergelijkingsvragen sturen Copilot naar gestructureerd divergent denken zonder direct te convergeren naar één “beste” antwoord. Je vraagt om meerdere opties en laat ze langs criteria leggen: effect, risico, afhankelijkheden, uitvoerbaarheid, governance-impact. Dit past sterk bij de archetypes AI Trusteer (opties), Creative Director (richting/criteria) en Power User (herhaalbaar format).

Het belangrijkste mechanisme is dat je Copilot dwingt om criteria expliciet te maken in plaats van impliciet te wegen. Zonder criteria gaat het model vaak “onzichtbaar optimaliseren” voor wat in algemene teksten gangbaar klinkt. Met criteria maak je transparant waarom optie A beter scoort op snelheid maar slechter op controleerbaarheid, of waarom optie B zorgvuldiger is maar meer doorlooptijd vraagt.

Best practice: vraag om een tabel met vaste kolommen en verplicht ook een kolom “onzekerheden/benodigde verificatie”. Daarmee voorkom je dat opties als af advies worden gelezen. Je creëert een beslisdocument dat past bij DNB-waarden: transparant, herleidbaar, en eerlijk over wat nog niet zeker is.

Een typische misvatting is dat vergelijken “objectief” wordt omdat het een tabel is. De tabel maakt vooral de aannames zichtbaar—het blijft jouw taak om criteria te bevestigen en weging te bepalen. Valkuil is ook dat Copilot criteria gaat toevoegen die jouw organisatie niet hanteert; voorkom dat door criteria zelf te geven of te laten afleiden uit jouw input (en die afleiding dan expliciet te laten labelen).

Overzicht: welk vraagtype past bij welk denkdoel?

Dimensie	Afbakeningsvraag	Verhelderingsvraag	Toetsvraag (Self-Check)	Falsificatievraag	Vergelijkingsvraag
Primair doel	Scope en definities vastzetten	Ontbrekende info en ambiguïteit vinden	Feit vs interpretatie scheiden	Kwetsbaarheden en tegenevidence vinden	Opties structureren langs criteria
Beste moment	Helemaal aan het begin	Vóór je laat schrijven of concluderen	Na een conceptoutput	Na een voorlopige redenering	Wanneer je keuzes moet voorbereiden
Typische outputvorm	Regels/constraints + “niet doen”	Lijst open vragen + impact	Claim-tabel + labels + onzekerheden	Aannamekaart + zwakke plekken	Optietabel + trade-offs
Archetypes die het meest profiteren	Offloader, Power User, AI-Assisted Editor	Creative Director, Self-Checker	Self-Checker, Critical Verifier	Critical Verifier, Creative Director	AI Trusteer, Co-creator, Power User
Grootste valkuil	Te vaag (“neutraal”)	Gaten onbewust laten invullen	Labels vertrouwen zonder bronpassage	Debatstijl i.p.v. toetsbaar risico	Criteria laten “meeliften” zonder explicietheid

Twee uitgewerkte voorbeelden in DNB-werk

Voorbeeld 1: Van “schrijf een notitie” naar scherpe afbakening + verheldering (Offloader → Self-Checker)

Stel: je hebt overlegbullets en moet snel een interne notitie opleveren. Als je Copilot vraagt “maak een notitie”, krijg je vaak een logisch verhaal met nette overgangen. Het risico is dat Copilot verbindende zinnen toevoegt die klinken als besluiten (“er is afgesproken dat…”) terwijl het eigenlijk interpretatie is. Dat schaadt herleidbaarheid en kan later discussie geven: wie heeft dit besloten, waar staat het?

Je pakt dit aan met twee vraagtypes achter elkaar. Eerst afbakening: je zet bronkader en outputstructuur vast (alleen bullets gebruiken, geen externe aanvulling, aparte sectie aannames). Daarna verheldering: je vraagt Copilot om te benoemen welke ontbrekende informatie nodig is om de notitie “besluitvast” te maken (bijvoorbeeld: eigenaar, deadline, definitie van termen, uitzonderingen). Zo voorkom je dat ontbrekende context stilzwijgend wordt gereconstrueerd.

In de workflow zie je het effect direct. De Offloader-kant levert tijdswinst door structuur (kernpunten, besluiten, open punten). De Self-Checker-kant reduceert risico door expliciet te maken waar interpretatie binnenkomt (“ik heb afgeleid dat X prioriteit heeft, omdat bullet Y dat suggereert”). Beperking blijft: als de bullets zelf onduidelijk zijn, kan Copilot geen feiten toevoegen; maar je wint juist doordat die onduidelijkheid zichtbaar en bespreekbaar wordt.

Voorbeeld 2: Een stevige claim toetsen en falsificeren vóór redactie (Critical Verifier → AI-Assisted Editor)

Stel: een concepttekst bevat een sterke conclusie (“maatregel X zal het risico substantieel verlagen”). Als je nu alleen vraagt “maak dit professioneler”, gaat de AI-Assisted Editor-stem de claim vaak sterker laten klinken, omdat professioneel schrijven vaak ‘zekerheid’ uitstraalt. Daarmee vergroot je onbedoeld het risico op overclaiming: stijl versterkt inhoud die misschien niet voldoende onderbouwd is.

Je doet daarom eerst een toetsvraag: laat Copilot claims isoleren, bronpassages aanwijzen, en labels geven (onderbouwd/onvoldoende/interpretatie). Daarbovenop zet je een falsificatievraag: “welke aannames moeten waar zijn voor deze conclusie, en welke interne tegenstrijdigheid in de tekst kan dit onderuit halen?” Dit dwingt tot kritische spanning in plaats van gladde coherentie.

Pas daarna schakel je naar redactie: je vraagt de AI-Assisted Editor om uitsluitend de “onvoldoende onderbouwde” zinnen te herschrijven naar voorbehouden taal (“op basis van”, “voor zover”, “dit wijst op”) zonder nieuwe feiten toe te voegen. De opbrengst is dubbel: je tekst wordt strakker én eerlijker over onzekerheid. De beperking is dat Copilot geen externe waarheid kan vaststellen zonder bronnen; maar je hebt wél een traceerbare, professioneel geformuleerde tekst die niet verder claimt dan de input draagt.

Afsluiten: scherp denken is vaak een sequence, geen single prompt

De kern is dat je Copilot beter stuurt door niet één grote vraag, maar een bewuste volgorde van vraagtypes: eerst begrenzen, dan verhelderen, dan toetsen, dan (optioneel) falsificeren, en pas op het eind vergelijken of redigeren. Daarmee houd je snelheid, terwijl je controleerbaarheid en transparantie verhoogt—precies wat je nodig hebt wanneer uitkomsten de kernwaarden van DNB moeten ondersteunen.

Dit sets you up perfectly for Triangulatie & verificatiepatronen [30 minutes].