Jeszcze kilka lat temu odpowiedź na pytanie "kto napisał ten kod?" była stosunkowo prosta. Można było wskazać programistę, zespół albo software house, który odpowiadał za konkretny moduł.
Dzisiaj sytuacja wygląda zupełnie inaczej.
Część kodu może powstać ręcznie. Część może wygenerować Copilot. Kolejny fragment stworzy agent programistyczny. Inny zostanie pobrany z biblioteki open source. Jeszcze inny będzie zależnością zewnętrznego pakietu. Do tego dochodzą API, usługi chmurowe, gotowe komponenty, frameworki i narzędzia dostarczane przez kolejne firmy.
System działa. Ale czy naprawdę wiesz, z czego został zbudowany?
Kod wygenerowany przez AI nie pojawia się w próżni
Rozwój narzędzi AI do programowania zmienia nie tylko sposób pisania oprogramowania. Zmienia również strukturę odpowiedzialności za kod.
Programista może dzisiaj opisać agentowi zadanie, a następnie otrzymać gotową funkcję, moduł, testy, konfigurację czy nawet propozycję zmian architektonicznych. To ogromne przyspieszenie pracy.
Problem zaczyna się wtedy, gdy wygenerowany kod traktujemy jako "kod znikąd".
AI nie tworzy bowiem kodu w oderwaniu od całego ekosystemu programistycznego. Modele są trenowane na ogromnych zbiorach danych, a wygenerowany fragment może być podobny do istniejących rozwiązań, wzorców czy publicznie dostępnego kodu. Właśnie dlatego kwestia pochodzenia kodu, licencji i odpowiedzialności staje się coraz ważniejsza.
Nie oznacza to automatycznie, że każdy fragment kodu wygenerowany przez AI narusza czyjąś licencję. Oznacza natomiast, że organizacja wykorzystująca AI w procesie wytwarzania oprogramowania powinna traktować pochodzenie i weryfikację kodu jako element procesu inżynierskiego, a nie ciekawostkę prawną.
To już nie jest wyłącznie teoria
16 września 2026 r. Sąd Apelacyjny 9. Okręgu rozstrzygnął część sprawy Doe v. GitHub, w której programiści zarzucali GitHubowi, Microsoftowi i podmiotom OpenAI m.in. wykorzystanie publicznie dostępnego kodu z GitHuba przy tworzeniu i trenowaniu narzędzi takich jak Copilot i Codex.
Jedno z roszczeń dotyczyło DMCA i informacji o prawach autorskich. Sąd podtrzymał odrzucenie tego konkretnego zarzutu. Jednocześnie sprawa obejmuje także inne kwestie związane z prawami autorskimi i licencjami open source.
To ważne nie dlatego, że jeden wyrok daje prostą odpowiedź na pytanie "czy można używać kodu z AI".
Nie daje.
Ważniejsze jest to, że spór pokazuje szerszy problem: w świecie AI granica pomiędzy kodem napisanym przez człowieka, kodem wygenerowanym przez model i kodem pochodzącym z istniejącego ekosystemu oprogramowania staje się coraz trudniejsza do prześledzenia.
A dla firm tworzących oprogramowanie oznacza to konieczność lepszego zarządzania tym procesem.
Software supply chain, czyli Twój system ma znacznie więcej "autorów"
W bezpieczeństwie oprogramowania od lat funkcjonuje pojęcie software supply chain - łańcucha dostaw oprogramowania.
To wszystkie komponenty, narzędzia, biblioteki, zależności i procesy, które uczestniczą w powstaniu finalnego produktu.
NIST wskazuje w tym kontekście m.in. na potrzebę zarządzania pochodzeniem komponentów, kontrolowania zależności open source, monitorowania podatności oraz stosowania SBOM, czyli Software Bill of Materials.
SBOM można w dużym uproszczeniu porównać do listy składników produktu.
Nie mówi tylko "mamy aplikację". Pokazuje, jakie komponenty znajdują się w środku.
Przykładowo:
- framework aplikacji,
- biblioteki zewnętrzne,
- wersje poszczególnych pakietów,
- komponenty open source,
- zależności pośrednie,
- elementy dostarczane przez zewnętrznych dostawców.
Dzięki temu, gdy pojawi się podatność w konkretnej bibliotece, można szybciej sprawdzić, które systemy jej używają.
NIST zwraca również uwagę na provenance, czyli możliwość prześledzenia pochodzenia elementów oprogramowania.
I właśnie tutaj AI dodaje nowy poziom komplikacji.
Bo do istniejącego łańcucha dochodzi kolejny sposób powstawania kodu.
Wyobraź sobie typowy system biznesowy
40% kodu napisał zespół.
20% powstało przy wsparciu AI.
Kolejne fragmenty wygenerował agent.
Kilka bibliotek pochodzi z open source.
Część zależności została dodana przez framework.
System korzysta z API zewnętrznego dostawcy.
Jeden komponent pochodzi z paczki, której nikt nie aktualizował od dwóch lat.
A dokumentacja zależności?
Jest gdzieś w repozytorium.
Albo jej nie ma.
System działa...
I właśnie dlatego problem jest niewidoczny. Dopóki nic się nie wydarzy.
A potem pojawia się podatność
Załóżmy, że w jednej z bibliotek zostaje wykryta poważna luka bezpieczeństwa.
Pytanie brzmi: Czy wiesz, czy Twój system jej używa?
Jeżeli masz uporządkowany rejestr zależności, odpowiedź może być kwestią minut.
Jeżeli nie masz - rozpoczyna się ręczne przeszukiwanie repozytoriów, kontakt z programistami, sprawdzanie środowisk, wersji pakietów i zależności pośrednich.
A teraz dodajmy do tego kod wygenerowany przez AI.
Czy wiadomo, który fragment powstał przy użyciu którego narzędzia?
Czy przeprowadzono code review?
Czy kod został pokryty testami?
Czy sprawdzono zależności?
Czy ktoś zweryfikował licencję komponentu?
Czy można odtworzyć proces, w wyniku którego powstał konkretny fragment?
To nie są już pytania wyłącznie dla programisty.
To pytania dotyczące zarządzania ryzykiem technologicznym firmy.
Największym problemem nie jest AI. Jest nim brak procesu
Łatwo byłoby stworzyć z tego artykułu ostrzeżenie przed sztuczną inteligencją.
Byłby to jednak zbyt prosty wniosek.
AI może bardzo mocno poprawić produktywność zespołu programistycznego.
Problem pojawia się wtedy, gdy firma zwiększa tempo produkcji kodu, ale nie zwiększa jednocześnie kontroli nad tym kodem.
To trochę tak, jakby fabryka nagle produkowała dziesięć razy więcej elementów, ale nie zwiększyła kontroli jakości, ewidencji materiałów ani kontroli dostawców.
W software house'ie odpowiednikiem takiego systemu kontroli są między innymi:
- code review
- automatyczne testy
- skanowanie zależności
- SBOM
- monitorowanie podatności
- kontrola licencji open source
- CI/CD z kontrolami bezpieczeństwa
- zarządzanie repozytoriami
- dokumentowanie architektury
- śledzenie pochodzenia komponentów
- jasne zasady wykorzystania AI w development
NIST wskazuje również na możliwość integrowania mechanizmów bezpieczeństwa łańcucha dostaw bezpośrednio z pipeline'ami CI/CD.
To ważna zmiana sposobu myślenia.
Bezpieczeństwo nie powinno być kontrolą wykonywaną dopiero przed wdrożeniem.
Powinno być częścią procesu powstawania oprogramowania.
"Kto napisał ten kod?" przestaje być właściwym pytaniem
W świecie tradycyjnego developmentu można było pytać o autora.
W świecie AI-assisted development znacznie ważniejsze stają się pytania:
- Skąd pochodzi ten komponent?
- Jaką ma licencję?
- Kto go zweryfikował?
- Jaką wersję wykorzystujemy?
- Jakie ma zależności?
- Czy jest nadal utrzymywany?
- Czy znamy jego podatności?
- Czy możemy odtworzyć historię zmian?
- Czy wiemy, gdzie AI uczestniczyło w jego powstaniu?
I przede wszystkim:
- Czy firma jest w stanie udowodnić, że nad tym wszystkim panuje?
Bo klient nie kupuje przecież "kodu od AI". Kupuje działający system. I odpowiedzialność za ten system nadal ponosi organizacja, która go dostarcza i utrzymuje.
Kod może być automatyczny. Odpowiedzialność nie
To prawdopodobnie jedna z najważniejszych zmian, jakie AI przynosi do software house'ów.
Programista nie znika. Jego rola się zmienia.
Coraz częściej nie chodzi wyłącznie o napisanie określonej liczby linii kodu. Chodzi o zaprojektowanie rozwiązania, kontrolę wygenerowanych elementów, ocenę ryzyka, testowanie, integrację, bezpieczeństwo i utrzymanie całego systemu.
Podobnie firma nie może ograniczyć się do pytania, czy jej programiści korzystają z AI.
Powinna wiedzieć jak korzystają, w jakim procesie, z jakimi kontrolami i jak wpływa to na cały cykl życia oprogramowania.
Bo za kilka lat pytanie może brzmieć nie: "Kto napisał ten system?"
ale: "Czy potrafisz odtworzyć, z czego i w jaki sposób został zbudowany?"
Jeżeli odpowiedź brzmi "nie do końca", problemem nie jest brak kolejnego narzędzia AI.
Problemem jest brak kontroli nad software supply chain.
