A kiindulópont
Ez nem incidens, hanem nyilvános menetrend
A vállalati IT hozzászokott ahhoz, hogy egy szoftververzió évekig fut. Ha valami elavul, arról hosszú átállási időszak szól, kiterjedt migrációs projekttel és szállítói támogatással. Az AI modelleknél ez egészen máshogy működik, és ezt a különbséget a legtöbb cégnél még senki nem fordította le házi szabályra.
A szállítók rendszeresen kivezetik a régebbi modelleket, mert az inferencia kapacitást az újakra kell felszabadítani. Ez nem üzemzavar és nem is meglepetés. Nyilvános, dokumentált és dátumozott folyamat, ami a szállító weboldalán bárki számára elolvasható. Az Anthropic dokumentációja szerint 2026 első felében a Claude Sonnet 3.7 februárban, a Claude Sonnet 4 és a Claude Opus 4 júniusban, a Claude Opus 4.1 pedig augusztusban került ki a kínálatból. Mindegyik esetben legalább hatvan nap előzetes értesítéssel.
A ciklus ráadásul rövidül. Néhány éve egy vállalati szoftver generációváltása többéves eseménynek számított. A nagy nyelvi modelleknél ma nagyjából negyedévente jelenik meg új generáció, és a régi nem marad velünk örökre. Aki 2024-ben épített egy folyamatot, az azóta jó eséllyel már kétszer is átesett volna egy váltáson. Ha nem esett át, az nem azt jelenti, hogy megúszta, hanem azt, hogy a rendszer még mindig a legrégebbi elérhető modellen fut.
A hatvan nap bőven elég idő. Pontosan addig elég, amíg valaki a cégben tudja, hogy a levél róla szól. Amit én látok a projektekben, az az, hogy a levél a fejlesztői postafiókba érkezik, a következmény pedig három osztállyal arrébb jelentkezik.
Fogalmak
Négy állapot, amit a vezetőnek is ismernie kell
A modell életciklusa négy szakaszra bomlik, és ezek üzletileg teljesen mást jelentenek. Az első az aktív állapot, amikor a modell teljes támogatást kap és ajánlott a használata. A második a legacy, ami annyit tesz, hogy a modell már nem kap frissítést, de még fut. A harmadik a deprecated, vagyis visszavonás alatt álló. Ilyenkor a modell még működik, de a szállító már nem ajánlja, megnevezi a javasolt utódot, és kitűz egy visszavonási dátumot. A negyedik a retired, amikor a modell megszűnik. Az erre a névre küldött kérés ettől kezdve hibára fut.
Azt tapasztaltam, hogy a cégek a harmadik és a negyedik szakasz közti különbséget nem érzik át. A deprecated állapotot hallva mindenki megnyugszik, mert még minden működik. Semmi nem áll le, a mérőszámok nem romlanak, a felhasználók nem panaszkodnak. Ez a hatvan nap tökéletesen csendes. Ezért nem is történik semmi benne.
Van ennek egy második rétege is. A visszavonás alatt álló modellek jellemzően kevésbé megbízhatóak, mint az aktívak. Tehát még a leállás előtt is romolhat a minőség, csak épp olyan fokozatosan, hogy senki nem köti a bejelentéshez. Az egyik ügyfelemnél két hónapig kerestük egy dokumentumfeldolgozó folyamat lassú minőségromlásának okát, mielőtt kiderült, hogy egyszerűen a modell volt kivezetés alatt.
A valódi kockázat
Nem a chat felület fáj, hanem a beégetett modellnév
Ha a cégedben kétszáz ember használ egy AI asszisztenst a böngészőben, a modellváltásból ők semmit nem vesznek észre. A szállító a felület mögött lecseréli az alapmodellt, és a munka megy tovább. Ez a réteg gyakorlatilag védett.
A baj ott van, ahol egy konkrét modellnév beleíródott valamibe. Egy 400 fős logisztikai cégnél amikor ezt végigvettük, négy ilyen helyet találtunk, és a felsővezetés egyikről sem tudott.
Az első a régi kísérlet, ami észrevétlenül élesbe ment. Valaki tavaly összerakott egy prototípust, jól működött, rákötötték egy napi riportra, és soha senki nem minősítette éles rendszerré. A második a beszállító terméke, amiben nem is látod a modellnevet, mert a szoftver belsejében van. Itt nem te kapod az értesítést, hanem a beszállító, és a te kockázatod az, hogy ő mikor lép. A harmadik az adatelemző saját szkriptje, ami hónapok óta ugyanazt a heti kimutatást tolja a vezetői riportba. A negyedik a low-code automatizáció, amit egy lelkes kolléga kattintott össze, és ahol a modell egy legördülő menü kiválasztott eleme.
Ezt a négyet érdemes külön kezelni, mert eltérő a kockázati profiljuk. Az első kettőnél te látod a modellnevet, tehát a leltárban megtalálod. A harmadiknál és a negyediknél a modellnév olyan helyen ül, ahová a központi IT nem lát be, mert a rendszer nem az ő nyilvántartásában van. A logisztikai cégnél a heti vezetői kimutatást előállító szkriptről csak azért derült ki, hogy AI hívást tartalmaz, mert megkérdeztük a kollégát, aki készítette.
Ebből a projektből azt tanultam, hogy a kérdés nem technikai, hanem tulajdonosi. Egyik helynek sem volt gazdája. Mind a négyet valaki lelkesedésből építette, és senki nem vette át üzemeltetésre.
Beszerzési vakfolt
Ugyanaz a modell, két különböző lejárati dátum
Van egy részlet, ami a beszerzési oldalon szinte mindig kiesik. A szállító saját platformján érvényes visszavonási dátum nem feltétlenül azonos azzal, ami a partnerplatformokon érvényes. Az Anthropic dokumentációja külön kiemeli, hogy az Amazon Bedrock és a Google Cloud saját menetrendet állít fel. Ugyanaz a modellnév ott más időpontban jár le.
Az egyik pénzügyi holding kontrolling csapatánál pontosan ez okozott zavart. A beszerzés a szállító hivatalos oldaláról olvasta ki a dátumot, és nyugodtan tervezett. A fejlesztés viszont Bedrocköt használt, ahol más ütem élt. Két különböző igazság volt egyszerre az asztalon, mindkettő helyes, csak nem ugyanarra a felületre vonatkozott.
Ez a fajta eltérés a szerződéskötésnél kezelhető a legolcsóbban. Ha egyszer belekerül a keretszerződésbe, hogy a szállító melyik felületre milyen értesítési határidőt vállal, akkor a beszerzés nem szállítót választ többé, hanem menetrendet is vásárol hozzá.
Időzítés
Ne a határidő utolsó hetében válts
Amikor a hatvan napos értesítő megérkezik, a legtöbb helyen az első reakció az, hogy ez ráér. Ez logikusnak tűnik, hiszen a régi modell még dolgozik, az új pedig nem hoz azonnali üzleti hasznot. A gond az, hogy a váltás nem egy művelet, hanem több egymás utáni lépés, és mindegyiknek átfutási ideje van.
Az egyik ügyfelemnél kialakítottunk erre egy egyszerű ütemezést, ami azóta is tartja magát. Az első két hétben megvan a leltár és eldől, mely rendszereket érinti a változás. A következő két hétben lefut a regressziós teszt az új modellel, párhuzamosan a régivel, azonos bemeneteken. Az ötödik és hatodik héten megy át az éles forgalom, először a kevésbé kritikus folyamatoknál. Az utolsó két hét pedig tartalék, mert mindig van valami, ami nem a terv szerint alakul.
Ez az ütemezés két dolgot old meg. Az egyik, hogy a párhuzamos futás alatt van összehasonlítási alapod. Ha az új modell máshogy viselkedik egy adott ügytípusnál, azt élesben látod, nem utólag a panaszokból. A másik, hogy a tartalékhét miatt a váltás nem esik egybe egy zárási időszakkal vagy egy kampánycsúccsal. Azt tapasztaltam, hogy a modellváltásokból származó valódi üzleti kár szinte mindig nem magából a váltásból jött, hanem abból, hogy rossz héten történt.
Amiről kevesen beszélnek
Nem csak a modell tűnik el, a beállítás is
A modellváltás sokszor nem egyszerű névcsere. A szállítók a régi vezérlőparamétereket is kivezetik, ha az új generációnál már nincs értelmük. Az Anthropic például a Claude Opus 4.7-től kezdve a temperature, a top_p és a top_k paraméterek beállítását hibával utasítja vissza, ha valaki nem az alapértéket adja meg. Aki ezeket a kódjában hagyta, annál a váltás nem attól függ, hogy átírja-e a modell nevét.
Ez azért figyelemre méltó, mert ellentétes az intuícióval. A csapat felkészül a nagy dologra, a modell cseréjére, aztán elesik egy paraméteren, amiről már évek óta nem gondolkodott senki. Amikor ezt egy ügyfelemnél elvégeztük, a tényleges modellcsere húsz percbe telt, a paraméterek és a promptok utánigazítása pedig másfél napba.
Ugyanez igaz a prompt szintjén is. Egy új modell máshogy reagál ugyanarra a megfogalmazásra. Nem rosszabbul, csak másképp. Ha a kimenetre bármilyen automatizmus épül, például egy strukturált mező kiolvasása, akkor ez a másképp önmagában elég a töréshez.
Gyakorlat
Négy lépés, ami hatvan napból húsz percet csinál
Az első a leltár. A legtöbb szállítói konzolon exportálható a használat kulcsonkénti és modellenkénti bontásban. Ez egyetlen táblázat, amiből azonnal látszik, hol fut még régi modell. Ezt negyedévente újra le kell futtatni, mert a lista folyamatosan változik.
A második a gazda. Minden modellfüggő rendszerhez tartozzon egy név. Nem csapat, nem osztály, hanem egy ember, aki megkapja a szállítói értesítést és felelős a váltásért. Ez az egyetlen pont, ami nélkül a másik három nem működik.
A harmadik a regressziós készlet, és szerintem ez hozza a legtöbbet. Harminc vagy ötven valós eset a saját üzletedből, mindegyikhez az elvárt kimenet. Ha ez megvan, akkor egy modellváltás nem hit kérdése, hanem lefuttatsz egy tesztet és megnézed az eredményt. Egy 35 fős kreatív ügynökségnél ennek az összeállítása másfél napba került, és azóta minden váltás fél napos rutinfeladat, nem pedig kockázati esemény.
A negyedik a szerződés. A keretszerződésbe bekerülhet, hogy a szállító hány nappal korábban értesít, milyen felületekre vonatkozik a vállalás, és van-e párhuzamos futási időszak, amikor a régi és az új modell egyszerre elérhető. Egy McKinsey elemzés is megerősítette, amit a magyar piacon is látok, hogy a nagyvállalatok jelentősen gyorsabban skálázzák az AI-t, mint a kisebb szervezetek. Ez a szakadék részben pont ilyen üzemeltetési apróságokon nyílik.
Zárás
A modell súlyai megmaradnak, a te rendszered nem
Az Anthropic 2025 novemberében kötelezettséget vállalt arra, hogy a nyilvánosan kiadott modellek súlyait megőrzi, legalább a cég fennállásának idejéig, és a visszavonás előtt dokumentált folyamatot futtat le. A Claude Opus 3 nyugdíjazása 2026 januárjában már e szerint zajlott, és az a modell azóta is elérhető maradt az előfizetőknek.
Ez a szállító oldaláról szép és felelős gyakorlat, de a te folyamatodra nézve nem véd meg semmitől. A súlyok megőrzése nem azonos azzal, hogy a te API hívásod holnap is lefut. Ha egy éles vállalati folyamat egyetlen modellnévre támaszkodik, akkor az a folyamat egy külső ütemtervhez van kötve, amit nem te írsz.
Ez a kockázat egyébként nem szól a felhő ellen és nem a helyi modellek melletti érv. A helyben futtatott nyílt súlyú modell sem véd meg tőle, csak áthelyezi a terhet. Ott te felelsz azért, hogy a modell ne maradjon karbantartás nélkül, és tapasztalatom szerint ez a felelősség sokkal könnyebben felejtődik el, mint egy szállítói értesítő.
A gyakorlati következtetés ennyi. Az AI rendszer nem beruházás, hanem üzemeltetett eszköz, aminek karbantartási ciklusa van, ugyanúgy, ahogy a szervernek vagy a céges autónak. Aki így tervez, annál a következő visszavonási értesítő egy naptárbejegyzés lesz. Aki nem, annál egy hétfő reggel.
kdconsulting.hu · [email protected]