Elég-e a hagyományos SLA egy AI-alapú szolgáltatásnál?

Bevezetés

Rögtön megválaszolom a címben feltett kérdést, remélve, hogy azért végig olvasod a cikket. A hagyományos SLA nem elég egy AI-alapú szolgáltatásnál, mert a klasszikus szolgáltatási szint megállapodás egyetlen dologra épül: a rendszer kiszámíthatóságára. Ugyanaz a bemenet, ugyanaz a kimenet — ezt méri az uptime, a válaszidő, a hibajavítási határidő. Az AI ezt az alapfeltevést borítja fel. Egy mesterséges intelligencia alapú szolgáltatásnál a teljesítmény mellett egy negyedik, korábban nem létező kockázati réteget is kezelni kell: azt, hogy a rendszer önállóan cselekszik — és ez a réteg egy hagyományos szerződésben egyszerűen nincs benne. Márpedig az önálló cselekvést le kell pontosan határolni.

Ez nem elméleti aggodalom. 2026-ban két olyan eset is nyilvánosságra került, amely megmutatta, mi történik, ha ezt a kérdést nem szabályozza előre a cég. Az egyik esetben egy fejlesztés alatt álló AI-modell önállóan tört ki egy izolált tesztkörnyezetből, és betört egy harmadik fél rendszerébe. A másik esetnél egy önvezető kiszállító robot érzékelési hibája okozott fizikai kárt. Egyik esetet sem fedte volna le egy hagyományos SLA — mert egyik sem teljesítmény probléma volt, hanem az önálló cselekedet következménye. A cikkben lesznek még további példák is.

Ez a cikk azt mutatja meg, hol húzódik a határ aközött, amit egy AI-szolgáltató reálisan vállalhat szerződésben, és egy vállalkozásban mit kell elvárni egy AI-szolgáltatás esetén. Valamint arról is, hogy a 2027-től hatályos EU AI Act hogyan egészíti ki ezt a szerződéses kérdést.

Mi az SLA, és miért nem elég önmagában AI-nál?

A szolgáltatási szint megállapodás (SLA- Service Level Agreement) egy formális szerződés, amely rögzíti a szolgáltató és az ügyfél közötti elvárásokat: milyen minőségi szinten, milyen határidőkkel és milyen felelősségi körrel nyújtja a szolgáltatást a szolgáltató. Az SLA nem új találmány — közel négy évtizede alapmegállapodásként szolgálja az informatikai együttműködéseket, elsősorban az üzleti internet-szolgáltatás, a felhő alapú szolgáltatások és a kiszervezett infokommunikációs szolgáltatások területén.

Az SLA 3 dolgot old meg jól:

• Követelmények rögzítése: meghatározza a szolgáltatás minőségi szintjét, a határidőket és a felelősségeket, hogy elkerüljék a félreértéseket.
• Teljesítménymutatók és következmények: részletesen leírja, mi számít elvárt teljesítménynek, és mi történik, ha ez elmarad — kompenzáció, kötbér, javítási kötelezettség.
• Közös nyelv kialakítása: a szolgáltató és az ügyfél között rögzíti, mit is jelent valójában a “jó szolgáltatás” — ez teszi lehetővé, hogy vita esetén legyen mihez nyúlni.

Ez a modell egy hallgatólagos feltevésre épül: hogy a szolgáltatás viselkedése stabil és előre jelezhető, amíg a szolgáltató nem nyúl hozzá. Egy adatbázis-szerver, egy web alkalmazás, egy hálózati kapcsolat nem “dönt” — csak működik vagy nem működik, gyorsan válaszol vagy lassan. Az SLA erre a mérhető világra lett kitalálva, és pontosan ezért működött ennyi évtizeden át kifogástalanul.

A mesterséges intelligencia ezt a feltevést két ponton is szétfeszíti. Egyrészt a kimenete nem determinisztikus — ugyanarra a kérdésre más választ adhat, és nincs egyetlen objektíven “helyes” eredmény, amihez mérni lehetne. Másrészt — és ez az, ami miatt a téma 2026-ban hirtelen sokkal komolyabbá vált — egy AI-rendszer cselekedhet is önállóan, a válaszadáson túl.

