Publieke AI-standaarden maken systemen niet beslisklaar

U moet vóór ingebruikname per toepassing vastleggen welke foutkosten onaanvaardbaar zijn, en een domeinspecifieke stresstest uitvoeren die aantoont dat het systeem die drempel niet overschrijdt. Een conformiteitsclaim op basis van NIST AI RMF of ISO/IEC 42001 bewijst alleen dat het governanceproces is ingericht, niet dat het systeem uw specifieke fouten niet maakt.

De aanleiding is een analyse van 15 november 2026 van domeinspecifieke stresstests voor AI-systemen, die aantoont dat publieke standaarden principes geven maar geen operationele foutdrempel of testset voor een concrete taak bepalen. Recente academische studies gebruiken een methode genaamd STRESSEVAL, die nieuwe testgevallen opbouwt uit waargenomen missers van een taalmodel en grotere prestatieverliezen blootlegt dan statische benchmarks. In onze inschatting verschuift dit het zwaartepunt van governance van een eenmalige conformiteitsclaim naar een doorlopend systeem van domeinspecifieke stresstests per toepassing.

Waarom een hoge score op publieke tests niet betekent dat het systeem uw taak aankan

Statische publieke testsets verouderen door contaminatie en overfitting. Modellen presteren goed op bekende vragen zonder dat dit betekent dat zij een nieuwe, afwijkende casus aankunnen. Voor wie een AI-systeem moet goedkeuren voor een klinische, financiële, wetenschappelijke of cyberveiligheidstaak, raakt dit de kern van het goedkeuringsbesluit.

Een enkele score verbergt de feitelijke gevolgen van een fout. Een systeem dat gemiddeld hoog scoort kan juist falen op het ene fouttype dat in uw domein onomkeerbare schade veroorzaakt. Capaciteit op losse vraag-antwoordtests voorspelt de prestatie op de hele taak niet. Omdat een ISO- of NIST-conformiteitsverklaring geen foutdrempel voor uw taak vastlegt, blijft het goedkeuringrisico volledig bij uw organisatie liggen.

Welke fouttypen moet u testen voordat u het systeem inzet?

• Rekenfouten in kritieke stappen — fouten die een frontiermodel blijft maken ondanks hoge scores op losse vragen.
• Falen op domeinafwijkende input — prestatie op nieuwe, onbekende casus die niet in de trainingsdata voorkomen.
• Slagingskans over de volledige keten — end-to-end prestatie inclusief tool- en datatoegang, niet alleen antwoordnauwkeurigheid.
• Fouttypen uit uw eigen werkstroom — missers die in uw specifieke context voorkomen en waarvan u de oorzaak hebt vastgelegd.
• Regressie na model- of promptwijziging — prestatieverval na updates die u niet hebt voorzien.

Welke concrete controles moet u kunnen aantonen?

1. Definieer de onaanvaardbare foutdrempel per toepassing — leg vast welke foutkosten voor uw domein onomkeerbare schade veroorzaken en bij welke frequentie het systeem niet door mag.
2. Voer een acceptatietest uit met afgeschermde, domeinrepresentatieve data — zet in het inkoopcontract vast dat dit een opleveringsvoorwaarde is, niet een aanbeveling.
3. Test de volledige operationele keten inclusief tool- en datatoegang — een CISO mag niet alleen antwoordnauwkeurigheid toetsen, maar moet de agent op de hele workflow testen.
4. Zet elke gevonden fout om in een versieerbare regressietest — deze test draait na elke model- of promptwijziging opnieuw, zodat een eerdere goedkeuring geldig blijft.
5. Leg een expliciet stop- of escalatiecriterium vast met menselijke fiatteur — elke goedkeuring moet een drempel hebben waarop het systeem uit de hand wordt genomen.

Hoe bouwt u een test die werkelijk aantoont dat het systeem beslisklaar is?

Ontwerp de test rond de feitelijke gevolgen van fouten in uw workflow, niet rond een algemeen leaderboard. Het NIST AI RMF blijft een bruikbaar uitgangspunt voor de governancestructuur. De operationele invulling komt echter van uw eigen test: u bepaalt welke fouttypen u gaat meten, welke testgevallen u gebruikt, en welke drempel u stelt. Dit sluit aan bij de bevindingen van de vier studies dat dynamische, uit waargenomen missers opgebouwde tests grotere zwaktes blootleggen dan statische benchmarks.

Eén open vraag blijft staan: de studies laten nog niet zien hoe organisaties deze dynamische tests structureel integreren zonder dat de drempels afhankelijk blijven van niet-gekalibreerde expertbeoordelingen. Dat is het punt waarop governance en vakinhoud elkaar het hardst nodig hebben. Tooling kan u helpen bij het vastleggen van missers, het genereren van nieuwe testgevallen en het beheren van regressietests. Maar de keuze welke fouttypen onaanvaardbaar zijn, en hoe streng u de drempel stelt, blijft uw eigen professionele oordeel.