AI-förvaltning: vad lösningen kräver efter lansering

AI-förvaltning är det löpande arbete som håller en AI-lösning korrekt och i drift efter lanseringen: en namngiven ägare, uppföljning mot baslinjen, omtest när modell, instruktion eller regler ändras, en incidentrutin för när lösningen gör fel, en reservrutin för när leverantören ligger nere och en budget som täcker allt det. Hur testerna byggs före lansering beskrivs i testa AI-lösningar; förvaltningen tar vid när lösningen går i drift.

I artikeln Hidden Technical Debt in Machine Learning Systems (NeurIPS 2015) skrev ingenjörer på Google att maskininlärningssystem är relativt snabba och billiga att bygga men svåra och dyra att underhålla, bland annat för att omvärlden ändras. Samma sak gäller när en process automatiseras med AI: regler, mallar och dataformat ändras, och leverantören byter modellen under lösningen.

Förvaltningen bestäms före lanseringen: vem som äger lösningen, vad som mäts, vad som utlöser ett nytt test och vad medarbetarna gör när AI-funktionen är avstängd.

Vem äger lösningen när projektet är slut?

Utse en person i verksamheten, med namn, som äger kvaliteten, får larmen, beslutar om ändringar och har mandat att stänga av AI-funktionen. Den tekniska förvaltningen kan ligga internt eller hos en leverantör, men den ska vara uttalad och ha tid avsatt. Ägaren behöver ett underlag: vad lösningen gör och inte gör, vilken modellversion och instruktion som gäller, vilka system och konton den använder, testsetet med godkännandenivåerna, hur den stängs av och hur leverantören nås en fredagseftermiddag.

I en enkät som Gartner publicerade 30 juni 2025, med 432 svarande, uppgav 45 procent av cheferna i organisationer med hög AI-mognad att deras AI-initiativ var kvar i produktion i tre år eller mer, mot 20 procent vid låg mognad. Gartner kopplar skillnaden bland annat till robust styrning och ingenjörspraxis.

Hur följs lösningen upp mot baslinjen?

Följ tre slags tal, vart och ett mot värdet före lanseringen eller i testet.

Effekt: samma mätetal som baslinjen, som handläggningstid, andel ärenden utan manuell hantering och andel fel och omarbete. Hur baslinjen sätts beskrivs i AI ROI.

Kvalitet: ett regelbundet stickprov av produktionsfallen, bedömt med samma mått och nivåer som testsetet.

Driftsignaler: Googleartikeln ger tre startpunkter. Fördelning: andelen ärenden per kategori som lösningen sätter ska ligga nära den verkliga, och ett plötsligt skifte tyder på att verkligheten eller modellen har ändrats. Handlingsgränser: ett tak för hur många åtgärder lösningen får utföra per timme eller dag, som larmar och lämnar över till en människa. Källor: övervaka indata från andra system, eftersom ett ändrat format uppströms ger fel längre ned. Följ också förbrukningen per flöde.

Bestäm i förväg vad som räknas som avvikelse och vem som agerar på den.

När ska lösningen testas om?

Varje ändring som kan påverka svaren ska följas av ett regressionstest innan den når användarna: samma testset, samma mått, jämfört med förra körningen. Testet ska utlösas när:

1. Modellen byts. Anthropic lovar minst 60 dagars varsel innan en publik modell pensioneras, enligt sin policy för modellavveckling. I Microsoft Foundry lever allmänt tillgängliga modeller normalt 18 månader, med avisering minst 60 dagar före pensionering, och i distributionstyperna Global Standard, Data Zone Standard och Standard uppgraderar Microsoft automatiskt till ersättaren (livscykelpolicyn, juli 2026). Modellen kan alltså bytas utan att ni gör något; lägg pensioneringsdatumet i kalendern och testa ersättaren i god tid.
2. Instruktionen ändras, varje ny prompt eller regel i lösningen.
3. Underlaget ändras, nya eller ändrade dokument i det lösningen söker i.
4. Verksamheten ändras, nya prislistor, mallar, avtal eller regler.
5. Systemen ändras, en uppdatering i affärssystemet eller ett nytt dataformat i en integration.

Notera varje ändring i en ändringslogg, kör testet, jämför per kategori, godkänn mot nivåerna och behåll den gamla versionen tills den nya är godkänd, så att ni kan backa.

Vad gör ni när lösningen gör fel i drift?

En AI-incident är en händelse där lösningen ger fel utdata med följder, hanterar uppgifter fel, agerar utanför sitt mandat eller slutar fungera. Till skillnad från en vanlig it-incident kan felet ha pågått tyst i veckor, orsaken kan ligga hos en leverantör ni inte styr, och utan loggar går det inte att visa vad systemet gjorde. En agent kan också styras om av instruktioner gömda i ett mejl eller dokument den läser, så kallad indirekt promptinjektion; promptinjektion står först på OWASP:s lista över risker för LLM-tillämpningar 2025. Rutinen för det första dygnet:

