De modelkaart die niemand leest

Anthropic publiceert een modelkaart voor elke Claude-release. OpenAI publiceert een systeemkaart voor elke GPT-release. Google DeepMind publiceert technische rapporten voor Gemini. Meta publiceert modelkaarten voor Llama. Mistral publiceert ze voor hun modellen. Dit zijn de primaire brondocumenten — geschreven door de mensen die de modellen bouwden — die precies beschrijven wat het model kan, wat het niet kan, waar het faalt, en onder welke omstandigheden de output niet vertrouwd moet worden.

Vrijwel niemand leest ze.

De marketingpagina krijgt miljoenen bezoeken. De modelkaart krijgt duizenden. De blogpost die het model aankondigt wordt gedeeld in elke AI-nieuwsbrief en op elke LinkedIn-feed. De modelkaart — het document dat je daadwerkelijk vertelt of dit model geschikt is voor jouw use case — staat stilletjes op een documentatiesite, ongelezen, niet geciteerd, ongebruikt.

Dit is een probleem. Specifiek het soort probleem dat bedrijven geld kost, slechte implementaties oplevert en het vertrouwen in AI-tools ondermijnt — allemaal omdat het belangrijkste document dat bij elk model wordt meegeleverd wordt behandeld als een technische bijlage in plaats van een operationele handleiding.

Wat een modelkaart werkelijk bevat

De term “modelkaart” komt uit een paper uit 2019 van Margaret Mitchell, Simone Wu, Andrew Zaldivar, Parker Barnes, Lucy Vasserman, Ben Hutchinson, Elena Spitzer, Inioluwa Deborah Raji en Timnit Gebru. De paper stelde een gestandaardiseerd documentatiekader voor machine learning-modellen voor — analoog aan een voedingswaardelabel voor voedsel of een veiligheidsinformatieblad voor chemicalien.

Het oorspronkelijke kader specificeerde: modeldetails, beoogd gebruik, factoren (relevante demografische of contextuele factoren), metrics, evaluatiedata, trainingsdata, kwantitatieve analyses, ethische overwegingen, en voorbehouden en aanbevelingen.

In de praktijk zijn modelkaarten van de grote AI-labs verder geeevolueerd dan deze template, maar het kerndoel blijft: eerlijke documentatie van de capaciteiten, beperkingen en geschikte use cases van een model, geschreven door de mensen die het model het beste kennen.

Anthropics Claude-modelkaarten bevatten bijvoorbeeld:

Capaciteitsbeoordelingen met specifieke benchmarks. Niet “Claude is goed in redeneren” maar “Claude scoort X% op de MMLU-benchmark, Y% op HumanEval, Z% op MATH.” Deze cijfers zijn vergelijkbaar tussen modellen. Ze vertellen je specifiek hoe het model presteert op gestandaardiseerde tests van kennis, programmeervaardigheden en wiskundig redeneren.

Bekende beperkingen expliciet gedocumenteerd. De modelkaart vermeldt waar het model faalt. Waar het hallucineert. Waar de output niet vertrouwd moet worden zonder menselijke verificatie. Deze informatie is niet weggestopt in disclaimers — het staat vooraan als operationele richtlijn.

Veiligheidsbeoordelingen. Hoe het model is getest op schadelijke output, bias en misbruikpotentieel. Welke mitigaties zijn toegepast. Welke restrisico’s overblijven. Dit is de eerlijkste beoordeling van het veiligheidsprofiel van een model die ergens beschikbaar is — eerlijker dan een marketingblogpost, specifieker dan de samenvatting van een journalist.

Beoogde use cases en misbruikpotentieel. Waarvoor het model is ontworpen, waarvoor het niet is ontworpen, en welk gebruik de ontwikkelaars specifiek afraden. Voor een mkb-bedrijf dat evalueert of het dit model wil inzetten voor een specifieke taak, is deze sectie het meest waardevolle stukje richtlijn dat bestaat.

OpenAI’s systeemkaarten bieden equivalente informatie in een ander formaat, met bijzondere diepgang over hun veiligheidsbeoordelingsmethodologie — red-teaming resultaten, geautomatiseerde evaluatiepipelines, en de specifieke risicocategorieen die ze testen.

Deze documenten zijn geen marketingmateriaal. Het zijn technische onthullingen. Het zijn het dichtste dat de AI-industrie produceert bij eerlijke zelfbeoordeling. En ze worden genegeerd.

Waarom niemand ze leest

Drie redenen, alle drie structureel.

