Kto się podpisze pod kodem od AI? Odpowiedzialność, code review i plan na awarię

Kto odpowiada za kod napisany przez AI? Ten sam człowiek i ta sama firma, co za każdy inny kod: wykonawca, który go dostarczył, i firma, która go uruchomiła. Dokumentacja jądra Linuksa mówi to wprost: agent AI nie może dodać znacznika Signed-off-by, bo pochodzenie kodu (Developer Certificate of Origin) może poświadczyć tylko człowiek, a osoba zgłaszająca zmianę bierze za nią pełną odpowiedzialność (AI Coding Assistants, docs.kernel.org, odczyt 30.10.2026). Kod generowany przez AI tego nie zmienia: odpowiedzialność za kod AI nie znika razem z promptem. Trzeba tylko ustalić, kto składa który podpis.

Wymóg oznaczania pomocy AI znacznikiem Assisted-by usunięto z tej dokumentacji w głównym repozytorium jądra commitem z 14.10.2026 (historia pliku, git.kernel.org), choć strona na docs.kernel.org jeszcze go pokazuje. Zakaz dodawania Signed-off-by przez AI został bez zmian.

Odpowiedź wprost

Za kod napisany przez AI odpowiada ten, kto go dostarcza, zatwierdza i uruchamia na produkcji: wykonawca wobec zamawiającego, a firma wobec swoich klientów. Narzędzie AI nie jest stroną umowy. Ochrona oferowana przez dostawców narzędzi, takich jak Microsoft czy Anthropic, obejmuje roszczenia o prawa autorskie osób trzecich, a nie błędy, luki ani przestoje.

Piszę jako Fractional CTO i programista PHP (Symfony, Laravel), który na co dzień pracuje z Claude Code i Codex.

W skrócie: cztery podpisy pod kodem od AI

Pod kodem od AI powinny stać cztery podpisy: code review, umowa, własność kodu i plan na awarię. Każdy ma właściciela z imienia i nazwiska, a tam, gdzie nazwiska brakuje, jest Twoje ryzyko.

Dlaczego „to napisała AI” nie jest wytłumaczeniem

Wobec zamawiającego za błędy odpowiada wykonawca, a wobec klientów odpowiada firma. Narzędzie AI nie jest stroną żadnej z tych umów, więc nie da się na nie przerzucić odpowiedzialności.

Dłużnik odpowiada za nienależyte wykonanie zobowiązania (art. 471 KC), a staranność profesjonalisty ocenia się z uwzględnieniem zawodowego charakteru działalności (art. 355 § 2 KC) (KC, t.j. Dz.U. 2026 poz. 795). Żaden przepis nie zwalnia wykonawcy dlatego, że użył AI. To wniosek z przepisów, bo orzeczenia o AI w kodzie brak.

Przykład procesu, nie straszak: w lipcu 2025 r. agent AI w serwisie Replit usunął produkcyjną bazę danych aplikacji założyciela SaaStr, mimo polecenia, by nie zmieniać kodu (The Register, 21.07.2025). Zabrakło rozdzielenia środowisk i człowieka zatwierdzającego zmiany. Więcej o ryzyku aplikacji z demo we wpisie o vibe codingu.

Wykonawca, firma, dostawca narzędzia: kto za co odpowiada

Kto odpowiada za błędy w kodzie AI, zależy od relacji: wykonawca przed Tobą, Ty przed klientami, a dostawca narzędzia głównie według własnego regulaminu.

• Wykonawca: za jakość i staranność wobec zamawiającego, w zakresie z umowy.
• Twoja firma: wobec klientów i urzędów, np. przy wycieku danych.
• Dostawca narzędzia AI: według swoich warunków. Anthropic w Commercial Terms (wersja od 17.06.2025) dostarcza wyniki „as is” i nie gwarantuje, że są bezbłędne (Anthropic, Commercial Terms).

Odpowiedzialność zarządu to osobny temat, opisany we wpisie o tym, czy CEO może sam programować z AI.

