AI-átállás

Digitális transzformáció józanul — lépésről lépésre

AI-átállás · Digitális transzformáció

Nem az a kérdés, kell-e AI — hanem hogy hol, mekkora, és mi előzze meg.

A legtöbb KKV-nál az AI-átállás nem egy nagy modellel kezdődik, hanem rendezett folyamatokkal és elérhető adatokkal. Ezen az oldalon interaktív példákon mutatjuk meg, hogyan döntsön: felhő vagy lokális modell, milyen infrastruktúra kell hozzá — és mikor elég egy jól megírt szabály a tokenégetés helyett.

Érettségi önfelmérés Felhő vagy lokális?
0 token egy jól megírt szabály futási költsége
4–8 hét egy mérhető pilot jellemző hossza
6 szint a sablontól az agent-rendszerig
nessyfy-router — feladat-útválasztó
DEMÓ
Beérkező feladatok · melyik szint oldja meg? 6/6 besorolva
  1. Számla ÁFA-összegének ellenőrzése Szabály 0 token · < 1 ms
  2. Ügyfél-e-mail besorolása (panasz / ajánlatkérés) LLM ~600 token · lokális kis modell
  3. Heti készletriport összeállítása az ERP-ből RPA / API 0 token · ütemezett robot
  4. 30 oldalas szerződés kockázatainak összefoglalása LLM ~25 000 token · EU-s felhő
  5. Szállítólevél adatainak kiolvasása OCR / ML dokumentum-felismerés · 0 LLM-token
  6. 15% feletti kedvezmény jóváhagyása Ember döntési jogkör · nem automatizáljuk
Nyelvi modell: 2/6 feladatnál
01 · Alapok

Mit jelent valójában az AI-átállás?

A digitális transzformáció nem eszközvásárlás, hanem a működés átgondolása: folyamatok, adatok, rendszerek és emberek összehangolása. Az AI ennek egy — nagyon erős — eszköze, de nem minden feladatra ez a legjobb válasz.

Folyamat előbb, technológia utána

Az AI egy jól működő folyamatot felgyorsít — egy rosszul működőt csak gyorsabban ront el. Az átállás első lépése mindig a folyamat megértése és rendbetétele.

Az adat az üzemanyag

A modell annyit ér, amennyi rendezett, elérhető és jogszerűen használható adat áll mögötte. Ennek felmérése nem mellékszál, hanem a projekt gerince.

Az ember marad a döntéshozó

Az AI javasol, összefoglal, előkészít — a felelős döntés emberi kézben marad. Egy jó rendszerben előre rögzített, hol kell emberi jóváhagyás.

Mítosz vagy valóság?

Hat állítás, amelyet szinte minden első egyeztetésen hallunk. Kattintson a kártyákra a válaszért.

02 · Döntési létra

Mikor elég egy jobb folyamat a tokenégetés helyett?

A megoldásoknak szintjei vannak — a sablontól az agent-rendszerig. Minden szinttel nő a rugalmasság, de a költség, a futásidő és az ellenőrzés igénye is. A jó tervezés a legalacsonyabb elégséges szintet választja.

Megoldás-választó

Gondoljon egy konkrét folyamatára, és válaszoljon öt kérdésre.

1Le van írva a folyamat, és mindenki ugyanúgy végzi?

2Leírható egyértelmű szabályokkal, mi a teendő?

3Milyen formában érkezik a bemenet?

4Kell-e szöveget értelmezni vagy megfogalmazni?

5Hány rendszeren és lépésen ível át?

  1. 06 AI agentek és A2A sok token / feladat
  2. 05 Generatív AI (LLM) token / hívás
  3. 04 Dokumentum-felismerés és ML 0 LLM-token
  4. 03 RPA és integráció 0 token
  5. 02 Szabály és workflow 0 token
  6. 01 Folyamat-rendbetétel 0 token

Válaszoljon a kérdésekre — a javasolt szint itt jelenik meg, és a létrán is kiemeljük.

Javasolt szint

01 · Folyamat-rendbetétel

Sablon, felelős, határidő, egyértelmű szabályok — technológia nélkül. Meglepően gyakran ez hozza a legnagyobb javulást, és minden további szint alapja.

Javasolt szint

02 · Szabály és workflow

Űrlap, jóváhagyási folyamat, ERP-szabály vagy néhány soros szkript. Determinisztikus, olcsó és auditálható: ugyanarra a bemenetre mindig ugyanazt adja.

Javasolt szint

03 · RPA és integráció

Rendszerek összekötése API-val vagy szoftverrobottal: az adat emberi másolgatás nélkül jut el A-ból B-be, ütemezve vagy eseményre.

Javasolt szint

04 · Dokumentum-felismerés és ML

