PoC-tól az éles rendszerig: így validáld az AI-ötleted 2-4 hét alatt

Egyre több magyar cég vág bele az AI-ba: az Eurostat szerint a 10 fő feletti hazai vállalkozások 10,37%-a használt AI-t 2025-ben, egy évvel korábban még csak 7,41% (Eurostat, 2025). A lelkesedés azonban kevés: a legtöbb AI-projekt nem a technológián bukik el, hanem azon, hogy senki nem validálta az ötletet, mielőtt pénzt öltek bele. Ebben a cikkben megmutatjuk, hogyan csináld ezt 2–4 hét alatt, hétről hétre. A cikk az AI bevezetése a vállalkozásban útmutatónk validálásra fókuszáló része.

Mi az a PoC, és miért ezzel kezdd az AI-projektet?

A PoC (proof of concept, azaz működőképesség-igazolás) egy szűk hatókörű, 2–4 hetes kísérleti projekt. Célja, hogy a saját adataidon, előre rögzített mérőszámokkal igazolja: az ötleted működik. Nem véletlen az óvatosság: egyes becslések szerint az AI-projektek több mint 80%-a megbukik (RAND, 2024).

Ez kétszerese a hagyományos IT-projektek bukási arányának. A RAND kutatói 65 senior adattudóssal készített interjú alapján jutottak erre. A leggyakoribb okok között nem a technológia szerepel, hanem a félreértett üzleti probléma és a hiányzó adat.

A Gartner 2024-es előrejelzése ugyanezt erősíti: eszerint a generatív AI-projektek legalább 30%-át elhagyták a PoC-fázis után 2025 végéig (Gartner, 2024). Az okok: rossz adatminőség, hiányzó kockázatkontroll, növekvő költségek és tisztázatlan üzleti érték.

Elsőre ijesztő számok, pedig épp a PoC mellett szólnak. Mindegyik bukási ok olyasmi, amit egy jól felépített PoC néhány hét alatt, a teljes fejlesztés töredékéért kiderít. A PoC tehát nem plusz költség, hanem kockázatcsökkentő eszköz: a nagy döntés előtt kicsiben megveszed a tanulságot. Arról, hogy ez a teljes költségképben hol helyezkedik el, az AI bevezetés költségeiről szóló cikkünkben írtunk részletesen.

Mit tartalmaz egy jó PoC?

Egy jó PoC három pilléren áll: szűk scope (egyetlen folyamat), valós adat (a tiéd, nem demó-adathalmaz) és mérhető cél-KPI (előre rögzített sikerküszöb). Ha ez a három megvan, az eredmény döntésre alkalmas. Nálunk a Composite-nál egy PoC átfutása 2–4 hét (Composite, PoC-fejlesztés, 2026).

Szűk scope: egy folyamat, egy kérdés

A PoC egyetlen kérdésre válaszol, például: „Tudja-e az AI a bejövő e-mailjeink 70%-át helyesen kategorizálni?" Nem cél a szép felület, a teljes integráció vagy a több felhasználási eset. Minden, ami nem a fő kérdést válaszolja meg, kifelé mutat a scope-ból. Tapasztalatunk szerint a legtöbb elcsúszott PoC a szétfolyó hatókörön bukik el, nem a modellen.

Valós adat: a te adataid, nem demó

A demó-adaton működő AI semmit nem bizonyít. A PoC-nak a te dokumentumaidon, e-mailjeiden, ticketjeiden kell futnia, az összes elgépeléssel és hiányossággal együtt. Ez egyben adat-egészségügyi szűrés is: már az első héten kiderül, mennyire használható, amid van. Ha bizonytalan vagy, előtte érdemes végigmenni az AI-készültségi ellenőrzőlistánkon.

Mérhető cél-KPI: előre rögzített küszöb

A sikerküszöböt a projekt elején, írásban rögzítsd: például 70% feletti kategorizálási pontosság vagy ügyenként 5 perc megtakarítás. Ha utólag határozod meg, mindig találsz olyan mérőszámot, amire a projekt „sikeres". Az előre rögzített KPI véd a legdrágább hibától: a félig működő rendszer továbbépítésétől.

Hogyan néz ki a 2-4 hetes menetrend hétről hétre?

