Nieautoryzowane narzędzia i usługi AI w organizacji — jak ograniczyć ich instalowanie, używanie i dostęp do danych

Pracownik instaluje Claude Desktop, Cursor albo narzędzie z rodziny Codex, aby szybciej przygotować dokument lub napisać kod. Inny wkleja materiały służbowe do Gemini, ChatGPT lub DeepSeek w przeglądarce. Narzędzie pochodzi z oficjalnego źródła, działa poprawnie i nie wywołuje alarmu antywirusa. Nie oznacza to zgody na używanie go do pracy. Instytucja mogła nie ocenić, do jakich plików i usług narzędzie uzyska dostęp, gdzie trafią dane oraz jakie działania wykona na komputerze, koncie użytkownika lub w podłączonych zasobach.

Skuteczna ochrona wymaga połączenia trzech elementów: jasnych zasad, zrozumiałej informacji i technicznego egzekwowania decyzji. Sam zakaz w regulaminie ani samo odebranie praw administratora nie wystarczą.

Opisane rozwiązania dotyczą urzędów, uczelni publicznych i prywatnych oraz innych instytucji. Wymienione produkty są przykładami narzędzi wymagających oceny, a nie listą rozwiązań z definicji niebezpiecznych. Nieautoryzowany oznacza tutaj: niedopuszczony do określonego zastosowania przez daną instytucję.

Artykuł jest skierowany do osób odpowiedzialnych za bezpieczeństwo, zarządzanie urządzeniami, ochronę danych i organizację pracy. Przedstawia model postępowania, a nie instrukcję konfiguracji konkretnego produktu.

Stan weryfikacji źródeł: 25 września 2026 r. Proponowany model organizacyjny i harmonogram są rekomendacjami autora. Funkcje produktów zależą od wersji, systemu operacyjnego i planu licencyjnego.

Trzeba kontrolować używanie, a nie tylko instalowanie

Zakaz instalacji obejmuje tylko część problemu. Oprogramowanie może działać z katalogu użytkownika, jako aplikacja przenośna, rozszerzenie przeglądarki lub edytora, narzędzie wiersza poleceń albo skrypt uruchamiany przez dostępne środowisko wykonawcze. Usługi AI można również wykorzystywać przez przeglądarkę, bez instalowania dodatkowego programu.

Dlatego instytucja powinna objąć zasadami instalowanie, uruchamianie, dodawanie rozszerzeń, łączenie usług i przekazywanie danych. Zgoda na jedną postać narzędzia nie powinna automatycznie oznaczać zgody na wszystkie pozostałe.

Zgoda na czat do redagowania materiałów publicznych nie obejmuje automatycznie dostępu do poczty, repozytorium czy dysku sieciowego. Osobnej oceny wymagają też serwery Model Context Protocol (MCP) — komponenty udostępniające aplikacji dodatkowe zasoby i funkcje.^[5]

Środki organizacyjne: kto decyduje i na jakich warunkach

Katalog zatwierdzonych narzędzi

Punktem wyjścia jest ustalenie, jakie oprogramowanie faktycznie działa na urządzeniach oraz z jakich usług AI korzystają użytkownicy, a następnie określenie, które zastosowania są dopuszczone. CIS Controls wskazują inwentaryzację oprogramowania, obsługę oprogramowania nieautoryzowanego oraz kontrolę dozwolonych aplikacji i skryptów jako elementy zarządzania bezpieczeństwem.^[1]

Praktyczny katalog powinien zawierać więcej niż nazwę produktu:

Wpis „Cursor — dozwolony” jest zbyt ogólny. Znacznie użyteczniejsze jest dopuszczenie go określonej grupie programistów, w zarządzanym środowisku, dla wskazanych projektów, z zatwierdzonym kontem i ograniczeniami integracji.

Jasny podział odpowiedzialności

Kierownictwo zatwierdza zasady i wyznacza osobę uprawnioną do akceptacji ryzyka. Właściciel procesu uzasadnia potrzebę. IT ocenia możliwość bezpiecznego wdrożenia i utrzymania. Osoba odpowiedzialna za bezpieczeństwo analizuje zagrożenia oraz zabezpieczenia. IOD doradza w zakresie ochrony danych osobowych; nie należy automatycznie przypisywać mu roli osoby zatwierdzającej każde narzędzie.

