En automatisk opdatering fra Statens IT gav ifølge Ingeniøren Microsoft Copilot adgang til Sundhedsdatastyrelsens Outlook-miljø. Den nye oplysning gør hændelsen mere præcis end den første omtale: Adgangen opstod ikke nødvendigvis, fordi en medarbejder ignorerede en regel. En ændring i den fælles it-drift kunne flytte grænsen, efter at organisationen mente, den var sat.
Det betyder, at ledelsens kontrol ikke kan slutte, når et AI-værktøj bliver godkendt eller slået fra. Den skal gentages, når leverandøren ændrer produktet, når en integration bliver opdateret, og når nye funktioner bliver koblet til mail, dokumenter eller drev.
Det ved vi, og det ved vi ikke
Ingeniøren beskrev 4. august, at en Microsoft-opdatering fra Statens IT i en periode gav Copilot adgang til Sundhedsdatastyrelsens Outlook-miljø. Mediet bygger historien på en aktindsigt hos Datatilsynet og kalder adgangen ulovlig. Computerworld har tidligere omtalt, at styrelsen anmeldte episoden til Datatilsynet.
Aktindsigten og den konkrete hændelsesrapport er ikke offentligt tilgængelige. ING og Version2 bringer samme journalistiske historie og udgør derfor ikke to uafhængige bekræftelser. De tilgængelige kilder dokumenterer heller ikke, hvilke konkrete oplysninger Copilot kunne nå, hvor længe adgangen bestod, eller om systemet læste, kopierede eller sendte noget til Microsoft.
Det er vigtigt at skelne mellem adgang og konstateret overførsel. Hændelsen dokumenterer efter mediernes oplysninger en forkert adgang. Den dokumenterer ikke et datalæk til leverandøren.
Ingeniøren citerer samtidig Allan Frank fra Datatilsynet for, at Statens IT kan slå indstillingen fra hos den enkelte myndighed, men at nye Microsoft-opdateringer kan koble Copilot til dele af Microsoft 365 igen. Hvis den beskrivelse er rigtig, er det ikke nok at kontrollere opsætningen én gang. Kontrollen skal følge ændringerne.
Produktet er kun den synlige del
Når en organisation godkender et AI-værktøj, er det let at tro, at den store beslutning er taget. Jura, informationssikkerhed og indkøb har vurderet leverandøren. Medarbejderne har fået regler for, hvilke oplysninger de må skrive i en prompt.
Men et moderne AI-værktøj kan få oplysninger på andre måder end gennem den tekst, en medarbejder selv indtaster. Det kan være koblet til mail, dokumenter, drev, kalender eller en samarbejdsplatform. Det kan arve rettigheder fra en bruger, en gruppe eller en teknisk konto. En integration eller en ny standardindstilling kan udvide det, systemet kan se.
Den relevante kontrol er derfor mere konkret end spørgsmålet: “Har vi godkendt AI?”
En ansvarlig leder bør kunne få svar på:
- Hvilke datakilder kan værktøjet nå lige nu?
- Hvilken identitet og hvilke grupper giver det adgangen?
- Er adgangen begrænset til det arbejde, værktøjet faktisk skal udføre?
- Hvem godkender en udvidelse, og hvem kontrollerer bagefter, at den blev som aftalt?
- Kan vi se i loggen, når værktøjet søger i eller henter interne oplysninger?
- Hvem lukker adgangen, hvis noget ser forkert ud?
Det er almindelig adgangsstyring. AI gør konsekvensen større, fordi værktøjet kan finde, kombinere og opsummere store mængder information langt hurtigere end en medarbejder, der klikker sig gennem mapper.
En instruks kan ikke rette en teknisk adgang
Datatilsynet har tidligere advaret om brud, hvor ansatte lagde personoplysninger ind i generative AI-værktøjer uden arbejdspladsens viden eller tilladelse. Her er træning, klare procedurer og eventuel teknisk blokering relevante svar.
Sagen hos Sundhedsdatastyrelsen peger på en anden situation. Hvis et værktøj allerede har teknisk adgang til interne data, kan medarbejderen undlade at skrive én eneste følsom oplysning og stadig arbejde i en opsætning med for brede rettigheder.
Ingeniøren citerer Allan Frank for, at en instruks mod at bruge Copilot til sagsbehandling ikke er tilstrækkelig, hvis produktet er installeret på den computer og det netværk, hvor arbejdet foregår. Organisationen bør også overveje tekniske foranstaltninger.
Kompetence er fortsat nødvendig. Medarbejderen skal forstå, hvad værktøjet gør, og hvornår en opgave kræver særlig forsigtighed. Men vedkommende kan ikke forventes at gennemskue gruppemedlemskaber, integrationer og adgangspolitikker bag en knap i et kontorprogram.
Ansvaret ligger derfor også hos dem, der stiller arbejdspladsen til rådighed: ledelsen, systemejerne, it-driften, sikkerhedsfunktionen og leverandørstyringen. Rollefordelingen skal være konkret nok til, at en forkert adgang ikke ender mellem fem afdelinger, der hver især troede, at en anden kontrollerede den.
Adgang skal følge arbejdet
Jeg arbejder selv med digitale kolleger, som har forskellige roller og adgange. Den praktiske regel er, at en rolle ikke skal kunne se alt det, der måske bliver nyttigt en dag. Den skal kunne se det, der er nødvendigt for det arbejde, den ejer nu.
En researcher behøver kilder, men ikke nødvendigvis kundemail. En kollega, der følger en salgsproces, behøver relevante kontakter og aftaler, men ikke adgang til alle virksomhedens dokumenter. Når grupper ikke bør dele information, bør de heller ikke dele én samlet hukommelse eller en identitet med brede rettigheder.
Den opdeling koster lidt mere at sætte op. Til gengæld bliver det muligt at forstå en hændelse: Hvilken rolle havde adgang? Hvorfor havde den det? Hvilken opgave blev udført? Hvad kan afgrænses uden at lukke alt andet arbejde?
NISTs ramme for AI-risikostyring behandler styring som løbende arbejde med ansvar, dokumentation, måling og monitorering. OWASP fremhæver blandt andet følsom informationsafsløring, leverandørkæder og for stor handlekraft som generelle risici i LLM-applikationer. Ingen af rammerne afgør den konkrete Sundhedsdatastyrelsen-sag. De understøtter den bredere driftsopgave: adgang, integrationer og overvågning skal vedligeholdes over tid.
En brugbar rytme kan være enkel:
- Beskriv det konkrete arbejde og de nødvendige datakilder.
- Giv den mindst mulige adgang, der stadig gør arbejdet muligt.
- Test med data og identiteter, der svarer til den virkelige opsætning.
- Log adgang og ændringer, så de kan undersøges.
- Kontroller rettigheder igen efter større leverandøropdateringer, nye integrationer og modelskift.
- Navngiv den person, der kan stoppe adgangen med det samme.
Den gamle godkendelse gælder ikke automatisk den nye opsætning
En leverandøropdatering er ikke i sig selv et problem. Opdateringer lukker sikkerhedshuller, forbedrer funktioner og kan gøre et system nemmere at drive. Alternativet kan være et forældet og dårligere sikret miljø.
Problemet opstår, hvis organisationen behandler en ændret opsætning som den samme opsætning. En tidligere godkendelse fortæller kun, hvad der blev vurderet på det tidspunkt. Hvis en opdatering ændrer integrationer, identiteter eller datakilder, skal den del af vurderingen åbnes igen.
Det er den praktiske forskel mellem at have godkendt et produkt og at have styr på dets adgang efter næste opdatering.