Silent Updates: waarom de AI die jij denkt te draaien een andere is dan de documentatie zegt

De documentatie noemt versie 1.3. In de praktijk draait er misschien versie 1.7, met een andere system prompt, andere routering, andere fine-tuning, ander retrieval-gedrag. Niemand kan het van buitenaf controleren. Dit is geen theoretisch risico, het is de realiteit van vandaag, en het ondermijnt de kernonderbouwing van AI-governance.

Dit artikel, gebaseerd op het arXiv-paper Silent Updates: Measuring and Closing the Post-Deployment Disclosure Gap van Sophia Abraham en Ben Bucknall, analyseert waarom "silent updates" een compliance-tijdbom zijn voor Nederlandse overheidsorganisaties die op externe modellen leunen.

Het probleem: een verbroken chain of custody

De fundamentele aanname achter AI-governance is dat er een extern verifieerbare keten van custody bestaat: het model dat in een systeemkaart of evaluatierapport wordt beschreven, is hetzelfde model dat aan gebruikers wordt geserveerd. Deze aanname verbindt de documentatie met de realiteit.

Het Silent Updates-paper toont aan dat deze aanname in de praktijk niet houdbaar is. Providers kunnen het gedrag van gedeployde modellen wijzigen via vijf mechanismen:

1. Fine-tuning, het model wordt bijgetraind op nieuwe data.
2. Classifier-updates, de safety/classificatielaag verandert.
3. System prompt-revisies, de instructies die het model sturen veranderen.
4. Retrieval-wijzigingen, de documenten die het model kan ophalen veranderen.
5. Routing-wijzigingen, verkeer wordt anders verdeeld over modellen.

Elk van deze mechanismen kan het gedrag van het systeem materieel veranderen. En elk kan stil gebeuren: zonder publieke openbaarmaking, zonder versie-increment, zonder her-evaluatie.

Formele definitie: wat is een "silent update"?

Laat $M_t$ het model zijn dat op tijdstip $t$ aan gebruikers wordt geserveerd, en laat $D_t$ de gedocumenteerde beschrijving van het model zijn (systeemkaart, versie, evaluatieresultaten). Definieer een update als stil wanneer:

$$M_{t_1} \neq M_{t_2} \land D_{t_1} = D_{t_2}$$

met $t_1 ＜ t_2$. Dat wil zeggen: het geserveerde model is veranderd, maar de documentatie is identiek gebleven. De chain of custody is verbroken wanneer een externe partij op basis van $D_t$ niet kan verifiëren dat $M_t$ overeenkomt met de documentatie.

Het paper stelt de kernvraag: bestaat er in de praktijk een externe verificatieroute van $D_t$ naar $M_t$? Het antwoord is ontkennend voor de gehele onderzochte steekproef.

De empirische bevindingen

Abraham en Bucknall onderzochten post-deployment disclosure practices bij negen first-party API-providers en zeven third-party inference-hosts.

De bevindingen zijn genuanceerd en dat is precies het probleem:

• Providers publiceren substantieel safety-materiaal: kwantitatieve evaluaties, versie-specifieke rapporten, uitgebreide documentatie.
• Maar geen enkele provider publiceert informatie waarmee een externe partij kan verifiëren dat het geserveerde artefact hetzelfde is als het artefact in de documentatie.

Dit is de crux: de documentatie is rijk, maar niet geverifieerd gekoppeld aan de realiteit. Een evaluatie op versie X betekent niets als het live-systeem versie Y draait.

Een codevoorbeeld: detecteer een silent update

Hoe stel je als afnemer vast dat een geserveerd model veranderd is? Een pragmatische aanpak is een behavioral fingerprint: stuur een vaste referentieset van prompts en vergelijk de output-distributie over de tijd. Als de distributie statistisch significant verschuift terwijl de gedocumenteerde versie ongewijzigd blijft, is dat een signaal van een silent update.

import numpy as np

