4 kwestie, które ustal w umowie z software house

Umowa z software house’em powinna jasno opisywać zakres i harmonogram prac, zasady odbioru, prawa do programu, przetwarzanie danych oraz wykorzystanie narzędzi AI. Nie każda współpraca jest umową o dzieło: ten model dotyczy ustalonego rezultatu, a umowa o świadczenie usług może regulować wykonywanie określonych czynności w czasie. Dlatego odpowiedź na pytanie, co powinna zawierać umowa z software house’em, zależy również od modelu współpracy. Ustal te zasady przed rozpoczęciem projektu, aby dopasować zapisy do jego zakresu i uniknąć niejasności przy zmianach, odbiorach czy zakończeniu współpracy. W tym artykule poznasz cztery obszary wymagające szczególnej uwagi: dane osobowe, prawa do kodu, terminy etapów oraz programowanie z użyciem AI.

Najważniejsze wnioski

• Ustal zasady przetwarzania danych osobowych, jeśli wykonawca będzie korzystać z nich w twoim imieniu.
• Opisz w umowie, komu przysługują prawa do programu i na jakich zasadach możesz go rozwijać.
• Podziel prace na etapy, określ terminy, sposób odbioru i reguły wprowadzania zmian.
• Ureguluj wykorzystanie narzędzi AI oraz praw do kodu powstałego przy ich użyciu.

Spis treści

• Czy umowa wdrożeniowa musi zawierać umowę powierzenia przetwarzania danych?
• Czy faktura przenosi prawa do programu?
• Harmonogram prac i elastyczne terminy etapów
• Własność intelektualna i prawa do kodu tworzonego z użyciem AI
• Jak Internet Stars może pomóc w realizacji projektu?

Czy umowa wdrożeniowa musi zawierać umowę powierzenia przetwarzania danych?

Umowa wdrożeniowa nie zawsze wymaga powierzenia danych. Dołącz je, gdy wykonawca przetwarza dane osobowe w twoim imieniu, na przykład testuje aplikację na danych klientów. Warunki takiego przetwarzania powinny odpowiadać art. 28 RODO. Umowa powierzenia opisuje, jakie czynności wykonawca może wykonywać na danych podczas realizacji projektu.

Najpierw opisz przedmiot umowy: jaki system powstanie, jakie funkcje obejmie wdrożenie i jaki rezultat ma zostać przekazany. Przy dużym projekcie dodaj ogólny opis, a szczegóły umieść w załącznikach technicznych. Wskaż wymagania, integracje, środowiska i dokumentację. Takie zapisy porządkują zakres projektu oraz obowiązki obu stron.

Połącz opis zakresu z harmonogramem etapów i sposobem odbioru. Jeśli pracujecie w metodyce Agile, zapisz, że obie strony wybrały ten tryb, i określ, jak zatwierdzacie kolejne zadania. Ustal osoby kontaktowe, sposób raportowania postępów oraz procedurę wprowadzania zmian. Dzięki temu dodatkowe funkcje nie trafią do realizacji bez uzgodnienia.

Wymień też dostęp do danych, repozytoriów i narzędzi potrzebnych do korzystania z systemu. Oddziel kod dedykowany, biblioteki wykonawcy, komponenty open source i dokumentację. Określ prawa majątkowe albo licencje do każdego elementu. W Polsce odpowiedzialność za niewykonanie lub nienależyte wykonanie zobowiązania reguluje art. 471 Kodeksu cywilnego, według Sejmu Rzeczypospolitej Polskiej.

Jeśli projekt obejmuje sztuczną inteligencję, rozdziel obowiązki dotyczące zgodności między zamawiającym i wykonawcą. Unia Europejska wskazuje, że AI Act przewiduje za pozostałe naruszenia, na przykład dotyczące systemów wysokiego ryzyka, karę maksymalną do 15 000 000 EUR lub 3% globalnego obrotu. Zapisz, kto odpowiada za konkretne działania związane z systemem.

Ureguluj wprost gwarancję, rękojmię, SLA i wsparcie po wdrożeniu. Określ zakres zgłoszeń, czasy reakcji i naprawy oraz godziny obsługi. Wskaż, które błędy obejmuje gwarancja i jak zgłaszać usterki. SLA opisuje poziom usług, a umowa powinna również ustalać zasady utrzymania systemu po odbiorze.

Czy faktura przenosi prawa do programu?

