Öt dolog, amire érdemes odafigyelni AI megoldások beszerzésekor

A belső jogászok kontroll-szerepe az utóbbi időben felértékelődni látszik a vállalatok által eszközölt AI-beszerzések során. Ennek oka, hogy például az IT-szerződések évtizedes gyakorlatával ellentétben ezen a területen egyelőre még nem alakultak ki azok az egyértelmű piaci standardok és elvárások, amelyeket egy AI eszköz vagy éppen fejlesztés beszerzése során egy megrendelő reálisan elvárhat a beszállítótól. Mivel az üzleti döntéshozók elsősorban az AI által ígért előnyöket tartják szem előtt, az IT csapat pedig általában a technológiai integráció kérdéseivel foglalkozik, sok esetben a jogászokra marad a feladat, hogy a beszerzés munkáját az AI által felvetett speciális jogi kérdésekben támogassa. Szintén a jogászok feladata, hogy a cég üzleti elvárásait jogi szaknyelven megfogalmazzák, illetve az adott szolgáltató, illetve az általa értékesíteni kívánt AI rendszer kockázatait megfelelően azonosítsák és kezeljék többek között szerződéses kötelezettségvállalásokkal, tilalmakkal, engedélykérések és szavatosságok előírásával. Ennek a feladatnak az elvégzéséhez azonban az AI jogi szabályok ismeretén túl szükséges az AI kockázatmenedzsmentre vonatkozó gyakorlatok, és a beszerzési folyamatok AI specifikus szempontrendszerének az ismerete is. Az alábbiakban a felelős AI beszerzésekről szóló IEEE 3119:2025 szabvány tanúsított szakértőjeként összefoglalom azt az öt legfontosabb tudnivalót, amelyeket érdemes szem előtt tartani az AI megoldások beszerzése során.

1. Milyen problémát szeretnénk megoldani az AI használatával?

A use case meghatározásának fontossága

AI megoldásokat fejlesztő cégeket képviselve több alkalommal tapasztaltam, hogy a megrendelő egyszerűen nem tudta megmondani pontosan, hogy mi az a probléma, amire AI-alapú megoldást keres. Emögött általában az áll, hogy az üzleti döntéshozó anélkül vetett szemet a hatékonyságnövelési és/vagy költségcsökkentési ígéretekkel beharangozott AI megoldásra vagy egy lehetséges fejlesztési ötletre, hogy végiggondolta volna annak a saját üzleti tevékenységében elfoglalt helyét és az AI hatásmechanizmusát, és egyértelműen definiálta volna a konkrét igényt. Ennek rögtön két kockázata is van. 

A felesleges beszerzések és a magasabb költségek kockázata

Az egyik, hogy a megrendelő fokozottan kiszolgáltatottá válhat a szolgáltatói ígéreteknek, és olyan AI rendszert vásárolhat meg, ami nem lesz alkalmas az általa akár csak holisztikusan elképzelt üzleti célra. A második probléma, hogy külső fejlesztés esetén a szolgáltatónak is rendkívül fontos a megrendelő konkrét felhasználási esetének a meghatározása, mivel a fejlesztők díjazása, vagy legalábbis a sikerdíja sok esetben közvetlenül függ az AI-jal elért megtakarításoktól. Amennyiben viszont a megrendelő nem végezte el a házi feladatát, úgy kénytelen lesz kifizetni azt a többletköltséget is, ami a szolgáltató ezzel kapcsolatos tevékenysége során merül fel.

Ha tehát a költséghatékonyság fontos szempont, akkor érdemes előzetesen elvégezni ezt a feladatot.

A probléma egyeztetése és definiálása

Ennek a leghatékonyabb módja az elérni tervezett üzleti cél meghatározása, a beszerzési tervekkel érintett belső vezetőkkel és egyéb érintettekkel való egyeztetés és a felhasználási eset finomítása,  a cél elérésére alkalmas lehetséges (akár AI nélküli) megoldási javaslatok és a piacon már elérhető szolgáltatások feltérképezése, a felhasználási esettel kapcsolatos kockázati kritériumok meghatározása, és a fenti folyamat dokumentálása. 

