Umowa na wdrożenie AI różni się od typowej umowy na wdrożenie systemu IT w kilku miejscach, które łatwo przeoczyć w entuzjazmie po udanym demo. Poniżej checklista tego, co warto sprawdzić przed podpisem — z perspektywy firmy zamawiającej, nie dostawcy.

Dlaczego umowa na AI wymaga innego podejścia

Klasyczna umowa wdrożeniowa odpowiada głównie na pytania o zakres, harmonogram i cenę. Umowa na wdrożenie AI musi odpowiedzieć dodatkowo na pytania, które przy zwykłym oprogramowaniu rzadko się pojawiają: kto jest właścicielem tego, co zostało skonfigurowane dla Twojej firmy, co się dzieje z danymi, które trafiają do modelu, i kto odpowiada, gdy model się pomyli w sposób, który kosztuje pieniądze. Pominięcie tych pytań na etapie podpisu nie sprawia, że znikają — wracają później, zwykle w gorszym momencie niż podczas negocjacji.

Poniższa checklista nie jest listą formalności do odhaczenia. To pytania, które warto zadać na głos w trakcie rozmowy z potencjalnym dostawcą, zanim padnie propozycja konkretnych zapisów umownych — sposób, w jaki dostawca na nie odpowiada, mówi często więcej niż sam projekt umowy.

Własność promptów, modeli i danych

Pierwszy blok pytań dotyczy tego, co faktycznie powstaje w trakcie wdrożenia i do kogo to należy.

Prompty i instrukcje. Dostawca buduje dla Twojej firmy konkretne prompty, szablony instrukcji i logikę, która steruje tym, jak model odpowiada na Wasze dane. Warto mieć w umowie jasno napisane, że to Wy jesteście właścicielem tej konfiguracji — nie dostawca, który mógłby ją potem wykorzystać u konkurencji albo zatrzymać przy zakończeniu współpracy.

Dane trafiające do modelu. Warto sprawdzić wprost, czy dane Waszej firmy — dokumenty, zapytania klientów, dane finansowe — mogą być wykorzystywane do trenowania albo dostrajania modelu dostawcy usługi AI. W większości przypadków odpowiedź powinna brzmieć „nie, bez wyraźnej, osobnej zgody” — a umowa powinna to stwierdzać wprost, a nie milczeć na ten temat.

Dane wejściowe i wynikowe. Kto jest właścicielem danych, które trafiają do systemu, i wyników, które on generuje? To pytanie wydaje się oczywiste, dopóki nie okaże się, że umowa go w ogóle nie porusza — a wtedy domyślna odpowiedź bywa mniej korzystna dla zamawiającego niż milczące założenie.

Warunki wyjścia

Umowa, która dobrze opisuje start współpracy, ale milczy na temat jej zakończenia, jest niekompletna — niezależnie od tego, jak dobrze wygląda reszta.

Warto sprawdzić, czy w razie zakończenia współpracy da się odzyskać dane, prompty i konfigurację w formacie, który nadaje się do dalszego użycia — nie tylko w teorii, ale w praktyce, bez konieczności odtwarzania wszystkiego od zera u nowego dostawcy. Dobra umowa określa też okres przejściowy i zakres dokumentacji przekazania: co dokładnie dostajecie, w jakim terminie i w jakiej formie, jeśli zdecydujecie się zmienić dostawcę albo przenieść wdrożenie do zespołu wewnętrznego.

Brak jasnych warunków wyjścia to jeden z najczęstszych powodów, dla których firmy zostają przy dostawcy dłużej, niż chciałyby — nie dlatego, że są zadowolone, tylko dlatego, że zmiana wygląda na bardziej kosztowną i ryzykowną niż jest w rzeczywistości.

Koszty utrzymania, nie tylko koszt wdrożenia

Pisaliśmy szerzej o tym, że wdrożenie AI to trzy budżety, nie jeden — pilotaż, produkcję i utrzymanie. Umowa powinna jasno odpowiadać na pytanie, co dokładnie obejmuje cena: czy tylko etap budowy, czy też bieżące utrzymanie po starcie.

Warto sprawdzić wprost, kto ponosi koszt, gdy dostawca modelu językowego wypuszcza nową wersję i trzeba sprawdzić, czy system nadal działa poprawnie; kto płaci za poprawki, gdy dostawca danych (na przykład bank czy kontrahent) zmienia format dokumentów, które system ma czytać; i czy monitoring działania systemu w czasie jest w ogóle częścią umowy, czy osobną, dodatkową pozycją, o której dowiecie się dopiero po fakcie.

