Umowa wdrożeniowa IT w dobie AI: jak skutecznie zabezpieczyć własność intelektualną?

Czy wiesz, z jakich elementów rzeczywiście składa się system zamawiany przez Twoją firmę? Które z nich stworzył wykonawca, które pochodzą z open source, a które powstały przy wykorzystaniu AI? Czy po zapłacie wynagrodzenia będziesz mógł samodzielnie rozwijać oprogramowanie? I czy wykonawca na pewno może przenieść na Ciebie prawa, które zobowiązał się przekazać?

Wyobraź sobie, że firma zamawia dedykowaną aplikację. Projekt zostaje odebrany i opłacony, a umowa przewiduje przeniesienie autorskich praw majątkowych do kodu. Dopiero później okazuje się, że część rozwiązania powstała przy użyciu narzędzia generatywnego, kluczowe funkcje korzystają z zewnętrznego modelu AI, a niektóre komponenty podlegają odrębnym licencjom.

Czy zamawiający rzeczywiście uzyskał prawa pozwalające bezpiecznie korzystać z całego rozwiązania i dalej je rozwijać?

Samo postanowienie, zgodnie z którym wykonawca „przenosi wszystkie autorskie prawa majątkowe do oprogramowania”, może nie wystarczyć. W projekcie wykorzystującym AI trzeba najpierw ustalić, co rzeczywiście powstało, jaki był udział człowieka, z jakich komponentów korzysta system oraz którymi prawami wykonawca może skutecznie rozporządzać.

1. Gdzie AI zmienia klasyczną umowę wdrożeniową?

Umowa wdrożeniowa może obejmować stworzenie dedykowanego rozwiązania, konfigurację istniejącego systemu, integrację z infrastrukturą klienta albo uruchomienie usługi korzystającej z modelu AI. Z perspektywy IP istotne jest przede wszystkim odróżnienie dwóch sytuacji.

W obu przypadkach umowa powinna odzwierciedlać rzeczywistą architekturę rozwiązania. Nazwa „system” albo „oprogramowanie” nie wyjaśnia jeszcze, czy przedmiotem praw są kod dedykowany, komponenty wykonawcy, biblioteki open source, model zewnętrzny, dokumentacja, baza danych czy prompty systemowe.

AI Act (Rozporządzenie Parlamentu Europejskiego i Rady, Dz.U.UE.L.2024.1689) reguluje rozwój, wprowadzanie do obrotu, oddawanie do użytku i wykorzystywanie systemów AI oraz posługuje się własnymi kategoriami uczestników rynku. Nie rozstrzyga jednak wprost, czy konkretny output AI jest utworem ani komu przysługują prawa do kodu tworzonego z wykorzystaniem AI. W tym zakresie podstawowe znaczenie mają przepisy prawa autorskiego, warunki konkretnego narzędzia oraz rzeczywisty udział człowieka w powstaniu rezultatu.

2. Czy wykonawca może przenieść prawa do rezultatów powstałych z wykorzystaniem AI?

Zgodnie z art. 1 ust. 1 ustawy o prawie autorskim i prawach pokrewnych utworem jest przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci. Konstrukcja prawa autorskiego zakłada twórczość człowieka. Dlatego przy rezultatach generowanych przez AI kluczowe jest ustalenie, czy i w jakim zakresie rezultat jest efektem twórczych wyborów człowieka.

Inaczej należy ocenić sytuację, w której narzędzie generuje gotowy fragment, a człowiek jedynie go akceptuje, a inaczej taką, w której programista dokonuje twórczej selekcji, gruntownej modyfikacji i włącza rezultat do samodzielnie zaprojektowanej struktury programu. Samo skorzystanie z AI nie wyklucza ochrony całego rozwiązania. Nie można jednak automatycznie przyjmować, że wykonawcy przysługują wyłączne prawa do każdego outputu wygenerowanego w toku prac.

Również brak ochrony konkretnego outputu nie oznacza automatycznie pełnej swobody korzystania. Nadal mogą mieć znaczenie prawa do materiałów wykorzystanych w rezultacie, warunki dostawcy narzędzia, tajemnica przedsiębiorstwa, prawa do bazy danych lub zobowiązania dotyczące poufności.

Wykonawca może przenieść tylko prawa, które rzeczywiście posiada. Dlatego przed ustaleniem zakresu transferu należy zidentyfikować pochodzenie najważniejszych elementów systemu.

Najważniejsze obszary ryzyka IP

3. Jak zabezpieczyć IP w umowie?

W większości projektów właściwe będzie rozwiązanie mieszane: przeniesienie autorskich praw majątkowych do elementów stworzonych indywidualnie dla zamawiającego oraz odpowiednio szeroka licencja do komponentów wykonawcy. Open source, komponenty third-party i modele zewnętrzne pozostają objęte warunkami właściwych licencji lub usług.

