Vad är modellutfasning?

En AI-modell känns permanent tills den plötsligt inte är det. Modellutfasning – att leverantören pensionerar en version och tvingar fram en migrering – är en av de mest underskattade riskerna i AI-avtal. För de flesta är det en fotnot. För en reglerad verksamhet kan det bli en kris om varseltiden inte står i avtalet.

Definitionen

Modellutfasning innebär att en AI-leverantör slutar tillhandahålla en viss modellversion och kräver att de som använder den byter till en nyare. Det är en normal del av modellernas livscykel: nya versioner släpps, gamla underhålls inte i all evighet.

Konsekvensen för er beror på hur ni använder modellen. Ibland är ett byte en okomplicerad uppdatering. Ibland – särskilt när modellens beteende är inbakat i en verksamhetskritisk eller reglerad process – innebär det ett omfattande omtag. Och det som avgör om ni hinner med är varseltiden.

Varför det spelar roll även utan formella krav

Modellutfasning uppfattas ofta som ett problem enbart för strängt reglerade branscher. Men även en vanlig verksamhet påverkas, eftersom en ny modellversion inte beter sig exakt som den gamla. Prompter som finslipats för en version kan ge andra svar på nästa – ibland bättre, ibland sämre, men sällan identiska. Har ni byggt en tjänst där tonläge, format eller precision är viktigt måste den testas om vid varje modellbyte.

Ett konkret exempel: en kundtjänstassistent har trimmats så att svaren håller rätt ton och längd. När den underliggande modellen fasas ut och ersätts kan samma instruktioner plötsligt ge längre eller mer formella svar. Utan varsel och en testperiod märker ni det först när kunderna gör det. Därför är varseltiden en fråga för fler än de som har en formell valideringsprocess.

Varseltiden varierar dramatiskt

Här är kärnan i problemet: hur långt varsel ni får skiljer sig enormt mellan leverantörer och modelltyper.

Spannet går alltså från över ett år ned till ett par veckor. Notera särskilt att vissa leverantörer inte har något avtalat minimum alls – då är ni utlämnade till en policy som kan ändras. Och observerade mönster, som Copilots dryga månad, är inte samma sak som ett avtalat åtagande.

Konsekvensen för reglerade verksamheter

För verksamheter som måste omvalidera formellt vid ett modellbyte blir varseltiden avgörande. Omvalidering innebär att visa att den nya modellversionen uppfyller samma krav som den gamla – ett arbete som tar tid.

Om varseltiden är kortare än revalideringsfönstret uppstår ett glapp: modellen är utfasad innan den nya hunnit godkännas. Ett konkret scenario: en verksamhet med formell modellvalidering får två veckors varsel om att deras modellversion pensioneras, men deras omvalideringsprocess tar längre än så. Resultatet är att de tvingas välja mellan att stanna på en avvecklad modell eller köra en icke färdigvaliderad.

Lösningen är att köra två modellversioner parallellt under revalideringsfönstret – den gamla håller igång produktionen medan den nya valideras. Det förutsätter att ni planerat för det, och att avtalet ger tillräcklig varseltid.

Gör varseltiden till en avtalspunkt

Slutsatsen är enkel: behandla varseltiden som en förhandlingspunkt, inte en fotnot. Skriv in ett minsta varsel i avtalet, planera för parallelldrift där omvalidering krävs, och bygg lösningen så att ett modellbyte inte tvingar fram ett totalt omtag.

Och eftersom varseltider och utfasningspolicyer ändras över tid: kontrollera leverantörens aktuella policy i stället för att lita på en siffra du läst någonstans. Det som gällde vid förra avtalet kan ha ändrats.

Vill du se hur modellutfasning hänger ihop med leverantörsval, residens och driftsäkerhet i ett helt AI-projekt finns mer på vår AI-sida. Behöver du hjälp att bygga en AI-lösning som tål ett modellbyte? Hör av dig.