Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
Vi har set det før: At en teknologi bliver adopteret af brugere før it-afdelingens godkendelse.
Dropbox, Google Docs og Slack blev en del af hverdagen, længe før der fandtes klare politikker for brugen.
Dengang førte det til datalæk, overtrædelser af compliance-krav og et væld af uautoriserede integrationer. Nu sker det igen med AI.
Forskellen er, at en fejl i dag ikke blot betyder et dokument på afveje — den kan resultere i læk af proprietær kildekode, interne API-specifikationer, credentials eller hele arkitekturdiagrammer.
Problemet er, at man sjældent ved, hvor data ender, når de sendes til gratisversioner af AI-tjenester. For en udvikler kan det være fristende at smide en bug report, et stack trace eller en konfigurationsfil ind i en chatbot for at få hurtig hjælp — men i samme øjeblik mister man kontrollen.
Mange AI-udbydere gemmer input for at forbedre deres modeller, og selvom det kan lyde uskyldigt, kan det betyde, at din internal_payment_service.py eller docker-compose.yml bliver en del af en global træningsdatabase.
Derfor er du nødt til at ride med på AI-bølgen – uanset om du synes vibe coding er cool eller ej.
GDPR og NIS2 – uhyggelige konsekvenser
Vi går lige et skridt tilbage: Ingen af dine ansatte eller udviklere har intention om at dele data med ukendte kilder, men begrænsninger i et potentielt mere effektivt arbejdsflow ”tvinger” dem til at bruge platforme, som som udgangspunkt ikke er sikre – hvis ikke de tilbydes af virksomheden og i de rette rammer.
Vi så præcis det samme ske i kommuner på tværs af Norden, hvor personkritisk data blev delt via dropbox-mapper, fordi kommunens it-system simpelthen var for langsomt at arbejde i.
Det er et kæmpe problem, når det kommer til regulativer som GDPR og NIS2 – og det bliver ukontrolleret AI-brug også.
For udviklere handler det ikke kun om jura, men om at forstå de praktiske implikationer: Hvor befinder data sig fysisk? Bliver der logget, hvem der har sendt hvad? Og sender vi overhovedet mere information, end der er nødvendigt?
Manglende svar på disse spørgsmål kan ikke alene medføre lovbrud og store bøder, men også tab af forretningshemmeligheder og tillid fra kunder.
Huller i osten – øhm.. koden
Risikoen ligger ikke kun i datadeling.
Utrænet og uovervåget brug af AI kan også føre til lavkvalitets output, der i værste fald introducerer sikkerhedshuller i kodebasen.
Hallucineret kode kan se korrekt ud og fungere i udviklingsmiljøet, men bryde i produktion eller skabe kritiske sårbarheder — alt fra SQL injections til usikre API-kald.
Forståelsen af modellens begrænsninger er derfor afgørende, både for at undgå at implementere fejlbehæftede løsninger og for at undgå licensproblemer eller brud på arkitekturprincipper.
Og ved man ikke, at der bliver brugt AI i udvikling, ja så er det svært at finde AI-inspirerede fejl.
Det betyder, at ledelsen og udviklerne sammen skal tage ansvar for at definere klare rammer for AI-brugen.
Det handler ikke om at kvæle innovation, men om at skabe et miljø, hvor værktøjerne bruges sikkert. Enterprise-konti hos AI-udbydere kan give bedre databeskyttelse, mulighed for at deaktivere træning og adgang til private endpoints.
Samtidig bør udviklere forstå, hvilke typer data der aldrig må forlade organisationens grænser — og hvordan man teknisk sikrer, at det ikke sker.
Skygge-AI er ikke et teoretisk problem, men et praktisk og akut et af slagsen. Det er et spørgsmål om, hvornår det rammer — ikke om det rammer.
Forskellen på at have styr på det eller stå midt i en sikkerhedsskandale afhænger af, hvor hurtigt organisationen får styr på datastrømme, tekniske værktøjer og udviklernes arbejdsrutiner.
Hvis ikke, risikerer vi, at den næste store sikkerhedshændelse starter med et uskyldigt prompt-vindue — og først bliver opdaget, når skaden er sket.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.