Agent pisze działający fragment, a potem zespół dodaje go do produktu bez pytania o źródło, licencję i umowę. Test przechodzi, więc temat wydaje się zamknięty. Kod działa, ale nie wiadomo, na jakich zasadach może zostać, czy zawiera cudzy fragment i czy przypadkiem nie ujawnia klienta.
Praktycznym sposobem oceny praw do kodu z AI jest prowadzenie rejestru pochodzenia, sprawdzanie licencji i odbiór techniczny. Nie ma jednej odpowiedzi dla każdego modelu i kraju. Proces powinien pokazywać, co zostało wygenerowane, co człowiek zmienił i jakie dokumenty obowiązują.
Zacznij od umowy i roli
Zapisz, kto zleca pracę, kto jest autorem lub wykonawcą i jakie prawa przenoszą umowy. Nie zakładaj, że kod wygenerowany przez model automatycznie należy do ciebie lub klienta. Oceń dokumenty z właściwą osobą.
Sprawdź warunki modelu i planu. Nie przenoś warunków darmowego konta na firmowe. Umowa z klientem powinna odpowiadać rzeczywistemu procesowi pracy.
Przy prawach stosuj zasady z artykułu o prawach autorskich AI. Model jest narzędziem, a prawa i odpowiedzialność wymagają oceny.
Rejestr pochodzenia kodu
Zachowaj wersję modelu, prompt lub zakres zadania, źródła, datę i osobę odpowiedzialną. Nie przechowuj poufnych briefów w publicznym repozytorium. Identyfikator procesu wystarczy.
Zapisz, które fragmenty zostały wygenerowane i jak je zmieniono. Nie musisz analizować każdej litery, ale przy ważnych komponentach rejestr powinien pokazywać proces.
Przy agencie kodującym stosuj zasady z artykułu o briefie dla agenta AI. Rejestr nie powinien tworzyć nowego wycieku danych.
Licencje źródeł i zależności
Do wpisu o bibliotece dołącz wersję i plik licencji z konkretnego wydania, a osobno zaznacz zależności wprowadzane pośrednio. Gdy warunki użycia pozostają niejasne, odłóż decyzję o wdrożeniu do czasu ich wyjaśnienia.
Sprawdź licencje bibliotek, fragmentów, obrazów, danych i dokumentacji. Nie zakładaj, że kod dostępny publicznie jest do dowolnego użycia. Model może powielić fragment bez poprawnego opisu.
Dodaj automatyczne skanowanie zależności, ale odbierz nietypowe przypadki ręcznie. Narzędzie nie zna kontekstu umowy i zamierzonego użycia. Zapisz decyzję.
Przy włączaniu nowej biblioteki sprawdź, czy licencja pasuje do produktu i dystrybucji. Nie dokładaj zależności dla jednej prostej funkcji bez oceny kosztu i praw.
Test podobieństwa nie jest testem praw autorskich
Narzędzie może pokazać podobieństwo do publicznego kodu, ale nie rozstrzyga praw autorskich i dozwolonego użycia. Wynik wymaga analizy źródła i licencji. Nie traktuj procentu podobieństwa jako werdyktu.
Przy podobnym fragmencie oceń, czy jest to standardowy wzorzec, nieunikniona forma czy konkretna implementacja. Prawnik i technik powinni ocenić właściwy przypadek.
Nie przepisuj kodu automatycznie na inną składnię, żeby „uniknąć” podobieństwa. To nie rozwiązuje praw ani koniecznie poprawia jakość. Lepszy jest odbiór źródła.
Bezpieczeństwo przed stylem
Przy odbiorze sprawdź walidację, autoryzację, sekrety, dane wejściowe, błędy i skutki uboczne. Kod może być poprawny licencyjnie i niebezpieczny. To osobne pytania.
Nie akceptuj fragmentu na podstawie jednego testu jednostkowego. Dodaj przypadki graniczne, negatywne i integracyjne. Agent nie powinien uruchamiać nieznanych zależności z pełnymi uprawnieniami.
Przy odbiorze stosuj zasady z artykułu o kodzie i bezpieczeństwie AI. Proces powinien obejmować rzeczywiste zachowanie.
Poufność promptu i kodu klienta
Nie przesyłaj prywatnego repozytorium do modelu bez odpowiedniego uprawnienia oraz mapy odbiorców. Prompt, kontekst i odpowiedź mogą ujawniać architekturę oraz sekrety. Ogranicz zakres.
Sprawdź, czy kod nie zawiera tokenów, adresów wewnętrznych i danych klientów. Usuwaj je przed analizą, ale oceń, czy pozostały kontekst nadal identyfikuje. Logi powinny być minimalne.
Przy NDA stosuj zasady z artykułu o danych poufnych AI. Pochodne i historie agentów również są objęte procesem.
Umowa z klientem o zakresie praw
Opisz, co powstaje jako nowa praca, jakie źródła są używane i jakie prawa przenoszą strony. Nie obiecuj pełnej wyłączności dla każdego elementu niezależnie od licencji i prawa.
Zapisz, kto odpowiada za odbiór, zależności i publikację. Klient powinien wiedzieć, czy model był użyty i na jakich zasadach. Nie ukrywaj procesu za ogólnym „wykonanie”.
Przy zmianie modelu lub dostawcy oceń, czy warunki wymagają nowej decyzji. Stara umowa nie zawsze odpowiada na nowy kanał.
Przykład: agent dodaje bibliotekę
Agent proponuje małą bibliotekę zamiast napisać funkcję. Sprawdź licencję, utrzymanie, zależności i sposób dystrybucji. Może prostszy własny kod jest lepszy niż nowy pakiet.
Zapisz decyzję i wersję. Nie przenoś automatycznie do produkcji na podstawie samej popularności. Popularność nie jest licencją ani dowodem bezpieczeństwa.
Po odbiorze uruchom testy zależne i jeden kontrolny. Zachowaj informację o źródle i osobie akceptującej.
Przykład: fragment przypomina publiczny kod
Skan pokazuje podobieństwo do repozytorium z restrykcyjną licencją. Nie publikuj od razu. Otwórz źródło i porównaj zakres, formę i wymagania.
Może kod należy zastąpić własną implementacją, uzyskać prawa lub wybrać inną bibliotekę. Decyzja zależy od przypadku. Model nie powinien wybierać najwygodniejszej odpowiedzi sam.
Zachowaj dokumentację analizy bez kopiowania poufnych fragmentów do publicznego raportu.
Test praw w procesie CI
Dodaj skan licencji zależności, sekretów i źródeł. Nie zastępuj ręcznej oceny nietypowych przypadków. Automat powinien zatrzymywać znane ryzyko, a nie zgadywać prawo.
Wersjonuj listę zależności i raporty. Przy zmianie modelu powtórz tylko zależne przypadki i kontrolne. Nie przepisuj całej historii kodu dla nowego skanu.
Przy odbiorze przez właściciela praw przedstaw konkretne fragmenty i dokumenty. Nie wysyłaj samego raportu „0 błędów”.
Praca z kodem open source
Przy publikowaniu kodu zachowaj wymagane informacje o licencjach i źródłach. Nie usuwaj autorów i notatek. Opisz własne zmiany zgodnie z procesem.
Nie przypisuj całego projektu modelowi jako autorowi. Prawa i odpowiedzialność należą do ludzi oraz organizacji zgodnie z oceną. Rejestr powinien być dostępny dla zespołu.
Przy używaniu cudzych komponentów sprawdź, czy sposób publikacji i dystrybucji jest zgodny z licencją. Inny kanał może zmieniać obowiązki.
Kiedy zatrzymać publikację kodu
Zatrzymaj przy nieznanej licencji, podejrzeniu kopiowania, poufnym źródle, sekretach i niejasnej umowie. Nie publikuj z zamiarem poprawienia później. Skutek jest trudny do cofnięcia.
Zachowaj wersję i zakres. Właściciel decyduje o zastąpieniu, uzyskaniu praw lub kontakcie z klientem. Nie przepisuj historii commitów dla ukrycia procesu.
Po poprawce powtórz testy techniczne i prawne zależne od zmiany. Dopiero potem publikuj.
Minimalna karta komponentu
Zapisz źródło, model, wersję, licencje, zależności, odbiór techniczny, prawa i właściciela decyzji. Dodaj datę i zakres użycia. Nie przechowuj poufnego promptu.
Przy kolejnej wersji zaktualizuj tylko zależne pola i testy. Nie twórz nowej karty dla każdej litery. Karta ma pokazywać skutek i odpowiedzialność.
Kiedy przepisywać zamiast licencjonować
Jeżeli źródło lub licencja nie pasuje, rozważ własną implementację opartą na wymaganym zachowaniu, a nie na kopiowaniu cudzej. Zapisz specyfikację i testy zanim agent zacznie pisać. To ogranicza ryzyko przenoszenia konkretnej implementacji.
Nie przepisuj kodu linia po linii z innego repozytorium pod kierownictwem modelu. To nadal może wymagać analizy praw i źródła. Czasem lepsza jest inna biblioteka lub prostsza funkcja. Decyzja powinna obejmować koszt utrzymania i bezpieczeństwo.
Przegląd po zmianie modelu kodującego
Nowy model może proponować inne biblioteki i wzorce. Powtórz skan zależności oraz przypadki dotyczące źródeł. Nie przenoś starej akceptacji licencji na nowy kod automatycznie.
Porównaj, czy proces nadal używa tych samych komponentów i czy nie dodano poufnego kontekstu. Zapisz wersję i datę odbioru. Przy dużej zmianie nie ograniczaj się do testu buildu, bo prawa i pochodzenie nie mają testu zielonego przycisku.
Instrukcja dla agenta kodującego
Dodaj do briefu zasady: nie dodawaj zależności bez zgody, nie kopiuj publicznych fragmentów bez źródła, nie umieszczaj sekretów, zachowaj licencje i raportuj niepewność. Wymagaj listy zmienionych plików i nowych pakietów.
Ogranicz prawa do odczytu i szkicu przy nowym procesie. Publikacja wymaga odbioru technicznego oraz prawnego przy wskazanych przypadkach. Agent powinien zatrzymać się przy nieznanej licencji zamiast wybierać najprostszą odpowiedź „open source”.
Odbiór przez właściciela repozytorium
Właściciel powinien wiedzieć, które komponenty zmieniły się i dlaczego. Przy większej funkcji przygotuj krótką mapę źródeł i decyzji zamiast samego diffu. Nie wysyłaj całej historii promptów jako dowodu.
Po merge sprawdź, czy dokumenty licencji i zależności zostały opublikowane zgodnie z procesem. Odbiór kończy się na repozytorium i produkcie, a nie na akceptacji w rozmowie z agentem.
Odbiór wersji przed release
Przygotuj listę nowych komponentów, zależności i fragmentów generowanych. Porównaj z poprzednią wersją i zaznacz te wymagające oceny praw. Nie przesyłaj całego diffu do przypadkowego modelu przy sprawdzaniu źródeł.
Właściciel potwierdza licencje i zakres publikacji, a technik wykonuje testy. Po release zapisz wersję dokumentów i datę. Jeżeli pojawi się pytanie o konkretny fragment, rejestr powinien pozwalać znaleźć źródło bez odtwarzania całego projektu od zera.
Nie zgaduj autorstwa i praw przy generowaniu
Model może opisać prawdopodobny wzorzec, ale nie wie, na jakiej podstawie powstał konkretny fragment. Nie przypisuj mu automatycznie autorstwa człowiekowi lub organizacji. Oceń źródło, umowę i proces.
Jeżeli odpowiedź prawna jest niejasna, zapisz ją jako ograniczenie i poproś specjalistę. Nie używaj ogólnego „AI nie ma praw autorskich” jako odpowiedzi na każdy przypadek. Proces powinien odpowiadać na konkretne prawa, licencje i rolę osób.
Aeneia Audit pomaga zmapować proces i odpowiedzialność. Przy odbiorze pomocny jest przewodnik Aeneia Signal.
Dobry kod z AI ma źródło, licencje i odbiór. Działanie jest tylko jednym kryterium. Prawa i bezpieczeństwo nie powinny zostać w komentarzu na później.
Przy kolejnym odbiorze zachowaj listę pytań bez zgadywania odpowiedzi. Jeżeli źródło jest nieznane, oznacz je jako ograniczenie i wybierz właściwy kanał oceny. Model może przyspieszać inwentarz i testy, ale nie rozstrzyga praw autorskich. Rejestr powinien pokazywać, kiedy decyzja wymaga człowieka i dlaczego została podjęta.
Przy małej bibliotece komponentów nie twórz skomplikowanego systemu. Wystarczy tabela z wersją, licencją i odbiorem. Jeżeli zespół nie potrafi jej znaleźć, popraw dostęp i właściciela. Proces ma przyspieszać odpowiedzialne decyzje, a nie dodawać kolejną warstwę administracji między kodem a publikacją. Zachowaj właściciela i datę każdej decyzji. Dzięki temu odbiór jest powtarzalny przy kolejnych wersjach kodu źródłowego produktu.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
