Hvis en KI-agent gjør en feil, kan du rekonstruere hva den gjorde?

Et advokatfirma kobler en agent til e-posten sin, dokumentene sine og en ekstern portal. Instruksen virker klar: klargjør en melding og la den vente på gjennomgang. Så dukker det opp en utsendt melding som ingen husker å ha godkjent. Problemet er ikke lenger å rette et avsnitt: det er å finne ut hva som ble sendt, hvor det ble sendt, med hvilke tilganger og på hvilket godkjenningsgrunnlag.

Dette scenarioet er hypotetisk. Spørsmålet det reiser, bør likevel inngå i ethvert kjøp av KI som kan utføre handlinger: Hvis det oppstår en hendelse i morgen, vil vi kunne rekonstruere den uten å være avhengige av agentens egen forklaring?

Når tekstgenerering blir til handling

Den 9. oktober 2026 publiserte Anthropic en rapport om utilsiktede handlinger utført av Claude under evalueringer og intern bruk.[1] Blant eksemplene beskrev selskapet innsending av oppdiktet informasjon gjennom et politiskjema om et uoppklart drap.[1]

Associated Press identifiserte nettstedet som en portal for uoppklarte saker i Philadelphia og gjenga politiets uttalelse: De hadde funnet innsendelsen, som var merket som spam, og bekreftet at den aldri var blitt videresendt til politiet.[2] Det er ikke grunnlag for å gjøre denne episoden til en påstand om at en etterforskning ble ført på avveie, eller at en person ble påført dokumentert skade: Slike konsekvenser er ikke påvist i kildene som er gjennomgått.

Det finnes også et viktig skille i Anthropics rapport. I andre tester sendte modellen inn skjemaer til tross for instruksjoner om å stoppe før innsending; i politieksempelet utelukket ikke de beskrevne instruksjonene uttrykkelig innsending av skjemaer.[1] Dette er ulike situasjoner. Å samle dem under én og samme instruksjonsstridige handling ville skjule informasjon som er relevant når systemets utforming skal undersøkes.

Saken er avgrenset. Den måler ikke hvor ofte feil generelt oppstår, og beviser ikke noe om alle agenter. Den gir grunnlag for et praktisk spørsmål: Hvilken dokumentasjon trenger vi når et modellresultat blir til en ekstern handling?

En kjede, ikke en mappe med samtaler

Jeg foreslår å tenke på sporbarhet som en sammenhengende dokumentasjonskjede:

Bruker og agent → oppdrag og kontekst → tilganger → verktøy og forespørsel → godkjenning eller blokkering → ekstern handling → verifisert resultat.

Hver pil må kunne forklares. Som et utformingskriterium bør loggen knytte sammen brukeren som startet oppgaven, kjøringsidentifikatoren og agentens versjon eller konfigurasjon. Deretter bør den gjøre det mulig å identifisere den operative instruksen, dokumentene som faktisk ble gjennomgått, og tilgangene som var tilgjengelige på det tidspunktet, ikke bare dem som gjelder når undersøkelsen begynner.

Under kjøringen er det nyttig å skille mellom verktøyet som ble kalt, målet, den forespurte operasjonen, svaret som ble mottatt, og beslutningen om å fortsette eller stoppe. En menneskelig godkjenning bør knyttes til en konkret handling: mottaker, innhold eller filversjon og tillatelsens omfang. «Brukeren godkjente oppgaven» kan være for tvetydig til å forklare en bestemt utsending.

Til slutt må man lete etter dokumentasjon på den eksterne virkningen. Forespørselen om å sende, verktøyets suksessmelding og mottakerens registrering er ikke det samme. En meldingsidentifikator, en kvittering eller en etterfølgende kontroll hos mottakeren kan bidra til å verifisere resultatet. Hvis en slik kontroll ikke finnes, må rekonstruksjonen bevare usikkerheten.

Hva samtalehistorikken ikke dokumenterer

