Licencjonowanie modeli AI i danych treningowych: prawa autorskie, komercjalizacja i ryzyka prawne

Gdy firma chce wdrożyć AI: od czego naprawdę zależy legalność użycia modelu

Wdrożenie sztucznej inteligencji w organizacji rzadko sprowadza się do prostej decyzji zakupowej. Przedsiębiorstwa często zakładają, że opłacenie subskrypcji lub pobranie modelu z otwartego repozytorium rozwiązuje kwestie formalne. W praktyce status prawny całego procesu zależy od wielu nakładających się na siebie reżimów prawnych.

Ryzyko naruszenia prawa nie ogranicza się wyłącznie do bezpośredniego złamania warunków jednej umowy. Obejmuje ono potencjalne roszczenia z tytułu praw autorskich, naruszenia tajemnicy przedsiębiorstwa, bezprawnego przetwarzania danych osobowych oraz niedopełnienia obowiązków regulacyjnych. Prawidłowa ocena legalności wymaga dekompozycji narzędzia AI na poszczególne elementy składowe.

Jeden model, kilka warstw praw i kilka podmiotów odpowiedzialnych

Licencja na korzystanie z aplikacji lub interfejsu programistycznego (API) nie przesądza automatycznie o prawach do samego modelu, danych użytych do jego wytrenowania ani generowanych rezultatów. Każdy z tych elementów może podlegać odrębnym reżimom prawnym i należeć do innego podmiotu.

W typowym systemie opartym na sztucznej inteligencji należy wyodrębnić co najmniej sześć podstawowych warstw:

• Model bazowy: architektura sieci neuronowej oraz wyuczone parametry będące wynikiem pierwotnego treningu na ogromnych zbiorach danych.
• Kod źródłowy: oprogramowanie służące do uruchomienia, optymalizacji, serwowania i integracji modelu z infrastrukturą techniczną.
• Wagi modelu (model weights): wartości liczbowe określające siłę połączeń między neuronami, które determinują zachowanie i odpowiedzi systemu.
• Zbiory danych treningowych: zasoby tekstowe, graficzne, audiowizualne lub tabelaryczne wykorzystane na etapie pre-treningu, dostrajania (fine-tuning) lub wyrównywania (alignment).
• Dane wejściowe (input / prompty): zapytania, dokumenty, fragmenty kodu lub polecenia wprowadzane przez użytkownika końcowego.
• Dane wyjściowe (output): treść, grafika, kod lub decyzje wygenerowane przez system w odpowiedzi na prompt.

Inne ryzyka prawne powstają przy korzystaniu z gotowego narzędzia w modelu Software as a Service (SaaS), inne przy uruchamianiu modelu we własnej infrastrukturze (on-premise lub private cloud), a zupełnie inne w sytuacji, gdy organizacja decyduje się na dotrenowanie istniejącego modelu własnymi zasobami informacyjnymi.

Rozbieżność ryzyk dobrze obrazuje typowa sytuacja w przedsiębiorstwie. Gdy dział marketingu generuje wpisy na bloga w publicznym portalu webowym, główne ryzyko dotyczy ujawnienia planów produktowych w promptach oraz braku ochrony prawnoautorskiej wygenerowanego tekstu. Gdy jednak dział IT integruje komercyjny model językowy przez API z systemem obsługi klienta i bazą CRM, pojawia się problem legalności powierzenia danych osobowych, retencji zapytań przez dostawcę, gwarancji dostępności oraz odpowiedzialności za błędne odpowiedzi udzielane konsumentom.

Licencja na model AI: co wolno zrobić z kodem, wagami i usługą

Pojęcie „licencji na sztuczną inteligencję” bywa mylące, ponieważ w obrocie gospodarczym występują radykalnie różne formy udostępniania tych technologii. Korzystanie z usługi chmurowej nie jest tożsame z nabyciem praw do korzystania z wag modelu na własnym serwerze.

Regulamin serwisu SaaS reguluje wyłącznie zasady dostępu do usługi świadczonej drogą elektroniczną. Z kolei licencja na model określa zakres uprawnień do pliku z wagami i architektury, determinując m.in. możliwość ich modyfikacji, dalszego rozpowszechniania czy wykorzystania w produktach komercyjnych.

Modele zamknięte, otwarte i „open-weight” — pojęcia, których nie należy utożsamiać

