To sprawia, że ocena dokumentacji SaaS nie powinna ograniczać się do sprawdzenia ceny i okresu subskrypcji. Przedmiotem analizy jest cały układ kontraktowy: formularz zamówienia, regulamin, umowa powierzenia przetwarzania danych, polityka prywatności, załącznik SLA, dokumentacja bezpieczeństwa oraz polityki dotyczące podwykonawców. Nierzadko właśnie w dokumentach odsyłanych lub udostępnianych na stronie internetowej znajdują się postanowienia najistotniejsze dla ryzyka prawnego.

Audyt umowy SaaS to analiza modelu zależności

SaaS jest wygodny, ponieważ skraca drogę do wdrożenia. Ta wygoda ma jednak cenę w postaci zależności od dostawcy. Przedsiębiorca powierza mu nie tylko utrzymanie aplikacji, ale często również przechowywanie danych, zarządzanie dostępami użytkowników, wykonywanie kopii zapasowych i rozwój funkcjonalności. W przypadku systemów CRM, ERP, księgowych, HR, marketing automation lub narzędzi wykorzystujących generatywną AI konsekwencje błędnego wyboru warunków są szczególnie dotkliwe.

Dobry audyt nie polega na mechanicznym wyszukiwaniu niekorzystnych klauzul. Najpierw należy ustalić, do czego usługa będzie używana, jakie informacje do niej trafią i czy brak dostępu przez kilka godzin, dni lub tygodni zatrzyma istotny proces. Inny poziom zabezpieczeń jest racjonalny dla narzędzia do zarządzania kalendarzem, a inny dla platformy obsługującej transakcje finansowe, dokumentację medyczną, dane pracownicze lub tajemnice przedsiębiorstwa.

Punktem wyjścia powinno być również określenie roli przedsiębiorcy. Czy będzie jedynym klientem dostawcy, czy platforma ma służyć także jego własnym klientom? Czy użytkownicy końcowi będą mogli przesyłać do systemu pliki, treści chronione prawem autorskim albo dane osobowe? Odpowiedzi wpływają na potrzebę uregulowania praw własności intelektualnej, odpowiedzialności za treści oraz relacji wynikających z RODO i przepisów konsumenckich.

Co powinien obejmować audyt umowy SaaS

Zakres usługi i prawo dostawcy do zmian

Opis funkcjonalności bywa ogólny: dostawca zapewnia dostęp do platformy, aktualizacji i wsparcia technicznego. Taka formuła nie odpowiada jeszcze na pytanie, co dokładnie klient otrzyma. W audycie należy porównać opis umowny z materiałami sprzedażowymi, specyfikacją wdrożenia oraz funkcjami uznanymi przez biznes za krytyczne.

Szczególnej uwagi wymagają klauzule pozwalające jednostronnie zmieniać regulamin, funkcjonalności, limity użycia lub polityki bezpieczeństwa. Sama możliwość aktualizowania usługi jest naturalna dla SaaS i często korzystna. Problem powstaje, gdy dostawca może usunąć istotną funkcję, ograniczyć integrację albo wprowadzić nowy model rozliczeń bez realnego prawa klienta do sprzeciwu lub rozwiązania umowy.

Warto więc sprawdzić, czy zmiana istotnie pogarszająca sytuację klienta jest odpowiednio komunikowana, czy przewidziano okres przejściowy i czy klient może zakończyć współpracę bez sankcji. Przy rozwiązaniach kluczowych dla działalności zasadne jest umowne wskazanie funkcji podstawowych oraz procedury zarządzania zmianą.

SLA, wsparcie i konsekwencje niedostępności

Deklaracja dostępności na poziomie 99,9 proc. może brzmieć dobrze, ale nie przesądza o jakości ochrony. Należy ustalić okres pomiaru, wyłączenia z kalkulacji, planowane prace serwisowe, sposób raportowania oraz to, czy dostępność dotyczy całej usługi, czy tylko wybranych komponentów. Różnica między miesięcznym a rocznym sposobem liczenia dostępności może mieć praktyczne znaczenie.

Istotne są też czasy reakcji i usunięcia błędów, kanały zgłoszeń oraz klasyfikacja incydentów. W wielu standardowych kontraktach jedynym świadczeniem za naruszenie SLA jest service credit, czyli przyszły rabat na abonament. Nie zawsze jest to rozwiązanie nieakceptowalne. Dla usługi o niskiej krytyczności może być proporcjonalne, ale nie powinno zastępować odpowiedzialności za szkody wynikłe z rażącego naruszenia obowiązków, naruszenia poufności lub bezprawnego wykorzystania danych.

Dane osobowe, tajemnica przedsiębiorstwa i lokalizacja danych

Jeżeli w systemie przetwarzane są dane osobowe, umowa powierzenia nie może być traktowana jako formalny załącznik bez znaczenia operacyjnego. Trzeba zweryfikować kategorię danych, zakres operacji, instrukcje administratora, środki techniczne i organizacyjne, zasady korzystania z podprocesorów oraz procedurę obsługi naruszeń ochrony danych.

Należy rozróżnić sytuację, w której dostawca rzeczywiście działa jako procesor, od przypadków, w których wykorzystuje dane także dla własnych celów, na przykład do analityki produktowej, bezpieczeństwa lub trenowania modeli. Zwłaszcza przy narzędziach AI sformułowania o ulepszaniu usług wymagają precyzyjnej oceny. Dane wprowadzane przez użytkowników nie powinny automatycznie stawać się materiałem wykorzystywanym do rozwoju produktu, jeżeli nie wynika to jasno z uzgodnionych zasad i nie zostało ocenione pod kątem podstaw prawnych oraz poufności.

Audyt powinien objąć lokalizację centrów danych i transfery poza Europejski Obszar Gospodarczy. Informacja, że dostawca jest globalny, nie stanowi odpowiedzi na pytanie o mechanizm legalizujący transfer, zakres dostępu personelu z państw trzecich ani środki dodatkowe. W sektorach regulowanych potrzebna może być dalej idąca analiza wymogów outsourcingu, cyberbezpieczeństwa, tajemnicy zawodowej lub zasad nadzorczych.

Własność intelektualna i dane wprowadzane do systemu

W modelu SaaS licencja na korzystanie z oprogramowania jest zwykle ograniczona, niewyłączna i nieprzenoszalna. To standard, ale jej zakres musi odpowiadać rzeczywistemu użyciu. Wątpliwości mogą dotyczyć korzystania przez spółki z grupy, kontraktorów, klientów klienta, administratorów zewnętrznych albo dostępu przez API.

Równie istotne jest ustalenie, komu przysługują prawa do danych, raportów, konfiguracji, szablonów i rezultatów wygenerowanych w systemie. Dostawca powinien mieć tylko takie uprawnienia do materiałów klienta, jakie są konieczne do wykonania usługi. Klauzula udzielająca szerokiej, nieodpłatnej i nieodwołalnej licencji na wszelkie treści klienta może być nie do pogodzenia z ochroną tajemnicy przedsiębiorstwa, obowiązkami wobec klientów lub zasadami licencjonowania cudzych materiałów.

Warto także ustalić, czy usługodawca zapewnia ochronę przed roszczeniami osób trzecich z tytułu naruszenia praw własności intelektualnej. Wyłączenie takiej odpowiedzialności może być szczególnie ryzykowne, gdy SaaS udostępnia biblioteki treści, komponenty programistyczne lub funkcje generowania materiałów marketingowych.

Limit odpowiedzialności nie może być analizowany w oderwaniu od ryzyka

Najczęściej spotykane ograniczenie odpowiedzialności dostawcy to wielokrotność opłat zapłaconych w określonym okresie, niekiedy z wyłączeniem utraconych korzyści, szkód pośrednich i wszelkich roszczeń związanych z utratą danych. Dla klienta płacącego niski abonament limit może być symboliczny wobec skali potencjalnej szkody.

Nie oznacza to, że każda umowa powinna przewidywać nieograniczoną odpowiedzialność dostawcy. Takie żądanie może być nieproporcjonalne i nierealistyczne w relacji z dużym globalnym podmiotem. Potrzebne jest natomiast świadome rozdzielenie ryzyk. Wyższy albo odrębny limit warto rozważyć dla naruszenia poufności, obowiązków związanych z danymi osobowymi, umyślnego działania, rażącego niedbalstwa oraz roszczeń dotyczących praw własności intelektualnej.

Trzeba przy tym pamiętać, że ograniczenie odpowiedzialności w relacji B2B podlega ocenie według prawa właściwego dla umowy. W kontraktach międzynarodowych wybór prawa obcego i sądu zagranicznego ma znaczenie nie tylko procesowe. Może również wpływać na skuteczność określonych wyłączeń oraz koszt dochodzenia roszczeń.

Wyjście z usługi jest testem jakości kontraktu

Najbardziej pomijanym elementem dokumentacji SaaS jest exit plan. Tymczasem pytanie nie brzmi wyłącznie, czy można wypowiedzieć umowę, lecz czy po jej zakończeniu przedsiębiorca odzyska dane w formacie użytecznym biznesowo i technicznie. Eksport pliku PDF albo niepełnego arkusza kalkulacyjnego nie zawsze pozwoli przenieść historię transakcji, załączniki, metadane, uprawnienia i konfigurację do nowego dostawcy.

Umowa powinna określać okres dostępu do danych po zakończeniu współpracy, format eksportu, ewentualne opłaty, wsparcie migracyjne i termin trwałego usunięcia danych. W przypadku rozwiązań krytycznych warto testować procedurę eksportu jeszcze przed pełnym wdrożeniem. To działanie techniczne, lecz jego sens jest również prawny: pozwala sprawdzić, czy deklarowana przenoszalność danych ma rzeczywistą wartość.

Audyt powinien wykrywać nie tylko wady tekstu, lecz także rozdźwięk między kontraktem a modelem operacyjnym przedsiębiorstwa. Najlepsza umowa nie zastąpi właściwego zarządzania dostępami, klasyfikacji informacji czy procedury reagowania na incydenty. Może jednak zapewnić, że gdy dostawca zmieni warunki, usługa przestanie działać albo dane trzeba będzie odzyskać, firma nie będzie dopiero wtedy odkrywać, jaką cenę ma pozornie prosty abonament.

Dla przedsiębiorcy najważniejsze jest właściwe postawienie pytania. Nie chodzi o to, czy każda treść, przy której wykorzystano narzędzie AI, wymaga widocznego dopisku. Pytanie brzmi: kto stworzył lub wdrożył dany system, jaki jest charakter wyniku, kto jest jego odbiorcą oraz czy odbiorca może racjonalnie uznać treść za autentyczną albo ludzką.

Obowiązek oznaczania treści generowanych przez AI w AI Act

Rozporządzenie 2024/1689, określane jako AI Act, w art. 50 ustanawia obowiązki transparentności dotyczące określonych zastosowań systemów AI. Ich celem nie jest zakaz syntetycznych treści. Chodzi o umożliwienie odbiorcy rozpoznania, że ma do czynienia z systemem sztucznej inteligencji albo z treścią sztucznie wygenerowaną lub zmanipulowaną.

Obowiązki zostały rozdzielone między różne podmioty. Dostawca systemu AI przeznaczonego do bezpośredniej interakcji z osobami fizycznymi powinien zaprojektować go tak, aby informował użytkownika, że komunikuje się z maszyną. Wyjątkiem są sytuacje, w których jest to oczywiste z kontekstu. Prosty bot w oknie pomocy opisany jako „asystent AI” zasadniczo spełnia ten standard. Asystent podszywający się w korespondencji pod konkretnego pracownika – już niekoniecznie.

Dostawcy narzędzi generujących lub manipulujących obrazem, dźwiękiem, wideo albo tekstem mają zapewniać, aby wynik był oznaczony w formacie nadającym się do odczytu maszynowego oraz umożliwiającym wykrycie sztucznego pochodzenia lub manipulacji. To obowiązek o charakterze technicznym. Nie oznacza automatycznie, że każda publikacja musi zawierać duży komunikat widoczny dla człowieka, ale wymaga wdrożenia mechanizmów identyfikowalności, o ile jest to technicznie wykonalne i skuteczne.