Zakupy i obsługa prawna uczestniczą wtedy, gdy wymaga tego umowa, licencja lub charakter przetwarzania. Bezpłatne narzędzie też wymaga oceny: brak faktury nie oznacza braku zobowiązań ani ryzyka.

Sprawna procedura zgłoszenia potrzeby

Pracownik powinien mieć jeden formularz lub kanał zgłoszeń. Wniosek powinien odpowiadać na pytania: do czego potrzebne jest narzędzie, kto będzie z niego korzystać, jakie dane przetworzy, do czego uzyska dostęp i dlaczego nie wystarcza rozwiązanie już zatwierdzone.

Warto ustalić mierzalny termin pierwszej odpowiedzi, np. trzy dni robocze. Jest to przykładowy standard obsługi, a nie termin ustawowy ani obietnica zakończenia całej oceny. Jeśli instytucja tygodniami nie odpowiada, zwiększa motywację do obchodzenia procedur.

Wyjątki z terminem i właścicielem

Wyjątek powinien określać użytkowników, urządzenia, dane, zabezpieczenia, termin wygaśnięcia i osobę akceptującą ryzyko. „Zgoda dla działu IT bez ograniczeń” nie jest dobrym wyjątkiem.

Na uczelni warto rozdzielić stanowiska administracyjne, pracownie dydaktyczne i środowiska badawcze. Potrzeba testowania nowych narzędzi przemawia za wydzielonym środowiskiem z kontrolowanymi danymi i siecią, a nie za nieograniczonym dostępem do zasobów całej uczelni.

Środki informacyjne: pracownik musi wiedzieć, co zrobić

Krótka instrukcja powinna odpowiadać na pięć pytań:

1. Gdzie sprawdzę, czy narzędzie jest dopuszczone?
2. Jak uzyskam zgodę na nowe narzędzie lub integrację?
3. Jakich danych nie wolno do niego przekazywać?
4. Co zrobić, gdy program został już zainstalowany lub uzyskał dostęp do plików?
5. Jak zgłosić podejrzenie ujawnienia danych?

Szkolenie powinno opierać się na zadaniach wykonywanych w instytucji. W administracji uczelni będą to np. dokumenty studentów, sprawy pracownicze i projekty umów. W zespole programistycznym — kod, klucze API, konfiguracja infrastruktury i kopie baz danych. Publiczny opis projektu i plik zawierający dane osobowe wymagają odmiennej oceny.

Pracownik powinien usłyszeć wprost: oficjalny sklep, podpis cyfrowy, popularność produktu ani prywatnie opłacony abonament nie zastępują zgody instytucji. Deklaracja niewykorzystywania danych do trenowania modeli również nie odpowiada na wszystkie pytania o ich przesyłanie, przechowywanie i dostęp.

Komunikat blokady powinien wskazywać powód i drogę rozwiązania: „Ta aplikacja nie jest dopuszczona na tym urządzeniu. Sprawdź katalog narzędzi lub zgłoś potrzebę przez helpdesk”. Ogólny błąd techniczny zachęca do kolejnych prób.

Warto zachęcać do szybkiego zgłaszania pomyłek i oddzielać przyjęcie zgłoszenia od późniejszej oceny odpowiedzialności. Nie należy obiecywać bezwarunkowej bezkarności, ale strach przed zgłoszeniem nie powinien utrudniać ograniczenia skutków zdarzenia.

Środki techniczne: warstwy, które się uzupełniają

Standardowe konto użytkownika

Do codziennej pracy należy używać konta bez stałych lokalnych praw administratora, również w dziale IT. Czynności administracyjne wymagają oddzielnego konta lub kontrolowanego, czasowego podniesienia uprawnień. Aplikacje działające bez takich praw nadal mogą uzyskać dostęp do danych użytkownika.

Kontrola uruchamiania aplikacji

Dla typowych stanowisk biurowych rekomendowany jest model: uruchamiać można zatwierdzone oprogramowanie, pozostałe jest blokowane. W Windows służą temu m.in. App Control for Business i AppLocker. Microsoft rozróżnia ich możliwości i wskazuje App Control dla scenariuszy wymagających silniejszej ochrony.^[2]

