Bezpieczeństwo AI 2026. Nawet Google szuka po omacku

Bezpieczeństwo AI 2026 — czas między włamaniem a kolejnym etapem ataku spadł z 8 godzin do 22 sekund. COO Google Cloud przyznaje, że nawet Google improwizuje. Polskie firmy w erze NIS2 bez recepty.

---

Liczby do zapamiętania

---

Co się stało — Google Cloud i kryzys zaufania

24 maja 2026 roku TechCrunch opublikował długą rozmowę Connie Loizos z Francisem de Souzą, COO Google Cloud. Wywiad odbył się backstage podczas wydarzenia w Los Angeles. De Souza mówił spokojnym, akademickim tonem i powtarzał to, co specjaliści od bezpieczeństwa próbują wbić do głów zarządom firm od lat — tyle że teraz problem stał się pilny.

Trzy główne tezy de Souzy:

• Bezpieczeństwo nie może być doklejone do produktu AI po fakcie. Musi być wbudowane od początku, jako część strategii platformy.
• „Shadow AI” — pracownicy używający konsumenckich narzędzi AI bez nadzoru IT — jest realnym, narastającym problemem.
• Nie ma strategii AI bez strategii danych i strategii bezpieczeństwa. To trzy elementy tej samej układanki.

Francis de Souza, COO Google Cloud (parafraza za TechCrunch): Firmy są w okresie przejściowym — i potem wszyscy dojdziemy do lepszego miejsca.

Brzmi rozsądnie. Tylko że w tle wywiadu Google sam wpadł w serię publicznych awarii bezpieczeństwa, które pokazują, że nawet ten gigant nie ma gotowej recepty.

Skala zagrożenia — 22 sekundy

De Souza podał konkretną liczbę, która powinna spędzać sen z powiek każdemu polskiemu CISO: średni czas między pierwotnym włamaniem a „handoffem” do kolejnego etapu ataku spadł z 8 godzin do 22 sekund. Innymi słowy — atakujący nie czekają już dnia, żeby przekazać dostęp dalej w łańcuchu. Robią to natychmiast, automatycznie, z pomocą agentów AI.

Konsekwencja jest brutalna: klasyczna obrona oparta o ludzkich analityków SOC (Security Operations Center, centrum operacji bezpieczeństwa) jest po prostu za wolna. Człowiek nie nadąży za maszyną.

„Bug-pocalypse” — krytyczny niedobór ludzi

W tym samym tygodniu Lea Kissner, CISO LinkedIn-a, w wywiadzie dla New York Times-a użyła określenia „bug-pocalypse” — apokalipsa błędów. Jej teza jest prosta: AI generuje kod z błędami szybciej, niż zespoły bezpieczeństwa potrafią je łatać. Branża nie będzie rozumiała bezpieczeństwa AI w sposób trwały przez najbliższe kilka lat.

To bardzo niewygodna prawda dla każdego, kto sprzedaje „kompleksowe rozwiązania AI security”. Włącznie z Google.

---

Skąd ten ruch — co działo się przedtem

Wywiad de Souzy nie wyskoczył w próżni. To była próba kontroli narracji po serii kompromitujących publikacji branżowego pisma The Register.

Klucze API i pięciocyfrowe rachunki

Przez kilka tygodni w kwietniu–maju 2026 roku The Register dokumentował falę polskich i światowych deweloperów Google Cloud, którym ktoś podstępnie wygenerował rachunki za zapytania do Gemini API — modelu AI Google. Kluczowy szczegół: ofiary nigdy nie używały Gemini ani świadomie nie aktywowały tej usługi.

Mechanizm ataku był prosty i przerażający:

• Deweloper umieszczał klucz API w publicznym kodzie (np. front-end JavaScriptu), bo Google instruował, że tak należy robić — klucz Google Maps API.
• Google po cichu rozszerzył zakres istniejących kluczy o dostęp do Gemini, bez wyraźnego poinformowaniaużytkowników.
• Atakujący skanował publiczne repozytoria, znajdował klucz, próbował zapytań do Gemini — i sukces.