Inaczej przedstawia się sytuacja podmiotu, który używa systemu, czyli deployera. Jeżeli publikuje on obraz, nagranie audio lub wideo stanowiące deepfake, powinien ujawnić, że treść została sztucznie wygenerowana lub zmanipulowana. Deepfake to nie każde użycie AI w postprodukcji. Chodzi o materiał przypominający istniejące osoby, przedmioty, miejsca lub zdarzenia, który mógłby sprawiać wrażenie autentycznego.

Szczególna reguła dotyczy tekstu generowanego lub zmanipulowanego przez AI, publikowanego w celu informowania społeczeństwa o sprawach leżących w interesie publicznym. Co do zasady należy ujawnić jego sztuczne pochodzenie. AI Act przewiduje jednak istotne wyłączenie: obowiązek może nie powstać, gdy treść została poddana kontroli człowieka lub procesowi redakcyjnemu, a osoba fizyczna albo prawna ponosi odpowiedzialność redakcyjną za publikację.

To wyłączenie ma duże znaczenie dla redakcji, firm publikujących analizy rynkowe i zespołów komunikacji korporacyjnej. Nie zwalnia ono jednak z realnej kontroli. Pobiegłe przejrzenie tekstu wygenerowanego przez model, bez weryfikacji faktów, źródeł i ocen, trudno traktować jako proces redakcyjny uzasadniający pełną odpowiedzialność za materiał.

Oznaczenie musi być adekwatne do ryzyka

AI Act nie narzuca jednego uniwersalnego sformułowania. Komunikat powinien być jasny, dostosowany do odbiorcy i umieszczony tak, aby nie został przeoczony. W reklamie wideo właściwym rozwiązaniem może być czytelna plansza lub informacja w opisie, zależnie od tego, jak materiał jest konsumowany. Przy nagraniu głosowym syntetyczny charakter wypowiedzi powinien wynikać z komunikatu słyszalnego, a nie wyłącznie z drobnego tekstu na stronie.

W przypadku treści artystycznych, satyrycznych, fikcyjnych lub analogicznych rozporządzenie dopuszcza bardziej elastyczną formę ujawnienia, o ile nie utrudnia ona odbioru utworu. Nie jest to jednak zgoda na tworzenie pozornie autentycznego nagrania polityka, konkurenta lub klienta bez żadnego wyjaśnienia. Im większe prawdopodobieństwo, że odbiorca podejmie decyzję na podstawie rzekomej autentyczności materiału, tym wyższy standard transparentności.

Nie ma jednej polskiej reguły dla każdego materiału AI

Poza zakresem AI Act nie istnieje generalna zasada, zgodnie z którą każda grafika, tekst lub prezentacja powstała z pomocą AI musi być oznaczona. Użycie modelu do korekty stylu, transkrypcji spotkania, usunięcia szumu z nagrania czy wygenerowania roboczego szkicu nie jest samo w sobie podstawą do obowiązkowego etykietowania finalnego materiału.

Brak formalnego obowiązku nie oznacza jednak braku ryzyka prawnego. Jeżeli przedsiębiorca wykorzystuje awatar AI jako „specjalistę” zachęcającego do zakupu, a odbiorca może uznać go za realną osobę, ocena powinna uwzględniać przepisy o nieuczciwych praktykach rynkowych i ochronie konsumenta. Przekaz handlowy nie może zniekształcać decyzji przeciętnego konsumenta przez wprowadzające w błąd działanie lub zaniechanie.

W relacjach B2B istotne będą także przepisy o zwalczaniu nieuczciwej konkurencji. Dotyczy to zwłaszcza symulowania rekomendacji klientów, ekspertów lub inwestorów, które w rzeczywistości zostały wygenerowane automatycznie. Fakt, że odbiorcą jest profesjonalista, nie daje przedsiębiorcy swobody w kreowaniu fałszywego wrażenia autentyczności.

Osobną kategorią są dobra osobiste i wizerunek. Wygenerowanie realistycznego materiału z udziałem rozpoznawalnej osoby może prowadzić do odpowiedzialności cywilnej nawet wtedy, gdy materiał zawiera oznaczenie AI. Etykieta nie legalizuje bezprawnego wykorzystania czyjejś twarzy, głosu, reputacji lub tożsamości. W praktyce konieczne może być uzyskanie zgody, a przy kampaniach o szerokim zasięgu – również precyzyjne ustalenie zakresu licencji i sposobów eksploatacji.

Co wdrożyć w firmie przed publikacją

Największym błędem compliance jest traktowanie oznaczeń jako zadania dla osoby publikującej post w mediach społecznościowych. Decyzja powinna zapadać wcześniej, na etapie procesu tworzenia i akceptacji materiału. Firma potrzebuje krótkiej, lecz operacyjnej procedury klasyfikacji treści.

Warto ustalić, czy materiał jest syntetyczny, czy przedstawia osobę albo zdarzenie w sposób realistyczny, czy jest kierowany do konsumentów, czy dotyczy spraw publicznych oraz kto odpowiada za kontrolę redakcyjną. Dopiero na tej podstawie można zdecydować o formule komunikatu, metadanych i dokumentacji akceptacji.

W praktyce procedura powinna obejmować co najmniej cztery elementy:

• rejestr narzędzi AI dopuszczonych do użycia oraz ich zastosowań;
• zasady oznaczania deepfake’ów, awatarów, syntetycznych głosów i materiałów informacyjnych;
• weryfikację praw do wykorzystywanych danych, wizerunków, nagrań i znaków towarowych;
• przypisanie odpowiedzialności za końcową akceptację redakcyjną oraz za archiwizację decyzji.

Dokumentacja ma znaczenie nie tylko na wypadek kontroli. Pozwala także obronić spójność komunikacji, gdy zespół marketingu korzysta z wielu dostawców, a treści są publikowane jednocześnie na stronie, w aplikacji, w reklamie i na platformach społecznościowych.

Nie myl metadanych z komunikatem dla odbiorcy

Techniczne oznaczenie pochodzenia treści jest wartościowe, ale nie zawsze realizuje obowiązek wobec człowieka. Metadane mogą zniknąć po kompresji pliku, eksporcie, zrzucie ekranu albo publikacji na platformie, która je usuwa. Z kolei widoczny napis „materiał wygenerowany z użyciem AI” może nie wystarczyć tam, gdzie konieczne jest zachowanie informacji maszynowo odczytywalnej.

Bezpieczny model zakłada więc dwa poziomy: odpowiednie oznaczenie techniczne po stronie narzędzia lub procesu produkcyjnego oraz jasny komunikat dla odbiorcy, gdy wymaga tego AI Act, charakter przekazu albo ryzyko wprowadzenia w błąd. Zakres tego drugiego elementu zależy od kontekstu, a nie od samego faktu użycia modelu generatywnego.

Firmy wykorzystujące AI w komunikacji nie powinny pytać wyłącznie, jak ukryć technologię, aby przekaz wyglądał bardziej naturalnie. Trwalszą przewagą będzie zaprojektowanie komunikacji tak, by odbiorca wiedział, kiedy kontaktuje się z człowiekiem, a kiedy z syntetycznym przekazem – i mimo tej wiedzy mógł zaufać marce.

Dla przedsiębiorstwa technologicznego własność intelektualna nie jest pobocznym obszarem obsługi prawnej. Jest częścią struktury aktywów, ładu korporacyjnego i compliance. Obejmuje nie tylko patent czy znak towarowy, ale także kod źródłowy, dokumentację, modele danych, interfejs, treści marketingowe, bazę klientów, know-how, nazwę produktu oraz rezultaty pracy wykonawców i systemów generatywnej AI.

Własność intelektualna: nie jedno prawo, lecz kilka reżimów

Pod wspólnym pojęciem kryją się prawa o odmiennej funkcji, czasie trwania i sposobie nabycia. Ten sam produkt cyfrowy może jednocześnie korzystać z ochrony prawa autorskiego, tajemnicy przedsiębiorstwa, ochrony znaku towarowego, a w określonych przypadkach także ochrony patentowej. Błąd polega na założeniu, że jedna umowa lub rejestracja „załatwia” całość.

Prawo autorskie chroni sposób wyrażenia twórczej koncepcji, a nie samą ideę biznesową. Kod programu, projekt graficzny, tekst dokumentacji, film reklamowy czy architektura strony mogą być utworami, jeżeli spełniają ustawowe przesłanki twórczości i indywidualności. Ochrona powstaje co do zasady automatycznie, bez rejestracji.

To nie oznacza jednak, że spółka automatycznie nabywa autorskie prawa majątkowe. Szczególne reguły dotyczą utworów pracowniczych oraz programów komputerowych tworzonych w ramach stosunku pracy. Nie należy ich mechanicznie przenosić na współpracę B2B, kontrakty menedżerskie, umowy z agencją czy pracę freelancera. W tych relacjach zakres praw trzeba zwykle uregulować wyraźnie.

Znak towarowy chroni natomiast oznaczenie odróżniające towary lub usługi. Może nim być nazwa, logo, slogan, a niekiedy także nietypowe oznaczenie graficzne. Rejestracja nie jest obowiązkowa, lecz daje znacznie silniejszą pozycję dowodową i wyłączne prawo w zakresie wskazanych klas. Zanim spółka zainwestuje w branding, powinna sprawdzić kolizje z wcześniejszymi oznaczeniami – w Polsce, Unii Europejskiej i na rynkach planowanej ekspansji.

Tajemnica przedsiębiorstwa obejmuje informacje techniczne, handlowe, organizacyjne i inne informacje posiadające wartość gospodarczą, które nie są powszechnie znane, jeżeli przedsiębiorca podjął działania dla zachowania ich poufności. Algorytm, polityka cenowa, roadmapa produktu lub lista leadów nie stają się tajemnicą tylko dlatego, że firma nazywa je poufnymi. Konieczne są realne środki ochrony: właściwe uprawnienia dostępu, klauzule poufności, procedury offboardingu i kontrola obiegu danych.

Kod, dane i dokumentacja: kto naprawdę ma prawa?

W audycie IP najczęściej ujawnia się problem nielegalnego używania cudzej własności, lecz brak uporządkowanego łańcucha tytułów prawnych. Spółka używa repozytorium, materiałów sprzedażowych i design systemu, ale nie potrafi wykazać, że skutecznie nabyła prawa od osób, które je stworzyły.

W odniesieniu do programów komputerowych umowa powinna precyzyjnie wskazywać, czy chodzi o przeniesienie autorskich praw majątkowych, czy o licencję. To rozróżnienie ma znaczenie gospodarcze. Inwestor lub nabywca biznesu będzie oczekiwać, że spółka może swobodnie rozwijać, modyfikować i zbywać produkt. Licencja może być wystarczająca dla bieżącego korzystania, ale ograniczać transakcję M&A, outsourcing lub ekspansję na nowe modele dystrybucji.

Przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności. Sama faktura, e-mail z deklaracją „przekazuję wszystkie prawa” albo regulamin współpracy nie zawsze spełnią ten wymóg. Umowa musi też określać pola eksploatacji, czyli sposoby korzystania z utworu. W przypadku oprogramowania warto objąć nie tylko zwielokrotnianie i rozpowszechnianie, lecz również trwałe lub czasowe reprodukowanie, modyfikację, łączenie z innymi systemami, udostępnianie w modelu SaaS oraz korzystanie w ramach grupy kapitałowej, jeśli jest to przewidywane.

Trzeba przy tym pamiętać, że autorskie prawa osobiste pozostają przy twórcy i co do zasady nie podlegają przeniesieniu. Praktyczne znaczenie ma zatem zobowiązanie twórcy do niewykonywania tych praw w zakresie dopuszczalnym przez prawo oraz zgoda na ingerencje konieczne dla rozwoju produktu. Nie eliminuje to wszystkich ryzyk, ale ogranicza pole późniejszego konfliktu.

Szczególnej ostrożności wymaga open source. Wykorzystanie komponentu na licencji permissive będzie miało inne konsekwencje niż użycie kodu na licencji copyleft. Problem nie polega na tym, że open source jest z definicji niebezpieczny. Ryzyko wynika z braku ewidencji komponentów, nieznajomości warunków licencji i wdrażania zależności bez procesu akceptacji. W produkcie przeznaczonym do sprzedaży lub finansowania warto prowadzić rejestr użytych bibliotek, wersji, licencji i obowiązków informacyjnych.

Dane również wymagają rozdzielenia kilku kwestii. Baza danych może podlegać ochronie prawnoautorskiej lub ochronie sui generis, ale dane osobowe nie są „własnością” przedsiębiorcy. Ich przetwarzanie opiera się na przepisach o ochronie danych, celu przetwarzania i odpowiedniej podstawie prawnej. Próba opisania danych klientów jako wyłącznego aktywa IP może prowadzić do błędnych decyzji transakcyjnych i compliance.

AI nie przenosi praw – może tworzyć nowe ryzyka

Wykorzystanie generatywnej AI komplikuje łańcuch praw do treści, kodu i materiałów wizualnych. Fakt, że narzędzie wygenerowało rezultat na polecenie pracownika, nie przesądza jeszcze o istnieniu utworu ani o zakresie uprawnień użytkownika. Polskie prawo autorskie opiera ochronę na twórczości człowieka. Im bardziej rezultat jest automatyczny, tym trudniej przypisać mu ochronę autorskoprawną w tradycyjnym rozumieniu.

Nie oznacza to, że materiały wygenerowane przez AI są prawnie obojętne. Mogą naruszać prawa osób trzecich, zawierać elementy zbyt podobne do istniejących utworów albo ujawniać poufne informacje, jeżeli użytkownik wprowadził je do zewnętrznego modelu. Warunki dostawcy narzędzia mogą regulować wykorzystanie inputów i outputów, lecz nie zastępują analizy ryzyka naruszeń.

Dobra polityka AI powinna określać, jakie narzędzia są dopuszczone, jakiego rodzaju dane wolno do nich wprowadzać, kto zatwierdza wykorzystanie wyników w produkcie i kiedy konieczna jest weryfikacja człowieka. W firmie rozwijającej oprogramowanie przydatne jest także rozróżnienie między użyciem AI jako wsparcia programisty a automatycznym włączaniem wygenerowanego kodu do repozytorium produkcyjnego.

Ochrona własności intelektualnej zaczyna się przed sporem

Najlepszą reakcją na naruszenie nie jest pierwsze wezwanie do zaprzestania naruszeń, lecz dokumentacja przygotowana wcześniej. Przedsiębiorca powinien umieć szybko odpowiedzieć na cztery pytania: co stanowi jego aktywo IP, kto je stworzył, na jakiej podstawie spółka korzysta z niego oraz jakie dowody potwierdzają tę podstawę.

W praktyce warto stworzyć rejestr kluczowych aktywów, powiązać je z umowami i osobami odpowiedzialnymi oraz ustalić terminy odnowienia praw, zwłaszcza znaków towarowych i domen. Rejestr nie musi być rozbudowanym systemem klasy enterprise. Na początkowym etapie często wystarcza kontrolowany wykaz, pod warunkiem że jest aktualny i przypisany do odpowiedzialnej osoby.

Przy współpracy z pracownikami i kontraktorami należy rozdzielić trzy obszary: prawa do rezultatów pracy, poufność oraz zakaz korzystania z materiałów osób trzecich bez uprawnienia. Sama klauzula NDA nie przenosi praw autorskich, a sama klauzula o prawach autorskich nie chroni wystarczająco know-how. Równie istotne są procedury praktyczne: dostęp według ról, repozytoria należące do spółki, firmowe konta i odbiór materiałów przy zakończeniu współpracy.

Patent może być właściwym narzędziem, gdy firma dysponuje rozwiązaniem technicznym spełniającym wymogi patentowalności. Nie każda innowacja cyfrowa kwalifikuje się do tej ochrony. Program komputerowy „jako taki” nie jest patentowalny, ale wynalazek wspomagany komputerowo może uzyskać ochronę, jeśli rozwiązuje problem techniczny i spełnia pozostałe przesłanki. Czasem lepszą strategią będzie zachowanie rozwiązania jako tajemnicy przedsiębiorstwa, zwłaszcza gdy trudno je odtworzyć z gotowego produktu. Patent wymaga ujawnienia rozwiązania, ale daje czasowo ograniczony monopol. Tajemnica nie wymaga rejestracji, lecz przepada, gdy informacja zostanie legalnie ujawniona lub niezależnie opracowana.

Własność intelektualna powinna być traktowana jak element decyzji biznesowej, a nie dokument do podpisania po wdrożeniu produktu. Im wcześniej firma połączy kontrakty, architekturę technologiczną i governance z realnym przepływem praw, tym mniej kosztowna będzie każda kolejna runda finansowania, współpraca z partnerem i obrona przed konkurencją.

Kiedy informacja jest tajemnicą przedsiębiorstwa?

Punktem wyjścia jest art. 11 ustawy o zwalczaniu nieuczciwej konkurencji. Tajemnicą przedsiębiorstwa są informacje techniczne, technologiczne, organizacyjne lub inne informacje mające wartość gospodarczą, które jako całość lub w szczególnym zestawieniu nie są powszechnie znane ani łatwo dostępne dla osób zwykle zajmujących się tego rodzaju informacjami. Przedsiębiorca musi też podjąć działania w celu utrzymania ich w poufności.

Definicja jest szersza niż katalog dokumentów opatrzonych klauzulą „poufne”. Ochroną mogą być objęte m.in. algorytmy, architektura systemu, baza klientów, model wyceny, warunki negocjowane z kontrahentami, roadmapa produktu, parametry emisji tokenów przed publikacją czy wyniki testów bezpieczeństwa. W firmach technologicznych szczególne znaczenie ma również zestawienie danych, które pojedynczo bywają jawne, lecz razem ujawniają strategię lub sposób działania przedsiębiorstwa.

Nie każda istotna informacja spełni jednak te kryteria. Powszechnie dostępny cennik, wiedza zawodowa pracownika albo rozwiązanie możliwe do odtworzenia na podstawie legalnie nabytego produktu co do zasady nie stają się tajemnicą wyłącznie dlatego, że firma tak je nazwała. Prawo nie służy do objęcia trwałą wyłącznością informacji, które nie są realnie chronione.

Jak chronić tajemnicę przedsiębiorstwa w firmie systemowo

Największym błędem jest budowanie ochrony wyłącznie po wystąpieniu wycieku. Wtedy często brakuje odpowiedzi na podstawowe pytania: co konkretnie było tajemnicą, kto miał dostęp i jakie zabezpieczenia obowiązywały. Skuteczny model zaczyna się od uporządkowania informacji, a nie od wzoru oświadczenia o poufności.

Ustal katalog informacji i ich właścicieli

Przedsiębiorstwo powinno zidentyfikować informacje o wartości gospodarczej oraz przypisać im właściciela biznesowego. Nie musi to oznaczać tworzenia rozbudowanej biurokracji. Wystarczająca może być przemyślana klasyfikacja obejmująca np. dane publiczne, wewnętrzne, poufne i ściśle poufne, połączona z jasną instrukcją postępowania.

Warto opisać, gdzie znajdują się kluczowe zasoby: w repozytoriach kodu, CRM, wirtualnych pokojach danych, skrzynkach pocztowych, narzędziach do zarządzania projektami czy prywatnych urządzeniach. W praktyce właśnie rozproszenie informacji utrudnia później dochodzenie roszczeń. Jeżeli członkowie zespołu mogą bez ograniczeń eksportować bazy lub kopiować dokumenty do prywatnych chmur, przedsiębiorcy będzie trudno przekonywać, że zastosował rozsądne działania ochronne.

Ogranicz dostęp, a nie tylko deklaruj poufność

Dostęp powinien odpowiadać roli i aktualnym zadaniom danej osoby. Programista nie zawsze potrzebuje całej bazy klientów, a osoba z działu sprzedaży nie musi mieć dostępu do pełnej dokumentacji bezpieczeństwa produktu. Zasada minimalnych uprawnień ma znaczenie zarówno dla cyberbezpieczeństwa, jak i dla ochrony prawnej tajemnicy.

W systemach cyfrowych oznacza to w szczególności indywidualne konta, uwierzytelnianie wieloskładnikowe, rozdzielenie środowisk, okresowy przegląd uprawnień i rejestrowanie pobierania istotnych plików. Logi nie zapobiegają samodzielnie naruszeniu, ale mogą wykazać zakres dostępu i ułatwić zabezpieczenie dowodów.

Istotny jest także proces zakończenia współpracy. W dniu odejścia pracownika, współpracownika B2B lub członka organu należy odebrać dostępy, przejąć urządzenia i konta, potwierdzić zwrot nośników oraz przypomnieć o obowiązujących zobowiązaniach. Opóźnienie o kilka dni bywa wystarczające, aby doszło do nieodwracalnego skopiowania danych.

Zadbaj o umowy, ale nie oczekuj od nich wszystkiego

Umowa o poufności powinna precyzyjnie określać informacje chronione, cel ich przekazania, krąg uprawnionych odbiorców, zasady korzystania, okres obowiązywania oraz procedurę zwrotu lub usunięcia materiałów. Ogólny zapis o „zachowaniu wszelkich informacji w tajemnicy” może mieć ograniczoną użyteczność, zwłaszcza przy sporze o to, czy kontrahent rozumiał zakres obowiązków.

W relacjach z pracownikami należy uwzględnić przepisy prawa pracy, w tym obowiązek dbałości o dobro zakładu pracy i zachowania w tajemnicy informacji, których ujawnienie mogłoby narazić pracodawcę na szkodę. Z kolei umowa B2B wymaga wyraźnego, kontraktowego uregulowania poufności. Kara umowna może wzmacniać dyscyplinę kontraktową, ale nie zastępuje organizacyjnych i technicznych środków ochrony.

Nie należy też utożsamiać poufności z zakazem konkurencji. Były pracownik może wykorzystywać własne doświadczenie i umiejętności, nawet jeżeli zdobył je podczas zatrudnienia. Zakaz konkurencji po ustaniu stosunku pracy wymaga odrębnej podstawy i, w przypadku pracownika, wiąże się z obowiązkiem wypłaty odszkodowania. Zbyt szerokie ograniczenia są ryzykowne i nie powinny zastępować precyzyjnej ochrony konkretnych informacji.

Szczególne ryzyko: chmura, AI i współpraca z dostawcami

Przedsiębiorcy coraz częściej przekazują dane dostawcom SaaS, firmom programistycznym, podmiotom audytującym i narzędziom generatywnej AI. W każdym z tych przypadków należy odróżnić kwestie ochrony danych osobowych od ochrony tajemnicy przedsiębiorstwa. Dokument może nie zawierać danych osobowych, a mimo to ujawniać model biznesowy, kod, marżę lub plan inwestycyjny.

Przed wdrożeniem narzędzia AI warto sprawdzić, czy dostawca wykorzystuje wprowadzane dane do trenowania modelu, gdzie dane są przetwarzane, czy administrator może wyłączyć taką funkcję oraz jakie reguły obowiązują po rozwiązaniu umowy. W wielu organizacjach rozsądnym rozwiązaniem jest lista zatwierdzonych narzędzi, zakaz wprowadzania określonych kategorii informacji do publicznych chatbotów oraz procedura anonimizacji promptów.

Podobnej staranności wymagają projekty outsourcingowe. Dostawca powinien otrzymać tylko te informacje, które są potrzebne do wykonania zlecenia, a umowa powinna obejmować również jego personel i podwykonawców. Przy transakcjach inwestycyjnych oraz due diligence szczególne znaczenie mają wirtualne pokoje danych, stopniowanie dostępu i zakaz masowego pobierania dokumentów.

Co zrobić, gdy doszło do ujawnienia?

Pierwsze godziny po wykryciu incydentu są ważniejsze niż rozbudowana korespondencja prawna. Należy zabezpieczyć dowody: logi, historię pobrań, wiadomości, kopie plików i informacje o urządzeniach. Równocześnie trzeba ograniczyć dalszy dostęp, zmienić poświadczenia, wstrzymać konta oraz ustalić, czy informacje trafiły do konkurenta, podwykonawcy lub publicznego repozytorium.

Dalsza strategia zależy od skali zdarzenia i relacji stron. Możliwe są wezwanie do zaprzestania naruszeń, żądanie zwrotu albo usunięcia nośników i kopii, a w razie potrzeby dochodzenie roszczeń cywilnych. Ustawa o zwalczaniu nieuczciwej konkurencji przewiduje m.in. żądanie zaniechania niedozwolonych działań, usunięcia ich skutków, naprawienia szkody czy wydania bezpodstawnie uzyskanych korzyści. W określonych przypadkach ujawnienie tajemnicy może mieć także konsekwencje karne.

