A pilot után akkor érdemes skálázni, ha a kísérlet mérhető üzleti eredményt hozott valós adatokon, és van gazdája, költségkerete, integrációs terve és felügyeleti rendje az éles működésnek. Ha ezek közül bármelyik hiányzik, a skálázás nem a következő lépés, hanem a következő kockázat. Ebben a cikkben végigmegyünk a döntés szempontjain, az átállás lépésein és azon, amit a pilot sosem mutat meg: hogyan viselkedik egy AI-megoldás hónapokig, valódi felhasználókkal, változó adatokon. A cikk hazai kkv-k és középvállalatok vezetőinek, IT-vezetőinek és projektgazdáinak szól, akik már túl vannak egy sikeresnek látszó kísérleten, és most azt kell eldönteniük, mennyit és mire költsenek.

Stratify
stratify.hu
Skálázza az AI-t megalapozottan
A Stratify üzleti célokra épülő AI-tanácsadással segít kiválasztani és megvalósítani a mérhető értéket teremtő megoldásokat.

Ismerje meg a Stratifyt

Röviden

  • A sikeres pilot még nem bizonyítja, hogy a megoldás élesben is működik. A kontrollált környezetben végzett tesztelés nem helyettesíti az élesítés utáni felügyeletet.
  • Skálázás előtt öt kérdésre kell igennel válaszolni: mérhető eredmény, gazda, adat, integráció, governance.
  • Fokozatosan élesítsen: árnyék üzemmód, szűk felhasználói kör, majd teljes bevezetés, mindegyik lépés előtt előre rögzített küszöbértékekkel.
  • Az EU AI Act szabályainak többsége 2026. augusztus 2. óta alkalmazandó, ezért a skálázott AI-rendszerhez dokumentált felügyelet és felelősségi rend kell.
  • A skálázás nagyobb része szervezeti munka: folyamatok átírása, képzés, felelősök kijelölése.

Tartalomjegyzék

Miért akad el a legtöbb pilot

Magyarországon ma nem az a gond, hogy a cégek nem próbálják ki a mesterséges intelligenciát. Az AmCham Hungary 2025-ös AI-felkészültségi felmérése szerint a cégek nagyjából 85%-a kísérletezik AI-eszközökkel, miközben 59%-uknak nincs dedikált belső IT-erőforrása. A felmérés azt is mutatja, hogy csak kevés vállalat jutott túl a korai pilotokon, és sokan ma sem tudják megbízhatóan mérni a megtérülést. Az NMHH kkv-felméréséről szóló HWSW-cikk szerint a megkérdezett cégek csaknem 80%-a rendszeresen használta a ChatGPT-t az előző évben.

A kettő együtt sokat elmond. A kísérletezés olcsó és gyors lett, a beépítés a napi működésbe viszont nem. A pilotok jellemzően azért akadnak el, mert:

  • nincs előre rögzített sikerkritérium, így a pilot végén senki sem tudja megmondani, hogy jó lett-e;
  • a pilot kézzel válogatott, tiszta adaton fut, az éles rendszerekben viszont hiányos, ellentmondásos, több helyen tárolt adatok vannak;
  • a lelkes kezdeményező a gazda, nem az a vezető, akinek a területén a megoldás élni fog;
  • az integráció kimarad a tervből, mert a pilotban elég volt egy külön felület vagy egy exportált táblázat;
  • senki nem számolt az üzemeltetéssel: ki figyeli a minőséget, ki dönt, ha a modell hibázik, mennyibe kerül havonta.

Ha a pilotot még most tervezi, érdemes az elejétől skálázásra gondolva felépíteni. Ebben segít a középvállalati AI-pilot lépésről lépésre útmutatónk.

Mikor kész egy pilot a skálázásra

A skálázási döntés nem hangulat kérdése. Az alábbi szempontokat a pilot zárásakor érdemes egyenként végigvenni a projektgazdával, az érintett szakterület vezetőjével és az IT-vel közösen.

Szempont Mikor zöld? Figyelmeztető jel
Üzleti eredmény A pilot a kezdéskor rögzített mutatón mérhető javulást hozott (átfutási idő, hibaarány, feldolgozott tétel per fő) Az eredményt csak elégedettségi visszajelzések támasztják alá
Adat A megoldás az éles adatforrásokon is működik, és ismert, ki fér hozzá az adatokhoz A pilot exportált, kézzel tisztított mintán futott
Gazda Van üzleti gazda, akinek a célkitűzései között szerepel a megoldás A gazda az IT vagy egy külső szállító
Integráció Ismert, mely rendszerekhez (ERP, CRM, dokumentumtár) kell kapcsolódni, és mennyi munka ez A felhasználók másolgatják az adatot két felület között
Költség Van becslés az éles üzem havi költségére, volumen szerint Csak a pilot költsége ismert
Governance Kijelölt felelős, naplózás, emberi jóváhagyási pontok, AI Act-besorolás Senki sem tudja, ki felel egy hibás kimenetért