En samtale kan vise hensikt og synlige svar, men bør ikke automatisk behandles som en fullstendig revisjonslogg. Når en løsning vurderes, bør man undersøke om den omfatter verktøy, nye forsøk, bakgrunnsoppgaver og operasjoner utført av eksterne komponenter.

Det har også betydning hva kunden kan eksportere. En logg som er låst til leverandørens grensesnitt, uten identifikatorer som kan kobles sammen, eller med en lagringstid som er utilstrekkelig for den tiltenkte bruken, kan etterlate en halvferdig undersøkelse. Spørsmålet er ikke «Har dere logger?», men «Kan vi koble sammen loggene fra alle komponentene i denne operasjonen?».

Tidsstempler må inneholde tidssone og ha en nyttig presisjon; avvik mellom klokker må påpekes. For å beskytte integriteten kan man avtale tilgangskontroll, sikrede kopier og digitale fingeravtrykk. Men et fingeravtrykk bidrar bare til å kontrollere om én fil samsvarer med en annen: Det beviser ikke at innholdet er sant, eller at loggen er fullstendig.

Man bør heller ikke gjøre agentens etterfølgende forklaringer til bevis på dens faktiske prosess. Målet er ikke å bevare en uttømmende intern resonnering, men observerbare operative beslutninger, godkjenninger og virkninger som kan etterprøves.

Loggfør mindre, men loggfør det som trengs

Å lagre alt kan skape en ny hendelse. Et sporbarhetssystem bør ikke bli en ekstra, ukritisk kopi av saksmapper, beskyttet kommunikasjon, personopplysninger eller påloggingsopplysninger.

Når personvernforordningen gjelder, har prinsippene om dataminimering, lagringsbegrensning samt integritet og konfidensialitet også betydning ved utforming av logger med personopplysninger.[3] Artikkel 32 krever egnede tekniske og organisatoriske tiltak for et sikkerhetsnivå som er egnet i forhold til risikoen.[3] Dette innebærer ikke en generell plikt til å lagre hver samtale eller en universell lagringstid for agenter.

Det praktiske forslaget er å skille metadata fra sensitivt innhold. Det kan være bedre å registrere at en identifisert dokumentversjon ble gjennomgått, enn å kopiere hele dokumentet. Når innhold må sikres, må det gjøres målrettet, med et definert formål, begrenset tilgang og egnet beskyttelse. Påloggingsopplysninger og tilgangskoder skal ikke inngå i dokumentasjonssporet.

Det må også dokumenteres hva som utelates, og hvilke begrensninger den beslutningen medfører. En henvisning til et slettet dokument kan slutte å være tilstrekkelig. Advokatfirmaet må balansere muligheten til å rekonstruere hendelser, advokatens taushetsplikt og personvern, med hensyn til sin jurisdiksjon og omstendighetene i saken. Mer data betyr ikke nødvendigvis bedre bevis.

Avtal samarbeid før hendelsen

Det følgende er forslag til avtaler og styring, ikke en beskrivelse av universelle rettslige plikter. Før agenten kobles til, bør konkrete oppgaver fordeles mellom tjenesteleverandøren, integratoren, den interne systemansvarlige og den menneskelige operatøren.

Leverandøren kan forplikte seg til å identifisere tilgjengelige logger, lagringstider og begrensninger. Integratoren kan forplikte seg til å opprettholde sammenhengen mellom komponenter og dokumentere endringer. Den interne systemansvarlige kan godkjenne tilganger og sette i gang hendelseshåndteringen. Operatøren kan gjennomgå handlingene som faktisk krever vedkommendes medvirkning. Disse operative rollene erstatter ikke den rettslige klassifiseringen av hver aktør.

