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 trafiającymi do modelu, i kto odpowiada, gdy model pomyli się w sposób, który kosztuje pieniądze.

Dlaczego umowa na AI wymaga innego podejścia

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 rozmowie 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 Waszej firmy konkretne prompty 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.
  • Dane trafiające do modelu. Warto sprawdzić wprost, czy dane Waszej firmy mogą być wykorzystywane do trenowania albo dostrajania modelu dostawcy. W większości przypadków odpowiedź powinna brzmieć „nie, bez wyraźnej, osobnej zgody” — a umowa powinna to stwierdzać wprost.
  • 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.

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 — bez konieczności odtwarzania wszystkiego od zera u nowego dostawcy. Dobra umowa określa też okres przejściowy i zakres dokumentacji przekazania.

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 i kryteria odbioru

Pisaliśmy szerzej o tym, że wdrożenie AI to trzy budżety, nie jeden — pilotaż, produkcję i utrzymanie. Umowa powinna jasno odpowiadać, 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ę, kto płaci za poprawki, gdy zmienia się format dokumentów wejściowych, i czy monitoring działania systemu jest częścią umowy, czy osobną pozycją.

„AI działa dobrze” to nie jest kryterium odbioru — to opinia. Dobra umowa definiuje konkretne, mierzalne warunki: na przykład określony poziom trafności klasyfikacji na realnych danych firmy, maksymalny czas odpowiedzi albo procent przypadków obsłużonych 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 powinny odwoływać się do wyników tego etapu, nie do zapewnień sprzedażowych sprzed testów.

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 pomyli się 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 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 granica odpowiedzialności — nie zakładać, że to pytanie rozwiąże się samo.

W skrócie

Umowa na wdrożenie AI jest kompletna, kiedy odpowiada na pięć pytań: kto jest właścicielem konfiguracji, co się dzieje z danymi po zakończeniu współpracy, co obejmuje cena, jak wygląda odbiór i kto odpowiada za błąd. Jeśli przygotowujecie się do takiej rozmowy, więcej o naszym podejściu do wdrożeń znajdziecie na stronie oferty AI.

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.