W dyskursie technologicznym i biznesowym modele AI często określa się mianem „open source”, co w wielu przypadkach jest nieścisłością wprowadzającą w błąd zespoły prawne. Klasyczna definicja Open Source Initiative (OSI) wymaga udostępnienia pełnego kodu źródłowego, narzędzi budowy oraz swobody dowolnego wykorzystania i modyfikacji bez ograniczeń dyskryminacyjnych.

Większość modeli określanych marketingowo jako otwarte to w rzeczywistości modele typu open-weight. Ich twórcy publikują pliki z wagami sieci, lecz zachowują w tajemnicy kod użyty do trenowania, architekturę pipeline’u danych oraz same zbiory treningowe.

Co istotne, licencje towarzyszące tym modelom zawierają ograniczenia, które wykluczają je z kategorii tradycyjnego open source. Dotyczy to m.in. zakazów stosowania modelu w wybranych branżach, progów liczby użytkowników komercyjnych czy zakazów wykorzystywania wygenerowanych danych do trenowania innych, konkurencyjnych systemów.

Warunki komercyjnego użycia, modyfikacji i redystrybucji

Analizując licencję modelu lub biblioteki AI, należy w pierwszej kolejności sprawdzić występowanie klauzul typu Acceptable Use Policy (AUP) lub Responsible AI Licenses (RAIL). Warunki te wprowadzają zakazy użycia w określonych sektorach, np. medycznym, prawniczym, wojskowym, w automatycznym podejmowaniu decyzji finansowych lub w infrastrukturze krytycznej.

Drugim istotnym elementem są klauzule zakazu konkurencji technologicznej. Wielu dostawców modeli open-weight zabrania wykorzystywania wyników generowanych przez ich model do trenowania, destylacji lub ulepszania innych modeli sztucznej inteligencji. Naruszenie tego zapisu może skutkować natychmiastowym wygaśnięciem licencji i roszczeniami o odszkodowanie.

Kolejnym obszarem są warunki redystrybucji zmodyfikowanych wersji (tzw. wag pochodnych, adapterów LoRA czy checkpointów po fine-tuningu). Licencje mogą nakładać obowiązek:

• Publikowania zmodyfikowanych wag na tej samej licencji (mechanizm copyleft).
• Wyraźnego oznaczania, że model został zmodyfikowany względem oryginału.
• Zachowania wszystkich not prawnych i ograniczeń AUP narzuconych przez pierwotnego twórcę.
• Umieszczania informacji o użyciu modelu w dokumentacji lub interfejsie produktu końcowego.

W przypadku integracji przez API kluczowe znaczenie mają zapisy dotyczące praw dostawcy do zapytań użytkownika. Regulaminy darmowych narzędzi z reguły przyznają dostawcy prawo do wykorzystywania promptów i danych wyjściowych do ulepszania usług i dalszego trenowania systemów. W wersjach komercyjnych (Enterprise) standardem powinna być klauzula zero data retention lub gwarancja niewykorzystywania danych klienta do celów szkoleniowych.

Przed wdrożeniem modelu technologia musi przejść weryfikację pod kątem zgodności wersji. Twórcy modeli regularnie aktualizują licencje między kolejnymi iteracjami (np. przejście z wersji v1 na v2 może wiązać się z całkowitą zmianą zasad komercjalizacji). Sprawdzenie samej nazwy licencji nie wystarcza – konieczna jest analiza konkretnego dokumentu prawnego przypisanego do danej wersji wag.

Dane treningowe a prawa autorskie, tajemnica przedsiębiorstwa i dane osobowe

Najwięcej sporów prawnych na styku technologii i prawa generuje proces pozyskiwania i przetwarzania danych treningowych. Budowa zaawansowanego modelu wymaga milionów tekstów, obrazów lub nagrań, z których większość stanowi utwory w rozumieniu prawa autorskiego.

Samo legalne wejście w posiadanie kopii utworu nie oznacza uprawnienia do jego swobodnego wykorzystania w procesie trenowania sztucznej inteligencji. Przetwarzanie danych na potrzeby uczenia maszynowego wiąże się ze zwielokrotnianiem utworów, ekstrakcją cech oraz tworzeniem reprezentacji wektorowych, co wkracza w monopol autorski twórców.

Legalne pozyskanie danych nie zawsze oznacza swobodę użycia ich do treningu