2.  A megrendelői követelményrendszer meghatározása

AI vagy hagyományos megoldás?

Amennyiben a folyamat során kialakult konszenzus abba az irányba mutat, hogy AI alapú megoldás szükségeltetik, akkor érdemes átgondolni az adott use case-re vonatkozó belső szervezeti és külső jogi, illetve szerződéses követelményeket, mégpedig azért, mert ezeket a konkrét megoldással kapcsolatos technológiai elvárások mellett szükséges lesz beépíteni a konkrét szolgáltató és/vagy az általa kínált megoldás kiválasztási és értékelési folyamatába.

Ennek a folyamatnak az eredményeként szerencsés esetben előállhat egy olyan dokumentum, ami egyértelműen tartalmazza az adott szolgáltatással és szolgáltatóval kapcsolatos követelményeinket, amelyet akár RfP formájában is megküldhetünk a feladatra pályázó jelölteknek.

A jogi követelmények beazonosítása

Amennyiben például a tervezett felhasználás az AI Act által magas kockázatúnak minősített területen történne (például HR-ben, vagy az oktatásban), akkor érdemes figyelembe venni azt is, hogy az AI Act releváns, a szolgáltatóra és felhasználóra vonatkozó kötelezettségei már 2027. december 2-tól alkalmazandóak lesznek. Mivel eddig a határidőig alig több, mint egy év van hátra, így a beszerzési és kivitelezési folyamat hosszától függően érdemes olyan szolgáltatót és szolgáltatást választani, aki megfelelően garantálni tudja a hamarosan alkalmazandó jogi kötelezettségek teljesítését és a megfelelő dokumentáltságot is, hogy mire hatályba lépnek a jogi kötelezettségek, ne kelljen újratárgyalnunk a szerződésünket, vagy ne kelljen új szolgáltató vagy termék után néznünk.

On-prem vagy cloud?

Bankoknál és egyéb, szabályozott szektorokban működő cégeknél többször felmerül, hogy a felhasználási esettel érintett adatok szenzitivitása és bizalmassága miatt inkább helyben telepített (on-prem) AI megoldást szeretnének, mivel a felhő-alapú technológiai stack-et nem gondolják kellően sem transzparensnek, sem biztonságosnak. A helyszíni telepítés és futtatás ugyanakkor általában nem várt pluszköltségekkel is járhat, mivel a rendszer helyi futtatásához és a helyi infrastruktúra kiépítéséhez komoly számítási kapacitás szükséges, ami nem olcsó mulatság, és általában a működés minősége is elmarad a fejlettebb modellekétől.

Ezt egy külső fejlesztés beszerzése esetén még tetézheti az a plusz kockázat is, hogy ilyen esetben a szolgáltatók általában a sokkal kevésbé védett, és magasabb kiberbiztonsági és egyéb kockázati kitettséggel járó nyílt súlyú kínai modelleket használnak, így a látszólagos, helyi telepítésnek tulajdonított előnyből könnyen költséges hátrány, és felesleges kockázati kitettség keletkezhet. 

Kockázatkezelés a tervezés és üzemeltetés kapcsán

Szintén fontos annak tisztázása is, hogy az AI rendszernek milyen a kockázati profilja, és ennek érdekében a kapcsolódó ISO szabványokat is segítségül hívhatjuk a felhasznált modellel, a részünkre leszállítandó vagy fejlesztendő AI rendszerrel, vagy éppen a belső felhasználási környezetünkben jelentkező kockázatok definiálásával és kezelésével kapcsolatban. Ezen folyamat során leginkább a vállalati kockázatmenedzsmenttel foglalkozó ISO 31000:2018 és az AI kockázatok kezelésével foglalkozó ISO/IEC 23894:2023 szabályrendszerek jöhetnek szóba. Fontos, hogy az általunk a kockázatok kezelésére meghatározott kockázatkezelési megoldásokat szintén megfelelően artikulálnunk kell, mivel ezekre a kiválasztási folyamat részeként, és végül a szolgáltatónkkal kötött szerződésben is hivatkoznunk kell majd.

