Ha már Google Workspace-re vagy Google Cloudra épül a működésed, a Gemini agent megér egy korlátozott pilotot. Egy működő saját agent-orchestrationt ne cserélj le a bejelentés alapján. Előbb hasonlítsd össze a két megoldást egy valódi, alacsony kockázatú munkafolyamaton.
A Google Cloud 2026. október 8-án jelentette be a Gemini agentet, amelyet univerzális munkahelyi agentként mutat be. A cég szerint az agent megtervezi a munkát, skilleket és eszközöket használ, üzleti rendszerekhez kapcsolódik, majd dokumentumban, postafiókban vagy fejlesztői környezetben adja át az eredményt. Modellt is választ a feladathoz, beépített költségkontrollt ígér, valamint vállalati biztonsági, adminisztrációs és felügyeleti funkciókat kínál.
A beszerzési döntés súlypontja ezzel megváltozik. A modellválasztás csökkentheti az egyetlen modellcsaládtól való függést, miközben a memória, a skillek, az agent-identitások és a jogosultságok a Google platformjára kerülnek. A pilotnak ezért a feladatminőség mellett a platformfüggést és a későbbi kilépés ráfordítását is fel kell mérnie.
Mit venne át a Gemini agent a saját orchestration-rétegtől?
A Gemini agent a feladat megtervezését, az eszköz- és modellválasztást, a több agent közötti munkamegosztást, valamint a hosszabb feladatok folytatását is átvenné.
Thomas Kurian, a Google Cloud vezérigazgatója a Google tajvani blogján, kínai nyelven közzétett előadáskivonatban úgy fogalmazott, hogy az agent egy felületen tud kérdéseket megválaszolni, feladatokat végrehajtani és kódot készíteni. Az összetett munkához subagenteket szervezhet, a feladat pedig a laptop bezárása után is folytatódhat a cloudban. A felsorolt hozzáférési csatornák között a Google Workspace alkalmazásai, a Microsoft 365, a Slack, a parancssor és a háttérben futó headless agent is szerepel.
Az agent jelenleg Gemini- és Claude-modellek közül választhat, később pedig más zárt és nyílt modelleket is támogathat. Ez lehetővé teheti, hogy az egyszerű feladatokhoz olcsóbb, az összetettekhez erősebb modellt rendelj.
A saját orchestration-réteg megtartása több műszaki feladatot hagy nálad, például a session-kezelést, a modellválasztást, a hibakezelést és a naplózást. Cserébe te döntöd el, hol tárolod az állapotot, hogyan cserélsz szolgáltatót, és melyik komponenshez milyen hozzáférést adsz. Az OpenAI menedzselt megoldásánál felmerülő hasonló döntést külön útmutató mutatja be.
Hol csökken, és hol nő a szállítói függés?
A Gemini agent csökkentheti a modellfüggést, de növelheti a Google platformjától való függést.
A modellválasztás önmagában nem teszi hordozhatóvá a rendszert. A tartós érték egy vállalati agentnél gyakran a skillekben, az eszközkapcsolatokban, a memóriában, a jogosultságokban és a korábbi futásokból kialakult kontextusban halmozódik fel. A Google négy memóriatípust, megosztható skilleket, tool registryt és saját Workspace-fiókkal rendelkező coworker agenteket ír le.
Kérdezd meg a Google-t, milyen formában exportálhatók a skillek, a memóriák és az agent-beállítások. Kilépési terv nélkül egy későbbi váltásnál újra kell írni az integrációkat, újra ki kell alakítani a jogosultságokat, és újra kell futtatni az eval-készletet.
A pilotban ezért azt is vizsgáld meg, hogyan vihető át egy skill, hogyan törölhető a memória, hogyan cserélhető le egy modell, és milyen adatok maradnak a szolgáltatásban a hozzáférés megszüntetése után.
Mely biztonsági és felügyeleti funkciókat tudod a pilotban tesztelni?
A pilotban közvetlenül tesztelhető az agent-identitás, a legkisebb szükséges jogosultság, az audit trail és a központi hálózati szabályok működése.
A Google szerint minden agent külön, kriptográfiailag hitelesített identitást kap. A szerepköralapú jogosultságokat a vállalati biztonsági rendszergazda hagyhatja jóvá, az audit trail pedig az agent saját identitásával rögzíti minden lépését. Az agentek elkülönített hálózati határral rendelkező Agent Sandboxban futnak, a forgalom pedig az Agent Gatewayen halad át. A gateway központilag érvényesítheti például azt a szabályt, hogy egy agent nem nyithat meg bizalmasnak jelölt dokumentumot.
Az elfogadási tesztben ezekhez kérj megfigyelhető bizonyítékot:
- Az agent megtagadja a tiltott dokumentum megnyitását.
- Egy jóvá nem hagyott eszközhívás nem fut le.
- Minden művelet megjelenik az audit trailben az agent saját identitásával.
- A rendszergazda egy helyen vissza tudja vonni az agent jogosultságát.
- A futás leállítható anélkül, hogy függőben maradt műveletet hajtana végre.
A termelékenységi állításokat kezeld másként. A bejelentés több ügyféleredményt felsorol, de nem ad egységes tesztkörnyezetet, kiindulási értéket vagy módszertant. Ezekből nem érdemes magyar üzleti tervhez megtérülést számolni.
Ha a Gemini agentet a saját agent-rendszereddel hasonlítanád össze, a vállalati AI platformok szolgáltatásunk segít megtervezni a pilotot, az integrációt és a kilépési utat. Vállalati AI platformok
Hogyan tervezd meg a pilot költségkeretét?
A pilot költségkerete akkor állítható össze, ha a Google megadja az árazást és a költségkontroll részletes működését.
A Google egy konkrét költségmechanizmust nevez meg: a BigQueryben elmentett riportlekérdezések újrafuttatása nem jelent további tokenköltséget. Ez egy szűk eset, a teljes agent-futás költségét nem mutatja meg.
Kérdezd meg, hogy a magyar jogi személyed milyen elérhetőségi státusszal, árral, adattárolási és adatmegőrzési feltételekkel kapja meg a szolgáltatást, és hol tárolják az identitást, a memóriát és a skill registryt. Ezeket szerződéses mellékletben kérd, majd a pilotban feladatonként mérd a teljes költséget. A mérésbe kerüljön bele a modellhasználat, az eszközhívás, az adatbázis-lekérdezés, a sikertelen ismétlés, az emberi javítás és az integráció üzemeltetése is.
A sikeres feladat költsége jobb döntési alap, mint a tokenár. Egy olcsó futás is drága lehet, ha sokat kell javítani rajta, vagy a helyi ERP-kapcsolat rendszeresen hibázik.
Mit kell összekötni egy magyar vállalati pilotban?
Egy magyar pilotban az integrációs kockázatot a saját ERP-, CRM- és dokumentumkezelő rendszereken kell felmérni.
A Google felsorolja többek között a Salesforce, ServiceNow, Jira, Confluence, Slack, Microsoft Office, Teams, Google Workspace, BigQuery, Databricks, Postgres és Snowflake kapcsolatát. A szolgáltatás MCP-szerverekhez is kapcsolódhat. Egy helyi fejlesztésű magyar ERP-hez vagy CRM-hez valószínűleg egyedi eszközre vagy MCP-szerverre lesz szükség.
Az ilyen kapcsolat a bevezetés kritikus része lehet. Először csak olvasási jogosultságot adj, és válassz egy visszafordítható munkafolyamatot, például rendszeres vezetői riport előkészítését. A feladat induljon jóváhagyott adatforrásból, készítsen ellenőrizhető dokumentumot, majd kérjen emberi jóváhagyást a küldés előtt.
A magyar nyelvű minőséget külön eval-készleten mérd. Kerüljenek bele belső rövidítések, magyar ékezetes nevek, magyar dátum- és összegformátumok, táblázatok, valamint a céged által használt szakmai kifejezések. Az MCP vállalati integrációs szerepét ez az útmutató mutatja be részletesebben.
Mikor indokolt a pilot, és mikor jobb kivárni?
A pilot akkor indokolt, ha a működésed már Google Workspace-re vagy Google Cloudra épül, van alacsony kockázatú folyamatod, és a beszerzési feltételeket írásban megkapod.
| Helyzet | Ésszerű döntés | Következő teszt |
|---|---|---|
| Google Workspace vagy Cloud, saját orchestration nélkül | Korlátozott pilot | Jogosultság, audit trail, magyar minőség, sikeres feladat költsége |
| Működő saját agent-orchestration | Összehasonlító pilot | Azonos feladatkészlet, azonos adat és azonos elfogadási feltételek |
| Microsoft 365-központú működés Google Cloud nélkül | Várj a platformváltással | Az identitás, a memória és az adatok tárolási helye |
| Helyi ERP vagy CRM kész connector nélkül | Először integrációs próba | Csak olvasási jogú MCP-kapcsolat vagy egyedi eszköz |
A Microsoft 365 használata önmagában nem zárja ki a Gemini agentet, mert a Google ezt hozzáférési csatornaként felsorolja. A platformváltás előtt a szerződés rögzítse, hol tárolják az identitást, a memóriát és a skill registryt. Ha Microsoft-központú a szervezeted, ne indíts platformváltást kizárólag a bejelentés alapján.
A döntés előtt futtasd végig ezt az ellenőrzőlistát:
- Határozd meg az egyetlen vizsgált munkafolyamatot és a tiltott műveleteket.
- Készíts reprezentatív magyar nyelvű eval-készletet valódi, anonimizált esetekből.
- Rögzítsd a jelenlegi folyamat idejét, javítási igényét és költségét.
- Teszteld az Agent Gateway szabályait, az agent-identitást és az audit trailt.
- Mérd a sikeres feladat költségét és az emberi javítás idejét.
- Próbáld ki a jogosultság visszavonását, a memória törlését és az adatexportot.
- Csak akkor tervezz váltást, ha a Gemini agent mérhető előnyt ad, és a kilépési feltételek elfogadhatók.