Miért csalódnak a cégek az új AI modellekben?
Nem a modellel van a baj: miért égetik a pénzt és az időt a vállalkozások, ha ugyanazt az ad-hoc munkamódszert viszik át a GPT-5.6, a Claude vagy a Gemini új generációira – és hogyan építhető fel órák alatt a mérhető, biztonságos AI-munkafolyamat.
Záporoznak ránk az egyre újabb AI modellek. A vezető AI-laboroknak (OpenAI, Anthropic, Google, xAI, Meta, Mistral, Alibaba/Qwen, NVIDIA) rövid idő alatt megközelítőleg 100 új modellváltozata jelent meg. Csak az OpenAI több mint 20 kiadást zúdított a piacra – köztük a GPT-5.4 családot (mini, nano, thinking, coding), a GPT-5.6 Sol / Terra / Luna hármast, valamint a további o-szériás és multimodális modelleket. Közben a cégvezetők és csapatok körében egyre hangosabb a csalódás: „Ez a modell butább, mint az előző.” „Nálam semmivel nem lett jobb.” „Csak égeti a pénzt.”
Ahol a tempó tényleg baj: miért nem biztonsági frissítés egy új AI-modell?
A legtöbb vállalkozás ott követi el az első súlyos hibát, hogy az új AI-modellek megjelenését úgy kezeli, mint egy Windows- vagy böngészőfrissítést: amint kijön az új verzió, azonnal átkapcsol rá, és várja a csodát.
Azt gondolná az ember, hogy ezt az elképesztő sebességű technológiai fejlődést minden cég egy soha vissza nem térő piaci lehetőségnek éli meg. Ehhez képest a szakmai fórumok és a vezetői megbeszélések tele vannak kiábrándult hangokkal. Amikor azonban mélyebbre ásunk egy-egy „használhatatlanul elbutult” modell panasza mögött, szinte kivétel nélkül ugyanazt a jelenséget látjuk: ugyanazt a megszokott munkamódszert és ugyanazokat a félmondatos kéréseket viszik át az egyik modellcsaládról a másikra, majd csodálkoznak, hogy szétesik az eredmény.
Az iramban valóban van probléma, csak éppen nem ott, ahol a legtöbben keresik. Nem az a baj, hogy a gyártók túl gyorsan hozzák ki az új modelleket – hanem az, hogy egy komplex szellemi munkaeszközt nem lehet két hét alatt megtanulni. Pláne úgy nem, ahogy a hazai KKV-k többségében történik: a munkatársak autodidakta módon, saját szakállukra próbálgatják a felületet, rábízva a végeredményt a jószerencsére meg a modell vélt „mindentudására”.
Szinte senki nem veszi a fáradságot ahhoz, hogy a hivatalos fejlesztői dokumentációk (prompting guide-ok, rendszerkártyák) alapján utánajárjon: pontosan milyen bemeneti szerkezetet, milyen kontextust és milyen paraméterezést vár az adott modell a hatékony munkához. Mire pedig a csapat végre ráállna egy nagy nehezen kitapasztalt munkamódszerre, addigra befut a következő modellkiadás, és kezdődik elölről a vakon tapogatózás.
Nem kell minden egyes sajtóbejelentésre ugrani. A szervezetben ki kell jelölni egy felelőst, aki egzakt módszertannal (etalon feladatokon) leteszteli az új jelölteket, és a cég csak akkor vált, ha az új modell az adott üzleti feladathoz mérhetően jobb vagy gazdaságosabb. Aki minden új kiadásra azonnal átáll, az valóban folyamatosan tanul – csak épp soha nem jut el odáig, hogy üzleti hasznot húzzon a tanultakból.
1. Infografika: A „Modell-turizmus” csapdája vs. Tudatos Vállalati Modellmenedzsment
Módszertani különbségTanulság cégvezetőknek: Egyetlen etalon-tesztelés néhány óra munkát igényel egyetlen embertől, viszont megspórol egy teljes hónapnyi csapatszintű találgatást és termelékenységvesztést.
Ki nem tud jól „AI-ul” beszélni? Szerkezet vs. beszélgetés
Mivel az AI-val magyarul (természetes nyelven) beszélgetünk, annyira magától értetődőnek hat a használata, hogy elfelejtjük: ez valójában egy precíziós szerszám. Egy műszerész-fogóval is be lehet verni egy szöget a falba, de lássuk be, nem egymáshoz találták ki őket.
Ez az a pont, ahol a magyar vállalkozásoknál a legtöbb pénz és munkaóra elvész. A különböző modellcsaládok eltérő betanítási (alignment és instruction-tuning) filozófián alapulnak, ezért ugyanaz a prompt nem hordozható át egy az egyben egyik gyártó modelljéről a másikra:
1. Szerkezet vs. beszélgetés (Claude vs. GPT-vonal)
Az Anthropic Claude-modelljei kimagaslóan jól reagálnak a hosszabb, szigorúan tagolt, explicit szabályokat (akár Markdown vagy XML-címkéket) tartalmazó utasításokra: pontos szerepkörre, értékelési szempontokra, rögzített kimeneti formátumra és tételes tiltásokra. Ezzel szemben az OpenAI GPT-vonalánál (különösen a gondolkodó thinking / o-szériás / GPT-5.6 modelleknél) a túlszabályozott, merev parancsok gyakran beszűkítik a modell saját belső érvelési láncát; ott a rövidebb, célzott problémafelvetés és a megfelelő gondolkodási mélység (reasoning effort) beállítása sokkal jobb eredményt ad.
2. Írj explicit szabályokat egyszer, ne külön minden beszélgetésben!
Minden komolyabb professzionális AI-eszközben létezik projektszintű vagy rendszerszintű utasítási réteg – például a Claude Code-nál a CLAUDE.md fájl, a ChatGPT-nél és Claude webes felületén a Projects / Custom Instructions, vagy a fejlesztői környezetekben a .cursorrules.
Ide tartozik minden olyan peremfeltétel, ami a cégedre jellemző: a kódstílus, a kötelező tesztparancsok, a tiltott függvénykönyvtárak listája; üzleti oldalon pedig a cégnév pontos írásmódja, a magázódó/tegeződő megszólítási forma, a tiltott reklámkifejezések és a szabványos aláírásblokk. Ha ezeket minden egyes chat-beszélgetés elején újra begépeled (vagy bemásolod), kétszer fizetsz érte: a drága munkaidőddel és a bemeneti tokenekkel – ráadásul az esetek felében a fele szabályról el is fogsz feledkezni.
A „Találd ki, mire gondoltam” prompt
Hiányoznak a tények, a határidők, a kompenzációs lehetőségek, a hangnem és a terjedelem. A modell kénytelen hallucinálni és sablonos mentegetőzésbe menekülni.
A strukturált, szabályvezérelt prompt
Tartalmazza a tényeket, az alternatívákat, a formai korlátokat, a negatív tiltásokat és a visszakérdezési kötelezettséget.
Általánosítható, 5 lépéses recept egy jó vállalati kérésre
Tények és adatok
Mi történt pontosan? Határidők, számok, okok, felajánlható opciók – találgatás nélkül.
Mit szeretnél?
A konkrét feladat és cél (pl. ügyféllevél, refaktorálás, szerződés-kockázatelemzés).
Formátum & Terjedelem
Tárgysor, max. 150 szó, táblázat, JSON kimenet, magázódó és tényszerű hangnem.
Mit NE csináljon!
Negatív korlátok: ne mentegetőzzön hosszan, ne találjon ki nem létező kedvezményt.
Kérdezzen vissza!
„Ha bármilyen adat hiányzik a pontos végrehajtáshoz, kérdezz rá, ne találgass!”
# VÁLLALATI ÉS PROJEKTSZINTŰ AI SZABÁLYZAT (CLAUDE.md / Project Instructions) ## 1. Cégprofil és Kommunikációs Alapelvek - **Cégnév pontos írásmódja:** [Cégnév Kft.] (Soha ne rövidítsd, és ne fordítsd le angolra!) - **Alapértelmezett nyelv és hangnem:** Magyar nyelv, üzleti magázódó („Ön / Önök”), tényszerű, szakértői, sallangmentes. - **Tiltott kifejezések:** Kerüld az üres marketing-kliséket („forradalmi”, „páratlan”, „dinamikusan fejlődő”), a túlzott mentegetőzést és a passzív angol tükörfordításokat. ## 2. Fejlesztési és Műszaki Szabályok (IT / Kódolás esetén) - **Kötelező tesztelés:** Minden kódmódosítás után futtasd a `pytest` / `npm run test` parancsot. Teszthiba esetén ne nyilvánítsd késznek a feladatot! - **Tiltott műveletek:** Soha ne módosíts éles `.env` fájlt, migrációs történetet vagy produkciós adatbázis-sémát emberi jóváhagyás nélkül. - **Kimeneti elvárás:** Kódgenerálásnál csak a módosított függvényeket és a pontos diff-magyarázatot add vissza. ## 3. Hallucináció-megelőzés és Munkamódszer - Ha egy feladathoz hiányzik egy üzleti tény, paraméter vagy hozzáférési adat, **ALLJ MEG ÉS KÉRDEZZ RÁ** – soha ne találj ki fiktív adatot! - Hosszú feladatnál vezesd a `WORKLOG.md` munkafájlt: rögzítsd a kész lépéseket, a nyitott döntési pontokat és a felhasznált adatforrásokat.
A gondolkodási mélységet állítsd a feladathoz – és takarítsd a kontextusablakot!
Aki minden egyes feladatot a legdrágább csúcsmodellen futtat egy hetek óta nyitva tartott, parttalan chat-szálban, az nem hatékonyabb, hanem nagyságrendekkel drágább, lassabb és pontatlanabb lesz.
Miért nem lövünk mindenre csúcsmodellel?
A mai modellcsaládok több teljesítményszinten érhetők el (pl. GPT-5.4 mini / nano / thinking / coding vagy GPT-5.6 Sol / Terra / Luna). A legerősebb változat akár ötszörös (vagy még magasabb) áron fut a belépő modellhez képest, miközben a válaszideje is jóval hosszabb.
| Modellszint | Tipikus vállalati feladat | Költség & Sebesség |
|---|---|---|
| Belépő / Gyors nano, mini, Luna, Haiku, Flash |
Git commit-üzenet írása, logfájlok előszűrése, szöveg átfogalmazása, táblázat-konverzió, nyersfordítás. | 1× ár • Azonnali |
| Közép / Munkás Terra, Sonnet, alap 5.4 / Pro |
Napi üzleti levelezés, ügyfélszolgálati választervezet, modulszintű kódírás, dokumentum-összefoglalás. | 2–3× ár • Gyors |
| Csúcs / Gondolkodó Sol, Thinking, Opus, Deep Think |
Architekturális döntések, komplex többmodulú hibakeresés, jogi szerződéselemzés, biztonsági audit. | 5×+ ár • Lassabb |
A milliós tokenablak nem arra való, hogy szeméttel töltsd meg!
A gyártók előszeretettel büszkélkednek az 1–2 millió tokenes kontextusablakkal, de a gyakorlatban egy elhúzódó beszélgetésben súlyos kontextusszennyezés (context poisoning / attention dilution) lép fel.
Egy hosszúra nyúlt szálban végig ott marad minden korábbi zsákutca, minden félresikerült próbálkozás, téves feltételezés és elvetett kódváltozat – és a modell figyelem-mechanizmusa (attention) ezekre is súlyt helyez minden egyes új válasznál. Ráadásul minden új kérdésnél újra kifizeted a teljes előzmény tokenköltségét.
Ha a beszélgetési szál eleje már nem releváns az aktuális részfeladatra, vagy két-három zsákutcán már túl vagytok: kérd meg a modellt egy 10 soros tiszta állapot-összefoglalóra, és nyiss vele új szálat!
2. Infografika: Miért „butul el” a modell egy hosszú beszélgetés végére? (Kontextusromlás vs. Tiszta szál)
Attention DilutionPrompt Hardening egy etikus hacker ajánlásával: 5 szabály, amit ügyfélmunkában tilos megszegni
Míg a jó promptolás a hatékonyságról és a költségcsökkentésről szól, addig a Prompt Hardening a cég túléléséről, az ügyféladatok védelméről és az elszabaduló AI-ügynökök megfékezéséről.
Soha ne adj be éles titkot vagy nyers ügyféladatot!
Éles hozzáférési adatot (felhasználónév, jelszó, API-token), privát kulcsot, .env fájltartalmat, azonosítható ügyféladatot vagy GDPR-köteles személyes adatot szigorúan tilos külső modellnek beadni. Ha egy szerver-hibanaplót (logot) elemzünk, beküldés előtt kötelező anonimizálni (maszkolni)!
Licenc-tudatosság: Tisztában kell lenni azzal, hogy a lakossági (Free/Plus) és a vállalati (Team/Enterprise/API Zero-Data-Retention) csomagok adatmegőrzési és modelltanítási feltételei alapvetően eltérnek – és ezt az ügyfelekkel kötött titoktartási szerződések (NDA) is szigorúan számonkérhetik.
„Csak rám figyelj!” – Védelem a Prompt Injection ellen
Minden, amit a modell kívülről olvas be (weboldal, beérkező e-mail, önéletrajz PDF, beszállítói számla), szigorúan adatként kezelendő, soha nem utasításként! Egy PDF-be fehér betűvel beleírt rejtett parancs (Indirect Prompt Injection) ráveheti a modellt adatok kiszivárogtatására vagy jogosulatlan műveletre.
Az OWASP Top 10 for LLM (LLM01) szerint ma ez a leggyakoribb támadási felület. Alapszabály: külső tartalomból származó utasítás soha nem hajtható végre explicit emberi megerősítés (Human-in-the-Loop) nélkül!
Legkisebb jogosultság elve az ügynöki (Agent) hozzáférésnél
Ha az AI-modell vagy ügynök (pl. MCP szerveren vagy CLI-n keresztül) fájlrendszerhez, adatbázishoz vagy belső API-hoz fér hozzá, a jogosultságát alapértelmezetten csak olvasási (Read-Only) jogra kell korlátozni.
Mindig izolált fejlesztői környezetben vagy adatbázis-másolaton dolgoztassuk. Semmilyen körülmények között ne adjunk az AI-nak közvetlen írási/törlési jogot éles adatbázisra vagy éles tűzfal/szerver konfigurációra azonnali visszaállítási (rollback) lehetőség nélkül!
Ellenőrzés (Review) nélkül semmi nem mehet élesbe!
Sem generált forráskód, sem szerződésszöveg, sem ügyfélnek szánt hivatalos levél nem hagyhatja el a céget emberi ellenőrzés nélkül. Az AI által írt kódra pontosan ugyanaz a biztonsági tesztkör (SAST/DAST) és ugyanaz a négyszem-elves code review vonatkozik, mintha egy junior fejlesztő írta volna. Ha a kötelező review-val együtt a folyamat lassabb, mint AI nélkül, akkor nem a review a felesleges, hanem a munkafolyamat van rosszul összerakva!
Kettős jegyzetelés: Biztonsági napló + Modell munkafájl
Kétféle jegyzetelést kell bevezetni. 1) Biztonsági auditnapló: ki, mikor, milyen bemenetet adott a modellnek, és mit kapott vissza – incidens vagy ügyfélreklamáció esetén ez lesz az egyetlen bizonyítékod. 2) Modell által vezetett munkafájl (pl. WORKLOG.md): ahova maga az AI jegyzeteli a részfeladatokat, az előrehaladást, a döntési pontokat, a szükséges adatforrásokat, valamint a felhasznált idő- és tokenkeretet. Mert amit nem mérsz, azon nem is tudsz javítani.
Hogyan mérd le néhány óra alatt, hogy tényleg megéri-e váltani?
Ahelyett, hogy nemzetközi ranglisták (leaderboardok) vagy hangos fórumviták alapján döntenél, építs saját, 3–5 feladatból álló vállalati etalon-mércét!
Válassz ki három-öt olyan valós feladatot, amit a cégedben hetente végzel, és amelyeknél pontosan tudod, hogyan kell kinéznie a hibátlan, üzletileg elfogadható végeredménynek. Írd le ezeket a feladatokat, és tedd melléjük a strukturált etalon promptot. Ez a csomag lesz a te saját, megvesztegethetetlen mércéd.
Amikor megjelenik egy új modellcsalád, a kijelölt felelős futtassa le rajtuk ezt az 5 etalon feladatot, és három objektív mutatót jegyezzen fel:
- Hány körből (iterációból) lett valóban használható az eredmény?
- Mennyi tokenbe (és centbe/forintba) került a teljes folyamat összesen?
- Mennyi időt kellett utána kézzel javítani a generált kimeneten?
Ez a mérés összesen néhány óra munka, viszont megspórol egy teljes hónapnyi csapatszintű találgatást és felesleges előfizetés-váltogatást.
Mennyibe kerül az „Ad-hoc AI használat” a cégednek havonta?
Állítsd be, hány kolléga használ AI-t a csapatban, és nézd meg, mennyi munkaidőt és tokenköltséget éget el a strukturálatlan promptolás, a kontextusszennyezés és az utólagos kézi javítgatás!
Miért csalódnak a cégek az új AI modellekben?
Munkamódszer, prompt-architektúra, kontextushigiénia, Prompt Hardening és etalon mérés.
Nyugati fejlesztőeszközök vs. felzárkózó kínai modellek
Miért nyugati fejlesztők eszközeit használom éles munkában, és mit gondolok a felzárkózó kínai modellekről?
Melyik AI-előfizetés éri meg a gyakorlatban?
Konkrét költség-haszon elemzés, csomagok, API vs. havidíjas licencek és adatvédelmi garanciák.
Következő lépés
Tudd meg, hol vannak a céges IT valódi kockázatai.
Egy kockázatfelmérés során átvizsgáljuk a rendszered legfontosabb pontjait, majd világos, fontossági sorrendbe rendezett javaslatokat adunk a javításhoz.