Rapport over afviklingskløft før EU-lancering

Hvorfor en gap-rapport er vigtig før lancering

Når du forbereder dig på at udgive et AI-system i EU, skal du dokumentere, at du har opfyldt de forpligtelser, der er fastsat i AI-loven. En gap-rapport omdanner disse lovmæssige krav til en konkrete liste over opgaver, du har gennemført, og opgaver, der endnu ikke er gennemført. Denne liste er nyttig for interne teams, revisorer og myndigheder, fordi den viser nøjagtigt, hvor arbejde er nødvendigt. Den lover ikke overholdelse, men viser blot den nuværende tilstand af indsats.

Vi starter med at læse den officielle tekst af loven og de relaterede retningslinjer fra Europa-Kommissionen. Hver forpligtelse kopieres ordret ind i en spalte i en regneark. Ved siden af hver forpligtelse tilføjer vi en spalte til bevis (såsom en politikdokument, en testresultat eller en kodekommentar). Hvis bevisspalten er tom, markerer vi rækken som en gap. Den resulterende tabel bliver arbejdslisten, der driver afhjælpning.

Fordi loven er skrevet i juridisk sprog, oversætter vi hver sætning til klare handlinger. For eksempel bliver "give klar information om AI-systemets funktioner" til "oprette en brugerorienteret beskrivelse, der listar inputtyper, outputformater og kendte begrænsninger". Denne oversættelsesproces forhindrer misfortolkning og gør det let at tildele ejere.

Hvordan vi mapper Act-forpligtelser til tekniske kontroller

Mapping er den kerneaktivitet, der omdanner juridisk tekst til ingeniørarbejde. Vi bruger en tre-kolonne-tabel: Forpligtelse, Kontrol, Bevis. Forpligtelses-kolonnen indeholder den præcise formulering fra loven. Kontrol-kolonnen listar de konkrete tekniske eller procedurmæssige foranstaltninger, vi har iværksat for at tilfredsstille denne formulering. Bevis-kolonnen indeholder en reference til en artifact (en dokumentlink, en testlog eller en konfigurationsfil).

Nedenfor er et eksempel på tabellen, vi vedligeholder. Den viser en undermængde af forpligtelser relateret til gennemsigtighed og datastyring. Tabellen opbevares i et delt regneark, så produkt-, juridisk- og ingeniørteam kan opdatere den i realtid.

Forpligtelse (lovens formulering) | Kontrol (hvad vi gør) | Bevis (artifact) Leverandører skal sikre, at naturlige personer er informeret om, at de interagerer med et AI-system (Artikel 13(1)). | Tilføje en varig banner på chat-grænsefladen, der lyder "Du taler med en AI-assistent". | Skærmbillede af banneret i staging-miljøet (link: internt/wiki/ai-banner). Leverandører skal gøre oplysninger om AI-systemets evner og begrænsninger tilgængelige på en klar og tilgængelig måde (Artikel 13(2)). | Udgive en modelkort, der listar anvendelsesformål, kendte fejlmål og performancesmetrikker. | Modelkort PDF gemt i overholdelsesrepoen (stien: docs/model-card-v2.pdf). Leverandører skal implementere passende datastyringsforanstaltninger for at sikre, at træningsdata er relevante, repræsentative og fri for fejl (Artikel 10(1)). | Køre en natlig datakvalitetsscript, der checker for manglende værdier, labelinkonsistenser og ud-af-distributionsekssempler. | Scriptoutputlog for sidste...

Tabellen gør det let at se, hvilke forpligtelser har bevis og hvilke ikke har. Manglende bevisrækker bliver til punkter på reparationsopgavelisten. Vi gennemgår tabellen på hvert sprintplanmøde og tildeler ejere til at lukke hullerne.

Opbygning af arbejdslisten: trin vi følger

Vores proces for at omdanne loven til en arbejdsliste består af fem gentagne trin. Hvert trin udføres af et lille tværfunktionelt team, der inkluderer en juridisk analytiker, en produktchef og en ingeniør.

- Indsamle kilde tekster – downloade den officielle Journal-version af loven, Kommissionens FAQ og eventuelle relevante standarder (f.eks. OWASP LLM Top 10 eller NIST AI RMF). Gem dem i en skrivebeskyttet mappe. - Udtræk pligter – kopier hver sætning, der pålægger en pligt på udbydere, til en hovedliste. Brug ordret formulering; oversæt ikke på dette stadie. - Oversæt til handlinger – for hver pligt skriv en kort imperativ sætning, der beskriver, hvad der skal gøres for at opfylde den. Hold oversættelsen under 20 ord, hvor det er muligt. - Match til kontroller – se på eksisterende politikker, kode og dokumentation for at se, om nogen allerede opfylder den oversatte handling. Hvis der findes en match, link beviset; hvis ikke, markér et gap. - Prioriter gapper – tildel en prioritet baseret på risikoniveau (høj, medium, lav) og anslået indsats (lille, medium, stor). Høj-risiko, lav-indsats gapper håndteres først.