Ha a kockázatkezelést elmulasztjuk, akkor kénytelenek leszünk megelégedni a szolgáltató nemlétező, vagy bizonytalan tartalmú biztonsági ígéreteivel, és ha ezeket csak később azonosítjuk be, akkor könnyen belefuthatunk abba is, amit már én is sokszor tapasztaltam megrendelői képviselet közben, hogy a szolgáltató egyszerűen magasabb díjat kér egy egyébként szokásos biztonsági feature beépítéséért vagy működtetéséért. 

Minimum elvárások egy vállalati chatbot-tal kapcsolatban

Ez utóbbira jó példa lehet egy chatbot vállalati weboldalba történő integrációja, ahol a felhasználók által beírt promptok és az AI modell által adott válaszok megfelelő előszűrése, valamint ezek egyes esetekben emberi felülvizsgálatra utalása mára már alapkövetelmény, de a szolgáltatók sok esetben a szolgáltatás minőségének romlására, és a biztonsági megoldások költségességére hivatkozással utasítják el az erre irányuló megrendelői kéréseket. Szerencsésebb és biztonságosabb tehát, ha ezeket a feltételeket előre meghatározzuk és közöljük a beszállítónkkal.

A céges elvárás-, illetve követelményrendszerünk meghatározásakor tehát érdemes ezeket a szempontokat is figyelembe vennünk számos egyéb feltétel (például a titokvédelem, adatvédelem) mellett.

3.  A szolgáltató kiválasztása és értékelése

A szolgáltató érettségének és felkészültségének ellenőrzése

Természetesen egy ChatGPT vagy ehhez hasonló előfizetés megvásárlásakor nem merül fel sem igényként, sem lehetőségként, hogy a szolgáltató érettségét, felkészültségét és teljesítőképességét ellenőrizzük, de egy önálló fejlesztésre adott megbízáskor, vagy egy már meglévő AI rendszer beszerzésekor érdemes ezt is mérlegelni. Ennek az adhat különös jelentőséget, hogy az AI fejlesztési piacra történő belépés korlátai meglehetősen alacsonyra csökkentek az utóbbi időben, és a szolgáltatóknál a fejlesztések alapjául szolgáló, egyre erősebb AI modellek képeségeinek kihasználására való képességtől általában messze elmarad a felelős, kiszámítható, biztonságos és etikus AI használathoz és fejlesztéshez szükséges szervezeti felkészültség és governance struktúra.

A beszerzési követelményrendszer AI szempontokkal történő kiegészítése

Amennyiben fontosabb funkciót kívánunk a szolgáltató által értékesített vagy fejlesztett megoldással, vagy amennyiben a belső vállalati rendszerünk amúgy is részletes előírásokat tartalmaz a technológiai megoldásokat beszállítók kiértékelésével és rangsorolásával kapcsolatban, akkor ezt a szempontrendszert érdemes kiegészíteni néhány AI-specifikus elemmel is.

Fontos például, hogy a szolgáltatónál rendelkezésre álljanak azok a szervezeti, személyi és technológiai garanciák és eljárások, amelyek egyértelműen biztosítani tudják a nyújtani kívánt szolgáltatás magas színvonalát, pontosságát, megbízhatóságát, lekövetik a felhasznált AI modellek piacán folyamatosan történő változásokat, és például az emelkedő token-költségek szem előtt tartásával optimalizált felhasználói élményt tudnak nyújtani cégünknek.

Szabványok: tényleges, vagy csak látszólagos biztosíték?

