Steeds meer organisaties proberen hun AI-keuzes te sturen met praktische regels: gebruik geen ‘buitenlandse’ modellen, neem alleen software van vertrouwde partijen, en controleer de naam op de verpakking. Maar wie denkt dat een landlabel of uitgeversnaam het hele verhaal vertelt, komt bedrogen uit. Cisco waarschuwt dat je bij AI herkomst checken niet kunt leunen op labels—omdat model-lineage complexer is dan wat er op een productfiche staat.
In onderzoek van Cisco samen met VAIL blijkt namelijk dat relaties tussen modelfamilies niet altijd zichtbaar worden via de bekende “publisher & country”-informatie. Zelfs als een model post-training is aangepast of onder een nieuwe naam wordt aangeboden, kan het nog steeds detecteerbaar verbonden zijn met een upstream model. Dat heeft gevolgen die lijken op de risico’s van de software supply chain.
Waarom een landlabel niet genoeg is
Overheids- en veiligheidscontexten maken labels aantrekkelijk. Als een landnaam een indicatie lijkt voor nationaal risico, is het verleidelijk om AI op die manier te filteren. Cisco ziet dat anders. In de blogpost “The ‘U.S. vs. China’ AI Trap: An Incomplete Proxy for AI Security” betoogt Cisco dat landlabels niet automatisch correleren met wat er technisch in een model zit.
De kern zit in een fenomeen dat Cisco “provenance entanglement” noemt: de componenten en eigenschappen van een model kunnen vermengd raken. Een AI kan tijdens het ontwikkelproces voortbouwen op bestaande gewichten of checkpoints. Daardoor kan het gedrag en de “vingerafdruk” van een upstream model doorwerken in downstream varianten.
Het resultaat: een model dat in de administratie “x-land” of “y-publisher” is, kan in de praktijk kenmerken hebben die je eerder zou verwachten bij een ander land of een andere modelfamilie.
Wat Cisco en VAIL onderzochten
Om te toetsen of labels werkelijk een betrouwbaar beeld geven, kozen onderzoekers twee modelvarianten: Nemotron en Qwen. Ze kozen deze sets niet willekeurig, maar omdat bekend is dat sommige Nemotron-modellen gebruikmaken van Qwen base weights. Daarmee hadden ze een realistische situatie om te beoordelen of er nog relaties te detecteren zijn.
Vervolgens gebruikten ze twee benaderingen voor model fingerprinting:
- Model Provenance Kit (Cisco): onderzoekt artefacten “van binnenuit”.
- Behavioral Fingerprinting (VAIL): kijkt naar gedrag “van buitenaf”, dus via inferentie/gebruik.
Belangrijk detail: beide methoden kunnen verschillen in waar je precies naar kijkt. Daardoor geven ze samen een steviger indicatie dan alleen één soort meting.
Detecteerbare upstream-relaties blijven bestaan
De onderzoekers vonden dat Nemotron-modellen die zijn gebouwd vanuit Qwen base weights, aanzienlijk meer lijken op Qwen-modellen dan je op basis van toeval zou verwachten. Met andere woorden: een nieuwe naam of post-training betekent niet automatisch dat technische relaties verdwijnen.
Dit inzicht is relevant omdat organisaties vaak aannemen dat het verwijderen van labels of het “opnieuw publiceren” van een model het risico wist. Volgens Cisco is dat niet zo. Technische lineage kan blijven doorwerken in gewichten, biases en gedragskenmerken—ook wanneer het eindproduct anders wordt gepresenteerd.
De link met software supply chain security
Waarom is dit zo belangrijk? Omdat model-lineage risico’s kan creëren die sterk lijken op de software supply chain threat waarvoor SBOM’s (Software Bill of Materials) zijn ontwikkeld. Bij software wil je weten uit welke componenten een applicatie bestaat, juist om later te kunnen bepalen welke systemen geraakt zijn als een upstream onderdeel besmet blijkt.
Cisco maakt een vergelijkbare redenering voor AI-modellen. Stel dat een upstream model later een achterdeur, systematische bias of exploiteerbaar gedrag blijkt te bevatten. Dan moeten organisaties kunnen inschatten welke downstream-modellen mogelijk dezelfde kenmerken dragen en daarom nader onderzoek verdienen.
Dat is niet alleen theoretisch. Het gaat om het praktische “wat moeten we nu doen”-vraagstuk wanneer er nieuwe informatie opduikt.
Waarom een AI-SBOM moeilijker is dan software-SBOM
In een ideale wereld voeg je bij elk AI-model een “model bill of materials” toe, zodat je upstream afhankelijkheden kunt volgen. Cisco en de onderzoekers stellen dat AI-modellen in zekere zin ook een SBOM nodig hebben.
Maar: het is lastiger dan bij klassieke software. De reden is dat afhankelijkheden niet altijd netjes in een manifest-bestand staan. Bij AI kunnen elementen “ingebakken” zitten in de learned weights. Bovendien is het ontwikkelpad vaak niet: start vanaf nul, maar eerder: fine-tune bestaande checkpoints.
Daarmee schuift de uitdaging van administratie naar analyse: je hebt lineage-informatie én technische verificatie nodig. Cisco noemt technische fingerprints als mogelijke aanvulling om disclosures te onderbouwen of om relaties te vinden die niet uit de documentatie blijken.
Drie verbeterpunten voor organisaties en de industrie
Uit het onderzoek volgen drie concrete richtingen om efficiënter met AI-security om te gaan.
1) Behandel publisher-identiteit als één puzzelstuk
Voor ondernemingen die een model willen gebruiken, adviseert Cisco om de uitgever en herkomst niet als eindconclusie te zien. Je due diligence moet breder zijn: kijk naar lineage, training dependencies, analyseer gedrag en bepaal hoe je het model operationeel controleert. Met andere woorden: AI herkomst checken is zinvol, maar alleen als onderdeel van een bredere set controles.
2) Regulatoren: beter zicht op upstream afhankelijkheden
Regels en rapportage kunnen effect hebben, maar dan wel met een realistisch begrip van waar upstream-afhankelijkheden zitten. Zonder die verdieping blijft het beeld te grof om kwetsbaarheden, biases en restricties door model-lineage goed te beoordelen.
3) Ontwikkelaars: lineage transparant maken
Cisco pleit ervoor om lineage disclosure routine te maken in plaats van een optionele extra. Transparantie wordt gezien als een manier om upstream afhankelijkheden inzichtelijk te maken voordat een model in een tech stack wordt geïntegreerd. Daarbij is het niet alleen “wat staat er op de verpakking”, maar ook wat er technisch meespeelt.
Praktische aanpak: hoe kun je zelf beginnen?
Ook als je organisatie geen eigen model-fingerprintlabs heeft, kun je stappen zetten. Denk aan een aanpak in lagen:
- Documentatie verzamelen: vraag naar ontwikkelgeschiedenis, training dependencies en model-herkomst—niet alleen land en uitgever.
- Gedrag testen: evalueer of het model opvallende patronen vertoont die passen bij bekende upstream-kenmerken.
- Operationele controle: beperk waar het model toegang heeft en hoe outputs worden gebruikt, zodat je sneller kunt ingrijpen als er risico’s opduiken.
- Regelmatige herbeoordeling: behandel “vertrouwd” niet als permanent; herzie keuzes bij nieuwe informatie over modelsamenstelling of kwetsbaar gedrag.
Zo voorkom je dat labels een schijnzekerheid geven. Je creëert een proces dat beter aansluit bij hoe modellen technisch tot stand komen.
Waarom dit ook draait om bias en achtergronden
Model-lineage gaat niet alleen over malware-achtige risico’s. Het speelt ook mee bij bias en andere structurele eigenschappen. Als upstream modellen bijdragen aan gedrag in downstream varianten, dan kunnen die eigenschappen mee terugkomen—ook wanneer het downstream model een andere naam of positionering heeft gekregen.
Voor datagedreven securityteams is dat extra relevant: incidenten of kwaliteitsproblemen kunnen “verderop in de keten” ontstaan, terwijl de oorzaak bij een upstream afhankelijkheid ligt.
Gerelateerd: AI-gedreven verdediging en supply-chain denken
Het is nuttig om supply-chain-denken door te trekken naar AI. Een praktische manier om dat thema te verbreden is het combineren van model- en keteninzichten met algemene securitybewustwording. Als je meer wilt lezen over hoe AI in defensie en operationele besluitvorming kan bijdragen, zie ook Bron: https://www.securityweek.com/think-youve-eliminated-chinese-ai-check-the-models-lineage-cisco-says/