Czego nie da Ci ochrona od Microsoftu czy Anthropic

Ochrona od dostawców narzędzi dotyczy roszczeń osób trzecich o naruszenie praw autorskich do wyniku. Nie pokrywa błędów, luk bezpieczeństwa ani przestoju.

Microsoft w Customer Copyright Commitment broni klientów przed niektórymi roszczeniami z zakresu własności intelektualnej, także przy GitHub Copilot (od 3.04.2026 bez dodatkowych wymaganych zabezpieczeń) (Microsoft Learn). Anthropic broni klientów płatnych usług przed podobnymi roszczeniami (pkt K.1 Commercial Terms). Gdy kod nie działa albo ma dziurę, zostaje Ci umowa z wykonawcą.

Podpis nr 1: code review kodu AI

Pierwszy podpis składa człowiek z kompetencjami, który przeczytał zmianę i potrafi jej bronić. Nie może to być osoba, która wpisała prompt i przyjęła wynik bez czytania.

W Stack Overflow Developer Survey 2026 (n = 13 162) 9,6% programistów deklaruje, że używa odpowiedzi AI bez sprawdzania (Stack Overflow, odczyt 30.10.2026, dane na licencji ODbL). Według badania Veracode z 29.10.2026 około 38% rozwiązań wygenerowanych przez 18 modeli zawierało podatność (Veracode via Business Wire, 29.10.2026). To badanie producenta narzędzi bezpieczeństwa na zadaniach testowych, ale wniosek jest jasny: bezpieczeństwo kodu generowanego przez AI trzeba sprawdzać.

Kto powinien sprawdzać kod wygenerowany przez AI

Code review kodu AI to sprawdzenie zmiany przez człowieka, który rozumie system, zanim trafi ona na produkcję: czy robi to, co trzeba, czy jest bezpieczna i czy da się ją utrzymać. Recenzent podpisuje się pod zmianą tak, jakby napisał ją sam.

Zwykle to doświadczony programista lub architekt, a nie vibe coder. Przy migracjach aplikacji Symfony i Laravel z PHP 5 i PHP 7.4, które prowadziłem z Claude Code i Codex, AI najpierw przygotowywało plan zmian. Potem ręcznie go weryfikowałem i poprawiałem, a dopiero wtedy AI iteracyjnie wprowadzało zmiany, każdą sprawdzaną testami. Migracje trwały od 2–3 dni do tygodnia (więcej o aktualizacji PHP).

Minimum, które musi przejść każdy kod

Każda zmiana, także od AI, powinna przejść pięć kontroli przed wdrożeniem.

1. Bezpieczeństwo: walidacja danych, uprawnienia, brak haseł i kluczy w kodzie.
2. Testy: automatyczne, uruchamiane przy każdym wdrożeniu.
3. Zależności i licencje: czy AI nie dodało nieznanej biblioteki o niepasującej licencji.
4. Dane osobowe: gdzie trafiają i czy nie wyciekają do logów.
5. Commit z nazwiskiem człowieka: brak commita człowieka oznacza brak podpisu.

Jak sprawdzić, czy wykonawca naprawdę robi review, nie znając się na kodzie

Nie musisz czytać kodu. Wystarczą cztery pytania i dowody, które da się pokazać w pięć minut.

• Kto zatwierdza zmiany i czy to inna osoba niż autor?
• Pokażcie ostatnie trzy pull requesty z komentarzami recenzenta.
• Jakie testy uruchamiają się automatycznie i co się dzieje, gdy nie przejdą?
• Jakich narzędzi AI używacie i jakie nasze dane do nich trafiają?

Więcej w poradniku o kontroli software house'u.

Podpis nr 2: umowa z wykonawcą

Zakres odpowiedzialności wykonawcy ustala umowa. To ona decyduje, czy odpowiada on za rezultat, czy za staranność, i ile odzyskasz, gdy coś pójdzie źle.