Nie. Faktura dokumentuje rozliczenie, ale sama nie przenosi autorskich praw majątkowych do programu. Współpraca B2B z programistą również nie przenosi ich automatycznie. Potrzebujesz wyraźnego postanowienia umownego, które wskazuje przeniesienie praw oraz jego zakres.

W Polsce przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności. Umowa powinna wymieniać pola eksploatacji, czyli sposoby korzystania z oprogramowania. Określa je art. 41 ust. 2 ustawy o prawie autorskim. Zapisz osobno, czy możesz uruchamiać program, udostępniać go użytkownikom, modyfikować i rozwijać.

Zwykły skan podpisanego dokumentu ani podpis elektroniczny niekwalifikowany nie spełniają wymogu formy pisemnej. Kwalifikowany podpis elektroniczny jest jej równoważny. Zadbaj także o jednoznaczne określenie momentu przeniesienia praw, na przykład po odbiorze programu i zapłacie wynagrodzenia. Sama faktura nie zastępuje takiego zapisu ani podpisu pod umową.

Rozdziel kod dedykowany, wcześniejsze narzędzia wykonawcy, biblioteki open source i dokumentację. Umowa może przenieść prawa do nowego kodu, a do własnych elementów wykonawcy przyznać licencję. Wskaż, czy licencja jest wyłączna, jak długo obowiązuje i czy pozwala na modyfikacje. Licencja wyłączna wymaga formy pisemnej.

Prawa autorskie osobiste, w tym prawo do autorstwa, pozostają przy twórcy i nie podlegają przeniesieniu. Umowa może zawierać klauzulę non-assertion, czyli zobowiązanie wykonawcy, że w zakresie potrzebnym do korzystania z programu nie będzie wykonywać tych praw wobec zamawiającego. Umowa ramowa powinna stosować te zasady również do kolejnych zleceń. Przy tworzeniu aplikacji dedykowanej zadbaj o jasny podział praw już w umowie.

Przygotowanie aplikacji dedykowanej zaczyna się od ustalenia zakresu prac i praw do rezultatów.

Harmonogram prac i elastyczne terminy etapów

Wpisz do umowy etapy projektu, ich rezultaty i warunki rozpoczęcia. Sam termin końcowy nie pokazuje, kiedy otrzymasz projekt graficzny, integrację czy wersję testową. Przy każdym kamieniu milowym opisz, co wykonawca przekaże i jak zaakceptujesz rezultat. Dzięki temu harmonogram staje się planem działania, a nie ogólną deklaracją.

Powiąż terminy z zależnościami po obu stronach. Jeśli wykonawca potrzebuje dostępu do systemu albo danych testowych, wskaż, kto je dostarcza i kiedy. Możesz uzgodnić, że etap przypada 7 dni roboczych od zatwierdzenia danych prac przez klienta. Zapisz też, jak przesunięcie takiego terminu wpływa na kolejne etapy.

Ustal częstotliwość raportowania, osoby kontaktowe i sposób zgłaszania opóźnień. W modelu Agile harmonogram może obejmować krótsze cykle, a zakres kolejnych zadań może wynikać z ustaleń zespołu. Zapisz, jak strony zatwierdzają zmiany i kiedy potrzebny jest aneks. Dzięki temu nowe funkcje nie przesuną po cichu terminu wdrożenia.

Połącz kamienie milowe z odbiorami. Opisz kryteria odbioru, czas na testy i procedurę zgłaszania błędów. Określ też, jak strony postępują w przypadku prac dodatkowych. Jeśli strony przewidują kary umowne za opóźnienie, wskaż, których terminów dotyczą i na jakich warunkach są naliczane.

Dodaj procedurę aktualizacji harmonogramu na wypadek zmiany wymagań lub zależności. Wskaż, kto zatwierdza nowy plan i jak strony dokumentują decyzję. Taki zapis pomaga odróżnić opóźnienie wykonawcy od oczekiwania na materiały lub akceptację po stronie klienta. Dopasuj terminy do rzeczywistego przebiegu prac, zamiast wpisywać sztywne daty bez określenia warunków.

Przy planowaniu terminów uwzględnij ich powiązanie z zakresem prac i sposobem odbioru. Umowa powinna jasno opisywać zakres prac, etapy projektu, zasady odbioru, procedurę akceptacji prac dodatkowych i sposób dokumentowania ustaleń. Zapisz również zasady komunikacji, aby ustalenia dotyczące etapów były spójne. Umowa z software house’em powinna określać zakres prac, harmonogram, zasady odbioru, procedurę zmian, odpowiedzialność, prawa autorskie, dostęp do kodu, poufność, dane, SLA, utrzymanie i zasady zakończenia współpracy.