W prawie europejskim kwestię eksploracji danych reguluje Dyrektywa o prawie autorskim na jednolitym rynku cyfrowym (Dyrektywa DSM). Wprowadza ona wyjątki dotyczące eksploracji tekstów i danych (Text and Data Mining – TDM). O ile instytucje badawcze i naukowe korzystają z szerokiego dozwolonego użytku, o tyle podmioty komercyjne podlegają istotnym ograniczeniom.

Zgodnie z art. 4 Dyrektywy DSM, komercyjna eksploracja danych jest dozwolona pod warunkiem, że uprawniony nie zastrzegł wyraźnie zakazu takiego wykorzystania (tzw. mechanizm opt-out). W odniesieniu do treści dostępnych w internecie zastrzeżenie to powinno nastąpić za pomocą środków możliwych do odczytania maszynowego (np. protokół robots.txt, metadane, nagłówki HTTP).

Ignorowanie maszynowych zastrzeżeń właścicieli praw autorskich podczas pobierania danych z sieci stwarza bezpośrednie ryzyko roszczeń odszkodowawczych oraz żądania zniszczenia modeli wytrenowanych z naruszeniem prawa (tzw. algorithmic disgorgement).

Web scraping, bazy licencjonowane i treści przekazane przez użytkowników

Podmioty budujące lub dotrenowujące modele stają przed wyborem źródła danych. Każde z nich wiąże się z innym profilem ryzyka:

• Masowy web scraping: wysokie ryzyko naruszenia praw autorskich, złamania regulaminów serwisów internetowych (ToS) oraz obejścia zabezpieczeń technicznych, co może rodzić odpowiedzialność kontraktową i deliktową.
• Komercyjne bazy licencjonowane: bezpieczniejsze rozwiązanie, pod warunkiem że umowa jednoznacznie zezwala na machine learning training, a nie tylko na standardowe przetwarzanie danych w ramach analityki biznesowej.
• Dane od użytkowników platformy: wymagają precyzyjnych zapisów w regulaminie usługi. Zgoda na świadczenie usługi nie oznacza zgody na wykorzystanie treści do trenowania modeli bazowych.

Osobnym zagadnieniem jest tajemnica przedsiębiorstwa. Wprowadzenie do procesu treningowego wewnętrznych dokumentów organizacji, kodów źródłowych, kalkulacji marż czy danych finansowych kontrahentów bez odpowiednich procedur może doprowadzić do utraty ochrony prawnej tych informacji. Jeżeli model zapamięta fragmenty danych (zjawisko memorizacji) i wygeneruje je w odpowiedzi na zapytanie innego podmiotu, dochodzi do bezprawnego ujawnienia tajemnicy.

W odniesieniu do danych osobowych (RODO) proces trenowania modeli generuje wyzwania dotyczące realizacji praw osób, których dane dotyczą. Zasady minimalizacji danych, ograniczenia celu oraz prawo do bycia zapomnianym (art. 17 RODO) są trudne do pogodzenia ze strukturą wag sieci neuronowych. Z wag modelu nie da się w prosty sposób „skasować” pojedynczego nazwiska bez kosztownego ponownego treningu (tzw. machine unlearning, który wciąż znajduje się we wczesnej fazie rozwoju technologicznego).

Praktyczny problem pojawia się, gdy firma planuje dostroić model językowy na historii zgłoszeń z helpdesku. Korespondencja zawiera imiona, nazwiska, adresy e-mail, dane teleadresowe, a niekiedy numery PESEL czy dane o stanie zdrowia. Zanim te zbiory trafią do pipeline’u treningowego, konieczna jest rygorystyczna pseudonimizacja lub pełna anonimizacja, weryfikacja podstawy prawnej przetwarzania oraz usunięcie materiałów przesłanych przez klientów, do których prawa przysługują osobom trzecim.

Jeśli chcesz pogłębić ten wątek, sprawdź też: Kiedy „free” nie znaczy darmowe: pułapki licencji freeware i shareware.

Kto ma prawa do treści wygenerowanych przez AI i gdzie pojawia się ryzyko naruszenia

Status prawny rezultatów generowanych przez sztuczną inteligencję (outputu) jest jednym z najbardziej dyskutowanych zagadnień współczesnego prawa własności intelektualnej. Z punktu widzenia biznesu kluczowe są dwa pytania: czy wygenerowane materiały można chronić prawem autorskim oraz czy ich komercyjne użycie może naruszyć prawa osób trzecich.

