Vertex AI új néven: itt a Gemini Enterprise Agent Platform
Még az év első felében hallhattad a videómban, hogy miért jó a Google Cloud. Ebben a videóban röviden összefoglaltam a legfontosabb dolgokat. Említettem, hogy a Google, mint AI-first cég, már nagyon régen használ mesterséges intelligenciát a mindennapi működése során. Ennek ellenére, még mindig csak a harmadik „nagy” felhő-szolgáltató az AWS és az Azure mögött.
Már akkor is azt mondtam, hogy náluk az AI lehet az a pont, ahol van lehetőségük a kiugrásra és a felzárkózásra. Úgy tűnik, ők is így gondolják és most tettek efelé egy lépést.
Nem feltétlenül forradalmi dologra kell gondolni, inkább amolyan „rájöttünk, hogy hogyan kell pozícionálnunk magunkat” lépésre.
Aki régóta dolgozik cloud platformokkal, az már megszokhatta, hogy a nagy szolgáltatók időnként újracímkéznek egy-egy terméket, finomhangolják a portfóliót, aztán megy tovább az élet. Ami viszont 2026. április 22-én a Google Cloud Next konferencián történt, az ennél kicsivel több: a Google Cloud egyszerre nevezte át az egyik legismertebb AI-platformját valamint több adat- és analitikai termékét is, és közben egy új gondolkodásmódot is bevezetett.
Mi változott a néven?
A legfontosabb bejelentés: a Vertex AI Platform beleolvad egy nagyobb ernyőbe, aminek a neve Gemini Enterprise Agent Platform. A hivatalos közlés szerint ez a Vertex AI evolúciója, és mostantól minden Vertex AI szolgáltatás és új fejlesztés ezen a platformon keresztül érhető el, önálló szolgáltatásként nem.
Emellett a Data Analytics oldalon több termék is beszédesebb nevet kapott. A Dataplex Universal Catalog mostantól Knowledge Catalog. A BigLake új neve Lakehouse. A Dataproc mostantól Managed Service for Apache Spark. A Composer új neve Managed Service for Apache Airflow. A Looker Studio pedig Data Studio néven fut tovább.
Ez elsőre soknak tűnhet, de van egy jó hír: a nevek logikája egyszerűbb lett. A „Managed Service for Apache Spark” önmagában elárulja, hogy egy felügyelt Spark szolgáltatásról van szó. Nem kell kitalálnod, mit takar a „Dataproc” márkanév. Ez különösen segít azoknak, akik most ismerkednek a GCP világával, és eddig a saját termékneveket kellett bemagolniuk.
| Régi név | Új név | Mit takar? |
|---|---|---|
| Vertex AI Platform | Gemini Enterprise Agent Platform | A Google Cloud AI-platformja, mostantól agent-fókusszal: építés, skálázás, kormányzás, optimalizálás egy ernyő alatt |
| Dataplex Universal Catalog | Knowledge Catalog | Központi adatkatalógus és governance réteg, amely átláthatóvá teszi, hol milyen adat található és ki férhet hozzá |
| BigLake | Lakehouse | Egységes tárolási réteg a data lake és data warehouse világ között, nyílt formátumokkal |
| Dataproc | Managed Service for Apache Spark | Menedzselt Spark környezet nagy adatmennyiségek feldolgozásához, klaszterkezelés nélkül |
| Composer | Managed Service for Apache Airflow | Menedzselt Airflow szolgáltatás data pipeline-ok ütemezésére és orchestrálására |
| Looker Studio | Data Studio | Vizualizációs és riportkészítő eszköz dashboardokhoz és adatmegjelenítéshez |
Ebből a táblázatból kiolvasható, az egy tudatos iránymutatás a Google részéről. Az AI-platform nevében megjelenik a Gemini és az Agent szó, ami egyértelműen kijelöli, merre megy a termékstratégia. A Data Analytics oldalon pedig a saját márkanevek helyett leíró, iparági szabvány szerinti elnevezések kerültek előtérbe: Spark, Airflow, Lakehouse. Ez sokak számára hasznos, mert ezek a fogalmak más cloudokban és on-premise világban is ugyanezt jelentik.
Mi marad változatlan?
A Google Cloud kommunikációja ebben a kérdésben egyértelmű: a projektjeid, a konfigurációk és az árazás nem változik. A számlázásod ugyanúgy fut tovább, és a meglévő elmentett linkek automatikus átirányítással működnek a konzolon belül. Az SKU megjelenítési nevek és leírások ugyan frissülnek a következő hónapokban, de a Data Analytics SKU-k nevei változatlanok maradnak.
Ez fontos üzenet: Egy enterprise ügyfél számára a legnagyobb kockázat nem egy új név, hanem ha egy átnevezés mögött rejtett árváltozás vagy kényszerű migráció áll. Itt most nem ez a helyzet. Mégis azt tanácsolom, hogy ha céges környezetben dolgozol, érdemes átfésülni a belső dokumentációt, runbook-okat és oktatási anyagokat, mert a kollégák fél év múlva már az új neveken fogják keresni ezeket a szolgáltatásokat.
Miért Agent Platform?
A Gemini Enterprise Agent Platform neve nem véletlen. A Google Cloud hivatalos bejelentése szerint a platform négy fő képességre épül: Build, Scale, Govern és Optimize. Olyan komponensek tartoznak ide, mint az Agent Studio a low-code építéshez, az Agent Development Kit a kódalapú fejlesztéshez, az Agent Runtime a futtatáshoz, a Memory Bank a hosszú távú kontextushoz, valamint az Agent Identity, Agent Registry és Agent Gateway a kormányzáshoz.
Mit is jelentenek ezek?
- Build: az agentek felépítése, legyen szó low-code vizuális eszközről (Agent Studio) vagy kódalapú fejlesztésről (Agent Development Kit).
- Scale: az agentek futtatása éles környezetben, stabil teljesítménnyel, hosszú távú kontextussal és memóriakezeléssel (Agent Runtime, Memory Bank).
- Govern: az agentek felügyelete: minden agent saját azonosítót kap, központi regiszterbe kerül, és egységes biztonsági szabályok mentén működik (Agent Identity, Agent Registry, Agent Gateway).
- Optimize: az agentek viselkedésének mérése és finomhangolása éles forgalom alapján, tesztekkel, megfigyelhetőséggel és automatikus javaslatokkal (Agent Simulation, Agent Evaluation, Agent Observability).
Hogy ez mit jelent a gyakorlatban, arra mondok egy egyszerű példát:
Képzelj el egy biztosítót, amelynél egy AI-agent fogadja az ügyféligényeket, lekérdezi a belső rendszereket, majd ha kell, átad egy másik agentnek, aki a kárrendezést indítja el. Eddig ehhez sok külön eszközt kellett összedrótozni.
Az Agent Platform ígérete az, hogy ezek egy közös platformon, egységes identitással, auditálhatóan és biztonsági kontrollokkal futnak. Azt, hogy ez a gyakorlatban minden környezetben problémamentesen működik-e, még nem tudom biztosan, de a koncepció iránya egyértelmű: az egyedi AI-feladatoktól haladni egy kormányzott agent-ökoszisztéma felé.
Hogyan illeszkedik ez a többi cloudhoz?
Érdemes megnézni, mit csinálnak a nagy versenytársak. Az AWS-nél a Bedrock és az Amazon Q köré épül az agentek világa, az Azure-nál pedig az Azure AI Foundry és a Microsoft Copilot Studio vonal adja a hasonló irányt. Mindhárom szereplő ugyanabba az irányba megy: nem elég egy jó modell, szükség van futtatókörnyezetre, identitáskezelésre, megfigyelhetőségre és governance-re.
Ez karriertervezés szempontjából is fontos jelzés. Ha most lépsz be a cloud vagy AI világába, ne csak a modellekkel és a prompttal foglalkozz. Sokkal értékesebb tudás, ha érted, hogyan kell egy agentet biztonságosan integrálni egy vállalati környezetbe, hogyan figyeli a csapat a működését, és hogyan kontrollálja a költségeit.
Hasznos tippek a folytatáshoz
Ahogy a hagyományos cloud workloadok esetén, az AI-agenteknél is ugyanazok a hibák jönnek elő, amelyeket sok cégnél elrontanak. Az első klasszikus csapda a tervezés nélküli használat: valaki elindít egy agentet teszteléshez, aztán elfelejti leállítani, és hónapokig fut a háttérben. Ez ugyanaz a történet, mint amikor egy fejlesztői VM-et nem állítanak le éjszakára, és a hónap végén megérkezik a meglepetés a számlán.
A második ilyen a governance hiánya. Ha bárki szabadon hozhat létre agenteket, saját jogosultságokkal, saját eszközökkel, akkor hamar ott állsz egy átláthatatlan ökoszisztéma közepén. Pontosan ezért emeli ki a Google az Agent Identity és az Agent Registry szerepét: minden agentnek legyen azonosítója, és legyen egy központi hely, ahol látható, mi fut, milyen jogosultsággal.
A harmadik terület a biztonsági alapok kihagyása. A legtöbb startup jellegű projektben érthetően először az a cél, hogy egyáltalán működjön valami. Ez rendben is van, a simplicity elv szerint először legyen egy működő megoldás. De még mielőtt élesbe kerülne, érdemes átgondolni a legalapvetőbb kérdéseket: milyen adatokhoz fér hozzá az agent, ki láthatja a logokat, és mi történik hiba esetén.
Záró gondolatok
Három gondolatot szeretnék ezzel átadni neked. Az első: ne memorizálj szolgáltatásneveket, inkább értsd meg a mögöttes fogalmakat és összefüggéseket. Egy felügyelt Spark szolgáltatás az AWS-en EMR, a Google Cloud-on Managed Service for Apache Spark, és az Azure-on Synapse vagy Fabric környezetben találsz hasonlót. A fogalom ugyanaz, a csomagolás más. (Erről hamarosan majd közzé is teszek egy interaktív szótárat.)
A második: a költségtudatosság sosem megy ki a divatból. Minden új agent, minden új adatpipeline pénzbe kerül, és a leggyakoribb hiba, hogy ezt csak utólag vesszük észre. Váljon szokásoddá, hogy minden erőforráshoz hozzágondolod a kérdést: mit kapcsoljak ki, ha nem használom?
A harmadik: a jövőállóság nem jóslás, hanem kíváncsiság. Nem tudjuk pontosan, merre megy a piac öt év múlva, de azt látjuk, hogy az agent-alapú világ egyre több felületen jelenik meg. Aki most megérti a governance, az identity és az observability szerepét, az bármelyik platformon könnyen átül.
Habár a név megváltozott, de a tanulság a régi:
a Cloud-ban és az AI-ban nem feltétlenül az nyer, aki a leggyorsabban vág bele, hanem aki tudatosan építkezik.