Ha egy szolgáltató rendelkezik az információbiztonságra vonatkozó ISO/IEC 27001:2022, az annak módszertanára épülő, az AI irányítási rendszerekkel kapcsolatos jó iparági gyakorlatokat kodifikáló ISO/IEC 42001:2023, vagy más hasonló minősítéssel, az mindenképpen jó jel, mivel arra utal(hat), hogy az adott cég egyszer már alaposan végiggondolta, internalizálta, és remélhetőleg működőképes szabályzatokban és eljárási protokollokban rögzítette a működési környezetére és tevékenységére vonatkozó szabályokat, a kockázatkezelés rendjét, és a magukkal szemben támasztott elvárásokat. Persze a munkám során több olyan céggel is találkoztam, ahol egy ISO-szabvány bevezetése kimerült egy dokumentumcsomag testreszabásában és kihirdetésében, miközben az irányítási rendszer működtetéséhez szükséges governance folyamatok csak részben, vagy egyáltalán nem kerültek kialakításra. Amennyiben fontosnak tartjuk ezt a területet, akkor egy egyszerű megerősítésen túl érdemes egyéb kérdéseket is feltenni a belső governance rendszer működésével kapcsolatban.

Az ezen folyamat körében ellenőrizendő intézményes garanciák között felmerülhet továbbá az Európai Bizottság ún. gyakorlati kódexeihez való csatlakozás ellenőrzése, más hasonló szabályrendszerek bevezetése, illetve a szolgáltató beszállítói láncolatának ellenőrzésére kialakított eljárásrend ellenőrzése is.

4. Az AI rendszer megfelelőségének ellenőrzése

A szekvenciális megközelítés fontossága

A feladat ebben a részében arról igyekszünk meggyőződni, hogy a részünkre kínált AI megoldás alkalmas-e az általunk előzetesen meghatározott, illetve a jogszabályokból, belső szabályzatainkból és/vagy az irányadó szabványoknak megfelelő követelményeknek, és rendelkezik a szolgáltató marketing anyagában körülírt tulajdonságokkal.

Ez a folyamat nyilván nehezebb, és kevesebb sikerrel kecsegtet, ha a fenti kezdeti folyamatokat nem végeztük el. Szintén nagyobb a kitettségünk, ha nem ismerjük a szolgáltató által kínált megoldás technológiai sajátosságait, működési kockázatait, a rá irányadó jogi követelményrendszert.

A feladat elvégzéséhez szükséges dokumentumok és információk

Meglévő szolgáltatás beszerzésekor érdemes egy részletes műszaki leírást kérnünk az AI rendszer működéséről, dependenciáiról, kockázatairól, használatának feltételeiről, az engedélyezett és/vagy rendelkezésre álló felhasználási esetekről, a költségek és a felhasználás skálázhatóságáról, a működéshez szükséges adatigényről, a biztonságos felhasználáshoz szükséges oktatási igényekről, a rendszerben felhasznált AI modellek kiválasztásának feltételeiről és körülményeiről, az AI rendszer vállalati környezetbe való integrálhatóságának követelményeiről. Ezeket az információkat természetesen egyeztetnünk szükséges házon belül az egyes szakterületekkel is, és ennek során a jogi megfelelőségről, az üzleti cél megvalósíthatóságáról és a rendszer alkalmasságáról, a compliance, adatvédelmi és kiberbiztonsági, valamint a rendszerintegrációs feltételek teljesítéséről érdemes az érintett területek vezetőinek szakvéleményét is kikérni. 

Ez az a kör, ahol rendszerint felmerül az AI rendszer által létrehozott eredmények használhatóságának kritériumrendszere, az érintett felhasználási eset komplexitásának szintjéhez igazoldó emberi felügyelet intézményrendszerének ellenőrzése is. Ez utóbbi értelemszerűen más egy egyszerű vállalati chatbot esetében, és megint más (jóval bonyolultabb és összetettebb) egy ügynöki AI megoldás beszerzése esetén, ahol külön ügyelni kell az ügynökök részére engedett felhatalmazások és engedélyek megfelelő szabályozására, és a működés vészhelyzeti leállíthatóságának ellenőrzésére is. 

