OpenAI több felhőben: mit rögzítsünk a szerződésben az éles AI-bevezetés előtt?

A felhőpiac átalakulása csökkenti a függőségeket, a többszereplős modellhasználat viszont új adatvédelmi és felelősségi csapdákat rejt a hazai cégek számára.

OpenAI több felhőben: mit rögzítsünk a szerződésben az éles AI-bevezetés előtt?

Amikor az OpenAI megerősítette, hogy a meglévő infrastruktúra-partnerein túl a Google Cloud számítási kapacitásaira is támaszkodik, világossá vált: a vezető modellfejlesztők hardveréhsége végleg szétfeszítette a kizárólagos felhős megállapodások kereteit. Érdemes persze tisztán látni a technológiai határokat. A háttérkapacitások megosztása önmagában nem jelenti azt, hogy az OpenAI modelljei automatikusan megjelentek a Google Cloud piacterén. A hazai IT-döntéshozók számára a hír igazi üzenete az, hogy a vállalati mesterséges intelligencia belépett a többfelhős korszakba, ez pedig a beszerzési stratégiák és a szerződéskötési rutinok azonnali felülvizsgálatát követeli meg.

A vállalati bevezetéseknél a menedzsment hajlamos egyetlen zárt, dobozos termékként tekinteni az AI-ra, pedig a valóságban összetett szállítói lánc működik a háttérben. A modellfejlesztő adja az algoritmust, a felhőszolgáltató a vasat és a hálózati sávszélességet, a piactér intézi a számlázást, a bevezetést végző integrátor pedig mindezt ráhúzza a meglévő belső folyamatokra. Ezek a rétegek jogi és üzemeltetési szempontból élesen elválnak egymástól. Attól még, hogy egy jól bejáratott felhőplatformon keresztül fizetünk elő egy nyelvi modellre, a platform üzemeltetője nem vállal garanciát a válaszok pontosságáért, a késleltetésért vagy az adatok szigorú határokon belüli kezeléséért.

A többcsatornás modellbeszerzés vitathatatlan előnye, hogy csökkenti az egyetlen szállítótól való függést, a klasszikus vendor lock-int. Azok a kkv-k, amelyek már rendelkeznek kiterjedt keretszerződésekkel az Azure, az AWS vagy a Google Cloud felületén, rugalmasan oszthatják el a költségeiket. A felhőpiactéren keresztüli vásárlás egyetlen számlán összesíti a kiadásokat, ami kényelmes a pénzügynek, és segít lefaragni a korábban vállalt költési minimumokat is. Ez a kényelem viszont könnyen elaltatja a döntéshozók éberségét. A konszolidált számla nem jelent automatikusan olcsóbb működést: a közvetítői árrések és a járulékos felhős rétegek díjai idővel észrevétlenül felverik az egy tranzakcióra jutó valós költségeket.

A megállapodások legkényesebb pontját továbbra is az adatkezelési záradékok jelentik, ahol az általános szerződési feltételek rutinból történő elfogadása kifejezetten kockázatos. Az OpenAI üzleti API-jaira, valamint a ChatGPT Enterprise és Business előfizetésekre vonatkozó irányelvei rögzítik, hogy a beküldött ügyféladatokat nem használják a modellek tanítására. Ez megnyugtató, de korántsem elegendő. Az OpenAI API-platformjának visszaélés-ellenőrző rendszerei ugyanis alapesetben harminc napig megőrzik a forgalmi naplókat. Szigorúan szabályozott környezetben, például a pénzügyi vagy egészségügyi szektorban, ez már önmagában megfelelési kockázatot szül. A jogosult vállalati ügyfelek ugyan kérhetik a naplózás azonnali törlését vagy a nullás adatmegőrzési szintet, ám ezt nem kapcsolja be senki automatikusan: külön, egyedi szerződéses megállapodásban kell kiharcolni és rögzíteni.