Większość jurysdykcji, w tym polski system prawny oparty na ustawie o prawie autorskim i prawach pokrewnych, konsekwentnie przyjmuje zasadę, że utworem może być wyłącznie rezultat działalności kreacyjnej człowieka. Wytwory wygenerowane w sposób w pełni automatyczny przez algorytm nie podlegają ochronie prawnoautorskiej i trafiają do domeny publicznej z chwilą ich powstania.

Output nie jest

chroniony automatycznie

Ochrona przysługuje wyłącznie wtedy, gdy człowiek wykaże istotny, twórczy wkład w ostateczny kształt materiału. Samo wpisanie prompt

u, nawet bardzo szczegółowego i rozbudowanego, traktowane jest zazwyczaj jako polecenie wykonania pracy (zbliżone do zlecenia rzemieślnikowi stworzenia dzieła), a nie bezpośredni akt kreacji artystycznej czy literackiej.

Sytuacja zmienia się, gdy wygenerowany materiał staje się zaledwie surowcem w wieloetapowym procesie twórczym. Jeżeli grafik wykorzystuje generatywną grafikę jako tło, a następnie ręcznie modyfikuje kompozycję, dopracowuje szczegóły, dodaje autorskie elementy wektorowe i decyduje o finalnej palecie barwnej, ten zmodyfikowany fragment może zyskać ochronę. Warunkiem jest jednak to, by ostateczny rezultat nosił indywidualne piętno człowieka, a elementy ludzkiej twórczości dały się oddzielić lub przynajmniej wyraźnie zidentyfikować w całości dzieła.

Ryzyko naruszenia praw osób trzecich przez wygenerowany materiał

Brak ochrony prawnoautorskiej po stronie użytkownika nie oznacza braku odpowiedzialności za ewentualne naruszenia cudzych monopoli. Ryzyko materializuje się w dwóch głównych sytuacjach:

• Zjawisko memorizacji i plagiatu wprost: Modele generatywne w specyficznych warunkach (np. przy silnie sprecyzowanym prompcie lub zbyt wąskim zbiorze treningowym w danej dziedzinie) potrafią odtworzyć niemal identyczny fragment chronionego tekstu, kodu źródłowego czy elementu graficznego z bazy treningowej. Użycie takiego materiału w kampanii reklamowej lub oprogramowaniu komercyjnym rodzi bezpośrednie ryzyko pozwu o naruszenie praw autorskich.
• Wykorzystanie cudzych znaków towarowych i wizerunku: Modele mogą generować treści przedstawiające rozpoznawalne postaci publiczne, zastrzeżone znaki towarowe, logotypy czy chroniony wzornictwem przemysłowym design produktów. Publikacja takiego materiału bez zgody uprawnionego narusza prawo do wizerunku, dobra osobiste lub przepisy o zwalczaniu nieuczciwej konkurencji.

Wielu dostawców komercyjnych oferuje obecnie tzw. IP indemnification – klauzule gwarancyjne, w ramach których dostawca zobowiązuje się pokryć koszty obrony prawnej i odszkodowań, jeśli output wygenerowany przez model naruszy prawa autorskie osób trzecich. Klauzule te są jednak obwarowane licznymi wyłączeniami. Nie chronią one klienta, jeśli celowo wymusił on na modelu naruszenie (np. wpisując prośbę o wygenerowanie postaci konkretnego komiksu) lub jeśli wyłączył wbudowane filtry bezpieczeństwa.

Komercjalizacja modelu AI: licencjonowanie własnego rozwiązania i odpowiedzialność wobec klientów

Przejście z fazy eksperymentu do budowy produktu opartego na sztucznej inteligencji wymaga zdefiniowania zasad, na jakich rozwiązanie będzie oferowane rynkowi. Firma, która wytrenowała własny model od podstaw, dostroiła model zewnętrzny lub stworzyła zaawansowany system RAG (Retrieval-Augmented Generation), musi precyzyjnie skonstruować umowę z klientem końcowym.

Konstrukcja prawna oferty zależy w głównej mierze od architektury technologicznej oraz tego, co faktycznie podlega licencjonowaniu: dostęp do usługi w chmurze, pakiet oprogramowania instalowany on-premise, czy zmodyfikowane wagi modelu.

Projektowanie umowy licencyjnej na rozwiązanie bazujące na AI

Standardowe umowy SaaS nie odpowiadają specyfice systemów probabilistycznych. Wdrożenie wymaga wprowadzenia do kontraktu lub regulaminu specyficznych klauzul:

• Wyłączenie gwarancji co do poprawności merytorycznej: Sztuczna inteligencja ma tendencję do halucynowania – generowania fałszywych informacji brzmiących w sposób w pełni wiarygodny. Umowa musi wyraźnie wskazywać, że wygenerowane treści nie stanowią profesjonalnej porady prawnej, medycznej, finansowej ani technicznej, a klient ponosi wyłączną odpowiedzialność za ich merytoryczną weryfikację przed wdrożeniem.
• Prawa do danych wejściowych i wyjściowych: Należy jednoznacznie określić, że klient zachowuje prawa do zapytań (inputów) oraz otrzymanych odpowiedzi (outputów), przy czym dostawca oprogramowania zastrzega sobie (bądź wyraźnie wyłącza) prawo do przetwarzania tych danych w celach telemetrycznych lub rozwojowych.
• Definicja poziomu dostępności (SLA) a zależność od poddostawców: Jeśli autorska aplikacja korzysta pod spodem z API zewnętrznego dostawcy modeli bazowych, SLA udzielane klientowi końcowemu nie może być szersze niż gwarancje oferowane przez tego poddostawcę. Przerwa w działaniu API zewnętrznego powinna być traktowana jako okoliczność wyłączająca odpowiedzialność z tytułu niedostępności systemu.

Kaskada licencyjna i ryzyko zanieczyszczenia prawnego

Największym zagrożeniem przy komercjalizacji rozwiązań AI jest tzw. zanieczyszczenie licencyjne (license contamination). Oprogramowanie oparte na AI rzadko powstaje w próżni – zwykle łączy model bazowy, biblioteki open source (np. do tokenizacji czy akceleracji obliczeń) oraz zbiory danych o różnym statusie prawnym.

Jeżeli do dotrenowania modelu wykorzystano zbiór danych udostępniony na licencji zakazującej komercjalizacji (np. Creative Commons NonCommercial), a cały system został następnie zintegrowany z produktem komercyjnym i sprzedany w modelu subskrypcyjnym, całe wdrożenie staje się wadliwe prawnie. Uprawniony może zażądać wstrzymania sprzedaży usługi oraz zapłaty wynagrodzenia za bezumowne korzystanie z utworu.

Identyczny mechanizm zachodzi w przypadku licencji copyleft na kod źródłowy lub same wagi (np. licencje typu GPL lub niektóre odmiany licencji RAIL). Przeoczenie tych powiązań w łańcuchu dostaw technologii może wymusić na firmie upublicznienie własnościowych komponentów systemu lub konieczność natychmiastowego wycofania produktu z rynku.

Ocena ryzyka przed wdrożeniem: scenariusze, które wymagają różnych decyzji

Wdrożenie sztucznej inteligencji w organizacji nigdy nie powinno przebiegać według jednego, sztywnego schematu prawnego. W zależności od tego, jak głęboko technologia ingeruje w procesy biznesowe i jakie dane są przez nią przetwarzane, zespół decyzyjny staje przed odmiennymi wyzwaniami regulacyjnymi.

Scenariusz 1: Agencja marketingowa integruje generatory treści w procesie obsługi klientów

W tym wariancie ryzyko prawne koncentruje się wokół umów z klientami agencji. Większość profesjonalnych umów o dzieło i świadczenie usług marketingowych zawiera oświadczenie agencji, że dostarczone materiały (grafiki, teksty, koncepcje kreatywne) są utworami oryginalnymi, do których agencja posiada pełne majątkowe prawa autorskie, a ich przeniesienie na klienta następuje bez wad prawnych.

Jeżeli agencja dostarczy klientowi materiał wygenerowany bezpośrednio przez model bez istotnej obróbki człowieka, złoży fałszywe oświadczenie w umowie – praw autorskich nie da się przenieść, ponieważ one w ogóle nie powstały. Jeśli klient spróbuje taki projekt zarejestrować jako znak towarowy lub zabezpieczyć przed konkurencją, ochrona prawna okaże się iluzoryczna.

Praktyczne decyzje: Agencja musi zrewidować wzorce umowne. Niezbędne jest wprowadzenie zapisów informujących klienta o użyciu narzędzi AI, ograniczenie przenoszenia praw wyłącznie do elementów faktycznie wytworzonych przez człowieka oraz formalne uzgodnienie poziomu ludzkiego nadzoru i edycji w finalnych deliverablach.