Reguły muszą obejmować właściwe typy plików i pakietów. Sama nazwa pliku jest niewystarczająca, a zbyt szerokie zaufanie do wydawcy może dopuścić jego inne produkty. Wyjątki pozwalające uruchamiać wszystko z katalogów zapisywalnych przez użytkownika mogą podważyć ochronę. Możliwości mechanizmów zależą od wersji systemu i sposobu zarządzania.^[2][4]

Tryb audytu nie blokuje aplikacji. Pomaga zebrać zdarzenia do przygotowania reguł. Wdrożenie powinno obejmować audyt, ocenę wykrytych programów, pilotaż blokowania i stopniowe rozszerzanie ochrony. Automatyczne dopuszczenie wszystkiego z logów może zalegalizować istniejące nieautoryzowane oprogramowanie.^[3]

Dystrybucja i aktualizacje

Aplikacje powinny trafiać na urządzenia przez IT lub firmowy katalog samoobsługowy. Kontroli wymagają także sklepy i menedżery pakietów. Polityka musi uwzględniać zmiany plików, podpisów i zachowania po aktualizacji oraz pilne dopuszczanie poprawek bezpieczeństwa. Blokady nie mogą prowadzić do utrzymywania podatnych wersji.

Rozszerzenia i środowiska programistyczne

Rozszerzenia przeglądarek i edytorów wymagają oddzielnej listy dopuszczeń oraz kontroli instalacji spoza zatwierdzonych źródeł. Zgoda na aplikację bazową nie obejmuje automatycznie jej dodatków.

Dopuszczenie interpretera Pythona albo środowiska Node.js nie oznacza automatycznie, że wszystkie uruchamiane skrypty są zatwierdzone. Podobnie kontrola systemu gospodarza nie daje pełnej kontroli kodu w WSL, kontenerach i maszynach wirtualnych.

Na stanowiskach biurowych należy ograniczać zbędne możliwości wykonywania kodu. Programistom warto zapewnić wydzielone środowiska z kontrolą poświadczeń, sieci i dostępu do produkcji. Jedna polityka dla księgowości i programistów może być nieskuteczna i uciążliwa.

Usługi internetowe i dane

Kontrolę aplikacji uzupełnia zarządzanie przeglądarkami, usługami i kontami. Zależnie od ryzyka można stosować filtrowanie DNS, bramę bezpiecznego dostępu do internetu, kontrolę aplikacji chmurowych oraz mechanizmy zapobiegania wyciekom danych (DLP).

Każda warstwa ma ograniczenia: blokada strony pobierania nie zatrzyma już zainstalowanego programu, a sam filtr domen nie pozwoli ustalić, jakie dane zostały przesłane. DLP może przeoczyć informacje poufne lub wygenerować fałszywy alarm. Inspekcja szyfrowanego ruchu wymaga oceny prywatności, zgodności i kompatybilności z aplikacjami.

Trzeba sprawdzić działanie ochrony laptopów poza siedzibą, w tym na hotspotach i bez połączenia z systemem zarządzania. Filtr działający tylko w sieci instytucji nie wystarczy.

Antywirus, EDR i inne systemy operacyjne

Legalny, nieautoryzowany program może nie wywołać alarmu antywirusa. System klasy EDR (Endpoint Detection and Response), służący do wykrywania i obsługi zagrożeń na urządzeniach, może dostarczać informacji o procesach i połączeniach. Jego zdolność do zapobiegania zdarzeniom zależy od dostępnych funkcji i konfiguracji.

W macOS i Linux trzeba zaprojektować analogiczne warstwy ochrony. Samo zarządzanie urządzeniem, weryfikacja podpisu czy kontrola repozytorium pakietów nie zapewniają kompletnej listy dozwolonego oprogramowania.

Jak oceniać popularne narzędzia AI

Dla każdego produktu należy zastosować ten sam zestaw pytań. Tabela jest schematem oceny, a nie deklaracją, że wszystkie wymienione funkcje występują w każdym narzędziu.

Claude Desktop. Anthropic dokumentuje systemowe polityki dotyczące m.in. organizacji, w której użytkownik może się logować, rozszerzeń oraz lokalnych serwerów MCP. Należy osobno ocenić udostępnione foldery i funkcje wykonawcze.^[5]