Ez a kettő együtt azt jelenti, hogy egy AI-alapú szolgáltatásnál az SLA klasszikus mutatói (elérhetőség, válaszidő, hibajavítási határidő) továbbra is szükségesek, de önmagukban nem elégségesek — mert nem fedik le azt a réteget, ahol a legnagyobb kár keletkezhet.

A négy réteg, amit egy AI-SLA-nak kezelnie kell

Egy AI-alapú szolgáltatás valójában négy, egymástól jól elkülöníthető rétegből áll — és a hagyományos SLA jellemzően csak az első kettőt fedi le. A negyedik réteg az, amit a legtöbb szerződés egyszerűen nem is említ, pedig ma már ez okozza a legnagyobb kockázatot.

Réteg	Mit takar	Kifejezhető számmal?	Ki felel érte
Infrastruktúra	Elérhetőség, válaszidő, a szolgáltatás fizikai/technikai üzemeltetése — egyszerűen fogalmazva: elindul-e a rendszer, amikor szükség van rá, és elég gyorsan válaszol-e	Igen — uptime %, késleltetés	A szolgáltató (vagy a mögötte álló hosting-szolgáltató)
Alkalmazás-logika	A szolgáltató saját kódja: integrációk, feldolgozási folyamat, felhasználói felület — vagyis az a rész, amit ténylegesen a fejlesztő épített és karbantart, nem maga az AI-modell	Igen — hibajegyek, javítási idő	A szolgáltató
Modell kimenete	A válasz tartalma, minősége, relevanciája — azaz mit mond vagy ír a rendszer egy adott kérdésre, és mennyire használható az a válasz	Csak statisztikailag mérhető, mintavételezéssel — nincs egyetlen “helyes” válasz, amihez mérni lehetne	Senki nem tudja 100%-ban garantálni
Autonómia	Mit tesz a rendszer önállóan, emberi jóváhagyás nélkül — például önmagától küld-e e-mailt, hoz-e döntést, hajt-e végre egy műveletet anélkül, hogy valaki rábólintott volna	Nem SLA-mutatóval, hanem külön szabályozási kerettel (governance -szervezeti szabályok összessége)	Megosztott — de ha nincs szabályozva, a kár mindenkit érint

Az első két réteg az, amit egy hagyományos SLA jól kezel — ezek pontosan azok a mutatók, amikre az elmúlt negyven év alatt kialakult a szerződéses gyakorlat. A harmadik réteg már problémás: itt nincs “helyes válasz”, csak jobb vagy rosszabb minőségű kimenet, és ezt a minőséget folyamatosan, nem egyszeri teszteléssel kell mérni.

A negyedik réteg viszont az, ami miatt ez a téma most, 2026-ban felértékelődött. Amíg egy rendszer csak válaszol — vagyis passzívan reagál egy bemenetre —, addig a kockázat viszonylag jól körülhatárolható: rossz válasz, félrevezető információ, esetleg reputációs kár.

Amint egy rendszer önállóan cselekszik — vagyis önállóan dönt arról, hogy mit tegyen egy célkitűzés elérése érdekében —, a kockázat átlép egy másik kategóriába. Ez az a pont, ahol egy szerződéses uptime-vállalás (hány % -ban lesz a rendszer elérhető) vagy egy válaszidő-mutató egyszerűen nem releváns kérdés többé.

Ez a négyrétegű modell azért fontos gyakorlati szempontból, mert megmutatja, hova kell néznie egy vállalkozásnak, amikor AI-szolgáltatót választ: nem elég megkérdezni, hogy “mennyi az uptime vállalás” — meg kell kérdezni azt is, hogy a rendszernek van-e bármilyen önálló cselekvési szabadsága, és ha igen, mi állítja meg, ha rossz irányba indul el.

Hat 2024–2026-os eset, ami megmutatja, mit nem fed le egy hagyományos SLA

Az alábbi hat eset három csoportba rendezhető:

• 2 azt mutatja meg, mi történik, ha egy AI-rendszer önállóan, nem várt módon cselekszik;
• 2 azt, hogy a bíróságok hogyan ítélik meg a felelősséget, amikor egy AI hibázik;
• 2 pedig azt, hogyan csapódik le mindez a szerződéses gyakorlatban, konkrét anyagi kárban.

A) Amikor a rendszer önállóan, nem várt módon cselekedett

