Konfidentialitet och förtroende för leverantören

Integritet är inte hela frågan

Att ta bort ert namn från ett dokument innebär inte att idén i dokumentet förlorar sitt värde. Skyddet av personuppgifter och affärshemligheter överlappar varandra, men de är inte samma löfte.

Vad Navier–Stokes-tvisten visar om förtroende för en leverantör

I september 2026 publicerade forskare en AI-assisterad lösning på ett långvarigt problem inom strömningsmekaniken, Navier–Stokes-ekvationerna. Kort därefter uppstod en debatt om huruvida forskarnas konfidentiella arbete indirekt hade påverkat OpenAI:s modeller, sedan OpenAI oberoende av dem hävdat att företaget hade löst samma problem med hjälp av sin egen modell.

När OpenAI tillfrågades om forskarnas Navier–Stokes-resultat uppgav företaget i sin första redogörelse att det inte kunde utesluta att avidentifierade data som härletts från deras användning av företagets produkter hade bidragit till att förbättra modellerna. I en uppföljning på OpenAI:s sida uppgavs att deras promptar från de föregående två månaderna inte kunde ha påverkat systemet, inte heller genom träning.

Uppföljningen är ett uttalande om företagets egen utredning. I de publicerade redogörelserna kom både osäkerheten och försäkran från OpenAI; kunden fick inte tillgång till de underliggande bevisen för att kunna göra en självständig granskning. Det bevisar inte att missbruk har skett. Det blottlägger kärnproblemet: leverantören sitter på den bevisning som behövs för att pröva dess redogörelse.

Och avidentifiering är inte detsamma som att ta bort värde. Ta bort namnet från ett dokument och det kan fortfarande innehålla en opublicerad metod, en prismodell, en strategi. Det en konkurrent helst vill ha är vanligtvis inte de personuppgifter som GDPR skyddar.

Avtalet avgör vad som räknas som ”kunddata”

Avtal skiljer mellan ”kunddata” och annat material som systemet genererar. Vid den gränsen börjar värde läcka ut. Inbäddningar, mellanliggande tillstånd, cacheinnehåll, utvärderingsloggar och härledd statistik klassas inte alltid som kunddata, och en definition som skrevs när en produkt var ny förutser sällan AI-genererade resultat med ett eget kommersiellt liv.

Incitamenten är inte neutrala. Träningsdata är en värdefull tillgång för ett AI-företag, och användarinnehåll kan vara en riklig källa till sådana data. En leverantör som kan behandla en representation av era indata som något annat än kunddata har hittat ett sätt att använda ert material utan att ge er de rättigheter ni trodde att ni hade. Avtalen skrivs av den part som har starkast skäl att vidga definitionen.

Det är värt att fråga rakt ut vilka av dessa som omfattas: råa promptar, färdiga utdata, inbäddningar som kodar innebörden av det ni skickade, innehållet i en kontextcache eller KV-cache som håller ert material under en förfrågan, och aggregerad statistik som härletts från er användning. Om svaret är ”bara råa indata” kan den mest återanvändbara formen av era data redan ligga utanför löftet.

Leverantören kan läsa det ni skriver när den väljer att göra det

OpenAI har med egna ord visat att företaget läser promptinnehåll och agerar utifrån det. Dess hotrapport från juni 2026 beskriver grupper av ChatGPT-konton som företaget bedömde vara hemliga påverkansoperationer och stängde av, och citerar och sammanfattar vad användarna bad modellen att generera. Med andra ord: leverantören granskade specifika användares promptaktivitet och vidtog åtgärder utifrån den. Rapporten framställer dessa åtgärder som svar på hemliga påverkansoperationer.

Det här publicerade exemplet visar att användares aktiviteter granskas och att åtgärder kan vidtas mot deras intressen. I just det här fallet blev denna inblandning känd för allmänheten. Användare har ingen oberoende möjlighet att veta om och när deras egna data granskas, lagras, används eller leder till åtgärder bakom leverantörens kontrollsystem.

Inget av detta behöver vara illasinnat för att vara av betydelse. Era indata passerar någon annans maskiner, loggar och bedömningar. Tjänsteavtalet anger löften om dataanvändning i avsnitt 4.2; det ger er inte direkt insyn i hur löftena genomförs.

Routningstjänster lägger till fler händer som era data måste passera

