Mi történik, ha az AI-rendszer elromlik? Üzemeltetés és felelősség
Mi jön az átadás után, és mi történik, ha egy élő AI-rendszer megáll? Sorra vesszük, mi szokott elromlani, hogyan veszed észre időben, és mit kell előre a szerződésbe írni.
Röviden
- Egy élő AI-rendszert öt dolog szokott megállítani: a mögöttes modell kivezetése, egy API vagy kapcsolódó rendszer változása, romló bemeneti adat, a válaszok lassú elcsúszása, és az a hiba, amiről senki nem kap jelzést.
- A modellek kivezetése rendszeres: az Anthropic 2025 óta több mint tíz modell kivezetését jelentette be, legalább 60 napos előzetes értesítéssel. Az értesítést viszont az kapja, akinek a nevén a fejlesztői fiók van.
- Az AI akkor is változhat, ha senki nem nyúl hozzá: egy 2023-as kutatásban ugyanaz a modellnév három hónap alatt 84%-ról 51%-ra rontott egy feladaton.
- A felépítés a munka kisebbik része. A mi tapasztalatunk szerint nagyjából 40% az építés és 60% a karbantartás, a finomhangolás és a figyelés.
- A szerződésben rögzítsd, kinek a nevén vannak a fiókok, ki veszi észre a hibát, mennyi idő alatt áll helyre a rendszer, és hogyan viheted el, ha váltasz.
Tartalom
- Mi romlik el egy AI-rendszerben élesben?
- Mi történik, ha kivezetik a mögöttes AI-modellt?
- Változhat-e az AI akkor is, ha senki nem nyúl hozzá?
- Mit jelent a monitorozás egy AI-rendszernél?
- Egy valós eset: amikor egy AI-levelező egyik napról a másikra leállt
- Miért a karbantartás a munka nagyobb része?
- Ki a felelős, ha az AI-rendszer hibázik?
- Mit kérj a szerződésben az üzemeltetésről?
- Hogyan üzemeltetjük mi az ügyfeleink rendszereit?
Egy élesben futó AI-rendszer ritkán azért áll le, mert rossz a kódja. Azért áll le, mert megváltozik körülötte valami: kivezetik a mögötte futó AI-modellt, módosul egy kapcsolódó rendszer, romlik a bejövő adat, vagy lassan elcsúsznak a válaszai. Az üzemeltetés az a munka, ami ezt előbb veszi észre, mint az ügyfeled, és helyreállítja, mielőtt kár keletkezik. Nálunk ez a munka nagyobbik fele.
Ezt a cikket annak írom, aki már eldöntötte, hogy AI-rendszert vezet be, és most azt akarja tudni, mi jön az átadás után. Ha még a döntés előtt állsz, a mesterséges intelligencia bevezetése egy kkv-nál című útmutatónk a teljes utat leírja. Itt a harmadik hónapról lesz szó, nem az elsőről.
Mi romlik el egy AI-rendszerben élesben?
Egy élesben futó AI-rendszerben öt dolog szokott elromlani: a mögöttes modellt kivezetik, egy API vagy kapcsolódó rendszer megváltozik, a bemeneti adat minősége romlik, a válaszok lassan elcsúsznak, és a legrosszabb: valami elromlik, de senki nem kap róla jelzést. Az első kettő hirtelen jön, a következő kettő lassan, az ötödik pedig bármelyiket órákig vagy napokig láthatatlanná teszi.
| Mi romlik el | Mi történik | Hogyan veszed észre | Mit csinál az üzemeltető |
|---|---|---|---|
| Modell-kivezetés | A szolgáltató megszünteti a modellt vagy a felületet, a kérések hibát adnak | Ha senki nem figyeli a kivezetési naptárat: amikor leáll | Előre teszteli az utódmodellt, és határidő előtt átköltöztet |
| API- vagy integrációváltozás | Egy mező átnevezése, egy paraméter tiltása, egy lejárt jelszó | A folyamat egy ponton megáll, gyakran hibaüzenet nélkül | Napi szintetikus próbával észreveszi, javítja a kapcsolatot |
| Romló bemeneti adat | Új számlaformátum, új termék, ami nincs a tudásbázisban | Több kivétel, furcsa válaszok | Frissíti a tudásbázist, szabályt vagy példát ad hozzá |
| Elcsúszó válaszok | A válaszok hangja vagy pontossága lassan romlik | Csak mintavétellel: a panasz későn jön | Rendszeresen visszaméri a mintákat, finomhangol |
| Csendes hiba | A rendszer „fut”, de nem dolgozik | Sehogy, amíg valaki rá nem kérdez | Riasztást épít arra is, ha nem történik semmi |
Mi történik, ha kivezetik a mögöttes AI-modellt?
A nagy modellszolgáltatók rendszeresen kivezetik a régebbi modelljeiket, és a kivezetés után az azokra küldött kérések egyszerűen hibát adnak. Az Anthropic dokumentációja szerint a nyilvános modellek kivezetéséről legalább 60 nappal előre értesíti az érintett ügyfeleit. Az OpenAI saját szabálya szerint az általánosan elérhető modelleknél legalább hat hónapot ad, a speciális változatoknál legalább hármat, az előzetes (preview) modelleknél akár csak két hetet. Egy teljes fejlesztői felület, az Assistants API megszüntetésére egy év átmenetet adott.
Két dolgot érdemes ebből megérteni. Az egyik, hogy ez nem kivételes esemény, hanem a működés része: az Anthropic listáján csak 2025 és 2026 között több mint tíz modell került kivezetett vagy kivezetés alatt álló státuszba. A másik, hogy az értesítést az kapja, akinek a nevén a fejlesztői fiók van. Ha ez a fiók a szolgáltatód nevén fut, te akkor tudod meg, amikor a rendszer leáll.
A költöztetés sem csak egy szó átírása a kódban. Az új modell másképp fogalmaz, máshogy követi az utasításokat, és néha a régi beállításokat sem fogadja el. Az Anthropic például a 4.7-es és újabb Claude-modelleknél hibával utasítja el a kérést, ha a régi modellek egyik gyakori beállítását (a temperature paramétert) nem alapértéken küldik. Egy régi, változatlan kód így az új modellen az első hívásnál elakad. Ezért kell az utódmodellt a határidő előtt a saját valós példáidon tesztelni.
Változhat-e az AI akkor is, ha senki nem nyúl hozzá?
Igen. Egy szolgáltatói modellnév mögött idővel változhat a viselkedés, és a te promptod, a te szabályaid ugyanazok maradnak. A Stanford és a Berkeley kutatói 2023-ban ugyanazt a feladatsort futtatták ugyanazon a modellnéven márciusban és júniusban. A prímszámok felismerésében a pontosság 84%-ról 51%-ra esett, és romlott az utasításkövetés is.
A szerzők következtetése egyszerű: ugyanaz a nyelvi modell-szolgáltatás viszonylag rövid idő alatt jelentősen megváltozhat, ezért folyamatosan mérni kell. Üzleti nyelvre fordítva: egy AI-levelező, ami tavasszal kifogástalanul válaszolt, ősszel kicsit hosszabban, kicsit hivatalosabban, kicsit pontatlanabbul írhat. Egyetlen nap alatt ez nem tűnik fel senkinek. Három hónap alatt az ügyfeleidnek igen.
Ide tartozik a te oldaladon történő elcsúszás is. Új termék, új árlista, új szabály a cégben, ami nem került be a tudásbázisba. A rendszer ilyenkor a régi tudásával válaszol, magabiztosan.
Mit jelent a monitorozás egy AI-rendszernél?
A monitorozás egy AI-rendszernél nem csak annak figyelése, hogy fut-e. Azt is figyelni kell, hogy jól dolgozik-e, és hogy egyáltalán dolgozik-e. Egy hagyományos program vagy működik, vagy hibát dob. Egy AI-rendszer működhet úgy is, hogy közben rossz választ ad, vagy csendben nem csinál semmit. Ezért több réteg kell.
- Szintetikus próba. Naponta egy kitalált teszteset végigmegy a teljes folyamaton: egy próbalevél, egy próbahívás, egy próbaszámla. Ha nem ér célba, riasztás megy.
- Riasztás a csendre is. Ha egy rendszerben, ahol naponta jönnek levelek, hat órán át nem történik semmi, az nem nyugalom, hanem gyanú.
- Minőségi mintavétel. Hetente néhány valós kimenetet ember néz át ugyanazok szerint a szempontok szerint, és a pontszám idősorát figyeli.
- Költség- és korlátfigyelés. A modellhasználatnak van keretje. Ha elfogy, a rendszer leáll vagy gyengébb módba vált. Ezt előbb kell tudni, mint hogy bekövetkezik.
- Kivezetési naptár. Minden használt modell és szolgáltatás kivezetési dátuma egy helyen, időben ütemezett költöztetéssel.
A második és a negyedik pontot a saját bőrünkön tanultuk meg. A saját cégünket is AI-ügynökök viszik, és egyszer az egyikük kifutott a használati keretéből. Kívülről úgy tűnt, csak csendes nap van, közben órákig nem dolgozott, és a hibát először rossz helyen kerestük. Azóta a keret kifogyására is riasztás megy. Nem az a baj, hogy valami elromlik. Az a baj, ha nem szól.
Egy valós eset: amikor egy AI-levelező egyik napról a másikra leállt
A Profitszakértő Kft. ügyfélszolgálati leveleit egy korábbi szolgáltató által épített AI-rendszer kezelte. Ez a rendszer egyik napról a másikra leállt, mert a mögöttes technológiát kivezették. Még aznap átvettük, elmentettük a teljes beállítást, visszaállítottuk a működését, és erősebb AI-motorra költöztettük. Azóta minden bejövő levelet kategorizál, és személyre szabott választervezetet ír.
Ott nem új rendszer épült: a meglévőt mentettük meg, költöztettük át és finomítottuk. Szendrei Ádám cégvezető szavaival: „Az elkészült válaszok azóta sokkal pontosabbak, barátságosabbak és emberibbek.” Szabó Éva ehhez hozzátette, hogy a válaszok „minimális emberi beavatkozást igényelnek”. A részletek az esettanulmányban vannak.
Ilyenkor a sorrend számít. Első a mentés: minden beállítás, szabály, sablon és példa, amíg még hozzáférünk. Második a működés visszaállítása, mert közben jönnek a levelek. A költöztetés csak harmadik. Ami ilyenkor eldönti, hogy órák vagy hetek kellenek: le van-e írva, mit csinált a rendszer, és kinek a nevén vannak a fiókok. Ahol ez megvan, ott egy másik csapat is gyorsan átveszi. Ahol nincs, ott a rendszert a viselkedéséből kell visszafejteni.
Hudácsek Bence Társalapító, CTO · AutomatingMiért a karbantartás a munka nagyobb része?
Mert az építés egyszer történik meg, a világ viszont folyamatosan változik a rendszer körül. A mi tapasztalatunk szerint egy AI-rendszer felépítése a munka nagyjából 40%-a, a karbantartás, a finomhangolás és a figyelés a maradék 60%. Ettől lesz fél év múlva is ugyanolyan pontos, mint az első napon. Nem attól, hogy a rendszer magától tanul.
A karbantartás a gyakorlatban unalmas és konkrét munka: a kivételek átnézése, a tudásbázis frissítése, amikor új termék vagy új szabály jön, a válaszminták visszamérése, a modellek költöztetése a határidő előtt, és az integrációk javítása, amikor egy kapcsolódó rendszer frissül. Aki ezt nem kéri vagy nem kapja meg, az nem spórol vele, csak később fizeti meg, egyszerre.
Ki a felelős, ha az AI-rendszer hibázik?
Az ügyféllel szemben a cég felel, amelyik az AI-rendszert használja, nem a szoftver és nem a szolgáltató. A szolgáltatóval szemben az számít, ami a szerződésben áll. Ha a rendszer személyes adatot kezel, és ez a legtöbb ügyfélszolgálati és értékesítési rendszerre igaz, a GDPR szerint a szolgáltató adatfeldolgozó, és vele írásos adatfeldolgozói szerződést kell kötni.
A GDPR 28. cikke előírja, mi legyen ebben a szerződésben: a szolgáltató csak a te dokumentált utasításod szerint kezelheti az adatokat, gondoskodik a biztonságukról, csak a hozzájárulásoddal vonhat be további feldolgozót, és a szerződés végén törli vagy visszaadja az adatokat. A 33. cikk szerint adatvédelmi incidensnél a szolgáltatónak indokolatlan késedelem nélkül szólnia kell neked, neked pedig főszabály szerint 72 órán belül a hatóságnak, Magyarországon a NAIH-nak. Az adatvédelmi kérdéseket részletesen az AI és a GDPR kapcsolatáról szóló cikkünk bontja ki.
Mit kérj a szerződésben az üzemeltetésről?
A szerződésben öt dolgot rögzíts előre: kinek a nevén vannak a fiókok és az adatok, ki veszi észre a hibát és milyen gyorsan reagál, mi történik modell-kivezetéskor, mit tartalmaz a havi díj, és hogyan viheted el a rendszert, ha váltasz. Ezek nélkül az üzemeltetés ígéret marad, nem kötelezettség.
| Kérdés | Miért fontos | Jó válasz |
|---|---|---|
| Kinek a nevén vannak az AI- és egyéb fiókok? | A kivezetési értesítés oda megy, és a hozzáférés is | A te cégeden, vagy dokumentált átadással |
| Ki veszi észre a hibát? | A csendes hiba a legdrágább | Automatikus figyelés és riasztás, nem a te panaszod |
| Mennyi idő alatt reagál, és mennyi alatt áll helyre? | A „hamarosan” nem határidő | Konkrét reakcióidő, munkanapra vagy órára |
| Mi történik modell-kivezetéskor? | Biztosan be fog következni | Előzetes teszt és költöztetés, benne a havi díjban |
| Mit tartalmaz a havi díj? | Futási költség és karbantartás külön mozog | Tételes bontás |
| Exportálható-e minden? | Ettől függ, hogy válthatsz-e | Beállítások, szabályok, tudásbázis, előzmények: igen |
| Van-e adatfeldolgozói szerződés? | GDPR 28. cikk | Igen, aláírva, az alvállalkozók listájával |
Ha több szolgáltató közül választasz, ezek a kérdések jól beférnek abba a listába, amit az AI ügynökség kiválasztásáról szóló cikkünk ad. Az üzemeltetés díját pedig ne külön nézd, hanem a teljes megtérülés részeként: az AI megtérülésének kiszámításáról szóló cikkünk a havi költséget is beszámítja.
Hogyan üzemeltetjük mi az ügyfeleink rendszereit?
Ugyanazokból a rétegekből, amiket fent leírtunk: szintetikus próba, riasztás a hibára és a csendre, költségfigyelés, és kivezetési naptár minden használt modellre. Az ügyfél oldalán kijelölünk egy embert, aki a kivételeket kapja, és rendszeresen átnézzük vele, mit kezelt a rendszer, hol hibázott, mit kell frissíteni. A rendszer és a tudásbázis az ügyfélé, exportálható, és le van írva, mit csinál, hogy bárki át tudja venni. A Profitszakértőnél is az döntött, hogy a teljes beállítás még elérhető és menthető volt: ezért működött újra még aznap.
Gyakori kérdések
Mennyibe kerül egy AI-rendszer üzemeltetése havonta?
Két részből áll: a futási költségből (AI-modell használata, telefonpercek, szerver) és a karbantartásból (figyelés, frissítés, finomhangolás). A futási rész a forgalommal arányos, a karbantartás inkább fix. Kérd tételesen, hogy lásd, melyik mennyi, és hogy a forgalom növekedése mit jelent. A teljes költségszerkezetről a bevezetés áráról szóló cikkünk ír.
Mi történik, ha a szolgáltató, aki megépítette, eltűnik?
Ha a fiókok a te cégeden vannak, a beállítások, a szabályok és a tudásbázis dokumentálva és exportálhatók, akkor egy másik csapat át tudja venni, akár napon belül. Ha minden a szolgáltató nevén van, a rendszer vele együtt tűnik el. Ezért ez a legfontosabb szerződéses pont.
Kell-e saját embert kijelölni az AI-rendszer mellé?
Igen, egy embert, aki tudja, mit kell csinálnia a rendszernek, megkapja a kivételeket, és szól, ha valami furcsa. Nem kell informatikusnak lennie. Gazdája kell, nem rendszergazdája.
Tanul magától az AI-rendszer a hibáiból?
A mai üzleti AI-rendszerek többsége nem tanul magától élesben. Amit javulásnak látsz, az a karbantartás: valaki átnézi a hibákat, és módosítja a szabályokat, a példákat vagy a tudásbázist. Ha ezt senki nem csinálja, a rendszer nem javul, hanem lassan elcsúszik.
Források
- Model deprecations, Anthropic (2026-09-30)
- Deprecations, OpenAI (2026-10)
- How is ChatGPT's behavior changing over time?, Lingjiao Chen, Matei Zaharia, James Zou (Stanford, UC Berkeley), arXiv (2023-10-31)
- Az Európai Parlament és a Tanács (EU) 2016/679 rendelete (GDPR), 28. és 33. cikk, EUR-Lex (2016-04-27)
Utolsó tartalmi frissítés: 2026. október 4.
Homoki Gábor · 10 perc