Ha a hat sorból legalább egy piros, az nem feltétlenül jelenti a projekt végét. Jelentheti azt, hogy a pilotot egy második, rövidebb körben kell folytatni, éles adaton vagy szélesebb felhasználói körrel, mielőtt a komoly beruházásról döntenek. Ritkábban azt is, hogy a megoldást le kell állítani, mert az üzleti haszon nem fedezi az éles üzem költségét. Ez is jó eredmény: a pilot pontosan erre való.

A skálázás lépései pilot után

Az alábbi sorrend a legtöbb hazai középvállalatnál beválik, legyen szó dokumentumfeldolgozásról, belső tudásbázisra épülő asszisztensről vagy ajánlatkészítést támogató megoldásról.

  1. Zárja le a pilotot írásban. Egy-két oldalas összefoglaló: mit mértek, milyen eredménnyel, milyen hibákat láttak, mi maradt nyitva. Ez lesz a skálázási döntés alapja, és később az AI Act szerinti dokumentáció első eleme is.
  2. Számolja újra az üzleti esetet éles volumennel. A pilotban száz dokumentum feldolgozása olcsó. Éles üzemben havi tízezer is lehet, a modellhasználat, a tárhely és a felülvizsgálati munkaidő költsége pedig együtt nő. Készítsen három forgatókönyvet (óvatos, várható, optimista), és nézze meg, melyikben térül meg a befektetés.
  3. Rendezze az adatokat és a jogosultságokat. Döntse el, mely adatforrásokból dolgozhat a rendszer, ki láthatja a kimeneteket, és mi nem kerülhet külső szolgáltatóhoz. A személyes adatokat és az üzleti titkokat itt kell szétválogatni, nem az első incidens után.
  4. Tervezze meg az integrációt. Az AI-megoldás akkor hoz valódi megtakarítást, ha ott jelenik meg, ahol a munka zajlik: az ERP-ben, a CRM-ben, a levelezésben vagy a dokumentumtárban. A vállalati webes automatizáció 2026-os trendjei jól mutatják, hogy az automatizáció értéke egyre inkább a rendszerek közötti összekötésben rejlik, nem az önálló eszközökben.
  5. Élesítsen fokozatosan. Az MLOps-alapú visszacsatolási architektúrákról szóló tanulmány a fokozatos élesítési módszereket (árnyék, canary és blue/green bevezetés) ajánlja a kockázat csökkentésére. A gyakorlatban ez így néz ki: először árnyék üzemmód, amikor a rendszer dolgozik, de a kimenetét csak összevetik az emberi munkával; utána egy csapat vagy egy telephely használja élesben; csak ezután jön a teljes bevezetés.
  6. Rögzítse a továbblépési küszöböket. Minden szakasz előtt döntse el, milyen pontosság, hibaarány vagy feldolgozási idő mellett lép tovább, és mi esetén lép vissza. Ha ezt előre leírják, a döntés nem a legmeggyőzőbb érvelőn múlik.
  7. Építse be az emberi kontrollt. Határozza meg, mely kimeneteket hagy jóvá ember, milyen összeghatár vagy kockázati szint felett kötelező a felülvizsgálat, és hogyan jelzik a felhasználók a hibát.
  8. Képezze a felhasználókat és írja át a folyamatot. Ha a régi munkafolyamat változatlan marad, és az AI csak egy plusz lépés benne, a megtakarítás elmarad. A folyamatleírást, a felelősségi mátrixot és a teljesítménymutatókat is frissíteni kell.
  9. Állítsa be a folyamatos felügyeletet. Erről szól a következő fejezet, mert ez az a rész, amelyet a legtöbb pilot kihagy.

A lépések nem feltétlenül egymás után következnek: az adatrendezés és az integrációs tervezés párhuzamosan is futhat, a képzés pedig már az árnyék üzemmód alatt elkezdődhet. A sorrend inkább azt jelzi, hogy melyik lépés nélkül nem érdemes a következőbe kezdeni. Konkrét példát a nagykereskedelmi AI pilottól skálázásig bemutató cikkünk ad.

Amit a pilot nem mutat meg: felügyelet élesítés után

