Umowa wdrożenia AI — 12 klauzul, które powinny znaleźć się w kontrakcie z software house’em

Wdrażanie sztucznej inteligencji w przedsiębiorstwach staje się jednym z najważniejszych kierunków rozwoju rynku usług informatycznych. Firmy zamawiają aplikacje wykorzystujące modele językowe, systemy automatycznej analizy dokumentów, chatboty obsługujące klientów, agentów AI wykonujących zadania biznesowe oraz rozwiązania wspierające podejmowanie decyzji. Coraz częściej projekty te realizowane są przez zewnętrzne software house’y, które odpowiadają za stworzenie aplikacji, integrację modeli sztucznej inteligencji oraz połączenie nowego rozwiązania z istniejącą infrastrukturą informatyczną zamawiającego. Problem polega jednak na tym, że tradycyjna umowa wdrożeniowa IT nie zawsze odpowiada specyfice takich projektów. Sztuczna inteligencja wprowadza bowiem nowe rodzaje ryzyka, których nie można skutecznie uregulować wyłącznie standardowymi postanowieniami dotyczącymi terminu wykonania oprogramowania, wynagrodzenia, odbioru prac i przeniesienia praw autorskich.

Umowa wdrożenia AI powinna regulować nie tylko stworzenie aplikacji, lecz również sposób działania systemu sztucznej inteligencji, odpowiedzialność za generowane wyniki, korzystanie z modeli zewnętrznych, bezpieczeństwo danych, prawa własności intelektualnej oraz podział obowiązków wynikających z AI Act. Szczególne znaczenie ma ustalenie, czy software house będzie dostawcą systemu AI w rozumieniu rozporządzenia, czy jedynie wykonawcą technicznym realizującym projekt na rzecz klienta. Nie mniej ważne pozostaje określenie odpowiedzialności za błędne odpowiedzi modelu, zmianę warunków korzystania z API, niedostępność usług zewnętrznych oraz możliwość wykorzystania danych przedsiębiorstwa do trenowania modeli sztucznej inteligencji.

W praktyce dobrze przygotowana umowa wdrożeniowa AI powinna zabezpieczać interesy obu stron. Zamawiający musi otrzymać rozwiązanie odpowiadające ustalonym wymaganiom, możliwe do legalnego wykorzystywania w działalności gospodarczej i wyposażone w odpowiednią dokumentację. Software house powinien natomiast unikać przyjmowania nieograniczonej odpowiedzialności za technologię, której sam nie opracował i nad którą nie posiada pełnej kontroli. Odpowiednie postanowienia kontraktowe pozwalają ograniczyć ryzyko sporów, nieprzewidzianych kosztów i problemów z późniejszym utrzymaniem systemu.

Dlaczego zwykła umowa wdrożeniowa IT może nie wystarczyć przy projektach AI?

Tradycyjne oprogramowanie jest zazwyczaj projektowane w taki sposób, aby określone dane wejściowe prowadziły do przewidywalnego rezultatu zgodnego z zaprogramowaną logiką. Jeżeli aplikacja ma obliczać podatek na podstawie wskazanych parametrów, możliwe jest przygotowanie zestawu testów pozwalających stosunkowo jednoznacznie ustalić, czy działa prawidłowo. W przypadku systemów wykorzystujących generatywną sztuczną inteligencję sytuacja jest bardziej skomplikowana. Ten sam model może generować różne odpowiedzi na podobne pytania, nieprawidłowo interpretować kontekst, pomijać istotne informacje albo tworzyć treści, które brzmią wiarygodnie, ale nie odpowiadają rzeczywistości.

Dodatkowym problemem jest zależność od zewnętrznych dostawców modeli. Software house może opracować całą aplikację, a mimo to jej podstawowa funkcjonalność będzie zależała od dostępności zewnętrznego API, parametrów konkretnego modelu, polityki bezpieczeństwa jego dostawcy oraz zmian wprowadzanych bez udziału wykonawcy. Aktualizacja modelu może poprawić jakość odpowiedzi, ale może również zmienić ich strukturę, zwiększyć opóźnienia albo spowodować, że wcześniej działające mechanizmy przestaną spełniać oczekiwania klienta.

Równolegle pojawiają się obowiązki regulacyjne. AI Act przewiduje różne kategorie podmiotów uczestniczących w tworzeniu i wykorzystywaniu systemów AI, a zakres ich obowiązków zależy między innymi od roli w łańcuchu wartości, przeznaczenia systemu oraz jego kwalifikacji pod względem ryzyka. Do tego dochodzą przepisy RODO, prawa autorskiego, ochrony tajemnicy przedsiębiorstwa oraz odpowiedzialności kontraktowej. Dlatego umowa wdrożenia AI nie powinna być jedynie zmodyfikowanym wzorem umowy na stworzenie strony internetowej lub standardowej aplikacji SaaS.

Klauzula pierwsza — precyzyjne określenie przedmiotu umowy i przeznaczenia systemu AI

Pierwszym elementem prawidłowo przygotowanej umowy powinno być dokładne określenie, jakie rozwiązanie ma zostać opracowane i do jakich celów będzie wykorzystywane. Ogólne sformułowanie, zgodnie z którym wykonawca zobowiązuje się do stworzenia aplikacji wykorzystującej sztuczną inteligencję do automatyzacji procesów biznesowych, jest zdecydowanie niewystarczające. Nie pozwala bowiem ustalić, jakie funkcje mają zostać wykonane, jakie rezultaty powinien generować system ani w jaki sposób strony będą oceniały prawidłowość realizacji projektu.

