Wybór „odpowiedniego narzędzia AI” przestaje być dziś dla firm kluczowym wyzwaniem. Prawdziwy problem wygląda inaczej: pracownicy już korzystają z AI - tylko nie z tego, które zatwierdziła organizacja.

Gdy kierownictwo wciąż ustala zasady nadzoru, prawnicy weryfikują zgodność z RODO, a IT porównuje dostawców, osoby z marketingu, HR, finansów czy zespołów technicznych wklejają firmowe dane do darmowych, konsumenckich chatbotów. To zjawisko nazywa się shadow AI. I dopóki nie zapewnisz ludziom bezpiecznej, firmowej alternatywy objętej jasnymi zasadami, shadow AI będzie nadal dominować.

Ten tekst przedstawia konkretny, czterowariantowy model wdrażania dużych modeli językowych (LLM) w sposób bezpieczny, zgodny z regulacjami i możliwy do przeprowadzenia w realiach nowoczesnej organizacji. Punkt wyjścia jest prosty: nie każde rozwiązanie AI oferuje ten sam poziom bezpieczeństwa, a nie każda firma potrzebuje najdroższego scenariusza z pełnym utrzymaniem modeli we własnym środowisku. Właściwy wybór zależy od tego, co chcesz osiągnąć (korzystać z AI czy tworzyć rozwiązania z jej wykorzystaniem), jak wrażliwe są Twoje dane oraz jakiego poziomu kontroli faktycznie potrzebujesz.

Omówimy cztery podejścia:

• konsumenckie Gemini na koncie prywatnym

• Gemini w ramach Google Workspace

• dostęp programistyczny przez API (Vertex AI / Gemini API)

• LLM-y utrzymywane samodzielnie lub open source na własnej infrastrukturze

…i powiążemy je z kwestiami ładu organizacyjnego, RODO, całkowitego kosztu posiadania (TCO) oraz konkretnymi scenariuszami biznesowymi.

Dlaczego to jest ważne właśnie teraz: Shadow AI to problem „na dziś”

Generatywne AI weszło do firm w niesamowitym tempie - szybciej niż większość wcześniejszych technologii - bo rozwiązuje bardzo realny, codzienny problem: pisanie, streszczanie, tłumaczenie.
Właśnie dlatego pracownicy sięgnęli po najprostsze narzędzia: darmowe, publiczne chatboty.

I tu zaczyna się wyciek.

• Marketing wrzuca listy klientów, żeby „zobaczyć insighty”.

• Developerzy wklejają zastrzeżony kod, żeby „znaleźć błędy”.

• HR podsyła oceny okresowe, żeby „streścić feedback”.

A wszystko to często trafia do narzędzi, które:

• są podpięte do prywatnych kont, a nie domeny firmowej,

• działają na regulaminach konsumenckich,

• mogą wykorzystywać przesłane dane do trenowania modeli,

• mogą udostępniać dane recenzentom.

Efekt? Gdy zarząd wciąż dyskutuje o „ryzykach AI”, realny wyciek już trwa - od środka.
Dlatego pierwszy ruch biznesowy to nie „zbudujmy platformę AI”, tylko: odetnijmy niekontrolowany kanał i zastąpmy go zatwierdzonym.

Framework 4 ścieżek (perspektywa enterprise)

Ryzyko nie tkwi w samej AI, tylko w modelu wdrożenia. Ten sam dostawca może oferować:

• produkt konsumencki (ryzykowny),

• produkt korporacyjny (bezpieczny),

• API (bardzo silna ochrona prywatności),

• opcję self-hosted (maksymalna kontrola, maksymalny koszt).

Przejdźmy więc przez nie po kolei: im więcej kontroli, tym wyższy koszt jej uzyskania.

1. Konsumencki Gemini na prywatnym koncie - dlaczego to „no-go” dla biznesu

To narzędzie, po które pracownicy sięgają jako pierwsze, bo jest:

• darmowe,

• w przeglądarce,

• bez zakupu licencji,