Aggregatorer som ligger framför många modellleverantörer, som OpenRouter, utökar den sårbara ytan. OpenRouter uppger i sin egen dokumentation att tjänsten inte lagrar promptar som standard och erbjuder en inställning för att undvika routning till leverantörer som kan träna på era data. Inställningen finns eftersom vissa av leverantörerna bakom en router faktiskt tränar på det de tar emot.

Granskningsfrågan kvarstår även med inställningar för nollagring (Zero-retention): vilken bevisning kan varje part lägga fram för att den överenskomna policyn tillämpades på er förfrågan, inklusive härledda data och radering? Dokumentationen beskriver löftet; den verifierar inte i sig att det efterlevs.

En enda förfrågan kan alltså passera flera företag, vart och ett med sina egna villkor för lagring och träning, och ni förväntas känna till och lita på dem alla. En gateway ger bekvämlighet, men lägger också till fler parter: fler platser där ert innehåll finns, fler policyer att lita på, fler brister som ni inte kan upptäcka.

En företagspolicy stoppar inte läckan

Många organisationer har policyer: lägg inte konfidentiellt material i en AI-tjänst. Policyn är nödvändig, men svag på egen hand. En proxy eller gateway kan konfigureras för att fånga upp uppenbara personuppgifter innan de lämnar organisationen, och GDPR:s sanktionsavgifter ger organisationen skäl att försöka. OpenAI:s integritetspolicy för kommunikation är ett exempel på den omfattning och de begränsningar som en leverantör själv formulerar. Men ett filter för personuppgifter är inte ett filter för hemligheter.

Personuppgifter följer ofta ett mönster; en företagshemlighet är värdefull just för att den är specifik — en formel, en förhandlingsposition i ett avtal, en ännu inte lanserad konstruktion eller design, ett anbud. Ett filter för personuppgifter kan inte skilja en hemlighet från harmlös text; en skriven policy kan inte ensam förhindra att de röjs. Den förlust som betyder mest är också svårast att skydda sig mot och svårast att kvantifiera. En personuppgiftsincident kan medföra en sanktionsavgift; en konkurrent som i tysthet får reda på er strategi kan ha tagit något som aldrig syns i någon incidentrapport, och det kanske inte finns något praktiskt sätt att bevisa att det hände eller att få tillbaka det.

Egen krypteringsnyckel (BYOK — Bring Your Own Key) löser mindre än vad den lovar

Tänk på en hårdvarusäkerhetsmodul (HSM). En HSM är en manipulationsskyddad enhet som utför kryptering och dekryptering medan den skyddade nyckeln stannar inuti enheten. Det är ett starkt skydd för en lagrad nyckel.

Begränsningen ligger i var enheten är placerad. HSM:en finns i leverantörens miljö, och för att använda den passerar data och nycklar genom leverantörens processer. En symmetrisk nyckel på väg till en HSM kan observeras av den som driver utrustningen — leverantören driver just de system som förflyttar nyckeln under överföringen. Kryptering inuti ett system som ni inte själva driver är inte kryptering som skyddar mot systemets operatör.

Löften om personal har samma form. En policy om att bara anställa EU-medborgare säger något om vilka som anställs; den säger ingenting om vad ett amerikanskt moderbolag kan tillhandahålla: en nyckel, ett underhållsgränssnitt, en konstruktionsändring — inget av det kräver en EU-anställd. Det här är verkliga riskbegränsningar. De minskar angreppsytan. De tar inte bort det förtroende som kvarstår – förtroendet för att en leverantör i praktiken kommer att avstå från att göra något som den faktiskt kan göra.

Frågan är vad ni faktiskt kan verifiera

Inget av detta innebär att leverantörer är fientligt inställda. Det innebär att konfidentialitet vilar på en blandning av vad ni kan granska, vad ni måste lita på försäkringar om och vilka möjligheter till gottgörelse som finns om försäkringen sviker. För varje lager — en modellleverantör, en aggregator, en nyckelhanteringsfunktion, en personalpolicy — fråga vilken bevisning ni kan granska i stället för att räkna ännu en policy som ytterligare en garanti.

Det är den luckan en dedikerad driftmiljö tar itu med. Med hårdvara dedikerad till en enda kund bestämmer ni själva dataflöden, loggning och åtkomstarrangemang, och ert innehåll passerar inte genom en operatörs delade tjänster. Det tar inte bort risker i programvara, säkerhet eller mänskligt agerande. Det flyttar gränsen för vad ni faktiskt kan verifiera till den plats där ert innehåll faktiskt befinner sig.

Källor och vidare läsning

Prata med oss om era behov