Om ossTjänsterProjektArtiklar

Teknisk efterlevnad av AI-förordningen: teknisk dokumentation, loggning, mänsklig tillsyn och datastyrning

Det mesta som skrivits om AI-förordningen (AI Act) handlar om tillämpningsområdet: vilken riskkategori du hamnar i, om du är leverantör eller tillhandahållare och om ditt system omfattas av bilaga III. Den frågan besvarar dina juridiska rådgivare.

Nästan ingen tar upp vad som händer efter svaret. Om ditt system har hög risk kräver förordningen ett riskhanteringssystem som löper över hela livscykeln, datastyrning du kan styrka, automatisk loggning med fastställd lagringstid, teknisk dokumentation enligt en föreskriven struktur, mänsklig tillsyn som är konstruerad och inte bara påstådd, och övervakning efter utsläppandet på marknaden som faktiskt samlar in något. Det är leveranser för utvecklingsteamet. Det är den delen vi bygger.

Var tidsfristerna står i dag

AI-förordningen (förordning (EU) 2024/1689) trädde i kraft i augusti 2024 och börjar tillämpas i etapper. Etapperna ändrades under 2026, och det lönar sig att vara exakt, eftersom ändringen flyttade både pengar och uppmärksamhet.

  • 2 februari 2025: förbuden mot vissa AI-metoder och kraven på AI-kunnighet började gälla.
  • 2 augusti 2025: skyldigheterna för AI-modeller för allmänna ändamål började gälla.
  • 2 augusti 2026: transparenskraven i artikel 50 började gälla: att informera användaren om att den interagerar med ett AI-system, märkning av syntetiskt innehåll, information om känsloigenkänning och biometrisk kategorisering samt märkning av deepfakes.
  • 2 december 2027: kraven för fristående AI-system med hög risk, efter Digital Omnibus. Rådet och parlamentet enades om uppskjutandet i maj 2026, och det fick sitt slutliga godkännande i juni 2026.
  • 2 augusti 2028: kraven för AI-system med hög risk som är inbyggda i reglerade produkter.

Är du leverantör av ett system med hög risk gav uppskjutandet dig ungefär sexton månader till. Arbetet blev inte mindre, och de två skyldigheter som redan gäller flyttades inte: transparens enligt artikel 50 och AI-kunnighet hos den personal som hanterar systemen.

Det här bygger vi

Teknisk dokumentation som genereras

Bilaga IV anger vad den tekniska dokumentationen ska innehålla: systembeskrivning, designval, arkitektur, datakrav, träningsmetodik i förekommande fall, validerings- och testförfaranden, mätvärden, riskhanteringsåtgärder och de ändringar som gjorts under livscykeln.

Skrivs dokumentet för hand är det inaktuellt veckan efter att det skrevs under. Vi bygger det som något din pipeline producerar: modellkort och datablad som genereras från tränings- och utvärderingskörningarna, beskrivningar av arkitektur och dataflöden som underhålls tillsammans med koden, utvärderingsresultat kopplade till den version de beskriver och en ändringshistorik som kommer från versionshanteringen i stället för från någons minne. Dokumentet blir en del av byggresultatet.

Automatisk loggning som uppfyller artikel 12

System med hög risk ska logga automatiskt under hela sin livstid, på en nivå som gör det möjligt att spåra hur systemet fungerat och att övervaka det efter utsläppandet på marknaden. Lagringstiden ska vara lämplig för ändamålet och i vissa fall minst sex månader.

I praktiken betyder det att bestämma vad en ”händelse” är i just ditt system, fånga indata, utdata, modellversion, beslutsväg och identiteten på den människa som var inblandad, och lagra det i en form som går att söka i flera år senare. Allt det utan att samla på dig personuppgifter du saknar grund att behålla. Den spänningen (logga tillräckligt för AI-förordningen, spara tillräckligt lite för dataskyddsförordningen (GDPR)) är det egentliga designproblemet, och vi arbetar igenom det uttryckligen tillsammans med dina dataskyddsansvariga.

Datastyrning enligt artikel 10