W przypadku aplikacji wykorzystującej model językowy należy określić, czy system ma wyłącznie generować propozycje odpowiedzi, czy również analizować dokumenty, podejmować działania w innych systemach informatycznych albo samodzielnie wykonywać określone operacje. Jeżeli projekt obejmuje agenta AI, szczególnego znaczenia nabiera wskazanie, czy agent może wysyłać wiadomości, tworzyć dokumenty, modyfikować rekordy w bazie danych, składać zamówienia lub wykonywać inne czynności wywołujące skutki gospodarcze. Każda z tych funkcjonalności może generować odmienny poziom ryzyka i wymagać innych mechanizmów kontroli.

W umowie warto również określić przeznaczenie systemu w rozumieniu AI Act. Ma to znaczenie nie tylko dla oceny zgodności regulacyjnej, lecz również dla późniejszej odpowiedzialności stron. Jeżeli aplikacja została opracowana jako narzędzie pomocnicze do analizy dokumentów, zamawiający nie powinien automatycznie zakładać, że może wykorzystywać ją do samodzielnego podejmowania decyzji dotyczących zatrudnienia, oceny zdolności kredytowej czy innych procesów mogących należeć do kategorii wysokiego ryzyka. Zmiana przeznaczenia systemu może bowiem wpływać na jego kwalifikację prawną, a w określonych sytuacjach prowadzić do powstania dodatkowych obowiązków.

Prawidłowo przygotowana klauzula powinna zatem odróżniać funkcjonalności objęte zamówieniem od zastosowań wyłączonych, wskazywać środowisko pracy systemu oraz określać podstawowe ograniczenia technologiczne. Dzięki temu obie strony wiedzą, co stanowi przedmiot świadczenia i za jakie rezultaty wykonawca rzeczywiście odpowiada.

Klauzula druga — ustalenie ról Provider i Deployer oraz odpowiedzialności za AI Act

Jednym z najważniejszych zagadnień w umowie wdrożenia sztucznej inteligencji jest ustalenie ról stron w rozumieniu AI Act. Rozporządzenie rozróżnia między innymi dostawcę systemu AI, czyli provider, oraz podmiot stosujący system, czyli deployer. Kwalifikacja ta nie zależy wyłącznie od tego, kto finansuje projekt albo kto fizycznie tworzy kod aplikacji. Znaczenie mają rzeczywiste okoliczności, w szczególności sposób opracowania i udostępnienia rozwiązania, jego przeznaczenie oraz to, pod czyją nazwą lub znakiem towarowym jest ono wprowadzane do obrotu albo oddawane do użytku.

Software house tworzący aplikację na indywidualne zamówienie klienta nie musi automatycznie stawać się jej dostawcą w rozumieniu AI Act. Jednocześnie przedsiębiorca opracowujący własny system AI i oferujący go wielu klientom w modelu abonamentowym może pełnić właśnie taką rolę, nawet jeżeli wykorzystuje model językowy opracowany przez inny podmiot. Szczególne znaczenie ma art. 25 AI Act, który przewiduje sytuacje, w których podmiot może przejąć obowiązki dostawcy systemu wysokiego ryzyka, między innymi wskutek określonego rebrandingu, istotnej modyfikacji albo zmiany przeznaczenia systemu.

W umowie należy zatem ustalić, kto odpowiada za kwalifikację systemu, przygotowanie dokumentacji technicznej, przeprowadzenie wymaganych testów, zapewnienie zgodności z właściwymi wymaganiami oraz współpracę z organami nadzorczymi. Jeżeli projekt obejmuje system wysokiego ryzyka, szczególnie ważne może być zapewnienie dostępu do informacji i wsparcia technicznego od dostawców modeli, narzędzi oraz innych komponentów. Art. 25 ust. 4 AI Act przewiduje w określonych przypadkach obowiązek ustalenia w pisemnej umowie zakresu informacji, możliwości technicznych i pomocy potrzebnych dostawcy systemu wysokiego ryzyka do spełnienia jego obowiązków, z uwzględnieniem przewidzianych w przepisie wyjątków.

Należy jednak pamiętać, że strony nie mogą dowolnie zmieniać swojej kwalifikacji prawnej poprzez odpowiedni zapis kontraktowy. Jeżeli określony przedsiębiorca jest dostawcą systemu AI na podstawie przepisów rozporządzenia, samo postanowienie przenoszące całą odpowiedzialność regulacyjną na drugą stronę nie musi zwolnić go z obowiązków publicznoprawnych. Umowa może natomiast określać podział zadań, obowiązki współpracy oraz odpowiedzialność kontraktową za niewykonanie uzgodnionych czynności.

Klauzula trzecia — odpowiedzialność za modele AI i usługi dostawców zewnętrznych

Znaczna część współczesnych aplikacji AI nie wykorzystuje modeli opracowanych przez wykonawcę. Software house buduje aplikację, integruje ją z zewnętrznym API i opracowuje logikę biznesową, ale samo generowanie odpowiedzi odbywa się z wykorzystaniem infrastruktury innego dostawcy. Powoduje to powstanie zależności technologicznej, której nie można pomijać podczas przygotowywania umowy.

Kontrakt powinien określać, jakie modele i usługi zewnętrzne będą wykorzystywane, kto zawiera umowy z ich dostawcami oraz kto ponosi koszty związane z korzystaniem z API. Należy również ustalić, czy wykonawca może samodzielnie zmienić model na inny, czy potrzebuje zgody zamawiającego oraz jakie parametry muszą zostać zachowane po takiej zmianie. W przypadku systemów wykorzystywanych w procesach istotnych dla działalności przedsiębiorstwa zmiana modelu może bowiem wpływać nie tylko na jakość wyników, ale również na bezpieczeństwo danych, zgodność regulacyjną i przewidywalność działania aplikacji.

