Umowa na wdrożenie AI. 6 klauzul, które ochronią Twój biznes przed kosztownymi sporami.

Twój software house właśnie podpisał umowę fixed-price na wdrożenie chatbota AI. Klient dostarczył bazę wiedzy pełną duplikatów i nieaktualnych danych. Model halucynuje. Klient odmawia odbioru. Sprawdzasz umowę — masz standardowy kontrakt IT. Nie ma tam ani słowa o jakości danych wejściowych, halucynacjach ani o tym, że dostawca modelu może jutro zmienić warunki API.

Scenariusz fikcyjny? Nie do końca. Sygnały branżowe wskazują na około 30-procentowy wzrost liczby sporów prawnych w firmach IT związanych z generatywną AI. A Rozporządzenie (UE) 2024/1689 (AI Act), które od 2 sierpnia 2026 r. w pełni obejmie systemy wysokiego ryzyka, wymaga od stron umowy spełnienia obowiązków, o których klasyczna umowa na wdrożenie IT w ogóle nie wspomina.

AI to system probabilistyczny, zależny od danych i zewnętrznych dostawców. Jeśli spróbujesz wpisać go w ramy klasycznego kontraktu na software — narażasz się na spory, których koszt wielokrotnie przekroczy wartość samego projektu.

W tym artykule znajdziesz 6 klauzul, które odróżniają bezpieczną umowę na wdrożenie AI od tykającej bomby. Dowiesz się, jak zdefiniować przedmiot umowy przez KPI, podzielić odpowiedzialność za dane, uregulować własność intelektualną do outputów AI i zabezpieczyć się przed awariami zewnętrznych API.

Najważniejsze pojęcia, zanim przejdziemy dalej

Zanim omówimy poszczególne klauzule, warto uporządkować kilka terminów, które będą się pojawiać w dalszej części artykułu.

Dlaczego klasyczna umowa IT nie działa przy wdrożeniach AI

Standardowa umowa na wdrożenie IT zakłada, że system działa deterministycznie — dostajesz zdefiniowany zakres funkcji, testujesz je, odbierasz. Wynik jest powtarzalny i przewidywalny.

System AI działa inaczej. Oto sześć różnic, które generują ryzyko, gdy nie są uwzględnione w umowie:

Każda z tych różnic wymaga osobnej klauzuli. Poniżej omawiamy sześć, które stanowią niezbędne minimum.

Klauzula 1: przedmiot umowy zdefiniowany przez KPI, nie przez funkcje

W klasycznej umowie IT opisujesz, co system ma robić (lista funkcji). W umowie na wdrożenie AI musisz opisać, jaki cel biznesowy ma osiągnąć — i jak zmierzysz, czy go osiągnął.

Dlaczego? Bo system probabilistyczny nigdy nie daje 100% trafności. Jeśli wpiszesz „system klasyfikuje dokumenty”, a nie zdefiniujesz progu akceptowalnej skuteczności — klient może odmówić odbioru przy 95% trafności, twierdząc, że oczekiwał 100%.

Co wpisać do umowy:

1. Cel biznesowy systemu (np. „automatyczna klasyfikacja faktur zakupowych według kategorii kosztowych”).
2. Mierzalne KPI z progami akceptacji (np. dokładność ≥90% na zbiorze testowym o zdefiniowanej strukturze).
3. Warunki pomiaru — na jakim zbiorze danych, w jakim okresie, kto przeprowadza testy.
4. Procedurę go/no-go po fazie PoC — z jasnym kryterium, kiedy projekt przechodzi do skalowania, a kiedy się kończy.

Model rozliczenia: Zamień fixed-price na podejście iteracyjne. PoC rozliczany jako osobna faza z własnym budżetem i kryteriami decyzji. Dopiero po pozytywnym PoC — skalowanie w modelu Time & Material z miesięcznymi przeglądami budżetu. Model fixed-price przy tak dużej niepewności co do zachowania modelu jest hazardem dla obu stron.

Klauzula 2: zarządzanie danymi i zasada Garbage In, Garbage Out

To najważniejszy bezpiecznik wykonawcy — i najczęściej pomijana klauzula.

Model AI uczy się na danych. Jeśli klient dostarczy bazę wiedzy pełną błędów, duplikatów i nieaktualnych informacji — model będzie generował błędne wyniki. Bez klauzuli GIGO wykonawca odpowiada za niską skuteczność modelu, choć przyczyna leży po stronie danych klienta.

