Tworzenie oprogramowania z wykorzystaniem sztucznej inteligencji – do kogo należy kod?

Dlaczego własność kodu w erze AI ma kluczowe znaczenie?

W ostatnich miesiącach 2025 roku i na początku 2026 roku jesteśmy świadkami wielu spraw sądowych w USA (na przykład Doe v. GitHub) i w Europie, które dotyczą autorstwa wytworów generowanych przez AI. W Czechach na przykład Sąd Miejski w Pradze (Městský soud v Praze) orzekł już, że obraz wygenerowany przez AI nie jest chroniony prawem autorskim bez możliwej do wykazania twórczej działalności człowieka. To nie jest tylko prawnicza abstrakcja. Jeśli nie wiedzą Państwo, do kogo należy Państwa kod, czekają Państwa problemy, które obniżą wartość firmy, zablokują inwestycję lub postawią Państwa w pozycji obronnej w sporze sądowym.

Własność kodu ma zasadnicze znaczenie w kilku kluczowych obszarach. Przy sprzedaży lub połączeniu spółek kupujący poprosi o zapewnienia, że rzeczywiście są Państwo właścicielem kodu. Jeśli nie mogą Państwo wykazać czystego tytułu prawnego, transakcja zostanie zablokowana.

W zobowiązaniach umownych wobec klientów obiecują Państwo wyłączność kodu; jeśli nie są Państwo jego właścicielem, naruszają Państwo umowę i ryzykują proces. Przy licencjonowaniu bez jasnej własności nie mogą Państwo udostępniać kodu osobom trzecim ani dochodzić swoich praw. Wreszcie, bez własności nie mogą Państwo skutecznie chronić przewagi konkurencyjnej jako tajemnicy handlowej, a inwestycja w rozwój może okazać się trudna do spieniężenia.

Dlatego prawnicy kancelarii ARROWS postrzegają własność kodu generowanego przez AI jako jedną z najczęstszych luk prawnych, która ujawnia się w najgorszych możliwych momentach – gdy kupujący nie chce nabyć Państwa firmy, gdy pojawia się żądanie regulatora lub w sporze sądowym.

Jak w praktyce prawnej ustala się własność kodu generowanego przez AI?

W USA, podobnie jak w Czechach i pozostałych państwach Unii Europejskiej, od podstawowych aktów prawnych (Copyright Act z 1976 roku w USA, czeska ustawa o prawie autorskim (ustawa nr 121/2000 Sb., dalej „AZ”) w Czechach) obowiązuje podstawowa zasada: prawu autorskiemu podlegają wyłącznie utwory stworzone przez człowieka.

W marcu 2025 roku Sąd Apelacyjny dla Okręgu DC (USA) ponownie potwierdził, że sztuczna inteligencja nie może być autorem. Nawet jeśli ktoś wydał AI polecenie – samo promptowanie bez dalszej pracy twórczej nie wystarcza, by uznać człowieka za autora.

Oznacza to bardzo konkretnie: kod, który AI wygeneruje bez znaczącej twórczej interakcji człowieka, nie jest chroniony prawem autorskim. Bez ochrony prawnoautorskiej może z niego korzystać praktycznie każdy. Nie pomoże Państwu w ochronie przewagi konkurencyjnej, nie da się go skutecznie egzekwować, a przy sprzedaży firmy usłyszą Państwo po prostu: „to nie jest nasze”.

Czeska praktyka prawna kieruje się w tym zakresie tymi samymi zasadami co USA i Unia Europejska. U nas kwestia ta nie była jeszcze masowo rozpatrywana przez sądy (w przeciwieństwie do USA), ale orzecznictwo innych państw UE i interpretacje czeskich prawników wskazują, że czeskie sądy postąpią tak samo: bez twórczej pracy człowieka nie ma ochrony prawnoautorskiej.

Co uznaje się za wystarczającą twórczą pracę człowieka?

Prawnicy kancelarii ARROWS zajmują się tu konkretnymi przypadkami z praktyki i wiedzą, że granica między „prostym promptem” a „twórczym udziałem” często zaciera się w sądach. Za pracę twórczą powszechnie uznaje się:

• Wielokrotne, ukierunkowane promptowanie – nie jedno proste polecenie typu „stwórz logowanie”, lecz serię dopracowanych instrukcji ze szczegółowymi wymaganiami.
• Edycję, modyfikację i ulepszanie wyników AI – programista celowo zmienia części kodu, przebudowuje logikę, poprawia błędy.
• Faktyczne decyzje dotyczące architektury i struktury kodu – człowiek sam wybiera, jak będzie zbudowana całość, jakich wzorców użyje i jak zintegruje fragmenty wygenerowane przez AI.
• Integrację części wygenerowanej przez AI z całym systemem z własnym wkładem intelektualnym – nie chodzi tylko o „sklejenie” wyników AI, lecz o podejście systemowe, w którym kod wygenerowany przez AI jest częścią szerszej twórczej wizji.

Przykład praktyczny: jeśli programista wpisze do AI prompt „stwórz formularz logowania” i weźmie kod w takiej postaci, w jakiej zwróciła go AI, bez dalszych zmian, i po prostu skopiuje go do projektu – to nie wystarcza do ochrony prawnoautorskiej.

Jeśli jednak określi szczegółowe wymagania bezpieczeństwa, iteracyjnie poprawia błędy, przepisuje kluczowe części w celu integracji z resztą aplikacji i tworzy dokumentację działania, ma większą szansę na uznanie twórczego autorstwa.

Problem polega na tym, że granica jest niepewna. Nawet doświadczeni prawnicy nie zawsze są w sporach sądowych pewni, gdzie dokładnie zaczyna się „praca twórcza”, a gdzie kończy „zwykłe zastosowanie”. Dlatego prawnicy z ARROWS zalecają, aby zawsze, gdy kod ma istotne znaczenie dla Państwa firmy, dokumentować wszystko, co się działo – logi promptów, wersje plików, wprowadzone zmiany, wszystko. Taka dokumentacja stanie się Państwa najlepszym dowodem w sądzie.

Własność kodu w stosunku pracy

W stosunku pracy zasada jest jednoznaczna i wynika wprost z ustawy o prawie autorskim: autorskie prawa majątkowe do utworu stworzonego przez pracownika w ramach wykonywania obowiązków pracowniczych wykonuje pracodawca we własnym imieniu i na własny rachunek (czeska ustawa o prawie autorskim nr 121/2000 Sb., § 58 ust. 1 AZ), o ile umowa nie stanowi inaczej.

Dotyczy to kodu bez względu na to, czy został wygenerowany przez człowieka, częściowo przez AI, czy w całości przez AI. Warunek jest jednak krytyczny: chociaż prawa wykonuje pracodawca z mocy ustawy, wysoce zalecane jest, aby wynikało to z umowy o pracę lub wewnętrznego regulaminu firmy, i to w sposób wystarczająco jasny i konkretny.

Spółki, które uważały, że „to oczywiste”, i nie zapisały tego konkretnie, później przekonały się, że pracownik ma pewne argumenty, zwłaszcza gdy wnosi pozew, twierdząc, że „AI wygenerowała kod, a ja tylko kliknąłem”. Jeśli umowa nic nie mówi lub jest niejasna („pracownik uczestniczy w projektach”), może dojść do sporu.

Forma pisemna jest tu kluczowa. Należy:

• Mieć pisemną umowę o pracę (lub przynajmniej aneks), która wyraźnie stanowi, że cała własność intelektualna stworzona w ramach obowiązków pracowniczych należy do pracodawcy.
• Wprowadzić wewnętrzną politykę lub regulamin dotyczący AI, który określa, jak narzędzia AI mogą i nie mogą być używane, oraz że wszystkie wyniki należą do firmy.
• Dokumentować, z jakich narzędzi AI pracownicy korzystali w ramach projektu i w jaki sposób, a zwłaszcza jaki był twórczy wkład człowieka.

Prawnicy kancelarii ARROWS regularnie pomagają firmom w przygotowaniu takich regulaminów i w przeglądzie umów o pracę. To nie jest tylko akademickie ćwiczenie – to ochrona, która okaże się istotna w razie sporu, konfliktu z pracownikiem lub kontroli przez osoby trzecie (inwestora, kupującego).

