Umowa wdrożenia systemu AI: 12 klauzul, które trzeba ustalić przed podpisaniem

1. Rola stron w świetle AI Act

Pierwszym zadaniem jest ustalenie, czy strony występują jako dostawca, podmiot stosujący, importer, dystrybutor lub inny uczestnik łańcucha wartości. To nie jest terminologia marketingowa, lecz kwalifikacja mogąca decydować o obowiązkach regulacyjnych. Szczególnej uwagi wymaga art. 25 AI Act: określone działania strony trzeciej, w tym rebranding, istotna modyfikacja lub zmiana przeznaczenia systemu, mogą spowodować przejęcie obowiązków dostawcy systemu wysokiego ryzyka. Umowa powinna określać dopuszczalny zakres modyfikacji i obowiązek informowania o zmianach mogących wpływać na kwalifikację.

2. Opis systemu i dozwolone zastosowanie

Przedmiot umowy powinien precyzyjnie określać funkcje systemu, środowisko wdrożenia, kategorie użytkowników i dozwolone cele. Ogólna formuła „narzędzie AI do wsparcia biznesu” utrudnia później ustalenie, czy rozwiązanie zostało użyte zgodnie z instrukcją i założeniami bezpieczeństwa. Warto opisać zastosowania zakazane przez organizację, sytuacje wymagające decyzji człowieka oraz proces zatwierdzania nowych use case’ów. To szczególnie ważne, gdy jedno narzędzie może być wykorzystywane zarówno do prostych funkcji pomocniczych, jak i decyzji wpływających na pracowników, klientów lub dostęp do usług.

3. Dane wejściowe i tajemnice

Umowa powinna odpowiadać na pytanie, co dostawca może robić z promptami, dokumentami i innymi danymi wprowadzanymi przez klienta. Trzeba ustalić, czy dane są używane do trenowania lub poprawy modeli, jak długo są przechowywane, gdzie są przetwarzane oraz kto ma do nich dostęp. Organizacja powinna odrębnie uregulować dane osobowe, tajemnicę przedsiębiorstwa, informacje objęte tajemnicą zawodową i dane klientów. Samo zapewnienie o „enterprise privacy” nie zastępuje konkretnego zobowiązania umownego.

4. Prawa do outputu i ryzyko naruszeń IP

Należy ustalić prawa do rezultatów generowanych przez system oraz odpowiedzialność za roszczenia osób trzecich. W praktyce nie każdy output będzie utworem chronionym prawem autorskim, a zakres ochrony może zależeć od wkładu twórczego człowieka. Umowa powinna jednak rozstrzygać, w jakim zakresie dostawca przenosi lub pozostawia klientowi swoje prawa do elementów rezultatu, jakie są ograniczenia licencyjne i czy zapewnia mechanizmy ochrony w razie zarzutu naruszenia cudzych praw. W zastosowaniach marketingowych lub programistycznych warto również określić procedurę weryfikacji outputu przed publikacją.

5. Jakość, halucynacje i poziom usługi

Modele generatywne mogą tworzyć błędne odpowiedzi. Zamiast deklarować „bezbłędność AI”, należy umownie ustalić mierzalne parametry usługi, zasady monitorowania jakości oraz obszary, w których wynik zawsze wymaga kontroli człowieka. Jeżeli system wykonuje klasyfikację, scoring lub analizę, warto określić metryki walidacyjne i sposób raportowania zmian. SLA powinno obejmować nie tylko dostępność techniczną, ale również komunikację o istotnych degradacjach modelu, zmianach funkcji i incydentach bezpieczeństwa.

6. Aktualizacje modelu i istotna modyfikacja

Dostawca usług AI może aktualizować model bez tradycyjnej instalacji nowej wersji po stronie klienta. Taka zmiana może wpływać na jakość, ryzyko, funkcje i zgodność. Umowa powinna określać, jakie zmiany mogą być dokonywane jednostronnie, z jakim wyprzedzeniem klient zostanie poinformowany i kiedy ma prawo przetestować wersję przed wdrożeniem. Szczególnie ważna jest kontrola zmian mogących prowadzić do istotnej modyfikacji systemu wysokiego ryzyka lub zmiany jego przeznaczenia.