Kryteria odbioru

„AI działa dobrze” to nie jest kryterium odbioru — to opinia. Dobra umowa definiuje konkretne, mierzalne warunki, po spełnieniu których wdrożenie uznaje się za zakończone: na przykład określony poziom trafności klasyfikacji na realnych danych firmy, maksymalny czas odpowiedzi, albo procent przypadków, które system obsługuje bez eskalacji do człowieka.

Pisaliśmy o tym, jak wybrać moment na przejście z pilotażu do pełnego wdrożenia, w tekście pilotaż czy pełne wdrożenie AI — kryteria odbioru w umowie powinny wprost odwoływać się do wyników tego etapu, a nie do ogólnych zapewnień sprzedażowych sprzed testów na Waszych danych.

Odpowiedzialność za błędy AI

To pytanie, którego wiele firm nie zadaje na etapie podpisu, a które ma największe znaczenie, gdy coś faktycznie pójdzie nie tak: kto odpowiada, gdy model się pomyli w sposób, który kosztuje pieniądze albo powoduje szkodę?

Odpowiedź w dużej mierze zależy od tego, jak zaprojektowane jest samo wdrożenie. Jeśli AI wyłącznie proponuje, klasyfikuje albo przygotowuje materiał, a decyzję o realnym skutku finansowym podejmuje człowiek albo deterministyczny kod — zasadę tę opisaliśmy szerzej w tekście AI proponuje, kod liczy — odpowiedzialność jest dużo łatwiejsza do przypisania niż w modelu, w którym system sam „decyduje” o wszystkim bez żadnej warstwy kontrolnej. Umowa powinna jasno opisywać, gdzie w architekturze systemu przebiega ta granica, a nie zakładać, że pytanie o odpowiedzialność rozwiąże się samo, gdy problem faktycznie się pojawi.

Checklist w skrócie

Zanim podpiszecie umowę na wdrożenie AI, warto mieć jasną odpowiedź na każde z poniższych pytań:

  • Kto jest właścicielem promptów, konfiguracji i logiki zbudowanej dla Waszej firmy?
  • Czy Wasze dane mogą trafić do trenowania modelu dostawcy — i na jakich warunkach?
  • Co się dzieje z danymi i konfiguracją, jeśli zdecydujecie się zakończyć współpracę?
  • Czy cena obejmuje tylko wdrożenie, czy też bieżące utrzymanie po starcie?
  • Kto płaci za dostosowanie systemu do zmian formatu danych albo aktualizacji modelu?
  • Jakie są konkretne, mierzalne kryteria, po których wdrożenie uznaje się za zakończone?
  • Kto odpowiada, gdy AI się pomyli w sposób, który kosztuje pieniądze?

Najczęstsze pytania

Czy standardowa umowa wdrożeniowa wystarczy do projektu AI? Zwykle nie w pełni — potrzebne są dodatkowe zapisy dotyczące własności promptów i danych, warunków wyjścia oraz odpowiedzialności za błędy modelu, których nie ma w typowej umowie na wdrożenie systemu IT.

Czy dostawca może wykorzystać dane naszej firmy do trenowania swojego modelu? Nie powinien, bez wyraźnej, osobnej zgody zapisanej w umowie — warto to sprawdzić wprost, a nie zakładać domyślnie.

Jak zdefiniować kryteria odbioru, jeśli jeszcze nie wiemy, jak system się sprawdzi? Dobrym punktem wyjścia jest pilotaż na realnych danych firmy — kryteria odbioru dla pełnego wdrożenia powinny opierać się na wynikach tego etapu, a nie na założeniach sprzed testów.

Czy warto negocjować warunki wyjścia, skoro dopiero zaczynamy współpracę? Tak — to najlepszy moment na negocjacje, bo obie strony patrzą na sprawę racjonalnie. Po rozpoczęciu współpracy pozycja negocjacyjna zamawiającego zwykle słabnie.

Kto powinien odpowiadać za błędy AI w umowie? To zależy od architektury wdrożenia, ale zasadą powinno być jasne przypisanie odpowiedzialności do konkretnej warstwy — człowieka albo deterministycznego kodu — a nie pozostawienie tego pytania bez odpowiedzi do momentu, aż faktycznie wydarzy się błąd.

Jeśli przygotowujecie się do rozmowy o umowie na wdrożenie AI i chcecie skonsultować, na co zwrócić uwagę w Waszym konkretnym przypadku, napiszcie do nas — patrzymy na to również z perspektywy dostawcy, który sam musi odpowiadać na te pytania.