Szállítói MI-átvilágítás: mit kérjen a szerződésbe
Ha a cég MI-t vásárol, nem a saját fejlesztéséért felel, hanem azért, amit a szállítótól kap. Az EU AI Act alkalmazói kötelezettségei akkor is a vevőn maradnak, ha a rendszert más építette. Gyakorlati átvilágítási lista és szerződéses kikötések kkv-méretben, a 2026 nyári jogi állapot szerint.

A cikk lényegeHa a cég MI-t vásárol, nem a saját fejlesztéséért felel, hanem azért, amit a szállítótól kap. Az EU AI Act alkalmazói kötelezettségei akkor is a vevőn maradnak, ha a rendszert más építette. Gyakorlati átvilágítási lista és szerződéses kikötések kkv-méretben, a 2026 nyári jogi állapot szerint.
Rövid válasz. Az MI-beszerzésnél a felelősség nem száll át a szállítóra. Az EU AI Act az alkalmazóra – arra a cégre, amelyik a rendszert a saját nevében használja – önálló kötelezettségeket telepít, függetlenül attól, hogy a szoftvert megvásárolta vagy bérli. A vevő azonban csak azt tudja teljesíteni, amiről a szállítótól adatot kap. Ezért az átvilágítás nem jogi formaság, hanem az egyetlen mód arra, hogy a saját megfelelés egyáltalán elvégezhető legyen. Öt kérdés eldönti, hogy egy ajánlat vállalható-e: mit csinál pontosan a rendszer, milyen kockázati kategóriába esik, milyen dokumentációt ad, mi történik hiba esetén, és mi lesz az adatainkkal. Aki ezt az öt kérdést a szerződéskötés előtt teszi fel, az utólag nem lesz kiszolgáltatva.
Miért a vevőn marad a felelősség?
A rendelet két fő szerepet különböztet meg. A szolgáltató az, aki a rendszert fejleszti és forgalomba hozza; az alkalmazó az, aki a saját tevékenységében használja. A kettő kötelezettségei eltérnek, de nem helyettesítik egymást. Ha egy cég kész MI-megoldást vásárol, alkalmazóvá válik: neki kell gondoskodnia arról, hogy a rendszert rendeltetésszerűen használják, hogy ahol kell, ember felügyelje, és hogy a személyzet felkészült legyen rá. Ezek nem átruházhatók a szerződéssel.
Van egy fontos kivétel, amit érdemes ismerni: ha a vevő a saját nevével vagy védjegyével hozza forgalomba a rendszert, vagy lényegesen módosítja, illetve a rendeltetését megváltoztatja, akkor maga is szolgáltatóvá válhat – jóval szigorúbb kötelezettségekkel. Ez a gyakorlatban akkor fordul elő, amikor egy vásárolt modellt a cég a saját márkája alatt kínál ügyfeleinek. Ilyenkor az átvilágítás nem elég: teljes körű megfelelési projekt kell.
Ki mit visel a két szerepben
A mátrix azt mutatja, melyik kötelezettség kire hárul. A bal oszlop a szállítóé, a jobb a vevőé. A középső sáv az, ami a szerződés nélkül eldöntetlen marad – és a gyakorlatban ez okozza a vitákat, nem a jogszabály értelmezése.
A dokumentáció átadása például nem automatikus. A rendelet a szolgáltatóra ír elő dokumentációs kötelezettséget, de az alkalmazó akkor tud megfelelni a saját kötelezettségeinek, ha ezt megkapja. Ha a szerződés hallgat róla, a vevő olyan előírásnak nem tud eleget tenni, aminek a teljesítéséhez nincs eszköze.
Ugyanez a helyzet a naplókkal. Az alkalmazói oldalon a naplók megőrzése elvárás, de a naplózást magát a rendszer végzi. Ha a szállító nem ad hozzáférést a naplóállományhoz, vagy harminc nap után felülírja, a vevő papíron felel valamiért, amit fizikailag nem tud teljesíteni.
A harmadik sor az, amit a legtöbben átugranak: a rendeltetési cél. Ha a cég a megvásárolt rendszert más célra kezdi használni, mint amire a szállító szánta, a felelősség eltolódik. Nem kell hozzá fejlesztés, elég egy új munkafolyamat – és a szerepváltás észrevétlenül megtörténik.
Az öt kérdés, amit a szerződés előtt fel kell tenni
- 01
Mit csinál pontosan a rendszer? Nem marketingszöveget kérünk, hanem a rendeltetés leírását: milyen bemenetből milyen kimenetet állít elő, és milyen döntést támogat vagy hoz meg.
- 02
Milyen kockázati kategóriába esik? A szállító nyilatkozzon: tiltott gyakorlat nem érinti, magas kockázatú-e, és ha igen, melyik melléklet alapján. A besorolás a felhasználás módjától is függ.
- 03
Milyen dokumentációt ad át? Használati útmutató, a rendszer képességeinek és korlátainak leírása, a pontosságra és a ismert torzításokra vonatkozó adatok, naplózási lehetőség.
- 04
Mi történik hiba vagy incidens esetén? Bejelentési határidő, kapcsolattartó, javítási vállalás, és hogy a szállító értesít-e minket, ha a rendszerről utólag derül ki hiányosság.
- 05
Mi lesz az adatainkkal? Betanításra használják-e a bevitt adatot, hol tárolják, meddig, és ki fér hozzá. Üzleti titok és személyes adat esetén ez a legkockázatosabb pont.
Milyen kikötések kerüljenek a szerződésbe?
| Kikötés | Miért kell | Mire figyeljen |
|---|---|---|
| Dokumentáció-átadási kötelezettség | E nélkül a saját megfelelés nem teljesíthető | Ne csak a szerződéskötéskor, hanem minden lényeges verzióváltáskor |
| Kockázati besorolási nyilatkozat | Írásban rögzíti, mit állít a szállító | A besorolás a mi felhasználásunkra vonatkozzon, ne általánosságban |
| Adatkezelési kikötés | A bevitt adat betanításra használata sokszor alapértelmezett | Kifejezett kizárás, ha üzleti titok kerülhet be |
| Változás-értesítés | Egy modellfrissítés megváltoztathatja a kimenet minőségét | Előzetes értesítés és tesztelési idő kikötése |
| Naplózás és auditálhatóság | Utólag bizonyítani kell tudni, mi történt | Ki fér a naplókhoz, meddig őrzik, kiadják-e nekünk |
| Alvállalkozói lánc átláthatósága | A szállító gyakran maga is továbbszolgáltat | Az MI-ismeretségi és adatkezelési kikötés terjedjen ki rájuk is |
Mit tegyünk, ha a szállító nem válaszol?
A hallgatás önmagában információ. Ha egy szolgáltató nem tudja megmondani, milyen adatokon tanult a modell, vagy nem hajlandó írásba adni, hogy a bevitt adatot nem használja betanításra, az nem jogi akadékoskodás kérdése, hanem üzleti kockázat. A gyakorlatban három út marad: alacsonyabb kockázatú felhasználásra korlátozzuk a rendszert, kiegészítő emberi ellenőrzést építünk köré, vagy más szállítót keresünk. Mindhárom védhető döntés – az nem védhető, ha a kérdést fel sem tettük.
Nagy nemzetközi szolgáltatóknál gyakran nincs egyedi szerződéskötés, csak általános feltételek. Ilyenkor az átvilágítás nem tárgyalás, hanem dokumentálás: rögzítjük, mit állít a nyilvános feltételrendszer, mikor néztük meg, és milyen korlátozásokat vezettünk be emiatt a saját használatunkban. Ez a feljegyzés a megfelelés bizonyítéka. Fontos részlet, hogy az általános feltételek egyoldalúan változhatnak: érdemes a dátumot és a hivatkozott változat azonosítóját is rögzíteni, különben egy év múlva nem lesz eldönthető, mihez képest döntöttünk.
Hogyan épül be ez a beszerzési folyamatba?
Az átvilágítás akkor működik, ha nem külön projekt, hanem a meglévő beszerzési lépések közé illesztett kapu. A gyakorlatban három ponton érdemes beavatkozni. Az ajánlatkéréskor: az öt kérdés bekerül a kiírásba, így minden ajánlattevő ugyanarra válaszol, és az ajánlatok összehasonlíthatóvá válnak. A döntés előtt: a válaszok alapján megszületik a besorolás, és eldől, kell-e emberi felülbírálat vagy adatkorlátozás. A szerződéskötésnél: a lényeges válaszok kikötésként bekerülnek a szövegbe, mert ami csak e-mailben hangzott el, azt később nehéz érvényesíteni.
Ez a három kapu együtt sem igényel új szervezetet. Egy kkv-nál általában ugyanaz a személy viszi, aki a beszerzést amúgy is intézi – a különbség annyi, hogy van előtte egy kérdéslista és utána egy feljegyzés. A tapasztalat szerint a második beszerzésnél már rutin, mert a kérdések ugyanazok maradnak, csak a válaszok változnak.
| Beszerzési szakasz | Mi történjen | Mi keletkezik |
|---|---|---|
| Ajánlatkérés | Az öt kérdés bekerül a kiírásba | összehasonlítható ajánlatok |
| Értékelés | Besorolás a mi felhasználásunkra, kockázatarányos döntés | besorolási feljegyzés |
| Szerződéskötés | A lényeges válaszok kikötéssé válnak | szerződéses melléklet |
| Bevezetés | Használati szabály és a személyzet tájékoztatása | belső szabály, jelenléti ív |
| Üzemeltetés | Verzióváltás és incidens követése | változásnapló |
Miért kapu, és nem ellenőrzőlista
A kapu azt jelenti, hogy a folyamat nem megy tovább, amíg a kérdés nincs megválaszolva. Az ellenőrzőlista attól különbözik, hogy azt utólag is ki lehet tölteni, és rendszerint ki is töltik – a szerződéskötés után, a rend kedvéért.
A legfontosabb kapu a második. Ha az öt kérdés az ajánlatkérésben szerepel, a szállító a saját ajánlatában válaszol rá, írásban, versenyhelyzetben. Ugyanez a kérdés a szerződéskötés előtti héten már alkupozíciót veszít: ekkor a vevő már döntött, és a nemleges válasz kellemetlen.
A negyedik kapunál egy formai részlet dönt. Ha a kikötések a szerződés törzsszövegében vannak, akkor a szerződés részei. Ha mellékletben, akkor a melléklet érvényességéről és módosíthatóságáról külön rendelkezni kell, különben a szállító egyoldalúan frissítheti.
Az ötödik kapu a legritkábban használt: az átvételkor kell ellenőrizni, hogy a megígért dokumentáció ténylegesen megérkezett-e. A gyakorlat az, hogy a rendszer működik, a papír pedig valamikor jön – és a valamikor ritkán érkezik el magától.
Kkv-méretű átvilágítás: mennyi az elég?
Szövegfogalmazás, ötletelés
Egy oldalas feljegyzés: mit használunk, mire, milyen adatot nem viszünk be. Szerződéses külön kikötés általában nem szükséges.
Ügyfélkommunikáció, elemzés
Az öt kérdés végigkérdezve és írásban rögzítve, átláthatósági jelölés az ügyfél felé, emberi ellenőrzés a kimeneten.
Toborzás, hitelbírálat, hozzáférés
Teljes dokumentáció-átadás, besorolási nyilatkozat, naplózás, emberi felülbírálat és rendszeres visszamérés. Itt külső szakmai támogatás indokolt.
Mit jelent mindez a saját adatainkra nézve?
Az MI-beszerzés legalattomosabb kockázata nem a jogszabályi megfelelés, hanem az adatkiáramlás. Amikor egy munkatárs beilleszt egy ajánlatot, egy szerződéstervezetet vagy egy ügyféllistát a rendszerbe, az adat elhagyja a céget. Hogy mi történik vele, azt nem a jó szándék dönti el, hanem a szolgáltatói feltételek. Három kérdést kell tisztázni: betanításra használják-e, milyen földrajzi területen tárolják, és mennyi ideig őrzik. A válaszokból következik, mit szabad bevinni – és ezt a szabályt a munkatársakkal is közölni kell, mert a rendszer önmagában nem fogja megakadályozni őket.
Személyes adat esetén ehhez adatvédelmi jogalap is kell, a hozzá tartozó tájékoztatással. Üzleti titoknál pedig érdemes végiggondolni, mi történik, ha a bevitt információ egy másik ügyfél válaszában köszön vissza. A védekezés nem technikai: a legjobb eredményt az adja, ha a cég kijelöl egy rövid tiltólistát arról, mi nem kerülhet MI-rendszerbe, és ezt a listát a képzésbe is beépíti.
A leggyakoribb hibák
- 01
A cég azt hiszi, a szállító megfelelése az övé is. Nem az: az alkalmazói kötelezettségek külön élnek.
- 02
Az átvilágítás a beszerzés után történik, amikor már nincs alkupozíció.
- 03
Csak a szoftvert nézik, a mögötte lévő modellszolgáltatót nem – pedig az adat oda kerül.
- 04
A verziófrissítést senki nem követi, így a rendszer észrevétlenül másképp viselkedik.
- 05
A vizsgálat eredménye nem kerül papírra, így utólag semmi nem bizonyítható.
Mi a helyzet a beépített MI-funkciókkal?
A legtöbb kkv nem MI-rendszert vásárol. Számlázót, ügyfélkezelőt, levelezőt, projektkövetőt vásárol, amelybe a szállító időközben MI-funkciót épített. A különbség lényeges: itt nincs beszerzési döntés, amit át lehetne világítani, mert a funkció egy frissítéssel jelent meg egy már futó szerződés alatt.
Ez a helyzet a gyakorlatban gyakoribb, mint a tudatos MI-beszerzés, és pontosan ezért marad észrevétlen. A cég nem tudja, hogy MI-t használ, mert az a szoftver menüjében egy új gomb formájában érkezett. A megfelelési kötelezettség viszont a használathoz kapcsolódik, nem a beszerzés módjához.
A kezelése két lépésből áll. Az első az MI-leltár: melyik használt szoftverben van MI-funkció, és használja-e valaki. A második a szállítói tájékoztatás rendje: kérni kell, hogy az új MI-funkciók bevezetéséről a szállító előzetesen értesítsen. Ez utóbbi a legtöbb általános szerződési feltételből hiányzik, és éppen ezért érdemes külön kérdezni rá.
A leltárnál a leggyakoribb tévedés az, hogy csak a nyilvánvaló eszközöket keresik. A generatív szövegjavaslat egy levelezőben, az automatikus összefoglaló egy értekezlet-alkalmazásban vagy a jelöltszűrés egy toborzó modulban mind MI-funkció, akkor is, ha a felület nem nevezi annak.
Az átláthatósági szabály a beszerzésben
A rendelet 50. cikke átláthatósági kötelezettségeket ír elő: a felhasználónak tudnia kell, ha géppel beszélget, és a mesterségesen előállított tartalmat meg kell jelölni. Ezek a szabályok 2026. augusztus 2-án léptek alkalmazásba, a jelölési előírásokhoz kapcsolódó türelmi idő pedig 2026. december 2-ig tart.
A beszerzésnél ennek konkrét következménye van. Ha a cég ügyfélkommunikációra vásárol MI-eszközt, a közlési kötelezettség a cégen marad, de a teljesítéshez a rendszernek támogatnia kell: kell lennie helye a tájékoztató szövegnek, és a generált tartalomnak jelölhetőnek kell lennie. Ha a termék ezt nem tudja, a kötelezettséget kézzel kell teljesíteni, ami hosszú távon nem tartható.
Ez az a pont, ahol egy egyszerű kérdés sok utólagos munkát megspórol: a rendszer támogatja-e a közlési és jelölési kötelezettség teljesítését, és ha igen, hogyan. A válasz vagy konkrét, vagy nincs válasz – harmadik eset ritkán fordul elő.
Hogyan értékeljük a szállítói válaszokat?
Az öt kérdés akkor hasznos, ha a válaszokat egységesen értékeljük. Nem pontozásra van szükség, hanem három kategóriára: megkaptuk, részben kaptuk meg, nem kaptuk meg. A harmadik kategória nem automatikus kizárás, de dokumentált döntést igényel.
| Válasz típusa | Mit jelent | Mi a teendő |
|---|---|---|
| Konkrét, írásbeli | A szállító megnevezi a modellt, a naplózási időt, a dokumentáció körét. | Bekerül a szerződéses mellékletbe hivatkozásként, és az átvételnél ellenőrizhető. |
| Általános megfelelőségi állítás | „Rendszerünk megfelel az EU AI Actnek” – a mi felhasználásunkról nem mond semmit. | Visszakérdezés a konkrét felhasználásra. Ha nem érkezik válasz, a második kategória. |
| Részleges | Néhány kérdésre válaszol, a többit kereskedelmi titokra hivatkozva kihagyja. | Mérlegelés: a kihagyott kérdés kritikus-e. A naplózás jellemzően az. |
| Nincs válasz | Két megkeresésre sem érkezik érdemi felelet. | Dokumentált döntés a saját oldali pótlásról, vagy a szállító kizárása. |
A táblázat célja nem a szállító minősítése, hanem a saját döntés nyomon követhetősége. Ha egy évvel később kérdés merül fel, hogy miért ezt a rendszert használjuk, a válasznak dokumentumban kell lennie, nem emlékezetben.
A három kikötés, ami nélkül ne írjunk alá
Az öt kérdés a megismerésről szól, a kikötések a jogviszonyról. A kettő nem ugyanaz: attól, hogy a szállító elmondta, hogyan naplóz, még nem vállalt kötelezettséget rá. A gyakorlatban három kikötés van, amelynek a hiánya később biztosan problémát okoz.
Miért éppen ez a három
Az első a dokumentáció átadása, meghatározott terjedelemben és határidővel. Terjedelem nélkül a szállító egy kétoldalas termékleírással is teljesít, határidő nélkül pedig a rendszer élesbe áll, a papír pedig „hamarosan” érkezik. A kettő együtt működik, külön-külön egyik sem.
A második a naplókhoz való hozzáférés és a megőrzési idő. Itt az a kérdés dönt, hogy a napló a vevő számára kinyerhető-e, és milyen formában. Egy képernyőn megjeleníthető, de nem exportálható napló a gyakorlatban nem használható sem belső vizsgálathoz, sem hatósági kérdéshez.
A harmadik a lényeges változásról szóló előzetes értesítés. Enélkül a rendszer viselkedése egy frissítéssel megváltozhat úgy, hogy a cég a saját kockázatértékelését nem tudja frissíteni. Ez a kikötés az, amelyik a legkevesebbe kerül a szállítónak, és a legtöbbet ér a vevőnek.
A három kikötés a szerződés törzsszövegébe való, nem mellékletbe. A melléklet módosíthatósága rendszerint másképp van szabályozva, és a szállító egyoldalúan frissítheti – ezzel pedig a kikötés értelmét veszti.
Az auditjog azért került az utolsó helyre, mert kkv-méretben szinte soha nem gyakorolható. Egy tízfős cég nem küld auditort egy nemzetközi szolgáltatóhoz, és ha a szerződésben benne is van, a jogosultság kihasználatlan marad. Az erőforrást érdemesebb az első három kikötésre fordítani, amelyek papír nélkül is számonkérhetők.
Mi történik, ha kiderül, hogy rosszat vásároltunk?
Ez a kérdés ritkán kerül elő a beszerzés előtt, pedig a válasz befolyásolja a döntést. Ha egy MI-eszközről a bevezetés után derül ki, hogy a felhasználás magasabb kockázati sávba esik, mint gondoltuk, a cégnek három lehetősége marad: a felhasználás szűkítése, a megfelelési munka elvégzése, vagy a rendszer kivezetése.
A szűkítés a leggyakoribb és a legolcsóbb út. Nem a rendszer megy ki, hanem az a konkrét felhasználás, ami a besorolást felfelé mozdította. Egy toborzási modul, amelyet nem a jelöltek rangsorolására, hanem csak a beérkezett anyagok rendezésére használnak, más sávban van – de ehhez a szűkítést írásba kell foglalni, mert szóbeli megállapodás nem bizonyítható.
A kivezetés költsége az, amiről a beszerzéskor érdemes gondolkodni. Ha az adatok exportálhatók szabványos formátumban, a váltás néhány hetes munka. Ha nem, a cég akkor is a rendszernél marad, ha már nem szeretné – és ez a függés a szerződés megújításánál pénzben is megjelenik. A kilépési feltételek tisztázása ezért nem pesszimizmus, hanem árazási kérdés.
A gyakorlatban a legrosszabb kimenet nem a hibás vásárlás, hanem az, hogy a hibát senki nem jelzi. Ha a rendszert használó kolléga látja, hogy a kimenet rendszeresen pontatlan, de nincs hova jeleznie, a probléma addig marad rejtve, amíg ügyfélpanasz nem lesz belőle. Egy megnevezett kapcsolattartó és egy egymondatos jelzési út többet ér, mint bármelyik szerződéses kikötés.
Amit a szállító oldaláról érdemes látni
Az átvilágítás akkor működik, ha a vevő érti, miért nehéz a másik oldalnak válaszolni. Egy szoftverfejlesztő cég gyakran maga sem tudja pontosan megmondani, milyen adatokon tanították azt a modellt, amelyet egy nagy szolgáltatótól licencel. Nem titkolózik: ő maga is alkalmazó abban a láncban, és ugyanazokkal a kérdésekkel néz szembe felfelé.
Ebből két gyakorlati következtetés adódik. Az első: a kérdést úgy érdemes megfogalmazni, hogy a szállító a saját tudásának határát is megjelölhesse. A „nem tudjuk, mert a modellt harmadik féltől licenceljük” használható válasz, sokkal többet ér, mint egy megnyugtató, de tartalmatlan mondat.
A második: a lánc minden szereplőjének ugyanaz a problémája, ezért a jól megfogalmazott kérdés a szállítónak is hasznos. Több hazai fejlesztő éppen az ilyen ügyfélkérdések hatására kezdte el összeállítani a saját dokumentációját, mert ugyanaz a kérdés több vevőtől is megérkezett. Ez a hatás lassú, de valós.
Végül egy tapasztalati megfigyelés: az a szállító, amelyik az öt kérdésre gyorsan és konkrétan válaszol, jellemzően az üzemeltetési kérdésekben is megbízhatóbb. A válaszadás módja önmagában információ a cégről, függetlenül attól, hogy a tartalma mennyire kedvező.
Érdemes hozzátenni: a beszerzési oldal ereje nem a cég méretéből jön, hanem a kérdés időzítéséből. Ugyanaz az öt kérdés az ajánlatkérésben tárgyalási tétel, a szerződéskötés után pedig már csak panasz. Ez a különbség egy tízfős cégnél éppolyan érvényes, mint egy nagyvállalatnál – a beszerzés sorrendje független a létszámtól.
A módszer és a korlátok
- 01
Minden jogszabályi állítás a rendelet hatályos szövegéből ellenőrizve: (EU) 2024/1689 és a módosító (EU) 2026/1744, nem másodkézből vett összefoglalókból.
- 02
A szerep-elhatárolás a rendelet fogalommeghatározásaira épül. Ahol a besorolás a konkrét felhasználástól függ, azt a szöveg kimondja, és nem ad rá általános szabályt.
- 03
Az átvilágítási kérdések gyakorlati beszerzési helyzetekből származnak, nem elméleti listából. Mindegyikhez tartozik az is, mit jelent, ha nem érkezik rá válasz.
- 04
A szerződéses kikötéseknél a szöveg nem ad kész klauzula-mintát: a megfogalmazás a konkrét szerződés rendszerétől függ, és jogi ellenőrzést igényel.
- 05
A cikk időbélyeget visel: a 2026 nyári állapotot tükrözi. A későbbi módosítások az éves felülvizsgálaton kerülnek át.
Esettanulmány: amikor a hallgatás volt a válasz
Hat hét, két szállító, egy visszalépés
Anonimizált eset 2026 tavaszáról. Egy huszonöt fős szolgáltató cég ügyfélkezelő rendszert keresett beépített MI-funkcióval. Két ajánlat érkezett, hasonló áron. Az öt kérdés az ajánlatkérésben szerepelt.
| Szakasz | Mi történt | Szám |
|---|---|---|
| 1. hét | Ajánlatkérés kiküldve, benne az öt átvilágítási kérdés | 2 ajánlat |
| 2. hét | A vezető szállító a betanítási adatokra nem válaszolt, kétszeri kérésre sem | 0 válasz |
| 3. hét | A második szállító írásban megadta a modell eredetét és a naplózás módját | 4 oldal |
| 4. hét | Kiderült: a vezető ajánlat naplói 30 nap után felülíródnak, hosszabbítás nincs | 30 nap |
| 5. hét | Ár-újratárgyalás a második szállítóval: 11 százalékkal drágább maradt | +11% |
| 6. hét | Szerződés a második szállítóval, a kikötések a törzsszövegben | aláírva |
Eredmény. A cég a drágább ajánlatot választotta, és ez a döntés a beszerzési dokumentumban indokolva van. A tanulság nem az, hogy a drágább a jobb. Az, hogy a különbség kizárólag azért vált láthatóvá, mert a kérdések az ajánlatkérésben szerepeltek, nem a szerződéskötés előtti héten. Ha a szerződés után derül ki a harmincnapos naplófelülírás, a vevőnek nincs alkupozíciója, csak egy problémája.
A legerősebb ellenérv
Az állítás: A szállítói átvilágítás a kkv-nál is elvégzendő, mert a felelősség a vevőn marad.
Ami ellene szól: Egy tíz-huszonöt fős cég nem tud alkupozíciót érvényesíteni egy nemzetközi szoftverszolgáltatóval szemben. Az általános szerződési feltételeket nem lehet módosítani, a támogatás nem válaszol egyedi kérdésekre, és a valós választás gyakran két hasonlóan zárkózott szolgáltató között van. Ilyen helyzetben az átvilágítás formalitássá válik: elkészül a dokumentum, de a szerződésen nem változtat semmit, viszont elviszi a beszerzés idejének egy részét.
Amit erre mondani lehet: Az ellenérv a nagy szolgáltatóknál megáll, és ezt nem érdemes szépíteni. A különbség az, hogy mire használjuk az eredményt. Ha az átvilágítás célja a szerződés módosítása, akkor valóban kudarcra van ítélve. Ha a célja az, hogy a cég tudja, mit vásárolt, akkor akkor is működik, ha egyetlen szerződéses sor sem változik: kiderül, mit kell a saját oldalon pótolni. A harmincnapos naplófelülírás ismerete attól még hasznos, hogy nem lehet megváltoztatni – a cég ehhez igazíthatja a saját megőrzési gyakorlatát. A tiltólista és az emberi felülbírálat a vevő oldalán marad, ezekhez nem kell a szállító hozzájárulása.
Végrehajtási sorrend és erőforrásigény
| # | Lépés | Ki | Ráfordítás | Kimenet |
|---|---|---|---|---|
| 1 | Az öt kérdés beépítése az ajánlatkérési sablonba | beszerzésért felelős | 2-3 óra, egyszer | bővített sablon |
| 2 | A meglévő MI-szállítók listája: kitől mit vásárolunk ma | beszerzés + informatika | fél nap | szállítói lista |
| 3 | A futó szerződések átnézése a három kritikus kikötésre | beszerzés + jogi | 1 nap | hiánylista |
| 4 | Ahol hiányzik: pótlás a következő megújításkor | beszerzés | megújításonként | módosított szerződés |
| 5 | Amit a szállító nem ad meg: saját oldali pótlás | kijelölt felelős | esetenként 2-4 óra | belső eljárás |
| 6 | Éves felülvizsgálat: mi változott a szállítói oldalon | kijelölt felelős | fél nap, évente | felülvizsgálati feljegyzés |
A teljes első kör két-három munkanap egy huszonöt fős cégnél. A leggyakoribb hiba a harmadik lépés kihagyása: a cég az új beszerzéseknél már kérdez, a futó szerződéseket viszont sosem nézi át, pedig a kockázat többsége éppen ott van.
Másolható: az öt kérdés, ahogy az ajánlatkérésbe kerül
Átvilágítási kérdésblokk – beilleszthető az ajánlatkérésbe
- Milyen modellt vagy modelleket használ a rendszer, és ki a modell fejlesztője? Ha harmadik fél modelljét építi be, kérjük megnevezni.
- Milyen adatokon tanították a modellt, és a mi adataink felhasználásra kerülnek-e további betanításra? Ha igen, kérjük megjelölni, hogyan mondható le erről.
- Milyen naplózást biztosít a rendszer, mennyi ideig őrzi meg a naplókat, és milyen formában adja át azokat, ha kérjük?
- Mi a rendszer megjelölt rendeltetési célja, és mely felhasználásokat zárja ki kifejezetten?
- Milyen dokumentációt ad át átvételkor, és milyen csatornán jelzi, ha a rendszer működésében lényeges változás történik?
A blokk szándékosan öt kérdés, nem húsz. Egy hosszú kérdőívre a szállítók egy része nem válaszol, és a válaszhiányt nehéz értékelni. Öt kérdésnél a hallgatás önmagában értékelhető jelzés.
Fogalomtár
Amit ez a cikk nem tud
- Nem ad szerződésminta-szöveget. A kikötés megfogalmazása a szerződés egészének rendszerétől függ, és jogi ellenőrzést igényel.
- Nem dönti el, hogy egy konkrét rendszer magas kockázatú-e. A besorolás a felhasználáson múlik, és ehhez a folyamat ismerete kell.
- Nem foglalkozik a nemzetközi adattovábbítás adatvédelmi kérdéseivel. Az önálló téma, és a beszerzési döntést érdemben befolyásolhatja.
- A hazai hatósági gyakorlat 2026 nyarán még formálódik. Ahol a szöveg erre támaszkodik, azt közepes konfidenciával jelöli, nem tényként.
Gyakori kérdések
Ha megveszem a rendszert, nem a gyártó felel érte?
A gyártó a saját szolgáltatói kötelezettségeiért felel, de az alkalmazói kötelezettségek a használó cégnél maradnak: a rendeltetésszerű használat, ahol előírt az emberi felügyelet, és a személyzet felkészítése. A kettő párhuzamosan áll fenn.
Mikor válok magam is szolgáltatóvá?
Jellemzően akkor, ha a rendszert a saját nevem vagy védjegyem alatt hozom forgalomba, lényegesen módosítom, vagy megváltoztatom a rendeltetését. Ez lényegesen szigorúbb kötelezettségeket jelent, ezért érdemes tudatosan elkerülni, ha nem cél.
A már futó szerződéseinket is át kell néznünk?
Érdemes, és jellemzően itt van a kockázat nagyobb része. Az új beszerzéseknél a kérdések már beépülnek a folyamatba, a futó szerződések viszont abból az időszakból származnak, amikor ezek a szempontok fel sem merültek. A gyakorlati megoldás nem az azonnali újratárgyalás, hanem a megújítási időpontokhoz kötött, ütemezett pótlás.
Mit tegyünk, ha a szállító általános szerződési feltételei nem módosíthatók?
Ez a nagy nemzetközi szolgáltatóknál a tipikus helyzet. Ilyenkor az átvilágítás célja nem a szerződés módosítása, hanem a saját oldali hiánypótlás megtervezése. Ha a naplók harminc nap után felülíródnak, és ezen nem lehet változtatni, akkor a cégnek kell eldöntenie, hogy exportálja-e őket, vagy vállalja a következményt – de tudatosan, dokumentáltan.
Számít-e, hogy a szoftverben csak egy kis MI-funkció van?
A kötelezettség a felhasználáshoz és annak kockázatához kapcsolódik, nem a funkció méretéhez. Egy apró jelöltszűrő modul foglalkoztatási döntést befolyásol, ezért súlyosabban esik latba, mint egy nagy nyelvi modell, amit belső jegyzetelésre használnak. A kérdés mindig az, mire hat a kimenet.
Ki végezze el az átvilágítást egy kis cégnél?
Ugyanaz a személy, aki a beszerzést egyébként intézi. Az öt kérdés nem igényel jogi vagy műszaki szakértelmet a feltevéshez – a válaszok értékeléséhez viszont érdemes bevonni azt, aki a rendszert használni fogja. A felhasználó ismeri fel leghamarabb, ha egy válasz a gyakorlatban nem működik.
Elég, ha a szállító azt írja, hogy megfelel az AI Actnek?
Önmagában nem elég. Az általános megfelelőségi állítás nem mondja meg, milyen kockázati kategóriába esik a mi konkrét felhasználásunk, és nem pótolja a dokumentációt, amiből a saját kötelezettségeinket teljesíteni tudjuk. Konkrét, a mi használatunkra vonatkozó nyilatkozat kell.
Mi a helyzet a nemzetközi felhőszolgáltatókkal?
Ott ritkán van egyedi szerződés. Ilyenkor a nyilvános feltételek átvizsgálását és a saját korlátozásaink rögzítését kell elvégezni – dátummal. Ez a feljegyzés lesz a megfelelés bizonyítéka.
Kell-e külön kikötés az alvállalkozókra?
Igen, ha a nevünkben kezelik a rendszert. Az adatkezelési és az MI-ismeretségi elvárás terjedjen ki rájuk is, és a partner nyilatkozzon a saját gyakorlatáról.
Mennyi időt vesz igénybe egy ilyen átvilágítás?
Alacsony tétnél néhány óra, közepesnél egy-két nap. A magas kockázatú felhasználás ennél több, de ott a beszerzési döntés súlya is nagyobb. A legdrágább változat mindig az, amit utólag kell pótolni.
Források
- (EU) 2024/1689 rendelet – EU AI Act – A szolgáltatói és alkalmazói szerepek elhatárolása, az alkalmazói kötelezettségek, valamint az a szabály, amely szerint a jelentős módosítás vagy a saját név alatti forgalomba hozatal szolgáltatóvá minősítheti a vevőt. (2024)
- (EU) 2026/1744 rendelet – Digital Omnibus on AI – A magas kockázatú rendszerek határidejének kitolása 2027. december 2-re; hatályos 2026. július 27-től. (2026)
- 2025. évi LXXV. törvény és 344/2025. Korm. rendelet – Az AI Act magyar végrehajtási kerete: hatósági kijelölések és eljárási szabályok. (2025)