Accepteer AI-prestatieclaim pas na eigen test

U mag een prestatieclaim over AI niet aanvaarden op basis van een certificaat, modelkaart of leveranciersverklaring alleen. U moet vóór gunning onafhankelijk verifiëren wat het systeem kan en niet kan, daarvoor representatieve validatiedata gebruiken die de leverancier niet kent, en prestaties gedurende de levenscyclus blijven monitoren.

Een analyse van 11 november 2026 van onafhankelijke verificatie van AI-prestatieclaims vóór aanbesteding stelt dat inkooporganisaties AI-systemen niet kunnen accepteren op basis van leveranciersclaims alleen. Het voorbeeld daarvan is de beoordeling van AI-acquisities bij Amerikaanse federale instanties, waarin wordt vastgesteld dat instanties vóór gunning onafhankelijk moeten verifiëren met representatieve validatiedata, drempels moeten stellen, hertests moeten uitvoeren na modelwijzigingen en een weigeringsoptie moeten hebben. In onze inschatting verschuift dit het inkoopvraagstuk fundamenteel: het gaat niet langer alleen om welke leverancier u kiest, maar om hoe u vóór gunning verifieert dat de prestatieclaim in uw eigen context klopt. Dit controleprincipe geldt even hard voor private organisaties als voor de publieke sector.

Waarom een leverancierscertificaat niet volstaat

Leveranciersdocumentatie bevat vaak niet de informatie die u nodig hebt om een claim zelfstandig te beoordelen. Academisch onderzoek naar zelfrapportages voor publieke-sector-AI toont aan dat deze documenten regelmatig de baseline, de testmethode en de context missen. Een getal zonder vergelijkingsbasis is geen bewijs dat het systeem bij u werkt. Daarom bevelen onderzoekers aan zelfrapportages aan te vullen met onafhankelijke audits, sandboxpilots en eigen evaluaties in plaats van op verklaringen alleen te vertrouwen.

De praktische gevolgen zijn duidelijk: een jurist die later een geschil over ondermaatse prestaties moet voeren, kan niet op een certificaat alleen bouwen. U moet meetbare drempels, een hertestplicht na modelwijzigingen en een rollback- of ontbindingsclausule vastleggen in het contract.

Welke fasen moet u in uw inkoopproces inbouwen?

Werk in vier stappen van eigen eisen naar afdwingbare afspraken. Eerst vertaalt u uw functionele vereisten in concrete prestatiedrempels die u kunt meten. Vervolgens vraagt u de leverancier om schriftelijke informatie over dataverwerking, trainingsdatakwaliteit, bekende lacunes, biasrisico's en praktische testresultaten. In de derde fase voert u zelf een verificatie uit met een eigen, afgeschermde validatieset voordat de gunningsbeslissing valt. Dat bewijs moet u kunnen documenteren. Ten slotte legt u contractueel vast hoe u prestaties gedurende de levenscyclus blijft volgen en wat er gebeurt wanneer het systeem afwijkend gedrag vertoont.

Welke risico's moet u voorkomen?

• Onvoldoende baseline — leveranciersclaims zonder referentiepunt waartegen u ze kunt toetsen.
• Eenmalige acceptatie — een test vóór gunning gebruiken als blijvend bewijs, terwijl modellen na implementatie kunnen worden gewijzigd.
• Verborgen modelwijzigingen — geen zichtbaarheid in wanneer en hoe een systeem wordt bijgewerkt.
• Ontoereikende evaluatiecapaciteit — de verificatie overslaan omdat u intern geen middelen hebt.
• Geen contractuele handhaving — geen clausules die u in staat stellen prestaties af te dwingen of het systeem terug te trekken.

Welke controles moet u kunnen aantonen?

1. Definieer meetbare prestatiedrempels vóór gunning — vastleggen welke nauwkeurigheid, betrouwbaarheid en andere maatstaven u minimaal accepteert.
2. Voer een onafhankelijke verificatie uit met afgeschermde validatiedata — test het systeem met data die de leverancier niet kent en die representatief is voor uw werkelijke gebruikscontext.
3. Leg wijzigingsnotificatie en hertestplicht contractueel vast — eisen dat de leverancier u in kennis stelt van modelupdates en dat u het systeem opnieuw kunt testen voordat een nieuwe versie live gaat.
4. Documenteer uw evaluatiebeslissing en de bewijsstukken — houd vast wie wat heeft getest, welke resultaten zijn behaald en op welke basis u het systeem hebt goedgekeurd.
5. Neem een weigeringsoptie op in uw inkoopbeleid — zeg nee tegen leveranciers die onvoldoende controleerbaar bewijs leveren.

Hoe handhaaft u dit na gunning?

Een eenmalige acceptatietest is geen blijvend bewijs. Omdat modellen na implementatie kunnen worden gewijzigd, moet u wijzigingsnotificatie, logtoegang en herbeoordeling vóór elke nieuwe versie contractueel eisen. Dat maakt afwijkend gedrag eerder zichtbaar. Omdat private organisaties zelden de interne evaluatiecapaciteit van federale instanties hebben, dreigt het risico dat verificatie wordt overgeslagen. Belleg die functie daarom expliciet in, intern of via een onafhankelijke derde.

Tooling kan u helpen logboeken bij te houden, testresultaten te documenteren en wijzigingen te volgen. Wat u echter zelf moet bepalen, is welke prestatiedrempels voor uw organisatie acceptabel zijn, hoe representatief uw validatiedata moet zijn voor uw werkelijke gebruikscontext, en wanneer u een systeem moet weigeren of terugtrekken. Die oordelen laten zich niet automatiseren.