Az AI-beszállító kiválasztásának helyes sorrendje: üzleti célok, majd a szabályozási szerepek tisztázása, végül pilot alapú validálás. Ne technológiával kezdje, hanem azokkal a KPI-kkel, amelyeket javítani akar. Rögzítse, hogy a beszerzett rendszer melletti jogi szerepe provider vagy deployer, és ezt vezesse át a szerződésen. Csak a mért pilot után skálázzon.

Röviden:

  • Az EU AI Act 25. cikke szerint a vevő szolgáltatóvá válhat, ha saját márkás rendszert forgalmaz, lényegesen módosít vagy megváltoztatja a rendeltetést.
  • Az ajánlatkérésben kérjen kiindulási értéket, célértéket és elfogadási küszöböt minden üzleti mutatóhoz, valamint írásos dokumentációt a kockázatokról és a korlátokról.
  • Szerződéskezelési pilotban hasonlítsa össze az egy szerződés átnézésére fordított átlagos időt a próba előtti értékkel, valós adatokon, majd döntsön előre rögzített küszöb alapján.
  • A legjobb két vagy három ajánlattevőtől kérjen pilotjavaslatot, majd azonos adatokon és feltételekkel hasonlítsa össze teljesítményüket, dokumentált elfogadási küszöbök szerint.
  • Csak akkor skálázzon, ha az üzleti elfogadási küszöbök teljesülnek, a technikai mutatók stabilak maradnak, és a beszállító vállalja az üzemeltetési feltételeket.
Stratify
Válasszon üzleti célhoz illő AI-megoldást
A Stratify üzleti célok, kockázatok és megtérülési lehetőségek alapján segít az AI-megoldások értékelésében és bevezetésében.

Ismerje meg a Stratifyt

Tartalomjegyzék

Milyen szempontok szerint értékelje az AI-beszállítókat?

A beszerzés és az IT akkor tud gyorsan szűrni, ha mindkét oldal ugyanazt a rangsorolt listát használja. Az alábbi szempontokat javasoljuk fontossági sorrendben, és a súlyozást érdemes az ajánlatkérés előtt rögzíteni, nem utána.

  • Üzleti érték: kérjen be a beszállítótól mérhető KPI-ket (például egy szerződés átfutási ideje, a manuális ellenőrzésre fordított órák, a hibás tételek aránya), és minden KPI-hez induló értéket, célértéket és elfogadási küszöböt. Ha a beszállító nem tud a saját termékéhez mérési módszert javasolni, az figyelmeztető jel.
  • Governance és megfelelés: kérjen írásos dokumentációt a kockázatkezelésről, a tesztelésről és a rendszer ismert korlátairól. A szerepek tisztázása az Article 25 miatt szerződéses kérdés, nem pusztán jogi háttérinformáció.
  • MLOps-érettség: verziókövetés, újratanítási rend, automatizált telepítési folyamat és élő monitoring. Kérdezze meg, ki és milyen eseményre indít újratanítást.
  • Adatkezelés és adatminőség: ki fér hozzá az adataihoz, történik-e anonimizálás, mennyi ideig őrzik meg a bemeneteket és a naplókat, és vissza lehet-e törölni őket a szerződés végén.
  • Magyarázhatóság és emberi felülvizsgálat: milyen indoklást ad a rendszer egy-egy döntéséhez, és hol kapcsolódik be az ember a folyamatba.
  • Szerződéses kitételek: felelősségi korlátok, szellemi tulajdon, együttműködési kötelezettségek és kilépési feltételek.

A súlyozáshoz egy egyszerű mátrix is elég: minden szempontra adjon pontot, szorozza a fontossági súllyal, és az eredményt vesse össze a pilot tapasztalataival. Így a döntés nem a legjobb prezentációt, hanem a legjobb bizonyítékot díjazza.

Profi tipp: Az ajánlatkérésbe tegye be, hogy a beszállító írásban nevezze meg a rendszer szándékolt rendeltetését. Ha később eltér tőle, pontosan látszik, ki változtatott.

Mely beszerzési feladatokban térül meg leginkább az AI?

