Streszczenie AI
The EU AI Act makes any IT contract or SLA that covers an AI system a legal instrument that must embed the regulation’s technical demands—such as risk‑management, data‑quality, documentation and mandatory logging—into the contract language.
It creates two distinct responsibilities: the provider must supply a compliant system, documentation, real‑time event records and swift incident reporting, while the deployer must follow the provider’s instructions, maintain human oversight, monitor the system’s performance, and perform data‑protection impact assessments.
Consequently, an AI‐based agreement must spell out the intended use, provide CE‑marked technical dossiers, grant audit‑ready logs, specify escalation timelines for serious incidents, and lock in human‑in‑the‑loop controls and role‑transfer boundaries to satisfy both legal and operational compliance.
Spis treści:
- Dlaczego AI Act wymusza nowe podejście do umów
- Kluczowe elementy techniczno-prawne umowy z dostawcą AI
- Załącznik IV AI Act – dekompozycja techniczna a zapisy umowne
- Telemetria, logi (art. 12) i rygory raportowania incydentów (art. 73)
- Zestawienie wymogów regulacyjnych i klauzul kontraktowych
- Wzorcowe klauzule umowne do adaptacji (Model AI Clauses)
- Praktyczne wdrożenie – integracja zespołów Legal, IT i Compliance
- Źródła
Pełne wejście w fazę stosowania rozporządzenia (UE) 2024/1689 (AI Act) sprawia, że kontrakty IT i umowy SLA na rozwiązania bazujące na sztucznej inteligencji muszą bezwzględnie operacjonalizować wymogi prawne. W relacjach B2B kluczowe jest precyzyjne rozgraniczenie ról regulacyjnych oraz przeniesienie technicznych rygorów w zakresie dokumentacji (art. 11, załącznik IV), logowania zdarzeń (art. 12), zarządzania incydentami (art. 73) i nadzoru (art. 26) na grunt prawny.
AI Act definiuje wielopoziomowy łańcuch wartości, nakładając odmienne obowiązki na dostawcę (provider) oraz podmiot wdrażający (deployer). Umowa nie może być traktowana jedynie jako porozumienie handlowe – stanowi ona formalny dowód podziału odpowiedzialności i procedur compliance w razie kontroli organów nadzoru rynku lub audytów powdrożeniowych.
Dlaczego AI Act wymusza nowe podejście do umów
Wdrożenie systemów wysokiego ryzyka (np. w procesach rekrutacyjnych, oceny scoringowej czy infrastruktury krytycznej) wiąże się z rygorystycznymi obowiązkami technicznymi. Zgodnie z AI Act dostawca musi wdrożyć system zarządzania ryzykiem (art. 9), zarządzać jakością danych (art. 10), przygotować i aktualizować dokumentację techniczną (art. 11 i załącznik IV) oraz wdrożyć mechanizmy automatycznej rejestracji zdarzeń (art. 12) i procedury raportowania poważnych incydentów (art. 73).
Z kolei podmiot wdrażający (deployer) na podstawie art. 26 ma obowiązek stosować system ściśle według dostarczonej instrukcji, zapewnić realny nadzór ludzki (art. 14), monitorować jego poprawne działanie, a w określonych sytuacjach przeprowadzić ocenę wpływu na prawa podstawowe (FRIA – art. 27). Jeżeli kontrakt nie zapewni nabywcy dostępu do metryk, logów i danych o ograniczeniach algorytmu, deployer nie jest w stanie legalnie i bezpiecznie użytkować zakupionego narzędzia.
Kluczowe elementy techniczno-prawne umowy z dostawcą AI
Strukturyzując kontrakt na dostawę lub subskrypcję systemu AI, należy uwzględnić następujące obszary zgodności:
- Kwalifikacja techniczna i zamierzone przeznaczenie (Intended Purpose): Umowa musi precyzyjnie definiować zakres zastosowania systemu, ograniczenia operacyjne oraz formalny status stron (provider / deployer) w świetle art. 25 AI Act.
- Certyfikacja i deklaracja zgodności UE: Oświadczenie dostawcy o przeprowadzeniu oceny zgodności, wystawieniu deklaracji zgodności UE (art. 47) oraz naniesieniu oznakowania CE przed udostępnieniem oprogramowania na rynku.
- Dostęp do dokumentacji technicznej i instrukcji obsługi: Zapewnienie odbiorcy wyczerpującej instrukcji (art. 13) oraz niezbędnych wyciągów z dokumentacji technicznej z załącznika IV (m.in. poziomów dokładności, podatności na błędy, wymagań dotyczących danych wejściowych).
- Architektura logowania zdarzeń i retencja (art. 12): Zdefiniowanie protokołów rejestracji zdarzeń, formatu danych, minimalnego czasu przechowywania logów (co do zasady minimum 6 miesięcy, o ile przepisy sektorowe nie wymagają dłuższego okresu) oraz mechanizmów eksportu na potrzeby audytów.
- Wielopoziomowe procedury obsługi incydentów (art. 73): Ustalenie rygorystycznych okien czasowych na wzajemne powiadamianie o anomaliach i incydentach, w tym natychmiastowej ścieżki eskalacji dla zdarzeń krytycznych.
- Mechanizmy nadzoru ludzkiego (Human-in-the-loop / Human-on-the-loop): Zobowiązanie dostawcy do dostarczenia interfejsów i narzędzi umożliwiających operatorowi po stronie deployera zatrzymanie systemu (tzw. „stop button”), zignorowanie rekomendacji modelu lub nadpisanie decyzji algorytmicznej.
- Klauzula modyfikacji i przejścia ról (art. 25): Określenie granic dozwolonej parametryzacji i fine-tuningu, aby zapobiec nieświadomemu przejęciu roli dostawcy (nowego providera) przez podmiot wdrażający w wyniku istotnej modyfikacji (substantial modification).
- Post-market monitoring i aktualizacje modeli: Uregulowanie procedury przekazywania informacji zwrotnych o funkcjonowaniu systemu w środowisku produkcyjnym oraz zasad informowania o aktualizacjach wag, architektur i danych treningowych.
Załącznik IV AI Act – dekompozycja techniczna a zapisy umowne
Załącznik IV definiuje minimalną zawartość dokumentacji technicznej. Poniższe zestawienie wskazuje, jak poszczególne elementy techniczne powinny przekładać się na postanowienia umowne:
- Punkt 1 – Ogólny opis systemu: Wskazanie architektury (on-premise, cloud SaaS, API), specyfikacji sprzętowej oraz zamierzonego celu działania. W umowie należy ustalić, że każda zmiana interfejsu API lub parametrów wejścia/wyjścia wymaga wcześniejszego powiadomienia technicznego.
- Punkt 2 – Metodyka rozwoju i dane: Wykorzystane modele bazowe (foundation models), architektura sieci, pochodzenie zbiorów danych treningowych, walidacyjnych i testowych oraz procedury przeciwdziałania biasowi (stronniczości). Umowa powinna gwarantować legalność źródeł danych oraz brak naruszeń praw autorskich (IP warranty).
- Punkt 3 – Monitoring i zdolności operacyjne: Precyzyjne metryki wydajności (precision, recall, F1-score) w odniesieniu do zróżnicowanych grup docelowych oraz znane ograniczenia systemu. W umowie należy powiązać te parametry ze zobowiązaniami jakościowymi (SLA).
- Punkt 4 – Walidacja metryk: Dowód, że dobrane miary wydajności są adekwatne do celów biznesowych i prawnych. Kontrakt powinien przewidywać procedurę rekalibracji w razie degradacji parametrów (data drift / concept drift).
- Punkt 5 – System zarządzania ryzykiem: Udostępnienie deployerowi macierzy ryzyk resztkowych (residual risk) oraz zidentyfikowanych ryzyk dla praw podstawowych, co jest niezbędne do sporządzenia oceny FRIA (art. 27).
- Punkt 6 – Zarządzanie zmianą w cyklu życia: Procedura wprowadzania poprawek, re-treningu oraz wersjonowania modeli (MLOps). Umowa musi definiować, kiedy zmiana modelu staje się modyfikacją istotną wymagającą ponownej certyfikacji.
- Punkt 7 – Normy zharmonizowane: Wskazanie stosowanych standardów technicznych (np. norm CEN-CENELEC, ISO/IEC 42001, ISO/IEC 22989, ISO/IEC 23894) z gwarancją ich utrzymywania przez cały okres trwania umowy.
- Punkt 8 – Deklaracja zgodności UE: Przekazanie kopii deklaracji wraz z numerem wpisu do bazy danych UE (EU Database for High-Risk AI Systems).
- Punkt 9 – Plan nadzoru po wprowadzeniu do obrotu: Szczegółowy podział ról w procesie ciągłego monitorowania działania algorytmu w środowisku produkcyjnym klienta.
Telemetria, logi (art. 12) i rygory raportowania incydentów (art. 73)
Zgodnie z art. 12 system wysokiego ryzyka musi automatycznie zapisywać przebieg sesji, dane wejściowe, identyfikatory operatorów weryfikujących wyniki oraz wygenerowane predykcje. Kontrakt musi jednoznacznie regulować, po której stronie spoczywa infrastrukturalny ciężar utrzymywania logów oraz jak realizowane są prawa dostępu w przypadku postępowań wyjaśniających.
W zakresie zgłaszania poważnych incydentów (art. 73) obowiązują ścisłe terminy raportowania do organów nadzoru rynku:
- Incydent krytyczny (zgon lub poważne zagrożenie zdrowia/życia): Zgłoszenie natychmiastowe, nie później niż w ciągu 2 dni (lub maksymalnie 10 dni w określonych okolicznościach).
- Pozostałe poważne incydenty (prawa podstawowe, infrastruktura krytyczna, mienie): Zgłoszenie natychmiast po wykazaniu związku przyczynowego, nie później niż w terminie 15 dni od momentu powzięcia wiedzy o zdarzeniu.
Aby dostawca mógł dochować terminów ustawowych, umowa musi nakładać na deployera obowiązek zgłoszenia podejrzenia anomalii wewnątrzorganizacyjnie w ciągu kilkunastu godzin od jej wykrycia (zgodnie z art. 26 ust. 5).
Zestawienie wymogów regulacyjnych i klauzul kontraktowych
Obszar techniczny | Podstawa w AI Act | Wymagany zapis w umowie B2B |
|---|---|---|
| Role w łańcuchu dostaw | Art. 25, 26 | Jednoznaczna identyfikacja statusu stron, zakaz modyfikacji zmieniających przeznaczenie bez pisemnej zgody pierwotnego dostawcy. |
| Dokumentacja i instrukcje | Art. 11, 13, Załącznik IV | Gwarancja dostępu do aktualnej instrukcji, metryk dokładności, specyfikacji danych wejściowych i streszczenia oceny ryzyka. |
| Rejestracja logów (Audit Trail) | Art. 12 | Format logów (czas, user ID, wejście/wyjście), polityka retencji (min. 6 miesięcy), szyfrowanie i API do audytu logów. |
| Raportowanie incydentów | Art. 73, Art. 26 ust. 5 | Ścieżka eskalacji incydentów (SLA powiadomienia np. do 24h), podział ról w kontaktach z krajowym organem nadzoru. |
| Nadzór ludzki (Human Oversight) | Art. 14 | Zapewnienie interfejsu technicznego umożliwiającego interwencję człowieka, wstrzymanie egzekucji oraz manualny override. |
| Ciągły monitoring (Post-market) | Art. 72 | Zasady przekazywania raportów z działania w warunkach produkcyjnych oraz mechanizmy obsługi driftu danych i modeli. |
Wzorcowe klauzule umowne do adaptacji (Model AI Clauses)
Poniższe wzory klauzul bazują na wytycznych Komisji Europejskiej dotyczących modelowych klauzul umownych dla systemów AI wysokiego ryzyka. Mają one charakter referencyjny i wymagają dostosowania do specyfiki wdrożenia:
§ 1. Oświadczenia dotyczące zgodności i dokumentacji technicznej
1. Dostawca oświadcza i gwarantuje, że System AI stanowi system wysokiego ryzyka w rozumieniu art. 6 i załącznika III do rozporządzenia Parlamentu Europejskiego i Rady (UE) 2024/1689 (AI Act) oraz spełnia wszelkie wymogi określone w Rozdziale III AI Act.
2. Dostawca oświadcza, że sporządził, zweryfikował i utrzymuje dokumentację techniczną zgodnie z art. 11 i załącznikiem IV AI Act oraz przeprowadził procedurę oceny zgodności, wystawiając deklarację zgodności UE.
3. Dostawca zobowiązuje się udostępnić Zamawiającemu wyczerpujące instrukcje obsługi, o których mowa w art. 13 AI Act, w tym specyfikację parametrów dokładności, odporności na cyberzagrożenia oraz znanych ograniczeń funkcjonalnych.§ 2. Logowanie zdarzeń, telemetria i retencja danych
1. System AI zapewnia funkcjonalność automatycznego rejestrowania zdarzeń (logów) przez cały cykl życia oprogramowania, zgodnie z art. 12 AI Act. Zakres rejestrowanych danych obejmuje co najmniej: znacznik czasu (timestamp), unikalny identyfikator sesji i operatora, dane wejściowe przekazane do przetworzenia oraz wygenerowaną predykcję/decyzję.
2. W przypadku modelu SaaS Dostawca zobowiązuje się do przechowywania logów w bezpiecznym repozytorium przez okres nie krótszy niż 6 miesięcy od daty ich wygenerowania oraz zapewnienia Zamawiającemu dostępu do logów poprzez dedykowany interfejs lub zabezpieczone API w celach audytowych i wyjaśniania incydentów.§ 3. Zarządzanie poważnymi incydentami i obowiązki informacyjne
1. Zamawiający zobowiązuje się niezwłocznie, lecz nie później niż w ciągu 24 godzin od momentu wykrycia, powiadomić Dostawcę o każdym zdarzeniu mogącym stanowić poważny incydent w rozumieniu art. 3 pkt 49 i art. 73 AI Act lub o stwierdzeniu nieprawidłowości stwarzających zagrożenie dla zdrowia, bezpieczeństwa lub praw podstawowych.
2. Dostawca odpowiada za formalne zgłoszenie poważnego incydentu do właściwego organu nadzoru rynku z zachowaniem terminów ustawowych wynikających z art. 73 AI Act (w tym w terminie do 2 dni w przypadku bezpośredniego zagrożenia życia/zdrowia lub do 15 dni w pozostałych przypadkach).
3. Strony zobowiązują się do pełnej współpracy technicznej przy analizie przyczyn źródłowych (Root Cause Analysis) oraz wdrażaniu natychmiastowych działań korygujących.
Praktyczne wdrożenie – integracja zespołów Legal, IT i Compliance
Skuteczne zarządzanie kontraktami w erze AI Act wymaga interdyscyplinarnego podejścia:
- Techniczne Due Diligence przedkontraktowe: Przed podpisaniem umowy zespół IT wspólnie z prawnikami powinien zweryfikować architekturę MLOps dostawcy, źródła danych treningowych, deklarację zgodności UE oraz gotowość systemu do eksportu logów audytowych.
- Wdrożenie wewnętrznych procedur MLOps / AI Governance: Organizacja wdrażająca musi ustanowić procedury kontroli wersji i zmian parametrów modeli, aby uniknąć ryzyka przeklasyfikowania na „nowego dostawcę” w rozumieniu art. 25.
- Sformalizowanie playbooka incydentów AI: Zdefiniowanie ścieżek eskalacji pomiędzy administratorami systemów a zespołem compliance, co pozwala na uruchomienie procedury z art. 73 w ciągu pierwszych godzin od wystąpienia anomalii.