Konkretne ofiary:

• Rod Danan, CEO platformy szkoleniowej Prentus, dostał rachunek na 10 138 USD w ciągu 30 minut.
• Isuru Fonseka, deweloper z Sydney, obudził się z rachunkiem 17 000 AUD, mimo że ustawił sobie limit 250 USD.

Automatyczne podnoszenie limitów

Tu pojawia się druga warstwa skandalu. Google automatycznie podnosi limity wydatków użytkowników na podstawie historii konta, do nawet 100 000 USD, bez wyraźnej zgody. Czyli — twój nominalny limit 250 USD może być realnie ignorowany przez system, jeśli konto ma odpowiednią „historię”.

Po publikacji The Register Google zwrócił pieniądze obu deweloperom. Ale jednocześnie oświadczył, że nie zmieni polityki automatycznego podnoszenia limitów — bo priorytetem firmy jest „zapobieganie przerwom w usłudze”, a nie „egzekwowanie deklarowanych przez użytkowników budżetów”.

Polskie tłumaczenie: wygodniej dla Google obciążyć cię niż przestać świadczyć usługę.

23 minuty po unieważnieniu klucza

Drugi krytyczny ustalenie The Register, z artykułu z 21 maja 2026: badanie firmy bezpieczeństwa Aikido pokazało, że usunięty klucz API Google nadal działa nawet 23 minuty po unieważnieniu. Powód? Wewnętrzna propagacja revokacji przez infrastrukturę Google nie jest natychmiastowa.

Badacz Joseph Leon z Aikido pokazał, że w niektórych minutach po unieważnieniu klucza ponad 90 procent zapytań nadal się autoryzowało. Atakujący ma 23 minuty na eksfiltrację plików i historii konwersacji z Gemini.

Co ważne, Leon zaznaczył, że nowsze formaty kluczy Google działają znacznie szybciej: service account credentials revokują się w 5 sekund, klucze AQ-prefixed dla Gemini w około minutę. Czyli technicznie problem da się rozwiązać, ale dla starszych formatów kluczy Google wybrał inny priorytet.

---

Analiza techniczna — co się zmienia w obronie AI

De Souza w wywiadzie wymienił nową powierzchnię ataku, którą tradycyjne zespoły bezpieczeństwa muszą teraz uwzględnić. Oprócz klasycznego „estate” (sieć, serwery, bazy danych, aplikacje) firmy muszą chronić:

• Modele AI — wagi modeli, ich architekturę, dostępy do nich;
• Data pipelines — kanały treningu modeli, źródła danych, ETL;
• Agenty AI — autonomiczne programy działające w imieniu firmy;
• Prompty — historia konwersacji, system prompts, instrukcje dla modeli.

Agenci AI w starych systemach

Jedno spostrzeżenie de Souzy jest szczególnie ważne dla polskich firm: agenci AI przeszukujący wewnętrzne systemy organizacji odkrywają zapomniane repozytoria danych. Stare serwery SharePoint, niezaktualizowane kontrole dostępu, archiwa z dekady wstecz — wszystko to było bezpieczne przez „security by obscurity” (bezpieczeństwo przez niejasność). Nikt nie wiedział, gdzie są.

Agent AI uruchomiony do „przeszukania wewnętrznych dokumentów firmy” znajdzie je w 5 minut. I pokaże dane, których nikt nie powinien zobaczyć.

To realne ryzyko dla polskich korporacji, które od lat traktowały stare SharePointy, FTP-ki, intranety jako „ledwo żywe systemy”. Bo nikt po nie nie sięgał. Teraz agent AI uruchomiony jako asystent działu HR znajdzie zarchiwizowaną listę pensji z 2014 roku — i pokaże ją niewłaściwej osobie.

