En FRIA (fundamental rights impact assessment) er den konsekvensanalyse vedrørende grundlæggende rettigheder, som artikel 27 i AI-forordningen kræver, før visse idriftsættere tager et højrisiko-AI-system i brug første gang. Den gælder offentlige myndigheder, private, der leverer offentlige ydelser, samt brugere af AI til kreditvurdering og prisfastsættelse af livs- og sygeforsikring. Resultatet skal anmeldes til markedsovervågningsmyndigheden.
Det vigtigste kort fortalt
- FRIA er en pligt for idriftsætteren, ikke for udbyderen. Den handler om, hvordan og hvor I bruger systemet, ikke om hvordan det er bygget.
- Den dækker kun højrisiko-AI i bilag III og undtager kritisk infrastruktur (bilag III, punkt 2).
- Artikel 27, stk. 1, litra a–f, lister seks elementer, fra de processer systemet indgår i til klagemuligheder, hvis skaden sker.
- Har I allerede en konsekvensanalyse vedrørende databeskyttelse (DPIA) efter GDPR, supplerer FRIA'en den og kan genbruge arbejdet.
- Efter Digital Omnibus gælder pligten sammen med højrisikokravene i bilag III fra 2. december 2027. Hvilken dansk myndighed der skal modtage anmeldelsen, er pr. oktober 2026 endnu ikke besluttet.
Hvorfor kræver AI-forordningen en FRIA?
De fleste krav i forordningen rammer udbyderne, men de kan ikke kende alle de sammenhænge, deres system bliver brugt i. En model til at matche ledige med job kan være grundigt testet hos leverandøren og alligevel stille en bestemt gruppe dårligere, når et jobcenter bruger den på langtidsledige borgere. FRIA'en lukker det hul ved at bede idriftsætteren, som kender de berørte mennesker, om at se på konkrete skader før første brug. Den ligger ved siden af idriftsætterens pligter i artikel 26. Den bredere ramme finder I i vores guide til AI-forordningen.
Har I brug for hjælp med cloud?
Book et gratis 30-minutters møde med en af vores specialister inden for cloud. Vi analyserer jeres behov og giver konkrete anbefalinger — helt uden forpligtelse.
Hvem skal lave en FRIA?
Teksten står i artikel 27 i forordningen om kunstig intelligens. En FRIA kræves, før et højrisiko-AI-system efter artikel 6, stk. 2, altså et system i bilag III, tages i brug af tre grupper:
| Idriftsætter | Hvilke systemer | Danske eksempler |
|---|---|---|
| Offentligretlige organer | Alle højrisikosystemer i bilag III undtagen kritisk infrastruktur (punkt 2) | En kommune, der bruger AI til at prioritere sager om kontanthjælp; en region, der bruger AI til at visitere patienter; et universitet, der bruger AI i optagelsen |
| Private, der leverer offentlige ydelser | Samme omfang som ovenfor | En privat leverandør af hjemmepleje, en friskole eller et privathospital, der bruger et højrisikosystem i ydelsen |
| Idriftsættere af systemer i bilag III, punkt 5, litra b og c, uanset ejerskab | Kreditvurdering og kreditscoring (dog ikke svindelopdagelse); risikovurdering og prisfastsættelse i livs- og sygeforsikring | En bank eller forbrugslånsvirksomhed med en scoremodel; et pensions- eller forsikringsselskab, der prissætter sundhedsforsikringer med AI |
To praktiske konsekvenser: En privat virksomhed, der bruger et AI-værktøj til at screene jobansøgere, skal ikke lave en FRIA, medmindre den leverer en offentlig ydelse, men mange vil alligevel lave en lettere udgave. Og alle banker og forsikringsselskaber, der bruger AI til kredit eller prisfastsættelse af livs- og sygeforsikring, er omfattet uanset ejerform.
Er I i tvivl om, hvilke af jeres systemer der hører til de tre grupper, kan Opsios gratis vurdering af AI-forordningen kortlægge jeres brug af AI på cirka 40 minutter og skrive en skabelon til AI-risikovurdering, som er et praktisk udgangspunkt for risikodelen af en FRIA.
Hvad skal en FRIA indeholde? Artikel 27, stk. 1, litra a–f
Forordningen nævner seks elementer. Lovteksten er kort, så højre kolonne foreslår, hvad et brugbart svar indeholder.
| Litra | Krævet element | Et godt svar indeholder |
|---|---|---|
| a | En beskrivelse af idriftsætterens processer, hvor systemet bruges i overensstemmelse med det tilsigtede formål | Processen trin for trin, hvor AI-outputtet kommer ind, og hvem der handler på det |
| b | Tidsrum og hyppighed for den tilsigtede brug | Startdato, forventet varighed, antal afgørelser pr. måned |
| c | Kategorier af fysiske personer og grupper, der sandsynligvis berøres | Ansøgere, kunder, borgere, medarbejdere, og sårbare undergrupper som personer med handicap eller lave digitale færdigheder |
| d | De specifikke risici for skade, under hensyn til udbyderens oplysninger efter artikel 13 | Forskelsbehandling, udelukkelse fra ydelser, fejl i vigtige afgørelser, indgreb i privatlivet; hver med sandsynlighed og alvor |
| e | Foranstaltninger til menneskeligt tilsyn efter brugsanvisningen | Hvem gennemgår output, deres oplæring og beføjelser, hvornår de skal tilsidesætte systemet, og hvordan uenighed registreres |
| f | Hvad der gøres, hvis risiciene indtræffer, herunder intern styring og klagemekanismer | Eskalering, kriterier for at stoppe brugen, klageadgang for de berørte, udbedring og evaluering |
Litra d er kernen. Brug rettighederne i EU's charter om grundlæggende rettigheder som tjekliste: menneskelig værdighed, ikke-forskelsbehandling, privatliv og databeskyttelse, ytringsfrihed, børns rettigheder, arbejdstageres rettigheder, adgang til social sikring og retten til effektive retsmidler. En ensartet scoringsmetode gør resultaterne sammenlignelige på tværs af systemer.
Tidspunkt, genbrug og opdatering
FRIA'en skal laves, før systemet tages i brug første gang. Efter artikel 27, stk. 2, kan idriftsætteren i lignende tilfælde støtte sig til en tidligere FRIA eller til en konsekvensanalyse, som udbyderen har lavet. Ændres et af de seks elementer under brugen, fx fordi systemet udvides til en ny gruppe borgere, skal analysen opdateres.
Fristen følger højrisikokravene. Efter Digital Omnibus gælder de for bilag III fra 2. december 2027. Offentlige myndigheder, der allerede bruger et højrisikosystem, har frist til 2. august 2030. Alle datoer står i tidslinjen for AI-forordningen.
Anmeldelse til markedsovervågningsmyndigheden
Når analysen er færdig, skal idriftsætteren efter artikel 27, stk. 3, anmelde resultaterne til markedsovervågningsmyndigheden og indsende den udfyldte skabelon. Eneste undtagelse er tilfælde efter artikel 46, stk. 1, hvor en myndighed undtagelsesvis har tilladt et system af hensyn til fx offentlig sikkerhed. Gem altid den fulde FRIA, og forvent opfølgende spørgsmål.
I Danmark er det pr. oktober 2026 endnu ikke endeligt besluttet, hvilken myndighed der fører tilsyn med højrisiko-AI og dermed modtager anmeldelserne. Den gældende lov nr. 467 af 14. maj 2025 dækker kun forbuddene, og et bredere lovforslag bortfaldt ved folketingsvalget i marts 2026. Læs mere i artiklen om tilsynet med AI-forordningen i Danmark.
Skabelonen fra AI-kontoret
Efter artikel 27, stk. 5, skal AI-kontoret udvikle en skabelon til et spørgeskema, eventuelt som et automatiseret værktøj, så idriftsættere kan opfylde pligten på en forenklet måde. Pr. oktober 2026 har vi ikke kunnet bekræfte, at en endelig officiel version er offentliggjort. Tjek AI-kontorets sider og Kommissionens AI Act Service Desk om artikel 27, før I indsender, og byg i mellemtiden jeres FRIA op om de seks elementer i artikel 27, stk. 1, så den nemt kan overføres til den officielle skabelon.
FRIA og DPIA: hvad er forskellen?
De fleste højrisikosystemer behandler personoplysninger, så mange idriftsættere skal også lave en konsekvensanalyse vedrørende databeskyttelse efter GDPR artikel 35. Artikel 27, stk. 4, siger, at hvis en pligt allerede er opfyldt gennem en DPIA, supplerer FRIA'en den. Efter ændringerne i Digital Omnibus kan idriftsætteren henvise til DPIA'en eller genbruge relevante dele af den. I skal ikke lave det samme arbejde to gange.
| DPIA (GDPR) | FRIA (AI-forordningen) | |
|---|---|---|
| Hjemmel | GDPR artikel 35 | AI-forordningen artikel 27 |
| Hvem laver den | Den dataansvarlige | Idriftsætter i en af de tre grupper |
| Udløses af | Behandling med sandsynlig høj risiko for de registrerede | Første brug af et højrisikosystem i bilag III |
| Fokus | Rettigheder berørt af behandlingen af personoplysninger | Alle grundlæggende rettigheder berørt af AI-brugen, også ud over privatliv |
| Kontakt med myndighed | Forudgående høring af Datatilsynet kun ved høj restrisiko | Resultatet anmeldes til markedsovervågningsmyndigheden |
En brugbar model er én samlet analyse med fælles beskrivelse af behandlingen og systemet og separate afsnit for databeskyttelsesrisici og for bredere rettighedsrisici. Artikel 26, stk. 9, giver desuden idriftsættere lov til at bruge udbyderens oplysninger efter artikel 13 i deres DPIA. Datatilsynets vejledning til offentlige myndigheder om brug af kunstig intelligens er et godt udgangspunkt for DPIA-delen. Har I brug for hjælp til GDPR-delen, kan I læse om vores GDPR-compliance.
En FRIA trin for trin
- Afklar omfang. Er systemet højrisiko efter bilag III og ikke punkt 2, og er I offentlig myndighed, leverandør af offentlige ydelser eller bruger af AI til kredit eller forsikring?
- Indhent udbyderens oplysninger. Brugsanvisning, tilsigtet formål, nøjagtighed, kendte begrænsninger og en eventuel konsekvensanalyse fra udbyderen.
- Beskriv processen (litra a) og tidsrum og hyppighed (litra b).
- Identificér de berørte (litra c), gerne med inddragelse af medarbejdere i frontlinjen og repræsentanter for de berørte grupper.
- Vurdér risici for skade (litra d) rettighed for rettighed, med sandsynlighed og alvor.
- Fastlæg menneskeligt tilsyn (litra e) med navngivne roller og oplæring.
- Planlæg reaktionen (litra f): kriterier for at stoppe, klager og udbedring.
- Kobl til DPIA'en med henvisninger i stedet for dobbeltarbejde.
- Godkend, anmeld og arkivér. Ledelsens godkendelse, anmeldelse til myndigheden og en dato for næste gennemgang.
Ofte stillede spørgsmål om FRIA
Hvem skal lave en FRIA efter AI-forordningen?
Idriftsættere af højrisiko-AI i bilag III, der er offentligretlige organer eller private, der leverer offentlige ydelser, samt alle, der bruger AI til kreditvurdering, kreditscoring eller risikovurdering og prisfastsættelse i livs- og sygeforsikring. Systemer i kritisk infrastruktur (bilag III, punkt 2) er undtaget. Udbydere laver ikke en FRIA.
Hvornår gælder kravet om FRIA?
FRIA'en hører til højrisikokravene for bilag III. Efter Digital Omnibus, forordning (EU) 2026/1744, gælder de fra 2. december 2027, pr. oktober 2026. Offentlige myndigheder, der allerede bruger et højrisikosystem, har frist til 2. august 2030. Analysen skal laves, før systemet tages i brug første gang.
Er en FRIA det samme som en DPIA?
Nej. En DPIA efter GDPR handler om risici ved behandling af personoplysninger, mens en FRIA dækker alle grundlæggende rettigheder, der berøres af brugen af et AI-system, fx ikke-forskelsbehandling og adgang til ydelser. FRIA'en supplerer DPIA'en, og I kan henvise til eller genbruge relevante dele af den.
Findes der en officiel FRIA-skabelon?
AI-forordningen pålægger AI-kontoret at udvikle et spørgeskema, eventuelt som et automatiseret værktøj, som idriftsættere indsender med anmeldelsen. Pr. oktober 2026 har vi ikke kunnet bekræfte en endelig version, så tjek AI-kontorets sider. Bygger I analysen op om de seks elementer i artikel 27, stk. 1, er den nem at overføre.
Skal vi lave en ny FRIA, hver gang vi bruger systemet?
Nej. Pligten gælder første brug, og i lignende tilfælde kan I støtte jer til en tidligere FRIA eller udbyderens konsekvensanalyse. Analysen skal opdateres, når et af de seks elementer ændrer sig eller ikke længere er retvisende, fx ved nye grupper af berørte, en ny proces eller en væsentligt anden brug.
Gør grundarbejdet, før FRIA'en skal laves
En FRIA er langt lettere, når I allerede ved, hvilke systemer I har, hvem der ejer dem, og hvordan I vurderer risiko. Få gratis AI governance-skabeloner skrevet til jeres organisation: Vurderingen tager cirka 40 minutter, og når I sender, får I fire redigerbare Word-dokumenter på engelsk – en AI governance-ramme, en AI-politik for medarbejdere, en tjekliste til vurdering af AI-leverandører og en skabelon til AI-risikovurdering – samt en modenhedsscore på ti områder. Spørgsmålene er på dansk. Gratis og uden forpligtelser.
Denne artikel er generel information og ikke juridisk rådgivning. Kontrollér den konsoliderede tekst af forordning (EU) 2024/1689 som ændret ved forordning (EU) 2026/1744. Oplysningerne er pr. oktober 2026.
Skrevet af
Country Manager, Sverige
Johan leder Opsios drift i Sverige og driver AI-indførelse, DevOps-transformation, sikkerhedsstrategi og cloud-løsninger til nordiske virksomheder. Med over 12 års erfaring inden for cloud-infrastruktur har han leveret over 200 projekter på AWS, Azure og GCP — med speciale i Well-Architected-reviews, landing zone-design og multi-cloud-strategi.
Redaktionelle retningslinjer: Artiklen er skrevet af cloud-eksperter og gennemgået af vores ingeniørteam. Vi opdaterer den, når den teknologi eller regulering, den handler om, ændrer sig; datoerne på siden viser den seneste opdatering. Opsio er redaktionelt uafhængig.