Własność kodu w przypadku niezależnych dostawców i zleceniobiorców

Tu sytuacja się komplikuje i dla wielu przedsiębiorców jest zaskakująca.

W USA, w Czechach i w UE obowiązuje następująca podstawowa zasada: jeśli zatrudnią Państwo niezależnego programistę, agencję lub zleceniobiorcę, a oni wygenerują dla Państwa kod, to z mocy prawa kod należy do nich, chyba że pisemna umowa wyraźnie stanowi inaczej. To nie tak jak w przypadku pracownika. Niezależny zleceniobiorca „pracuje na własny rachunek” – nawet jeśli Państwo mu płacą, z prawnego punktu widzenia tworzy dla siebie, a nie dla Państwa.

Aby własność przeszła na Państwa, pisemna umowa musi zawierać:

• Wyraźne przeniesienie praw – po angielsku nazywa się to „assignment of rights”. Po polsku mogłoby to brzmieć na przykład: „Wykonawca przenosi na Zamawiającego wszelkie prawa autorskie, w tym wyłączne prawa do korzystania, zwielokrotniania, rozpowszechniania i modyfikacji, do całego kodu stworzonego w zakresie niniejszej umowy o dzieło, ze skutkiem natychmiastowym i w pełnym zakresie.”
• Musi być podpisana przez obie strony. Ustne porozumienie, e-mail czy słowna obietnica nie są prawnie wiążące. Musi to być pisemny dokument z podpisami.
• Musi chodzić o natychmiastowe przeniesienie praw – sformułowanie musi brzmieć „Wykonawca przenosi” lub „Wykonawca niniejszym przekazuje”, a nie „Wykonawca wyrazi zgodę na przeniesienie”.

Jaki problem pojawia się najczęściej? Firma zatrudnia agencję, w umowie albo w ogóle nie ma nic o własności, albo znajduje się tam niejasne zdanie o „licencji”, a potem okazuje się, że:

• Agencja wykorzystuje kod jako wzór w kolejnych projektach i sprzedaje go konkurentom.
• Agencja „pożycza” kod konkurencji, ponieważ faktycznie jest jego właścicielem.
• Przy sprzedaży firmy pojawia się kupujący, który przeprowadził badanie (due diligence), a jego prawnik stwierdza, że Państwa oprogramowanie w rzeczywistości nie jest Państwa własnością – mają Państwo jedynie licencję, czyli ograniczone prawa.
• Transakcja zostaje zablokowana, cena spada o 20–50% (lub więcej) albo umowa zostaje całkowicie zerwana. To typowy prawny powód, dla którego transakcji w ogóle nie da się zrealizować.

To poważna sprawa, a prawnicy kancelarii ARROWS spotykają się z podobnymi przypadkami niepotrzebnie często. Są gotowi rozwiązywać takie sytuacje – zarówno prewencyjnie (prawidłowe sformułowanie umów na początku), jak i poprzez naprawę, jeśli problem już wystąpił.

Jakie ryzyka wynikają z nieuregulowanej własności kodu?

Sprawa nie jest wyłącznie teoretyczna. W praktyce przedsiębiorcy unikają kwestii własności, a potem problem pojawia się w najgorszym możliwym momencie.

Ryzyko 1: Zablokowanie sprzedaży firmy lub finansowania

Gdy przygotowują się Państwo do sprzedaży firmy, wejścia inwestora lub połączenia z inną firmą, pierwszą rzeczą, którą sprawdzi kupujący lub inwestor, jest: „Czy rzeczywiście są Państwo właścicielem całego kodu stanowiącego rdzeń Państwa firmy?”

Jeśli odpowiedź brzmi: „Nie jesteśmy pewni, używamy kodu generowanego przez AI, nie jest jasne, jaka część należy do nas, a jaka do dostawcy” lub „Mamy licencję od agencji, ale nigdy nie uregulowaliśmy własności”, due diligence (badanie prawne) zostaje wstrzymane.

Kupujący będzie się obawiał, że pewnego dnia konkurencja zakaże mu korzystania z kodu lub agencja go odbierze. Transakcja się przedłuży, cena spadnie o 20–50% (lub więcej) albo umowa zostanie całkowicie zerwana. To typowy prawny powód, dla którego transakcji w ogóle nie da się zrealizować.

