W pracy analityka biznesowego zdarza się, że analizuje on projekty zahaczające o aspekty prawne. Często jednak nie ma wystarczającej wiedzy na temat przepisów, więc w najgorszym wypadku przyjmuje, że tych wymagań nie ma, ewentualnie pisze enigmatyczne „system musi spełniać wymagania prawne”. Jakiś czas temu zapytałam Was, jakie problemy prawne spotykacie w analizach i jak je rozwiązujecie, czy szukacie sami, czy korzystacie z pomocy prawników oraz jak się Wam z nimi współpracuje.
O prawie w analizie i systemach IT rozmawiałam z prawnikiem Alicją Cybulską. Alicja jest radcą prawnym prowadzącym własną kancelarię, specjalizującym się w umowach, ochronie danych osobowych i bieżącej obsłudze przedsiębiorstw. Bogate doświadczenie zdobyła pracując jako wewnętrzny prawnik korporacyjny w branży IT oraz jako zewnętrzny konsultant i audytor.
Zacznijmy od pytania, czy prawnik jest potrzebny przy prowadzeniu projektów i analizie biznesowej?
Tak jak analityk biznesowy często wykonuje zadania UX Designera, tak samo Project Manager czy analityk biznesowy może dysponować wystarczającą wiedzą na temat przepisów prawa niezbędną do prawidłowego prowadzenia projektu lub przeprowadzenia analizy biznesowej. Nie trzeba studiować prawa, żeby znaleźć odpowiedzi na pytania prawne. Czasami wystarczy skontaktować się z odpowiednim urzędem lub porozmawiać ze specjalistami z danej dziedziny, np. bankowości czy kadr. Można też poszukać odpowiedzi w Internecie, przy czym trzeba być bardzo ostrożnym, bo można znaleźć tam wszystko. Sztuką jest odsianie informacji fałszywych, nieprzydatnych, nieaktualnych, które to w przypadku kwestii prawnych zdarzają się niestety bardzo często.
Dlatego, jeśli ma się jakiekolwiek wątpliwości odnośnie konkretnych wymagań prawnych, warto skonsultować kluczowe kwestie, wymagania lub finalną treść umowy z prawnikiem, ale takim, który jest faktycznie ekspertem w danej dziedzinie. To tak jak z lekarzami – nie każdy internista będzie dobry i skuteczny w leczeniu chorób serca.
Jeśli projekt ma być prowadzony w podejściu zwinnym, a prawnik, który nam doradza, nie zna zasad Agile, to może być bardziej przeszkodą niż pomocą. Nie raz uczestniczyłam w przedłużających się negocjacjach tylko dlatego, że prawnik drugiej strony przesyłał umowę z mnóstwem zbędnych zmian i komentarzy. Rzekomo miały one chronić interes jego klienta (oczywiście wszystko na czerwono, żeby jego klient widział, za co płaci), a w istocie strony były dogadane zupełnie inaczej i nie potrzebowały zabezpieczeń na wypadek wszelkiego możliwego ryzyka, włącznie z „opętaniem przez złego ducha” (autentyczny przykład!). Warto rozmawiać szczerze ze swoim prawnikiem, nie bać się polemizować z jego opinią i postawić wobec niego jasne wymagania, aby nie tylko wskazywał problemy, ale szukał rozwiązań, które będą fair dla obu stron. A jeśli coś jest niezrozumiałe, to nie bójmy się pytać i drążyć, aż uzyskamy jasną i satysfakcjonującą odpowiedź.
Jakie mogą być konsekwencje, jeśli nie zadbamy, podczas analizy wymagań o sprawdzenie wymogów prawnych?
W większości przypadków – pewnie żadne. Firmy mogą sobie ufać, współpracować i konstruktywnie rozwiązywać otwarte kwestie. Gdy na horyzoncie zaczynają pojawiać się problemy, zwykle strony porozumiewają się odnośnie załatwienia sporu lub odpuszczają żądania, byleby tylko nie wikłać się w proces sądowy na kilka dobrych lat. Takie działanie jest wkalkulowane w prowadzenie biznesu.
Czasami jednak ziszczenie się ryzyka może wymagać zapłaty dużego odszkodowania lub kary administracyjnej za naruszenie przepisów, nie mówiąc o pogorszeniu wizerunku, które często jest najbardziej dotkliwe. Jeśli oczekiwania zamawiającego i wykonawcy istotnie się różnią i jednocześnie nie zostały dostatecznie sformułowane na wstępnym etapie współpracy lub projekt został źle poprowadzony, a w grę wchodzą znaczne nakłady finansowe, to ryzyko negatywnych konsekwencji rośnie.
Wszystko zależy od tego, w jaki sposób została sformułowana umowa pomiędzy stronami i jak wygląda proces komunikacji. Przyjęło się, że umowę pisze się na złe czasy, czyli na wypadek konieczności prowadzenia sporu przed sądem. Standardem są długie negocjacje klauzul o zachowaniu poufności, kar umownych, opisywanie poszczególnych etapów projektu i odpowiedzialności za nieudane działania. Prawnik zwykle chce w największym stopniu uchronić swojego klienta przed wszelkim możliwym ryzykiem i przerzucić je na drugą stronę. Tymczasem lepiej dla wszystkich jest, jeśli negocjacje umowy skupiają się na określaniu celów biznesowych, analizie biznesowej oraz opisaniu zasad komunikacji i współpracy pomiędzy stronami.
Jak w takim razie ocenić, czy umowa na projekt jest dobrze skonstruowana?
Przykładowo, jeśli tworzymy oprogramowanie w sposób zwinny, nie możemy poprzestać na klasycznych wzorach umów, które z góry opisują etapy, odbiory i efekt końcowy, a w postanowieniach końcowych wymagają „zmian w formie pisemnej pod rygorem nieważności” czy własnoręcznego podpisu członków zarządu. Słyszałam o przypadku, w którym kierownicy projektu umówili się mailowo na zmianę treści umowy (aneks) w zakresie wydłużenia harmonogramu, byli zgodni co do tej zmiany i wszystko byłoby w porządku, gdyby nie to, że finalnie projekt się nie powiódł i sprawa skończyła się w sądzie. Sędzia uznał, zgodnie z treścią umowy, że aneks zawarty w formie mailowej jest nieważny, bo strony w pisemnej umowie nie przewidziały takiej możliwości i ostatecznie przegrany musiał zapłacić karę umowną wynikającą z pierwotnych terminów, a nie tych aneksowanych. Dlatego warto zapobiegać tego typu sytuacjom i mieć umowę zgodną z faktycznymi ustaleniami.
Przy okazji jeszcze jedna kwestia, która często się pojawia w czasach digitalizacji. Zdarza się, że zawieramy umowę w formie elektronicznej, czy to za pomocą maila, dedykowanej platformy, czy przesłania skanu zamówienia lub skanu akceptacji oferty podpisanej przez zarząd. Potem zapominamy o przekazaniu oryginałów. Definiujemy, że zmiany umowy również mogą nastąpić drogą elektroniczną, itd., a w treści piszemy o przeniesieniu praw autorskich do programu lub utworu. Tymczasem dla skuteczności udzielenia licencji wyłącznej lub przeniesienia praw autorskich na zamawiającego konieczna jest umowa w formie pisemnej pod rygorem nieważności (czyli papier i długopis, ewentualnie bezpieczny podpis elektroniczny, który spełnia wymagania przepisów).
Polecam poszukać w Internecie artykułów na temat typowych błędów w umowach wdrożeniowych i pisaniu umów w projektach Agile. Bycie świadomym tych podstawowych kwestii może znacznie pomóc w prowadzeniu biznesu.
Często słyszę takie zdanie „ja się na prawie nie znam, umów czytać nie umiem, od tego są prawnicy”. W porządku, ja też nie muszę rozumieć linijek kodu, które tworzą programiści. Tylko trzeba wiedzieć, że samo wysłanie umowy do prawnika bez wyjaśnienia mu kontekstu biznesowego, wymagań, specyfikacji, jest jak czytanie kodu źródłowego bez komentarza. Oczywiście ekspert pewnie sobie poradzi, ale o ile łatwiej i skuteczniej byłoby posiłkować się dodatkowymi informacjami. Poza tym często lepiej się spotkać i omówić problem z prawnikiem i drugą stroną, niż wymieniać kolejnymi komentarzami do umowy. Dzięki temu mamy szansę w pełni skorzystać ze wsparcia prawnego i dobrze skonstruować umowę.
Zdarza się, że zadając to samo pytanie dwóm prawnikom otrzymamy dwie różne odpowiedzi. Skąd się to bierze?
Jest taki dowcip, jak prawnik, inżynier i matematyk zdają test. Zaczyna inżynier, pytają go: Ile jest 1+1? Inżynier pomyślał chwilę i powiedział: 2. Potem zawołano matematyka i zadano mu to samo pytanie. Po chwili zastanowienia odpowiedział: 2,0. Następnie wezwano prawnika. Usłyszał to samo pytanie i odpowiedział szybciej niż matematyk: A ile chcecie, żeby było?
Prawnik często pracuje w ten sposób, że szuka w przepisach i orzecznictwie argumentów na potwierdzenie tez, które będą korzystne dla klienta, ale też wskazuje ryzyko na wypadek zakwestionowania danej interpretacji. Ocena ryzyka i interpretacja przepisów do stanu faktycznego to zawsze kwestia wiedzy i doświadczenia danego prawnika.
Jak ustalać wymagania i rozwiązywać problemy prawne, jeśli nie mamy możliwości skorzystania z porad eksperta, bo na przykład firmy nie stać na wysokie koszty usług prawnych?
Można oczywiście próbować szukać samemu w Internecie, przy czym powinien on być wskazówką, a nie jedynym źródłem informacji, tak jak wspomniałam wyżej. Trudno mi tutaj wylistować, które konkretnie strony są wiarygodne, a które nie. Często to kwestia wyczucia i krytycznej oceny. Na pewno warto patrzeć na datę artykułu, im nowszy tym lepiej. Przykładowo, jeśli wpiszemy w wyszukiwarkę „rejestracja zbiorów danych osobowych oraz ABI” to nadal znajdziemy porady odnośnie tego obowiązku, mimo, że z dniem wejścia w życie RODO został on zniesiony. Dlatego warto przejrzeć więcej stron i przeanalizować ewentualne sprzeczne informacje. Niestety często jest tak, że gdy głębiej drążymy temat, to darmowe porady internetowe okazują się niewystarczające. Wtedy warto skontaktować się z prawnikiem, traktując to jako inwestycję w ochronę przed dużo wyższymi kosztami odszkodowawczymi.
Załóżmy, że mamy system, który trzeba utrzymywać i pilnować zgodności z prawem. Jak śledzić zmiany przepisów, żeby nie przegapić niczego ważnego? Kto jest za to odpowiedzialny?
To zależy od zakresu zlecenia i umowy. Jeśli sprzedaję gotowe oprogramowanie, np. dostęp do aplikacji do obsługi księgowej, to jako dostawca powinienem zagwarantować produkt dobrej jakości, czyli m.in. zgodny z prawem. Przykładowo, jeżeli 1 stycznia 2019 roku zmieniły się zasady rozliczania samochodów służbowych, to klient ma prawo domagać się, żebym zmienił odpowiednio treść formularzy, abym on mógł prawidłowo prowadzić swoją księgowość. Jeśli tego nie zrobię, klient ma prawo reklamować produkt i domagać się odszkodowania.
Jeśli zaś klient przychodzi do firmy wytwarzającej software na zamówienie i mówi „Poproszę aplikację do zarządzania rekrutacją. Chcę, żeby była nowoczesna i zgodna z prawem.”, to w ramach negocjacji strony powinny się umówić, kto definiuje wymagania prawne – zamawiający (dział prawny klienta, kadrowa, zewnętrzny konsultant czy radca prawny) czy wykonawca, który powinien znaleźć specjalistę od rekrutacji lub prawa pracy i wliczyć to w koszt projektu. Podobnie z wymaganiami w sektorze bankowym. Niby oczywiste, że każdy projekt dla banku powinien spełniać wymagania prawa bankowego, jednak powinny być one zdefiniowane na etapie analizy biznesowej, tak samo jak inne wymagania funkcjonalne i reguły biznesowe.
Warto też uregulować w umowie podejście do zmian wymagań prawnych. Wyobraźmy sobie taką sytuację. Sieć sklepów w kwietniu 2019 roku zleca wykonawcy przygotowanie aplikacji do wystawiania faktur na podstawie paragonu. Wykonawca ma odpowiadać za pozyskanie wymagań i zgodność aplikacji z przepisami. Angażuje doradcę podatkowego lub czyta przepisy i zapisuje się na branżowe newslettery. Deweloperzy pracują w pocie czoła. W połowie czerwca aplikacja jest gotowa. Zamawiający ma jednak kilka drobnych poprawek odnośnie wyglądu i funkcjonalności. Nagle media zaczynają informować, że rząd pracuje nad nowelizacją ustawy o VAT. Obecna praktyka – pobierania paragonu przy kasie i przejścia z nim do punktu obsługi klienta, gdzie wystawiana jest faktura i zwracany paragon, będzie musiała zostać zmieniona. Nowe przepisy mają wejść w życie od 1 września 2019 r. Jest to jednak nadal tylko projekt ustawy, bo przepisy nie zostały jeszcze uchwalone przez Sejm ani opublikowane w Dzienniku Ustaw i w każdej chwili może je zablokować Senat lub Prezydent. Wykonawcy zależy na jak najszybszym oddaniu aplikacji, bo już osiągnął zakładany próg godzinowy opłacalności projektu i ma dla zespołu zaplanowane inne zadania. Z kolei zamawiający wie, że za miesiąc aplikacja może nie być zgodna z prawem. Robi wszystko, aby przedłużyć termin odbioru do momentu uzyskania informacji, co dalej z ustawą i aby ewentualne zmiany już uwzględnić w cenie pierwotnej wersji aplikacji. Skomplikowana sytuacja. Dlatego warto o tym rozmawiać przed rozpoczęciem projektu, aby na każdym etapie móc współdziałać, a nie sabotować projekt.
Chyba podobnie było z RODO?
Zgadza się. RODO zostało uchwalone 27 kwietnia 2016, a weszło w życie 25 maja 2018 roku. Teoretycznie wszyscy wiedzieli, że będą zmiany, ale w praktyce mało kto potrafił interpretować przepisy i przewidzieć, jakie zmiany w polskim prawie pociągnie za sobą rozporządzenie unijne. Nawet prawnicy nie byli w stanie odpowiedzieć na kluczowe pytania i wydawali sprzeczne interpretacje.
Bywały takie sytuacje, że zamawiający przed majem 2018 roku zlecił stworzenie aplikacji webowej, potem przez kilka miesięcy wysyłał wielokrotnie prośby o drobne poprawki. Kiedy po prawie roku przyszło do odbioru finalnego produktu, okazało się, że aplikacja jest niezgodna z RODO i w takiej formie nie może być wypuszczona na rynek, więc zamawiający nie zamierzał płacić wykonawcy. Co więcej, chciał odzyskać już wpłacone środki, skoro odmówił odbioru dzieła z powodu istotnych wad. Może gdyby na etapie negocjowania umowy obie strony zaangażowały prawników, to sprawa skończyłaby się inaczej. Udawanie, że przepisy nas nie dotyczą i pisanie nieprecyzyjnego wymagania „system przechowuje dane osobowe” kończy się bardzo źle.
Jak zdefiniować w aplikacji okres przechowywania danych osobowych? Czy jest to zadanie leżące po stronie zamawiającego czy wykonawcy?
Artykuł 5 lit. e RODO stanowi, że „Dane osobowe muszą być przechowywane w formie umożliwiającej identyfikację osoby, której dane dotyczą, przez okres nie dłuższy, niż jest to niezbędne do celów, w których dane te są przetwarzane (…)” Piękne ogólnie sformułowanie, które nam nic nie mówi, prawda? O tym, jak długo administrator danych (zamawiający) będzie przechowywał dane osobowe decyduje on sam, a nie wykonawca oprogramowania. Przykład: najwięksi eksperci od ochrony danych osobowych spierają się z Urzędem Ochrony Danych Osobowych i między sobą, czy dane osobowe kandydatów trzeba usuwać zaraz po zakończeniu rekrutacji, czy można przechowywać jeszcze przez ileś lat, co najmniej do czasu przedawnienia roszczeń z tytułu ewentualnej dyskryminacji w zatrudnieniu. Polecam artykuł, który świetnie opisuje ten problem: https://www.prawo.pl/kadry/co-zrobic-z-cv-po-zakonczeniu-rekrutacji-wytyczne-uodo,309657.html (przy okazji: ten portal to jest jedno z dobrych źródeł informacji o prawie).
Jeśli miałabym doradzać wykonawcy, jak projektować aplikację, niezależnie czy na zlecenie zamawiającego, czy jako gotowy produkt do sprzedaży, to proponuję dać opcję samodzielnego definiowania przez klienta okresu przechowywania danych, wraz z funkcją ich trwałego usunięcia lub skutecznej anonimizacji (oraz z ww. linkiem do artykułu 😊).
Co z kodeksami dobrych praktyk, które miały opanować chaos związany z RODO?
Tworzą się, a częściowo już się pojawiły, tylko trzeba trochę poszukać. Mogę polecić np. link i stronę Fundacji Panoptykon. Warto ich śledzić i zapisać się na ich newsletter, bo robią sporo dobrej roboty. https://panoptykon.org/wiadomosc/gdzie-te-kodeksy
Dziękuję 😊