De documenten zijn geschreven voor onderzoekers, niet voor gebruikers. Modelkaarten gebruiken de taal van machine learning-onderzoek: benchmarknamen, evaluatiemethodologieen, statistische maten. Een inkoopmanager die evalueert of Claude ingezet moet worden voor classificatie van klantvragen weet niet waar MMLU voor staat, heeft geen referentiekader voor het interpreteren van een HumanEval-score, en weet niet hoe een veiligheidsbeoordeling vertaald moet worden naar een operationele risicobeoordeling. De informatie is waardevol. De vertaallaag ontbreekt.

De marketing is makkelijker te consumeren. Een blogpost die een nieuw model aankondigt is 1.500 woorden toegankelijke tekst met duidelijke claims: “sneller,” “nauwkeuriger,” “beter in programmeren.” De modelkaart is 15.000 woorden technische documentatie met voorbehouden, beperkingen en voorwaardelijke uitspraken. De blogpost bevestigt wat je wilt horen. De modelkaart vertelt je wat je moet weten. Dit zijn verschillende doelgroepen, en de marketing wint altijd de aandachtcompetitie.

Niemands functie omvat het lezen van modelkaarten. In een bedrijf van 200 personen dat een AI-implementatie evalueert, is niemand verantwoordelijk voor het lezen van de modelkaart. De CTO heeft misschien de technische achtergrond maar mist de tijd. De projectmanager heeft de tijd maar mist de technische achtergrond. De externe consultant heeft al een modelaanbeveling klaar voordat de modelkaart is gedownload. De modelkaart valt in een verantwoordelijkheidskloof — te technisch voor de zakelijke beslisser, te operationeel voor het onderzoeksteam, te gedetailleerd voor de tijdlijn van de consultant.

Wat een modelkaart je vertelt dat niets anders doet

Laat me het demonstreren met een specifiek voorbeeld. Ik doorloop drie categorieen informatie uit modelkaarten die direct beinvloeden of een EU mkb-bedrijf een specifiek model moet inzetten voor een specifieke use case.

Categorie 1: Taalprestatievariatie

Modelkaarten rapporteren meertalige prestatiebenchmarks. Deze benchmarks onthullen prestatieverschillen tussen talen die marketingmateriaal nooit vermeldt.

Een model dat 89% scoort op Engelstalige vraagbeantwoording kan 72% scoren op Duits en 58% op Portugees. De marketingpagina zegt “ondersteunt 95+ talen.” De modelkaart toont je de werkelijke prestatiegradient — en voor een EU mkb-bedrijf dat actief is in meerdere markten is het verschil tussen 89% en 58% het verschil tussen een bruikbare tool en een aansprakelijkheid.

Wanneer een Portugese klant een vraag indient en de begripnauwkeurigheid van het model 31 procentpunten lager is dan voor een Engelse vraag, verslechtert de outputkwaliteit. De klant ontvangt een minder nauwkeurig antwoord. Als het antwoord een aanbeveling, classificatie of beslissing betreft, wordt het nauwkeurigheidsverschil een kwaliteitsverschil, een eerlijkheidsverschil, en potentieel een juridisch verschil onder AVG artikel 22.

De modelkaart vertelt je dit. De blogpost niet.

Categorie 2: Hallucinatiepercentages per domein

Modelkaarten rapporteren steeds vaker hallucinatiepercentages — de frequentie waarmee het model plausibel klinkende maar feitelijk onjuiste informatie genereert. Deze percentages varieren dramatisch per domein.

Een model kan hallucineren met 2% bij algemene kennisvragen en 12% bij domeinspecifieke technische vragen. Voor een mkb-bedrijf dat het model inzet om klantvragen over een gespecialiseerde productlijn te beantwoorden, is het relevante hallucinatiepercentage het domeinspecifieke, niet het kopgetal.

Nog kritischer: modelkaarten beschrijven de typen hallucinaties waartoe het model neigt. Sommige modellen hallucineren specifieke details (datums, getallen, namen) terwijl de algemene richting klopt. Andere hallucineren complete causale ketens — ze produceren verklaringen die gezaghebbend klinken en compleet verzonnen zijn. Het type hallucinatie bepaalt het type menselijk toezicht dat nodig is.

Een model dat soms datums fout heeft, heeft een feitcontroleerlaag nodig. Een model dat verklaringen verzint, heeft een domeinexpert-beoordelaar nodig. De operationele respons verschilt. De modelkaart vertelt je welke respons nodig is.

Categorie 3: Veiligheidsbeoordelingsresultaten

Modelkaarten van verantwoorde AI-labs bevatten red-teaming resultaten — de uitkomsten van systematische pogingen om het model schadelijke, bevooroordeelde of ongepaste output te laten produceren.