Przed wystąpieniem na drogę sądową warto jednak ocenić cel biznesowy. Czasem priorytetem będzie szybkie odcięcie dostępu i ograniczenie rozpowszechniania informacji, a nie wieloletni spór o odszkodowanie. W sprawach pilnych znaczenie może mieć zabezpieczenie roszczenia, lecz jego skuteczność zależy od dobrze udokumentowanego statusu informacji i realnego ryzyka naruszenia.

Tajemnica przedsiębiorstwa nie zastąpi innych praw

Tajemnica przedsiębiorstwa chroni poufność, ale nie daje monopolu na rozwiązanie znane publicznie. Jeżeli kluczowym aktywem jest wynalazek możliwy do odtworzenia po wprowadzeniu produktu na rynek, warto rozważyć ochronę patentową. Jeśli przewaga wynika z utworu, bazy danych lub oprogramowania, konieczne jest również prawidłowe uregulowanie praw autorskich i praw do rezultatów prac twórców.

Wybór między zachowaniem rozwiązania w tajemnicy a jego zgłoszeniem do ochrony formalnej zawsze zależy od rodzaju technologii, kosztów, ryzyka odtworzenia i planów ekspansji. Dobra praktyka polega na podjęciu tej decyzji przed publikacją, prezentacją inwestorską albo udostępnieniem produktu szerokiemu gronu testerów.

Najbardziej wiarygodna ochrona powstaje wtedy, gdy zarząd, dział prawny, IT i właściciele procesów działają według wspólnej reguły: informację ujawniamy tylko wtedy, gdy wiemy komu, po co, w jakim zakresie i na jakich warunkach. To właśnie taka codzienna dyscyplina najczęściej przesądza, czy tajemnica przedsiębiorstwa pozostanie aktywem, a nie materiałem dowodowym po kryzysie.

Ta różnica przesądza o skuteczności całego projektu. Blockchain może być warstwą technologiczną dla rejestru, komunikacji z inwestorami albo rozliczeń. Nie zastępuje jednak czynności prawnej wymaganej przez Kodeks spółek handlowych, postanowienia umowy spółki ani obowiązków regulacyjnych związanych z oferowaniem instrumentów finansowych.

Najpierw ustal, co właściwie ma reprezentować token

W języku biznesowym „tokenizacja udziałów” bywa używana dla kilku odmiennych modeli. Pierwszy polega na emisji tokenów, które ekonomicznie naśladują wartość udziałów, lecz nie dają ich posiadaczowi statusu wspólnika. Drugi zakłada, że token jest cyfrowym certyfikatem powiązanym z konkretnym udziałem. Trzeci ma prowadzić do tego, by przeniesienie tokena wywoływało zarazem skutek w postaci przeniesienia udziału.

Tylko ostatni model realizuje pełną tokenizację praw korporacyjnych. Jest też najtrudniejszy prawnie. W spółce z ograniczoną odpowiedzialnością nabywca staje się wspólnikiem wskutek ważnej umowy zbycia udziału oraz po spełnieniu wymogów ustawy i umowy spółki. Sam zapis w publicznym lub prywatnym blockchainie nie stanowi automatycznie ekwiwalentu tych wymogów.

Token może natomiast reprezentować inne prawa: wierzytelność z tytułu pożyczki, prawo do udziału w przychodach, uprawnienie informacyjne, prawo głosu w niewiążącym głosowaniu społeczności czy prawo nabycia udziałów w przyszłości. Każdy z tych wariantów wymaga osobnej kwalifikacji cywilnoprawnej i regulacyjnej. Nazwanie tokena „udziałowym” nie przesądza o jego charakterze.

Jak tokenizować udziały w spółce z o.o.

W polskiej spółce z o.o. udział jest prawem udziałowym wspólnika, a nie klasycznym papierem wartościowym. Jego zbycie, zastawienie lub użytkowanie wymaga formy pisemnej z podpisami notarialnie poświadczonymi. Umowa spółki może ponadto uzależniać zbycie od zgody spółki, zarządu albo zgromadzenia wspólników, przyznawać prawo pierwszeństwa lub wprowadzać inne ograniczenia.

To oznacza, że transfer tokena między portfelami nie może sam w sobie przenieść udziału, jeżeli nie towarzyszy mu czynność prawna w wymaganej formie. Smart contract może wspierać proces – przykładowo zablokować token do czasu podpisania dokumentów, odnotować zgodę organu spółki i uaktualnić stan technicznego rejestru – ale nie usuwa wymogu notarialnego poświadczenia podpisów.

Dodatkowo zarząd prowadzi księgę udziałów, a wobec spółki skuteczny jest co do zasady ten, kto został do niej wpisany po zawiadomieniu spółki o przejściu udziału i przedstawieniu dowodu czynności. Projekt tokenizacyjny powinien zatem jednoznacznie określać relację między blockchainem, dokumentacją transakcyjną oraz księgą udziałów. Jeżeli rozbieżności są możliwe, trzeba wskazać, który zapis ma znaczenie dla wykonywania praw korporacyjnych.

W praktyce rozsądniejszy bywa model hybrydowy. Token jest przypisany do udziału i pełni funkcję narzędzia ewidencyjno-informacyjnego, ale rozporządzenie udziałem odbywa się według procedury korporacyjnej i cywilnoprawnej. Nie jest to rozwiązanie tak efektowne marketingowo jak natychmiastowy obrót on-chain, lecz daje większą pewność prawną.

Prosta spółka akcyjna i spółka akcyjna

Inaczej wygląda sytuacja w prostej spółce akcyjnej. Akcje PSA nie mają formy dokumentu, a ich istnienie i przysługujące prawa są ujawniane w rejestrze akcjonariuszy. Ustawa dopuszcza prowadzenie tego rejestru z wykorzystaniem technologii rozproszonego rejestru. Nie oznacza to jednak pełnej dowolności wyboru rozwiązania ani automatycznego dopuszczenia każdego publicznego blockchaina jako rejestru akcjonariuszy.

Rejestr musi spełniać wymagania ustawowe, w tym dotyczące podmiotu prowadzącego rejestr, identyfikacji akcjonariuszy, ochrony danych i wykonywania obowiązków informacyjnych. Warto oddzielić te kwestie od technologicznej atrakcyjności tokena. Dobrze zaprojektowany rejestr DLT może być elementem struktury PSA, ale nie może działać poza regułami prawa spółek.

W spółce akcyjnej akcje są zdematerializowane i podlegają reżimowi rejestru akcjonariuszy albo depozytu papierów wartościowych, zależnie od statusu spółki. Tokenizacja akcji wymaga więc szczególnie ostrożnego zbadania infrastruktury rejestrowej, zasad obrotu oraz przepisów rynku kapitałowego.

Token udziałowy a MiCA i przepisy rynku kapitałowego

Rozporządzenie MiCA często pojawia się w dyskusjach o tokenizacji, lecz nie jest uniwersalną podstawą prawną dla każdego tokena. MiCA co do zasady nie obejmuje kryptoaktywów, które kwalifikują się jako instrumenty finansowe. Token dający prawa odpowiadające akcjom, udziałom lub innym instrumentom finansowym może wejść w zakres regulacji rynku kapitałowego, w tym przepisów wdrażających MiFID II oraz regulacji dotyczących ofert publicznych.

Kluczowa jest treść praw związanych z tokenem, sposób jego oferowania i jego zbywalność, a nie wyłącznie technologia emisji. Token oferowany szerokiemu kręgowi inwestorów, reklamowany jako inwestycja i umożliwiający udział w wynikach przedsięwzięcia będzie analizowany znacznie surowiej niż zamknięty instrument używany w relacji kilku znanych wspólników.

Jeżeli oferta ma charakter publiczny, trzeba ocenić obowiązki informacyjne, możliwość zastosowania wyjątków od obowiązku publikacji prospektu, zasady promocji inwestycji oraz zakres regulacji dotyczącej pośrednictwa. Fragmentacja jednego pakietu udziałów na tysiące tokenów może ułatwić dostęp do kapitału, ale może też zwiększyć ryzyko zakwalifikowania przedsięwzięcia jako regulowanej oferty inwestycyjnej.

Nie wolno też zakładać, że wyłączenie spod MiCA oznacza brak regulacji. Przeciwnie: w przypadku tokenów będących instrumentami finansowymi właściwy może być bardziej restrykcyjny reżim rynku kapitałowego.

Dokumentacja, governance i identyfikacja inwestorów

Tokenizacja jest projektem prawnym jeszcze przed wdrożeniem smart contractu. Umowa spółki, uchwały organów, regulamin emisji lub sprzedaży tokenów oraz warunki korzystania z platformy powinny opisywać ten sam model. Szczególnego doprecyzowania wymagają zasady przypisania tokena do udziału, wykonywania prawa głosu, wypłaty dywidendy, przymusowego wykupu, dziedziczenia, utraty dostępu do portfela i postępowania na wypadek błędu technicznego.

W dobrze zaprojektowanym modelu nie wystarczy zasada „kto kontroluje klucz prywatny, ten wykonuje prawa”. Prawo spółek operuje konkretną osobą wspólnika albo akcjonariusza, a spółka musi móc zidentyfikować uprawnionego, prowadzić rejestry i realizować obowiązki podatkowe. Konieczne są procedury KYC, a w zależności od roli uczestników także analiza obowiązków AML i sankcyjnych.

Trzeba również rozstrzygnąć, kto administruje kontraktem oraz czy może korygować błędne wpisy. Niezmienność blockchaina bywa zaletą dowodową, lecz w relacjach korporacyjnych absolutna nieodwracalność transakcji może stać się problemem. Utrata klucza, zajęcie egzekucyjne, śmierć wspólnika, błąd adresu portfela lub wykonanie prawomocnego orzeczenia wymagają procedury odzyskania kontroli albo aktualizacji rejestru.

Ryzyka, których nie rozwiąże technologia

Tokenizacja nie znosi ograniczeń umownych dotyczących zbywania udziałów ani konfliktów między wspólnikami. Nie zastępuje też badania prawa właściwego, gdy inwestor, emitent, portfel lub infrastruktura techniczna są powiązane z różnymi państwami. W takim układzie prawo prywatne międzynarodowe może przesądzić o właściwości prawa i sądu, a regulacje lokalne mogą wpływać na dopuszczalność marketingu oraz dystrybucji tokenów.

Od strony operacyjnej należy uwzględnić cyberbezpieczeństwo, kontrolę dostępu, audyt kodu i ochronę danych osobowych. Publiczny rejestr może ujawniać strukturę własności w stopniu nieakceptowalnym dla inwestorów. Z kolei prywatna sieć daje większą kontrolę, ale ogranicza deklarowaną otwartość i płynność obrotu.

Najbezpieczniejszą kolejnością jest najpierw opisanie praw, które inwestor ma uzyskać, następnie wybranie formy spółki i modelu obrotu, a dopiero potem dobór technologii. Warto przeprowadzić tę analizę przed pierwszą komunikacją sprzedażową. Koszt zmiany smart contractu jest zwykle niższy niż koszt naprawienia nieprawidłowo przeprowadzonej emisji lub sporu o status wspólnika.

Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554, znane jako DORA, nie tworzy jednego obowiązku, który można zamknąć wdrożeniem narzędzia do cyberbezpieczeństwa. Buduje raczej spójny model governance obejmujący zarządzanie, dokumentację, testowanie, reakcję na incydenty oraz relacje z zewnętrznymi dostawcami technologii. To właśnie ta systemowość jest największą zaletą regulacji, ale też źródłem jej kosztów i trudności wdrożeniowych.

Recenzja rozporządzenia DORA: regulacja o odpowiedzialności

DORA obejmuje szeroki katalog podmiotów finansowych, w tym banki, firmy inwestycyjne, zakłady ubezpieczeń, instytucje płatnicze, dostawców usług w zakresie kryptoaktywów oraz niektóre podmioty funkcjonujące w ramach infrastruktury rynku finansowego. Zakres zastosowania należy jednak ustalać indywidualnie. Sam fakt działania w branży fintech nie przesądza jeszcze o pełnym podleganiu rozporządzeniu, podobnie jak status małego przedsiębiorstwa nie eliminuje automatycznie wszystkich obowiązków.

