Danske virksomheder ruller AI ud i et tempo, hvor sikkerheden ærligt talt ofte halter bagefter. Det er ikke sagt for at være dramatisk. Det er bare det, vi ser. En intern chatbot starter som en ufarlig pilot i support eller HR, og pludselig ligger den tæt på kontrakter, persondata, kode eller kundedokumenter. Så er vi et andet sted end en smart demo.

Det er også hovedpointen i en ny gennemgang af fem best practices til at sikre AI-systemer. AI skaber en ny angrebsflade, som traditionelle sikkerhedsrammer ikke var bygget til at håndtere. Den pointe går igen på tværs af kilderne her, og den er vigtig, fordi mange stadig behandler AI som et ekstra lag oven på eksisterende it i stedet for som noget, der ændrer selve trusselsbilledet.

AI opfører sig ikke som almindelig software

Problemet er ikke kun, at en model kan lave fejl. Problemet er, at et AI-system både tager input ind, bruger data, genererer svar, træffer små valg og i nogle tilfælde kalder andre værktøjer. Det gør angrebsfladen bredere. Og mere sær. Prompt injection, dataekstraktion, misbrug af agenters værktøjskald og risici i model-forsyningskæden er ikke nicheord længere. Det er praktiske driftsspørgsmål.

Vi ser tit, at virksomheder starter det forkerte sted. De vælger use case, model og interface først. Governance, rettigheder og sikkerhedsarkitektur kommer senere, hvis de overhovedet kommer. Man bliver meget begejstret af en copilots første fem minutter. Mindre af dens adgangsrettigheder i uge seks.

En af de mere præcise formuleringer i hovedkilden er, at AI nu bliver bygget ind i kritiske operationer og derfor kræver et flerlaget forsvar med databeskyttelse, adgangskontrol og løbende overvågning. Det er tæt på definitionen på moden AI-drift. Springer man de lag over, får man let et system, der ser fint ud på overfladen, men er porøst nedenunder.

Første greb er kedeligt og helt afgørende

Det første råd er streng adgangsstyring og datagovernance. Ja, det lyder tørt. Men det er her mange af de reelle problemer enten bliver stoppet eller sluppet ind. Role-based access control, altså adgang efter jobfunktion, betyder i praksis, at ikke alle skal kunne se, ændre, finjustere eller træne modeller på følsomme data. Kun de rigtige mennesker til de rigtige opgaver.

Her giver tanken om Zero Trust for AI faktisk mening. Ikke som modeord, men som arbejdshypotese: Stol ikke blindt på brugere, agenter eller integrationer, bare fordi de er interne. Giv mindst mulige rettigheder. Hvis en AI-agent kun skal kunne læse fra ét system, skal den ikke også kunne skrive i tre andre. Det lyder banalt, men vi har set opsætninger, hvor en ellers uskyldig assistent fik lovligt brede arme, fordi ingen ville være den sure, der sagde stop.

Den typiske indvending kommer hurtigt: Vi bruger jo kun AI internt. Men interne løsninger er ikke automatisk sikre. Hvis en intern bot er koblet til dokumentarkiv, wiki, kodebase eller HR-materiale, kan dårlig styring stadig føre til lækager eller utilsigtet adgang. Og hvis input til modellen kan manipuleres, er intern en ret tynd trøst. Det er lidt som at låse hoveddøren og lade bagdøren stå på klem.

Kryptering er ikke pynt

Næste practice er kryptering af både modeller og de data, der bruges til at træne eller drive dem. Ifølge hovedkilden bør det ske både i hvile og under transport, især når der indgår personoplysninger eller proprietær kode. En ukrypteret model eller et datasæt i et delt miljø er i praksis en invitation til problemer.

Det bliver ekstra konkret i cloudmiljøer og integrationslag, hvor data flyder mellem flere tjenester. Mange AI-løsninger lever ikke ét sted. De går fra en chatflade til en modeltjeneste, videre til et internt API og måske over i et dokumentlager. Hvis ikke kryptering og nøglestyring er på plads hele vejen, opstår der små svage punkter. De er sjældent synlige i den flotte demo. Men de findes.

Og så er der en detalje, som ofte bliver skubbet til side, fordi den ikke er særlig sexet: governance. Kilde 379 peger på, at AI-sikkerhed ikke kun handler om netværk og systemer, men også om risici, der er særlige for AI, og som kræver mere specialiserede greb. Derfor er datakvalitet, sporbarhed og ansvar ikke sidebemærkninger. Det er kontroller.

Prompt injection er ikke længere et kuriosum

En af de mest konkrete trusler er prompt injection. Hovedkilden beskriver det som angreb, hvor skadelige instruktioner gemmes i input for at få modellen til at tilsidesætte sin tiltænkte adfærd. Og den samme kilde knytter det præcist til OWASP Top 10 for LLM-applikationer, hvor prompt injection er rangeret som topsårbarhed. Det er værd at hæfte sig ved.

Det her betyder noget i praksis, fordi mange stadig tænker på input som uskyldig tekst. Men for en sprogmodel er tekst ikke bare tekst. Det er instruktioner, kontekst og mulige omveje i ét. Hvis en medarbejder, kunde eller tredjepart kan få modellen til at ignorere regler, hente følsom information eller kalde et værktøj på forkert grundlag, har man et problem, også selv om resten af infrastrukturen ser pæn ud på PowerPoint.

Det, der overraskede os første gang vi testede noget lignende på en kundecase, var ikke at modellen kunne narres. Det kunne den. Det overraskende var, hvor lidt der skulle til, før svarene begyndte at glide. En skæv instruktion i et dokument, et sidespor i en forespørgsel, og så stod vi med et system, som stadig virkede hjælpsomt, men ikke længere helt lydigt. Den slags føles meget abstrakt, lige indtil det ikke gør.

