AI-forordningen ›

FRIA: den komplette guide til konsekvensanalyse af grundlæggende rettigheder

En FRIA er obligatorisk efter AI-forordningens artikel 27, men kun for bestemte idriftsættere af højrisiko-AI. Få styr på hvem der skal lave en, de seks krav, hvordan den supplerer din DPIA, og hvordan du laver en trin for trin.

Feature-billede til artiklen med den store overskrift »FRIA Guide« i mørkeblå på en blå-til-lilla gradientbaggrund med bløde blob-former. Over overskriften labelen »Artikel 27 · AI-forordningen« og under den en kort underrubrik. Til højre en blød bro i linjestil, der spænder fra et abstrakt AI-/chip-symbol til et vægt-/retfærdighedssymbol og antyder faserne beskriv, vurdér og afbød.

Skal din organisation til at idriftsætte et højrisiko-AI-system, er du sandsynligvis stødt på en ny forpligtelse med et ukendt akronym: FRIA'en. Den ligger ved siden af den konsekvensanalyse vedrørende databeskyttelse, du allerede kender, den bygger på dokumenter, som din AI-leverandør skal give dig, og den gælder for en overraskende snæver gruppe organisationer. At ramme forkert i begge retninger, at lave en når du ikke skal, eller at springe den over når du skal, er en dyr fejl.

En FRIA (Fundamental Rights Impact Assessment), på dansk en konsekvensanalyse af indvirkningen på grundlæggende rettigheder, er en forpligtelse forud for idriftsættelse efter artikel 27 i AI-forordningen (forordning (EU) 2024/1689). Der findes stadig meget få klare gennemgange på dansk af, hvad den egentlig kræver. Denne guide er skrevet for at være den ressource.

Nedenfor får du præcist hvem der skal lave en FRIA, de seks elementer loven kræver, hvordan en FRIA hænger sammen med din konsekvensanalyse vedrørende databeskyttelse (DPIA), en praktisk fremgangsmåde trin for trin, konkrete eksempler for en kommune, en bank og et forsikringsselskab, og hvad Digital Omnibus betyder for din tidsplan.

Hvad er en FRIA?

En FRIA er en struktureret analyse, som en idriftsætter foretager, før et højrisiko-AI-system tages i brug, for at identificere de specifikke risici, systemet udgør for menneskers grundlæggende rettigheder, og for at fastlægge, hvad der skal gøres, hvis disse risici opstår. Det er en af de få forpligtelser i AI-forordningen, der ser ud over selve teknologien og stiller det svære spørgsmål: hvad gør systemet ved de mennesker, der står på den modtagende side af dets afgørelser?

Formålet fremgår af præambelbetragtning 96. Idriftsætteren skal identificere de specifikke risici for rettighederne for de enkeltpersoner eller grupper, der sandsynligvis vil blive berørt, og fastlægge de foranstaltninger, der skal træffes, hvis risiciene opstår. Analysen skal laves før idriftsættelse og ajourføres, når idriftsætteren vurderer, at de relevante faktorer har ændret sig.

FRIA'en var ikke med i Kommissionens oprindelige forslag fra 2021. Den blev tilføjet af Europa-Parlamentet i 2023 ud fra en bekymring for, at højrisiko-AI i hænderne på offentlige myndigheder og udbydere af væsentlige tjenester i det stille kan udhule rettigheder som ikke-forskelsbehandling, værdighed og adgang til retfærdighed, medmindre nogen er forpligtet til at lede efter den skade på forhånd.

AI-forordningen definerer i artikel 3, nr. 2, risiko som kombinationen af sandsynligheden for, at der opstår en skade, og skadens alvor. Netop den kobling af alvor og sandsynlighed er det, som risikovurderingsdelen af en FRIA skal arbejde sig igennem, rettighed for rettighed.

FRIA vs DPIA: forskellen alle snubler over

Den absolut hyppigste misforståelse om FRIA'en er, at den enten erstatter eller erstattes af den konsekvensanalyse vedrørende databeskyttelse (DPIA), du allerede laver efter GDPR artikel 35. Den gør ingen af delene.