• bez udziału admina.

Ale dla danych firmowych to najgorsza możliwa opcja.

Cel i zakres.
Ta usługa jest projektowana dla osób prywatnych, a nie organizacji. Obowiązują ją szerokie polityki prywatności dla konsumentów, które w skrócie mówią: „zbieramy dane, by świadczyć, utrzymywać i ulepszać nasze usługi oraz tworzyć nowe”. To w pełni sensowny model dla produktu konsumenckiego - ale stoi w sprzeczności z interesem firmy, która chce, by jej dane nie trafiały do cudzego pipeline’u treningowego.

Review przez ludzi.
Dokumentacja mówi wprost: rozmowy mogą być przeglądane przez recenzentów (ludzi) w celu poprawy jakości. Nawet jeśli dane są zanonimizowane, z perspektywy firmy poufność już została naruszona - ktoś spoza organizacji, zobaczył ich treść.

Retencja.
Nawet gdy użytkownik wyłączy historię aktywności, dostawca może przez pewien czas przechowywać dane (np. 72 godziny) na potrzeby bezpieczeństwa i wykrywania nadużyć. Część danych użytych do review może być przechowywana dłużej. Z perspektywy RODO tu zaczyna się problem:

• nie egzekwujesz w pełni ograniczenia celu przetwarzania,

• nie możesz w pełni zagwarantować prawa do usunięcia,

• nie jesteś w stanie przejrzyście wskazać, gdzie dane faktycznie teraz są.

Brak kontroli enterprise.
Nie masz:

• konsoli admina,

• centralnego audytu,

• integracji z DLP,

• powiązania z rolami/OU w organizacji,

• widoczności dla zespołu bezpieczeństwa.

Czyli nawet jeśli pracownik zrobi coś niewłaściwego, Ty jako administrator i tak tego nie widzisz.

Wniosek dla modelu 1:
to nie jest „tańsza opcja dla biznesu”. To ryzyko i potencjalna odpowiedzialność.
Właściwa polityka: blokuj, zabroń, wyjaśnij.
Zablokuj dostęp z urządzeń i sieci firmowych, zabroń używania do danych biznesowych i wytłumacz, dlaczego - podkreślając, że ten sam vendor oferuje bezpieczną, zarządzaną alternatywę dla firm.

2. Gemini w Google Workspace - najszybsza bezpieczna ścieżka dla większości firm

Zmiana w umowie.
Przechodząc z konta konsumenckiego na Gemini w Google Workspace, zmienia się model biznesowy.
Przestajesz być produktem - produktem staje się usługa.

Twoje prompty, maile, Dokumenty, Arkusze są traktowane jako Customer Data w ramach istniejącej umowy enterprise i Cloud Data Processing Addendum.
W języku prawnym: Google jest procesorem, Ty - administratorem danych. To odwrotność modelu konsumenckiego.

Kluczowe gwarancje (te, o które zawsze pyta zarząd):

• „Twoje dane nie są przeglądane przez ludzi.”

• „Twoje dane nie są używane do trenowania modeli.”

• „Twoje dane są przetwarzane w ramach Twojej domeny i zgodnie z Twoimi politykami.”

To właśnie sprawia, że ten model jest zgodny z RODO: możesz wskazać umowę, DPA, rolę procesora i jasno określone cele przetwarzania.

Dziedziczone bezpieczeństwo.
Druga ogromna zaleta: nie musisz od nowa budować bezpieczeństwa „pod AI”.
Gemini dziedziczy to, co już masz w Workspace:

• reguły DLP (np. numery kart, PESEL, NIP),

• uprawnienia do plików (jeśli użytkownik nie widzi pliku z pensją CEO, Gemini też go nie streści),

• logi audytowe (ta sama konsola, ten sam SIEM),

• Client-Side Encryption (jeśli szyfrujesz po stronie klienta, Google nie widzi treści - Gemini też nie przetworzy),

• reguły udostępniania i IRM.