Cursor. Dokumentacja opisuje ograniczenia dozwolonych zespołów i rozszerzeń oraz centralne ustawienia bezpieczeństwa. Ocena powinna objąć także modele, klucze API, repozytoria i uprawnienia agenta.^[6][7]

Codex. Trzeba rozróżnić aplikację desktopową, narzędzie wiersza poleceń (CLI), rozszerzenie środowiska programistycznego (IDE) oraz zadania wykonywane w chmurze. Nie należy przenosić ustaleń o zabezpieczeniach jednego wariantu na pozostałe. OpenAI opisuje wymagania administratora, izolację i telemetrię we własnym wdrożeniu.^[8] Ten opis nie dowodzi dostępności wszystkich mechanizmów w każdym planie i środowisku klienta. Punktem odniesienia dla konkretnych ustawień jest również dokumentacja konfiguracji.^[12]

Ustawienie zmieniane przez użytkownika nie jest równoważne polityce wymuszanej centralnie. Instrukcja przekazana agentowi, np. „nie otwieraj plików kadrowych”, nie zastępuje uprawnień. Danych i poświadczeń zbędnych do zadania najlepiej w ogóle nie udostępniać jego środowisku.

Google, Microsoft i AI w pakietach biurowych

Google Gemini oraz Gemini Notebook, wcześniej NotebookLM. Ocena powinna rozróżniać konto prywatne, zarządzane konto Workspace lub Education i usługi deweloperskie, takie jak Google AI Studio. Google ogranicza zakres swojego centrum prywatności Workspace do wskazanych usług i odpowiednich edycji. Nie wolno przenosić tych zapewnień na każdą usługę dostępną po zalogowaniu kontem Google.^[13] W rejestrze warto zachować zarówno aktualną, jak i wcześniejszą nazwę produktu, aby nie zgubić historycznych zgłoszeń.^[14]

Przed dopuszczeniem trzeba sprawdzić możliwość włączenia usługi dla określonych grup, zakres dostępu do dokumentów i zasady udostępniania materiałów. Wgranie wewnętrznych dokumentów do narzędzia badawczego jest odrębnym zastosowaniem od opracowywania ogólnodostępnych źródeł. Zgoda na korzystanie z Dysku Google nie oznacza zgody na udostępnianie jego zawartości każdej funkcji AI.

Microsoft Copilot i GitHub Copilot. Należy oddzielić wariant konsumencki, usługę używaną w kontekście służbowym Microsoft 365 oraz narzędzia programistyczne GitHub Copilot. Microsoft opisuje ochronę danych przedsiębiorstwa w ramach określonych zobowiązań umownych i technicznych; nie jest to uniwersalna gwarancja dla wszystkich produktów noszących nazwę Copilot.^[15][16] W ocenie warto sprawdzić konto, licencję, dodatki, agentów i dostęp do dokumentów. Nadmierne uprawnienia do zasobów pozostają problemem także po wdrożeniu AI. Osobnej weryfikacji wymagają zapytania wysyłane do wyszukiwarki internetowej oraz agenci korzystający z dodatkowych usług: mogą podlegać innym warunkom przetwarzania niż zasadnicza usługa organizacyjna.^[15]

W GitHub Copilot trzeba odróżniać subskrypcje indywidualne od Business i Enterprise. Dokumentacja wskazuje odmienne zasady wykorzystania danych do trenowania oraz zarządzania ustawieniami: w planach indywidualnych użytkownik może wyłączyć wykorzystanie interakcji do treningu, natomiast dane Business i Enterprise są objęte zobowiązaniem zakazującym takiego wykorzystania bez upoważnienia klienta. Prywatny abonament nie zastępuje wdrożenia zarządzanego przez organizację.^[16]

Funkcja AI w zatwierdzonym programie również wymaga oceny. Aktualizacja edytora, przeglądarki, komunikatora lub platformy spotkań może dodać transkrypcję, podsumowania albo analizę dokumentów. Dotychczasowa zgoda na aplikację nie powinna automatycznie obejmować nowego sposobu przetwarzania danych.

Usługi chińskich dostawców i modele pochodzące z Chin

Do katalogu rozpatrywanych narzędzi należy włączyć m.in. DeepSeek, Qwen i Kimi. Lista nie jest rankingiem popularności ani bezpieczeństwa i powinna być uzupełniana na podstawie faktycznych zgłoszeń i wykryć w instytucji.^[17][18][19]