Artikel 27, stk. 4, er udtrykkelig. Hvis en forpligtelse under FRIA'en allerede er opfyldt gennem en DPIA, supplerer FRIA'en den pågældende konsekvensanalyse vedrørende databeskyttelse. Sagt enkelt supplerer FRIA'en DPIA'en. En DPIA opfylder ikke i sig selv din FRIA-forpligtelse, og en FRIA fjerner ikke dit behov for en DPIA. Det er to selvstændige, men komplementære instrumenter, og hvor begge gælder, kan du fornuftigt køre dem som én samlet øvelse, så længe rettighedsdelen reelt rækker ud over databeskyttelse.

Grunden til, at de ikke kan smelte sammen til ét, er, at de dækker forskelligt:

Aspekt	DPIA (GDPR art. 35)	FRIA (AI-forordningen art. 27)
Retsgrundlag	GDPR artikel 35	AI-forordningen artikel 27
Fokus	Risici ved behandling af personoplysninger	Risici for hele viften af grundlæggende rettigheder i chartret
Rettigheder	Primært databeskyttelse (chartrets art. 8)	Ikke-forskelsbehandling, værdighed, effektive retsmidler, god forvaltning m.m.
Hvem er berørt	Personer, hvis personoplysninger behandles	Alle berørte, også personer hvis data aldrig behandles
Udløser	Højrisikobehandling af personoplysninger	Idriftsættelse af bestemte højrisiko-AI-systemer
Forhold	Står alene	Supplerer DPIA'en hvor de overlapper

En god måde at se det på: en DPIA spørger, om du håndterer folks data lovligt og sikkert. En FRIA spørger, om systemet som helhed behandler mennesker retfærdigt. En kreditvurderingsmodel kan bestå en DPIA på datahåndtering og alligevel afvise ansøgere fra bestemte postnumre langt over gennemsnittet. Det er indirekte forskelsbehandling, som en DPIA aldrig var bygget til at fange, og det er præcis, hvad en FRIA er til for.

Har du allerede modne processer for DPIA, er de det naturlige udgangspunkt at bygge en FRIA ovenpå frem for at starte på et blankt stykke papir.

Hvem skal egentlig lave en FRIA?

Det er her, de fleste artikler skyder over målet. FRIA'en er en snæver, målrettet forpligtelse, og de fleste almindelige private virksomheder er ikke direkte omfattet. Artikel 27, stk. 1, gælder kun, når tre betingelser er opfyldt samtidig.

For det første skal systemet være et højrisiko-AI-system efter artikel 6, stk. 2, og bilag III. For det andet må det ikke være et system efter bilag III, punkt 2, om kritisk infrastruktur, da disse udtrykkeligt er undtaget fra FRIA-forpligtelsen. For det tredje skal du falde inden for en af de bestemte kategorier af idriftsættere, som artiklen nævner.

Kategori af idriftsætter	Typiske eksempler	FRIA påkrævet?
Offentligretlige organer	Ministerier, kommuner, regioner, styrelser	Ja, for ethvert omfattet højrisikosystem
Private udbydere af offentlige tjenester	Uddannelse, sundhed, sociale ydelser, bolig, retspleje	Ja, for ethvert omfattet højrisikosystem
Idriftsættere af bilag III, 5(b)	Banker, långivere og fintechs med kreditvurderings-AI	Ja, selvom private
Idriftsættere af bilag III, 5(c)	Liv- og sundhedsforsikring med AI til risikovurdering og prissætning	Ja, selvom private
Andre private idriftsættere	En virksomhed der bruger et højrisiko-rekrutteringsværktøj (bilag III, punkt 4)	Ingen FRIA efter art. 27, men fulde pligter efter art. 26 gælder stadig

To ting er værd at understrege. Henvisningen til "private udbydere af offentlige tjenester" er bevidst bred. Præambelbetragtning 96 kobler den til opgaver i offentlighedens interesse som uddannelse, sundhed, sociale ydelser, bolig og retspleje, så et privat hospital, en friskole med offentlig finansiering eller en almen boligorganisation kan være omfattet. Og kredit- og forsikringsidriftsættere trækkes ind, selvom de er private, og selvom de køber modellen som en færdig hyldevare.

