AI-säkerhet börjar med tydliga befogenheter

Små företag kan få större nytta av AI genom att bestämma vad systemen får göra, hur fel upptäcks och vem som kan stoppa dem.

AI-säkerhet blir konkret i samma ögonblick som en digital assistent får göra något som kostar pengar. Tänk dig ett mindre handelsföretag som låter en AI-assistent föreslå svar på reklamationer. När assistenten också får besluta om återbetalningar förändras uppgiften: ett dåligt svar kan nu bli en felaktig utbetalning.

Det här är ett tänkt exempel, men det visar vilken fråga företagaren behöver besvara före nästa automatisering: vilka beslut är vi beredda att överlåta, och på vilka villkor? Min utgångspunkt är att tydliga befogenheter gör det lättare att använda tekniken offensivt. Företaget behöver kunna skilja mellan ett användbart förslag och en handling som kräver godkännande.

Börja med handlingen som kan gå fel

Y Combinators programbeskrivning för AI Safety Fact vs. Fiction lyfter säkerhetsforskning, automatisk verifiering och metoder för att utsätta system för svåra prov. De angivna gästerna är Stanfordprofessorerna Clark Barrett och Mykel Kochenderfer. Beskrivningen ger en användbar utgångspunkt för företagaren: säkerhet går att behandla som ett praktiskt konstruktionsproblem.

För ett mindre företag föreslår jag därför att arbetet börjar i en bestämd arbetsuppgift. Ska assistenten sammanfatta ett kundärende, föreslå ett beslut eller genomföra beslutet? Skriv ned skillnaden. Om samma formulering används för alla tre blir det svårt att avgöra vad som faktiskt ska testas.

I det tänkta handelsföretaget kan första steget vara att assistenten skriver ett förslag som en medarbetare granskar. Ett senare steg kan vara begränsade återbetalningar enligt tydliga villkor. Varje utökad befogenhet behöver då följas av en ny bedömning av vilka fel som kan uppstå och hur de ska hanteras.

Den som arbetar med egna AI-agenter på jobbet kan använda samma fråga som vägledning: vad får agenten läsa, föreslå och ändra? Ett konkret svar hjälper både den som bygger lösningen och den som ska använda den.

Prova det besvärliga kundärendet

En lyckad demonstration visar hur tjänsten kan fungera under de förutsättningar som demonstrationen innehåller. Företagarens nästa uppgift bör vara att ändra förutsättningarna. Vad händer om underlaget saknas, kundens uppgifter motsäger varandra eller ett önskemål ligger precis utanför företagets villkor?

I programöversikten ligger adaptiv stresstestning vid 32:11. Y Combinators beskrivning av temat handlar om hur testmetoder som använts för flygsystem nu riktas mot språkmodeller. Det är en beskrivning av ett forskningsområde, inte ett belägg för att en viss företagstjänst är säker.

Som praktisk tillämpning föreslår jag en liten samling besvärliga provärenden. Låt återbetalningsassistenten möta ett otydligt kvitto, ett krav som överstiger dess befogenheter och en kundtext som försöker få den att frångå instruktionerna. Bestäm det önskade beteendet innan provet genomförs.

Resultatet behöver också bedömas utifrån handlingen. Om assistenten saknar tillräckligt underlag bör den kunna lämna ärendet vidare. Ett välformulerat svar hjälper föga om systemet samtidigt genomför en utbetalning som det borde ha stoppat.

Spara provärendena och använd dem igen när lösningen ändras. Då får företaget ett eget jämförelsematerial, knutet till den verksamhet där tekniken faktiskt ska arbeta. Det gör även leverantörssamtalet mer konkret: visa hur tjänsten hanterar våra svåra fall.

Ge varje skydd en bestämd uppgift

Programbeskrivningen tar också upp automatisk bevisföring för kod. Här är det viktigt att hålla isär frågorna. Ett bevis för att kod följer en viss specifikation avgör inte i sig om specifikationen motsvarar företagets behov. Företagaren behöver fortfarande bestämma vilka handlingar som ska vara tillåtna.

För återbetalningsassistenten skulle jag därför vilja se flera tydliga begränsningar: bara åtkomst till relevanta ärenden, kontroll av tillåtet belopp före utbetalning och mänskligt godkännande för undantag. Varje begränsning ska ha en begriplig uppgift och kunna prövas separat.

Det är också rimligt att granska den vanliga informationssäkerheten innan assistenten kopplas in. Konton, åtkomst och hantering av kunduppgifter förtjänar samma uppmärksamhet som modellens svar. För den som vill fördjupa den delen finns även läsning om dataläckan kopplad till den danska folkbokföringen.

Gör ansvar till en del av införandet

Vem får stänga av assistenten under en intensiv arbetsdag? Vem undersöker en felaktig utbetalning? Mitt råd är att utse ansvariga innan tjänsten får börja agera. Annars återstår en organisatorisk lucka även om den tekniska lösningen har genomtänkta begränsningar.

Företagsledningen bör dessutom bestämma vilka erfarenheter som ska leda till en förändring. Ett återkommande fel kan motivera mindre befogenheter, bättre underlag eller en paus. Kopplingen mellan verksamhetsmål och kontroll hör också hemma i styrelsens arbete med AI.

Lärdomen: utöka befogenheterna stegvis

AI-säkerhet bör enligt min mening byggas in i själva införandet. Välj en avgränsad uppgift, bestäm vilka handlingar som är tillåtna och pröva vad som händer när underlaget brister. Låt sedan erfarenheterna avgöra nästa steg.

För småföretagaren innebär det en hanterbar början: en arbetsuppgift, en ansvarig och ett antal svåra provärenden. När det fungerar går det att överväga större befogenheter. Teknikens nytta blir lättare att bedöma när företaget också vet hur det ska upptäcka, begränsa och rätta till fel.

Fördjupning: Y Combinators AI Safety Fact vs. Fiction med de angivna gästerna Clark Barrett och Mykel Kochenderfer. Programöversikten placerar adaptiv stresstestning vid 32:11 och övervakning under drift vid 40:30.

Varje utökad befogenhet behöver då följas av en ny bedömning av vilka fel som kan uppstå och hur de ska hanteras.

Teknikens nytta blir lättare att bedöma när företaget också vet hur det ska upptäcka, begränsa och rätta till fel.

▶

Se originalavsnittet på YouTube: Y Combinator.

Källor

• Y Combinator: AI Safety Fact vs. Fiction | YC Paper Club — Underlaget är den tillhandahållna programbeskrivningen och kapitelöversikten, inte en verifierad transkription. Hänvisningar till teman och tidsangivelser följer detta underlag. Företagsexemplet är uttryckligen tänkt och de praktiska rekommendationerna är självständiga resonemang.