Model Google, runtime developera, dane między — kto odpowiada za incident w architekturze Antigravity SDK

Disclaimer: Ten artykuł nie jest poradą prawną ani analizą inwestycyjną. Stanowi techniczno-prawną analizę implikacji bezpieczeństwa funkcji Antigravity SDK i Managed Agents ogłoszonych przez Google na I/O 2026 (19 maja 2026). Klasyfikacja dostawców ICT pod kątem DORA, NIS2 i polskiej ustawy o krajowym systemie cyberbezpieczeństwa wymaga konsultacji z radcą prawnym specjalizującym się w prawie nowych technologii i compliance enterprise. Analiza opiera się na publicznych dokumentach Google z keynote'u I/O 2026 oraz wynikach researchu architektury Antigravity na podstawie podobnych usług Google Cloud (Vertex AI, Cloud Functions, Cloud Run). Część szczegółów technicznych mechanizmu deployment Managed Agents jest oparta na predykcjach z architektury — Google opublikuje pełną dokumentację w drugiej połowie 2026.

Scenariusz, którego Google nie pokazał na keynote

Polski startup B2B SaaS, 18 osób, rok od pierwszej rundy. Buduje produkt do automatyzacji procesów księgowych dla małych firm. CTO słucha keynote'u I/O 2026. Słyszy ogłoszenie Managed Agents w Gemini API. Robi szybką kalkulację.

Wcześniejszy plan zespołu na agentic features: 4 miesiące pracy zespołu ML (którego nie mają — musieli zatrudnić), miesiące setupu sandbox infrastructure, security audyt, deployment pipeline, monitoring. Realistyczny budżet: 800,000 PLN, realistyczny timeline: 7-9 miesięcy do MVP.

Z Managed Agents: pierwszy działający prototyp w 2 tygodnie. Single API call do Gemini API z odpowiednim system prompt'em. Fully provisioned agent z remote sandboxem, autoscalingiem, logging, security przez Google's SOC 2 Type II compliance. Budżet do MVP: 30,000 PLN (głównie pricing API). Time to market: tydzień, nie miesiące.

CTO podpisuje na Managed Agents tego samego wieczoru po keynote.

Trzy lata później, kiedy startup ma 50 osób, 3 miliony PLN ARR i 200 klientów wśród polskich biur księgowych, Google ogłasza deprecation Managed Agents tier który startup używa. Migracja do nowego tier (z nowym pricing, 3x droższym) lub do innego provider (Anthropic, OpenAI) — 8-12 miesięcy pracy zespołu.

Pytanie nie brzmi "czy Managed Agents są dobrym wyborem dziś". Brzmi: "czy znamy pełen koszt tej decyzji w 36-miesięcznej perspektywie".

CyberFlux pisze o tej drugiej stronie. O threat modelu, vendor lock-in, supply chain attack vectors, odpowiedzialności prawnej w architekturze, którą Google promuje jako "5 minut do production".

Antigravity SDK i Managed Agents — co to dokładnie jest ?

Google ogłosił na I/O 2026 dwa komplementarne produkty dla developerów chcących wdrażać agentów AI:

Antigravity SDK — zestaw bibliotek programistycznych dla developerów chcących uruchamiać agentów Google na własnej infrastrukturze. Model językowy (Gemini 3.5 Flash) pozostaje po stronie Google, ale agent runtime, sandbox, deployment i dane są po stronie developera.

Managed Agents w Gemini API — fully provisioned agent z remote sandboxem dostępny przez single API call. Wszystko po stronie Google: model, runtime, sandbox, infrastructure, logging, scaling.

Te dwa produkty reprezentują dwie diametralnie różne filozofie wdrażania agentów AI:

Antigravity SDK = control path. Developer ma więcej kontroli, więcej odpowiedzialności, więcej pracy. Dane po stronie developera, audit log po stronie developera, security przez własną architekturę.

Managed Agents = fast path. Developer ma minimum pracy, minimum kontroli, minimum widoczności. Dane przepływają przez infrastrukturę Google, audit log po stronie Google (z ograniczonym dostępem developera), security przez Google's compliance certifications.

Wybór między nimi to nie tylko decyzja techniczna. To fundamentalna decyzja prawno-organizacyjna dla polskich firm, które muszą respektować RODO, DORA (jeśli sektor finansowy), NIS2 (jeśli operator usług kluczowych) i polską ustawę o krajowym systemie cyberbezpieczeństwa (jeśli sektor publiczny).