Kluczowe jest przesunięcie perspektywy. DORA nie pyta wyłącznie, czy organizacja posiada politykę bezpieczeństwa, kopie zapasowe i umowę z dostawcą chmury. Pyta, czy te elementy tworzą mechanizm zdolny do utrzymania krytycznych usług finansowych podczas zakłócenia oraz czy organ zarządzający rzeczywiście rozumie ryzyka związane z technologią.

Odpowiedzialność organu zarządzającego została w rozporządzeniu ujęta wyraźnie. Zarząd ma określać, zatwierdzać, nadzorować i ponosić odpowiedzialność za ramy zarządzania ryzykiem ICT. Delegowanie zadań do działu IT, CISO lub zewnętrznego konsultanta może być operacyjnie rozsądne, lecz nie przenosi odpowiedzialności regulacyjnej. W praktyce wymusza to lepszy przepływ informacji między technologią, compliance, ryzykiem, bezpieczeństwem i biznesem.

Pięć filarów, które trzeba czytać łącznie

Konstrukcja DORA opiera się na pięciu wzajemnie zależnych obszarach. Pierwszym jest zarządzanie ryzykiem ICT. Instytucja powinna znać swoje aktywa informacyjne, systemy, zależności, procesy krytyczne oraz słabe punkty. Rejestr systemów sam w sobie nie wystarczy, jeśli nie pozwala ustalić, która usługa przestanie działać po awarii określonego komponentu lub dostawcy.

Drugim filarem jest zgłaszanie poważnych incydentów związanych z ICT. Regulacja wymaga procedur identyfikacji, klasyfikacji, eskalacji i raportowania. Organizacja musi więc wcześniej zdecydować, kto ocenia wagę incydentu, kto kontaktuje się z właściwym organem, jakie dane są zbierane i jak komunikacja z klientami pozostaje spójna z komunikacją nadzorczą. Chaos informacyjny po ataku ransomware lub awarii środowiska chmurowego może stanowić problem regulacyjny niezależnie od samej technicznej przyczyny zdarzenia.

Trzeci obszar to testowanie operacyjnej odporności cyfrowej. DORA wymaga testów proporcjonalnych do skali, profilu ryzyka i znaczenia podmiotu. Dla części instytucji wystarczą regularne testy podatności, scenariusze ciągłości działania czy ćwiczenia reagowania na incydenty. Najważniejsze podmioty mogą zostać objęte zaawansowanymi testami penetracyjnymi prowadzonymi z wykorzystaniem informacji o zagrożeniach, czyli TLPT.

Czwarty filar dotyczy wymiany informacji i informacji o cyberzagrożeniach. Rozporządzenie dostrzega, że izolowane organizacje reagują wolniej. Udział w zaufanych mechanizmach wymiany informacji może poprawić wykrywanie zagrożeń, ale wymaga ostrożności w zakresie tajemnicy zawodowej, ochrony danych, tajemnicy przedsiębiorstwa i reguł konkurencji.

Piątym, najbardziej wymagającym w praktyce, jest zarządzanie ryzykiem wynikającym z korzystania z usług ICT świadczonych przez dostawców zewnętrznych. To obszar, w którym DORA najmocniej ingeruje w dotychczasowe modele kontraktowania usług technologicznych.

Umowa z dostawcą nie może być już tylko dokumentem zakupowym

Wiele instytucji finansowych korzysta z usług chmurowych, systemów do obsługi płatności, narzędzi KYC, rozwiązań analitycznych, dostawców cyberbezpieczeństwa i podwykonawców utrzymujących starsze systemy. DORA nie zakazuje outsourcingu. Przeciwnie, przyjmuje go jako trwały element rynku. Nakazuje jednak sprawować nad nim kontrolę odpowiednią do ryzyka.

W praktyce oznacza to konieczność prowadzenia rejestru informacji o wszystkich umowach dotyczących usług ICT. Instytucja musi umieć wskazać dostawcę, rodzaj usługi, podwykonawców, miejsce przetwarzania danych, charakter wspieranych funkcji oraz znaczenie usługi dla działalności. Szczególnej oceny wymagają usługi wspierające funkcje krytyczne lub istotne.

DORA wymusza również przegląd klauzul kontraktowych. W umowach należy odpowiednio uregulować między innymi poziomy usług, wymogi bezpieczeństwa, zasady współpracy przy incydentach, dostęp do informacji, uprawnienia audytowe, warunki korzystania z podwykonawców oraz uporządkowane zakończenie współpracy. Najtrudniejsze bywają negocjacje z globalnymi dostawcami chmurowymi, którzy opierają relację na standardowych wzorcach umownych.

Nie oznacza to, że każda instytucja ma realną możliwość wynegocjowania dowolnego postanowienia. Znaczenie ma skala podmiotu, rodzaj usługi i jego pozycja negocjacyjna. Nie zwalnia to jednak z udokumentowania analizy ryzyka oraz z przygotowania strategii wyjścia. Strategia wyjścia nie powinna być deklaracją, że dane da się kiedyś przenieść. Musi odpowiadać na pytanie, ile potrwa migracja, kto ją przeprowadzi, jak zachować ciągłość działania i czy alternatywa w ogóle istnieje.

Co DORA robi dobrze, a gdzie pojawiają się ryzyka

Największą wartością DORA jest zastąpienie rozproszonego podejścia wspólnym językiem odporności cyfrowej. Regulacja łączy kwestie, które w wielu organizacjach funkcjonowały osobno: cyberbezpieczeństwo, outsourcing, ciągłość działania, nadzór korporacyjny i raportowanie incydentów. Dla grup kapitałowych działających w kilku państwach UE jest to szczególnie istotne, ponieważ ułatwia budowę wspólnych standardów.

DORA trafnie rozpoznaje też ryzyko koncentracji u niewielkiej liczby dużych dostawców ICT. Awaria dominującego dostawcy infrastruktury chmurowej może równocześnie zakłócić usługi wielu instytucji, nawet jeśli każda z nich z osobna spełnia podstawowe wymagania bezpieczeństwa. Stąd unijny mechanizm nadzoru nad krytycznymi zewnętrznymi dostawcami usług ICT.

Słabszą stroną regulacji jest jej ciężar organizacyjny. Podmiot o ograniczonych zasobach może odczuwać DORA przede wszystkim jako obowiązek tworzenia rejestrów, procedur, ocen i dowodów wykonania kontroli. Ryzyko formalizmu jest realne. Dobrze napisana polityka nie zmniejsza skutków incydentu, jeżeli nie została przećwiczona, a osoby odpowiedzialne nie znają swoich ról.

Dlatego zasada proporcjonalności powinna być stosowana rozsądnie, a nie jako wygodny argument za zaniechaniem. Mniejsza organizacja nie musi kopiować struktury banku systemowego. Powinna jednak umieć wykazać, dlaczego przyjęte zabezpieczenia, częstotliwość testów i model nadzoru nad dostawcą odpowiadają jej konkretnemu profilowi ryzyka.

Od czego zacząć wdrożenie

Najbardziej użytecznym pierwszym krokiem jest diagnoza, a nie zakup kolejnego systemu bezpieczeństwa. Należy zestawić wymogi DORA z faktycznym sposobem działania organizacji: usługami krytycznymi, architekturą systemów, incydentami z ostatnich lat, umowami ICT oraz aktualnym podziałem odpowiedzialności.

Następnie warto ustalić właścicieli poszczególnych działań i harmonogram usuwania luk. Część braków będzie miała charakter kontraktowy, inne proceduralny albo techniczny. Nie wszystkie należy usuwać w tej samej kolejności. Pierwszeństwo powinny mieć te obszary, w których zakłócenie może zatrzymać funkcję krytyczną, narazić klientów na szkodę lub uniemożliwić terminowe raportowanie.

Szczególnej uwagi wymaga dokumentowanie decyzji zarządczych. Przy kontroli liczy się nie tylko końcowy rezultat, lecz także możliwość wykazania, że podmiot rozpoznał ryzyko, ocenił warianty i podjął adekwatne działania. DORA premiuje organizacje, które potrafią przedstawić spójną historię swoich decyzji, zamiast gromadzić dokumenty dopiero po incydencie.

Najlepszym sprawdzianem przygotowania nie jest więc liczba przyjętych polityk. Warto postawić zespołowi konkretne pytanie: co wydarzy się jutro rano, jeśli kluczowy dostawca ICT utraci dostępność, a klienci zaczną zgłaszać problemy? Jeżeli odpowiedź wskazuje osoby, decyzje, dane i realny plan działania, compliance DORA zaczyna spełniać swoją właściwą funkcję.

AI Act, czyli rozporządzenie 2024/1689, ma zastosowanie bezpośrednio w państwach członkowskich UE. Większość jego zasad stosuje się od 2 sierpnia 2026 r. Część obowiązków weszła jednak w życie wcześniej: zakazy określonych praktyk i wymóg odpowiedniego poziomu kompetencji w zakresie AI obowiązują od 2 lutego 2025 r., a obowiązki dotyczące modeli AI ogólnego przeznaczenia – co do zasady – od 2 sierpnia 2025 r. Nie jest więc rozsądne traktowanie zgodności jako projektu, który można odłożyć do chwili kontroli.

Jak wdrożyć AI Act w firmie: najpierw ustal swoją rolę

Rozporządzenie nie nakłada identycznych obowiązków na każdego przedsiębiorcę korzystającego z technologii AI. Kluczowe znaczenie ma rola przedsiębiorstwa w łańcuchu wartości. Firma może być dostawcą, jeżeli rozwija system AI lub zleca jego rozwój i wprowadza go do obrotu pod własną nazwą. Może być podmiotem stosującym, gdy używa systemu pod swoją kontrolą zawodową. W określonych sytuacjach wystąpi też jako importer, dystrybutor albo upoważniony przedstawiciel.

Ta kwalifikacja ma skutki praktyczne. Bank wykorzystujący gotowy system do oceny zdolności kredytowej nie ma takich samych powinności jak podmiot, który ten system stworzył i sprzedaje innym instytucjom. Z kolei spółka, która istotnie zmienia przeznaczenie zakupionego rozwiązania albo wprowadza je do obrotu pod własną marką, może przejąć obowiązki dostawcy. Nazwa w umowie z dostawcą nie przesądza sprawy – liczy się rzeczywista kontrola nad produktem, jego przeznaczeniem i sposobem udostępnienia.

W praktyce jedna grupa kapitałowa może pełnić kilka ról naraz. Dział technologiczny tworzy model, spółka operacyjna stosuje go wobec klientów, a inna spółka dystrybuuje rozwiązanie na rynku. Wtedy governance AI musi przypisywać obowiązki konkretnym podmiotom i osobom, zamiast opierać się na ogólnym założeniu, że „grupa jest zgodna”.

Inwentaryzacja ma obejmować faktyczne użycie AI

Największym błędem jest audyt ograniczony do projektów formalnie zatwierdzonych przez IT. W wielu firmach AI trafia do procesów oddolnie: przez funkcje w pakietach biurowych, narzędzia do wideokonferencji, systemy CRM, programy graficzne czy aplikacje używane przez zewnętrznych wykonawców. Taka praktyka bywa określana jako shadow AI. Nie oznacza automatycznie naruszenia prawa, ale uniemożliwia świadome zarządzanie ryzykiem.

Rejestr systemów AI powinien odpowiadać nie tylko na pytanie, jakie oprogramowanie jest używane. Potrzebne są również informacje o celu biznesowym, użytkownikach, kategoriach osób, których dotyczą wyniki systemu, danych wejściowych, stopniu automatyzacji decyzji oraz dostawcy. Warto odnotować, czy wynik modelu jest jedynie materiałem pomocniczym, czy faktycznie wpływa na zatrudnienie, dostęp do usługi, cenę, ocenę wiarygodności albo bezpieczeństwo.

Dla każdego systemu należy też zabezpieczyć dokumenty kontraktowe i techniczne. W odniesieniu do rozwiązania zewnętrznego istotne będą w szczególności instrukcje użycia, deklaracje zgodności, informacje o ograniczeniach systemu, warunkach monitorowania i aktualizacjach. Jeżeli dostawca nie jest w stanie wyjaśnić przeznaczenia narzędzia ani jego klasyfikacji regulacyjnej, jest to sygnał ryzyka zakupowego, a nie wyłącznie problem działu prawnego.

Klasyfikacja ryzyka nie może być ćwiczeniem formalnym

AI Act opiera się na zróżnicowanym podejściu do ryzyka. Część praktyk jest zakazana, część systemów kwalifikuje się jako wysokiego ryzyka, a dla niektórych rozwiązań przewidziano przede wszystkim obowiązki przejrzystości. Poza tym zakresem pozostają systemy, które nadal mogą rodzić ryzyka na gruncie RODO, prawa pracy, ochrony konsumentów, prawa autorskiego, tajemnicy przedsiębiorstwa lub przepisów sektorowych.

W pierwszej kolejności firma powinna wykluczyć praktyki niedopuszczalne. Dotyczy to między innymi określonych form manipulacji, wykorzystywania szczególnej podatności osób, niektórych systemów oceny społecznej oraz pewnych zastosowań rozpoznawania emocji w miejscu pracy i placówkach edukacyjnych. Ocena wymaga ostrożności: marketingowe określenie funkcji jako „analizy zaangażowania” nie przesądza, że nie chodzi w istocie o analizę emocji.

Następnie należy sprawdzić, czy system nie mieści się w katalogu systemów wysokiego ryzyka. Praktyczne znaczenie mają zwłaszcza zastosowania w rekrutacji i zarządzaniu pracownikami, edukacji, ocenie kredytowej, dostępie do podstawowych usług prywatnych i publicznych, egzekwowaniu prawa czy migracji. System wspierający rekrutera w porządkowaniu aplikacji może wymagać innej analizy niż narzędzie automatycznie odrzucające kandydatów. Granica często zależy od funkcji systemu i wagi skutków dla osoby, a nie od deklarowanej obecności „człowieka w procesie”.

W przypadku systemów wysokiego ryzyka po stronie dostawcy pojawiają się między innymi wymogi zarządzania ryzykiem, jakości danych, dokumentacji technicznej, rejestrowania zdarzeń, nadzoru człowieka, dokładności, cyberbezpieczeństwa i oceny zgodności. Podmiot stosujący nie jest zwolniony z działania. Powinien używać systemu zgodnie z instrukcją, zapewnić właściwy nadzór ludzki, monitorować funkcjonowanie rozwiązania, przechowywać logi, gdy ma taki obowiązek lub kontrolę nad nimi, a także reagować na poważne incydenty.

Nie myl AI Act z pełnym audytem prawnym AI

Zgodność z AI Act nie zastępuje pozostałych analiz. To szczególnie widoczne przy generatywnej AI. Pracownik, który wprowadza do publicznego czatu fragment umowy, kod źródłowy lub nieopublikowane wyniki finansowe, może naruszyć obowiązek zachowania poufności albo zasady ochrony tajemnicy przedsiębiorstwa. Jeżeli prompt zawiera dane osobowe, potrzebna jest równoległa analiza na gruncie RODO, w tym podstawy przetwarzania, retencji i ewentualnego transferu danych poza Europejski Obszar Gospodarczy.

Również treść wygenerowana przez model nie jest prawnie neutralna. Materiał może naruszać prawa autorskie, dobra osobiste, znaki towarowe lub przepisy o czynach nieuczciwej konkurencji. W branżach regulowanych dochodzą wymogi sektorowe, na przykład dotyczące outsourcingu, zarządzania ryzykiem ICT, tajemnicy zawodowej czy komunikacji z klientem. Dobrze zaprojektowany program compliance powinien zatem łączyć AI Act z ochroną danych, cyberbezpieczeństwem, prawem własności intelektualnej i procedurami operacyjnymi.

Governance powinno decydować, a nie tylko dokumentować

Polityka korzystania z AI jest potrzebna, lecz sama nie wdraża rozporządzenia. Dokument, który zakazuje „podawania danych wrażliwych” i nakazuje „weryfikować odpowiedzi AI”, bez wskazania odpowiedzialnych osób oraz procedury eskalacji, pozostaje deklaracją.

Skuteczniejszy model opiera się na procesie. Każdy nowy przypadek użycia powinien przechodzić przez proporcjonalną kwalifikację: opis celu, rolę firmy, klasę ryzyka, dane, wpływ na osoby, dostawcę i wymagane zabezpieczenia. Dla narzędzia do redagowania wewnętrznych notatek wystarczy zwykle prostsza ścieżka. Dla systemu oceniającego kandydatów, klientów lub kontrahentów konieczna będzie pogłębiona analiza prawna, techniczna i biznesowa przed uruchomieniem.

Właściciel biznesowy powinien odpowiadać za zasadność celu i sposób użycia. IT oraz cyberbezpieczeństwo – za architekturę, dostęp, logowanie i zarządzanie dostawcą. Prawnicy oraz compliance – za kwalifikację obowiązków, dokumentację i zgodność z innymi reżimami prawnymi. Nie chodzi o mnożenie komitetów, lecz o to, by decyzja o wdrożeniu nie zapadała bez osoby, która może ocenić konsekwencje dla użytkownika, klienta i przedsiębiorstwa.

Kompetencje pracowników są obowiązkiem, ale szkolenie musi być konkretne

AI Act wymaga podejmowania środków zapewniających wystarczający poziom kompetencji w zakresie AI u personelu i innych osób działających w imieniu organizacji. Nie oznacza to jednego, identycznego szkolenia dla wszystkich. Innych kompetencji potrzebuje osoba tworząca model, innych rekruter korzystający z narzędzia wspomagającego selekcję, a jeszcze innych członek zarządu zatwierdzający wykorzystanie AI w procesie o dużym wpływie na klientów.

Szkolenie powinno obejmować ograniczenia modeli, ryzyko błędów i konfabulacji, zasady pracy z danymi, znaczenie nadzoru ludzkiego oraz obowiązek zgłaszania nieprawidłowości. W procesach wysokiego ryzyka konieczne są instrukcje operacyjne: kiedy pracownik może zaakceptować wynik, kiedy ma go zakwestionować i komu zgłosić podejrzenie dyskryminacji, błędu lub incydentu bezpieczeństwa. Warto utrwalać nie tylko udział w szkoleniu, ale także zakres przekazanych zasad.

Najlepszym momentem na wdrożenie AI Act nie jest dzień poprzedzający kontrolę ani publikacja kolejnej polityki. Jest nim chwila, w której firma chce użyć AI do decyzji mającej znaczenie dla człowieka, klienta albo rynku. Wtedy dobrze zadane pytania i właściwie przypisana odpowiedzialność są znacznie cenniejsze niż deklaracja, że organizacja „korzysta z AI odpowiedzialnie”.

W praktyce szczególne znaczenie ma to w projektach technologicznych. Ich wartość często nie wynika z bieżących przychodów, lecz z kodu, danych, praw własności intelektualnej, zespołu oraz zdolności do przeprowadzenia kolejnej rundy. Inwestor powinien więc badać nie tylko wycenę, ale również prawny „łańcuch tytułu” do kluczowych aktywów i zasady podejmowania decyzji w spółce.

Najlepsze zabezpieczenia prawne inwestora zaczynają się przed inwestycją

Najbardziej kosztowne spory inwestycyjne mają często źródło w zbyt powierzchownym due diligence. Przed objęciem udziałów lub akcji należy ustalić, kto rzeczywiście kontroluje spółkę, czy cap table odpowiada deklaracjom założycieli oraz czy istnieją opcje, warranty, konwertowalne pożyczki albo nieujawnione uzgodnienia dotyczące przyszłej emisji.

W spółce technologicznej konieczne jest także sprawdzenie praw do oprogramowania, znaków towarowych, domen, baz danych i rezultatów prac twórców. Kod napisany przez współpracownika B2B nie przechodzi automatycznie na spółkę tylko dlatego, że został opłacony. Podobnie korzystanie z komponentów open source może wiązać się z obowiązkami licencyjnymi, które są istotne dla późniejszej sprzedaży przedsiębiorstwa lub wejścia inwestora branżowego.

Badanie powinno objąć również umowy z kluczowymi klientami, kredytodawcami i dostawcami technologii, sprawy sądowe, ochronę danych osobowych, a w zależności od modelu biznesowego także regulacje sektorowe. Fintech, platforma wykorzystująca tokeny czy dostawca usług opartych na AI będą wymagać odmiennej analizy ryzyk compliance. Celem nie jest osiągnięcie abstrakcyjnej pewności, lecz rozpoznanie ryzyka, jego wycena i wpisanie właściwej odpowiedzi do dokumentacji transakcyjnej.

Dokumenty muszą działać na dwóch poziomach

Podstawowy błąd polega na umieszczeniu wszystkich uzgodnień wyłącznie w umowie wspólników lub akcjonariuszy. Taka umowa wiąże jej strony, ale nie zawsze zatrzyma czynność dokonaną przez organ spółki albo wspólnika wobec osoby trzeciej. Jeżeli inwestorowi zależy na trwałym ukształtowaniu praw udziałowych i reguł korporacyjnych, kluczowe rozwiązania powinny znaleźć odzwierciedlenie również w umowie spółki albo statucie.

W spółce z o.o. trzeba rozważyć zwłaszcza zasady zbywania udziałów, wymogi zgód korporacyjnych, uprzywilejowanie udziałów i kompetencje zgromadzenia wspólników. W prostej spółce akcyjnej oraz spółce akcyjnej instrumentarium może być bardziej elastyczne, ale nie zwalnia to z konieczności precyzyjnego opisania praw akcjonariuszy i mechanizmów emisji. Dobór formy prawnej nie powinien być decyzją estetyczną. Powinien wynikać z planowanego sposobu finansowania, modelu motywacyjnego dla zespołu i prawdopodobnej ścieżki exitowej.

Umowa inwestycyjna, umowa wspólników i akt korporacyjny muszą być ze sobą zgodne. W przeciwnym razie strona może dysponować roszczeniem odszkodowawczym, lecz nie uzyskać wpływu na zdarzenie, któremu chciała zapobiec.

Kontrola nad decyzjami, nie nad każdą decyzją

Prawa inwestora do współdecydowania zwykle przybierają formę katalogu spraw zastrzeżonych. Mogą obejmować emisję nowych udziałów lub akcji, zmianę budżetu, zaciągnięcie istotnego zadłużenia, sprzedaż aktywów IP, zmianę profilu działalności, transakcje z podmiotami powiązanymi czy zatrudnienie i odwołanie kluczowych członków zarządu.

Katalog nie może być jednak nadmiernie szeroki. Inwestor mniejszościowy, który wymaga zgody na zwykłe umowy handlowe, może faktycznie sparaliżować operacje spółki. To obniża jej wartość i rodzi napięcie z zespołem założycielskim. Dobrze zaprojektowane veto dotyczy decyzji zmieniających profil ryzyka lub strukturę ekonomiczną inwestycji, a nie bieżącego zarządzania.

Przydatne są również prawo powołania członka organu, obserwatora rady nadzorczej lub rady dyrektorów, jeżeli forma spółki na to pozwala, a także rozbudowane obowiązki informacyjne. Miesięczne raportowanie cash flow, wskaźników biznesowych, zobowiązań i istotnych incydentów prawnych pozwala reagować wcześniej niż po otrzymaniu rocznego sprawozdania finansowego. Sam dostęp do informacji nie zastępuje prawa głosu, ale bez informacji prawo głosu bywa iluzoryczne.

Ochrona ekonomiczna przy kolejnych rundach

Rozwodnienie udziału jest naturalnym skutkiem finansowania equity. Nie zawsze jest negatywne – mniejszy procent w istotnie bardziej wartościowej spółce może oznaczać lepszy wynik ekonomiczny. Inwestor powinien jednak wiedzieć, kiedy rozwodnienie wynika z uzasadnionej rundy, a kiedy z emisji przeprowadzonej na warunkach niekorzystnych dla dotychczasowych wspólników.

Prawo pierwszeństwa objęcia nowych udziałów lub akcji pozwala zachować proporcjonalny udział w kolejnych emisjach. Warto określić procedurę zawiadomienia, termin wykonania prawa, metodę ustalenia ceny oraz konsekwencje częściowego skorzystania z uprawnienia. Nieprecyzyjne prawo pierwszeństwa często zawodzi właśnie wtedy, gdy runda jest prowadzona pod presją czasu.

