Krótka odpowiedź
Google zmienia nazewnictwo Vertex AI. Zgodnie z oficjalną mapą zmian Vertex AI Platform staje się Gemini Enterprise Agent Platform, a skrócona nazwa Vertex AI jest zastępowana przez Agent Platform. Zmiana obejmuje też nazwy wielu komponentów: Vertex AI Studio staje się Agent Studio, Vertex AI API - Gemini Enterprise Agent Platform API, a Vertex AI Search - Agent Search.
Dla firmy nie jest to jednak tylko pytanie o nowe nazwy w prezentacji. Rebranding pokazuje zmianę kierunku platformy: od środowiska kojarzonego głównie z modelami, uczeniem maszynowym i generatywną AI do warstwy służącej budowaniu, uruchamianiu oraz kontrolowaniu całych ekosystemów agentów.
To istotna różnica. Model generuje odpowiedź. Agent może korzystać z pamięci, wyszukiwać dane, wywoływać narzędzia i wykonywać działania w systemach. Wraz z taką autonomią rośnie znaczenie tożsamości, uprawnień, audytu, testów i możliwości zatrzymania procesu.
Zmiana nazwy nie oznacza automatycznie, że każdą istniejącą aplikację Vertex AI trzeba przepisać. Oznacza natomiast, że organizacja powinna sprawdzić, czy jej dotychczasowa architektura jest gotowa na przejście od pojedynczych wywołań modelu do agentów działających w wielu systemach.
Co dokładnie zmienia nazwę
Google opublikował oficjalną tabelę zmian nazw. Jest ona szczególnie ważna w okresie przejściowym, ponieważ stare nazwy mogą nadal występować w konsoli, kodzie, adresach API, materiałach szkoleniowych i dokumentacji starszych wersji.
| Poprzednia nazwa | Nowa nazwa |
|---|---|
| Vertex AI Platform | Gemini Enterprise Agent Platform |
| Vertex AI | Agent Platform |
| Generative AI on Vertex AI | Generative AI on Gemini Enterprise Agent Platform |
| Vertex AI Studio | Agent Studio |
| Vertex AI API | Gemini Enterprise Agent Platform API |
| Vertex AI Model Garden | Gemini Enterprise Agent Platform Model Garden |
| Vertex AI Search | Agent Search |
| Vertex AI Vector Search | Vector Search on Gemini Enterprise Agent Platform |
| Vertex AI Model Evaluation | Gemini Enterprise Agent Platform Evals |
| Vertex AI Pipelines | Gemini Enterprise Agent Platform Pipelines |
Nie wszystkie nazwy muszą zmienić się w tym samym momencie we wszystkich miejscach. W praktyce zespoły mogą przez pewien czas widzieć nową nazwę w dokumentacji i starą w interfejsie albo identyfikatorze technicznym. To normalne dla dużej platformy chmurowej, ale wymaga dyscypliny w dokumentacji projektowej.
Wewnętrzne instrukcje powinny przez okres przejściowy zawierać obie nazwy. Zamiast pisać wyłącznie „Agent Search”, warto dodać „wcześniej Vertex AI Search”. Ułatwia to obsługę, wyszukiwanie błędów i komunikację z dostawcami.
Rebranding czy realna zmiana produktu
Google określa Gemini Enterprise Agent Platform jako ewolucję Vertex AI. W ogłoszeniu platformy firma wskazuje, że dotychczasowe możliwości dotyczące modeli i tworzenia aplikacji są łączone z nowymi funkcjami integracji agentów, orkiestracji, DevOps oraz bezpieczeństwa.
Nowa narracja jest zorganizowana wokół czterech obszarów:
- Build - projektowanie agentów w Agent Studio albo kodzie z użyciem Agent Development Kit.
- Scale - uruchamianie agentów w zarządzanym środowisku, obsługa sesji, pamięci i długotrwałych zadań.
- Govern - rejestr agentów, ich tożsamość, kontrola wywołań narzędzi i polityki bezpieczeństwa.
- Optimize - ewaluacja, symulacje, tracing, monitoring i poprawianie instrukcji agentów.
To nie znaczy, że każda firma powinna teraz budować autonomiczne zespoły agentów. Oznacza, że Google przygotowuje jedną platformę dla pełnego cyklu: od testu modelu do zarządzania agentami działającymi w środowisku organizacji.
Warto potraktować zmianę nazwy jako okazję do przeglądu architektury, a nie jako powód do natychmiastowej migracji.
Trzy warstwy, których nie należy mylić
W materiałach marketingowych nazwy Gemini, Gemini Enterprise i Agent Platform pojawiają się blisko siebie. Pełnią jednak różne funkcje.
Modele Gemini
Gemini to rodzina modeli zapewniających zdolności językowe, multimodalne i rozumowanie. Model jest jednym z komponentów rozwiązania. Nie zarządza samodzielnie rolami użytkowników, procesem biznesowym, odpowiedzialnością ani integracjami.
Agent Platform nie ogranicza się wyłącznie do Gemini. Model Garden udostępnia modele Google, wybrane modele innych dostawców i modele otwarte. Trzeba jednak osobno sprawdzić dostępność modelu w regionie, metody wdrożenia, funkcje, warunki i koszty.
Gemini Enterprise Agent Platform
To warstwa dla zespołów technicznych. Służy do budowania, wdrażania, zabezpieczania i monitorowania agentów oraz rozwiązań opartych na modelach. Obejmuje środowiska low-code i code-first, runtime, RAG, zarządzanie modelami, ewaluację oraz mechanizmy governance.
Aplikacja Gemini Enterprise
To warstwa dla użytkowników organizacji. Ma być miejscem, w którym pracownicy odkrywają, uruchamiają i wykorzystują agentów zatwierdzonych przez firmę. Agent może zostać zbudowany w Agent Platform, ale udostępniony użytkownikowi przez aplikację Gemini Enterprise albo własny interfejs firmy.
Rozdzielenie tych warstw zapobiega częstemu błędowi: zakup dostępu do modelu albo aplikacji dla pracowników nie oznacza jeszcze posiadania kompletnej platformy do wytwarzania i kontrolowania agentów.
Czy istniejące wdrożenie Vertex AI wymaga migracji
Sama zmiana nazwy nie jest wystarczającym powodem do przebudowy działającego systemu. Migracja jest uzasadniona, gdy Google wycofuje konkretną usługę, wersję modelu, SDK lub endpoint albo gdy organizacja chce świadomie skorzystać z nowych funkcji.
Przegląd istniejącego rozwiązania powinien objąć:
| Obszar | Co trzeba sprawdzić |
|---|---|
| API i SDK | Używane wersje, komunikaty o wycofaniu, nowe biblioteki i zgodność endpointów |
| Modele | Nazwy modeli, daty zakończenia wsparcia, regiony i limity |
| IAM | Role, konta usługowe, uprawnienia użytkowników i agentów |
| Dane | Lokalizację przechowywania, miejsce przetwarzania i retencję |
| RAG | Indeksy, embeddingi, parsery dokumentów, reranking i źródła |
| Monitoring | Logi, tracing, alerty, mierniki jakości i kosztów |
| Automatyzacja wdrożeń | Terraform, pipeline CI/CD, zmienne środowiskowe i polityki organizacji |
| Dokumentacja | Stare i nowe nazwy, właściciele, instrukcje oraz procedury incydentowe |
Najpierw należy stworzyć inwentaryzację. Dopiero później podejmować decyzję o zmianie. Aktualizacja nazw w dokumentacji może być potrzebna od razu, podczas gdy kod może działać bez zmian jeszcze przez długi czas.
Nie warto też łączyć rebrandingu z nieplanowaną zmianą architektury. Jednoczesna wymiana SDK, modelu, bazy wektorowej i sposobu uwierzytelniania utrudnia ustalenie przyczyny błędów. Bezpieczniej rozdzielić zmiany i testować je etapami.
Od wywołania modelu do agenta wykonującego pracę
W prostej aplikacji przepływ wygląda następująco: użytkownik wysyła pytanie, aplikacja dodaje instrukcję i kontekst, model generuje odpowiedź, a człowiek ją wykorzystuje.
Agent działa inaczej. Może:
- rozpoznać zamiar użytkownika;
- wybrać źródło wiedzy;
- pobrać dane z CRM, ERP lub hurtowni;
- wywołać narzędzie lub innego agenta;
- zapamiętać kontekst między sesjami;
- podjąć kilka kroków bez dodatkowej instrukcji;
- zatrzymać proces i poprosić człowieka o decyzję;
- wykonać działanie w systemie.
Z technicznego punktu widzenia agent staje się nowym aktorem systemu. Potrzebuje tożsamości i uprawnień tak samo jak użytkownik albo usługa. Z biznesowego punktu widzenia trzeba określić granice jego odpowiedzialności.
Jeżeli agent może pobrać fakturę, utworzyć klienta i wysłać wiadomość, nie powinien automatycznie otrzymywać pełnych praw administracyjnych. Każde narzędzie powinno mieć wąski zakres, walidację danych, limity i czytelny ślad audytowy.
Tożsamość agenta jest ważniejsza niż sam prompt
Prompt opisuje zachowanie, ale nie jest mechanizmem bezpieczeństwa. Instrukcję można źle zinterpretować, wejście może zawierać próbę manipulacji, a model może wybrać niewłaściwe narzędzie.
Agent Platform rozwija mechanizmy, które mają rozdzielać logikę od dostępu. Agent Identity nadaje agentowi odrębną, kryptograficznie potwierdzoną tożsamość i integruje ją z IAM, VPC Service Controls oraz logami audytowymi. Agent może działać we własnym imieniu albo - w odpowiednim modelu uwierzytelnienia - w imieniu użytkownika.
W praktyce projekt powinien odpowiedzieć na kilka pytań:
- Czy agent działa jako osobna usługa, czy reprezentuje konkretnego użytkownika?
- Jakie zasoby może odczytywać, a jakie modyfikować?
- Czy uprawnienie jest stałe, czy nadawane na czas działania?
- Czy użytkownik widzi planowaną operację przed zatwierdzeniem?
- Czy log wskazuje agenta, użytkownika i wykonane narzędzie?
- Jak cofnąć dostęp bez zatrzymywania całej aplikacji?
Bez takich odpowiedzi agent pozostaje efektownym demo, ale nie jest gotowy do bezpiecznej pracy w organizacji.
Dane i region muszą być decyzją architektoniczną
W projektach AI często pojawia się zdanie „dane są w Europie”. Jest zbyt ogólne. Trzeba osobno ustalić miejsce przechowywania danych i miejsce wykonywania obliczeń modelu.
Dokumentacja rezydencji danych Agent Platform rozróżnia dane w spoczynku od przetwarzania ML. Endpointy regionalne lub unijne mogą zapewniać określone granice przetwarzania, natomiast endpoint globalny nie daje regionalnej izolacji. Jednocześnie dostępność modeli i funkcji różni się między lokalizacjami.
Decyzja o regionie powinna więc powstać przed wyborem modelu. W przeciwnym razie zespół może zbudować pilota na funkcji niedostępnej w docelowej lokalizacji albo wymagającej innego sposobu przetwarzania.
Macierz decyzji powinna zawierać przynajmniej:
- klasy danych i właścicieli;
- wymagane miejsce przechowywania;
- wymagane miejsce inferencji i innych operacji ML;
- dostępność modelu, RAG, pamięci i wykonania kodu;
- zasady szyfrowania i zarządzania kluczami;
- transfery między regionami oraz systemami zewnętrznymi;
- retencję promptów, odpowiedzi, dokumentów i logów.
Zgodność nie wynika z samego wyboru europejskiego regionu. Jest efektem całej architektury, dostępu i sposobu użycia danych.
Co platforma zapewnia, a czego nie zrobi za firmę
Agent Platform może dostarczyć runtime, katalog agentów, tożsamość, zabezpieczenia wywołań narzędzi, tracing i mechanizmy ewaluacji. To wartościowe elementy, szczególnie gdy liczba agentów zaczyna rosnąć.
Platforma nie:
- wybierze za firmę procesu, który warto automatyzować;
- uporządkuje sprzecznych dokumentów i danych;
- ustali odpowiedzialności między działami;
- zdefiniuje poprawnej decyzji biznesowej;
- zagwarantuje jakości odpowiedzi po zmianie modelu;
- zdecyduje, kiedy potrzebna jest kontrola człowieka;
- policzy rzeczywistego zwrotu z inwestycji.
Największym ryzykiem nie jest brak funkcji technicznej. Jest nim zbudowanie rozbudowanego środowiska bez procesu, właściciela i miernika efektu.
Kiedy Gemini Enterprise Agent Platform ma sens
Pełna platforma jest dobrym kandydatem, gdy:
- organizacja ma istotne dane i systemy w Google Cloud;
- rozwija kilka agentów lub planuje wspólne standardy dla wielu zespołów;
- potrzebuje centralnego katalogu, polityk, tożsamości i audytu;
- agent ma korzystać z wielu narzędzi i działać przez dłuższy czas;
- potrzebne są zarządzany runtime, pamięć, RAG i monitoring;
- zespół chce łączyć low-code z własnym kodem;
- skala lub wymagania bezpieczeństwa uzasadniają inwestycję platformową.
Prostsze rozwiązanie może być lepsze, gdy:
- firma testuje jeden wąski przypadek;
- AI tylko przygotowuje szkic dla człowieka;
- aplikacja wykonuje jedno wywołanie modelu i nie potrzebuje agentowego runtime;
- zespół potrzebuje głównie integracji SaaS i deterministycznego workflow;
- wymagane jest środowisko niezależne od jednego dostawcy chmurowego;
- proces biznesowy nie jest jeszcze uporządkowany.
W takich sytuacjach warto rozważyć bezpośrednie API modelu, własną warstwę aplikacyjną, Dify do szybkiego budowania aplikacji LLM albo n8n do integracji i automatyzacji systemów. Narzędzie powinno wynikać z procesu, a nie odwrotnie.
Jak powinien wyglądać wartościowy pilot
Pilot nie powinien kończyć się demonstracją, że agent potrafi odpowiedzieć na kilka pytań. Powinien sprawdzić cały fragment procesu.
Przykład: agent wspiera obsługę zapytań klientów. Pobiera aktualne informacje z bazy wiedzy, sprawdza status sprawy, przygotowuje odpowiedź i tworzy propozycję dalszego działania. Wiadomości wymagające zobowiązania lub wyjątku trafiają do człowieka.
Dobry pilot obejmuje:
- Proces i miernik - na przykład czas obsługi, udział zaakceptowanych szkiców albo liczbę poprawnych eskalacji.
- Źródła wiedzy - wybrane dokumenty, ich właścicieli, aktualność i uprawnienia.
- Minimalne narzędzia - tylko operacje potrzebne w jednym scenariuszu.
- Kontrolę człowieka - jasno określone decyzje wymagające zatwierdzenia.
- Zestaw testów - typowe sprawy, wyjątki, brak danych i próby manipulacji.
- Monitoring - jakość, koszt, opóźnienie, błędy narzędzi i ślad wykonania.
- Decyzję po pilocie - rozwijamy, poprawiamy, upraszczamy albo zatrzymujemy.
Taki pilot pozwala ocenić nie tylko model, lecz również gotowość danych, procesu i zespołu.
Checklista przed wyborem Agent Platform
- Czy mamy konkretny proces i miernik biznesowy?
- Czy potrzebujemy agenta, czy wystarczy pojedyncze wywołanie modelu?
- Jakie działania agent ma wykonywać samodzielnie?
- Które decyzje muszą pozostać po stronie człowieka?
- Czy firma ma już dane, integracje i kompetencje w Google Cloud?
- Czy wymagamy wielu modeli, RAG, pamięci lub długotrwałych zadań?
- Jak agent będzie uwierzytelniany i autoryzowany?
- Czy docelowe funkcje są dostępne w wymaganym regionie?
- Jak będziemy testować odpowiedzi i wywołania narzędzi?
- Czy potrafimy odtworzyć przebieg konkretnej decyzji?
- Jaki jest koszt modelu, runtime, RAG, logów i utrzymania?
- Jak wycofamy agenta albo przeniesiemy logikę do innego środowiska?
Jeżeli większość odpowiedzi jest jeszcze nieznana, organizacja nie potrzebuje od razu pełnej platformy. Potrzebuje najpierw warsztatu architektonicznego i małego pilota.
Jak Sorix.tech podchodzi do wyboru platformy AI
W Sorix.tech nie zaczynamy od założenia, że firma potrzebuje Agent Platform, Azure, Dify, n8n albo własnego frameworka. Zaczynamy od procesu, danych, uprawnień i miernika efektu.
Następnie projektujemy najmniejszą architekturę, która pozwala bezpiecznie sprawdzić wartość. Jeśli wystarczy API modelu i kontrola człowieka, nie dokładamy platformy agentowej. Jeśli rozwiązanie wymaga wielu agentów, wspólnego runtime, centralnej tożsamości i monitoringu, oceniamy platformy enterprise oraz koszty ich utrzymania.
Przy istniejącym Vertex AI najpierw wykonujemy inwentaryzację usług, modeli, endpointów, danych i automatyzacji wdrożeń. Rozdzielamy aktualizację nazewnictwa od zmian technicznych i tworzymy plan oparty na rzeczywistych komunikatach o kompatybilności oraz wycofaniu funkcji.
Celem nie jest wdrożenie możliwie dużej liczby narzędzi AI. Celem jest rozwiązanie, które ma właściciela, daje się przetestować, pozostawia ślad audytowy i może być bezpiecznie rozwijane po udanym pilocie.
Podsumowanie
Vertex AI przechodzi w Gemini Enterprise Agent Platform, ale dla firm najważniejszy nie jest rebranding. Ważna jest zmiana sposobu myślenia: od wywoływania modeli do zarządzania agentami, które otrzymują tożsamość, narzędzia, pamięć i możliwość działania w systemach.
Istniejącego rozwiązania nie należy przepisywać tylko dlatego, że zmieniła się nazwa. Trzeba zinwentaryzować używane usługi, śledzić komunikaty dotyczące konkretnych API i modeli, a zmiany wprowadzać etapami.
Agent Platform ma sens tam, gdzie skala, liczba agentów, środowisko Google Cloud i wymagania governance uzasadniają platformę enterprise. Przy prostym zastosowaniu lepsze może być bezpośrednie API lub mniejsza warstwa aplikacyjna.
Profesjonalne wdrożenie zaczyna się od procesu i odpowiedzialności. Dopiero później wybiera model, runtime i markę platformy.