Wojna prędkością maszynową

De Souza argumentuje, że trzeba walczyć z agentami AI atakującymi za pomocą agentów AI broniących. Człowiek „w pętli” (human-in-the-loop) jest za wolny, zamiast tego trzeba „człowieka nad pętlą” (human-over-the-loop) — który nadzoruje agentów, ale nie podejmuje pojedynczych decyzji.

Brzmi rozsądnie, ale ma poważne implikacje:

• Decyzje o autonomicznym blokowaniu ruchu mogą prowadzić do błędnych „false positive” — blokady prawdziwych pracowników.
• Wymagania audytu — jak udowodnić, że agent obronny działał poprawnie? Czy logi są wystarczające?
• Compliance — czy AI agent decydujący o dostępie do danych osobowych jest zgodny z RODO?

To są pytania, na które rynek nie ma jeszcze gotowych odpowiedzi. I dlatego Lea Kissner mówi, że „bug-pocalypse” potrwa jeszcze kilka lat.

Multicloud i konsystencja security

De Souza odpiera zarzut, że tak naprawdę reklamuje Google Cloud. Argument: prawie żadna firma nie działa naprawdę na jednej chmurze. Nawet jeśli wybiera „single cloud”, używa SaaS-ów osadzonych w innych chmurach, ma partnerów na różnych chmurach, ma backupy gdzie indziej.

Wniosek: strategia bezpieczeństwa musi być konsystentna w wielu chmurach i wielu modelach AI. Polskim CISO to powinno przypomnieć, że ich obecna mapa security prawie na pewno nie pokrywa pełnej powierzchni ataku.

---

Bezpieczeństwo AI 2026 w Polsce — dane rynkowe i regulacje

Polska scena cyberbezpieczeństwa 2026 roku ma trzy unikalne elementy, których brak w analizach amerykańskich.

NIS2 — pierwszy pełny rok obowiązywania

Dyrektywa NIS2 (Network and Information Security 2) została wdrożona w Polsce przez ustawę o Krajowym Systemie Cyberbezpieczeństwa, której pełna implementacja weszła w życie w drugiej połowie 2025 roku. W 2026 roku jest to pierwszy pełny rok obowiązywania.

Co to oznacza dla polskich firm?

• Rozszerzona lista podmiotów krytycznych — z około 350 w starym KSC do ponad 6 000 firm w nowym KSC. W tym sektor energetyczny, transport, finanse, zdrowie, produkcja chemiczna, dostawcy cyfrowi (chmury, data centers), administracja publiczna.
• Obowiązek zgłaszania incydentów — 24 godziny na wstępne zgłoszenie, 72 godziny na pełne, miesiąc na raport końcowy.
• Odpowiedzialność osobista zarządów — w przypadku poważnego incydentu zarząd firmy może być osobiście pociągnięty do odpowiedzialności, nawet finansowej.

Polski CERT Polska (NASK) w raporcie za 2024 rok zarejestrował ponad 134 tysiące incydentów cyberbezpieczeństwa — rekord. W 2025 roku liczba dalej rosła. Ataki z użyciem AI (phishing, deepfake, social engineering) stanowiły już ponad 30 proc. wszystkich incydentów.

AI Act i bezpieczeństwo modeli AI

AI Act (rozporządzenie UE 2024/1689) w 2026 roku jest w fazie pełnego wdrożenia. Dla bezpieczeństwa AI istotne są dwa elementy:

• Modele GPAI (General Purpose AI) — takie jak Gemini, GPT, Claude — muszą mieć udokumentowane środki bezpieczeństwa, w tym ochronę przed jailbreakiem, prompt injection i adversarial attacks.
• Wysokiego ryzyka systemy AI (HR, edukacja, kredyty, infrastruktura krytyczna) muszą mieć audytowalność i human oversight — nadzór człowieka.