A NIST amerikai szabványügyi intézet telepített AI-rendszerek felügyeletéről szóló jelentése szerint az élesítés előtti, kontrollált tesztelés önmagában nem elég. Az élesítés utáni monitorozás kell ahhoz, hogy kiderüljön, megbízható-e a rendszer a valós használatban, romlik-e a teljesítménye az idő múlásával, és ad-e váratlan kimeneteket. A nyelvi modellek nem determinisztikusak: ugyanarra a kérdésre ma kicsit mást válaszolhatnak, mint tegnap, és ez a pilotban ritkán derül ki.

Mit érdemes felügyelni egy skálázott AI-megoldásnál?

  • Minőség: mintavételes emberi ellenőrzés, a felhasználói javítások aránya, a visszautasított vagy kézzel átírt kimenetek száma.
  • Adatváltozás: új terméktörzs, új dokumentumsablon, megváltozott ügyfélkör. Ilyenkor a pilotban mért pontosság már nem érvényes.
  • Költség és sebesség: havi modellhasználati költség, válaszidő, hibás futások.
  • Biztonság: ki mit kérdezett, milyen adatokhoz fért hozzá a rendszer, történt-e szokatlan használat.

A felügyelet logikája nem új. A távfelügyelt felvonók folyamatos monitorozása ugyanezt az elvet követi: a telepítés után is folyamatosan jöjjön jel a működésről, és a hiba még a felhasználó előtt derüljön ki. Az AI-nál ugyanez a cél, csak a „hiba” gyakran nem leállás, hanem egy magabiztosan megfogalmazott téves válasz.

Ahogy nő a megoldások száma, a kézi felügyelet egyre kevésbé tartható. Az AI Sweden modellek nagy számú éles üzemeltetéséről szóló tanulmánya szerint automatizálás nélkül minden új modell további költséget, koordinációs terhet és megfelelési kockázatot hoz, ezért a felügyeletnek idővel maga is kell tudnia beavatkozást indítani, például újratanítást, ha romlik a teljesítmény. Egy középvállalatnál ez ritkán jelent ezer modellt, de már három-négy AI-megoldásnál is megéri közös felügyeleti keretet építeni ahelyett, hogy mindegyiket külön figyelnék.

A mérés egyben a vezetői kommunikáció alapja. Ha a felügyeleti adatok egy irányítópulton futnak össze, az üzleti hatás is látható: hasonló elven működnek a könyvelési adatokra épülő Power BI riportok, amelyek a pénzügyi mutatókat frissítik automatikusan. Az AI-megoldásnál a megtakarított munkaórák, a feldolgozási idő és a hibaarány kerülhet ugyanígy havi riportba.

AI Act: mit jelent a skálázásra 2026 őszén

Az Európai Bizottság AI Act szolgálati oldalának ütemterve szerint a rendelet szabályainak többsége 2026. augusztus 2. óta alkalmazandó. A magas kockázatú rendszerekre vonatkozó határidők későbbiek: az önálló magas kockázatú rendszereknél 2027. december 2., a szabályozott termékekbe épített rendszereknél 2028. augusztus 2. Ezek az időpontok a rendelet egyszerűsítése után alakultak így: az Európai Tanács ütemterve szerint a Tanács 2026. június 29-én adta meg a végső jóváhagyást.

A skálázás szempontjából ez három gyakorlati teendőt jelent:

  • Besorolás: a pilot zárásakor dokumentálja, milyen célra használják a rendszert, és ez melyik kockázati kategóriába eshet. HR-kiválasztást, hitelbírálatot vagy ügyfelek értékelését érintő felhasználásnál ezt jogi szakértővel érdemes átnézetni.
  • Átláthatóság: ha ügyfelek vagy munkatársak AI-val beszélgetnek, vagy AI által generált tartalmat kapnak, tudniuk kell róla.
  • Felelősségi rend: ki engedélyezi a változtatásokat, ki nézi a naplókat, ki dönt a leállításról.

A témát részletesebben az AI Act hatása a magyar cégekre című cikkünk tárgyalja, a szabályzatok és a kockázatkezelés gyakorlati oldalát pedig az AI compliance szolgáltatásunk oldala.

Gyakori hibák a skálázás során

Mindent egyszerre. A sikeres pilot után nagy a kísértés, hogy a megoldás egy lépésben az egész cégnél élesedjen. Ha valami hibázik, nem lehet tudni, hol és miért, és a bizalom gyorsabban fogy, mint ahogy épült.

Másik eszköz, mint a pilotban. Gyakori, hogy a skálázáskor „komolyabb” platformra váltanak. Ez indokolt lehet, de akkor a pilot eredményei nem vihetők át automatikusan, és az új környezetben újra kell mérni.