Datamängder för träning, validering och testning ska vara relevanta, tillräckligt representativa och så långt det är möjligt felfria och fullständiga, och de ska granskas för snedvridning (bias). För att klara det behöver du dataspårbarhet du kan visa upp, dokumenterat ursprung, en metod för biasbedömning med resultat och möjlighet att återskapa vilka data som gav vilken modellversion.

Vi bygger den pipeline som gör de påståendena kontrollerbara i stället för önsketänkande: versionshanterade datamängder, reproducerbara uppdelningar, automatiska kvalitetskontroller av data och biasutvärdering på de skyddade egenskaper som är relevanta för ditt användningsfall.

Mänsklig tillsyn som byggs, inte deklareras

Artikel 14 kräver att system med hög risk utformas så att en människa kan förstå utdata, vara medveten om automationsbias, tolka resultatet korrekt, välja att inte använda det och ingripa eller stoppa systemet.

Det är en specifikation för ett användargränssnitt. Vi bygger in tillsynen i produkten: säkerhet och osäkerhet redovisas ärligt, de faktorer som ligger bakom ett resultat syns, det är lika enkelt att åsidosätta ett resultat som att godta det, stoppfunktionen fungerar och varje åsidosättande loggas så att övervakningen efter utsläppandet har något att lära sig av.

Övervakning efter utsläppandet på marknaden och incidentrapportering

Det krävs en övervakningsplan, och allvarliga incidenter ska rapporteras till behörig myndighet. Vi bygger den telemetri som matar planen: prestanda som följs mot mätvärdena i din dokumentation, upptäckt av drift i indata och utdata, en kanal för problem som användare rapporterar och som faktiskt når utvecklarna, och ett incidentflöde där tidskraven är inbyggda från början i stället för att upptäckas mitt under en incident.

Transparenskrav enligt artikel 50

De gäller redan. Information om att användaren har att göra med ett AI-system, maskinläsbar märkning av syntetiskt ljud, bild, video och text, märkning av deepfakes och information vid känsloigenkänning. Vi implementerar de ställen där informationen visas och märkningen av innehållets ursprung (C2PA content credentials där det är rätt mekanism), och ser till att märkningen överlever de export- och omkodningssteg som brukar ta bort den.

Stöd för registrering och bedömning av överensstämmelse

System med hög risk inom områdena i bilaga III ska registreras i EU-databasen innan de släpps ut på marknaden, och leverantörer ska genomföra en bedömning av överensstämmelse. Vi tar fram det tekniska underlaget (dokumentationen, bevispaketet och kvalitetsledningssystemets artefakter på utvecklingssidan) och arbetar tillsammans med ditt anmälda organ eller din interna bedömningsprocess.

Det här gör vi inte

Vi ger inte juridisk rådgivning, och vi säger inte vilken riskkategori ditt system tillhör. Den bedömningen är juridisk, får verkliga konsekvenser och hör hemma hos en jurist eller en kvalificerad compliancerådgivare.

Vi säljer inte heller någon plattform för AI-styrning. Det finns gott om sådana, och behöver du ett register över AI-system och ett arbetsflöde för policyer passar någon av dem dig bättre än vi. Det vi gör är utvecklingsarbetet inne i själva systemen.

Vem det här passar

Leverantörer av AI-system med hög risk enligt bilaga III (rekrytering och personalhantering, kreditbedömning, prissättning av försäkringar, bedömning inom utbildning, rätt till väsentliga tjänster, biometriska system), som nu har till december 2027 och mycket att bygga.

Tillverkare som bygger in AI i reglerade produkter (medicintekniska produkter, maskiner, fordon), där AI-förordningen läggs ovanpå en befintlig ordning för bedömning av överensstämmelse och de två dokumentationerna måste stämma överens.

Företag som använder system med hög risk som de köpt av någon annan och som har egna skyldigheter: mänsklig tillsyn, relevanta indata, övervakning och lagring av loggar.

Alla som levererar generativa funktioner till användare i EU, där transparenskraven i artikel 50 redan gäller i dag oavsett riskkategori.

Så går ett uppdrag till

Teknisk gapanalys, två till fyra veckor. Vi utgår från den klassificering ditt juridiska team har kommit fram till och bedömer dina system mot de tekniska skyldigheter som följer av den. Leveransen är ett gapregister (skyldighet, nuläge, vad som måste byggas, arbetsinsats) som både dina complianceansvariga och dina utvecklingsansvariga kan arbeta utifrån.

