AI Act a odpowiedzialność software house’u — Provider, Deployer i obowiązki przy wdrażaniu sztucznej inteligencji

Wykorzystanie sztucznej inteligencji w projektach informatycznych przestało być rozwiązaniem zarezerwowanym dla największych przedsiębiorstw technologicznych. Polskie software house’y coraz częściej tworzą aplikacje wykorzystujące modele językowe, wdrażają chatboty obsługujące klientów, budują systemy automatyzujące procesy biznesowe oraz integrują rozwiązania AI z istniejącym oprogramowaniem przedsiębiorstw. W wielu przypadkach wykonawca nie opracowuje własnego modelu sztucznej inteligencji, lecz korzysta z technologii dostarczanej przez zewnętrzny podmiot, dostosowując ją do potrzeb konkretnego klienta. Powstaje wówczas pytanie, kto ponosi odpowiedzialność za zgodność takiego rozwiązania z prawem, kto powinien przygotować dokumentację wymaganą przez AI Act oraz czy software house może ograniczyć swoje obowiązki poprzez odpowiednie postanowienia umowy wdrożeniowej.

Problem jest szczególnie istotny w kontekście rozporządzenia Parlamentu Europejskiego i Rady (UE) 2024/1689, określanego jako AI Act. Regulacja ta wprowadziła jednolite zasady dotyczące opracowywania, udostępniania i wykorzystywania systemów sztucznej inteligencji na rynku Unii Europejskiej. Wbrew częstemu przekonaniu AI Act nie dotyczy wyłącznie przedsiębiorstw tworzących własne modele AI. Obowiązki mogą obejmować również firmy integrujące gotowe modele z aplikacjami, przedsiębiorców oferujących systemy AI pod własną marką, podmioty wykorzystujące sztuczną inteligencję w procesach biznesowych oraz dostawców komponentów wykorzystywanych w rozwiązaniach wysokiego ryzyka.

Kluczowe znaczenie ma prawidłowe ustalenie roli przedsiębiorcy w całym procesie. AI Act posługuje się między innymi pojęciami provider oraz deployer, które w polskiej wersji rozporządzenia odpowiadają dostawcy i podmiotowi stosującemu system AI. Rozróżnienie to nie ma wyłącznie charakteru terminologicznego. Od prawidłowej kwalifikacji zależy zakres obowiązków prawnych, odpowiedzialność za dokumentację, sposób przeprowadzania oceny zgodności, zasady monitorowania systemu oraz zakres informacji, które należy przekazać użytkownikom.

Dla software house’u oznacza to konieczność przeprowadzenia analizy prawnej już na etapie przygotowywania oferty. Nie wystarczy bowiem ustalić, jakie funkcjonalności ma posiadać aplikacja i ile będzie kosztowało jej wykonanie. Należy również odpowiedzieć na pytanie, czy wykonawca będzie jedynie technicznym podwykonawcą, czy też stanie się dostawcą systemu AI w rozumieniu unijnych przepisów. W niektórych przypadkach pozornie niewielka zmiana modelu biznesowego, sposobu udostępniania aplikacji albo jej przeznaczenia może istotnie zmienić sytuację prawną przedsiębiorstwa.

Czym jest system AI w rozumieniu AI Act?

Punktem wyjścia do analizy odpowiedzialności powinno być ustalenie, czy tworzone lub wykorzystywane rozwiązanie rzeczywiście stanowi system sztucznej inteligencji w rozumieniu rozporządzenia. Nie każda automatyzacja procesu biznesowego, aplikacja wykorzystująca rozbudowane algorytmy czy system oparty na regułach logicznych będzie automatycznie kwalifikowany jako system AI. Rozporządzenie posługuje się własną definicją, która odnosi się do systemu maszynowego zaprojektowanego do działania z różnym poziomem autonomii, mogącego wykazywać zdolność adaptacji po wdrożeniu i wnioskującego na podstawie otrzymanych danych wejściowych, w jaki sposób generować wyniki, takie jak przewidywania, treści, zalecenia lub decyzje wpływające na środowisko fizyczne albo wirtualne.

W praktyce do kategorii systemów AI mogą należeć aplikacje analizujące dokumenty przy wykorzystaniu modeli językowych, systemy rekomendacyjne, rozwiązania wspierające ocenę kandydatów do pracy, narzędzia służące do automatycznej klasyfikacji zgłoszeń czy aplikacje podejmujące decyzje na podstawie danych przetwarzanych przez modele uczenia maszynowego. Sama obecność rozbudowanego algorytmu nie jest jednak wystarczająca do dokonania kwalifikacji. Konieczne jest ustalenie rzeczywistego sposobu działania rozwiązania, stopnia autonomii oraz mechanizmu generowania wyników.

Dla przedsiębiorcy ma to istotne znaczenie, ponieważ błędne zakwalifikowanie zwykłego oprogramowania jako systemu AI może prowadzić do niepotrzebnego wdrażania procedur i ponoszenia kosztów. Z drugiej strony uznanie systemu wykorzystującego sztuczną inteligencję za zwykłą aplikację może skutkować pominięciem obowiązków wynikających z rozporządzenia. Dlatego pierwszym etapem audytu prawnego projektu AI powinno być zawsze ustalenie, czy dane rozwiązanie mieści się w definicji systemu AI oraz jakie funkcje faktycznie realizuje.

Provider i Deployer — podstawowa różnica w AI Act

AI Act definiuje dostawcę, czyli provider, jako podmiot, który opracowuje system AI albo model AI ogólnego przeznaczenia lub zleca jego opracowanie, a następnie wprowadza go do obrotu albo oddaje system do użytku pod własną nazwą lub znakiem towarowym. Definicja obejmuje zarówno przedsiębiorców, jak i inne podmioty, a odpłatność nie jest warunkiem koniecznym uznania za dostawcę. Oznacza to, że również bezpłatne udostępnienie rozwiązania może prowadzić do powstania określonych obowiązków regulacyjnych.

Podmiot stosujący system AI, czyli deployer, to natomiast podmiot wykorzystujący system AI w ramach swojej działalności i pod własną odpowiedzialnością, z wyłączeniem sytuacji, w których system jest używany wyłącznie w ramach osobistej działalności pozazawodowej. Typowym przykładem będzie przedsiębiorca korzystający z narzędzia AI do obsługi klientów, analizy dokumentów, wspierania procesów rekrutacyjnych albo automatyzacji pracy działu księgowego. Podmiot taki nie musi tworzyć własnego oprogramowania ani posiadać wiedzy dotyczącej budowy modelu, aby podlegać określonym obowiązkom wynikającym z AI Act.

Najważniejsza różnica polega zatem na roli pełnionej przez przedsiębiorcę. Dostawca odpowiada za opracowanie i udostępnienie systemu w określonym modelu prawnym, natomiast podmiot stosujący wykorzystuje system w swojej działalności. W praktyce granica pomiędzy tymi kategoriami może być jednak mniej oczywista, szczególnie gdy oprogramowanie jest rozwijane przez zewnętrzny software house, udostępniane pod marką klienta albo modyfikowane już po wdrożeniu.

Należy również pamiętać, że role przewidziane w AI Act nie zawsze są wzajemnie wykluczające się. Przedsiębiorstwo może być dostawcą jednego systemu, podmiotem stosującym inny system oraz jednocześnie dostawcą określonych komponentów wykorzystywanych przez klientów. Sama nazwa stanowiska, sposób opisania współpracy w ofercie czy określenie wykonawcy jako integratora nie przesądzają jeszcze o jego rzeczywistej kwalifikacji prawnej.

Czy software house tworzący aplikację AI automatycznie staje się dostawcą?

Nie. Sam fakt opracowania aplikacji wykorzystującej sztuczną inteligencję nie oznacza automatycznie, że software house będzie dostawcą systemu AI w rozumieniu rozporządzenia. Konieczne jest ustalenie, kto wprowadza system do obrotu lub oddaje go do użytku, pod czyją nazwą jest on udostępniany, kto określa jego przeznaczenie oraz jaką rolę pełni wykonawca w całym procesie.

Można wyobrazić sobie sytuację, w której przedsiębiorca zamawia stworzenie wewnętrznego systemu AI służącego do analizy dokumentów, a software house wykonuje wyłącznie prace programistyczne zgodnie ze specyfikacją klienta. System jest następnie wykorzystywany przez zamawiającego pod jego własną odpowiedzialnością. W takim przypadku nie można automatycznie przyjmować, że wykonawca jest dostawcą wyłącznie dlatego, że napisał kod. Należy zbadać rzeczywisty model udostępnienia systemu, treść umowy, zakres odpowiedzialności stron oraz to, kto formalnie i faktycznie oddaje rozwiązanie do użytku.

Inaczej może wyglądać sytuacja, gdy software house opracowuje własną aplikację AI, oferuje ją wielu klientom w modelu SaaS, samodzielnie określa jej funkcjonalności i udostępnia ją pod własną marką. Wówczas istnieją znacznie mocniejsze podstawy do uznania przedsiębiorstwa za dostawcę systemu AI. Nie zmienia tego fakt, że aplikacja wykorzystuje model językowy opracowany przez innego dostawcę. Dostawca modelu i dostawca gotowego systemu AI mogą bowiem stanowić dwa odrębne podmioty, na których ciążą różne obowiązki.

Z perspektywy praktyki kontraktowej szczególnie niebezpieczne jest pozostawienie tej kwestii bez jakiejkolwiek regulacji. Jeżeli umowa wdrożeniowa ogranicza się do wskazania funkcjonalności, terminu realizacji i wynagrodzenia, może nie odpowiadać na najważniejsze pytanie dotyczące odpowiedzialności regulacyjnej. W razie sporu każda ze stron może twierdzić, że obowiązki wynikające z AI Act powinien wykonać drugi podmiot, mimo że rozporządzenie przypisuje je według rzeczywistej roli w łańcuchu wartości.

Czy wykorzystanie zewnętrznego modelu AI zwalnia software house z odpowiedzialności?

Jednym z najczęstszych modeli tworzenia aplikacji AI jest korzystanie z gotowych modeli językowych udostępnianych za pośrednictwem API. Software house buduje interfejs, logikę biznesową, system zarządzania użytkownikami, bazę danych oraz mechanizmy komunikacji z modelem, ale sam nie opracowuje podstawowego modelu sztucznej inteligencji. Tak powstają między innymi chatboty, systemy analizy dokumentów, asystenci obsługi klienta oraz aplikacje wykorzystujące technikę Retrieval-Augmented Generation, czyli RAG.

W takim przypadku należy odróżnić dostawcę modelu AI ogólnego przeznaczenia od dostawcy systemu AI wykorzystującego ten model. Podmiot opracowujący model może podlegać obowiązkom przewidzianym dla dostawców modeli ogólnego przeznaczenia, natomiast przedsiębiorca integrujący model z konkretną aplikacją może stać się dostawcą odrębnego systemu AI. Nie oznacza to, że każda integracja API prowadzi automatycznie do takiej kwalifikacji, ale samo korzystanie z technologii zewnętrznego dostawcy nie stanowi zwolnienia z obowiązków.

Przykładowo software house może stworzyć aplikację umożliwiającą automatyczną analizę dokumentów księgowych, a następnie oferować ją przedsiębiorcom w modelu abonamentowym. Jeżeli aplikacja jest udostępniana pod marką software house’u, a przedsiębiorstwo określa jej przeznaczenie i sposób działania, może ono pełnić rolę dostawcy systemu AI, mimo że model językowy pochodzi od zewnętrznego podmiotu. Dostawca modelu odpowiada za własne obowiązki, natomiast dostawca aplikacji powinien przeanalizować obowiązki odnoszące się do oferowanego przez siebie rozwiązania.

Z prawnego punktu widzenia niezwykle istotne jest również ustalenie, jakie informacje dostawca modelu przekazuje integratorowi. Jeżeli aplikacja ma zostać zakwalifikowana jako system wysokiego ryzyka, przedsiębiorca odpowiedzialny za gotowy system może potrzebować dokumentacji, informacji technicznych i odpowiedniego wsparcia od podmiotów dostarczających poszczególne komponenty. Brak takich informacji może istotnie utrudnić wykazanie zgodności całego rozwiązania z wymaganiami rozporządzenia.

AI Act a aplikacja rekrutacyjna — przykład odpowiedzialności software house’u

Wyobraźmy sobie polski software house, który otrzymuje zlecenie stworzenia aplikacji wspierającej rekrutację pracowników. System ma analizować CV, porównywać doświadczenie kandydatów z wymaganiami stanowiska i przygotowywać ranking osób najlepiej odpowiadających profilowi poszukiwanego pracownika. Aplikacja wykorzystuje zewnętrzny model językowy, natomiast software house opracowuje mechanizmy oceny, interfejs oraz integrację z systemem HR klienta.

Taki projekt wymaga szczególnej ostrożności, ponieważ systemy AI wykorzystywane do określonych czynności związanych z rekrutacją i selekcją kandydatów zostały wymienione w załączniku III do AI Act jako rozwiązania mogące należeć do kategorii wysokiego ryzyka. Nie oznacza to, że każda aplikacja wykorzystywana przez dział HR automatycznie podlega wszystkim obowiązkom przewidzianym dla systemów wysokiego ryzyka. Konieczne jest zbadanie rzeczywistego przeznaczenia systemu, charakteru wykonywanych zadań oraz ewentualnych przesłanek wyłączających kwalifikację wysokiego ryzyka.

Jeżeli aplikacja rzeczywiście służy do oceny kandydatów i wpływa na podejmowanie decyzji rekrutacyjnych, ryzyko zakwalifikowania jej jako systemu wysokiego ryzyka jest znaczne. Wówczas należy ustalić, kto będzie dostawcą rozwiązania, kto odpowiada za jego dokumentację, kto przeprowadzi wymagane procedury oceny zgodności oraz kto będzie monitorował działanie systemu po wdrożeniu. Trzeba również określić zasady nadzoru człowieka nad wynikami generowanymi przez aplikację i sposób reagowania na błędne albo dyskryminujące rekomendacje.

W praktyce może się okazać, że software house jest wyłącznie wykonawcą technicznym, a klient odpowiada za udostępnienie systemu pod własną marką. Możliwa jest jednak również sytuacja odwrotna, w której software house dostarcza gotowy produkt rekrutacyjny wielu przedsiębiorcom, a jego klienci pełnią rolę podmiotów stosujących. Odpowiedzialność nie powinna być więc ustalana na podstawie samego faktu finansowania projektu, lecz na podstawie rzeczywistych czynności i definicji zawartych w AI Act.

Czy klient może stać się dostawcą systemu AI?

Tak. Jednym z najważniejszych przepisów dla przedsiębiorców wdrażających sztuczną inteligencję jest art. 25 AI Act, który reguluje odpowiedzialność w łańcuchu wartości AI. Przepis przewiduje sytuacje, w których podmiot pierwotnie występujący w innej roli może zostać uznany za dostawcę systemu wysokiego ryzyka. Ma to szczególne znaczenie w przypadku modyfikowania istniejących rozwiązań, udostępniania ich pod własną marką oraz zmiany przeznaczenia systemu.

Pierwsza sytuacja dotyczy umieszczenia własnej nazwy lub znaku towarowego na systemie AI wysokiego ryzyka, który został już wprowadzony do obrotu albo oddany do użytku. Jeżeli przedsiębiorca przejmuje taki system i udostępnia go pod własną marką, może zostać uznany za jego dostawcę na zasadach określonych w rozporządzeniu. W praktyce może to dotyczyć modeli white label, w których software house opracowuje gotowe rozwiązanie, a klient oferuje je następnie jako własny produkt.

Druga sytuacja obejmuje istotną modyfikację systemu AI wysokiego ryzyka. Jeżeli przedsiębiorca wprowadza zmiany spełniające przesłanki istotnej modyfikacji w rozumieniu AI Act, może przejąć obowiązki dostawcy. Nie każda aktualizacja, zmiana interfejsu albo modyfikacja konfiguracji będzie jednak automatycznie uznawana za istotną modyfikację. Konieczne jest zbadanie zakresu zmian, ich wpływu na zgodność systemu oraz tego, czy zostały przewidziane w pierwotnej ocenie zgodności.

Trzecia sytuacja dotyczy zmiany przeznaczenia systemu, który wcześniej nie był klasyfikowany jako system wysokiego ryzyka. Jeżeli przedsiębiorca zmienia jego przeznaczenie w taki sposób, że rozwiązanie staje się systemem wysokiego ryzyka, może zostać uznany za dostawcę. Przykładowo ogólny system analizy dokumentów może zostać dostosowany do oceny kandydatów do pracy, co wymaga ponownej analizy jego kwalifikacji prawnej.

Warto podkreślić, że art. 25 nie oznacza automatycznego przeniesienia wszystkich obowiązków na dowolnego klienta dokonującego jakiejkolwiek modyfikacji. Przepis określa konkretne przesłanki, a jego zastosowanie wymaga analizy danego systemu i sposobu jego wykorzystania. Niemniej dla software house’ów oraz ich klientów jest to jeden z najważniejszych przepisów regulujących odpowiedzialność za rozwiązania AI.

Czy umowa może przenieść obowiązki wynikające z AI Act?

Umowa może regulować podział zadań pomiędzy stronami, ale nie zawsze pozwala zmienić kwalifikację prawną wynikającą bezpośrednio z rozporządzenia. Jeżeli przedsiębiorca jest dostawcą systemu AI w rozumieniu AI Act, samo wpisanie do kontraktu, że wszystkie obowiązki regulacyjne ponosi klient, nie musi zwolnić go z odpowiedzialności wobec właściwych organów. Podobnie klient, który rzeczywiście pełni rolę dostawcy, nie może zakładać, że zostanie zwolniony z obowiązków wyłącznie dlatego, że wykonawca zobowiązał się do przygotowania dokumentacji.

Nie oznacza to jednak, że postanowienia umowne są pozbawione znaczenia. Przeciwnie, odpowiednio przygotowana umowa wdrożeniowa może określać, która strona odpowiada za przygotowanie dokumentacji technicznej, przeprowadzenie testów, dostarczenie informacji dotyczących danych treningowych, wdrożenie mechanizmów nadzoru człowieka, przeprowadzenie oceny zgodności oraz monitorowanie systemu po jego uruchomieniu. Można również ustalić zasady współpracy przy kontrolach, odpowiedzialność za naruszenie zobowiązań kontraktowych i sposób rozliczania kosztów związanych z koniecznością wprowadzenia zmian.

Szczególnie ważne jest rozróżnienie odpowiedzialności regulacyjnej od odpowiedzialności kontraktowej. Organ nadzorczy będzie oceniał obowiązki wynikające z przepisów, natomiast relacje finansowe pomiędzy software house’em a klientem mogą być dodatkowo regulowane umową. Odpowiednio skonstruowane postanowienia mogą więc ograniczyć ryzyko gospodarcze wykonawcy, ale nie powinny być traktowane jako sposób całkowitego wyłączenia obowiązków wynikających z AI Act.

Jakie obowiązki ma dostawca systemu AI wysokiego ryzyka?

W przypadku systemów zakwalifikowanych jako wysokiego ryzyka AI Act przewiduje rozbudowany zestaw wymagań dotyczących ich projektowania, dokumentowania, udostępniania i monitorowania. Dostawca powinien zapewnić zgodność systemu z właściwymi wymaganiami rozporządzenia, wdrożyć odpowiednie procesy zarządzania ryzykiem oraz przygotować dokumentację pozwalającą wykazać spełnienie obowiązków. Znaczenie mają również jakość i zarządzanie danymi wykorzystywanymi w systemie, przejrzystość działania, możliwość prowadzenia rejestrów zdarzeń, nadzór człowieka oraz odpowiedni poziom dokładności, odporności i cyberbezpieczeństwa.

Jednym z najważniejszych elementów jest system zarządzania ryzykiem, który powinien obejmować cały cykl życia rozwiązania. Nie wystarczy jednorazowe sprawdzenie aplikacji przed przekazaniem jej klientowi. Należy analizować zagrożenia wynikające z przewidzianego sposobu używania systemu, możliwe błędy, przewidywalne niewłaściwe wykorzystanie oraz skutki dla osób, których dotyczą wyniki generowane przez AI. W przypadku aplikacji rekrutacyjnej mogą to być między innymi ryzyka związane z dyskryminacją kandydatów, błędną oceną kwalifikacji albo nadmiernym poleganiem na automatycznie wygenerowanych rekomendacjach.

Dostawca systemu wysokiego ryzyka powinien również przygotować wymaganą dokumentację techniczną i zapewnić możliwość wykazania zgodności z przepisami. W zależności od rodzaju systemu konieczne może być przeprowadzenie odpowiedniej procedury oceny zgodności, sporządzenie deklaracji zgodności UE, oznakowanie CE oraz dokonanie wymaganej rejestracji. Zakres poszczególnych obowiązków zależy od kwalifikacji rozwiązania i właściwych przepisów szczególnych.

Dla software house’u istotne jest to, że spełnienie tych wymagań może wymagać znacznie większego nakładu pracy niż samo opracowanie funkcjonalnej aplikacji. Dokumentacja techniczna, procedury testowania, zarządzanie ryzykiem, monitorowanie działania systemu oraz przygotowanie materiałów dla podmiotu stosującego mogą stanowić odrębne i kosztowne elementy projektu. Jeżeli nie zostaną uwzględnione na etapie przygotowywania oferty, wykonawca może znaleźć się w sytuacji, w której wynagrodzenie obejmuje wyłącznie development, podczas gdy rzeczywisty zakres wymaganych prac jest znacznie szerszy.

Jakie obowiązki ma podmiot stosujący system AI?

Podmiot stosujący system AI również nie pozostaje poza zakresem regulacji. W przypadku systemów wysokiego ryzyka AI Act przewiduje obowiązki dotyczące między innymi korzystania z rozwiązania zgodnie z instrukcjami dostawcy, zapewnienia odpowiedniego nadzoru człowieka, monitorowania działania systemu oraz reagowania na stwierdzone zagrożenia. Znaczenie może mieć także jakość danych wejściowych, jeżeli podmiot stosujący posiada nad nimi kontrolę i wykorzystuje je do działania systemu.

W praktyce przedsiębiorca wdrażający system AI w procesie rekrutacyjnym nie powinien zakładać, że cała odpowiedzialność spoczywa na software house’ie. Nawet prawidłowo zaprojektowane rozwiązanie może zostać wykorzystane w sposób niezgodny z przeznaczeniem, na podstawie nieodpowiednich danych albo bez rzeczywistego nadzoru człowieka. Jeżeli pracownicy działu HR traktują ranking wygenerowany przez AI jako ostateczną decyzję, mimo że system został zaprojektowany wyłącznie jako narzędzie wspomagające, może to prowadzić do odrębnych problemów prawnych po stronie pracodawcy.

Istotne znaczenie mają również obowiązki informacyjne. W określonych przypadkach podmiot stosujący system wysokiego ryzyka powinien poinformować osoby, których dotyczą decyzje podejmowane lub wspierane przez system AI, o wykorzystywaniu takiego rozwiązania. W przypadku zastosowań w miejscu pracy rozporządzenie przewiduje także szczególne obowiązki informacyjne wobec pracowników i ich przedstawicieli. Niektóre podmioty stosujące określone systemy wysokiego ryzyka będą ponadto zobowiązane do przeprowadzenia oceny wpływu na prawa podstawowe.

Z perspektywy przedsiębiorcy zamawiającego aplikację AI najważniejsze jest więc ustalenie, czy otrzymuje gotowe rozwiązanie wraz z instrukcjami i dokumentacją pozwalającą na zgodne z prawem korzystanie z systemu. Sama techniczna możliwość uruchomienia aplikacji nie oznacza jeszcze, że przedsiębiorstwo jest przygotowane do realizacji wszystkich obowiązków wynikających z jej wykorzystania.

Czy każdy chatbot i agent AI jest systemem wysokiego ryzyka?

Nie. Jednym z najczęstszych błędów w analizach AI Act jest utożsamianie wykorzystania sztucznej inteligencji z automatycznym zakwalifikowaniem systemu jako rozwiązania wysokiego ryzyka. Rozporządzenie przyjmuje podejście oparte na ryzyku, a zakres obowiązków zależy między innymi od przeznaczenia systemu, sposobu jego wykorzystania oraz wpływu na określone osoby i procesy.

Chatbot odpowiadający na podstawowe pytania dotyczące godzin otwarcia sklepu internetowego co do zasady będzie oceniany inaczej niż system analizujący kandydatów do pracy albo wspierający decyzje dotyczące przyznawania określonych świadczeń. Podobnie agent AI służący do porządkowania dokumentacji wewnętrznej nie musi podlegać tym samym wymaganiom co system wykorzystywany w obszarze wymienionym w załączniku III do rozporządzenia.

Nie oznacza to jednak, że systemy niewysokiego ryzyka są całkowicie wyłączone z AI Act. W zależności od funkcjonalności mogą podlegać określonym obowiązkom dotyczącym przejrzystości, w szczególności informowania użytkownika o interakcji z systemem AI albo oznaczania określonych treści generowanych lub manipulowanych przez sztuczną inteligencję. Niezależnie od tego nadal mogą mieć zastosowanie przepisy RODO, prawa konsumenckiego, prawa autorskiego oraz regulacje dotyczące odpowiedzialności kontraktowej.

Dlatego prawidłowy audyt systemu AI powinien obejmować nie tylko pytanie, czy rozwiązanie jest wysokiego ryzyka, ale również ustalenie wszystkich pozostałych obowiązków wynikających z jego funkcjonalności i rzeczywistego sposobu wykorzystania.

AI Act a systemy wysokiego ryzyka — kiedy przepisy zaczną obowiązywać?

Terminy stosowania AI Act mają szczególne znaczenie dla przedsiębiorców planujących nowe wdrożenia. Rozporządzenie weszło w życie 1 sierpnia 2024 roku, ale poszczególne obowiązki zaczęły być stosowane etapami. Część regulacji dotyczących zakazanych praktyk oraz kompetencji w zakresie AI zaczęła być stosowana 2 lutego 2025 roku, natomiast obowiązki dotyczące modeli AI ogólnego przeznaczenia rozpoczęły stosowanie 2 sierpnia 2025 roku. Znaczna część pozostałych przepisów, w tym określone wymagania dotyczące przejrzystości, zaczęła być stosowana 2 sierpnia 2026 roku.

Istotne zmiany przyniosło rozporządzenie (UE) 2026/1744, określane jako Digital Omnibus on AI, które weszło w życie 27 lipca 2026 roku. W jego następstwie przesunięto terminy stosowania części wymagań dotyczących systemów wysokiego ryzyka. W przypadku systemów należących do kategorii wskazanych w załączniku III zasadniczy termin rozpoczęcia stosowania odpowiednich wymagań został przesunięty na 2 grudnia 2027 roku. Natomiast w odniesieniu do systemów wysokiego ryzyka powiązanych z określonymi produktami objętymi unijnym prawodawstwem harmonizacyjnym, o których mowa w załączniku I, właściwy termin przypada zasadniczo na 2 sierpnia 2028 roku.

Zmiany te nie oznaczają, że przedsiębiorcy mogą całkowicie odłożyć przygotowania do zgodności z AI Act. Po pierwsze, część obowiązków jest już stosowana. Po drugie, przygotowanie dokumentacji, wdrożenie procedur zarządzania ryzykiem i dostosowanie architektury systemu może wymagać wielu miesięcy. Po trzecie, projekty wdrażane obecnie mogą pozostawać w użyciu przez wiele lat, a ich późniejsze dostosowanie do wymagań prawnych może być znacznie droższe niż uwzględnienie tych wymagań na etapie projektowania.

Z perspektywy software house’u rozsądnym rozwiązaniem jest zatem uwzględnianie docelowych wymagań AI Act już podczas opracowywania nowych systemów, nawet jeżeli określone obowiązki zaczną być stosowane dopiero w przyszłości. Szczególnie dotyczy to projektów z obszaru rekrutacji, edukacji, dostępu do istotnych usług oraz innych zastosowań, w których decyzje wspierane przez AI mogą wpływać na prawa i sytuację osób fizycznych.

Czy software house odpowiada za błędne decyzje sztucznej inteligencji?

AI Act nie tworzy prostej zasady, zgodnie z którą za każdy błędny wynik systemu AI odpowiada jego dostawca albo programista. Odpowiedzialność za nieprawidłowe działanie rozwiązania należy oceniać z uwzględnieniem rodzaju naruszenia, roli poszczególnych podmiotów, treści zawartych umów oraz właściwych przepisów prawa cywilnego i innych regulacji.

Przykładowo system AI może wygenerować błędną rekomendację dlatego, że model zewnętrznego dostawcy posiada określone ograniczenia, ponieważ software house nieprawidłowo zaimplementował mechanizm przetwarzania danych albo dlatego, że klient wykorzystał aplikację niezgodnie z jej przeznaczeniem. Każda z tych sytuacji wymaga odrębnej analizy. Nie można automatycznie przyjmować, że za każdy błąd odpowiada podmiot, który napisał interfejs aplikacji, ale nie można również wyłączyć odpowiedzialności wykonawcy wyłącznie dlatego, że korzystał z zewnętrznego modelu językowego.

W relacjach B2B szczególne znaczenie ma precyzyjne określenie przedmiotu umowy, parametrów jakościowych, ograniczeń technologicznych oraz sposobu testowania rozwiązania. Jeżeli software house zobowiązuje się do stworzenia systemu automatycznie oceniającego dokumenty, należy ustalić, jak będzie mierzona poprawność wyników, jakie błędy są dopuszczalne, kiedy klient może odmówić odbioru oraz czy wykonawca gwarantuje określony rezultat, czy jedynie dostarcza narzędzie wspomagające proces decyzyjny.

Należy również rozróżnić odpowiedzialność za naruszenie obowiązków regulacyjnych od odpowiedzialności za szkodę wyrządzoną przez produkt lub usługę. Naruszenie AI Act może mieć znaczenie dla oceny zachowania przedsiębiorcy, ale nie oznacza automatycznie, że każda osoba niezadowolona z wyniku działania AI uzyska odszkodowanie. Konieczne pozostaje ustalenie odpowiedniej podstawy prawnej i przesłanek odpowiedzialności.

Jak zabezpieczyć odpowiedzialność w umowie wdrożeniowej AI?

Umowa dotycząca wdrożenia systemu AI powinna być znacznie bardziej szczegółowa niż standardowa umowa na wykonanie prostej aplikacji internetowej. Oprócz zakresu funkcjonalnego, harmonogramu, wynagrodzenia i zasad odbioru należy uwzględnić specyfikę technologii opartej na modelach probabilistycznych, zależność od dostawców zewnętrznych oraz obowiązki wynikające z regulacji dotyczących sztucznej inteligencji.

Jednym z najważniejszych elementów jest określenie przeznaczenia systemu. Strony powinny jasno wskazać, do jakich celów aplikacja może być wykorzystywana, jakie procesy ma wspierać oraz jakie zastosowania są wyłączone. Ma to szczególne znaczenie w przypadku systemów, które mogą zostać wykorzystane w obszarach wysokiego ryzyka. Jeżeli aplikacja została zaprojektowana do porządkowania dokumentów, a klient zaczyna wykorzystywać ją do automatycznej oceny pracowników, może dojść do istotnej zmiany ryzyka prawnego.

Kolejnym elementem powinien być podział odpowiedzialności za dokumentację i zgodność regulacyjną. Umowa powinna określać, kto dokonuje kwalifikacji systemu, kto odpowiada za przygotowanie wymaganych informacji technicznych, kto przeprowadza testy oraz kto zapewnia realizację obowiązków dotyczących monitorowania i aktualizacji. Warto również ustalić zasady współpracy w przypadku zmiany przepisów albo pojawienia się nowych wytycznych właściwych organów.