A menetrend négy szakaszra bomlik: az első hét a scope és az adat, a második a prototípus, a harmadik a valós adatos tesztelés, a negyedik a mérés és a döntés. Kisebb feladatnál a szakaszok összecsúszhatnak, ezért 2–4 hét a reális sáv (Composite, PoC-fejlesztés, 2026).

Nézzük, mi történik az egyes hetekben:

1. 1. hét: scope és adat. Közösen rögzítjük a fő kérdést, a cél-KPI-t és a go/no-go küszöböt. Összegyűjtjük és előkészítjük a valós adatmintát. Itt dől el a projekt fele.
2. 2. hét: prototípus. Elkészül a működő váz: modell, prompt-logika, szükség esetén RAG (a modell a saját dokumentumaidból dolgozik). Csúnya, de működik, és ez most pont elég.
3. 3. hét: tesztelés valós adaton. A prototípus a teljes adatmintán fut. Mérjük a pontosságot, gyűjtjük a hibatípusokat, és a folyamatgazda kollégáid is kipróbálják.
4. 4. hét: mérés és döntés. Összevetjük az eredményt a rögzített KPI-val. Döntési riportot kapsz: mit mértünk, mennyibe kerülne az éles rendszer, megéri-e folytatni.

Egy fontos szabály a saját gyakorlatunkból: a menetrendet nem toldjuk meg „még egy hét finomhangolással". Ha a küszöb nincs meg négy hét alatt, az önmagában is értékes adat a döntéshez.

Hogyan értékeld az eredményt? A go/no-go döntés

A PoC kimenete nem egy demó, hanem egy döntés. Négy kritériumot nézz: elérte-e a prototípus a rögzített KPI-küszöböt, kijön-e a megtérülési számítás, van-e technikai út az éles rendszerig, és elég jó-e az adatod. Ha mind a négyre igen a válasz, mehet a folytatás.

A négy kritérium a gyakorlatban:

• KPI-küszöb: a mért érték eléri vagy meghaladja az első héten rögzített célt. Nem „majdnem", nem „ígéretes": eléri vagy nem.
• Üzleti eset: a kiváltott munkaóra és a megmentett bevétel fedezi az éles rendszer becsült költségét belátható időn belül.
• Technikai út: a prototípus architektúrája skálázható, a szükséges integrációk (CRM, ERP, belső rendszerek) megvalósíthatók.
• Adatminőség: a tesztelés során talált adatproblémák javíthatók észszerű ráfordítással.

Három kimenet lehetséges. Go: minden kritérium teljesül, indul az éles fejlesztés számokkal alátámasztott üzleti esettel. Pivot: az ötlet magja működik, de más scope-pal vagy más folyamaton érdemes újrafuttatni. No-go: a számok nem jönnek ki, a projekt itt megáll.

És itt a lényeg: a no-go nem kudarc, hanem a PoC egyik legértékesebb kimenete. A Gartner által jelzett, PoC után elhagyott projektek (Gartner, 2024) ott fájnak igazán, ahol az elhagyás előtt már elköltötték az éles fejlesztés büdzséjét. Te a töredékéért tudtad meg ugyanezt.

Mi változik a PoC és az éles rendszer között?

A PoC működőképességet bizonyít, az éles rendszer üzemet visz: ez két különböző műfaj. A go-döntés után három terület nő meg jelentősen: az integrációk, a biztonság és megfelelés, valamint az üzemeltetés. Erre a szakaszra tervezz külön büdzsét és időt, mert jellemzően több munka, mint maga a PoC volt.

Integrációk és jogosultságok

A PoC-ban az adat jellemzően exportált minta. Élesben a rendszer a CRM-edből, ERP-edből vagy webshopodból dolgozik, valós időben. Ehhez API-kapcsolatok, jogosultságkezelés, hibakezelés és visszamérés kell. A tipikus buktatókról az AI-bevezetés kihívásairól szóló cikkünkben írtunk.

Biztonság és megfelelés