Ryzyko 2: Spory o prawa autorskie i nieoczekiwane pozwy

Jeśli Państwa kod jest podobny do kodu innego przedsiębiorcy, a nie mogą Państwo wykazać, że stworzyli go Państwo własną pracą twórczą (szczególnie w przypadku AI), mogą Państwo zostać pozwani za naruszenie praw autorskich.

Osoba, która twierdzi, że jest właścicielem kodu, i nie jest z Państwa zadowolona, pozwie Państwa za „nieuprawnione korzystanie”. Jednocześnie, jeśli AI, z której Państwo korzystają, trenowała swój model na danych osób trzecich bez ich zgody, mogą Państwo znaleźć się w pozycji pozwanego w sprawie o naruszenie praw autorskich osób trzecich.

Tak było w sprawie Getty Images i New York Times przeciwko OpenAI i innym firmom AI. Jeśli Państwa oprogramowanie zawiera fragmenty, które AI skopiowała z ich materiałów, pozew może trafić także do Państwa.

Ryzyka specyficzne dla kodu generowanego przez AI:

• Luki w zabezpieczeniach: AI jest trenowana na danych publicznych, które mogą zawierać stary, podatny kod i przestarzałe praktyki bezpieczeństwa. AI nauczyła się tych wzorców i czasem je powtarza. Jeśli zintegrują Państwo kod wygenerowany przez AI bez gruntownej kontroli bezpieczeństwa, mogą Państwo wpuścić do aplikacji SQL injection, XSS lub inne podatności.
• Naruszenie licencji: AI może wygenerować fragment kodu objęty licencją GPL lub AGPL (licencje copyleft), a Państwo zintegrują go z własnościowym oprogramowaniem, nie wiedząc, że się tam znajduje. Później wychodzi to na jaw i są Państwo zobowiązani upublicznić cały kod – to katastrofa dla przewagi konkurencyjnej.
• Nieznane pochodzenie: Jeśli AI wygeneruje kod przypominający cudzy, a później to wyjdzie na jaw i ta osoba uzna go za swój, mogą Państwo ściągnąć na siebie spór patentowy lub autorski. Wiadomo, że narzędzia AI czasem „halucynują” – generują fragmenty przypominające kod, który widziały podczas treningu.

Ryzyka wynikające z niewystarczającej dokumentacji:

• Nie mogą Państwo udowodnić, że mieli twórczy udział w kodzie – więc prawo autorskie go nie obejmuje.
• Nie mogą Państwo wykazać, że pracownik stworzył go w ramach obowiązków służbowych – pracownik może wtedy uważać, że kod należy do niego.
• Nie mogą Państwo wykluczyć naruszenia licencji open source – podczas kontroli regulatora lub w sądzie nie będzie to dobrze wyglądać.

Najczęstsze ryzyka i jak pomaga ARROWS

Ramy prawne w UE, w Czechach i nowe regulacje

Czechy kierują się przede wszystkim ustawą o prawie autorskim (AZ), która chroni utwory stworzone przez człowieka. Wykładnia prawa opiera się na Dyrektywie UE 2019/790 (dyrektywie w sprawie prawa autorskiego na jednolitym rynku cyfrowym), która harmonizuje prawo autorskie w UE.

Ponadto do gry wchodzi unijny AI Act (Rozporządzenie UE 2024/1689), który wszedł w życie 1 sierpnia 2024 i jest stopniowo wdrażany do końca 2026 roku.

Co oznacza unijny AI Act dla Państwa?

AI Act klasyfikuje systemy AI w kategoriach według poziomu ryzyka. Jeśli tworzą Państwo z pomocą AI oprogramowanie należące do kategorii „wysokiego ryzyka” (na przykład decyzje w zatrudnieniu, dostęp do usług lub systemy stosowane w infrastrukturze krytycznej), muszą Państwo spełniać rygorystyczne obowiązki:

• Dokumentacja – muszą Państwo prowadzić szczegółowy zapis tego, jak działa AI, jakie ma ograniczenia i jak została opracowana.
• Testowanie i walidacja – muszą Państwo przetestować AI i sprawdzić, czy robi to, co powinna, oraz czy jest niezawodna i dokładna.
• Rejestrowanie zdarzeń (audit trail) – muszą Państwo prowadzić zapis tego, jak AI pracuje i jakie podejmuje decyzje, aby można było wstecznie zweryfikować jej działanie.
• Nadzór człowieka (human oversight) – muszą Państwo zapewnić rzeczywisty nadzór człowieka nad decyzjami AI, tak aby człowiek mógł interweniować i korygować decyzje.
• Cyberbezpieczeństwo – muszą Państwo zapewnić, aby AI była bezpieczna i odporna na ataki, manipulację i nieuprawniony dostęp.

Obowiązki są wprowadzane stopniowo i w pełni zaczną obowiązywać w odniesieniu do systemów AI wysokiego ryzyka od sierpnia 2026 roku. Jeśli tworzone przez Państwa oprogramowanie nie jest klasyfikowane jako „AI wysokiego ryzyka”, mają Państwo lżejsze obowiązki (np. przejrzystość), ale należy sprawdzić, do jakiej kategorii należy Państwa system.

Oczekuje się także rewizji obecnej dyrektywy w sprawie odpowiedzialności za produkty wadliwe (Product Liability Directive), która będzie miała istotny wpływ na odpowiedzialność za szkody wyrządzone przez systemy AI. Nowo proponowana regulacja przewiduje surowszą odpowiedzialność za AI.

Jeśli AI wygeneruje w kodzie lukę w zabezpieczeniach, która wyrządzi szkodę (np. haker dostanie się przez Państwa aplikację do danych), mogą Państwo ponosić odpowiedzialność, nawet jeśli wszystko „przemyśleli” i zrobili to, co było rozsądne. Przewiduje się wprowadzenie „strict liability” – odpowiedzialności niezależnej od winy. Dlatego audyt i dokumentacja kodu generowanego przez AI są bardziej niezbędne niż kiedykolwiek.

W Czechach nie ma jeszcze szczególnych przepisów dotyczących oprogramowania generowanego przez AI (jak w niektórych innych krajach), ale praktyka sądowa się kształtuje. Prawnicy kancelarii ARROWS śledzą rozwój orzecznictwa i są gotowi doradzić Państwu zgodnie z najnowszą wykładnią prawa.

Praktyczne kroki, które muszą Państwo podjąć już teraz

Jeśli korzystają Państwo z AI przy tworzeniu oprogramowania, powinni Państwo niezwłocznie zadać sobie pytania:

Krok 1: Czy mają Państwo dokumentację potwierdzającą Państwa twórczy udział w kodzie generowanym przez AI?

Jeśli nie, proszę zacząć natychmiast. Bez dokumentacji nie będą Państwo w stanie później udowodnić twórczego autorstwa.

Należy prowadzić logi promptów ze znacznikami czasu, wersje kodu pokazujące iteracje i zmiany, dokumenty projektowe i tworzone schematy. Proszę zacząć od dziś. Będzie to Państwa kosztować kilka godzin tygodniowo, ale za rok oszczędzi mnóstwo problemów.

Krok 2: Czy mają Państwo ze wszystkimi pracownikami i zleceniobiorcami umowy, które jasno stanowią, że cały kod należy do Państwa?

Jeśli nie, to krytyczny brak. Proszę zwrócić się do prawników kancelarii ARROWS, aby zweryfikowali i dostosowali Państwa umowy.

Nie chodzi tylko o to, aby znalazło się tam zdanie o prawie autorskim. Należy zadbać, aby było ono sformułowane jasno i konkretnie dla Państwa przypadku. W przypadku pracowników: klauzula w umowie o pracę musi być konkretna i odwoływać się do § 58 AZ. W przypadku zleceniobiorców: aneks lub nowy kontrakt z wyraźnym przeniesieniem praw.

Krok 3: Czy korzystają Państwo z komponentów open source (bibliotek, frameworków)?

