ChatGPT OpenAI agents crypto

Opinie: AI-agents mogen privacy niet stilletjes verlagen

kunstmatige intelligentie•
Een AI-agent mag niet zelfstandig besluiten dat beschikbaarheid belangrijker is dan de privacykeuze van zijn gebruiker. Valt een model uit, dan mag een alternatieve route alleen worden gebruikt wanneer de afgesproken bescherming gelijk blijft of sterker wordt.
Kan dat niet, dan moet de opdracht stoppen. Of de gebruiker moet vooraf bewust toestemming hebben gegeven voor die zwakkere route.
Dat lijkt streng. Het is dezelfde logica die we bij geld vanzelfsprekend vinden.

Een bestedingslimiet verdwijnt ook niet bij een fallback

Geef een AI-agent toestemming om maximaal €10 uit te geven en niemand verwacht dat een alternatieve betaalprovider dat bedrag stilletjes mag verhogen naar €50.
De limiet hoort bij de opdracht.
Niet bij één specifieke technische route.
Privacy zou op dezelfde manier moeten werken.
Wie kiest voor verwerking binnen een beveiligde uitvoeringsomgeving, geeft daarmee niet automatisch toestemming om dezelfde tekst naar een gewone externe modelprovider te sturen zodra het eerste model druk of offline is.
De opdracht blijft hetzelfde. De voorwaarden horen daarom mee te reizen.

NEAR AI laat zien dat 'privé' meerdere dingen kan betekenen

De modelcatalogus van NEAR AI maakt het probleem opvallend zichtbaar.
Daar staan meerdere privacyklassen naast elkaar.
Bij Private TEE draait het model volgens NEAR AI in een beveiligde enclave op de eigen systemen. De dienst zegt daarbij dat zelfs NEAR AI de prompts niet kan zien en biedt een attestationrapport om die uitvoering te controleren.
Bij Private 3P TEE draait het model eveneens in een afgeschermde omgeving, maar bij een derde partij.
Daarnaast bestaat Incognito.
Bij die route verbergt een beveiligde router de identiteit van het account, terwijl het model bij de externe leverancier zelf draait. NEAR AI vermeldt daar expliciet bij dat geen hardwarematige privacygarantie geldt.
Dat zijn geen cosmetische labels.
Het zijn verschillende afspraken over wie gegevens kan verwerken en onder welke technische bescherming.

Een andere route kan dus een andere belofte zijn

Stel dat een gebruiker bewust voor Private TEE kiest omdat een tekst vertrouwelijke financiële gegevens bevat.
Het gewenste model blijkt tijdelijk niet beschikbaar.
Een router kan vervolgens een ander model vinden dat dezelfde taak aankan en misschien zelfs sneller antwoordt.
Maar wanneer dat alternatief onder Incognito valt, verandert er meer dan alleen het model.
De gegevens gaan nu naar een externe leverancier zonder dezelfde enclavegarantie.
Functioneel kan de opdracht identiek zijn.
De privacyvoorwaarde is dat niet.
Een automatische fallback zou in dat geval volgens ons standaard moeten worden geblokkeerd.

OpenRouter bewijst dat zo'n harde grens technisch kan

Dat principe is geen theoretisch productidee.
OpenRouter documenteert hoe Zero Data Retention als routeringsvoorwaarde kan worden afgedwongen.
ZDR betekent daar dat een uitvoerende provider de gegevens niet opslaat.
Die eis kan accountbreed, via een guardrail of voor een afzonderlijk verzoek worden ingesteld.
Het interessante detail zit in de voorrang.
Een individueel verzoek kan de bescherming aanscherpen, maar een bestaande accountbrede ZDR-eis niet uitschakelen.
OpenRouter behandelt de instellingen als een logische OF-voorwaarde: zodra één toepasselijke regel ZDR eist, moet de router alleen geschikte endpoints gebruiken.
Dat is precies het gedrag dat privacyvoorwaarden breder nodig hebben.

ZDR is alleen niet hetzelfde als vertrouwelijke uitvoering

Daarmee is OpenRouter niet automatisch een volledig voorbeeld voor iedere privacyeis.
Zero Data Retention gaat in de eerste plaats over bewaren.
Het zegt niet dat een modelprovider de invoer tijdens de verwerking zelf niet kan zien.
Een beveiligde enclave probeert een ander probleem op te lossen.
Ook gegevenslocatie, externe zoekfuncties, gekoppelde tools en aanvullende verwerkers kunnen afzonderlijke voorwaarden hebben.
Daarom is één knop met “privacy” onvoldoende.
Een agent moet weten welke bescherming de gebruiker verlangt.

Maak privacy van een label tot een set voorwaarden

Een praktische instelling kan uit meerdere onderdelen bestaan.
Bijvoorbeeld: geen opslag door de uitvoerder, alleen verwerking in een aantoonbaar afgeschermde omgeving, geen doorgifte aan aanvullende leveranciers en geen externe zoekopdrachten met de oorspronkelijke invoer.
Een alternatief model hoeft dan niet van hetzelfde bedrijf te komen.
Het hoeft zelfs niet hetzelfde modeltype te zijn.
Het moet alleen aan de gekozen voorwaarden blijven voldoen.
Dat maakt de regel technologieneutraal.
Een betere provider kan morgen probleemloos worden toegevoegd zolang de afgesproken grens overeind blijft.

