Kategori: AI-infrastruktur / Erfarenheter
Det här är inte ett inlägg om att molnet är dåligt. Molnet är ett bra verktyg för många ändamål, och vi samarbetar med molnleverantörer i flera av våra kunders miljöer. Men efter att ha arbetat med AI-infrastruktur i en rad organisationer – från medelstora tillverkningsbolag till regionala myndigheter – ser vi samma misstag återkomma. Inte en gång, utan konsekvent.
Och i de flesta fall är de fullt undvikbara. Det förtjänar en ärlig genomgång.
Misstag 1: Man räknar inte på vad det kostar att skala
Det är billigt att komma igång med AI i molnet. Det är det designat för att vara. En pilot med begränsad datamängd och sporadisk körning kostar lite. Det skapar en falsk föreställning om vad det faktiskt kostar att drifta systemet i produktion.
Vi har pratat med kunder vars molnfaktura för AI tredubblades inom sex månader efter att de gick i produktion – utan att trafikvolymen ökat i motsvarande utsträckning. Orsaken var en kombination av kontinuerlig inferens, egress-kostnader för data, och lagringspriser som skalades oväntat.
Lösningen är inte att undvika molnet. Lösningen är att räkna ordentligt på TCO innan man committar till en arkitektur – och i de flesta fall väger en on-prem eller hybridlösning tyngre än det verkar i en pilotfas.
Misstag 2: Man bygger sig fast i en leverantörs ekosystem
Det går snabbt att bygga beroenden till en specifik molnleverantörs AI-tjänster – deras proprietära API:er, deras specifika format för modelldeployment, deras sätt att hantera vektordatabaser. I ett tidigt skede är det oproblematiskt. Det är smidigt och det funkar.
Problemet uppstår när ni vill byta, eller när leverantören ändrar prissättning, avslutar en tjänst, eller inför villkor som inte passar er verksamhet. Migrering från ett djupt integrerat molnekosystem är tekniskt komplicerat och organisatoriskt smärtsamt.
Vi ser det här särskilt tydligt i offentlig sektor och hälsa, där ett plötsligt ägarbyte av en molntjänst eller en ändring i villkoren kan skapa allvarliga problem för verksamhetskritiska system.
Misstag 3: Datasuveränitet behandlas som en checkbox
’Vi lagrar data i ett europeiskt datacenter’ är ett svar som låter bra i en upphandling men som inte betyder det de flesta tror att det betyder. Var data fysiskt lagras och vem som juridiskt kontrollerar den är två helt olika frågor.
CLOUD Act, som ger amerikanska myndigheter möjlighet att begära åtkomst till data som hanteras av amerikanska bolag oavsett var den lagras fysiskt, är ett välkänt exempel. Men det finns subtilare varianter: modellägarskap (vem äger en modell som tränas på er data hos en extern leverantör?), loggning (vad loggar leverantören och hur länge?), och träning (används era data för att förbättra leverantörens egna modeller?).
Dessa frågor behöver ställas och besvaras skriftligt, inte antas.
Misstag 4: Säkerhet läggs till i efterhand
AI-system byggs ofta iterativt och snabbt, vilket är bra för innovation men dåligt för säkerhetsarkitektur. Det som börjar som ett intern verktyg för ett team expanderar gradvis – fler användare, mer känslig data, bredare integration med andra system – utan att säkerhetsmodellen uppdateras i takt.
Åtkomstkontroll på dokumentnivå i RAG-system är ett konkret exempel vi redan nämnt. Men det finns fler: API-nycklar som delas utan rotationspolicy, modeller som körs med överdrivna rättigheter, loggning som inte möter krav för revision, och integrationer med externa tjänster som inte granskats ordentligt.
Att retrofita säkerhet in i ett befintligt system är alltid dyrare än att bygga rätt från start. Det är ett kliché, men det är sant.
Misstag 5: Man underskattar vad ’i produktion’ faktiskt innebär
Det är en stor skillnad mellan ett AI-system som fungerar och ett AI-system som är driftbart. Fungerar betyder att det producerar rimliga outputs. Driftbart innebär att det är monitorerat, uppdaterbart, felsökt, dokumenterat, och kan hanteras av fler än den person som byggde det.
AI-system i produktion kräver en MLOps-process: versionering av modeller och data, automatiserad testning, monitorering av modellprestanda över tid, och tydliga rutiner för när och hur modellen uppdateras. Utan det sitter ni med ett system som fungerar tills det inte gör det, och ingen vet riktigt varför.
Vad det kostar att göra om
Det gemensamma temat i dessa fem misstag är att de är dyra att korrigera i efterhand men relativt enkla att undvika med rätt arkitekturbeslut tidigt.
Det kräver att man ställer svåra frågor i ett skede när det fortfarande känns som ett pilotprojekt. Vad händer när det skalas? Vem äger egentligen datan? Vad behöver vi kunna visa i en revision? Hur uppdateras systemet om ett halvår?
Det är de frågorna vi ställer när vi hjälper organisationer att designa sin AI-infrastruktur. Inte för att bromsa, utan för att slippa bygga om.
Kontakta oss på Aixia om ni vill ha ett ärligt samtal om er nuvarande setup, eller utforska AiQu på aiqu.ai.
