AI governance w praktyce: czego CISOs naprawdę potrzebują, żeby zabezpieczyć środowisko AI

Q: "Dlaczego blokowanie shadow AI nie działa jako strategia bezpieczeństwa?"

"Blokowanie popycha użytkowników do pracy w ukryciu. 57% pracowników aktywnie ukrywa używanie narzędzi AI przed pracodawcą - nie dlatego, że robią coś złośliwego, ale dlatego, że polityka zabraniała, a praca i tak musiała być wykonana. Blokowanie przez kontrole sieciowe skłania pracowników do korzystania z prywatnych VPN i urządzeń osobistych, eliminując tę odrobinę widoczności, jaką miał zespół bezpieczeństwa. Wynikiem jest najgorszy scenariusz: AI jest wszędzie w użyciu, bez logowania, bez kontroli danych i bez governance."

Q: "Czego naprawdę wymaga widoczność AI w organizacji?"

"Trzech warstw: narzędzi - jakie aplikacje AI faktycznie działają (większość zespołów bezpieczeństwa wymienia dwa lub trzy; rzeczywista liczba jest zazwyczaj dziesięciokrotnie wyższa); ekosystemu - z czym te narzędzia się łączą, w tym serwery MCP, wtyczki i rozszerzenia z aktywnym dostępem do CRM lub infrastruktury chmurowej; oraz artefaktów - co pracownicy budują za pomocą AI, jak aplikacje wewnętrzne i zautomatyzowane przepływy pracy, które mogą tworzyć ekspozycje bez bezpośredniego wycieku danych. Widoczność we wszystkich trzech warstwach jest fundamentem - bez niej governance jest zgadywaniem."

Q: "Jak NIS2, DORA i unijne rozporządzenie o AI stosują się do ryzyka związanego ze środowiskiem AI?"

"Wszystkie trzy regulacje dotykają artefaktów generowanych przez AI i ryzyka związanego z narzędziami zewnętrznymi. NIS2 wymaga środków bezpieczeństwa sieci i systemów informatycznych obejmujących działające w nich narzędzia. DORA nakłada obowiązek zarządzania ryzykiem ICT podmiotów zewnętrznych, obejmującego narzędzia AI powiązane z procesami finansowymi. Unijne rozporządzenie o AI wprowadza obowiązki dotyczące systemów AI wysokiego ryzyka. Stwierdzenie, że istniała polityka, nie utrzyma się podczas audytu, gdy dowody wskazują na niezarządzane narzędzia AI podłączone do krytycznych systemów."

11 May 2026 • 2 min read • AI GovernanceShadow AIBezpieczeństwo AICISOCEEMENA

AI governance w praktyce zaczyna się od niepokojącej liczby: 57% pracowników aktywnie ukrywa przed pracodawcą fakt używania narzędzi AI.

Nie dlatego, że robią coś złośliwego. Polityka mówiła nie, a praca i tak musiała zostać wykonana.

Widzę to regularnie. Polityka istnieje. Zachowania, które miała powstrzymać, też istnieją - tylko poza zasięgiem wzroku.

Model zagrożeń jest już nieaktualny

Większość zespołów bezpieczeństwa nadal myśli o ryzyku AI jak o zakładce w przeglądarce. Ktoś wkleja tekst do ChatGPT. Może wycieka coś wrażliwego.

To był 2023 rok.

Dziś przeciętna firma ma aktywnie uruchomionych nawet 27 narzędzi AI. IDE z natywną obsługą AI z pełnym dostępem do systemu plików. Narzędzia do vibe-codingu podłączone do produkcyjnych systemów SaaS. Serwery MCP dające modelom AI bezpośredni interfejs do wewnętrznych API i baz danych.

Każdy endpoint jest teraz workspace’em AI. Twoje kontrole perymetryczne nic z tego nie widzą.

Dwie odpowiedzi. Obie złe.

Blokuj wszystko - pracownicy omijają blokady przez prywatne VPN, shadow AI schodzi głębiej, tracisz resztki widoczności, którą miałeś.

Zezwalaj bez nadzoru - każdy endpoint staje się potencjalnym punktem wejścia, a ty nie masz pojęcia, gdzie trafiają dane.

Rozmawiałem niedawno z zespołem Pluto Security. Opisali realny incident: pracownik użył Lovable do zbudowania wewnętrznej aplikacji podłączonej do Workday i Salesforce. AI automatycznie postawiło bazę danych Supabase. Źle skonfigurowaną. Wystawioną na publiczny internet. Bezpośredni backdoor do kluczowych systemów biznesowych - stworzony przez kogoś, kto chciał być produktywny, nie przez atakującego.

Narzędzie nie było problemem. Nikt nie wiedział, że działa.