Hasonló körültekintést kíván az adatfeldolgozás földrajzi helye és az alvállalkozói lánc feltérképezése. Az európai adatvédelmi elvárások szempontjából kulcskérdés, hogy a lekérdezések valóban uniós adatközpontokban futnak-e le, vagy egy kapacitáshiányos időszakban csendben átirányítják őket tengerentúli szerverekre. A szerződésnek pontosan el kell határolnia az adatkezelői és adatfeldolgozói szerepeket, egyértelműen meghúzva a határt, hogy a modell fejlesztője vagy az integrátor milyen mélységben férhet hozzá a nyers adatokhoz. A megrendelőnek el kell várnia az alfeldolgozók tételes listáját, valamint azt a garanciát, hogy az esetleges adatvédelmi incidensekről a szolgáltató ne hetek múlva, hanem legkésőbb 24-48 órán belül hivatalos értesítést küldjön.

A technológiai felelősségvállalás kérdése még tovább bonyolódik, ha a modell és az infrastruktúra elválik egymástól. Ha egy ügyfélszolgálati folyamatba épített mesterséges intelligencia leáll vagy drasztikusan lelassul, a vállalat azonnali bevételkiesést könyvel el. Ilyenkor a felelősség könnyen szétporlad a modellgazda, a felhőszolgáltató és a bevezetést végző partner között. A felhőszerződésekben megszokott 99,9 százalékos rendelkezésre állási vállalás a virtuális gépekre és a hálózati kapcsolatra vonatkozik, nem pedig a modell funkcionális válaszkészségére vagy a másodpercenként generált tokenek sebességére. A szerződésben ezért kötelező különválasztani az alkalmazásszintű, a platformszintű és a modellspecifikus SLA-kat, pontosan szabályozva a leállások után járó kötbéreket vagy jóváírásokat.

A pénzügyi tervezésnél elkövetett leggyakoribb hiba, hogy a cégek kizárólag a tokenárakat hasonlítják össze. A közvetlen modellszámla ugyanis csupán a bekerülési költség egy része. Az adatok felhők közötti mozgatása, a kimenő hálózati forgalom, a monitorozási infrastruktúra fenntartása és a biztonsági szűrők üzemeltetése mind hozzáadódnak a végösszeghez. Számolni kell a kiemelt terméktámogatás díjával, a hibaelhárítási készenléttel, valamint egy későbbi modellváltás fejlesztési költségeivel is. Emellett a közvetlen API-hozzáférés sokszor azonnal elérhetővé teszi a legújabb funkciókat, míg a közvetítő piactereken ezek esetenként heteket vagy hónapokat késnek, ami versenyhátrányba hozhatja a céget a gyorsabban reagáló versenytársakkal szemben.

A szabályozási környezet változása szintén konkrét szerződéses felkészülést követel. Az Európai Unió mesterséges intelligenciáról szóló rendelete, az AI Act tiltott gyakorlatokra vonatkozó szabályai 2025. február 2-tól közvetlenül alkalmazandók. Bár az általános célú modellekre vonatkozó szigorúbb kötelezettségek lépcsőzetesen lépnek életbe, a megrendelőknek már a most futó fejlesztéseknél biztosítaniuk kell a megfelelést. Nem lehet bemondásra elhinni a szállítói ígéreteket: a vállalatnak részletes műszaki dokumentációt, a kockázatértékelést alátámasztó anyagokat és hivatalos megfelelőségi nyilatkozatokat kell kérnie. A megállapodásban kötelezni kell a partnert arra, hogy haladéktalanul tájékoztatást adjon a modellt érintő érdemi változtatásokról és az esetleges hatósági vizsgálatokról.

A gyakorlatban a sikeres bevezetés a tárgyalóasztalnál dől el. Írásba kell adni az adatfeldolgozás pontos fizikai helyét, az adatminimalizálás követelményét és a tanítás teljes kizárását. Ugyanígy rögzíteni kell az API-hívások garantált kapacitását, a naplózási adatok egyedi törlési idejét, a váratlan áremelések korlátait, valamint azt a jogot, hogy az alfeldolgozók cseréje esetén a cég azonnal felmondhassa a szerződést. Azok a hazai vállalkozások, amelyek ezeket a pontokat nem jogi formaságként, hanem a napi üzletmenet-folytonosság garanciájaként kezelik, valódi működési előnyt faraghatnak a többfelhős világ adta szabadságból.

Megosztás

Kíváncsi, hogyan segíthetünk?


Ismerje meg saját fejlesztésű megoldásainkat, vagy beszéljük át a projektjét.

CraneFlow ERP Document Recognition Tool Szolgáltatások Kapcsolatfelvétel