A beszállító követelményeit a konkrét felhasználási eset határozza meg, ezért először válassza ki, hol keletkezik a legtöbb ismétlődő, dokumentumigényes munka. A jó jelölt olyan feladat, ahol sok az adat, a szabályok nagyjából rögzítettek, és az eredmény ellenőrizhető.

  • Szerződéskezelés: a rendszer kiemeli a lejárati dátumokat, az eltérő felelősségi klauzulákat és a sablontól való eltéréseket, a jogász pedig csak a jelölt részeket olvassa át.
  • Kiadás- és költségelemzés: a tételek automatikus kategorizálása felfedi a szétszórt, kedvezmény nélküli vásárlásokat és a duplikált beszállítókat.
  • Beszállítói teljesítmény-előrejelzés: késések, minőségi reklamációk és szállítási minták alapján jelzi, mely partnernél nő a kockázat.
  • Tudásmenedzsment: egy RAG alapú belső keresőasszisztens (olyan rendszer, amely a cég saját dokumentumaiból válaszol, forrásmegjelöléssel) a beszerzési szabályzatokra, korábbi ajánlatokra és szerződésekre ad gyors választ.
  • Kockázatmonitoring az ellátási láncban: hírek, pénzügyi jelzések és szállítási adatok összevetése a kritikus partnerekre.

Pilotfázisban minden esethez érdemes egyetlen mérőszámot rögzíteni. Szerződéskezelésnél ez lehet az egy szerződésre jutó átlagos átnézési idő a pilot előtt és alatt, költségelemzésnél a kategorizálás pontossága egy kézzel címkézett mintán, a keresőasszisztensnél pedig az, hogy a válaszok mekkora része hivatkozik helyes forrásra. További példákat a munkafolyamatokban használható AI-alkalmazási területekről szóló összefoglalónkban talál.

Mit jelent a provider és a deployer szerep az EU AI Act szerint?

Az EU AI Act eltérő kötelezettségeket ír elő a rendszert fejlesztő és forgalomba hozó providernek, a használó deployernek, valamint az importőröknek és forgalmazóknak. A szerepek tisztázása szerint a hibás besorolás konformitási kockázathoz és bírsághoz vezethet, ezért a beszerzés első teendője a szerep azonosítása.

Az Article 25 lényege, hogy a vevő provider-ré válhat. Ez három esetben fordulhat elő: ha saját neve vagy védjegye alatt hozza forgalomba a rendszert, ha lényegesen módosítja, vagy ha úgy változtatja meg a rendeltetését, hogy az magas kockázatúvá válik. Ilyenkor a vevőre hárulnak a provider feladatai, az eredeti szolgáltatónak pedig együtt kell működnie, és hozzáférést kell adnia a dokumentációhoz.

Feltételek, amelyek átruházzák a vevő szolgáltató felelősségeit

A kötelezettségek eltérnek: a provider köteles kockázatkezelési rendszert működtetni és műszaki dokumentációt fenntartani, a deployerre pedig üzemeltetési naplózás és emberi felülvizsgálat jellegű feladatok hárulhatnak.

A beszerző teendői a szerepek tisztázására:

  1. Rögzítse írásban, milyen célra használja majd a rendszert, és vesse össze a beszállító által megadott rendeltetéssel.
  2. Döntse el, hogy a saját márkanév alatt, külső ügyfeleknek fogja-e nyújtani a megoldást.
  3. Kérje el a műszaki dokumentációt és az ismert korlátok, hibamódok leírását, és szerződésben biztosítsa a hozzáférést.
  4. Rögzítse, hogy a rendszer lényeges módosítását csak előzetes egyeztetéssel, dokumentált tesztelés után lehet elvégezni.
  5. Kérje a naplók exportálhatóságát és megőrzési idejének meghatározását.

A szabály lényege az Article 25-ben: a forgalmazó, importőr, deployer vagy más harmadik fél provider-ré válhat, ha saját neve alatt hozza forgalomba a rendszert, lényegesen módosítja, vagy megváltoztatja a rendeltetését. A jogi következményekről részletesebben a magyar cégekre gyakorolt hatásról szóló jogi összefoglalónkban írunk.

Milyen műszaki érettséget kérjen számon az AI-beszállítótól?

