Vad är zero data retention (ZDR)?

Av Weapp · Uppdaterad

Zero data retention (ZDR) innebär att AI-leverantören varken sparar dina prompts eller modellens svar efter att anropet besvarats. Det skiljer sig från löftet om 'ingen träning', som inte utesluter lagring för till exempel missbruksdetektering. Hos de stora leverantörerna är ZDR något du förhandlar fram per avtal, inte en knapp du slår på.

När känsliga uppgifter skickas till en AI-tjänst blir en fråga central: vad händer med datan efter att svaret kommit tillbaka? Zero data retention – ZDR – är leverantörernas svar på just det. Men begreppet missförstås ofta, och det ser sällan ut som en enkel inställning.

Definitionen

Zero data retention innebär att leverantören inte sparar vare sig din prompt eller modellens svar efter att anropet har besvarats. Datan behandlas i stunden för att generera svaret och lagras sedan inte – den finns inte kvar i loggar eller mellanlagring efteråt.

Det är en starkare utfästelse än den vanligaste formuleringen, “vi tränar inte på din data”. Skillnaden är viktig och underskattas ofta.

ZDR är inte samma sak som “ingen träning”

Många leverantörer lovar att din data inte används för att träna modellen. Det är bra, men det säger ingenting om lagring. Data kan mycket väl sparas en tid även om den aldrig tränar modellen – exempelvis för att upptäcka missbruk, felsökning eller support.

ZDR tar bort själva lagringen. En leverantör kan alltså erbjuda “ingen träning” utan att erbjuda ZDR. När du läser villkor är det värt att skilja på de två: den ena skyddar mot att din data förbättrar en framtida modell, den andra mot att den finns kvar över huvud taget.

För en verksamhet som hanterar känsliga uppgifter är det ofta den andra frågan som väger tyngst. Om prompterna innehåller personuppgifter eller affärshemligheter spelar det mindre roll att de inte tränar modellen – risken ligger i att de över huvud taget lagras hos leverantören, i loggar som kan nås vid en incident eller en myndighetsbegäran. Då räcker inte “ingen träning” som svar; det är lagringen i sig som behöver bort. Att veta vilken av de två utfästelserna ett avtal faktiskt ger är därför avgörande för att kunna bedöma om tjänsten passar för känsliga flöden.

En förhandling, inte en knapp

Det största missförståndet är att ZDR skulle vara en inställning man aktiverar. Hos de stora leverantörerna är det snarare en förhandling som förs i avtalsprocessen.

Vägarna dit skiljer sig åt. Förenklat kan det handla om en begäran inom ett enterprise-avtal, ett godkännande från leverantörens säljsida, eller en särskild ansökan om begränsad åtkomst. Gemensamt är att det kräver ett aktivt steg och ofta ett skriftligt godkännande – inte ett klick.

Dessutom kan vissa endpoints vara undantagna även när ZDR beviljats. Ett konkret scenario: ett bolag får ZDR bekräftat för sina huvudsakliga anrop, men en särskild funktion visar sig ligga utanför överenskommelsen. Slutsatsen är att villkoren måste bekräftas per endpoint och modell, inte för leverantören i stort.

Kräv villkoren skriftligt

Eftersom retention-dagar och undantagslistor ändras över tid är siffror i artiklar och blogginlägg en osäker grund. Det som gällde förra året kan vara inaktuellt idag, och det som gäller en endpoint behöver inte gälla en annan.

Förlita dig på principen – att ZDR måste begäras, godkännas och gälla per endpoint – och kräv de aktuella villkoren skriftligt från leverantören för varje endpoint och modell ni använder. Då står din dokumentation på avtalet, inte på en tredjehandsuppgift.

Frågor att ställa till leverantören

När du utvärderar ZDR i ett avtal är det några konkreta frågor som skär igenom marknadsföringen:

  • Sparas prompt och svar efter besvarat anrop – ja eller nej? Skilj tydligt på detta från frågan om träning.
  • Gäller ZDR alla endpoints och modeller vi ska använda, eller är några undantagna? Be om undantagen skriftligt.
  • Hur beviljas ZDR – och vad krävs av oss för att aktivera det? Ansökan, enterprise-avtal, godkännande?
  • Vad gäller för loggar som skapas för missbruksdetektering eller support? Även med “ingen träning” kan sådan lagring finnas.

Svaren hör hemma i avtalet eller ett skriftligt tillägg. En muntlig utfästelse eller en hänvisning till en generell hjälpsida räcker inte som dokumentation den dag någon frågar.

Vill du se hur ZDR hänger ihop med residens, överföringsmekanismer och myndighetsåtkomst i ett helt AI-projekt finns mer på vår AI-sida. Behöver du hjälp att reda ut vad ett leverantörsavtal faktiskt säger om lagring? Hör av dig så går vi igenom det tillsammans.

Vanliga frågor

Är zero data retention samma sak som att datan inte används för träning?

Nej, det är två olika saker. 'Ingen träning' betyder att din data inte tränar modellen, men den kan ändå lagras en tid, till exempel för missbruksdetektering eller support. ZDR går längre: varken prompt eller svar sparas efter besvarat anrop. En leverantör kan alltså lova det ena utan det andra.

Kan jag bara slå på ZDR i tjänsten?

Sällan. Hos de stora leverantörerna är ZDR en förhandling snarare än en inställning. Det kan kräva en ansökan, ett godkännande från säljorganisationen eller ett enterprise-avtal. Utgå inte från att en kryssruta räcker – kravet måste oftast lyftas i avtalsprocessen och bekräftas skriftligt.

Gäller ZDR för alla modeller och endpoints?

Inte nödvändigtvis. Även när ZDR är beviljat kan vissa endpoints eller funktioner vara undantagna. Det är därför man måste bekräfta villkoren per endpoint och modell, inte för leverantören som helhet. En generell utfästelse på leverantörsnivå säger lite om just det anrop din tjänst gör.

Hur ansöker man om ZDR hos de stora leverantörerna?

Vägarna skiljer sig. Förenklat kan det handla om en begäran inom ett enterprise-avtal, ett godkännande från leverantörens säljsida eller en särskild ansökan om begränsad åtkomst. Eftersom processerna ändras bör du utgå från principen – att ZDR måste begäras och godkännas – och stämma av den aktuella vägen med leverantören.

Varför räcker det inte att lita på retention-siffror i artiklar?

För att retention-dagar och undantagslistor ändras över tid och skiljer sig mellan avtal och endpoints. En siffra som stämde förra året kan vara inaktuell idag. Kräv i stället de aktuella villkoren skriftligt per endpoint och modell, så att din dokumentation vilar på avtalet – inte på en tredjehandsuppgift.