Możesz określić termin na zgłoszenie uwag, na przykład 14 dni od przekazania rezultatu. Warto przy tym powiązać odbiór z ustalonymi kryteriami, tak aby było jasne, jaki rezultat stanowi podstawę akceptacji. Brak jasnych zasad odbioru prac w projekcie IT może prowadzić do sporu o to, czy projekt został wykonany. Ustal zatem kryteria odbioru oraz procedurę akceptacji rezultatów, a także sposób zgłaszania prac dodatkowych. Umowa może określać również warunki gwarancji i wsparcia, co pozwala uwzględnić je obok harmonogramu i odbiorów.

Własność intelektualna i prawa do kodu tworzonego z użyciem AI

Kod przygotowany z pomocą narzędzi AI wymaga równie precyzyjnych ustaleń jak pozostałe elementy projektu. Opisz, kto może korzystać z wygenerowanych fragmentów, kto je sprawdza i kto odpowiada za ich wdrożenie. Zapisz też, czy wykonawca ma ujawnić użyte narzędzia i wskazać części kodu, które powstały z ich pomocą.

Nie zakładaj, że zasada dotycząca pracowników rozstrzyga relację z każdym wykonawcą. Art. 74 ust. 3 prawa autorskiego dotyczy programów stworzonych przez pracowników w ramach obowiązków pracowniczych. Nie reguluje automatycznie umów B2B. Dlatego określ w umowie, czy prawa do kodu dedykowanego zostaną przeniesione, czy otrzymasz licencję.

Rozdziel rezultat projektu od zaplecza technologicznego software house’u. Wykonawca może zachować prawa do własnych bibliotek, narzędzi i know-how. Umowa powinna wskazywać te elementy oraz zakres licencji pozwalającej zamawiającemu korzystać z gotowego systemu. Ustal również, czy licencja umożliwia modyfikowanie i rozwijanie kodu po zakończeniu współpracy.

Poproś o wykaz wykorzystanych komponentów open source i ich licencji, również wtedy, gdy AI podpowiada fragment kodu. Dzięki temu można jasno rozdzielić kod dedykowany, biblioteki zewnętrzne i narzędzia wykonawcy. Ustal, kto ocenia zgodność użytych licencji z planowanym sposobem korzystania z programu.

Opisz też, jakie dane można przekazywać narzędziom AI podczas pracy. Na przykład zakaz wprowadzania danych osobowych lub poufnych ogranicza ryzyko ich niezamierzonego udostępnienia. Wskaż, kto zatwierdza wyjątki i jak dokumentuje się użycie narzędzi. Ustal te zasady przed rozpoczęciem prac, razem z regułami przeniesienia praw i dostępu do kodu.

Ustal zasady praw do kodu AI przed startem projektu. Porozmawiaj o założeniach projektu z użyciem AI.

Jak Internet Stars może pomóc w realizacji projektu?

Internet Stars tworzy aplikacje, sklepy internetowe i automatyzacje dla firm. Zwróć się do zespołu, gdy masz pomysł na system, sklep lub automatyzację i potrzebujesz wsparcia w realizacji prac programistycznych. Przed rozpoczęciem projektu ustal w umowie jego zakres i etapy, prawa do kodu oraz zasady współpracy.

Jeśli planujesz narzędzie dopasowane do procesów swojej firmy, aplikacje dedykowane pozwalają tworzyć rozwiązania odpowiadające określonym potrzebom. Gdy rozwijasz sprzedaż online, sklep internetowy może wspierać handel cyfrowy. Automatyzacje mogą ograniczyć ręczne wykonywanie powtarzalnych czynności. W każdym z tych projektów ustal, jakie funkcje mają powstać i jak zostaną przekazane.

Przed rozpoczęciem projektu przygotuj opis celu, użytkowników i procesów, które ma obsłużyć system. Internet Stars wykorzystuje te informacje przy realizacji aplikacji, sklepu internetowego lub automatyzacji. Omów również, jak projekt ma współpracować z używanymi już narzędziami. Takie ustalenia pomagają określić zakres prac, potrzebne integracje i oczekiwany rezultat do zapisania w dokumentach współpracy.