Czy wiedzą Państwo, na jakich licencjach są udostępnione? Jeśli nie, ryzyko jest duże. Audyt licencyjny należy przeprowadzić jak najszybciej. Jeśli w Państwa oprogramowaniu znajduje się kod na licencji GPL, a Państwo uważają, że wszystko jest własnościowe, mają Państwo problem. Pomóc w tym mogą prawnicy z ARROWS.

Krok 4: Czy mają Państwo wewnętrzną politykę dotyczącą AI?

Czy wiedzą Państwo, kto może korzystać z jakich narzędzi AI? Co wolno, a czego nie? Jeśli nie, należy ją wprowadzić.

Niewłaściwe korzystanie z AI (np. pracownik przesyła dane zastrzeżone do ChatGPT) może oznaczać problem bezpieczeństwa lub problem prawny, który trudno będzie wytłumaczyć podczas kontroli lub w sądzie. Prawnicy z ARROWS pomogą Państwu w opracowaniu takich regulaminów.

Krok 5: Umowy z nowymi dostawcami

Jeśli zatrudniają Państwo agencję lub programistę, proszę upewnić się, że umowa zawiera wyraźne przeniesienie wszystkich praw do całego kodu, w tym kodu generowanego przez AI. Proszę powierzyć sformułowanie tego prawnikom z ARROWS, aby było to prawnie bezsporne i aby jasno wskazywało, kto jest autorem, kto właścicielem oraz że prawa przechodzą na Państwa bezwarunkowo.

Prawnicy z ARROWS pomogą Państwu we wszystkich pięciu krokach. To nie jest tylko lista do „odhaczenia” – to strategiczne podejście, które chroni Państwa długoterminowo.

Podsumowanie końcowe

Własność kodu w erze AI to nie tylko kwestia prawna – to kwestia, która decyduje o tym, czy będą Państwo mieli wyłączność na swoje oprogramowanie, czy będą mogli je sprzedać, czy nie przejmie go konkurent i czy przy sprzedaży firmy kupujący nie powie: „nie, dziękuję, to nie jest Państwa kod”.

Kluczowy wniosek jest następujący: samo wpisanie promptu do AI nie wystarcza do uzyskania ochrony prawnoautorskiej. Musi istnieć udokumentowana twórcza praca człowieka. Oznacza to, że firmy korzystające z AI bez jasnej dokumentacji i jasnych umów narażają się na ogromne ryzyko. Gdy przyjrzy się temu inwestor, kupujący lub sąd, stwierdzi, że „sprawy nie są jasne”, a transakcja zostanie wstrzymana lub jej cena spadnie.

Drugi wniosek: unijny AI Act i nowo proponowana dyrektywa w sprawie odpowiedzialności za produkty wprowadzają surowszą odpowiedzialność. Jeśli kod wygenerowany przez AI spowoduje incydent bezpieczeństwa lub naruszenie prawa, nie będą Państwo mogli tłumaczyć się, że „zrobiła to AI”. Odpowiadają Państwo. Odpowiadają Państwo za jakość, bezpieczeństwo i zgodność licencyjną.

Trzeci wniosek: własność reguluje się na piśmie. Bez pisemnej umowy z jasnym przeniesieniem praw (po angielsku „assignment”) nie jest jasne, do kogo należy kod. Rozmowy przez e-mail czy „poleganie na tym, że będzie to oczywiste” nie wystarczą.

Jeśli nie chcą Państwo ryzykować poważnych problemów prawnych, finansowych i biznesowych – a proszę wierzyć, że to się zdarza – należy działać teraz. Prawnicy kancelarii ARROWS mogą zapewnić kompleksowe rozwiązanie:

• Przegląd Państwa obecnych umów i identyfikację luk.
• Aktualizację umów z pracownikami i dostawcami.
• Przygotowanie polityki AI i audyt compliance.
• Opinie prawne w szczegółowych kwestiach.
• Reprezentację w razie sporu.

Zachęcamy do kontaktu z kancelarią ARROWS pod adresem konsultacja@arws.cz. Chętnie pomożemy Państwu w kwestii własności kodu i w uniknięciu podobnych problemów w przyszłości. Dzięki sieci ARROWS International kancelaria ARROWS zajmuje się także sprawami z elementem międzynarodowym, jeśli będzie to istotne w Państwa sytuacji.