
AI-governance kan kombinere et ledelsessystem, et risikoframework og juridiske forpligtelser. Den tekniske udfordring er at forbinde dem uden at lade som om, de er udskiftelige. En politik, en evalueringsrapport og en juridisk klassificeringsbeslutning kan understøtte den samme AI-tjeneste, men hver af dem besvarer et forskelligt spørgsmål.
ISO/IEC 42001 fastlægger, hvordan en organisation styrer AI. NIST's AI Risk Management Framework hjælper teams med at undersøge og styre risici i deres kontekst. EU's AI-forordning fastlægger juridiske forpligtelser ud fra systemet, dets tilsigtede formål og organisationens rolle som operatør.
For en CTO er det nyttige resultat én governancekæde, der kan gennemgås: en defineret use case, ansvarlige ejere, implementerede sikkerhedsforanstaltninger, testevidens, releasebeslutninger og overvågning. Frameworkmappinger bør pege ind i den kæde og samtidig bevare de krav, der stadig kræver teknisk, juridisk eller overensstemmelsesrelateret arbejde.
| Instrument | Primært formål | Nyttigt implementeringsoutput | Hvad det ikke fastlægger |
|---|---|---|---|
| ISO/IEC 42001 | Krav til et ledelsessystem for AI, et AIMS | Afgrænsede governanceprocesser, ansvarsområder, vurderinger, operationelle kontroller og registreringer af forbedringer | Automatisk overholdelse af lovgivningen eller godkendelse af ethvert AI-produkt |
| NIST AI RMF | Frivillig vejledning i styring af AI-risici | Kontekstuel risikoanalyse, evalueringsmetoder, behandlingsbeslutninger og overvågning | En certificering i ISO-stil eller en juridisk undtagelse |
| EU's AI-forordning | Bindende juridiske forpligtelser inden for dens anvendelsesområde | Beslutninger om rolle og klassificering, gældende tekniske og organisatoriske foranstaltninger og påkrævet juridisk dokumentation | En universel tjekliste, der gælder ens for enhver AI-use case |
ISO/IEC 42001 specificerer krav til at etablere, implementere, vedligeholde og løbende forbedre et AIMS. Kravene til ledelsessystemet omfatter organisationens kontekst, ledelse, planlægning, støtte, drift, evaluering af præstationer og forbedring.
Den struktur er vigtig, når flere teams bygger eller køber AI. Den giver et grundlag for at beslutte, hvem der godkender idriftsættelse, hvordan konsekvens- og risikovurderinger gennemføres, hvordan leverandørafhængigheder håndteres, og hvordan fejl fører til korrigerende handlinger.
Standarden indeholder også referencekontroller i Annex A og vejledning i implementering. Udvælgelsen af kontroller er risikobaseret og kræver en dokumenteret begrundelse; at kopiere bilaget ind i en tjekliste fastslår ikke, at ledelsessystemet fungerer.
Et uafhængigt certificeringsorgan kan vurdere det afgrænsede AIMS. ISO selv certificerer ikke organisationer. Certificering giver sikkerhed for det pågældende ledelsessystem inden for dets angivne grænse, ikke en ubegrænset påstand om, at enhver model eller ethvert output er sikkert.
NIST AI RMF organiserer risikoarbejdet omkring Govern, Map, Measure og Manage. Govern går på tværs; funktionerne er ikke blot fire sekventielle projektfaser.
Rammens kendetegn for troværdighed omfatter validitet og pålidelighed, sikkerhed for mennesker, sikkerhed og modstandsdygtighed, ansvarlighed og gennemsigtighed, forklarbarhed og fortolkelighed, beskyttelse af privatlivet samt retfærdighed med styring af skadelig bias. Disse kendetegn kan indebære afvejninger. Mere detaljerede forklaringer kan for eksempel afsløre oplysninger, der kræver beskyttelse af privatlivet.
NIST's vejledning hjælper teams med at omsætte brede mål til spørgsmål og evalueringer, der er specifikke for en use case. Den adresserer også ansvarlighed; governance er ikke forbeholdt ISO 42001. Der findes ingen certificeringsordning for NIST AI RMF, der kan sammenlignes med ISO-certificering af ledelsessystemer. En ekstern vurdering kan understøtte sikkerheden, men dens scope og metode skal angives.
EU's AI-forordning regulerer bestemte praksisser, AI-systemer og AI-modeller til almen brug gennem forskellige bestemmelser. Den juridiske anvendelighed afgøres ikke af en teknisk risikoscore alene. Tilsigtet formål, territorialt anvendelsesområde, operatørrolle og specifikke klassificeringsregler har betydning.
En udbyders forpligtelser adskiller sig fra en idriftsætters. En model er ikke det samme som den applikation, der indbygger den, og at kalde software en “agent” afgør ikke dens juridiske rolle eller klassificering.
Vedligehold en AI-fortegnelse på niveau med de operationelle use cases og ikke kun med leverandørnavne. Én underliggende model kan understøtte både en intern skriveassistent og et værktøj til screening af ansøgere. Disse idriftsættelser har forskellige berørte personer, konsekvenser, kontroller og potentielle forpligtelser.
Registrér for hver use case:
En organisation uden for EU kan under bestemte omstændigheder stadig være omfattet af forordningens anvendelsesområde. Omvendt berettiger det at have kunder i EU ikke til at tildele alle tænkelige forpligtelser til ethvert produkt. Gennemgå de faktiske betingelser for territorium og rolle.
Adskil forbudte praksisser, krav til højrisikosystemer, særlige gennemsigtighedsforpligtelser og forpligtelser for AI-modeller til almen brug. Det er ikke udskiftelige niveauer på én teknisk alvorlighedsskala. En tilsyneladende harmløs chatbot kan have gennemsigtighedsforpligtelser; en use case med stor påvirkning kræver en mere detaljeret juridisk vurdering.
Europa-Kommissionens oversigt over AI-forordningen angiver, kontrolleret pr. 7. oktober 2026, følgende tidsplan:
| Område | Anvendelsesdato |
|---|---|
| Forbudte praksisser og AI-færdigheder | 2. februar 2025 |
| Bestemmelser om AI til almen brug | 2. august 2025 |
| Generel anvendelse, herunder gennemsigtighed | 2. august 2026 |
| Højrisikosystemer efter bilag III | 2. december 2027 |
| Højrisikosystemer knyttet til regulerede produkter efter bilag I | 2. august 2028 |
Vurdér ændrede bestemmelser, overgangsordninger og det specifikke system separat. Udskyd ikke forpligtelser, der allerede gælder, fordi der findes en senere dato for højrisiko. Hold den juridiske vurdering dateret, og brug vores guide til parathed over for AI-forordningen som kontekst for tidsplan og vurdering af roller.
En praktisk governancekæde starter med use casen og slutter med en gennemgået beslutning:
Formål → påvirkninger og risici → krav → sikkerhedsforanstaltninger → evalueringer → godkendelse → overvågning.
Hver forbindelse kræver tilstrækkelige detaljer til, at en person uden for implementeringsteamet kan undersøge den. “Menneskeligt tilsyn implementeret” er utilstrækkeligt, hvis den gennemgående ikke kan fastslå, hvem der kan gribe ind, hvad de ser, og om indgrebet virker.
Brug en kravregistrering, der skelner kildekravet fra dets implementering. Et nyttigt minimumsskema omfatter kilde og version, scope, kravtekst eller henvisning, lokal fortolkning, kontrolejer, tilknyttet evidens, gennemgående, status og resterende hul.
| Governancehensyn | Fælles evidens | Yderligere spørgsmål, der skal bevares |
|---|---|---|
| Ansvarlighed | Registreringer af ejerskab og godkendelsesprocedure | Har den juridiske operatør de påkrævede ansvarsområder? |
| Datastyring | Oprindelse, dokumentation af datasæt og adgangskontroller | Er systemspecifikke lovkrav adresseret? |
| Menneskeligt tilsyn | Brugerfladedesign, uddannelse og test af indgreb | Kan den udpegede person forstå, tilsidesætte eller stoppe den relevante operation? |
| Risikostyring | Vurdering, behandlingsplan og beslutning om restrisiko | Dækker vurderingen den påkrævede livscyklus og de berørte personer? |
| Overvågning | Målinger, hændelsesregistreringer og gennemgange af ændringer | Er gældende indberetnings- og efterfølgende markedsovervågningsforpligtelser opfyldt separat? |
Behandl tabellen som et implementeringshjælpemiddel, ikke som et autoritativt ækvivalenskort. Relationerne er mange-til-mange: én evaluering kan understøtte flere krav, mens ét krav kan kræve flere kontroller og registreringer.
Før evidens genbruges, skal dens scope, dato, systemversion og konklusion kontrolleres. En test af én modelkonfiguration kan ikke automatisk understøtte en anden konfiguration. En virksomhedspolitik beviser, at der findes en dokumenteret regel; der kræves driftsregistreringer for at påvise, at den udføres.
NIST-funktionerne giver en nyttig måde at organisere implementeringsspørgsmål på inden for AIMS'et. De bør resultere i konkrete artefakter og ikke kun i udfyldte felter i spørgeskemaer.
Definér, hvem der ejer systemet, hvem der uafhængigt gennemgår væsentlige risici, og hvem der kan godkende undtagelser eller stoppe idriftsættelsen. Specificér kompetencekrav og eskaleringsveje. Forbind disse ansvarsområder med eksisterende processer for sikkerhed, privatliv, indkøb og hændelseshåndtering.
En nyttig leverance er en releaseprocedure, der identificerer påkrævede gennemgående og påkrævet evidens. En risikoaccept bør navngive beslutningstageren, begrundelsen, betingelserne og udløseren for gennemgang i stedet for blot at registrere “accepteret”.
Dokumentér arbejdsgangen, før målinger vælges. Identificér, hvor AI påvirker beslutninger, hvem der oplever konsekvenserne, og hvad der sker, når output er forkert, utilgængeligt eller misbrugt.
Medtag forudsigeligt misbrug og fejl i afhængigheder. For en agent, der kan udføre handlinger, skal værktøjer, legitimationsoplysninger, tilgængelige data, godkendelsesgrænser og gendannelsesveje kortlægges. For AI fra tredjeparter skal det registreres, hvad leverandøren kontrollerer, og hvad der fortsat er jeres ansvar.
Vælg evalueringer, der er knyttet til identificerede risici. Afhængigt af use casen kan de omfatte nøjagtighed i opgaven, præstation i undergrupper, robusthed, læk af privat information, prompt injection, uautoriserede handlinger og operatørens forståelse.
Dokumentér datasættenes oprindelse, repræsentativitet, testbetingelser, målinger, begrænsninger og acceptgrænser. Mål hele applikationen, hvor det er muligt: retrieval, prompts, rettigheder, brugerflader og menneskelig arbejdsgang kan ændre resultaterne, selv når den underliggende model forbliver den samme.
Omsæt fund til sikkerhedsforanstaltninger, begrænsninger, afhjælpning eller en beslutning om ikke at idriftsætte. Eksempler omfatter at reducere værktøjsrettigheder, kræve godkendelse af handlinger med konsekvenser, udelukke ikke-understøttede anvendelser eller levere en pålidelig reserveløsning uden AI.
Fastsæt tærskler for overvågning og responsprocedurer. En måling uden en ejer eller en responsregel er kun telemetri. Registrér, hvilke hændelser der udløser en ny vurdering, herunder leverandøropdateringer, ændrede datakilder, udvidede anvendelser og hændelser.
Hvis certificering er et mål, skal AIMS'ets grænse defineres, før der forberedes til en ekstern audit. Scope kan dække et bestemt produkt, en forretningsenhed eller et sæt livscyklusaktiviteter, men det bør tydeligt beskrive de inkluderede aktiviteter og grænseflader. Et snævert scope må ikke præsenteres som sikkerhed for hele organisationen.
Gennemfør en gapanalyse op mod kravene til ledelsessystemet og de gældende kontroller. Fastlæg politik, mål, metoder til risiko- og konsekvensvurdering, dokumenteret anvendelighed af kontroller, ansvarsområder og driftsprocedurer. Generér derefter evidens for, at disse processer faktisk fungerer.
Nyttige registreringer omfatter gennemførte vurderinger, leverandørgennemgange, uddannelsesregistreringer, releasegodkendelser, overvågningsgennemgange, korrigerende handlinger, fund fra intern audit og beslutninger fra ledelsens evaluering. Intern audit og ledelsens evaluering er forskellige aktiviteter: den ene vurderer overensstemmelse og effektivitet; den anden understøtter ledelsens vurdering og styring af ledelsessystemet.
En uafhængig certificeringsproces omfatter ofte faser for vurdering af parathed og implementering. Aftal scope og auditordninger med certificeringsorganet i stedet for at behandle certificering som en indsendelse af papirer. Fortsæt overvågning, intern gennemgang og forbedring efter certificeringen.
Hverken et certifikat eller en RMF-vurdering erstatter en gældende overensstemmelsesvurdering efter AI-forordningen. Proceduren for overensstemmelse afhænger af systemet og de relevante bestemmelser; ikke alle højrisikosystemer kræver den samme tredjepartsprocedure. Krav til erklæring, registrering, mærkning og indberetning skal ligeledes kontrolleres for den relevante rolle og det relevante system.
Illustrative forudsætninger: en arbejdsgiver i EU køber en applikation, der rangerer ansøgere til gennemgang før samtaler. Leverandøren leverer applikationen, mens arbejdsgiveren konfigurerer jobkriterierne og bruger rangeringerne. Rekrutteringsmedarbejdere træffer de endelige ansættelsesbeslutninger. Antag, at den juridiske gennemgang identificerer en højrisikoanvendelse inden for beskæftigelse efter bilag III og i første omgang identificerer arbejdsgiveren som idriftsætter.
Det løses ikke ved at sige, at “et menneske træffer den endelige beslutning”. Rangering kan i væsentlig grad påvirke, hvem der bliver taget i betragtning. Vurderingen skal undersøge den faktiske arbejdsgang, herunder om rekrutteringsmedarbejderne rutinemæssigt ignorerer ansøgere under en grænseværdi.
Den tekniske ejer registrerer inputfelter, de oplysninger om rangeringslogikken, som leverandøren stiller til rådighed, applikationsversion, konfiguration, brugere og eksportdestinationer. Indkøb anmoder om leverandørens brugsanvisning, begrænsninger, relevant evalueringsevidens, underretning om ændringer og støtte til organisationens forpligtelser.
Den juridiske gennemgang dokumenterer antagelserne om klassificering og rolle, herunder om fremtidig ændring eller relancering under eget navn kan ændre rollen. Privatlivsgennemgangen vurderer separat behandlingen af ansøgerdata. AI-governance erstatter ikke databeskyttelsesanalysen.
Ved hjælp af NIST's Map- og Measure-funktioner evaluerer teamet repræsentative rekrutteringsscenarier, adfærd ved manglende data og præstationsforskelle på tværs af relevante grupper, hvor det er lovligt og muligt. Det dokumenterer usikkerhed og begrænsninger i stikprøverne i stedet for at præsentere en retfærdighedsmåling som bevis for, at al skadelig bias er forsvundet.
Menneskeligt tilsyn omfatter uddannelse af rekrutteringsmedarbejdere, synlige begrænsninger, en vej til at gennemgå frasorterede ansøgninger og mulighed for at suspendere rangeringen. Teamet tester, om de gennemgående forstår outputtet og kan tilsidesætte det uden driftsmæssige forhindringer.
Sikkerhedskontroller begrænser adgangen til ansøgerposter og forhindrer ikke-godkendte eksporter. Ændringsstyringen kræver en ny vurdering, når rangeringskriterier, modeller eller leverandørens behandlingsordninger ændres.
AIMS-registreringen viser, hvordan vurderinger, ejerskab, leverandørgennemgang og godkendelsesprocesser fungerede. RMF-registreringen forklarer de kontekstuelle risici, test, behandling og resterende usikkerhed. Den juridiske registrering identificerer gældende forpligtelser for idriftsætteren, tidsplanen og det udestående arbejde.
Antag, at leverandøren ikke har leveret tilstrækkelige anvisninger til et pålideligt tilsyn. Releaseregistreringen bør vise det hul, dets ejer og beslutningen om at udskyde eller begrænse idriftsættelsen, ikke en grøn status arvet fra arbejdsgiverens ISO-certifikat.
Prioritér gældende juridiske forpligtelser og uacceptable driftsrisici først. ISO-certificering kan foregå sideløbende med afhjælpning, men et auditmål bør ikke fortrænge presserende kontroller.
Hvis teams mangler ensartede processer for ejerskab og gennemgang, så byg fundamentet for AIMS'et. Hvis governance findes, men systemevalueringerne er svage, så brug RMF'en til at forbedre den kontekstuelle analyse og test. Hvis en kunde kræver certificering, så bekræft det forventede scope, før der budgetteres.
Undgå universelle antagelser om omkostninger eller varighed. Indsatsen afhænger af antallet af systemer, eksisterende governance, evalueringsbehov, indsigt i leverandørerne og afhjælpning. RMF'en er frit tilgængelig, men implementeringen kræver stadig medarbejdertid; ISO-certificering tilføjer overvejelser om adgang til standarden og ekstern vurdering.
Efter release skal udløsere for gennemgang knyttes til artefakterne. En opdatering af leverandørens model kan ugyldiggøre evalueringsresultater; en ny handlingsrettighed kan ændre trusselsmodellen; et nyt marked kan kræve en ny juridisk vurdering. Bevar tidligere versioner og beslutninger, så de gennemgående kan rekonstruere, hvad der blev godkendt på det pågældende tidspunkt.
Almindelige fejl omfatter at behandle mappinger som compliance, at indsamle politikker uden driftsevidens, at acceptere leverandørpåstande uden en analyse, der er specifik for idriftsættelsen, og at registrere restrisiko uden en beslutningsejer. En anden er at måle modelkvaliteten og samtidig ignorere applikationsrettigheder og menneskelig adfærd.
Secani kan understøtte evidensarbejdsgangen ved at forbinde krav, kontroller, kildemateriale, ejere, opgaver og gennemgåede beslutninger. Start med ét defineret scope, knyt evidens til det, den understøtter, og gør manglende eller forældet materiale til tildelt arbejde. Behandl AI-assisterede forslag som udkast: et menneske bør gennemgå mappinger og konklusioner, og kilder og begrundelser for godkendelse bør bevares. Det holder governancegrundlaget efterprøvbart uden at erstatte teknisk eller juridisk vurdering.
Ja, hvor deres implementering og evidens dækker AI-idriftsættelsen. Adgangskontrol, hændelsesrespons og leverandørstyring bidrager ofte. De besvarer ikke i sig selv spørgsmål om skadelig bias, tilsigtet formål eller effektivt menneskeligt tilsyn.
Registrér begrænsningen i indsigten. Søg evidens, der står i forhold til use casen, evaluér den idriftsatte applikation, og afgør, om kontraktmæssige forsikringer, begrænsninger eller alternative leverandører er nødvendige. Manglende indsigt er ikke automatisk acceptabel, fordi tjenesten er kommercielt tilgængelig.
Vælg én use case med konsekvenser, og saml dens ejer, formål, rollevurdering, risikoregistrering, sikkerhedsforanstaltninger, test og godkendelse. Gennemgå hullerne på tværs af alle tre instrumenter. Den afgrænsede øvelse afslører, om organisationen har brug for bedre governance, bedre teknisk evidens eller har uafklaret juridisk arbejde, før der udvides.
Secani forbinder scopes, dokumentation, opgaver og AI-agenter i ét fælles arbejdsområde.
En aktuel, rollebaseret tilgang til parathed over for AI-forordningen, herunder Kommissionens opdaterede tidsplan, vurdering af højrisiko og ansvarlig governance.
Et kildelink gør ikke en AI-vurdering pålidelig. Relationen mellem krav, evidens og vurdering skal kunne testes.
AI-native compliance betyder at importere eksisterende dokumentation, forstå konteksten, finde mangler, gennemgå output og bevare menneskelig kontrol, hvor vurderinger er afgørende.