Co visibility naprawdę oznacza

Zanim nim zarządzisz, musisz wiedzieć, co istnieje. Trzy warstwy:

Narzędzia - jakie aplikacje AI faktycznie działają. Większość zespołów bezpieczeństwa potrafi wymienić dwie lub trzy. Rzeczywista liczba jest dziesięć razy większa.

Ekosystem - z czym te narzędzia się łączą. MCP, pluginy, rozszerzenia. AI czytające tekst to jedno ryzyko. AI z aktywnym połączeniem do twojego CRM lub infrastruktury chmurowej to zupełnie inne.

Artefakty - co pracownicy budują z tymi narzędziami. Kod, workflow, wewnętrzne aplikacje. Incident z Lovable był problemem z artefaktem - AI nie wykradło danych, zbudowało coś, co stworzyło ekspozycję.

Pluto Security potrafi zmapować około 80% shadow AI footprint organizacji w dwie godziny przez read-only integrację z EDR. Bez agentów, bez zmian w infrastrukturze. Visibility nie musi być projektem na sześć miesięcy.

Control, który działa na skalę

Runtime enforcement bije sieciowe blokady. PII trafiające do publicznego modelu - przechwycone. Złośliwe rozszerzenie próbujące się uruchomić - zatrzymane. Pracownik dostaje komunikat w kontekście wyjaśniający politykę bezpieczeństwa, nie generyczną stronę blokady.

Nie potrzeba do tego SOC z 50 analitykami.

Kontekst CEE

NIS2, DORA i EU AI Act dotykają AI-generated artifacts i ryzyko narzędzi trzecich stron. “Mieliśmy politykę bezpieczeństwa” nie przejdzie w audycie, gdy dowody pokazują niezarządzane narzędzia podłączone do systemów krytycznych.

Zacznij od footprintu. Sprawdź, co działa. Zmapuj połączenia. Zrozum, co zostało zbudowane. To zajmuje godziny.

Wszystko inne z tego wynika.

Wymiar tożsamości i dostępu - jak AI agents dziedziczą credentials i co oznacza to dla powierzchni ataku - omawia Bezpieczeństwo agentów AI: mają już klucze.

Pracujesz nad tym w swojej organizacji? Napisz na LinkedIn lub info@et-cybersecurity.pl.

Najczęstsze pytania

Dlaczego blokowanie shadow AI nie działa jako strategia bezpieczeństwa?

Blokowanie popycha użytkowników do pracy w ukryciu. 57% pracowników aktywnie ukrywa używanie narzędzi AI przed pracodawcą - nie dlatego, że robią coś złośliwego, ale dlatego, że polityka zabraniała, a praca i tak musiała być wykonana. Blokowanie przez kontrole sieciowe skłania pracowników do korzystania z prywatnych VPN i urządzeń osobistych, eliminując tę odrobinę widoczności, jaką miał zespół bezpieczeństwa. Wynikiem jest najgorszy scenariusz: AI jest wszędzie w użyciu, bez logowania, bez kontroli danych i bez governance.

Czego naprawdę wymaga widoczność AI w organizacji?

Trzech warstw: narzędzi - jakie aplikacje AI faktycznie działają (większość zespołów bezpieczeństwa wymienia dwa lub trzy; rzeczywista liczba jest zazwyczaj dziesięciokrotnie wyższa); ekosystemu - z czym te narzędzia się łączą, w tym serwery MCP, wtyczki i rozszerzenia z aktywnym dostępem do CRM lub infrastruktury chmurowej; oraz artefaktów - co pracownicy budują za pomocą AI, jak aplikacje wewnętrzne i zautomatyzowane przepływy pracy, które mogą tworzyć ekspozycje bez bezpośredniego wycieku danych. Widoczność we wszystkich trzech warstwach jest fundamentem - bez niej governance jest zgadywaniem.

Jak NIS2, DORA i unijne rozporządzenie o AI stosują się do ryzyka związanego ze środowiskiem AI?

Wszystkie trzy regulacje dotykają artefaktów generowanych przez AI i ryzyka związanego z narzędziami zewnętrznymi. NIS2 wymaga środków bezpieczeństwa sieci i systemów informatycznych obejmujących działające w nich narzędzia. DORA nakłada obowiązek zarządzania ryzykiem ICT podmiotów zewnętrznych, obejmującego narzędzia AI powiązane z procesami finansowymi. Unijne rozporządzenie o AI wprowadza obowiązki dotyczące systemów AI wysokiego ryzyka. Stwierdzenie, że istniała polityka, nie utrzyma się podczas audytu, gdy dowody wskazują na niezarządzane narzędzia AI podłączone do krytycznych systemów.