Virksomheders AI-kontrolmekanismer kan være vigtigere end AI-fronten

Glem AI-fronten. Kunderne kræver, at virksomheder indfører flere kontrolmekanismer for den AI, de allerede bruger, og erfaringerne med PCI DSS giver en nyttig model.

AI’s regulatoriske friperiode er forbi. Nyere afsløringer har sat gang i diskussioner om at sætte farten ned på AI-fronten og indføre obligatoriske kontroller. Et af de få områder, hvor der er enighed, er, at kontrollerne bør ligge uden for modellerne og underkastes uafhængig verifikation.

Det diskuteres stadig, hvad der nu skal ske, men myndighederne er i bevægelse. EU’s AI-forordning indfører gradvist sikkerhedsforpligtelser, herunder ansvar for købere. I USA bliver NIST’s ramme for risikostyring af AI taget i brug som standard for, hvad der udgør forsvarlig omhu. Globalt er OWASP’s top 10 over LLM-applikationer blevet et almindeligt referencepunkt i sikkerhedsvurderinger, og ISO/IEC 42001-certificering begynder at dukke op i indkøbsdokumenter.

Det betyder, at modeludviklerne ikke er de eneste, der kan holdes ansvarlige. Sikkerhedsforpligtelser og -risici gælder også virksomheder, der bruger modeller, som allerede er lanceret, især i højrisikosituationer. Forkerte svar i et sikkerhedsspørgeskema fra en kunde eller i et svar på en RFP kan forsinke en B2B-aftale.

PCI DSS viser vejen

Heldigvis har vi set det før. For tyve år siden byggede sikkerheden i webapplikationer for det meste på regelmæssige kodegennemgange, statiske analyser og udviklernes omhu. Derefter krævede PCI DSS-krav 6.6, der blev udgivet i 2006 og håndhævet fra 2008, at organisationer, som håndterede kortholderdata, enten gennemgik al applikationskode for sårbarheder eller installerede automatiserede tekniske kontroller. Senere blev muligheden for kodegennemgang fjernet, og tekniske kontroller blev obligatoriske.

PCI DSS begyndte dog ikke som lovgivning. Det begyndte som en kontraktlig standard, der omformede markedet, sandsynligvis hurtigere, end lovgivning ville have gjort, fordi kontrakter udvikler sig hurtigere end statslige love.

Tilsvarende oplever organisationer nu pres for at indføre kontrolmekanismer for AI, der allerede er taget i brug, ikke fra myndighederne, men fra kunder og partnere – gennem sikkerhedsspørgeskemaer, RFP-klausuler og krav i forsikringspolicer.

Løs de driftsmæssige udfordringer, så følger efterlevelsen

Det kan være svært at håndtere det pres, fordi AI-styring ikke kun handler om politikker. Det handler også om løbende teknisk dokumentation.

Mange af de virksomheder, jeg taler med, har et halvt dusin eller flere modeller i produktion. Ofte kæder eller orkestrerer de modellerne, så outputtet fra én model bliver input til en anden. Forestil dig at skulle dokumentere, at én enkelt politik håndhæves på tværs af hele systemet – for eksempel at modeloutput ikke indeholder personhenførbare oplysninger (PII) – under disse forhold. Manuel kontrol af flere modeller, der hver er konfigureret individuelt, ville lægge beslag på udviklernes tid. Desuden har de fleste organisationer svært ved at håndtere ikke-godkendt og højrisikopræget brug af AI, for eksempel når medarbejdere indsætter følsomme data i forbrugerrettede AI-værktøjer, eller SaaS-udbydere uden videre aktiverer nye AI-funktioner. Ansvaret ligger dog fuldt ud hos virksomheden.

I så krævende situationer kan kravene koges ned til én enkel opgave: Vis, at I løbende kan begrænse input til og output fra modellerne og samtidig registrere denne aktivitet, så den kan verificeres. Når applikationer kalder modeller, agenter aktiverer værktøjer, og modeller udfører handlinger eller udløser arbejdsgange, er det handlingen, der skal kontrolleres: værktøjskaldet, API-anmodningen eller udløsningen af arbejdsgangen.

Flyt sikkerheden til inferensvejen

Handlingen udgør det håndhævelsespunkt for applikationstrafik, som eksperter i applikationssikkerhed har brugt 20 år på at etablere. Især når inferens dirigeres gennem delt infrastruktur, bliver inferensvejen det ideelle kontrolpunkt på tværs af modeller og endda på tværs af ikke-godkendt AI-brug. AI-inferenstrafik skal leveres, inspiceres, autentificeres og styres som enhver anden vigtig interaktion med en applikation, alt efter hvor trafikken kommer fra, og hvad den forsøger at gøre. I modsætning til manuel kontrol kan styring af inferenstrafik skaleres.

Sådan kommer I i gang

I lyset af den retning, reguleringen bevæger sig i, bør organisationer straks begynde på tre ting:

1. Kortlæg, hvor I kan blive gjort ansvarlige – fra SaaS-API’er og hostede slutpunkter til skygge-AI.
2. Adskil sikkerhedspolitik og håndhævelse fra modellerne, og placér dem i inferensvejen.
3. Sørg for, at der oprettes revisionsspor uden for modellernes og agenternes kontrol, da det er påvist, at de forsøger at ændre registreringer af deres egne handlinger.

Det er stadig ved at blive fastlagt, hvad der tæller som tilstrækkelig overvågning og håndhævelse, men jeres drifts- og sikkerhedsteams ved, hvad der reelt kan håndhæves, hvor meget en kontrol koster i forsinkelse og kompleksitet, og hvor en velment regel kan føre til et forkert resultat. Inddrag dem nu. De sikkerhedsrisici og -forpligtelser, der følger med brugen af AI, er reelle, og jeres kunder og ledelse går uden tvivl mere op i de risici, de står over for i dag, end i truslerne fra morgendagens AI-modeller i front.