Den osynliga risken med AI-implementeringar

Den osynliga risken med AI-implementeringar är de fel som inte syns i en demo men dyker upp i drift: dålig datakvalitet, bias, shadow AI, leverantörslås, bristande spårbarhet och regelefterlevnad. De går att fånga tidigt.

Varför demon ljuger

En demo är gjord för att övertyga. Den körs på ren, utvald data, i ett snävt scenario, av någon som vet exakt var systemet är starkt. Allt som kan gå fel har redan rensats bort innan ni ser skärmen.

Drift är motsatsen. Där möter systemet verklig data som är ofullständig, motsägelsefull och full av historiska mönster ingen tänkte på. Det möter användare som ställer frågor utvecklaren aldrig förutsåg. Och det möter ett regelverk som inte bryr sig om hur bra demon var.

Skillnaden mellan ett lyckat pilotprojekt och ett system som havererar i produktion är sällan modellen. Det är riskerna runt modellen, de som inte ryms i en presentation. De flesta av dem går att se i förväg, om man vet var man ska titta.

De osynliga riskerna, en och en

Fyra risker skiljer ett AI-system som håller i drift från ett som inte gör det: datans kvalitet, vem som äger systemet, om besluten går att spåra, och om det följer lagen. Här är var och en.

Datakvalitet och bias

En AI-modell är aldrig bättre än datan den tränats och matas med. Är datan ofullständig, snedfördelad eller historiskt partisk, ärver modellen det, och gör det i skala, snabbare än någon hinner upptäcka.

Det farliga är att felet inte syns. Modellen levererar svar med samma självsäkerhet oavsett om underlaget är solitt eller skevt. En rekryteringsmodell tränad på tio års anställningar lär sig vilka som historiskt anställts, inte vilka som borde anställas. En kreditmodell kan återskapa mönster som lagen förbjuder, utan att någon skrev in dem.

Frågan att ställa: vet ni vad som finns i datan, var den kommer ifrån, och vilka grupper den representerar dåligt? Om svaret är nej är det inte ett modellproblem, det är ett datastyrningsproblem.

Shadow AI

Shadow AI är AI-verktyg som medarbetare använder i arbetet utan att organisationen känner till det. Någon klistrar in ett kundavtal i en publik chattjänst för att få en sammanfattning. Någon låter ett verktyg utanför era system skriva svar till medborgare.

Det sker inte av illvilja. Det sker för att verktygen är bra och nära till hands, och för att alternativet inom organisationen saknas eller är trögt. Men i samma stund lämnar känslig data er kontroll, och beslut börjar vila på underlag ingen har granskat.

Förbud löser sällan problemet, det driver bara användningen längre ner i skuggan. Det första steget är att kartlägga vad som faktiskt används, och sedan ge ett tryggt alternativ. Vi går djupare i shadow AI och vad organisationer bör veta.

Leverantörslås

Leverantörslås uppstår när er data, era promptar och er modellogik är så inbäddade i en leverantörs plattform att ett byte innebär att bygga om från grunden. Det märks sällan i början. Det märks vid prishöjningen, vid villkorsändringen, eller den dag leverantören lägger ner produkten.

I ett AI-projekt finns låset på fler ställen än i klassisk programvara: i modellen, i datan som matats in, i de finjusteringar som gjorts, och i integrationerna runt omkring. Frågan att ställa tidigt: kan vi ta med oss data och konfiguration om vi vill byta, och har vi det skriftligt?

Bristande spårbarhet

När ett AI-system fattar eller stödjer ett beslut som påverkar en människa, kommer frågan förr eller senare: varför blev det så? Kan ni inte svara, inte visa vilken data, vilken modellversion och vilken logik som låg bakom, har ni inget system ni kan stå för.

Spårbarhet är svår att lägga till i efterhand. Loggas inte rätt saker från start finns inte historiken att rekonstruera. Vid en granskning, en överklagan eller en incident är det skillnaden mellan ett svar och en gissning. Spårbarhet är inbyggt, inte efterhandsklätt.

Regelefterlevnad och EU AI Act