Bizonyos use case-k esetén nem felesleges a nekünk kínált vagy részünkre fejlesztett AI rendszer megfelelő működéséért felelős “rendszer prompt”-jának, valamint a rendszerben felhasznált modellek megfelelőségével kapcsolatos kiválasztási szempontok vizsgálata sem, és elmondható, hogy

az ellenőrzési feladattal kapcsolatos általános elvárhatóság kritériumrendszerének meghatározása a lehetőségek és kockázatok gazdag tárháza miatt itt is rendkívül nehéz.

Több esetben sor kerülhet az AI rendszerrel kapcsolatos hatásvizsgálat elvégzésére is (mi erre általában az ISO/IEC 42005:2025 szabványt használjuk az eset körülményeire történő testreszabást követően), amelynek az eredménye becsatornázásra kerülhet a kockázatkezelési rendszerbe, és természetesen a szolgáltatóval megkötendő szerződésbe is.

 A szolgáltató által rendelkezésünkre bocsátott, és az egyéb forrásokból beszerzett információk és dokumentumok körültekintő mérlegelése segíthet a számunkra megfelelő szolgáltató és megoldás kiválasztásában.

5.  A szerződéskötési folyamat

Tervezettől a megállapodás aláírásáig

Ha a folyamatban idáig eljutottunk, akkor már csak a szerződéstervezet elkészítése és/vagy a meglévő, általában szolgáltatói tervezet “kitárgyalása”, és a szerződés megkötése marad hátra. 

Bár a beszerzési szekvenciában ez az utolsó lényeges lépés, jelentőségében mégis túlmutat az eddigieken, hiszen amennyiben nem sikerül jogilag pontos, közérthető nyelven és kikényszeríthető, számonkérhető és szankcionálható módon, megfelelő garanciákkal körbebástyázva megfogalmaznunk a korábban beazonosított elvárás-rendszerünket, akkor bizony az elvégzett munka nagy része kárba veszhet.

Szakértők igénybevétele, és az AI officer szerepe

Hogy ez ne így történjen, ahhoz javasolt az ilyen megállapodások elkészítésében járatos jogi tanácsadó igénybevétele, aki ismeri nemcsak a technológiát, az irányadó jogi követelményeket, de rendelkezik a területen alkalmazott szabványok szerinti szemlélettel is. Szintén előny, ha a kiválasztott tanácsadó ismeri a másik oldal preferenciáit és szempontrendszerét is, így különbséget tud tenni a jogos és eltúlzott elvárások között, ezzel is segítve a szerződéssel kapcsolatos szerkesztési és tárgyalási folyamatokat, és a működőképes, mindkét fél számára elfogadható kompromisszumos megoldások kidolgozását és megtalálását. Ha a fentiek közül bármelyik képesség hiányzik, az a folyamat elhúzódásához, vagy akár megakadásához is vezethet. Ha a megrendelő esetleg rendelkezik megfelelő kvalitásokkal bíró belső AI governance vezetővel, az nagymértékben megkönnyítheti a folyamat lebonyolítását, mivel tapasztalataim szerint sokszor a megrendelői oldalon az egyes szakterületek közötti mediálatlan egyet nem értés is megakaszthatja az ügymenetet.

Ha például a compliance a terület szakértő ismerete okán megfelelő szűrés nélkül küldi ki a hagyományosan hosszú beszállítói kérdőívét, ez sokszor megijesztheti az egyébként jó megoldást kidolgozó, de a szervezeti érettség alacsonyabb fokán álló beszállítót, aki nem biztos, hogy szeretne akár többszázezer forintot elkölteni egy külsős AI jogi tanácsadó igénybevételére, aki segít neki megválaszolni az egyébként a megrendelő szempontjából standard kérdőívet. 

Miben különböznek az AI szolgáltatásokat szabályozó megállapodások az IT szerződésektől?