Prawo autorskie wymaga przy tym precyzji. Art. 41 ust. 2 nakazuje wyraźnie wymienić pola eksploatacji, a art. 53 wymaga formy pisemnej pod rygorem nieważności dla przeniesienia autorskich praw majątkowych. W przypadku programu komputerowego należy uwzględnić szczególny zakres praw z art. 74 ust. 4, dotyczący m.in. zwielokrotniania, modyfikowania i rozpowszechniania programu. Znaczenie mogą mieć również prawa zależne, terytorium, czas licencji i możliwość udzielania sublicencji.

Umowa powinna przede wszystkim regulować:

• zasady korzystania z AI – wskazanie dopuszczalnych narzędzi i zakresu, w którym mogą być używane;
• ochronę danych i poufności – zakaz wprowadzania kodu, danych osobowych i informacji poufnych do niezatwierdzonych narzędzi;
• obowiązek informowania o użyciu AI – co najmniej wtedy, gdy może ono wpływać na status prawny lub bezpieczeństwo kluczowego rezultatu;
• human review – obowiązek profesjonalnego sprawdzenia i przetestowania materiałów przygotowanych z wykorzystaniem AI;
• pochodzenie komponentów – rozróżnienie elementów dedykowanych, komponentów wykonawcy, open source, third-party i rezultatów AI;
• zakres praw lub licencji – zapewniający korzystanie, modyfikowanie i rozwijanie systemu zgodnie z celem wdrożenia;
• roszczenia osób trzecich – zasady współpracy przy obronie, podział kosztów i obowiązek dostarczenia rozwiązania zastępczego;
• wydanie kodu i dokumentacji – tak aby formalnym prawom towarzyszyła techniczna możliwość dalszego korzystania z systemu.

Kto odpowiada, jeśli rezultat AI narusza cudze prawa?

W projekcie może uczestniczyć wykonawca, jego podwykonawca, dostawca modelu i zamawiający. Rozproszony łańcuch technologiczny może prowadzić do liability gap, czyli trudności w ustaleniu, na którym etapie powstał problem i kto powinien ponieść jego skutki.

AI Act przypisuje uczestnikom rynku określone obowiązki regulacyjne, ale nie tworzy kompletnego systemu odpowiedzialności odszkodowawczej. W relacji wykonawca–zamawiający kluczowe pozostają zatem postanowienia umowy oraz ogólne zasady odpowiedzialności kontraktowej, w szczególności art. 471 i nast. Kodeksu cywilnego.

Umowa powinna określać obowiązek współpracy po zgłoszeniu roszczenia, zasady obrony, koszty postępowania, wymianę problematycznego komponentu oraz wpływ naruszenia IP na limit odpowiedzialności. Samo wskazanie, że dany element został wygenerowany przez AI, nie powinno zwalniać profesjonalnego wykonawcy z obowiązku jego weryfikacji.

4. Same prawa nie wystarczą: kod, dokumentacja i vendor lock-in

Zamawiający może uzyskać szeroki zakres praw, a mimo to pozostać faktycznie uzależniony od dotychczasowego wykonawcy. Taki vendor lock-in powstaje m.in. wtedy, gdy klient nie otrzymuje materiałów lub dostępów potrzebnych do uruchomienia, utrzymania i rozwijania systemu.

W zależności od charakteru projektu umowa powinna przewidywać przekazanie co najmniej:

• aktualnego kodu źródłowego;
• repozytorium albo jego eksportu;
• dokumentacji technicznej i dokumentacji API;
• wykazu komponentów open source oraz third-party wraz z informacją o licencjach;
• danych dostępowych, kont i kluczy należących do zamawiającego.

Jeżeli kluczowe funkcje aplikacji zależą od zewnętrznego modelu, trzeba również ustalić, kto zawiera umowę z jego dostawcą, kto kontroluje konto i czy integrację można przenieść do innej usługi. Zamawiający zazwyczaj nie nabywa praw do samego modelu tylko dlatego, że korzysta z niego wdrożona aplikacja.

Skuteczne zabezpieczenie IP nie polega zatem na maksymalnym rozszerzeniu praw jednej strony. Powinno zapewniać zamawiającemu prawne i techniczne możliwości korzystania z kompletnego rozwiązania zgodnie z celem wdrożenia, a wykonawcy pozostawiać prawa do jego rzeczywistych komponentów bazowych i know-how.

Podsumowanie

Wykorzystanie AI komplikuje odpowiedź na pytanie, co właściwie powstaje w ramach wdrożenia, komu przysługują prawa do rezultatu i czy wykonawca może skutecznie przekazać klientowi oczekiwany zakres uprawnień.

Dlatego przed podpisaniem umowy warto sprawdzić przede wszystkim:

• z jakich komponentów składa się system;
• które rezultaty powstały przy wykorzystaniu AI i jaki był wkład człowieka;
• czy wykonawca posiada prawa, które zobowiązuje się przenieść;
• jakie licencje dotyczą rozwiązań open source, third-party i zewnętrznych modeli;
• czy zamawiający będzie mógł faktycznie korzystać z systemu i rozwijać go po zakończeniu współpracy.

Ogólne postanowienie o przeniesieniu „wszystkich praw” nie zastąpi rzetelnej identyfikacji komponentów, prawidłowego modelu licencyjnego i zabezpieczeń odnoszących się do wykorzystania AI.