Jak pisać umowy z dostawcami AI po AI Act? Wzorcowe klauzule

Wejście w życie AI Act oznacza, że umowy z dostawcami systemów AI muszą wprost odzwierciedlać nowe obowiązki regulacyjne, zwłaszcza dla systemów wysokiego ryzyka. W praktyce każda umowa B2B na rozwiązanie AI powinna dziś “przekopiować” do relacji kontraktowej wymogi dotyczące dokumentacji technicznej, logów i obsługi incydentów, jakie AI Act nakłada na dostawców (providers) i użytkowników (deployers).

AI Act wprowadza podział ról w łańcuchu wartości: dostawca (provider) odpowiada przede wszystkim za zgodność systemu, a wdrażający/użytkownik (deployer) za sposób użycia i nadzór nad systemem. Rozporządzenie przewiduje też sytuacje, w których wdrażający staje się “nowym dostawcą”, np. gdy znacząco modyfikuje system albo zmienia jego przeznaczenie, co ma bezpośredni wpływ na alokację obowiązków i ryzyka w umowie.

Dlaczego AI Act wymusza nowe podejście do umów

Dla systemów wysokiego ryzyka AI Act wymaga m.in. sporządzenia i utrzymywania dokumentacji technicznej (art. 11 i załącznik IV), prowadzenia logów (art. 12), zarządzania ryzykiem oraz raportowania poważnych incydentów (art. 73). Coraz częściej to właśnie umowa ma być dowodem, że strony jasno podzieliły między sobą obowiązki wynikające z AI Act i zapewniły sobie wzajemną współpracę, np. przy audytach czy zgłaszaniu incydentów.

Co musi zawierać umowa z dostawcą AI po AI Act

Poniższe elementy są kluczowe, jeżeli korzystasz z systemu, który może być kwalifikowany jako wysokiego ryzyka w rozumieniu AI Act.

• Klasyfikacja systemu i role stron. Umowa powinna jasno określić, czy dany system jest wysokiego ryzyka, jaka jest jego zamierzona funkcja oraz kto jest “providerem”, a kto “deployerem” w rozumieniu AI Act, z odniesieniem do art. 25 o odpowiedzialności w łańcuchu wartości.
• Deklaracja zgodności i status regulacyjny. Dla systemów wysokiego ryzyka dostawca powinien oświadczyć, że przeprowadził ocenę zgodności, sporządził deklarację zgodności UE oraz — jeśli wymagane — zarejestrował system w odpowiedniej bazie.
• Dostęp do dokumentacji technicznej z art. 11 i załącznika IV. AI Act wymaga, aby dokumentacja techniczna była sporządzona przed wprowadzeniem systemu na rynek i aktualizowana, obejmując elementy z załącznika IV. Umowa powinna przyznać nabywcy prawo dostępu do tej dokumentacji w zakresie niezbędnym do spełnienia własnych obowiązków (np. audyty, oceny wpływu na prawa podstawowe), z zastrzeżeniem ochrony tajemnicy przedsiębiorstwa.
• Logi i zasady dostępu do logów. Art. 12 AI Act wymaga, aby systemy wysokiego ryzyka technicznie umożliwiały automatyczne logowanie zdarzeń przez cały cykl życia systemu, w celu zapewnienia śledzenia działania, monitoringu po wprowadzeniu na rynek i identyfikacji sytuacji ryzykownych. Umowa powinna opisywać, jakie logi są generowane, przez kogo utrzymywane, jak długo przechowywane oraz w jakim zakresie nabywca ma do nich dostęp (np. do celów dochodzeń, audytów, raportowania incydentów).
• Procedury raportowania incydentów. AI Act nakłada na dostawców systemów wysokiego ryzyka obowiązek zgłaszania “poważnych incydentów” właściwym organom nadzoru w określonych terminach (co do zasady nie później niż 15 dni od uzyskania informacji). Umowa powinna zdefiniować, jak strony identyfikują incydent, jakie informacje przekazują sobie nawzajem, kto dokonuje zgłoszeń do regulatora i jaki jest harmonogram działań.
• Post-market monitoring i współpraca. Dostawca systemu wysokiego ryzyka musi prowadzić system monitorowania po wprowadzeniu na rynek, w tym zbierania informacji o działaniu systemu i aktualizacji dokumentacji. Kontrakt powinien zobowiązywać strony do współpracy w ramach tego procesu (np. raportowania problemów przez deployera, udziału w przeglądach okresowych, udostępniania danych do analiz).
• Zmiany systemu i “nowy provider”. AI Act przewiduje, że w pewnych sytuacjach wdrażający staje się nowym dostawcą (np. głęboka modyfikacja systemu, zmiana przeznaczenia na zastosowanie wysokiego ryzyka), co przenosi na niego obowiązki dostawcy. Umowa musi opisywać, jakie modyfikacje są dopuszczalne, kiedy nabywca przejmuje status “provider” oraz jak pierwotny dostawca będzie współpracował, przekazując informacje i wsparcie techniczne.
• Standardy i specyfikacje techniczne. Załącznik IV wymaga wskazania stosowanych norm zharmonizowanych i innych specyfikacji technicznych, na podstawie których wykazywana jest zgodność. W umowie warto zobowiązać dostawcę do utrzymywania zgodności z tymi normami oraz informowania o zmianach standardów, które mogą wpływać na system.

