Tankeledare

Skyddsåtgärder för AI i företag kan vara viktigare än AI-fronten

mm
Lägg till Unite.AI bland dina föredragna källor på Google

Glöm AI-fronten. Kunderna kräver att företag inför fler skyddsåtgärder för AI som redan används, och erfarenheterna från PCI DSS ger en användbar modell.

Smekmånaden för AI-reglering är över. Nya uppgifter har lett till diskussioner om att bromsa utvecklingen av de mest avancerade AI-modellerna och införa obligatoriska kontroller. En av få saker man är överens om är att kontrollerna bör ligga utanför modellerna och verifieras oberoende.

Det diskuteras vad som händer härnäst, men tillsynsmyndigheterna agerar. Europeiska unionens AI-förordning inför gradvis säkerhetskrav, däribland ansvar för köpare. I USA börjar NIST:s ramverk för riskhantering inom AI användas som standard för vad som utgör rimlig omsorg. Globalt har OWASP:s topp 10 över risker för LLM-applikationer blivit en vanlig referens vid säkerhetsgranskningar, och certifiering enligt ISO/IEC 42001 börjar förekomma i upphandlingsdokument.

Det innebär att modellutvecklare inte är de enda som hålls ansvariga. Säkerhetskrav och risker gäller också företag som använder modeller som redan har släppts, särskilt i användningsområden med hög risk. Felaktiga svar i ett kundformulär om säkerhet eller i ett svar på en offertförfrågan (RFP) kan sinka en B2B-affär.

PCI DSS visar vägen

Lyckligtvis har vi sett det här förut. För tjugo år sedan byggde säkerheten i webbapplikationer främst på regelbundna kodgranskningar, statiska analyser och utvecklarnas noggrannhet. Sedan infördes PCI DSS-krav 6.6, som publicerades 2006 och började tillämpas 2008. Kravet innebar att organisationer som hanterade kortinnehavaruppgifter antingen måste granska all applikationskod för att hitta sårbarheter eller installera automatiserade tekniska kontroller. Senare togs möjligheten att välja kodgranskning bort, och tekniska kontroller blev obligatoriska.

Men PCI DSS började inte som en lag. Det började som en avtalsbaserad standard som omformade marknaden, förmodligen snabbare än lagstiftning skulle ha gjort, eftersom avtal får genomslag snabbare än offentliga lagar.

På samma sätt känner organisationer nu av trycket att införa skyddsåtgärder för AI som används i produktion, inte från tillsynsmyndigheter utan från kunder och partner – genom säkerhetsfrågeformulär, klausuler i offertförfrågningar och krav i försäkringsvillkor.

Lös det operativa problemet, så följer regelefterlevnaden

Det kan vara svårt att hantera det trycket, eftersom AI-styrning inte bara handlar om policy. Det handlar också om löpande tekniska belägg.

Många företag jag pratar med kör minst ett halvdussin modeller i produktion och kopplar ofta ihop eller samordnar dem så att resultatet från en modell blir indata till en annan. Tänk dig att försöka visa att en viss policy efterlevs i hela systemet – till exempel att modellresultat inte innehåller personligt identifierbar information (PII) – under sådana förhållanden. Att manuellt granska flera modeller som konfigurerats var för sig skulle ta mycket av utvecklarnas tid i anspråk. Dessutom har de flesta organisationer svårt att hantera otillåten och högriskbetonad AI-användning, till exempel när anställda klistrar in känsliga uppgifter i AI-verktyg för konsumenter eller när SaaS-leverantörer i tysthet aktiverar nya AI-funktioner. Ändå ligger hela ansvaret på företaget.

I sådana utmanande situationer kan kraven kokas ner till en enkel uppgift: visa att ni kontinuerligt kan begränsa indata till och utdata från modeller och samtidigt logga aktiviteten så att den kan verifieras. När applikationer anropar modeller, agenter använder verktyg och modeller utför åtgärder eller utlöser arbetsflöden är det själva åtgärden som behöver kontrolleras – verktygsanropet, API-begäran eller utlösningen av arbetsflödet.

Flytta säkerheten till inferensvägen

Den åtgärden är den kontrollpunkt som experter på applikationssäkerhet har ägnat 20 år åt att bygga upp för applikationstrafik. Särskilt när inferens dirigeras via delad infrastruktur blir inferensvägen den perfekta kontrollpunkten för olika modeller och även för otillåten AI-användning. AI-inferens trafik måste levereras, granskas, autentiseras och styras på samma sätt som annan viktig interaktion med applikationer, utifrån var trafiken kommer ifrån och vad den försöker göra. Till skillnad från manuell granskning kan styrningen av inferenstrafik skalas upp.

Så kommer ni igång

Med tanke på den kommande regleringen behöver organisationer börja med tre saker redan nu:

  1. Kartlägg var ni kan hållas ansvariga, från SaaS-API:er och värdbaserade slutpunkter till skugg-AI.
  2. Frikoppla säkerhetspolicy och tillämpning från modellerna och placera dem i inferensvägen.
  3. Se till att granskningsspår skapas utanför modellernas och agenternas kontroll. Det har visats att de kan försöka ändra loggar över sina egna åtgärder.

Det är fortfarande under utredning vad som räknas som tillräcklig övervakning och tillämpning, men era drift- och säkerhetsteam vet vad som faktiskt går att genomdriva, vilken kostnad en kontroll medför i form av fördröjning och komplexitet och när en välmenande regel kan få fel effekt. Involvera dem redan nu. Säkerhetsriskerna och skyldigheterna i samband med AI-användning är verkliga, och era kunder och chefer bryr sig utan tvekan mer om de risker de står inför i dag än om hoten från framtidens mest avancerade AI-modeller.

Michael Montoya är teknik- och driftchef på F5. Han leder organisationerna för säkerhet, risk och digital verksamhet och anslöt sig till F5:s verkställande ledningsgrupp efter att ha suttit i F5:s styrelse från 2021 till 2025. Montoyas tidigare erfarenhet omfattar ledande befattningar på C-nivå hos BlueVoyant, Equinix, Digital Realty och Microsoft.