Vi gentager cyklen, når loven ændres eller når vi udgiver en ny version af modellen. Hovedlisten findes på en Confluence-side, der kun kan redigeres af compliance-lederen, hvilket sikrer en enkelt kilde til sandheden.

Eksempel: Transparensforpligtelser (Artikel 13)

Artikel 13 fokuserer på at sikre, at brugerne er klar over, at de har med en AI-system at gøre, og forstår, hvad det kan og ikke kan gøre. For at opfylde dette har vi iværksat tre konkrete handlinger.

Først tilføjede vi en synlig advarsel til hver brugergrænseflade. Advarslen vises før den første interaktion og forbliver, indtil brugeren lukker den. Den indeholder den præcise frase, der kræves af loven: "Du interagerer med et AI-system". Advarselsteksten er gemt i UI-strings-filen (stien: src/i18n/da.json) og kontrolleres af vores automatiserede UI-testsuite.

Anden, oprettede vi en modelkort, der sammenfatter modellens ønskede brug, kendte begrænsninger og performancesnumre. Kortet følger formatet foreslået i OWASP LLM Top 10-vejledningen for transparens. Det er vært på vores interne dokumentationsside og er linket fra produktets hjælpeside.

Tredje, har vi oprettet en kvartalsvis gennemgang, hvor produktteamet verificerer, at advarslen stadig vises efter hver UI-udgivelse, og at modelkortet afspejler den seneste version. Enhver afvigelse skaber et nyt gap-element, der føjes til arbejdslisten.

Eksempel: Datastyringsforpligtelser (Artikel 10)

Artikel10 kræver, at udbydere sikrer, at de data, der bruges til træning, er passende, og at dokumentere de trin, der er taget for at adresse fordomme. Vi imødekommer disse krav gennem en kombination af automatiserede kontroller og manuel dokumentation.

Vi kører en datakvalitetspipeline hver nat, der scanner træningssættet for manglende værdier, duplikatposter og label-fejl. Pipelinen er bygget med åbne kildekomponenter og er konfigureret til at fejle bygningen, hvis nogen kritisk grænseværdi overskrides. Pipelineloggene er arkiveret i vores overholdelsesbucket (sti: gs://clauseguard-compliance/data-quality/).

Til biasreduktion vedligeholder vi en levende optegnelse, der listar hver intervention, vi har anvendt, såsom re-sampling af underrepræsenterede grupper eller justering af tabsvægte. Optegnelsen indeholder datoen, årsagen til ændringen og den målte virkning på retfærdighedsmålinger. Denne optegnelse opfylder dokumentationskravet og gennemgås af etikrådet før hver modeludgivelse.

Vi henviser også til NIST AI RMF, når vi vælger kontroller for datastyring.

Hvad dette ikke er

Denne gap-rapport er ikke en overensstemmelseserklæring. Den garanterer ikke, at AI-systemet opfylder alle krav i loven. Den lover ikke, at myndighederne vil acceptere de beviser, vi fremlægger. Den hævder ikke en 100 % succesrate i at finde alle mulige huller. Den påstår ikke, at arbejdslisten aldrig vil overse et problem. Den er blot en gennemsigtig optegnelse over, hvad vi har gjort, og hvad vi stadig har brug for at gøre, baseret på de kilder, vi har konsulteret.

Hvordan vi holder rapporten opdateret

At vedligeholde en nøjagtig gap-rapport kræver regelmæssige opdateringer. Vi har indført en let rytmik, der passer ind i vores eksisterende sprint-cyklus.

Til starten af hver sprint kører compliance-lederen et script, der sammenligner den nuværende version af loven (downloadet fra EU's officielle portal) med den mest komplette liste over forpligtelser. Eventuelle nye eller ændrede sætninger føjes til som nye rækker. Scriptet checker også bevis-links for at se, om nogen er flyttet eller er blevet utilgængelige; ødelagte links bliver markeret for den ansvarlige ejer.

Under sprint-rettrospektet gennemgår teamet gap-listen og markerer punkter som færdige, når det tilknyttede bevis er uploadet og verificeret. Færdige punkter flyttes til en arkiv-fane, så de kan være tilgængelige for revisioner, men ikke kludder den aktive visning.

Hver kvartal afholder vi et formelt gennemgangsmøde med juridiske, produkt- og ingeniørledere. I mødet gennemgår vi høj-prioriterede huller, bekræfter anstrengelsesestimater og justerer tidsrammer, hvis nødvendigt. Mødets udfald er en kort opdateringsnote, der føjes til Confluence-siden.

Referencer

- OWASP LLM Top 10 for Large Language Model Applications - NIST AI Risk Management Framework