Szczególne znaczenie ma odpowiedzialność za komponenty zewnętrzne. Jeżeli system korzysta z modelu dostarczanego przez inny podmiot, należy określić konsekwencje zmiany API, wycofania modelu, zmiany warunków licencyjnych, ograniczenia dostępności usługi albo pogorszenia jakości generowanych wyników. Software house nie powinien bezrefleksyjnie przyjmować nieograniczonej odpowiedzialności za elementy infrastruktury i technologii, nad którymi nie posiada rzeczywistej kontroli.

Umowa powinna także regulować zasady przetwarzania danych, prawa własności intelektualnej, korzystanie z danych klientów do trenowania lub doskonalenia modeli, zasady przechowywania promptów i wyników oraz procedury postępowania w przypadku incydentów. W praktyce warto również określić, kto ponosi koszty dostosowania systemu do nowych wymagań prawnych, zwłaszcza w projektach realizowanych na wiele miesięcy przed rozpoczęciem stosowania określonych przepisów AI Act.

AI Act a RODO — czy zgodność z jednym rozporządzeniem wystarczy?

Nie. AI Act i RODO regulują częściowo odmienne zagadnienia, choć w wielu projektach ich zakresy będą się nakładały. AI Act koncentruje się między innymi na wymaganiach dotyczących systemów sztucznej inteligencji, ich przeznaczenia, ryzyka, przejrzystości i odpowiedzialności podmiotów uczestniczących w łańcuchu wartości. RODO dotyczy natomiast przetwarzania danych osobowych, w tym podstaw prawnych, zasad minimalizacji, obowiązków informacyjnych, bezpieczeństwa danych oraz praw osób, których dane dotyczą.

Przykładowo aplikacja rekrutacyjna wykorzystująca AI może podlegać określonym wymaganiom AI Act, ale jednocześnie przetwarzać dane osobowe kandydatów. Przedsiębiorca musi wówczas ustalić podstawę prawną przetwarzania danych, zakres informacji przekazywanych kandydatom, okres przechowywania dokumentów, zasady korzystania z usług podmiotów przetwarzających oraz ewentualną konieczność przeprowadzenia oceny skutków dla ochrony danych. Dodatkowo znaczenie może mieć art. 22 RODO dotyczący określonych decyzji opartych wyłącznie na zautomatyzowanym przetwarzaniu.

Nie można więc przyjmować, że uzyskanie zgodności z AI Act automatycznie oznacza zgodność z RODO. Podobnie prawidłowo przygotowana polityka prywatności i umowa powierzenia danych nie zastępują dokumentacji oraz procedur wymaganych przez AI Act. W praktyce audyt systemu AI powinien obejmować obie regulacje, a także inne przepisy właściwe dla konkretnego zastosowania.

AI Act a prawa autorskie do systemu i wyników generowanych przez AI

Kolejnym istotnym zagadnieniem jest własność intelektualna. W projektach AI należy odróżnić prawa do kodu aplikacji, prawa do wykorzystywanych modeli, licencje na komponenty zewnętrzne, prawa do baz danych oraz zasady korzystania z treści generowanych przez system. Każda z tych kategorii może podlegać odrębnym regulacjom i ograniczeniom.

Software house może posiadać autorskie prawa majątkowe do stworzonego przez siebie kodu, ale jednocześnie korzystać z modelu AI udostępnianego na podstawie licencji zewnętrznego dostawcy. Nie oznacza to, że może przenieść na klienta prawa do samego modelu, jeżeli takich praw nie posiada. W umowie należy więc dokładnie rozdzielić elementy stworzone przez wykonawcę od komponentów zewnętrznych oraz określić zakres uprawnień klienta do korzystania z całego rozwiązania.

Osobnym problemem są wyniki generowane przez AI. Nie każda treść wygenerowana przez system będzie automatycznie stanowiła utwór chroniony prawem autorskim. Ocena zależy między innymi od rzeczywistego wkładu twórczego człowieka i charakteru procesu powstawania rezultatu. Strony mogą umownie określić zasady korzystania z wygenerowanych treści, ale nie powinny zakładać, że każda taka treść automatycznie podlega ochronie prawnoautorskiej i może być przedmiotem skutecznego przeniesienia praw autorskich.

W praktyce umowa wdrożeniowa AI powinna zatem obejmować nie tylko standardowe postanowienia dotyczące przeniesienia praw do oprogramowania, lecz również zasady korzystania z modeli, danych wejściowych, wyników działania systemu oraz materiałów wykorzystywanych do jego konfiguracji i doskonalenia.

Jak przeprowadzić audyt zgodności systemu AI z AI Act?

Audyt prawny systemu AI powinien rozpoczynać się od ustalenia jego rzeczywistego przeznaczenia, sposobu działania oraz podmiotów uczestniczących w procesie tworzenia i wykorzystywania rozwiązania. Konieczne jest określenie, kto opracował system, kto dostarcza model, kto udostępnia aplikację pod własną marką, kto decyduje o jej funkcjonalnościach oraz kto wykorzystuje ją w praktyce. Dopiero na tej podstawie można prawidłowo przypisać role przewidziane w AI Act.

Następnie należy przeprowadzić kwalifikację ryzyka. W szczególności trzeba ustalić, czy system należy do kategorii objętych zakazanymi praktykami, czy może zostać zakwalifikowany jako system wysokiego ryzyka, czy podlega obowiązkom dotyczącym przejrzystości oraz czy wykorzystuje model AI ogólnego przeznaczenia. Istotne jest również sprawdzenie, czy zastosowanie systemu nie zostało zmienione po jego pierwotnym wdrożeniu i czy wprowadzane modyfikacje nie wpływają na zakres obowiązków.

