AI-styring: å revidere det som ikke er deterministisk

De fleste virksomheter som allerede bruker AI i noe som betyr noe, kan svare på om de bruker AI. Færre kan svare på hvilke beslutninger som påvirkes, hvem som godkjente at systemet ble satt i drift, hvilken modellversjon som kjørte da beslutningen ble tatt, og hvor dataene i konteksten kom fra. Det er sjelden et teknologiproblem. Det er et styringsproblem, og det ser ut som informasjonssikkerhet gjorde for femten år siden: praksis som virker, uten sporbarhet som tåler spørsmål. Dette er skrevet for dere som er forbi det innledende: modeller i produksjon, avtaler på plass, og noen som har begynt å spørre hvordan det styres.

Hva ISO/IEC 42001 tilfører

ISO/IEC 42001 er et ledelsessystem for kunstig intelligens, bygget på den samme harmoniserte strukturen som ISO 27001 og ISO 9001: kontekst, ledelse, planlegging, støtte, drift, evaluering og forbedring. Standarden er sertifiserbar på vanlig måte. Rammen er altså kjent. Det nye er hva den ber dere styre.

Den krever en AI-policy, definerte roller gjennom hele livsløpet til et AI-system, styring av dataene systemet hviler på, en erklæring om anvendelighet for kontrollene i vedlegg A, og framfor alt en konsekvensvurdering av AI-systemet. Forskjellen på den og en ordinær risikovurdering er ikke akademisk. En risikovurdering etter 27001 spør hva som kan skade virksomheten. Konsekvensvurderingen etter 42001 spør i tillegg hva systemet kan gjøre mot enkeltpersoner, grupper og samfunn som berøres av beslutningene. Den spørsmålsstillingen lar seg ikke arve fra ISMS-et.

Standarden står ikke alene. ISO/IEC 22989 gir begrepsapparatet, ISO/IEC 23894 veiledning om risikostyring for AI, og ISO/IEC 42005 om selve konsekvensvurderingen. Berigo er autorisert PECB-partner på ISO/IEC 42001.

Forholdet til ISO 27001

Har dere et fungerende ISMS, skal dere ikke bygge et parallelt system ved siden av. Omfang, risikometodikk, avvikshåndtering, internrevisjon og ledelsens gjennomgang kan være felles. Det som må komme i tillegg, er en risikotaksonomi for AI og et eget sett kontroller. Merk samtidig at avgrensningen fungerer annerledes: et ISMS trekkes gjerne rundt organisasjonen og tjenestene, mens et AI-styringssystem må trekkes rundt de AI-systemene dere faktisk har, og de rollene dere har i dem: som leverandør, som ibruktaker, eller begge deler.

27001 beskytter konfidensialitet, integritet og tilgjengelighet. 42001 legger til egenskaper som ikke lar seg måle på samme måte: robusthet, forklarbarhet, rettferdighet og evnen til å gripe inn mens systemet er i drift. Et AI-system kan være upåklagelig sikret og likevel produsere systematisk skjeve resultater. Det er ikke et sikkerhetsavvik i 27001-forstand, men det er et avvik i AI-styringen, og det er nettopp dette 42001 skal fange opp.

AI Act: rollen avgjør pliktene

EUs AI-forordning, forordning (EU) 2024/1689, klassifiserer etter risiko: forbudt bruk, høyrisiko, bruk med transparensplikter, og resten. Ved siden av dette går et eget regime for generelle AI-modeller, med plikter som først og fremst treffer den som utvikler modellen. Men den praktiske inngangen er sjelden risikoklassen. Det er rollen. De aller fleste virksomheter er ibruktaker, det forordningen kaller deployer, og ikke leverandør, og pliktene er vesentlig forskjellige.

