AI agent vállalkozásban ma már nem „kísérlet”: ügyfélszolgálatot automatizál, ajánlatot ír, riportot készít, sőt rendszerek között intézkedik (például jegyet nyit, számlát előkészít, CRM-ben státuszt vált). A gond ott kezdődik, hogy a demóban minden működik, élesben viszont előjönnek a kérdések: ki felel, ha hibázik? milyen adatot küldesz át? mennyibe kerül valójában a skálázás? és kihez vagy bezárva két hónap múlva?
Most különösen fontos ezt jól megfogni, mert a nagy platformok (OpenAI, Anthropic/Claude, Google/Gemini, valamint vállalati csomagok, például Azure OpenAI) egyre több „agent” képességet adnak: eszközhasználatot, külső rendszerek hívását, hosszabb távú feladatvégzést, naplózást és admin kontrollokat. A Microsoft Azure OpenAI szolgáltatói információi (lásd: oai.azure.com) is azt sugallják: vállalati környezetben a biztonság, megfelelés és irányítás legalább akkora téma, mint a modell „okossága”. Magyar vállalkozóként neked az a célod, hogy a szerződésben is meglegyen az a kontroll, amit a sales híváson ígértek.
1) Költség: mit fizetsz valójában egy AI agentért?
Az AI agent költsége ritkán egyetlen sor a díjtáblázatban. Jellemzően több rétegből áll, és ha ezt nem bontod szét, könnyen alulárazod a projektet.
1. kérdés: Mi a teljes költségmodell (token, hívás, eszközhasználat, tárolás, hálózat)?
Tipikus költségelemek:
- Modellhasználat (token alapú díj, esetleg csomag/kvóta).
- Eszközhasználat (pl. keresés, fájlkezelés, kódfuttatás jellegű funkciók, ha a platform külön számolja).
- RAG / tudásbázis: vektortár, indexelés, tárhely, lekérdezés.
- Naplózás és megfigyelhetőség (logok, trace-ek, audit naplók tárolása).
- Integrációk (middleware, iPaaS, API gateway, hitelesítés).
- Emberi felülvizsgálat (ha kötelező „human-in-the-loop”, annak munkaideje).
Tárgyalási tipp: kérj egy 3 szcenáriós költségbecslést: (1) pilot, (2) normál üzem, (3) csúcsidő/marketing kampány. A szerződésben rögzítsétek, hogy milyen metrikák alapján számolnak, és milyen gyakran kapsz költség-riportot.
2. kérdés: Van-e költségplafon, kvóta, riasztás és automatikus leállítás?
Egy agent képes „elszaladni”: túl sok körben gondolkodik, túl sok eszközt hív, vagy egy hibás integráció miatt végtelen ciklusba kerül. Ez nem elmélet, hanem tipikus üzemeltetési kockázat.
Mit kérj: költségkeret, kvóta, rate limit, riasztás (e-mail/Slack), és vészleállító („kill switch”) opció. Ez nem csak pénzvédelem, hanem incidens-kezelési alap is.
3. kérdés: Mi számít „termelési” használatnak, és mennyi a minimum vállalás?
Nézd meg a minimum díjakat, commitokat, felhasználói licencet, környezetek számát (dev/test/prod), és hogy a pilot után milyen árazás lép életbe. Ha ügynökség vagy fejlesztő partner építi, tisztázd: a platform-előfizetés a te neveden fut-e, vagy a partnerén (ez később vendor lock-in kockázat).
2) Felelősség: ki viszi el a balhét, ha az agent hibázik?
Az „agent” szó üzletileg azt jelenti: a rendszer cselekszik. Ha cselekszik, hibázhat. Ha hibázhat, akkor a felelősséget előre le kell osztani.
4. kérdés: Ki a felelős a döntésekért és a kárért (limitációk, kártérítési plafon)?
A szolgáltatók szerződéseiben gyakori a felelősségkorlátozás. Neked viszont az a kérdés, hogy a saját ügyfeleid felé mit vállalsz. Ha az agent például rossz árat ír ajánlatba, vagy tévesen töröl egy rekordot, abból lehet közvetlen károd.
Mit tisztázz:
- Kártérítési plafon (pl. éves díj többszöröse vs. minimális összeg).
- Kizárások (közvetett kár, elmaradt haszon).
- Incidens felelőse: ki vizsgál, ki kommunikál, ki fizet.
Magyar kontextus: ha személyes adat érintett, és adatvédelmi incidens történik, a te céged (adatkezelőként) nem tudja „átpasszolni” az összes felelősséget. Erről érdemes adatvédelmi szakértővel és könyvelővel/jogásszal is egyeztetni.
5. kérdés: Milyen „biztonsági kontrollok” vannak az agent eszközhasználatára?
Az agent tipikusan API-kon keresztül fér hozzá CRM-hez, e-mailhez, naptárhoz, fájlokhoz, számlázóhoz. A kulcs: legkisebb jogosultság elve és jóváhagyási pontok.
Kérdezd meg konkrétan:
- Lehet-e csak olvasási módot adni bizonyos rendszerekhez?
- Van-e jóváhagyás-kérés (pl. „küldhetem ezt az e-mailt?”) bizonyos műveletek előtt?
- Van-e szabálymotor, amivel tiltod a műveleteket (pl. „ne utalj”, „ne törölj”, „ne módosíts árlistát”)?
- Kezeli-e a rendszer a titkokat (API kulcsok) biztonságosan (vault, rotáció)?
Ha a válaszok ködösek, az intő jel: lehet, hogy a megoldás inkább demo-barát, mint vállalati.
3) Adatkezelés: GDPR és AI a szerződésben, nem a slide-on
Az AI agent akkor hasznos, ha adathoz fér. Pont ezért kell tisztázni, hogy ki a szereplő adatvédelmi értelemben, hol mennek az adatok, és mi történik velük.
6. kérdés: Ki az adatkezelő és ki az adatfeldolgozó? Van adatfeldolgozói szerződés?
A legtöbb esetben te vagy az adatkezelő (te döntöd el a célokat), a platform/szolgáltató pedig adatfeldolgozó vagy al-adatfeldolgozó. Ehhez kell adatfeldolgozói szerződés (DPA), amiben szerepel:
- az adatkezelés tárgya, időtartama, jellege, célja,
- az adatkategóriák és érintetti körök,
- a technikai és szervezési intézkedések,
- alvállalkozók (al-adatfeldolgozók) listája és változáskezelése,
- incidens-bejelentési határidők és együttműködés.
Tárgyalási tipp: ne elégedj meg azzal, hogy „van DPA”. Kérd el, olvasd el, és nézd meg, illeszkedik-e a te folyamataidhoz (például 72 órás incidens-ablak, érintetti kérelmek kezelése).
7. kérdés: Hol történik az adatfeldolgozás, és van-e adattovábbítás az EU-n kívülre?
GDPR szempontból kritikus, hogy az adatok fizikailag és jogilag hol mozognak. Vállalati platformoknál (például Azure OpenAI esetén) jellemzően régióválasztásról, vállalati kontrollokról és megfelelőségi keretekről kommunikálnak a szolgáltatói oldalon (lásd: oai.azure.com). Neked viszont a szerződésben kell tisztán látni:
- Melyik régióban fut a szolgáltatás?
- Van-e távoli hozzáférés (support, üzemeltetés) más országokból?
- Alkalmaznak-e standard szerződési feltételeket (SCC), ha van EU-n kívüli adattovábbítás?
Ha érzékeny adatot kezelsz (egészségügy, pénzügy, HR), itt ne engedj a „majd később” válasznak.
8. kérdés: Tanítják-e a modellt a te adataiddal? Mi az alapértelmezés?
Az egyik legfontosabb, üzletileg is érzékeny kérdés: a beszélgetések, fájlok, promptok felhasználhatók-e modellfejlesztésre. Sok vállalati ajánlatnál az ígéret az, hogy nem (vagy csak külön opt-in esetén), de ezt neked írásban kell látni.
Kérj egyértelmű választ:
- Használják-e a te adataidat tanításra vagy termékfejlesztésre?
- Mennyi ideig őrzik a logokat és a kéréseket/válaszokat?
- Kérhető-e rövidebb megőrzés vagy teljes tiltás?
Ez nem csak GDPR, hanem üzleti titok kérdés is (árazás, ügyféllista, szerződésrészletek).
4) Auditálhatóság és működtetés: tudod-e bizonyítani, mi történt?
Ha az agent döntéseket hoz és műveleteket végez, előbb-utóbb lesz vitás eset: ügyfél reklamál, belső ellenőrzés kérdez, vagy egy kolléga azt mondja: „én ezt nem hagytam jóvá”. Ilyenkor az számít, mennyire auditálható a rendszer.
9. kérdés: Milyen naplózás, visszakereshetőség és riportolás van?
Minimum elvárás vállalati környezetben:
- Prompt és válasz napló (megfelelő maszkolással).
- Eszközhívások naplója (melyik API-t hívta, milyen paraméterekkel).
- Felhasználói azonosítás (ki indította a folyamatot, milyen jogosultsággal).
- Verziózás (melyik modell, melyik rendszerprompt, melyik workflow verzió futott).
Tárgyalási tipp: kérj mintát egy „incidens riportból”: mit tudnak visszaadni 30 nap múlva egy konkrét agent-futásról. Ha erre nincs jó válasz, az auditálhatóság gyenge.
10. kérdés: Mi a vendor lock-in kockázata, és hogyan jössz ki belőle?
A vendor lock-in nem csak azt jelenti, hogy „drágán váltasz”. Azt is jelenti, hogy a tudásbázisod, workflow-id, értékelési adataid és naplóid olyan formátumban vannak, amit nem tudsz átvinni.
Konkrét kérdések:
- Kié a workflow definíció és exportálható-e (JSON/YAML, dokumentált formátum)?
- Exportálható-e a tudásbázis (forrásfájlok, indexek, embeddingek)?
- Megkapod-e a tesztkészleteket, értékelési eredményeket, minőségi metrikákat?
- Mi a kilépés folyamata: adatok törlése, igazolás, határidők?
Ha a szolgáltató vagy integrátor azt mondja, hogy „ez nem exportálható”, akkor kezeld úgy, mintha egy többéves elköteleződést írnál alá.
Praktikus tippek / Következő lépések: tárgyalási checklist, amit holnap bevihetsz
Ha most készülsz AI agent bevezetésre, ezt a sorrendet javaslom, hogy ne a hype diktáljon, hanem a kockázatkezelés.
1) Írd le az agent „munkaköri leírását” egy oldalban
Mit csinál pontosan, milyen rendszerekhez fér hozzá, milyen adatokat lát, és mi a tiltott művelet. Ez lesz a szerződés és a belső szabályzat alapja.
2) Készíts RACI-t: ki felel, ki hagy jóvá, ki értesül
Legalább ezekre legyen válasz: incidens, hibás válasz, adatvédelmi kérés (törlés/hozzáférés), költségriasztás, modellfrissítés.
3) Kérj „vállalati csomag” jellegű dokumentumokat még a pilot előtt
Ne a végén derüljön ki, hogy a DPA, a régióválasztás vagy a naplózás csak drágább csomagban érhető el. A szolgáltatói információkat (például Azure OpenAI esetén a hivatalos oldalon) kezeld kiindulópontként, de a te szerződésed legyen a döntő.
4) Állíts fel minőségi és biztonsági kapukat
- Minőség: tesztkészlet, elfogadási kritériumok, rendszeres újramérés.
- Biztonság: jogosultságok, jóváhagyás, titokkezelés, riasztások.
- Adatvédelem: adatminimalizálás, maszkolás, megőrzési idők.
5) Tedd bele a szerződésbe a „változáskezelést”
Modellek frissülnek, platformok változnak. Rögzítsétek: hogyan értesítenek, mi a visszagörgetés lehetősége, és mi számít szerződésszegésnek (például régióváltás vagy al-adatfeldolgozó csere előzetes értesítés nélkül).
Gyakran Ismételt Kérdések
Mi a különbség egy chatbot és egy AI agent között vállalkozásban?
Egy chatbot jellemzően válaszol. Egy AI agent viszont feladatot hajt végre: eszközöket hív, rendszerekben műveleteket végez, és több lépésben eljut egy célhoz. Emiatt nagyobb az üzleti érték, de a felelősségi, adatkezelési és auditálhatósági elvárás is.
Elég, ha a szolgáltató azt mondja, hogy „GDPR-kompatibilis”?
Nem. A „GDPR-kompatibilis” állítás önmagában marketingmondat. Neked konkrétan DPA-ra (adatfeldolgozói szerződésre), adattovábbítási feltételekre, megőrzési időkre, al-adatfeldolgozói listára és incidenskezelési vállalásokra van szükséged, írásban.
Mit jelent az auditálhatóság AI agenteknél?
Azt, hogy utólag bizonyítani tudod: ki indította a folyamatot, milyen adatokkal dolgozott, milyen eszközöket hívott, milyen döntési lépései voltak, és mi lett az eredmény. Ez kulcs vitás eseteknél, belső kontrollnál és adatvédelmi incidenseknél.
Hogyan csökkentsd a vendor lock-in kockázatát?
Úgy, hogy már a szerződésben rögzíted az exportálhatóságot (workflow, tudásbázis, logok, teszteredmények), a kilépési folyamatot (törlés és igazolás), és lehetőleg nyíltabb, dokumentált interfészeket használsz. Emellett a kritikus üzleti logikát ne csak a platform „varázslóiban” tartsd, hanem legyen saját dokumentációd is.
Mikor érdemes könyvelővel vagy jogásszal egyeztetni?
Ha személyes adatot érint az agent (ügyféladat, HR), ha pénzügyi művelet közelébe kerül (számlázás, utalás előkészítés), vagy ha az agent külső ügyfelek felé kommunikál. Ilyenkor a felelősség, a szerződéses feltételek és az adatkezelés részletei üzleti kockázatot jelentenek, amit érdemes szakértővel validálni.
Zárás: így menj be a következő tárgyalásra
Ha AI agentet vezetsz be, ne a „melyik modell a jobb” legyen az első kérdésed, hanem az, hogy mennyibe kerül skálázva, ki felel a hibákért, és hogyan kezeled a GDPR és AI metszetét a gyakorlatban. A 10 kérdésből csinálj egy belső checklistet, és csak akkor mondj igent, ha mindegyikre kapsz írásos, ellenőrizhető választ.
CTA: Ha szeretnéd, írd meg, milyen folyamathoz (ügyfélszolgálat, sales, HR, pénzügy, riporting) tervezel AI agentet, és milyen platformon (OpenAI/Claude/Gemini/Azure OpenAI). Összerakok neked egy személyre szabott tárgyalási kérdéssort és egy minimum szerződéses elváráslistát, amit be tudsz vinni a szolgáltatóhoz.
