Przejdź do treści
Quantima.AI

BLOG

Dostawca wyłącza model, na którym stoi Wasz proces. Umowa milczy — i to jest normą

9 września 2026 · Paweł Marszałko · Quantima.AI

Podpisujecie trzyletnią umowę na narzędzie AI, które ma obsługiwać zapytania klientów. Pod spodem pracuje konkretny model językowy — i ten model ma opublikowaną datę końca wsparcia za czternaście miesięcy. Kiedy nadejdzie, Wasz proces trzeba będzie przestroić i przetestować od nowa, bo następca zachowuje się inaczej: inaczej formatuje odpowiedzi, inaczej reaguje na te same instrukcje, w innych miejscach się myli. To jest realna, wyceniana w dniach robota. Pytanie brzmi, kto ją wykona i kto za nią zapłaci — a w większości umów na rynku odpowiedzi na to pytanie po prostu nie ma. Nie dlatego, że ktoś działa w złej wierze; dlatego, że wzory umów pochodzą ze świata oprogramowania, w którym kupiony moduł działał tak samo w piątym roku jak w pierwszym. W AI to założenie jest fałszywe, a konsekwencje ponosi kupujący.

Dlaczego umowa na AI to nie jest umowa na oprogramowanie

Klasyczna licencja opisuje produkt, który się nie zmienia bez Waszej zgody. Aktualizacje przychodzą, ale zachowanie systemu jest przewidywalne, a jak coś przestaje działać, to jest to błąd do zgłoszenia. Narzędzie oparte na modelu językowym działa inaczej na trzech poziomach naraz i każdy z nich wymaga innego zapisu.

Po pierwsze, warstwa, która wykonuje pracę, jest wymienna i ma własny harmonogram wycofania, ustalany nie przez Waszego dostawcę, tylko przez producenta modelu. Po drugie, jakość wyniku jest statystyczna — nie ma stanu „działa”, jest tylko skuteczność w procentach, którą trzeba jakoś zmierzyć i zapisać. Po trzecie, do działania narzędzie potrzebuje Waszych danych, często wrażliwych, i one gdzieś fizycznie trafiają.

Umowa, która nie odnosi się do żadnej z tych trzech rzeczy, nie jest zła — jest po prostu z innej epoki. I taką dostaniecie domyślnie, bo dostawca też ją skądś skopiował. Poniżej siedem zapisów, których w niej najczęściej brakuje, w kolejności od tego, który najczęściej boli.

1. Zmiana i wycofanie modelu — kto płaci za przestrojenie

To jest zapis, którego brakuje najczęściej i który kosztuje najwięcej. Potrzebujecie trzech rzeczy: wyprzedzenia (ile dni przed zmianą modelu dostawca ma Was powiadomić), okresu równoległego (czy przez jakiś czas da się jeszcze pracować na starej wersji) i rozstrzygnięcia kosztu ponownego przetestowania procesu na nowym modelu.

Rozsądny punkt wyjścia w negocjacji: zmiana modelu inicjowana przez dostawcę oznacza, że to on odtwarza uzgodnioną skuteczność na własny koszt, a Wy tę skuteczność weryfikujecie zestawem testów uzgodnionym przy odbiorze. Zmiana inicjowana przez Was — bo chcecie nowszej, lepszej wersji — jest normalnym zleceniem. Ten podział jest uczciwy dla obu stron i zwykle nie budzi oporu, jeśli w ogóle postawicie temat.

Warunkiem, żeby ten zapis miał sens, jest istnienie zestawu testów, na którym mierzy się skuteczność. Bez niego „odtworzenie jakości” jest przedmiotem sporu, a nie ustaleniem. Jak taki zestaw zbudować i jaki próg przyjąć, rozłożyliśmy na czynniki pierwsze przy testowaniu wdrożenia AI — i to jest jedyny fragment tej listy, który trzeba przygotować przed rozmową z dostawcą, a nie w jej trakcie.

2. Czyje są dane wejściowe, wyniki i konfiguracja

Do rozstrzygnięcia są trzy różne rzeczy, które w ofertach lądują w jednym zdaniu. Dane, które wprowadzacie, powinny zostać Wasze — to zwykle bezsporne. Wyniki, które narzędzie generuje, powinny być do Waszego swobodnego użytku komercyjnego, bez ograniczeń co do sposobu wykorzystania. A konfiguracja — instrukcje systemowe, reguły, przygotowana baza wiedzy, mapowania na Wasze systemy — jest tą pozycją, o którą najczęściej nikt nie pyta, a która stanowi większość realnej wartości wdrożenia.

Zapis, który warto mieć wprost: przy zakończeniu współpracy otrzymujecie konfigurację w formacie nadającym się do odczytu i ponownego użycia, a nie zrzut ekranu z panelu. Jeśli dostawca odmawia, to jest to legalna decyzja biznesowa, ale musicie ją wycenić — oznacza, że koszt zmiany dostawcy to koszt zbudowania wdrożenia od zera.

Osobno: czy Wasze dane zasilają uczenie modeli. W ofertach dla firm domyślnie zwykle nie, ale bywa to ukryte w warunkach planu, który akurat kupujecie, i potrafi się różnić między planem podstawowym a wyższym. To jedno zdanie do wyciągnięcia z regulaminu na piśmie, a nie ze strony marketingowej.

3. Powierzenie przetwarzania i lista podwykonawców

Jeżeli przez narzędzie przechodzą dane osobowe — a przechodzą, gdy w treści jest nazwisko klienta, adres albo cokolwiek z korespondencji — potrzebna jest umowa powierzenia zgodna z art. 28 RODO. To nie jest formalność do odhaczenia: musi określać zakres i cel przetwarzania, kategorie danych, środki bezpieczeństwa, zasady dalszego powierzenia i to, co się z danymi dzieje po zakończeniu współpracy.

Punkt, który w AI jest nietypowy i wymaga uwagi, to łańcuch podwykonawców. Wasz dostawca zwykle korzysta z modelu innej firmy, ta hostuje go u jeszcze innej, a do tego dochodzą dostawcy wyszukiwania czy przechowywania danych. Chcecie mieć aktualną listę, informację o lokalizacji przetwarzania i prawo sprzeciwu wobec dodania nowego podwykonawcy — albo przynajmniej powiadomienie z wyprzedzeniem. Ciche rozszerzanie tej listy jest jednym z najczęstszych mechanizmów, przez który firma traci kontrolę nad tym, gdzie właściwie są jej dane.

Warto też ustalić maksymalny czas powiadomienia o incydencie. Wasze 72 godziny na zgłoszenie naruszenia zaczynają biec od momentu, w którym się o nim dowiedzieliście — a jeśli dostawca ma w umowie „niezwłocznie”, to w praktyce nie macie żadnego terminu. Dwadzieścia cztery godziny to rozsądny standard, którego zwykle nikt nie kwestionuje.

4. SLA, które faktycznie mierzy to, co Was interesuje

Standardowe SLA obiecuje dostępność usługi. Przy narzędziu AI to jest miara niepełna, bo system może być w pełni dostępny i jednocześnie odpowiadać źle. Dostępność 99,9% przy skuteczności, która spadła z 90% do 60%, formalnie nie łamie umowy, a biznesowo jest awarią.

Dlatego warto rozdzielić dwa parametry: dostępność techniczną i jakość działania mierzoną na uzgodnionym zestawie przypadków. Przy drugim wystarczy skromnie — próg, poniżej którego dostawca ma obowiązek zareagować, i tryb tej reakcji. Nie chodzi o kary umowne, tylko o to, żeby istniała definicja słowa „działa”, do której obie strony mogą się odwołać bez kłótni.

Drugi parametr, o którym się zapomina przy narzędziach działających samodzielnie: czas reakcji na zachowanie nieprawidłowe, ale nie awaryjne — narzędzie wysłało coś, czego nie powinno, albo zaczęło wykonywać operacje poza zakresem. To jest inna kategoria zgłoszenia niż „system nie odpowiada” i potrzebuje własnej ścieżki. Dlaczego to nie jest teoretyczne ryzyko, opisaliśmy przy prompt injection.

5. Odpowiedzialność za błąd modelu i za cudze prawa

Dwa różne ryzyka, oba zwykle wyłączone w standardowych warunkach. Pierwsze: narzędzie generuje odpowiedź nieprawdziwą, która trafia do klienta i powoduje szkodę. Realistyczne rozstrzygnięcie nie polega na przerzuceniu tego na dostawcę — nikt tego nie przyjmie i słusznie — tylko na uczciwym opisaniu, gdzie kończy się jego rola, a zaczyna Wasz nadzór. Jeśli umowa mówi, że wyniki wymagają weryfikacji człowieka, to Wy musicie tę weryfikację faktycznie mieć wbudowaną w proces, inaczej zapis obraca się przeciwko Wam przy pierwszym sporze.

Drugie: roszczenie osoby trzeciej dotyczące treści wygenerowanej przez narzędzie. Duzi dostawcy oferują tu ochronę, zwykle obwarowaną warunkami — trzeba korzystać z konkretnej wersji usługi i nie wyłączać wbudowanych filtrów. Warto sprawdzić, czy Wasz dostawca ma taką ochronę od swojego dostawcy i czy przekazuje ją dalej, bo między jednym a drugim często jest luka. Szerzej o tym, co realnie grozi przy treściach z AI, pisaliśmy przy treściach AI w marketingu.

Trzecia rzecz, formalna, ale coraz częściej istotna: podział ról z AI Act. Wy zwykle jesteście podmiotem stosującym, dostawca — dostawcą. Chcecie mieć w umowie zobowiązanie do przekazania dokumentacji i informacji potrzebnych do wypełnienia Waszych obowiązków, bo bez nich ich nie wypełnicie. Co z tych obowiązków dotyczy małej firmy, a co jest mitem, rozłożyliśmy przy AI Act w małej firmie.

6. Cena, która nie zmieni się w połowie roku

Rozliczenie za zużycie jest w AI standardem i samo w sobie jest w porządku. Problem pojawia się, gdy jednostka rozliczeniowa jest po stronie dostawcy — bo to on decyduje, ile „zużycia” generuje jedno zapytanie. Zmiana modelu na droższy, dołożenie kroku weryfikacji, wydłużenie kontekstu: każda z tych rzeczy podnosi rachunek bez zmiany cennika i bez Waszej decyzji.

Minimalne zabezpieczenie to trzy elementy: widoczność zużycia w czasie rzeczywistym, ustalony pułap miesięczny z alertem przed jego przekroczeniem oraz zapis, że przeniesienie do wyższego progu cenowego wymaga Waszej zgody, a nie samego powiadomienia. Bez pierwszego z nich pozostałe dwa są niewykonalne — więc jeśli dostawca nie pokazuje zużycia na bieżąco, to jest to sygnał sam w sobie.

Warto też przewidzieć koszt, który pojawia się dopiero w drugim roku i którego nikt nie wpisuje do budżetu: utrzymanie. Zmiany w Waszych procesach, nowe przypadki, korekty po każdej zmianie modelu. Anatomię budżetu wdrożenia razem z pozycjami, które zwykle wypadają z arkusza, opisaliśmy przy kosztach wdrożenia AI.

7. Wyjście — najważniejszy zapis, który brzmi najmniej pilnie

Przy podpisie nikt nie chce rozmawiać o rozstaniu, i to jest właśnie moment, w którym macie największą siłę negocjacyjną. Później nie będzie już żadnej. Potrzebujecie odpowiedzi na cztery pytania: w jakim formacie i w jakim terminie odzyskujecie dane, czy dostajecie konfigurację, jak długo dostawca współpracuje przy przejściu i kiedy oraz jak trwale usuwa Wasze dane po zakończeniu.

Konkret, który warto wpisać zamiast ogólników: dane w otwartym formacie w ciągu trzydziestu dni od wypowiedzenia, wsparcie migracyjne przez określoną liczbę godzin w cenie, potwierdzenie usunięcia na piśmie. To nie są wygórowane żądania i większość poważnych dostawców zgadza się na nie bez dyskusji — właśnie dlatego reakcja na tę propozycję jest najlepszym testem, jaki możecie zrobić przed podpisem.