Voor een EU mkb-bedrijf zijn de relevante veiligheidsoverwegingen specifiek: of het model bevooroordeelde output genereert die werkgelegenheidsbeslissingen kan beinvloeden (relevant onder AVG artikel 22 en artikel 6 van de AI-verordening van de EU), of het discriminerende content produceert in klantgerichte toepassingen, en of het trainingsdata lekt die persoonlijke informatie bevat.

De modelkaart behandelt deze vragen met specifieke testresultaten. Niet “we hebben op bias getest” maar “we hebben getest op demografische bias in X categorieen met Y-methodologie, en observeerden Z-patroon van restbias onder de volgende omstandigheden.”

Deze informatie is essentieel voor de conformiteitsbeoordeling die de AI-verordening van de EU vereist voor hoog-risico AI-systemen. Artikel 9 vereist een risicobeheersysteem dat identificatie en analyse van bekende en voorzienbare risico’s omvat. De modelkaart is de primaire bron voor bekende risico’s. Het negeren ervan is niet alleen operationeel onverstandig — het kan juridisch ontoereikend zijn.

Hoe je een modelkaart leest

Voor een mkb-bedrijf dat een AI-implementatie evalueert, hier is de operationele aanpak voor het lezen van een modelkaart. Dit kost ongeveer twee uur, wat minder is dan de gemiddelde stuurgroepvergadering en meer bruikbare informatie oplevert.

Stap 1: Lees eerst de sectie beoogd gebruik. Komt het beoogde gebruik overeen met jouw use case? Als de modelkaart zegt dat het model “ontworpen is voor conversationele assistentie en contentgeneratie” en je wilt het gebruiken voor geautomatiseerde kredietscore, is er een mismatch. De mismatch betekent niet dat het model het niet kan. Het betekent dat de ontwikkelaars het niet voor dat doel hebben getest, wat betekent dat de verantwoordelijkheid voor testen bij jou ligt.

Stap 2: Controleer de meertalige benchmarks. Zoek de prestatiecijfers voor elke taal die jouw implementatie zal gebruiken. Als het prestatieverschil tussen je primaire taal en secundaire talen meer dan 10 procentpunten bedraagt, plan dan een kwaliteitsborgingslaag in de slechter presterende talen.

Stap 3: Lees de beperkingensectie volledig. Dit is de meest waardevolle sectie. De ontwikkelaars vertellen je waar hun model faalt. Ze weten het, omdat ze het getest hebben. Deze sectie negeren is het AI-equivalent van het negeren van het rapport van de constructeur voordat je op een stuk grond gaat bouwen. De informatie is er. De gevolgen van het negeren zijn voorspelbaar.

Stap 4: Beoordeel de veiligheidsevaluatie. Identificeer de categorieen schadelijke output die zijn getest en de restrisico’s die overblijven. Koppel deze aan jouw use case. Als jouw implementatie kwetsbare populaties betreft (klanten die financiele producten aanvragen, sollicitanten, patienten), is de veiligheidsevaluatie geen aanvullende lectuur. Het is een compliancevereiste.

Stap 5: Vergelijk tussen modellen. Modelkaarten zijn vergelijkbaar. Dezelfde benchmarks, dezelfde categorieen, dezelfde evaluatiemethodologieen verschijnen in de modelkaarten van verschillende labs. Lees drie modelkaarten van concurrerende modellen en de prestatieverschillen — inclusief de niet-voor-de-hand-liggende die begraven liggen in de bijlagen — worden duidelijk.

Categorie 4: Documentatie van gepast gebruik en misbruik

Modelkaarten bevatten steeds vaker expliciete lijsten van beoogde use cases en gedocumenteerde misbruikscenario’s. Deze lijsten zijn niet hypothetisch. Ze zijn afgeleid van geobserveerd gebruikersgedrag tijdens testen en implementatie.

Voor een mkb-bedrijf dat een taalmodel inzet voor klantgerichte toepassingen is de misbruikdocumentatie operationeel kritisch. De modelkaart kan specificeren: “Dit model is niet ontworpen voor medische diagnose, juridisch advies of financiele aanbevelingen.” Als jouw implementatie het model gebruikt om aanbevelingen voor financiele producten te genereren, heeft de modelkaart je zojuist verteld — zwart op wit, van de mensen die het model bouwden — dat jouw use case buiten het beoogde bereik valt.

Dit betekent niet dat het model de taak niet kan uitvoeren. Het presteert er misschien adequaat in. Maar de misbruikdocumentatie van de modelkaart betekent dat de modelontwikkelaars het model niet voor die specifieke toepassing hebben getest of gevalideerd. De veiligheidsbeoordelingen dekken jouw use case niet. De prestatiebenchmarks zijn niet gekalibreerd voor jouw domein. De aansprakelijkheid, in het geval van schadelijke output, valt geheel op jou — omdat de modelkaart expliciet vermeldde dat jouw gebruik niet beoogd was.