Załącznik IV AI Act – punkt po punkcie i wpływ na umowę

Załącznik IV szczegółowo opisuje, co musi zawierać dokumentacja techniczna systemu wysokiego ryzyka, a umowa powinna zapewnić realny dostęp do tych informacji (co najmniej w formie streszczeń biznesowo‑prawnych).

• Punkt 1 – opis ogólny systemu. Obejmuje m.in. przeznaczenie systemu, dane identyfikujące dostawcę, wersje, sposób dystrybucji (API, SaaS, oprogramowanie wbudowane) oraz podstawowy opis interfejsu użytkownika. W umowie warto wymagać, aby te informacje były utrzymywane w aneksie technicznym i aktualizowane przy każdej istotnej zmianie wersji.
• Punkt 2 – opis elementów i procesu rozwoju. Załącznik wymaga opisu metod rozwoju, wykorzystania systemów wstępnie wytrenowanych, logiki i architektury algorytmów, danych treningowych (proweniencja, główne cechy, metody czyszczenia), walidacji, testów, środków nadzoru ludzkiego i cyberbezpieczeństwa. Kontrakt powinien przewidywać, że dostawca udostępni odbiorcy co najmniej wysokopoziomowe informacje w tych obszarach, tak aby możliwa była ocena ryzyk i audyty, przy zachowaniu ochrony tajemnicy przedsiębiorstwa.
• Punkt 3 – monitoring, funkcjonowanie i kontrola. Dokumentacja ma zawierać informacje o możliwościach i ograniczeniach systemu (w tym poziomach dokładności dla określonych grup), przewidywalnych skutkach niezamierzonych oraz środkach nadzoru ludzkiego. Umowa powinna wymagać przekazania takich informacji w instrukcjach dla deployera i regulować, w jaki sposób będą one aktualizowane (np. w razie zmiany metryk dokładności).
• Punkt 4 – adekwatność metryk wydajności. Załącznik IV wymaga uzasadnienia, że przyjęte metryki (np. dokładność, robustność) są odpowiednie dla danego zastosowania. W kontrakcie można powiązać te metryki z parametrami usługowymi (SLA) lub przynajmniej z obowiązkiem informowania o ich spadku poniżej ustalonych progów.
• Punkt 5 – system zarządzania ryzykiem. Dokumentacja musi opisywać proces zarządzania ryzykiem zgodnie z art. 9 AI Act, w tym identyfikację, analizę i mitygację zagrożeń dla zdrowia, bezpieczeństwa i praw podstawowych. W umowie warto wymagać dostępu do wyników tych analiz w zakresie dotyczącym konkretnego wdrożenia oraz zobowiązać dostawcę do aktualizacji analiz przy istotnych zmianach systemu lub kontekstu użycia.
• Punkt 6 – zmiany w cyklu życia. Załącznik nakazuje opisywanie zmian w systemie w czasie (np. aktualizacje modeli, nowe funkcje) oraz ich wpływu na zgodność. Umowa powinna definiować, kiedy zmiana jest “istotna”, jakie konsultacje są wymagane i kiedy klient może wstrzymać użycie systemu do czasu ponownej oceny zgodności.
• Punkt 7 – normy i specyfikacje. W dokumentacji trzeba wskazać listę norm zharmonizowanych i innych specyfikacji technicznych, które zastosowano, lub opisać alternatywne rozwiązania zapewniające spełnienie wymogów AI Act. Klauzula umowna może zobowiązywać dostawcę do informowania klienta, gdy przestaje stosować określone normy lub gdy pojawiają się nowe normy istotne dla systemu.
• Punkt 8 – deklaracja zgodności UE. Dokumentacja musi zawierać kopię deklaracji zgodności, którą dostawca wystawia dla systemu. Umowa powinna przewidywać udostępnienie klientowi aktualnej deklaracji oraz powiadamianie o każdej jej zmianie lub cofnięciu.
• Punkt 9 – plan monitorowania po wprowadzeniu na rynek. Załącznik wymaga opisu systemu monitorowania działania systemu po jego wdrożeniu (post-market monitoring), zgodnie z art. 72. Kontrakt musi określać, jakie dane eksploatacyjne będzie przekazywał deployer, jak często będą prowadzone przeglądy oraz jakie działania korygujące strony podejmą w razie stwierdzenia istotnych problemów.

