Federated inference is geen AVG-vrijwaring: privacy eindigt niet bij de aggregator

Federated inference klinkt als een antwoord op een bekend probleem: gevoelige gegevens hoeven niet eerst in één centrale dataset te worden samengebracht voordat meerdere modellen er waarde uit kunnen halen. Maar decentralisatie is geen eigenschap die je eenmaal aan een architectuur toekent. Zij moet per gegevensstroom worden aangetoond.

Dat onderscheid wordt zichtbaar in Privacy-Preserving Heterogeneous Multi-LLM Federated Inference for Cognitive Diagnosis van Boyapati en collega's, arXiv:2609.02947v1 van 1 september 2026. Het paper combineert voorspellingen van drie verschillende taalmodellen en voegt voor aggregatie lokaal Laplace-ruis toe. De formele privacygarantie betreft de gepubliceerde diagnostische vector. De auteurs schrijven tegelijk expliciet dat commerciële API-providers de ruwe leerlingantwoorden en prompts kunnen verwerken en loggen.

De centrale these van dit artikel is daarom beperkt maar belangrijk:

In de onderzochte commerciële-API-architectuur reduceert output-level differential privacy het risico rond gedeelde voorspellingen, maar zij beheerst niet het afzonderlijke risico dat persoonsgegevens al in de prompt aan een provider worden verstrekt. Of dat resterende risico onder de AVG aanvaardbaar is, hangt af van doelbinding, minimalisatie, verwerkerswaarborgen, beveiliging en eventuele internationale doorgifte. Het paper bewijst die rechtmatigheid niet.

Dat is geen afwijzing van federated inference. Het is een correctie op de plaats waar de privacyclaim eindigt.

Mijn bezwaar richt zich dus niet tegen cloudgebruik als zodanig. Ik zou deze architectuur in een DPIA pas privacybevorderend noemen wanneer naast epsilon ook de volledige promptketen aantoonbaar is beheerst. Dat is een strengere toets dan het overnemen van het label uit een technisch paper, maar precies daar begint bestuurlijke verantwoordelijkheid.

Wat het paper werkelijk onderzoekt

Het framework is gericht op cognitieve diagnostiek: uit antwoorden van leerlingen wordt per concept een geschatte beheersingsscore afgeleid. De gebruikte modellen zijn LLaMA-3.3-70B via Groq, GPT-4o-mini en Claude-3-Haiku, waarbij latere experimenten volgens het paper een opvolgend Claude-model gebruikten. Elk model produceert een vector met scores tussen nul en één. De voorspellingen worden vervolgens geaggregeerd.

De auteurs evalueren op ASSIST09, GSM8K en UCI Student Performance. Voor een privacybudget van epsilon gelijk aan 2 rapporteren zij gemiddeld 11,99 procent lagere mean absolute error dan hun single-model baseline, met gemiddeld 0,46 procent extra fout ten opzichte van dezelfde federatie zonder privacyruis. Bij een strenger budget van epsilon gelijk aan 0,5 verdwijnt het voordeel op ASSIST09 en wordt de uitkomst 3,69 procent slechter dan de baseline. Privacy en bruikbaarheid blijven dus een trade-off, geen gratis combinatie.

Belangrijker voor de architectuur is de scheiding tussen twee fasen:

1. In de kalibratiefase blijven datasets verdeeld over entiteiten.
2. In de inferentiefase wordt dezelfde testleerling door alle model-API's beoordeeld.
3. Iedere entiteit voegt ruis toe aan haar voorspelling.
4. Een aggregator combineert de geberuisde voorspellingen met residual correction.

Dit is geen klassieke federated-learningronde waarin modelgewichten of gradients worden uitgewisseld. De modellen blijven black boxes. De gedeelde objecten zijn voorspellingen. Daardoor zijn gradient leakage en modelinversie via gedeelde updates niet het primaire mechanisme. Daar staat tegenover dat de inferentieprompt naar meerdere externe endpoints kan gaan.

De formele grens van de privacygarantie

Laat (x) de invoer over een leerling zijn, (M_j) modelprovider (j), (z_j=M_j(x)) de lokale voorspelling en eta_j de toegevoegde Laplace-ruis. De gepubliceerde uitkomst is in vereenvoudigde vorm:

[ \tilde{y}=\frac{1}{m}\sum_{j=1}^{m}(z_j+\eta_j) ]

Het paper claimt epsilon-local differential privacy voor deze uitkomst, bij passende sensitiviteit en ruisschaal. Die garantie begrenst hoeveel de verdeling van de gepubliceerde output verandert wanneer één record wordt toegevoegd of verwijderd. Zij zegt niet dat provider (M_j) niets over (x) kan leren. De provider moet (x), of een daarvan afgeleide prompt, immers verwerken om (z_j) te produceren.