Co wpisać do umowy:

1. Wymagania jakościowe dla danych wejściowych — kompletność, reprezentatywność, format, aktualność.
2. Procedurę walidacji danych — kto sprawdza dane przed rozpoczęciem treningu, jakie kryteria muszą spełnić.
3. Konsekwencje dostarczenia danych niespełniających wymagań — prawo wykonawcy do wstrzymania prac, wydłużenie terminów, dodatkowe koszty czyszczenia danych.
4. Odpowiedzialność za anonimizację i etykietowanie — precyzyjne przypisanie, kto odpowiada za przygotowanie danych (klient czy wykonawca).

Kwestia douczania modeli na danych klienta:

Tu pojawia się poważne ryzyko naruszenia RODO. Jeśli wykonawca douczył model ogólny na danych klienta (np. dane medyczne pacjentów) i używa tego modelu dla innych klientów — może dojść do naruszenia zasady ograniczenia celu (art. 5 RODO) i braku podstawy prawnej przetwarzania (art. 6 RODO).

Opinia Europejskiej Rady Ochrony Danych (EROD) 28/2024 potwierdza: modele AI trenowane na danych osobowych w pełni podlegają RODO. Ich rzekomą „anonimowość” należy oceniać indywidualnie — model nie może być automatycznie uznany za anonimowy tylko dlatego, że jest modelem.

Umowa musi regulować:

1. Czy wykonawca może używać danych klienta do trenowania modeli ogólnych (domyślnie: nie).
2. Kto jest administratorem, a kto podmiotem przetwarzającym dane w rozumieniu art. 28 RODO.
3. Zasady retencji i usuwania danych po zakończeniu umowy.
4. Obowiązek przeprowadzenia oceny skutków dla ochrony danych (DPIA) — art. 35 RODO — gdy system przetwarza dane na dużą skalę lub łączy dane z różnych źródeł.

Skontaktuj się z nami, jeśli potrzebujesz wsparcia przy audycie umów AI lub przygotowaniu klauzul chroniących Twoje dane.

Klauzula 3: zasada Back-to-Back wobec dostawców modeli AI

Twoja umowa na wdrożenie AI z klientem nie może obiecywać więcej, niż gwarantuje Ci dostawca technologii.

To brzmi oczywisto. A jednak software house’y regularnie wpisują w umowy SLA na poziomie 99,9% uptime, podczas gdy warunki korzystania z API dostawcy modelu nie zawierają żadnych gwarancji dostępności. Dostawcy tacy jak OpenAI oferują usługi „as-is” — bez gwarancji ciągłości, z limitem zapytań (RPM, RPD, TPM) i prawem do zmiany warunków.

Co zrobić:

1. Przeanalizuj warunki użytkowania (ToS) i SLA każdego dostawcy modelu, z którego korzystasz.
2. Przygotuj tabelę porównawczą: Twoje zobowiązania wobec klienta vs. gwarancje dostawcy.
3. Upewnij się, że Twoje SLA nie przekracza SLA dostawcy — w żadnym parametrze.
4. Wpisz do umowy klauzulę informacyjną: klient wie, że system korzysta z zewnętrznego API i akceptuje ograniczenia wynikające z warunków dostawcy.

Art. 25 ust. 4 AI Act wprost wymaga, aby dostawca systemu AI wysokiego ryzyka i każda osoba trzecia dostarczająca komponenty lub usługi zintegrowane z systemem zawarli pisemną umowę określającą zakres informacji, dostępu technicznego i pomocy. To bezpośrednia podstawa prawna dla klauzuli Back-to-Back.

Dodatkowe ryzyko: od 2 sierpnia 2025 r. dostawcy modeli GPAI mają obowiązek publikowania streszczeń zbiorów danych chronionych prawem autorskim, wykorzystanych w trenowaniu. Jeśli okaże się, że model był trenowany na danych naruszających prawa autorskie — Twoja umowa powinna regulować, kto ponosi odpowiedzialność.

Klauzula 4: własność intelektualna do outputów AI i ulepszeń modelu

To co wygeneruje AI, często nie jest chronione prawem autorskim. Polskie prawo autorskie (art. 1 ust. 1 ustawy z 4 lutego 1994 r.) wymaga „osobistego udziału twórczego” — a treści wygenerowane samodzielnie przez system AI tego warunku nie spełniają.