Osobno warto ocenić zależność architektoniczną, której żaden zapis nie usunie. Jeśli cała logika procesu siedzi w panelu dostawcy, a Wy macie tylko interfejs, to zmiana dostawcy zawsze będzie budową od zera — niezależnie od tego, co mówi umowa. Kiedy warto trzymać część rozwiązania u siebie i jak to policzyć, opisaliśmy przy własnym modelu na firmowym serwerze, a przy integracjach — przy połączeniu AI z systemami firmy.

Co zrobić, jeżeli umowa jest już podpisana

Większość firm czyta taki tekst po fakcie, więc wersja dla tych, którzy mają już działające wdrożenie i standardowe warunki dostawcy. Nie trzeba niczego renegocjować, żeby wyraźnie poprawić swoją pozycję — wystarczy zrobić trzy rzeczy, wszystkie po własnej stronie.

  1. Spiszcie konfigurację poza panelem dostawcy: instrukcje systemowe, reguły, źródła wiedzy, listę integracji i uprawnień. Jeden dokument, aktualizowany przy każdej zmianie. To jest Wasza polisa na wypadek rozstania i zajmuje pół dnia.
  2. Zbudujcie zestaw kilkudziesięciu przypadków testowych z oczekiwanymi odpowiedziami i przepuszczajcie go raz w miesiącu. Dzięki temu spadek jakości po cichej zmianie modelu zauważycie w tygodniach, a nie w reklamacjach klientów.
  3. Wyeksportujcie dane historyczne — rozmowy, decyzje, wyniki — do własnego magazynu, jeśli dostawca na to pozwala. Nawet jeśli dziś ich nie używacie, to one są materiałem do przeniesienia procesu gdzie indziej.
  4. Zapytajcie dostawcy na piśmie o dwie rzeczy: jaki model jest obecnie używany i jaka jest polityka powiadamiania o jego zmianie. Odpowiedź na maila nie ma mocy aneksu, ale ma wartość dowodową i zwykle przychodzi w ciągu tygodnia.
  5. Sprawdźcie, czy macie umowę powierzenia i czy jej zakres odpowiada temu, co faktycznie wysyłacie do narzędzia. Rozjazd między jednym a drugim jest najczęstszym ustaleniem, jakie robimy przy przeglądach po kimś.

Jak używać tej listy w rozmowie z dostawcą

Nie chodzi o to, żeby wywalczyć wszystkie siedem punktów — przy mniejszym wdrożeniu to nierealne i niepotrzebne. Chodzi o to, żeby świadomie zdecydować, które ryzyka bierzecie na siebie. Umowa bez zapisu o zmianie modelu jest do zaakceptowania, jeśli wiecie, że za rok czeka Was przestrojenie na własny koszt, i macie to w budżecie. Ta sama umowa jest problemem, jeśli o tym nie wiecie.

Praktycznie: wyślijcie te siedem pytań przed rozmową handlową, nie po. Dostawca, który odpowie konkretnie na pięć z siedmiu i uczciwie powie, czego nie zrobi, jest lepszym wyborem niż taki, który na wszystkie odpowie „oczywiście, to standard”. Reakcja na tę listę mówi o dostawcy więcej niż demo — a demo i tak wygląda dobrze u każdego, bo po to jest przygotowane. Kilka innych pytań, które szybko kończą rozmowę z niepoważną ofertą, zebraliśmy przy agentach AI kontra automatyzacji.

U nas przegląd umowy i uprawnień jest częścią audytu przed wdrożeniem i mieści się w jednym warsztacie: przechodzimy przez siedem punktów na konkretnej ofercie, oznaczamy ryzyka, które zostają po Waszej stronie, i wyceniamy je. Jeśli chcecie przejść przez to na własnym przypadku, zakres konsultingu i wdrożeń AI opisaliśmy osobno, stawki są w cenniku, a na rozmowę wstępną — umów bezpłatną konsultację.

Chcesz sprawdzić, gdzie AI zwróci się w Twojej firmie?

Bezpłatna konsultacja 15–30 minut, wycena w 1 dzień roboczy.