No products added!
Når en LLM-løsning skal i drift, er det sjældent modellen alene, der skaber den største risiko. Det er dataflowet omkring den, adgangen til den og de leverandører, der bliver en del af kæden. Uden et klart billede af disse tre områder kan selv en teknisk stærk løsning ende med uklare ansvarslinjer, svag dokumentation og unødig eksponering af data.
Et målrettet sikkerheds- og compliance assessment giver et beslutningsgrundlag, før løsningen møder rigtige brugere, rigtige dokumenter og rigtige forretningsprocesser. Det skaber ro i ledelsen, retning for IT og et stærkere grundlag for dialog med jura, indkøb og informationssikkerhed.
Hvor et assessment skaber værdi
Mange organisationer starter med et konkret behov: intern videnssøgning, kundeservice, sagsstøtte, dokumentanalyse eller copilot-funktioner i hverdagen. LLM-løsningen virker lovende, men det afgørende spørgsmål er ikke kun, om den kan bruges. Spørgsmålet er, om den kan bruges ansvarligt.
Det kræver, at man kortlægger hele bevægelsen fra input til output. Hvilke data kommer ind i prompts? Hvilke dokumenter bliver indekseret i en RAG-løsning? Hvem har adgang til logs, træningsmiljøer og administrative funktioner? Og hvad sker der hos den eksterne modelleverandør?
Typisk bør et assessment afdække:
- Prompt-input og filuploads
- Datakilder, indeks og vektorlagre
- Roller, rettigheder og servicekonti
- Logning, retention og revisionsspor
- Underdatabehandlere og leverandørkæde
Datakortlægning fra kilde til output
En LLM-løsning består næsten altid af mere end selve modellen. Der er integrationslag, API-kald, lagring, observability, identitetsstyring og ofte eksterne tjenester. Datakortlægning handler om at gøre dette synligt, så organisationen kan se, hvilke oplysninger der behandles, hvor de ligger, og hvem der kan tilgå dem.
I praksis begynder arbejdet med at identificere alle inputkilder. Det kan være brugerprompts, PDF-filer, CRM-data, intranetindhold, sagsmapper, HR-dokumenter eller indhold fra tredjeparts-API’er. Derefter kortlægges processeringspunkter og outputkanaler: embeddings, cache-lag, logs, dashboards, tickets, e-mails eller videre systemintegrationer. Når det er gjort ordentligt, bliver dataflowet ikke et pænt diagram til mødelokalet, men et arbejdsredskab til risikostyring.
For persondata er dette tæt knyttet til GDPR. Register over behandlingsaktiviteter, dataminimering og privacy by design kræver, at man kan forklare behandlingen hele vejen gennem løsningen. Det gælder også, når data passerer gennem en modeludbyder eller indgår i logs, hvor mange organisationer overser både følsomhed og opbevaringsperiode.
Det gode setup er levende, ikke statisk.
Moderne værktøjer til metadata, lineage og MLOps kan støtte dette arbejde, men teknologien løser ikke opgaven alene. Der skal også være ejerskab, versionering og rutiner for at opdatere kortlægningen, når nye datakilder, agenter eller workflows bliver koblet på. Netop LLM-miljøer ændrer sig hurtigt, og et kort, der ikke vedligeholdes, mister værdi meget hurtigt.
Adgangskontrol skal følge konteksten
Adgang i LLM-løsninger er mere nuanceret end klassisk systemadgang. En bruger kan måske gerne stille spørgsmål til en model, men ikke få adgang til kildedokumenterne bag svarene. En udvikler kan have adgang til testmiljøet, men ikke til produktionslogs med følsomme prompts. En servicekonto kan kalde modellen, men ikke ændre dens policy eller modelkonfiguration.
Det er her, adgangsmodellen skal matche virkeligheden. Mange begynder med rollebaseret adgang, fordi det er let at forklare og let at dokumentere. Når løsningen vokser, opstår der ofte behov for kontekstbaserede regler, hvor tid, netværk, dataklassifikation eller enhedens sikkerhedsniveau også skal tælle med.
| Model | Styrke | Begrænsning | God anvendelse i LLM |
|---|---|---|---|
| RBAC | Enkel og auditvenlig | Bliver hurtigt grovkornet | Basale roller i drift og administration |
| ABAC | Fleksibel og kontekstfølsom | Sværere at styre over tid | Adgang efter afdeling, enhed, lokation eller dataklasse |
| PBAC | Politikker kan versioneres og testes centralt | Kræver moden styring | Større miljøer med mange undtagelser og klare governancekrav |
Et stærkt assessment ser ikke kun på, hvem der har adgang nu. Det ser på, hvordan adgang gives, ændres, tilbagekaldes og dokumenteres. Der ses også på API-autentificering, token-håndtering, MFA på administrationsflader, least privilege og adskillelse mellem menneskelige brugere og ikke-menneskelige identiteter.
Efter en gennemgang er det ofte tydeligt, hvor kontrolniveauet skal skærpes:
- Menneskelige brugere: MFA, rolleopdeling og løbende adgangsreview
- Servicekonti: Kortlivede tokens, nøgle-rotation og præcise scopes
- Trænings- og udviklingsmiljøer: Strammere isolation end i almindelige appmiljøer
- Output og logs: Beskyttelse mod utilsigtet lagring af persondata og fortrolige oplysninger
Leverandørrisiko starter før indkøbet
En stor del af LLM-risikoen ligger uden for egen infrastruktur. Det gælder modeludbydere, hostingpartnere, embeddings-tjenester, observability-værktøjer og underdatabehandlere. Hvis en ekstern part modtager prompts, dokumenter eller metadata, skal det vurderes med samme alvor som andre kritiske databehandlere.
Et solidt assessment ser derfor både på sikkerhed og kontrakt. Hvor behandles data geografisk? Må leverandøren bruge kundedata til at træne egne modeller? Hvilke underleverandører indgår? Findes der logning, revisionsspor, sikkerhedscertificeringer og klare processer ved brud? Hvis svarene er uklare, bliver risikoen sjældent mindre af at gå i drift hurtigt.
Det er også vigtigt at vurdere leverandørens tekniske modenhed. Dokumentation om dataproveniens, modelkort, test mod prompt injection, beredskab ved hændelser og styring af modelopdateringer er væsentlige punkter. En leverandør kan være stærk på funktionalitet og stadig være utilstrækkelig på styring.
Kontrakterne skal kunne bære driften. Databehandleraftale, slettefrister, krav til brudvarsling, auditret og klare begrænsninger for genbrug af data er ikke formaliteter. De er styringsværktøjer.
Kravbildet i Danmark og Norden
For danske og nordiske organisationer er kravene sjældent begrænset til almindelig informationssikkerhed. GDPR er et fast udgangspunkt, men mange miljøer skal også forholde sig til ISO 27001, ISO 27701, NIS2 og de voksende krav omkring AI governance. For nogle organisationer vil også AI-forordningen få direkte betydning for dokumentation, risikovurdering, logging og intern kontrol.
Det nordiske marked stiller samtidig høje forventninger til gennemsigtighed. Tillid er en styrke, men også en forpligtelse. Når medarbejdere, kunder og borgere møder AI i en service eller beslutningsproces, forventes det, at organisationen kan forklare, hvilke data der bruges, hvordan adgang styres, og hvilke værn der er etableret.
Derfor er dokumentation ikke et bilag bagerst i projektmappen. Det er en aktiv del af selve løsningen.
Et stærkt assessment omsætter regler og standarder til praktiske kontroller. Ikke som teori, men som konkrete beslutninger om dataminimering, logning, opbevaring, identitetsstyring, leverandørvalg og ansvar.
Hvad organisationen står med bagefter
Et godt forløb ender ikke med en generel risikoliste. Det skal munde ud i en prioriteret plan, som både ledelse og fagteams kan arbejde videre med. Organisationen bør stå med et opdateret overblik over dataflow, en vurdering af adgangsmodellen, en leverandøranalyse og en tydelig liste over de kontroller, der skal på plads før drift.
I mange tilfælde giver det også mening at koble assessmentet sammen med intern kompetenceudvikling. Når medarbejdere i IT, HR, jura, marketing eller projektledelse arbejder med de samme cases og de samme kontroller, bliver governance lettere at fastholde i praksis. Her giver praksisnære, AI-integrerede læringsforløb særlig værdi, fordi dokumentation, risikoforståelse og ansvarlig anvendelse bliver en del af hverdagen og ikke kun et punkt i projektstarten.
Det gælder især i organisationer, hvor LLM-brug vokser hurtigt, og hvor flere teams får adgang til værktøjer, agenter og automatisering på samme tid.
Nordisk Business Academy arbejder netop med denne type praksisnær kompetenceudvikling, hvor ansvarlig brug af AI kobles tæt til virkelige arbejdssituationer, opdaterede materialer og et tydeligt fokus på anvendelse. Det gør det lettere at flytte fra usikker afprøvning til kontrolleret drift med dokumentation, som faktisk kan bruges.