EU AI Act är EU:s förordning för artificiell intelligens. Den trädde i kraft 1 augusti 2024 och fasas in över flera år, med de centrala kraven för högrisk-system i sin helhet från 2 augusti 2026 (EUR-Lex, förordning 2024/1689). Förordningen klassar AI-system i fyra risknivåer, och klassningen avgör vad som krävs.

Faller er användning under högrisk gäller konkreta krav: riskhantering, datastyrning, teknisk dokumentation, loggning, mänsklig tillsyn och transparens mot den som påverkas. Många organisationer vet inte var de landar i klassningen, och därmed inte vad som väntar. Vi har sammanfattat det i EU AI Act, vad företag bör veta.

Hur man upptäcker dem tidigt

Det fina är att inga av de här riskerna är osynliga för den som vet var man tittar. De är bara osynliga i en demo. Tre saker flyttar upptäckten före incidenten i stället för efter.

Granska innan ni bygger, inte efter. En mognadsmätning kartlägger var er organisation står på data, kompetens, styrning och teknik, innan pengarna är lagda på fel sak. Det är billigare att hitta ett datakvalitetsproblem på ett whiteboard än i produktion.

Sätt styrning som följer hela livscykeln. Governance handlar inte om en policy i en pärm. Det handlar om vem som får besluta vad ett system får göra, hur det loggas, hur det följs upp och vem som äger felet när det inträffar. ISO 42001, den första internationella standarden för styrning av AI-system, fastställd 2023, ger ett ramverk för just det.

Testa på verklig data, inte på demodata. Innan ett system går i drift, kör det på data som liknar verkligheten: ofullständig, partisk, oväntad. Det som spricker där hade spruckit i produktion ändå, men nu utan att en medborgare eller en kund drabbas.

Ett konkret exempel

Ta ett typfall, satt ihop av mönster vi sett återkomma snarare än ett enskilt uppdrag. En kommun vill införa ett AI-stöd som föreslår beslut i ett handläggningsflöde. Demon imponerar: rätt svar, snabbt, på de ärenden leverantören valt.

I drift möter systemet tio års verkliga ärenden. Den historiska datan bär mönster från en tid då handläggningen såg annorlunda ut, och modellen återskapar dem. En handläggare märker att förslagen systematiskt missgynnar en grupp sökande. Ingen kan svara på varför, loggningen fångade aldrig vilket underlag varje förslag byggde på. Och eftersom systemet stödjer myndighetsbeslut som rör enskilda, ligger det i ett område där EU AI Act ställer höga krav.

Inget av detta var dolt. Datakvaliteten gick att granska före köp. Spårbarheten gick att bygga in från start. Klassningen mot EU AI Act gick att göra innan upphandlingen. Det som gjorde riskerna osynliga var att ingen tittade förrän demon redan hade övertygat.

Mönstret är inte ovanligt. Det vi gång på gång ser är att lyckade piloter fastnar i steget mot drift just där de osynliga riskerna sitter, och att de problemen nästan alltid gick att se i förväg.

Vanliga missförstånd

“Vi väljer en bra leverantör, då är riskerna deras.” Ansvaret för ett beslut som påverkar er kund eller er medborgare stannar hos er, oavsett vem som byggde modellen. En bra leverantör minskar risken. Den tar inte över ansvaret.

“Vi kör en pilot först, då ser vi problemen.” En pilot på utvald data och en avgränsad grupp döljer precis de risker som dyker upp vid skala och bredd. Piloten visar att det går, inte att det håller.

“EU AI Act gäller inte oss.” Många antar det utan att ha gjort klassningen. Förordningen utgår från vad systemet används till, inte vilken bransch ni är i. Ett HR- eller handläggningsstöd kan landa i högrisk även i en organisation som inte ser sig som ett tech-bolag.

“Vi fixar styrningen sen.” Spårbarhet och datastyrning som läggs till i efterhand kostar mer och täcker mindre. Det som inte loggades från start går inte att rekonstruera.

Den osynliga risken är inte att AI är farligt. Det är att de avgörande frågorna ställs efter att systemet är byggt, i stället för innan. Flytta frågorna framåt, så blir riskerna synliga medan de fortfarande är billiga att åtgärda.

Skriven av Joakim Ekman.