Kolejnym etapem powinna być analiza dokumentacji prawnej i technicznej. W zależności od charakteru projektu może ona obejmować umowę wdrożeniową, umowy z dostawcami modeli, regulaminy usług, dokumentację techniczną, politykę prywatności, umowy powierzenia danych, instrukcje użytkowania, procedury testowania, dokumentację zarządzania ryzykiem oraz zasady reagowania na incydenty. Należy również sprawdzić, czy dokumenty odpowiadają rzeczywistemu sposobowi działania aplikacji i czy przedsiębiorca posiada możliwość wykazania zgodności z wymaganiami prawnymi.

Ostatnim etapem powinno być przygotowanie planu działań naprawczych. Samo stwierdzenie, że przedsiębiorca nie posiada odpowiedniej dokumentacji albo nie przeprowadził wymaganej kwalifikacji systemu, nie jest wystarczające. Raport audytowy powinien wskazywać, jakie działania należy wykonać, które obowiązki mają już zastosowanie, jakie wymagania zaczną obowiązywać w przyszłości oraz kto powinien odpowiadać za ich realizację.

Dlaczego audyt AI warto przeprowadzić przed podpisaniem umowy?

W przypadku projektów informatycznych analiza prawna jest często wykonywana dopiero wtedy, gdy pojawia się spór pomiędzy wykonawcą a klientem albo gdy gotowy produkt ma zostać wprowadzony na rynek. W projektach AI takie podejście może być szczególnie kosztowne. Jeżeli dopiero po zakończeniu developmentu okaże się, że system należy do kategorii wysokiego ryzyka, konieczne może być przygotowanie dodatkowej dokumentacji, przeprowadzenie testów, zmiana architektury rozwiązania albo wdrożenie nowych mechanizmów nadzoru człowieka.

Wcześniejszy audyt pozwala również prawidłowo określić zakres odpowiedzialności stron. Software house może uwzględnić w ofercie prace związane z dokumentacją i zgodnością regulacyjną, a klient uzyska jasną informację o obowiązkach, które będzie musiał realizować podczas korzystania z systemu. Dzięki temu można ograniczyć ryzyko późniejszych sporów dotyczących tego, czy przygotowanie dokumentacji AI Act mieściło się w pierwotnym wynagrodzeniu, czy stanowi dodatkową usługę.

Z punktu widzenia przedsiębiorców szczególnie istotne jest również to, że AI Act nie powinien być analizowany w oderwaniu od całego modelu biznesowego. Odpowiedzialność za system może zależeć od tego, czy aplikacja jest oferowana jako SaaS, czy została wykonana na indywidualne zamówienie, czy jest udostępniana pod marką klienta oraz czy po wdrożeniu planowane są istotne modyfikacje. Właśnie dlatego analiza prawna powinna obejmować nie tylko dokumentację, ale również sposób komercjalizacji rozwiązania.

Podsumowanie — kto odpowiada za system AI stworzony przez software house?

AI Act istotnie zmienia sposób oceny odpowiedzialności przedsiębiorców uczestniczących w tworzeniu i wdrażaniu systemów sztucznej inteligencji. Kluczowe znaczenie ma rozróżnienie pomiędzy dostawcą systemu AI a podmiotem stosującym, ponieważ poszczególne role wiążą się z odmiennymi obowiązkami regulacyjnymi. Nie można jednak przyjmować, że software house automatycznie staje się dostawcą każdego systemu, który stworzył, ani że klient zawsze pozostaje wyłącznie podmiotem stosującym.

W praktyce o kwalifikacji decydują rzeczywiste okoliczności, w szczególności sposób udostępnienia systemu, jego przeznaczenie, oznaczenie marką określonego przedsiębiorcy oraz zakres wprowadzanych modyfikacji. Szczególne znaczenie ma art. 25 AI Act, który przewiduje możliwość uznania określonych podmiotów za dostawców systemów wysokiego ryzyka w przypadku rebrandingu, istotnej modyfikacji albo zmiany przeznaczenia rozwiązania.

Dla polskich software house’ów najważniejszym wnioskiem jest konieczność uwzględniania wymagań AI Act już na etapie przygotowywania oferty i negocjowania umowy wdrożeniowej. Odpowiednie postanowienia kontraktowe nie zastąpią obowiązków wynikających bezpośrednio z przepisów, ale mogą skutecznie określić podział zadań, zasady współpracy, odpowiedzialność finansową i sposób realizacji wymagań regulacyjnych.

Równie istotna jest prawidłowa kwalifikacja ryzyka. Nie każdy chatbot, agent AI czy aplikacja wykorzystująca model językowy stanowi system wysokiego ryzyka, ale również rozwiązania niewysokiego ryzyka mogą podlegać określonym obowiązkom wynikającym z AI Act oraz innych przepisów. Przeprowadzenie audytu prawnego pozwala ustalić rzeczywisty zakres wymagań i uniknąć zarówno niepotrzebnych kosztów, jak i ryzyka pominięcia istotnych obowiązków.

Wraz z rozwojem rynku sztucznej inteligencji analiza roli dostawcy i podmiotu stosującego będzie stawała się jednym z podstawowych elementów obsługi prawnej projektów IT. Przedsiębiorcy, którzy odpowiednio wcześnie uporządkują umowy, dokumentację i procesy związane z AI, będą lepiej przygotowani do dalszego rozwoju swoich produktów oraz do zmian regulacyjnych przewidzianych w kolejnych etapach stosowania AI Act.