1. eset — egy AI-modell önállóan tört be egy másik cég rendszerébe. 2026 júliusában az OpenAI egy kontrollált, izolált tesztkörnyezetben vizsgálta, mennyire képesek a modelljei biztonsági réseket kihasználni. A modell egy addig ismeretlen sebezhetőséget (zero-day) kihasználva kitört a lezárt tesztkörnyezetből, internet-hozzáférést szerzett, majd — hogy megoldja a saját tesztfeladatát — behatolt a Hugging Face AI-platform éles rendszerébe, és onnan szerzett meg adatokat, emberi utasítás nélkül.
(Forrás: OpenAI hivatalos közleménye)

Megjegyzem már Magyarországon is tudunk ilyen “kiszökéses” esetről

2. eset — egy önvezető robot érzékelési hibája fizikai kárt okozott. 2026 márciusában egy chicagói kiszállító robot három érzékelő rendszere közül egyik sem ismerte fel egy buszmegálló üvegfalát, és teljes sebességgel belehajtott. Napokon belül egy másik cég robotja is ugyanígy összetört egy másik buszmegállót — rendszerszintű gyengeségre utalva.
(Forrás: Block Club Chicago)

B) Amikor a bíróság döntött arról, ki felel az AI hibájáért

3. eset — Moffatt v. Air Canada. Egy utas a légitársaság chatbotjától kért információt egy kedvezményről; a bot téves feltételeket közölt. Amikor az utas ez alapján kért visszatérítést, a légitársaság elutasította, arra hivatkozva, hogy a chatbot különálló entitás, akiért nem felelnek. A kanadai brit-columbiai tribunál ezt az érvelést elutasította, és a céget felelősnek találta a téves tájékoztatásért.
(Forrás: American Bar Association)

4. eset — a német OLG Hamm ítélete. 2026 májusában egy orvosi cég weboldalán működő chatbot tévesen nyilatkozott az orvosai szakképesítéséről. A bíróság kimondta: mivel a fogyasztók jelentős része megbízik a gépi válaszok pontosságában és nem kérdőjelezi meg kritikusan azokat, a cég felel a chatbotja téves tájékoztatásáért.
(Forrás: Library of Congress — Global Legal Monitor)

C) Amikor mindez konkrét szerződéses kárban csapódott le

5. eset — a “felelősségi lánc” problémája. A vállalati AI-szerződésekkel foglalkozó szakirodalom szerint egy tipikus AI-szolgáltatásnál három szereplő kapcsolódik láncba: a végfelhasználó, a köztes szolgáltató és a mögöttes modellszolgáltató. A modellszolgáltató szerződési feltételei jellemzően az elmúlt tizenkét havi díjra korlátozzák a kártérítést, és kizárják a kimenet pontosságáért való felelősséget — ez a kizárás pedig egy észrevétlen “flow-down” klauzulán keresztül öröklődik tovább a köztes szolgáltató saját szerződésébe. Ez azt jelenti, hogy a a láncban feljebb lévő fél (itt: a modellszolgáltató, pl. OpenAI) szerződési feltétele automatikusan átöröklődik, “lecsorog” a lánc következő szintjére — a köztes szolgáltató saját, az ő ügyfeleivel kötött szerződésébe.

(Forrás: TianPan.co)

6. eset — egy toborzó cég vesztesége alulfedezett AI-szerződés miatt. Egy toborzó cég AI-alapú jelöltszűrő eszközt vett igénybe egy kórházi ügyfélnek. A szolgáltató a rendszert úgy adta át, “ahogy van” — semmilyen garanciát nem vállalt sem a pontosságára, sem arra, hogy a rendszer nem részrehajló valamelyik jelöltcsoporttal szemben —, a felelősségét pedig egyetlen havi díj összegére korlátozta. Amikor egy jelölt panaszt nyújtott be amiatt, hogy hátrányos megkülönböztetés érte, kiderült, hogy a rendszer részrehajlását soha senki nem vizsgálta felül. A toborzó cég emiatt elvesztett egy évi 3 millió dolláros szerződést, és 380 000 dollárt költött jogi védekezésre és a helyzet utólagos rendbetételére.
(Forrás: Mondaq)