Zamiast wynajdywać nowy „AI governance stack”, opierasz się na tym, co admini już znają.

Koszt i rollout (TCO).
To prosta subskrypcja per użytkownik. Bez kupowania GPU, bez zatrudniania MLOpsów.
Włączasz, testujesz polityki, wdrażasz na organizację.

Dlatego jest to najszybszy sposób, by pozbyć się Shadow AI:
dajesz pracownikom narzędzie lepsze niż to nieoficjalne - i jednocześnie bezpieczne.

3. Dostęp programistyczny przez API (Vertex AI / Gemini API) - gdy chcesz budować, a nie tylko używać

Nie każda firma poprzestaje na „używaniu AI”.
Wiele chce:

• wbudować AI w swoje produkty,

• zautomatyzować część obsługi klienta,

• zbudować wewnętrzne copiloty,

• stworzyć pipeline’y analityczne oparte na LLM.

Do tego potrzebujesz API, a nie tylko „AI w Dokumentach”.

Ten model ma nieco inny profil bezpieczeństwa - w pewnych aspektach jeszcze mocniejszy niż Workspace.

Zero Data Retention.
Umowy dla generatywnego AI w Google Cloud są bardzo jasne:
dane wysyłane do API są używane wyłącznie do wygenerowania odpowiedzi i nie są wykorzystywane do trenowania modeli.

Istnieje drobny techniczny wyjątek: platforma może cache’ować dane przez maksymalnie 24 h dla poprawy opóźnień - ale można to wyłączyć na poziomie projektu.
Dla banków, ochrony zdrowia czy sektora publicznego to kluczowe.

Ale… współdzielona odpowiedzialność.
Tu wiele zespołów się potyka. Dostawca zabezpiecza:

• model,

• endpoint API,

• data center,

• sieć.

Ty musisz zabezpieczyć:

• kod aplikacji,

• uwierzytelnianie i autoryzację (IAM),

• sanityzację wejścia (przed prompt injection itp.),

• szyfrowanie (jeśli wysyłasz wrażliwe payloady),

• logging i monitoring,

• rate limiting i wykrywanie nadużyć.

Innymi słowy: bezpieczne API nie czyni Twojej aplikacji bezpieczną.
Jeśli logujesz surowe dane, albo pozwalasz użytkownikowi pytać o dokumenty, do których nie ma praw, fakt, że LLM nie przechowuje danych, niewiele Cię uratuje.

Koszt.
API są świetne, bo są tanie na start i skalują się z użyciem.
Przy bardzo dużych wolumenach trzeba myśleć o optymalizacji, batchowaniu czy distillacji modeli.
Dla większości firm średniej wielkości koszt zmienny jest i tak korzystniejszy niż CapEx self-hostingu.

Wniosek dla modelu 3:
wybierz go, jeśli masz sensowny zespół inżynierski i chcesz budować funkcje/produkty oparte na AI.
Akceptujesz model współdzielonej odpowiedzialności - i dokumentujesz go.

4. Self-hosted / open-source LLM - maksimum kontroli, maksimum obciążeń

To ścieżka, o której wszyscy lubią rozmawiać, a którą naprawdę niewielu powinno wybierać.

Dlaczego kusi?
Bo obiecuje 100% suwerenności danych. Model działa:

• na Twoim sprzęcie,

• w Twojej sieci,

• w Twoim VPC,

• czasem wręcz w środowisku odciętym od internetu.

Dane nigdy nie wychodzą na zewnątrz.
Dla sektora obronnego, wywiadu, części bankowości czy R&D na ultra wrażliwym IP - to jest dokładnie to, czego trzeba.

Ale koszty są odroczone i ciężkie.

Trzeba uwzględnić:

• CapEx: szafy GPU klasy A100/H100 (lub odpowiedników), wydajna sieć, storage, czasem nawet rozbudowa serwerowni. To setki tysięcy zł/dolarów.

• OpEx: prąd, chłodzenie, miejsce, utrzymanie, monitoring.

