Løsning
En regulering gælder nu for os
AI-forordningen i praksis
De fleste organisationer møder AI-forordningen som anvender frem for som udbyder: de bruger AI-systemer, andre har bygget, inde i processer de selv ejer. Den skelnen betyder noget, for de forpligtelser der lander på en anvender er snævrere end dem overskrifterne beskriver, og næsten alle afgøres af, hvordan systemet er bygget og drevet.
Arbejdet er sjældent en juridisk øvelse. At vide hvilke systemer der er i brug og i hvilken risikoklasse, at gøre det menneskelige tilsyn reelt frem for nominelt, at logge hvad systemet gjorde, og at kunne fremvise det: det er egenskaber ved en arkitektur. Et politikdokument kan påstå dem. Kun systemet kan holde dem.
I er formentlig her, fordi
- Nogen har spurgt, hvilke AI-systemer I bruger, og listen tog længere tid at lave end forventet.
- En leverandør har oplyst, at deres system er compliant, og det er uklart, hvad det efterlader jer ansvarlige for.
- Menneskeligt tilsyn findes på papiret, men den person der er udpeget til det, har ingen praktisk mulighed for at gribe ind.
- Et udbud eller et kundespørgeskema beder om dokumentation, I ikke producerer i dag.
Hvad der løser det
En oversigt, der bliver ved med at være aktuel
Hvilke AI-systemer der er i brug, hvem der ejer hvert enkelt, hvad det beslutter eller assisterer med, og hvilken risikoklasse det falder i. Udledt af, hvordan systemer registreres, frem for af en rundspørge der er forældet ugen efter.
Menneskeligt tilsyn, der faktisk kan gribe ind
Tilsyn er først reelt, når den der kontrollerer, ser beslutningen inden den får virkning, har konteksten til at bedømme den og kan standse den. Det er en arkitektonisk egenskab: hvor kontrolpunktet ligger, og hvad systemet gør, mens det venter.
Logning, der kan besvare spørgsmålet bagefter
Hvad systemet fik, hvad det producerede, hvilken version af model og prompt, og hvad der fulgte. Registreret i det øjeblik det sker, fordi det ikke kan rekonstrueres bagefter med nogen form for redelighed.
Åbenhed over for de berørte
Hvor en person interagerer med et AI-system, eller en afgørelse om vedkommende er understøttet af et, skal det fremgå i brugerfladen frem for i en politik, ingen åbner.
Dokumentation, en myndighed kan få fremvist
Dokumentationsforpligtelserne indfriet som et biprodukt af at drive systemet frem for som et projekt, der starter, når nogen spørger.
Start med kortlægningen, og tag så det mest risikofyldte system på listen. Tilsyn og logning er den dyre del, og de tager præcis så lang tid, som det tager at ændre de systemer.
sådan bliver det leveret
Kompetencer, cases og videre læsning
Leveres gennem
- Operationel AI
AI-systemer, der spiller sammen med eksisterende platforme og arbejdsgange, med kontrol, sporbarhed og driftssikkerhed.
Hvor vi har gjort det
- Decision Architecture
A decision-system redesign that embeds AI assistance while preserving accountability and control.
- AI Operating Model
A practical operating model that aligns leadership governance with implementation teams and measurable outcomes.
- Sovereign AI Gateway
A unified gateway that centralizes model routing, policy enforcement, and auditability.
Videre læsning
- The EU AI Act: what it asks of deployers
Most organizations buying or building on AI are deployers rather than providers. That distinction decides which obligations land on you, and most of them are architectural.
faq
Frequently asked questions
- Er vi udbyder eller anvender efter AI-forordningen?
- De fleste organisationer, der bruger AI i deres egne processer, er anvendere: en anden har bygget systemet og bragt det på markedet, og I tager det i brug. Skelnen betyder noget, fordi en anvenders forpligtelser er betydeligt snævrere. Den kan dog rykke sig, særligt hvis I ændrer et system væsentligt eller sætter jeres eget navn på det, og det er værd at få afklaret tidligt frem for at antage.
- Gælder forpligtelserne også de systemer, vi allerede driver?
- Som udgangspunkt ja, og det er den del, organisationer undervurderer. Det handler ikke kun om, hvad I anskaffer næste gang; det omfatter det, der allerede er i produktion, og det er som regel dér, kortlægningen viser sig at være større end forventet.
- Vores leverandør siger, at produktet er compliant. Er det nok?
- Det afklarer deres forpligtelser, ikke jeres. Et compliant system, der bruges uden reelt tilsyn, uden logning hos jer, eller uden for det formål det er vurderet til, gør ikke anvendelsen compliant. Ansvarsfordelingen er værd at skrive eksplicit ned, både i kontrakten og i arkitekturen.
- Hvordan afgør vi, hvilken risikoklasse et system falder i?
- Klassificeringen følger af, hvad systemet bruges til, ikke af hvordan det er bygget, så den samme underliggende teknologi kan lande i forskellige klasser i to forskellige processer. Det gør det til en vurdering af jeres egen anvendelse, med en navngiven ejer og en nedskrevet begrundelse, frem for noget en leverandør kan svare på jeres vegne. Er en sag reelt i gråzonen, er det værd at få juridisk rådgivning om den konkrete anvendelse frem for om teknologien.
- Hvor lang tid tager det?
- Kortlægningen og risikoklassificeringen tager som regel uger frem for måneder. At gøre tilsyn og logning reelt i systemer, der ikke er bygget til det, tager så lang tid, som det tager at ændre de systemer, og derfor er det normalt rigtigst at starte fra den mest risikofyldte anvendelse frem for fra hele porteføljen.