Élesben a rendszer valódi ügyfél- és céges adatokat kezel, ezért a GDPR- és adatbiztonsági követelmények teljes súlyukkal érvényesek. Az EU AI Act 2026. augusztus 2-től teljeskörűen alkalmazandó (Európai Bizottság, 2026), és például a chatbotoknál átláthatósági kötelezettséget is előír. A PoC-fázisban ez még kezelhető minimummal, élesben tervezett munka.

Üzemeltetés és minőségkontroll

Az éles rendszer folyamatos figyelmet kér: API-költségek követése, válaszminőség rendszeres ellenőrzése, a modell- és folyamatváltozások lekövetése. Ha nincs belső kapacitásod erre, a havidíjas AI Partnership konstrukció a fejlesztést és az üzemeltetést egyben kezeli.

Mikor ne csinálj PoC-t?

Őszinte válasz: ha a feladatodra létezik kész, bevált eszköz, ne fizess validálásért. A PoC egyedi, bizonytalan kimenetelű ötletek kockázatcsökkentésére való, nem sablonfeladatokra. Egy egyszerű, integráció nélküli GYIK-chatbotot például platform-előfizetéssel is kipróbálhatsz, saját fejlesztés nélkül, havidíjas konstrukcióban.

Négy helyzet, amikor a PoC felesleges kör:

• Kész eszköz megoldja. Sablonos, integráció nélküli feladatnál a platform-előfizetés maga a validálás: kipróbálod, és látod az eredményt.
• Nincs valós adatod. Adat nélkül a PoC csak demó lenne. Előbb gyűjts, rendszerezz, aztán validálj.
• A folyamat épp átalakul. Mozgó célpontra nem érdemes mérni; előbb stabilizáld a folyamatot.
• Túl kicsi a volumen. Havi néhány tucat esetnél a legjobb eredmény sem térül meg, a PoC csak elodázná ezt a felismerést.

Ez egyben fejlesztőválasztási teszt is: a korrekt partner megmondja, ha a feladatodhoz nem kell egyedi fejlesztés. Aki minden problémára PoC-t vagy projektet ajánl, az eszközt ad el, nem megoldást. A 7 kérdés AI-fejlesztő választásához cikkünkben ezt a szűrőt is megtalálod.

Gyakran ismételt kérdések

Mennyi ideig tart egy PoC?

Nálunk a Composite-nál 2–4 hét (Composite, PoC-fejlesztés, 2026). A sáv a feladat méretétől függ: egy folyamat, rendezett adatokkal a rövidebb, több adatforrás vagy összetettebb logika a hosszabb végére esik. Ha egy ajánlat több hónapos „PoC-t" ígér, az valójában már fejlesztési projekt, más kockázattal.

Mi a különbség a PoC, a pilot és az MVP között?

A PoC azt igazolja, hogy az ötlet műszakilag és üzletileg működik: kontrollált körülmények között, szűk scope-on. A pilot már éles környezetben, valós felhasználókkal futó próbaüzem. Az MVP (minimum viable product) pedig a legkisebb piacképes termék. A sorrend jellemzően: PoC, aztán pilot, aztán éles rendszer vagy MVP.

Mi történik, ha a PoC nem hozza a cél-KPI-t?

Akkor a PoC megtette a dolgát: a teljes fejlesztés töredékéért derült ki, hogy ne költs többet erre az irányra. A döntési riportból azt is látod, miért nem jött ki az eredmény: adatminőség, folyamathiba vagy modellkorlát. Ez alapján dönthetsz a pivot mellett, vagy zárhatod le nyugodt szívvel az ötletet.

Használható a PoC kódja az éles rendszerben?

Részben. A PoC-ban a sebesség a cél, nem a hosszú távon karbantartható kód, ezért az éles rendszer jellemzően újraírást és bővítést igényel. Ami biztosan átvihető: a validált megközelítés, a prompt- és RAG-logika, a KPI-mérési módszertan és az adat-előkészítés tanulságai. Ez a tudás a PoC valódi terméke.

Van egy AI-ötleted, de nem tudod, megéri-e ráfordítani? Pontosan erre való a PoC-fejlesztés: 2–4 hét alatt, valós adataidon, mérhető eredménnyel derül ki. Ha előbb beszélnéd át, melyik folyamatod érett rá, foglalj ingyenes AI-konzultációt: 30 perc, kötelezettség nélkül.