AI-säkerhet handlar mest om systemdesign
Säkerhetsmötet efter demon
Demon hade gått bra på vanligt sätt. Modellen läste en bunt interna dokument, svarade på en policyfråga, föreslog ett nästa steg och producerade en snygg sammanfattning för ärendet. Rummet nickade. Någon frågade om den kunde kopplas till arbetsflödessystemet. Någon annan frågade hur snart. Sedan frågade säkerhetsansvarige vad som skulle hända om modellen hade fel men var övertygande. Rummet blev mycket intresserat av kexen.
Den frågan är var praktisk AI-säkerhet börjar. Inte i det abstrakta och inte i en slogan. Utan i formen på systemet kring en modell som ibland har fel, ibland är inaktuell, ibland är övermodig, ibland är för osäker och ibland har rätt av fel anledning. Säkerhetsfrågan handlar inte bara om modellens beteende. Den handlar om vad systemet tillåter det beteendet att göra.
En modell som utkastar en mening är en risk. En modell som uppdaterar ett förmånsbeslut är en annan. En modell som anropar ett verktyg med skrivbehörighet är en annan. En modell som dirigerar en patient, avslår ett krav, ändrar en kreditgräns eller styr utrustning befinner sig i en helt annan faroklass. Samma underliggande modell kan vara ofarlig, användbar, riskabel eller oacceptabel beroende på gränser, tillstånd, bevis, behörighet, övervakning och återställning. Det är därför AI-säkerhet till största delen är systemdesign.
Till största delen gör ett arbete i den meningen. Modellforskning spelar roll. Datakvalitet spelar roll. Inriktningsmetoder spelar roll. Utvärderingsvetenskap spelar roll. Men när en organisation driftsätter AI blir säkerhet operativ. Vem får fråga. Vad modellen får se. Vad den får ändra. Vilka bevis som krävs. Vilket tillstånd som bevaras. Vad som händer när källor inte överensstämmer. När måste en människa godkänna. Hur upptäcks drift. Hur rullas en dålig version tillbaka. Det är designfrågor innan de är etikuttalanden. Etikuttalandet kan vara uppriktigt. Systemet utför inte uppriktighet.
Säkerhet är ett kontrollproblem
När människor hör säkerhet tänker de ofta på värderingar, träningsdata, vägranspolicyer och modellinriktning. Det är en del av bilden, men ett driftsatt system behöver också kontroller. En kontroll är något som ändrar vad som kan hända: en åtkomstkontroll, ett schema, en timeout, ett tröskelvärde, ett mänskligt godkännande, en sandlåda, en hastighetsgräns, en verifierare, en återställning, en dödsbrytare, en post som inte kan redigeras av serveringsvägen. Kontroller är tråkiga tills de saknas. Då blir de hela mötet.
Ett säkert AI-system utgår från att modellen kan misslyckas och utformar den omgivande mekaniken därefter. Det skiljer förslag från handling. Det begränsar verktygens befogenheter. Det kontrollerar bevis innan tillstånd ändras. Det gör osäkerhet synlig. Det registrerar modellversion och källans omfattning. Det vägrar när obligatoriska fält saknas. Det ger operatörer ett sätt att pausa automatisering. Det behandlar modellens utdata som en kandidat, inte som ett påbud från ett mycket artikulerat kalkylblad.
Detta är vanlig säkerhetsteknik med en språkmodell i mitten. Flyg, medicin, järnväg, industriell styrning och finans har alla lärt sig att viktiga system behöver skiktade kontroller eftersom ingen komponent är perfekt. AI-versionen känns ny eftersom komponenten talar. Tal gör misslyckanden socialt övertygande. Ett felaktigt svar som låter lugnt kan glida förbi en trött operatör lättare än en blinkande röd felindikator. Kontrollutformningen måste därför vara mer envis än prosan.
Kontrollutformning börjar med att fråga vad systemet tillåts påverka. Om AI:n bara kan utarbeta förslag fokuserar säkerheten på källkvalitet, kontroll av hallucinationer, tydlighet i användargränssnittet och granskning. Om den kan dirigera arbete lägger säkerheten till tillståndsspårning, köintegritet, servicenivåer och överklagandevägar. Om den kan anropa verktyg lägger säkerheten till behörighetsomfattningar, argumentvalidering, transaktionsloggar och kompenserande åtgärder. Om den kan påverka rättigheter eller fysiska system kräver säkerheten bevis, formell granskning, begränsad autonomi och planering för allvarliga incidenter. Modellen är en del. Befogenhetsramen är den andra.
Gränsen är produkten
Den viktigaste linjen i ett AI-system är ofta inte synlig i gränssnittet. Det är gränsen mellan att läsa och skriva, rekommendera och besluta, sammanfatta och registrera, assistera och agera. Svaga gränser är hur ofarliga prototyper blir osäkra tjänster. En modell som börjar som ett hjälpmedel för utkast får en knapp för att tillämpa utkastet. Sedan får den ett verktyg för att uppdatera ärendet. Sedan får den en dirigeringsregel eftersom teamet har mycket att göra. Sex månader senare kan ingen förklara vilka beslut som är automatiserade och vilka som bara är assisterade. Detta är inte illvilja. Det är omfattningsglidning i bekväma skor.
Bra gränser är tydliga och granskningsbara. Modellen får läsa dessa källor, inte de där. Den får föreslå dessa fält, inte genomföra dem. Den får anropa detta verktyg med dessa argument, inte godtycklig text. Den får dirigera lågriskärenden, inte omtvistade ärenden. Den får svara endast när bevisen är aktuella. Den får inte använda privata anteckningar för offentliga förklaringar. Den får inte korsa från en klient, region, ett konto eller en rättslig grund till en annan för att nästa stycke verkade hjälpsamt.
Gränser måste också upprätthållas utanför modellen. En uppmaning som säger att inte skriva till kunddatabasen är inte en gräns om verktyget har skrivbehörighet och ingen gateway. Ett systemmeddelande som säger att ange källor är inte en gräns om svar kan lagras utan källhänvisningar. Ett policyavsnitt som säger att mänskligt godkännande krävs är inte en gräns om arbetsflödet låter automatisering markera som godkänt. Säkerhetsinstruktioner i modellen är användbara, men de räcker inte. Systemet måste göra osäkra vägar svåra eller omöjliga.
Detta är det oromantiska arbete som faktiskt skyddar människor. Tydliga verktygsanrop. Snäva omfattningar. Skrivskyddade standardinställningar. Separata godkännandetjänster. Idempotenta operationer. Granskningsloggar. Versionshanterade policyer. Kötillstånd. Tydliga vägranslägen. Ordförrådet låter som att en backend-ingenjör hade en lugn helg med en anteckningsbok. Bra. Säkerhet i produktion ser oftast ut så. Det försöker inte vinna en slogan-tävling.
State är där säkerheten blir verklig
AI-konversationer kan få system att verka tillståndslösa. En användare frågar, en modell svarar, skärmen ändras. Produktion är inte tillståndslös. Ärenden rör sig. Ärenden åldras. Behörigheter upphör att gälla. Dokument rättas. En modellversion ändras. En människa överrider en rekommendation. Ett överklagande kommer in. En användare frågar varför något hände förra månaden. Säkerheten beror på om systemet bevarade det tillstånd som behövdes för att svara.
Tillstånd talar om för systemet vad som redan har hänt och vad som kan hända härnäst. Utan det ser modellen en ögonblicksbild och gissar resten. Så uppstår dubbelarbete, deadlines försvinner, godkännanden antas och gammal bevisning återförs in i ett nytt beslut. Ett säkert arbetsflöde registrerar explicita tillstånd: utkast, bevisning saknas, policy blockerar, granskning krävs, godkänt, utfört, ifrågasatt, rättat, återkallat. Dessa tillstånd är inte dekorativa. De hindrar modellen från att behandla en process med konsekvenser som en chattlogg med ambitioner.
Tillstånd ger också människor hävstång. En operatör kan undersöka varför ett ärende ligger i granskning. En chef kan se om automatiseringen skapar en kö. En revisor kan spela upp vilka källversioner som var aktiva. En användare kan ifrågasätta ett utfall med något mer hållbart än en skärmdump. En utvecklare kan mäta om en ny modell ökar avvisanden, eskaleringar eller omarbete. Utan tillstånd blir varje säkerhetssamtal teater. Människor pratar om ansvar, men systemet har tappat bort substantiven.
För AI bör tillstånd inkludera modell- och policyversion, prompt- eller mallidentifierare, källuppsättning, hämtningstidsstämpel, verktygsanrop, konfidens eller osäkerhet, avvisandeskäl, mänsklig åtgärd och effekt nedströms. Allt detta hör inte hemma i en enda loggrad, och allt ska inte vara synligt för alla. Integritet och säkerhet spelar roll. Men informationen måste finnas under kontrollerad åtkomst. Annars blir säkerheten beroende av minne, och minne är en berömt dålig databas med utmärkta ursäkter.
Bevisning är säkerhetsräcket
Ett modellsvar är säkrare när det är kopplat till bevisning. Det låter självklart tills systemet är under press. Bevisning hoppas över för att den tillför latens. Citat lagras som text i stället för identifierare. Hämtningspoäng bevaras inte. Källversioner skrivs över. Modellen skriver en självsäker förklaring från ett dokument som sedan har rättats. Senare frågar alla varför svaret var fel. Svaret är att räcket var dekorativt.
Användbar bevisning är inte en fotnot. Det är en kedja. Begäran kom in med en identitet och ett syfte. Källorna valdes ut under behörighet. Hämtningen hittade specifika delar eller poster. Modellen producerade ett resultat under en namngiven version. En verifierare kontrollerade påståenden eller tröskelvärden. En människa godkände, redigerade eller avvisade. Åtgärden ändrade tillståndet. Systemet lagrade tillräckligt mycket av den kedjan för att kunna spela upp eller ifrågasätta den. Detta är inte byråkrati för dess egen skull. Det är så säkerhet överlever tid.
Bevisning skyddar också modellen från att bli ombedd att utföra omöjligt arbete. Om systemet kräver aktuella källor kan modellen vägra inaktuell indata. Om systemet kräver två matchande poster kan den flagga oenighet. Om systemet kräver källidentifierare kan den stoppa ogrundade påståenden. Modellen behöver inte längre omvandla saknad bevisning till flytande osäkerhetshantering. Den kan återgå till ett säkert tillstånd. Detta är snällare mot modellen och mycket snällare mot den person som påverkas av resultatet.
Det finns en balans. Insamling av bevisning ska inte bli övervakning. Känsligt innehåll kan hashas, maskeras, separeras eller behållas under begränsade perioder. Poängen är inte att spela in allt för alltid. Poängen är att bevara de fakta som behövs för att granska viktigt beteende. Säkerhet utan bevisning är bara förtroende i en snyggare kostym. Det kan se bra ut i lobbyn. Det håller inte vid en incident.
Människor behöver utformad auktoritet
Human in the loop används ofta som ett magiskt uttryck. Det är inte magi. En trött granskare med svag bevisning, otydlig policy och en kö på tvåhundra ärenden är inte ett säkerhetssystem. Det är en person som placerats i slutet av ett löpande band och ombetts att vara styrning. Det kan fungera en kort tid, särskilt om personen är erfaren och envis. Det är ingen utformning.
Mänsklig auktoritet måste vara specifik. Vilka ärenden kräver granskning. Vilken bevisning ser granskaren. Kan granskaren ändra strukturerade fält eller bara godkänna text. Vet granskaren om modellen var osäker eller om policyn krävde eskalering. Matas oenigheter tillbaka till utvärderingen. Är granskare skyddade från automatiseringsbias. Kan de pausa ett arbetsflöde. Kan de eskalera till en specialist. Kan de se liknande tidigare ärenden. Kan de förklara ett beslut för den berörda personen. Dessa detaljer avgör om mänsklig tillsyn är verklig eller dekorativ.
God tillsyn skiljer också omdöme från administrativ räddningsplockning. Människor ska inte behöva lägga tid på att hitta saknade källidentifierare, avduplicera återförsök, översätta modellprosa till arbetsflödesstatus eller gissa vilken policyversion som gällde. Systemet ska paketera ärendet. Människan ska tillämpa omdöme där omdöme behövs: omtvistad innebörd, undantag, proportionalitet, kontext, empati och ansvar. Om människan mestadels städar upp infrastrukturella luckor har organisationen förväxlat bemanning med säkerhet.
Designen måste också tillåta människor att invända mot automatisering utan att friktionen blir ett straff. Om det krävs åtta klick för att åsidosätta modellen och ett klick för att acceptera, har gränssnittet en policy. Om eskalering får ett team att framstå som långsamt kommer människor att undvika eskalering. Om mätetal endast belönar genomströmning blir säkerhetsgranskningar ceremoniella. Systemdesign omfattar incitament, skärmar, köer och standardval. Modellen kanske inte känner till mätetalet, men människorna kommer definitivt att göra det.
Lokalitet förändrar risk
Var AI-arbete sker spelar roll. Ett system som skickar varje dokument till en fjärrmodell har andra risker än ett som utför extrahering nära datan och endast skickar ett härlett fält. Ett system som lagrar spår i tjänsteleveransen har andra risker än ett som för oberoende revisionsloggar. Ett system som förlitar sig på en enda extern router har andra återställningsmöjligheter än ett som kan degradera lokalt. Lokalitet är inte nationalism med ett nätverksdiagram. Det är den praktiska frågan om vilka risker som flyttas när data, beräkning, policy och bevis flyttas.
Visst arbete bör ske nära känslig data eftersom att flytta datan skapar exponering. Visst arbete bör ske nära användare eftersom latens påverkar säkerheten. Visst arbete bör ske i en central tjänst eftersom specialiserad granskning eller hårdvara krävs. Vissa bevis bör lagras bort från modellens leveransväg eftersom leveransvägen kan vara det som utreds. Den säkra designen är sällan allt lokalt eller allt på distans. Det är medveten placering.
Lokalitet påverkar också juridiskt och organisatoriskt ansvar. Om ett modellanrop korsar regioner, vilken lag styr datan. Om ett index byggs utanför källsystemet, hur sprids raderingar. Om en leverantör ändrar en modell, hur sker notis och testning. Om loggar ligger i en leverantörsportal, kan organisationen exportera dem under en incident. Detta är inte abstrakta suveränitetsfrågor. Det är säkerhetsfrågor eftersom de avgör om organisationen kan kontrollera och förklara systemet under press.
Fel placering kan göra säkert beteende dyrt. Om varje verifieringssteg kräver en fjärrresa kan team välja att stickprova i stället för att kontrollera varje ärende. Om revisionsdata är svår att sammanfoga blir utredningar långsamma. Om privat data måste färdas för enkel klassificering ökar risken utan vinst. God lokalitetsdesign minskar kostnaden för att göra det säkra. Detta spelar roll eftersom kontroller som är för dyra så småningom kommer att beskrivas som valfria, vilket är hur många dåliga historier börjar.
Utvärderingen måste följa systemet
Många team utvärderar modellen men glömmer att utvärdera systemet. De testar om svaren är korrekta på en uppsättning prompts och distribuerar sedan i ett arbetsflöde med behörigheter, källfärskhet, köer, verktygsanrop, mänsklig granskning, försök och föränderliga policyer. Modellriktmärket kan fortfarande vara användbart, men det beskriver inte längre hela risken. Säkerhetsfel lever ofta i skarvarna.
En systemutvärdering testar beteendet från början till slut. Den frågar om rätt källa hämtas för rätt användare. Den kontrollerar om inaktuella data vägras. Den verifierar att verktygsanrop blockeras utan behörighet. Den mäter om högriskärenden når människor. Den testar återställning. Den testar köfördröjning. Den testar modelluppgraderingsvägar. Den testar konstiga men vanliga fall: saknat datum, dubblettkund, regionundantag, överklagande efter korrigering, källradering, partiellt avbrott, överbelastad granskare. Produktionen har en smak för de fall som ingen trodde var dramatiska nog.
Utvärderingen bör inkludera negativ förmåga. Systemet måste vara bra på att inte göra saker. Inte svara utan bevis. Inte korsa behörighetsgränser. Inte eskalera till handling när endast utkast är tillåtet. Inte dölja osäkerhet. Inte använda en källa efter radering. Inte fortsätta när ett verktyg returnerar inkonsekvent tillstånd. Säkerhet beror lika mycket på vägran och paus som på noggrannhet. Den viktigaste utmatningen från ett säkert AI-system kan vara inte tillräckligt med bevis, vilket är en mening som inget demoteam någonsin sätter på en banderoll.
Systemutvärdering förändrar också releasehanteringen. En promptändring, modelländring, indexåteruppbyggnad, policyuppdatering, ändring av verktygsbehörigheter eller ändring av granskargränssnittet kan förändra säkerheten. Varje sådan ändring behöver en testomfattning och en återställningsplan. Teamet bör veta vilka beteenden som ändrades och vilka risker som ökade. Detta är tråkigt på samma sätt som bilbälten är tråkiga. Det blir intressant först när det saknas, vilket är för sent för att vara bekvämt.
Lärdomen
AI-säkerhet är mestadels systemdesign eftersom skada vanligtvis färdas genom system. En modellutmatning blir riskabel när ett arbetsflöde litar för mycket på den, en verktygsgateway är för vid, bevis saknas, tillståndet är vagt, granskningen är överbelastad, loggarna är svaga eller återställningen är imaginär. Modellen kan vara den synliga källan till meningen, men systemet avgör om meningen blir handling.
Den här synen är mindre dramatisk än många debatter om AI-säkerhet, och mer användbar för organisationer som driftsätter system nu. Den ber team att dra gränser, namnge ansvar, bevara bevis, designa tillstånd, placera arbete medvetet, utvärdera från början till slut och ge människor verklig makt. Den behandlar modellen som en kraftfull komponent i en säkerhetsanalys, inte som hela säkerhetsanalysen. Det är den vuxna hållningen. Den ger också ingenjörer något att bygga utöver ännu en policy-PDF, vilket är vänligt mot alla.
Säkerhetsansvariges fråga efter demon var helt rätt. Vad händer om modellen har fel men är övertygande. Ett säkert system borde ha ett svar: den kan bara utkasta här, den måste citera aktuella källor där, den kan inte anropa det verktyget, det här fallet går till granskning, den här åtgärden lämnar ett kvitto, det här arbetsflödet kan pausas, den här releasen kan rullas tillbaka, det här beslutet kan ifrågasättas. De svaren är inte vibbar. De är design.
Det kommer alltid att finnas osäkerhet inom AI. Den praktiska uppgiften är att hindra osäkerhet från att bli obegränsad auktoritet. Det görs med gränssnitt, tillstånd, kontroller, bevis, lokalisering, utvärdering, återställning och mänskligt omdöme som har utrustats på rätt sätt. Med andra ord: systemdesign. Inte för att värderingar inte spelar roll, utan för att värderingar måste göras genomförbara innan de kan skydda någon.