Klauzule antyrozwodnieniowe są bardziej ingerujące. Mogą korygować cenę konwersji lub liczbę instrumentów przysługujących inwestorowi, gdy kolejna runda odbywa się po niższej wycenie. Model pełnego ratchet chroni inwestora najsilniej, ale może wyjątkowo dotkliwie obciążyć założycieli i utrudnić pozyskanie nowego finansowania. Formuła ważonej średniej jest zwykle bardziej proporcjonalna. Wymaga jednak jasnego wskazania, jakie emisje są uwzględniane, a jakie wyłączone – na przykład program opcyjny dla pracowników lub akcje emitowane przy przejęciu innego podmiotu.

Innym narzędziem jest preferencja likwidacyjna. Określa ona, w jakiej kolejności i do jakiej wysokości inwestor otrzyma środki przy sprzedaży spółki, likwidacji lub zdarzeniu uznanym umownie za exit. Różnica między preferencją uczestniczącą a nieuczestniczącą oraz między jednokrotnością a wielokrotnością zainwestowanej kwoty ma fundamentalne znaczenie dla podziału ceny sprzedaży. Te postanowienia należy modelować liczbowo dla kilku wariantów wyceny, a nie akceptować na poziomie ogólnej deklaracji.

Założyciele, IP i utrzymanie wartości spółki

Inwestor inwestuje zwykle także w zdolność założycieli do realizacji projektu. Dlatego standardem jest vesting, czyli stopniowe nabywanie pełnego ekonomicznego prawa do udziałów przez founderów w czasie. Mechanizm powinien rozróżniać good leaver i bad leaver oraz precyzyjnie określać skutki odejścia, naruszenia zakazu konkurencji lub rażącego niewykonywania obowiązków.

Nie wystarczy przy tym ogólny zakaz konkurencji. Musi on być proporcjonalny, jasno zdefiniowany podmiotowo i przedmiotowo oraz skoordynowany z przepisami prawa pracy i prawem zobowiązań. Nadmiernie represyjna klauzula może być trudna do wyegzekwowania, a przede wszystkim odstraszać potrzebnych menedżerów.

Równie istotne są zapewnienia i oświadczenia składane przez spółkę oraz założycieli. Powinny obejmować między innymi prawdziwość danych finansowych, tytuł do IP, brak ukrytych zobowiązań, zgodność z prawem i kompletność ujawnionych informacji. Skuteczność tego mechanizmu zależy od precyzji odpowiedzialności: limitów, okresów dochodzenia roszczeń, wyjątków od limitów oraz procedury zgłaszania naruszeń. Bez tych elementów zapewnienia mogą pozostać deklaracją bez praktycznej wartości.

Wyjście z inwestycji trzeba uzgodnić, gdy strony są zgodne

Tag along chroni inwestora mniejszościowego, pozwalając mu przyłączyć się do sprzedaży udziałów lub akcji przez większościowego wspólnika na tych samych warunkach. Drag along służy z kolei przeprowadzeniu sprzedaży całej spółki, gdy transakcję popiera określona większość. Oba mechanizmy wymagają dopracowania ceny, procedury zawiadomień, zasad reprezentacji, odpowiedzialności sprzedających oraz ochrony przed nierównym traktowaniem.

Szczególnej ostrożności wymaga drag along. Nie powinien umożliwiać większości przerzucenia na mniejszość nieproporcjonalnych gwarancji, zakazów konkurencji czy odpowiedzialności wykraczającej poza otrzymaną cenę. Inwestor powinien także ocenić, czy umowa przewiduje rozwiązanie patowe. Deadlock między założycielem a inwestorem może wymagać mediacji, mechanizmu wykupu lub z góry określonej ścieżki decyzyjnej. Nie ma jednego właściwego modelu, ponieważ zależy on od struktury własności, etapu projektu i siły negocjacyjnej stron.

Dobra dokumentacja inwestycyjna nie polega na maksymalnym ograniczaniu założycieli. Polega na takim podziale ryzyka, który pozwala im szybko rozwijać produkt, a inwestorowi chronić kapitał w sytuacjach naprawdę krytycznych. Przed podpisaniem dokumentów warto przeprowadzić symulację kilku zdarzeń: kolejnej rundy po niższej wycenie, odejścia foundera, sprzedaży spółki i sporu o kluczowe IP. To właśnie w tych scenariuszach widać, czy klauzule zapewniają ochronę, czy tylko dobrze wyglądają w term sheetcie.

Dla założycieli, działów compliance i inwestorów kluczowe pytanie brzmi nie „czy to jest token?”, lecz „jakie skutki prawne wywołuje jego oferowanie, obrót i używanie?”. Odpowiedź może prowadzić do reżimu rozporządzenia MiCA, przepisów o instrumentach finansowych, regulacji usług płatniczych, obowiązków AML albo prawa konsumenckiego. Czasem kilka tych porządków działa równolegle.

Dlaczego nazwa tokenu nie przesądza o kwalifikacji

W dokumentach projektowych często pojawiają się określenia takie jak token użytkowy, token społecznościowy czy token inwestycyjny. Mają one znaczenie komunikacyjne, lecz nie rozstrzygają kwalifikacji prawnej. Organ nadzoru, sąd lub kontrahent będzie badać rzeczywistą treść praw i obowiązków, a nie marketingową deklarację emitenta.

Jeżeli token daje prawo do udziału w przyszłych przychodach, wypłaty zysku, wykupu po określonej cenie albo współdecydowania o przedsiębiorstwie, może wykazywać cechy instrumentu finansowego. Jeżeli ma służyć przede wszystkim jako środek wymiany lub zachowywania wartości, trzeba rozważyć jego status na gruncie MiCA, a w szczególnych przypadkach także regulacji płatniczych. Token uprawniający wyłącznie do skorzystania z jeszcze niedostępnej usługi również nie jest automatycznie wolny od ryzyk – znaczenie ma między innymi skala oferty, komunikacja z nabywcami i faktyczna użyteczność w chwili emisji.

Prawna kwalifikacja nie jest jednorazowym testem. Token, który początkowo umożliwia dostęp do konkretnej funkcji aplikacji, może zmienić profil ryzyka po wprowadzeniu mechanizmu odkupu, stakingu, wtórnego obrotu lub obietnicy korzyści ekonomicznych. Z perspektywy governance oznacza to potrzebę kontroli zmian produktu po starcie, a nie wyłącznie przed jego premierą.

Ocena ryzyka prawnego tokenu: od funkcji do reżimu prawnego

Rzetelna analiza powinna zaczynać się od mapy praw wynikających z tokenu. Należy ustalić, co dokładnie otrzymuje nabywca i od kogo może dochodzić wykonania świadczenia. Czy ma roszczenie wobec emitenta? Czy token zapewnia dostęp do usługi, rabat, prawo głosu, udział w aktywach, wynagrodzenie za aktywność w sieci albo prawo do umorzenia?

Równie istotna jest odpowiedź na pytanie, skąd ma pochodzić wartość tokenu. Jeżeli komunikacja projektu akcentuje wzrost ceny, pasywny dochód albo działania zespołu mające zwiększyć rentowność przedsięwzięcia, ryzyko zakwalifikowania produktu jako instrumentu finansowego wyraźnie rośnie. Nie usuwa go zastrzeżenie, że token „nie stanowi inwestycji”, gdy jego ekonomiczny przekaz sugeruje coś przeciwnego.

Następnie trzeba zidentyfikować emitenta oraz podmioty faktycznie uczestniczące w operacji. W zdecentralizowanych projektach często rozdziela się role między fundację, spółkę rozwijającą oprogramowanie, operatora interfejsu, twórców smart kontraktów i podmiot prowadzący marketing. Taki podział nie zwalnia automatycznie z odpowiedzialności. Przeciwnie, może utrudniać wskazanie podmiotu zobowiązanego wobec użytkownika oraz ocenę, kto prowadzi działalność regulowaną.

Analiza obejmuje także geograficzny zasięg oferty. Dostępność strony po angielsku, możliwość nabycia tokenu przez obywatela UE czy kampania skierowana do polskiej społeczności mogą mieć znaczenie przy ustalaniu, czy projekt jest oferowany na rynku unijnym. W projektach transgranicznych dochodzą pytania o prawo właściwe, jurysdykcję oraz egzekwowalność regulaminu. Prawo prywatne międzynarodowe nie jest tu dodatkiem do dokumentacji, lecz elementem konstrukcji ryzyka.

MiCA nie obejmuje wszystkiego, ale zmienia punkt wyjścia

Rozporządzenie MiCA ustanawia ramy dla kryptoaktywów, które nie są objęte istniejącymi regulacjami unijnymi dotyczącymi usług finansowych. W praktyce oznacza to konieczność sprawdzenia, czy token należy do jednej z kategorii kryptoaktywów regulowanych przez MiCA, w szczególności tokenów powiązanych z aktywami, tokenów będących e-pieniądzem lub pozostałych kryptoaktywów.

Dla emitenta istotne są między innymi zasady sporządzania i publikowania dokumentu informacyjnego, wymogi co do jego treści, uczciwa i jasna komunikacja marketingowa oraz odpowiedzialność za informacje przedstawiane odbiorcom. W zależności od rodzaju tokenu i modelu emisji pojawiają się również dalej idące obowiązki organizacyjne, kapitałowe i dotyczące rezerw.

Nie należy jednak traktować MiCA jako prostego „zezwolenia na tokenizację”. Jeżeli dany token jest instrumentem finansowym, pierwszeństwo mają właściwe regulacje rynku kapitałowego. Wtedy mogą aktualizować się między innymi zagadnienia prospektowe, zasady oferowania instrumentów finansowych, wymogi dla firm inwestycyjnych oraz regulacje dotyczące obrotu. Błędne przyjęcie, że MiCA stanowi jedyny reżim, jest jednym z najpoważniejszych błędów projektowych.

Dokumentacja musi odpowiadać produktowi, nie narracji sprzedażowej

White paper, regulamin sprzedaży, warunki korzystania z platformy, polityka token allocation i materiały promocyjne powinny tworzyć spójny system. Rozbieżność między nimi może być źródłem odpowiedzialności cywilnej, problemów z nadzorem lub sporów z nabywcami.

Szczególnej ostrożności wymaga język używany w komunikacji. Sformułowania o „gwarantowanym zwrocie”, „bezpiecznej lokacie”, „pewnym wzroście” czy „udziale w sukcesie projektu” bywają ryzykowne nawet wtedy, gdy znajdują się wyłącznie w postach społecznościowych lub prezentacji przygotowanej dla partnerów. Ryzyko zwiększa się, gdy emitent jednocześnie ogranicza odpowiedzialność w regulaminie, lecz buduje oczekiwania finansowe w reklamie.

Dokumentacja powinna jasno określać techniczne i prawne ograniczenia tokenu. Warto precyzyjnie opisać zasady emisji, podaż, uprawnienia administratora smart kontraktu, możliwość zamrożenia transferów, warunki odkupu, zasady spalania tokenów i ryzyka utraty dostępu do portfela. Nie są to wyłącznie kwestie techniczne. Każda z tych funkcji wpływa na rozkład kontroli, oczekiwania nabywcy i ocenę charakteru produktu.

Ryzyka poza kwalifikacją regulacyjną

Prawidłowa kwalifikacja tokenu nie kończy analizy. Projekt może nadal naruszać przepisy o przeciwdziałaniu praniu pieniędzy i finansowaniu terroryzmu, ochronie konsumentów, danych osobowych, prawie podatkowym albo ochronie własności intelektualnej.

Jeżeli model obejmuje przechowywanie kryptoaktywów klientów, wykonywanie zleceń, wymianę tokenów lub prowadzenie platformy obrotu, trzeba odrębnie zbadać, czy działalność stanowi usługę w zakresie kryptoaktywów oraz jakie wymogi organizacyjne wynikają z MiCA. Z kolei sprzedaż tokenów osobom fizycznym może aktywować zagadnienia prawa konsumenckiego, zwłaszcza przejrzystości warunków, prawa odstąpienia i zakazu klauzul abuzywnych. Ocena zależy od konstrukcji konkretnej oferty, a nie od tego, czy płatność następuje w kryptowalucie.

W projektach opartych na NFT lub tokenizacji treści warto też ustalić, co jest przedmiotem nabycia. Token może potwierdzać zapis w blockchainie, ale sam przez się zwykle nie przenosi autorskich praw majątkowych ani prawa do znaku towarowego. Jeżeli takie uprawnienia mają przejść na nabywcę, wymaga to odpowiedniej podstawy kontraktowej i precyzyjnego określenia pól eksploatacji.