Een bruikbaar dreigingsmodel moet daarom minstens drie oppervlakken uit elkaar houden:

[ R_{totaal}=R_{prompt}+R_{aggregatie}+R_{publicatie} ]

• (R_{prompt}): blootstelling tijdens verzending, verwerking, logging en eventuele hergebruik door de modelprovider.
• (R_{aggregatie}): wat de aggregator uit individuele voorspellingen kan afleiden.
• (R_{publicatie}): wat ontvangers uit de gedeelde einduitkomst kunnen afleiden.

De differential-privacyconstructie adresseert vooral de laatste twee oppervlakken. Het paper erkent dat het eerste oppervlak buiten de garantie valt. Daarmee is de term privacy-preserving niet onjuist, maar wel domeingebonden: de eigenschap geldt voor een afgebakende gegevensstroom en een afgebakende aanvaller.

Wat de AVG wel en niet uit deze architectuur laat volgen

Artikel 32 AVG verplicht zowel verwerkingsverantwoordelijke als verwerker passende technische en organisatorische maatregelen te nemen, rekening houdend met risico, stand van de techniek, context en kosten. Artikel 28 vereist dat een verwerkingsverantwoordelijke alleen verwerkers gebruikt die voldoende waarborgen bieden. Hoofdstuk V stelt aanvullende voorwaarden wanneer persoonsgegevens naar een land buiten de Europese Economische Ruimte worden doorgegeven.

Daaruit volgen drie juridische correcties op een te eenvoudige lezing.

Ten eerste kan een organisatie haar eigen verantwoordelijkheid niet laten verdwijnen door in een contract te schrijven dat de leverancier alle risico draagt. Contracten zijn wel degelijk relevant: zij leggen instructies, beveiligingsafspraken, subverwerkers, auditrechten en regres vast. Maar zij vervangen de selectie-, toezicht- en verantwoordingsplicht van de verwerkingsverantwoordelijke niet.

Ten tweede is gebruik van een externe of Amerikaanse provider niet automatisch onrechtmatig. Doorgifte kan bijvoorbeeld steunen op een adequaatheidsbesluit, waaronder voor deelnemende Amerikaanse organisaties het EU-US Data Privacy Framework, of op passende waarborgen. Ook dan blijven de overige AVG-beginselen gelden. De vraag is dus niet alleen waar de provider is gevestigd, maar welke entiteit de gegevens ontvangt, onder welk regime, met welke contractuele en technische waarborgen, en voor welk doel.

Ten derde is differential privacy geen algemene AVG-conformiteitsverklaring. Zij kan een sterke maatregel zijn voor een specifiek inferentierisico, maar beantwoordt niet zelfstandig vragen over rechtsgrond, transparantie, doelbinding, bewaartermijnen, rechten van betrokkenen, verwerkerskeuze of doorgifte.

De juiste conclusie is daarom niet dat federated inference met een commerciële API per definitie verboden is. De juiste conclusie is dat de outputgarantie geen bewijs levert voor beheersing van de inputketen.

Drie concurrerende verklaringen

De architectuur kan vanuit drie werkelijk verschillende hypothesen worden beoordeeld.

H1: promptblootstelling domineert het resterende privacyrisico

Volgens H1 is de grootste resterende kwetsbaarheid dat dezelfde leerlinginput naar meerdere providers gaat. Het risico groeit niet door de aggregator, maar door vermenigvuldiging van verwerkingslocaties, loggingregimes en subverwerkers. Het paper ondersteunt deze hypothese doordat het expliciet vermeldt dat providers de ruwe aanvragen kunnen verwerken en loggen en dat de DP-garantie dit niet afdekt.

H2: dataminimalisatie en providerwaarborgen maken de externe route aanvaardbaar

Volgens H2 hoeft API-gebruik niet het dominante risico te zijn. Wanneer prompts geen direct identificerende gegevens bevatten, alleen Q-matrixrelevante kenmerken meenemen, contractueel niet voor training worden gebruikt, kort of niet worden bewaard en onder aantoonbare beveiligings- en doorgiftewaarborgen vallen, kan een externe route een passend beschermingsniveau bereiken. In sommige omgevingen kan een professioneel beheerde provider bovendien veiliger zijn dan een zwak beheerd lokaal model.

H3: de winst komt vooral uit ensemblediversiteit, niet uit federation

Volgens H3 verklaren de verschillende modelsterktes vooral de gemeten nauwkeurigheidswinst. Het paper bevat daarom terecht een eenvoudige drie-model-ensemblebaseline, maar de praktische privacywaarde blijft afhankelijk van hoe de prompts worden samengesteld en waar de modellen draaien. Als alle modellen dezelfde persoonsgegevens ontvangen, is het label federated op zichzelf geen bewijs van dataminimalisatie.

