När det gäller cyberattacker passar dataförgiftning verkligen in. Det låter helt enkelt illa, särskilt när näringslivet i allt högre grad betraktar data som den digitala motsvarigheten till en ädelmetall.
Det är logiskt, eftersom dataförgiftning är illa. Begreppet syftar på en framväxande risk för AI-modeller där en angripare – som kan vara extern eller intern – avsiktligt korrumperar träningsdata för att påverka modellens funktion eller resultat. Det kan innebära att lägga till dåliga data, manipulera befintliga data eller ta bort rena data.
Om du bygger AI-drivna SaaS-produkter – säg en app för marknadsföringsautomation som innehåller ett LLM-verktyg – behöver du närmare granska hur du skyddar dina modeller.
I den här artikeln delar jag med mig av expertråd om centrala strategier för att minimera risken för dataförgiftning i dina AI-träningsdata.
Vad är dataförgiftning?
Ett exempel på dataförgiftning från NIST, som liksom många andra säkerhetsinriktade organisationer tydligt uppmärksammar hotet: ”[Angripare kan smyga in] många exempel på olämpligt språk i samtalsregister, så att en chattbot tolkar dessa exempel som tillräckligt vanligt språkbruk för att använda det i sina egna kundinteraktioner.”
Plötsligt använder din pålitliga kundtjänstchattbot svordomar (eller ännu grövre språk) i samtal med dina riktiga mänskliga kunder. Det är förmodligen inte vad någon tänker på när de talar om att använda AI för att öka produktivitet, effektivitet eller innovation.
Oavsett användningsområde behöver CTO:er som bäddar in generativ AI eller andra AI-baserade applikationer i sina SaaS-produkter vidta åtgärder för att skydda sina träningsdata mot skadliga tillägg, borttagningar eller andra manipulationer som kan påverka allt från modellens prestanda till användarupplevelsen och varumärkets anseende.
Dessutom verkar experter i allmänhet vara överens om att förebyggande åtgärder är den bästa strategin mot dataförgiftning. Det är vanligtvis enklare att förhindra att det händer än att begränsa effekterna av en incident.
Så bekämpar du dataförgiftning – 5 principer för att minimera riskerna
1. Lär känna dina data.
Att stärka ditt försvar mot dataförgiftning börjar med att förstå vad du skyddar – du kan inte skydda något du inte känner till.
”Den första delen i arbetet med att bekämpa dataförgiftning i AI-drivna SaaS-produkter är att ha en tydlig förståelse för vilka data du tränar din modell på,” säger Ian Ahl, SVP på P0 Labs, avdelningen för hotforskning hos identitetssäkerhetsleverantören Permiso. ”Det är avgörande att träna modeller på data som du kan kontrollera.”
Vilken typ av data handlar det om? Var kommer den ifrån? Vem har tillgång till den? Om du inte har tydliga svar på frågor som dessa löper du förmodligen större risk att utsättas för en förgiftningsattack.
En god förståelse för dina träningsdata är också en förutsättning för bra datastyrning, vilket vi går igenom nedan. Men tills vidare räcker det att konstatera att det måste finnas kontroller för hur personer, team och processer interagerar med och använder träningsdata.
”Genom att utvärdera själva data kan du införa striktare kontroller för de användare som uppdaterar den och ha tydliga säkerhetsramar för hur kunder kan interagera med dessa data,” Ahl säger. ”Det är en kombination av tillsyn över personer, processer och data.”
2. Se över din strategi för datatransformering.
Du måste också överväga – och eventuellt ompröva – hur dina data tar sig från sina ursprungliga källor till dina modeller, vilket också kallas en datapipeline.
”De beslut CTO:er fattar om strategin för datatransformering påverkar direkt säkerheten i deras AI-drivna SaaS-produkter, eftersom dessa beslut påverkar hur sårbara datapipelines kan vara för förgiftning,” säger Dave Jenkins, VP för produkt och forskning på Iterate.ai.
Jenkins säger mer specifikt att vi befinner oss mitt i en bredare övergång från ETL (Extract, Transform, Load) till ELT (Extract, Load, Transform)-arkitektur för datapipelines. Det finns flera orsaker till utvecklingen, men en fördel med den senare strategin är att den är bättre lämpad för att minimera risken för problem som dataförgiftning.
”Anledningen är att när AI-data transformeras tidigt, och modellen är dåligt finjusterad eller datamängderna fortfarande är ofullständiga, vilket ibland händer med ETL, kan potentiellt dåliga data byggas in,” säger Jenkins. ”Fel och hallucinationer kan mångfaldigas därifrån, och att hitta – och korrigera – källan till de förgiftade data kan vara nästintill omöjligt.”
På grund av detta tillägger Jenkins att du bör undvika ett scenario där olika applikationer utför sina egna transformeringar innan data flyttas till en datasjö. ELT-modellen vänder så att säga på ordningen för operationerna och ger dig större kontroll samt en mer enhetlig transformeringsprocess.
”Genom att i stället flytta alla transformationer till en datalagermiljö som Snowflake får CTO:er och deras team bättre insyn och kontroll när de bygger ut sina produkter,” säger Jenkins.
3. Prioritera god datastyrning.
Insyn och kontroll är avgörande, men de är otillräckliga utan starka policyer och styrning genom hela era datapipelines och processer.
”Att göra detta rätt kräver förstås också tydlig styrning,” säger Jenkins. ”CTO:er måste ange var AI-datatransformationer får ske. De kommer att vilja ha granskningsspår, valideringsramverk, referensdataset för jämförelsetester och helst även transformationssandlådor för att testa och testa om igen efter eventuella fel eller hallucinationer innan produktion.”
Ahl påpekar att styrningen även måste omfatta människor, särskilt i form av tydliga policyer och skyddsräcken kring vem som får interagera med träningsdata, vilka data de får använda och så vidare: ”Oavsett om det är en användare eller ett team som har möjlighet att lägga till filer för att träna en modell måste det finnas begränsningar för vilka data de får använda.”
4. Stärk er övergripande säkerhetsnivå.
Det är också viktigt att komma ihåg att AI i allmänhet återigen utökar angreppsytan för många organisationer. Dataförgiftning är bara ett potentiellt hot – om än ett viktigt sådant. Allt ovanstående bör ske inom ramen för en bredare säkerhetsstrategi.
Om ni redan hoppar över grundläggande säkerhetsåtgärder som korrigeringar, god lösenordshygien, identitetshantering och principen om minsta möjliga behörighet, följer det att era AI-modeller och träningsdata också kommer att vara ännu mer utsatta för risker.
5. Överväg adversariell modellträning.
När nyare hot som dataförgiftning uppstår följer vanligtvis nya strategier och verktyg för att försvara sig mot dessa hot. Det sker nu med AI, som har medfört en hel uppsättning nya risker, inte bara dataförgiftning. Dessa samlas ibland under begreppet ”adversariell AI”, eller skadlig användning av maskininlärning och andra typer av AI för att angripa andra AI-system. Dataförgiftning är en form av adversariell AI.
Här kan ni vända på steken och använda adversariell träning, vilket i praktiken lär era modeller att upptäcka potentiella mönster och avvikelser som kan tyda på dataförgiftning eller andra former av adversariell AI och sedan vidta åtgärder för att begränsa dem.
Adversariell träning får allt större betydelse som en central metod för AI-säkerhet. Exempelvis erbjuder denna akademiska artikel ett ramverk för att minska fördomar som kan ha uppstått genom datainsamling inom vården, där de potentiella konsekvenserna av dataförgiftning och andra angrepp är särskilt allvarliga. En annan artikel föreslår ett ramverk för adversariell träning som specifikt är utformat för att försvara mot dataförgiftning.
Vad händer härnäst?
Om ni bygger in generativ AI och andra AI-drivna funktioner i er SaaS-produktportfölj måste ni se till att era träningsdata är rena, korrekta och säkra.
Annars ökar ni risken för dataförgiftning och andra problem – och dessa problem är vanligtvis enklare att förebygga än att lösa i efterhand.
Innan ni går vidare kan ni registrera er för vårt nyhetsbrev för att få de senaste insikterna!