class SilentUpdateDetector:
    def __init__(self, reference_prompts, z_threshold=3.0):
        self.reference_prompts = reference_prompts
        self.z_threshold = z_threshold
        self.baseline = None  # (mean, std) per output-dimensie

    def snapshot(self, model_fn):
        """Vang een output-distributie voor de referentieset."""
        return np.array([model_fn(p) for p in self.reference_prompts])

    def calibrate(self, model_fn, n=10):
        """Bouw een baseline uit n snapshots (tijdens gecontroleerde versie)."""
        samples = np.array([self.snapshot(model_fn) for _ in range(n)])
        self.baseline = (samples.mean(axis=0), samples.std(axis=0) + 1e-9)

    def detect(self, model_fn):
        """Z-score van de huidige snapshot t.o.v. de baseline."""
        current = self.snapshot(model_fn)
        if self.baseline is None:
            return False
        z = np.abs((current - self.baseline[0]) / self.baseline[1])
        return bool((z - self.z_threshold).any() > 0)

Complexiteitsanalyse: het opslaan van de baseline is $O(k)$ geheugen (voor $k$ referentieprompts). Elke detectie-cyclus is $O(k \cdot c)$ tijd, waar $c$ de kost van één model-inferentie is. De detectie is daarmee lineair in het aantal referentieprompts en schaalt niet met de grootte van de onderliggende modelparameters, de fingerprint is een observabel, geen model-inspectie. De beperking is duidelijk: deze methode detecteert gedragsverandering, niet artefact-identiteit. Een provider die de output op de referentieset identiek houdt maar elders anders gedraagt, wordt gemist. Dit is een inherente beperking van black-box-detectie zonder cryptografische artefact-binding.

De drie-parten-gedragstrigger

Het paper stelt een Three-Part Behavioral Trigger System voor om te bepalen wanneer een post-deployment modificatie disclosure- of her-evaluatieverplichtingen oproept. Het idee is dat niet elke wijziging een verplichte openbaarmaking rechtvaardigt, alleen wijzigingen die het gedrag materieel beïnvloeden.

De drie delen zijn, in abstracte vorm:

1. Gedragsafwijking: de wijziging resulteert in meetbaar ander gedrag op een referentieset.
2. Risico-impact: de wijziging raakt een veiligheids- of compliance-relevante dimensie (safety, privacy, juridische uitkomst).
3. Gebruikersimpact: de wijziging kan gebruikers anders beïnvloeden dan voorheen.

Wanneer alle drie triggeren, is disclosure vereist. Dit is een pragmatisch antwoord op de vraag "elke wijziging openbaren", wat onuitvoerbaar is, versus "nooit openbaren", wat de governance ondergraaft.

De Silent Updates Scorecard

Het paper introduceert de Silent Updates Scorecard, een publiek instrument om post-deployment disclosure practices te meten over providers en hosts. Dit is een direct bruikbaar assessment-instrument voor organisaties die modelleveranciers evalueren.

De Scorecard meet, in essentie, op welke dimensies een provider externe verifieerbaarheid biedt. Het is een concrete checklist die een organisatie kan gebruiken om haar modelleveranciers te toetsen.

Competing hypotheses: waarom doen providers dit?

Er zijn meerdere materieel verschillende verklaringen voor de afwezigheid van externe verifieerbaarheid:

• H1 (Operationele noodzaak): Providers moeten modellen continu bijwerken om veiligheidsrisico's te adresseren, en kunnen niet wachten op disclosure-cycli. Stilte is een bijproduct van snelle iteratie, niet een doel.
• H2 (Strategische ondoorzichtigheid): Providers hebben geen prikkel om transparant te zijn over interne wijzigingen die hun concurrentiepositie of compliance-status kunnen schaden. Stilte is strategisch.
• H3 (Technische onmogelijkheid): Externe verifieerbaarheid van "hetzelfde model" is technisch niet goed opgelost, er is geen gestandaardiseerd mechanisme om een geserveerd artefact te koppelen aan een documentatie-artefact.
• H4 (Null-hypothese): Providers zouden wel verifieerbaarheid bieden als er een markt- of regelgevingsprikkel voor bestond, maar die prikkel ontbreekt momenteel.

