W projektach technologicznych własność intelektualna często staje się problemem dopiero wtedy, gdy produkt zaczyna mieć realną wartość. Wtedy okazuje się, że umowy nie odpowiadają na pytanie, kto może rozwijać kod, wykorzystywać know-how, używać danych, przenieść projekt do innego dostawcy albo komercjalizować rezultat.
Pięć miejsc, w których najczęściej powstaje ryzyko
- Brak jasnego zakresu praw. Umowa mówi o „przekazaniu projektu”, ale nie rozstrzyga pól eksploatacji, modyfikacji, sublicencji, kodu źródłowego i materiałów pomocniczych.
- Nieuregulowane wkłady zespołu. Pracownicy, kontraktorzy i podwykonawcy tworzą elementy produktu, ale dokumentacja przeniesienia praw jest rozproszona albo niepełna.
- Open source bez procesu. Organizacja korzysta z komponentów open source, ale nie ma zasad oceny licencji, zgodności i obowiązków informacyjnych.
- Dane i know-how traktowane jak zwykły załącznik. W projektach AI i data-driven dane, modele, metody, prompt engineering i dokumentacja procesu mogą być kluczowym aktywem.
- Brak scenariusza wyjścia. Dopiero przy zmianie dostawcy pojawia się pytanie, co można przenieść, co wymaga licencji, a co pozostaje po stronie poprzedniego wykonawcy.
Co zrobić praktycznie
Warto zacząć od mapy aktywów: kod, dokumentacja, znaki towarowe, bazy danych, materiały marketingowe, know-how, dane treningowe, modele, integracje i licencje zewnętrzne. Dopiero potem można sensownie ustalić, co ma zostać przeniesione, co licencjonowane, a co jedynie udostępnione na czas współpracy.
Dobre uregulowanie IP nie musi komplikować projektu. Przeciwnie, zmniejsza tarcie przy wdrożeniu, audycie, inwestycji, sprzedaży produktu lub zmianie dostawcy.
Materiał ma charakter informacyjny i nie stanowi porady prawnej. Strategia IP powinna być dopasowana do modelu produktu, jurysdykcji, zespołu i sposobu komercjalizacji.