Az IT-nek és az architektúráért felelős kollégáknak nem a modell tudása, hanem az üzemeltethetőség a kulcskérdés. Egy jó modell is használhatatlan, ha nem látszik, mikor romlik el, és nem lehet visszaállítani az előző verziót.

  • Modell életciklusa: verziókezelés minden modellre, dokumentált újratanítási szabály, fokozatos kivezetés (canary rollout), amelyben egy új verzió előbb a forgalom kis részét kapja.
  • Monitoring és naplózás: kérjen mérőszámokat a pontosságról, a válaszidőről és az adateltolódásról (drift), valamint egyértelmű megőrzési időt az üzemeltetési naplókra.
  • Adat- és hozzáférés-kezelés: titkosítás nyugalmi és átviteli állapotban, szerepköralapú hozzáférés, anonimizálás és törlési folyamat.
  • Magyarázhatóság: kérdezze meg, milyen indoklást kap a felhasználó egy-egy kimenethez, és ezt a pilot során próbálja ki mintákon, ne a bemutató demón.
  • Integráció: nyitott API-k, dokumentált adatcsatornák, kompatibilitás a meglévő ERP-vel, szerződéskezelővel és azonosításkezelő rendszerrel.

A gyakorlati MLOps-lépésekhez hasznos kiegészítés ez a platformfüggetlen MLOps-útmutató, amely angol nyelvű, de jól használható ellenőrző listaként. Az üzemzavarok kezeléséhez nézze meg az AI-rendszerek incidenskezeléséről szóló írásunkat is.

Profi tipp: Kérjen a beszállítótól egy leírást arról, mi történik, ha a modell teljesítménye romlik: ki értesül, mennyi időn belül, és vissza lehet-e lépni az előző verzióra.

Hogyan épül fel egy AI-beszerzés az RFP-től a döntésig?

A folyamat előkészítésre, ajánlatkérésre, pilotra és döntésre osztható. A legtöbb hiba az előkészítésben történik, mert az ajánlatkérés még azelőtt kimegy, hogy a cél és a mérési mód rögzítve lenne.

Előkészítés. Fogalmazza meg az üzleti célt, a hozzá tartozó KPI-ket és a kockázati profilt: milyen adatot kezel a rendszer, kire hat a kimenete, és milyen döntésnél van szükség emberi jóváhagyásra. Ez adja az értékelési mátrix súlyait is. A kockázati profilhoz segítséget ad az AI kockázatértékelési útmutatónk.

Ajánlatkérés (RFP). A sablonban kötelező kérdések legyenek az Article 25 szerinti szerepek, az MLOps-érettség, a naplózás, az adatkezelés és a magyarázhatóság. Kérjen konkrét válaszokat és dokumentumokat, ne általános nyilatkozatokat. A beszállító az ajánlatában nevezze meg a pilot feltételeit és az elszámolás módját is.

A pilot paraméterei: világosan körülhatárolt scope, előre rögzített elfogadási kritériumok és egy kijelölt belső tulajdonos. A pilot ne éles, kritikus folyamaton fusson, de valós adatokon, különben a mérés nem lesz meggyőző. A pilot felépítéséhez lépésről lépésre segít az AI pilot projektről szóló útmutatónk.

Döntési folyamat. A pilot végén a döntés pontszám és küszöb alapján születik, nem benyomás alapján. A szerződés tartalmazzon átmenetet a skálázáshoz: mit vállal a beszállító nagyobb terheléskor, hogyan változik az ár, és mi történik kilépésnél.

A folyamat lépései röviden:

  1. Rögzítse az üzleti célt, a KPI-ket és a kockázati profilt.
  2. Határozza meg a szerepeket (provider vagy deployer) és a szerződéses minimumot.
  3. Küldje ki az RFP-t a kötelező kérdésekkel, és szűrjön a mátrix alapján.
  4. Válassza ki a két-három legjobb ajánlattevőt, és kérjen tőlük pilotjavaslatot.
  5. Futtassa a pilotot azonos feltételekkel, azonos adatokon.
  6. Értékelje az eredményeket a küszöbök szerint, és hozzon dokumentált döntést.
  7. Kösse a skálázást és a szerződés végleges formáját az elfogadási küszöbök teljesüléséhez.

Ha a beszállítók azonos feltételekkel versenyeznek, a pilot egyben jó tárgyalási alap is: a mért adat erősebb érv, mint bármely ajánlati prezentáció.

