AI Act w outsourcingu IT
Kto odpowiada za wykorzystanie AI w projekcie?
25.08.2026
AI jest już stałym elementem pracy zespołów tworzących oprogramowanie. Przyspiesza development, pomaga analizować kod i automatyzuje część zadań, ale nie przejmuje odpowiedzialności za bezpieczeństwo, jakość ani sposób wykorzystania danych.
Od 2 sierpnia 2026 roku, kiedy zaczęła być stosowana zasadnicza część AI Act, pytanie o nadzór nad AI nabrało dodatkowego znaczenia.
Kto powinien ustalać zasady korzystania z narzędzi, kontrolować wygenerowany kod i reagować na ryzyko, gdy w projekcie pracują zewnętrzni specjaliści?
Odpowiedź zależy nie tylko od przepisów, lecz także od modelu współpracy z dostawcą.
AI Act w tworzeniu oprogramowania - co zmieniło się 2 sierpnia?
Chociaż AI Act wszedł z życie 1 sierpnia 2024 roku, to jego przepisy są stosowane etapami. Zakazane praktyki oraz obowiązki związane z AI literacy zaczęły obowiązywać 2 lutego 2025 roku. Nieco ponad rok później, 2 sierpnia 2026 roku, zaczęła być stosowana zasadnicza część rozporządzenia, a organy odpowiedzialne za jego egzekwowanie uzyskały odpowiednie uprawnienia. Niektóre regulacje dotyczące systemów wysokiego ryzyka mają dłuższe okresy przejściowe.
Nie oznacza to, że od tej daty każdy dostawca software’u automatycznie staje się dostawcą systemu AI w rozumieniu rozporządzenia. AI Act rozróżnia między innymi dostawców systemów AI oraz podmioty wykorzystujące takie systemuy pod swoją kontrolą. Rola organizacji zależy od tego, co tworzy, udostępnia i w jaki sposób korzysta z AI.
Dla firm tworzących oprogramowanie, oprócz formalnej klasyfikacji systemu znaczenie ma także to, że AI stało się częścią codziennej pracy specjalistów. Programiści (i nie tylko) wykorzystują AI w tworzeniu i analizowaniu kodu, generowaniu testów, przygotowywaniu dokumentacji, wyszukiwaniu błędów czy porządkowanku wymagań.
W ten sposób AI Act w tworzeniu oprogramowania przestaje być zagadnieniem jedynie dla działów prawnych. Dotyczy również decyzji podejmowanych przez CTO, Delivery Managerów, liderów zespołów oraz firmy korzystające z zewnętrznych specjalistów.
Korzystanie z AI przez programistów nie oznacza autonomicznej pracy AI
Skala wykorzystania AI rośnie znacznie szybciej niż możliwość pozostawienia mu pełnej kontroli nad zadaniem.
W badaniu Anthropic pracownicy firmy deklarowali, że korzystają z Claude w blisko 60% swojej pracy. Jednocześnie większość z nich oceniała, że może całkowicie powierzyć AI jedynie od 0 do 20% zadań. W pozostałych przypadkach potrzebne są aktywne prowadzenie narzędzia, dostarczenie kontekstu, ocena odpowiedzi i weryfikacja efektu.
Raport „2026 Agentic Coding Trends” pokazuje ten sam kierunek w odniesieniu do rozwoju oprogramowania: praca stopniowo przesuwa się od samodzielnego pisania całego kodu w stronę kierowania agentami, oceniania ich działań i integrowania wygenerowanych elementów z większym rozwiązaniem.
Nie znaczy to, że AI wykonuje większość pracy za człowieka. Oznacza raczej, że uczestniczy w wielu etapach procesu, ale nadal wymaga specjalistycznego nadzoru. Deweloper nie odpowiada już wyłącznie za kod, który napisał samodzielnie. Odpowiada również za to, co zaakceptował, zmodyfikował i dopuścił do dalszego wykorzystania.
Im większy udział AI w software development, tym ważniejsza staje się więc umiejętność rozpoznania sytuacji, w których wynik wygląda poprawnie, ale zawiera błąd, nie uwzględnia kontekstu projektu albo tworzy ryzyko trudne do zauważenia podczas pobieżnego przeglądu.
Bezpieczeństwo kodu generowanego przez AIU nadal wymaga kontroli
Jednym z najbardziej konkretnych ryzyk jest bezpieczeństwo kodu generowanego przez AI.
W badaniu Veracode obejmującym ponad 150 modeli tylko 55% zadań generowania kodu zakończyło się powstaniem rozwiązania uznanego za bezpieczne. W pozostałych 45% przypadków model wprowadził znaną podatność. Badanie wykazało również, że nowsze i większe modele nie osiągały automatycznie lepszych wyników pod względem bezpieczeństwa.
Nie oznacza to, że 45% każdej aplikacji tworzonej z wykorzystaniem AI zawiera podatności. Wynik dotyczy konkretnych zadań testowych i nie powinien być bezpośrednio przenoszony na każdą bazę kodu. Pokazuje jednak istotny problem: kod może być poprawny składniowo, kompilować się i realizować oczekiwaną funkcję, a mimo to zawierać błąd bezpieczeństwa.
Ryzyko nie ogranicza się przy tym do samego kodu. Wykorzystanie publicznego narzędzia bez uzgodnionych zasad może prowadzić do przekazania modelowi fragmentów kodu źródłowego, danych klienta, informacji o architekturze systemu, danych osobowych lub innych informacji poufnych.
AI może również zaproponować nieistniejącą bibliotekę, zastosować nieaktualne rozwiązanie, pominąć istotny przypadek brzegowy albo stworzyć kod, którego autor nie rozumie wystarczająco dobrze, aby świadomie wziąć za niego odpowiedzialność.
AI przyspiesza więc tworzenie rozwiązań, ale może równie szybko skalować błędy. Problemem nie jest samo korzystanie z narzędzia. Problem pojawia się wtedy, gdy wzrost tempa nie idzie w parze ze wzrostem kontroli.
Co AI Act mówi o osobach korzystających z AI w imieniu organizacji?
W dyskusji o AI Act w outsourcingu IT szczególnie istotny jest artykuł 4 dotyczący AI literacy. Obowiązuje on już od 2 lutego 2025 roku, a zmiany przyjęte w 2026 roku nie usunęły tego obowiązku.
Zgodnie z aktualnym podejściem dostawcy i podmioty wykorzystujące systemy AI powinni podejmować działania wspierające rozwój kompetencji dotyczących AI wśród swoich pracowników oraz innych osób zajmujących się obsługą i wykorzystaniem systemów AI w ich imieniu.
Komisja Europejska wyjaśnia, że do tej drugiej grupy mogą należeć między innymi kontraktorzy i usługodawcy znajdujący się w organizacyjnym obszarze odpowiedzialności danego podmiotu.
AI literacy nie oznacza przy tym jednego obowiązkowego szkolenia dla wszystkich ani konieczności osiągnięcia przez każdą osobę identycznego poziomu wiedzy. Działania powinny uwzględniać doświadczenie użytkowników, charakter wykorzystywanego systemu, kontekst zastosowania oraz związane z nim ryzyko.
W praktyce nie wystarczy więc przekazać specjaliście dostęp do narzędzia. Potrzebne jest również rozumienie jego ograniczeń, zasad ochrony danych, możliwych konsekwencji błędu oraz sposobu sprawowania nadzoru nad rezultatami.
Jednocześnie AI Act nie daje prostej, uniwersalnej odpowiedzi na pytanie, kto w konkretnym projekcie ma zatwierdzić narzędzie, skontrolować wygenerowany kod czy odpowiadać za rezultat pracy. To zależy również od sposobu organizacji projektu i ustaleń między klientem a dostawcą.
Odpowiedzialność prawna, kontraktowa i operacyjna to nie to samo
Rozmowa o odpowiedzialności za AI często prowadzi do poszukiwania jednej strony, która „odpowiada za wszystko”. W praktyce odpowiedzialność jest podzielona na kilka poziomów.
Odpowiedzialność wynikająca z AI Act zależy od roli organizacji w rozumieniu rozporządzenia oraz od sposobu wykorzystania konkretnego systemu. Odpowiedzialność kontraktowa wynika z umowy zawartej pomiędzy klientem a dostawcą. Z kolei odpowiedzialność operacyjna pokazuje, kto rzeczywiście podejmuje codzienne decyzje: wybiera narzędzia, organizuje pracę, kontroluje jakość i akceptuje rezultat.
Te trzy poziomy nie zawsze pokrywają się ze sobą.
Samo zlecenie pracy na zewnątrz nie powoduje automatycznego przeniesienia wszystkich obowiązków na firmę zewnętrzną. Nie oznacza też, że cała odpowiedzialność zawsze pozostaje po stronie klienta. Znaczenie ma rzeczywisty zakres usługi: kto zarządza specjalistą, kto udostępnia środowisko pracy, kto ustala zasady oraz kto odpowiada za efekt.
Dlatego pytanie „czyja jest odpowiedzialność?” warto zastąpić bardziej precyzyjnymi pytaniami:
- Kto decyduje, z jakich narzędzi AI można korzystać?
- Czy specjalista pracuje na koncie prywatnym, koncie dostawcy czy w środowisku klienta?
- Jakich danych nie wolno przekazywać do modelu?
- Kto weryfikuje rezultat pracy?
- Kto akceptuje kod przed wdrożeniem?
- Jak wygląda reakcja na błąd lub incydent?
- Czy te ustalenia są zgodne z wymaganiami klienta i charakterem projektu?
Dopiero odpowiedzi na te pytania pokazują, gdzie rzeczywiście znajduje się kontrola.
AI Act w outsourcingu IT: staff augmentation a managed service
Różnica jest szczególnie widoczna przy porównaniu staff augmentation z usługą zarządzaną.
W modelu staff augmentation zewnętrzny specjalista dołącza do zespołu klienta. Najczęściej pracuje w jego środowisku, realizuje zadania zgodnie z jego procesem i podlega jego bieżącemu zarządzaniu. Klient zachowuje dzięki temu dużą kontrolę nad pracą, ale zwykle pozostaje również odpowiedzialny za określenie zasad korzystania z narzędzi, organizację nadzoru oraz akceptację rezultatów.
Nie zwalnia to dostawcy z odpowiedzialnego doboru specjalisty ani z obowiązków wynikających z własnej roli. Pokazuje jednak, że sam fakt pozyskania eksperta od zewnętrznej firmy nie oznacza przejęcia przez nią całego procesu kontroli AI.
W managed service dostawca odpowiada za określony obszar, proces lub rezultat, a nie tylko za udostępnienie kompetencji. Może więc przejąć szerszą odpowiedzialność operacyjną za organizację pracy zespołu, sposób realizacji zadań, kontrolę jakości oraz stosowane narzędzia.
Nie oznacza to automatycznego przeniesienia wszystkich obowiązków prawnych z klienta na dostawcę. Zakres odpowiedzialności nadal zależy od roli każdej ze stron, wykorzystania AI oraz zapisów umowy. Z perspektywy klienta zmienia się jednak coś bardzo konkretnego: nie musi samodzielnie zarządzać każdą decyzją podejmowaną przez poszczególnych specjalistów, ponieważ część tej kontroli staje się elementem świadczonej usługi.
Nazwa modelu współpracy nie wystarczy więc do określenia odpowiedzialności. Liczy się to, kto faktycznie ustala zasady, sprawuje nadzór i odpowiada za rezultat.
Co należy ustalić, zanim specjalista zacznie pracować z AI?
Odpowiedzialne korzystanie z AI w projekcie nie zaczyna się od wyboru konkretnego modelu. Zaczyna się od określenia zasad, według których narzędzie może być używane.
Klient i dostawca powinni przede wszystkim ustalić:
- jakie narzędzia AI są dopuszczone w projekcie;
- na jakich kontach i w jakim środowisku można z nich korzystać;
- jakie informacje mogą być przekazywane do modelu;
- jakie dane, fragmenty kodu i dokumenty są wyłączone z użycia;
- w jakich zadaniach AI może pomagać specjaliście;
- jak będzie przebiegać kontrola kodu i innych rezultatów;
- kto odpowiada za ich ostateczną akceptację;
- czy i w jakim zakresie wykorzystanie AI powinno być dokumentowane;
- jak należy postąpić w przypadku błędu, nieautoryzowanego użycia lub podejrzenia ujawnienia danych.
Zakres tych ustaleń powinien odpowiadać ryzyku. Innych zabezpieczeń może wymagać przygotowanie wewnętrznego prototypu, a innych rozwój systemu przetwarzającego dane osobowe, finansowe lub medyczne.
Dlatego jedna ogólna polityka AI nie rozwiąże wszystkich problemów. Może wyznaczyć podstawowe granice, ale zasady pracy powinny być dopasowane do projektu, środowiska klienta, wykorzystywanych narzędzi i poziomu wrażliwości danych.
AI governance w software development musi rozwijać się razem z technologią
Narzędzia zmieniają się szybciej niż większość wewnętrznych polityk. Pojawiają się nowe modele, agenci otrzymują szerszy dostęp do repozytoriów i środowisk, a zadania, które jeszcze niedawno wymagały stałego prowadzenia, mogą być wykonywane coraz bardziej autonomicznie.
Dlatego AI governance w software development nie powinno być jednorazowym dokumentem przygotowanym wyłącznie po to, aby formalnie zamknąć temat AI Act. Potrzebny jest proces, który pozwala ponownie oceniać narzędzia, ryzyko i zakres kontroli.
W Infolet wychodzimy z założenia, że sposób korzystania z AI nie powinien pozostawać indywidualną i nieuzgodnioną decyzją specjalisty. Narzędzia, zakres wykorzystywanych danych, sposób weryfikowania efektów oraz podział odpowiedzialności powinny wynikać z charakteru projektu, modelu współpracy i wymagań klienta.
Podejście do AI będzie się nadal rozwijać wraz z technologią, regulacjami i doświadczeniem zespołów. Nie chodzi więc o stworzenie jednego zestawu zasad dla wszystkich klientów, ale o świadome ustalenie, jak AI może być wykorzystywane w konkretnym środowisku i kto odpowiada za poszczególne elementy kontroli.
AI nie usuwa odpowiedzialności. Zmienia sposób jej organizowania.
Korzystając z zewnętrznych kompetencji IT, firma nie kupuje dziś wyłącznie czasu i wiedzy specjalisty. Wybiera również model, w którym określony zostanie zakres kontroli nad jego pracą.
W staff augmentation klient zachowuje większy wpływ na sposób organizacji pracy, ale musi także świadomie zarządzać zasadami wykorzystywania AI. W usłudze zarządzanej dostawca może przejąć większą część odpowiedzialności operacyjnej za proces i rezultat. W obu przypadkach podział ról powinien zostać nazwany, uzgodniony i dostosowany do ryzyka projektu.
AI może skrócić czas tworzenia rozwiązania. Bez odpowiedniego nadzoru może jednak równie szybko zwiększyć dług technologiczny, ryzyko bezpieczeństwa i niepewność prawną.
Dlatego przed rozpoczęciem współpracy warto pytać nie tylko o kompetencje specjalistów i znajomość narzędzi AI. Równie ważne jest ustalenie, kto zdecyduje, jak można z nich korzystać, kto sprawdzi efekty oraz kto weźmie odpowiedzialność za to, co ostatecznie trafi do projektu.
Planujesz zaangażować zewnętrznych specjalistów lub powierzyć dostawcy większy obszar projektu? Porozmawiajmy o modelu współpracy dopasowanym do zakresu, ryzyka i potrzeb Twojej organizacji.
Artykuł ma charakter informacyjny i nie stanowi porady prawnej.
Źródła:
