Af Kasper Ravn Breindal
Dine proxylogs CASB logs viser trafik til AI-tjenester, du aldrig har godkendt. En medarbejder tester et browser-plugin. En udvikler bruger en ny, smart kodeagent. En specialist uploader et kundedokument til en gratis chatbot.
Det ligner og føles som øget produktivitet, og det er det nok også, men måske er det i virkeligheden eksponering af fortrolig data?
Denne artikel skulle egentlig have handlet om håndgribelige værktøjer til at bekæmpe cyberangreb (fx loganalyse i SIEM-systemer). Men med de seneste måneders udvikling inden for AI er der noget andet, der fylder mere lige nu. Nemlig hvordan vi håndterer “Shadow AI”.
Men netop fordi det som sådan ikke er noget nyt kan vi heldigvis også bruge en masse af den viden og erfaring vi har fra ”gammeldagsalmindelig” skygge-it. Og her gælder det helt grundlæggende, at du ikke kan styre risikoen, hvis du ikke kan følge med i brugen af teknologierne.
Begrebet “Shadow AI” dækker over, at medarbejdere tager AI-værktøjer i brug på egen hånd uden om de officielle kanaler, og på den måde åbner bagdøren for datalæk, compliance-brud eller et cyberangreb.
Men er det noget nyt? Set med mine it-sikkerhedsbriller er “Shadow AI”, et klassisk sikkerhedsproblem i en ny form. Men udviklingen går alarmerende hurtig og governance har simpelthen svært ved at følge med behovet i forretningen.
Men netop fordi det som sådan ikke er noget nyt kan vi heldigvis også bruge en masse af den viden og erfaring vi har fra ”gammeldagsalmindelig” skygge-it. Og her gælder det helt grundlæggende, at du ikke kan styre risikoen, hvis du ikke kan følge med i brugen af teknologierne. Og hvis du kun svarer med blokeringer, flytter brugen sig bare.
Derfor plejer jeg at rådgiver jeg mine kunder til at få tre ting på plads, som det første:
- Skab teknisk synlighed på tværs af netværk, endpoints, SaaS og identiteter
- Knyt AI-brug til data, roller og forretningskontekst
- Bliv enige om en beslutningsmodel for blokering, begrænsning eller kontrolleret onboarding
Lad os se lidt på, hvad det kan betyde i praksis.
Skab teknisk synlighed
Start med de kontroller, du allerede har. Shadow AI kræver sjældent et helt nyt sikkerhedsprogram – det kræver, at du bruger din eksisterende telemetriy bedre.
Typisk arbejder jeg og mine kolleger i VENZO i fire spor.
Først trafik. CASB, SSE, Secure Web Gateway, DNS, proxy og firewall kan afsløre kald til kendte AI-domæner og API-endpoints. Mange platforme har allerede kategorier for generative AI-applikationer. Brug dem aktivt. Ikke kun til blokering, men også til discovery.
Dernæst identitet. IdP-logs viser, hvem der logger ind hvor. OAuth-consent viser, hvilke apps der har fået adgang. Det er ofte her, de stille problemer dukker op: små SaaS-værktøjer, AI-plugins og private konti brugt til arbejdsdata.
Tredje spor er endpoints. EDR og MDM kan vise installerede klienter, browserudvidelser og lokale modeller. Det er vigtigt, fordi ikke al AI-brug går gennem tydelige webdomæner.
Fjerde spor er data. DLP og dataklassifikation skal kobles på AI-trafikken. Ellers ved du kun, at nogen bruger et værktøj, men ikke hvad de sender derhen.
Mange organisationer stopper ved applikationsnavnet, men dette er ikke nok. ChatGPT, Claude eller en ukendt SaaS-AI er tkun den halve historie – den anden finder vi ved at afdække hvem, hvad og hvorfor – altså hvem bruger applikationen, hvilken data har de smidt ind i den, og med hvilket formål.
Knyt AI-brug til data, roller og forretningskontekst
Når du har fundet brugen, skal den ikke bare ende i et regneark, men skal selvfølgelig forankres ind i en governancemodel.
Jeg anbefaler mine kunder et centralt AI-katalog, der viser observerede værktøjer, datatyper, kapabiliteter, brugergrupper, risikoniveau og beslutning, for eksempel blokeret, begrænset, under vurdering eller onboardet som godkendt løsning.
Derudover skal risikovurderingen være konkret. Hvor lagres data? Bruges input til træning? Er der databehandleraftale? Hvilken jurisdiktion gælder? Kan logs eksporteres? Kan adgang styres centralt? Kan kapabilitieter scopes ned?
Det er her, governance, security og compliance mødes. GDPR kræver styr på persondata. NIS2 øger presset på risikostyring og dokumentation. EU AI Act skubber yderligere på behovet for overblik. Du skal kunne forklare, hvad der bruges, af hvem, til hvad og med hvilke kontroller.
Compliance bliver ofte involveret for sent og det skaber unødvendige hovedbrud, hvis (eller rettere når) AI bliver brugt til noget det ikke skal bruges til.
Bliv enige om en beslutningsmodel
Nu kommer den svære del, nemlig at handle på det, I har fundet.
Kort sagt; vinder ingen på at lade stå til, men man vinder heller ikke på at blokere alt. Den rigtige vej ligger et eller andet sted i midten, hvor I beslutter, hvad der skal blokeres, hvad der kan rummes med begrænsninger, og hvad der bør integreres sikkert i platformen.
Tænk i tre enkle kategorier: blokér, begræns eller onboard.
- Bloker, når risikoen er klart for høj eller værdien for lav. Eksempel: en gratis AI-tjeneste uden kontroller, hvor fortrolige data nemt kan lække – den hører til i den røde kategori.
- Begræns, når et værktøj giver reel nytte, men kun er forsvarligt med skarpe rammer. For eksempel kan udviklere få lov at bruge en AI-kodeagentassistent – men kun på ufølsom kode, og aldrig på kundedata. Dette hører i en gul kategori.
- Onboard (integrér), når et skyggeværktøj er blevet uundværligt og kan bringes under fuld kontrol. Så giver det mening at gøre det til en officiel, kontrolleret del af jeres setup – fx via en enterprise-version eller en intern implementering. Dette er en grøn kategori.
I praksis kræver det en beslutningsproces, der både er hurtig og konsistent. Ideelt har I et lille tværgående team eller AI Governance Board som løbende vurderer nye AI-fund og hurtigt kan afgøre, hvilken kategorier værktøjerne.
Når I først har defineret, hvad der skal blokeres, begrænses eller onboardes, så husk at melde det klart ud. Medarbejderne skal vide, hvad de må bruge. Derudover skal de selvfølgelig også vide, hvilke typer data de aldrig må komme i eksterne AI-værktøjer, hvilke værktøjer der er okay at eksperimentere med – og hvilke, der er totalt no go. Husk især også at fortælle, hvad man gør, hvis man allerede har taget noget fy-fy uden for skiven i brug!
Næste skridt: 30 dages discovery
Ligesom skygge-it er et gammelt fænomenfænomen, kommer Shadow AI heller ikke til at forsvinde. Tværtimod bliver det sværere og sværere at håndtere efterhånden som der kommer flere og flere værktøjer, anvendelsesmuligheder og ønsker fra medarbejderne.
Og som nævnt reducerer I ikke risikoen ved kun at forbyde. I reducerer den ved at skabe synlighed, koble brugen til data og ved at være gode (og hurtige) til at træffe beslutninger om AI.
Og hvad så nu, spørger du?
Ovenstående kommer forhåbentlig ikke som lyn fra en klar himmel. Så et realistisk næste skridt kunne være at gennemføre en 30 dages discovery på jeres AI-trafik, OAuth-apps, browserudvidelser og DLP-hændelserved at bruge de datakilder i har tilgængelige. Byg derefter første version af dit AI-katalog, sørg for at I har et AI Governance Board af en art – og tag aktiv stilling til, hvad du vil blokere, begrænse eller bringe ud af skyggen og frem i lyset.