Szczególnie niebezpieczne dla software house’u jest przyjęcie nieograniczonej odpowiedzialności za dostępność i zachowanie zewnętrznego modelu. Wykonawca nie zawsze ma możliwość wpływania na decyzje dostawcy dotyczące wycofania określonej wersji, ograniczenia liczby zapytań, zmiany cen albo modyfikacji zasad moderowania treści. Nie oznacza to jednak, że może całkowicie wyłączyć odpowiedzialność za wszystkie problemy związane z integracją. Jeżeli nieprawidłowo skonfigurował usługę, wybrał rozwiązanie niespełniające uzgodnionych wymagań albo nie zapewnił przewidzianych w umowie mechanizmów awaryjnych, może odpowiadać za własne zaniedbania.

Dobrze przygotowana umowa powinna zatem rozróżniać ryzyka wynikające z działania infrastruktury zewnętrznej od odpowiedzialności za prawidłową implementację systemu. Warto również przewidzieć procedurę postępowania w przypadku wycofania modelu, utraty dostępu do API albo istotnej zmiany warunków korzystania z usługi.

Klauzula czwarta — jakość wyników AI, halucynacje i kryteria odbioru

Jednym z najczęstszych źródeł sporów przy wdrażaniu sztucznej inteligencji jest brak precyzyjnych zasad oceny jakości działania systemu. Zamawiający oczekuje, że aplikacja będzie generowała prawidłowe odpowiedzi, natomiast wykonawca wskazuje, że modele generatywne nie gwarantują całkowitej poprawności wyników. Jeżeli umowa nie określa odpowiednich kryteriów, strony mogą mieć zupełnie odmienne wyobrażenie o tym, kiedy projekt został wykonany prawidłowo.

W przypadku klasycznego oprogramowania testy odbiorowe często polegają na sprawdzeniu, czy konkretna funkcja zwraca oczekiwany rezultat. W systemach AI nie zawsze jest to możliwe w identyczny sposób. Dlatego warto uzgodnić zestawy testowe, sposób oceny wyników, dopuszczalny poziom błędów oraz parametry jakościowe właściwe dla konkretnego zastosowania. W systemie klasyfikującym dokumenty można przykładowo badać trafność przyporządkowania dokumentów do kategorii, natomiast w aplikacji wykorzystującej RAG istotne może być sprawdzanie zgodności odpowiedzi z dokumentami źródłowymi.

Nie należy przy tym automatycznie przyjmować, że wykonawca może zagwarantować stuprocentową poprawność każdej odpowiedzi modelu. Z drugiej strony ogólne zastrzeżenie, że sztuczna inteligencja może popełniać błędy, nie powinno zwalniać software house’u z odpowiedzialności za niespełnienie uzgodnionych parametrów systemu. Jeżeli wykonawca zobowiązał się do osiągnięcia określonego poziomu skuteczności na ustalonym zbiorze testowym, wynik poniżej tego poziomu może stanowić podstawę odmowy odbioru albo żądania usunięcia niezgodności.

Szczególnie ważne jest odróżnienie błędów technicznych aplikacji od ograniczeń samego modelu AI. Nieprawidłowe działanie mechanizmu logowania, utrata danych albo błędne przekazywanie dokumentów do modelu powinny być oceniane inaczej niż wygenerowanie nieprecyzyjnej odpowiedzi w granicach uzgodnionej tolerancji. Odpowiednia klauzula odbiorowa pozwala uniknąć sytuacji, w której każda niedoskonała odpowiedź systemu staje się podstawą niekończącego się procesu poprawek.

Klauzula piąta — bezpieczeństwo danych, RODO i tajemnica przedsiębiorstwa

Wdrożenie systemu AI bardzo często wiąże się z przetwarzaniem informacji należących do zamawiającego. Mogą to być dokumenty finansowe, dane klientów, korespondencja biznesowa, informacje dotyczące pracowników, dokumentacja medyczna albo dane stanowiące tajemnicę przedsiębiorstwa. W przypadku korzystania z modeli zewnętrznych część tych informacji może być przekazywana poza infrastrukturę zamawiającego, co wymaga szczegółowej analizy prawnej i technicznej.

Umowa powinna określać kategorie danych przetwarzanych przez system, zasady ich przekazywania, lokalizację przetwarzania oraz obowiązki stron dotyczące bezpieczeństwa informacji. Jeżeli software house przetwarza dane osobowe w imieniu zamawiającego, konieczne może być zawarcie umowy powierzenia przetwarzania danych zgodnej z art. 28 RODO. Nie należy jednak zakładać, że każdy wykonawca automatycznie jest podmiotem przetwarzającym. Prawidłowa kwalifikacja zależy od tego, kto ustala cele i sposoby przetwarzania oraz jakie czynności faktycznie wykonują poszczególne podmioty.

Szczególnego znaczenia nabiera ustalenie, czy dane przekazywane do modelu mogą być wykorzystywane do jego trenowania lub doskonalenia. Nie wszystkie usługi AI stosują identyczne zasady, a warunki korzystania z rozwiązań konsumenckich mogą różnić się od warunków usług biznesowych. Dlatego sama deklaracja, że system wykorzystuje bezpieczne API, nie wystarcza do prawidłowego zabezpieczenia interesów zamawiającego. Należy sprawdzić konkretne warunki przetwarzania, retencji, dostępu dostawcy do danych oraz ewentualnych transferów poza Europejski Obszar Gospodarczy.