Umowa z software house'em pracującym z AI podlega tym samym przepisom co zawsze. W umowie o dzieło wykonawca obiecuje rezultat (art. 627 KC), a przy usłudze ocenianej według przepisów o zleceniu odpowiada za należytą staranność (art. 750 KC). Między firmami można ograniczyć lub wyłączyć rękojmię (art. 558 § 1 KC), chyba że wadę podstępnie zatajono, ale nie da się z góry wyłączyć odpowiedzialności za szkodę wyrządzoną umyślnie (art. 473 § 2 KC) (KC, t.j. Dz.U. 2026 poz. 795). Rodzaj umowy oceni prawnik.

Co powinna zawierać klauzula AI

Klauzula AI w umowie mówi, jak wykonawca używa AI i kto ponosi skutki.

• Ujawnianie: czy i jakich narzędzi AI używa wykonawca.
• Review przez człowieka: każda zmiana sprawdzona przed przekazaniem.
• Wady i licencje: wykonawca odpowiada za kod niezależnie od tego, kto lub co go napisało.
• Dane firmy: zakaz wprowadzania kodu, danych klientów i tajemnic do narzędzi AI bez Twojej zgody.
• Odbiór: kryteria, testy akceptacyjne, kto podpisuje protokół.
• SLA i czas reakcji: osobno dla awarii krytycznych i drobnych.

Limity odpowiedzialności: na co uważać przy podpisywaniu

Uważaj zwłaszcza na limit równy wartości umowy połączony z wyłączeniem utraconych korzyści. Przy awarii, która zatrzymuje sprzedaż, taki limit może nie pokryć ułamka strat.

Szerzej o samej umowie piszę we wpisie umowa z software house, a konkretny tekst daj prawnikowi.

Podpis nr 3: do kogo należy kod

Prawa autorskie do kodu i faktyczna własność aplikacji to dwie osobne sprawy. Możesz mieć prawa na papierze i nie mieć dostępu do repozytorium.

Czy kod z AI ma prawa autorskie i co z tego wynika dla umowy

Kod wygenerowany przez AI bez twórczego wkładu człowieka najpewniej nie jest utworem. To dominujący pogląd w wykładni, bez polskiego orzeczenia, więc pewność jest średnia.

Ustawa chroni „każdy przejaw działalności twórczej o indywidualnym charakterze” (art. 1 ust. 1), a programy chroni jak utwory literackie (art. 74 ust. 1) (pr. aut., t.j. Dz.U. 2025 poz. 24). Prawa autorskie do kodu AI obejmują więc tylko wkład człowieka: dobór rozwiązań, edycję, architekturę. Ponieważ taki wkład zwykle jest, przeniesienie praw nadal jest potrzebne. Umowa musi wymieniać pola eksploatacji (art. 41 ust. 2 i art. 50) i mieć formę pisemną pod rygorem nieważności (art. 53). Przy B2B prawa bez takich zapisów nie przechodzą (automatycznie nabywa je tylko pracodawca, art. 74 ust. 3).

Repozytorium, hosting, domeny, klucze: co musi być na firmę

Ownership kodu oznacza, że to firma, a nie wykonawca, jest właścicielem repozytorium, kont i kluczy i ma do nich pełny dostęp bez pytania nikogo o zgodę.

Na firmę zakładasz repozytorium (GitHub, GitLab), konto hostingu lub chmury, domeny, konta w sklepach z aplikacjami, klucze API, także do narzędzi AI, i dostęp do kopii zapasowych. Wykonawca dostaje uprawnienia, które da się odebrać. Własność kodu aplikacji jest realna, gdy możesz jutro oddać projekt komuś innemu.

Jak udokumentować wkład człowieka

Wkład człowieka dokumentuje się na bieżąco, w narzędziach, których zespół i tak używa.

• Historia commitów z nazwiskami ludzi i opisami zmian.
• Decyzje architektoniczne: co wybrano, dlaczego i co odrzucono.
• Prompty i ich edycja przy większych zmianach, także plan od AI z poprawkami człowieka.