Der skal stå et filter ved døren

Derfor giver AI-specifikke firewalls og inputvalidering mening. Hovedkilden beskriver dem som en direkte måde at blokere prompt-injection ved indgangen, før input når modellen. På almindeligt dansk er det et filter ved døren. Ikke en garanti, ikke magi, men en vigtig kontrol, som klassiske webfiltre og endpoint-værktøjer ikke alene er bygget til at levere i AI-sammenhæng.

Det er også her mange organisationer overvurderer deres eksisterende sikkerhed. De tænker, at hvis mail, identitet og endpoints er dækket, så er AI-laget også nogenlunde dækket. Men AI-modeller står over for trusler, som konventionelle værktøjer ikke var designet til at opdage. Det understøttes både af hovedkilden og af den supplerende kilde fra Sysdig. Så nej, man kan ikke bare montere en chatbot oven på gammel sikkerhed og håbe på det bedste.

Hvis modellen ovenikøbet får lov at bruge værktøjer, stiger indsatsen. Agentmisbrug er kort fortalt risikoen for, at en model med for brede rettigheder udfører handlinger i andre systemer på et forkert eller manipuleret grundlag. Her bliver mindst privilegium helt centralt. En agent bør ikke kunne mere, end opgaven kræver. Helst mindre, indtil det er bevist nødvendigt.

Red teaming skal ind tidligt, ikke bagefter

Et andet råd i kilden er regelmæssig adversarial testing og red teaming. Altså kontrollerede angreb, hvor man forsøger at presse systemet, før andre gør det. Ifølge artiklen kan den form for test afsløre sårbarheder som data poisoning og model inversion, inden rigtige angribere finder dem. Og forskningen, der refereres, peger på noget ret væsentligt: Testen bør bygges ind i udviklingsforløbet løbende, ikke bare lægges på som en slutkontrol før go-live.

Det er en vigtig detalje. Mange virksomheder tænker stadig sikkerhedstest som et projekttrin til sidst. Men AI-systemer ændrer sig hele tiden. Modeller opdateres, datakilder skifter, integrationslag vokser, brugeradfærd flytter sig. Hvis man kun tester én gang, tester man næsten en anden løsning end den, man ender med at drifte.

Vi hører indimellem, at red teaming er for de store eller for de meget regulerede. Den holder ikke rigtigt. Selv mindre AI-løsninger kan have adgang til ting, de ikke burde dele, eller handlinger, de ikke burde udføre. Man behøver ikke bygge et helt sikkerhedsteater. Men man skal udsætte løsningen for reel modstand. Ellers ved man ikke, hvad der sker, når virkeligheden møder systemet en tirsdag morgen klokken 08.17.

Synlighed er sværere end folk tror

Så er der overvågning og samlet synlighed. AI lever sjældent i ét afgrænset miljø. Den ligger ofte spredt mellem cloud, on-prem, identitetslag, mail, netværk, endpoints og tredjepartsværktøjer. Hovedkilden advarer ret klart om, at siloer mellem de miljøer skaber blinde vinkler, hvor angreb kan bevæge sig uden at blive koblet sammen i tide. Det er ikke en ny lektie i sikkerhed, men AI gør konsekvensen værre.

Hvis telemetri fra identitet, netværk, cloud og endpoint ikke hænger sammen, ser man måske et mærkeligt login ét sted og en datahændelse et andet sted, uden at nogen forbinder punkterne. Den fragmentering er giftig, når AI-systemer både læser, skriver, henter og sender videre. Angrebskæden bliver mere snørklet. Ikke nødvendigvis mere spektakulær. Bare sværere at opdage i tide.

Det her er måske lidt niche, men vi ser også et organisatorisk problem. AI-projekter bor ofte hos forretning, innovation eller et digitalt team, mens sikkerhedsdata ligger et andet sted. Så får man den klassiske situation, hvor alle er ansvarlige på papiret og ingen helt i praksis. Der er en særlig stilhed i de møder, når nogen spørger, hvem der faktisk ejer logs og adgangsmodel.

De første skridt er ret enkle

Hvis man skal gøre noget nu, så start med at kortlægge hvor AI allerede har adgang. Ikke hvor man tror, den har adgang. Hvor den faktisk har det. Hvilke datakilder læser den fra, hvilke systemer kan den kalde, hvem kan ændre opsætningen, og hvilke modeller eller tredjepartstjenester indgår i kæden. Det er mindre glamourøst end at vælge ny model. Men langt mere nyttigt.

Derefter er rækkefølgen næsten banal: begræns rettigheder, krypter data og modeller, sæt inputkontrol op, og planlæg løbende test og overvågning. Ikke som et kæmpe transformationsprogram med 48 slides. Bare som de første nødvendige greb. For hvis AI allerede er på vej ind i drift, er spørgsmålet ikke, om sikkerhedsarbejdet skal begynde. Det er, hvorfor man ventede så længe.

Det er i virkeligheden den jordnære pointe i hele historien. Forskellen på en smart AI-løsning og et sikkerhedsproblem ligger ofte i nogle ret usexede ting: rettigheder, kryptering, filtre, logs og test. Ikke i den store vision. Man opdager først forskellen, når systemet møder virkeligheden.

Kilder

• 5 best practices to secure AI systems
• Top 8 AI Security Best Practices – Sysdig
• Introducing Cisco's AI Security Best Practice Portal – Cisco Blogs
• Joint Cybersecurity Information AI Data Security
• Joint Guidance on Deploying AI Systems Securely – CISA
• Fundamentals of Secure AI Systems with Personal Data