Deze hypothesen voorspellen verschillende observaties. H1 wordt sterker wanneer providerlogs volledige leerlingantwoorden bevatten en meerdere subverwerkers betrokken zijn. H2 wordt sterker wanneer een gegevensstroomanalyse aantoont dat providers alleen geminimaliseerde, niet direct herleidbare kenmerken ontvangen en bewaarbeleid technisch controleerbaar is. H3 wordt sterker wanneer een gecentraliseerd ensemble met dezelfde modellen vergelijkbare nauwkeurigheid haalt en de federated scheiding nauwelijks extra risicoreductie oplevert.

Een toetsbaar architectuurmodel

Een DPIA of security review moet niet vragen of een product "federated" is, maar welke dreiging door welke maatregel wordt afgedekt. Onderstaande minimale Python-check geeft geen juridisch oordeel. Hij voorkomt wel dat output-DP ten onrechte als dekking voor de hele keten wordt geregistreerd.

controls = {
    "prompt_minimisation": True,
    "provider_retention_verified": False,
    "processor_guarantees": True,
    "transfer_mechanism": True,
    "output_dp": True,
}

surfaces = {
    "prompt": ("prompt_minimisation", "provider_retention_verified"),
    "provider": ("processor_guarantees", "transfer_mechanism"),
    "published_output": ("output_dp",),
}

uncovered = [
    surface
    for surface, required in surfaces.items()
    if not all(controls[name] for name in required)
]

assert uncovered == ["prompt"]
print("Openstaande oppervlakken:", ", ".join(uncovered))

Voor (m) modellen en (k) concepten kost de numerieke aggregatie (O(mk)) tijd en (O(k)) extra geheugen wanneer streaming wordt opgeteld. In de praktijk domineren niet deze bewerkingen, maar de parallelle API-latentie, tokenkosten, retries en rate limits. Het toevoegen van een model verhoogt ook het aantal te beoordelen providerrelaties. Architectuurcomplexiteit groeit dus niet alleen computationeel, maar ook bestuurlijk.

Praktijkvoorbeeld: cognitieve diagnostiek bij een gemeente

Stel dat een gemeente een leerplatform inzet voor bijscholing en dat antwoorden van deelnemers worden beoordeeld door drie modelproviders. De aggregator bewaart alleen een geberuisde beheersingsscore. Op papier lijkt de centrale database daardoor privacyvriendelijk.

De gegevensstroom laat echter zien dat iedere provider de oorspronkelijke vrije tekst ontvangt. Die tekst kan namen, werklocaties, beperkingen of andere context bevatten. De eerste vraag is daarom welke persoonsgegevens functioneel noodzakelijk zijn en of de prompt lokaal kan worden geredigeerd of naar kenmerken kan worden omgezet voordat hij de organisatie verlaat.

Vervolgens moeten de rollen van provider en gemeente expliciet zijn, inclusief retentie, modeltraining, menselijke inzage, subverwerkers en internationale doorgiften. Ten slotte is een test nodig die laat zien dat de gekozen DP-parameter de beoogde publicatiedreiging werkelijk beperkt.

Als alleen de laatste vraag wordt beantwoord, is de review onvolledig. Als alle vragen aantoonbaar worden beantwoord, kan een externe route wel degelijk verdedigbaar zijn. Zie voor de bredere valkuil dat lokaal draaien evenmin automatisch privacy bewijst ook Local is geen privacygarantie.

De EU AI Act voegt een tweede beoordelingslaag toe

AI voor onderwijs is niet automatisch high-risk. De classificatie hangt af van het beoogde gebruik. Systemen die toegang, toelating, leeruitkomsten of het passende onderwijsniveau beoordelen en daarmee personen materieel beïnvloeden, vallen onder de relevante categorieën van Annex III. Voor zulke high-risk systemen verlangt artikel 15 een passend niveau van nauwkeurigheid, robuustheid en cybersecurity gedurende de levenscyclus.

Dat verandert de AVG-analyse niet in een AI-Act-analyse. De kaders stellen verschillende vragen. De AVG ziet op persoonsgegevens en verwerking. De AI Act ziet onder meer op systeemrisico, kwaliteitsbeheer, documentatie, menselijk toezicht en robuustheid. Een organisatie moet daarom kunnen aantonen welke maatregel welk wettelijk en technisch risico adresseert. Eén privacyparameter kan niet als vervanging dienen voor ketenbeveiliging, leveranciersbeheer of menselijke controle.

Wat zou de hoofdthese falsifiëren?