Polskie firmy używające Gemini API lub OpenAI API w sektorach wysokiego ryzyka już teraz muszą mieć dokumentację zgodności. Wielu CISO w Polsce nie ma tej dokumentacji — bo dostawca chmury nie dostarczył jasnych wytycznych.

Polski rynek cyberbezpieczeństwa — kto co robi

Polska scena bezpieczeństwa w 2026 roku to mix globalnych graczy i polskich firm:

Niedobór ludzi w polskim cyber

ISACA Polska szacowała w 2025 roku, że polskiemu rynkowi brakuje ok. 17 tysięcy specjalistów cyberbezpieczeństwa. Zarobki seniorów (CISO, security architect) sięgają w Warszawie 30–50 tys. zł bruttomiesięcznie, juniorów w SOC — 9–14 tys. zł brutto.

Skutek jest taki, że polskie firmy nie mają kim obsadzić procesów obronnych, które de Souza zaleca. Nawet jeśli kupią Google Security Operations czy Microsoft Defender for Cloud, brakuje analityków, którzy będą interpretować alerty.

Polskie incydenty AI security w 2025–2026

W ostatnich miesiącach polski rynek doświadczył kilku głośnych incydentów związanych z AI:

• Atak deepfake na polski bank (2025) — sklonowany głos CFO przekonał działaczy do transferu 2,7 mln zł. Bank odzyskał część środków, ale incydent wstrząsnął branżą.
• Phishing z AI-generated treścią — polski sektor MŚP odnotował trzykrotny wzrost udanych ataków phishingowych w 2025 roku, głównie z tekstami generowanymi przez AI w idealnej polszczyźnie.
• Wyciek danych z chatbota miejskiego — jeden z polskich samorządów wdrożył chatbot AI z dostępem do bazy mieszkańców. Po kilku tygodniach okazało się, że klucz API był w publicznym GitHubie.

To są dokładnie te same wzorce, które The Register opisał globalnie. Polska nie jest wyspą — jesteśmy w tym samym rzece.

---

Co Google powinien zmienić — i co polskie firmy

Wywiad de Souzy ma sens jako manifest stratega. Ale w świetle skandali Gemini API ma też dużą lukę między tym, co Google mówi, a co Google robi.

Co Google powinien zmienić natychmiast

• Natychmiastowa rewokacja kluczy API — 23 minuty to zbyt długo. Google ma technologię (5 sekund dla service account), trzeba ją wdrożyć dla wszystkich kluczy.
• Wyraźna zgoda na rozszerzanie zakresu klucza — jeśli klucz Google Maps miałby działać dla Gemini, użytkownik musi to wiedzieć i wyrazić zgodę.
• Twarde limity wydatków — limit 250 USD musi znaczyć 250 USD, a nie „limit, który może być automatycznie podniesiony do 100 000 USD”.
• Klarowna komunikacja przy zmianach — Google ma obowiązek (zgodny zresztą z AI Act i RODO) informować o zmianach zakresu usług.

Co polskie firmy powinny zrobić w ciągu najbliższych 90 dni

Konkretny plan dla polskiego CISO lub managera IT:

• Audyt kluczy API w organizacji — sprawdź, gdzie są klucze do chmury (Google, AWS, Azure), kto ma dostęp, czy są w publicznych repozytoriach.
• Hard limit w chmurach — ustaw twarde limity wydatków u dostawcy chmury, dwukrotnie sprawdź, czy nie są one „miękkie”.
• Polityka shadow AI — opracuj jasny dokument, jakie narzędzia AI pracownicy mogą używać, a jakich nie (ChatGPT konsumencki — nie, ChatGPT Business — tak).
• Mapowanie zapomnianych systemów — przeprowadź audyt starych SharePointów, intranetów, FTP-ek. Zamknij, co nie jest używane.
• Test agenta AI — jeśli wdrażasz agenta AI w organizacji, najpierw przeprowadź red-team — sprawdź, czy nie odkryje danych, których nie powinien.
• Plan reakcji NIS2 — jeśli jesteś w nowej liście podmiotów krytycznych, masz 24 godziny na zgłoszenie incydentu. Sprawdź, czy zespół to wie i ma procedurę.
• Backup poza chmurą — w obliczu ryzyka utraty dostępu do chmury (z dowolnego powodu) miej kopię danych poza Google/Azure/AWS.