Ibruktakerens plikter ved høyrisikosystemer er konkrete og mindre kjent enn de burde være. Systemet skal brukes i tråd med leverandørens bruksanvisning. Den menneskelige kontrollen skal legges til navngitte personer med nødvendig kompetanse, opplæring og myndighet, og med den støtten som skal til for faktisk å kunne overprøve. Har dere kontroll over inndataene, skal de være relevante og tilstrekkelig representative for formålet. Driften skal overvåkes, og leverandør og myndighet varsles ved risiko og alvorlige hendelser. Logger som systemet genererer automatisk, og som dere rår over, skal oppbevares, som hovedregel i minst seks måneder. Tas systemet i bruk på arbeidsplassen, skal ansatte og deres representanter informeres på forhånd. Og enkeltpersoner som er gjenstand for beslutninger tatt med systemet, har krav på å få vite det; ved beslutninger med rettsvirkning eller tilsvarende betydelig innvirkning kan de be om en forklaring på hvilken rolle systemet spilte.

Det som overrasker flest, er hvor lett man skifter rolle. Setter dere eget navn eller varemerke på et høyrisikosystem, endrer det tiltenkte formålet slik at systemet blir høyrisiko, eller gjør vesentlige endringer i det, kan dere bli regnet som leverandør, med leverandørens fulle dokumentasjons-, samsvars- og registreringsplikter. En intern «liten tilpasning» av en innkjøpt modell er ikke nødvendigvis liten juridisk sett.

To presiseringer hører med. Enkelte ibruktakere skal i tillegg gjennomføre en vurdering av konsekvenser for grunnleggende rettigheter før høyrisikosystemet tas i bruk: offentlige organer, private som yter offentlige tjenester, og de som bruker slike systemer til kredittvurdering av fysiske personer eller til risikovurdering og prising innen liv- og helseforsikring. Og forordningen er merket EØS-relevant. Uavhengig av når den innlemmes i norsk rett, treffer kravene norske virksomheter via kunder og eiere i EU, og gjennom at forordningen også omfatter bruk utenfor unionen når resultatet brukes innenfor. Kravene fases inn over tid, og tidslinjene har vært justert politisk underveis: planlegg mot innholdet i kravene, ikke mot datoene.

Tre vurderinger som ikke er det samme

Tre vurderinger blir rutinemessig blandet sammen, selv om de hviler på ulike hjemler, stiller ulike spørsmål og utløses av ulike ting. Personvernkonsekvensvurderingen, DPIA etter personvernforordningen artikkel 35, utløses når behandlingen sannsynligvis medfører høy risiko for de registrertes rettigheter og friheter, og handler om personopplysninger. Konsekvensvurderingen etter ISO/IEC 42001 dekker et bredere sett virkninger av AI-systemet, også der ingen personopplysninger inngår. Vurderingen av konsekvenser for grunnleggende rettigheter etter AI Act treffer bare bestemte ibruktakere og bestemte høyrisikosystemer.

De overlapper, og arbeidet kan gjenbrukes, men den ene erstatter ikke den andre. I praksis lønner det seg å ha ett vurderingsunderlag med moduler, slik at samme faktagrunnlag betjener alle tre, og slik at det er dokumentert hvilken plikt hver del oppfyller. Alternativet er tre dokumenter som sier nesten det samme, skrevet på ulike tidspunkt, med ulike konklusjoner.

Datastyring: hvor kommer dataene fra, og hvem har sett dem

Det er her de fleste programmene sprekker ved første ettersyn. Spørsmålene er enkle å stille og vanskelige å besvare i etterkant: Hvilke data er brukt til trening eller finjustering, med hvilket behandlingsgrunnlag og hvilken lisens? Hva hentes inn som kontekst ved kjøretid, fra hvilke kilder? Går forespørslene til en leverandør, brukes de til å trene leverandørens modeller, hvor lenge lagres de, og hvor? Blir data som er samlet inn til ett formål brukt som treningsgrunnlag for noe annet, er formålsbegrensningen et selvstendig spørsmål, ikke bare et sikkerhetsspørsmål.

Den vanligste feilen i praksis ligger i tilgangsstyringen i søkeindeksen. Når en assistent henter dokumenter for å svare, arver svaret indeksens rettigheter, ikke brukerens, med mindre tilgangskontroll håndheves på spørretidspunktet. Resultatet er en modell som lojalt gjengir innhold brukeren aldri skulle sett, uten at noe i loggene ser ut som et brudd. Krev tilgangskontroll på dokumentnivå ved kjøretid, ikke bare ved indeksering.

