„Chcemy AI, ale nie możemy wysyłać dokumentów klientów do losowego czatu.” – słyszymy to często w regulowanych branżach. I słusznie. Ten artykuł odpowiada wprost: gdzie są dane, kto je widzi, czy idą na trening modelu i co mieć na piśmie – krok po kroku.
Dlaczego „bezpieczeństwo AI” to coś więcej niż zwykłe IT?
Co tydzień 1 mail z konkretem
O AI, sprzedaży B2B i wdrożeniach. Bez spamu, wypisujesz się jednym klikiem.
Klasyczne IT chroni miejsca przechowywania – serwery, dyski, konta. AI dodaje warstwę: treść musi być przetworzona przez model, żeby dać odpowiedź. W pewnym momencie fragment dokumentu trafia do systemu obliczeniowego.
Pytanie więc nie brzmi „czy dane trafią do AI” (często trzeba), tylko:
- Gdzie są przetwarzane?
- Kto ma dostęp?
- Czy trafiają na trening?
- Jak długo są przechowywane?
- Co robicie przy błędzie lub incydencie?
Pięć filarów bezpieczeństwa AI w firmie
Filar 1: Lokalizacja i model przetwarzania
Opcja A – publiczna chmura dostawcy (np. konsumencki czat)
Najniższa kontrola. W wariantach darmowych dane mogą być wykorzystywane do ulepszania usług / treningu – zależnie od regulaminu. Plany Teams / Enterprise u dostawców często wyłączają trening, ale dane i tak są na ich infrastrukturze – to trzeba mieć w DPA i polityce.
Opcja B – dedykowana instancja w UE (Azure OpenAI, AWS Bedrock itd.)
Dobre saldo: jakość dużych modelów + region (np. Frankfurt, Amsterdam) + umowy pod RODO. Nadal potrzebujesz DPA i jasnego opisu subprocessora.
Opcja C – własna infrastruktura / on-prem
Maksymalna kontrola geograficzna i sieciowa; wyższy koszt sprzętu (GPU), utrzymania i ekspertyzy. Nie oznacza automatycznie „bezpieczniej niż dobra chmura EU” – własny serwer też trzeba patchować, backupować i monitorować.
Praktycznie: dla wielu firm sensowny jest wariant B z jasnym regionem UE – o ile regulacje nie wymuszają wyłącznie on-prem.
Filar 2: Kto widzi jakie dane? (nie wszyscy mają widzieć wszystko)
| Mechanizm | Po co |
|---|---|
| Role (RBAC) | Partner vs asystent – inny zakres działań i danych. |
| Przestrzenie / projekty | Dokumenty klienta X oddzielone od Y. |
| Dostęp na poziomie pliku | Szczególnie poufne umowy tylko dla wskazanych osób. |
| Dziennik (audit log) | Kto, kiedy, o co pytał i jakie źródła zobaczył. |
Dlaczego to krytyczne przy AI: bez filtrów uprawnień model mógłby zwrócić fragment z cudzej sprawy, jeśli cała baza jest „płaska”. Dobre RAG ogranicza wyszukiwanie do tego, co wolno użytkownikowi.
To wymóg, nie „fajny dodatek”.
Filar 3: Czy dostawca trenuje na Twoich danych?
Orientacyjnie: plany darmowe / konsumenckie częściej zastrzegają możliwość wykorzystania treści do usprawniania usług; plany biznesowe, enterprise i typowe API – zwykle nie używają Twoich treści do treningu – ale nie zgaduj: potrzebujesz klauzuli w umowie / DPA.
Na piśmie powinno być:
DPA (powierzenie przetwarzania), zakaz treningu (jeśli tak ma być), region lub sposób określenia lokalizacji przetwarzania.
Filar 4: Logowanie i dostęp do samego systemu
| Element | Minimum |
|---|---|
| Silne hasła + polityka | Tak. |
| MFA | Tak – w wielu branżach to standard dobrych praktyk, nie „opcja”. |
| Blokada po błędnych logowaniach | Tak. |
| Timeout sesji | Tak (np. przy bezczynności). |
| SSO (opcjonalnie) | Ułatwia zarządzanie w większej organizacji. |
Filar 5: Monitoring i reagowanie
Warto rejestrować m.in.: nieudane logowania, nietypowe zapytania, masowy eksport, zużycie tokenów (koszt i nadużycia). W części branż pełny audyt zapytań jest oczekiwany przez regulatorów lub politykę wewnętrzną.
Checklist przed wdrożeniem
Dane i infrastruktura
- Jasny region (np. UE) lub uzasadniony mechanizm transferu.
- DPA z dostawcą przetwarzania.
- Potwierdzenie braku treningu na Twoich danych (jeśli wymagane).
- Szyfrowanie w spoczynku i w transmisji (standardy branżowe).
- Kopie zapasowe i procedura odtworzenia.
Dostęp
- MFA dla użytkowników.
- Role i minimalne uprawnienia.
- Separacja dokumentów (klient / sprawa / dział).
- Filtrowanie wyników AI wg uprawnień.
- Automatyczne wylogowanie przy bezczynności.
Organizacja
- Aktualna polityka prywatności (u Ciebie: Polityka prywatności) i informacja dla pracowników.
- Procedura incydentów.
Najczęstsze błędy (mówimy wprost)
„Damy firmowe konto ChatGPT – problem z głowy.”
Krok lepszy niż nic, ale nie zastępuje segregacji danych, audytu i architektury pod dokumenty firmowe. Często kolejny krok to kontrolowane środowisko lub RAG z uprawnieniami.
„Postawimy lokalnie – będzie w 100% bezpiecznie.”
Lokalnie też są aktualizacje, dostęp, backupy i ludzie. Często dojrzała chmura EU z dobrym kontraktem bije własny serwer utrzymywany „przy okazji”.
„Zabronimy AI.”
Ludzie i tak użyją prywatnych narzędzi – bez widoczności dla firmy. Lepsza jest świadoma polityka i narzędzie, które jest wygodniejsze i bezpieczniejsze niż obejście.
Podsumowanie
Bezpieczne AI w firmie to głównie: świadomy wybór miejsca przetwarzania, umowy, kontrola dostępu, logi, MFA – i realistyczna ocena, czy konsumencki czat w ogóle wystarczy. Szerszy kontekst narzędzi i kosztów znajdziesz w przewodniku po AI dla firm; przy małych, kontrolowanych krokach warto pamiętać o logice MVP.
Wdrażacie AI w branży z restrykcjami? Napisz lub umów rozmowę – pomożemy przełożyć wymagania na architekturę i dokumentację.