Az AI megoldásokkal kapcsolatos szerződések bár sokban emlékeztetnek a hagyományos IT-szerződésekre, sokban különböznek is azoktól. A szerződés szempontjából kulcsfontosságú a leszállítandó rendszer képességeinek, funkcióinak, engedélyezett és tiltott felhasználási eseteinek meghatározása, a szolgáltató korábbi vonzó ígéreteinek a szerződésben számonkérhető és szankcionálható kötelezettségekre történő lefordítása. 

Az AI tulajdonságaival kapcsolatos kockázatok allokációja és a felelősségkorlátozó rendelkezések

Nem kerülhető meg az AI technológia véletlenszerűségével kapcsolatos kockázatok megfelelő allokációja és az egyes ellenérdekű felek pozíciójának végiggondolása sem. A szolgáltató részéről természetesnek tűnhet, hogy a rendszer működéséből fakadó valamennyi kockázatot (ideértve az esetleges hallucinációkat, kitalációkat, pontatlanságokat, megbízhatatlanságot) a megrendelőre hárítsa, viszont ugyanez a megrendelő oldaláról általában ritkán elfogadható, még akkor is, ha az AI megoldások piacán a nagy modell és rendszer szolgáltatók is minden esetben a downstream felhasználóra tolják át a szállított megoldással kapcsolatos kockázatokat. 

Itt kerülhetnek előtérbe a kártérítési és kimentési klauzúlák, valamint a fentebb már említett, a rendszer szolgáltatójától elvárható biztonsági intézkedések. Lehet, hogy egy az ügyfelek által használt vállalati chatbot néha valótlant állít, de ha a szolgáltató ennek mérséklésére megfelelő intézkedéseket vezetett be, az némileg ellensúlyozni tudja a fenti egyoldalú helyzetet.

Természetesen nagyon sok függ a megrendelő kockázati étvágyától és kockázatkezelési szabályaitól is, és természetesen más a kitettség egy csak válaszokat, illetve tartalmakat gyártó AI rendszer, és egy komplex célok megvalósítására alkalmas ügynöki AI megoldás esetén. 

Ennek megfelelően változhat a szolgáltatói felelősség felső határa, és az általa alkalmazott felelősségkizárások megrendelő általi elfogadhatósága is. Ezt természetesen egyéb szempontok (például a szolgáltató által ajánlott kedvezményes ár) megfelelően ellensúlyozhatják, de fel kell készülni az olyan szolgáltatói megközelítésekre is, miszerint a szolgáltató által ajánlott ár csak a szolgáltató által szigorú és egyoldalú felelősségkizárás mellett érvényes. Ezekre tapasztalataim szerint azok a megrendelők tudnak stratégiai módon és jól reagálni, akik egyrészt konzekvensen követték a fentiekben meghatározott eljárásrendet, másrészt tisztában vannak az adott AI megoldás által jelentett kockázatok mértékével, és így számszerűsíteni tudják a szerződés alapján őket fenyegető kitettségüket. Ez a szám aztán megfelelő hivatkozási alapot képezhet a szerződéses tárgyalások során, és összevethető a szerződésen túlmutató, adott esetben a megrendelő rendelkezésére álló kockázatkezelési eszközökkel (például biztosítás) is.

A kis cégek korlátozott felelősségvállalási képessége a nagyvállalati elvárások tükrében: a kockázati asszimetria

A felelősségvállalás egyébként azért is válhatott ilyen kardinális kérdéssé az AI szerződések területén, mert a piacra való belépés szintjének csökkenése egy csomó olyan start-up megjelenését eredményezte, akiknek a pénzügyi teljesítőképessége és forrásai egyszerűen nem állnak arányban az általuk kínált megoldások kockázati profiljával. Számos olyan esetet láttam elsősorban megrendelői oldalon, ahol a szolgáltató azért utasította el az egyébként a piaci standardoknak megfelelő, és a megrendelő nagyvállalati státuszához igazított felelősségi szabályokat, mert egyszerűen nem rendelkezett az ahhoz szükséges anyagi fedezettel, és mivel az AI károkkal kapcsolatos biztosítási piac is még alakulóban van, a szerződéses kockázatot még így sem tudta volna másra áthárítani. Ez egy olyan szempont, amire főleg nagyvállalati oldalon érdemes különösen odafigyelni a szolgáltatói és a szolgáltatásokkal kapcsolatos kiválasztási és szerződési folyamatok során.

