Bezpieczne korzystanie z AI

1. Czat AI

Czat AI to najprostsza i najpopularniejsza forma korzystania z dużych modeli językowych: interaktywny model konwersacyjny działający w chmurze dostawcy, z którym rozmawiasz w trybie pytanie-odpowiedź przez przeglądarkę albo aplikację. Piszesz wiadomość (tzw. prompt), model odpisuje, ty dopytujesz — i tak w kółko. Warto od razu zaznaczyć, czym czat NIE jest: to nie jest agent, który samodzielnie klika po systemie, wysyła maile czy operuje na twoich plikach. Poza samą rozmową model nie podejmuje autonomicznych działań. Cała "moc" zamyka się w oknie czatu. (Uwaga: część dostawców dokleja dziś do czatu dodatki — wyszukiwanie w sieci, wtyczki czy tryby "agentowe" — ale to już nadbudówki nad czystym czatem, a nie jego domyślne działanie.)

Mechanika jest prosta, ale kluczowa dla oceny ryzyka: wszystko, co wpiszesz w prompt — łącznie z wklejonymi dokumentami, fragmentami kodu, danymi klientów czy zrzutami z systemów — jest wysyłane na serwery dostawcy i tam przetwarzane. Model nie działa lokalnie na twoim komputerze; twój komputer tylko wyświetla interfejs. To oznacza, że decyzja "co wkleić do czatu" jest w praktyce decyzją "co wysłać firmie zewnętrznej". Dla osoby prywatnej to zwykle akceptowalne, dla małej firmy przetwarzającej dane klientów, umowy czy tajemnice handlowe — to już świadomy wybór, który powinien być przemyślany (a przy danych osobowych bywa też pytaniem o RODO i o to, gdzie fizycznie stoją serwery).

Gdzie te dane trafiają dalej i jak długo żyją, zależy od konkretnego dostawcy, wybranego planu i ustawień konta. W zależności od tych czynników rozmowy mogą (ale nie muszą) być wykorzystywane do trenowania kolejnych wersji modelu, a część z nich bywa przeglądana przez ludzi w ramach moderacji i kontroli nadużyć. Plany biznesowe i firmowe zwykle domyślnie wyłączają trening na twoich danych i dają dodatkowe gwarancje umowne, darmowe konta bywają pod tym względem bardziej "otwarte". Trzeba przy tym pamiętać, że "brak treningu" to nie to samo co "brak przechowywania" — nawet gdy dane nie idą na trening, rozmowy zwykle i tak są przez jakiś czas logowane (nadużycia, wymogi prawne). To nie jest teoria spiskowa ani powód do paniki — to normalny model działania usługi chmurowej, który trzeba po prostu znać i pod niego dostosować swoje nawyki.

Z perspektywy bezpieczeństwa czat AI traktuj więc jak bardzo kompetentnego, ale zewnętrznego konsultanta przez internet: świetny do pisania, nauki, tłumaczeń i burzy mózgów, ale nie miejsce na hasła, klucze API, dane osobowe klientów czy poufne dokumenty, których nie wysłałbyś zwykłym mailem do obcej firmy. Do tego dochodzi druga pułapka, niezależna od prywatności: model potrafi odpowiadać pewnym tonem rzeczy, które są po prostu nieprawdziwe (halucynacje) — dotyczy to też odpowiedzi z podanymi "źródłami", które czasem bywają zmyślone lub niepasujące. Dlatego odpowiedzi z czatu warto weryfikować wszędzie tam, gdzie liczą się fakty, a nie tylko forma.

2. Agent AI

Agent AI to nie kolejny czatbot, tylko model językowy (LLM) osadzony w pętli działania. Zamiast wyłącznie odpowiadać na pytania, agent najpierw planuje kroki, potem sięga po narzędzia — przeglądarkę, terminal, API, pliki, interpreter kodu — wykonuje zadanie etapami, sprawdza wynik i decyduje o kolejnym ruchu. Kluczowe słowo to "akcja": agent nie tylko mówi, co zrobić, ale realnie to robi w Twoim imieniu. To przesuwa go z roli doradcy do roli wykonawcy.

Różnica wobec zwykłego czatu jest fundamentalna i najlepiej widać ją po skutkach ubocznych. Czat generuje tekst — najgorsze, co Ci zostawi, to zła rada, którą sam oceniasz przed użyciem. Agent operuje na Twoim środowisku: może utworzyć plik, wysłać maila, zmienić rekord w bazie, uruchomić skrypt, zacommitować kod. Człowiek przestaje być pośrednikiem między pomysłem modelu a jego wykonaniem, a to właśnie ten pośrednik dotąd wyłapywał błędy. Dlatego przy agencie liczy się nie tylko jakość odpowiedzi, ale to, do czego dokładnie ma dostęp i co może nieodwracalnie zmienić.

Technicznie agent działa w powtarzalnym cyklu: dostaje cel, rozbija go na kroki, wybiera narzędzie, wykonuje je, czyta wynik (treść strony, zawartość pliku, kod błędu, odpowiedź API) i na tej podstawie planuje dalej — aż uzna zadanie za skończone lub utknie. Ta zdolność do czytania świata zewnętrznego jest jego siłą, ale ma dwie ciemne strony. Pierwsza: model traktuje napotkane treści jako kontekst, a spreparowana strona, plik czy mail może zawierać ukryte polecenia (prompt injection), które agent potraktuje jak instrukcję od Ciebie — i użyje własnych narzędzi (maila, API, sieci), żeby wynieść Twoje dane na zewnątrz. Dane z internetu i od osób trzecich nie są zaufane, a agent domyślnie tego nie odróżnia. Druga: w wieloetapowej pętli błędy się kumulują — pomyłka w jednym kroku pociąga za sobą kolejne, a agent potrafi się zapętlić albo "dorobić" nieistniejący fakt, żeby domknąć zadanie.

Z perspektywy prywatności i kontroli nad danymi agent to jednocześnie największa dźwignia i największe ryzyko. Żeby wykonać sensowną pracę, musi dostać dostęp do jakiegoś fragmentu Twojego świata: repozytorium, skrzynki, dysku, konta w SaaS. Każdy taki dostęp to poszerzenie powierzchni ataku i potencjalny kanał wycieku. Dla jednej osoby i dla małej firmy to nie jest argument, żeby z agentów rezygnować — to argument, żeby wpuszczać je świadomie: nadawać minimum uprawnień (least-privilege), uruchamiać w sandboksie lub na kopii, a wszystkie akcje nieodwracalne (wysyłka, usunięcie, płatność, publikacja) zostawiać do zatwierdzenia przez człowieka (human-in-the-loop). Agent ma robić za Ciebie nudną robotę, a nie podejmować za Ciebie decyzji, których nie da się cofnąć.

Jaki agent do czego

3. Własny model AI na PC + agent

Lokalny model AI to po prostu model językowy uruchamiany na Twoim własnym sprzęcie — laptopie, stacji roboczej albo serwerze w firmie — zamiast w chmurze dostawcy. Cała różnica sprowadza się do tego, gdzie fizycznie odbywa się przetwarzanie. Gdy pytasz chmurowy czat, Twój tekst (a często i wgrywane pliki) leci na cudze serwery. Przy modelu lokalnym prompt, odpowiedź i dokumenty zostają na Twojej maszynie. Nic nie wychodzi na zewnątrz, jeśli sam tego nie skonfigurujesz.

Powodów, żeby to robić lokalnie, jest kilka i są konkretne. Prywatność i kontrola nad danymi — wrażliwe dane klientów, kod, umowy czy notatki nie trafiają do żadnej firmy trzeciej, co upraszcza (choć samo w sobie nie załatwia) kwestie RODO i tajemnicy przedsiębiorstwa. Działanie offline — model liczy bez internetu, więc sprawdza się w odizolowanym środowisku albo tam, gdzie łącze bywa zawodne. Brak opłat per token — płacisz raz za sprzęt i prąd, a potem generujesz tyle, ile chcesz, bez licznika bijącego przy każdym zapytaniu. I pełna kontrola: sam wybierasz model i jego wersję, nic Ci się nie zmieni z dnia na dzień, nie ma nagłej zmiany polityki dostawcy, cenzury promptów ani vendor lock-inu.