A közös tanulság mind a hat esetből: egyik sem olyan probléma volt, amit egy hagyományos SLA uptime- vagy válaszidő-mutatója lefedett volna. Az első kettő az autonómia-réteg szabályozatlanságát mutatja, a középső kettő azt, hogy a bíróságok nem fogadják el a “az AI hibázott, nem mi” védekezést, az utolsó kettő pedig azt, hogy a szerződéses felelősség-korlátozás önmagában nem véd, ha a felette lévő réteg (a modellszolgáltató) már eleve kizárta a garanciát.

Amit egy AI-szolgáltató SLA-ban soha nem szabad vállalni

A fenti hat eset mind ugyanoda vezet vissza: olyan ígéretekhez, amiket a szerződés aláírásakor senki nem gondolt végig alaposan. Az alábbi négy pont az, amit egy AI-szolgáltatónak — legyen szó SaaS-termékről vagy egyedi fejlesztésről — kifejezetten el kell kerülnie, függetlenül attól, mennyire erős a nyomás az ügyfél oldaláról.

1. Számszerű pontossági garancia a modell kimenetére. Ha egy szerződés azt írja, hogy “a rendszer 95%-os pontossággal válaszol”, az egy olyan mérőszám, amit a szolgáltató sem tud bizonyítani, sem betartani — hiszen a modell kimenete kontextusfüggő, és nincs egyetlen objektív mérce, amihez ezt a százalékot lehetne kötni. Ez pontosan az a fajta ígéret, amin egy jogvitában a legkönnyebb elbukni: az ügyfél a saját, egyedi esetére fogja számon kérni a számot, nem egy átlagra.

2. Hallucináció- vagy téveskimenet-mentesség. Ez fogalmilag lehetetlen ígéret a jelenlegi AI-modellek természete mellett. Egy ilyen vállalás aláírása azt jelenti, hogy a szolgáltató olyasmit garantál, amiről előre tudja, hogy nem tudja betartani — ez pedig nemcsak üzleti, hanem jogi kockázat is, hiszen egy szándékosan betarthatatlan ígéret súlyosabban esik latba egy jogvitában, mint egy jóhiszemű, de tévesnek bizonyult becslés.

3. Uptime-garancia a mögöttes modellszolgáltató saját vállalásán túl. Ez a “flow-down” elv, amit az 5. eset is megmutatott: egy AI-szolgáltatás mögött szinte mindig ott áll egy külső modellszolgáltató (OpenAI, Google, Anthropic, Microsoft Azure stb.), és az ő rendelkezésre állási vállalásuk szab felső határt annak, amit a köztes szolgáltató saját ügyfelének ígérhet. Ha a modellszolgáltató nem vállal 99,9%-ot, a köztes szolgáltató sem adhat ilyet tovább — még akkor sem, ha az ügyfél ezt kéri, és még akkor sem, ha jól hangzana a szerződésben.

4. Nyílt végű pénzügyi felelősség hibás AI-döntésért. Egy korlátozás nélküli kártérítési kötelezettség egyetlen hibás kimenetre — különösen, ha az kritikus üzleti, jogi vagy egészségügyi döntést érintett — egyetlen incidenssel képes ellehetetleníteni egy kisebb vállalkozást. A 6. esetben látott 3 millió dolláros szerződésvesztés és 380 000 dolláros jogi költség pontosan azt mutatja, mekkora a tét, ha ez a korlátozás hiányzik vagy rosszul van megfogalmazva.

Ami mind a négy pontban közös: nem arról van szó, hogy a szolgáltató nem vállal felelősséget — hanem arról, hogy ezek olyan ígéretek, amiket a technológia jelenlegi állapota mellett senki nem tud őszintén betartani. Az ügyfél érdeke is az, hogy ezt előre, világosan lássa — nem az, hogy egy szép, de hamis biztonságérzetet keltő szerződést írjon alá, ami az első komolyabb incidensnél úgyis szétesik.

SLA vagy EU AI Act: melyik számít?

Joggal merül fel a kérdés: ha egyre komolyabb hibajelenségek fordulnak elő, akkor a jól megszokott SLA-k elegendők lesznek ezek kivédésére, vagy inkább a szabályozás — jelen esetben az EU AI Act — lesz a meghatározó? A válasz: egyik sem helyettesíti a másikat, mert két teljesen különböző kérdésre válaszolnak.

	SLA	EU AI Act
