Når det gjelder cyberangrep, er datagifting helt på sin plass. Det høres rett og slett ille ut, særlig når næringslivet i økende grad behandler data som den digitale ekvivalenten til et edelmetall.
Det gir mening, for datagifting er ille. Begrepet viser til en fremvoksende risiko for AI-modeller der en angriper – som kan være ekstern eller intern – med hensikt ødelegger treningsdatasett for å påvirke modellens drift eller resultater. Det kan innebære å legge til dårlige data, manipulere eksisterende data eller slette rene data.
Hvis du utvikler AI-drevne SaaS-produkter – for eksempel en app for markedsføringsautomatisering som inkluderer et LLM-verktøy – må du se nærmere på hvordan du beskytter modellene dine.
I denne artikkelen deler jeg ekspertråd om kjernestrategier for å minimere risikoen for datagifting i AI-treningsdatasettene dine.
Hva er datagifting?
Et eksempel på datagifting fra NIST, som i likhet med mange andre sikkerhetsorienterte organisasjoner tydeligvis følger med på trusselen: «[Angripere kan snike] en rekke tilfeller av upassende språk inn i samtaleregistre, slik at en chatbot tolker disse tilfellene som vanlig nok språkbruk til å bruke det i sine egne kundeinteraksjoner.»
Plutselig bruker den pålitelige kundeservice-chatboten din banneord (eller enda verre språk) i samtaler med dine faktiske menneskelige kunder. Det er sannsynligvis ikke det noen ser for seg når de snakker om å bruke AI til å øke produktivitet, effektivitet eller innovasjon.
Uavhengig av bruksområde må CTO-er som bygger inn generativ AI eller andre AI-baserte applikasjoner i SaaS-produktene sine, ta grep for å beskytte treningsdataene mot ondsinnede tilføyelser, slettinger eller andre manipulasjoner som kan påvirke alt fra modellens ytelse til brukeropplevelse, merkevareomdømme og mer.
Også: Eksperter ser generelt ut til å være enige om at forebygging er den beste tilnærmingen til datagifting. Det er vanligvis enklere å forhindre at det skjer enn å begrense konsekvensene av en hendelse.
Slik bekjemper du datagifting – 5 prinsipper for å minimere risiko
1. Kjenn dataene dine.
Å styrke forsvaret mot datagifting begynner med å forstå hva du beskytter – du kan ikke beskytte noe du ikke kjenner.
«Den første delen av å bekjempe datagifting i AI-drevne SaaS-produkter er å ha en klar forståelse av hvilke data du trener modellen din på», sier Ian Ahl, SVP i P0 Labs, trusselforskningsavdelingen til identitetssikkerhetsleverandøren Permiso. «Det er avgjørende å trene modeller på data du kan kontrollere.»
Hva slags data er det? Hvor kommer de fra? Hvem har tilgang til dem? Hvis du ikke har klare svar på spørsmål som disse, har du sannsynligvis høyere risiko for et forgiftningsangrep.
En god forståelse av treningsdataene dine er også en forutsetning for god datastyring, som vi skal se nærmere på nedenfor. Men foreløpig er det nok å si at det må finnes kontroller for hvordan personer, team og prosesser samhandler med og bruker treningsdata.
«Ved å evaluere selve dataene kan du innføre strengere kontroller for brukerne som oppdaterer dem, og ha strenge sikkerhetsrammer rundt hvordan kunder kan samhandle med disse dataene», Ahl sier. «Det er en kombinasjon av tilsyn med personer, prosesser og data.»
2. Gå gjennom strategien for datatransformasjon på nytt.
Du må også vurdere – og potensielt revurdere – hvordan dataene dine kommer fra de opprinnelige kildene til modellene dine, også kjent som en datapipeline.
«Beslutningene CTO-er tar om strategien for datatransformasjon, påvirker sikkerheten til de AI-drevne SaaS-produktene deres direkte, fordi disse beslutningene påvirker hvor sårbare datapipelines kan være for datagifting», sier Dave Jenkins, VP for produkt og forskning hos Iterate.ai.
Jenkins sier spesifikt at vi er midt i en bredere overgang fra ETL (trekk ut, transformer, last inn) til ELT (trekk ut, last inn, transformer)-arkitektur for datapipelines. Det finnes flere grunner til denne utviklingen, men en fordel med den sistnevnte strategien er at den er bedre egnet til å minimere risikoen for problemer som datagifting.
«Bakgrunnen for dette er at når AI-datatransformasjoner skjer tidlig, og modellen er dårlig innstilt eller datasettene fortsatt er ufullstendige, slik det noen ganger skjer med ETL, blir potensielt dårlige data bakt inn», sier Jenkins. «Feil og hallusinasjoner kan mangedobles derfra, og det kan være nærmest umulig å finne – og korrigere – kilden til de forgiftede dataene.»
På grunn av dette, legger Jenkins til, bør du unngå et scenario der ulike applikasjoner gjør sine egne transformasjoner før dataene flyttes inn i en datasjø. ELT-modellen snur så å si rekkefølgen på operasjonene, og gir deg mer kontroll og en mer enhetlig transformasjonsprosess.
«Ved i stedet å flytte alle transformasjoner til et datavarehusmiljø som Snowflake får CTO-er og teamene deres bedre oversikt og kontroll når de utvikler produktene sine», sier Jenkins.
3. Prioriter god datastyring.
Oversikt og kontroll er avgjørende, men de er ufullstendige uten tydelige retningslinjer og god styring gjennom hele datapipeline- og databehandlingsprosessene.
«Å få dette riktig krever selvfølgelig også tydelig styring», sier Jenkins. «CTO-er må spesifisere hvor AI-datatransformasjoner kan finne sted. De vil ha behov for revisjonsspor, valideringsrammeverk, referansedatasett for sammenligningstesting og, ideelt sett, sandkasser for transformasjoner, slik at de kan teste og teste på nytt for eventuelle feil eller hallusinasjoner før produksjonssetting.»
Ahl påpeker at styringen også må omfatte mennesker, særlig i form av tydelige retningslinjer og sikkerhetsrammer for hvem som kan samhandle med treningsdata, hvilke data de kan bruke og så videre: «Den som har mulighet til å legge til filer for å trene en modell, enten det er en bruker eller et team, må ha begrensninger på hvilke data de kan benytte.»
4. Styrk det overordnede sikkerhetsnivået.
Det er også viktig å huske at AI generelt nok en gang utvider angrepsflaten til mange organisasjoner. Dataforgiftning er bare én potensiell trussel – om enn en viktig en. Alt det ovennevnte bør skje som en del av en bredere sikkerhetsstrategi.
Hvis du allerede nedprioriterer grunnleggende sikkerhetstiltak som oppdateringer, god passordhygiene, identitetsstyring og prinsippet om minste privilegium, følger det at AI-modellene og treningsdataene dine også vil være enda mer utsatt for risiko.
5. Vurder trening av modeller mot angrep.
Når nyere trusler som dataforgiftning oppstår, følger det vanligvis nye strategier og verktøy for å forsvare seg mot disse truslene. Det skjer nå med AI, som har kommet med en hel rekke nye risikoer, ikke bare dataforgiftning. Disse samles noen ganger under begrepet «fiendtlig AI», eller ondsinnet bruk av maskinlæring og andre typer AI for å angripe andre AI-systemer. Dataforgiftning er én form for fiendtlig AI.
Her kan du snu på saken og bruke trening mot angrep, som i praksis lærer modellene dine å oppdage mulige mønstre og avvik som kan tyde på dataforgiftning eller andre former for fiendtlig AI, og deretter iverksette tiltak for å redusere dem.
Trening mot angrep får stadig større betydning som en viktig tilnærming til AI-sikkerhet. Denne akademiske artikkelen tilbyr for eksempel et rammeverk for å redusere skjevheter som kan ha blitt tilegnet gjennom datainnsamling i helsesektoren, der de potensielle konsekvensene av dataforgiftning og andre angrep er spesielt alvorlige. En annen artikkel foreslår et rammeverk for trening mot angrep som spesifikt skal beskytte mot dataforgiftning.
Hva skjer videre?
Hvis du bygger inn generativ AI og andre AI-drevne funksjoner i SaaS-produktporteføljen din, må du sørge for at treningsdataene dine er rene, nøyaktige og sikre.
Ellers øker du risikoen for dataforgiftning og andre problemer – og disse problemene er vanligvis enklere å forebygge enn å løse i etterkant.
Før du går, meld deg på nyhetsbrevet vårt for å få de nyeste innsiktene!