Odrębną kwestią jest ochrona informacji poufnych. Nawet jeżeli określone dane nie stanowią danych osobowych, mogą mieć znaczną wartość gospodarczą i podlegać ochronie jako tajemnica przedsiębiorstwa. Umowa powinna zatem przewidywać odpowiednie obowiązki poufności, ograniczenia dotyczące wykorzystania danych oraz zasady ich usuwania po zakończeniu współpracy.

Klauzula szósta — prawa autorskie do oprogramowania, modeli i wyników AI

Kwestia własności intelektualnej w projektach AI jest znacznie bardziej złożona niż w przypadku standardowego oprogramowania. Należy bowiem rozróżnić kod aplikacji stworzony przez software house, komponenty open source, modele sztucznej inteligencji dostarczane przez podmioty zewnętrzne, dane wykorzystywane do konfiguracji systemu oraz treści generowane przez model. Każda z tych kategorii może podlegać odrębnym zasadom prawnym i licencyjnym.

W przypadku kodu tworzonego na zamówienie strony powinny ustalić, czy zamawiający otrzyma autorskie prawa majątkowe, czy jedynie licencję na korzystanie z oprogramowania. Jeżeli przewidziano przeniesienie praw autorskich, należy uwzględnić wymagania polskiego prawa autorskiego, w szczególności dotyczące formy pisemnej oraz wyraźnego określenia pól eksploatacji. Istotne znaczenie mają także zasady przekazania kodu źródłowego, dokumentacji technicznej i uprawnień niezbędnych do dalszego rozwijania aplikacji.

Inaczej wygląda sytuacja w odniesieniu do modelu zewnętrznego. Software house korzystający z modelu na podstawie licencji albo API nie może skutecznie przenieść na klienta praw, których sam nie posiada. Dlatego umowa powinna jednoznacznie określać, które elementy stanowią własność wykonawcy, które należą do dostawców zewnętrznych, a które powstają specjalnie na potrzeby zamawiającego.

Osobnego uregulowania wymagają wyniki generowane przez AI. Nie każda treść wytworzona automatycznie przez system stanowi utwór chroniony prawem autorskim. W polskim systemie prawnym istotne znaczenie ma twórczy wkład człowieka, a sama automatyczna generacja treści nie przesądza o powstaniu autorskich praw majątkowych. Strony mogą jednak określić zasady korzystania z wyników, odpowiedzialność za ich dalsze rozpowszechnianie oraz sposób postępowania w przypadku zgłoszenia roszczeń przez osoby trzecie.

Klauzula siódma — nadzór człowieka i granice autonomii agenta AI

Rozwój agentów AI powoduje, że systemy sztucznej inteligencji coraz częściej nie ograniczają się do generowania odpowiedzi, lecz samodzielnie wykonują określone zadania. Agent może analizować wiadomości, przygotowywać dokumenty, wprowadzać zmiany w systemach informatycznych, wysyłać korespondencję albo inicjować działania w zewnętrznych usługach. Z perspektywy prawa oznacza to konieczność określenia granic jego autonomii oraz odpowiedzialności za skutki wykonywanych operacji.

Umowa wdrożeniowa powinna wskazywać, jakie działania agent może wykonywać samodzielnie, a które wymagają zatwierdzenia przez człowieka. Szczególnie istotne jest to w przypadku czynności mogących wywoływać skutki prawne lub finansowe, takich jak wysyłanie ofert, składanie zamówień, akceptowanie dokumentów, dokonywanie płatności czy modyfikowanie danych klientów. Brak odpowiednich ograniczeń może prowadzić do sytuacji, w której agent wykona czynność niezgodną z rzeczywistą wolą przedsiębiorcy.

W praktyce warto określić mechanizmy autoryzacji, zakres uprawnień, limity wykonywanych operacji oraz zasady rejestrowania działań systemu. Należy również przewidzieć możliwość natychmiastowego zatrzymania agenta i cofnięcia jego uprawnień. Takie rozwiązania mają znaczenie nie tylko techniczne, lecz również dowodowe, ponieważ w razie sporu pozwalają ustalić, jakie działanie zostało wykonane, na podstawie jakiego polecenia i przy jakim poziomie nadzoru człowieka.

W przypadku systemów wysokiego ryzyka obowiązki dotyczące nadzoru człowieka wynikają również bezpośrednio z AI Act. Jednak nawet gdy dane rozwiązanie nie należy do tej kategorii, odpowiednie mechanizmy kontroli mogą być konieczne z punktu widzenia należytego wykonania umowy, bezpieczeństwa przedsiębiorstwa i ograniczenia odpowiedzialności za działania systemu.

Klauzula ósma — aktualizacje modeli, zmiany technologiczne i rozwój systemu

System AI nie jest produktem całkowicie statycznym. W trakcie jego eksploatacji mogą pojawiać się nowe wersje modeli, aktualizacje bibliotek, zmiany interfejsów API oraz nowe wymagania dotyczące bezpieczeństwa. Część aktualizacji może być konieczna dla utrzymania funkcjonalności aplikacji, podczas gdy inne będą związane z rozwojem produktu albo dostosowaniem go do nowych potrzeb biznesowych.

Umowa powinna określać, kto odpowiada za monitorowanie zmian technologicznych, jakie aktualizacje mieszczą się w wynagrodzeniu za utrzymanie systemu oraz kiedy konieczne jest odrębne zlecenie prac. Szczególnie ważne jest rozróżnienie aktualizacji usuwających błędy od zmian rozwojowych. Jeżeli dostawca zewnętrznego modelu wycofa określoną wersję API, strony powinny wiedzieć, czy dostosowanie aplikacji stanowi obowiązek wykonawcy w ramach istniejącej umowy, czy wymaga dodatkowego wynagrodzenia.

