Jak zarządzać wykorzystaniem AI w firmie: framework dla europejskich organizacji

dlaczego zakazy nie działają

Odruchem, gdy narzędzia AI po raz pierwszy pojawiają się jako problem governance, jest często ich ograniczanie. Zablokuj domeny. Dodaj do polityki linijkę zakazującą nieautoryzowanego użycia AI. Czekaj, aż ryzyko samo zniknie.

Problem w tym, że narzędzia AI wrosły w to, jak ludzie pracują. Badania Microsoftu pokazują, że 1 na 2 osoby używające AI w pracy robi to bez wiedzy pracodawcy. Całkowity zakaz tego nie zatrzymuje. Spycha to pod ziemię. Pracownicy dalej używają narzędzi. Przestają o tym mówić IT. Dane nadal płyną. Organizacja ma mniej widoczności niż wcześniej, nie więcej.

Drugi problem to koszt produktywności. Narzędzia AI są naprawdę użyteczne. Ograniczanie ich bez frameworku, który określa, które narzędzia są dopuszczalne, tworzy tarcie, które twoje zespoły po prostu obejdą. Governance, które działa, zaczyna się od innego założenia: adopcja AI jest faktem. Celem jest uczynić ją widoczną, klasyfikowalną i kontrolowaną, tak żeby narzędzia, których ludzie używają, były narzędziami, które oceniłeś, a dane, które się przemieszczają, były danymi, o których powiedziałeś, że mogą się przemieszczać.

framework governance

krok 1: najpierw widoczność

Nie da się zarządzać czymś, czego nie widać. To warunek konieczny dla każdego kolejnego kroku. Widoczność oznacza wiedzę, w dowolnym momencie, jakie narzędzia AI są w użyciu, przez kogo, jakimi kanałami i z jakim dostępem do danych firmowych. Obejmuje to narzędzia wdrożone przez IT, narzędzia, które zespoły przyjęły samodzielnie, prywatne konta AI używane do pracy, rozszerzenia AI w przeglądarce zainstalowane na zarządzanych urządzeniach oraz aplikacje-connectory, które dostały granty OAuth do dostępu do firmowej poczty lub dokumentów.

Praktycznym punktem startu jest twój identity provider. Wyciągnij pełną listę grantów OAuth i przefiltruj pod kątem aplikacji związanych z AI. Samo to ujawnia znaczną część aktywnego użycia AI, w tym narzędzia, które nigdy nie przeszły przez IT. Potem sprawdź logi DNS pod kątem znanych domen AI, co wyłapuje narzędzia przeglądarkowe bez śladu OAuth. Potem przejrzyj inwentarz rozszerzeń przeglądarki, jeśli zarządzasz endpointami. To, co budujesz, to inwentarz: lista tego, co faktycznie działa, wraz z dostępem, jaki ma każde narzędzie. Polityka napisana bez tego będzie mieć luki, o których jej autor nie wiedział.

krok 2: klasyfikacja danych

Gdy już wiesz, jakie narzędzia są w użyciu, kolejnym pytaniem jest, jakie dane mogą, a jakie nie mogą do nich trafiać. Klasyfikacja danych pod kątem AI nie musi być rozbudowana. Musi być na tyle konkretna, żeby pracownik czytający ją mógł odpowiedzieć na pytanie: czy to, co za chwilę wkleję do narzędzia, jest objęte regułą? Zacznij od tych kategorii:

• Dane osobowe. Nazwiska klientów, dane kontaktowe, dane pracowników, wszystko objęte RODO. Żadne narzędzie AI w wersji konsumenckiej bez DPA.
• Materiały objęte NDA. Wszystko z relacji z klientem lub dostawcą objęte klauzulami poufności.
• Kod źródłowy. To kategoria, która najczęściej trafia do zewnętrznych modeli bez governance (incydent Samsunga w 2023 roku dotyczył kodu źródłowego i danych wewnętrznych wklejanych do ChatGPT przez mniej więcej trzy tygodnie, zanim to wykryto).
• Dane finansowe jeszcze niepubliczne. Prognozy, informacje o fuzjach i przejęciach, niepublikowane wyniki.
• Wewnętrzne dokumenty strategiczne. Roadmapy, plany organizacyjne, competitive intelligence.

Klasyfikacja nie eliminuje całego ryzyka. Daje pracownikom punkt odniesienia, tworzy podstawę dla polityki, której mogą przestrzegać, i tworzy audit trail, do którego można się odwołać, jeśli później pojawi się pytanie.

krok 3: lista zatwierdzonych narzędzi i proces weryfikacji

Lista zatwierdzonych narzędzi mówi pracownikom, których narzędzi AI mogą używać. Proces weryfikacji mówi im, co się dzieje, gdy chcą użyć czegoś, czego nie ma na liście. Potrzebne jest jedno i drugie. Lista bez procesu weryfikacji się dezaktualizuje. Proces weryfikacji bez listy nie daje pracownikom żadnych wskazówek do codziennych decyzji.

Co trafia na listę zatwierdzonych: narzędzia, które zostały sprawdzone pod kątem poniższych pytań, z odnotowanymi warunkami, na przykład „ChatGPT Teams (wymagany tryb enterprise, bez danych osobowych)". Pięć pytań weryfikacyjnych, na które trzeba odpowiedzieć dla każdego narzędzia przed jego zatwierdzeniem:

1. Czy dostawca oferuje umowę powierzenia przetwarzania danych (DPA)? Jeśli używasz narzędzia z danymi osobowymi, potrzebujesz jej. Narzędzie w wersji konsumenckiej niemal nigdy tego nie zapewnia.
2. Czy wprowadzane dane są używane do trenowania modelu? Wersje darmowe i konsumenckie zwykle zastrzegają sobie to prawo. Standardem do użytku służbowego są plany enterprise z wyłączonym trenowaniem.
3. Jaka jest data residency? Gdzie dane są przechowywane i przetwarzane? Dla danych osobowych z UE ma to bezpośrednie implikacje dla RODO.
4. Czy istnieje plan enterprise lub business, który wyłącza trenowanie? Jeśli tak, to ten plan trafia na listę zatwierdzonych, nie wersja darmowa.
5. Jakie certyfikaty bezpieczeństwa ma dostawca? ISO 27001 i SOC 2 Type II to minimum.

Określ, kto odbiera zgłoszenia weryfikacyjne i jaki jest oczekiwany czas realizacji. Zgłoszenia, które znikają w kolejce, napędzają nieformalną adopcję. Docelowy czas odpowiedzi, nawet wstępne „to jest sprawdzane", utrzymuje proces sprawnym.

krok 4: kontrole techniczne

Polityka mówi ludziom, co robić. Kontrole techniczne sprawiają, że polityka jest egzekwowalna, i dają siatkę bezpieczeństwa na przypadki, gdy nie jest przestrzegana. Liczą się trzy kategorie. Monitoring DNS: jeśli masz filtrowanie DNS, skonfiguruj alerty lub blokady dla znanych domen AI spoza listy zatwierdzonych, co wyłapuje narzędzia przeglądarkowe niepozostawiające śladu OAuth. DLP na wrażliwych kategoriach danych: polityki data loss prevention skonfigurowane na kategoriach z twojej klasyfikacji mogą oznaczać lub blokować przesyłanie objętych regułą materiałów do zewnętrznych endpointów AI, a DLP na poziomie przeglądarki wyłapuje najczęstszy wzorzec, czyli kopiowanie i wklejanie przez użytkownika z wewnętrznego dokumentu do karty przeglądarki. Rozszerzenia przeglądarki zarządzane przez MDM: rozszerzenia AI mogą czytać otwarte karty, przechwytywać wpisywany tekst, a w niektórych konfiguracjach mieć dostęp do tokenów uwierzytelniających, więc zarządzaj rozszerzeniami przez politykę MDM, blokuj niezatwierdzone, przeglądaj scope'y dostępu tych zatwierdzonych i dokumentuj, do czego każde z nich ma prawo. Te kontrole nie zastępują polityki. Wypełniają lukę między tym, co mówi polityka, a tym, co dzieje się w zwykły wtorek, gdy ktoś znajdzie przydatne narzędzie.

krok 5: edukacja pracowników o mechanizmie

Ostatnim krokiem jest powiedzenie ludziom, dlaczego reguły istnieją, nie tylko jakie są. Reguła mówiąca „nie wprowadzaj danych osobowych do narzędzi AI" jest mniej skuteczna niż wyjaśnienie: „Konsumenckie narzędzia AI zwykle wykorzystują twoje dane wejściowe do ulepszania swoich modeli. Dane osobowe wprowadzone bez zawartej DPA tworzą ekspozycję na RODO dla firmy, a potencjalnie też dla klienta, którego dane zostały udostępnione. Dlatego ta reguła istnieje." Ludzie stosują się do wskazówek, które rozumieją. Nie wymaga to długiego szkolenia. Wystarczy krótki dokument, przekazany podczas onboardingu i przywoływany ponownie, gdy polityka się aktualizuje. Chodzi o to, żeby pracownicy wiedzieli, że polityka istnieje, wiedzieli, gdzie ją znaleźć, i rozumieli powód na tyle, żeby podjąć właściwą decyzję, gdy trafią na przypadek brzegowy.

główne ryzyka, krótko

Powyższy framework adresuje najczęstszą ścieżkę, którą governance AI się rozpada. Warto nazwać ryzyka, które pod nim leżą.

Wyciek danych do zewnętrznych modeli. Pracownicy wklejają treści firmowe do publicznych narzędzi AI: umowy, dane klientów, dane finansowe, kod źródłowy. Dane wychodzą, zanim jakakolwiek polityka zdefiniuje granicę. To problem widoczności i polityki, nie dyscypliny.

Niezweryfikowane narzędzia w stacku. Narzędzia przyjęte bez sprawdzenia statusu DPA, warunków trenowania na danych, data residency w UE czy istnienia wersji enterprise. Ekspozycja jest proporcjonalna do danych, których narzędzie dotyka.

Rozszerzenia AI w przeglądarce z szerokim dostępem. Rozszerzenia mogą czytać treść otwartych kart, przechwytywać wpisywany tekst, a w niektórych konfiguracjach mieć dostęp do tokenów sesji. Większość nie jest zinwentaryzowana. Nieliczne mają jakikolwiek audit trail.

Prompt injection. Złośliwe instrukcje osadzone w treści, którą przetwarza model AI. Dokument podany asystentowi AI zawiera ukryty tekst, który zmienia działanie modelu. Atak jest niewidoczny w danych wejściowych i trudny do przewidzenia w wyniku. Istotne przy każdym wdrożeniu, w którym AI czyta zewnętrzne treści lub treści dostarczane przez użytkownika.

Agentic AI z nadmiernym dostępem. Agenci AI działający na poświadczeniach użytkownika mogą wysyłać e-maile, tworzyć dokumenty i podejmować działania w podpiętych aplikacjach. Działania, jakie może podjąć agent z nadmiernymi uprawnieniami, są ograniczone wyłącznie przez poświadczenia, które posiada. Zdefiniuj zakres dostępu przed wdrożeniem, nie po tym, jak coś pójdzie nie tak.

Halucynacje w outpucie skierowanym na zewnątrz. Modele AI generują pewny siebie, dobrze sformatowany, błędny output. Gdy taki output trafia do umów, propozycji dla klienta, raportów finansowych czy komunikacji zewnętrznej bez etapu weryfikacji, błąd wychodzi poza organizację. Pytanie governance brzmi, czy między outputem AI a użyciem na zewnątrz stoi etap ludzkiej weryfikacji.

co unijny AI Act oznacza dla deployera

Unijny AI Act jest zwykle przedstawiany jako regulacja dla twórców AI. Takie ujęcie pomija istotną część zakresu regulacji. Akt nakłada obowiązki na deployerów, czyli organizacje, które używają systemów AI w kontekście zawodowym. Jeśli twoja organizacja używa narzędzi AI w pracy, unijny AI Act dotyczy jej w jakiejś formie. Pytanie brzmi, które obowiązki mają zastosowanie i na jakim poziomie.

Klasyfikacja ryzyka. Akt przypisuje systemy AI do czterech kategorii: ryzyko niedopuszczalne (zakazane), wysokie ryzyko (istotne wymogi), ograniczone ryzyko (obowiązki przejrzystości) i minimalne ryzyko (brak obowiązkowych wymogów). Większość ogólnych narzędzi AI do produktywności mieści się w kategorii ograniczonego lub minimalnego ryzyka. Klasyfikacje wysokiego ryzyka dotyczą konkretnych przypadków użycia: AI w decyzjach zatrudnieniowych, scoringu kredytowym, zarządzaniu infrastrukturą krytyczną i identyfikacji biometrycznej, między innymi.

Co to oznacza w praktyce dla większości deployerów. Jeśli twoje narzędzia AI to ogólne oprogramowanie do produktywności, twoim podstawowym obowiązkiem jest posiadanie inwentarza tego, czego używasz, stosowanie oznaczeń przejrzystości tam, gdzie są wymagane (na przykład informowanie, że odpowiedzi chatbota widocznego dla klientów są generowane przez AI), i śledzenie etapowego harmonogramu wdrożenia.

Gdzie robi się bardziej wymagająco. Jeśli używasz AI w procesach HR, decyzjach finansowych lub innych konkretnych kategoriach wysokiego ryzyka, masz obowiązki deployera, które obejmują ocenę wpływu na prawa podstawowe, udokumentowane procedury nadzoru ludzkiego, retencję logów i informowanie osób, których to dotyczy, tam gdzie jest to wymagane.

Zależność z RODO. Unijny AI Act nie zastępuje RODO. Dla systemów AI przetwarzających dane osobowe obowiązują oba akty. DPIA już wymagana na mocy RODO może teraz wymagać dodatkowo oceny wpływu specyficznej dla AI.

Harmonogram wdrożenia. Zakaz systemów o niedopuszczalnym ryzyku zaczął obowiązywać od lutego 2025. Obowiązki dla modeli AI ogólnego przeznaczenia i ich providerów obowiązują od sierpnia 2025. Obowiązki dla systemów wysokiego ryzyka w określonych kontekstach pierwotnie wyznaczono na sierpień 2026; Digital Omnibus, przyjęty w czerwcu 2026 i oczekujący na publikację w Dzienniku Urzędowym, przesuwa samodzielne obowiązki wysokiego ryzyka z Annex III na 2 grudnia 2027. Praktyczny pierwszy krok jest taki sam jak w przypadku frameworku governance: zbuduj inwentarz systemów AI w użyciu, a potem je sklasyfikuj.

szkielet polityki na start

Polityka dopuszczalnego użycia AI nie musi być długa. Musi być na tyle konkretna, żeby dało się jej przestrzegać. Ten szkielet obejmuje niezbędne elementy.

1. Zakres. Kogo dotyczy polityka. Wszystkich pracowników, kontraktorów i innych użytkowników mających dostęp do systemów firmowych.
2. Lista zatwierdzonych narzędzi. Nazwana lista narzędzi AI zatwierdzonych do użytku służbowego, z odnotowanymi warunkami. Lista jest żywym dokumentem, przeglądanym co kwartał.
3. Klasyfikacja danych. Kategorie danych, których nie można wprowadzać do żadnego zewnętrznego narzędzia AI, z przykładami w prostym języku. Co najmniej: dane osobowe objęte RODO, materiały objęte NDA, kod źródłowy, niepublikowane dane finansowe, wewnętrzne dokumenty strategiczne.
4. Proces weryfikacji. Co robić, gdy chcesz użyć narzędzia spoza listy zatwierdzonych. Wskaż osobę zgłaszającą, właściciela procesu i docelowy czas odpowiedzi.
5. Rozszerzenia przeglądarki. Na zarządzanych urządzeniach dozwolone są wyłącznie rozszerzenia AI zatwierdzone przez politykę MDM.
6. Weryfikacja outputu. Każda treść wygenerowana przez AI używana w dokumentach zewnętrznych wymaga etapu ludzkiej weryfikacji przed użyciem.
7. Zgłaszanie. Jeśli zaobserwujesz lub podejrzewasz, że dane firmowe zostały udostępnione niezatwierdzonemu narzędziu AI, zgłoś to do IT. Brak kary za zgłoszenie w dobrej wierze.
8. Cykl przeglądu. Polityka jest przeglądana i aktualizowana według ustalonego harmonogramu, albo gdy wymaga tego istotna zmiana na rynku narzędzi AI.

częste błędy

Pisanie polityki przed zbudowaniem inwentarza. Polityka, która nie uwzględnia narzędzi już będących w użyciu, będzie wymagała wyjątków, zanim zostanie opublikowana. Najpierw zbuduj inwentarz.

Klasyfikacja, która jest zbyt ogólnikowa. „Nie udostępniaj poufnych informacji" nie mówi pracownikowi, czy nazwa klienta w podsumowaniu podlega tej regule. To konkretne kategorie z przykładami zmieniają zachowanie.

Zatwierdzanie darmowej wersji narzędzia. Darmowa wersja niemal każdego narzędzia AI wykorzystuje dane wejściowe do trenowania i nie zapewnia DPA. Na liście zatwierdzonych powinien znaleźć się plan enterprise lub business.

Brak procesu weryfikacji nowych narzędzi. Bez zdefiniowanego procesu pracownicy, którzy chcą użyć niezatwierdzonego narzędzia, albo czekają w nieskończoność, albo używają go nieformalnie. Oba te scenariusze są gorsze niż lekki proces z określonym właścicielem i czasem realizacji.

Traktowanie tego jako jednorazowego projektu. Rynek narzędzi AI zmienia się szybko. Polityka i lista zatwierdzonych, które nie są przeglądane przynajmniej raz w roku, oddalą się od rzeczywistości. Wbuduj w to cykl przeglądu.

Ignorowanie rozszerzeń przeglądarki. Rozszerzenia to najbardziej niewidoczna kategoria narzędzi AI, często instalowana w kilka sekund z szerokimi uprawnieniami w przeglądarce. Uwzględnij rozszerzenia w polityce MDM.

Brak wyjaśnienia powodu. Polityk bez uzasadnienia przestrzega się mniej konsekwentnie niż tych z uzasadnieniem. Krótkie wyjaśnienie, dlaczego każda reguła istnieje, sprawia, że przestrzeganie jej staje się wyborem, nie obciążeniem.

jak to mapuje się na standardy

Praca nad AI governance nie dzieje się w izolacji. Łączy się bezpośrednio z kilkoma frameworkami, względem których być może już pracujesz.

RODO. Każde narzędzie AI przetwarzające dane osobowe wymaga DPA. Lista zatwierdzonych narzędzi ze zweryfikowanym statusem DPA jest tu twoim głównym dowodem zgodności.

ISO 27001. Annex A obejmuje kontrole dla relacji z dostawcami, klasyfikacji informacji i kontroli dostępu, które praca nad AI governance bezpośrednio spełnia. Proces weryfikacji narzędzi AI z udokumentowanymi zapisami dostarcza dowodów oceny dostawcy, jakich te kontrole wymagają.

SOC 2. Kryteria trust service dotyczące dostępności i poufności mają tu bezpośrednie znaczenie: kontrole nad podmiotami przetwarzającymi dane u zewnętrznych dostawców i nad danymi udostępnianymi systemom zewnętrznym.

NIS2 i DORA. Oba wymagają udokumentowanego zarządzania ryzykiem w całym łańcuchu dostaw technologicznych. Narzędzie AI z szerokim dostępem OAuth do systemów firmowych jest częścią tego łańcucha dostaw. Zapisy weryfikacji i lista zatwierdzonych narzędzi są dowodem spełnienia tego wymogu.

Unijny AI Act. Obowiązki deployera wymagają inwentarza systemów AI w użyciu, klasyfikacji względem kategorii ryzyka i dokumentacji nadzoru dla wdrożeń wysokiego ryzyka. Powyższy framework governance buduje inwentarz i klasyfikację jako swoje pierwsze kroki.