---

Co to znaczy dla polskiego rynku

1. Polskie zarządy muszą zacząć rozumieć cyberbezpieczeństwo jako temat strategiczny. De Souza ma rację — to jest sprawa boardroom-level, nie tylko zespołu IT. NIS2 wprowadza osobistą odpowiedzialność członków zarządu, w niektórych przypadkach finansową. Polski prezes, który nie rozumie różnicy między prompt injection a SQL injection, jest ryzykiem dla firmy, nie tylko jej ofiarą.

2. Polski rynek AI security ma realny popyt i ograniczoną podaż. Z deficytem 17 tysięcy specjalistów cyber i rosnącą bazą firm objętych NIS2, polskie firmy bezpieczeństwa mogą rosnąć dwucyfrowo. To dobry moment dla startupów typu Securitum, Niebezpiecznik, polskich SOC-as-a-Service. Ale też dla edukacji — Politechnika Warszawska, AGH, WAT, UMK powinny zwiększyć liczbę miejsc na kierunkach cyber.

3. Polska zależność od Google Cloud i Microsoft Azure jest realnym ryzykiem strategicznym. Skandal z kluczami API pokazuje, że nawet sami operatorzy chmur niekoniecznie chronią klienta wystarczająco dobrze. Polskie banki, sektor zdrowia, administracja powinny realnie ocenić, czy ich umowy z Google/Microsoft zawierają adekwatne SLA bezpieczeństwa. To jest moment dla chmury suwerennej (OChK) — i jest to dobra wiadomość dla polskiego rynku.

4. Polskie MŚP są w największym ryzyku. Duże korporacje mają zespoły CISO, audyty, kontrakty. Polskie małe firmy nie mają nic — używają ChatGPT konsumenckiego, wklejają dane klientów, klucze API są w publicznych Gistach. To są realne źródła wycieków, które dopiero wybuchają. Polskie izby gospodarcze powinny pilnie uruchomić programy edukacji cyber dla MŚP — bez tego stracimy tysiące firm na ataki, których można było uniknąć.

---

Czy ufać Google Cloud i innym hyperscalerom

TL;DR: Tak, jeśli rozumiesz ryzyko i masz hard limity. Nie, jeśli twoja organizacja nie ma działu IT albo działasz w sektorze krytycznym bez backup planu.

Tak — używaj Google Cloud / Azure / AWS, jeśli:

• masz dedykowany zespół IT lub partnera technologicznego, który zna konfiguracje bezpieczeństwa twojej chmury;
• wdrożyłeś hard limity wydatków i regularnie audytujesz klucze API;
• twoja firma jest w ekosystemie SaaS (CRM, ERP, marketing), w którym wybór chmury jest naturalny;
• używasz planów Enterprise z dedykowanym wsparciem i compliance — nie konsumenckich planów dla biznesu;
• masz multi-region backup i disaster recovery plan poza twoją główną chmurą.

Nie — odpuść hyperscalera (lub używaj go bardzo selektywnie), jeśli:

• jesteś mikro firmą bez działu IT — koszty operacyjne błędu konfiguracji mogą cię zniszczyć;
• działasz w sektorze krytycznym (energetyka, woda, infrastruktura) i potrzebujesz chmury suwerennej (OChK, EuroStack) z polskim DPA;
• twoja firma ma kategoryczny zakaz wynoszenia danych poza UE (niektóre regulowane zawody, NDA z klientami strategicznymi);
• nie masz budżetu na specjalistyczne consultingi (Asseco, Comp, Comarch, EXATEL) wspierające konfigurację;
• twój sektor wymaga suwerenności danych zgodnie z polskim KSC — chmura suwerenna lub on-premises jest lepszym wyborem.