Der er også et filter i artikel 6, stk. 3. Et bilag III-system er ikke automatisk højrisiko, hvis det kun udfører en snæver proceduremæssig opgave, forbedrer resultatet af en allerede afsluttet menneskelig aktivitet, opdager mønstre i beslutninger uden at erstatte den menneskelige vurdering, eller udfører forberedende arbejde. Men det filter slukkes i det øjeblik, systemet profilerer fysiske personer. En kreditvurderingsmodel profilerer per design og kan derfor ikke bruge filteret til at slippe fri.

Er du stadig i gang med at afklare, om AI-forordningen overhovedet gælder for dig, så start med vores guide til hvem der skal efterleve AI-forordningen og vores gennemgang af hvad der tæller som et AI-system. Vil du have det fulde billede af forordningen, så se vores komplette AI Act Guide.

De seks obligatoriske elementer i en FRIA

Artikel 27, stk. 1, fastsætter seks minimumselementer, som enhver FRIA skal indeholde. Indtil den officielle skabelon kommer, er det hele opgaven at ramme disse seks rigtigt. De falder naturligt i tre dele: at beskrive idriftsættelsen, at vurdere risiciene, og at fastlægge afbødningen.

Element	Hvad artikel 27, stk. 1, kræver
(a) Processer	En beskrivelse af idriftsætterens processer, hvori systemet vil blive anvendt i overensstemmelse med dets tilsigtede formål
(b) Tid og hyppighed	En beskrivelse af den periode og hyppighed, inden for hvilken systemet tilsigtes anvendt
(c) Berørte personer	De kategorier af fysiske personer og grupper, som forventes at blive påvirket i den specifikke kontekst
(d) Specifikke risici	De specifikke risici for skade for disse personer, under hensyntagen til udbyderens oplysninger efter artikel 13
(e) Menneskeligt tilsyn	En beskrivelse af gennemførelsen af foranstaltninger til menneskeligt tilsyn i overensstemmelse med brugsanvisningen
(f) Afbødning	De foranstaltninger, der skal træffes, hvis risiciene opstår, herunder intern ledelse og klagemekanismer

Element (a) til (c) er den beskrivende del. Element (d) er selve vurderingen. Element (e) og (f) er, hvor du viser, hvad du rent faktisk vil gøre ved de risici, du har fundet, herunder at give berørte personer en måde at klage og blive hørt på.

Hvornår skal en FRIA laves, og hvor ofte?

Forpligtelsen knytter sig til den første anvendelse af systemet, så FRIA'en skal være færdig, før du tager det i brug. For offentlige myndigheder er det naturlige tidspunkt at gå i gang under indkøbet, i god tid før idriftsættelse, så det, du lærer, stadig kan forme beslutningen om at købe eller vilkårene, du køber på.

Du behøver ikke opfinde den dybe tallerken hver gang. Artikel 27, stk. 2, lader dig i lignende tilfælde bygge på FRIA'er, du allerede har lavet, eller på en eksisterende analyse, som udbyderen har foretaget. En udbyders FRIA er et nyttigt udgangspunkt, men kun det. Den kan ikke fange de risici, der er specifikke for din kontekst, dine processer og de mennesker, du betjener, så behandl den som råmateriale snarere end en færdig leverance.

En FRIA er et levende dokument. Hvor oplysningerne ikke længere er ajour, skal du tage de nødvendige skridt til at opdatere dem. I praksis bør du gennemgå den mindst en gang om året og hver gang noget væsentligt ændrer sig: en ny version af modellen, en ny gruppe af berørte personer, en ny anvendelse, eller en hændelse, der viser, at en risiko er blevet virkelig.

Underretning af myndigheden og AI-kontorets skabelon

Når FRIA'en er lavet, kræver artikel 27, stk. 3, at du underretter markedsovervågningsmyndigheden om resultaterne og indsender en udfyldt skabelon som en del af underretningen. Det er en separat kanal fra alt, hvad du gør efter GDPR. En FRIA-underretning går til AI-myndigheden, ikke til databeskyttelsesmyndigheden, selvom det i Danmark kan være det samme organ, der bærer begge kasketter for systemer, der involverer personoplysninger. Der er en snæver undtagelse knyttet til artikel 46, stk. 1, for visse ekstraordinære tilladelser.