1. Stoppa flödet, inte verksamheten. En lösning byggd för drift har en avstängning som lämnar det manuella arbetssättet kvar.
2. Begränsa skadan: dra in agentens behörigheter, stäng sökindexet, återkalla nycklar.
3. Säkra loggarna innan något ändras: prompter, svar, verktygsanrop, modellversion, tidpunkter och vem som godkände vad, enligt principerna i AI-agenter i drift.
4. Bedöm omfattningen: vilka utdata som var fel, sedan när, för vilka och om personuppgifter berördes.
5. Anmäl och informera där regler eller avtal kräver det, och kontakta leverantören om felet kan ligga hos dem.
6. Rätta beslut och dokument som påverkats under felperioden, med loggarna som karta.
7. Skriv en kort incidentrapport samma vecka och lägg in fallet i testsetet, så att just det felet inte kommer tillbaka obemärkt.

Klockorna som kan börja ticka:

• GDPR artikel 33: en personuppgiftsincident anmäls till IMY utan onödigt dröjsmål och om möjligt inom 72 timmar, se IMY:s vägledning om personuppgiftsincidenter.
• Cybersäkerhetslagen: omfattas ni av cybersäkerhetslagen (2025:1506), i kraft sedan 15 januari 2026, ska en betydande incident rapporteras inom 24 timmar, följas av en incidentanmälan inom 72 timmar och en slutrapport inom en månad.
• AI-förordningen: för AI-system med hög risk, som rekrytering eller kreditprövning enligt bilaga III, gäller kraven från 2 december 2027 enligt den konsoliderade lydelsen. Tillhandahållaren ska då avbryta användningen och informera leverantören vid risk (artikel 26.5), och leverantören rapportera allvarliga incidenter senast 15 dagar efter kännedom, i vissa fall tidigare (artikel 73). Vilken roll ni har reds ut i AI-förordningen och GDPR.
• Avtalen: servicenivåer och informationsplikt mot kunder har egna frister.

Vad händer när leverantören ligger nere?

Den 19 till 20 oktober 2025 hade Amazon Web Services region us-east-1 störningar i drygt fjorton timmar, enligt AWS redogörelse utlösta av ett latent fel i DynamoDB:s DNS-hantering. Den 18 november 2025 fick Cloudflares nätverk omfattande fel i leveransen av trafik från klockan 11.20 UTC; kärntrafiken flöt i stort sett normalt 14.30 och alla system fungerade igen 17.06, enligt Cloudflares rapport.

En AI-lösning beror på flera sådana led: modellleverantören, plattformen, molnet, nätverkstjänsterna och datakällorna. Rita kedjan per flöde och sätt en tolerans, alltså hur länge verksamheten klarar sig utan funktionen. En chattassistent mot kunder märks inom minuter, ett flöde för leverantörsfakturor tål kanske en dag. Toleransen avgör reservnivån:

1. Manuell rutin, nedskriven och övad, med samma system och behörigheter som AI-flödet. En lösning som tagit bort det manuella spåret har tagit bort reserven.
2. Kontrollerad degradering: misslyckade anrop köas och görs om med väntetid, ärenden går till människor och användaren får ett tydligt besked, aldrig ett tyst fel.
3. En andra väg för det som inte tål stopp: en annan modell eller leverantör bakom samma gränssnitt, testad mot samma testset.
4. En utväg för gott: data, instruktioner, konfiguration och loggar ska gå att få ut i vanliga format. För molntjänster ger dataförordningen per oktober 2026 kunden rätt att byta leverantör inom högst 30 dagar efter en uppsägningstid på högst två månader (artikel 25), och från 12 januari 2027 får inga bytesavgifter tas ut (artikel 29). Hur exit skrivs in i avtalet beskrivs i kravställa AI.

Öva rutinen, till exempel en gång per kvartal: stäng av AI-funktionen i ett flöde en timme, meddelat i förväg, och mät tiden tills någon larmar och tills reservläget är igång.

Hur budgeteras förvaltningen?

Ge förvaltningen en egen rad i kalkylen från början, uppdelad på poster som går att uppskatta:

• Ägarens tid för uppföljning, larm och beslut, i timmar per månad.
• Stickprov av produktionsfall, i timmar per vecka eller månad.
• Omtest och justering vid varje utlösare ovan. Med en livscykel på 18 månader, som Microsofts standard ovan, innebär en lösning som ska leva i tre år minst ett modellbyte.
• Förbrukning och licenser: anrop per flöde, plattformar och verktyg, se vad AI kostar.
• Beredskap: incidentrutin, reservrutin och kvartalsövning.
• Förändringar i verksamheten: nya regler, mallar och system att följa.

Sätt timmar och belopp per post och lägg summan i samma kalkyl som nyttan. En kalkyl utan förvaltning förutsätter att lösningen sköter sig själv, just det Googleartikeln varnar för.

Vill ni att lösningen håller efter lanseringen?

Ägare, nivåer, utlösare och reservrutin går att bestämma redan i en förstudie, den första fasen i ett bygge. Byron Calles bygger AI-lösningar och kan efter lanseringen stå för drift och vidareutveckling eller lämna över med dokumentation, så att ni förvaltar själva; båda ingår i AI-utveckling. Boka ett samtal så går vi igenom vad förvaltningen skulle kräva för ert flöde.