Stan prawny w Polsce (stan na I kwartał 2025 r.):

1. Polskie sądy nie wydały żadnego orzeczenia bezpośrednio dotyczącego statusu prawnego outputów AI.
2. Projekt nowelizacji ustawy o prawie autorskim (druk sejmowy nr 1245) zawierał art. 7a o „utworach powstających w wyniku działania systemów automatycznych” — został usunięty po konsultacjach z powodu braku konsensusu.
3. Sprawa Thaler v. Perlmutter (USA, 9th Cir. 2023) potwierdziła, że prawo autorskie USA wymaga „ludzkiego autora” — orzeczenie nie jest wiążące w Polsce, ale wskazuje kierunek interpretacji.
4. Dyrektywa 2019/790 (Copyright Directive) reguluje wyjątek TDM (text and data mining) dla trenowania modeli, ale nie rozstrzyga kwestii ochrony outputów.

Konsekwencja: Prawa do outputów AI musisz regulować wyłącznie kontraktowo. Nie możesz polegać na ochronie ustawowej.

Co wpisać do umowy:

1. Definicję „outputów AI” jako danych wyjściowych objętych licencją lub tajemnicą przedsiębiorstwa (nie prawem autorskim).
2. Przypisanie praw ekonomicznych do outputów — klientowi lub wykonawcy, w zależności od modelu współpracy.
3. Regulację własności ulepszeń modelu (fine-tuned weights) — czy wykonawca może wykorzystywać ulepszone wagi w innych projektach.
4. Klauzulę weryfikacji outputów pod kątem plagiatu i nieuprawnionych przeróbek cudzych utworów.
5. Zakaz przypisywania treści wygenerowanych przez AI człowiekowi — wymóg wynikający z warunków użytkowania dostawców modeli (np. OpenAI).

Klauzula 5: podział odpowiedzialności — błąd w kodzie vs. halucynacja modelu

W klasycznej umowie IT odpowiedzialność za błędy jest prosta: jeśli system nie działa zgodnie ze specyfikacją — wina wykonawcy. W umowie na wdrożenie AI musisz rozdzielić trzy kategorie przyczyn błędów:

Klauzula human-in-the-loop:

AI Act wymaga nadzoru człowieka nad systemami wysokiego ryzyka. Ale nawet przy systemach niebędących systemami wysokiego ryzyka — wpisanie obowiązku weryfikacji wyników AI przez człowieka po stronie klienta przed podjęciem decyzji biznesowej chroni obie strony.

Zdefiniuj w umowie, które decyzje wymagają ludzkiej weryfikacji. Przykład: system AI generujący raporty finansowe — klient musi zweryfikować raport przed podjęciem decyzji inwestycyjnej. Jeśli tego nie zrobi i poniesie stratę na podstawie halucynacji modelu — odpowiedzialność spoczywa na kliencie.

Art. 22 RODO dodatkowo wzmacnia tę zasadę: osoba fizyczna ma prawo do niepodlegania decyzji opartej wyłącznie na zautomatyzowanym przetwarzaniu, jeśli decyzja wywołuje skutki prawne lub w podobny sposób istotnie na nią wpływa. Prawo do „interwencji człowieka” musi być realne — nie „rubber stamping”.

Odpowiedzialność za szkody wyrządzone przez AI — stan prawny UE:

Projekt dyrektywy o odpowiedzialności za AI (AILD), który miał wprowadzić domniemanie związku przyczynowego i ułatwić poszkodowanym dochodzenie roszczeń, został formalnie wycofany w październiku 2025 r. Oznacza to, że odpowiedzialność za szkody wyrządzone przez AI pozostaje regulowana wyłącznie przez krajowe przepisy deliktowe — w Polsce art. 415 k.c. (odpowiedzialność na zasadzie winy) i art. 435–436 k.c. (odpowiedzialność na zasadzie ryzyka). Brak unijnych domniemań dowodowych sprawia, że precyzyjne klauzule umowne są jedynym narzędziem regulującym podział odpowiedzialności między stronami.

Klauzula 6: zgodność z AI Act i mechanizm adaptacji regulacyjnej

AI Act obowiązuje etapowo. Część obowiązków już weszła w życie, część wejdzie w najbliższych miesiącach i latach. Twoja umowa na wdrożenie AI musi to uwzględniać.