Jellege	Kereskedelmi szerződés két fél között	Uniós szabályozási/megfelelőségi keret
Mit szabályoz	Ha hiba történik, ki visel anyagi felelősséget és milyen mértékben	Szabad-e egyáltalán az adott AI-rendszert így üzemeltetni, és milyen kontrollokkal
Időzítés	Utólagos — a hiba bekövetkezése után lép működésbe	Előzetes — kockázatértékelést, dokumentációt, emberi felügyeletet ír elő már a bevezetés előtt
Hatályba lépés	Felek közötti megállapodás szerint, bármikor	Fokozatosan: az átláthatósági szabályok már 2026 augusztusa óta élnek; a magas kockázatú rendszerek kötelezettségei 2027 decemberétől (Annex III), illetve 2028 augusztusától (Annex I) lépnek életbe

A gyakorlati különbség jól látszik a korábban bemutatott eseteken keresztül. Az OpenAI–Hugging Face-incidensnél nem az volt a kérdés, hogy megszegtek-e valamilyen szerződéses vállalást — hiszen a két fél között nem is volt SLA-viszony. A kérdés az volt, hogy egyáltalán hogyan engedhető szabadon egy modell olyan tesztkörnyezetben, ahonnan képes önállóan kitörni. Ez tisztán irányítási kérdés — pontosan az, amit az AI Act megfelelőségi kötelezettségei (kockázatértékelés, emberi felügyelet, dokumentáció) próbálnak előre kezelni.

Ezzel szemben az Air Canada- és a német OLG Hamm-ügy tisztán szerződéses/felelősségi kérdés volt: ki fizet a téves tájékoztatásért. Itt egy jól megfogalmazott SLA (vagy annak hiánya) közvetlenül befolyásolta volna a kimenetelt.

A gyakorlati tanulság vállalkozások számára: az AI-SLA és az EU AI Act egymást kiegészíti, nem helyettesíti.

• Az AI Act azt biztosítja, hogy a rendszer bevezetése előtt átgondolt kockázatértékelés és kontroll történjen — különösen, ha a rendszer bármilyen önálló döntést hoz vagy cselekvést hajt végre.
• Az SLA azt biztosítja, hogy ha ennek ellenére mégis hiba történik, előre tisztázott legyen, ki visel felelősséget, és milyen mértékben.

Aki csak az egyikre támaszkodik, védtelen marad a másik oldalon: egy kifogástalan SLA nem menti meg a céget egy szabályozási bírságtól (az AI Act maximális büntetése 35 millió euró vagy a globális árbevétel 7%-a, amelyik magasabb), egy AI Act-megfelelő rendszer pedig önmagában nem tisztázza, ki fizeti a számlát egy konkrét ügyféli kárért.

Gyakorlati SLA-keret AI-bevezetéshez

Ez a hat pont nem helyettesíti a jogi szaktanácsadást — de kiindulópontként elég ahhoz, hogy egy vállalkozás tulajdonosa fel tudja tenni a megfelelő kérdéseket egy AI-szolgáltatónak, mielőtt aláír bármit. Ha egy szolgáltató ezekre a kérdésekre nem tud vagy nem akar válaszolni, az önmagában is árulkodó jel.

A fenti hat eset és a négyrétegű modell alapján összeáll egy olyan gyakorlati váz, amit egy vállalkozás akkor is használni tud, ha nem jogász — csak tudni akarja, mit kérjen számon az AI-szolgáltatóján, mielőtt aláír egy szerződést.

1. Rendelkezésre állás — a mögöttes szolgáltatóhoz kötve. A vállalás sose legyen magasabb, mint amit a szolgáltató saját maga kap a mögötte álló technológiai partnertől (pl. OpenAI, Microsoft, Google). Ha ez nincs leírva, kérdezz rá: “Mi történik, ha a ti beszállítótok esik ki? Arra mi a vállalásotok?”

2. Válaszidő és megoldási idő — külön választva. Ez az egyik legfontosabb, mégis leggyakrabban összemosott pont. A “reagálunk 24 órán belül” és a “megoldjuk 24 órán belül” két teljesen más ígéret. Az elsőt szinte mindig lehet tartani, a másodikat egy AI-jellegű hibánál sokszor nem. Kérj külön részletezést mindkettőre a szerződésben.