Kraj pochodzenia dostawcy jest elementem oceny, ale nie wystarcza do rozstrzygnięcia o dopuszczeniu. Trzeba ustalić podmiot świadczący usługę, jurysdykcję, miejsca przetwarzania, podwykonawców, retencję, wykorzystanie danych oraz dostępne zabezpieczenia. DeepSeek w polityce prywatności usług objętych tym dokumentem wskazuje przetwarzanie i przechowywanie danych osobowych w Chińskiej Republice Ludowej. To konkretna okoliczność do oceny, a nie podstawa do przypisywania identycznych praktyk wszystkim chińskim produktom.^[17]

Należy rozróżnić trzy sytuacje:

• używanie publicznej aplikacji lub API dostawcy;
• korzystanie z modelu przez innego operatora, np. dostawcę chmury;
• uruchomienie udostępnionego modelu we własnym środowisku.

W drugim wariancie trzeba zbadać rzeczywisty łańcuch przetwarzania. Sama obecność modelu DeepSeek, Qwen lub Kimi w katalogu europejskiego dostawcy chmurowego nie przesądza, że dane są przekazywane twórcy modelu. W trzecim pochodzenie modelu nie oznacza samo w sobie wysyłania zapytań do jego twórcy, ale trzeba zweryfikować kod, telemetrię, aktualizacje, integracje i połączenia wychodzące. Lokalny model nie jest automatycznie bezpieczny.

Jeżeli wykorzystanie usługi wiąże się z przekazywaniem danych osobowych do państwa trzeciego, trzeba ocenić wymagania rozdziału V RODO, niezależnie od narodowości dostawcy. Sama deklaracja zgodności z RODO nie zastępuje tej analizy.^[11] Do czasu wyjaśnienia istotnych braków rekomendowane jest niedopuszczenie danych osobowych i poufnych do danego zastosowania; ewentualny pilotaż powinien wykorzystywać dane syntetyczne lub odpowiednio dobrane materiały publiczne.

Inne narzędzia, które łatwo pominąć

Polityka powinna obejmować także ChatGPT, Perplexity, Grok, narzędzia Mistral, DeepL oraz funkcje AI w Canva. Poniższa tabela wskazuje pytania do oceny, a nie domyślne uprawnienia lub praktyki każdego produktu.

Źródła poniższych przykładów potwierdzają istnienie i ogólny zakres produktów, nie pełne warunki prywatności wszystkich planów. Przed dopuszczeniem trzeba dodatkowo sprawdzić umowę, politykę prywatności i dokumentację ustawień właściwe dla konkretnego wariantu.^{[20][21][22][23][24]} Najczęstszy błąd organizacyjny polega na objęciu zasadami wyłącznie „czatbotów”, mimo że dane trafiają również do tłumaczy, edytorów i asystentów spotkań.

Monitoring musi mieć określony cel i granice

Inwentaryzacja i rejestrowanie zdarzeń powinny być ograniczone do danych potrzebnych do zarządzania bezpieczeństwem. Zwykle warto zaczynać od identyfikatora urządzenia, aplikacji, czasu zdarzenia, użytkownika i wyniku zastosowanej reguły. Pełna treść promptów, dokumentów czy korespondencji wymaga znacznie mocniejszego uzasadnienia.

Pracownicy

Jeśli rozwiązanie stanowi ich monitoring, trzeba ocenić niezbędność i związek z celami z art. 22³ Kodeksu pracy: zapewnieniem organizacji pracy umożliwiającej pełne wykorzystanie czasu pracy oraz właściwego użytkowania narzędzi pracy. Hasło „cyberbezpieczeństwo” nie jest samodzielnym upoważnieniem do dowolnego nadzoru.^[9][10]

Należy określić cel, zakres i sposób monitoringu oraz spełnić obowiązki informacyjne. Art. 22³ odsyła do odpowiedniego stosowania art. 22² § 6–10, w tym poinformowania pracowników nie później niż dwa tygodnie przed uruchomieniem monitoringu i przekazania wymaganych informacji na piśmie przed dopuszczeniem pracownika do pracy. Ochrona tajemnicy korespondencji i dóbr osobistych nadal obowiązuje.^[9]

Pozostali użytkownicy

Wobec studentów, doktorantów, wykonawców, współpracowników B2B, gości i zewnętrznych administratorów trzeba odrębnie ustalić podstawę prawną, obowiązki informacyjne i dopuszczalny zakres rejestrowania aktywności. Sam status użytkownika infrastruktury nie czyni go pracownikiem; jedna osoba może też występować w różnych rolach.

Dla każdego modelu należy ustalić podstawę przetwarzania danych, dostęp do logów i retencję. Trzymiesięcznego okresu dla nagrań monitoringu wizyjnego nie przenosi się automatycznie na logi IT.^[9] Ocenę należy przeprowadzić z udziałem IOD i obsługi prawnej.

Co zrobić po wykryciu nieautoryzowanego narzędzia lub usługi AI

Samo wykrycie nieautoryzowanego programu, usługi, konta lub integracji nie przesądza, że doszło do ujawnienia danych. Nie wolno jednak zakładać, że odinstalowanie aplikacji albo zablokowanie strony kończy sprawę.

Rekomendowana kolejność działania:

1. Ustalić, czy narzędzie lub usługa były używane, z jakiego konta, na jakim urządzeniu i z jakimi uprawnieniami.
2. Ograniczyć dalszy dostęp; przy podejrzeniu aktywnego zagrożenia zastosować izolację zgodnie z procedurą incydentową.
3. Zabezpieczyć potrzebne logi i konfigurację przed usunięciem programu.
4. Sprawdzić przekazane pliki, podłączone zasoby, tokeny i zgody na integracje.
5. Cofnąć zbędne dostępy, a potencjalnie ujawnione sekrety unieważnić lub zmienić.
6. Ocenić skutki i obowiązki zgłoszeniowe, a następnie usunąć aplikację, odebrać dostęp do usługi lub przeprowadzić formalną ocenę dopuszczenia.

Ocena musi odróżniać naruszenie polityki od incydentu bezpieczeństwa i naruszenia ochrony danych osobowych. Zgłoszenie do UODO nie jest automatyczną konsekwencją instalacji programu. Jeżeli stwierdzono naruszenie ochrony danych, zastosowanie mają warunki art. 33–34 RODO; termin 72 godzin z art. 33 dotyczy zgłoszenia wymaganego na podstawie tego przepisu i biegnie od stwierdzenia naruszenia przez administratora.^[11]

Jak wykorzystać AI Governance Manager JSFP do zarządzania dopuszczeniami

Informacja o powiązaniu z produktem: AI Governance Manager JSFP jest rozwijany przez Public Systems, wydawcę tego artykułu. Ta część pokazuje przykładowe przełożenie zasad na proces zarządzany w systemie. Informacje o funkcjach pochodzą z opisu producenta i nie stanowią niezależnej oceny skuteczności produktu.

Proces AI governance powinien łączyć decyzję organizacyjną z jej realizacją i późniejszym przeglądem. Rejestr zawierający wyłącznie nazwy programów nie wystarczy: ten sam produkt może być dopuszczony do opracowywania materiałów publicznych i niedopuszczony do analizy dokumentacji kadrowej.

Według aktualnego opisu producenta AI Governance Manager JSFP obsługuje rejestr dostawców, systemów i zastosowań, ocenę, opinie i decyzje, zadania, dowody, przeglądy oraz ewidencję działań szkoleniowych.^[25] Poniższy przebieg jest rekomendacją wykorzystania i konfiguracji tego typu systemu. Automatyczne integracje z zabezpieczeniami wymagają osobnego potwierdzenia i wdrożenia.

Od zgłoszenia do potwierdzonego dopuszczenia

Warto odróżniać „decyzja pozytywna z warunkami” od „dopuszczone do użycia”. Sam podpis kierownika nie potwierdza, że IT ograniczyło dostęp, a użytkownicy poznali zasady. Zapisy te są proponowanymi statusami procesu, nie opisem nazw ekranów konkretnej wersji aplikacji.

Przykład modelowy: analiza dokumentów w narzędziu Google