7. Audyt i dokumentacja zgodności

Klient potrzebuje dostępu do informacji pozwalających wykazać własną zgodność. Zakres może obejmować dokumentację bezpieczeństwa, instrukcje użycia, informacje o modelu, raporty z testów, podwykonawców i wyniki audytów. Prawo audytu trzeba projektować realistycznie: dostawca dużej platformy może nie zgodzić się na fizyczną inspekcję infrastruktury, ale może udostępnić certyfikaty, raporty niezależnych audytorów i określone informacje na żądanie. Najważniejsze jest zapewnienie danych niezbędnych do wykonania konkretnych obowiązków klienta.

8–12. Incydenty, odpowiedzialność, wyjście i współpraca

Pozostałe kluczowe obszary to obowiązek szybkiego informowania o incydentach i wadach, reguły odpowiedzialności oraz limity odszkodowawcze, cyberbezpieczeństwo, warunki zakończenia współpracy i migracji danych oraz pomoc przy kontroli regulatora. Szczególnie niebezpieczne są klauzule, w których dostawca wyłącza odpowiedzialność niemal całkowicie, a jednocześnie nie daje klientowi informacji potrzebnych do zarządzania ryzykiem. Umowa powinna rozdzielać odpowiedzialność zgodnie z faktyczną kontrolą stron: klient nie powinien odpowiadać za elementy modelu, których nie może zobaczyć ani zmienić, a dostawca nie powinien odpowiadać za użycie systemu wbrew instrukcji i ustalonym ograniczeniom.

Klauzula „change in law” i zmiany regulacyjne AI

Rynek AI rozwija się szybciej niż typowy cykl życia umowy technologicznej. Kontrakt podpisany na trzy lata może działać w kilku różnych fazach stosowania AI Act i podlegać nowym standardom, wytycznym lub wymaganiom sektorowym. Dlatego warto przewidzieć mechanizm dostosowania do zmian prawa. Powinien on określać, która strona monitoruje regulacje, kto ponosi koszt koniecznych zmian, kiedy modyfikacja wymaga aneksu oraz co dzieje się, gdy dostosowanie jest technicznie niemożliwe lub ekonomicznie nieuzasadnione. Klauzula nie powinna dawać dostawcy blankietowego prawa do jednostronnego pogorszenia funkcji. Klient potrzebuje również prawa do informacji o zmianach modelu, które mogą wpływać na klasyfikację ryzyka, bezpieczeństwo, lokalizację danych lub użycie podwykonawców. Szczególnie przy systemach zintegrowanych z procesami HR, finansami lub obsługą klienta brak mechanizmu zarządzania zmianą może prowadzić do sytuacji, w której zgodność organizacji zależy od decyzji dostawcy podejmowanych bez jej wiedzy.

Exit plan i przenoszalność jako warunek bezpieczeństwa

W umowach AI łatwo skoncentrować się na wdrożeniu i pominąć zakończenie współpracy. Tymczasem klient powinien z góry wiedzieć, w jakim formacie odzyska dane, konfiguracje, prompty systemowe, historię decyzji i inne elementy potrzebne do migracji. Warto ustalić czas wsparcia po rozwiązaniu umowy, obowiązek usunięcia kopii danych i sposób potwierdzenia usunięcia. Jeżeli rozwiązanie było trenowane lub dostrajane na danych klienta, trzeba rozstrzygnąć, co stanie się z powstałymi parametrami, artefaktami i dokumentacją. Exit plan jest również narzędziem kontroli ryzyka dostawcy: pozwala zareagować na istotny incydent, pogorszenie jakości, zmianę właściciela dostawcy lub brak dostosowania do prawa. Bez takich postanowień organizacja może znaleźć się w technologicznym lock-inie, mimo że dalsze korzystanie z systemu staje się prawnie lub biznesowo nieakceptowalne.

Materiał ma charakter informacyjny i nie zastępuje analizy konkretnego wdrożenia, incydentu albo sprawy.