Nie każda zmiana modelu jest neutralna z perspektywy zgodności z prawem. W przypadku systemów wysokiego ryzyka określone modyfikacje mogą wpływać na wcześniejszą ocenę zgodności albo wymagać ponownej analizy regulacyjnej. Z tego powodu warto wprowadzić procedurę zarządzania zmianą, która będzie uwzględniała nie tylko aspekt techniczny, lecz również wpływ aktualizacji na przeznaczenie, bezpieczeństwo i zgodność systemu z wymaganiami prawnymi.

Dobrze przygotowany kontrakt powinien również określać zasady informowania zamawiającego o istotnych zmianach, sposób przeprowadzania testów regresyjnych oraz możliwość odmowy wdrożenia aktualizacji, która powodowałaby niedopuszczalne ryzyko dla działalności przedsiębiorstwa.

Klauzula dziewiąta — odpowiedzialność za błędy systemu i ograniczenie odpowiedzialności wykonawcy

Jednym z najważniejszych elementów negocjacji umowy wdrożeniowej AI jest określenie odpowiedzialności za nieprawidłowe działanie systemu. Błędy mogą wynikać z wad kodu, niewłaściwej integracji, nieprawidłowej konfiguracji modelu, błędnych danych wejściowych, ograniczeń technologii albo niewłaściwego wykorzystania aplikacji przez zamawiającego. Każda z tych sytuacji wymaga odrębnej oceny, ponieważ nie wszystkie okoliczności pozostają pod kontrolą wykonawcy.

Z perspektywy software house’u szczególnie niebezpieczne jest zobowiązanie do zapewnienia całkowitej poprawności wszystkich wyników generowanych przez system. W przypadku generatywnej sztucznej inteligencji takie zobowiązanie może być niemożliwe do wykonania w praktyce. Jednocześnie wykonawca nie powinien zakładać, że ogólne zastrzeżenie o możliwości występowania halucynacji automatycznie wyłączy odpowiedzialność za nieprawidłowo zaprojektowaną aplikację albo niespełnienie uzgodnionych parametrów.

W umowie warto określić zasady odpowiedzialności za poszczególne kategorie naruszeń, procedurę zgłaszania błędów, obowiązki współpracy przy ograniczaniu szkody oraz ewentualny limit odpowiedzialności odszkodowawczej. W relacjach B2B możliwe jest odpowiednie kształtowanie odpowiedzialności kontraktowej, jednak swoboda stron nie jest nieograniczona. Należy uwzględnić między innymi art. 473 § 2 Kodeksu cywilnego, zgodnie z którym nieważne jest zastrzeżenie wyłączające odpowiedzialność dłużnika za szkodę wyrządzoną wierzycielowi umyślnie.

Warto również pamiętać, że ograniczenia odpowiedzialności przewidziane w umowie nie muszą wpływać na obowiązki przedsiębiorcy wynikające z przepisów bezwzględnie obowiązujących. Nie można więc zakładać, że odpowiedni limit odszkodowawczy automatycznie wyłączy możliwość nałożenia sankcji administracyjnej albo odpowiedzialność wobec osób trzecich. Umowa powinna być konstruowana z uwzględnieniem zarówno relacji pomiędzy wykonawcą a zamawiającym, jak i ryzyk wynikających z przepisów regulacyjnych.

Klauzula dziesiąta — utrzymanie systemu AI, SLA i reagowanie na incydenty

Oddanie aplikacji AI do użytku nie oznacza zakończenia wszystkich obowiązków związanych z jej funkcjonowaniem. System może wymagać stałego monitorowania, aktualizacji, kontroli jakości wyników, zarządzania kosztami API oraz reagowania na problemy bezpieczeństwa. W przypadku rozwiązań wykorzystywanych w istotnych procesach biznesowych brak odpowiednich zasad utrzymania może prowadzić do poważnych zakłóceń działalności zamawiającego.

Umowa powinna określać poziom dostępności usługi, zasady zgłaszania incydentów, czas reakcji oraz sposób usuwania awarii. Warto przy tym odróżnić dostępność infrastruktury wykonawcy od dostępności zewnętrznych modeli i usług. Jeżeli aplikacja działa w chmurze zamawiającego, a model jest udostępniany przez inny podmiot, wykonawca nie zawsze ma możliwość zagwarantowania nieprzerwanej dostępności wszystkich elementów systemu.

Szczególnie istotne jest również określenie zasad postępowania w przypadku incydentu dotyczącego danych albo nieprawidłowego działania systemu. Może to obejmować obowiązek niezwłocznego przekazania informacji, zabezpieczenia logów, współpracy przy analizie przyczyn oraz wdrożenia działań ograniczających skutki zdarzenia. Jeżeli incydent dotyczy danych osobowych, konieczne może być równoległe wykonanie obowiązków wynikających z RODO, w tym zapewnienie administratorowi informacji potrzebnych do oceny obowiązków notyfikacyjnych.

W przypadku systemów wysokiego ryzyka należy dodatkowo uwzględnić odpowiednie obowiązki monitorowania i raportowania wynikające z AI Act, zgodnie z właściwymi terminami rozpoczęcia ich stosowania. Dobrze przygotowana umowa powinna więc rozróżniać standardowe obowiązki utrzymaniowe od szczególnych obowiązków regulacyjnych, których wykonanie może wymagać dodatkowych działań i kosztów.

Klauzula jedenasta — zakończenie współpracy, migracja danych i zmiana dostawcy AI