---

Co obserwować w nadchodzących miesiącach

1. Reakcja Google — czy faktycznie zmieni politykę kluczy API i automatycznego podnoszenia limitów. Termin presji: lipiec 2026, po kolejnych publikacjach The Register.
2. Polskie wytyczne CERT/NASK — czy w 2026 roku ukażą się szczegółowe wytyczne dla polskich firm korzystających z AI w chmurze.
3. Pierwsze decyzje UODO w sprawach AI — czy polski regulator wyda pierwsze decyzje sankcyjne za nieprawidłowe wdrożenia AI w sektorze finansowym lub HR.
4. Wzrost polskich firm cyber — czy Securitum, Niebezpiecznik, Comp, Asseco będą ogłaszać akwizycje lub rundy finansowania.
5. Operator Chmury Krajowej — czy polski rząd faktycznie przeniesie kolejne usługi państwowe na OChK i czy banki za nim podążą.
6. Praktyka NIS2 w sądach — pierwsze polskie wyroki za niewdrożenie NIS2 prawdopodobnie w 2027 roku, ale 2026 to rok pierwszych postępowań przygotowawczych.

🎯 Wniosek końcowy

Bezpieczeństwo AI 2026 to nie temat dla zespołu IT — to temat dla całej organizacji, od zarządu po pracowników działu sprzedaży. Google sam przyznaje (przez Francisa de Souzę), że jesteśmy w okresie przejściowym. Ale skandale z kluczami API pokazują, że nawet Google nie jest jeszcze w „lepszym miejscu”, do którego sam się nawołuje.

Mówiąc wprost: jeśli twoja polska firma używa AI w chmurze (Gemini, OpenAI, Claude), masz dziś realne ryzyko, że twój klucz API już krąży po dark webie, twój chatbot udostępnia dane mieszkańcom, a twój agent AI właśnie znalazł dokument, którego nikt nie powinien widzieć. NIS2 daje ci 24 godziny na zgłoszenie incydentu. Najwyższy czas zacząć działać.

W szerszym kontekście rok 2026 jest momentem, w którym AI security przestaje być niszą techniczną, a staje się podstawową kompetencją biznesową. Polskie firmy, które do końca roku nie będą miały realnej polityki AI security, w 2027 roku staną się przykładami case study na konferencjach NASK — i nie w pozytywnym sensie. Czas decyzji jest teraz.

---

Źródła:

• TechCrunch / Connie Loizos — Everyone is navigating AI security in real time — even Google (24.05.2026)
• The Register — Google users fight for refunds as unauthorized API usage bills soar (13.05.2026)
• The Register — Threat hunters find Google API keys still usable 23 minutes after deletion (21.05.2026)
• Aikido — paper o czasie revokacji kluczy Google API (maj 2026)
• New York Times — wypowiedź Lea Kissner (LinkedIn CISO) o „bug-pocalypse” (24.05.2026)
• CERT Polska / NASK — Raport o stanie bezpieczeństwa cyberprzestrzeni RP 2024
• ISACA Polska — Raport o rynku specjalistów cyber 2025
• PMR — Polski rynek cyberbezpieczeństwa 2025
• Ministerstwo Cyfryzacji — wytyczne wdrażania NIS2 i KSC 2025
• Rozporządzenie UE 2024/1689 (AI Act) — wymagania dla GPAI i wysokiego ryzyka AI
• Ustawa o Krajowym Systemie Cyberbezpieczeństwa (wersja po wdrożeniu NIS2)

0 komentarzy

Bądź miły — kultura dyskusji to nasza wartość. Dodaj komentarz

Bądź pierwszy, dodaj komentarz!