To rekomendacje kancelarii, nie wymóg przepisu.

Podpis nr 4: plan na awarię i utrzymanie

Ktoś z imienia i nazwiska musi wiedzieć, co robić, gdy aplikacja padnie: kto przejmuje incydent, jak wycofać wdrożenie i z czego przywrócić dane.

Pierwsza godzina po awarii: plan krok po kroku

Awaria aplikacji: co robić? Zatrzymać szkody, wycofać zmianę, sprawdzić dane i oddać sprawę jednej osobie. To praktyka, nie przepis.

Rollback to wycofanie wdrożenia do ostatniej działającej wersji aplikacji. Nie cofa zmian w danych, dlatego potrzebna jest też kopia zapasowa.

1. Wyznacz właściciela incydentu. Jedna osoba decyduje, reszta wykonuje.
2. Zatrzymaj szkody. Wyłącz wadliwą funkcję albo włącz tryb serwisowy.
3. Zrób rollback, zanim zaczniesz szukać przyczyny.
4. Sprawdź dane i w razie potrzeby przywróć je z kopii.
5. Oceń, czy chodzi o dane osobowe. Jeśli tak, uruchom procedurę RODO.
6. Komunikuj: co nie działa, co robicie, kiedy kolejna informacja.
7. Spisz wnioski bez szukania winnych.

Kopia, której nikt nie przywracał, jest tylko nadzieją.

Wyciek danych: 72 godziny na zgłoszenie do UODO

Przy naruszeniu ochrony danych osobowych administrator zgłasza je do UODO bez zbędnej zwłoki, w miarę możliwości w ciągu 72 godzin od stwierdzenia (art. 33 RODO), chyba że ryzyko dla osób jest mało prawdopodobne (UODO, odczyt 30.10.2026).

Administratorem jest Twoja firma, nie wykonawca. Zapisz w planie, kto decyduje o zgłoszeniu.

Kto utrzymuje kod, którego nikt nie napisał

Utrzymanie aplikacji napisanej przez AI wymaga człowieka, który zna kod, i drugiej osoby, która go zastąpi. Kod z AI nie ma autora, którego można zapytać, więc wiedza musi być w dokumentacji i w co najmniej dwóch głowach.

Zobacz, co się stanie, jeśli jutro odejdzie jedyny programista. Utrzymanie to też aktualizacje, np. aktualizacja PHP w firmie. Stałą opiekę prowadzę w ramach usługi rozwój aplikacji.

Stan prawny na 30.10.2026: co zmienia prawo w latach 2026–2027

Nowe przepisy unijne obejmują oprogramowanie, ale firmie zamawiającej kod dają mniej, niż sugerują nagłówki. W relacji z wykonawcą liczą się umowa i Kodeks cywilny.

To nie jest porada prawna. Sekcja opisuje stan na 30.10.2026 i przed publikacją wymaga przejrzenia przez prawnika.

Dyrektywa o odpowiedzialności za produkt: oprogramowanie to produkt, ale nie dla strat firmy

Dyrektywa o odpowiedzialności za produkt traktuje oprogramowanie jako produkt i obejmuje produkty wprowadzone na rynek po 9.12.2026 (art. 2 ust. 1). Odszkodowanie dostają jednak osoby fizyczne, a mienie i dane używane zawodowo są wyłączone (art. 6).

Dyrektywa chroni osoby fizyczne, a nie straty firmy. Gdy kod wykonawcy zatrzyma sprzedaż albo zniszczy firmowe dane, zostają umowa i KC. Polskie wdrożenie, UC163, jest na razie projektem.

Cyber Resilience Act: kogo dotyczy i od kiedy

Cyber Resilience Act wymaga od producentów zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów od 11.09.2026, a w pełni będzie stosowany od 11.12.2027 (Komisja Europejska, CRA: obowiązki zgłaszania). Dotyczy produktów z elementami cyfrowymi wprowadzanych do obrotu.