Kalendarz obowiązków — co już obowiązuje i co nadchodzi:

Kary za naruszenie AI Act:

Ryzyko zmiany roli — art. 25 AI Act:

Jednym z najpoważniejszych ryzyk kontraktowych jest nieświadome przejście z roli podmiotu stosującego na dostawcę systemu AI wysokiego ryzyka. Wystarczy, że Twoja firma:

1. Oznaczy system własnym logo lub znakiem towarowym.
2. Istotnie zmodyfikuje działanie systemu (np. fine-tuning zmieniający przeznaczenie).
3. Zmieni przeznaczenie systemu niebędącego dotąd systemem wysokiego ryzyka w sposób powodujący, że nim się staje.

W każdym z tych przypadków przejmujesz pełen katalog obowiązków dostawcy z art. 16 AI Act — w tym ocenę zgodności, dokumentację techniczną przechowywaną przez co najmniej 10 lat, nadzór człowieka i rejestrację w unijnej bazie danych.

Co wpisać do umowy:

1. Precyzyjną definicję przeznaczenia systemu — to od niego zależy kategoria ryzyka.
2. Zakaz zmiany przeznaczenia systemu bez pisemnej zgody dostawcy i analizy wpływu na klasyfikację.
3. Klauzulę adaptacyjną — obowiązek informowania drugiej strony o zmianach prawa mogących zmienić klasyfikację systemu.
4. Podział odpowiedzialności za kary regulacyjne — kto odpowiada, jeśli system zostanie uznany za niezgodny z AI Act.
5. Obowiązek prowadzenia logów i dokumentacji technicznej zgodnie z wymogami AI Act.

Checklista: 6 klauzul umowy na wdrożenie AI

Zanim podpiszesz umowę, sprawdź, czy zawiera wszystkie sześć elementów:

Jeśli na którekolwiek z tych pytań odpowiedź brzmi „nie” — Twoja umowa wymaga korekty.

Możemy Ci w tym pomóc

Przygotowanie umowy na wdrożenie AI wymaga połączenia wiedzy z trzech obszarów: prawa umów, prawa IT/IP i regulacji AI Act/RODO. Standardowy wzór umowy IT nie uwzględnia żadnego z sześciu opisanych wyżej ryzyk.

Wspieramy founderów, CTO i liderów produktowych firm technologicznych w porządkowaniu kontraktów AI — od audytu istniejących umów po przygotowanie nowych wzorów dopasowanych do modelu działalności.

Zakres wsparcia:

1. Audyt aktualnych umów IT/AI pod kątem 6 klauzul opisanych w artykule — z raportem ryzyk i rekomendacjami.
2. Przygotowanie wzorów umów na wdrożenie AI — z klauzulami KPI, GIGO, Back-to-Back, IP, podziału odpowiedzialności i zgodności z AI Act.
3. Analiza warunków użytkowania dostawców modeli (OpenAI, Google, Anthropic) — tabela porównawcza zobowiązań.
4. Wsparcie przy negocjacjach z klientami i dostawcami — gotowe warianty negocjacyjne zamiast teoretycznych analiz.
5. Szkolenie dla zespołu sprzedaży i project managerów — jak wyjaśnić klientowi, dlaczego fixed-price na AI to ryzyko dla obu stron.

Nie tworzymy dokumentów „na zapas”. Projektujemy zasady tam, gdzie faktycznie powstaje ryzyko — od developmentu po sprzedaż.

Umowa na wdrożenie AI to Twoje jedyne zabezpieczenie

Brak polskiego orzecznictwa dotyczącego outputów AI, wycofanie dyrektywy AILD i etapowe wdrażanie AI Act oznaczają jedno: umowa na wdrożenie AI jest jedynym narzędziem, które reguluje podział odpowiedzialności, własność IP i zasady współpracy w projektach AI.

Sześć klauzul opisanych w tym artykule — przedmiot z KPI, zarządzanie danymi, Back-to-Back, IP, podział odpowiedzialności, zgodność z AI Act — stanowi niezbędne minimum. Bez nich każde wdrożenie AI niesie ryzyko sporu, którego koszt wielokrotnie przekroczy wartość przygotowania solidnej umowy.

Jeśli wdrażasz lub sprzedajesz rozwiązania AI i chcesz uporządkować swoje kontrakty — napisz do nas. Przejrzymy Twoją umowę i wskażemy, gdzie są luki.