Bez ściemy: to nie jest darmowy obiad. Modele, które zmieścisz na typowym pececie, rozumują słabiej i gorzej korzystają z narzędzi niż najlepsze modele chmurowe — trzeba realistycznie dobrać zadania. Potrzebujesz też przyzwoitego GPU albo dużo RAM-u, a utrzymanie (aktualizacje, konfiguracja, rachunek za prąd) spada na Ciebie. Trzeba też pamiętać, że lokalny nie znaczy automatycznie bezpieczny — serwer modelu i pobierane pliki wymagają takiej samej higieny co każda inna usługa. Dla wielu zastosowań — streszczanie dokumentów, pomoc w kodzie, klasyfikacja, robocze redagowanie tekstów — lokalny model jest już jednak w zupełności wystarczający, a dane w całości zostają u Ciebie.

Agent na lokalnym modelu

Lokalny model to nie tylko okienko czatu — można na nim postawić agenta, czyli AI, które samo wykonuje zadania i korzysta z narzędzi. Najprostsza droga to wtyczka do programowania: Cline albo Continue w VS Code wskazany na lokalny endpoint Ollamy — asystent czyta i pisze kod bez wysyłania repozytorium do chmury. Do automatyzacji procesów nadaje się n8n z krokiem AI podpiętym pod lokalny endpoint (np. "przeczytaj maila, sklasyfikuj, zapisz do bazy"). Open WebUI potrafi udostępniać modelowi narzędzia i wyszukiwanie, a jeśli budujesz coś własnego, frameworki jak LangChain czy CrewAI spokojnie działają na lokalnym API zgodnym z OpenAI — z ich perspektywy Twój Ollama wygląda jak zwykły dostawca. Trzeba jednak trzymać oczekiwania w ryzach: mniejsze modele lokalne słabiej rozumują i wyraźnie gorzej używają narzędzi (wywołań funkcji) niż topowe modele chmurowe, więc agent bywa mniej niezawodny i wymaga prostszych, dobrze opisanych zadań. Do tego dochodzi sprzęt — sensowny tool-use i dłuższy kontekst wymagają przyzwoitego GPU oraz sporo RAM-u/VRAM-u. I jeszcze jedno z perspektywy bezpieczeństwa: agent to model, który realnie sięga do plików, sieci i poleceń — trzymaj jego uprawnienia wąsko, a lokalny endpoint na localhost lub za autoryzacją, bo inaczej otwierasz sobie furtkę we własnej sieci.

4. Higiena pracy z komercyjnymi modelami AI

Kiedy korzystasz z komercyjnego, chmurowego modelu AI — ChatGPT, Claude, Gemini czy dowolnego innego dostępnego przez przeglądarkę albo API — musisz przyjąć jedno założenie: wszystko, co wpiszesz w okno rozmowy, opuszcza twój komputer i ląduje na cudzych serwerach. To nie jest kalkulator działający lokalnie. To usługa, w której twój tekst jest przesyłany, przetwarzany, a często również przechowywany przez jakiś czas po stronie dostawcy. Zależnie od planu i ustawień może zostać użyty do trenowania kolejnych wersji modelu, a fragmenty rozmów bywają przeglądane przez ludzi w ramach moderacji i kontroli jakości. To nie teoria spiskowa, tylko standardowa mechanika tych usług — i punkt wyjścia do każdej sensownej higieny pracy.