Jednym z najczęściej pomijanych elementów umów wdrożeniowych jest określenie zasad zakończenia współpracy. W przypadku systemów AI problem ten może być szczególnie istotny, ponieważ przedsiębiorca może uzależnić kluczowe procesy biznesowe od rozwiązania stworzonego przez jednego wykonawcę oraz modelu dostarczanego przez określonego dostawcę technologii. Jeżeli po kilku latach klient zdecyduje się zmienić software house albo dostawcę modelu, może okazać się, że migracja jest kosztowna, technicznie skomplikowana lub niemożliwa bez udziału dotychczasowego wykonawcy.

Umowa powinna określać, jakie dane i elementy systemu zostaną przekazane zamawiającemu po zakończeniu współpracy. Mogą to być bazy danych, dokumentacja techniczna, konfiguracje, prompty systemowe, schematy integracji, wyniki testów, a w określonych przypadkach również kod źródłowy i elementy umożliwiające dalsze rozwijanie aplikacji. Należy jednak pamiętać, że możliwość przekazania poszczególnych komponentów zależy od przysługujących praw oraz warunków licencji zewnętrznych.

Szczególnego znaczenia nabiera ustalenie, czy aplikacja może zostać przeniesiona na inny model AI. Jeżeli rozwiązanie jest silnie uzależnione od specyficznych funkcjonalności jednego dostawcy, migracja może wymagać istotnej przebudowy systemu. Dlatego warto już na etapie zawierania umowy określić zasady współpracy przy zmianie modelu, zakres dokumentacji niezbędnej do migracji oraz sposób rozliczenia prac związanych z zakończeniem współpracy.

W określonych sytuacjach znaczenie mogą mieć również przepisy Data Act dotyczące zmiany dostawcy usług przetwarzania danych. Nie należy jednak automatycznie przyjmować, że każdy system AI albo każda usługa udostępniająca model przez API podlega identycznym obowiązkom dotyczącym zmiany dostawcy. Zakres zastosowania przepisów wymaga odrębnej analizy charakteru konkretnej usługi.

Klauzula dwunasta — zmiany prawa, audyt zgodności i obowiązki dokumentacyjne

Ostatnią z kluczowych klauzul powinna być regulacja dotycząca zmian prawnych oraz współpracy stron przy zapewnianiu zgodności systemu z obowiązującymi przepisami. Jest to szczególnie istotne w przypadku AI Act, którego wymagania zaczęły być stosowane etapami, a część terminów dotyczących systemów wysokiego ryzyka została zmieniona. W konsekwencji aplikacja wdrażana obecnie może w przyszłości podlegać dodatkowym obowiązkom, których realizacja będzie wymagała przygotowania dokumentacji, przeprowadzenia testów albo wprowadzenia zmian technicznych.

Umowa powinna określać, kto odpowiada za monitorowanie zmian prawa, informowanie drugiej strony o nowych wymaganiach oraz przygotowanie planu dostosowania systemu. Należy również ustalić, czy prace związane z nowymi obowiązkami regulacyjnymi mieszczą się w pierwotnym wynagrodzeniu, czy wymagają odrębnego zlecenia. Brak takiego postanowienia może prowadzić do sporu, w którym zamawiający będzie oczekiwał bezpłatnego dostosowania systemu, a wykonawca uzna te czynności za dodatkowe prace rozwojowe.

Warto również przewidzieć zasady audytu zgodności. Zamawiający może potrzebować możliwości zweryfikowania dokumentacji, wyników testów, sposobu przetwarzania danych oraz mechanizmów bezpieczeństwa. Uprawnienia audytowe nie powinny jednak prowadzić do nieograniczonego dostępu do tajemnicy przedsiębiorstwa wykonawcy albo poufnych informacji należących do dostawców zewnętrznych. Dlatego kontrakt powinien określać zakres audytu, zasady poufności, sposób udostępniania informacji i procedurę usuwania stwierdzonych niezgodności.

Szczególnie istotne jest rozróżnienie dokumentacji technicznej potrzebnej do utrzymania systemu od dokumentacji regulacyjnej wymaganej przez AI Act. W przypadku systemów wysokiego ryzyka zakres dokumentacji może być znacznie szerszy niż standardowa dokumentacja developerska. Jeżeli strony nie ustalą, kto odpowiada za jej przygotowanie i aktualizację, problem może ujawnić się dopiero podczas kontroli albo przed planowanym wprowadzeniem systemu na rynek.

Umowa wdrożenia AI a odpowiedzialność za działanie agentów autonomicznych

Rozwój autonomicznych agentów sztucznej inteligencji powoduje, że klasyczne postanowienia umowne dotyczące oprogramowania wymagają dalszego dostosowania. Tradycyjna aplikacja zazwyczaj wykonuje działania bezpośrednio zainicjowane przez użytkownika, natomiast agent AI może samodzielnie planować kolejne czynności, korzystać z narzędzi zewnętrznych i podejmować działania na podstawie otrzymanego celu. Oznacza to, że błędna interpretacja polecenia może prowadzić nie tylko do wygenerowania nieprawidłowej odpowiedzi, lecz również do wykonania konkretnej operacji w systemie przedsiębiorstwa.

Przykładowo agent odpowiedzialny za obsługę korespondencji może przygotować i wysłać wiadomość zawierającą nieprawidłową informację handlową. Agent zakupowy może złożyć zamówienie na niewłaściwy produkt, natomiast agent pracujący z dokumentacją może usunąć albo zmodyfikować dane, które powinny pozostać niezmienione. W takich przypadkach znaczenie ma nie tylko poprawność modelu, lecz również sposób zaprojektowania uprawnień, mechanizmów autoryzacji oraz procedur zatwierdzania działań.