Jak zaplanować analizę przed emisją

Największą wartość daje ocena wykonana przed publicznym ogłoszeniem parametrów emisji. Na tym etapie można jeszcze zmienić mechanizm ekonomiczny, ograniczyć prawa tokenariuszy, poprawić komunikację albo rozdzielić funkcje między podmioty w sposób zgodny z prawem i realiami biznesowymi.

Praktyczny proces obejmuje zwykle opis modelu biznesowego, analizę funkcji tokenu, kwalifikację regulacyjną, przegląd przepływów pieniężnych i tokenowych, ocenę grupy docelowej oraz audyt dokumentów i przekazów marketingowych. Równolegle warto przygotować rejestr ryzyk z przypisaniem właścicieli, terminów i decyzji wymagających akceptacji zarządu. Samo wskazanie ryzyka bez decyzji, kto ma je ograniczyć, nie jest compliance.

Nie każdy token wymaga takiego samego nakładu pracy. Zamknięty token dostępowy używany w ograniczonym środowisku będzie oceniany inaczej niż token sprzedawany szerokiej publiczności z perspektywą notowania na platformach obrotu. Różnica nie polega jednak na stopniu formalności nazwy projektu, lecz na rzeczywistym ryzyku dla nabywcy i rynku.

Przed uruchomieniem sprzedaży warto postawić jedno niewygodne pytanie: czy dokumenty, kod i marketing mówią o tym samym produkcie? Jeżeli odpowiedź nie jest jednoznacznie twierdząca, emisję lepiej wstrzymać na czas korekty. Koszt tej decyzji jest zwykle niższy niż koszt późniejszego sporu z inwestorami, nadzorem lub własną społecznością.

Nie istnieje jedna ustawa, która rozstrzyga legalność zbioru treningowego. Ocena wymaga jednoczesnego uwzględnienia prawa autorskiego, RODO, przepisów o tajemnicy przedsiębiorstwa, ochronie baz danych, treści umów oraz obowiązków wynikających z AI Act. W praktyce znaczenie ma także rola podmiotu: inne ryzyka ponosi dostawca modelu ogólnego przeznaczenia, a inne spółka wdrażająca zamknięty system do analizy własnych dokumentów.

Dane treningowe AI: problem zaczyna się przed treningiem

Pojęcie danych treningowych obejmuje znacznie więcej niż pliki, które trafiają do procesu uczenia. Są to również metadane, etykiety tworzone przez anotatorów, prompty, dane walidacyjne i testowe, logi interakcji użytkowników oraz dane używane przy późniejszym dostrajaniu modelu. Każda z tych warstw może mieć odrębne pochodzenie i odmienny reżim prawny.

Samo pobranie materiału z internetu nie tworzy prawa do jego komercyjnego wykorzystania. Dostępność publiczna oznacza co najwyżej, że treść była technicznie osiągalna. Nie przesądza o istnieniu licencji, zgodzie na przetwarzanie danych osobowych ani o braku zastrzeżenia praw przez uprawnionego. Szczególnie ryzykowne jest utożsamianie braku technicznych zabezpieczeń strony z dorozumionym przyzwoleniem na masowe pozyskiwanie jej zawartości.

Warto też rozdzielić dwa etapy, które bywają traktowane jako jeden proces. Pierwszy to pozyskanie i sporządzenie kopii materiałów. Drugi to korzystanie z wytrenowanego modelu, w tym jego dystrybucja, udostępnianie przez API oraz generowanie wyników. Legalność pierwszego etapu nie gwarantuje bezpieczeństwa drugiego, ale nieprawidłowość przy pozyskaniu danych może obciążyć cały projekt już od początku.

Prawa autorskie i eksploracja tekstów oraz danych

Teksty, fotografie, grafiki, nagrania, kod źródłowy czy artykuły prasowe mogą stanowić utwory chronione prawem autorskim. Proces treningowy zwykle wymaga ich kopiowania, konwersji, indeksowania i analizy. To właśnie te czynności, a nie tylko ewentualne podobieństwo wyniku modelu do konkretnego utworu, powinny być przedmiotem analizy.

Prawo Unii Europejskiej przewiduje wyjątki dotyczące eksploracji tekstów i danych, określane skrótem TDM. Nie są one jednak blankietową zgodą na trenowanie dowolnego systemu na wszystkim, co można znaleźć online. Dla przedsięwzięć komercyjnych kluczowe są zgodny z prawem dostęp do materiału oraz możliwość zastrzeżenia korzystania przez uprawnionego. W środowisku internetowym takie zastrzeżenie powinno być dokonane w sposób maszynowo odczytywalny, ale jego ocena może wymagać analizy konkretnego serwisu, pliku lub repozytorium.

Inaczej wygląda sytuacja instytucji prowadzących badania naukowe w rozumieniu właściwych przepisów, a inaczej startupu budującego komercyjny model generatywny. Przedsiębiorca nie powinien automatycznie przenosić na swoją działalność wyjątków przewidzianych dla badań naukowych. Istotna bywa także treść regulaminu serwisu, warunków licencji open source lub umowy z dostawcą danych. Umowa może określać zakres dozwolonego korzystania, sposób przypisania autorstwa, zakaz dalszego udostępniania albo obowiązek usunięcia danych po zakończeniu współpracy.

Szczególnej ostrożności wymaga kod. Licencja pozwalająca na wgląd w repozytorium nie zawsze pozwala na wykorzystanie kodu jako materiału treningowego, a warunki licencji mogą wiązać się z obowiązkami przy późniejszej dystrybucji. Nie można przy tym zakładać, że statystyczny charakter modelu automatycznie usuwa problem prawnoautorski. Ocena zależy od architektury systemu, sposobu retencji danych, możliwości odtwarzania fragmentów oraz rzeczywistego wykorzystania materiału w procesie.

RODO: dane dostępne publicznie nadal są danymi osobowymi

Profile zawodowe, komentarze, wpisy w mediach społecznościowych, nagrania i zdjęcia twarzy często zawierają dane osobowe. Ich publiczna dostępność nie wyłącza stosowania RODO. Jeżeli podmiot decyduje o celach i sposobach użycia tych danych do treningu, będzie co do zasady administratorem, nawet gdy dane zostały zebrane przez zewnętrznego dostawcę.

Projekt powinien zacząć się od ustalenia celu przetwarzania i podstawy prawnej. Zgoda rzadko jest realistyczna przy masowych zbiorach, lecz powołanie się na prawnie uzasadniony interes również nie działa automatycznie. Wymaga zidentyfikowania interesu, oceny konieczności przetwarzania i wyważenia go z prawami osób, których dane dotyczą. Znaczenie mają skala zbioru, rozsądne oczekiwania użytkownika, charakter danych oraz ryzyko ich ujawnienia przez model.

Dane szczególnych kategorii, takie jak informacje o zdrowiu, poglądach politycznych, pochodzeniu etnicznym czy biometrii, podnoszą poprzeczkę istotnie wyżej. W wielu przypadkach ich usunięcie lub skuteczne wykluczenie będzie rozsądniejszym rozwiązaniem niż budowanie skomplikowanej konstrukcji prawnej. Jeżeli projekt może powodować wysokie ryzyko dla praw i wolności osób fizycznych, konieczna może być ocena skutków dla ochrony danych, czyli DPIA.

W praktyce częstym błędem jest określanie jako anonimizacji prostego usunięcia imion i adresów e-mail. Dane pozostają osobowe, jeśli można osobę zidentyfikować po połączeniu cech, kontekstu albo z użyciem informacji dostępnych u innych podmiotów. Pseudonimizacja zmniejsza ryzyko, ale nie wyprowadza danych poza RODO.

Tajemnica przedsiębiorstwa, bazy danych i obowiązki kontraktowe

Firma trenująca system na własnych dokumentach powinna oceniać nie tylko swoje prawa do ich użycia, lecz także interesy kontrahentów i pracowników. Oferty handlowe, korespondencja, dokumentacja techniczna, listy klientów i dane o cenach mogą zawierać tajemnicę przedsiębiorstwa. Przekazanie ich zewnętrznemu dostawcy AI, nawet w celu testowym, może stanowić ujawnienie informacji osobie trzeciej.

Ochrona bazy danych może istnieć niezależnie od praw autorskich do pojedynczych rekordów. Masowe pobieranie istotnej części bazy lub powtarzalne pobieranie jej nieistotnych części może naruszać prawo producenta bazy. Osobnym źródłem ograniczeń są umowy: NDA, umowy licencyjne, postanowienia o poufności, regulaminy platform oraz umowy powierzenia przetwarzania danych.

Nie wystarczy zatem zapytać, czy spółka „ma dane”. Należy ustalić, czy ma prawo użyć ich do nowego, analitycznego celu, czy może przekazać je dalej, gdzie będą przechowywane oraz czy dostawca usługi nie wykorzysta ich do własnego treningu. Odpowiedź zależy od treści konkretnej umowy i konfiguracji usługi, a nie od marketingowej nazwy produktu AI.

AI Act nie legalizuje zbioru treningowego

Rozporządzenie AI Act wprowadza obowiązki dotyczące jakości danych, zarządzania ryzykiem i przejrzystości, ale nie zastępuje prawa autorskiego ani RODO. Zgodność z AI Act nie jest więc argumentem, że dane zostały pozyskane legalnie. Przeciwnie, regulacja wymusza bardziej uporządkowane podejście do dokumentowania źródeł i procesu zarządzania danymi.

W systemach wysokiego ryzyka dane treningowe, walidacyjne i testowe powinny podlegać odpowiednim praktykom governance. Chodzi między innymi o projektowanie zbiorów pod kątem relewantności, reprezentatywności, możliwych błędów i uprzedzeń. Nie jest to nakaz osiągnięcia abstrakcyjnie „neutralnego” zbioru, lecz obowiązek świadomego zarządzania ryzykami, które mogą prowadzić do dyskryminujących lub nierzetelnych rezultatów.

Dostawcy modeli AI ogólnego przeznaczenia mają dodatkowo obowiązek wdrożenia polityki zgodności z unijnym prawem autorskim oraz sporządzenia wystarczająco szczegółowego publicznego streszczenia treści użytych do treningu. Streszczenie nie oznacza publikacji kompletnego zbioru ani listy każdego utworu, ale nie może być wyłącznie ogólnikową deklaracją. Dla nabywców modeli jest to również sygnał, by badać dokumentację dostawcy przed włączeniem jego narzędzia do procesu biznesowego.

Jak przeprowadzić ocenę przed rozpoczęciem projektu

Najlepszy moment na ocenę prawną przypada przed pierwszym masowym pobraniem danych. Po treningu usunięcie wadliwie pozyskanego zbioru może nie wystarczyć, zwłaszcza gdy model został już rozpowszechniony lub gdy nie da się technicznie ustalić wpływu konkretnych danych na jego parametry.

Praktyczna analiza powinna objąć co najmniej cztery obszary:

• pochodzenie danych, ich właściciela, licencję, warunki dostępu i ewentualne zastrzeżenia TDM;
• występowanie danych osobowych, danych wrażliwych, tajemnicy przedsiębiorstwa oraz danych objętych ograniczeniami umownymi;
• architekturę przepływu danych, w tym lokalizację przetwarzania, podwykonawców, retencję, możliwość usunięcia i użycie danych przez dostawcę;
• dokumentację decyzji, ocenę ryzyka, zasady kontroli jakości oraz procedurę reagowania na żądania osób, twórców i kontrahentów.

Taka dokumentacja ma znaczenie nie tylko obronne. Ułatwia negocjowanie umów z dostawcami, przygotowanie informacji dla inwestora, przeprowadzenie audytu due diligence oraz zmianę technologii bez utraty kontroli nad materiałem źródłowym. W organizacjach regulowanych powinna być elementem szerszego systemu compliance, a nie jednorazową opinią przygotowaną tuż przed premierą produktu.

Dobrze zbudowany rejestr źródeł danych często staje się ważniejszy niż sam deklarowany rozmiar zbioru. Pozwala bowiem wykazać, że model rozwijano na materiale, którego pochodzenie, ograniczenia i ryzyka są rzeczywiście znane – a właśnie ta wiedza daje przedsiębiorcy przestrzeń do odpowiedzialnego rozwoju AI.