Z tego wynika prosta zasada przewodnia: traktuj czat z modelem AI tak, jakbyś rozmawiał z zewnętrznym wykonawcą, którego nie znasz i nie masz jak zweryfikować. Nie powiedziałbyś takiej osobie hasła do firmowej poczty ani nie podesłał bazy klientów „żeby coś sprawdziła". Ten sam odruch obowiązuje wobec modelu. Druga strona medalu to zaufanie do odpowiedzi: model potrafi zmyślać w sposób gładki i przekonujący — wymyślone przepisy prawne, nieistniejące funkcje bibliotek, błędne wyliczenia podane z pełną pewnością siebie. Wyjście z modelu to punkt startu do weryfikacji, nie gotowy werdykt.

Dla małej firmy dochodzi jeszcze wymiar prawny i organizacyjny. Wrzucanie danych osobowych klientów do darmowego konta konsumenckiego to w praktyce powierzenie przetwarzania danych podmiotowi, z którym nie masz podpisanej umowy powierzenia (DPA) — a regulamin konta konsumenckiego takiej umowy w rozumieniu art. 28 RODO nie zastępuje. Rozwiązaniem nie jest zakaz używania AI (i tak będą go używać, tyle że po kryjomu), lecz świadome ramy: odpowiednie plany, jasna polityka, anonimizacja danych i nawyk weryfikacji. Poniższe zasady to minimum, od którego warto zacząć.