Czysty SaaS jest poza CRA (motyw 12), a aplikacja na własny użytek firmy co do zasady nie jest wprowadzana do obrotu. Granicę w Twoim przypadku oceni prawnik.

AI Act a programista: co naprawdę obowiązuje

Asystent kodu w typowym użyciu nie jest systemem wysokiego ryzyka. Firmę, która go używa, obowiązuje głównie art. 4 AI Act: zadbanie o kompetencje w zakresie AI osób pracujących z narzędziem.

Art. 4 stosuje się od 2.02.2025, a jego brzmienie zmieniło rozporządzenie Digital Omnibus (2026/1744), które przesunęło też obowiązki dla systemów wysokiego ryzyka z Załącznika III na 2.12.2027. Ocenę konkretnego zastosowania zostaw prawnikowi.

Karta podpisu: 10 pytań do siebie i do wykonawcy

Ta checklista to szybki audyt kodu napisanego przez AI od strony procesu. Pytanie, na które nie odpowiesz nazwiskiem albo dokumentem, jest pierwszym do załatwienia.

Tabelę możesz wysłać wykonawcy jako checklistę code review kodu AI i procesu.

Jak to ustawić w małej firmie bez własnego CTO

Mała firma bez CTO ma trzy ścieżki: audyt kodu, fractional CTO, który podpisuje się po stronie firmy, albo stałe utrzymanie z jasnym zakresem odpowiedzialności. Można je łączyć.

• Audyt kodu: zewnętrzny programista sprawdza kod, review, testy i dostępy. Przykład procesu: audyt kodu projektu na Laravel.
• Fractional CTO: doświadczona osoba na część etatu ustala zasady review, czyta umowy technicznie i pilnuje planu awaryjnego. Zobacz, czy mała firma potrzebuje CTO i jak działa fractional CTO.
• Stałe utrzymanie: aktualizacje, monitoring i reakcja na awarie z SLA w umowie.

Przy przejęciu kodu po poprzednim wykonawcy zacznij od ratowania projektu IT: najpierw dostępy i kopie, potem diagnoza.

FAQ: odpowiedzialność za kod AI

Kto odpowiada za kod napisany przez AI?

Za kod napisany przez AI odpowiada wykonawca wobec zamawiającego, a firma wobec swoich klientów i urzędów. Narzędzie AI nie jest stroną umowy, więc nie da się przerzucić na nie odpowiedzialności. To wniosek z art. 471 i 355 § 2 Kodeksu cywilnego, bo polskiego orzeczenia o AI w kodzie jeszcze nie ma.

Czy software house może zwolnić się z odpowiedzialności, bo użył AI?

Co do zasady nie, bo użycie AI nie zwalnia wykonawcy. Zakres odpowiedzialności ustala jednak umowa: między firmami można ograniczyć lub wyłączyć rękojmię (art. 558 KC), ale nie odpowiedzialność za szkodę wyrządzoną umyślnie (art. 473 § 2 KC). Dlatego przed podpisem sprawdź limity.

Czy kod wygenerowany przez AI ma prawa autorskie?

Ochronę ma tylko twórczy wkład człowieka. Kod wygenerowany przez AI bez takiego wkładu najpewniej nie jest utworem w rozumieniu prawa autorskiego. To dominujący pogląd w wykładni, ale polskiego orzeczenia brak. Warto więc dokumentować wkład człowieka i nadal zapisywać przeniesienie praw w umowie.

Kto jest właścicielem kodu, który napisała AI?

To osobne pytanie od praw autorskich. Faktyczną własność wyznaczają umowa i dostępy: kto jest właścicielem repozytorium, hostingu, domen, kluczy i dokumentacji. Przeniesienie praw wymaga umowy pisemnej z polami eksploatacji (art. 41, 50 i 53 prawa autorskiego). Repozytorium i konta zakładaj na firmę.

Czy w umowie z wykonawcą potrzebna jest klauzula o AI?