Falsificatie: H1 zou worden ontkracht als providers stille updates doen zonder operationele noodzaak. H2 zou worden ontkracht als providers transparantie bieden op niet-concurrentiegevoelige wijzigingen. H3 zou worden ontkracht als een eenvoudige technische oplossing bestaat die providers niet implementeren.

Falsificatie van de centrale stelling: wat zou bewijzen dat het silent-updates-risico geen compliance-probleem is? Dat zou het geval zijn als een externe partij, op basis van publieke documentatie, wél kon verifiëren dat het geserveerde model gelijk is aan het gedocumenteerde artefact. Het paper toont aan dat dit in de gehele steekproef niet mogelijk is, een falsifieerbare claim die momenteel standhoudt.

Het paper levert geen uitsluitsel over welke hypothese dominant is, en dat is epistemisch correct. De strategische implicatie is echter identiek onder alle vier: een organisatie kan niet vertrouwen op de externe verifieerbaarheid die providers vrijwillig bieden.

Counterfactual: zou dit zonder stille updates ook een probleem zijn?

De informatieve counterfactual: als providers elke wijziging openbaar zouden maken, zou EU AI Act-conformiteit dan gegarandeerd zijn?

Het antwoord is genuanceerd nee. Transparantie is noodzakelijk maar niet voldoende. Zelfs met volledige disclosure blijft er een probleem: de afnemer moet de wijziging detecteren, de impact beoordelen, en zijn eigen risicobeheer aanpassen. Een provider die elke wijziging meldt, verschuift de beoordelingslast naar de afnemer.

De scherpere counterfactual is dus: zou een organisatie die zelf het model host (geen externe provider) hetzelfde compliance-risico lopen? Het antwoord is: gedeeltelijk nee. Een organisatie die het model zelf draait, heeft controle over de artefacten en kan interne versiebeheer afdwingen. Het risico van stille updates is specifiek een outsourcing-risico: het bestaat alleen omdat de controle over het artefact buiten de organisatie ligt.

Dit leidt tot een belangrijke conclusie: het silent-updates-risico is een vorm van leveranciersrisico, en moet als zodanig worden behandeld in NIS2/BIO2-risicobeheer, niet als een "modelgedrag"-kwestie.

Waarom dit de EU AI Act-conformiteit ondermijnt

De EU AI Act vereist dat high-risk AI-systemen voldoen aan conformiteitsbeoordelingen. De kern van die beoordeling is dat het beoordeelde systeem het systeem is dat in gebruik wordt genomen. Als het systeem stil verandert na de beoordeling, is de beoordeling ongeldig geworden.

De AI Act kent bovendien post-market monitoring-verplichtingen (Art. 72). Providers en deployers moeten het gedrag van het systeem in de markt monitoren. Dit is onmogelijk als de afnemer niet kan vaststellen welk model er draait.

Voor Nederlandse overheidsorganisaties is de consequentie concreet:

• Een gemeente die een AI-chatbot gebruikt voor burgercommunicatie, kan niet aantonen welk model de antwoorden genereerde op een bepaald moment.
• Een UWV-systeem dat beslissingsondersteuning biedt, kan niet aantonen dat de beslissing is genomen op basis van het model dat in de DPIA is beoordeeld.
• Een zorginstelling die LLM-ondersteuning voor klinische processen gebruikt, kan niet verifiëren dat de versie die de patient-data verwerkt, dezelfde is als de gevalideerde versie.

Wat moet je anders doen: een auditbare AI-leveranciersstrategie

Dit risico staat niet op zichzelf. Het is een facet van hetzelfde fundamentele probleem als de intrekking van frontier-modellen door exportcontroles: de afnemer heeft geen controle over het artefact dat hij gebruikt. Revocatie en wijziging zijn twee zijden van dezelfde medaille, de leverancier bepaalt zowel de beschikbaarheid als de identiteit van het model.

De strategische consequentie is dat Nederlandse organisaties externe verifieerbaarheid van modelleveranciers actief moeten eisen en meten, niet erop hopen:

1. Gebruik de Silent Updates Scorecard als onderdeel van het leveranciers-assessment. Beoordeel elke modelprovider op externe verifieerbaarheid, en neem deze score op in het risicoregister.
2. Controleer modelversies periodiek. Voor kritieke toepassingen, bouw een eigen verificatiemoment dat vaststelt welk model daadwerkelijk wordt geserveerd, onafhankelijk van de provider-documentatie.
3. Documenteer de versie op het moment van beslissing. Voor high-impact toepassingen (geautomatiseerde besluitvorming), leg vast welk model de uitkomst genereerde, zodat een auditor later kan reconstructen.
4. Behandel stille updates als leveranciersrisico in BIO2/NIS2. Voeg model-revocatie- en model-wijziging-risico toe aan de leveranciersanalyse.
5. Overweeg self-hosting voor kritieke toepassingen. Waar de keten van custody onvervangbaar is, is controle over het artefact de enige garantie.

Wat blijft onzeker?

Het paper is methodologisch sterk maar heeft belangrijke grenzen:

• Steekproefomvang: negen providers en zeven hosts is een representatieve maar geen uitputtende steekproef. De bevinding "geen enkele provider biedt externe verifieerbaarheid" geldt voor de onderzochte set.
• Geen technische oplossing getest: het paper identificeert het probleem en stelt een scorecard voor, maar test geen cryptografische of technische oplossingen voor artefact-verificatie.
• Onzekerheid over motivatie: de competing hypotheses (H1-H4) blijven ongediscrimineerd. We weten niet of stilte operationeel, strategisch of technisch is.
• Regelgevingsontwikkeling: of de EU AI Act of andere regelgeving externe verifieerbaarheid zal afdwingen is ongewis. Dit is een HYPOTHESIS over de regelgevingsrichting.

Beperkingen van deze analyse

Deze analyse kent grenzen die belangrijk zijn om te benoemen. De empirische basis is een steekproef van negen providers en zeven hosts, representatief maar niet uitputtend, en de bevinding kan veranderen naarmate meer providers externe verifieerbaarheid implementeren. Ten tweede meet het paper de afwezigheid van disclosure-praktijken, niet de aanwezigheid van opzettelijke verhulling; we kunnen niet onderscheiden of stilte operationeel, strategisch of technisch is (de hypotheses H1-H3 blijven ongediscrimineerd). Ten derde is de behavioral-fingerprint-methode in dit artikel een illustratie, geen gevalideerd instrument, het detecteert gedragsverandering, niet artefact-identiteit, en mist providers die op de referentieset identiek blijven. Methodologisch is dit artikel daarmee een interpretatie van primaire onderzoeksbevindingen, geen nieuw experiment; de conclusies moeten worden gelezen als SUPPORTED_INFERENCE op basis van het paper, niet als onafhankelijk geverifieerde feiten.

De synthese die de bronnen niet direct trekt

De originele synthese van dit artikel verbindt het Silent Updates-paper met het Sovereign-by-necessity-paper (arXiv:2608.13272): beide papers beschrijven een ander facet van hetzelfde fundamentele probleem, de afnemer heeft geen controle over het artefact dat hij gebruikt. De exportcontrole-paper toont dat toegang kan worden ingetrokken (revocatie); het Silent Updates-paper toont dat het model stil kan veranderen (wijziging). Samen beschrijven ze een model waarin de afnemer noch de beschikbaarheid, noch de identiteit van het model kan garanderen.

Deze twee risico's, revocatie en wijziging, vragen om dezelfde governance-oplossing: externe verifieerbaarheid van het artefact. Een Nederlandse overheidsorganisatie die haar AI-risico's serieus beheert, zou beide dimensies in één leveranciersrisicomodel moeten opnemen, en voor kritieke toepassingen controle over het artefact moeten eisen, hetzij door contractuele garanties, hetzij door self-hosting.

De AI Act veronderstelt een keten van custody die in de praktijk niet bestaat. Dat is geen theoretische tekortkoming, het is een operationeel risico dat vandaag al van invloed is op elke organisatie die externe modellen gebruikt. Het is tijd om het te meten, te eisen, en waar nodig te controleren.