Controle moet vóór verzending plaatsvinden

Timing is hier alles.
Een waarschuwing nadat de prompt al naar een andere leverancier is gestuurd, is waardeloos.
De router moet vóór iedere overdracht controleren of de volgende uitvoerder binnen de toegestane privacyvoorwaarden valt.
Voldoet hij eraan, dan gaat de opdracht door.
Voldoet hij niet, dan zijn er twee nette uitkomsten: stoppen of toestemming vragen.
Niet eerst verzenden en achteraf melden dat voor deze ene aanvraag een andere route nodig bleek.
Vertrouwelijke data kun je na verzending niet terughalen met een melding.

Het sterkste bezwaar is beschikbaarheid

Daar staat een serieus probleem tegenover.
Harde privacyvoorwaarden verkleinen de beschikbare modelpool.
Een geschikt model kan tijdelijk uitvallen. Een alternatief binnen dezelfde beschermingsklasse kan duurder of trager zijn. Soms bestaat er helemaal geen gelijkwaardig alternatief.
Een privacygrens kan daardoor betekenen dat een belangrijke opdracht mislukt.
Dat is geen denkbeeldig nadeel.
Voor een agent die processen zelfstandig moet afmaken, is betrouwbaarheid juist een groot deel van zijn waarde.

Laat de gebruiker daarom vooraf een fallbackladder kiezen

De oplossing is niet om privacy bij storing automatisch los te laten.
Geef gebruikers vooraf verschillende niveaus.
Voor openbare teksten kan iemand bijvoorbeeld toestaan dat de agent iedere beschikbare aanbieder gebruikt.
Voor interne documenten kan de regel zijn: geen opslag, maar verschillende providers zijn toegestaan.
Voor zeer gevoelige data kan de eis juist luiden: alleen aantoonbare enclaveverwerking, anders stoppen.
Daarmee hoeft een gebruiker niet bij iedere modelwissel een pop-up te beantwoorden.
De toestemming reist vooraf mee met het soort taak.
Beschikbaarheid blijft dan een keuze die de gebruiker zelf maakt, in plaats van een reden waarom de agent zijn voorwaarden achteraf herschrijft.

Ook toestemming moet specifiek genoeg zijn

Een algemene instelling als “gebruik alternatieven wanneer nodig” is daarvoor te vaag.
Alternatieven kunnen verschillen in prijs, prestaties én gegevensverwerking.
Een bruikbare toestemming zegt bijvoorbeeld dat bij uitval een externe provider zonder opslag mag worden gebruikt, maar geen provider die prompts bewaart.
Dan weet de router werkelijk waar de grens ligt.
Hetzelfde principe kennen we al van financiële agents.
“Betaal deze rekening” betekent niet automatisch “betaal ieder bedrag via iedere rekening die beschikbaar is”.

Providers moeten de werkelijke route ook vastleggen

Een tweede vereiste is controle achteraf.
Een dienst zou per opdracht moeten kunnen tonen welk model de taak uitvoerde, bij welke provider dat gebeurde en welke privacyklasse op dat moment gold.
Niet ieder technisch detail hoeft standaard in beeld te staan.
Maar gebruikers en zakelijke klanten moeten wel kunnen controleren of de ingestelde grens werkelijk is gevolgd.
Zonder zo'n spoor blijft een privacybeleid vooral een belofte van de router zelf.

Deze norm moet ook voor onze eigen redactie gelden

CryptoBenelux kan zo'n regel alleen geloofwaardig verdedigen wanneer we hem ook op onze eigen AI-processen toepassen.
Een openbaar persbericht mag technisch anders worden behandeld dan een nog niet gepubliceerd onderzoeksdossier, vertrouwelijke correspondentie of ruwe broninformatie.
Wanneer voor zo'n gevoelige taak een afgeschermde route is gekozen, hoort een storing niet automatisch toestemming te geven voor een minder beschermde provider.
Dan mag snelheid plaatsmaken voor een foutmelding.
Dat is soms irritant. Het is wel helder.

Privacy moet een constraint worden, geen voorkeur

AI-agents krijgen steeds meer ruimte om zelf modellen, tools en leveranciers te kiezen.
Juist daardoor is een privacyinstelling die alleen bij de eerste stap geldt onvoldoende.
De afspraak moet onderdeel worden van de opdracht zelf.
Een fallback mag sneller zijn. Goedkoper. Slimmer. Of technisch compleet anders.
Maar wanneer hij de afgesproken gegevensbescherming verlaagt, is het geen gelijkwaardige fallback meer.
Dan is het een nieuwe overeenkomst.
En voor die overeenkomst hoort de gebruiker aan zet te zijn.

Stop met te veel betalen voor je crypto. Bij de Amsterdamse exchange Finst handel je tegen de laagste tarieven van Nederland, zonder verborgen kosten.

👀 Bekijk Finst nu ›

Let op: Beleggen in crypto brengt risico’s met zich mee. Handel alleen met geld dat u kunt missen.

Ga verder met lezen
loading
Dit vind je misschien ook leuk
Laat mensen jouw mening weten

Loading