Co musi znaleźć się w umowie z dostawcą AI?

Zastrzeżenie

Piszę to z perspektywy człowieka, który siedzi po stronie technicznej i widzi, co się psuje po podpisaniu. Konstrukcja zapisów, odpowiedzialność odszkodowawcza i kary umowne to praca dla prawnika. Poniżej jest lista rzeczy, o które warto go poprosić, żeby nie zapomniał, że kupujecie coś innego niż zwykły program.

Czym ta umowa różni się od zwykłej

Standardowy wzór na wdrożenie oprogramowania zakłada, że przedmiot umowy jest stały, że wykonawca ma go dostarczyć i że po odbiorze koszty się kończą. Przy wdrożeniu opartym na modelu językowym żadne z tych trzech założeń nie jest prawdziwe.

Dane wychodzą poza firmę. Zapytanie do modelu to przesłanie treści na cudzą infrastrukturę, często poza Europejski Obszar Gospodarczy.

Przedmiot się zmienia bez udziału stron. Dostawca modelu wycofuje wersje i podmienia je na nowsze. Ta sama instrukcja daje wtedy inny wynik, a nikt was nie pytał o zgodę.

Rachunek rośnie z użyciem. Płacicie za liczbę przetworzonych jednostek tekstu, więc udany wdrożony proces jest droższy od nieudanego.

Każda z tych trzech różnic wymaga w umowie osobnego zapisu i żadnej nie ma w typowym wzorze. Czwarta warstwa, role wynikające z AI Act, nie bierze się z natury technologii, tylko z przepisu, i o niej też trzeba rozstrzygnąć przed podpisem.

Warstwa danych

Zacznijcie od ustalenia, kto jest kim. Jeżeli przez system przechodzą dane osobowe, wasza firma jest administratorem, a wykonawca wdrożenia procesorem. Dostawca modelu bywa dalszym procesorem i to jego warunki decydują o tym, co dzieje się z treścią zapytań.

Art. 28 RODO określa, co taka umowa musi zawierać: przedmiot i czas trwania przetwarzania, jego charakter i cel, rodzaj danych osobowych, kategorie osób, których dane dotyczą, oraz obowiązki i prawa administratora. To minimum ustawowe, nie lista życzeń.

Do tego cztery rzeczy, które w praktyce rozstrzygają najwięcej:

• wyłączone trenowanie na treści zapytań — w ofertach konsumenckich bywa włączone domyślnie,
• lista dalszych procesorów i tryb jej zmiany — dostawca modelu nie jest jedynym podmiotem w łańcuchu,
• region przetwarzania — część dostawców oferuje przetwarzanie w Europie i wtedy transfer jest prostszy do uregulowania,
• okres przechowywania treści zapytań — logi bywają trzymane miesiącami po stronie dostawcy.

Szerzej o tej warstwie, razem z konsekwencjami wrzucenia danych klienta do publicznej wersji narzędzia, piszę w tekście o RODO przy korzystaniu z modeli.

Warstwa ról z AI Act

Ten fragment umyka najczęściej, a potrafi przenieść na firmę obowiązki producenta.

Art. 25 ust. 1 AI Act mówi, że za dostawcę systemu AI wysokiego ryzyka uznaje się dystrybutora, importera, podmiot stosujący albo inną stronę trzecią i obejmuje go obowiązkami z art. 16, jeżeli zachodzi jedna z trzech okoliczności: umieszczenie własnej nazwy lub znaku towarowego na systemie wysokiego ryzyka już wprowadzonym do obrotu, dokonanie w takim systemie istotnej zmiany, po której pozostaje on systemem wysokiego ryzyka, albo zmiana przeznaczenia systemu — również ogólnego przeznaczenia — w taki sposób, że dopiero staje się systemem wysokiego ryzyka.

Kwalifikator „wysokiego ryzyka” jest w pierwszych dwóch okolicznościach przesłanką, nie skutkiem. Umieszczenie własnej marki na zwykłym asystencie tekstowym albo na chatbocie obsługi klienta nie uruchamia więc art. 25 ust. 1 lit. a) ani b). Trzecia okoliczność jest inna i dotyczy właśnie systemów zwykłych: opisuje zmianę przeznaczenia, przez którą system dopiero staje się systemem wysokiego ryzyka.

Pierwsza z tych okoliczności ma w przepisie zastrzeżenie, które w omówieniach ginie, a jest tu najważniejsze: umieszczenie własnej nazwy przenosi obowiązki dostawcy „bez uszczerbku dla ustaleń umownych przewidujących, że podział obowiązków następuje w inny sposób”. Strony mogą więc ten skutek rozłożyć umową i właśnie dlatego warto o nim wiedzieć przed podpisem. Przy istotnej zmianie i przy zmianie przeznaczenia takiego zastrzeżenia w przepisie nie ma.