1. Nigdy nie wklejaj sekretów — Hasła, klucze API, tokeny dostępowe, dane logowania, klucze prywatne — to wszystko wychodzi na serwer dostawcy i może zostać zapisane w logach lub w historii rozmowy. Jeśli jakikolwiek sekret trafił do czatu, potraktuj go jak ujawniony i wymień (rotacja klucza, zmiana hasła).
2. Nie wysyłaj PII, danych klientów ani materiałów pod NDA — Dane osobowe, dokumentacja klientów, tajemnice firmowe, treści objęte umową o poufności — nic z tego nie powinno trafić do modelu konsumenckiego. Nie masz kontroli nad tym, gdzie i jak długo to zostanie, ani kto to zobaczy. Pamiętaj też o funkcjach „pamięci" i zapisanej historii, które utrwalają twoje dane między rozmowami — one też są miejscem, gdzie wrażliwe treści zostają na dłużej.
3. Anonimizuj i pseudonimizuj przed wysłaniem — Jeśli musisz przeanalizować realny przypadek, usuń lub zamień nazwiska, adresy, numery, nazwy firm i inne identyfikatory na zastępniki. Model zwykle świetnie poradzi sobie z problemem opisanym abstrakcyjnie, bez prawdziwych danych.
4. Sprawdź i wyłącz użycie rozmów do treningu (opt-out) — Część usług domyślnie wykorzystuje twoje rozmowy do trenowania kolejnych modeli. W ustawieniach konta zwykle da się to wyłączyć — zrób to. To nie eliminuje ryzyka wycieku, ale ogranicza, gdzie twoje treści trafiają na stałe.
5. Do danych firmowych używaj planów biznesowych/enterprise — Plany biznesowe/enterprise domyślnie nie używają twoich treści do trenowania modeli i pozwalają podpisać umowę powierzenia przetwarzania (DPA) — to podstawa zgodnego z RODO przetwarzania danych klientów. Ważna różnica: „brak trenowania na danych" to nie to samo co „zero data retention" (ZDR). Nawet plany firmowe zwykle przechowują treści przez pewien czas (np. na potrzeby wykrywania nadużyć); pełne ZDR, czyli nieprzechowywanie treści w ogóle, to zazwyczaj osobne ustalenie (często dostępne dla API po wniosku). Darmowe konto konsumenckie nie daje żadnej z tych gwarancji.
6. Pamiętaj o RODO przy danych osobowych — Wrzucenie danych osobowych klientów do chmury AI to przetwarzanie danych z konkretnymi konsekwencjami prawnymi: potrzebna podstawa prawna, umowa powierzenia (DPA) i kontrola nad tym, gdzie dane są przetwarzane (również poza UE/EOG). Bez tego narażasz firmę na realne ryzyko.
7. Traktuj każde wyjście jako niezweryfikowane — Modele halucynują — podają zmyślone fakty, nieistniejące przepisy, błędne cytaty i wyliczenia, robiąc to w pełni przekonującym tonem. Weryfikuj fakty, kod, liczby i źródła w niezależnych, wiarygodnych miejscach, zanim się na nich oprzesz.
8. Uważaj na prompt injection — Nie każ modelowi ślepo wykonywać instrukcji zawartych w niezaufanych treściach — stronach WWW, plikach, mailach. Ukryty w takiej treści tekst może przejąć zachowanie modelu (np. skłonić go do wysłania danych albo wykonania niechcianej akcji). Instrukcje niech pochodzą od ciebie, treść zewnętrzna to tylko dane. Ryzyko rośnie, gdy model ma dostęp do narzędzi i integracji.
9. Ostrożnie z wtyczkami, integracjami i „działaniami" — Wtyczki, konektory i funkcje agentowe (dostęp do poczty, plików, przeglądarki, zewnętrznych API) znacząco rozszerzają powierzchnię ataku. Każda integracja to nowe uprawnienie i nowe ryzyko — włączaj tylko te, których faktycznie potrzebujesz, i sprawdzaj, do czego mają dostęp.
10. Rób code review kodu wygenerowanego przez AI — Wygenerowany kod potrafi zawierać luki bezpieczeństwa, przestarzałe wzorce, podatności typu wstrzyknięcie SQL czy błędną obsługę danych wejściowych. Czytaj go tak samo krytycznie jak kod od nowego, niesprawdzonego programisty — nie wrzucaj na produkcję bez przeglądu.
11. Osobne konta i role, bez współdzielenia — Każdy pracownik powinien mieć własne konto, a dostępy nadawane według ról. Współdzielone logowanie uniemożliwia audyt, miesza historie rozmów i utrudnia odcięcie dostępu po odejściu osoby z firmy.
12. Wprowadź politykę użycia AI oraz logowanie i audyt — W firmie spisz jasne zasady: co wolno, a czego nie wolno wrzucać do modeli, z jakich narzędzi korzystać i na jakich planach. Dołóż do tego logowanie i okresowy przegląd użycia — inaczej nie masz pojęcia, jakie dane naprawdę wychodzą z organizacji.
13. Zakładaj, że rozmowy bywają przeglądane przez ludzi — Dostawcy w ramach moderacji i oceny jakości mogą kierować fragmenty rozmów do przeglądu przez pracowników lub podwykonawców. Pisz z założeniem, że po drugiej stronie ekranu może usiąść człowiek — i nie wysyłaj niczego, czego nie chciałbyś pokazać obcej osobie. Na planach enterprise z ZDR taki przegląd przez ludzi jest zwykle wyłączony, ale nie zakładaj tego bez sprawdzenia w umowie.
14. Nie oddawaj AI decyzji prawnych, medycznych i finansowych — Model może pomóc uporządkować temat i przygotować pytania, ale nie zastąpi prawnika, lekarza ani doradcy. W sprawach o realnych konsekwencjach zawsze weryfikuj wynik u wykwalifikowanego eksperta — odpowiedzialność za decyzję zostaje po twojej stronie.

5. Co wybrać kiedy

• › Dane niewrażliwe, jednorazowe zadanie tekstowe (pisanie, nauka, tłumaczenie, burza mózgów): użyj czatu chmurowego — zero konfiguracji, najmocniejsze modele, a najgorszy skutek to zła rada, którą i tak sam oceniasz. Wynik weryfikuj wszędzie tam, gdzie liczą się fakty.
• › Dane firmowe lub osobowe klientów, ale nadal tryb rozmowy: czat, ale wyłącznie na planie biznesowym/enterprise z podpisaną umową powierzenia (DPA) i wyłączonym treningiem — nigdy na darmowym koncie konsumenckim. Zawsze najpierw anonimizuj to, co się da.
• › Trzeba realnie wykonać wieloetapową pracę na Twoich systemach (kod, automatyzacja, research z akcjami): agent — ale z least-privilege, w sandboksie lub na kopii, a każdą akcję nieodwracalną (wysyłka, usunięcie, płatność, publikacja) zostaw do zatwierdzenia przez człowieka.
• › Dane wrażliwe, poufne lub objęte tajemnicą, których nie chcesz nigdzie wysyłać, albo praca offline: model lokalny (Ollama/LM Studio) — nic nie wychodzi na zewnątrz. Zaakceptuj słabsze rozumowanie i utrzymanie sprzętu po swojej stronie, a endpoint trzymaj na localhost lub za autoryzacją.
• › Zasada nadrzędna niezależnie od formy: im wrażliwsze dane, tym bliżej lokalnego końca skali; im prostsze i mniej ryzykowne zadanie, tym spokojniej możesz sięgnąć po czat chmurowy. Nie ma jednego dobrego wyboru — jest dopasowanie do wrażliwości danych i charakteru zadania.

