Amit a számok mutatnak
A szállító székhelye bekerült a döntési mátrixba
Korábban írtam már arról, hogyan válasszunk vállalati AI platformot, és arról is, mikor van értelme helyben futtatni a modellt. Azok a cikkek a képességekről és a költségekről szóltak. Ez most másról szól. Arról a szempontról, ami az elmúlt egy évben jelent meg a beszerzési űrlapokon, és amire a legtöbb magyar cégnek még nincs kidolgozott válasza.
Egy friss Deloitte felmérés is megerősítette, amit én is tapasztalok az ügyfeleimnél. A megkérdezett szervezetek több mint háromnegyede már figyelembe veszi a szállító származási országát, amikor AI eszközről dönt. Ez a szám két éve gyakorlatilag nem létezett, ma pedig ott van szinte minden nagyvállalati tenderben.
Amikor először találkoztam ezzel egy energiaipari ügyfelemnél, őszintén szólva túlzásnak tartottam. Egy nyelvi modell nem atomerőmű. Aztán végigvezettem a csapatot azon, mi történik, ha a szállító joghatósága megváltoztatja a játékszabályokat, és a saját véleményemet is felülírtam. Nem paranoia áll a kérdés mögött, hanem az üzletmenet folytonossága.
A négy valódi kockázat
Mi rejtőzik a származási ország kérdése mögött
A szuverenitás szó túl nagy és túl politikai ahhoz, hogy egy beszerzési döntés alapja legyen. Ezért mindig szétbontom négy konkrét kockázatra. Ez a négy dolog az, ami ténylegesen kárt tud okozni egy magyar cégnél.
1. Jogi hozzáférés az adataidhoz
Az első kérdés nem az, hogy a szolgáltató jó szándékú-e. Az, hogy melyik állam milyen jogcímen kérhet hozzáférést a szervereihez. Egy amerikai székhelyű szolgáltatóra más szabályok vonatkoznak, mint egy európaira, és ez akkor is igaz, ha az adat fizikailag egy frankfurti adatközpontban pihen. Az egyik pénzügyi holding kontrolling csapatánál pontosan itt akadt el a bevezetés. Nem a modell teljesítményével volt baj, hanem azzal, hogy a jogi osztály nem tudta megválaszolni, mi történik egy külföldi adatkérés esetén.
2. Az ellátás megszakadása
Ez a kockázat sokkal prózaibb, és sokkal gyakoribb. Exportkorlátozás, szankciós lista, kereskedelmi vita. Bármelyik oda vezethet, hogy egy szolgáltatás egyik napról a másikra nem elérhető a te régiódból. Ha ez a szolgáltatás addigra beépült húsz munkafolyamatba, akkor nem egy eszközt veszítesz el, hanem a napi működés egy szeletét.
3. Az adatok tanításra kerülnek
A nagy szolgáltatók vállalati szerződéseiben ma már szinte mindenhol szerepel, hogy az ügyféladatot nem használják modelltanításra. Ezt viszont ellenőrizni kell, mert a szabad felhasználású verzió és a vállalati verzió között óriási különbség van. Egy 400 fős logisztikai cégnél azt találtam, hogy a hivatalos vállalati előfizetés mellett a kollégák fele még mindig a saját ingyenes fiókjából dolgozott. A szerződés rendben volt, a gyakorlat nem.
4. A modell megváltozik alattad
Erre a legkevesebben gondolnak. A szolgáltató bármikor lecserélheti, finomhangolhatja vagy nyugdíjazhatja azt a verziót, amire a folyamataidat építetted. Volt olyan ügyfelem, ahol egy gondosan kalibrált dokumentumfeldolgozó folyamat egy modellfrissítés után más formátumban kezdte visszaadni az eredményt. Két hét munka ment el arra, hogy újra beálljon. Ez nem geopolitika, hanem szállítói függés, és ugyanabba a kockázati kosárba tartozik.
A gyakorlat
Hat kérdés, ami bekerül a szállítói táblázatba
Amikor ezt elvégeztük az energiaipari ügyfélnél, a végeredmény nem egy negyvenoldalas kockázatelemzés lett, hanem hat kérdés, ami azóta minden AI szállítójuk értékelésénél szerepel. Ezt a hatot azóta több ügyfelemnél is bevezettem, mert elég konkrét ahhoz, hogy egy beszerző is meg tudja válaszolni jogász nélkül.
Melyik jogi entitással szerződünk és hol van a székhelye? Nem a márkanév számít, hanem az a cég, ami aláírja a szerződést. Sok szolgáltatónak van európai leányvállalata, ez nagyot változtat a képen.
Hol tárolódnak és hol dolgozódnak fel az adatok? A kettő nem ugyanaz. Van, ahol a tárolás európai, a feldolgozás viszont nem. Kérd külön mindkettőt.
Mi a felmondási és kilépési feltétel, és milyen formátumban kapjuk vissza az adatainkat? Ha erre nincs pontos válasz a szerződésben, akkor a válasz az, hogy sehogy.
Mennyi ideig érhető el egy adott modellverzió, és mennyi az előzetes értesítés a kivezetés előtt? A komoly vállalati szolgáltatók erre számot mondanak. Aki nem mond, az azt üzeni, hogy nem tervezhetsz rá.
Kik az alvállalkozók a láncban? A szolgáltatód lehet európai, miközben a mögötte lévő számítási kapacitás nem az. A lánc végét kell megnézni.
Van rá alternatívánk, és mennyi idő átállni? Ez a legkeményebb kérdés, és erről szól a cikk utolsó szakasza.
Ami ebben a hat kérdésben közös, hogy egyik sem a modell képességeiről szól. Pontosan ez a lényeg. A képességeket úgyis leteszteled, arra minden csapatnak van rutinja. Ezek a kérdések azt a részt fedik le, amit a demó soha nem mutat meg, és ami két évvel a bevezetés után derül ki.
A szervezeti oldal
Ki dönt erről valójában a cégen belül
A technikai válaszoknál sokszor nehezebb megmondani, kinek a felelőssége ez a döntés. Azt tapasztaltam, hogy ez a kérdés a legtöbb szervezetben három osztály között ragad be. Az IT azt mondja, hogy jogi kérdés. A jogi osztály azt mondja, hogy üzleti kockázat. Az üzlet pedig azt mondja, hogy technikai részlet. Ilyenkor senki nem dönt, és a döntést végül az hozza meg, aki elsőként aláír egy előfizetést a saját bankkártyájával.
Nálam ez ma már a bevezetési projekt első hetének a témája. Egyetlen nevet kérek, aki az AI szállítói portfólióért felel. Nem bizottságot, nevet. Ez a személy általában nem a legmagasabb beosztású a teremben, hanem az, aki a meglévő szállítói kockázatokat is kezeli, és aki tudja, hogyan néz ki egy rendes exit klauzula. A legtöbb közepes és nagyvállalatnál létezik ilyen ember, csak az AI eszközök eddig valahogy kimaradtak a hatásköréből, mert nem klasszikus IT beszerzésként érkeztek a házba.
Az egyik ügyfelemnél az derült ki ezen a ponton, hogy tizennégy különböző AI szolgáltatás fut a cégben, ebből hét olyan, amiről a beszerzés nem tudott. Nem volt köztük egyetlen rosszhiszemű döntés sem. Egyszerűen mindegyik egy csapatszintű előfizetésként indult, ami elég olcsó volt ahhoz, hogy ne kerüljön jóváhagyásra. Amikor ez a tizennégy sor egy táblázatba került, a vezetés fél óra alatt megértette, miről szól a szuverenitás kérdése. Sokkal gyorsabban, mint bármelyik prezentációmból.
A tipikus tévedés
A szuverenitás nem igen vagy nem kérdés
A leggyakoribb hiba, amit látok, hogy a szervezetek bináris döntéssé alakítják ezt a témát. Vagy teljesen európai megoldást akarnak, vagy legyintenek az egészre. Mindkét út rossz helyre visz.
Aki legyint, az később szembesül azzal, hogy egy szabályozott iparágban az auditor nem legyint. Aki viszont az európai gyökereket teszi meg egyetlen szempontnak, az gyakran gyengébb eszközzel dolgozik, és a felhasználók egyszerűen megkerülik. Ezt az egyik gyógyszeripari beszállítónál láttam a legélesebben. Bevezettek egy megnyugtató papírokkal rendelkező megoldást, aztán fél évvel később kiderült, hogy a fejlesztők és a marketingesek a saját eszközeikkel dolgoznak, mert azok gyorsabbak. A szuverenitás így nem nőtt, csak láthatatlanná vált.
Amit ehelyett javaslok, az a rétegzés. Nem minden adatod egyforma. Egy belső marketing ötletelés, egy ügyfélszerződés és egy fejlesztés alatt álló termékdokumentáció három különböző kockázati osztály. Az egyik ügyfelemnél három szintet határoztunk meg. A legalsó szinten bármelyik jóváhagyott felhőszolgáltatás használható. A középsőn csak vállalati szerződéssel és európai adattárolással. A legfelsőn az adat nem hagyja el a céges környezetet, ott helyben futó modell dolgozik, akkor is, ha az gyengébb. Ez a három szint egy oldalon elfér, és a kollégák meg tudják jegyezni. Egy negyvenoldalas policy-t nem jegyeznek meg.
A valódi biztosíték
A hordozhatóság többet ér, mint a szállító útlevele
Ebből a projektből tanultam meg a legtöbbet, és ez az, amit minden vezetőnek elmondok, aki a témával megkeres. A származási ország egy szempont a sok közül. A tényleges védelmet nem a szállító kiválasztása adja, hanem az, hogy mennyi idő alatt tudsz lecserélni egy szállítót.
Ha az architektúrád úgy épül fel, hogy a modellhívás egy jól elkülönített rétegen megy keresztül, ha a promptjaid és a folyamataid nem egyetlen szolgáltató sajátos formátumához tapadnak, és ha van egy dokumentált tesztkészleted, amivel egy másik modellt le tudsz mérni, akkor a szállítóváltás hetek kérdése. Ha nincs, akkor hónapoké, és a hónapok alatt áll a működés.
Egy 35 fős kreatív ügynökségnél ezt a leggyorsabban végig lehetett vinni, mert még nem volt sok beépült folyamatuk. Egyetlen közös réteget építettünk, amin minden AI hívás átment, és összeállítottunk hetven tesztfeladatot abból, amit ténylegesen csinálnak. Amikor fél évvel később árat emelt a szolgáltatójuk, két nap alatt lemérték a versenytársat, és három hét alatt átálltak. Nem a jogi elemzés mentette meg őket, hanem az, hogy volt hova menni.
Ezt a hetven tesztfeladatot azóta minden nagyobb ügyfelemnél elkészítjük. Ez a legalulértékeltebb eszköz a vállalati AI bevezetésben. Nem védekezés, hanem tárgyalási pozíció. Aki meg tudja mérni, hogy egy másik szállító mit tud a saját feladatain, az egészen máshogy ül le tárgyalni a megújításról.
Összegzés
Mit tegyél a következő beszerzés előtt
Ha egyetlen dolgot viszel el ebből a cikkből, az legyen ez. Ne a szállító nemzetiségéről vitatkozz a vezetői ülésen, hanem arról, hogy mi történik, ha holnap eltűnik. Ez a kérdés minden résztvevő számára értelmezhető, a pénzügyesnek, a jogásznak és az üzemeltetésnek is.
A konkrét első lépés egyszerű. Vedd elő a jelenleg használt AI eszközeitek listáját, és mindegyik mellé írd oda, hány munkafolyamat függ tőle és mennyi idő alatt lenne pótolható. A legtöbb szervezetnél ez az első olyan táblázat, ami után a vezetőség nem a modellek képességeiről kezd beszélni. Onnantól kezdve a szuverenitás nem elvont téma, hanem egy sor a kockázati nyilvántartásban, ahol a helye van.
Forrás: Deloitte, State of AI in the Enterprise 2026 (deloitte.com).
Segíthetek a vállalatodat AI-ra felkészíteni?
Ha a témában szeretnél konzultálni, vagy AI bevezetési projekten gondolkozol, keress meg.