Logi i incydenty – jak przełożyć AI Act na klauzule umowne

Art. 12 AI Act wymaga, aby systemy wysokiego ryzyka automatycznie rejestrowały zdarzenia istotne dla śledzenia działania systemu, monitorowania po wdrożeniu i identyfikowania sytuacji mogących prowadzić do poważnego ryzyka. Dla niektórych kategorii (np. zdalna identyfikacja biometryczna) prawodawca wskazuje minimalny zakres logów: czas użycia, baza referencyjna, dane wejściowe, osoby weryfikujące wyniki.

Art. 73 nakłada z kolei na dostawców systemów wysokiego ryzyka obowiązek zgłaszania poważnych incydentów właściwym organom nadzoru niezwłocznie po ustaleniu związku przyczynowego z systemem, a najpóźniej w ciągu 15 dni od uzyskania informacji. Wytyczne do art. 73 podkreślają, że chodzi o system wczesnego ostrzegania i budowanie odpowiedzialności dostawców, przy czym w razie braku kontaktu z dostawcą część obowiązków może przejąć deployer.

Umowa powinna więc obejmować co najmniej: wspólne definicje incydentów i kryteria “poważności”, obowiązek natychmiastowego zgłaszania problemów między stronami, podział ról w raportowaniu do organów oraz zasady wykorzystania logów przy analizie przyczyn zdarzenia.

AI Act a umowa – podsumowanie w tabeli

Przykładowe klauzule umowne (wyłącznie edukacyjne)

Uwaga: poniższy fragment ma charakter wyłącznie edukacyjny i nie stanowi porady prawnej. Przed wykorzystaniem podobnych zapisów w realnych umowach konieczna jest analiza konkretnego przypadku z udziałem profesjonalnego doradcy.

1. Dokumentacja techniczna i zgodność z AI Act
Dostawca oświadcza, że dla Systemu AI sporządził i utrzymuje dokumentację techniczną wymaganą art. 11 oraz załącznikiem IV rozporządzenia (UE) 2024/1689 (AI Act), obejmującą w szczególności opis ogólny systemu, elementy i proces rozwoju, system zarządzania ryzykiem, stosowane normy oraz plan monitorowania po wprowadzeniu na rynek.
Dostawca zapewni Klientowi dostęp do aktualnej dokumentacji technicznej w zakresie niezbędnym do wykonania przez Klienta obowiązków nałożonych na deployera w AI Act, w uzgodnionej formie (np. portal online), z zastrzeżeniem ochrony tajemnicy przedsiębiorstwa i informacji poufnych Dostawcy.

