En AI-agent som svarer en kunde, godkjenner et krav eller sender inn et dokument, gjør det på vegne av virksomheten som drifter den. Air Canada hevdet noe annet i 2024, etter at selskapets chatbot hadde gitt en kunde feil informasjon om rabatterte billetter ved dødsfall i familien. En kanadisk tvisteløsningsnemnd svarte i Moffatt mot Air Canada at dette var en oppsiktsvekkende anførsel («This is a remarkable submission»), og at det ikke spiller noen rolle om informasjonen kommer fra en statisk side eller en chatbot («It makes no difference whether the information comes from a static page or a chatbot»).
Det meste av jussen en agent møter, er slik: skrevet før agenter fantes, allerede i kraft og likegyldig til hvordan programvaren virker. Derfor kombinerer vi ingeniørfaglig dybde med kompetanse innen teknologirett. Reglene en agent handler under, bestemmer deler av arkitekturen, og de er billigst å bygge inn før arkitekturen finnes.
Reglene finnes før agenten
De kommer fra tre steder.
Loven. Personvernforordningen (GDPR) gir en person «rett til ikke å være gjenstand for en avgjørelse som utelukkende er basert på automatisert behandling» når avgjørelsen har rettsvirkning for vedkommende eller påvirker vedkommende i betydelig grad på tilsvarende måte (artikkel 22), og virksomheten «skal kunne påvise» at forordningens prinsipper overholdes (artikkel 5). Sektorregler kommer i tillegg, som DORA for finanssektoren. EUs KI-forordning legger til plikter som avhenger av hva et system brukes til. Det kommer vi tilbake til nedenfor.
Virksomhetens avtaler. Det den har lovet kunder og partnere: vilkårene kunden kjøpte under, konfidensialitetsklausuler, databehandleravtaler. Og det den har akseptert fra leverandørene sine: modelleverandørens vilkår for hvor data behandles og hvor lenge de lagres, og lisensen til hver åpen kildekode-komponent i systemet.
Virksomhetens egne retningslinjer. Hvem som kan godkjenne en utbetaling, hva som kan loves en kunde, hvor lenge en opplysning oppbevares.
Ingenting av dette er nytt for virksomheten. Det nye er programvare som handler under disse reglene med større frihet enn tidligere programvare hadde: En agent velger stegene sine selv.
En regel i en prompt er en anmodning
Den første ideen i de fleste prosjekter er å skrive reglene inn i instruksjonene til agenten. Da blir hver regel en anmodning til en språkmodell, og en modell oppfører seg ikke likt hver gang. Atil mfl. satte opp fem modeller for deterministiske svar, og nøyaktigheten varierte likevel med opptil 15 % mellom kjøringer av de samme oppgavene. En agent leser dessuten tekst som ingen i prosjektet har skrevet, for eksempel en innkommende e-post eller en nettside, og den teksten kan inneholde egne instruksjoner.
Sikkerhetsmiljøet har allerede trukket konklusjonen. OWASPs veiledning om for stor handlefrihet hos agenter er å legge tilgangskontrollen i systemene agenten kaller, i stedet for å la en språkmodell avgjøre om en handling er tillatt («implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not»).
Det samme gjelder enhver regel som betyr noe. Den må bli en kontroll: noe utenfor modellen som sjekker, stopper eller sender saken til et menneske, og som etterlater et spor.
Illustrasjon av hvordan regler blir kontroller for en agent som behandler kundekrav. Tre regler er skrevet ned. Et punkt i kundevilkårene, en linje i virksomhetens retningslinjer for data og artikkel 22 nr. 1 i personvernforordningen. En første kjøring avslår et krav og passerer alle tre reglene uten at noe blir kontrollert, stoppet eller registrert. Deretter blir hver regel en kontroll i kjøringen. Svar kontrolleres mot punktet de viser til, agentens verktøy når bare godkjente verter, og et avslag avgjøres av et menneske. Den samme kjøringen gjentas. Svaret kontrolleres mot vilkårene, ett kall til en ikke-godkjent vert blir blokkert, og avslaget venter til et menneske bekrefter det. Hver av de tre kontrollene etterlater en oppføring i loggen.
Fra regel til kontroll
Denne oversettelsen er stedet der juridisk kompetanse gjør nytte i et utviklingsprosjekt: å lese en regel for hva den krever av et system, og formulere det slik at en utvikler kan implementere det og en test kan kontrollere det. Resultatet er de tre egenskapene vi bygger hver agent for å ha.
Verifiserbar. En virksomhet står inne for det agenten forteller folk. Moffatt er én nemnds avgjørelse og binder ingen domstol i Europa, men resonnementet er alminnelig: Nemnda fant at flyselskapet ikke hadde utvist rimelig aktsomhet for å sikre at chatboten var nøyaktig. I systemet blir det til et svar som viser til punktet det bygger på, en kontroll av at punktet sier det svaret hevder, og evalueringer som måler hvor ofte dette holder.
Begrenset. En konfidensialitetsklausul eller en databehandleravtale sier hvor data kan sendes, og en retningslinje sier hvem som kan godkjenne hva. I systemet blir det til en liste over vertene agentens verktøy kan nå, håndhevet utenfor modellen, en modelleverandør og en behandlingsregion valgt for å passe avtalen, og tilganger som utelater alt oppgaven ikke trenger. En agent som ikke har noe verktøy for utbetaling, kan ikke overtales til å foreta en.
Styrt. Der en avgjørelse om en person ikke kan overlates til programvare alene, må et menneske ta den, og retten er presis om hva det innebærer. De europeiske datatilsynenes retningslinjer om artikkel 22 sier at den menneskelige kontrollen må være reell og ikke bare en symbolsk handling («meaningful, rather than just a token gesture»), og at den må utføres av noen som har myndighet og kompetanse til å endre avgjørelsen («someone who has the authority and competence to change the decision»). EU-domstolen har vært like streng med hvor en avgjørelse treffes: I SCHUFA (2023) ble en automatisk beregnet kredittscore regnet som en automatisert avgjørelse i seg selv, fordi långiveren som mottok den, i høy grad bygget på den («draws strongly»). I systemet blir det til et kontrollpunkt som holder avgjørelsen tilbake, viser den som vurderer saken, hvilket grunnlag agenten brukte, og lar vedkommende endre utfallet. En godkjenn-knapp under et resultat ingen leser, holder ikke.
Hver kontroll etterlater også et spor: hvilket punkt et svar viste til, hvilket kall som ble blokkert, hvem som avgjorde og når. Det sporet er det «å kunne påvise» betyr i praksis.
Å vite hva som ikke gjelder
Den andre halvdelen av arbeidet er rekkevidde. Å lese en regel presist er også å lese hvor den slutter.
EUs KI-forordning er det aktuelle eksempelet. De tyngste pliktene gjelder høyrisikosystemer, og et system er høyrisiko på grunn av hva det brukes til: Bruksområdene i vedlegg III omfatter blant annet rekruttering, kredittvurdering og tilgang til grunnleggende tjenester. En agent som gjennomgår leverandørkontrakter eller utarbeider fakturagrunnlag, er ikke blant dem. De fleste av pliktene ligger på leverandøren av systemet, ikke på enhver virksomhet som bruker et, og etter endringen i juli 2026 får de anvendelse fra 2. desember 2027. Forordningen er heller ikke en del av norsk rett ennå: Regjeringens uttalte ambisjon er å legge frem KI-loven for Stortinget våren 2027.
Den samme forordningen viser hvorfor rekkevidden ikke kan leses én gang og arkiveres. En virksomhet som endrer det tiltenkte formålet med et KI-system slik at det blir høyrisiko, regnes som leverandør av det (artikkel 25 nr. 1 bokstav c). Å sette en generell assistent til å vurdere jobbsøknader kan være en slik endring. Og noen plikter avhenger ikke av risikoklassen i det hele tatt: Et system som skal samhandle direkte med mennesker, må bygges slik at de får vite at de samhandler med et KI-system («are informed that they are interacting with an AI system», artikkel 50 nr. 1).
Et team som ikke kan lese hvor en regel slutter, kan ta feil i to retninger. Det kan bygge for plikter som ikke gjelder agenten, eller overse plikter som gjør det. Det første er arbeid ingen har krevd. Det andre er et system som må bygges om når mangelen oppdages.
Hvor det viser seg i et prosjekt
- Avgrensning. Hvem agentens resultater berører, hvilke avgjørelser den tar eller forbereder, hvilke data den leser og under hvilke avtaler, og hva det tiltenkte formålet er. Åpne spørsmål går til virksomhetens jurister mens svarene fortsatt kan endre designet.
- Arkitektur. Tilganger, dataflyt, valg av modelleverandør og region, og punktene der et menneske avgjør.
- Evalueringer. En regel som alltid må holde, blir et tilfelle i evalueringssuiten og et vilkår i utgivelseskontrollen, slik at en endring som bryter den, ikke slippes ut. Innlegget vårt om evalueringer beskriver hvordan en slik suite bygges.
- Drift. Et revisjonsspor som jurister og compliance-ansvarlige kan lese uten utviklerne som bygget systemet.
Verktøyene vi vedlikeholder som åpen kildekode, gjenspeiler samme tilnærming: tethered begrenser hvilke verter en Python-applikasjon kan koble til, og licenseal kontrollerer lisensene i et avhengighetstre før en utgivelse.
Hva den ikke erstatter
Vi er et ingeniørselskap, ikke et advokatfirma. Vi gir ikke juridisk rådgivning, og dette innlegget er generell informasjon. Om en regel gjelder for et bestemt system, og hva den krever der, er det virksomhetens egne jurister som avgjør.
Det juridisk kompetanse på ingeniørsiden endrer, er samtalen med juristene. Spørsmålene kommer tidlig og gjelder det konkrete systemet, og svarene havner i systemet som kontroller, tilganger og spor, ikke i et notat skrevet etter at det er bygget.
Den kombinasjonen har vært med oss fra starten: Vår gründer, Sergii Shcherbak, har arbeidet både som jurist innen teknologirett (LL.M. i rett og IT fra Stockholms universitet) og som AI-utvikler.
Spørsmål du bør stille
Enten dere bygger en agent selv eller kjøper en, viser disse spørsmålene om reglene var en del av designet.
- Hvilke regler håndheves av kode, og hvilke står bare i prompten?
- Hvilke av agentens avgjørelser berører en person, og hvem kan endre dem?
- Hvor sendes dataene, og hvilken avtale dekker hvert sted?
- Hvilket spor finnes etter det agenten gjorde, og kan compliance-ansvarlige lese det?
- Hva er systemets tiltenkte formål, og står den bruken på KI-forordningens høyrisikoliste?
- Når ble juristene deres spurt, og hva ble endret i designet etterpå?
Vi kombinerer ingeniørfaglig dybde med kompetanse innen teknologirett, slik at hver agent bygges for å være verifiserbar, begrenset og styrt.