Selve skabelonen er der, hvor tingene stadig er uafklarede. Artikel 27, stk. 5, kræver, at AI-kontoret udarbejder en skabelon i form af et spørgeskema, herunder et automatiseret værktøj, for at gøre efterlevelsen enklere. Som det ser ud nu, er den skabelon ikke offentliggjort, og der er ingen fast frist for den. At den mangler, sætter ikke din forpligtelse på pause. Byg din analyse på de seks lovbestemte elementer nu, og tilpas til den officielle skabelon, når den kommer.

Sådan hænger en FRIA sammen med leverandørens dokumenter

En FRIA er ikke tænkt til at blive skrevet i isolation. Den kobler sig direkte på de dokumenter, som udbyderen af højrisikosystemet skal give dig.

Brugsanvisningen efter artikel 13 fodrer element (d), fordi du skal inddrage udbyderens oplysninger, når du vurderer risiciene for skade, og den fodrer element (e), fordi det menneskelige tilsyn, du beskriver, skal svare til det, brugsanvisningen fastlægger. Bag kulisserne leverer udbyderens risikostyringssystem efter artikel 9 og den tekniske dokumentation efter artikel 11 og bilag IV meget af det stof, din analyse trækker på. Har din leverandør ikke afleveret disse, kan du ikke lave en ordentlig FRIA, hvilket gør dem til et kontraktligt krav snarere end noget rart at have.

Parallelt løber artikel 26, som fastlægger idriftsætterens bredere pligter: at bruge systemet efter brugsanvisningen, at sætte kompetente og uddannede personer til tilsynet, at opbevare de automatisk genererede logfiler i mindst seks måneder, at overvåge driften, at suspendere og indberette, hvor en alvorlig risiko opstår, og at informere medarbejderne, hvor systemet bruges på arbejdspladsen.

Sådan laver du en FRIA: en fremgangsmåde trin for trin

Den mest gennemarbejdede metode indtil videre er dansk. Institut for Menneskerettigheder har sammen med European Center for Not-for-Profit Law udgivet A Guide to Fundamental Rights Impact Assessments med en tilhørende skabelon. Trinene nedenfor kombinerer de lovbestemte elementer med den model.

Trin 1: klassificér og afgræns

Bekræft, at systemet er højrisiko, at det ikke er et system efter bilag III, punkt 2, om kritisk infrastruktur, og at du er en omfattet idriftsætter. Dokumentér din begrundelse, også hvor du konkluderer, at en FRIA ikke er påkrævet, så du har et spor af beslutningen. Sæt et tværfagligt hold og læg et budget.

Trin 2: beskriv idriftsættelsen (element a og b)

Beskriv det tilsigtede formål, de processer systemet indgår i, inputdata, output, den afgørelse det understøtter eller automatiserer, og perioden og hyppigheden af anvendelsen.

Trin 3: kortlæg de berørte personer (element c)

Identificér, hvem der berøres, direkte og indirekte, i netop denne kontekst. Vær særligt opmærksom på personer i sårbare situationer, som børn, ældre, minoriteter og modtagere af ydelser, der kan tage skade på måder, det er let at overse.

Trin 4: vurdér risiciene for rettighederne (element d)

For hver relevant rettighed i chartret opstiller du et realistisk typisk scenarie og et værst tænkeligt scenarie og scorer derefter alvoren og sandsynligheden for skade under hensyntagen til udbyderens oplysninger efter artikel 13. Prioritér de alvorligste konsekvenser. Skeln mellem absolutte rettigheder, hvor en reel risiko bør stoppe idriftsættelsen, og relative rettigheder, hvor du vurderer nødvendighed og proportionalitet.

Trin 5: fastlæg tilsyn og afbødning (element e og f)

Angiv konkrete foranstaltninger til menneskeligt tilsyn i overensstemmelse med brugsanvisningen, og fastlæg afbødning i tre familier: organisatorisk (reelt tilsyn, klage- og oprejsningsprocedurer, gennemsigtighed, AI-færdigheder), teknisk (cybersikkerhed, logstyring, repræsentative inputdata, test for bias) og kontraktlig (udbyderens pligter om datakvalitet, samarbejde om opdateringer, forklarlighed). Foretræk foranstaltninger, der forhindrer skade, frem for dem, der blot dæmper den.

Trin 6: beslut, underret og rapportér

Nå frem til en begrundet anbefaling om at idriftsætte eller lade være, underret markedsovervågningsmyndigheden om resultaterne, og offentliggør en passende sammenfatning, med begrænset håndtering hvor retshåndhævelse eller migration er involveret.

Trin 7: overvåg, gennemgå og inddrag

Sæt overvågning efter idriftsættelse i værk, opdatér FRIA'en når relevante faktorer ændrer sig, og inddrag berørte grupper og deres repræsentanter undervejs. At tale med de mennesker, der skal leve med systemet, er både en god praksis efter præambelbetragtning 96 og en reel kvalitetskontrol af dine egne antagelser.

Konkrete eksempler

En kommune der idriftsætter et ydelses- eller fraud-system

En kommune, der bruger et AI-system til at markere mulig socialt bedrageri, skal lave en FRIA. Arbejdet centrerer sig om at kortlægge berørte borgere, teste for indirekte forskelsbehandling via proxyer som postnummer eller husstandssammensætning, og dokumentere, at en sagsbehandler reelt gennemgår hver markering, før der handles på den. Tilsynet skal være ægte, ikke et gummistempel. Rettighederne i spil omfatter værdighed, ikke-forskelsbehandling, social sikring og bistand, god forvaltning og retten til effektive retsmidler.

En bank der bruger en kreditvurderingsmodel fra tredjepart

En bank, der idriftsætter en kreditvurderingsmodel, skal lave en FRIA, selvom den er en privat virksomhed, og selvom den har købt modellen af en leverandør. Den klassiske fejl er et system, der håndterer data lovligt, men alligevel afviser ansøgere fra bestemte områder i langt højere grad. De centrale spørgsmål er, om modellen diskriminerer indirekte, og om en ansøger kan forstå og anfægte den score, der formede afgørelsen.

Et liv- eller sundhedsforsikringsselskab der prissætter risiko med AI

Et forsikringsselskab, der bruger AI til risikovurdering og prissætning inden for liv- eller sundhedsforsikring, er klart omfattet. Fokus falder på uforholdsmæssig påvirkning af personer med lav indkomst eller højere risiko og på, hvor gennemsigtig prissætningslogikken er for de mennesker, den berører.

FRIA i Danmark: myndigheder og nationale regler

Danmark var en af de første medlemsstater, der lovgav for AI-forordningen. Lov om supplerende bestemmelser til AI-forordningen (lov nr. 467 af 14. maj 2025) trådte i kraft den 2. august 2025 og fastlægger den nationale håndhævelsesstruktur.

Digitaliseringsstyrelsen er notificerende myndighed, markedsovervågningsmyndighed og det centrale nationale kontaktpunkt. Datatilsynet er markedsovervågningsmyndighed for biometriske og personoplysningsrelaterede forhold og i praksis for højrisikosystemer, der involverer personoplysninger. Domstolsstyrelsen dækker domstolenes ikke-dømmende brug af AI. Den præcise fordeling af tilsynet med højrisikosystemer, og dermed hvor en FRIA-underretning skal lande, er stadig ved at falde på plads, hvilket er endnu en grund til at behandle AI-forordningen og GDPR som én sammenhængende øvelse frem for to adskilte siloer.

Fordi dansk DPIA-praksis allerede kræver en analyse for det meste substantielle offentlige AI, vil de fleste danske offentlige myndigheder opdage, at de har et solidt fundament at bygge en FRIA ovenpå, frem for at starte koldt.

Sanktioner ved manglende efterlevelse

Idriftsætterpligterne ligger i det mellemste niveau af AI-forordningens sanktionsregime. Efter artikel 99, stk. 4, kan overtrædelser udløse administrative bøder på op til 15 mio. euro eller op til 3 % af den samlede globale årlige omsætning i det foregående regnskabsår, alt efter hvad der er højest. For små og mellemstore virksomheder og startups er det det laveste af de to beløb, der gælder.

Det er værd at rette et tal, der cirkulerer i nogle artikler. Loftet for idriftsætterpligter er ikke 30 mio. euro eller 6 %. Det øverste niveau på 35 mio. euro eller 7 % er forbeholdt de forbudte praksisser i artikel 5, og det laveste niveau på 7,5 mio. euro eller 1 % gælder for at give ukorrekte eller vildledende oplysninger. Ud over bøderne kan en myndighed påbyde et system suspenderet eller trukket tilbage, hvilket ofte er mere forstyrrende for en virksomhed end selve bøden.

Hvad Digital Omnibus ændrer

Tidsplanen omkring højrisikopligterne har været i bevægelse. Digital Omnibus, en forenklingspakke, udskyder de selvstændige højrisikopligter i bilag III, og den FRIA der følger dem, fra den oprindelige dato 2. august 2026 til 2. december 2027. Europa-Parlamentet tilsluttede sig pakken i juni 2026, og Rådet gav sin endelige godkendelse kort efter, med virkning fra offentliggørelsen i Den Europæiske Unions Tidende.

Fordi datoen har været i flux, er den fornuftige tilgang at bygge efter forpligtelsen frem for efter en bestemt frist. Brug en eventuel udskydelse som tilløb til at lave en grundig og forsvarlig analyse, ikke som en grund til at holde pause. Bemærk også, at gennemsigtighedspligterne i artikel 50 ikke blev udskudt, så dele af AI-forordningen gælder fortsat efter den oprindelige tidsplan.

FRIA som del af løbende AI-governance

En FRIA virker bedst, når den ikke er et engangsdokument, men et resultat af et fast AI-governance-system. At indlejre løbende FRIA- og DPIA-cyklusser, styring af leverandørdokumentation og gennemgang efter idriftsættelse i en ramme som ISO 42001, den første ledelsessystemstandard for AI, giver dig sporbarhed og forhindrer, at hvert nyt system håndteres som en frisk brandslukning. Kører du allerede processer for governance, risiko og compliance, glider FRIA'en ind i dem frem for at sidde for sig selv.

Kom godt i gang

Det praktiske første skridt er ikke at skrive en FRIA. Det er at bygge et overblik over dine AI-systemer og for hvert enkelt vurdere, om det er højrisiko, om filteret i artikel 6, stk. 3, overhovedet er tilgængeligt, og om du er en omfattet idriftsætter. Den klassificering fortæller dig, hvor en FRIA er obligatorisk, og hvor den ikke er, og det er den dokumentation, du vil ønske dig, hvis en myndighed en dag spørger.

At håndtere FRIA'er, DPIA'er, leverandørdokumentation og løbende gennemgange på tværs af en portefølje af AI-systemer er præcis den slags arbejde, en dedikeret platform er bygget til. Vores AI Act framework hjælper dig med at klassificere systemer, gennemføre og gemme analyser og holde det hele klar til revision ét sted.

Vil du se, hvordan det fungerer i praksis? Book en demo, så viser vi dig rundt.

Oftest stillede spørgsmål om FRIA

Hvad er en FRIA?

En FRIA er en konsekvensanalyse af indvirkningen på grundlæggende rettigheder, en forpligtelse forud for idriftsættelse efter artikel 27 i AI-forordningen. En idriftsætter af bestemte højrisiko-AI-systemer skal analysere de specifikke risici, systemet udgør for menneskers grundlæggende rettigheder, og fastlægge, hvad der skal gøres, hvis risiciene opstår, før systemet tages i brug.

Hvem skal lave en FRIA?

Kun bestemte idriftsættere af højrisiko-AI: offentligretlige organer, private udbydere af offentlige tjenester og private idriftsættere af bilag III-systemer til kreditvurdering og liv- eller sundhedsforsikring. Den gælder ikke for alle idriftsættere eller alle højrisikosystemer, og aldrig for systemer efter bilag III, punkt 2, om kritisk infrastruktur.

Hvad er forskellen på en FRIA og en DPIA?

En DPIA efter GDPR artikel 35 vurderer risici ved behandling af personoplysninger. En FRIA efter AI-forordningens artikel 27 vurderer risici for hele viften af grundlæggende rettigheder i chartret, også for personer hvis data aldrig behandles. Efter artikel 27, stk. 4, supplerer FRIA'en DPIA'en. Ingen af dem erstatter den anden, og hvor begge gælder, kan de laves som én samlet analyse.

Erstatter en FRIA en DPIA?

Nej. En FRIA erstatter ikke en DPIA, og en DPIA erstatter ikke en FRIA. Artikel 27, stk. 4, fastslår, at FRIA'en supplerer konsekvensanalysen vedrørende databeskyttelse, hvor forpligtelserne overlapper. Du kan have brug for begge, og du kan lave dem sammen, men rettighedsdelen i FRIA'en skal reelt række ud over databeskyttelse.

Hvad er de seks elementer i en FRIA?

Artikel 27, stk. 1, kræver: (a) en beskrivelse af idriftsætterens processer med systemet; (b) perioden og hyppigheden af den tilsigtede anvendelse; (c) kategorierne af personer, der forventes berørt; (d) de specifikke risici for skade under hensyntagen til udbyderens oplysninger efter artikel 13; (e) hvordan menneskeligt tilsyn gennemføres; og (f) de foranstaltninger, der skal træffes, hvis risiciene opstår, herunder intern ledelse og klagemekanismer.

Hvornår skal en FRIA laves?

Før den første anvendelse af højrisikosystemet. I lignende tilfælde kan du bygge på en tidligere FRIA eller på en, udbyderen har lavet, men du skal opdatere analysen, når relevante faktorer ændrer sig. I praksis bør du gennemgå den mindst en gang om året og ved væsentlige ændringer som en ny modelversion, en ny berørt gruppe eller en indtruffen hændelse.

Skal jeg underrette en myndighed om min FRIA?

Ja. Efter artikel 27, stk. 3, skal idriftsætteren underrette markedsovervågningsmyndigheden om resultaterne og indsende en udfyldt skabelon som en del af underretningen. Kanalen er separat fra GDPR, selvom det i Danmark kan være samme organ, der håndterer begge for systemer med personoplysninger. En snæver undtagelse gælder efter artikel 46, stk. 1.

Findes der en officiel FRIA-skabelon?

Artikel 27, stk. 5, kræver, at AI-kontoret udarbejder en skabelon i form af et spørgeskema, herunder et automatiseret værktøj. Som det ser ud nu, er den ikke offentliggjort, og der er ingen fast frist. At den mangler, sætter ikke forpligtelsen på pause, så byg din FRIA på de seks lovbestemte elementer nu, og tilpas til den officielle skabelon, når den kommer.

Skal en privat virksomhed lave en FRIA?

Som regel ikke, medmindre den udbyder en offentlig tjeneste eller idriftsætter et bilag III-system til kreditvurdering eller liv- eller sundhedsforsikring. En privat virksomhed, der bruger et højrisiko-rekrutteringsværktøj, er ikke direkte FRIA-forpligtet efter artikel 27, men bærer stadig de fulde idriftsætterpligter efter artikel 26, og dens offentlige kunder kan kontraktligt kræve FRIA-lignende dokumentation.

Hvad er sanktionen for ikke at lave en påkrævet FRIA?

Overtrædelser af idriftsætterpligter ligger i det mellemste niveau af artikel 99, med bøder på op til 15 mio. euro eller 3 % af den samlede globale årlige omsætning, alt efter hvad der er højest, og det laveste beløb for SMV'er og startups. Myndigheder kan også påbyde et system suspenderet eller trukket tilbage. Det ofte citerede tal på 30 mio. euro eller 6 % er forkert for idriftsætterpligter.

Har du fortsat spørgsmål?

Spørg Johannes direkte, han giver de fleste af vores demoer personligt

Book ham her

.legal compliance platform Kør FRIA'er og DPIA'er Uden Regneark-kaos

At håndtere FRIA'er, DPIA'er og leverandørdokumentation på tværs af en portefølje af AI-systemer er præcis den slags arbejde, en dedikeret platform er bygget til. .legal klassificerer hvert system, gennemfører og gemmer dine analyser og holder det hele revisionsklart ét sted.