Bygget, i etapper och oftast med start i loggning och generering av dokumentation, eftersom allt annat producerar bevis som måste hamna någonstans.

Beredskapsgranskning inför bedömningen av överensstämmelse, med bevispaketet sammanställt och de luckor som återstår ärligt redovisade.

Standarder och ramverk

Förordning (EU) 2024/1689 med bilagorna III och IV; de harmoniserade standarder som tas fram inom CEN/CENELEC JTC 21; ISO/IEC 42001 för ledningssystem för AI och ISO/IEC 23894 för riskhantering inom AI; NIST AI Risk Management Framework när ett amerikanskt moderbolag behöver samordning; och dataskyddsförordningen (GDPR), som inte försvinner och som begränsar de flesta besluten om loggning.

Vanliga frågor

Har AI-förordningen skjutits upp?

Delvis. Digital Omnibus sköt upp kraven för hög risk till 2 december 2027 för fristående system och till 2 augusti 2028 för AI som är inbyggd i reglerade produkter. Förbuden mot vissa AI-metoder, AI-kunnighet, skyldigheterna för AI-modeller för allmänna ändamål och transparensreglerna i artikel 50 sköts inte upp och gäller redan nu.

Vi använder bara AI-system som någon annan har byggt. Har vi skyldigheter?

Ja, som tillhandahållare. Till dem hör att använda systemet enligt instruktionerna, att ge den mänskliga tillsynen till personer med kompetens och befogenhet att utöva den, att se till att indata är relevanta för det avsedda ändamålet, att övervaka driften och att spara loggar. Lättare än en leverantörs skyldigheter, men verkliga. Observera också att om du ändrar ett system väsentligt eller sätter ditt eget namn på det kan du bli leverantör.

Vårt system har inte hög risk. Behöver vi göra något?

Troligen två saker. Transparenskraven i artikel 50 gäller vissa system oavsett riskkategori, bland annat chattbotar och generering av syntetiskt innehåll. Och kravet på AI-kunnighet i artikel 4 gäller leverantörer och tillhandahållare generellt. Utöver det är det värt mycket att kunna styrka klassificeringsbeslutet om en tillsynsmyndighet någon gång frågar.

Går den tekniska dokumentationen verkligen att generera?

Det mesta av den, ja. Arkitektur, beskrivningar av datamängder, utvärderingsresultat, mätvärden, modellversioner och ändringshistorik finns redan i dina system; arbetet består i att fånga dem i en stabil struktur vid byggtillfället. De delar som verkligen är berättande (avsett ändamål, riskanalys, motivering av designen) skrivs av människor och förvaras sedan i samma kodförråd, så att de versionshanteras tillsammans med allt annat.

Hur samspelar AI-förordningen med dataskyddsförordningen?

De överlappar och drar ibland åt olika håll, särskilt när det gäller loggning. AI-förordningen vill ha spårbarhet; dataskyddsförordningen vill ha minimering och radering. Lösningen är oftast pseudonymisering, en noggrann avgränsning av vad som loggas och en fastställd lagringstid kopplad till ett dokumenterat ändamål. Det är ett designbeslut som fattas en gång, och medvetet.

Blir vi leverantör av en modell från tredje part om vi använder den?

Nej, men bygger du ett AI-system ovanpå en sådan modell kan du bli leverantör av det systemet, med de skyldigheter som följer med. Var gränsen går beror på vad du bygger och hur du presenterar det, vilket är en juridisk fråga. Den tekniska konsekvensen är dock att du bör räkna med att behöva dokumentation för ditt eget system oavsett.

Kom i gång

Berätta vad dina system gör och vilken klassificering dina juridiska rådgivare har landat i. Vi bedömer vad skyldigheterna innebär i kod och ger dig ett gapregister med arbetsinsatsen angiven för varje rad.

Kontakta oss för att boka en teknisk gapanalys enligt AI-förordningen.

Relaterade tjänster

Vill du komma igång med den här tjänsten?

Kontakta oss
← Tillbaka till alla tjänster