Erstatningsansvar for autonome AI-agenter handler om, hvilken person eller organisation der kan blive ansvarlig, hvis en agent forårsager økonomisk tab, personskade, dataskade eller ulovlig behandling. I praksis placeres ansvaret ikke hos agenten selv, men hos de aktører, der udvikler, sælger, integrerer, kontrollerer eller bruger systemet.
Autonome AI-agenter får ikke selv erstatningsansvar; ansvaret vurderes hos de mennesker og virksomheder, der udvikler, integrerer, kontrollerer eller bruger systemet. Overblikket viser, hvordan ansvarskæden hænger sammen med EU AI Act, produkthaftighed, GDPR, dokumentation, kontrakter og praktisk risikostyring.
Hvem kan hæfte, når en autonom AI-agent gør skade?
En autonom AI-agent er ikke en selvstændig ansvarsbærer. Den kan handle med en vis grad af selvstændighed, men ansvaret vurderes gennem de mennesker, virksomheder og myndigheder, der har sat agenten i stand til at handle. Det kan være udvikleren af modellen, leverandøren af agentplatformen, virksomheden der integrerer agenten, eller den organisation der bruger agenten i en konkret arbejdsproces.
Hvis en agent sender en forkert betalingsinstruks, sletter data eller træffer en beslutning, der påvirker en person, vil spørgsmålet normalt være, hvem der havde kontrol over design, adgang, instruktion, test, overvågning og godkendelse. Jo mere agenten kan gøre uden menneskelig mellemkomst, desto mere centralt bliver det at dokumentere, hvem der gav den mandat, hvilke grænser der var sat, og hvilke kontroller der faktisk virkede.
Derfor bør erstatningsansvar ikke beskrives som et enkelt spørgsmål om, hvor intelligent agenten var. Det er snarere en analyse af ansvarskæden: hvem byggede systemet, hvem valgte det, hvem konfigurerede det, hvem overvågede det, og hvem kunne have stoppet handlingen, før skaden opstod?
Hvad betyder autonomi for ansvarskæden?
Autonomi betyder, at systemet kan udføre dele af en opgave uden løbende menneskelig instruktion. En almindelig chatbot svarer typisk i dialog, mens en AI-agent kan planlægge delopgaver, kalde værktøjer, hente data, skrive til systemer og gennemføre arbejdstrin. Hvis du vil afgrænse begrebet, er forskellen mellem en chatbot og en agent forklaret i AI Mentors gennemgang af hvad en AI-agent er.
Autonomi ændrer ikke i sig selv den grundlæggende idé om ansvar. Den ændrer derimod bevisbilledet. Når en agent selv vælger mellem flere mulige handlinger, bliver det nødvendigt at kunne forklare input, instruktioner, værktøjsadgange, grænser, logfiler og menneskelige godkendelser. Ellers kan det være svært at afgøre, om skaden skyldtes et systemdesign, en dårlig integration, en fejl i data, en manglende kontrol eller forkert brug.
Autonomi kan også være gradvis. En agent, der kun foreslår en handling, har en anden risikoprofil end en agent, der kan sende e-mails, godkende refusioner eller ændre kundedata. Ansvarsanalysen bør derfor starte med agentens konkrete handlefrihed, ikke med navnet på teknologien.
En fejl i en AI-agent er ikke automatisk et erstatningsansvar. Mange tekniske fejl giver irritation, omarbejde eller intern driftsrisiko uden at skabe et krav fra en skadelidt. Et ansvarsproblem opstår først, når fejlen kan forbindes med et tab eller en skade, og når der findes et ansvarsgrundlag hos en relevant aktør.
Et teknisk problem kan være, at agenten misforstår en instruktion, overser en undtagelse eller vælger et uegnet værktøj. Et ansvarsproblem kan opstå, hvis den samme fejl fører til tab af kundedata, diskriminerende behandling, en forkert afgørelse, brud på en kontrakt eller fysisk skade gennem et forbundet produkt. I praksis skal årsagssammenhæng, forudsigelighed, kontrol og dokumentation vurderes samlet.
Det betyder, at organisationer bør beskrive agentens opgaver på en måde, der kan efterprøves. En bred instruktion som “håndter kundesager” er svagere end en afgrænset proces med tilladte datakilder, stopkriterier, eskalationsregler og logning af alle værktøjskald. Jo bedre den tekniske styring er formuleret, desto lettere er det også at undersøge en hændelse bagefter.
Hvilke roller skal adskilles før ansvar kan placeres?
En AI-agent indgår ofte i en kæde af tekniske og organisatoriske roller. Den samme virksomhed kan have flere roller samtidig, men de bør alligevel adskilles i analysen. Ellers bliver det uklart, om en fejl stammer fra modeludvikling, agentdesign, integration, datagrundlag, brugeradgang eller intern arbejdsgang.
| Rolle | Typisk kontrolpunkt | Mulig ansvarsrelevans |
|---|---|---|
| Model- eller systemleverandør | Modelens egenskaber, dokumentation, sikkerhed og begrænsninger | Kan være relevant ved fejl i produkt, dokumentation eller sikkerhedsforanstaltninger |
| Agentudvikler | Planlægning, værktøjskald, hukommelse, systeminstruktioner, adgangsgrænser og fallback | Kan være relevant, hvis agentens design gjorde skadelig handling sandsynlig |
| Integrator | Forbindelse til e-mail, CRM, økonomi, databaser eller fysiske systemer | Kan være relevant, hvis integrationen gav for brede rettigheder eller manglende kontrol |
| Organisationen der bruger agenten | Formål, arbejdsgang, brugerroller, overvågning og menneskelig godkendelse | Kan være relevant, hvis agenten bruges uforsvarligt eller uden passende proceskontrol |
| Slutbruger eller medarbejder | Instruktioner, godkendelser og efterlevelse af interne regler | Kan være relevant ved misbrug, omgåelse af kontroller eller fejlagtig godkendelse |
Tabellen er ikke en facitliste. Den viser, hvorfor ansvar for autonome AI-agenter sjældent kan placeres sikkert uden teknisk hændelsesdata og klar rollefordeling.
Hvordan påvirker EU AI Act vurderingen?
EU AI Act definerer et AI-system som et maskinbaseret system, der er designet til at fungere med varierende grader af autonomi og kan generere output, der påvirker fysiske eller virtuelle miljøer. Den definition passer på mange agentlignende systemer, men loven er ikke en generel erstatningslov. Den opstiller først og fremmest krav til udvikling, markedsføring, brug og kontrol af AI-systemer ud fra risikoniveau.
Fra 2. august 2026 anvendes AI Act som hovedregel, mens enkelte dele allerede gælder tidligere. For high-risk AI systems lægger reglerne blandt andet vægt på risikostyring, dokumentation, logning, transparens, human oversight, robusthed og cybersikkerhed. De elementer kan få betydning for en senere vurdering af, om en aktør har handlet forsvarligt, fordi de viser, hvilke kontroller der burde være tænkt ind i systemets livscyklus.
AI Act afgør dog ikke alene, hvem der skal betale erstatning efter en konkret skade. Den kan derimod give et faktuelt og regulatorisk grundlag for at vurdere, om leverandør, integrator eller bruger har opfyldt relevante pligter. En organisation, der bruger en agent i en risikofyldt proces, bør derfor forbinde den tekniske opsætning med dokumenteret risikostyring i AI-implementeringer.
Hvornår kan produkthaftighed blive relevant?
Produkthaftighed bliver især relevant, når en skade skyldes et defekt produkt. EU’s nye produkthaftighedsdirektiv fra 2024 udvider rammen, så software og AI-systemer udtrykkeligt behandles som produkter. Direktivet skal gennemføres i medlemsstaterne senest 9. december 2026 og gælder for produkter, der bringes i omsætning eller tages i brug efter den dato.
For AI-agenter er den praktiske pointe, at softwarefejl, manglende sikkerhedsopdateringer, evne til fortsat læring, cybersikkerhed og forventelig brug kan blive relevante i vurderingen af, om et produkt er defekt. Det er en anden vinkel end almindelig kontraktstyring. Her handler spørgsmålet ikke kun om, hvad parterne har aftalt, men om produktet gav den sikkerhed, en person med rimelighed kunne forvente, eller som lovgivningen krævede.
Direktivet betyder ikke, at alle fejl i en agent automatisk udløser produkthaftighed. Skaden skal falde inden for de relevante skadetyper, og der skal være sammenhæng mellem defekten og skaden. Men for agentbaserede produkter, der kan handle i digitale eller fysiske miljøer, gør direktivet dokumentation af produktets design, opdateringer, begrænsninger og sikkerhedsforanstaltninger langt mere konkret.
Hvad betyder data og automatiserede beslutninger for ansvaret?
Når en AI-agent behandler personoplysninger, er databeskyttelse en selvstændig del af risikobilledet. GDPR kan være relevant, selv om der ikke er tale om et defekt produkt. Hvis agenten træffer eller forbereder beslutninger om personer, kan spørgsmål om behandlingsgrundlag, dataminimering, transparens, sletning, adgangsrettigheder og automatiserede afgørelser blive centrale.
GDPR artikel 22 giver registrerede en ret til ikke at være underlagt visse afgørelser, der udelukkende er baseret på automatiseret behandling og har retsvirkning eller tilsvarende væsentlig virkning. Der findes undtagelser, men de kræver passende garantier, blandt andet mulighed for menneskelig indgriben i relevante tilfælde. Det gør agentens rolle i beslutningskæden afgørende: foreslår den, sorterer den, eller træffer den reelt afgørelsen?
Hvis du arbejder med træningsdata, kundeoplysninger eller logfiler, bør datadelen vurderes selvstændigt. AI Mentors forklaring af GDPR for AI-træningsdata viser, hvorfor datakilder, formål og adgangsrettigheder bør være klare, før en agent får adgang til personoplysninger.
Hvordan bør organisationer styre agentens handlefrihed?
Erstatningsrisiko kan ikke fjernes ved at kalde agenten et eksperiment, hvis den reelt har adgang til systemer, data eller beslutninger. Styringen bør begynde med en enkel oversigt over, hvad agenten må se, foreslå, ændre, sende, købe, slette eller eskalere. Hver handling bør placeres i en risikoklasse med et passende kontrolniveau.
En lavrisikoagent kan for eksempel sammenfatte interne noter uden at skrive tilbage til kildesystemer. En mellemrisikoagent kan udarbejde udkast, som et menneske skal godkende. En højrisikoagent kan påvirke økonomi, adgangsrettigheder, persondata, kundevilkår eller fysiske processer. Jo tættere agenten kommer på irreversible handlinger, desto stærkere bør kravene være til test, overvågning, godkendelse og nødstop.
En nyttig arbejdsregel er at skelne mellem beslutningsstøtte og beslutningsfuldmagt. Hvis agenten kun giver et forslag, bør godkendelsespunktet være synligt. Hvis agenten kan handle selv, bør du kunne dokumentere, hvorfor den fik den adgang, hvilke begrænsninger der var sat, og hvordan fejl opdages. Den type afgrænsning hænger tæt sammen med forskellen mellem AI-agenter og AI-workflows.
Hvilke beviser bliver centrale efter en hændelse?
Efter en skade er det ofte for sent at rekonstruere hele forløbet, hvis agenten ikke allerede logger sine handlinger. Centrale beviser kan være systeminstruktioner, brugerinstruktioner, værktøjskald, datakilder, versionsnumre, adgangsrettigheder, testresultater, godkendelser, fejlmeddelelser og tidspunktet for menneskelig indgriben. Beviserne skal vise både, hvad agenten gjorde, og hvilke rammer den handlede inden for.
Logning bør ikke kun ses som teknisk drift. Den er også en del af ansvarsstyringen. Hvis agenten ændrer en kundesag, sender en besked eller kalder et eksternt API, bør loggen kunne vise handlingen, inputtet, beslutningspunktet og den ansvarlige proces. Uden den sporbarhed bliver det svært at skelne mellem modeladfærd, brugerfejl, integrationsfejl og manglende organisatorisk kontrol.
Dokumentation bør samtidig være proportional. En intern skriveassistent kræver ikke samme niveau som en agent, der kan gennemføre transaktioner. Men hvis agenten påvirker rettigheder, økonomi, sikkerhed eller persondata, bør logning og efterprøvning være en del af designet fra starten.
Hvordan kan kontrakter placere ansvar uden at fjerne risiko?
Kontrakter kan fordele ansvar mellem leverandør, kunde, integrator og underleverandører. De kan beskrive formål, databehandling, serviceniveau, test, sikkerhed, audit, hændelsesrapportering, adgangsbegrænsninger, ansvarsmaksimum og krav til menneskelig godkendelse. De kan også fastlægge, hvem der må ændre agentens værktøjer, modeller og produktionsadgange.
Kontrakter fjerner dog ikke nødvendigvis ansvar over for tredjeparter eller registrerede personer. En virksomhed kan ikke alene skrive sig ud af alle følger af en agent, hvis den selv bruger agenten i en proces, der påvirker kunder, borgere eller medarbejdere. Kontrakten hjælper først for alvor, når den passer til den tekniske virkelighed: agentens faktiske adgang, faktiske data og faktiske beslutningspunkter.
Det er derfor svagt kun at have generelle formuleringer om “AI-funktionalitet”. En bedre kontrakt beskriver konkrete agentfunktioner, tilladte værktøjer, kendte begrænsninger, ændringskontrol og hændelsespligter. Hvis leverandøren ændrer modellen, eller kunden giver agenten nye systemrettigheder, bør det udløse en ny vurdering.
Hvad er en praktisk beslutningsmodel før brug?
En enkel beslutningsmodel kan gøre ansvaret mere håndterbart før agenten sættes i drift. Først beskrives agentens opgave med almindelige ord. Derefter listes alle systemer, datakilder og værktøjer, agenten kan bruge. Dernæst markeres de handlinger, der kan skabe økonomisk tab, personpåvirkning, datalækage, diskrimination, sikkerhedsbrud eller fysisk risiko.
Næste trin er at vælge kontrol for hver risikofyldt handling. Det kan være menneskelig godkendelse, begrænsede beløbsgrænser, read-only-adgang, testmiljø, sandbox, rate limits, to-personers godkendelse, separat auditlog eller automatisk stop ved usikkerhed. Styringen bør være konkret nok til, at en teknisk administrator kan konfigurere den og en procesansvarlig kan kontrollere den.
Til sidst bør organisationen fastlægge, hvem der ejer risikoen i drift. Det er ikke altid den samme person, som ejer teknologien. En complianceansvarlig kan eje datarisikoen, en produktejer kan eje brugeroplevelsen, en sikkerhedsansvarlig kan eje adgangsmodellen, og en forretningsansvarlig kan eje konsekvensen af agentens handlinger.
Hvilke misforståelser bør undgås?
Den første misforståelse er, at en autonom AI-agent selv kan bære ansvaret. I praksis skal ansvar forbindes med mennesker, virksomheder eller myndigheder. Den anden misforståelse er, at leverandøren altid bærer hele ansvaret. Hvis en kunde selv giver agenten brede rettigheder, ignorerer kendte begrænsninger eller bruger den uden kontrol, kan kundens egen rolle blive central.
Den tredje misforståelse er, at ansvar kun handler om lovgivning. For autonome agenter handler forsvarlig brug også om arkitektur, adgangsstyring, logs, testdata, hændelsesrespons og løbende ændringskontrol. En agent kan være lovligt anskaffet, men stadig være uforsvarligt sat op i en konkret arbejdsgang.
Den fjerde misforståelse er, at en menneskelig godkendelse altid løser problemet. Hvis godkendelsen er ren formalitet, eller hvis medarbejderen ikke får tilstrækkelig information til at vurdere agentens forslag, er kontrollen svag. Human oversight fungerer kun, når mennesket kan forstå outputtet, se relevante begrænsninger og reelt standse eller ændre handlingen.
Hvordan hænger sikkerhed sammen med erstatningsrisiko?
Sikkerhed er en direkte del af ansvarsbilledet, fordi autonome agenter ofte har adgang til systemer og data. En agent, der kan kalde værktøjer, kan også misbruges gennem kompromitterede konti, manipulerede instruktioner, datalækager eller uautoriserede integrationer. Hvis skaden kunne være begrænset med basal adgangsstyring, segmentering eller overvågning, bliver sikkerhedsdesignet relevant.
AI Act lægger for high-risk AI systems vægt på robusthed og cybersikkerhed, og produkthaftighedsdirektivet nævner sikkerhedsrelevante cybersikkerhedskrav som en del af vurderingen af defectiveness. Det gør sikkerhed til mere end en teknisk driftsopgave. Den viser, om aktørerne har tænkt rimeligt forudsigelige angreb, fejl og misbrug ind i systemets design.
Praktisk betyder det, at agenten bør have mindst mulige rettigheder, klare adgangsgrænser, særskilte servicekonti, overvågning af usædvanlige handlinger og en mulighed for hurtigt at afbryde værktøjsadgang. Flere konkrete kontroltyper er beskrevet i AI Mentors oversigt over sikkerhedsforanstaltninger for AI-drevne systemer.
Hvordan bør ansvaret vurderes i praksis?
En praktisk vurdering bør starte med skaden og bevæge sig baglæns gennem kæden. Hvad skete der, hvem blev påvirket, hvilket system handlede, hvilke data blev brugt, hvilken adgang var givet, hvilke kontroller fandtes, og hvem kunne ændre eller stoppe agentens handling? Den rækkefølge gør vurderingen mere konkret end en generel debat om AI-autonomi.
Derefter bør rollerne holdes adskilt. Leverandørens ansvar kan handle om produktets egenskaber og dokumentation. Integratorens ansvar kan handle om systemadgange og konfiguration. Brugerorganisationens ansvar kan handle om formål, datagrundlag, intern kontrol og menneskelig godkendelse. Medarbejderens rolle kan handle om instruktioner og efterlevelse af procedurer.
Den mest robuste tilgang er at behandle erstatningsansvar som et designkrav, ikke kun som noget der undersøges efter en skade. Agentens mandat, grænser, logs, test, sikkerhed og eskalering bør være synlige, før systemet får adgang til virkelige opgaver. Det gør ikke ansvarsrisikoen nul, men det gør den mulig at styre, undersøge og forklare.
Hvilke kilder ligger til grund?
De vigtigste kilder er EU’s AI Act, som definerer AI-systemer og stiller krav til blandt andet high-risk AI systems, samt EU’s Product Liability Directive, der udtrykkeligt omfatter software og AI-systemer som produkter fra den nye anvendelsesdato.
Datadelen bygger på GDPR, især reglerne om automatiserede afgørelser, mens den praktiske risikostyring er holdt op mod NIST AI Risk Management Framework.