Z punktu widzenia prawa cywilnego nie należy zakładać, że sztuczna inteligencja jest samodzielnym podmiotem ponoszącym odpowiedzialność za swoje działania. Odpowiedzialność należy analizować w odniesieniu do osób i przedsiębiorców uczestniczących w projektowaniu, wdrażaniu i wykorzystywaniu systemu, zgodnie z właściwymi podstawami prawnymi. Właśnie dlatego umowa powinna szczegółowo regulować granice autonomii agenta, obowiązki zamawiającego dotyczące nadzoru oraz odpowiedzialność wykonawcy za prawidłowe wdrożenie uzgodnionych zabezpieczeń.

W projektach tego rodzaju szczególnie istotne jest także zabezpieczenie przed manipulowaniem poleceniami systemu, w tym przed atakami typu prompt injection. Jeżeli agent posiada możliwość korzystania z poczty elektronicznej, baz danych albo narzędzi finansowych, odpowiednie ograniczenie jego uprawnień może być jednym z podstawowych elementów należytego wykonania umowy wdrożeniowej.

AI Act w 2026 roku — jakie terminy powinny uwzględniać umowy wdrożeniowe?

Przygotowując umowę wdrożenia AI, należy uwzględnić aktualne terminy stosowania rozporządzenia. AI Act wszedł w życie 1 sierpnia 2024 roku, ale poszczególne obowiązki zaczęły być stosowane etapami. Od 2 lutego 2025 roku stosowane są między innymi określone przepisy dotyczące zakazanych praktyk i kompetencji w zakresie AI, natomiast od 2 sierpnia 2025 roku rozpoczęto stosowanie zasadniczej części obowiązków dotyczących dostawców modeli AI ogólnego przeznaczenia. Kolejne przepisy zaczęły być stosowane 2 sierpnia 2026 roku.

Istotne znaczenie mają zmiany wprowadzone do AI Act w 2026 roku. Po nowelizacji zasadnicze wymagania dotyczące systemów wysokiego ryzyka wymienionych w załączniku III mają być stosowane od 2 grudnia 2027 roku, natomiast w odniesieniu do odpowiednich systemów wysokiego ryzyka związanych z produktami objętymi regulacjami wskazanymi w załączniku I termin ten przypada zasadniczo na 2 sierpnia 2028 roku. Należy jednak pamiętać, że poszczególne przepisy mogą przewidywać rozwiązania szczególne, a nie wszystkie obowiązki dotyczące sztucznej inteligencji zostały przesunięte.

Z perspektywy umowy wdrożeniowej oznacza to konieczność odróżnienia wymagań obowiązujących już w chwili zawierania kontraktu od obowiązków, które zaczną być stosowane w przyszłości. Nie zawsze uzasadnione będzie wymaganie od wykonawcy natychmiastowego przeprowadzenia wszystkich procedur przewidzianych dla systemów wysokiego ryzyka, ale w projektach mających funkcjonować przez wiele lat warto uwzględnić przyszłe wymagania już na etapie projektowania architektury i dokumentacji.

Szczególnie niebezpieczne jest stosowanie w umowach ogólnych postanowień, zgodnie z którymi wykonawca zobowiązuje się do zapewnienia pełnej zgodności systemu ze wszystkimi obecnymi i przyszłymi przepisami prawa bez jakiegokolwiek ograniczenia czasowego, rzeczowego albo finansowego. Takie zobowiązanie może prowadzić do nieproporcjonalnego przeniesienia ryzyka regulacyjnego na software house. Znacznie bezpieczniejszym rozwiązaniem jest określenie stanu prawnego, względem którego oceniana będzie zgodność przy odbiorze, oraz odrębnej procedury dostosowywania systemu do późniejszych zmian.

Najczęstsze błędy w umowach wdrożeniowych AI

Jednym z najczęstszych błędów jest stosowanie standardowych wzorów umów IT bez uwzględnienia specyfiki modeli sztucznej inteligencji. W takich dokumentach często brakuje zasad oceny jakości wyników, odpowiedzialności za halucynacje, regulacji dotyczących modeli zewnętrznych oraz procedury postępowania w przypadku wycofania wykorzystywanej technologii. Zamawiający zakłada wówczas, że otrzyma rozwiązanie zapewniające określony rezultat, natomiast wykonawca traktuje swoje zobowiązanie jako dostarczenie narzędzia, którego wyniki mogą być zmienne.

Drugim istotnym błędem jest brak analizy ról stron wynikających z AI Act. W wielu projektach umowa nie określa, kto jest odpowiedzialny za kwalifikację systemu, przygotowanie dokumentacji i wykonanie obowiązków regulacyjnych. Problem ujawnia się dopiero wtedy, gdy klient oczekuje od software house’u dostarczenia dokumentacji zgodności, której przygotowanie nie zostało przewidziane w harmonogramie ani wycenie.

Kolejnym problemem jest niewystarczające zabezpieczenie danych. Strony koncentrują się na funkcjonalności aplikacji, ale nie analizują szczegółowo zasad przekazywania informacji do zewnętrznych modeli, okresów retencji, możliwości wykorzystywania danych do trenowania ani transferów poza Europejski Obszar Gospodarczy. W konsekwencji gotowy system może wymagać istotnych zmian przed dopuszczeniem go do przetwarzania rzeczywistych danych klientów.

Nie mniej istotne są błędy dotyczące własności intelektualnej. Umowy często przewidują ogólne przeniesienie wszystkich praw do systemu, mimo że wykonawca korzysta z komponentów zewnętrznych, modeli udostępnianych na podstawie licencji oraz bibliotek open source. Taki zapis może tworzyć fałszywe przekonanie, że zamawiający nabył prawa do całego stosu technologicznego, podczas gdy rzeczywisty zakres uprawnień jest znacznie węższy.

Czy software house powinien oferować audyt AI Act przed wdrożeniem?