De hoofdthese luidt niet dat externe API's altijd onrechtmatig zijn. Zij luidt dat in deze architectuur queryblootstelling een afzonderlijk, potentieel dominant risico vormt dat niet door output-level DP wordt afgedekt.

Een onafhankelijke replicatie falsifieert de hoofdthese of verzwakt haar materieel wanneer zij de volgende observaties bevestigt.

1. de provider geen persoonsgegevens of herleidbare vrije tekst ontvangt;
2. input-side bescherming de relevante kenmerken behoudt zonder de oorspronkelijke antwoorden prijs te geven;
3. retentie en secundair gebruik technisch controleerbaar zijn;
4. een geldige verwerkers- en doorgifteconstructie bestaat;
5. een aanvalstest geen betekenisvolle reconstructie uit prompts, logs of outputs oplevert.

Als die observaties standhouden, is (R_{prompt}) niet langer het dominante resterende risico en wint H2 aan verklaringskracht. Alleen een contractuele belofte zonder technische of auditbare onderbouwing discrimineert niet tussen H1 en H2.

Counterfactual: wat als de commerciële API verdwijnt?

In het tegenfeitelijke ontwerp draaien alle modellen binnen de eigen beveiligingsgrens. Dan verdwijnt providerblootstelling grotendeels, maar ontstaan nieuwe risico's: beheer van modelgewichten, patching, capaciteit, logging, insider access en mogelijk slechtere modelkwaliteit. Zelfhosting verlaagt dus één risicocomponent en kan andere verhogen.

Een tweede counterfactual past input-side DP of sterke feature-extractie toe voordat de provider wordt benaderd. Dat kan promptblootstelling beperken, maar agressieve perturbatie kan juist diagnostische signalen vernietigen. De bruikbare ontwerpvraag is daarom niet "cloud of lokaal", maar welke configuratie de totale risicoverdeling aantoonbaar verbetert zonder de taak onbetrouwbaar te maken.

Beperkingen en onzekerheid

Het paper is een onderzoeksresultaat, geen audit van een operationele onderwijsdienst en geen juridische conformiteitsbeoordeling. De experimenten meten voornamelijk voorspellingsfout en privacy-utility trade-offs. Zij meten niet rechtstreeks misbruik door providers, feitelijke bewaartermijnen, succes van promptreconstructie of naleving van verwerkersafspraken.

De gerapporteerde benchmarkresultaten zijn daarom ESTABLISHED binnen de beschreven experimentele opzet, maar niet automatisch generaliseerbaar naar Nederlandse publieke organisaties. Dat de DP-garantie de API-input niet omvat is ESTABLISHED, omdat de auteurs dit expliciet afbakenen. Dat promptblootstelling in een concrete implementatie het dominante risico is, blijft PROBABLE en moet met een gegevensstroomanalyse en aanvalstest worden vastgesteld. De juridische uitkomst voor één organisatie is UNKNOWN zonder kennis van doel, data, rollen, contracten en doorgiftemechanisme.

Ook de secundaire aanleiding over contractuele aansprakelijkheid bewijst niet dat iedere exoneratieclausule onder alle omstandigheden ongeldig is. Artikel 82 AVG verdeelt aansprakelijkheid en kent verweermogelijkheden. De robuuste conclusie is smaller: private afspraken heffen wettelijke verplichtingen tegenover betrokkenen en toezichthouders niet op.

Conclusie: ontwerp privacy per grens

Het paper levert een serieuze bijdrage: heterogene modellen kunnen op voorspelniveau worden gecombineerd en de gedeelde uitkomst kan met local differential privacy worden beschermd. Het maakt tegelijk ongewoon helder waar die garantie stopt. De ruwe aanvraag kan nog steeds door iedere API-provider worden verwerkt.

Voor architecten, FG's en CISO's volgt daaruit één praktische regel: accepteer nooit een architectuurlabel als bewijs. Leg per gegevensstroom vast wie de invoer ziet, wat wordt opgeslagen, welke aanvaller in scope is en welke maatregel die dreiging beperkt. Federated inference kan centrale aggregatierisico's verkleinen. AVG-verantwoording ontstaat pas wanneer ook de prompt-, provider- en doorgiftegrens aantoonbaar zijn beheerst.

Bronnen

• Boyapati, Y.M. et al. (2026), Privacy-Preserving Heterogeneous Multi-LLM Federated Inference for Cognitive Diagnosis, arXiv:2609.02947v1. Abstract en PDF
• Verordening (EU) 2016/679, met name artikelen 28, 32, 44-46 en 82. EUR-Lex
• European Data Protection Board, International data transfers. EDPB
• Europese Commissie, EU-US data transfers. Europese Commissie
• Verordening (EU) 2024/1689, met name artikel 15 en Annex III. EUR-Lex