Tak, jest zalecana. Powinna obejmować ujawnianie użycia narzędzi AI, review każdej zmiany przez człowieka, odpowiedzialność wykonawcy za wady i licencje niezależnie od tego, kto napisał kod, zakaz wprowadzania danych firmy do narzędzi bez zgody oraz odbiór, SLA i czas reakcji.

Kto powinien robić code review kodu od AI i co sprawdzić?

Człowiek z kompetencjami, który nie jest autorem promptu, zwykle doświadczony programista lub tech lead. Minimum to bezpieczeństwo, testy, zależności i licencje, dane osobowe oraz commit z nazwiskiem człowieka. W Stack Overflow Developer Survey 2026 (n = 13 162) 9,6% programistów deklaruje używanie odpowiedzi AI bez sprawdzania.

Czy kod z AI jest mniej bezpieczny od kodu pisanego przez człowieka?

Uczciwa odpowiedź: wymaga weryfikacji. Według badania Veracode z 29.10.2026 około 38% rozwiązań wygenerowanych przez 18 modeli zawierało podatność. Badanie nie porównuje tego z kodem ludzi, więc nie przesądza, kto pisze bezpieczniej. Przesądza, że kodu od AI nie wolno wdrażać bez sprawdzenia.

Co zrobić w pierwszej godzinie po awarii aplikacji napisanej przez AI?

Wyznacz właściciela incydentu, zatrzymaj szkody, zrób rollback do ostatniej działającej wersji i sprawdź dane, w razie potrzeby przywracając je z kopii. Oceń, czy doszło do naruszenia danych osobowych, bo wtedy masz w miarę możliwości 72 godziny na zgłoszenie do UODO. Potem poinformuj zespół i klientów.

Czy dyrektywa o odpowiedzialności za produkt da mojej firmie odszkodowanie od dostawcy oprogramowania?

Zasadniczo nie za straty firmowe. Dyrektywa 2024/2853 daje odszkodowanie osobom fizycznym i wyłącza mienie oraz dane używane zawodowo. Obejmie produkty wprowadzone na rynek po 9.12.2026, a polskie wdrożenie (UC163) jest projektem. Dla firmy realną drogą pozostają umowa i Kodeks cywilny.

Czy Cyber Resilience Act dotyczy mojej aplikacji?

Raczej tylko wtedy, gdy wprowadzasz na rynek produkt z elementami cyfrowymi, czyli sprzedajesz oprogramowanie lub urządzenie. Czysty SaaS jest poza CRA, a aplikacja na własny użytek firmy co do zasady nie jest wprowadzana do obrotu. Zgłaszanie obowiązuje od 11.09.2026, pełne stosowanie od 11.12.2027.

Czy AI Act reguluje używanie asystentów kodu w firmie?

W niewielkim stopniu. Asystent kodu w typowym użyciu nie jest systemem wysokiego ryzyka. Firmę, która z niego korzysta, obowiązuje przede wszystkim art. 4 AI Act, czyli zadbanie o kompetencje w zakresie AI osób pracujących z narzędziem. Konkretne zastosowanie warto skonsultować z prawnikiem.

Co się stanie z aplikacją, jeśli jedyna osoba, która rozumie kod, odejdzie?

Firma traci ciągłość: nikt nie wie, jak bezpiecznie wprowadzać zmiany i naprawiać awarie. Przy kodzie od AI ryzyko rośnie, bo nie ma autora, którego można zapytać. Zabezpieczeniem są dokumentacja, repozytorium i konta na firmę oraz druga osoba, która zna kod i regularnie z nim pracuje.

Chcesz wiedzieć, kto podpisuje się pod Twoim kodem? Zrób audyt

Jeśli przy którymś z czterech podpisów nie umiesz wpisać nazwiska, zacznij od audytu kodu. Sprawdzę kod, proces review, umowę od strony technicznej, dostępy i plan na awarię, a potem powiem, co poprawić najpierw.

Wolisz najpierw porozmawiać? Umów rozmowę.

Zobacz wersję Markdown →