AI-uitvoer controleren: meer dan een overtuigend antwoord

Een overtuigend AI-antwoord kan weinig houvast geven voor een echte productbeslissing. Een werkgever ziet bijvoorbeeld een score bij een vacature, maar weet daarmee nog niet welke formulering aandacht vraagt. AI-uitvoer controleren begint voor mij daarom met de vraag wat iemand met het antwoord moet kunnen doen. De vorm van de functie bepaalt hoeveel ruimte er voor beoordeling overblijft.

In mijn recente werk aan Onbeperkt aan de Slag heb ik vacaturefeedback concreter gemaakt met afzonderlijke criteria, uitleg en een berekening in de applicatie. Eerder werkte ik met AI-ondersteuning aan toegangsrechten voor Trustbird. Die voorbeelden gaan over verschillende producten, maar stellen dezelfde ontwikkelvraag: welk gedrag kunnen we vast controleren en waar blijft een menselijke afweging nodig?

AI-uitvoer controleren vraagt om zichtbare criteria

Een concrete aanleiding was de vraag van Provincie Zuid-Holland hoe provincievacatures konden worden gematcht met de achterban van Onbeperkt aan de Slag. In de samenwerking met de provincie en Startup in Residence Intergov kregen AI-matching, privacy by design en vacaturefeedback een plek. De feedbacktool ondersteunt werkgevers bij het bekijken van hun vacaturetekst: welke eisen zijn nodig en welke formuleringen kunnen belemmerend zijn?

Een algemene score vertelt een werkgever weinig over een mogelijke aanpassing. Ook is moeilijk te beoordelen of een veranderde score samenhangt met een relevante verbetering of met een andere modelbeoordeling. Voor vacaturefeedback is daarom meer nodig dan een eindcijfer. Het moet duidelijk worden welk onderdeel wordt beoordeeld en waarom het model daar aandacht voor vraagt.

Bij Onbeperkt aan de Slag heb ik de beoordeling opgedeeld in zes onderdelen: uren, flexibiliteit, taal, opleiding, werkzaamheden en arbeidsvoorwaarden. Per onderdeel moet het model een afweging met uitleg geven. Een werkgever kan zo bekijken waarom een taaleis beperkend wordt genoemd en vervolgens beoordelen of die eis voor de concrete werkzaamheden noodzakelijk is.

Die indeling maakt het gesprek over een vacature gerichter. Het model kan wijzen op een mogelijke belemmering, terwijl de werkgever de functiecontext kent. Een voorgestelde aanpassing blijft daarmee iets om inhoudelijk te beoordelen. Een overtuigend geformuleerde toelichting levert geen zelfstandig bewijs dat een eis overbodig is of dat een andere formulering meer geschikte reacties oplevert.

De applicatie voert de vaste berekening uit

De totaalscore wordt vervolgens door de applicatie berekend. Het model levert de afzonderlijke beoordelingen binnen vastgelegde grenzen aan; de software controleert de structuur en rekent met de geldige waarden. Daardoor is de rekenregel controleerbaar en staat deze los van de manier waarop het model zijn uitleg formuleert.

Dit verschil heeft gevolgen voor de foutafhandeling. Een onvolledig of ongeldig antwoord wordt niet aangevuld met een verzonnen standaardscore. Er ontstaat dan geen nieuwe beoordeling. Dat vraagt onderhoud aan validatie en toegestane antwoorden, en betekent dat een gebruiker soms geen bruikbaar resultaat krijgt. Voor deze toepassing is dat verdedigbaar: een ontbrekende beoordeling is herkenbaar, terwijl een ongefundeerd cijfer gemakkelijk verder wordt gebruikt.

Gelijke invoer hoeft geen nieuwe beoordeling te vragen

De verwerking kijkt ook of de relevante invoer is veranderd. Als de laatste feedback bij dezelfde inhoud en beoordelingsversie hoort, kan die opnieuw worden gebruikt. Dat beperkt onnodige herhaling van dezelfde beoordeling.

Vaste regels helpen waar gegevens voldoende precies zijn

Niet iedere berekening heeft een model nodig. Bij werkervaring kan gewone software periodes samenvoegen en bepalen hoeveel kalendermaanden iemand heeft gewerkt. Overlappende banen mogen daarbij niet dubbel meetellen. Twee gelijktijdige functies leveren immers geen twee keer zoveel verstreken tijd op.

Zijn de datums onvoldoende precies, dan blijft het totaal onbekend. Een jaartal zonder maand ondersteunt geen nauwkeurige berekening van kalendermaanden. De uitkomst ziet er daardoor soms minder compleet uit, maar volgt wel wat de gegevens toelaten. Voor een product is dat een belangrijke keuze: onbekend moet een bruikbare toestand zijn die de interface kan uitleggen.

Een vaste berekening maakt het modeloordeel overigens niet vanzelf juist. De optelsom kan correct zijn terwijl een onderliggende beoordeling context mist. Daarom houd ik onderscheid tussen de controle op de vorm, de controle op de berekening en de beoordeling van de inhoud. Ieder onderdeel vraagt om passend bewijs.

Ook geweigerde handelingen horen bij de kwaliteit

In juli werkte ik met Cursor als ontwikkelassistent aan de toegangslaag voor Trustbird. Daarbij zijn controles op rollen en rechten aangescherpt. Een toekenning mocht gegevens uit verschillende werkruimtes niet combineren. Onbekende rechten moesten expliciet worden geweigerd, zodat een ongeldige opdracht herkenbaar mislukt.

De tests onderzoeken daarom ook verkeerde combinaties en herhaalde toekenningen. Dat is relevant bij AI-ondersteund ontwikkelen: plausibele code moet nog steeds aantonen dat de afgesproken grenzen standhouden. Alleen de toegestane route controleren laat de vraag open wat een ongeldige opdracht veroorzaakt.

Een controleplan verbindt product en techniek

Voor een productowner helpt het om vooraf af te spreken welk soort zekerheid nodig is. De volgende vier stappen maken die afspraak concreet:

1. Bepaal welke beslissing of handeling de uitvoer moet ondersteunen.
2. Maak zichtbaar welke feiten, criteria en aannames het antwoord gebruikt.
3. Leg vaste regels vast voor berekeningen, toegangsrechten en ongeldige invoer.
4. Test foutpaden en bepaal wie de inhoud beoordeelt voordat er gevolgen zijn.

Zo'n plan voorkomt niet iedere fout. Het helpt wel om bevindingen gericht te behandelen. Een ontbrekend veld vraagt andere aanpassingen dan een rekenfout of een onjuiste inhoudelijke afweging. Zonder dat onderscheid kan iedere tegenvaller aanleiding worden voor een nieuwe prompt, terwijl de oorzaak mogelijk in de verwerking zit.

Controleerbaarheid maakt vervolgwerk bespreekbaar

Als developer en ondernemer zie ik de waarde van AI ook in de mogelijkheid een antwoord te onderzoeken en bewust af te wijzen. Zichtbare criteria, vaste regels en herkenbare onzekerheid geven gebruikers daar ruimte voor. Het product wordt beter bespreekbaar wanneer duidelijk is wat bewezen gedrag is en wat een oordeel blijft.

Wil je AI-uitvoer controleren binnen een bestaande applicatie? Mail me over de functie die je wilt beoordelen. Met een concreet voorbeeld wordt duidelijk welke controles nodig zijn en waar een aanpassing in het product meer oplevert dan een overtuigender antwoord.