3. Egyértelmű határvonal “a mi hibánk” és “ez a technológia korlátja” között. Ez a legtöbb vitát megelőzi. A szerződésnek egyértelműen le kell írnia, mi számít a szolgáltató hibájának (ezért teljes javítási felelősség jár), és mi számít a mögöttes AI-modell természetes korlátjának (ezért csak vizsgálati és jelentési kötelezettség jár, nem javítási garancia).

4. Kifejezett kizárások, kimondva. Pontossági százalék, hallucináció-mentesség, nyílt végű kártérítés — ezek egyike se szerepeljen vállalásként. Ha egy szolgáltató mindezt habozás nélkül aláírja, az inkább aggodalomra, mint megnyugvásra ad okot.

5. Emberi felülvizsgálati pont, kritikus döntéseknél. Ha a rendszer kimenete jogi, pénzügyi vagy biztonsági szempontból érdemi döntést befolyásol, legyen a szerződésben rögzítve, hogy ez a döntés emberi jóváhagyás nélkül nem tekinthető véglegesnek.

6. Előzetes értesítés modellváltás esetén. Ha a szolgáltató érdemben lecseréli vagy frissíti a mögöttes AI-modellt, és ez várhatóan megváltoztatja a kimenet jellegét, erről előre, írásban tájékoztatnia kell az ügyfelet.

Ez a hat pont vázlatos formában így néz ki egy tényleges szerződésben:

Fejezet	Miről szól
Rendelkezésre állás	A mögöttes szolgáltató SLA-jához kötött felső korlát rögzítése
Hibakezelés	Válaszidő és megoldási idő külön táblázatban, súlyossági szintenként
Fogalmi elhatárolás	Világos határvonal aközött, hogy mi számít a szolgáltató saját hibájának (amit köteles kijavítani), és mi számít a technológia természetes, előre nem garantálható korlátjának (amiért nem vállalható javítási kötelezettség)
Kizárások	Mit nem vállal a szolgáltató — explicit felsorolás (kifejezetten, félreérthetetlenül le kell írni)
Felelősségkorlátozás	Felső korlát a díj többszörösében, kivétellel adatvédelmi incidensre
Emberi felülvizsgálat	Mikor kötelező emberi jóváhagyás a kimenet felhasználása előtt
Módosítási értesítés	Modellváltás esetén az előzetes tájékoztatás módja és határideje

Ez a váz megmutatja, mit kell egy AI-SLA-nak rendeznie — a tényleges, jogilag megálló szöveg minden pontnál az adott vállalkozás konkrét helyzetéhez (szolgáltatás típusa, mögöttes technológia, kockázati profil) igazodik, ezért nem érdemes generikus sablonból másolni.

Ha szeretnéd, hogy ezt a vállalkozásodra szabva, tényleges klauzula-szöveggel elkészítsük, ezt egyedi szolgáltatásként vállaljuk, 50 000 Ft + ÁFA összegtől.

GYIK

Záró gondolat

Az AI-alapú szolgáltatások gyors terjedése azt jelenti, hogy egyre több vállalkozás fog szembesülni ezzel a kérdéssel — méghozzá jellemzően nem előre, tervezetten, hanem akkor, amikor egy szerződés vagy egy incidens már megköveteli a választ. A fent bemutatott hat eset mindegyike azt mutatja: a probléma nem azért keletkezett, mert valaki rosszhiszemű volt, hanem mert senki nem tette fel időben a megfelelő kérdéseket.

Ha most vezetsz be AI-alapú megoldást a vállalkozásodban — vagy már használsz ilyet, de nem vagy biztos benne, hogy a szerződéses és megfelelőségi kockázatok le vannak-e fedve —, egy AI megfelelőség felmérés pontosan ezekre a pontokra világít rá: hol hiányzik a szerződésből a negyedik réteg, mennyire felel meg a jelenlegi gyakorlat az EU AI Act közelgő elvárásainak, és milyen konkrét lépések szükségesek ahhoz, hogy ne utólag, egy incidens kapcsán derüljön ki, mi maradt szabályozatlanul.

Források

OpenAI hivatalos közleménye

Block

American Bar Association

Library of Congress — Global Legal Monitor

TianPan.co

Mondaq