2. Logi i dostęp do logów
Dostawca zapewni, aby System AI umożliwiał automatyczne rejestrowanie zdarzeń (logów) w sposób spełniający wymogi art. 12 AI Act, w zakresie odpowiednim do przeznaczenia systemu.
Strony uzgadniają, że logi obejmują co najmniej informacje o czasie użycia systemu, rodzaju wykonanych operacji oraz identyfikatorach sesji, a także inne dane określone w specyfikacji technicznej stanowiącej załącznik do Umowy.
Dostawca przechowuje logi przez okres co najmniej … lat, a Klient ma prawo dostępu do logów dotyczących jego użycia systemu w zakresie niezbędnym do wyjaśniania incydentów, audytów zgodności oraz realizacji obowiązków regulacyjnych, z uwzględnieniem ograniczeń wynikających z przepisów o ochronie danych osobowych.

3. Incydenty i raportowanie
Każda ze Stron niezwłocznie informuje drugą Stronę o wszelkich zdarzeniach mogących stanowić “poważny incydent” w rozumieniu AI Act, związanych z działaniem Systemu AI.
Dostawca bierze na siebie obowiązek raportowania poważnych incydentów właściwym organom nadzoru na zasadach określonych w art. 73 AI Act, przy czym Klient zobowiązany jest dostarczyć niezbędne informacje oraz współdziałać przy wyjaśnianiu przyczyn zdarzenia.
Strony ustalą szczegółową procedurę komunikacji i eskalacji incydentów w aneksie do Umowy (plan reagowania na incydenty AI), w tym terminy przekazywania informacji oraz osoby kontaktowe.

Praktyczne zastosowania – jak zorganizować współpracę prawników i IT

Aby umowy z dostawcami AI realnie wspierały zgodność z AI Act, konieczna jest ścisła współpraca działów prawnych, compliance i zespołów technicznych. Zespół prawny musi rozumieć strukturę dokumentacji z załącznika IV i wymogi dot. logów oraz incydentów, a IT – pomóc przełożyć je na konkretne parametry systemu i wymagania wobec dostawcy.

• Checklista przed negocjacjami umowy. Warto korzystać z list kontrolnych due diligence, które obejmują m.in. potwierdzenie sporządzenia dokumentacji z załącznika IV, status ocen zgodności oraz gotowość dostawcy do udostępniania logów i udziału w post-market monitoring.
• Biblioteka klauzul AI. Coraz więcej organizacji buduje własne biblioteki klauzul dotyczących AI Act, obejmujące dokumentację, logi, incydenty, role w łańcuchu wartości i odpowiedzialność. Pozwala to szybciej negocjować kolejne umowy i zachować spójność zapisów.
• Mapowanie ról “provider/deployer”. Przed podpisaniem kontraktu warto przeanalizować, czy w danym scenariuszu klient nie staje się de facto nowym dostawcą (np. przez głęboką personalizację lub łączenie modeli). W takim wypadku trzeba rozszerzyć zakres klauzul o obowiązki dostawcy, w tym własną dokumentację i procedury raportowania incydentów.
• Stałe przeglądy umów. Ponieważ Komisja może aktualizować wymagania dotyczące dokumentacji (art. 11 ust. 3), a praktyka organów nadzoru i wytyczne będą się zmieniać, umowy powinny przewidywać okresowe przeglądy i możliwość aktualizacji klauzul AI Act.

Źródła

• Annex IV – Technical documentation referred to in Article 11(1) (AI Act Service Desk)
• Article 11: Technical Documentation | EU Artificial Intelligence Act
• Article 12: Record-Keeping | EU Artificial Intelligence Act
• Article 73: Reporting of serious incidents | AI Act Service Desk
• Article 25: Responsibilities along the AI value chain | AI Act Service Desk
• EU AI Act Contract Terms for Buyers and Vendors | ClearContract
• AI Clauses in Vendor Contracts | Pitch.law
• EU AI Act Technical Documentation Guide | code4thought
• AI Vendor Due Diligence Under EU Regulations | SoftwareSeni
• Article 12: Record-keeping – Commentary | en.ai-act.io