Konfidensialitet og leverandørtillit
Personvern er ikke hele spørsmålet
Å fjerne navnet deres fra et dokument fjerner ikke verdien av ideen inni det. Personvern og forretningskonfidensialitet overlapper, men de er ikke den samme løftet.
Hva Navier–Stokes-tvisten viser om å stole på en leverandør
I september 2026 publiserte forskere en AI-assistert løsning på et langvarig problem i fluidmekanikk, Navier–Stokes-ligningene. Kort tid etter oppsto debatt om hvorvidt forskernes konfidensielle arbeid indirekte hadde påvirket OpenAIs modeller, etter at OpenAI uavhengig hevdet å ha løst det samme problemet med sin egen modell.
Da OpenAI ble spurt om forskernes Navier–Stokes-resultat, sa den første redegjørelsen at selskapet ikke kunne utelukke at avidentifiserte data utledet fra deres bruk av produktene hadde bidratt til å forbedre modellene. En oppfølging publisert på OpenAI-siden sa at forespørslene deres fra de to foregående månedene ikke kunne ha påvirket systemet, inkludert gjennom trening.
Oppfølgingen er en uttalelse om selskapets egen etterforskning. I de publiserte redegjørelsene kom både usikkerheten og beroligelsen fra OpenAI; kunden fikk ikke de underliggende bevisene til å revidere uavhengig. Det etablerer ikke misbruk. Det avslører kjerneproblemet: leverandøren sitter på bevisene som trengs for å teste redegjørelsen.
Og avidentifisering er ikke det samme som å fjerne verdi. Fjern navnet fra et dokument, og det kan fortsatt inneholde en upublisert metode, en prismodell, en strategi. Det en konkurrent helst vil ha, er vanligvis ikke personopplysningspunktene som GDPR beskytter.
Hva som regnes som «Customer Data» bestemmes av kontrakten
Kontrakter skiller mellom «Customer Data» og annet materiale systemet genererer. Det er der verdien begynner å lekke ut. Innebygginger (embeddings), mellomtilstander, cache-innhold, evalueringslogger og utledede statistikker er ikke alltid klassifisert som kundedata, og en definisjon skrevet mens produktet var nytt, antar sjelden en AI-utdata med eget kommersielt liv.
Insentivet er ikke nøytralt. Treningsdata er en verdifull eiendel for et AI-selskap, og brukerinnhold kan være en rikelig kilde til det. En leverandør som kan behandle en representasjon av det dere sender inn som ikke-kundedata, har funnet en måte å bruke materialet deres på uten å gi dere rettighetene dere trodde dere hadde. Disse kontraktene er skrevet av parten med sterkest grunn til å utvide definisjonen.
Det er verdt å spørre direkte hvilke av disse som dekkes: rå forespørsler, ferdige utdata, innebygginger som koder betydningen av det dere sendte, innholdet i en kontekst- eller KV-cache som holder materialet deres under en forespørsel, og aggregerte statistikker utledet fra bruken deres. Hvis svaret er «kun rå innputt», kan den mest gjenbrukbare formen av dataene deres allerede være utenfor løftet.
Leverandøren kan lese det dere skriver når den velger det
OpenAI har demonstrert, med egne ord, at selskapet leser forespørselsinnhold og handler på det. Dens trusselrapport fra juni 2026 beskriver klynger av ChatGPT-kontoer som selskapet vurderte som skjulte påvirkningsoperasjoner og utestengte, og siterer og oppsummerer hva disse brukerne ba modellen generere. Med andre ord: leverandøren undersøkte spesifikke brukeres forespørselsaktivitet og tok grep basert på den. Rapporten presenterer disse handlingene som svar på skjulte påvirkningsoperasjoner.
Dette publiserte eksemplet viser at brukeres aktivitet gjennomgås, og at tiltak kan tas mot deres interesser. I dette konkrete tilfellet ble den innblandingen gjort kjent for offentligheten. Brukere har ingen uavhengig måte å vite om og når deres egne data gjennomgås, beholdes, brukes eller behandles bak leverandørens kontroller.
Ingenting av dette trenger å være ondsinnet for å ha betydning. Innsendelsene deres går gjennom andres maskiner, logger og vurderinger. Tjenesteavtalen fastsetter databruksløfter i seksjon 4.2; den gir dere ikke direkte innsyn i hvordan disse løftene gjennomføres.
Rutingsleverandører legger til aktører dataene deres må gjennom
Aggregatorer som står foran mange modellleverandører, som OpenRouter, gjør den sårbare overflaten større. OpenRouter oppgir, i sin egen dokumentasjon, at det ikke lagrer forespørsler som standard, og tilbyr en innstilling for å unngå ruting til leverandører som kan trene på dataene deres. Den innstillingen finnes fordi noen av leverandørene bak en ruter faktisk trener på det de mottar.
Revisjonsspørsmålet står likevel også med innstillinger for null lagring: hvilke bevis kan hver part gi på at den avtalte politikken ble anvendt på forespørselen deres, inkludert utledede data og sletting? Dokumentasjon beskriver løftet; den verifiserer ikke i seg selv utførelsen.
Så én forespørsel kan gå gjennom flere selskaper, hver med egne lagrings- og treningsvilkår, og dere forventes å kjenne til og stole på alle. En gateway tilfører bekvemmelighet, og den tilfører også aktører: flere steder der innholdet deres finnes, flere politikkområder å stole på, flere feil dere ikke kan observere.
Bedriftspolitikk stopper ikke lekkasjen
Mange organisasjoner har politikk på plass: ikke legg konfidensielt materiale inn i en AI-tjeneste. Politikken er nødvendig, og alene er den svak. En proxy eller gateway kan konfigureres til å fange opp åpenbare personopplysninger før de forlater organisasjonen, og GDPR-bøtene gir en organisasjon en grunn til å forsøke. OpenAIs personvernpolicy for kommunikasjon er et eksempel på omfanget og grensene en leverandør skriver for seg selv. Men et filter for personopplysninger er ikke et filter for hemmeligheter.
Personopplysninger følger ofte et mønster; en forretningshemmelighet er verdifull nettopp fordi den er særegen — en formel, en kontraktsposisjon, et upublisert design, et bud. Et filter for personopplysninger kan ikke skille en hemmelighet fra uskyldig tekst; en skriftlig policy alene kan ikke forhindre at de avsløres. Tapet som betyr mest, er også det vanskeligste å forsvare seg mot og det vanskeligste å kvantifisere. Et brudd på personopplysninger har en bot knyttet til seg; en konkurrent som stille lærer strategien deres, kan ha tatt noe som ikke vises i noen bruddrapport, og det kan finnes ingen praktisk måte å bevise at det skjedde eller få det tilbake.
Ta med deres egen nøkkel løser mindre enn den lover
Tenk på en maskinvaremodul for sikkerhet (HSM). En HSM er en manipulasjonssikker enhet som utfører kryptering og dekryptering mens den holder den beskyttede nøkkelen inne i enheten. Det er sterk beskyttelse for en nøkkel i hvile.
Grensen er hvor enheten står. HSM-en lever i leverandørens miljø, og for å bruke den reiser data og nøkler gjennom leverandørens prosesser. En symmetrisk nøkkel som reiser til en HSM, kan observeres av den som driver maskineriet — leverandøren opererer de samme systemene som flytter nøkkelen i transitt. Kryptering inne i et system dere ikke opererer, er ikke kryptering fra det systemets operatør.
Personalløfter har samme form. En ansettelsespolitikk kun for EU-borgere sier noe om hvem som er ansatt; den sier ingenting om hva et amerikansk morselskap kan levere: en nøkkel, et vedlikeholdsgrensesnitt, en designendring — ingenting av det krever en EU-ansatt. Dette er reelle avbøtende tiltak. De innsnevrer angrepsoverflaten. De fjerner ikke tilliten som gjenstår — tilliten til at en leverandør i praksis vil avstå fra å gjøre noe den er i stand til å gjøre.
Det dere faktisk kan verifisere, er spørsmålet
Ingenting av dette betyr at leverandører er fiendtlige. Det betyr at konfidensialitet hviler på en blanding av det dere kan inspisere, det dere må ta på tro og love, og hvilken bot som finnes hvis løftet svikter. For hvert lag — en modellleverandør, en aggregator, en nøkkelhåndteringsfunksjon, en personellpolicy — spør hvilke bevis dere kan inspisere i stedet for å telle nok en policy som nok en garanti.
Det er gapet en dedikert installasjon tette. Med maskinvare dedikert til én kunde setter dere dataflyten, loggingen og tilgangsordningene, og innholdet deres går ikke gjennom en operatørs delte tjenester. Det sletter ikke programvare-, sikkerhets- eller menneskelig risiko. Det flytter grensen dere faktisk kan verifisere, dit innholdet deres faktisk er.
Kilder og videre lesning
- Opprinnelig uttalelse fra 8. september om Navier–Stokes (arkivert)
- OpenAIs nåværende redegjørelse, inkludert oppdateringen fra 10. september
- OpenAIs trusselrapport fra juni 2026 (PDF)
- OpenRouter: hva det lagrer, og hva som er av som standard
- OpenRouter: leverandørenes lagrings- og treningspolitikk
- OpenAIs personvernpolicy og avgrensninger
- OpenAIs tjenesteavtale, seksjon 4.2
- Amplify: AI-native ingeniørarbeid og IP-kontrakter (kommentar)