Prawa autorskie do kodu tworzonego z AI (vibecoding)

1. Vibecoding zmienił programowanie: nowy problem prawny

Dzisiaj programista dostarcza klientowi działający produkt znacznie szybciej niż kilka lat temu. W wielu sytuacjach część tego kodu, formalnie, może jednak nie należeć do nikogo. Vibecoding, czyli programowanie, w którym deweloper (albo „zwykły user") prowadzi narzędzie AI (Copilot, Cursor, ChatGPT) zamiast pisać każdą linijkę sam, stał się codziennością w wielu firmach IT. Dzięki temu kod powstaje szybciej, taniej i mniejszym zespołem.

Umowy sprzed kilku lat w ogóle nie przewidywały kodu tworzonego w ten sposób. Od tego, czyją własnością jest taki kod i czy jest chroniony prawem autorskim, zależy, co można sprzedać klientowi, co przenieść umową i czego obronić przed konkurencją.

Dla firmy, która sprzedaje klientowi kod niepisany w całości przez człowieka (albo kupuje go od podwykonawcy), prawa autorskie przestają być teorią i trzeba je uregulować w umowie.

Umów konsultację

2. Identyfikacja: kiedy kod jest „utworem" chronionym prawem autorskim

Zanim ustalimy, co zrobić z kodem z AI, trzeba zrozumieć, kiedy w ogóle jakikolwiek kod jest utworem.

Zgodnie z art. 1 ust. 1 ustawy o prawie autorskim i prawach pokrewnych (dalej: pr. aut.) utworem jest „każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci". Program komputerowy jest wprost wymieniony jako kategoria utworu, a art. 74 ust. 1 pr. aut. precyzuje, że „programy komputerowe podlegają ochronie jak utwory literackie".

Chronione jest jednak wyrażenie, nie funkcja. Sama ochrona obejmuje konkretny kod źródłowy i obiektowy, jego architekturę, strukturę modułów i nazewnictwo, ale nie idee, algorytmy, metody działania, interfejsy ani język programowania (art. 1 ust. 2(1) i art. 74 ust. 2 pr. aut.). Standard unijny doprecyzowuje, że program jest chroniony, jeśli stanowi własną twórczość intelektualną autora (TSUE, Infopaq C-5/08; SAS Institute C-406/10). Nowelizacja pr. aut. z 20 września 2024 r. (wdrożenie dyrektyw DSM i SATCAB II) nie zmieniła tych podstaw ani nie uregulowała wprost twórczości z udziałem AI, więc ocena opiera się na dotychczasowych zasadach.

Co znaczy „twórczy o indywidualnym charakterze". Definicja utworu kryje dwie odrębne przesłanki, które należy spełnić łącznie. Pierwsza to twórczość: rezultat musi być efektem intelektualnej, kreacyjnej działalności człowieka, a nie odtworzeniem cudzego rozwiązania czy czynnością rutynową. Wystarczy tu nowość subiektywna: nie chodzi o to, by nikt na świecie nie stworzył podobnego kodu, lecz by nie był on skopiowany, tylko samodzielnie „wymyślony" przez autora.

Druga przesłanka to indywidualny charakter: utwór musi nosić piętno osobowości twórcy, odróżniające go od rozwiązań szablonowych. W doktrynie służy do tego test statystycznej jednorazowości tj. dzieło ma charakter indywidualny, jeżeli jest statystycznie nieprawdopodobne, by inna osoba przy tym samym zadaniu stworzyła identyczny rezultat. Wiąże się z tym pojęcie przestrzeni swobody twórczej: TSUE mówi o „swobodnych i twórczych wyborach" autora (Painer, C-145/10). Im bardziej rozwiązanie jest zdeterminowane funkcją, wymaganiami technicznymi czy standardem, tym węższa ta przestrzeń i tym trudniej wykazać indywidualność.

W kodzie widać to szczególnie wyraźnie, bo znaczna część oprogramowania jest funkcjonalnie zdeterminowana: dany efekt da się osiągnąć tylko na kilka „oczywistych" sposobów, a wtedy wybór jednego z nich nie jest jeszcze twórczy. Prawo chroni minimum twórczości, a próg jest niski, choć nie zerowy. Granica biegnie tam, gdzie kończy się rozwiązanie narzucone przez funkcję lub konwencję, a zaczyna wybór, który realnie mógł wypaść inaczej i nosi indywidualny ślad autora. Tylko w takiej sytuacji możemy mówić o powstaniu utworu.

Dlaczego AI nie może być twórcą. W prawie polskim twórcą może być wyłącznie człowiek tj. prawo autorskie pierwotnie nabywa twórca i jego pierwszym źródłem jest twórcza działalność człowieka (art. 8 ust. 1 pr. aut.; SN, II CSK 281/13). Wytwór wygenerowany wyłącznie przez AI, bez mierzalnego wkładu człowieka w warstwę twórczą, to w terminologii prawa autorskiego wytwór, a nie utwór. Co do zasady nie powstają wtedy do niego niczyje wyłączne prawa autorskie. Powstanie "wytworu" a nie "utworu" nie znaczy jednak, że można ignorować inne ryzyka takie jak warunki korzystania z narzędzia AI, tajemnicę przedsiębiorstwa, dane wejściowe, podobieństwo do cudzych utworów albo obowiązki umowne.

Stąd rozróżnienie: - AI-generated: kod wygenerowany samodzielnie przez AI, bez merytorycznej ingerencji człowieka - co do zasady nie stanowi utworu ze względu na brak twórczego wpływu człowieka. - AI-assisted: kod tworzony przez AI pod kierownictwem i z twórczą interwencją człowieka. Ochrona możliwa, o ile człowiek zachowuje kreatywną kontrolę nad sposobem wyrażenia.

W praktyce najważniejsze jest wykazać, że kod jest AI-assisted, a nie AI-generated.

3. Czyje są prawa do kodu: UoP vs B2B (częsta pułapka)

Załóżmy, że kod jest utworem. Zostaje pytanie: kto ma do niego prawa? Odpowiedź zależy od formy współpracy i właśnie tu firmy najczęściej tracą prawa do własnego kodu.

Umowa o pracę (UoP). Programy komputerowe rządzą się szczególną zasadą. Zgodnie z art. 74 ust. 3 pr. aut. autorskie prawa majątkowe do programu stworzonego przez pracownika w ramach obowiązków służbowych przysługują pracodawcy z mocy ustawy, o ile umowa nie stanowi inaczej. W praktyce, jeżeli programista pracuje na etacie i tworzy program w ramach obowiązków pracowniczych, autorskie prawa majątkowe do kodu co do zasady nabywa pracodawca. Istotny jest zakres obowiązków: reguła obejmuje tylko kod tworzony w ramach zadań służbowych, a kod powstały całkowicie poza nimi (np. prywatny projekt po godzinach) niekoniecznie przechodzi na pracodawcę, co często bywa źródłem sporów.

B2B / umowa o dzieło / zlecenie. Tu nie ma automatycznego przejścia praw. Autorskie prawa majątkowe zostają przy programiście-wykonawcy, dopóki nie przeniesie ich jednoznacznie w umowie. Samo przeniesienie praw majątkowych wymaga m.in.: - formy pisemnej pod rygorem nieważności (art. 53 pr. aut.); ustalenia mailowe czy ustne nie wystarczą, - wymienienia pól eksploatacji (art. 41 ust. 2); przenieść można tylko to, co wprost wskazano.

Przenieść można przy tym jedynie autorskie prawa majątkowe. Autorskie prawa osobiste (m.in. prawo do autorstwa) są niezbywalne i zostają przy twórcy.

Najczęstsza pułapka B2B. Firmy, zwłaszcza startupy i software house'y, często współpracują z deweloperami na B2B i zakładają, że „skoro zapłaciłem, to kod jest mój". W rzeczywistości bywa inaczej. Bez prawidłowej klauzuli o przeniesieniu praw majątkowych nabywca dostaje najwyżej licencję (albo nic pewnego), a majątkowe prawa autorskie zostają u wykonawcy. Przy rundzie inwestycyjnej albo sprzedaży spółki kupujący płaci wtedy za kod, którego nie da się skutecznie przenieść, a to potrafi obciąć wycenę albo wywrócić transakcję na due diligence.

Przy vibecodingu pułapka B2B się podwaja, ponieważ nawet najlepsza klauzula przenosi prawa tylko do tego, co jest utworem. Jeśli część kodu to czysty AI-generated output (bez twórczego wkładu człowieka), nie ma czego przenosić, bo do tych fragmentów nie powstały niczyje prawa autorskie. Umowa z deweloperem powinna więc dziś łączyć klauzulę przeniesienia praw z obowiązkiem dokumentowania pracy z AI (sekcja 6) oraz z oświadczeniem wykonawcy, że twórczy wkład człowieka w kod jest wystarczający, by kod stanowił utwór w rozumieniu prawa autorskiego.

4. Poziomy twórczości w vibecodingu: trzy modele

Wkład człowieka w vibecoding można rozpatrywać na trzech poziomach, które przekładają się na siłę ochrony:

Do Modelu 1 pasuje analogia z fotografią: fotograf używa zaawansowanego aparatu, a narzędzie nie pozbawia go autorstwa, bo to on podejmuje twórcze wybory. Tak samo programista, który projektuje system i świadomie steruje AI, pozostaje twórcą finalnej formy kodu. Przy niższych poziomach wkładu ochronę coraz trudniej obronić.

5. Analiza prawna: co zrobić, żeby kod stał się utworem

Żeby kod z AI był utworem, wkład człowieka musi spełnić kryteria twórczości o indywidualnym charakterze (sekcja 2). Trudniejsze jest jednak inne pytanie: w którym momencie procesu vibecodingu ten charakter w ogóle powstaje. To kryterium jest wyjątkowo płynne, bo ocenia się je każdorazowo in casu, a nie zerojedynkowo.

Trzy błędne intuicje. Najpierw to, co charakteru twórczego jeszcze nie tworzy: - Nie w momencie promptu. Prompt wyraża pomysł i funkcję, a te są wprost wyłączone z ochrony (art. 1 ust. 2(1); art. 74 ust. 2 pr. aut.). Nawet ekspercki, rozbudowany prompt pozostaje niechronioną ideą, dopóki nie przełoży się na twórczy wybór sposobu wyrażenia. Sam prompt może wyjątkowo być chroniony jako tekst, jeśli spełnia przesłanki utworu, ale nie przesądza to o ochronie wygenerowanego kodu. - Nie w momencie wygenerowania. Output to rezultat danych treningowych i parametrów modelu, nie osobowości człowieka. Sam w sobie nie nosi „piętna" konkretnego autora. - Nie z powodu ilości pracy. Liczba promptów, godzin i iteracji nie tworzy utworu, jeśli nie prowadzi do indywidualnego wyrazu. Polskie prawo nie chroni „potu czoła", lecz minimalny poziom twórczego wkładu.

Moment, w którym charakter twórczy realnie powstaje. Charakter twórczy pojawia się wtedy, gdy człowiek dokonuje wyborów co do sposobu wyrażenia kodu (na tyle swobodnych, na ile pozwala funkcja), nienarzuconych przez zadanie ani biernie przejętych z domyślnego outputu. W praktyce vibecodingu przybiera to formy:

• projektowanie architektury: struktura modułów, podział na funkcje/klasy, ich powiązania,
• twórczy dobór i kombinacja wygenerowanych fragmentów, ich integracja i przeróbka,
• oryginalne nazewnictwo i sposób dokumentowania, odzwierciedlające indywidualny styl,
• twórcza refaktoryzacja kodu AI, prowadząca do odmiennej struktury i brzmienia,
• własne algorytmy i implementacje, wygenerowane częściowo przez AI, ale przekształcone przez programistę.

Dlaczego to kryterium jest tak płynne. Nie ma tu twardej linii ani reguły „X% ręcznej edycji = utwór". Sąd ocenia każdy przypadek osobno, a przesądza kilka rzeczy naraz:

1. Gradacja, nie trzy pudełka. Formy wkładu z sekcji 4 to proces. Realne przypadki najczęściej lądują pośrodku (Model 2), gdzie o ochronie rozstrzyga niuans tj. czy dobór i układ wygenerowanych fragmentów miał cechy indywidualne, czy był oczywisty.
2. Ta sama czynność, dwie kwalifikacje. „Prompt plus drobna korekta" bywa raz twórczy, raz czysto techniczny, zależnie od tego, czy korekta była realnym wyborem z szerokiej przestrzeni rozwiązań, czy jedyną sensowną poprawką narzuconą przez funkcję. SN konsekwentnie odróżnia pracę twórczą od technicznej, wskazując, że cechą pracy technicznej jest przewidywalność i powtarzalność rezultatu (SN, I CK 281/05).
3. Wąska przestrzeń swobody w kodzie. Fragment silnie zdeterminowany funkcją, biblioteką, konwencją języka czy wymogiem interoperacyjności zostawia mało miejsca na indywidualność, niezależnie od tego, kto go napisał. Duża część „zwykłego" kodu w ogóle nie osiąga progu twórczości, a model dodatkowo ciąży ku rozwiązaniom typowym, statystycznie najczęstszym. W praktyce bardzo często model po prostu kompiluje kod, na którym był trenowany lub do którego ma dostęp w internecie.
4. Test statystycznej jednorazowości bywa nierozstrzygalny. Trudno dowieść, że danego fragmentu „nie stworzyłby nikt inny", skoro model generuje to, co najbardziej prawdopodobne, a więc najłatwiejsze do powtórzenia. Nieprzewidywalność outputu (ten sam prompt daje różne wyniki) nie świadczy o twórczości człowieka ponieważ losowość kontrolują dane treningowe i parametry modelu, nie użytkownik.
5. Ocena zawsze ex post i całościowa. Sąd nie bada „czy użyto AI", lecz czy w finalnym kodzie, na tle udokumentowanego procesu, widać indywidualny wkład człowieka w warstwie wyrażenia.

Praktyczny test granicy. Zamiast pytać „ile AI?", warto zadać cztery pytania do konkretnego fragmentu:

1. Czy sposób jego wyrażenia był zdeterminowany funkcją (jedyne sensowne rozwiązanie)? Jeśli tak, twórczości brak, niezależnie od autora.
2. Czy inny kompetentny programista, mając to samo zadanie, napisałby to tak samo? Jeśli raczej tak, indywidualność jest wątpliwa.
3. Czy output modelu został realnie przekształcony (architektura, struktura, brzmienie), czy przyjęty w zasadzie bez zmian?
4. Czy istnieje ślad ludzkich wyborów (dobór, układ, refaktoryzacja), które mogły wypaść inaczej?

Im więcej odpowiedzi wskazuje na realny, swobodny wybór człowieka co do wyrażenia, tym pewniejsza ochrona. Zawsze jest to jednak ocena stopnia, a nie prosta alternatywa.

Przeszacujesz wkład albo go nie docenisz — kosztuje jedno i drugie. Uznanie za utwór czegoś, co nim nie jest, oznacza przenoszenie albo sprzedaż praw, których nie ma, z ryzykiem przy due diligence, rundzie inwestycyjnej i sporze. Niedocenienie własnego wkładu zostawia bez ochrony kod, który dało się obronić. Rozstrzyga tu nie deklaracja, lecz udokumentowany proces (sekcja 6).

Przegląd orzecznictwa: jedna linia w różnych jurysdykcjach.

Orzeczenia z Polski, Unii, USA i Azji układają się w jedną linię — od pytania, kto może być twórcą, przez to, co w kodzie jest chronione, po to, co realnie przesądza o ochronie.

1. Punkt wyjścia: twórcą może być tylko człowiek.

D.C. Circuit (USA), 18.03.2025, No. 23-5233 Thaler v. Perlmutter. Wniosek o rejestrację praw do obrazu, ze wskazaniem autonomicznego systemu AI jako autora. Copyright Act wymaga jednak autorstwa człowieka, więc maszyna autorem być nie może. Kwestii utworów współtworzonych z AI wyrok nie przesądził. Sąd Najwyższy USA odmówił przyjęcia sprawy do rozpoznania 2.03.2026 r., pozostawiając w mocy orzeczenie D.C. Circuit.

Ta sama zasada obowiązuje w prawie polskim (SN, II CSK 281/13 — sekcja 2). Skoro twórcą jest człowiek, kolejne pytanie brzmi: która warstwa kodu w ogóle podlega ochronie.

2. Przedmiot ochrony się zawęża: chronione jest wyrażenie, nie funkcja ani idea.

TSUE, 16.07.2009, C-5/08 Infopaq. Zapisywanie 11-wyrazowych fragmentów prasy. Ochrona przysługuje tylko wtedy, gdy fragment jest „własną twórczością intelektualną autora". To unijny punkt wyjścia oceny oryginalności.

TSUE stopniowo doprecyzował, gdzie ta ochrona się kończy. W C-406/10 SAS Institute (2.05.2012, odtworzenie funkcjonalności programu bez dostępu do kodu) uznał, że nie są chronione funkcjonalność, język programowania ani format plików. W C-159/23 Sony v. Datel (17.10.2024, oprogramowanie zmieniające wartości zmiennych gry w pamięci RAM) — że ochrona nie obejmuje danych w pamięci podczas działania programu. (Zastrzeżenie: sprawa o zakres ochrony programów, nie o zasadę oryginalności ani AI.)

Przy kodzie z AI wniosek jest prosty: chroniony jest konkretny wyraz kodu, a nie idea czy funkcja, którą AI może swobodnie odtworzyć. Zostaje pytanie, kiedy ten wyraz staje się „własną twórczością".

3. Miara oryginalności: swobodne, twórcze wybory.

TSUE, 1.12.2011, C-145/10 Painer. Fotografia portretowa jest chroniona, jeśli wyraża „swobodne, twórcze wybory" autora. To ten sam test, który przy kodzie z AI odróżnia realny wkład człowieka od automatyzmu generowania. Można go przy tym stosować nie tylko do całości.

4. Poziom oceny: nawet fragment kodu.

NSA, 7.12.2023, II FSK 812/22. Sprawa dotyczyła IP Box i fragmentów oprogramowania tworzonych przez programistę w ramach większego projektu. NSA przyjął, że odpowiedni fragment kodu, stanowiący swoisty podprogram, może samodzielnie podlegać ochronie jako program komputerowy na podstawie art. 74 pr. aut., o ile ma twórczy i indywidualny charakter. (Kontekst podatkowy; ochrona autorska to konsekwencja, nie dosłowna teza.)

Dla vibecodingu ma to bezpośredni skutek: ochronę ocenia się fragment po fragmencie. Jeden moduł może być utworem, a sąsiedni, wygenerowany bez wkładu człowieka, już nie.

5. Co przesądza w praktyce: udokumentowane wybory, nie losowość.

Sąd w Zhangjiagang (Chiny), 19.03.2025, Feng v. Dongshan. Obrazy z Midjourney na podstawie pojedynczego promptu. Odmowa ochrony: treść powstała głównie autonomicznie, losowość uniemożliwiła odtworzenie tych samych obrazów, a brak udokumentowanych wyborów twórczych przesądził o braku oryginalności. Apelacja oddalona (17.04.2025).

Sąd Miejski w Pradze, 11.10.2023, 10 C 13/2023. Grafika z DALL-E użyta przez pozwanego. Sąd uznał, że to nie unikalny rezultat twórczości osoby fizycznej, a powód nie wykazał nawet własnego autorstwa — nie wykluczył jednak autorstwa przy odpowiednich dowodach.

Oba sądy pokazują tę samą rzecz od strony dowodowej: przegrywa nie ten, kto użył AI, lecz ten, kto nie udokumentował własnych wyborów twórczych.

6. Sygnał organów podatkowych.

Interpretacje KIS nie rozstrzygają wiążąco o istnieniu utworu w sensie cywilnoprawnym, ale pokazują, jak organy zaczynają w praktyce odróżniać wytwór AI od pracy twórczej wspomaganej AI.

KIS, 29.04.2025, 0115-KDIT1.4011.190.2025.1.MN (https://sip.lex.pl/orzeczenia-i-pisma-urzedowe/pisma-urzedowe/0115-kdit1-4011-190-2025-1-mn-przychody-z-platform-185290197) (EUREKA: eureka.mf.gov.pl). Przychody z grafik generowanych przez AI i ze sklonowanego, syntetycznego głosu. Organ uznał, że wytwory wyłącznie AI nie są utworami, bo brak w nich przejawu twórczej działalności człowieka: „grafiki (…) są efektem pracy sztucznej inteligencji, nie zaś człowieka, który jedynie określa za pomocą komend słowa kluczowe czy reguły algorytmów (…) nie są utworem w rozumieniu odrębnych przepisów". Bez prawa do 50% KUP.

KIS, 25.04.2025, 0114-KDIP3-1.4011.236.2025.2.EC (https://sip.lex.pl/orzeczenia-i-pisma-urzedowe/pisma-urzedowe/0114-kdip3-1-4011-236-2025-2-ec-skutki-podatkowe-185290352) (EUREKA: eureka.mf.gov.pl). Zespół projektował i optymalizował algorytmy predykcyjne z AI jako narzędziem. Organ uznał, że praca wspomagana AI może być działalnością badawczo-rozwojową i uprawniać do 50% KUP, gdy decydujący wpływ twórczy zachowuje człowiek (złożone prompty oparte na wiedzy domenowej, selekcja wyników). (Stan faktyczny to prace B+R nad algorytmami, nie wprost vibecoding; przenoszenie wniosku wymaga ostrożności.)

Konwergencja. Wspólny kierunek jest widoczny, choć podstawy prawne różnią się między jurysdykcjami: ochronę daje udokumentowana, twórcza kontrola człowieka nad wyrazem kodu, a nie sam fakt użycia AI.

Co z tej linii wynika dla kodu z AI. Zestawione razem, te orzeczenia dają test, który stosuje się do konkretnego fragmentu:

• Prompt „napisz funkcję X" i przyjęcie wyniku. Zgodnie z wyrokiem Thaler i wyżej wskazaną interpretacją KIS to wytwór AI: brak swobodnych wyborów człowieka (Painer) i brak udokumentowanego wkładu (Feng). Ochrony brak.
• Prompt i istotna refaktoryzacja architektury oraz struktury. Człowiek dokonuje swobodnych, twórczych wyborów co do wyrazu (Painer), a ochronę ocenia się na poziomie tego właśnie fragmentu (NSA). Ochrona jest realna, o ile wybory są udokumentowane (Feng, Praga).
• Kod funkcjonalnie zdeterminowany (jedyne sensowne rozwiązanie). Nie jest twórczy nawet napisany w całości ręcznie; SAS Institute potwierdza, że sama funkcja nie podlega ochronie.

Orzecznictwo nie pyta więc „ile AI?", lecz „czy w finalnym wyrazie kodu widać udokumentowane, swobodne wybory człowieka" — a to jest dokładnie praktyczny test, o którym wcześniej mówiliśmy.

6. Jak wykazać twórczy wkład człowieka (dowody)

Ochrona powstaje z chwilą ustalenia utworu i nie trzeba jej rejestrować. W sporze o autorstwo albo naruszenie to jednak osoba, która powołuje się na prawa autorskie do kodu, musi wykazać, że kod jest utworem, a jego twórcą jest człowiek, a nie AI. Dowody najlepiej zbierać na bieżąco i unikać ich „odtwarzania" po fakcie.

A. System kontroli wersji (Git). Historia commitów (daty, autor) pokazuje chronologię i autorstwo fragmentów; diffy dowodzą, że finalny kod istotnie odbiega od pierwotnego outputu AI; opisy commitów („refactor modułu X", „replace AI-generated loop with custom algorithm") to ślad świadomych decyzji.

B. Logi sesji z AI. Eksport historii z Copilota/Cursora/ChatGPT to bezpośredni dowód, co zaproponowała AI, a co człowiek zmienił, odrzucił lub połączył.

C. Dokumentacja „przed kodem". Notatki, ADR (Architecture Decision Records), diagramy, specyfikacja sporządzone przed generowaniem kodu. Daje to niezależną warstwę twórczości i pokazuje, że architekturę zaprojektował człowiek.

D. Prompty i ich wersje. Sam prompt zwykle nie wystarczy do wykazania autorstwa kodu, ale jego wersje pokazują tok decyzji, zakres kontroli nad narzędziem i to, czy człowiek kierował sposobem wyrażenia, czy tylko zlecił uzyskanie funkcji.

E. Opinia biegłego. W sporze to jedyna rzetelna metoda ustalenia, jaka część kodu pochodzi wyłącznie z modelu, a jaka niesie indywidualny wkład (SN dopuszcza opinię biegłego w kwestiach wymagających wiadomości specjalnych, V CSK 180/13).

F. Domniemanie autorstwa (art. 8 ust. 2 pr. aut.). Jeśli jesteś oznaczony jako autor (nagłówki plików, dokumentacja, dane commitów), działa wzruszalne domniemanie, a ciężar jego obalenia przechodzi na drugą stronę. Dobry standard: jawnie oznaczaj udział AI (np. „initial implementation generated using [narzędzie], refactored and adapted by [imię nazwisko]"). Wzmacnia to pozycję dowodową, bo pozwala wskazać, które elementy podlegają ochronie.

Wiąże się to z przeniesieniem praw autorskich do kodu źródłowego z sekcji 3: przenieść można tylko istniejące autorskie prawa majątkowe, a jeżeli dany fragment nie jest utworem, prawa do niego nie powstały. Klauzula o przeniesieniu praw i obowiązek dokumentowania pracy z AI powinny więc iść w parze w każdej umowie z deweloperem (także B2B); standardowe wzory tego nie uwzględniają.

Zob. też: Umowa wdrożeniowa IT a AI Act · Umowa NDA w IT · commercial-legal-pl — asystent AI do umów · legal-cite-pl — weryfikacja przepisów