Testning av AI med hjälp av motståndare: Det saknade ledet i AI-styrningen

Din organisation använder med största sannolikhet mer AI än vad ditt säkerhetsteam är medvetet om. Frågan är inte om er AI-styrning omfattar detta. Frågan är om någon del av den skulle hålla måttet mot någon som försöker kringgå den.

De flesta företag befinner sig idag i en märklig klyfta. Å ena sidan mognar styrningen av AI: riktlinjer, regler för godtagbar användning och riskklassificeringar, ofta anpassade efter EU:s AI-lag. Å andra sidan fortsätter AI:s faktiska omfattning att växa snabbare än vad någon hinner följa med i.

Enligt Cloud Security Alliance utgör ”skugg-AI” över hälften av företagens användning av generativ AI, och 89 % av företagens AI-användning är osynlig för säkerhetsteamen (CSA, 2026). IBM:s rapport ”Cost of a Data Breach Report” från 2025 visade att var femte organisation som drabbats av ett dataintrång hade upplevt ett intrång där ”skugg-AI” var inblandat (IBM, 2025).

Förordningen kräver redan mer än bara pappersarbete

EU:s AI-lag ställer inte bara frågan om du har dokumenterat din AI. När det gäller högrisk-system ställer den frågan om de faktiskt är robusta och säkra.

Enligt artikel 15 i AI-lagen ska AI-system med hög risk uppnå ”en lämplig nivå av noggrannhet, robusthet och cybersäkerhet” samt vara motståndskraftiga mot försök från obehöriga tredje parter att ändra deras beteende genom att utnyttja sårbarheter (EUR-Lex, 2024). Det är ett säkerhetskrav som är inskrivet i lagen, inte en ren dokumentationsuppgift.

Det här är samma klyfta som Damovos Adversarial-team, Lares, har skrivit om inom andra områden: regelefterlevnadsåtgärder syftar till att kontrollera om säkerhetsåtgärderna är dokumenterade, medan angripare mäter om de faktiskt fungerar. AI är helt enkelt det senaste området där denna klyfta uppstår, och den växer snabbt eftersom införandet går snabbare än alla styrningsprocesser som skapats för att begränsa den.

Vad ”testning” av AI egentligen innebär

AI-system uppvisar fel som inte liknar traditionella sårbarheter i programvara, vilket är anledningen till att de inte upptäcks vid traditionell testning.

När vi utsätter en AI-lösning för adversariella tester genomför teamet inte någon sårbarhetsskanning. Vi attackerar den på samma sätt som en verklig angripare skulle göra:

• Att manipulera vad AI:n får i uppdrag att göra. En noggrant utformad indata kan åsidosätta en AI-assistents instruktioner och förvandla ett användbart internt verktyg till något som istället följer en angripares mål.
• Att missbruka det som AI:n har tillåtelse att använda. Moderna AI-agenter kan skicka e-post, göra sökningar i databaser och anropa interna API:er. Att lura agenten att missbruka dessa verktyg är en av de snabbaste vägarna till verklig skada.
• Att utvinna information om vad AI:n har sett. Modeller som har tränats på eller är kopplade till känsliga uppgifter kan förmås att avslöja dessa, en noggrant formulerad fråga i taget.

Inget av detta framgår vid en granskning av styrningen. Det framkommer först när någon medvetet försöker bryta sig in i systemet.

OWASP Top 10 för agentbaserade applikationer, som publicerades i slutet av 2025, kartlägger just dessa risker för autonoma AI-agenter (OWASP, 2025). Ramverket finns redan. Det som saknas i de flesta organisationer är bevis på att deras egna implementationer klarar dessa krav.

Fördjupning: OWASP Agentic AI Top 10: Hot i verkligheten

Ett praktiskt sätt att överbrygga klyftan: Utvärdering av AI genom motståndsbaserade tester

Damovos rådgivningsgrupp för offensiv cybersäkerhet, Lares, erbjuder ett strukturerat sätt att ta reda på vad din AI faktiskt gör vid en attack, inte bara vad dina riktlinjer säger att den ska göra.

Bedömningen av adversariell AI genomförs i tre nivåer, och organisationer kan delta på den nivå som bäst motsvarar deras mognadsgrad:

1. Kartläggning av AI-avtryck. Innan du kan säkra din AI måste du kartlägga alla delar av den, inklusive den ”skugg-AI” som din styrningsprocess inte har kännedom om. Detta är en medveten, expertledd kartläggning, inte resultatet av en skanning. Den viktigaste luckan är den som en skanner inte kan upptäcka.
2. Testning av AI med hjälp av motståndare. Praktisk testning av era AI-system mot verkliga attacktekniker:manipulation av promptar, missbruk av agentverktyg, datautvinning och övriga metoder som finns listade i OWASP-ramverken. Resultatet är inte en lista över teoretiska risker. Det är bevis på vad en angripare faktiskt skulle kunna göra, kopplat till de skyddsåtgärder som stoppade dem och de som inte gjorde det.
3. Testfrekvens för AI. AI-system förändras ständigt: nya modeller, nya integrationer, nya dataanslutningar. Ett engångstest blir snabbt inaktuellt. Testfrekvensen säkerställer en kontinuerlig validering, så att underlaget förblir aktuellt i takt med att systemets omfattning utvecklas.

Den röda tråden är enkel och bygger på samma princip som ligger till grund för allt Lares gör: berätta inte bara att era kontrollsystem fungerar. Visa oss det, under realistiska angreppsscenarier, där ert team deltar i att åtgärda de brister vi upptäcker.

Läs mer: Utvärdering av adversariell AI

Var ska man börja?

Om er organisation har infört AI-styrning men aldrig har testat hur dess AI-system faktiskt fungerar vid en attack, är det den luckan som måste täppas till först. Och om ni ännu inte känner till den fullständiga omfattningen av AI-användningen inom hela verksamheten, ger kartläggningsfasen svar på den frågan före allt annat.

Källor

• Cloud Security Alliance, Shadow AI-appar: Företagens attackyta som växer snabbare än övervakningen (2026)
• IBM, Rapport om kostnaderna för dataintrång 2025 (2025)
• EUR-Lex, förordning (EU) 2024/1689 (lagen om artificiell intelligens) (2024)
• OWASP GenAI Security Project, OWASP Top 10 för agentbaserade applikationer för 2026 (2025)