OCR, osztályozás, előrejelzés: célzott modellek kiszámítható költséggel — gyakran helyben futtatva. A nyelvi modellnél olcsóbb és jobban mérhető.

Javasolt szint

05 · Generatív AI (LLM)

Szöveg értelmezése, összefoglalása, megfogalmazása. Itt jelenik meg a tokenköltség — és az igény, hogy a kimenetet mintavételesen ellenőrizzük.

Javasolt szint

06 · AI agentek és A2A

Több lépéses, önálló eszközhasználat és agentek közötti feladatátadás. A legrugalmasabb szint — és a legtöbb tervezést, jogosultság-kezelést és felügyeletet igényli.

Ugyanaz a feladat, három úton

Havi 5 000 beérkező számla ÁFA-összegének ellenőrzése — egyértelmű, szabályalapú feladat. Ennyibe kerül, ha szabállyal, nyelvi modellel vagy AI agenttel oldjuk meg.

Szabály (kód)
0 Ft futási költség / hó
Idő tételenként
< 0,1 mp
Kiszámíthatóság
100% — ugyanarra a bemenetre mindig ugyanaz
LLM-hívás tételenként
9 000 Ft futási költség / hó
Idő tételenként
1–3 mp
Kiszámíthatóság
valószínűségi — mintavételes ellenőrzés kell
AI agent tételenként
150 000 Ft futási költség / hó
Idő tételenként
10–40 mp
Kiszámíthatóság
valószínűségi, több lépésben — naplózás és felügyelet kell

* Számítás: 5 000 tétel × ~1 500 token (LLM), illetve × ~25 000 token (agent, több lépés), 1 200 Ft / 1 millió token irányárral. A szabály költsége a fejlesztés egyszeri díja — futásonként gyakorlatilag nulla.

A tokenköltség önmagában kicsi is lehet — a valódi ár a kiszámíthatatlanság és az ellenőrzés. Ahol a szabály egyértelmű, ott a szabály nyer.

Folyamat-boncolás: hol van helye az AI-nak?

Három tipikus KKV-folyamat, lépésekre bontva. Váltson a „Ma” és az „Átállás után” nézet között: minden lépés a legalacsonyabb elégséges szintre kerül — és kiderül, hány lépéshez kell valóban nyelvi modell.

  1. 01 Ajánlatkérés kiolvasása az e-mailből Az LLM kinyeri az ügyfelet, a termékeket és a mennyiséget — strukturált adatként. Kézi LLM 10 perc 0,5 perc
  2. 02 Ügyfél ellenőrzése a CRM-ben API-hívás: törzsadat, fizetési fegyelem, korábbi ajánlatok. Kézi RPA / API 5 perc automatikus
  3. 03 Készlet és szállítási idő lekérdezése ERP-integráció: valós idejű készlet, telefonos egyeztetés nélkül. Kézi RPA / API 10 perc automatikus
  4. 04 Árazás a kedvezményszabályok szerint Szabálytábla: ügyfélkategória és mennyiség szerinti kedvezmény — nincs szükség AI-ra. Kézi Szabály 15 perc automatikus
  5. 05 Ajánlat-szöveg megfogalmazása Az LLM tervezetet ír a cég hangnemében; a munkatárs átnézi és küldi. Kézi LLM 20 perc 3 perc
  6. 06 Jóváhagyás 15% kedvezmény felett Tudatosan emberi döntés marad — a rendszer előkészíti az indoklást. Kézi Ember 5 perc 5 perc
Átfutás / ügy 65 65 perc 8,5 perc
Nyelvi modell 2/6

Hat lépésből kettőhöz kell nyelvi modell — a többit integráció és szabály oldja meg.

  1. 01 Számla beérkezése és iktatása Egy központi számlafogadó cím és iktatási szabály — szervezési kérdés. Kézi Folyamat 5 perc 0,5 perc
  2. 02 Számlaadatok kiolvasása Dokumentum-felismerés (OCR); csak a bizonytalan mezőket nézi meg ember. Kézi OCR / ML 8 perc 0,5 perc
  3. 03 Párosítás megrendeléssel és szállítólevéllel Háromutas egyeztetés szabály alapján: összeg, tétel, mennyiség. Kézi Szabály 10 perc automatikus
  4. 04 Rögzítés az ERP-ben Robot vagy API rögzíti — gépelés nélkül. Kézi RPA / API 6 perc automatikus
  5. 05 Eltérések kezelése Csak a kivételek jutnak emberhez, előkészített összehasonlítással. Kézi Ember 5 perc 3 perc
  6. 06 Utalási lista összeállítása Workflow: esedékesség szerint, jóváhagyási körrel. Kézi Szabály 4 perc automatikus
Átfutás / ügy 38 38 perc 4 perc
Nyelvi modell 0/6

Ehhez a folyamathoz egyáltalán nem kell generatív AI: dokumentum-felismerés, szabály és robot elég.

  1. 01 Levél beérkezése a közös postafiókba Egyetlen csatorna és jegykezelő rendszer — elveszett levelek nélkül. Kézi Folyamat 2 perc automatikus
  2. 02 Besorolás és sürgősség megállapítása Lokális kis nyelvi modell sorol: panasz, kérdés, rendelés — az adat a cégen belül marad. Kézi LLM 3 perc automatikus
  3. 03 Ügyféladatok és rendelési előzmények összegyűjtése Integráció a webshoppal és az ERP-vel. Kézi RPA / API 6 perc automatikus
  4. 04 Válasz-tervezet megírása Az LLM a céges tudásbázis alapján fogalmaz; a munkatárs ellenőriz és küld. Kézi LLM 12 perc 2 perc
  5. 05 Visszatérítés jóváhagyása Pénzügyi döntés — emberi kézben marad. Kézi Ember 4 perc 4 perc
  6. 06 Ügy lezárása és riport Szabály: státusz, címkézés, heti kimutatás automatikusan. Kézi Szabály 3 perc automatikus
Átfutás / ügy 30 30 perc 6 perc
Nyelvi modell 2/6

A besorolást egy lokális kis modell végzi, a válasz-tervezetet egy nagyobb — a döntés mindkét esetben emberé.

03 · Felhő vagy lokális

Hol fusson a modell?

Felhős API, EU-s privát felhő vagy saját szerver — mindháromnak megvan a helye. A döntést nem a divat, hanem az adat érzékenysége, a terhelés és a saját üzemeltetési képesség határozza meg.

Felhő API

A modell a szolgáltató adatközpontjában fut, és csak a tényleges használatért fizet. Gyors indulás, mindig a legújabb modellek.

Mikor jó? Nem érzékeny adatoknál, ingadozó terhelésnél, gyors pilothoz.

Privát / EU-s felhő

Dedikált vagy szerződéssel védett felhőkörnyezet EU-régióban, adatmegőrzés és a modell tanítására való felhasználás nélkül.

Mikor jó? Személyes adatoknál és üzleti titkoknál, ha nincs saját üzemeltetés.

Lokális (on-prem)

Nyílt súlyú modell a saját szerverén: az adat nem hagyja el a céget, és internet nélkül is működik — az üzemeltetés viszont az Öné.

Mikor jó? Szigorú adatvédelemnél, offline igénynél, nagy és egyenletes terhelésnél.

Mi igaz a cégére?

Jelölje be az állításokat — a mérleg azonnal mutatja, melyik irány illik jobban.

Irány-mérleg
Felhő API 0
Privát / EU-s felhő 0
Lokális (on-prem) 0

Jelöljön be legalább egy állítást — a pontszámok és a javaslat itt jelennek meg.

Felhő API

A rugalmasság és a gyors indulás a fontosabb. Üzleti előfizetéssel, adatfeldolgozói szerződéssel és belső szabályzattal biztonságosan használható.

Privát / EU-s felhő

Az adatvédelem számít, de saját üzemeltetést nem szeretne. EU-régiós, adatmegőrzés nélküli környezetben a csúcsmodellek is elérhetők.

Lokális modell

Az adat nem hagyhatja el a céget, vagy offline működés kell. Számoljon a hardverrel, a hűtéssel és az üzemeltetéssel — a lenti kalkulátor és a következő szekció segít.

Hibrid felállás

A két irány közel azonos — tipikusan a hibrid megoldás a nyerő: az érzékeny adatokkal dolgozó lépések lokálisan vagy privát felhőben futnak, a többi felhős modellel.

Erősségek és gyengeségek

Képesség Felhő API Privát / EU-s felhő Lokális (on-prem)
Kontroll az adatok felett
Alacsony indulási költség
Kis üzemeltetési teher
Hozzáférés a legerősebb modellekhez
Rugalmas skálázás
Offline működés
Kiszámítható havi költség

●●● = erős oldal · ●○○ = gyenge oldal. Általános irányok — a konkrét szolgáltató és szerződés sokat számít.

Költség-kalkulátor: felhő vagy saját szerver?

Állítsa be a várható terhelést — a kalkulátor irányárakkal összeveti a felhős futási díjat egy saját GPU-szerver havi költségével (36 hónapos értékcsökkenés + áram + üzemeltetés).

Modellméret

500
2 000

Havi költség

Felhő API 4 400 Ft
Saját szerver 107 444 Ft
havonta, irányárral

Ennél a terhelésnél a felhő ~24,4× olcsóbb.

Fordulópont: ennél a kérésméretnél kb. 12 000 kérés/nap fölött kezd megérni a saját szerver.

Tanulság: költség miatt ritkán, adatvédelem vagy offline működés miatt gyakran éri meg a lokális modell.

* Irányárak (2026): felhős futtatás 200 / 1 200 Ft per 1 millió token (vegyes be- és kimeneti árazással), szerver 1 600 000 / 7 000 000 Ft, havi 22 munkanappal számolva. A legerősebb, zárt modellek csak felhőből érhetők el. A pontos összevetést az Ön adataival a felmérésen készítjük el.

04 · Infrastruktúra

Milyen környezet kell az AI-hoz?

Az AI egy réteg a meglévő infrastruktúrán — és csak olyan stabil, mint ami alatta van. Válassza ki a működési módot, majd kattintson a rétegekre: megmutatjuk, mit kell ellenőrizni.

Irányítás és megfelelés

Felhős modell

A technológia mellé szabályok kellenek: ki, mire, milyen adattal használhatja az AI-t — és hogyan ellenőrizzük.

  • Belső AI-szabályzat és munkatársi képzés (az EU AI Act AI-jártasságot vár el)
  • Naplózás: ki, mikor, milyen kérést küldött a modellnek
  • GDPR: jogalap, adatkezelési tájékoztató, adatfeldolgozói szerződés
Lokális modell

Lokálisan az adat nem hagyja el a céget — de a hozzáférés-kezelés, a naplózás és a frissítés felelőssége teljesen az Öné.

  • Jogosultságkezelés és kétlépcsős azonosítás a modellszerveren is
  • Biztonsági frissítések és sérülékenység-kezelés ütemezve
  • Üzemeltetési felelős és helyettes kijelölése

Alkalmazás

Felhős modell

A felhasználó nem modellt használ, hanem egy eszközt: asszisztenst, automatizmust vagy agentet, amely a munkafolyamatába illeszkedik.

  • Ott jelenjen meg, ahol a munka folyik (levelező, ERP, Teams)
  • Emberi jóváhagyás a kockázatos lépéseknél
  • Visszajelzés-gyűjtés a válaszok minőségéről
Lokális modell

Lokális modell mellett is ugyanez a cél — a különbség, hogy a skálázás, a frissítés és a hibaelhárítás is saját feladat.

  • Belső felület vagy integráció a meglévő eszközökbe
  • Terheléshez méretezett kiszolgálás, sorban állással csúcsidőben
  • Verziókezelés: modell- és promptváltozások nyomon követése

Modell-réteg

Felhős modell

Felhős modellnél a választás a szolgáltatón és a szerződésen múlik: hol fut, mit tárol, és mire használhatja az adatot.

  • Üzleti előfizetés és adatfeldolgozói megállapodás (DPA), EU-s adatkezeléssel
  • Adatmegőrzés és a modell tanítására való felhasználás kizárása
  • Szolgáltató-függetlenség: a modell később cserélhető legyen
Lokális modell

Lokálisan nyílt súlyú modellek futnak (például a Llama, a Mistral vagy a Qwen családból). A modellméretet a feladathoz és a hardverhez kell szabni.

  • Modellválasztás feladat szerint: kicsi (7–14B) besorolásra, nagyobb az érveléshez
  • Kvantálás és kiszolgáló szoftver beállítása (például vLLM vagy Ollama)
  • Licencfeltételek ellenőrzése üzleti felhasználásra

Integráció

Felhős modell

Az AI akkor hasznos, ha a meglévő rendszerekből olvas, és oda ír vissza — nem egy külön ablakban él.

  • API vagy export a fő rendszerekből (ERP, CRM, könyvelés)
  • Integrációs réteg (API, RPA, workflow) a modell és a rendszerek között
  • Titkos kulcsok kulcstárban — soha nem a kódban vagy egy táblázatban
Lokális modell

Lokális modellnél az integráció a belső hálózaton marad — külső szolgáltatás felé nem megy adat.

  • Belső API-végpont a modellhez (szabványos, OpenAI-kompatibilis felülettel)
  • Hálózati szegmentálás: a modellszerver csak a szükséges rendszereket éri el
  • Monitorozás: válaszidő, hibaarány, GPU-terheltség

Adat és tudásbázis

Felhős modell

A modell csak azt tudja, amit odaadunk neki. A céges tudást (szabályzatok, termékadatok, korábbi válaszok) kereshető tudásbázisba szervezzük (RAG).

  • Egy hiteles forrás adatonként — nincs öt verziójú Excel
  • Jogosultság-szintek a dokumentumokon: a modell sem lát többet, mint a felhasználó
  • Adatminimalizálás: csak a szükséges adat kerül a modell elé
Lokális modell

Ugyanez a tudásbázis helyben épül fel: vektoradatbázis, indexelés és mentés is a saját infrastruktúrán.

  • Vektoradatbázis és indexelő szolgáltatás a saját szerveren
  • Rendszeres, tesztelt mentés a tudásbázisról is
  • Adatfrissítés felelőssel és ütemezéssel

Hardver és környezet

Felhős modell

Nincs szükség külön szerverre: a modell a szolgáltató adatközpontjában fut. A kritikus pont a hálózat és a munkaállomások állapota.

  • Stabil, lehetőleg szimmetrikus internet (irányszám: 50–100 Mbit/s)
  • Tartalék internetkapcsolat a kritikus folyamatokhoz
  • Naprakész, központilag menedzselt munkaállomások
Lokális modell

A modell a saját gépein fut — ehhez GPU-s szerver és megfelelő fizikai környezet kell. Egy GPU-s szerver 0,5–1,5 kW hőt termel, és nem csendes.

  • GPU-s szerver: kis modellhez ~24 GB, közepeshez 48–96 GB videómemória
  • Hűtött, zárt helyiség vagy rack, szünetmentes táp (UPS), elegendő áramkör
  • Zaj- és hőterhelés: irodai asztal alá nem ajánlott

Környezeti feltételek dióhéjban

0,5–1,5 kW hőleadás GPU-szerverenként — a hűtést előre kell tervezni
24–96 GB videómemória, a modellmérettől függően
UPS szünetmentes táp a folyamatos, adatvesztés nélküli üzemhez
50–100 Mbit/s stabil sávszélesség felhős modellnél (irányszám)
Önfelmérés

Hol tart most a cége?

18 állítás hat területen. Jelölje be, ami ma igaz — a radar megmutatja az erősségeket, és javaslatot ad az első lépésre.

Folyamatok

0/3

Adatok

0/3

Rendszerek

0/3

Biztonság és megfelelés

0/3

Emberek és szervezet

0/3

Üzleti cél és mérés

0/3
AI-érettség Folyamat Adat Rendszerek Biztonság Emberek Cél
0%

Jelölje be a cégére ma igaz állításokat — az értékelés itt jelenik meg.

Felfedező

Az alapok még épülnek — és ez teljesen rendben van, a legtöbb KKV innen indul. Az első lépés nem az AI, hanem a folyamatok és az adatok rendbetétele.

Alapozó

Több terület rendben van, de vannak hiányok, amelyek egy AI-projektet megbuktatnának. Célzott alapozással néhány hónap alatt pilotra kész lehet.

Pilotra kész

Megvannak az alapok egy jól körülhatárolt pilothoz. Válasszunk egy mérhető folyamatot, és 4–8 hét alatt bizonyítsunk.

Skálázható

Erős alapok: a bevált megoldások több folyamatra is kiterjeszthetők — ahol indokolt, akár együttműködő agent-rendszerré.

Küldje el nekünk az eredményt

* Önértékelés, tájékoztató jelleggel. Az ingyenes konzultáción részletesen átnézzük.

05 · Felmérés

A kérdések, amelyeket fel fogunk tenni

Egy átállás — legyen szó digitalizálásról vagy egy A2A agent-rendszerről — mindig jó kérdésekkel kezdődik. Itt vannak a mieink, indoklással. Ha előre végiggondolja őket, az első egyeztetés fele idő alatt jut eredményre.

  1. 01 Melyik három folyamat viszi el a legtöbb munkaidőt — és ezt mérték-e már? Miért kérdezzük?

    A megtérülés ott a legnagyobb, ahol sok az ismétlődő munkaóra. Becslés helyett mérésből indulunk.

  2. 02 Hol várnak a munkatársak egymásra vagy egy jóváhagyásra? Miért kérdezzük?

    A várakozás gyakran nagyobb veszteség, mint maga a munka — és sokszor szervezéssel, technológia nélkül megszüntethető.

  3. 03 Mely lépések szabályalapúak, és hol kell mérlegelni? Miért kérdezzük?

    Ez dönti el, hogy szabály, RPA vagy AI kell-e. Szabályalapú lépéshez nem érdemes nyelvi modellt használni.

  4. 04 Mi történik ma hiba vagy kivétel esetén? Miért kérdezzük?

    Az automatizálás jellemzően a kivételeknél csúszik el. Ha ezek nincsenek leírva, a rendszer sem tudja kezelni őket.

  5. 05 Ki a folyamat gazdája, és ki dönthet a változtatásról? Miért kérdezzük?

    Felelős nélkül a legjobb megoldás is elhal. Minden sikeres bevezetés egy névvel kezdődik.

  1. 01 Hol keletkezik és hol tárolódik a folyamathoz szükséges adat? Miért kérdezzük?

    Feltérképezzük az adat útját: papír, e-mail, Excel, ERP. Ahol az adat nem digitális, ott a digitalizálás az első lépés.

  2. 02 Mennyire tiszta és egységes az adat (duplikációk, hiányok, formátumok)? Miért kérdezzük?

    A modell nem javítja meg a rossz adatot — felerősíti. Az adattisztítás sokszor a projekt fele.

  3. 03 Mely adatok személyesek, üzleti titkok vagy szerződéssel védettek? Miért kérdezzük?

    Ez határozza meg, mehet-e az adat felhős modellhez, vagy lokális, illetve privát felhős megoldás kell.

  4. 04 Van-e elég múltbeli példa (dokumentum, válasz, döntés) a teszteléshez? Miért kérdezzük?

    A minőséget valós példákon mérjük. Néhány tucat-néhány száz jó példa már sokat elárul egy pilot előtt.

  5. 05 Ki felel az adatok naprakészségéért? Miért kérdezzük?

    Egy elavult tudásbázisból magabiztosan rossz válaszok születnek.

  1. 01 Milyen rendszereket használnak (ERP, CRM, könyvelés, levelezés), és van-e hozzájuk API? Miért kérdezzük?

    Az API-s kapcsolat gyors és stabil; ahol nincs, RPA-val vagy exporttal oldjuk meg.

  2. 02 Felhőben vagy helyben futnak a fő rendszerek? Miért kérdezzük?

    Ez befolyásolja, hol érdemes a modellt és az integrációt futtatni.

  3. 03 Milyen állapotban van a hálózat és a szerver-infrastruktúra? Miért kérdezzük?

    Lokális modellnél ez kritikus: áram, hűtés, hely, mentés, sávszélesség.

  4. 04 Van-e már céges, licencelt AI-eszköz — vagy magáncélú fiókokkal dolgoznak a kollégák? Miért kérdezzük?

    Az ellenőrizetlen „árnyék-AI” használat a leggyakoribb adatvédelmi kockázat. Felmérjük, és biztonságos alternatívával váltjuk ki.

  5. 05 Ki üzemelteti ma az IT-t (belső kolléga, külső partner)? Miért kérdezzük?

    Ettől függ, mennyi üzemeltetési terhet vállalhat a cég — és mennyire legyen menedzselt a megoldás.

  1. 01 Van-e jogosultságkezelés és kétlépcsős azonosítás a fő rendszereken? Miért kérdezzük?

    Egy AI-eszköz sem lehet biztonságosabb annál a fióknál, amellyel az adatokhoz hozzáfér.

  2. 02 Van-e írott szabály az AI-eszközök használatáról? Miért kérdezzük?

    Az EU AI Act a munkatársak AI-jártasságát is elvárja; egy rövid, érthető belső szabályzat ennek az alapja.

  3. 03 Érinti-e a tervezett felhasználás a munkavállalók vagy az ügyfelek jogait (például kiválasztás, hitelbírálat)? Miért kérdezzük?

    Ezek magas kockázatú felhasználások, szigorúbb követelményekkel — már a tervezésnél számolni kell velük.

  4. 04 Milyen naplózásra és visszakövethetőségre van szükség? Miért kérdezzük?

    Ha egy döntést meg kell magyarázni, tudni kell, milyen adatból és milyen modell-válasz alapján született.

  5. 05 Mi a teendő, ha a modell hibázik? Miért kérdezzük?

    Előre definiált hibakezelés és emberi jóváhagyási pont nélkül nem megyünk élesbe.

  1. 01 Kik fogják napi szinten használni, és bevontuk-e őket? Miért kérdezzük?

    A kulcsfelhasználók ismerik a kivételeket — és ők döntik el, hogy a megoldást használni fogják-e.

  2. 02 Milyen a hozzáállás az AI-hoz: félelem, kíváncsiság, túlzott elvárás? Miért kérdezzük?

    A változáskezelés fontosabb, mint a modellválasztás. A félelmet átláthatósággal, a túlzott elvárást egy mérhető pilottal kezeljük.

  3. 03 Ki lesz a belső felelős az átállás után? Miért kérdezzük?

    A megoldásnak gazdája kell legyen: valaki, aki visszajelzéseket gyűjt, és prioritásokról dönt.

  4. 04 Milyen képzés kell a használathoz és az eredmények ellenőrzéséhez? Miért kérdezzük?

    A jó kérdésfeltevés és a kimenet ellenőrzése tanulható — és a minőség nagy része ezen múlik.

  5. 05 Mely feladatok szabadulnak fel, és mire fordítják majd az időt? Miért kérdezzük?

    Az átállás célja nem a létszámleépítés, hanem a kapacitás jobb felhasználása — ezt érdemes már az elején kimondani.

  1. 01 Milyen konkrét problémát old meg az átállás? Miért kérdezzük?

    Az „AI-t akarunk” nem cél. Az „ajánlatadási időt a felére akarjuk csökkenteni” igen.

  2. 02 Mi a mérőszám, és mi a mai kiinduló érték? Miért kérdezzük?

    Kiinduló mérés nélkül nem lehet bizonyítani a megtérülést.

  3. 03 Mekkora a keret, és mekkora a tűréshatár a hibára? Miért kérdezzük?

    Ettől függ a megoldás szintje: egy szinte hibátlan pontosságot igénylő feladat más architektúrát kér, mint egy javaslattevő asszisztens.

  4. 04 Mi lenne egy jó első pilot (4–8 hét, mérhető eredménnyel)? Miért kérdezzük?

    Kicsiben kezdünk, gyorsan tanulunk, és csak a bevált megoldást skálázzuk.

  5. 05 Van-e pályázati vagy egyéb támogatási lehetőség? Miért kérdezzük?

    A digitalizációs és AI-fejlesztések egy része támogatásból is finanszírozható — ezt már a tervezésnél érdemes figyelembe venni.

Ha több, egymással együttműködő agentben gondolkodik, ezek a kérdések is az asztalra kerülnek:

  1. 01 Mely feladatok bonthatók jól elkülönülő szerepekre (beérkeztetés, árazás, ellenőrzés)? Miért kérdezzük?

    Az agent-rendszer akkor működik jól, ha minden agentnek egyértelmű, szűk felelőssége van.

  2. 02 Mit tehet meg önállóan egy agent, és mihez kell emberi jóváhagyás? Miért kérdezzük?

    Az önállóság határait előre rögzítjük: pénzügyi, jogi és ügyfélre ható lépéseknél ember dönt.

  3. 03 Milyen eszközökhöz és adatokhoz férhet hozzá egy-egy agent? Miért kérdezzük?

    A legkisebb jogosultság elve itt kritikus: minden agent csak azt éri el, ami a feladatához kell.

  4. 04 Hogyan követjük vissza, melyik agent mit döntött, és miért? Miért kérdezzük?

    Agentek közötti feladatátadásnál a teljes lánc naplózása nélkül a hibakeresés gyakorlatilag lehetetlen.

  5. 05 Mekkora a token- és költségkeret agentenként? Miért kérdezzük?

    A több lépéses agentek gyorsan égetik a tokent — költségkorlát és riasztás nélkül kellemetlen meglepetést okozhatnak.

06 · A2A

Amikor az agentek egymással dolgoznak

Az A2A (Agent2Agent) nyílt protokoll, amellyel különböző rendszerek AI agentjei felfedezik egymás képességeit, és feladatot adnak át egymásnak. Nézze meg egy ajánlatkérés útját — és azt, hol marad a döntés emberi kézben.

Beérkeztető agent e-mail, webes űrlap
Ajánlat-agent koordinálja a folyamatot
Készlet-agent raktár, szállítási idő
Értékesítési vezető ember · jóváhagyás
ERP MCP-eszköz
Árazó agent kedvezményszabályok
a2a-trace — ajanlatkeres #4471
A2ABeérkeztető agent → Ajánlat-agentfeladat: ajánlatkérés — Kovács Kft., 40 db SZ-220 szelep, határidő 2 hét
A2AAjánlat-agent → Készlet-agentkérdés: elérhető 40 db SZ-220? Mennyi a szállítási idő?
MCPKészlet-agent → ERPerp.stock(SZ-220) → 32 db raktáron, 8 db 6 munkanapon belül
A2AKészlet-agent → Ajánlat-agentválasz: 32 db azonnal, 8 db 6 munkanap — részszállítás lehetséges
A2AAjánlat-agent → Árazó agentárazás: 40 db, törzsügyfél, részszállítással
A2AÁrazó agent → Ajánlat-agentjavaslat: 18% kedvezmény — 15% felett jóváhagyás szükséges
HITLAjánlat-agent → Értékesítési vezetőjóváhagyási kérés: 18% kedvezmény, indoklással és árrés-számítással
HITLÉrtékesítési vezető → Ajánlat-agentjóváhagyva 15%-kal — a megjegyzés bekerül az ajánlatba
A2AAjánlat-agent → Beérkeztető agentkész: az ajánlat-tervezet elment az ügyfélnek · a teljes lánc naplózva
9/9 üzenet
  • A2Aagent ↔ agent feladatátadás
  • MCPagent ↔ eszköz vagy adatforrás
  • HITLemberi jóváhagyás (human-in-the-loop)

Agent Card — névjegy

Minden agent közzéteszi, mit tud, és hogyan érhető el. Így a többiek fel tudják fedezni, és tudják, kinek adhatnak át egy feladatot.

Feladat-átadás

Az agentek állapottal és eredménnyel adnak át feladatot egymásnak — gyártótól és keretrendszertől függetlenül.

MCP — eszközök és adatok

Az A2A az agentek közötti, az MCP (Model Context Protocol) az agent és az eszközök — ERP, adatbázis, fájlok — közötti kapcsolatot szabványosítja. A kettő kiegészíti egymást.

Mielőtt agent-rendszert építene

Szűk, egyértelmű szerepek

Minden agentnek egy jól körülhatárolt felelőssége van. A „mindenes” agent nehezen tesztelhető és drága.

Legkisebb jogosultság

Egy agent csak azokat az eszközöket és adatokat éri el, amelyek a feladatához kellenek — saját azonosítóval.

A teljes lánc naplózása

Minden üzenet, eszközhívás és döntés visszakövethető. Hibánál így percek alatt kiderül, hol csúszott el a folyamat.

Költségkorlát agentenként

Token- és költségkeret, riasztással. A több lépéses agentek kontroll nélkül gyorsan égetik a tokent.

Mikor NE építsen agent-rendszert? Ha a folyamat egy rendszeren belül, fix lépésekben fut, az agentek csak bonyolítanak — egy szabály vagy egy RPA-robot olcsóbb és megbízhatóbb. Ismerje meg az AI agenteket →

Útiterv

Az első kérdéstől a működő rendszerig

Kicsiben kezdünk, mérünk, és csak a bevált megoldást skálázzuk. Minden fázis végén kézzelfogható eredmény és döntési pont van.

01 /

Felmérés

Folyamatok, adatok, rendszerek és biztonság áttekintése a fenti kérdések mentén; prioritási lista a várható megtérülés szerint.

2–4 hét
02 /

Alapozás

Folyamat-rendbetétel, adattisztítás, jogosultságok és AI-szabályzat — ami nélkül minden AI-projekt ingatag.

1–3 hónap
03 /

Pilot

Egy kiválasztott folyamat, mérhető céllal és valós felhasználókkal. Itt dől el — mérés alapján — a felhő vagy lokális kérdés is.

4–8 hét
04 /

Bevezetés

Integráció a meglévő rendszerekbe, képzés, valamint a felügyelet és a naplózás beállítása.

1–3 hónap
05 /

Skálázás

A bevált megoldás kiterjesztése további folyamatokra — ahol indokolt, együttműködő agent-rendszerré.

folyamatos

Az átállás pályázati forrásból is finanszírozható lehet: több digitalizációs kiírás támogat AI- és szoftverfejlesztést. Aktuális pályázatok →

Gyakori kérdések

Amit az AI-átállásról kérdezni szoktak

Magáncélú, ingyenes fiókkal nem javasolt: nincs adatfeldolgozói szerződés, és nem látható, hová kerül az adat. Üzleti előfizetéssel, EU-s adatkezeléssel és belső szabályzattal viszont biztonságosan használható — ezt a felmérés során rendezzük.
Költség szempontjából a legtöbb KKV-nál a felhő az olcsóbb, mert csak a tényleges használatért kell fizetni. Lokális modell akkor indokolt, ha érzékeny adatokkal dolgozik, offline működés kell, vagy nagy és egyenletes a terhelés. Gyakori a hibrid felállás.
A felmérés néhány hetes, fix díjas munka; a pilot költsége a kiválasztott folyamattól függ. A futási költség felhős modellnél sokszor havi néhány ezer forint — ahogy a kalkulátor is mutatja, a nagyobb tétel jellemzően az integráció és a bevezetés. Pontos számot a felmérés után adunk.
Nem. A legtöbb KKV-megoldás kész modellekre épül; a kulcs a folyamat- és adatismeret, amit a munkatársai hoznak. Kell viszont egy belső felelős, aki a megoldás gazdája lesz.
Valószínűleg igen, de jellemzően enyhén. A legtöbb üzleti felhasználás alacsony kockázatú; ilyenkor főként az átláthatóság (például jelezni, ha valaki chatbottal beszél) és a munkatársak AI-jártassága az elvárás. Magas kockázatú területeken — például munkaerő-kiválasztásnál — szigorúbb szabályok vonatkoznak. A felmérés során ezt is besoroljuk.
A digitális transzformáció a tágabb kör: a folyamatok, az adatok, a rendszerek és a szervezet átalakítása. Az AI ennek egy eszköze — és csak akkor hoz eredményt, ha az alapok (digitális adat, rendezett folyamat, integrált rendszerek) megvannak.
Egy jól megválasztott pilot 4–8 hét alatt mérhető eredményt hoz. A teljes átállás folyamatos munka, de lépésenként, mindig mért eredménnyel haladunk.

Kezdjük egy beszélgetéssel

Az ingyenes első konzultáción átbeszéljük a fenti kérdéseket, és megmutatjuk, hol érdemes kezdeni — szabállyal, RPA-val vagy AI-jal, felhőben vagy helyben.

Kapcsolatfelvétel AI Agentek RPA Automatizáció