Wykonawca przysyła czterostronicową umowę, w której „sztuczna inteligencja“ pada raz — w tytule. Reszta to szablon przeklejony z wdrożenia strony internetowej: etapy, faktura, kara za zwłokę. Pół roku później nie wiesz, czyje są prompty, kto płaci rachunek za tokeny i co zrobicie, gdy dostawca modelu wycofa wersję, na której stoi całe wdrożenie.
Co musi znaleźć się w umowie na wdrożenie AI — dziewięć punktów
Umowa na wdrożenie AI w MŚP musi rozstrzygać dziewięć rzeczy, których standardowa umowa IT w ogóle nie dotyka: (1) warstwową definicję przedmiotu — osobno model bazowy, osobno konfiguracja i kod; (2) prawa do każdej z tych warstw, w formie pisemnej i z wymienionymi polami eksploatacji; (3) kto zakłada konto u dostawcy modelu i kto płaci za zużycie; (4) zakaz trenowania modeli na danych zamawiającego; (5) umowę powierzenia przetwarzania danych osobowych zgodną z art. 28 RODO; (6) podział ról wynikający z AI Act — kto jest dostawcą, a kto podmiotem stosującym; (7) SLA rozdzielone na dostępność i jakość odpowiedzi, z mierzalnymi progami; (8) kryteria odbioru uzgodnione, zanim ruszą prace, na zestawie testowym zamawiającego; (9) zasady zakończenia współpracy — eksport danych, dokumentacja, przekazanie wiedzy. Brak choćby jednego z tych punktów oznacza, że w sporze zostajesz z argumentem „przecież umawialiśmy się inaczej“, a nie z zapisem umownym.
Dlaczego szablon umowy IT tu nie wystarcza
Klasyczna umowa wdrożeniowa stoi na dwóch założeniach: że wykonawca jest właścicielem tego, co dostarcza, i że dostarczony system zachowuje się tak samo w poniedziałek i w czwartek. Wdrożenie AI łamie oba. Znaczna część systemu nigdy do wykonawcy nie należała, a jego zachowanie potrafi się zmienić bez niczyjej ingerencji — bo dostawca modelu podmienił wersję albo obciął limity.
Do tego dochodzi kwalifikacja samej umowy. Praca nad konkretnym rezultatem — uruchomieniem asystenta na dokumentach firmy — to raczej umowa o dzieło (art. 627 Kodeksu cywilnego), a bieżąca opieka i dostrajanie to umowa o świadczenie usług, do której stosuje się przepisy o zleceniu (art. 750 KC). Większość wdrożeń AI jest mieszana i warto to nazwać wprost, bo od kwalifikacji zależą rękojmia i sposób rozwiązania umowy.
Prawa do modelu: czego wykonawca nie może Ci sprzedać
Najczęstsze nieporozumienie brzmi tak: „kupujemy model AI na własność“. Nie kupujesz. Model bazowy — GPT, Claude, Gemini, Llama — zostaje własnością swojego dostawcy, a Ty korzystasz z niego na warunkach jego licencji. Wykonawca nie przeniesie na Ciebie praw, których sam nie ma.
To, co realnie kupujesz, leży warstwę wyżej: konfiguracja, prompty, kod integracji, dane i dokumentacja. Dlatego przedmiot umowy rozpisz warstwami, zamiast kwitować go jednym zdaniem „wdrożenie systemu AI“.
| Warstwa wdrożenia | Czy wykonawca może przenieść prawa? | Co wpisać do umowy |
|---|---|---|
| Model bazowy (GPT, Claude, Gemini, Llama) | Nie — nie jest jego właścicielem | Nazwa i wersja modelu, licencja dostawcy, tryb postępowania przy wycofaniu wersji |
| Dostrojenie modelu (fine-tuning, adapter) | Częściowo — wagi to zbiór liczb, niekoniecznie utwór | Wyłączne prawo korzystania, zakaz użycia u innych klientów, wydanie plików adaptera |
| Prompty, instrukcje systemowe, konfiguracja agenta | Tak, jeśli mają cechy utworu | Przeniesienie praw albo licencja wyłączna — na piśmie, z wymienionymi polami eksploatacji |
| Kod integracji, skrypty, wtyczki | Tak | Przeniesienie praw, wydanie repozytorium, oświadczenie o nabyciu praw od podwykonawców |
| Twoje dane, baza wektorowa, embeddingi | Dane są Twoje od początku | Zakaz trenowania, zwrot i usunięcie, format eksportu |
| Dokumentacja, schematy procesów, materiały | Tak | Przeniesienie praw, aktualność na dzień odbioru |
O tym, co naprawdę na Ciebie przechodzi, decydują trzy przepisy ustawy o prawie autorskim i prawach pokrewnych z 4 lutego 1994 r. Przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53) — skan podpisanej umowy odesłany mailem tego warunku nie spełnia, chyba że obie strony złożyły kwalifikowany podpis elektroniczny. Umowa obejmuje wyłącznie te pola eksploatacji, które wymieniono w niej wprost (art. 41 ust. 2), więc wypisz zwielokrotnianie, modyfikację, tłumaczenie i rozpowszechnianie kodu. Licencja wyłączna również wymaga formy pisemnej pod rygorem nieważności (art. 67 ust. 5).
Osobna pułapka: jeśli umowa nie mówi inaczej, licencja uprawnia do korzystania z utworu przez pięć lat, a potem prawo wygasa (art. 66). Gdy wykonawca proponuje licencję zamiast przeniesienia praw, dopisz przynajmniej „na czas nieoznaczony“ — ale pamiętaj, że licencję na czas nieoznaczony druga strona może wypowiedzieć (art. 68 ust. 1). Przy warstwach, bez których wdrożenie przestaje działać, bezpieczniejsze jest przeniesienie praw.
Zażądaj też oświadczenia, że wykonawca ma prawa po swoich programistach. Majątkowe prawa do programu stworzonego przez pracownika w ramach obowiązków służbowych przysługują pracodawcy, o ile umowa nie stanowi inaczej (art. 74 ust. 3). Przy współpracownikach na kontraktach B2B ta reguła nie działa — prawa musi przenieść osobna umowa na każdym ogniwie łańcucha, a ich brak stanie się Twoim problemem, nie wykonawcy.
Kto płaci za tokeny i kto ma konto
Tego zapisu nie ma w żadnym szablonie, a potrafi kosztować najwięcej. Ustal, kto zakłada konto u dostawcy modelu. Rozsądniej, żeby zrobił to zamawiający: widzisz wtedy zużycie na bieżąco i nie tracisz systemu w dniu zerwania współpracy. Wariant drugi jest taki, że wykonawca kupuje zużycie i odsprzedaje Ci je z narzutem.
Przy odsprzedaży żądaj miesięcznego zestawienia zużycia, jawnej wysokości narzutu i limitu budżetowego z automatycznym alertem. Bez limitu jedna zapętlona automatyzacja potrafi wygenerować rachunek, którego nikt nie zatwierdził.
Dane osobowe: powierzenie, zakaz trenowania, przekazywanie poza EOG
Jeśli system przetwarza dane osobowe — a asystent podpięty do firmowej skrzynki albo do CRM-u przetwarza je zawsze — potrzebujesz umowy powierzenia z art. 28 RODO. Musi opisywać przedmiot, czas trwania, charakter i cel przetwarzania, rodzaj danych oraz kategorie osób, których dane dotyczą. Musi też zobowiązywać wykonawcę do działania wyłącznie na Twoje udokumentowane polecenie, do zachowania poufności, do wdrożenia zabezpieczeń z art. 32, do korzystania z dalszych podmiotów przetwarzających tylko za Twoją zgodą, do pomocy przy realizacji praw osób oraz do zwrotu albo usunięcia danych po zakończeniu współpracy.
Do tego dwa zapisy, których w typowym wzorze powierzenia nie znajdziesz. Pierwszy: zakaz wykorzystywania danych zamawiającego do trenowania i ulepszania jakichkolwiek modeli — również przez dalsze podmioty przetwarzające. Drugi: imienna lista dalszych podmiotów przetwarzających wraz z krajami, w których przetwarzają dane. Większość dostawców modeli pracuje poza EOG, a przekazanie danych poza EOG wymaga podstawy z rozdziału V RODO — najczęściej standardowych klauzul umownych. Szerzej o tym w tekście o bezpieczeństwie danych przy AI w MŚP.
AI Act: ustal, kim jesteś w łańcuchu
Rozporządzenie (UE) 2024/1689 rozróżnia dostawcę systemu AI i podmiot stosujący. Kupując gotowe wdrożenie, jesteś zwykle podmiotem stosującym. Jeśli jednak oznaczysz system własną marką, istotnie go zmienisz albo użyjesz go do czegoś innego, niż przewidziano, sam stajesz się dostawcą — z całym pakietem obowiązków (art. 25). Umowa powinna wprost przypisywać role i zobowiązywać wykonawcę do wydania dokumentacji technicznej oraz instrukcji stosowania.
Kalendarz stosowania rozłożono na etapy: przepisy o zakazanych praktykach i o kompetencjach w zakresie AI obowiązują od 2 lutego 2025 r., obowiązki transparentności z art. 50 — od 2 sierpnia 2026 r. Terminy dla systemów wysokiego ryzyka przesunął przyjęty w czerwcu 2026 r. pakiet Digital Omnibus: samodzielne systemy z załącznika III — na 2 grudnia 2027 r., AI w produktach regulowanych z załącznika I — na 2 sierpnia 2028 r. Przed podpisaniem umowy sprawdź stan faktyczny w EUR-Lex, a status polskiej ustawy wdrażającej — w wykazie prac legislacyjnych Rządowego Centrum Legislacji. Nie opieraj się na dacie z prezentacji sprzedażowej.
Jeśli system rozmawia z klientami albo generuje treści, dopisz obowiązek oznaczania, że rozmówcą jest AI, oraz zasady nadzoru człowieka nad decyzjami systemu — kto zatwierdza, przy jakich kwotach, jak wygląda ścieżka eskalacji.
SLA: dostępność to nie to samo co jakość
Standardowe SLA mówi o dostępności usługi. Przy AI to za mało, bo system może być dostępny przez 99,9% czasu i przez cały ten czas odpowiadać błędnie. Rozdziel dwie grupy zobowiązań.
Dostępność i obsługa awarii. Zapisz miesięczny poziom dostępności, osobno czas reakcji i osobno czas naprawy (to nie synonimy), klasyfikację zgłoszeń, okna serwisowe i kanał zgłoszeń. Wyłączenia z SLA wylicz zamkniętą listą — awaria po stronie dostawcy modelu jest wyłączeniem uzasadnionym, ale dopisz wtedy obowiązek uruchomienia trybu awaryjnego albo modelu zapasowego.
Jakość odpowiedzi. Zapisz minimalną skuteczność na zestawie testowym, maksymalny odsetek odpowiedzi błędnych, odsetek spraw przekazywanych człowiekowi i czas obsługi. Dodaj test regresji: po każdej zmianie modelu albo promptów wykonawca ponownie uruchamia zestaw testowy, a wynik poniżej progu liczy się jako usterka do naprawy w ramach umowy.
Za niedotrzymanie SLA strony umawiają się zwykle na bonifikatę w kolejnym okresie rozliczeniowym albo na karę umowną. Pamiętaj, że karę umowną można zastrzec wyłącznie za niewykonanie lub nienależyte wykonanie zobowiązania niepieniężnego (art. 483 § 1 KC), a odszkodowania przewyższającego karę żąda się tylko wtedy, gdy strony wprost to zapisały (art. 484 § 1 KC). Bez tego jednego zdania kara zostaje Twoim jedynym roszczeniem.
Odbiór wdrożenia: kryteria uzgadniasz, zanim ruszą prace
Najdroższe spory biorą się z odbioru bez kryteriów. Zasada jest jedna: zestaw testowy przygotowuje zamawiający, przed rozpoczęciem prac, i trafia on do umowy jako załącznik. Rozsądny rozmiar to 100–300 realnych przypadków z Twojej firmy — pytań klientów, faktur, zgłoszeń — z opisanym wynikiem oczekiwanym dla każdego.
Dalej opisz procedurę: testy akceptacyjne po stronie zamawiającego, termin na zgłoszenie uwag, protokół odbioru z listą usterek i terminem ich usunięcia, prawo do odbioru warunkowego oraz prawo odmowy odbioru przy wadzie istotnej. Uważaj na klauzulę milczącego odbioru („brak uwag w ciągu 7 dni oznacza odbiór“). Jeśli już się na nią godzisz, wydłuż termin i licz go od dnia udostępnienia kompletnej dokumentacji, a nie od maila z jednym słowem „gotowe“.
Osobno zapisz okres stabilizacji po odbiorze — zwykle od miesiąca do trzech, w którym usterki naprawiane są bez dodatkowego wynagrodzenia — oraz warunki rękojmi. Do rękojmi za wady dzieła stosuje się odpowiednio przepisy o rękojmi przy sprzedaży (art. 638 KC), ale w relacji B2B strony mogą ją ograniczyć albo wyłączyć. Sprawdź, czy wykonawca nie zrobił tego jednym zdaniem w rozdziale „Postanowienia końcowe“.
Odpowiedzialność, poufność, rozstanie z wykonawcą
Wykonawcy standardowo ograniczają odpowiedzialność do wysokości wynagrodzenia i wyłączają utracone korzyści. To do przyjęcia, jeśli wyjmiesz spod limitu trzy kategorie: naruszenie ochrony danych osobowych, naruszenie praw autorskich osób trzecich i naruszenie tajemnicy przedsiębiorstwa. Niezależnie od tego, co strony zapiszą, nieważne jest zastrzeżenie, że dłużnik nie odpowiada za szkodę wyrządzoną umyślnie (art. 473 § 2 KC).
Poufność oprzyj na definicji tajemnicy przedsiębiorstwa z art. 11 ustawy o zwalczaniu nieuczciwej konkurencji i rozciągnij ją na prompty oraz dane treningowe. Zapytaj też o polisę OC z tytułu prowadzonej działalności — jeśli wykonawca jej nie ma, limit odpowiedzialności jest wart tyle, ile jego majątek.
Na koniec to, co pomija się najczęściej: zasady rozstania. Eksport wszystkich danych i konfiguracji w formacie czytelnym bez narzędzi wykonawcy, przekazanie repozytorium i dostępów, dokumentacja aktualna na dzień zakończenia, kilkutygodniowe wsparcie przejściowe, a przy większych wdrożeniach — depozyt kodu źródłowego u notariusza albo u wyspecjalizowanego depozytariusza, otwierany w razie upadłości wykonawcy lub zaprzestania wsparcia.
Zanim podpiszesz
Poproś wykonawcę, żeby wskazał w projekcie umowy dziewięć punktów z początku tego tekstu — numerami paragrafów. To test na pięć minut: kto wdrażał AI przed Tobą, wskaże je bez zastanowienia. Kto przysłał szablon, zacznie tłumaczyć, że „to standard rynkowy“.
Umowę na wdrożenie AI negocjuj równolegle z liczeniem opłacalności projektu — limit odpowiedzialności i sposób rozliczania zużycia zmieniają rachunek zwrotu z wdrożenia mocniej niż sama cena z oferty.
Materiał edukacyjny, nie stanowi porady prawnej. Stan na 2026 r. — interpretacja przepisów AI Act może się zmieniać.