Mit mérjen a pilot során, és mikor skálázzon?

A pilot végén azért tud objektíven dönteni, mert a mérőszámokat a pilot indulása előtt rögzítette. Két csoportot érdemes párhuzamosan követni: az üzleti és a technikai mutatókat.

  • Üzleti KPI-k: költségmegtakarítás, a feladatra fordított idő csökkenése, a hibák és az újrafeldolgozás mérséklődése. Minden mutatóhoz legyen kiindulási érték, amelyhez a pilot eredményét hasonlítja.
  • Technikai KPI-k: pontosság egy kézzel ellenőrzött mintán, válaszidő terhelés alatt, valamint az adateltolódás jelzése.
  • Validációs módszerek: tartott vissza (holdout) mintán végzett próba, A/B összehasonlítás a régi folyamattal, és mérés valós működési környezetben.
  • Üzemeltetési készenlét: szolgáltatási szint (SLA), támogatási modell és incidenskezelési eljárás, amelyet legalább egyszer le is próbál.

A skálázási döntés akkor megalapozott, ha az üzleti küszöbök teljesültek, a technikai mutatók stabilak maradtak a pilot teljes ideje alatt, és a beszállító vállalta az üzemeltetési feltételeket. Ha csak az egyik oldal teljesít, hosszabbítson vagy szűkítse a scope-ot, ne skálázzon.

Profi tipp: Határozza meg előre a „megállítási feltételt” is: milyen eredménynél állítja le a pilotot, és nem hosszabbítja meg. Ez megóvja a döntést a reményektől.

Szempont az AI-beszállító kiválasztásához: hogyan látjuk mi

Mi nem a technológiával kezdjük, hanem azzal, hogy a vállalat melyik üzleti problémáján javítana az AI. Vendor-függetlenül dolgozunk, így nincs érdekünk egyetlen terméket előtérbe tolni: a beszállítókat ugyanazzal a mátrixszal és ugyanazon a pilotfeltételeken mérjük. A governance, a biztonság és az auditálhatóság nálunk nem utólagos kiegészítés, hanem a pilot belépési feltétele. Tapasztalatunk szerint az a döntés tartós, amelyet mért adat támaszt alá.

— Zsolt

Hogyan segítünk az AI-beszállító kiválasztásában?

Stratify

Ha a fenti folyamatot nem egyedül szeretné végigvinni, a lépéseket támogatjuk. Az AI Discovery Workshopot 390 000 HUF egyszeri díjért kínáljuk: itt feltárjuk és priorizáljuk a lehetőségeket, és megfogalmazzuk a KPI-ket. Az AI tanácsadás és stratégia során üzleti célokból építünk ütemtervet, a kontrollált AI-bevezetés pedig a lehetőségfelmérést és a pilotot fogja össze, governance-beállítással. Az aktuális árakról a weboldalunkon talál információt. Kérjen workshopot vagy ajánlatot, és a következő beszerzését már mért pilottal indíthatja.

Gyakran ismételt kérdések

Hogyan válasszak AI-beszállítót a beszerzési folyamatban?

Kezdje az üzleti célokkal és a mérhető KPI-kkel, ne a technológiával. Ezután tisztázza a jogi szerepét, és pilotban hasonlítsa össze a beszállítókat azonos feltételekkel.

Mikor válhatok provider-ré, ha AI-rendszert vásárolok?

Ha saját neve alatt hozza forgalomba a rendszert, lényegesen módosítja, vagy megváltoztatja a rendeltetését, az Article 25 szerint provider-ré válhat. Ilyenkor a provider kötelezettségei is Önre vonatkoznak.

Mennyi ideig tartson egy AI-pilot?

Egy jól körülhatárolt felhasználási eset méréséhez általában változó idő szükséges. Fontosabb az előre rögzített KPI és elfogadási küszöb, mint a pontos hossz.

Mit kérjek a szerződésbe az AI-beszállítótól?

Kérjen hozzáférést a műszaki dokumentációhoz, az ismert korlátok és hibamódok átadását, a naplók exportálhatóságát és világos felelősségi, szellemi tulajdoni szabályokat. Rögzítse a módosítások egyeztetési rendjét is.

Források

Ajánlott

Tags: