Jak przygotować politykę użycia AI w zespole IT: zasady, wyjątki i kontrola ryzyka

Dlaczego zespół IT potrzebuje polityki użycia AI – realne powody, nie „papierologia”

Spontaniczne korzystanie z AI w codziennej pracy technicznej

Większość zespołów IT korzysta z narzędzi AI, zanim ktokolwiek w firmie zdążył to formalnie zauważyć. Programista kopiuje fragment kodu do ChatGPT, żeby przyspieszyć refaktoryzację. DevOps wkleja kawałek logów do modelu generatywnego, żeby szybciej znaleźć przyczynę błędu. Analityk biznesowy prosi AI o przepisanie wymagań w bardziej zrozumiałej formie. Product owner generuje prezentację na zarząd z pomocą modelu tekst–do–slajdów.

To są naturalne zachowania – ludzie szukają narzędzi, które oszczędzają czas i energię. Problem pojawia się w momencie, gdy do narzędzia AI trafiają dane, które nigdy nie powinny opuścić organizacji: kod objęty NDA, dane produkcyjne, treści kontraktów, poufne dokumenty klienta. Często dzieje się to „przy okazji”, bez złej woli. Wklejając fragment 200 linii kodu, nikt nie analizuje, że w połowie pliku jest chociażby klucz API albo identyfikator klienta.

Bez polityki użycia AI korzystanie z takich narzędzi opiera się na intuicji. A intuicja bywa zawodna, szczególnie jeśli nie każdy rozumie konsekwencje prawne, regulacyjne i bezpieczeństwa. Stąd potrzeba spójnego zestawu zasad, które pomagają zespołowi oddzielić „bezpieczne przyspieszacze” od realnych min przeciwpiechotnych.

Ryzyka działania bez polityki – od wycieków po chaos odpowiedzialności

Brak polityki korzystania z AI w firmie nie oznacza, że AI nie jest używana. Oznacza jedynie, że używana jest w sposób niekontrolowany i trudny do udokumentowania. Z perspektywy kierownictwa i działów prawnych oznacza to kilka typów ryzyk:

• Wyciek danych i tajemnicy przedsiębiorstwa – wysłanie fragmentu kodu z kluczami, logów z danymi osobowymi lub treści kontraktu do zewnętrznego narzędzia SaaS może być uznane za nieautoryzowane udostępnienie informacji.
• Naruszenie licencji i praw autorskich – generowany kod lub treści mogą bazować na danych treningowych, które obejmują projekty open source z licencjami niezgodnymi z polityką firmy albo klienta.
• Niejasna odpowiedzialność za błędy AI – gdy system produkcyjny zawiera fragmenty kodu wygenerowane przez AI, a pojawi się luka bezpieczeństwa, pytanie „kto zawinił” przestaje być czysto techniczne – staje się prawne i biznesowe.
• Chaos decyzyjny – jedni uważają, że wolno „wszystko, co nie jest zakazane”, inni boją się używać AI w ogóle. Zespół pracuje nierówno, standardy jakości są rozchwiane, a klienci dostają sprzeczne komunikaty.

Takie ryzyka rzadko wybuchają spektakularnym incydentem od pierwszego dnia. Raczej narastają po cichu. Sytuacja zaczyna być poważna dopiero, gdy klient pyta o to, czy jego dane były przetwarzane w narzędziach AI, a firma nie jest w stanie spójnie odpowiedzieć. Albo gdy audyt bezpieczeństwa wykazuje praktyki, o których menedżerowie nie mieli pojęcia.

Korzyści z dobrze zaprojektowanej polityki AI w zespole IT

Polityka korzystania z AI w firmie często kojarzy się z dodatkowymi ograniczeniami. Dobrze napisana polityka działa jednak jak tarcza i mapa: chroni zespół przed błędami, a jednocześnie pokazuje, gdzie można iść szybciej. Najważniejsze korzyści są bardzo praktyczne:

• Poczucie bezpieczeństwa w zespole – programista wie, co wolno wkleić do modelu AI, a czego nie. Analityk ma jasność, które fragmenty dokumentów można zanonimizować i w jakiej formie.
• Spójne praktyki pracy – zamiast „każdy po swojemu”, pojawia się wspólny język: klasyfikacja danych, matryca dozwolonych zastosowań, określone narzędzia.
• Łatwiejsza współpraca z działem prawnym i klientami – firma może pokazać konkretny dokument, procedury i zasady audytu. To skraca negocjacje dotyczące NDA i zwiększa zaufanie klientów.
• Przyspieszenie procesów bez utraty kontroli – zamiast ogólnego „nie używajcie AI do niczego ważnego”, pojawiają się miejsca, gdzie AI jest wprost zalecana (np. generowanie szablonowego kodu testowego, szkiców dokumentacji) oraz miejsca, gdzie jest zakazana.

Dla wielu zespołów IT kluczowe jest to, że polityka użycia AI nie zabiera im narzędzia, ale daje formalną zgodę na jego mądre używanie. Dzięki temu łatwiej jest stanąć przed klientem i powiedzieć: „Tak, korzystamy z AI. Tak, mamy to uregulowane. Tak, twoje dane są bezpieczne, bo…”.

Krótki scenariusz: „niewinny” fragment kodu i realny problem prawny

Wyobraźmy sobie typową sytuację. Programista pracuje nad modułem rozliczeń dla dużego klienta z sektora finansowego. W kodzie pojawia się złożony warunek biznesowy, którego logika jest niejasna. Zamiast spędzać godzinę na analizie dokumentacji, programista kopiuje 150 linii kodu do narzędzia generatywnego, z prośbą o wytłumaczenie i uproszczenie.

W tym fragmencie znajdują się:

• stałe z nazwą klienta,
• identyfikatory typów transakcji,
• komentarz z cytatem z dokumentu biznesowego klienta.

Od strony użytkownika – niewinna prośba o pomoc. Od strony prawa – przekazanie fragmentu tajemnicy przedsiębiorstwa oraz potencjalnie danych osobowych do zewnętrznego dostawcy SaaS, często spoza UE. Klient może zapytać: „Czy nasz kod i logika biznesowa były przetwarzane w narzędziach AI? Na jakiej podstawie prawnej? Czy mamy z tym dostawcą umowę powierzenia danych?”. Bez polityki i bez rejestru użycia AI, odpowiedź staje się trudna.

Jedna taka sytuacja może wywołać efekt domina: od przeglądu kontraktu, przez rozmowy z prawnikiem, aż po rewizję całej współpracy. W tle – realne ryzyko finansowe i reputacyjne. Tymczasem dobrze opisana polityka AI mogłaby jasno zabronić takiego działania, a jednocześnie zaproponować bezpieczną alternatywę: lokalne narzędzie AI zasilane jedynie danymi testowymi albo uogólnionym pseudokodem.

Jak komunikować politykę AI jako tarczę, a nie kaganiec

Zespół IT przyjmie politykę użycia AI dużo lepiej, jeśli od początku usłyszy, że jej celem jest umożliwienie korzystania z AI, a nie jego zakazanie. Pomaga tu kilka prostych zasad komunikacyjnych:

• Zacząć od „co wolno i na jakich warunkach”, a dopiero potem przejść do zakazów. Ludzie chętniej czytają przepisy, w których najpierw widzą korzyści.
• Wyjaśnić, że polityka stoi po stronie pracownika: jeśli ktoś działa zgodnie z nią, ma mocny argument w rozmowie z klientem, przełożonym czy działem prawnym.
• Pokazać konkretne przykłady bezpiecznego użycia AI: generowanie testów jednostkowych na bazie pseudokodu, przepisywanie dokumentacji technicznej, tworzenie szkiców migracji.
• Podkreślić, że polityka będzie aktualizowana – nie jest raz na zawsze „tablicą z kamienia”, ale narzędziem dostosowywanym do praktyki i nowych regulacji.

Dobrą praktyką jest wspólne przejście przez politykę z zespołem – z możliwością zadawania pytań. Ludzie szybciej akceptują zasady, które rozumieją i mieli wpływ na ich kształt, niż dokument narzucony z góry i wrzucony w intranet bez komentarza.

Podstawy prawne i regulacyjne przed napisaniem pierwszego punktu polityki

Kluczowe źródła prawa: dane, własność intelektualna, tajemnica przedsiębiorstwa

Polityka korzystania z AI w firmie IT nie powstaje w próżni. Musi uwzględniać kilka grup regulacji, które już dziś obowiązują, niezależnie od tego, czy zespół używa AI czy nie:

• RODO / GDPR – dotyczy przetwarzania danych osobowych. Wysyłając logi, tickety, fragmenty bazy czy zrzuty ekranu do narzędzi AI, łatwo nieświadomie przekazać dane osób fizycznych poza kontrolę administratora danych.
• Prawo autorskie i licencje – generowane treści (kod, dokumentacja, grafiki) mogą być utworami. Trzeba ustalić, kto jest ich autorem, kto ma prawa majątkowe i czy wyjściowa treść nie narusza cudzych praw (np. kopiując fragmenty kodu objętego inną licencją).
• Tajemnica przedsiębiorstwa – obejmuje know-how, logikę biznesową, algorytmy, szczegóły architektury. Przekazywanie takich informacji dostawcom SaaS bez odpowiednich umów może naruszać obowiązki wobec własnej firmy i klientów.
• Umowy z klientami – NDA, MSA, SLA, DPA bardzo często zawierają zapisy o tym, gdzie i jak dane klienta mogą być przetwarzane. Polityka AI musi być z nimi spójna, bo to tam leżą największe ryzyka finansowe.
• Wewnętrzne regulaminy IT i bezpieczeństwa – polityka haseł, zarządzanie dostępem, zasady korzystania z usług chmurowych. AI to po prostu kolejna grupa narzędzi w tym ekosystemie.

Nie trzeba być prawnikiem, żeby zrozumieć ogólną logikę: cokolwiek trafia do zewnętrznego narzędzia AI, jest przekazywane obcej organizacji. Jeśli to są dane osobowe lub poufne informacje, trzeba mieć podstawę prawną, odpowiednie umowy i zgodność z kontraktami klienckimi. Polityka powinna ten fakt upraszczać w praktyczne reguły.

Co zmienia unijny AI Act dla zespołów IT (w skrócie, ale konkretnie)

AI Act, czyli unijne rozporządzenie dotyczące sztucznej inteligencji, nie jest jeszcze w pełni wdrożone, ale jego kierunek jest jasny. Dla zespołów IT ważne są szczególnie trzy elementy:

• Klasy ryzyka systemów AI – od minimalnego po niedopuszczalne. Większość narzędzi wspomagających pracę programistów będzie w kategorii niskiego ryzyka, ale systemy podejmujące decyzje o kredycie, zatrudnieniu czy ocenie ryzyka mogą znaleźć się w wyższych klasach, z dodatkowymi wymaganiami.
• Wymogi transparentności – np. obowiązek oznaczania treści generowanych przez AI w niektórych kontekstach czy informowania użytkowników, że rozmawiają z systemem AI.
• Podział odpowiedzialności między dostawcę a użytkownika – producent modelu ma określone obowiązki (dokumentacja, ocena ryzyka), ale firma używająca AI w swoim procesie też ponosi odpowiedzialność za sposób zastosowania.

Dla polityki użycia AI w zespole IT AI Act staje się ważny w dwóch sytuacjach. Po pierwsze, gdy firma tworzy lub integruje systemy AI dla klientów – wtedy musi mieć procesy dokumentowania ryzyka, testów i zgodności. Po drugie, gdy AI wpływa pośrednio na produkty (np. generuje kod czy konfiguracje), trzeba zadbać o ślad audytowy, który pokaże, jak te treści były weryfikowane przez człowieka.

Polityka nie musi cytować AI Act. Wystarczy, że w kluczowych miejscach odnosi się do pojęć transparentności, nadzoru ludzkiego i odpowiedzialności – spójnych z tym, co wchodzi do prawa unijnego.

„Używamy gotowego narzędzia AI” vs „budujemy własne modele”

W wielu firmach IT występują równolegle dwa scenariusze wykorzystania AI:

• Użycie gotowych narzędzi AI – np. ChatGPT, GitHub Copilot, narzędzia AI w chmurze (Azure OpenAI, Vertex AI, Bedrock), pluginy w IDE.
• Budowa własnych modeli lub integracje – np. trenowanie modeli na danych klientów, tworzenie chatbotów wsparcia, systemów rekomendacyjnych lub silników decyzyjnych.

W pierwszym scenariuszu zespół ma niewielki wpływ na to, jak działa sam model. Główne ryzyka dotyczą tego, co wysyłamy do dostawcy i jak wykorzystujemy odpowiedzi. Polityka musi więc jasno określać:

• jakie klasy danych mogą być przekazywane do zewnętrznych narzędzi,
• które narzędzia są zatwierdzone, a które zakazane,
• jakie zasady weryfikacji odpowiedzi obowiązują.

W drugim scenariuszu firma staje się w praktyce dostawcą systemu AI. Odpowiedzialność rośnie: trzeba zadbać o dane treningowe, dokumentację, testy, nadzór, zgodność z RODO i AI Act. Polityka użycia AI w zespole powinna wtedy odsyłać do dodatkowych procedur: cyklu życia systemów AI, oceny ryzyka, procesów impact assessment.

Warto to rozróżnienie jasno zaznaczyć w polityce: inne zasady dotyczą „AI jako narzędzia pracy programisty”, a inne „AI jako elementu produktu dostarczanego klientowi”. Dzięki temu uniknie się sytuacji, w której jedna ogólna reguła blokuje innowacyjne projekty lub przeciwnie – nieświadomie wpuszcza firmę na pole wysokiego ryzyka regulacyjnego.

Jak sprawdzić, które regulacje dotyczą konkretnego zespołu

Nie wszystkie zespoły IT mają takie same obciążenia regulacyjne. Inaczej wygląda sytuacja w:

• fintechu – gdzie dane finansowe i systemy decyzyjne podlegają szczególnym wymogom,

Jak uwzględnić specyfikę branży przy pisaniu polityki

Na poziomie haseł regulacje wyglądają podobnie, ale diabeł siedzi w szczegółach domeny. Ten sam „prompt z danymi” w jednym zespole będzie tylko niezręcznością, w innym – naruszeniem przepisów sektorowych. Dlatego przed napisaniem polityki dobrze jest przejść przez krótkie ćwiczenie: w jakim świecie żyje nasz zespół?

• Fintech i sektor bankowy – dane transakcyjne, scoringi, analizy behawioralne. Tu szczególnie ważne są wytyczne nadzorców (KNF, EBA), zasady outsourcingu usług chmurowych oraz ryzyka związane z modelem „black box”. Polityka AI powinna łączyć się z procedurami zarządzania modelem ryzyka kredytowego i AML.
• Medycyna, healthtech – dane wrażliwe, dokumentacja medyczna, systemy wspierające decyzje lekarzy. Dochodzą regulacje MDR, wytyczne organów zdrowia publicznego i zasady badań klinicznych. Nawet prosty chatbot „FAQ dla pacjenta” może wejść w strefę wysokiego ryzyka.
• Sektor publiczny – przejrzystość, prawo dostępu do informacji publicznej, zasady równego traktowania. Każde użycie AI, które wpływa na decyzje wobec obywateli, wymaga szczególnej ostrożności i dobrej dokumentacji.
• Software house i consultingi – główny ciężar to umowy z klientami (NDA, DPA, zapisy o podwykonawcach), a nie zawsze przepisy sektorowe. Jeden zespół może jednocześnie obsługiwać fintech, retail i NGO, więc polityka AI powinna przewidywać różne „tryby pracy” zależnie od projektu.

Dobrym krokiem jest krótkie, wspólne spotkanie przedstawicieli IT, bezpieczeństwa, prawnego i sprzedaży. Celem nie jest stworzenie encyklopedii regulacji, tylko spisanie 1–2 stron: „Jakie dodatkowe wymogi branżowe nas dotyczą i co to oznacza dla AI?”. To potem staje się załącznikiem lub osobnym rozdziałem polityki.

Jak przełożyć język prawa na język zespołu

Nawet najlepsza analiza regulacji nie pomoże, jeśli w polityce zostanie przepisanym paragrafem. Programista, analityk czy DevOps potrzebują jasnych, operacyjnych wskazówek. „Zapewnić zgodność z RODO” nie mówi nikomu, co ma zrobić, kiedy siedzi przed edytorem prompta.

Przydaje się prosty schemat:

• Reguła prawna: np. „nie wolno bez podstawy prawnej przekazywać danych osobowych podmiotom zewnętrznym spoza EOG”.
• Tłumaczenie na praktykę: „nie wklejamy do zewnętrznego czatu AI logów produkcyjnych ani ticketów z danymi klientów, nawet jeśli trzeba szybko zdiagnozować błąd”.
• Bezpieczna alternatywa: „anonimizujemy dane lub korzystamy z wewnętrznego narzędzia AI pod kontrolą działu bezpieczeństwa”.

To przełączanie z paragrafów na przykłady staje się jednym z najważniejszych zadań przy pisaniu polityki. Dzięki niemu polityka zaczyna być narzędziem pracy, a nie dokumentem, który „gdzieś tam jest, bo musi”.

Mapa zastosowań AI w zespole IT – co realnie chcemy regulować

Dlaczego najpierw mapa zastosowań, a dopiero potem zakazy

Bez listy faktycznych zastosowań łatwo napisać politykę „na wszelki wypadek”, pełną abstrakcyjnych formułek. Tymczasem większość zagrożeń wynika nie z teorii, tylko z konkretnych nawyków: co ludzie robią pod presją czasu, jak radzą sobie z trudnymi zadaniami, do czego najchętniej odpalają AI.

Krótka sesja z zespołem (warsztat, ankieta, kanał na komunikatorze) pozwala zebrać przykłady takich sytuacji. Często wychodzą na jaw nieformalne praktyki, o których formalne struktury firmy nie mają pojęcia: „wrzucam stos błędów kompilacji do czatu”, „opisuję bug klienta z logami, bo AI lepiej to zrozumie niż kolega z projektu”. Na tej bazie powstaje mapa zastosowań, którą polityka ma objąć.

Typowe obszary użycia AI w zespołach IT

Każda organizacja ma swoją specyfikę, ale pewne grupy zastosowań powtarzają się niemal wszędzie. Dobrze je nazwać wprost i opisać bardziej szczegółowo w polityce.

• Wsparcie programowania i code review
  Generowanie fragmentów kodu, refaktor, podpowiedzi w IDE, automatyczne komentarze do merge requestów. Tu ryzyka dotyczą głównie jakości, licencji i przenikania fragmentów kodu klienta do zewnętrznych modeli.
• Testowanie i QA
  Tworzenie przypadków testowych, scenariuszy end-to-end, danych testowych, analiz raportów z testów. Problemem staje się szybkie kopiowanie logów, zrzutów ekranu czy elementów interfejsu z danymi rzeczywistymi.
• Analiza wymagań i dokumentacja
  Podsumowania spotkań, porządkowanie backlogu, generowanie szkiców user stories, konwersja notatek w dokumentację techniczną. AI jest tu pośrednikiem między ludźmi, więc łatwo przesłać informacje, które klient uznaje za poufne.
• DevOps i SRE
  Wsparcie w analizie logów, generowanie skryptów infrastruktury jako kodu, podpowiedzi przy konfiguracji CI/CD. W chwilach awarii pojawia się pokusa „wrzucenia wszystkiego, jak leci” do czatu, żeby szybciej znaleźć rozwiązanie.
• Wsparcie biznesu i zarządu
  Przygotowywanie prezentacji, streszczeń raportów, scenariuszy wdrożeń. AI często widzi tu planowane strategie, estymacje czy dane sprzedażowe. To już materia tajemnicy przedsiębiorstwa, nawet jeśli w tle nie ma danych osobowych.

Dobrze, jeśli polityka nie tylko wymienia te obszary, ale też przypisuje im poziom ryzyka i podstawowe zasady: gdzie pełna swoboda, gdzie „żółte światło”, gdzie „czerwone światło” i dodatkowa zgoda.

Jak zebrać realne use case’y z zespołu

Przy tworzeniu mapy zastosowań pomagają dwie proste techniki. Po pierwsze, anonimowa ankieta z pytaniami typu: „do czego używałeś AI w pracy w ostatnich 30 dniach?”, „z jakimi danymi pracowałeś?”. Po drugie, krótkie warsztaty z kartkami lub wirtualną tablicą, gdzie każdy dopisuje jeden przypadek użycia na kartkę.

Po zgrupowaniu tych przypadków pojawia się naturalny podział na kategorie. Można je później przenieść do polityki jako konkretne sekcje: „AI w developmentcie”, „AI w pracy z danymi klientów”, „AI w dokumentacji i komunikacji”. Dzięki temu dokument odzwierciedla faktyczne życie zespołu, a nie akademicką wizję użycia sztucznej inteligencji.

Priorytetyzacja – od jakich zastosowań zacząć

Nie ma sensu od razu regulować wszystkiego z jednakową szczegółowością. Lepiej podejść do tematu jak do backlogu: nadać priorytety i zacząć od obszarów, gdzie wpływ potencjalnego błędu jest największy.

• Wysoki priorytet – miejsca, gdzie AI styka się z danymi klientów, tajemnicą przedsiębiorstwa lub procesami regulowanymi (np. decyzje kredytowe, rekomendacje medyczne). Tu polityka powinna być bardzo konkretna i spójna z wymaganiami prawnymi.
• Średni priorytet – wsparcie developerskie w projektach dla klientów, które nie są silnie regulowane. Skupiamy się na klasyfikacji danych, licencjach kodu i obowiązkowej weryfikacji przez człowieka.
• Niższy priorytet – obszary wewnętrzne, jak prezentacje, drafty regulaminów, wewnętrzna dokumentacja. Tu większy nacisk pada na zdrowy rozsądek i dobre praktyki, mniej na formalne zakazy.

Dzięki temu polityka może rosnąć iteracyjnie: pierwsza wersja obejmuje kluczowe, ryzykowne zastosowania, kolejne rewizje rozszerzają zasady na kolejne obszary w miarę, jak zespół nabiera doświadczenia.

Klasyfikacja danych i materiałów – serce rozsądnej polityki AI

Dlaczego bez klasyfikacji każdy zapis stanie się sporny

Większość dyskusji o AI w firmach rozbija się o jedno pytanie: „czy to mogę wkleić do narzędzia, czy już nie?”. Żeby odpowiedzieć sensownie, trzeba mieć wspólny język opisu danych. Inaczej każdy kierownik projektu będzie interpretował „dane wrażliwe” po swojemu, a każdy developer będzie miał inne wyobrażenie „co jest poufne”.

Klasyfikacja danych to nic innego jak wspólna legenda mapy: nazwy, poziomy, przykłady. Gdy taka legenda istnieje, polityka może odwołać się do prostych zasad typu „dane w klasie 3 i 4 nie wychodzą poza środowisko kontrolowane przez dział bezpieczeństwa” zamiast tworzyć dziesiątki wyjątków typu „danych X nie wolno, ale Y czasem tak”.

Przykładowy, prosty model klasyfikacji na potrzeby AI

W wielu firmach istnieją już skomplikowane klasyfikacje informacji. Na początek można jednak zbudować prostszy model, nakierowany konkretnie na użycie AI, a później go zsynchronizować z istniejącymi politykami bezpieczeństwa.

Przykładowy podział może wyglądać tak:

• Klasa 0 – dane publiczne
  To wszystko, co i tak jest dostępne szeroko: dokumentacja open-source, artykuły na blogu firmowym, publiczne API, opisy produktów na stronie. Tego typu materiały można zazwyczaj bezpiecznie przetwarzać w zewnętrznych narzędziach AI – często są wręcz używane do budowania marki.
• Klasa 1 – dane wewnętrzne niestrategiczne
  Materiały, które nie są tajemnicą przedsiębiorstwa ani danymi osobowymi, ale nie są też oficjalnie publikowane: część wewnętrznej dokumentacji, szablony procedur, instrukcje techniczne do narzędzi. Tu dopuszcza się użycie zewnętrznych narzędzi AI w określonych warunkach (np. przy włączonej opcji „no training”).
• Klasa 2 – dane poufne biznesowe
  Plany rozwoju produktu, strategie cenowe, analizy konkurencji, fragmenty architektury rozwiązań klienta, specyficzne algorytmy. To już często tajemnica przedsiębiorstwa. Wysyłanie ich do zewnętrznych modeli wymaga bardzo mocnego uzasadnienia i zwykle jest zabronione.
• Klasa 3 – dane klientów i dane osobowe
  Wszystko, co pozwala zidentyfikować osobę lub dotyczy konkretnego klienta: logi z identyfikatorami, dokumenty z danymi kontaktowymi, raporty sprzedażowe, treść ticketów supportowych. Tu w zasadzie obowiązuje zasada: do zewnętrznych narzędzi AI nie trafia nigdy, chyba że istnieje osobna procedura zanonimizowania danych i umowy z dostawcą.
• Klasa 4 – dane szczególnie chronione i wysokiego ryzyka
  Dane medyczne, dane finansowe z sektora regulowanego, dane dzieci, dane objęte tajemnicą zawodową (np. adwokacką). Ich przetwarzanie jest obwarowane dodatkowymi przepisami, a użycie AI – jeśli w ogóle dopuszczalne – wymaga oddzielnych procedur i zgód.

Kluczem nie jest sam podział, lecz spójność: każdy w zespole powinien potrafić zaklasyfikować materiał, z którym pracuje, do jednej z kategorii. Reszta to już reguły polityki.

Jak praktycznie oznaczać klasy danych w pracy zespołu

Klasyfikacja ma sens tylko wtedy, gdy daje się ją zastosować w bieżącej pracy. Warto więc zadać sobie pytanie: gdzie ludzie spotykają dane? W repozytoriach kodu, w systemach ticketowych, w Confluence, w BI, w dyskach współdzielonych. Dobrze zaprojektowana polityka AI wchodzi właśnie w te miejsca.

Przykłady prostych, praktycznych rozwiązań:

• Tagi lub pola niestandardowe w systemie ticketowym (np. „klasa danych: 0–4”), wypełniane przy zakładaniu zgłoszenia.
• Szablony dokumentów z nagłówkiem, gdzie autor zaznacza klasę danych (np. „Ten dokument zawiera: dane klasy 2 – poufne biznesowe”).
• README w repozytorium z krótkim opisem: „Kod zawiera elementy logiki klienta – traktujemy go jako co najmniej klasę 2”.

Taki drobny wysiłek na wejściu pozwala potem uniknąć wielu nieporozumień. Developer, który ma wątpliwości, czy może wkleić fragment materiału do narzędzia AI, nie musi domyślać się, z jaką klasą ma do czynienia – ma ją podaną wprost.

Anonimizacja, pseudonimizacja i dane syntetyczne jako wentyl bezpieczeństwa

Nawet przy restrykcyjnych zasadach często zachodzi potrzeba „pokazania” AI czegoś, co pochodzi z realnego systemu. Tu pojawia się obszar kompromisów: anonimizacja, pseudonimizacja i dane syntetyczne.

W polityce warto rozdzielić te pojęcia i przypisać im jasne zasady:

• Anonimizacja – usunięcie lub tak silne przekształcenie danych, że nie da się po nich zidentyfikować osoby (nawet w połączeniu z innymi informacjami). Tylko dane faktycznie zanonimizowane mogą być traktowane jak nieosobowe.
• Pseudonimizacja – zastąpienie identyfikatorów innymi, ale z możliwością odtworzenia (np. przy użyciu klucza). To nadal dane osobowe, więc nie wolno ich po prostu wysyłać do dostawcy, który nie jest formalnie procesorem danych.

Dane syntetyczne i mieszane – jak nie przesadzić w żadną stronę

Dane syntetyczne często brzmią jak magiczne rozwiązanie: „wygenerujemy sztuczne i po kłopocie”. W praktyce są narzędziem, które trzeba stosować z głową, bo zbyt „realistyczne” dane syntetyczne mogą dać się odtworzyć do oryginałów, a zbyt uproszczone – przestaną być użyteczne.

Przy projektowaniu polityki przydaje się kilka prostych reguł:

• Dane w pełni syntetyczne do eksperymentów
  Do testowania nowych narzędzi AI, proof-of-conceptów, hackathonów – tylko dane wygenerowane lub zmieszane z wielu źródeł tak, by nie można było odtworzyć realnych osób czy klientów.
• Dane miksowane przy realnych scenariuszach
  Gdy trzeba zachować rozkłady, korelacje i typowe „brudy” danych (np. formaty dat, literówki), można mieszać kilka źródeł, dodawać szum, losowo zmieniać fragmenty. Kluczem jest brak możliwości powiązania rekordu z konkretną osobą czy firmą.
• Dokumentowanie metod
  W polityce dobrze jest przewidzieć, że każdy zestaw danych syntetycznych używany z AI ma krótką notkę: jak powstał, z czego, kto go zatwierdził. To nie biurokracja, tylko ślad, który uratuje zespół, gdy ktoś zapyta „a skąd to się wzięło?”.

Dobrym nawykiem jest też techniczne wsparcie – proste narzędzia lub skrypty do odzierania danych z identyfikatorów, generowania szumu, tworzenia fikcyjnych nazw. Jeśli developer ma do wyboru: kombinować ręcznie albo uruchomić gotowy skrypt, przewidywalne, którą opcję wybierze.

Rola security i compliance w klasyfikacji – partner, nie policjant

Jeśli klasyfikacja danych powstaje wyłącznie „w wieży z kości słoniowej” działu bezpieczeństwa, zespół IT szybko zacznie ją obchodzić. Lepiej potraktować security jak konsultanta, który pomaga dobrać poziomy i przykłady, niż jak wyrocznię, która zsyła zakazy z góry.

Praktyczny model współpracy może wyglądać tak:

• Zespół IT i produktywny (np. dev + analitycy) opisują realne przypadki: jakie dane, gdzie leżą, jak są wykorzystywane.
• Bezpieczeństwo i prawnik „przyklejają” do tych przypadków klasy 0–4, podrzucając konkretne ryzyka (np. RODO, tajemnica przedsiębiorstwa, NDA z klientami).
• Wspólnie dopisują 2–3 zdaniowe opisy per klasa i typowe przykłady z życia firmy, a nie z ogólnych podręczników.

Rezultat: klasyfikacja, która ma sens dla ludzi z zespołu i da się do niej odnieść w polityce AI jednym zdaniem, zamiast ciągłych interpretacji „co autor miał na myśli”.

Zasady korzystania z narzędzi AI – co wolno, czego nie wolno i na jakich warunkach

Podział narzędzi AI – nie każde „okienko z promptem” jest równe

Jednym z większych błędów jest wrzucenie wszystkich narzędzi AI do jednego worka. Chatbot w otwartej przeglądarce, własny model w VPC, wtyczka w IDE i wewnętrzny asystent na dokumentach firmy to cztery zupełnie różne ryzyka. Polityka powinna to jasno rozróżniać.

Przydaje się prosty podział na kategorie:

• Narzędzia publiczne (SaaS)
  Publiczne chatboty, generatory obrazów, copiloty w przeglądarce – tam, gdzie dane lecą do chmury dostawcy, często poza EOG, a wpływ na trening modeli jest ograniczony do kilku przełączników w UI. Tu przepisy są najbardziej restrykcyjne.
• Narzędzia „enterprise” z umową i DPA
  Wersje biznesowe tych samych usług (np. z gwarancją braku użycia danych do trenowania, osobnymi tenantami). Z reguły dopuszczają szersze zastosowania, ale nadal obowiązuje klasyfikacja danych i ograniczenia sektorowe.
• Narzędzia hostowane samodzielnie
  Modele uruchomione w infrastrukturze firmy (lub dedykowanym VPC) – open source albo licencjonowane komercyjnie. Tu zespół ma większą kontrolę nad przepływem danych, ale musi też sam zadbać o bezpieczeństwo i logowanie dostępu.
• Narzędzia wbudowane w inne systemy
  AI jako funkcja w CRM, IDE, systemie ticketowym, platformie chmurowej. Często „włączane jednym kliknięciem”, ale pod spodem działają te same modele i regulacje, co w narzędziach publicznych lub enterprise.

Dobrze, jeśli polityka zawiera tabelkę lub aneks z listą narzędzi dopuszczonych w firmie, z podziałem na te kategorie i krótkimi regułami użycia. Wtedy rozmowa nie brzmi: „czy mogę użyć AI?”, tylko: „którego narzędzia z listy mogę użyć do tego typu danych?”.

Ogólne zasady – wspólny mianownik dla wszystkich narzędzi

Niezależnie od dostawcy, kilka zasad zwykle jest wspólnych. Warto je zapisać wprost, bo oszczędzają dziesiątki indywidualnych konsultacji.

• Zakaz wklejania danych klasy 3 i 4 do narzędzi publicznych
  Bez wyjątku, nawet jeśli dostęp jest przez VPN lub konto firmowe. Dane osobowe, dane medyczne, finansowe, tajemnica zawodowa – poza narzędziami z wyraźnie uregulowaną rolą procesora danych i dodatkowymi zabezpieczeniami – są „poza zasięgiem”.
• Warunkowe użycie danych klasy 2 i 3 w narzędziach enterprise
  Tylko jeśli istnieje podpisana umowa powierzenia, narzędzie działa w określonej jurysdykcji, a konfiguracja (np. wyłączony training, szyfrowanie, logowanie) została sprawdzona przez security.
• Pełna swoboda dla klasy 0
  Publiczne dane, dokumentacje, artykuły – mogą być śmiało używane także w narzędziach publicznych, o ile nie naruszają licencji (np. kod open-source z ograniczeniami copyleft).
• Ostrożność z klasą 1
  Dane wewnętrzne, ale niestrategiczne – można wykorzystywać w narzędziach enterprise (a czasem publicznych, jeśli polityka tak dopuszcza), pod warunkiem, że nie zawierają przypadkowo fragmentów klas wyższych.

Takie „szyny” powodują, że codzienne decyzje stają się powtarzalne, a zespół nie musi za każdym razem pytać prawnika o opinię.

Specyficzne zasady dla copilotów developerskich

Copiloty w IDE to osobna kategoria ryzyka. Pracują na bieżąco z repozytorium, podpowiadają kod, czasem całe funkcje. Mogą przynieść potężny zysk produktywności, ale przy złych ustawieniach stają się tylnymi drzwiami do wycieku tajemnicy przedsiębiorstwa.

Przy formułowaniu zasad dla zespołu developerskiego przydadzą się konkretne punkty:

• Tryb pracy z kodem klienta
  W projektach klientowskich copilot może być dopuszczony tylko w ramach narzędzi enterprise, z gwarancją braku użycia kodu do treningu modeli oraz hostowaniem w odpowiedniej lokalizacji. Alternatywnie – całkowicie wyłączony w repozytoriach konkretnego klienta.
• Weryfikacja licencji i pochodzenia fragmentów
  Polityka może wymagać, by developer nie kopiował „w ciemno” długich fragmentów kodu podpowiedzianych przez AI, zwłaszcza gdy wyglądają na gotowe biblioteki. W newralgicznych projektach wprowadza się zasadę, że kod generowany w całości przez AI wymaga dodatkowego code review pod kątem licencji.
• Wyłączenie telemetryczne, gdy to możliwe
  Jeżeli narzędzie pozwala ograniczyć wysyłane dane (np. nie przesyła całych plików, tylko kontekst), polityka powinna wskazywać rekomendowane ustawienia domyślne IDE.

W praktyce przydają się krótkie checklisty dla tech leadów: przy nowym projekcie – czy copilot włączony, w jakim trybie, jakie repozytoria obejmuje, jak to komunikujemy zespołowi.

AI w analityce i pracy z danymi – jak nie zrobić „shadow ETL”

Analitycy danych bardzo szybko sięgają po AI do pisania zapytań SQL, opisu dashboardów czy eksploracji danych. To ogromne wsparcie, ale gdy bez przemyślenia zaczynają wklejać screeny z raportów lub sample tabel, w tle powstaje nieformalny „kanał eksportu” danych poza kontrolowane środowisko.

Przydają się więc jasne zapisy:

• Generowanie zapytań – tak, wynoszenie danych – nie
  AI może pomagać w schemacie „opisz mi tę tabelę, napisz zapytanie, popraw błąd”, ale z użyciem zanonimizowanych metadanych (nazwy tabel, kolumn) zamiast realnych rekordów.
• Zasada „najpierw wewnętrzne narzędzia”
  Jeżeli firma ma własne, zamknięte środowisko AI połączone z hurtownią danych, polityka powinna faworyzować je wprost: analityk w pierwszej kolejności sięga po wewnętrznego asystenta, dopiero w mniej wrażliwych przypadkach po narzędzia zewnętrzne.
• Brak eksportu pełnych raportów
  Screeny z dashboardów, tabele wyników, CSV z realnymi danymi – nie trafiają do narzędzi publicznych, nawet „tylko po to, żeby napisać ładne streszczenie”. Jeśli streszczenie jest potrzebne, powinno powstać wewnątrz środowiska BI lub wewnętrznego modelu.

Dobrym testem jest pytanie: „czy to, co wklejam, mogłoby trafić jako załącznik do maila wysłanego publicznie przez przypadek?”. Jeśli odpowiedź brzmi „nie”, to znaczy, że narzędzie też powinno być traktowane z większą ostrożnością.

Generowanie treści tekstowych – dokumentacja, maile, prezentacje

Tekstowy asystent AI błyskawicznie staje się „kopiarką pomysłów” – pomaga pisać maile, drafty polityk, opisy feature’ów. Tu ryzyko nie dotyczy tylko danych, ale też tonu komunikacji, poufności planów oraz… zwykłych błędów merytorycznych.

Przy formułowaniu zasad dla generowania treści dobrze jest jasno rozróżnić trzy obszary:

• Treści zewnętrzne
  Strona WWW, blog, maile do klientów, komunikacja PR. Zasada: AI może być używane do tworzenia draftów, ale finalna wersja jest zawsze sprawdzana przez człowieka odpowiedzialnego za dany obszar (marketing, prawnik, właściciel produktu). Polityka może też wprost zabraniać ujawniania w promptach informacji o roadmapie, przychodach, planowanych przejęciach itd.
• Treści wewnętrzne niestrategiczne
  Notatki ze spotkań, opisy tasków, instrukcje „how-to” dla zespołu. Tu można dopuścić większą swobodę, o ile nie pojawiają się dane klasy 3–4. AI może np. streszczać długie wątki z czatu, ale po wcześniejszym oczyszczeniu z danych osobowych.
• Treści regulacyjne i prawne
  Umowy, regulaminy, polityki formalne. AI może wspierać research i przygotowywanie szkieletu dokumentu, ale nie zastępuje prawnika. W polityce warto dopisać wyraźnie: „dokument wygenerowany przez AI nie jest źródłem prawa w firmie, dopóki nie zostanie zatwierdzony formalnie”.

Dzięki temu zespół nie ma wrażenia, że „nie wolno niczego”, tylko rozumie, gdzie AI jest partnerem, a gdzie tylko inspiracją, którą ktoś musi świadomie podpisać swoim nazwiskiem.

Odpowiedzialność człowieka – kto „podpisuje się” pod wynikiem AI

Najbardziej niebezpieczny nawyk brzmi: „tak wyszło z AI, więc tak zrobiliśmy”. Model nie ma odpowiedzialności prawnej ani zawodowej; człowiek – ma. Polityka powinna tę zasadę napisać grubą kreską.

Dobrym rozwiązaniem jest powiązanie odpowiedzialności z rolami:

• Developer odpowiada za to, że kod w repozytorium spełnia standardy jakości i licencyjne, niezależnie od tego, czy napisał go sam, czy podpowiedział go copilot.
• Analityk odpowiada za poprawność wniosków z danych i ich interpretację, nawet jeśli część analizy tekstowej przygotował model.
• Product owner / kierownik projektu odpowiada za decyzje biznesowe, które podejmuje na podstawie rekomendacji AI.

W praktyce oznacza to wymóg ludzkiej weryfikacji w krytycznych obszarach. Polityka może określić, w których procesach „AI-assisted” jest dopuszczalne (np. generowanie wariantów tekstu), a w których konieczne jest formalne potwierdzenie (np. decyzja o wdrożeniu zmiany w systemie finansowym).

Transparentność użycia AI wobec klientów i partnerów

Coraz częściej klienci pytają wprost: „czy używacie AI przy pracy nad naszym projektem?”. Brak jasnej odpowiedzi budzi nieufność, a zbyt ogólna deklaracja może z kolei wiązać ręce zespołowi. Dlatego polityka wewnętrzna powinna wspierać spójną komunikację na zewnątrz.

Przydaje się kilka zasad komunikacyjnych zapisanych w dokumencie:

• Zakres ujawniania
  Co mówimy klientowi w standardzie: np. że firma wykorzystuje narzędzia AI do wsparcia developerskiego i dokumentacyjnego, ale nie przekazuje do nich danych osobowych klientów bez odpowiednich umów.

Najczęściej zadawane pytania (FAQ)

Po co mi polityka użycia AI w zespole IT, skoro ludzie i tak już korzystają z narzędzi typu ChatGPT?

Polityka nie jest po to, żeby „odkleić” ludzi od AI, tylko żeby wprowadzić przewidywalne zasady gry. Skoro programiści, analitycy czy DevOpsi i tak używają modeli generatywnych, lepiej jasno określić, jakie dane wolno tam wkleić, jakich narzędzi używać i w jakich sytuacjach AI jest wręcz zalecana.

Bez polityki korzystanie z AI opiera się na intuicji, a ta zawodzi głównie przy danych wrażliwych: kodzie z kluczami API, logach z danymi osobowymi, fragmentach kontraktów. Polityka zamienia „jakoś to będzie” na konkrety: klasyfikację danych, listę bezpiecznych zastosowań, wymagania prawne i bezpieczeństwa, które każdy rozumie.

Jakie są największe ryzyka korzystania z AI w IT bez żadnych zasad?

Najczęściej chodzi o trzy obszary: dane, prawo i odpowiedzialność. Wysyłając kod, logi czy dokumenty do zewnętrznego SaaS, łatwo nieświadomie udostępnić tajemnicę przedsiębiorstwa lub dane osobowe. Z perspektywy GDPR/RODO to może być nieuprawnione przekazanie danych, a z perspektywy klienta – złamanie NDA.

Dochodzi do tego ryzyko naruszenia licencji (np. kod generowany na bazie projektów open source z „trudnymi” licencjami) oraz problem: kto odpowiada za błąd w systemie, jeśli kluczowy fragment napisała AI? Bez polityki trudno w ogóle udokumentować, kiedy i jak AI była użyta, więc rozmowa z audytorem czy klientem szybko zamienia się w gaszenie pożaru.

Co konkretnie powinno się znaleźć w polityce użycia AI dla zespołu IT?

Dobra polityka AI łączy kilka warstw: techniczną, prawną i organizacyjną. W praktyce przydaje się przynajmniej:

• klasyfikacja danych (co jest publiczne, wewnętrzne, poufne, ściśle tajne),
• matryca „co wolno / czego nie wolno” dla różnych typów danych i narzędzi AI,
• lista zatwierdzonych narzędzi (np. wewnętrzny chatbot, wybrani dostawcy SaaS z umową powierzenia danych),
• zasady oznaczania i przeglądu treści wygenerowanych przez AI (np. kodu w repozytorium),
• procedura reagowania na incydenty – co zrobić, gdy ktoś jednak wkleił za dużo.

Polityka powinna też wskazywać, w jakich obszarach AI jest wręcz rekomendowana, np. generowanie szablonowych testów jednostkowych z pseudokodu, szkiców dokumentacji czy draftów prezentacji, by ludzie widzieli w niej wsparcie, a nie zakazy.

Czy mogę bezpiecznie używać AI do analizy kodu, logów i dokumentacji technicznej?

Możesz, ale pod warunkiem, że panujesz nad tym, jakie dane wysyłasz i gdzie. Do publicznego narzędzia SaaS nie powinny trafiać:

• klucze API, tokeny, hasła, dane dostępu,
• dane osobowe (w logach, tikietach, zrzutach ekranu),
• poufne elementy logiki biznesowej klienta, objęte NDA.

Dla takich przypadków lepiej użyć lokalnego modelu AI (np. uruchomionego on-premise) lub pracować na zanonimizowanych danych: pseudokodzie zamiast pełnego modułu, „fałszywych” identyfikatorach zamiast prawdziwych.

Najprostsza zasada na start: jeśli nie pokazałbyś danego fragmentu podczas publicznej prezentacji na konferencji, nie wklejaj go do otwartego czatu AI bez sprawdzenia, jakie ma polityki przetwarzania danych i jakie umowy ma z Twoją firmą.

Jak przekonać zespół IT, że polityka AI to nie „kaganiec”, tylko pomoc?

Dobrze działa odwrócenie perspektywy: najpierw pokazujesz, w czym polityka pomaga, a dopiero potem mówisz o zakazach. Na przykład: „Tu jest lista rzeczy, które możecie śmiało robić z AI, bez obaw o RODO czy NDA. A tu – kilka czerwonych linii, za które nie przechodzimy”. Ludzie chcą wiedzieć, gdzie mają zielone światło.

Warto też podkreślać, że polityka stoi po stronie pracownika. Jeśli programista użył AI zgodnie z zasadami, ma mocny argument w rozmowie z przełożonym czy klientem: „Zrobiłem to tak, jak firma kazała, na zatwierdzonym narzędziu, bez danych produkcyjnych”. Dobrą praktyką jest wspólne przejście przez dokument na spotkaniu zespołu, z przestrzenią na pytania i przykłady z codziennej pracy.

Jakie przepisy prawne trzeba uwzględnić przy tworzeniu polityki AI w firmie IT?

Trzonem są regulacje, które i tak już obowiązują, tylko w świecie AI szybciej je naruszamy „przy okazji”. Najważniejsze to:

• RODO/GDPR – czyli wszystko, co dotyczy przetwarzania danych osobowych (logi, tickety, screeny, bazy),
• prawo autorskie i licencje – kto ma prawa do wygenerowanego kodu, dokumentacji, grafik i czy nie wchodzimy w konflikt z licencjami open source,
• tajemnica przedsiębiorstwa – zarówno Twojej firmy, jak i klientów (logika biznesowa, modele wyceny, procesy wewnętrzne).

Do tego dochodzą wewnętrzne polityki bezpieczeństwa informacji oraz regulacje branżowe (np. sektor finansowy, medyczny, publiczny). Dobra polityka AI „składa” to wszystko w jeden, zrozumiały dla zespołu zestaw zasad, zamiast odsyłać ludzi do kilku różnych, oderwanych dokumentów.

Czy trzeba prowadzić rejestr użycia AI w projektach IT, czy to przesada?

Prosty rejestr bardzo pomaga, zwłaszcza gdy pojawiają się pytania klientów albo audyt. Nie chodzi o śledzenie każdego prompta, tylko o możliwość odpowiedzi na pytanie: „Czy i w jaki sposób w tym projekcie korzystaliście z narzędzi AI? Czy przetwarzaliście nasze dane?”.

W praktyce wystarczy, że w projekcie odnotujecie: jakie narzędzia AI były używane, do czego (np. generowanie testów, refaktoryzacja pseudokodu, szkice dokumentacji) i czy dotyczyło to danych klienta, czy tylko materiałów wewnętrznych/testowych. Dzięki temu, gdy ktoś za rok zada trudne pytanie, nie trzeba przeszukiwać całego Slacka – jest konkretny punkt odniesienia.

Najważniejsze punkty

• Brak polityki AI nie oznacza braku AI w firmie – oznacza jej chaotyczne, nieudokumentowane użycie, w którym każdy działa „na czuja”, a ryzyka rosną po cichu.
• Niewinne wklejenie kodu, logów czy fragmentu kontraktu do zewnętrznego modelu może być realnym naruszeniem tajemnicy przedsiębiorstwa, RODO lub zapisów umów z klientem.
• Bez jasnych zasad trudno określić odpowiedzialność za skutki błędów wygenerowanych przez AI – spór „kto zawinił” przestaje być techniczny i wchodzi na poziom prawny oraz biznesowy.
• Dobrze ustawiona polityka AI działa jak tarcza i mapa jednocześnie: chroni przed wyciekami, a zarazem pokazuje, gdzie AI można używać agresywnie do przyspieszania pracy.
• Spójne zasady (np. klasyfikacja danych, lista bezpiecznych zastosowań, wskazane narzędzia) porządkują codzienną pracę: programista, analityk i product owner grają według tych samych reguł.
• Formalna polityka AI ułatwia rozmowy z prawnikami i klientami – zamiast ogólników firma pokazuje konkret: dokument, procedury, sposób audytu oraz granice użycia danych.
• W sytuacjach granicznych – jak analiza złożonego modułu rozliczeń – polityka powinna nie tylko zakazywać wklejania wrażliwego kodu do chmury, ale od razu wskazywać bezpieczną alternatywę (np. lokalne narzędzie, dane zanonimizowane lub pseudonimizowane).

Źródła informacji

• EU AI Act (Artificial Intelligence Act). European Union (2024) – Ramowe wymogi prawne i zarządzanie ryzykiem systemów AI w UE
• OECD AI Principles. OECD (2019) – Zasady odpowiedzialnego użycia AI, zarządzanie ryzykiem i transparentność
• NIST AI Risk Management Framework. National Institute of Standards and Technology (2023) – Metodyka identyfikacji, oceny i kontroli ryzyka związanego z AI
• ISO/IEC 42001 Artificial intelligence — Management system. ISO (2023) – System zarządzania dla organizacji wykorzystujących AI, polityki i kontrola