Az AI értékláncbeli szerepek meghatározása

Legalább ennyire fontos a szerződésekben az egyes felek AI Act-beli szerepének a meghatározása, amely néha nem is olyan egyszerű, mint amilyennek elsőre tűnik. Ha a fenti példánál maradva egy vállalati chatbotot fejlesztetünk egy szolgálatóval, akkor jó eséllyel annak szolgáltatójává is válhatunk, ami hátrányosabb, mintha csak alkalmazóként használnánk azt. Sokszor maguk a szolgáltatók sem rendelkeznek az ahhoz szükséges szaktudással, hogy a saját AI-értékláncbeli szerepüket pontosan meghatározzák, így nem ritka az ezzel kapcsolatos vita, aminek a fő oka az, hogy az AI Act alapján az egyes szereplőket terhelő kötelezettségeket jórészt az általuk betöltött szerepkör határozza meg.

Slágertémák a szerződésekben

Gyakran felmerülő téma a szerződéses tárgyalások során az AI rendszer, az annak működtetése során felhasznált adatok, az AI rendszer által generált eredmények szellemi alkotáshoz fűződő jogainak a kérdése is, illetve külső fejlesztés esetén a szolgáltató által létrehozott modell, vagy rendszer jogai megrendelőre történő átruházásának, az ehhez szükséges leszállítandók listájának meghatározása is. 

Szerződéses slágertémák még az adatvédelmi, titokvédelmi szerepkörök és kötelezettségek megfelelő, kockázati-alapú definiálása, a szolgáltató teljesítésével kapcsolatos mennyiségi és minőségi kritériumok, a működtetéssel kapcsolatos monitoring, változáskövetési eljárások, valamint a riportálási kötelezettségek tartalmának meghatározása, és a nem megfelelő teljesítés, illetve a szerződésszegés szankciórendszerének (szavatossági igények, kötbér, felmondás stb.) kidolgozása és kitárgyalása is. Ennek a részletessége, megfogalmazása természetesen attól is függ, hogy melyik fél milyen érdekérvényesítő képességgel rendelkezik, kinek fontosabb és sürgősebb a szerződés gyors tető alá hozatala. Gyakori, hogy a szolgáltatás nyújtásának megkezdése megelőzi a szerződés aláírását. Bár ez többek között adatvédelmi compliance szempontok miatt sem javasolt, a megrendelő malmára hajthatja a vizet, mivel a szolgáltatói számlák kiállításához és befogadásához általában szükséges az írásban aláírt szerződés is.

Ha a megrendelő egy úgynevezett szabályozott szektorban tevékenykedik, például vonatkozik rá a hazai általános, vagy ágazati kiberbiztonsági szabályozás, akkor az általában alkalmazandó adatvédelmi szabályok mellett az ilyen előírásokból fakadó kötelezettségeket (ideértve az incidenskezelést is) a szolgáltatóval kötött szerződésben is meg kell határoznunk.

A szerződéssel kapcsolatos monitoring tevékenység

Természetesen a történet még itt sem ér véget, hiszen a megkötött szerződés teljesítésének ellenőrzése legalább annyira fontos, mint annak szakszerű elkészítése és véglegesítése. A szerződés monitoring-gal kapcsolatos legfontosabb teendőket és tudnivalókat viszont majd egy külön cikkben fogom összefoglalni.

Amennyiben AI megoldással kapcsolatos beszerzési eljárással, a beszállító, vagy egy adott AI rendszer értékeléséhez, esetleg a szolgáltatóval megkötendő szerződéskötéshez kötődő segítségre vagy tanácsadásra lenne szükséged, szívesen állok rendelkezésedre az itteni elérhetőségeim bármelyikén.