W wielu przypadkach przeprowadzenie analizy prawnej przed rozpoczęciem developmentu może ograniczyć koszty całego projektu. Audyt pozwala ustalić, czy planowane rozwiązanie rzeczywiście stanowi system AI, jaka jest jego kwalifikacja pod względem ryzyka, jakie role będą pełniły poszczególne podmioty oraz jakie wymagania należy uwzględnić w dokumentacji i architekturze aplikacji. Dzięki temu wykonawca może prawidłowo wycenić prace, a zamawiający otrzymuje informację o obowiązkach związanych z późniejszym korzystaniem z systemu.

Szczególne znaczenie ma to w projektach dotyczących rekrutacji, edukacji, ochrony zdrowia, usług finansowych i innych obszarów, w których wykorzystanie sztucznej inteligencji może wpływać na prawa lub sytuację osób fizycznych. W takich przypadkach konieczne może być uwzględnienie nie tylko AI Act, lecz również RODO, przepisów sektorowych oraz szczególnych wymagań dotyczących bezpieczeństwa i odpowiedzialności.

Audyt przedwdrożeniowy powinien obejmować także analizę warunków korzystania z modeli zewnętrznych. Należy ustalić, czy wybrany dostawca zapewnia informacje i dokumentację potrzebne do zgodnego z prawem wdrożenia, jakie ograniczenia wynikają z licencji oraz czy model może być wykorzystywany do planowanego zastosowania. Jeżeli już na tym etapie okaże się, że wybrana technologia nie odpowiada wymaganiom projektu, zmiana rozwiązania będzie zazwyczaj znacznie mniej kosztowna niż przebudowa gotowej aplikacji.

Ile kosztuje przygotowanie umowy wdrożenia AI i od czego zależy zakres prac?

Zakres prac prawnych związanych z przygotowaniem umowy wdrożeniowej AI zależy przede wszystkim od charakteru projektu. Innego dokumentu będzie wymagało wdrożenie prostego chatbota obsługującego klientów sklepu internetowego, a innego stworzenie rozbudowanego systemu analizy dokumentacji medycznej albo agenta AI wykonującego operacje w systemach finansowych przedsiębiorstwa. Znaczenie ma również model współpracy, sposób rozliczenia projektu, liczba dostawców zewnętrznych oraz przewidywany zakres odpowiedzialności wykonawcy.

W prostszych projektach wystarczające może być odpowiednie dostosowanie istniejącej umowy wdrożeniowej IT, uzupełnienie jej o postanowienia dotyczące modeli AI, zasad przetwarzania danych i odpowiedzialności za wyniki. W bardziej złożonych przedsięwzięciach konieczne może być przygotowanie całego pakietu dokumentacji obejmującego umowę główną, specyfikację funkcjonalną, SLA, umowę powierzenia danych, zasady korzystania z modeli zewnętrznych oraz dokumentację dotyczącą obowiązków wynikających z AI Act.

Warto pamiętać, że koszt przygotowania prawidłowej umowy powinien być oceniany w odniesieniu do wartości całego projektu i potencjalnych konsekwencji sporu. W przypadku aplikacji wykorzystywanej w istotnych procesach biznesowych nieprecyzyjne postanowienia dotyczące odbioru, odpowiedzialności albo praw własności intelektualnej mogą prowadzić do strat znacznie przewyższających koszt wcześniejszej analizy prawnej.

Podsumowanie — jak zabezpieczyć umowę wdrożenia AI?

Umowa wdrożenia sztucznej inteligencji powinna być przygotowywana z uwzględnieniem rzeczywistego modelu technologicznego, sposobu wykorzystania systemu oraz obowiązków prawnych stron. Nie wystarczy określenie funkcjonalności aplikacji i zasad zapłaty wynagrodzenia. Konieczne jest również uregulowanie odpowiedzialności za modele zewnętrzne, jakości generowanych wyników, ochrony danych, praw własności intelektualnej, nadzoru nad autonomicznymi działaniami systemu oraz zasad utrzymania i dalszego rozwoju rozwiązania.

Szczególnie istotne jest prawidłowe ustalenie ról wynikających z AI Act. Software house nie zawsze jest dostawcą systemu AI, a zamawiający nie zawsze pozostaje wyłącznie podmiotem stosującym. Rzeczywista kwalifikacja zależy od sposobu opracowania i udostępnienia systemu, jego przeznaczenia oraz zakresu wprowadzanych modyfikacji. Umowa powinna odzwierciedlać ten podział i określać obowiązki współpracy, ale nie może być traktowana jako instrument dowolnego wyłączania odpowiedzialności wynikającej bezpośrednio z przepisów.

Z perspektywy software house’u najważniejsze jest unikanie zobowiązań, których wykonanie zależy od podmiotów zewnętrznych albo od właściwości technologii pozostających poza kontrolą wykonawcy. Z kolei zamawiający powinien zadbać o możliwość rzeczywistego korzystania z systemu, odpowiednią dokumentację, bezpieczeństwo danych oraz przewidywalne zasady reagowania na awarie i zmiany technologiczne.

Dobrze przygotowana umowa wdrożenia AI nie eliminuje wszystkich ryzyk związanych ze sztuczną inteligencją, ale pozwala je zidentyfikować, ograniczyć i odpowiednio rozdzielić pomiędzy strony. W praktyce jest to jeden z podstawowych elementów bezpiecznego wdrażania systemów AI w działalności gospodarczej. Dlatego przed podpisaniem kontraktu warto przeprowadzić analizę prawną projektu, ustalić rzeczywiste obowiązki wynikające z AI Act oraz dostosować dokumentację do konkretnego rozwiązania i modelu współpracy.