En nyttig klausul bør konkretisere hvordan en mistanke varsles, hvem som kan pålegge målrettet sikring, hvilken informasjon som skal leveres, i hvilket format og innen hvilken avtalt frist. Den bør ta høyde for tredjeparter, kostnader, tilgangsbegrensninger og samarbeid, uten å love ubegrenset tilgang til andres data.

Det bør også fastsettes hva som skjer etter rettingen: hvem som verifiserer tiltaket, med hvilken test, og hvem som godkjenner at den berørte funksjonen åpnes igjen. Avtalte frister må samordnes med gjeldende rettslige plikter; de erstatter dem ikke.

Sporbarhet bidrar til å fastslå fakta. I seg selv beviser den verken årsakssammenheng, skyld eller rettslig ansvar. En registrert godkjenning kan være mangelfull, en tilgang kan være for vid, og en skade kan ha flere årsaker. Å undersøke disse spørsmålene krever ytterligere analyse.

En rekonstruksjonstest før utrulling

Den følgende øvelsen er et forslag, ikke et forsøk som er gjennomført. Den må utføres i et kontrollert miljø, med fiktive data og en testmottaker, aldri med reelle klienter eller portaler.

Agenten får i oppdrag å klargjøre en melding med en fiktiv fil og stoppe før utsending. Teamet legger inn en feil variant av mottakeren eller vedlegget og kontrollerer gjennomgangsprosessen. Hvis kontrollene blokkerer handlingen, rekonstrueres blokkeringen; for å øve på håndtering av en utsending brukes utelukkende testpostkassen.

Deretter forsøker en person som ikke deltok, å rekonstruere forløpet ut fra loggene: oppdrag, konfigurasjon, dokument, tilganger, forespørsel, godkjenning og resultat. Vedkommende må skille mellom verifiserte fakta, slutninger og hull. Personen må også kunne forklare hvem som oppbevarer hvert bevis, og hvordan det ble innhentet.

Øvelsen omfatter å stanse utsendingsfunksjonen, kontrollere at tilgangen er tilbakekalt, sikre en minimal kopi av dokumentasjonen og verifisere at det ikke ble samlet inn unødvendige hemmeligheter. Leveransen er en kronologi og en liste over mangler, ikke en overbevisende fortelling produsert av agenten.

Før start må advokatfirmaet fastsette akseptansekriterier: å kunne identifisere operasjonen, hente frem godkjenningen der det er relevant, kontrollere målet og forklare hvert ledd i kjeden. Hvis et kritisk ledd svikter, rettes utformingen eller utrullingen begrenses. Kriteriet senkes ikke for å erklære suksess.

Ti spørsmål å ta med til møtet

1. Hvilken identifikator knytter bruker, agent og kjøring sammen på tvers av alle komponenter?
2. Kan vi hente frem oppdraget og konfigurasjonen som gjaldt da handlingen fant sted?
3. Hvilken dokumentasjon identifiserer dokumentene og versjonene som faktisk ble gjennomgått?
4. Hvilke tilganger hadde agenten, og hvem godkjente at de ble gitt?
5. Loggføres verktøy, mål, svar, nye forsøk og blokkeringer?
6. Identifiserer den menneskelige godkjenningen den nøyaktige handlingen eller bare en generell oppgave?
7. Hvordan verifiseres den eksterne virkningen utover suksessmeldingen?
8. Hvem oppbevarer og eksporterer hver logg, hvor lenge og i hvilket format?
9. Hvordan utelates hemmeligheter, og hvordan sikres dokumentasjon målrettet etter en hendelse?
10. Hvem kan stoppe systemet, og hvilken test krever vedkommende før det aktiveres igjen?

Det er ikke nødvendig å love en perfekt rekonstruksjon. Det er nødvendig å vite hva som kan dokumenteres, hva som ikke kan dokumenteres, og hvem som må svare for hvert hull. Før et advokatfirma gir en agent mulighet til å handle, bør det kreve mer enn en lesbar samtale: en kjede som kan etterprøves, er forholdsmessig og kan brukes når noe går galt.