Voor compliance met de AI-verordening van de EU is deze documentatie direct relevant. Artikel 13 vereist transparantie over het beoogde doel van een AI-systeem. Als de modelkaart zegt dat het model niet beoogd is voor jouw use case, en je zet het in voor die use case, heb je een compliancekloof gecreeerd die geen enkele post-hoc documentatie kan dichten.

De modelkaart vertelde het je. Je koos ervoor het niet te lezen. Het gevolg is voorzienbaar.

Het primaire-bronprincipe

Ik lees ECB-rapporten, niet wat journalisten zeggen over ECB-rapporten. Ik lees Eurostat-datasets, niet wat commentatoren zeggen over Eurostat-datasets. Ik lees artikelen van de AI-verordening van de EU, niet wat adviesbureaus zeggen over artikelen van de AI-verordening van de EU.

De modelkaart is de primaire bron voor wat een AI-model wel en niet kan. Al het andere — de blogpost, het analistenrapport, de aanbeveling van de consultant, de LinkedIn-hete-neem — is commentaar. Commentaar heeft zijn nut. Maar commentaar introduceert bias, compressie en agenda. De primaire bron niet.

De modelkaart is niet perfect. Het is geschreven door het lab dat het model bouwde, en labs hebben prikkels om hun modellen gunstig te presenteren. Maar de modelkaart wordt beperkt door reproduceerbaarheid — de benchmarks kunnen onafhankelijk worden geverifieerd, de beperkingen kunnen onafhankelijk worden getest, en de veiligheidsbeoordelingen kunnen onafhankelijk worden gerepliceerd. Marketing wordt door geen van deze beperkt.

Wanneer ik een AI-model evalueer voor een Bluewaves-implementatie, is de modelkaart het eerste document dat ik lees en het laatste document waarnaar ik verwijs. Niet het eerste omdat het makkelijk is — omdat het eerlijk is. Niet het laatste omdat het uitgebreid is — omdat de beslissingen die we nemen over implementatie verankerd zijn in wat de ontwikkelaars daadwerkelijk weten over hun model, niet in wat hun marketingteam wil dat wij geloven.

De operationele implicatie

Voor elke AI-implementatie bij jouw bedrijf moet een persoon de modelkaart lezen. Volledig. Niet scannen. Niet de samenvatting. Het volledige document.

Die persoon moet de technische beoordelingen van de modelkaart vertalen naar drie operationele documenten:

Een capaciteitsbeoordeling die in gewone taal vermeldt wat het model wel en niet kan voor jouw specifieke use case, gebaseerd op de benchmarks en beperkingen van de modelkaart.

Een risicoregister dat de veiligheidsbeoordelingen en bekende beperkingen van de modelkaart koppelt aan jouw specifieke implementatiecontext, en identificeert welke risico’s relevant zijn, welke mitigaties nodig zijn, en welke restrisico’s geaccepteerd moeten worden.

Een monitoringplan dat specificeert hoe je in productie zult verieren dat de werkelijke prestaties van het model overeenkomen met de gedocumenteerde prestaties van de modelkaart — omdat modellen kunnen degraderen, use cases kunnen verschuiven, en de enige controle op de claims van de modelkaart jouw eigen observatie is.

Deze drie documenten kosten een persoon ongeveer vier uur om te produceren. Ze kosten niets. Ze voorkomen de meest voorkomende en duurste AI-implementatiefouten: een model inzetten voor een use case waarvoor het nooit ontworpen was, implementeren in een taal waar de prestaties materieel lager zijn, en implementeren zonder een monitoringsysteem dat degradatie opvangt voordat gebruikers het doen.

De modelkaart is gratis. Het lezen ervan is gratis. Ernaar handelen is gratis.

De kosten van het niet lezen zijn de implementatie die faalt en het team dat het vertrouwen in AI-tools verliest omdat niemand het document las dat het falen had voorspeld.

Lees de modelkaart.

De primaire bron is beschikbaar. De primaire bron is gratis. De primaire bron bevat informatie die geen secundaire bron — geen blogpost, geen analistenrapport, geen aanbeveling van een consultant — kan repliceren.

De modelkaart is geschreven door de mensen die het model bouwden. Zij weten dingen over het gedrag ervan die niemand anders weet. Ze hebben die dingen gedocumenteerd — eerlijk, specifiek, met benchmarks en voorbehouden — in een document dat openbaar beschikbaar is en systematisch wordt genegeerd.

De kloof tussen de marketingpagina en de modelkaart is de kloof tussen wat je wilt horen en wat je moet weten. De modelkaart is wat je moet weten.

Lees het.