Poniższy scenariusz jest ilustracją procesu, a nie opisem wdrożenia u konkretnego klienta. Właściciel zgłasza wykorzystanie Gemini Notebook do analizy publicznych dokumentów strategicznych. Ocena dotyczy zarządzanego konta, określonej grupy pracowników i materiałów bez informacji poufnych. Decyzja przewiduje brak integracji z wewnętrznymi zasobami i weryfikację odpowiedzi przez pracownika. IT potwierdza konfigurację, a właściciel przekazuje instrukcję oraz dokumentuje przygotowanie użytkowników.

Późniejszy pomysł wgrywania akt osobowych nie mieści się w tej zgodzie. Powinien uruchomić ponowną ocenę zastosowania. Tak samo należy postąpić przy zmianie dostawcy, operatora API, modelu przetwarzania, planu, istotnych warunków umownych lub dodaniu integracji rozszerzającej dostęp.

Powiązanie z narzędziami bezpieczeństwa

AI Governance Manager dokumentuje, co wolno i na jakich warunkach. Zabezpieczenia urządzeń i usług egzekwują te warunki. Lista dopuszczeń powinna stanowić podstawę zleceń do IT dotyczących kontroli aplikacji, przeglądarek, kont i integracji. IT powinno zwrotnie przekazywać identyfikator reguły lub zgłoszenia, datę wdrożenia i wynik testu.

Można zacząć od ręcznego powiązania z helpdeskiem i załączania dowodów. Automatyczna synchronizacja przez API jest kolejnym krokiem, jeżeli oba systemy ją obsługują. Sam wpis do rejestru nie blokuje instalacji, nie wykrywa nieznanych narzędzi i nie dowodzi skuteczności DLP. Nie należy przedstawiać tych funkcji jako dostępnych bez sprawdzenia integracji.

Wykrycie nieautoryzowanego narzędzia powinno prowadzić do wskazania właściciela, decyzji o usunięciu albo przeprowadzeniu oceny dopuszczenia oraz dokumentowania działań naprawczych. Szczegółowe logi i materiały incydentowe mogą pozostać w odpowiednio chronionym systemie bezpieczeństwa; w AI Governance wystarczy odniesienie i niezbędny zakres informacji.

Wyjątki i informacja dla kierownictwa

Wyjątek należy powiązać z zastosowaniem, ryzykiem, zakresem danych, zabezpieczeniami kompensującymi i datą wygaśnięcia. Wygaśnięcie musi skutkować zadaniem odebrania dostępu lub ponowną decyzją; samo przypomnienie nie cofa technicznych uprawnień.

Przegląd kierowniczy powinien pokazywać zastosowania bez właściciela, niespełnione warunki dopuszczenia, zaległe przeglądy i wyjątki oraz rozbieżności między rejestrem a stanem urządzeń. Taki sposób pracy wpisuje się w zarządzanie ryzykiem AI przez cały cykl życia, wspierane m.in. przez dobrowolne ramy NIST AI RMF.^[26] Ocena w systemie i komplet dokumentów nie zastępują decyzji osób odpowiedzialnych ani sprawdzenia działania zabezpieczeń.

Praktyczny plan wdrożenia

Poniższy harmonogram jest przykładem dla instytucji posiadającej podstawowe zarządzanie urządzeniami. Duża lub rozproszona organizacja może potrzebować więcej czasu.

Terminy uruchomienia monitoringu trzeba dostosować do wymaganych działań formalnych i informacyjnych. Sam plan techniczny ich nie zastępuje.

Odbiór wdrożenia powinien obejmować kontrolowane testy: uruchomienie niezatwierdzonego programu z profilu użytkownika i nośnika zewnętrznego, wejście do niezatwierdzonej usługi przez przeglądarkę, przesłanie testowego pliku z prywatnego konta, dodanie rozszerzenia, użycie CLI, próbę podłączenia zasobu organizacji oraz działanie laptopa poza siecią instytucji. Równie ważne jest potwierdzenie, że zatwierdzone aplikacje, podpis elektroniczny i aktualizacje nadal działają.

Warto mierzyć udział urządzeń z rzeczywiście aktywną polityką blokowania, liczbę stałych administratorów lokalnych, czas obsługi wniosków, wygasłe wyjątki oraz czas reakcji na wykrycia. Liczba wysłanych komunikatów nie jest dowodem skuteczności zabezpieczeń.

Lista kontrolna dla kierownictwa

