Säkerhet med AI i utvecklingen är två skilda frågor som ofta blandas ihop: vad du skickar in till modellen, och vad som kommer ut. Den första är en fråga om avtal, sekretess och GDPR. Den andra är vanlig applikationssäkerhet, med en ny felkälla. Svara på dem var för sig.
Fråga ett: vad du skickar in
Allt du klistrar in i en prompt lämnar din maskin. Var det hamnar, hur länge det sparas och om det används för träning beror på vilken tjänst och vilken plan du använder — och det varierar mellan leverantörer och ändras över tid.
Det gör att den enda hållbara vanan är att avgöra vad som får skickas innan du sitter med en bugg och behöver hjälp. Beslutet blir sämre när det fattas under tidspress.
- Hemligheter. API-nycklar, lösenord, tokens, certifikat, anslutningssträngar. Även "bara för att visa formatet".
- Personuppgifter. Riktiga namn, personnummer, adresser, e-post, IP-adresser — i loggutdrag, testdata eller databasdumpar.
- Kunddata i klartext. Ett felmeddelande med en riktig order i sig är kunddata, även om det ser ut som ett stackspår.
- Kod som omfattas av NDA eller kundavtal, om inte avtalet uttryckligen tillåter det.
- Interna säkerhetsdetaljer. Nätverkstopologi, brandväggsregler, vilka system som saknar autentisering.
Om en nyckel råkar skickas in: rotera den. Inte "det var nog ingen fara". Rotation tar minuter, en läcka kan kosta betydligt mer, och det är den enda åtgärd som faktiskt återställer läget.
Anonymisering som faktiskt fungerar
Det räcker sällan att byta ut namnen. Ett utdrag kan identifiera en person genom kombinationen av uppgifter även när det uppenbara är borttaget.
Innan du klistrar in ett utdrag
- Byt ut, ersätt inte bara. Använd konsekventa platshållare:
anvandare@exempel.se,Kund A,19700101-0000. Behåll formatet — det är formatet modellen behöver. - Ta bort id:n som går att slå upp. Ordernummer, kundnummer och interna referenser är identifierande i era egna system.
- Korta ned. Femton rader ur loggen räcker nästan alltid. Hela filen tar med saker du inte läst igenom.
- Beskriv i stället för att visa när det går. "En tabell med användare, e-post och senaste inloggning" ger ofta lika bra svar som riktiga rader.
För kod som verkligen inte får lämna huset finns lokala modeller som körs på egen hårdvara. De är svagare än de största molnmodellerna, men frågan om var datan hamnar försvinner helt — vilket kan vara det avgörande kravet.
Fråga två: vad som kommer ut
AI-genererad kod har inte fler sårbarheter för att modellen är oaktsam. Den har dem för att den återger mönster från mycket kod, och en stor del av all kod som någonsin skrivits är osäker.
Modellen skriver dessutom gärna det som efterfrågats och inget mer. Bad du inte om behörighetskontroll får du sällan någon — inte för att den utelämnades medvetet, utan för att den inte var en del av uppgiften.
Hemligheter och nycklar
En särskild fallgrop: modellen skriver gärna exempelkod med nyckeln inlagd direkt i filen, eftersom det är så exempel ser ut i dokumentation. Det är rätt i ett exempel och fel i ett repo.
key, secret och token fångar det mesta.Leverantörsfrågorna
För arbete åt kund eller med personuppgifter räcker det inte att du känner dig trygg. Fyra frågor behöver ha ett dokumenterat svar innan verktyget används skarpt.
- Används vår data för träning? Skiljer sig ofta mellan gratis- och betalplaner hos samma leverantör.
- Hur länge sparas prompterna? Även utan träning kan de lagras för missbruksdetektering.
- Var behandlas datan geografiskt? Avgörande för överföring till tredjeland.
- Finns personuppgiftsbiträdesavtal? Krävs om personuppgifter kan förekomma i prompterna.
Svaren på de här frågorna ändras, och de skiljer sig mellan planer hos samma leverantör. Läs leverantörens aktuella villkor — fråga inte modellen, och lita inte på en artikel från i fjol. Det är precis den sortens uppgift som låter mest självsäker och åldras snabbast.
Säkerhetsfrågorna beror delvis på vilket verktyg du använder och hur det är uppsatt. Nästa guide går igenom valet.