Najczęściej zadawane pytania

Mam standardowy wzór umowy na wdrożenie IT — co dokładnie muszę w nim zmienić, żeby nadawał się do projektów AI?

Musisz dodać co najmniej sześć klauzul: przedmiot umowy zdefiniowany przez KPI (nie przez listę funkcji), zasady zarządzania danymi z klauzulą GIGO, zasadę Back-to-Back wobec dostawców modeli, regulację własności IP do outputów i ulepszeń modelu, podział odpowiedzialności rozdzielający bug w kodzie od halucynacji modelu i złych danych, oraz klauzulę zgodności z AI Act z mechanizmem adaptacji regulacyjnej. Standardowa umowa IT nie uwzględnia probabilistycznego charakteru AI, zależności od zewnętrznych API ani braku ochrony prawnoautorskiej outputów.

Czy mogę użyć danych klienta do trenowania mojego ogólnego modelu i potem oferować go innym firmom?

Domyślnie — nie, chyba że umowa wyraźnie na to zezwala i masz odrębną podstawę prawną w rozumieniu art. 6 RODO. Opinia EROD 28/2024 potwierdza, że modele AI trenowane na danych osobowych w pełni podlegają RODO. Dane zebrane w jednym celu (np. obsługa klienta) nie mogą być automatycznie używane do trenowania modeli dla innych podmiotów bez nowej podstawy prawnej. Naruszenie tej zasady grozi odpowiedzialnością na gruncie RODO (do 20 mln EUR lub 4% obrotu) oraz roszczeniami cywilnymi klientów.

Jak zdefiniować w umowie „sukces” wdrożenia AI, skoro model jest probabilistyczny?

Zdefiniuj sukces przez mierzalne KPI z progami akceptacji — np. dokładność modelu ≥90% na zdefiniowanym zbiorze testowym, czas odpowiedzi ≤1 sekundy, dostępność ≥99,5%. Określ warunki pomiaru: na jakim zbiorze danych, w jakim okresie, kto przeprowadza testy. Zastosuj podejście iteracyjne: najpierw PoC z kryteriami go/no-go, dopiero potem skalowanie. Unikaj fixed-price bez wcześniejszego PoC — przy probabilistycznym charakterze AI ryzyko przekroczenia budżetu lub niespełnienia oczekiwań jest zbyt wysokie.

Co jeśli dostawca modelu (np. OpenAI) nagle zmieni warunki API?

Wpisz do umowy klauzulę Back-to-Back: Twoje zobowiązania wobec klienta nie mogą przekraczać gwarancji dostawcy. Dodaj klauzulę informacyjną — klient wie, że system korzysta z zewnętrznego API i akceptuje ograniczenia wynikające z warunków dostawcy. Wyłącz odpowiedzialność za awarie zewnętrznych API w katalogu siły wyższej. Przygotuj plan migracji na alternatywnego dostawcę modelu — i wpisz do umowy, kto ponosi koszty takiej migracji.

Czy outputy wygenerowane przez AI (raporty, grafiki, teksty) należą do mnie czy do klienta?

Polskie prawo autorskie nie chroni outputów wygenerowanych samodzielnie przez AI — brak „osobistego udziału twórczego” w rozumieniu art. 1 ust. 1 ustawy o prawie autorskim. Polskie sądy do końca I kwartału 2025 r. nie wydały żadnego orzeczenia w tej sprawie. Prawa do outputów musisz regulować wyłącznie kontraktowo: zdefiniuj outputy AI jako „dane wyjściowe” objęte licencją lub tajemnicą przedsiębiorstwa i przypisz prawa ekonomiczne konkretnej stronie umowy.

Czy powinienem robić PoC przed głównym wdrożeniem i jak to ubrać w umowę?

Tak. PoC powinien być rozliczany jako osobna faza z własnym budżetem, harmonogramem i kryteriami go/no-go. W umowie zdefiniuj: zakres PoC (np. testowanie modelu na próbce danych klienta), KPI decydujące o przejściu do skalowania (np. trafność ≥85% na zbiorze testowym), konsekwencje negatywnego wyniku (zamknięcie projektu bez dodatkowych zobowiązań) i model rozliczenia dalszych prac (np. Time & Material z miesięcznymi przeglądami budżetu).