AI-sikkerhed er mest systemdesign
Sikkerhedsmødet efter demoen
Demoen var gået godt på den sædvanlige måde. Modellen læste en stak interne dokumenter, besvarede et politisk spørgsmål, foreslog et næste skridt og lavede et pænt resumé til sagsmappen. Rummet nikkede. Nogen spurgte, om den kunne forbindes til workflowsystemet. En anden spurgte, hvor hurtigt. Så spurgte sikkerhedsansvarlige, hvad der ville ske, hvis modellen tog fejl, men var overbevisende. Rummet blev meget interesseret i småkagerne.
Det spørgsmål er, hvor praktisk AI-sikkerhed begynder. Ikke i det abstrakte og ikke i et slogan. I formen på systemet omkring en model, der nogle gange tager fejl, nogle gange er forældet, nogle gange er overmodig, nogle gange er undervurderende og nogle gange har ret af den forkerte grund. Sikkerhedsproblemet er ikke kun modeladfærd. Det er, hvad systemet tillader den adfærd at gøre.
En model, der skriver et udkast til en sætning, er én risiko. En model, der opdaterer en ydelsesafgørelse, er en anden. En model, der kalder et værktøj med skriveadgang, er en tredje. En model, der ruter en patient, afviser et krav, ændrer en kreditgrænse eller styrer udstyr, befinder sig i en helt anden fareklasse. Den samme underliggende model kan være harmløs, nyttig, risikabel eller uacceptabel afhængigt af grænser, tilstand, evidens, autoritet, overvågning og genopretning. Det er derfor, AI-sikkerhed for det meste er systemdesign.
For det meste gør arbejde i den sætning. Model forskning betyder noget. Datakvalitet betyder noget. Justeringsmetoder betyder noget. Evalueringsvidenskab betyder noget. Men når en organisation implementerer AI, bliver sikkerhed operationel. Hvem må spørge. Hvad må modellen se. Hvad må den ændre. Hvilke beviser kræves. Hvilken tilstand bevares. Hvad sker der, når kilder er uenige. Hvornår skal et menneske godkende. Hvordan opdages drift. Hvordan rulles en dårlig udgivelse tilbage. Det er designspørgsmål, før de er etikkerklæringer. Etikkerklæringen kan være oprigtig. Systemet udfører ikke oprigtighed.
Sikkerhed er et kontrolproblem
Når folk hører sikkerhed, tænker de ofte på værdier, træningsdata, afvisningspolitikker og modeljustering. Det er en del af billedet, men et implementeret system har også brug for kontroller. En kontrol er noget, der ændrer, hvad der kan ske: et adgangstjek, et skema, en timeout, en tærskel, en menneskelig godkendelse, en sandkasse, en hastighedsgrænse, en verificator, en rollback, en nødafbryder, en registrering, der ikke kan redigeres af serveringsstien. Kontroller er kedelige, indtil de mangler. Så bliver de hele mødet.
Et sikkert AI-system forudsætter, at modellen kan fejle, og designer den omkringliggende maskineri derefter. Det adskiller forslag fra handling. Det begrænser værktøjets autoritet. Det kontrollerer dokumentation, før tilstande ændres. Det gør usikkerhed synlig. Det registrerer modelversion og kildens omfang. Det afviser, når obligatoriske felter mangler. Det giver operatører mulighed for at pause automatisering. Det behandler et modeloutput som en kandidat, ikke som et dekret fra et meget veltalende regneark.
Dette er almindelig sikkerhedsteknik med en sprogmodel i midten. Luftfart, medicin, jernbaner, industriel styring og finans har alle lært, at vigtige systemer har brug for lagdelte kontroller, fordi ingen komponent er perfekt. AI-versionen føles ny, fordi komponenten taler. Tale gør fejl socialt overbevisende. Et forkert svar, der lyder roligt, kan lettere glide forbi en træt operatør end en blinkende rød fejl. Kontroldesignet skal derfor være mere stædigt end prosateksten.
Kontroldesign starter med at spørge, hvad systemet må påvirke. Hvis AI'en kun kan udarbejde udkast, fokuserer sikkerheden på kildekvalitet, hallucinationskontrol, brugergrænsefladens klarhed og gennemgang. Hvis den kan dirigere arbejde, tilføjer sikkerheden tilstandssporing, køintegritet, serviceniveauer og klageveje. Hvis den kan kalde værktøjer, tilføjer sikkerheden tilladelsesområder, argumentvalidering, transaktionslogge og kompenserende handlinger. Hvis den kan påvirke rettigheder eller fysiske systemer, kræver sikkerheden dokumentation, formel gennemgang, begrænset autonomi og seriøs hændelsesplanlægning. Modellen er den ene del. Autoritetsrammen er den anden.
Grænsen er produktet
Den vigtigste linje i et AI-system er ofte ikke synlig i grænsefladen. Det er grænsen mellem at læse og skrive, anbefale og beslutte, opsummere og registrere, assistere og handle. Svage grænser er sådan, uskyldige prototyper bliver usikre tjenester. En model, der starter som et udkastværktøj, får en knap til at anvende udkastet. Så får den et værktøj til at opdatere sagen. Så får den en dirigeringsregel, fordi teamet har travlt. Seks måneder senere kan ingen forklare, hvilke beslutninger der er automatiserede, og hvilke der blot er assisterede. Dette er ikke ondskab. Det er omfangskryb i behagelige sko.
Gode grænser er eksplicitte og inspicerbare. Modellen må læse disse kilder, ikke andre. Den må foreslå disse felter, ikke forpligte dem. Den må kalde dette værktøj med disse argumenter, ikke vilkårlig tekst. Den må dirigere lavrisikosager, ikke omstridte sager. Den må kun svare, når dokumentationen er aktuel. Den må ikke bruge private noter til offentlige forklaringer. Den må ikke krydse fra én lejer, region, konto eller juridisk basis til en anden, fordi næste afsnit så ud til at være nyttigt.
Grænser skal også håndhæves uden for modellen. En prompt, der siger, at man ikke må skrive til kundedatabasen, er ikke en grænse, hvis værktøjet har skriveadgang og ingen gateway. En systembesked, der siger, at man skal angive kilder, er ikke en grænse, hvis svar kan gemmes uden kildehenvisninger. Et politikafsnit, der siger, at menneskelig godkendelse er påkrævet, er ikke en grænse, hvis arbejdsgangen lader automatisering markere som godkendt. Sikkerhedsinstruktioner inde i modellen er nyttige, men de er ikke nok. Systemet skal gøre usikre stier vanskelige eller umulige.
Dette er det uromantiske arbejde, der faktisk beskytter mennesker. Typede værktøjskald. Snævre omfang. Skrivebeskyttede standardindstillinger. Separate godkendelsestjenester. Idempotente operationer. Revisionslogge. Versionerede politikker. Køtilstande. Eksplicitte afvisningstilstande. Ordforrådet lyder, som om en backend-ingeniør havde en stille weekend med en clipboard. Godt. Sikkerhed i produktion ser normalt sådan ud. Det forsøger ikke at vinde en slogan-konkurrence.
State er der, hvor sikkerhed bliver reel
AI-samtaler kan få systemer til at se statsløse ud. En bruger spørger, en model svarer, skærmen ændrer sig. Produktion er ikke statsløs. Sager flytter sig. Billetter ældes. Rettigheder udløber. Dokumenter rettes. En modelversion ændres. Et menneske tilsidesætter en anbefaling. En appel ankommer. En bruger spørger, hvorfor noget skete sidste måned. Sikkerhed afhænger af, om systemet har bevaret den state, der er nødvendig for at svare.
State fortæller systemet, hvad der allerede er sket, og hvad der kan ske derefter. Uden den ser modellen et udsnit og gætter resten. Sådan opstår dobbelte handlinger, deadlines forsvinder, godkendelser antages, og gammel dokumentation genindgår i en ny beslutning. En sikker arbejdsgang registrerer eksplicitte states: kladde, dokumentation mangler, politik blokerer, gennemgang krævet, godkendt, udført, anfægtet, rettet, tilbagekaldt. Disse states er ikke dekorative. De forhindrer modellen i at behandle en konsekvensrig proces som en chatlog med ambitioner.
State giver også mennesker løftestang. En operatør kan inspicere, hvorfor en sag er under gennemgang. En leder kan se, om automatisering skaber en kø. En revisor kan afspille, hvilke kildeversioner der var aktive. En bruger kan anfægte et resultat med noget mere solidt end et skærmbillede. En udvikler kan måle, om en ny model øger afvisninger, eskaleringer eller omarbejdning. Uden state bliver enhver sikkerhedssamtale teater. Folk taler om ansvar, men systemet har forlagt navneordene.
For AI bør state omfatte model- og politikversion, prompt- eller skabelon-id, kildesæt, hentningstidsstempel, værktøjskald, tillid eller usikkerhed, afvisningsårsag, menneskelig handling og nedstrømseffekt. Ikke alt det hører til i én loglinje, og ikke alt skal være synligt for alle. Privatliv og sikkerhed betyder noget. Men oplysningerne skal eksistere under kontrolleret adgang. Ellers bliver sikkerhed afhængig af hukommelse, og hukommelse er en berygtet dårlig database med fremragende undskyldninger.
Dokumentation er sikkerhedsskinnen
Et modelsvar er sikrere, når det er forbundet med dokumentation. Det lyder indlysende, indtil systemet er under pres. Dokumentation springes over, fordi det tilføjer latenstid. Citater gemmes som tekst frem for identifikatorer. Hentningsscorer bevares ikke. Kildeversioner overskrives. Modellen skriver en selvsikker forklaring ud fra et dokument, der siden er blevet rettet. Senere spørger alle, hvorfor svaret var forkert. Svaret er, at skinnen var dekorativ.
Brugbar dokumentation er ikke en fodnote. Det er en kæde. Forespørgslen kom ind med en identitet og et formål. Kilder blev udvalgt under tilladelse. Hentning fandt specifikke bidder eller poster. Modellen producerede et output under en navngiven version. En verificering tjekkede påstande eller tærskler. Et menneske accepterede, redigerede eller afviste. Handlingen ændrede tilstand. Systemet gemte nok af kæden til at kunne afspille eller udfordre den. Dette er ikke bureaukrati for bureaukratiets skyld. Det er sådan sikkerhed overlever tid.
Dokumentation beskytter også modellen mod at blive bedt om at udføre umuligt arbejde. Hvis systemet kræver aktuelle kilder, kan modellen afvise forældet input. Hvis systemet kræver to matchende poster, kan den markere uenighed. Hvis systemet kræver kildeidentifikatorer, kan den stoppe ubegrundede påstande. Modellen skal ikke længere forvandle manglende beviser til flydende håndtering af usikkerhed. Den kan returnere en sikker tilstand. Dette er venligere mod modellen og meget venligere mod den person, der påvirkes af outputtet.
Der er en balance. Indsamling af dokumentation skal ikke blive til overvågning. Følsomt indhold kan hashes, redigeres, adskilles eller opbevares i begrænsede perioder. Pointen er ikke at registrere alt for evigt. Pointen er at bevare de fakta, der er nødvendige for at inspicere vigtig adfærd. Sikkerhed uden dokumentation er bare tillid med en pænere jakke. Det kan se fint ud i lobbyen. Det holder ikke til en hændelse.
Mennesker har brug for designet autoritet
Human in the loop bruges ofte som et magisk udtryk. Det er ikke magi. En træt gennemgående med svag dokumentation, uklar politik og en kø på to hundrede sager er ikke et sikkerhedssystem. Det er en person placeret for enden af et samlebånd og bedt om at være styring. Det kan virke kortvarigt, især hvis personen er erfaren og stædig. Det er ikke et design.
Menneskelig autoritet skal være specifik. Hvilke sager kræver gennemgang. Hvilken dokumentation ser gennemgående. Kan gennemgående ændre strukturerede felter eller kun godkende prosa. Ved gennemgående, om modellen var usikker, eller om politikken krævede eskalering. Bliver uenigheder ført tilbage til evaluering. Er gennemgående beskyttet mod automatiseringsbias. Kan de pause en arbejdsgang. Kan de eskalere til en specialist. Kan de se lignende tidligere sager. Kan de forklare en beslutning til den berørte person. Disse detaljer afgør, om menneskeligt tilsyn er reelt eller ornamentalt.
Godt tilsyn adskiller også dømmekraft fra administrativt oprydningsarbejde. Folk bør ikke bruge deres tid på at finde manglende kildeidentifikatorer, fjerne dubletter blandt gentagne forsøg, oversætte modelprosa til arbejdsgangstilstande eller gætte på, hvilken politikversion der blev anvendt. Systemet bør pakke sagen. Mennesket bør udøve dømmekraft, hvor dømmekraft er nødvendig: omtvistet betydning, undtagelser, proportionalitet, kontekst, empati og ansvar. Hvis mennesket for det meste rydder op efter infrastrukturmangler, har organisationen forvekslet bemanding med sikkerhed.
Designet skal også give mennesker mulighed for at være uenige med automatiseringen uden at friktion bliver til straf. Hvis det kræver otte klik at tilsidesætte modellen og ét klik at acceptere, har grænsefladen en politik. Hvis eskalering får et team til at fremstå langsomt, vil folk undgå eskalering. Hvis målinger kun belønner gennemløb, bliver sikkerhedsgennemgange ceremonielle. Systemdesign omfatter incitamenter, skærme, køer og standardindstillinger. Modellen kender måske ikke målingen, men folkene gør helt sikkert.
Lokalitet ændrer risiko
Hvor AI-arbejde finder sted, betyder noget. Et system, der sender hvert dokument til en fjern model, har andre risici end et, der udfører ekstraktion tæt på dataene og kun sender et afledt felt. Et system, der gemmer spor i tjenesten, har andre risici end et, der fører uafhængige revisionsregistre. Et system, der er afhængigt af en enkelt ekstern router, har andre genopretningsmuligheder end et, der kan nedgradere lokalt. Lokalitet er ikke nationalisme med et netværksdiagram. Det er det praktiske spørgsmål om, hvilke risici der flytter sig, når data, beregning, politik og beviser flytter sig.
Noget arbejde bør ske tæt på følsomme data, fordi det at flytte dataene skaber eksponering. Noget arbejde bør ske tæt på brugerne, fordi latenstid påvirker sikkerheden. Noget arbejde bør ske i en central tjeneste, fordi specialiseret gennemgang eller hardware er nødvendig. Nogle beviser bør opbevares væk fra modeltjenestens sti, fordi tjenestens sti kan være genstanden for undersøgelsen. Det sikre design er sjældent alt lokalt eller alt fjernt. Det er bevidst placering.
Lokalitet påvirker også juridisk og organisatorisk ansvar. Hvis et modelkald krydser regioner, hvilken lov gælder så for dataene. Hvis et indeks bygges uden for kildesystemet, hvordan udbredes sletninger så. Hvis en leverandør ændrer en model, hvordan modtages meddelelse, og hvordan udføres test så. Hvis logfiler ligger i en leverandørportal, kan organisationen så eksportere dem under en hændelse. Det er ikke abstrakte suverænitetsspørgsmål. Det er sikkerhedsspørgsmål, fordi de afgør, om organisationen kan kontrollere og forklare systemet under pres.
Forkert placering kan gøre sikker adfærd dyr. Hvis hvert verifikationstrin kræver en fjern rundtur, kan teams vælge at stikprøve i stedet for at kontrollere hver sag. Hvis revisionsdata er svære at sammenkæde, bliver undersøgelser langsomme. Hvis private data skal rejse for simpel klassificering, øges risikoen uden gevinst. Godt lokalitetsdesign reducerer omkostningerne ved at gøre det sikre. Det betyder noget, fordi kontroller, der er for dyre, til sidst vil blive beskrevet som valgfrie, hvilket er sådan mange dårlige historier begynder.
Evaluering skal følge systemet
Mange teams evaluerer modellen og glemmer at evaluere systemet. De tester, om svar er korrekte på et sæt prompts, og implementerer derefter i en arbejdsgang med tilladelser, kildefriskhed, køer, værktøjskald, menneskelig gennemgang, forsøg igen og skiftende politikker. Modelbenchmarken kan stadig være nyttig, men den beskriver ikke længere hele risikoen. Sikkerhedsfejl lever ofte i samlingerne.
En systemevaluering tester end-to-end-adfærd. Den spørger, om den rigtige kilde hentes til den rigtige bruger. Den kontrollerer, om forældede data afvises. Den verificerer, at værktøjskald blokeres uden tilladelse. Den måler, om højrisikosager når mennesker. Den tester rollback. Den tester køforsinkelse. Den tester modelopgraderingsstier. Den tester mærkelige, men almindelige tilfælde: manglende dato, duplikeret kunde, regionsundtagelse, appel efter korrektion, kildesletning, delvis nedbrud, overbelastet anmelder. Produktion har en smag for de tilfælde, ingen troede var dramatiske nok.
Evaluering bør inkludere negativ kapacitet. Systemet skal være godt til ikke at gøre ting. Ikke at svare uden dokumentation. Ikke at overskride tilladelsesgrænser. Ikke at eskalere til handling, når kun udkast er tilladt. Ikke at skjule usikkerhed. Ikke at bruge en kilde efter sletning. Ikke at fortsætte, når et værktøj returnerer inkonsistent tilstand. Sikkerhed afhænger lige så meget af afvisning og pause som af nøjagtighed. Den vigtigste output fra et sikkert AI-system kan være ikke nok dokumentation, hvilket er en sætning, intet demoteam nogensinde sætter på et banner.
Systemevaluering ændrer også release management. En promptændring, modelændring, indeksgenopbygning, politikopdatering, værktøjstilladelsesændring eller anmeldergrænsefladeændring kan ændre sikkerheden. Hver kræver et testomfang og en rollback-plan. Teamet bør vide, hvilke adfærdsændringer der skete, og hvilke risici der steg. Dette er kedeligt på den måde, sikkerhedsseler er kedelige. Det bliver kun interessant, når det er fraværende, hvilket er for sent til komfort.
Lærdommen
AI-sikkerhed er mest systemdesign, fordi skade normalt rejser gennem systemer. En modeloutput bliver risikabel, når en arbejdsgang stoler for meget på den, en værktøjsgateway er for bred, dokumentation mangler, tilstand er vag, gennemgang er overbelastet, logfiler er svage, eller rollback er imaginær. Modellen kan være den synlige kilde til sætningen, men systemet beslutter, om sætningen bliver til handling.
Denne tilgang er mindre dramatisk end mange AI-sikkerhedsdebatter og mere brugbar for organisationer, der implementerer systemer nu. Den beder teams om at trække grænser, navngive autoritet, bevare dokumentation, designe tilstande, placere arbejde bevidst, evaluere end-to-end og give mennesker reel magt. Den behandler modellen som en kraftfuld komponent i en sikkerhedscase, ikke som hele sikkerhedscasen. Det er den voksne position. Den giver også ingeniører noget at bygge ud over endnu en politik-PDF, hvilket er venligt mod alle.
Sikkerhedsansvarliges spørgsmål efter demoen var præcis rigtigt. Hvad sker der, hvis modellen tager fejl, men er overbevisende. Et sikkert system bør have et svar: det kan kun udarbejde udkast her, det skal citere aktuelle kilder der, det kan ikke kalde det værktøj, denne sag går til gennemsyn, denne handling efterlader en kvittering, denne arbejdsgang kan sættes på pause, denne udgivelse kan rulles tilbage, denne beslutning kan anfægtes. Disse svar er ikke fornemmelser. De er design.
Der vil altid være usikkerhed i AI. Den praktiske opgave er at forhindre usikkerhed i at blive ubegrænset autoritet. Det gøres med grænseflader, tilstande, kontroller, dokumentation, lokalitet, evaluering, genoprettelse og menneskelig dømmekraft, der er ordentligt udstyret. Med andre ord systems design. Ikke fordi værdier ikke betyder noget, men fordi værdier skal gøres eksekverbare, før de kan beskytte nogen.