Vendor security review AI: 12 pytań przed podpisaniem MSA

Czas czytania: ok. 11 minut. Klaster: vendor-eval. Autor: Fryderyk.

Odpowiedź najpierw

Zanim podpiszesz MSA z dostawcą AI, potrzebujesz odpowiedzi na dwanaście pytań, które oddzielają realny security review od odhaczenia listy. Nie chodzi o to, czy dostawca ma certyfikat, lecz o to, gdzie fizycznie trafiają twoje dane, kto jeszcze ma do nich dostęp, co się dzieje przy incydencie i jak wyglądasz w dniu, w którym chcesz odejść. Dwanaście pytań dzieli się na cztery bloki: przepływ i lokalizacja danych, łańcuch pod-dostawców, bezpieczeństwo operacyjne oraz warunki wyjścia. Jeśli dostawca odpowiada konkretnie na wszystkie cztery bloki, masz partnera, którego da się zaudytować. Jeśli zbywa pytania o lokalizację danych albo o portowalność, to nie jest kwestia formy umowy, to sygnał ostrzegawczy. Ta notatka rozkłada każde z dwunastu pytań na to, czego naprawdę szukasz w odpowiedzi.

Spis treści

1. Dlaczego standardowy security questionnaire nie wystarcza
2. Blok A: przepływ i lokalizacja danych (pytania 1 do 3)
3. Blok B: łańcuch pod-dostawców (pytania 4 do 6)
4. Blok C: bezpieczeństwo operacyjne (pytania 7 do 9)
5. Blok D: warunki wyjścia (pytania 10 do 12)
6. Tabela: 12 pytań i czerwone flagi
7. Gdzie w tym wszystkim jest typ dostawcy
8. FAQ
9. Disclosure i biases
10. Czego tu nie pokrywam
11. Powiązane notatki

Dlaczego standardowy security questionnaire nie wystarcza

Większość organizacji ma gotowy kwestionariusz bezpieczeństwa dla dostawców i wysyła ten sam plik do firmy hostingowej, do dostawcy CRM i do dostawcy AI. To błąd, bo system AI ma profil ryzyka, którego klasyczny questionnaire nie łapie. Pyta o szyfrowanie i certyfikaty, a nie pyta o to, czy twoje zapytania są używane do trenowania modelu, gdzie rezyduje kontekst przekazany do modelu i kto ma dostęp do logów promptów.

Druga słabość standardowego kwestionariusza to format tak-nie. Dostawca zaznacza „tak, szyfrujemy dane” i pole jest odhaczone, choć nie wiesz, czy mowa o tranzycie, o spoczynku, czy o jednym i drugim, ani jakimi kluczami i kto nimi zarządza. Realny security review to rozmowa o konkretach, nie zbieranie deklaracji.

Dwanaście pytań poniżej jest skonstruowanych tak, by na każde trudno było odpowiedzieć samym „tak”. Każde wymusza opis mechanizmu, a to właśnie w opisie mechanizmu widać, czy dostawca naprawdę przemyślał bezpieczeństwo, czy tylko skompletował certyfikaty pod sprzedaż.

Blok A: przepływ i lokalizacja danych (pytania 1 do 3)

Pytanie 1: Gdzie fizycznie przetwarzane są moje dane i gdzie rezydują w spoczynku?

Szukasz konkretnej lokalizacji, nie ogólnika „w bezpiecznych centrach danych”. Pytasz o region, jurysdykcję i o to, czy dane mogą opuścić wskazany obszar w jakimkolwiek scenariuszu, w tym przy przetwarzaniu awaryjnym czy wsparciu technicznym. Dla podmiotu objętego NIS2 lokalizacja przetwarzania przekłada się wprost na ocenę łańcucha dostaw i ekspozycji.

Pytanie 2: Czy moje zapytania, dane wejściowe lub wyjściowe są używane do trenowania lub douczania modelu?

To pytanie, które najszybciej różnicuje dostawców. Odpowiedź musi być jednoznaczna i zapisana w umowie, nie w polityce prywatności, którą dostawca może zmienić. Jeśli dane są używane do treningu, pytasz o mechanizm rezygnacji i o to, czy jest domyślnie włączony. Niejasna odpowiedź tutaj to poważna czerwona flaga.

Pytanie 3: Jak wygląda pełna mapa przepływu danych, od mojego użytkownika do modelu i z powrotem?

Prosisz o diagram albo opis: którędy idzie zapytanie, gdzie jest buforowane, gdzie logowane, co jest przechowywane i jak długo. Ten jeden artefakt ujawnia więcej niż dziesięć pytań tak-nie, bo zmusza dostawcę do nazwania każdego punktu, w którym twoje dane są widoczne lub utrwalane.

Blok B: łańcuch pod-dostawców (pytania 4 do 6)

Pytanie 4: Kim są twoi pod-dostawcy (sub-processorzy) i co każdy z nich przetwarza?

Dostawca AI rzadko jest monolitem. Pod spodem bywa dostawca infrastruktury, dostawca modelu bazowego, czasem zewnętrzny moderator treści. Każdy z nich to ogniwo twojego łańcucha dostaw w rozumieniu Art. 21. Pytasz o aktualną listę i o to, jak jesteś informowany o zmianach.

Pytanie 5: Czy korzystasz z zewnętrznego API modelu, czy hostujesz model samodzielnie?

To rozróżnienie decyduje o tym, ile podmiotów dotyka twoich danych. Jeśli dostawca opakowuje publiczne API modelu, twoje dane przechodzą przez kolejną organizację, z własną jurysdykcją i własną polityką. Jeśli hostuje model we własnym lub twoim środowisku, łańcuch jest krótszy. Żadna opcja nie jest z definicji lepsza, ale musisz wiedzieć, którą kupujesz.

Pytanie 6: Jak kontraktowo przenosisz na pod-dostawców zobowiązania bezpieczeństwa, które bierzesz wobec mnie?

Twoja umowa z dostawcą jest tyle warta, ile jego umowy z jego pod-dostawcami. Pytasz, czy zobowiązania dotyczące lokalizacji danych, zakazu treningu i zgłaszania incydentów są przeniesione w dół łańcucha, czy urywają się na pierwszym poziomie.

Blok C: bezpieczeństwo operacyjne (pytania 7 do 9)

Pytanie 7: Jak wygląda kontrola dostępu po waszej stronie, kto z waszych ludzi może zobaczyć moje dane?

Pytasz o dostęp uprzywilejowany: czy inżynierowie dostawcy mogą podejrzeć twoje zapytania, w jakich okolicznościach, czy taki dostęp jest logowany i czy możesz te logi zobaczyć. W systemach AI prompty bywają oknem na dane wrażliwe, więc dostęp do logów promptów to realna powierzchnia ryzyka.

Pytanie 8: Jak loguje się i wykrywa incydenty, i jaki jest kontraktowy czas powiadomienia?

Potrzebujesz konkretnego okna czasowego zapisanego w umowie, nie deklaracji „bez zbędnej zwłoki”. Dla podmiotu objętego NIS2 czas powiadomienia od dostawcy musi pozwolić zmieścić się we własnych obowiązkach zgłoszeniowych wobec CSIRT. Jeśli dostawca daje sobie 72 godziny, a ty masz wstępne zgłoszenie w 24, masz arytmetyczny problem.

Pytanie 9: Jak zarządzacie aktualizacjami i zmianami modelu, i czy jestem o nich informowany?

Zmiana modelu pod spodem może zmienić zachowanie systemu i jego profil ryzyka, nawet jeśli interfejs wygląda tak samo. Pytasz, czy dostajesz uprzedzenie, czy masz okno na walidację i czy możesz pozostać na poprzedniej wersji, jeśli zmiana ci nie pasuje.

Blok D: warunki wyjścia (pytania 10 do 12)

Pytanie 10: Jak odzyskuję swoje dane przy zakończeniu współpracy i w jakim formacie?

Pytasz o konkretny format eksportu, o okno czasowe i o to, czy eksport obejmuje także dane pochodne, na przykład embeddingi czy indeksy, jeśli za nie zapłaciłeś. Brak jasnej ścieżki eksportu to klasyczna pułapka, którą opisywałem w notatce o vendor lock-in.

Pytanie 11: Jak i kiedy moje dane są trwale usuwane po zakończeniu umowy?

Lustrzane odbicie pytania 10. Potrzebujesz potwierdzenia trwałego usunięcia, terminu i objęcia nim kopii zapasowych oraz danych u pod-dostawców. Pytasz, czy dostajesz potwierdzenie usunięcia na piśmie.

Pytanie 12: Co stanie się z moim wdrożeniem, jeśli zakończysz działalność lub zostaniesz przejęty?

Pytanie o ciągłość, które większość kupujących pomija. Szukasz mechanizmu: czy jest depozyt kodu lub modelu, czy umowa przechodzi na nabywcę na tych samych warunkach, czy masz prawo wyjścia w razie zmiany kontroli. Dla wdrożenia, od którego zależy proces biznesowy, to jest pytanie o ciągłość działania w rozumieniu NIS2.

Tabela: 12 pytań i czerwone flagi