A szállító diktál. Ha a pilotot egy eszköz forgalmazója vitte, a skálázási javaslat is jellemzően az ő termékéről szól. Érdemes független szemmel is megnézni, hogy az adott üzleti problémára ez-e a legjobb és legolcsóbb megoldás.

Nincs kivezetési terv. Mi történik, ha a szolgáltató árat emel, a modell megszűnik, vagy a megoldás nem hozza a vártat? A visszalépés lehetőségét a skálázás előtt kell biztosítani, nem utána.

Az emberek kimaradnak. Ha a munkatársak úgy érzik, a rendszer ellenőrzi vagy kiváltja őket, megkerülik. A bevonás, a képzés és a világosan kimondott cél (például: kevesebb adminisztráció, több idő az ügyfelekre) többet ér bármilyen technikai finomhangolásnál.

Az AI skálázás öt gyakori hibája

Hogyan látjuk mi a skálázást

A tapasztalatunk az, hogy a pilot utáni elakadás ritkán technológiai probléma. Sokkal gyakrabban az, hogy a pilot egy eszköz kipróbálásából indult, nem egy üzleti problémából, ezért a végén nincs mihez mérni az eredményt. Mi ezért minden projektet az üzleti célokkal, a megtérülési potenciállal és a szervezet felkészültségével kezdünk, és már a pilot tervezésekor rögzítjük, milyen eredmény esetén lépünk tovább.

A skálázásnál három dolgot nem engedünk el. Az első a fokozatosság: kontrollált lépésekben élesítünk, minden lépés előtt mérhető feltételekkel. A második a governance: az adatbiztonság, az emberi felügyelet, a naplózás és a megfelelés nálunk nem utólagos kiegészítés, hanem a megoldás része az első naptól. A harmadik a vendorfüggetlenség: nem egy adott eszközt akarunk eladni, hanem azt keressük, ami az adott cég adataihoz, rendszereihez és költségkeretéhez illik.

Azt is gyakran látjuk, hogy a cégek túl sokat akarnak egyszerre. Egy jól skálázott megoldás, amely havonta mérhető munkaórát takarít meg, többet ér öt félbehagyott pilotnál. A második és harmadik projekt pedig már sokkal gyorsabban megy, mert az adatkapcsolatok, a felügyelet és a felelősségi rend addigra megvan.

— Zsolt

Ha most dönt a következő lépésről

Ha van egy pilotja, amelyről nem tudja eldönteni, hogy skálázza-e, vagy még csak azt keresi, melyik folyamatban éri meg egyáltalán AI-val kísérletezni, az AI Discovery Workshop jó kiindulópont. A workshop egyszeri díja 390 000 Ft. Ha már a bevezetés a kérdés, a kontrollált AI-bevezetés keretében a lehetőségfelméréstől a pilotig és az éles működésig kísérjük végig a folyamatot, az üzemeltetést és a folyamatos optimalizálást pedig AI-alkalmazás szolgáltatásaink fedik le.

Gyakori kérdések

Mennyi ideig tartson egy pilot, mielőtt skálázunk?

Addig, amíg a kezdéskor rögzített mutatókról megbízható adat gyűlik össze, valós adatokon és valós felhasználókkal. Ez folyamattól függ: egy havi ciklusú folyamatnál (például számlafeldolgozás) legalább egy-két teljes ciklus kell. A túl hosszú pilot is hiba, mert a csapat lendülete elfogy.

Mi a különbség a POC és a pilot között?

A POC (proof of concept) azt bizonyítja, hogy a megoldás technikailag működik, jellemzően mintaadaton. A pilot azt vizsgálja, hogy a megoldás valós üzleti környezetben, valódi felhasználókkal is hozza-e az eredményt. Skálázási döntést a pilot eredményére érdemes építeni, nem a POC-ra.

Kell-e belső AI-csapat a skálázáshoz?

Nem feltétlenül, de kell belső gazda és legalább egy ember, aki érti a megoldás működését és a felügyeleti adatokat. Sok hazai középvállalatnál nincs dedikált IT-erőforrás, ezért a fejlesztés és az üzemeltetés egy része külső partnerre kerülhet. Az üzleti döntés és a felelősség viszont maradjon a cégen belül.

Mikor érdemes leállítani egy pilotot?

Ha éles volumennel számolva a működtetés költsége meghaladja a mérhető hasznot, vagy ha az adatok minősége nem javítható ésszerű ráfordítással. Akkor is, ha a megoldás olyan kockázatot hordoz, amelyet a cég nem tud kezelni. Egy dokumentált leállítás értékes tanulság a következő projekthez.

Források

Ajánlott

Tags: