Teknisk etterlevelse av EUs AI-forordning: dokumentasjon, logging, menneskelig kontroll og datastyring

Det meste som er skrevet om EUs AI-forordning handler om virkeområde: hvilken risikoklasse du havner i, om du er leverandør eller ibruktaker, om systemet ditt fanges opp av vedlegg III. Det svarer juristene dine på.

Nesten ingen tar det som kommer etterpå. Er systemet ditt høyrisiko, krever forordningen et risikostyringssystem som løper gjennom hele livsløpet, datastyring du kan dokumentere, automatisk logging med definert lagringstid, teknisk dokumentasjon i en foreskrevet struktur, menneskelig kontroll som er designet og ikke bare påstått, og ettermarkedsovervåking som faktisk samler inn noe. Det er ingeniørleveranser. Det er den delen vi bygger.

Der fristene står nå

AI-forordningen (forordning (EU) 2024/1689) trådte i kraft i august 2024 og får anvendelse trinnvis. Trinnene ble endret i 2026, og det er verdt å være presis, for endringen flyttet både penger og oppmerksomhet.

• 2. februar 2025: forbudte praksiser og kravene til AI-kompetanse fikk anvendelse.
• 2. august 2025: pliktene for AI-modeller for generelle formål fikk anvendelse.
• 2. august 2026: åpenhetspliktene etter artikkel 50 fikk anvendelse: opplysning om at brukeren samhandler med et AI-system, merking av syntetisk innhold, opplysning om følelsesgjenkjenning og biometrisk kategorisering, og merking av deepfakes.
• 2. desember 2027: høyrisikopliktene for frittstående systemer, etter Digital Omnibus. Rådet og Parlamentet ble enige om utsettelsen i mai 2026, og den ble endelig vedtatt i juni 2026.
• 2. august 2028: høyrisikopliktene for AI-systemer innebygd i regulerte produkter.

Er du leverandør av et høyrisikosystem, kjøpte utsettelsen deg omtrent seksten måneder. Den reduserte ikke arbeidsmengden, og den flyttet ikke de to pliktene som allerede gjelder: åpenhet etter artikkel 50, og AI-kompetanse hos de ansatte som betjener slike systemer.

Hva vi bygger

Teknisk dokumentasjon som et generert artefakt

Vedlegg IV fastsetter hva den tekniske dokumentasjonen må inneholde: systembeskrivelse, designvalg, arkitektur, datakrav, treningsmetodikk der det er relevant, validerings- og testprosedyrer, målinger, risikostyringstiltak og endringene som er gjort gjennom livsløpet.

Skrevet for hånd er dette dokumentet utdatert uken etter at det er signert. Vi bygger det som noe pipelinen din produserer: modellkort og datablad generert fra trenings- og evalueringskjøringene, arkitektur- og dataflytbeskrivelser vedlikeholdt sammen med koden, evalueringsresultater festet til den versjonen de beskriver, og en endringshistorikk som kommer fra versjonskontrollen og ikke fra noens hukommelse. Dokumentet blir en byggeleveranse.

Automatisk logging som oppfyller artikkel 12

Høyrisikosystemer skal logge automatisk gjennom hele levetiden, på et nivå som gjør det mulig å spore hvordan systemet fungerer og å drive ettermarkedsovervåking, med lagringstid tilpasset formålet, og i noen tilfeller minst seks måneder.

I praksis betyr det å bestemme hva en «hendelse» er i ditt system, fange input, output, modellversjon, beslutningsvei og identiteten til mennesket som var involvert, lagre det i en form som fortsatt kan spørres mot om flere år, og gjøre det uten å samle opp personopplysninger du ikke har grunnlag for å beholde. Den spenningen (logg nok for AI-forordningen, behold lite nok for GDPR) er den reelle designoppgaven, og den går vi eksplisitt gjennom sammen med personvernfolkene dine.

Datastyring etter artikkel 10

Trenings-, validerings- og testdatasett skal være relevante, tilstrekkelig representative og så langt det er mulig feilfrie og fullstendige, med undersøkelse for skjevheter. Å innfri det krever datalinje du kan vise fram, dokumentert opphav, en metodikk for skjevhetsvurdering med resultater, og evnen til å reprodusere hvilke data som ga hvilken modellversjon.

Vi bygger pipelinen som gjør de påstandene etterprøvbare i stedet for ambisiøse: versjonerte datasett, reproduserbare splitter, automatiserte datakvalitetskontroller og skjevhetsevaluering på de beskyttede egenskapene som er relevante for bruksområdet ditt.

Menneskelig kontroll, bygget og ikke erklært

Artikkel 14 krever at høyrisikosystemer utformes slik at et menneske kan forstå resultatet, være bevisst på automatiseringsskjevhet, tolke resultatet riktig, velge å ikke bruke det, og gripe inn eller stanse systemet.

Det er en spesifikasjon av et brukergrensesnitt. Vi bygger kontrollen inn i produktet: konfidens og usikkerhet vist ærlig, faktorene bak et resultat gjort synlige, en overstyring som er like lett å bruke som å godta, en stoppfunksjon som virker, og logging av hver overstyring slik at ettermarkedsovervåkingen har noe å lære av.

Ettermarkedsovervåking og hendelsesrapportering

Det kreves en overvåkingsplan, og det kreves rapportering av alvorlige hendelser til rette myndighet. Vi bygger telemetrien som mater den: ytelse fulgt opp mot målingene i dokumentasjonen din, deteksjon av endringer over tid i inn- og utdata, en kanal for brukerrapporterte problemer som faktisk når utviklerne, og en hendelsesprosess med tidsfristene innebygd i stedet for oppdaget underveis i en hendelse.

Åpenhetsplikter etter artikkel 50

Gjelder allerede. Opplysning om at brukeren har med et AI-system å gjøre, maskinlesbar merking av syntetisk lyd, bilde, video og tekst, merking av deepfakes, og opplysning ved følelsesgjenkjenning. Vi bygger flatene der opplysningen gis, og merkingen av innholdets opphav (C2PA content credentials der det er riktig mekanisme), og sørger for at merkingen overlever eksport- og rekodingsveiene som vanligvis stripper den bort.

Støtte til registrering og samsvarsvurdering

Høyrisikosystemer på områdene i vedlegg III skal registreres i EU-databasen før de bringes i omsetning, og leverandøren må gjennomføre en samsvarsvurdering. Vi forbereder de tekniske bidragene (dokumentasjonen, bevispakken, artefaktene fra kvalitetsstyringssystemet på ingeniørsiden), og jobber sammen med det tekniske kontrollorganet ditt eller den interne vurderingsprosessen.

Hva dette ikke er

Vi gir ikke juridiske råd, og vi forteller deg ikke hvilken risikoklasse systemet ditt havner i. Den vurderingen er juridisk, har reelle konsekvenser, og hører hjemme hos advokat eller en kvalifisert compliance-rådgiver.

Vi selger heller ikke en plattform for AI-styring. Det finnes mange av dem, og er behovet ditt et register over AI-systemer og en policy-arbeidsflyt, vil en av dem tjene deg bedre enn vi ville gjort. Det vi gjør, er ingeniørarbeidet inne i systemene selv.

Hvem dette er for

Leverandører av høyrisikosystemer etter vedlegg III (rekruttering og personalstyring, kredittvurdering, forsikringsprising, vurdering i utdanning, tilgang til vesentlige tjenester, biometriske systemer), som nå har til desember 2027 og mye å bygge.

Produsenter som bygger AI inn i regulerte produkter (medisinsk utstyr, maskiner, kjøretøy) der AI-forordningen legger seg oppå et eksisterende samsvarsregime og de to dokumentasjonssettene må stemme overens.

Virksomheter som tar i bruk høyrisikosystemer kjøpt fra andre, og som har sine egne plikter: menneskelig kontroll, relevante inndata, overvåking og oppbevaring av logger.

Alle som leverer generative funksjoner til brukere i EU, der åpenhetsplikten i artikkel 50 allerede gjelder i dag, uavhengig av risikoklasse.

Slik kjøres oppdragene

Teknisk gap-analyse, to til fire uker. Vi tar klassifiseringen juristene dine har landet på, og vurderer systemene dine mot de tekniske pliktene som følger av den. Leveransen er et gap-register (plikt, dagens tilstand, hva som må bygges, innsats), som både compliance- og utviklingsledelsen kan jobbe ut fra.

Bygging, i faser, som regel med logging og dokumentasjonsgenerering først, fordi alt annet produserer dokumentasjon som må lande et sted.

Klargjøringsgjennomgang i forkant av samsvarsvurderingen, med bevispakken satt sammen og de gjenstående hullene navngitt ærlig.

Standarder og rammeverk

Forordning (EU) 2024/1689 med vedlegg III og IV; de harmoniserte standardene som kommer fra CEN/CENELEC JTC 21; ISO/IEC 42001 for styringssystemer for AI og ISO/IEC 23894 for AI-risikostyring; NIST AI Risk Management Framework der et amerikansk morselskap trenger samsvar med den; og GDPR, som ikke forsvinner, og som legger føringer på de fleste loggebeslutningene.

Ofte stilte spørsmål

Har AI-forordningen blitt utsatt?

Delvis. Digital Omnibus utsatte høyrisikopliktene til 2. desember 2027 for frittstående systemer og 2. august 2028 for AI innebygd i regulerte produkter. Forbudte praksiser, AI-kompetanse, pliktene for AI-modeller for generelle formål og åpenhetsreglene i artikkel 50 ble ikke utsatt og gjelder nå.

Vi bare bruker AI-systemer bygget av andre. Har vi plikter?

Ja, som ibruktaker. Det omfatter å bruke systemet i tråd med bruksanvisningen, legge den menneskelige kontrollen til folk med kompetanse og myndighet til å utøve den, sørge for at inndataene er relevante for det tiltenkte formålet, overvåke driften og oppbevare logger. Lettere enn leverandørens plikter, men reelle, og merk at det å endre et system vesentlig eller sette ditt eget navn på det kan gjøre deg til leverandør.

Systemet vårt er ikke høyrisiko. Er det noe å gjøre likevel?

Sannsynligvis to ting. Åpenhetsplikten i artikkel 50 gjelder visse systemer uavhengig av risikoklasse, blant annet chatboter og generering av syntetisk innhold. Og AI-kompetanse etter artikkel 4 gjelder leverandører og ibruktakere generelt. Utover det er det verdt å kunne dokumentere selve klassifiseringsbeslutningen, om en tilsynsmyndighet noen gang spør.

Kan den tekniske dokumentasjonen virkelig genereres?

Det meste, ja. Arkitektur, datasettbeskrivelser, evalueringsresultater, målinger, modellversjoner og endringshistorikk finnes allerede i systemene dine; jobben er å fange dem i en stabil struktur ved byggetidspunktet. De virkelig narrative delene (tiltenkt formål, risikoanalyse, designbegrunnelse) skrives av mennesker, og legges så i samme repository slik at de versjoneres sammen med alt annet.

Hvordan spiller AI-forordningen sammen med GDPR?

De overlapper og trekker av og til i hver sin retning, særlig på logging. AI-forordningen vil ha sporbarhet; GDPR vil ha dataminimering og sletting. Løsningen er som regel pseudonymisering, nøye avgrensning av hva som logges, og definert lagringstid knyttet til et dokumentert formål. Det er en designbeslutning, tatt én gang, bevisst.

Blir vi leverandør av en tredjepartsmodell fordi vi bruker den?

Nei, men å bygge et AI-system oppå den kan gjøre deg til leverandør av det systemet, med pliktene som følger med. Hvor grensen går, avhenger av hva du bygger og hvordan du presenterer det, og det er et juridisk spørsmål, men den tekniske konsekvensen er at du bør regne med å trenge dokumentasjon for ditt eget system uansett.

Kom i gang

Fortell oss hva systemene dine gjør og hvor de juridiske rådgiverne dine har landet på klassifiseringen. Vi vurderer hva pliktene betyr i kode og gir deg et gap-register med innsats på hver linje.

Kontakt oss for å avtale en teknisk gap-analyse etter AI-forordningen.

Relaterte tjenester

• AI-agenter og MCP-integrasjon: å bygge systemene dette regelverket styrer
• EU-markedsinngang utvikling: den bredere stakken for digital etterlevelse i EU
• Utbedring av Nettilgjengelighet: det andre EU-kravet som viser seg å være et ingeniørprosjekt