Supply chain agenta AI — siedem kategorii zagrożeń

Klasyczny software supply chain (Bibliografia: SolarWinds 2020, Log4j 2021, XZ Utils 2024) ma znane wektory ataku — kompromis upstream dependency, malicious code w popularnej bibliotece, transitive dependency confusion. Agent supply chain ma własne, nakładające się kategorie.

Zagrożenie 1: zmiana zachowania modelu przez Google

Twój produkt SaaS na Managed Agents jest oparty na specyficznym zachowaniu Gemini 3.5 Flash w określonych zadaniach. W określonym tygodniu Google deployment update model (Gemini 3.5.1, Gemini 3.5.2) bez wcześniejszej notyfikacji enterprise customers.

Twoja aplikacja zaczyna zwracać inne odpowiedzi. Klienci raportują bugi. Zespół spędza tygodnie na debugging — by odkryć że model się zmienił, dokumentacja Google'a tego nie raportowała, a "behavior consistency" nie jest częścią SLA Managed Agents w consumer tier.

Mitigation: Antigravity SDK pozwala na pinning konkretnej wersji modelu (jak długo Google ją obsługuje). Managed Agents — Google decyduje. Dla aplikacji krytycznych — Antigravity SDK > Managed Agents.

Zagrożenie 2: deprecation API z krótkim okresem migracji

Google ma historię deprecation usług z krótkim okresem migracji (Google Reader, Google+, Google Hangouts, ostatnio Inbox by Gmail i Google Domains). Antigravity CLI (deprecating Gemini CLI 18 czerwca 2026, niespełna miesiąc od ogłoszenia) jest świeżym przykładem tej praktyki w produktach AI.

Twój startup zbudowany na Managed Agents tier X. Google ogłasza deprecation tier X za 12 miesięcy. Twój produkt produkcyjny używa tier X. Migracja wymaga rewrite części aplikacji (różne API contracts między tierami), pricing nowego tier jest 3x wyższy, plus reauthentication klientów.

Mitigation: Antigravity SDK z opcją pinning model version + sticky deployment — jeśli Google deprecates model, masz dłuższe okno migracji. Managed Agents — silne uzależnienie od decyzji Google'a o tier roadmap.

Zagrożenie 3: data exfiltration przez API model calls

Każde wywołanie modelu w Managed Agents wymaga przesłania kontekstu do Google API. Kontekst zawiera prompt, system prompt, ewentualne user data dla zadania.

Google deklaruje że "API data is not used for training" — to jest standardowy commitment dla enterprise customers. Ale nie zawsze dla consumer tier i hobbyist tier. Dokumentacja jest niespójna i zmienna. Polski CISO musi przeczytać aktualne TOS, każdą wersję, przed deployment.

Wektor zagrożenia: nawet jeśli Google nie trenuje na danych z API, loguje je dla 90 dni (default w wielu Google Cloud usługach). W logach mogą się znaleźć dane osobowe klientów twojego SaaS, dane handlowe, intellectual property.

W przypadku Google security incident (data breach), logi z API mogą zostać exposed. Twoja firma jest data controller za dane swoich klientów, ale data jest fizycznie w Google's logs.

Mitigation: Antigravity SDK z lokalnym sandbox — dane nie wychodzą poza twoją infrastrukturę, tylko model API calls. Mniejszy attack surface, mniej danych w Google's logs. Konfiguracja "log retention = 0" dla Gemini API (dostępna w enterprise tier).

Zagrożenie 4: prompt injection cross-agent

Twoja aplikacja używa Managed Agents do wykonywania zadań dla użytkowników. Inny developer używa tych samych Managed Agents w swojej aplikacji dla innych użytkowników. Google deklaruje "tenant isolation" — sandbox jest izolowany per tenant.

Ale prompt injection cross-tenant to nowa kategoria badań akademickich. W maju 2026 Anthropic i Google opublikowali (osobne) papers pokazujące że LLM-y mogą być manipulowane przez ukryte instrukcje w kontekście, które przechodzą przez wewnętrzną pamięć współdzielonej infrastruktury (cache, batch processing, embedding stores).

Ryzyko jest niskie ale niezerowe. Dla aplikacji handling wrażliwych danych (zdrowie, finanse, dane osobowe) — pre-emption attack przez inny tenant Managed Agents to threat który musi być w threat modelu.

Mitigation: Antigravity SDK z izolowanym sandbox po stronie własnej infrastruktury = pełne tenant isolation. Managed Agents — Google's word that isolation is enforced.