• Ludzi: tu jest prawdziwy koszt.
  Nie poprosisz admina „przy okazji” o ogarnianie LLM. Potrzebujesz MLOps, SRE, ludzi od tuningu, monitoringu i upgrade’ów modeli.

A po tym wszystkim… model, który uruchomisz lokalnie, często będzie słabszy niż ten dostępny przez API u dużego dostawcy - za ułamek ceny.
Odpowiadasz też za: uptime, backupy, skalowanie, DR.

Kiedy ma sens?
Gdy Twoje dane nie mogą legalnie lub operacyjnie opuścić środowiska,
i gdy masz budżet oraz ludzi, by utrzymywać to latami.
Wtedy - i tylko wtedy - self-hosting jest racjonalną strategią redukcji ryzyka, a nie sposobem na oszczędności.

Drzewko decyzyjne w 2 pytaniach

Nie potrzebujesz 30-stronicowej polityki, by podjąć decyzję.
Framework sprowadza się do dwóch prostych pytań:

1. Co chcemy robić z AI?

• Jeśli celem jest „zwiększyć produktywność pracowników” → Ścieżka 2 (Workspace).

• Jeśli celem jest „budować funkcje/produkty oparte na AI” → Ścieżka 3 (API).

2. Czy mamy skrajne, nienegocjowalne wymagania dot. suwerenności danych?

• Jeśli tak → rozważ Ścieżkę 4 (self-hosted).

• Jeśli nie → zostań przy 2 lub 3.

A Ścieżka 1 (konsumencka)?
Nigdy jej nie używamy. Blokujemy, banujemy, tłumaczymy dlaczego.

Governance: część, którą wszyscy chcą pominąć (ale nie mogą)

Technologia sama w sobie Cię nie uratuje.
Wszystkie cztery modele wymagają warstwy governance wewnątrz organizacji. Minimum to:

1. Acceptable Use Policy (1 strona):

• „Korzystamy z Workspace AI do pracy wewnętrznej.”

• „Blokujemy konsumenckie AI na urządzeniach firmowych.”

• „Dane ‘Confidential’ / ‘Client’ nie trafiają do AI bez zgody.”

• „Z API mogą korzystać tylko zatwierdzone projekty inżynieryjne.”

2. Klasyfikacja danych + DLP.
Tak, by nawet jeśli ktoś spróbuje wkleić wrażliwe dane, polityka go zatrzyma.

3. RBAC / IAM.
AI ma widzieć tylko to, do czego użytkownik ma uprawnienia.

4. Audyt i monitoring.
By zespół bezpieczeństwa widział wzorce użycia, anomalie i potencjalne nadużycia.

5. Rejestr modeli / promptów.
Centralna lista tego, co jest zatwierdzone - żeby ludzie nie budowali własnych, niebezpiecznych obejść.

To właśnie to sprawia, że AI jest powtarzalnie bezpieczne, a nie tylko „włączyliśmy i liczymy, że będzie dobrze”.

Najważniejszy wniosek

Jeśli zestawisz wszystkie cztery modele obok siebie, komunikat staje się bardzo prosty:

• AI konsumenckie - wygodne, ale niebezpieczne → blokuj.

• AI w Workspace - najszybszy sposób, by dać wszystkim bezpieczne AI → włącz.

• AI przez API - sposób, by wbudować AI w produkty → używaj, ale zabezpiecz swoją część.

• Self-hosted AI - dla nielicznych, przy skrajnych wymaganiach → wybieraj tylko wtedy, gdy naprawdę musisz.

Prawdziwe ryzyko to spędzić miesiące na debacie o Ścieżce 4, podczas gdy cała firma wciąż traci dane przez Ścieżkę 1.
Prawdziwe zwycięstwo to szybko dać ludziom mocne, zarządzane narzędzie, obudować je governance i zamknąć „cienie” Shadow AI.

Tak właśnie korzystasz z mocy AI bez płacenia za nią reputacją, karami regulacyjnymi czy utraconym IP.