Dina anställda använder redan AI för att förbättra sin – och därmed er – kod, men om du inte har kontroll över hur de gör det så riskerar du att kod, inloggningsuppgifter och interna systemdetaljer lämnas ut av företaget – utan någon form av loggning, spårbarhet eller granskning. Det menar Therese Lindepil, vountry manager for Eficode i Sverige.
Vi har sett det förut: en teknik som anammas av användarna innan it-avdelningen har godkänt den. Dropbox, Google Docs och Slack blev en del av vardagen långt innan det fanns tydliga riktlinjer för hur de skulle användas.
Det här är en opinionstext. Åsikter som uttrycks är skribentens egna.
Då ledde det till dataläckor, överträdelser av compliance-regler och en mängd otillåtna integrationer. Nu händer det igen med AI. Skillnaden är att ett misstag i dag inte bara betyder att ett dokument har kommit på avvägar – det kan leda till läckage av proprietär källkod, interna API-specifikationer, inloggningsuppgifter eller hela arkitekturdiagram.
Problemet är att man sällan vet var data hamnar när de skickas till gratisversioner av AI-tjänster. För en utvecklare kan det vara frestande att skicka en felrapport, en stackspårning eller en konfigurationsfil till en chatbot för att få snabb hjälp – men i samma ögonblick man gör det så förlorar man kontrollen. Många AI-leverantörer lagrar indata för att förbättra sina modeller, och även om det kan låta oskyldigt kan det innebära att din internal_payment_service.py eller docker-compose.yml blir en del av en global träningsdatabas.
Därför är du tvungen att hänga med på AI-vågen – oavsett om du tycker att Vibe-kodning är coolt eller inte.
Låt oss ta ett steg tillbaka: Ingen av dina anställda eller utvecklare har för avsikt att dela data med okända källor, men begränsningar i ett potentiellt mer effektivt arbetsflöde ”tvingar” dem att använda plattformar som inte är säkra – om inte sådana erbjuds av företaget och i rätt ramverk.
Vi såg exakt samma sak hända i kommuner i hela Norden när känsliga personuppgifter delades i Dropbox-mappar eftersom kommunens it-system helt enkelt var för långsamt att arbeta med.
Detta är ett enormt problem när det gäller regelverk som GDPR och NIS2 – och det är okontrollerad användning av AI också.
För utvecklare handlar det inte bara om lagstiftning utan om att förstå de praktiska konsekvenserna: Var hamnar uppgifterna rent fysiskt? Finns det en logg över vem som har skickat vad? Och skickar vi mer information än nödvändigt? Om man inte kan svara på dessa frågor kan det inte bara leda till lagbrott och höga böter, utan också till förlust av företagshemligheter och kundernas förtroende.
Riskerna finns inte bara i datadelningen.
Otränad och oövervakad användning av AI kan också leda till resultat med låg kvalitet, vilket i värsta fall kan introducera säkerhetshål i kodbasen. Hallucinerad kod kan se korrekt ut och fungera i utvecklingsmiljön, men fungera felaktigt i produktionen eller skapa kritiska sårbarheter – allt från SQL-injektioner till osäkra API-anrop. Att förstå modellens begränsningar är därför avgörande, både för att undvika att implementera felaktiga lösningar och för att undvika licensproblem eller brott mot arkitekturprinciper.
Och om man inte vet att AI används under utvecklingen så är det svårt att hitta AI-relaterade fel.
Detta innebär att ledning och utvecklare tillsammans måste ta ansvar för att definiera tydliga ramverk för AI-användningen. Det handlar inte om att hämma innovation, utan om att skapa en miljö där verktygen används på ett säkert sätt. Företagskonton hos AI-leverantörer kan ge bättre dataskydd, inaktivera datainsamlande träning och åtkomst till privata slutpunkter. Samtidigt bör utvecklare förstå vilka typer av data som aldrig får lämna organisationen – och hur man rent tekniskt ser till att det inte händer.
Skugg-AI är inte ett teoretiskt problem, utan ett praktiskt och akut sådant. Det är en fråga om när det smäller – inte om det smäller. Skillnaden mellan att ha kontroll och att hamna i en säkerhetsskandal beror på hur snabbt organisationen får kontroll över dataflöden, tekniska verktyg och utvecklarnas arbetsrutiner. Om inte så riskerar organisationen att nästa stora säkerhetsincident börjar med ett oskyldigt prompt-fönster – och upptäcks först när skadan redan är skedd.
Aktuell Säkerhet jobbar för alla som vill göra säkrare affärer och är därför en säker informationskälla för säkerhetsansvariga inom såväl privat som statlig och kommunal sektor. Vi strävar efter förstahandskällor och att vara på plats där det händer. Trovärdighet och opartiskhet är centrala värden för vår nyhetsjournalistik
Anmäl dig till vårt nyhetsbrev!
Genom att klicka på "Prenumerera" ger du samtycke till att vi sparar och använder dina personuppgifter i enlighet med vår integritetspolicy.
