En AI-konsekvensvurdering er ikke længere en rapport, man skriver én
En AI-konsekvensvurdering er ikke længere en rapport, man skriver én gang inden lancering og lægger i en skuffe. Med ISO/IEC 42005:2025 får vurderingen en defineret plads i hele livscyklussen for et AI-system, og AWS er begyndt at positionere sine værktøjer som en vej til at leve op til den.
Hvad standarden kræver af en konsekvensvurdering
ISO/IEC 42005:2025 handler om at vurdere, hvordan et AI-system påvirker mennesker, grupper og samfund. Den fastlægger bedste praksis for at gennemføre og dokumentere sådanne vurderinger, og den gør dem til en del af virksomhedens samlede risikostyring. Det er en vigtig forskel, fordi mange interne risikovurderinger stopper ved spørgsmålet om, hvad der kan gå galt for organisationen selv.
Sådan læser jeg det: En god vurdering beskriver formålet med systemet, hvilke data det bruger, hvem der berøres, og hvilke skader eller fordele der er sandsynlige. Og den bliver ikke færdig. En ny model, en ny datakilde eller en udvidet brugergruppe er efter min mening alle grunde til at tage den op igen.
Sådan kobler AWS-værktøjerne sig til standarden
AWS beskriver, at kunder kan bruge AWS-værktøjer til at tilpasse sig standarden. Det lyder rimeligt, og jeg kan se, hvorfor det giver mening. Et værktøj kan i bedste fald give overblik, spor og kontroller, som en vurdering kan bygge på.
Et værktøj opfylder dog ikke en standard. Det leverer materiale, som en organisation selv skal vurdere og tage ansvar for. At afgøre, hvem der kan blive skadet, og om en risiko er acceptabel, kan ingen cloud-platform tage over. Jeg læser derfor AWS' positionering som en måde at samle bevismaterialet på, ikke som en genvej til at slippe for selve vurderingen.
Fra enkeltstående rapport til fast del af livscyklussen
Den praktiske konsekvens er rytmen. En konsekvensvurdering hænger sammen med de punkter, hvor et AI-system ændrer karakter, og ikke med en enkelt dato. For et system bygget på en foundation-model kan et modelskifte hos leverandøren i princippet være nok til, at vurderingen skal tages op igen.
Det er her, jeg tror mange vil støde ind i virkeligheden. Er vurderingen et Word-dokument, bliver den forældet i samme øjeblik, systemet ændres, og ingen opdager det. Er den knyttet til konfigurationen, kan en ændring i model, rettigheder eller datakilder markere, at den skal gennemgås igen. Det er den tankegang, jeg selv ville bygge efter.
Dokumentation, der kan stå distancen over for risikostyring
En god konsekvensvurdering kan bruges af flere funktioner på én gang. Risikostyring skal kunne se, hvilke risici der er identificeret, og hvem der ejer dem. Jura og databeskyttelse skal kunne genbruge afsnittene om personoplysninger og berørte grupper. Ledelsen skal kunne se, hvilke restrisici man har valgt at acceptere.
Det stiller krav til indholdet. Formuleringer som systemet er sikkert holder ikke. Dokumentationen skal pege på konkrete kontroller, konkrete tests og konkrete ansvarlige. Hvis jeg ikke kan få vist et spor af, hvad en agent har gjort, har jeg ikke en medarbejder, men en risiko med pæn indpakning. Det gælder også for en vurdering: Uden teknisk forankring er den et dokument, ikke en kontrol.
Det betyder det for danske virksomheder med agenter i drift
For danske virksomheder er pointen, at en konsekvensvurdering giver et fælles format for noget af det arbejde, man alligevel bør have styr på. Hvordan det spiller sammen med EU's AI-forordning, må man afklare for sit eget system. Det kan jeg ikke svare på generelt. Til gengæld er et fast format nyttigt som fælles sprog mellem IT, jura og ledelse.
Når jeg bygger og driver agenter, er det grænsen, der er det svære, ikke selve agenten. Hvad må den røre? Det er det første spørgsmål. Bagefter kommer det ubehagelige: Hvad sker der, når den tager fejl, og hvem opdager det? Det er præcis de spørgsmål, en konsekvensvurdering tvinger frem, og de er nemmere at besvare, før systemet kører, end bagefter.