6. Co dalej — warto zgłębić

1. Prompt injection w praktyce — jak wygląda i jak się bronić — To najważniejsze, specyficzne dla AI zagrożenie przy agentach i integracjach; warto pokazać realny scenariusz (ukryte polecenie w mailu/stronie) i konkretne mechanizmy obrony: rozdział treści zaufanej od niezaufanej, least-privilege, human-in-the-loop.
2. Weryfikacja odpowiedzi i halucynacje — metody sprawdzania — Halucynacje dotyczą też zmyślonych źródeł i cytatów. Praktyczny warsztat (jak krzyżowo weryfikować fakty, kod, liczby, kiedy nie ufać nawet podanym linkom) jest konkretny i użyteczny dla każdego czytelnika.
3. Pochodzenie modeli i łańcuch dostaw — skąd brać wagi i pliki GGUF — Przy modelach lokalnych pobierasz wagi z zewnętrznych repozytoriów; warto omówić zaufane źródła, ryzyko zatrutych/zmodyfikowanych wag, weryfikację sum kontrolnych i licencje modeli (co wolno komercyjnie).
4. RODO i dane osobowe klientów w praktyce małej firmy — Konkretne obowiązki: podstawa prawna, umowa powierzenia (DPA), transfery poza EOG, różnica między brakiem treningu a zero data retention. To realne ryzyko prawne, które dotyczy odbiorcy PivLab bezpośrednio.
5. RAG lokalnie — własna baza wiedzy bez wysyłania dokumentów do chmury — Praktyczny sposób na pytania do umów, procedur i dokumentacji firmowej z zachowaniem prywatności; warto pokazać, jak połączyć lokalny model z własnymi plikami i jakie są granice tej metody.
6. Least-privilege i human-in-the-loop dla agentów — jak to wdrożyć — Sama zasada jest powtarzana, ale czytelnik potrzebuje konkretów: jak nadawać wąskie uprawnienia, jak uruchamiać w sandboksie/na kopii, gdzie wstawiać punkty zatwierdzania i jak audytować ciąg akcji agenta.
7. Bezpieczeństwo kodu generowanego przez AI — Wygenerowany kod bywa podatny (wstrzyknięcia, złe walidacje, przestarzałe wzorce). Warto dać checklistę code review pod kątem bezpieczeństwa i przykłady typowych błędów, których nie wolno wrzucać na produkcję.
8. Vendor lock-in, koszty i przewidywalność — Zależność od dostawcy (ceny, regulamin, dostępność modelu) i skokowy koszt tokenów przy agentach to realne ryzyko biznesowe. Warto porównać model kosztowy chmury vs. inwestycja w sprzęt lokalny.
9. Deepfake i socjotechnika wspierana AI — Rozszerza model zagrożeń poza własne narzędzia użytkownika: podrobiony głos/wideo szefa, spersonalizowany phishing. Dla firmy to bezpośrednie ryzyko oszustwa i warto dać zasady weryfikacji tożsamości.
10. Air-gap i sieć wydzielona dla wrażliwych wdrożeń AI — Dla najbardziej wrażliwych zastosowań warto pokazać, jak fizycznie/logicznie odseparować środowisko AI (brak egressu, VLAN, brak dostępu do internetu) i kiedy taki poziom izolacji ma sens.