Zagrożenie 5: change in Terms of Service

Google ma jednostronne prawo zmiany TOS dla większości swoich usług. Po 30-90 dniach notyfikacji new terms wchodzą w życie. Klient może albo zaakceptować, albo migrować.

W praktyce: jeśli twój produkt SaaS jest zbudowany na Managed Agents i nie masz alternatywy, "migracja" nie jest realną opcją. Akceptujesz nowe TOS, nawet jeśli są mniej korzystne.

Co konkretnie może się zmienić w TOS? Pricing (jak rozważone w Zagrożeniu 2). Data retention policies (może wzrosnąć z 90 do 365 dni). Usage rights (Google może nabyć right do używania twoich danych do "improvement of services" — gdyby coraz droższy enterprise tier był wymagany dla pełnego opt-out). Indemnification clauses (twoja odpowiedzialność przy incydentach security może wzrosnąć).

Mitigation: kontrakty enterprise z negotiated TOS — dostępne tylko dla większych klientów. Polski startup z $5K/m revenue nie ma negotiating power. Dla mniejszych firm — Antigravity SDK z modelem płaconym per token (mniej długoterminowych zobowiązań).

Zagrożenie 6: geopolityka i sankcje

Google jako amerykańska korporacja podlega US export controls i sanctions law. Hipotetyczny scenariusz: napięcia US-EU w obszarze AI regulation (już realnie istniejące w 2024-2026 z dyskusji EU AI Act vs US executive orders) eskalują do export restrictions.

Twoja firma w Polsce, używająca Managed Agents, może utracić dostęp do API z dnia na dzień. Albo dostęp może być utrzymany, ale data nie może być processowana w US-hosted infrastructure (jeśli EU narzuci data sovereignty). Albo Google przeniesie usługi do EU, ale za wyższy pricing.

Mało prawdopodobny scenariusz dla 2026, ale realny dla 2028-2030. Wystarczy do uwzględnienia w 36-miesięcznym risk planning.

Mitigation: dywersyfikacja providers (multi-vendor approach), używanie Antigravity SDK z możliwością relativnie szybkiej migracji na inny provider (Anthropic, Mistral, polski Bielik LLM jeśli osiągnie wymaganą jakość).

Zagrożenie 7: opaque billing i cost explosion

Managed Agents mają billing per token + billing per sandbox uptime + billing per outbound network bandwidth. To trzy ortogonalne dimensions ceny. Twoja faktura za miesiąc może być znacznie wyższa niż projektowałeś — bo system zachowuje się "average" dla większości operacji, ale niektóre operacje są bardzo droższe.

Klasyczny scenariusz: agent w pętli (loop bug) wykonujący tysiące API calls. Bez billing alerts skonfigurowanych explicite — odkrywasz dopiero pod koniec miesiąca, kiedy bill jest $50,000 zamiast planowanych $5,000.

Mitigation: budget alerts (Google Cloud Billing alerts at 50%, 80%, 100%), rate limiting po stronie aplikacji, circuit breakers dla loops, regular monitoring dashboards.

DORA, NIS2 i polska klasyfikacja ICT providers

Dla polskich firm w sektorach regulowanych Antigravity SDK i Managed Agents wprowadzają konkretne compliance challenges.

DORA (Digital Operational Resilience Act)

DORA obowiązuje od 17 stycznia 2025. Wymaga od finansowych entities (banki, ubezpieczyciele, brokerzy, niektóre firmy fintech) klasyfikacji "Critical ICT Third-Party Service Providers" (CTPP). Krytyczni dostawcy muszą:

• mieć contractual arrangements meeting specific requirements,
• być subject to ongoing monitoring przez financial entity,
• support exit strategy pozwalający na migrację bez dysrupcji.

Czy Google z Antigravity SDK + Managed Agents jest CTPP dla polskiego banku?

Yes, prawdopodobnie tak. Google Cloud jako całość jest często klasyfikowany jako critical ICT provider. AI services dochodzą do tej klasyfikacji.

Konsekwencje:

• bank musi przeprowadzić formalną due diligence Google'a jako provider,
• contract musi zawierać DORA-compliant clauses (right to audit, incident reporting, exit strategy),
• bank musi maintain "register of contracts" w sposób umożliwiający raportowanie do KNF,
• exit strategy musi być testowana okresowo.

Managed Agents w niewysoko-tier nie ma standardowo DORA-compliant contracts — to są enterprise tier features. Polski bank praktycznie nie może używać consumer-tier Managed Agents dla operations dotyczących klientów.