Trzecia okoliczność dotyczy również systemów ogólnego przeznaczenia. Firma, która bierze zwykłego asystenta tekstowego i kieruje go do wstępnej selekcji kandydatów do pracy, sama zmienia przeznaczenie w stronę zastosowania z załącznika III. Kupujący staje się wtedy dostawcą ze wszystkimi tego konsekwencjami.

Umowa powinna więc rozstrzygać dwie rzeczy. Po pierwsze, kto jest kim przy tym konkretnym wdrożeniu i przy jakich zmianach ta kwalifikacja się przesuwa. Po drugie, czy dostawca ma obowiązek współpracy, gdy przesunięcie nastąpi.

Ta druga rzecz zyska niedługo nowy ciężar. Digital Omnibus rozpisał art. 25 ust. 2 na konkretne obowiązki pierwotnego dostawcy: udostępnienie dokumentacji technicznej wystarczającej do oceny zgodności z art. 16, poinformowanie o znanych ograniczeniach i trybach awaryjnych oraz zapewnienie ukierunkowanego dostępu technicznego, w tym do testowania i walidacji. Ta sama nowelizacja dopisała obowiązki z art. 25 ust. 2 i 4 do katalogu kar w art. 99 ust. 4, czyli do pułapu 15 mln euro albo 3% światowego obrotu.

Jest przy tym data, bez której łatwo wyciągnąć przedwczesny wniosek. Art. 25 i 26 leżą w rozdziale III sekcja 3, a Digital Omnibus przesunął stosowanie sekcji 1⁠–⁠3 tego rozdziału na 2 grudnia 2027 dla systemów z załącznika III i na 2 sierpnia 2028 dla systemów wbudowanych w produkty objęte prawem produktowym. Dziś te przepisy jeszcze nie działają. Umowa podpisywana teraz najprawdopodobniej dożyje tamtych terminów, więc zapis lepiej mieć od razu, niż dopisywać go aneksem pod presją. Pełny rozkład terminów opisuję przy nowych datach po Digital Omnibus.

Jest przy tym zapis, którego warto szukać w cudzym wzorze, bo działa przeciwko kupującemu: obowiązek współpracy nie ma zastosowania, gdy pierwotny dostawca wyraźnie określił, że jego system nie może zostać zmieniony w system wysokiego ryzyka. Takie zastrzeżenie w dokumentacji dostawcy oznacza, że przy zmianie przeznaczenia zostajecie z tym sami.

Warstwa ciągłości

Modele mają cykl życia krótszy niż umowy. Wersja, na której zbudowano wdrożenie, zostanie kiedyś wycofana, a jej następczyni zachowa się inaczej przy tych samych instrukcjach.

Zapisy, które to porządkują:

• minimalny okres dostępności konkretnej wersji modelu i termin powiadomienia o wycofaniu,
• kto ponosi koszt ponownego dostrojenia i testów po podmianie wersji,
• zestaw testów akceptacyjnych, na których mierzy się, czy nowa wersja nadal spełnia wymagania,
• procedura wycofania się do poprzedniego rozwiązania, gdy nie spełnia.

Czwarty punkt bywa traktowany jako formalność, dopóki nie okaże się, że nie ma do czego wrócić.

Warstwa rachunku

Koszt zmienny wymaga innych zapisów niż koszt stały. Sam mechanizm rozliczania opisuję w tekście o kosztach utrzymania AI; tutaj chodzi o to, co z tego wynika dla umowy.

Trzy rzeczy do ustalenia przed podpisem: limit miesięcznych kosztów z alarmem przed jego przekroczeniem, kto płaci za zużycie wywołane błędem w kodzie albo pętlą w agencie, oraz co się dzieje, gdy dostawca modelu podniesie ceny w trakcie trwania umowy. Trzecia sytuacja jest najbardziej realna i najrzadziej opisana.

Wyjście

Najlepszy moment na uregulowanie rozstania to ten, w którym nikt o nim nie myśli. Praktyczna lista jest krótka: w jakim formacie i w jakim terminie dostajecie eksport danych, czy dostajecie wagi dostrojonego modelu, czy zbiór poleceń i konfiguracji jest waszą własnością, i kiedy dostawca usuwa kopie po zakończeniu współpracy.

Bez tych czterech zapisów zmiana wykonawcy oznacza budowanie wdrożenia od zera, a to jest dokładnie ta zależność, którą wykonawca ma interes utrzymać. O tym, jak rozpoznać wykonawcę, który tej zależności nie buduje, piszę osobno przy wyborze konsultanta.