21 AI-bevezetési hiba, és hogyan kezeld őket
Az AI-eszközök mára szinte minden szervezetben megjelentek, a kézzelfogható üzleti eredmény viszont sok helyen elmarad. A KPMG 2026 februárjában és márciusában, 20 ország 2110 felsővezetőjének megkérdezésével készült felmérése szerint a szervezetek 95%-a rendelkezik AI-stratégiával, de csak 8%-uk számolt be kimutatható megtérülésről, Európában pedig mindössze 6%-uk. A mintázat itthon is ismerős lehet: sok pilot, kevés éles használat.
Az MIT Project NANDA 2025-ös jelentéséből egy további adat is sokat elárul: a cégeknek csak 40%-a vásárolt hivatalos LLM-előfizetést, miközben a vállalatok több mint 90%-ánál a munkatársak rendszeresen használnak saját AI-eszközt a munkájukhoz. Ez az úgynevezett shadow-AI használat rengeteg kockázatot hordoz magában.
Ebben a cikkben a tanácsadói és képzési munkáink során leggyakrabban látott bevezetési hibákat és azok lehetséges megoldásait gyűjtöttük össze kategóriákba sorolva.
Tartalom
1. Stratégiai és vezetői hibák
Ez a kategória nem véletlenül került a sor elejére, ezek a hibák okozzák a legtöbb problémát a bevezetést követően. Közös jellemzőik, hogy többségében ezek vezetői szerepekhez kötődnek.
1.1. Nincs gazdája a bevezetésnek
Mint oly sok transzformáció és komplex változás esetén, az AI kapcsán is kiemelten fontos, hogy a bevezetést vezetői szinten is képviseljék. Ennek hiányában a kezdeményezés lassan elhalhat, vagy szigetszerű próbálkozásokra eshet szét. Gazda nélkül a csapatok közötti határokon, például az átadás-átvételi pontokon, senki nem gondolja végig a use case-t minden érintett szemszögéből, ezért a részmegoldások nem érnek össze.
Tünet: az IT megveszi a licenceket, a HR szervez egy képzést, de senki nem felel azért, hogy az AI-ból üzleti eredmény legyen.
Megoldás: jelölj ki egy üzleti oldali felelőst, akinek van döntési jogköre és ideje is a feladatra. Az is fontos, hogy az illető higgyen az eredmények elérhetőségében, legyen egy víziója a bevezetéssel kapcsolatban.
1.2. Nincs célja az AI-bevezetésnek
Az AI-bevezetést nem azért kezdjük el, mert ez most a „hype”, hanem azért, mert üzleti eredményt várunk tőle. Mérhető cél nélkül nincs döntési alap a skálázásra vagy a leállításra, ezért a pilotok vagy a végtelenségig futnak, vagy szubjektív alapon zárulnak le.
Tünet: a cél annyi, hogy „vezessünk be AI-t”. A pilot után senki nem tudja megmondani, hogy megérte-e.
Megoldás: minden use case-hez rögzíts előre egy-két mérőszámot (pl. átfutási idő, ráfordított óra, hibaarány), és mérd meg a kiinduló értéket a bevezetés előtt és után. Kiinduló érték nélkül később csak érzésekről lehet beszélni.
1.3. Rossz célmetrika
Legalább annyira komoly probléma a rossz mérőszám alkalmazása a célok tekintetében az AI-bevezetés során, mint ha nincs céldefiníció. Kritikus, hogy a bevezetéssel szállított érték üzletileg releváns és mérhető legyen.
Tünet: egy olyan cél, mint például a felhasznált tokenek havi átlagos volumene, vagy a használati adatok és aktivitás nem érték önmagában. Ezekkel a mérésekkel még nem lehet megmondani, hogy milyen megtérülést, üzleti előnyöket érünk el az AI-bevezetéssel.
Megoldás: az AI use case-ek esetén gondolkodj szerepkörben is, illetve vonj be üzleti oldali képviselőt, akiknek a csapatai tervezik használni az AI-t. Tegyetek fel olyan kérdéseket, mint: Ha ezt a feladatot AI támogatná, havonta mennyi időd szabadulna fel? Ezzel az AI-alapú megoldással milyen üzleti értéket tudnánk az ügyfeleinknek szállítani?
2. Módszertani hibák
Az AI-bevezetés sikerét alapjaiban határozza meg, hogy átgondolt, tudatos folyamat szerint valósítjuk-e meg. Talán ez a legszubjektívebb kategória, hiszen nincs egyetlen sikeres megközelítés. A felmérés, a kiválasztott feladat elemzése és a kipróbálás ritkán követi egymást szigorú sorrendben: iteratívan haladnak, és egymásra is visszahatnak. Egy PoC eredménye például átírhatja a prioritásokat, az elemzés pedig kimutathatja, hogy egy use case mégsem jó első jelölt. Egyiket sem érdemes kihagyni, mert a kihagyott lépés később drágábban jön vissza. A bevezetés szervezeti hatásaival a 8. fejezetben foglalkozunk.
2.1. Nincs use case felmérés
Az AI-bevezetés tapasztalataink szerint akkor hatékony, ha van egy előzetes képünk arról, hogy a szervezet mely területein milyen feladatokat, milyen mélységben képes az AI támogatni. Ilyen áttekintés nélkül a kiválasztás esetleges: az kerül előre, ami éppen látványos, amit egy demón láttunk, vagy amit valaki hangosan kér. A szervezet így könnyen olyan feladatra költi az első, korlátozott erőforrásait, amelynek kicsi az üzleti haszna, vagy amely technikailag túl nehéz egy első projekthez. Ha az első próbálkozás kudarcot vall, az ráadásul az egész AI-kezdeményezés hitelét rontja, és a jobb use case-ek esélyt sem kapnak.
Tünet: az első ötlet, vagy a leghangosabb kolléga igénye lesz a projekt, vagy a pilot. Később derül ki, hogy kicsi a haszna, vagy épp a legnehezebben megoldható feladatot választottátok.
Megoldás: tarts egy rövid felmérést. Vonj be több érintettet, gyűjtsd össze az igényeket és a lehetséges eseteket, értékeld őket legalább üzleti hatás és megvalósíthatóság, vagy komplexitás szerint.
2.2. Kimarad az előzetes elemzés
Ha a use case-ek kiválasztása megtörtént, a kiválasztott feladatokat egyenként is részletesen meg kell érteni. Az AI-bevezetésre nem mint projektre szoktunk hivatkozni, hiszen ez sokkal inkább hasonlít a digitális és agilis transzformációkra (bár már ezt a kifejezést is kezdik a piacon elkoptatni), mégis az implementáció előtt egy sor tényezőt érdemes tisztán látni. Ezek hiányában vakon repülünk és könnyen elmarad a várt haszon is.
Tünet: a megoldás már készül, de senki nem írta le, pontosan mi a feladat, milyen folyamathoz kapcsolódik, ki a felhasználó, mi a bemenet és mi az elvárt kimenet.
Megoldás: tisztázd a jelenlegi folyamatot, a követelményeket és az elfogadási kritériumokat, ahogy bármely más szervezeti változásnál tennéd. AI-nál ez még fontosabb, mert ha nincs leírva, milyen a jó válasz, tesztelni sem tudod.
2.3. Rögtön agent, PoC nélkül
A közösségi média és gyakran a különböző AI konferenciák is hemzsegnek az agentic működés (egyébként gyakran túlzó) ígéreteitől. Így teljes mértékben érthető, hogy egy terület, vagy szervezet vezetője rögtön magas produktivitást és eredményt ígérő agentek irányába fordulna. Azonban ennek több hátulütője is lehet:
- Ígéretre nem érdemes építeni, amíg nincs bizonyíték (Proof of Concept, PoC) az agent által elvégzett feladat üzleti értékére, addig maximum hipotézisről beszélünk. Viszont egy ilyen agent bevezetése az egyszerűbb, alapfunkciókkal lefedhető megoldásokhoz képest sokkal magasabb ráfordítást igényel, így a kockázat is magasabb.
- Egy kész agent átadása esetén a felhasználók nem feltétlenül értik a mögöttes logikát, nincs saját tapasztalatuk arról, hogy az agent milyen mélységű inputok és kontextus alapján adja az eredményt. Ez főleg az emberi kontrollpontoknál gondot okozhat.
- Az agentek valóban komoly értéket adhatnak, de nem feltétlenül minden feladat esetén. Továbbra is nagyon sok olyan feladat van, aminek esetében egyszerűbb eszközökkel magasabb megtérülést és egyszerűbb testreszabási lehetőségeket érhetünk el.
Tünet: Már az agent fejlesztéséről, integrációjáról és automatizálásáról folyik a beszélgetés, miközben még nem bizonyított, hogy maga a feladat AI-jal értékesen és megbízhatóan elvégezhető.
Megoldás: haladj lépésről lépésre, és mindegyiken igazold, hogy a megoldás működik:
- Kézi promptolás: néhány valós példán kipróbálod, képes-e egyáltalán a modell a feladatra.
- Tartós projekt: állandó háttéranyaggal és utasításokkal ellátott munkaterület (például Claude Project), amit többen használnak. Itt derül ki, stabil-e az eredmény.
- Skill: a bevált lépéseket újrahasználható utasításcsomagba rögzíted, így bárki ugyanazt a minőséget kapja.
- Agent vagy automatizáció: csak akkor, ha az előző lépcsőkön bizonyított, és a kézi futtatás már szűk keresztmetszet.
Sok feladatnál a második vagy harmadik lépcső már elég. Ott érdemes megállni, ahol a megoldás értéket ad, nem szabad az agentek bevezetéséből presztízskérdést csinálni.
3. Folyamathibák
Az elmúlt évekből a rutinosabb szakértők, legyen szó akár IT-rendszer bevezetéséről, vagy valamilyen nagyobb ívű átalakulás levezényléséről, pontosan tudják, hogy a megoldások és kezdeményezések gyakran üzleti folyamatokra épülnek. Az as-is (jelenlegi) és to-be (vágyott) folyamatok ismerete már önmagában az igényt és célokat is segít pontosítani és ami legalább annyira fontos, segít felszínre hozni a problémákat még az implementáció előtt.
3.1. A rossz folyamatok gyorsítása
Nagyon gyakori probléma, hogy a folyamatok az AI-bevezetés előtt nem kerülnek átgondolásra. Adottságnak vesszük azt, ami nem működik jól, ezzel lényegében a rossz eredmények szállítását gyorsítjuk fel, vagy akár még inkább megszilárdítjuk a hibás működést.
Tünet: a meglévő lépéseket egy az egyben AI-val végzik, de a felesleges jóváhagyások, a dupla adatbevitel és a várakozási idők megmaradnak. Az eredmény egy gyorsabb, de ugyanolyan nehézkes folyamat.
Megoldás: előbb nézd át a folyamatot. Mely lépés felesleges, hol vész el a legtöbb idő, mi az, ami csak megszokásból maradt benne? Ezután döntsd el, hova kerüljön AI.
3.2. Nincs kijelölve az ember szerepe
Az LLM modellek működése probabilisztikus, azaz valószínűség alapú. Ez egy óriási különbség a determinisztikus alapon működő folyamatautomatizációkkal szemben. A felhasználók nagy többsége determinisztikus működést keres, ám az AI-eszközök egyszerű konfigurációja és az alacsony belépési költség sok helyen ezt helyezi előtérbe. Az AI-bevezetés során kritikus, hogy a folyamatban a megfelelő helyeken és időben emberi kontrollpontokat helyezzünk. Senki sem szeretne olyan helyzetbe kerülni, hogy egy AI által készített dokumentum, ügyfélajánlat, vagy riport hibásan, nem megfelelő tartalommal jut el a célközönséghez. Az emberi ellenőrzés kötelező!
Tünet: nem tudni, ki ellenőrzi az AI kimenetét, és mikor kell emberi döntés. Ilyenkor vagy mindent kétszer néznek át, és elvész a nyereség, vagy semmit, és becsúszhatnak a hibák.
Megoldás: jelöld ki a kontrollpontokat: mi mehet tovább ellenőrzés nélkül, mit kell átnézni, és ki felel a végeredményért.
4. Adathibák
Megfelelő döntések és eredmények csak megfelelő adatok segítségével jöhetnek létre. Ez az alapvető állítás igaz az AI-bevezetésekre is. A kontextus, az input sok esetben megvan az emberek fejében, de ezt értelemszerűen az AI nem tudja felhasználni. Ezeknek valahol jobb esetben strukturált formában elérhetőnek kell lenniük. Megfelelő adatok nélkül, vagy rossz minőségű adatokkal nem lesz megfelelő az eredmény.
4.1. Gyenge adatminőség
Annak ellenére, hogy az adatminőség javítása az elmúlt évek húzótémája volt, még mindig sok helyen korlátot jelent. Manuális adatrögzítések, nem megfelelő adatvalidációk, ezek mind kockázatot jelentenek. Amennyiben az adatminőség nem megfelelő és nem stabil, az AI-bevezetés eredménye csak még több problémát fog okozni a későbbiekben.
Tünet: elavult, ellentmondó vagy duplikált dokumentumok a tudástárban. Az AI magabiztosan válaszol, csak éppen a tavalyi szabályzatból, vagy hibásan rögzített adatok alapján.
Megoldás: a kiválasztott use case-hez tartozó forrásokat tedd rendbe: egy érvényes verzió, egyértelmű tulajdonos, a régi anyagok archiválása. Nem kell az egész céget azonnal kitakarítani, elég azt a részt, amiből az AI dolgozik. Célszerű rendszeres adatvalidációkat is tartani a stabilitás jegyében.
4.2. Hiányzó adatstruktúra
Az adatok strukturáltsága komoly hatást gyakorol az AI-bevezetés eredményeire. A működési költségek (pl. tokenfelhasználás), a szükséges modellek szintje, illetve az eredmények is függnek attól, hogy az adatok milyen struktúrában érhetők el.
Tünet: a fontos információ e-mailekben, fejekben és szabad szöveges táblázatokban van, a CRM mezőinek egy része üres. Az AI-nak nincs miből dolgoznia, vagy fals eredményeket produkál.
Megoldás: a kritikus adatoknál vezess be minimális struktúrát (kötelező mezők, egységes elnevezések, sablonok), mielőtt AI-alapú megoldást vezetsz be, vagy automatizálsz.
4.3. Kössünk össze mindent AI-jal
Connectort, MCP-szervert vagy integrációt bekötni ma néhány kattintás. Ezért sok szervezet minden elérhető rendszert összeköt az AI-jal: levelezést, dokumentumtárat, CRM-et, pénzügyi rendszert. Az AI így olyan adatokhoz is hozzáfér, amelyekre az adott feladathoz nincs szüksége, és mivel az adatok nincsenek kategorizálva, azt sem tudni, mennyi köztük a bizalmas vagy személyes adat.
Tünet: minden connector be van kapcsolva minden felhasználónál, de senki nem tudja megmondani, melyik use case-hez melyikre van szükség. Egy egyszerű kérdésre adott válaszba bizalmas szerződésből vagy HR-dokumentumból is bekerül részlet, és utólag nehéz kideríteni, milyen adatok jutottak így tovább.
Megoldás: use case-enként döntsd el, mely rendszerekhez, és azokon belül mely adatokhoz kell hozzáférés, és csak azokat kösd be. Ehhez előbb kategorizáld az adatokat (például nyilvános, belső, bizalmas, személyes), és rögzítsd, melyik kategória érhető el AI-on keresztül. A bekötött connectorokat rendszeresen vizsgáld felül, ahogy bármely más hozzáférési jogosultságot. A gyakorlati kihívás az, hogy az AI-nak sokszor kevesebb adatot szeretnénk adni, mint amihez az adott munkatárs hozzáfér, például egy HR-es vagy pénzügyes kolléga esetén. A connectorok jellemzően a felhasználó jogosultságaival dolgoznak, ezért ezt külön kell megoldani, például dedikált mappával, szűkített hozzáféréssel vagy külön technikai fiókkal.
5. Emberek és kompetencia
Sajnos sok AI-bevezetés során hajlamosak a vezetők megfeledkezni a felhasználókról. Egyáltalán nem mindegy, hogy az eszköz használói milyen tapasztalatokkal, előítéletekkel, félelmekkel, képességekkel és persze vágyakkal kezdik el használni a megoldásokat. Amennyiben ezt kihagyjuk a képletből, az egész bevezetés ingataggá válik, hiába figyelünk az adatokra, a módszertanra, és a célokra is.
5.1. Licenc képzés nélkül
Ha csak licencet adunk, a felhasználók nem feltétlenül kezdenek el kísérletezni az eszközzel. Sokan nem tudnak vagy nem akarnak azzal foglalkozni, hogy maguk térképezzék fel a használati lehetőségeket, hiszen a munkaidejük mellett ez nem magától értetődő. Többen elakadnak, és ha nincs azonnali sikerélmény, félreteszik az eszközt.
Tünet: ügyfeleink gyakran ezzel a mondattal keresnek meg minket: „Támogatásra lenne szükségünk, az AI-licenceket kiosztottuk, de valamiért a kollégák nem használják az eszközt.” A tokenhasználat túl alacsony, a munkavégzés módja nem változik, a kérések kimerülnek egy-két nyaralástervezésben vagy e-mail-összefoglalásban.
Megoldás: szerepspecifikus, vagy gyakorlati képzés a résztvevők saját feladatain, utána gyakorlási idő és támogatás biztosítása. Egy üzleti elemzőnek, egy projektmenedzsernek és egy HR-esnek más use case-ek hozzák a hasznot, így a felhasználás módja is eltérő lehet.
5.2. Irreális elvárások
Az AI, bármennyire is annak tűnik kezdetben, nem csodafegyver. Vannak korlátai és ennek megfelelően érdemes az expectations managementet is kezelni. Irreális elvárások esetén a megoldás csalódást okozhat, ami gyengíti a későbbi használati kedvet.
Tünet: a csapat egyik fele azt várja, hogy az AI mindent megold, a másik fele az első hibás válasznál ítéletet mond.
Megoldás: a képzésben a korlátokat is mutasd meg: téves, de magabiztos válaszok, kontextusigény, ellenőrzési felelősség. Aki tudja, hol hibázik az eszköz, az ki is tudja ezt használni.
5.3. Nincs belső bajnok / power user
Minden átalakulás egyik fontos pontja a belső változási ügynökök (change agentek) szerepe. Ezek az ügynökök emberek, akik segítik az átalakulást, változást saját tapasztalatukkal és ismereteikkel. Az AI-bevezetés esetén kulcsfelhasználók, belső bajnokok, power userek (nevezzük bárhogy is őket) nélkül a bevezetés kitettsége magas lesz és a folyamatos fejlődés is sérülhet.
Tünet: a tudás egy-két lelkes kollégánál van. Ha ők leterheltek vagy kilépnek, minden megáll. A munkatársak nem tudják kezelni a folyamat-, vagy igénymódosításokat.
Megoldás: építs kulcsfelhasználói hálózatot, és tegyétek közössé a bevált promptokat, projekteket, skilleket, megoldásokat. Szervezz közösséget, Community of Practice-eket és segítsd az érintetteket, hogy folyamatosan nyomon kövessék a gyors és gyakori technológiai változásokat.
6. Biztonsági és megfelelési hibák
Az AI-bevezetések során az egyik legnagyobb kihívás a biztonságos működés és használat kereteinek megteremtése. Az AI alkalmazás megfelelő adat- és információ- és kiberbiztonsági keretek nélkül kockázatos, és mindezek mellett még a szabályozási réteg (AI Act, GDPR, illetve ahol releváns, az ISO 27001, NIS2) is további feladatokat róhat ránk.
6.1. Shadow AI és tiltások
Különösen nagyobb vállalatoknál fordul elő, hogy a szervezet tiltja az AI-használatot. Ennek tapasztalataink szerint több oka is lehet, leggyakrabban az alábbiakkal találkozunk:
- a szervezetnek még nincs kialakult stratégiája, nem tudja mire és hogyan használhatnák az AI-t, így amíg ez nem tisztázódik, addig inkább tiltják azt
- saját megoldás fejlesztésén dolgoznak és annak élesítéséig nem akarnak beruházni AI-eszközökre
- nem látják benne az üzleti értéket, vagy a felsővezetés elutasító az AI-jal kapcsolatban
Minden munkavállalónak vannak saját eszközei és saját AI-fiókkal kontrollálatlan használat és adatszivárgási veszély alakulhat ki.
Tünet: a munkatársak saját, ingyenes, vagy nem jól konfigurált fiókkal használnak AI-t, és ügyféladatot, szerződésrészletet, kényes információkat másolnak bele. A bevezetőben idézett MIT-adat szerint ez a vizsgált cégek nagy részénél jellemző.
Megoldás: a tiltás önmagában ritkán működik. Adj biztonságos, hivatalos alternatívát, támogasd a biztonságos használatot oktatásokkal és írd le egyértelműen, milyen adat kerülhet AI-eszközbe és milyen nem. A privát AI-fiókok nagy része alapértelmezett beállítás szerint a nagy modelleket is taníthatja, így a céges licencek használata javasolt.
6.2. "Minket nem érint az AI Act"
Az AI Act követelményei sok szervezet számára nehezen értelmezhetők. A mindennapi irodai AI-használat jellemzően nem tartozik a magas kockázatú kategóriába, miközben bizonyos általános kötelezettségek ezekre a felhasználásokra is vonatkoznak. Emiatt nem egyértelmű, hogy a vállalatnak pontosan milyen megfelelési feladatai vannak.
Tünet: a szabályozást a fejlesztők ügyének tekintik, vagy a konkrét előírások hiánya miatt nem foglalkoznak vele. Az AI Act 4. cikke azonban 2025. február 2. óta alkalmazandó, 2026 júliusa óta módosított formában: az AI-rendszereket használó szervezeteknek intézkedéseket kell hozniuk munkatársaik AI-jártasságának fejlesztésére. A jogszabály ugyanakkor nem ír elő konkrét képzési óraszámot, vizsgát vagy tanúsítványt. (forrás).
Megoldás: mérd fel, milyen AI-eszközöket és milyen célokra használtok. Azonosítsd, mely felhasználásokhoz kapcsolódnak tényleges jogszabályi kötelezettségek, és ezekhez igazítsd a szükséges intézkedéseket. Biztosítsd a munkatársak megfelelő AI-ismereteinek fejlesztését, és dokumentáld a megtett lépéseket. A személyes adatok kezelését a GDPR, az információbiztonsági kérdéseket pedig a vonatkozó ISO 27001 vagy NIS2 követelmények alapján vizsgáld.
7. Technológiai hibák
A technológiai döntések hosszú távra szólnak: az eszköz kiválasztása, a ráépülő tudás és az integrációk évekig meghatározzák, mit és milyen költséggel tud a szervezet az AI-jal megoldani. Ezek a hibák ritkán látszanak az elején, mert a kezdeti pilotok szinte bármilyen eszközzel működnek. Akkor derülnek ki, amikor a megoldást skálázni, bővíteni vagy cserélni kellene.
7.1. Kényelmi alapon választott eszköz
Sok szervezet ott keresi az AI-t, ahol már van szerződése, vagy amit a legkönnyebb beszerezni. Ennek jó okai vannak: nem kell új beszállítót átvilágítani, egyszerű a licencelés, és az eszköz eleve illeszkedik a meglévő rendszerekhez. A gond akkor kezdődik, ha a döntés kizárólag ezeken a szempontokon múlik, és senki nem nézi meg, mennyire alkalmas az eszköz a kiválasztott use case-ekre, és milyen költséggel. Ugyanaz a feladat eszközönként eltérő minőségben és eltérő áron oldható meg, a rosszul illeszkedő eszköz pedig a felhasználók csalódásán keresztül az egész bevezetés megítélését rontja.
Tünet: az AI-eszközről beszerzési vagy IT-döntés született, use case-teszt nélkül. A felhasználók egy része közben privát eszközt használ, mert az szerintük jobban megoldja a feladatot, vagy ugyanahhoz az eredményhez a vártnál több kiegészítő licencre van szükség.
Megoldás: mielőtt a teljes szervezetre licencet vásárolsz, a kiválasztott use case-eken, valós feladatokkal hasonlíts össze legalább két eszközt. A beszerzési egyszerűség legyen az egyik szempont a sok közül. Az is elképzelhető, hogy a szervezetben több eszköz indokolt, különböző feladatokra.
7.2. Minden egyetlen eszközre épül
Az AI-piac gyorsan változik: a szolgáltatók árat és feltételeket módosítanak, funkciókat vezetnek ki, új termékek jelennek meg. Ha a szervezet AI-hoz kapcsolódó tudása (utasítások, tudásbázis, folyamatleírások) egyetlen szolgáltató zárt formátumában halmozódik fel, minden ilyen változás közvetlenül a működést érinti, és a váltás költsége idővel egyre nő.
Tünet: a promptok, a tudásbázis és az integrációk egyetlen szolgáltató saját formátumában élnek. Ha az árazás, a feltételek vagy maga a termék megváltozik, nincs hova lépni, és a felhalmozott tudás jelentős része elvész.
Megoldás: a tudást (utasítások, folyamatleírások, bevált promptok) tartsátok a saját dokumentumtáratokban, szolgáltatótól független formában. Integrációnál részesítsd előnyben a nyílt szabványokat, például az MCP-t, így egy eszközváltás nem jelenti az egész megoldás újraépítését.
8. Szervezetfejlesztési hibák a bevezetés után
Az AI-bevezetés a licencek kiosztásával és az első működő megoldásokkal nem ér véget. Ha a munkakörök, a feladatkiosztás, a toborzás, a folyamatok és a szervezeti felépítés nem követik a megváltozott működést, a szervezet a régi struktúrában próbálja kihasználni az új lehetőségeket. Közben az emberek motivációja és munkához való viszonya is változik.
8.1. A felszabaduló kapacitást senki nem osztja újra
Az AI-bevezetés egyik legfontosabb ígérete a felszabaduló kapacitás. Ez a kapacitás azonban egyenetlenül jelenik meg: bizonyos szerepkörökben és feladatokban jelentős, máshol alig érzékelhető. Ha a felszabaduló időt senki nem irányítja tudatosan, akkor elszivárog, vagy egyenlőtlen terhelést okoz a csapaton belül. Tapasztalatunk szerint például a projektmenedzserek adminisztratív feladatainak nagy részét képes az AI támogatni, de ha nem gondoljuk újra, hogy a PM-ek milyen, valóban értéket adó feladatokkal töltsék a felszabaduló idejüket, az üzleti hatás nem tud közvetlenül megjelenni.
Tünet: tegyük fel, hogy az AI egy csapatnál átlagosan a kapacitás 30%-át szabadítja fel. Ha a megmaradt feladatok elosztását senki nem gondolja újra, lesz, aki egész nap az AI-nak ad feladatot, és lesz, aki ugyanúgy túlterhelt marad, mint korábban.
Megoldás: a bevezetés után nézd át a feladatkiosztást, a munkaköri leírásokat és a folyamatokat, és döntsd el tudatosan, mire fordítjátok a felszabaduló időt. Ha a munka jellege megváltozott, a csapatok felépítését és a jóváhagyási szinteket is érdemes felülvizsgálni.
8.2. A karrierutakat nem gondolják újra
A szakmai tudás nagy része gyakorlással épül: a junior kollégák jellemzően a rutinfeladatokon tanulják meg a szakmát, és így válnak évek alatt seniorrá. Ha éppen ezeket a feladatokat veszi át az AI, a tanulási út is megszakad. Rövid távon ez megtakarításnak tűnik, hosszabb távon utánpótlási problémához vezet, aminek kezelésének tervezését már most érdemes elkezdeni.
Tünet: nem vesztek fel juniort, mert a rutinfeladatokat már az AI végzi. Néhány év múlva nincs, aki seniorrá nőjön, és a tapasztalt kollégákat csak a külső piacról lehet pótolni.
Megoldás: gondold újra a karrierutakat: min tanul a junior, ha a rutinmunkát az AI végzi? Hol és hogyan épüljön be az AI-használat az elvárt kompetenciák közé? A juniorok szerepe lehet például az AI-kimenetek szakmai ellenőrzése, senior mentorálással, így a tanulás nem marad ki a folyamatból.
8.3. Figyelmen kívül marad az emberi oldal
Az AI-bevezetés az emberek munkához való viszonyát is megváltoztatja. Átalakul, hogy mire büszke valaki, miben számít szakértőnek, és mit jelent számára a jól végzett munka. Ezek a változások nem jelennek meg a hatékonysági mutatókban, de közvetlenül hatnak a motivációra, az elköteleződésre, és végső soron arra is, hogy a bevezetett eszközöket valóban használják-e.
Tünet: találkoztunk olyan ügyfélhelyzettel, ahol a fejlesztők AI-hozzáférést kaptak, és ehhez vezetői elvárás is párosult: az eszköz segítségével produktivitásnövelést fogalmaztak meg célként. A fejlesztők azonban ellenálltak a használatnak, mert úgy érezték, hogy az eszköz a szakmájuk lényegét veszi el. Máshol a munkahely elvesztésétől való félelem jelenik meg, de mindkét esetben csökken a motiváció, miközben a vezetés a hatékonysági számokat várja.
Megoldás: kommunikálj nyíltan arról, mi változik és mi nem. Adj új felelősségi köröket és fejlődési lehetőségeket, és rendszeresen kérdezd meg a csapatot, hogyan élik meg a változást.
Elakadtál valamelyik ponton?
Ha a fenti hibák közül bármelyikben magadra ismertél, nem kell egyedül kibogoznod. A ProMan Consulting csapata a bevezetés teljes ívén tud segíteni: use case felméréssel és AI-stratégiával az elején, szerepspecifikus AI-képzésekkel a felhasználóknál, AI-megfelelőségi támogatással (AI Act, ISO 27001, NIS2) a biztonsági oldalon, és AI-alapú szervezetfejlesztéssel a bevezetés után.
Írj nekünk, és egy rövid beszélgetésben átnézzük, hol tartotok, és mi lehet a következő lépés!
Gyakran ismételt kérdések az AI-bevezetésről
Hol érdemes elkezdeni az AI-bevezetést?
Egy rövid use case felméréssel. Gyűjtsétek össze, mely feladatoknál segíthet az AI, értékeljétek a jelölteket üzleti hatás és megvalósíthatóság szerint, és a legjobb kettő-hárommal induljatok. Mindegyikhez rögzítsetek előre mérőszámot és kiinduló értéket, hogy később eldönthető legyen, megérte-e.
Mire érdemes figyelni az AI-bevezetés során?
Tapasztalataink szerint a legtöbb hiba a technológia előtt születik meg. Legyen a bevezetésnek gazdája és mérhető célja, a megoldást teszteljétek kis lépésekben, mielőtt automatizáltok, tegyétek rendbe az érintett adatokat és jogosultságokat, és készítsétek fel a munkatársakat a saját feladataikra szabott képzéssel.
Miért gond a shadow AI?
Shadow AI-nak azt nevezzük, amikor a munkatársak a szervezet tudta vagy engedélye nélkül, saját fiókkal használnak AI-eszközöket. Ilyenkor ügyféladat, szerződésrészlet vagy belső szám kerülhet olyan szolgáltatóhoz, amelynek feltételeit senki nem ellenőrizte, és a privát fiókok a bevitt adatokat a modellek tanítására is felhasználhatják. A kockázatot egy biztonságos, hivatalos eszköz és egy egyértelmű szabály csökkenti arról, milyen adat kerülhet AI-ba.
Kötelező-e AI-képzést tartani a munkatársaknak?
Az AI Act 4. cikke 2025. február 2. óta alkalmazandó, 2026 júliusa óta módosított formában: az AI-rendszereket használó szervezeteknek intézkedéseket kell hozniuk munkatársaik AI-jártasságának fejlesztésére. Konkrét óraszámot, vizsgát vagy tanúsítványt a jogszabály nem ír elő. Gyakorlati szempontból pedig a licenc képzés nélkül ritkán hoz eredményt.
Mikor érdemes AI agentet építeni?
Akkor, ha a megoldás az egyszerűbb lépcsőkön már bizonyított: kézi promptolással, tartós projektben és skillként is stabil eredményt ad, és a kézi futtatás vált szűk keresztmetszetté. Sok feladatnál már a projekt vagy a skill szintje elég.
Miből látszik, hogy megtérül az AI-bevezetés?
A használati adatokból (tokenfelhasználás, aktív felhasználók) önmagában nem. Use case-enként előre meghatározott üzleti mérőszám kell, például átfutási idő, ráfordított óra vagy hibaarány, és ezek kiinduló értéke a bevezetés előtt. Ehhez képest mérhető a változás.
Melyik AI-eszközt válasszuk?
Azt, amelyik a kiválasztott use case-ekre a legjobban illik. Mielőtt a teljes szervezetre licencet vásároltok, valós feladatokkal hasonlítsatok össze legalább két eszközt. A beszerzési egyszerűség fontos szempont, de nem lehet az egyetlen, és az is elképzelhető, hogy különböző feladatokra különböző eszköz indokolt.
Mi változik a szervezetben az AI-bevezetés után?
Kapacitás szabadul fel, de egyenetlenül, ezért a feladatkiosztást, a munkaköröket és a folyamatokat újra kell gondolni. A karrierutakat is érdemes átnézni, mert ha a rutinfeladatokat az AI végzi, a juniorok tanulási útja megszakadhat. Az emberek munkához való viszonya is változik, ezért a motivációra és a szakmai identitásra is figyelni kell.