NIS2 (Network and Information Security Directive 2)

NIS2 obowiązuje w UE od października 2024 (z polską transpozycją trwającą). Rozszerza zakres NIS1 o nowe sektory (usługi cyfrowe, sektor zdrowia, transport publiczny, niektóre firmy produkcyjne). Operatorzy "essential services" muszą:

• maintain risk management measures,
• report significant incidents w specyficznych timeframes,
• have third-party risk management,
• conduct supply chain risk assessments.

Polska firma w sektorze NIS2 używająca Antigravity SDK lub Managed Agents musi:

• przeprowadzić risk assessment Google'a jako third-party,
• mieć incident reporting protocols obejmujący Google as potential source of incident,
• maintain ability to detect i respond do incidents in agent supply chain.

Praktyczna konsekwencja: każdy incident w infrastrukturze Google Cloud, który wpływa na agent capabilities, musi być raportowany przez polską firmę do CSIRT w okresie określonym w NIS2 (24 godziny dla early warning, 72 godziny dla initial assessment).

Polska ustawa o krajowym systemie cyberbezpieczeństwa (KSC)

KSC ustanawia kategorie podmiotów kluczowych i ważnych dla cyberbezpieczeństwa państwa. Dla podmiotów kluczowych (operatorzy usług kluczowych, dostawcy usług cyfrowych) — obowiązki incident reporting, ongoing security management, third-party risk.

KSC nie ma jeszcze specyficznych wytycznych dla agent-based services (rok 2026, wytyczne nadchodzą). Ale ogólne zasady applicable: agent supply chain to integral part of organization's security perimeter.

RODO art. 28 — data processing agreement

Niezależnie od sektora, RODO art. 28 wymaga że jeśli firma używa Google jako data processor (Managed Agents handling user data of EU citizens), musi mieć Data Processing Agreement (DPA) z Google.

Google ma standardowy DPA dla enterprise customers Google Cloud. Dla consumer tier Managed Agents — DPA jest częścią general TOS, bez negocjacji. To może być problematyczne dla niektórych use cases:

• jeśli twoja aplikacja procesuje special category data (zdrowie, religia, orientacja), generic DPA może nie być wystarczająco specyficzny,
• jeśli twoi klienci są big enterprise customers z własnymi DPAs, twój generic Google DPA może być w sprzeczności z ich wymaganiami.

Praktyczna rekomendacja: dla polskich firm processing wrażliwe dane przez agentów AI — enterprise tier z negocjowanym DPA (Antigravity SDK na własnej infrastrukturze z Gemini API jako data processor) zamiast consumer Managed Agents.

Praktyczne kroki dla polskich organizacji

Dla CTO / VP Engineering startupów

Decyzja: Antigravity SDK czy Managed Agents?

Macierz decyzyjna:

Aspekt	Antigravity SDK	Managed Agents
Time to MVP	4-12 tygodni	1-3 tygodnie
Setup cost	Wysoki	Niski
Operational cost	Średni-niski	Wysoki przy skali
Data sovereignty	Po twojej stronie	Po stronie Google
Vendor lock-in	Średni	Wysoki
Compliance flexibility	Wysoka	Niska (consumer tier)
Custom toolset	Tak	Ograniczone do Google's catalog
Best for	Aplikacje produkcyjne z sensitive data	Prototypowanie, MVP, non-sensitive use cases

Rekomendacja: prototyp na Managed Agents (szybkie validation), migracja na Antigravity SDK dla produkcji jeśli macie traction. Architekturuj kod tak, żeby model API był wymienialny (abstract layer over Gemini API).

Dla CISO/CIO polskich enterprise

1. Klasyfikuj Antigravity SDK + Managed Agents w portfolio third-party services. DORA, NIS2, KSC — wszystkie te frameworks wymagają takiej klasyfikacji.
2. Negocjuj enterprise contracts. Consumer tier Managed Agents nie ma negocjowanych warunków. Enterprise tier (Gemini Enterprise Agent Platform) ma negotiable TOS, DPA, SLA, indemnification.
3. Przeprowadź security audit Google'a jako provider. Większość elementów już istnieje (SOC 2 reports, ISO 27001, FedRAMP certification). Twój audit dokumentuje że je przejrzeliśmy i akceptujemy.
4. Maintain exit strategy. Dla każdej Google AI usage w organizacji — dokumentuj jak migrowałbyś na inny provider (Anthropic, OpenAI, własna infrastruktura). Test exit strategy raz na kwartał lub po istotnych zmianach.
5. Configure billing controls. Google Cloud Billing alerts at multiple thresholds, separate billing account dla Managed Agents (łatwiej śledzić), regular cost reviews.
6. Establish incident response protocols. Jak twoja organizacja reaguje na incident w Google'em? Plan reakcji uwzględniający że dane mogą być w Google's logs, że odpowiedzialność jest dzielona między ciebie a Google.

