AI vendor due diligence: weryfikacja dostawcy i umowy

Zacznij od umiejscowienia dostawcy w łańcuchu

Zanim przejdziesz do checklisty, odpowiedz na jedno pytanie strukturalne, bo ono zmienia, za co odpowiadasz: jaką rolę pełni ten dostawca i jaką rolę pełnisz ty.

AI Act (Regulation (EU) 2024/1689) definiuje w Artykule 3 cztery role: provider, deployer, importer i distributor. Kiedy kupujesz i używasz systemu AI w swojej firmie, zwykle jesteś deployerem. Dostawca zwykle jest providerem. To przypisanie decyduje, jakie obowiązki spadają na kogo.

To nie zawsze jest czyste rozgraniczenie. Artykuł 25 opisuje, kiedy deployer w świetle prawa staje się providerem: gdy umieści własną nazwę albo markę na systemie wysokiego ryzyka, dokona istotnej modyfikacji albo zmieni przeznaczenie systemu w sposób, który czyni go wysokiego ryzyka. Jeśli fine-tunujesz model dostawcy, white-labelujesz go albo wykorzystujesz do innego celu, sprawdź Artykuł 25, zanim założysz, że jesteś tylko deployerem, bo stanie się providerem pociąga za sobą dużo cięższy zestaw obowiązków.

Osobno, zgodnie z RODO niemal zawsze jesteś administratorem danych osobowych, które przepuszczasz przez narzędzie, a dostawca jest podmiotem przetwarzającym. To relacja regulowana przez Artykuł 28, i to na niej opiera się większość sprawdzeń umowy poniżej.

Sprawdzenia dotyczące obsługi danych

To pytania o to, co dzieje się z danymi, gdy trafią do dostawcy. Pokrywają się w dużej mierze ze standardowym kwestionariuszem bezpieczeństwa dostawcy, zawężonym do tego, co ma znaczenie, gdy w ścieżce danych jest model.

Umowa powierzenia (DPA)

Jeśli narzędzie przetwarza dane osobowe w twoim imieniu, Artykuł 28 RODO wymaga pisemnej umowy, czyli DPA, określającej przedmiot, czas trwania, charakter i cel przetwarzania, rodzaje danych oraz obowiązki obu stron. Bez niej nie możesz zgodnie z prawem przepuszczać danych osobowych przez narzędzie.

Jak wygląda dobry wynik: DPA jest oferowana, możesz ją podpisać bez przechodzenia przez cały proces enterprise sales, a dokument nazywa przetwarzanie, które narzędzie faktycznie wykonuje. DPA, która istnieje, ale wyłącza z zakresu funkcję AI, nie jest dla ciebie realną DPA. Potwierdź, że DPA obejmuje konkretnie funkcjonalność AI, nie tylko podstawowy produkt.

Trenowanie na twoich danych

Jeśli dostawca trenuje swoje modele na twoich danych wejściowych, twoje dane wymykają się spod kontroli w sposób, którego nie da się cofnąć: prompt zawierający nazwę klienta albo fragment kodu może stać się częścią modelu, o który pytają inni ludzie. Pocieszający fakt jest taki, że główni komercyjni dostawcy domyślnie nie trenują na danych z warstwy biznesowej i API. Pułapką jest traktowanie tego domyślnego stanu jako gwarancji. Domyślny stan wiąże dostawcę tylko wtedy, gdy mówi o tym umowa. Sprawdź, czy zobowiązanie do braku trenowania jest w DPA albo w samej umowie, nie tylko na stronie pomocy, którą dostawca może zmienić bez informowania cię. Darmowe plany konsumenckie zwykle nie przechodzą tego sprawdzenia, bo ich regulaminy dopuszczają trenowanie na danych wejściowych.

Retencja i usuwanie danych

Jak długo dostawca przechowuje twoje dane wejściowe i wyjściowe, decyduje o oknie twojej ekspozycji w razie naruszenia oraz o twojej zdolności do zrealizowania żądania usunięcia danych zgodnie z RODO. Bezterminowa retencja, nad którą nie masz kontroli, to stałe zobowiązanie ryzyka. Jak wygląda dobry wynik: określony okres retencji, udokumentowany sposób żądania usunięcia danych i najlepiej opcja zerowej albo krótkiej retencji w warstwie API albo biznesowej.

Podprocesorzy

Dostawca rzadko robi wszystko sam. Dostawcy AI w szczególności piętrzą podprocesorów szybciej niż tradycyjny SaaS: łańcuch zwykle obejmuje dostawcę modelu, chmurę, w której model działa, oraz osobnych dostawców moderacji treści, analityki i bezpieczeństwa. Jeśli twój dostawca odpytuje API modelu innego providera, faktycznie korzystasz z tego providera, a twoje due diligence rozciąga się na niego jako czwartą stronę.

Artykuł 28(2) RODO wymaga, żeby podmiot przetwarzający nie angażował podprocesora bez uprzedniej szczegółowej albo ogólnej pisemnej zgody administratora, a 28(4) wymaga, żeby te same obowiązki ochrony danych spływały w dół do tego podprocesora, przy czym pierwotny podmiot przetwarzający pozostaje odpowiedzialny za jego uchybienia. Jak wygląda dobry wynik: aktualizowana, publiczna lista podprocesorów, wcześniejsze powiadomienie o zmianach i prawo do sprzeciwu. Dostawca, który nie potrafi nazwać swoich podprocesorów, nie do końca rozumie własne przepływy danych.

Hosting i rezydencja danych

Miejsce przetwarzania danych decyduje, jakie prawo ma zastosowanie i czy dochodzi do transferu poza UE. Dla części danych hosting w UE to wymóg, nie preferencja. Jak wygląda dobry wynik: jasna dokumentacja, gdzie odbywa się przetwarzanie, opcja hostingu albo rezydencji danych w UE tam, gdzie jej potrzebujesz, oraz zgodny z prawem mechanizm transferu (na przykład standardowe klauzule umowne) dla wszystkiego, co opuszcza UE.

Sprawdzenia modelu i pochodzenia

Są nowsze niż sprawdzenia danych i specyficzne dla dostawców AI.

Pochodzenie modelu

Pochodzenie odpowiada na pytanie, skąd wziął się model i czy ktoś przy nim majstrował. Przy dostawcy odsprzedającym albo opakowującym cudzy model chcesz wiedzieć, jaki model bazowy stoi pod spodem, kto go trenował i na czym. Działy zakupów i audytu coraz częściej proszą o AI bill of materials: uporządkowany zapis modelu bazowego, zbiorów danych do fine-tuningu, wersji kodu treningowego, zależności frameworków i licencjonowania. Generative AI Profile NIST (AI 600-1), który rozszerza AI Risk Management Framework na AI generatywną, wprost odnosi się do przejrzystości danych treningowych, pochodzenia modelu i ryzyka zależności od stron trzecich, i jest rozsądnym punktem odniesienia, o co pytać.

Dane treningowe i licencjonowanie

Zapytaj, na czym trenowano model i czy dostawca może ręczyć za licencjonowanie tych danych. Ma to znaczenie z dwóch powodów: ryzyka, że w zbiorze treningowym znajdują się dane chronione albo niewłaściwie licencjonowane, oraz twojej własnej ekspozycji dalej w łańcuchu, jeśli wyniki odtwarzają materiał, do którego dostawca nie miał prawa. Dostawca, który potrafi jasno mówić o źródłach danych treningowych i licencjonowaniu, to mniejsze ryzyko niż taki, który traktuje to pytanie jak atak.

Sprawdzenia dostępu i bezpieczeństwa

Model dostępu

Samodzielne narzędzie, do którego wklejasz tekst, to jeden rodzaj decyzji. Narzędzie, które prosi o połączenie z twoim Google Workspace albo Microsoft 365 i odczyt poczty, plików albo kalendarzy, to zupełnie inna skala. Grant OAuth utrzymuje się, a zakres jest często szerszy, niż wymaga tego funkcja. Jak wygląda dobry wynik: narzędzie prosi o najwęższy zakres, jaki wystarcza do zadania, zakresy są widoczne i wyjaśnione, a każdy szeroki dostęp odczytu do poczty albo dysków jest uzasadniony funkcją, nie wygodą dostawcy.

Traktuj prośbę o połączenie jako kategorię wyżej niż narzędzie do wklejania tekstu. Narzędzie, które widzi tylko to, co ktoś wklei, ma ograniczony blast radius. Narzędzie ze stałym grantem do twojej poczty albo dysku może sięgnąć po dane, którymi nikt nie zdecydował się z nim podzielić, i zachowuje ten zasięg długo po tym, jak osoba, która go zatwierdziła, odeszła z firmy.

Poziom bezpieczeństwa i certyfikaty

Raport SOC 2 Type II albo certyfikat ISO 27001 to dowód, że niezależna strona sprawdziła kontrole dostawcy. To nie gwarancja, ale jego brak u dostawcy obsługującego wrażliwe dane to realna luka. Artykuł 28(5) RODO wprost uznaje przestrzeganie zatwierdzonego mechanizmu certyfikacji za jeden ze sposobów, w jaki podmiot przetwarzający może wykazać „wystarczające gwarancje" wymagane przez przepis, choć sama certyfikacja nie tworzy domniemania zgodności.

Za tym stwierdzeniem sprawdź dwie rzeczy. Że raport jest typu Type II, który testuje kontrole w okresie czasu, a nie Type I, który testuje jeden punkt w czasie. I że zakres raportu faktycznie obejmuje produkt, który weryfikujesz, bo certyfikat dużego dostawcy może pokrywać inną część biznesu.

Historia incydentów i dojrzałość dostawcy

Młody dostawca, który szybko się rozwija, może mieć płytkie praktyki bezpieczeństwa i krótką historię. Przeszłe incydenty i to, jak dostawca sobie z nimi poradził, mówią, jak zachowuje się pod presją. Jak wygląda dobry wynik: opublikowana strona bezpieczeństwa, sposób zgłaszania podatności, brak wzorca niezgłoszonych albo źle obsłużonych naruszeń oraz dostawca na tyle dojrzały, żeby odpowiadać na pytania o bezpieczeństwo bez tarcia.

Pytania o bezpieczeństwo, które warto zadać

Zwięzły zestaw, który możesz wysłać do dowolnego dostawcy AI, pogrupowany według tego, co chronią.

• Przetwarzanie danych · Pytania do zadania: Czy oferujecie DPA obejmującą konkretnie funkcję AI? Jaka jest podstawa prawna i cel przetwarzania?
• Trenowanie · Pytania do zadania: Czy nasze dane są używane do trenowania albo ulepszania waszych modeli? Czy zobowiązanie do braku trenowania jest w umowie i czy jest domyślnie włączone w naszej warstwie?
• Retencja · Pytania do zadania: Jak długo przechowujecie dane wejściowe i wyjściowe? Czy możemy zażądać usunięcia i czy dostępna jest opcja zerowej albo krótkiej retencji?
• Podprocesorzy · Pytania do zadania: Czy możecie udostępnić aktualną listę podprocesorów? Jak jesteśmy informowani o zmianach i czy możemy się sprzeciwić?
• Hosting · Pytania do zadania: Gdzie przetwarzane są dane? Czy dostępny jest hosting albo rezydencja danych w UE? Jaki mechanizm transferu obejmuje wszystko, co opuszcza UE?
• Model · Pytania do zadania: Jaki model bazowy stoi za produktem? Czy możecie dostarczyć AI bill of materials obejmujący dane treningowe, licencjonowanie i zależności?
• Dostęp · Pytania do zadania: O jakie zakresy prosi dowolna integracja i dlaczego? Czy zakres można zawęzić do faktycznej potrzeby funkcji?
• Bezpieczeństwo · Pytania do zadania: Czy macie aktualny SOC 2 Type II albo ISO 27001 obejmujący ten produkt? Gdzie jest wasza strona bezpieczeństwa i ścieżka zgłaszania podatności?

Gdzie ciężar musi udźwignąć umowa

Powtarzającym się motywem we wszystkich tych sprawdzeniach jest to, że strona marketingowa i umowa to nie to samo, a wyegzekwować da się tylko jedno z nich. Domyślny brak trenowania, opcja retencji, obowiązki wobec podprocesorów i zobowiązania bezpieczeństwa mają dla ciebie znaczenie dokładnie w takim zakresie, w jakim pojawiają się w DPA albo umowie. Dostawca może zmienić stronę pomocy bez ostrzeżenia. Nie może zmienić umowy, którą podpisałeś.

Dlatego ostatnim krokiem due diligence jest zestawienie warunków dotyczących danych z deklaracjami i upieranie się, żeby zobowiązania, na których polegasz, zostały spisane w umowie. Tam, gdzie ich nie ma, zaczyna się negocjacja, a przy dostawcy obsługującym wrażliwe dane warto ją przeprowadzić. Koszt pominięcia tego kroku ujawnia się później, jako ekspozycja na niewystarczające warunki podmiotu przetwarzającego zgodnie z Artykułem 28 RODO, albo jako dane, za którymi już nie nadążasz.

Źródła

• Regulation (EU) 2024/1689 (Artificial Intelligence Act), Artykuły 3 i 25 · eur-lex.europa.eu/eli/reg/2024/1689/oj (cztery role operatorów; kiedy deployer staje się providerem).
• RODO, Artykuł 28 (Podmiot przetwarzający) · gdpr-info.eu/art-28-gdpr (wystarczające gwarancje, obowiązkowa pisemna umowa, zgoda na podprocesora i spływanie obowiązków, certyfikacja jako dowód zgodnie z 28(5)).
• RODO, Artykuł 83 (Ogólne warunki nakładania administracyjnych kar pieniężnych) · gdpr-info.eu/art-83-gdpr (pułap z Artykułu 83(4): 10 milionów EUR albo 2% globalnego obrotu za naruszenia Artykułu 28).
• NIST, Artificial Intelligence Risk Management Framework: Generative AI Profile (NIST AI 600-1) · nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf (przejrzystość danych treningowych, pochodzenie modelu, ryzyko zależności od stron trzecich).
• IBM, Cost of a Data Breach Report 2025 (informacja prasowa, 30 lipca 2025) · newsroom.ibm.com/2025-07-30-ibm-report-13-of-organizations-reported-breaches-of-ai-models-or-applications,-97-of-which-reported-lacking-proper-ai-access-controls (luki w kontroli dostępu i governance AI stojące za ryzykiem dostawców).
• TrustArc, „AI Supply Chain Risk: The New Vendor Due Diligence" · trustarc.com/resource/ai-supply-chain-risk-vendor-due-diligence (piętrzenie się podprocesorów AI i due diligence czwartych stron).