
AI-forordningen
Udforsk EU's AI-forordning, verdens første omfattende AI-regulering. Lær, hvordan den klassificerer AI-systemer efter risiko, etablerer styring og sætter global...
EU’s AI-forordnings gennemsigtighedsregler er nu håndhævelige, og Google Cloud har lanceret et nyt Agent Identity-system. Her er, hvad der har ændret sig for teams, der bygger AI-agenter.
To annonceringer fra den første uge af august 2026 peger på den samme udvikling, fra modsatte retninger. Den 2. august trådte EU’s AI-forordnings gennemsigtighedsregler i kraft som håndhævelig lovgivning, hvilket kræver, at enhver, der implementerer en chatbot, indholdsgenerator eller følelsesaflæsende system, tydeligt skal oplyse om det eller risikere bøder på op til 15 millioner euro. Dage senere gjorde Google Cloud sit Agent Identity-system almindeligt tilgængeligt – et indbygget tilladelseslag, der sporer præcis, hvad en AI-agent kan få adgang til, og logger alt, hvad den gør. Det ene er en regulator, der tvinger til oplysning. Det andet er en cloud-platform, der sælger ansvarlighed som en funktion. Begge konvergerer mod den samme konklusion: En AI-agent, som ingen kan identificere, revidere eller holde ansvarlig, er ikke klar til produktion – uanset om en domstol siger det eller ej.
EU’s AI-forordnings artikel 50 om gennemsigtighedsforpligtelser blev generelt gældende og håndhævelig af nationale myndigheder i hele EU den 2. august 2026. I praksis dækker dette fire ting. Udbyderne skal sikre, at folk “tydeligt informeres om, at de har med et AI-system at gøre, medmindre dette er indlysende ud fra konteksten” – chatbot-oplysningsreglen. Udbyderne af systemer, der genererer syntetisk lyd, billede, video eller tekst, skal markere output i et maskinlæsbart, detekterbart format. Enhver, der implementerer et system, der producerer deepfakes af virkelige personer, steder eller begivenheder, skal oplyse om det. Og implementører af følelsesgenkendelses- eller biometriske kategoriseringssystemer skal informere de personer, der udsættes for dem, og overholde EU’s databeskyttelseslovgivning.
Intet af dette er nyt i konceptet – AI-forordningen blev underskrevet år tidligere. Det, der ændrede sig den 2. august, er, at disse specifikke forpligtelser ophørte med at være en fremtidig dato på en compliance-køreplan og blev noget, som nationale regulatorer rent faktisk kan håndhæve i dag.
Ikke alt i forordningen ankom som planlagt. Gennem Digital Omnibus on AI, underskrevet den 8. juli 2026, udskød EU sine krav til højrisikosystemer. Selvstændige systemer under bilag III – tænk ansættelsesscreening, uddannelse, retshåndhævelse, kritisk infrastruktur – har nu indtil 2. december 2027. AI integreret i allerede regulerede produkter under bilag I, såsom medicinsk udstyr eller elevatorer, har indtil 2. august 2028.
Den udskydelse er værd at være præcis om, fordi den let kan misfortolkes som “AI-forordningen blev forsinket.” Det blev den ikke. Listen over forbudt praksis og forpligtelser for generelle AI-modeller er uberørt. Det, der er flyttet, er specifikt højrisikoklassifikationskravene – det tungeste compliance-løft, for den smalleste gruppe af systemer. Hvis din agent taler til brugere eller genererer indhold, er du inden for den del af loven, der allerede er aktiv.
Gennemsigtighedskravet lyder beskedent ved siden af “højrisikosystem”, men det er den regel, de fleste AI-agentbyggere rent faktisk vil støde på først. En kundevendt supportagent, en indholdsgenereringsarbejdsgang, en stemmeassistent – alle disse er systemer, der taler til mennesker, hvilket betyder, at artikel 50 gælder, uanset om de nogensinde ville blive klassificeret som højrisiko. At få dette rigtigt er ikke kompliceret: Sig tydeligt, at brugeren taler med en AI, mærk genereret indhold, og gem dokumentation, der viser, at du gjorde det. At få det forkert er, hvor compliance-rapportering stopper med at være papirarbejde og begynder at være en juridisk eksponering med et reelt tal vedhæftet.
Googles Clouds svar på det samme underliggende problem ankom fra en helt anden retning: infrastruktur, ikke lovgivning. Virksomheden gjorde sin Gemini Enterprise Agent Platform almindeligt tilgængelig med en klynge af nye agentstyringsprimitiver – Agent Memory Bank, Agent Runtime, Agent Gateway, Agent Registry, Agent Evaluation og, mest bemærkelsesværdigt, Agent Identity.
Agent Identity er en indbygget IAM-legitimationskreditor bygget på åbne standarder, designet specifikt til autonome systemer frem for tilpasset fra menneskelige brugerkonti. Det håndhæver mindsterettighedsadgang ved at binde tilladelser direkte til agentens runtime, hvilket lukker en almindelig angrebsvej, hvor et stjålet agent-token kunne genbruges et andet sted. Det producerer ikke-afviselige logfiler over alle handlinger, en agent udfører. Og det administrerer legitimationskreditorens livscyklus automatisk, så en agent, der er blevet pensioneret, ikke efterlader et inaktivt, glemt sæt tilladelser, der venter på at blive misbrugt.
Den praktiske effekt er, at “hvilken agent gjorde dette, og var det tilladt?” bliver et spørgsmål med et definitivt svar i stedet for en gætning rekonstrueret fra applikationslogfiler bagefter. Det betyder mere, efterhånden som agenter bevæger sig fra at besvare spørgsmål til at udføre handlinger – booke ting, redigere registreringer, flytte penge, slette filer. En LLM-sikkerhedstilgang, der kun bekymrer sig om prompt injection i selve modellen, overser hele denne overflade: agentens faktiske tilladelser og hvad den gjorde med dem.
Det er også her, de to annonceringer forbinder mere, end de umiddelbart ser ud til. Artikel 50 spørger “oplyste du, at dette var AI?” Agent Identity besvarer et relateret, men adskilt spørgsmål: “kan du bevise præcis, hvad denne specifikke agent gjorde, med hvilke tilladelser, under hvis autoritet?” Et system, der kan besvare det andet spørgsmål rent, finder det første meget lettere.
Det er værd at nævne mønsteret direkte, fordi det vil fortsætte med at gentage sig. Regulatorer konvergerer mod oplysning og ansvarlighed fra en juridisk risikovinkel. Cloud-platforme konvergerer mod identitet og tilladelser fra en sikkerheds- og pålidelighedsvinkel. AI-agentrammeværker plejede at behandle identitet som en eftertanke – en API-nøgle i en miljøvariabel, delt på tværs af alle agenter i flåden. Den model overlever ikke kontakt med hverken regulatorisk granskning eller en reel sikkerhedshændelse, hvilket er præcis hvorfor begge retninger nu peger på den samme løsning: vid hvilken agent gjorde hvad, med hvilken adgang, og vær i stand til at vise det.
Teams, der allerede har eksperimenteret med virkelige AI-agenteksempler – kundesupportbots, forskningsassistenter, kodningsagenter – er dem, der vil mærke dette skift først, simpelthen fordi de har flere agenter i produktion, der genererer flere handlinger at redegøre for. Det er det samme mønster, vi så, da Claude Cowork og dets konkurrenter skubbede agenter fra enkeltsessions-chat til vedvarende opgaver over flere dage: Mere autonomi ankommer altid et skridt foran værktøjerne til at styre det.
At eftermontere revisionsspor på en agentflåde, der aldrig var designet til at producere dem, er et elendigt projekt – hver handling skal rekonstrueres fra de logfiler, der tilfældigvis eksisterede, og halvdelen af tiden gør de ikke. Den billigere vej er at bygge på værktøjer, hvor hvert skridt en agent tager er synligt og sporbart fra starten, på samme måde som data governance behandler dataafstamning som et førsteklasses anliggende snarere end noget, man tilføjer efter et brud.
Det er også her, tempoet i de underliggende modeller betyder noget. Nylige udgivelser som Microsofts Orchard-rammeværk og den bredere udvikling mod specialiserede, reviderbare agenter (i stedet for én enorm general-purpose-model, der gør alt) gør det mere praktisk at bygge agenter, hvis omfang – og dermed deres tilladelser – er snævre og veldefinerede af design. En snævert afgrænset agent er i sagens natur lettere at styre end en, der teoretisk set kan gøre alt.
FlowHunts tilgang følger samme logik: Som AI-agentplatform er hver automatisering et synligt flow, ikke en sort boks, så når et compliance-spørgsmål kommer ind – hvad gjorde denne agent, hvorfor, og under hvilken autorisation – er svaret allerede til stede i arbejdsgangen, ikke noget dit team skal rekonstruere under tidspres.
EU’s AI-forordnings gennemsigtighedsregler og Googles Agent Identity-system koordinerede ikke med hinanden, og de løser nominelt forskellige problemer – det ene er juridisk compliance, det andet er cloud-infrastruktur. Men de landede i samme uge og pegede på den samme underliggende sandhed: Efterhånden som AI-agenter påtager sig mere autonome og konsekvensrige opgaver, holder “vi ved ikke rigtig, hvad den gjorde” op med at være et acceptabelt svar, uanset om personen, der spørger, er en regulator eller dit eget sikkerhedsteam. De teams, der behandler identitet, oplysning og revisabilitet som kerneprioriteter nu – ikke funktioner, der skal tilføjes senere – er dem, der vil finde både compliance og produktionshændelser langt mindre smertefulde, når de dukker op.
Arshia er AI Workflow Engineer hos FlowHunt. Med en baggrund inden for datalogi og en passion for AI, specialiserer han sig i at skabe effektive workflows, der integrerer AI-værktøjer i daglige opgaver og øger produktivitet og kreativitet.

FlowHunt giver hver automatisering et synligt, redigerbart flow – så når nogen spørger, hvad din agent gjorde og hvorfor, har du et svar, ikke en sort boks.

Udforsk EU's AI-forordning, verdens første omfattende AI-regulering. Lær, hvordan den klassificerer AI-systemer efter risiko, etablerer styring og sætter global...

Udforsk de vigtigste AI-praksisser, der er forbudt af EU’s AI-forordning, herunder forbud mod social scoring, manipulerende AI, realtids biometrisk identifikati...

Udforsk EU's AI-forordnings graduerede straframme med bøder på op til 35 millioner euro eller 7% af den globale omsætning for alvorlige overtrædelser, herunder ...
Cookie Samtykke
Vi bruger cookies til at forbedre din browsingoplevelse og analysere vores trafik. See our privacy policy.