Jeśli twoi pracownicy będą korzystać z nowego rozwiązania, uwzględnij szkolenie w planie projektu, aby pomóc im poznać jego obsługę i wdrożyć je w codziennej pracy. Ma to znaczenie zwłaszcza wtedy, gdy system zmienia sposób obsługi zamówień, zadań lub danych. W ten sposób rozwój oprogramowania i przygotowanie zespołu tworzą spójny proces, zamiast dwóch osobnych działań.

Planujesz aplikację, sklep internetowy albo automatyzację? Skontaktuj się z Internet Stars i opowiedz o swoim projekcie.

Zamień założenia projektu w plan działania

Dobrze opisana współpraca nie kończy się na podpisaniu dokumentu. Traktuj go jako punkt odniesienia przy kolejnych decyzjach o rozwoju systemu. Gdy pojawia się nowa potrzeba, łatwiej ocenić, czy mieści się w pierwotnym celu, czy wymaga osobnych ustaleń. Dzięki temu projekt może się rozwijać bez utraty kontroli nad jego kierunkiem.

Jeśli nadal zastanawiasz się, co powinna zawierać umowa z software house’em, zacznij od przełożenia planu biznesowego na konkretne cele projektu. Internet Stars realizuje rozwiązania cyfrowe, wspierając firmy w rozwijaniu pomysłów na aplikacje, sklepy internetowe i automatyzacje. Rozmowa o projekcie pomoże uporządkować jego założenia i określić następny krok.

Porozmawiaj z Internet Stars o swoim projekcie i rusz z nim dalej.

Często zadawane pytania

Czy każda umowa z software house jest umową o dzieło?

Nie, nazwa umowy nie przesądza o jej rodzaju. Liczy się przede wszystkim to, do czego strony faktycznie się zobowiązały. Jeśli zakres obejmuje stałe prace rozwojowe, opisz ich rytm, raportowanie i zasady kończenia zleceń. Przy umowie dotyczącej jednego wdrożenia wyodrębnij rezultat, który będzie można odebrać.

Jakich punktów w umowie z software housem powinien oczekiwać klient?

To, co powinna zawierać umowa z software house’em, zależy od sposobu realizacji projektu. Ustal, kto po twojej stronie zatwierdza decyzje i może zmieniać priorytety. Dodaj procedurę eskalacji na wypadek, gdy osoby kontaktowe nie uzgodnią rozwiązania. Określ także, jak strony dokumentują ustalenia ze spotkań, aby zmiany zakresu nie opierały się na ustnych deklaracjach.

Czy faktura przenosi prawa do programu?

Nie. Traktuj fakturę jako dokument rozliczeniowy, a nie dowód pełnego łańcucha praw do wszystkich elementów systemu. Przy odbiorze projektu porównaj przekazane moduły z dokumentacją i ustaleniami dotyczącymi autorstwa. Jeśli nad kodem pracuje kilku twórców, zadbaj, by dokumenty od wykonawcy obejmowały prawa potrzebne do dalszego rozwoju każdego przekazanego elementu.

Czy software house może korzystać z podwykonawców?

Tak, jeśli umowa nie wyklucza takiej możliwości. Ustal, czy wykonawca poinformuje cię o zmianie podwykonawcy i jak zapewni ciągłość prac. Warto też określić, kto odpowiada za przekazanie dokumentacji, dostępów i rezultatów po odejściu podwykonawcy z projektu. Dzięki temu zmiana składu zespołu nie pozbawi cię potrzebnych materiałów.

Czy umowa wdrożeniowa musi zawierać umowę powierzenia przetwarzania danych?

Nie zawsze. Przed uruchomieniem projektu rozpisz przepływ informacji, uwzględniając dane w środowisku testowym, dziennikach zdarzeń, kopiach zapasowych i zgłoszeniach do pomocy technicznej. Te miejsca łatwo pominąć, choć mogą zawierać dane osobowe. Taka mapa ułatwia ustalenie, czy wykonawca uzyskuje do nich dostęp i jakie zapisy powinny go regulować.

Czy warto negocjować wzór umowy przygotowany przez software house?

Tak, dopasuj wzór do ryzyk konkretnego wdrożenia. W umowie z software house’em zapisz, jak rozstrzygać spór o zgodność rezultatu z wymaganiami oraz kto może zatwierdzić odbiór pod nieobecność głównego przedstawiciela firmy. Przejrzyj też załączniki i sprawdź, czy zawarte w nich odwołania są spójne. Przy złożonym projekcie skonsultuj treść z prawnikiem.

Artykuł autorstwa

Andrzej Klimek

Od 2008 roku właściciel firmy Internet Stars