Dla developerów

1. Naucz się architekture multi-vendor. Twój kod powinien być structured tak, żeby model API był wymienialny przez interfejs warstwę. Trochę dodatkowej pracy upfront, dużo elastyczności w średnim terminie.
2. Monitoruj billing aggressively. Loop bugs są bardzo drogie w agent context. Każdy production deployment powinien mieć rate limiting, circuit breakers, billing alerts.
3. Audytuj dependencies regularnie. Google deprecates services. Subscribe do Google Cloud changelog. Maintain documentation o jakich features twoja aplikacja zależy.
4. Test failure modes. Co się dzieje gdy Gemini API jest niedostępne? Czy aplikacja degraduje gracefully czy fail'uje? Implementuj fallback strategies (cached responses, alternative providers, queue-and-retry).

Refleksja końcowa

Antigravity SDK i Managed Agents są technicznie imponujące. Próg wejścia dla agentic features spada z miesięcy do tygodni — to jest realna wartość dla rozwoju polskich startupów, agencji, enterprise.

Ale "5 minut do production" w marketingu nie obejmuje "tygodnie odzyskiwania po incidencie", "miesięcy migracji gdy provider zmieni warunki", "lat lock-in jeśli zbudujesz core business na single provider".

Polski rynek SaaS i AI ma do wyboru dwie ścieżki:

Ścieżka adopcji szybkiej: Managed Agents jako default, build fast, migrate later if needed. Maksymalizacja velocity rozwoju, akceptacja ryzyka vendor lock-in jako koszt prędkości. Realnie wybór większości early-stage startupów.

Ścieżka adopcji ostrożnej: Antigravity SDK z multi-vendor architecture od początku, więcej upfront cost, znacznie więcej elastyczności w średnim terminie. Realnie wybór organizacji enterprise i regulowanych sektorów.

Obie ścieżki są ważne. Obie mają miejsce. Ale decyzja musi być świadoma — co znaczy, że zespół musi czytać disclaimer'y, robić threat modeling, dokumentować acceptance ryzyka. Nie podpisywać na Managed Agents w 5 minut po keynote'cie tylko dlatego że Google daje dobre demo.

Jednym z tematów, które najbardziej brakuje w polskim ecosystem startupów AI w 2026, jest kontrkultura "slow down and consider". Konferencje, podcasty, branżowe media — wszystkie premiumują szybkość adopcji nowych narzędzi. CyberFlux próbuje wypełnić tę lukę — pokazując że "5 minut to production" ma ukryty cennik, który warto poznać przed podpisaniem.

Następny i ostatni wpis CyberFlux w hubie Google I/O 2026: warstwa 4, Intelligent Eyewear — privacy modelu always-on. Audio glasses, kamery, mikrofony, RODO art. 6 dla osób trzecich w polu widzenia.

---

Powiązane wpisy

W hubie Google I/O 2026:

• Google I/O 2026 — kiedy Agentic Web stała się oficjalną strategią Google (wpis flagowy huba)
• 47 sekund, 3 zakupione produkty, 2 utworzone konta, 0 kliknięć użytkownika (flagowy CyberFlux huba)
• 197 milionów parametrów, zero dodatkowej zgody — co Google zrobił z weights.bin po Gemma 197M (warstwa 1 CyberFlux)
• Antigravity 2.0 — kiedy agent-first development przestaje być pluginem do edytora (warstwa 2 WebFlux)

Słownik:

• Antigravity SDK
• Managed Agents (Gemini API)
• Antigravity 2.0
• Antigravity CLI (agy)
• Gemini Enterprise Agent Platform
• Gemini 3.5 Flash
• Supply chain attack MCP
• Sandboxing agenta

Źródła zewnętrzne:

• Chrome for Developers: 15 updates from Google I/O 2026
• Google Developers Blog: I/O 2026 developer highlights
• DORA — Digital Operational Resilience Act (EUR-Lex)
• NIS2 Directive (EUR-Lex)
• Polski Urząd Komisji Nadzoru Finansowego (KNF)
• NASK / CSIRT GOV

---