• Czy rejestr AI Governance odzwierciedla rzeczywiste zastosowania i wdrożone zabezpieczenia?
• Czy wiadomo, kto zatwierdza narzędzia i akceptuje wyjątki?
• Czy pracownik ma katalog dopuszczeń i sprawną ścieżkę zgłoszenia potrzeby?
• Czy ochrona faktycznie blokuje niezatwierdzone uruchomienia i ogranicza dostęp do niezatwierdzonych usług, także poza siedzibą?
• Czy kontrolowane są dodatki, integracje i konta?
• Czy monitoring ma określone granice, a wykrycia prowadzą do reakcji?
• Czy zatwierdzone narzędzia pozwalają wykonywać potrzebne zadania?

Źródła

Data dostępu do źródeł: 25 września 2026 r. Dokumentacja produktowa jest aktualizowana na bieżąco; artykuł nie przypisuje jej jednej wersji. Przy wdrożeniu należy zapisać wersję klienta, system, plan i datę sprawdzenia konkretnej funkcji.

1. CIS. CIS Critical Security Control 2: Inventory and Control of Software Assets — inwentaryzacja i kontrola oprogramowania.
2. Microsoft. App Control for Business and AppLocker Overview — zakres i różnice mechanizmów kontroli aplikacji.
3. Microsoft. Use audit events to create App Control policy rules — audyt i przegląd reguł przed ich dopuszczeniem.
4. Microsoft. App Control for Business and AppLocker feature availability — dostępność funkcji i różnice reguł.
5. Anthropic. Enterprise configuration for Claude Desktop — zarządzane ustawienia aplikacji.
6. Cursor. Identity and Access Management — kontrola zespołów, rozszerzeń i polityk urządzeń.
7. Cursor. Security and Privacy Hardening — warstwy ochrony i ograniczenia poszczególnych mechanizmów.
8. OpenAI. Running Codex safely at OpenAI — opis zarządzanej konfiguracji i zabezpieczeń stosowanych przez dostawcę; nie jest niezależnym audytem produktu.
9. ISAP. Kodeks pracy, t.j. Dz.U. z 2025 r. poz. 277 ze zm., art. 22²–22³.
10. UODO. Dotyczące przesłanek przetwarzania danych osobowych — cele i warunki monitoringu pracowniczego.
11. EUR-Lex. Rozporządzenie (UE) 2016/679, w szczególności art. 33–34 i rozdział V.
12. OpenAI. Configuration Reference — parametry konfiguracji Codex; zakres należy odnieść do używanego klienta.
13. Google. Generative AI in Google Workspace Privacy Hub — zakres ochrony danych w odpowiednich usługach i edycjach.
14. Google. NotebookLM is now Gemini Notebook — informacja o zmianie nazwy produktu.
15. Microsoft. Enterprise data protection in Microsoft Copilot and Microsoft Copilot Chat — zobowiązania organizacyjne, zapytania internetowe i agenci.
16. GitHub. Managing GitHub Copilot policies as an individual subscriber — ustawienia, różnice planów i wykorzystanie danych do treningu.
17. DeepSeek. Privacy Policy, aktualizacja 10 lutego 2026 r.
18. Qwen. Terms of Service oraz Privacy Policy dla usług dostępnych przez qwen.ai. Warunki wskazują Alibaba Cloud (Singapore) Private Limited jako podmiot udostępniający opisane usługi; zakres dokumentów należy odnieść do konkretnego produktu i sposobu korzystania.
19. Kimi. Kimi Privacy Policy oraz Data Processing and Security dla Kimi API. Zapewnień dotyczących API nie należy automatycznie przenosić na czat, aplikację konsumencką ani inne produkty Kimi.
20. Perplexity. Perplexity Enterprise.
21. xAI. Grok — oficjalny opis produktu.
22. Mistral AI. Mistral Vibe, formerly Le Chat.
23. DeepL. DeepL for Business.
24. Canva. Canva AI.
25. Public Systems. AI Governance Manager JSFP — opis funkcji systemu do zarządzania zastosowaniami AI.
26. NIST. AI Risk Management Framework.

Dokumentacja producentów potwierdza opisane możliwości konfiguracyjne, ale nie zastępuje testu skuteczności zabezpieczeń w środowisku instytucji. Rekomendacje organizacyjne, przykładowy katalog, harmonogram i scenariusze odbioru stanowią autorską propozycję wdrożenia.