Checklista: hitta AI-modellerna som slutar fungera innan kunden gör det

När en AI-modell stängs ner märks det sällan i ett möte. Det märks när ett kalkylblad slutar fylla i rader, när formuläret inte längre sammanfattar ärenden, eller när en kund får vänta för att ett litet skript fortfarande anropar ett modell-ID som leverantören har pensionerat.

Ett modell-ID är det namn en app, integration eller automatisering skickar till en AI-leverantör för att välja modell, till exempel gemini-2.0-flash eller grok-build-0.1. Det låter tekniskt. I praktiken är det en driftfråga. Om ID:t ändras utan test, ägare och fallback kan ett fungerande arbetsflöde bli en tyst felkälla.

Gemini 2.0 Flash försvann den 1 juni

Google skrev i Gemini API:s release notes den 1 juni 2026 att gemini-2.0-flash, gemini-2.0-flash-001, gemini-2.0-flash-lite och gemini-2.0-flash-lite-001 nu är avstängda. Deprecations-sidan pekar mot gemini-3.5-flash för Flash-varianterna och gemini-3.1-flash-lite för Flash-Lite-varianterna.

På papper ser bytet enkelt ut. I verkligheten kan det gamla namnet ligga kvar i kod, miljövariabler, Zapier- eller Make-scenarier, notebooks, mallar, proxyregler, testsviter, dashboards och gamla instruktioner till kollegor.

Källa: Gemini API release notes och Gemini API deprecations

En modell i en meny är inte samma sak som ett API-avtal

Samma vecka dök xAI:s Composer 2.5 upp i Grok Build. xAI skriver att modellen finns i Grok Build och kan väljas från /models-menyn för SuperGrok och abonnemanget X Premium Plus. Det är användbart för den som arbetar interaktivt i Grok Build.

Men xAI:s publika modellkatalog för utvecklare listar vid kontrolltillfället inte Composer 2.5 som ett API-modell-ID. Där finns bland annat Grok 4.3 och grok-build-0.1, men inte ett dokumenterat composer-2.5-ID med pris, kontextfönster och API-garanti.

Det här är en annan sorts risk än Geminis nedstängning. Här handlar det inte om ett gammalt ID som försvinner, utan om ett nytt namn som någon kan frestas att klistra in i ett API- eller no-code-flöde innan leverantören har publicerat kontraktet.

Källa: xAI: Composer 2.5 och xAI developer models

Ibland ändras svaret, inte bara modellen

Mistrals uppdaterade resonemangs-dokumentation visar en tredje fälla. De tidigare native reasoning-modellerna magistral-small-latest och magistral-medium-latest är deprecierade. Mistral hänvisar i stället till mistral-small-latest och mistral-medium-3-5 med parametern reasoning_effort.

Där finns en detalj som kan få ett arbetsflöde att gå sönder även om modellen svarar. Med reasoning_effort="high" kan svaret komma som chunkar, bland annat ThinkChunk och TextChunk. Med reasoning_effort="none" kan innehållet vara en vanlig sträng. Om ert flöde bara förväntar sig en textsträng, och sedan skickar svaret vidare till ett ärendesystem, en rapport eller ett CRM-fält, behöver parsern testas.

En parser är bara den del av flödet som läser AI-svaret och plockar ut rätt text, fält eller JSON. Den är ofta osynlig tills den misslyckas.

Källa: Mistral: Reasoning

Gör en modell-ID-audit innan ni byter

Den enkla versionen: leta inte bara efter modellen där ni tror att den finns. Leta där den kan ha kopierats.

• Lista alla modellsträngar. Sök efter modellnamn i kod, .env-filer, no-code-verktyg, kalkylblad, promptbibliotek, interna guider och gamla testexempel.
• Skriv vem som äger varje flöde. Ett kundsvar, en veckorapport och en intern researchbot ska inte ha samma risknivå bara för att de använder samma leverantör.
• Skilj alias från fasta ID:n. Ett alias som följer senaste versionen kan vara bekvämt. Ett fast ID kan vara bättre när ni behöver reproducerbara svar. Båda behöver dokumenteras.
• Testa ersättaren med riktiga exempel. Kör minst tio sparade inputs från flödet. Titta på svarskvalitet, ton, fältformat, kostnad, svarstid och vad som händer när svaret blir tomt eller oväntat långt.
• Kontrollera parsern, inte bara prompten. Om leverantören ändrar svarstyp, streaminghändelser eller reasoning-format kan det vara integrationen efter modellen som går sönder.
• Bestäm fallback innan stoppdatumet. Det kan vara en annan modell, manuell kö, pausat flöde, eller ett tydligt meddelande till användaren. Fallbacken ska inte uppfinnas när kunden redan väntar.
• Lägg in nästa kontroll i kalendern. Modellbyten är inte engångsprojekt längre. De hör hemma i samma rutin som andra leverantörs- och systemändringar.

Ett litet register slår mycket panik

För Hammer-kunder brukar den bästa första versionen vara ganska tråkig: ett dokument eller kalkylblad med modell-ID, leverantör, var ID:t används, ägare, fallback, senaste testdatum och nästa kända avstängningsdatum. Inte perfekt. Bara tillräckligt tydligt för att någon ska kunna agera.

Det är också en bra Tool Forge-fråga. Om AI redan är inbyggt i formulär, ärendehantering, rapporter eller kundflöden kan Hammer hjälpa till att hitta modellsträngarna, bygga ett testpaket och göra bytet mindre dramatiskt. Poängen är inte att jaga varje ny modell. Poängen är att slippa upptäcka gamla modeller genom trasiga flöden.