Scenariusz 2: Software house buduje asystenta kodowania zintegrowanego z wewnętrznym repozytorium

W tym przypadku głównym zagrożeniem jest tajemnica przedsiębiorstwa oraz potencjalne roszczenia ze strony zleceniodawców, dla których software house tworzy dedykowane oprogramowanie na zamówienie. Klienci branży IT niemal zawsze wprowadzają do umów NDA rygorystyczne zakazy udostępniania kodu osobom trzecim oraz wykorzystywania ich bibliotek do projektów innych klientów.

Skierowanie wewnętrznych repozytoriów, w tym kodu objętego NDA, do modelu chmurowego, który wykorzystuje zapytania do samouczenia, stanowi rażące naruszenie tajemnicy przedsiębiorstwa i może uruchomić wielomilionowe kary umowne. Dodatkowo istnieje ryzyko, że asystent podpowie fragment kodu chronionego restrykcyjną licencją GPL innemu programiście pracującemu nad projektem komercyjnym o zamkniętym kodzie, co doprowadzi do skażenia licencyjnego całego produktu.

Praktyczne decyzje: Niezbędne jest wdrożenie wyłącznie rozwiązań typu Enterprise z gwarancją niewykorzystywania danych użytkownika do treningu lub uruchomienie modelu open-weight na własnej infrastrukturze (on-premise / chmura prywatna). Konieczne jest również wdrożenie automatycznych filtrów sprawdzających, czy generowany kod nie pokrywa się z chronionymi bazami open source.

Scenariusz 3: Dział medyczny wdraża model RAG do wspomagania analizy dokumentacji pacjentów

Tu ryzyko przesuwa się niemal całkowicie w stronę prawa ochrony danych osobowych (RODO) i regulacji sektorowych. Dokumentacja medyczna zawiera dane szczególnych kategorii (art. 9 RODO). Przesyłanie takich informacji do publicznych modeli zewnętrznych jest niedopuszczalne z perspektywy przepisów o tajemnicy zawodowej oraz ochronie zdrowia.

Dodatkowym wyzwaniem jest kwestia halucynacji w kontekście odpowiedzialności cywilnej za błędy diagnostyczne lub terapeutyczne. W tym układzie model nie może podejmować autonomicznych decyzji, a jego wdrożenie wymaga procedury human-in-the-loop z pełną rejestracją operacji w celach audytowych.

Praktyczne decyzje: Architektura musi opierać się na pełnej izolacji środowiska (brak wyjścia do publicznego internetu). Wymagana jest ocena skutków dla ochrony danych (DPIA) oraz formalne wyznaczenie lekarza jako podmiotu wyłącznie odpowiedzialnego za każdą decyzję opartą na rekomendacji algorytmu, co eliminuje zarzut zautomatyzowanego przetwarzania o krytycznym wpływie na prawa pacjenta.

Świadome zarządzanie licencjami i prawami własności intelektualnej w projektach AI wymaga stałej współpracy programistów, architektów systemowych i prawników. Dynamiczne zmiany w orzecznictwie oraz wchodzące w życie przepisy europejskiego Aktu o Sztucznej Inteligencji (AI Act) sprawiają, że weryfikacja łańcucha dostaw danych i oprogramowania staje się stałym procesem nadzoru biznesowego, a nie jednorazową formalnością przeprowadzaną w dniu startu projektu.

Kluczowe Wnioski

• Legalność wdrożenia AI zależy od odrębnej oceny modelu, kodu, wag, danych treningowych, promptów i wyników.
• Dostęp do usługi SaaS nie oznacza nabycia praw do modelu ani możliwości uruchamiania jego wag we własnej infrastrukturze.
• Określenie „open source” nie powinno być automatycznie stosowane do modeli open-weight, których licencje mogą zawierać ograniczenia komercyjne, branżowe lub dotyczące redystrybucji.
• Przed wdrożeniem trzeba sprawdzić warunki komercyjnego użycia, modyfikacji, redystrybucji oraz prawa dostawcy do promptów i danych wyjściowych.
• Dane treningowe wymagają analizy praw autorskich, tajemnicy przedsiębiorstwa, danych osobowych oraz zasad eksploracji tekstów i danych.
• Ocena ryzyka powinna uwzględniać konkretną wersję modelu, sposób wdrożenia i odpowiedzialność poszczególnych podmiotów w całym łańcuchu technologicznym.