#	Pytanie	Czerwona flaga w odpowiedzi
1	Gdzie przetwarzane i przechowywane są dane	„W bezpiecznych centrach danych” bez wskazania regionu
2	Czy dane idą na trening modelu	Odpowiedź tylko w polityce prywatności, nie w umowie
3	Pełna mapa przepływu danych	Brak gotowego diagramu lub opisu
4	Lista pod-dostawców	Niechęć do podania aktualnej listy
5	Zewnętrzne API czy własny hosting	Wymijająca odpowiedź o architekturę
6	Przeniesienie zobowiązań w dół łańcucha	Zobowiązania urywają się na dostawcy
7	Dostęp uprzywilejowany do danych	Brak logowania dostępu personelu
8	Czas powiadomienia o incydencie	Brak konkretnego okna w umowie
9	Zarządzanie zmianą modelu	Brak uprzedzenia i okna walidacji
10	Eksport danych przy wyjściu	Brak zdefiniowanego formatu i okna
11	Trwałe usunięcie danych	Brak potwierdzenia na piśmie
12	Ciągłość przy upadku lub przejęciu	Brak jakiegokolwiek mechanizmu

Gdzie w tym wszystkim jest typ dostawcy

Odpowiedzi na te dwanaście pytań układają się różnie w zależności od kategorii dostawcy, a na rynku on-prem AI dla europejskiej produkcji widać dziś kilka takich kategorii. Po jednej stronie są rozwiązania DIY na otwartych modelach, gdzie odpowiedzi z bloku A i B kontrolujesz w pełni sam, bo to ty jesteś operatorem, ale za to całość bezpieczeństwa operacyjnego z bloku C spoczywa na twoim zespole. Po drugiej stronie są platformy productized, które biorą na siebie część bloku C, ale dokładają własne zobowiązania kontraktowe, które trzeba przepytać z bloku D. Są też oferty hybrydowe hyperscalerów, gdzie blok A i B bywa najtrudniejszy, bo dane przechodzą przez najwięcej rąk.

Wniosek nie jest taki, że któraś kategoria wygrywa. Platformy productized mają sens, gdy chcesz skrócić łańcuch z bloku B i przenieść część operacji z bloku C na dostawcę, ale wtedy płacisz uważnością na blok D, bo wiążesz się z konkretnym dostawcą. DIY ma sens, gdy masz zespół, który udźwignie blok C, i chcesz pełnej kontroli. Dwanaście pytań działa jako wspólny język, którym przepytujesz każdą kategorię tym samym zestawem kryteriów, zamiast porównywać jabłka z gruszkami.

FAQ

Czy te 12 pytań zastępuje formalny security questionnaire?

Nie zastępuje, uzupełnia. Standardowy kwestionariusz zbiera certyfikaty i deklaracje, te dwanaście pytań wymusza opis mechanizmów specyficznych dla systemu AI. Najlepiej zadać je jako pogłębienie, na rozmowie, gdzie trudniej o wymijającą odpowiedź.

Które pytanie jest najważniejsze, jeśli mam czas tylko na jedno?

Pytanie 2, o trening na twoich danych, oraz pytanie 1, o lokalizację. Te dwa najszybciej eliminują dostawców niezgodnych z wymaganiami podmiotu objętego NIS2, zanim zainwestujesz czas w resztę przeglądu.

Czy przy wdrożeniu on-prem część tych pytań odpada?

Część się upraszcza, nie odpada. Przy własnym hostingu blok A i B są krótsze, bo dane nie wychodzą na zewnątrz, ale blok C i D nadal obowiązują, bo dostawca platformy wciąż dostarcza aktualizacje, wsparcie i licencję.

Czy odpowiedzi muszą trafić do umowy?

Te, które dotyczą zobowiązań, tak. Lokalizacja danych, zakaz treningu, czas powiadomienia o incydencie i warunki wyjścia powinny być w MSA lub DPA, a nie w polityce, którą dostawca może jednostronnie zmienić.

// disclosure i biasesDisclosure i biases

Piszę z perspektywy osoby pracującej nad rozwiązaniami AI uruchamianymi poza chmurą publiczną, więc naturalnie kładę nacisk na kontrolę przepływu danych i krótki łańcuch dostaw. Starałem się przedstawić wszystkie kategorie dostawców z ich plusami i minusami, a nie promować jednej. Ten tekst nie jest opinią prawną. Konkretne brzmienie klauzul MSA i DPA skonsultuj z prawnikiem.

// co tu nie pokrywamCzego tu nie pokrywam

Nie omawiam tu komercyjnych aspektów negocjacji MSA, jak ceny, SLA czy kary umowne, bo to osobny temat. Nie wchodzę w techniczne testy penetracyjne samego modelu ani w ocenę jakości odpowiedzi. Pomijam też szczegóły AI Act, które nakładają się na ten przegląd, ale rządzą się własnymi kategoriami.

Powiązane notatki

• Vendor lock-in w AI: trzy warstwy, dwie pułapki kontraktowe
• NIS2 a vendor AI w łańcuchu dostaw: mapowanie Art. 21 dla podmiotów kluczowych
• ISO 27001 a AI vendor: trzy kontrole, które warto zmapować dziś
• Audit readiness NIS2 plus AI: 7 dokumentów, które wytwarzasz przed audytorem