Datastyring i 42001-forstand handler dessuten om mer enn kvalitet. Det handler om proveniens: hvor datasettet kom fra, hvem som godkjente bruken, og hvilken versjon som lå til grunn for modellen som var i drift i mars. Uten en datakatalog med versjon og navngitt eierskap er dette spørsmål ingen kan besvare et halvår senere.

Modell- og leverandørrisiko

Et AI-system er ikke ett produkt, men en kjede: grunnmodell, tilpasningslag, systemprompt, kunnskapskilde, filtre, applikasjon. Hvert ledd kan endres uten at dere blir spurt. En leverandør som oppgraderer modellen, justerer sikkerhetsfiltrene eller avvikler en versjon, endrer et system dere har validert.

Behandle derfor modellversjon, promptversjon, indeksversjon og filterkonfigurasjon som konfigurasjonselementer under endringskontroll. Og få inn i avtalen det dere trenger for å styre: varsling ved vesentlige modellendringer, frist ved avvikling av versjoner, mulighet til å teste før endringer settes i produksjon, tilgang til logger, databehandleravtale med oversikt over underdatabehandlere og overføringsgrunnlag der data forlater EØS, og en exit-klausul som lar seg gjennomføre i praksis.

Menneskelig kontroll som kontroll, ikke som formulering

«Menneske i loopen» er blant de billigste setningene å skrive og de dyreste å innfri. Kontrollen er reell først når mennesket har tid, alternativ informasjon og et incentiv til å være uenig. Uten det får dere automatiseringsskjevhet: en godkjenner som bekrefter.

Her ligger det også et selvstendig personvernrettslig krav. Personvernforordningen artikkel 22 gir den enkelte rett til ikke å være gjenstand for en avgjørelse som utelukkende er basert på automatisert behandling, når avgjørelsen har rettsvirkning eller tilsvarende betydelig innvirkning. Unntakene forutsetter tiltak, blant annet rett til menneskelig inngripen. Et menneske som bare trykker godkjenn, gjør ikke behandlingen mindre automatisert i rettslig forstand.

Mål det derfor. Overstyringsrate er en av de mest informative indikatorene dere kan ha, og ligger den på null over tid, er kontrollen sannsynligvis seremoniell. Logg hvilke saker som ble overstyrt, hvorfor, og hva utfallet ble. Det dokumenterer at kontrollen virker, og forbedrer systemet.

Å revidere noe som ikke er deterministisk

En revisor kan ikke få bekreftet at systemet alltid gjør X, for det gjør det ikke. Da må revisjonsobjektet flyttes. Dere reviderer ikke enkeltsvaret; dere reviderer grensene, bevisene og prosessen rundt. En revisor tester i praksis to ting: at kontrollen er utformet slik at den kan virke, og at den faktisk har virket over tid. Ingen av delene forutsetter at modellen svarer likt to ganger.

Konkret: et fastfrosset evalueringssett med definerte akseptkriterier, kjørt på nytt ved hver endring; strukturerte logger som knytter utdata til modellversjon, prompt, kildedokumenter og bruker; stikkprøvebasert menneskelig gjennomgang med et definert vurderingsgrunnlag; overvåking av at ytelsen ikke forskyver seg gradvis; og terskler som utløser tilbakerulling. Full reproduserbarhet er sjelden oppnåelig. Etterprøvbarhet er det, forutsatt at dere bestemte dere for å ta vare på beviset før dere trengte det.

Fra ad hoc til styringssystem

Rekkefølgen betyr mer enn ambisjonsnivået. Begynn med oversikt: hva brukes faktisk, inkludert funksjonene som fulgte med i verktøy dere allerede har. Deretter en enkel triagering etter konsekvens: de fleste bruksområdene trenger lite, noen få trenger alt. Så kontrollpunkter for de få: konsekvensvurdering, navngitt eier, definert menneskelig kontroll, evaluering før produksjon og logging. Til slutt bevis, i en form som lar seg legge fram et halvår senere.

Berigo arbeider med AI-styring som en del av ledelsessystemet, ikke som et dokumentprosjekt ved siden av det, og holder kurs for dem som skal eie det internt.

Dette er ikke et større program enn et ISMS. Det er som regel det samme programmet med et nytt kapittel, og kapittelet er lettere å skrive mens dere fortsatt husker hvorfor beslutningene ble tatt.