RFP dla AI vendora compliance: szkielet 24 pytań w 4 kategoriach

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

Odpowiedź najpierw

Dobry RFP dla dostawcy AI w regulowanym manufacturing to nie lista życzeń funkcjonalnych, tylko narzędzie decyzyjne. Ma zrobić jedno: zmusić vendora do napisania na papierze rzeczy, których na callu sprzedażowym nie powie, i dać ci porównywalne odpowiedzi od kilku dostawców. Poniżej gotowy szkielet: 24 pytania w czterech kategoriach, security, regulacje, architektura i exit, po sześć w każdej. Każde pytanie ma jasny cel i wskazówkę, jak czytać odpowiedź. Możesz wkleić go do zapytania ofertowego bez zmian albo przyciąć do własnego kontekstu.

Spis treści

1. Po co osobny RFP, a nie mail z pytaniami
2. Jak czytać odpowiedzi i punktować
3. Kategoria 1: Security
4. Kategoria 2: Regulacje i compliance
5. Kategoria 3: Architektura i integracja
6. Kategoria 4: Exit i ciągłość
7. Jak zważyć wynik i gdzie są czerwone flagi
8. Czego tu nie pokrywam
9. Disclosure i biases
10. Powiązane notatki

Po co osobny RFP, a nie mail z pytaniami

Trzy powody, dla których warto sformalizować zapytanie zamiast wymieniać maile.

Po pierwsze, porównywalność. Kiedy każdy vendor odpowiada na to samo pytanie w tej samej kolejności, różnice widać gołym okiem. Luźna korespondencja daje trzy niezestawialne narracje sprzedażowe.

Po drugie, ślad audytowy. Pod NIS2 zarząd odpowiada za analizę ryzyka łańcucha dostaw. RFP z datą, pytaniami i odpowiedziami vendora to dokument, który wytwarzasz raz, a pokazujesz audytorowi jako dowód należytej staranności przy wyborze dostawcy.

Po trzecie, wiążący charakter. Odpowiedź w RFP łatwiej potem przenieść do MSA i DPA jako oświadczenie dostawcy. Ustne zapewnienie ze spotkania nie ma tej wagi.

RFP nie zastępuje due diligence technicznego ani proof of concept. Zawęża pole do dwóch, trzech vendorów, których warto puścić dalej.

Jak czytać odpowiedzi i punktować

Zanim przejdziemy do pytań, ustal skalę. Prosty schemat, który się sprawdza: każde pytanie punktujesz 0, 1 lub 2.

Dwa punkty to odpowiedź konkretna, z liczbą, nazwą standardu albo zapisem, który da się przenieść do kontraktu. Jeden punkt to odpowiedź ogólna, kierunkowo dobra, ale bez twardego zobowiązania. Zero to unik, „to zależy" bez rozwinięcia albo cisza.

Kluczowa zasada: waż kategorie, nie sumuj na ślepo. Dla podmiotu pod NIS2 kategoria regulacje i kategoria exit ważą więcej niż lista funkcji. Wysoki wynik w security przy zerze w exit to nie jest bezpieczny wybór, to uzależnienie od jednego dostawcy z ładnym certyfikatem.

Kategoria 1: Security

Sześć pytań o to, co dzieje się z twoimi danymi i modelem oraz kto ma do nich dostęp.

1. Gdzie fizycznie przetwarzane są nasze dane i gdzie trafiają prompty oraz odpowiedzi? Cel: ustalić, czy cokolwiek opuszcza twoją infrastrukturę. Odpowiedź „w naszej bezpiecznej chmurze" to jeden punkt. „Wyłącznie w waszym data center, żaden prompt nie wychodzi na zewnątrz" to dwa, o ile potwierdzone w architekturze.

2. Jak wygląda izolacja między tenantami albo, przy on-prem, między środowiskami? Cel: sprawdzić, czy twoje dane mogą wyciec do innego klienta lub innego działu. Szukaj konkretu o modelu izolacji, nie hasła „single-tenant".

3. Jaki dostęp do naszych danych i modelu ma personel dostawcy i jak jest logowany? Cel: zredukować ryzyko insidera po stronie vendora. Dobra odpowiedź opisuje dostęp break-glass, pełne logowanie i brak stałego dostępu do danych produkcyjnych.

4. Jak szyfrowane są dane w spoczynku i w tranzycie oraz kto zarządza kluczami? Cel: ustalić, czy klucze są po twojej stronie. Zarządzanie kluczami po stronie klienta to mocny sygnał.

5. Jaki jest proces zgłaszania i obsługi incydentu bezpieczeństwa i w jakim czasie nas powiadomicie? Cel: dopasować do obowiązku zgłoszeniowego pod NIS2. Potrzebujesz konkretnego okna czasowego, nie „bez zbędnej zwłoki".

6. Jak testujecie własne zabezpieczenia i czy udostępniacie raporty z testów lub certyfikaty? Cel: odróżnić deklarację od dowodu. Pentest przez stronę trzecią, raport SOC 2 albo równoważny dokument to dwa punkty.

Kategoria 2: Regulacje i compliance

Sześć pytań, które łączą dostawcę z twoimi obowiązkami pod NIS2, AI Act i RODO.

7. Które certyfikacje i normy realnie posiadacie, a nie tylko „jesteście zgodni"? Cel: rozdzielić posiadany certyfikat od deklaracji. Poproś o numer, zakres i datę ważności ISO 27001 albo równoważnika.

8. Jak wasze rozwiązanie wspiera nasze obowiązki z Art. 21 NIS2, w szczególności analizę ryzyka i bezpieczeństwo łańcucha dostaw? Cel: sprawdzić, czy vendor rozumie, że jest częścią twojego łańcucha dostaw. Odpowiedź „to wasza odpowiedzialność" to czerwona flaga.

9. Czy podpiszecie DPA i które klauzule powierzenia są dla was nienegocjowalne? Cel: wychwycić opór kontraktowy wcześnie. Brak gotowości do DPA przy przetwarzaniu danych osobowych dyskwalifikuje.

10. Jak klasyfikujecie system wobec AI Act i czy wspieracie obowiązki dla systemów high-risk? Cel: ustalić, czy vendor śledzi AI Act i wie, kiedy zastosowanie w produkcji wpada w high-risk. Szukaj świadomości Annex III, nie ogólników.

11. Gdzie przebiega granica odpowiedzialności między wami a nami w zakresie compliance? Cel: uniknąć luki, w której „każdy myślał, że robi to drugi". Dobra odpowiedź to jasna macierz odpowiedzialności.

12. Jak informujecie o zmianach regulacyjnych i aktualizacjach, które nas dotyczą? Cel: sprawdzić, czy compliance jest procesem, a nie jednorazowym oświadczeniem przy podpisie. Digital Omnibus i przesuwane terminy AI Act pokazują, że to się zmienia.

Kategoria 3: Architektura i integracja

Sześć pytań o to, jak rozwiązanie wpina się w twoją infrastrukturę i kto je utrzymuje.

13. Jaki jest model wdrożenia: on-prem, prywatne środowisko czy chmura i co dokładnie działa u nas? Cel: rozbić marketingowe „on-prem" na konkret. Ustal, które komponenty stoją u ciebie, a które u dostawcy.

14. Jakie są minimalne i rekomendowane wymagania sprzętowe, w tym GPU? Cel: policzyć realny koszt wdrożenia. Konkretne liczby sizingu to dwa punkty i materiał do kalkulacji TCO.

15. Jak rozwiązanie integruje się z naszymi systemami i przez jakie interfejsy? Cel: sprawdzić, czy nie kupujesz wyspy. Standardowe API i dokumentacja to minimum.

16. Jak wygląda utrzymanie, aktualizacje modeli i kto je wykonuje? Cel: ustalić, czy potrzebujesz własnego zespołu ML ops, czy dostawca to bierze na siebie. To jedna z największych ukrytych pozycji kosztowych.

17. Jak logujecie i udostępniacie ślad audytowy działania systemu? Cel: dopiąć observability do wymogu audytowego NIS2. Potrzebujesz audytowalnego logu, kto, kiedy, co zapytał i co dostał.

18. Jak rozwiązanie skaluje się przy wzroście liczby użytkowników i zapytań? Cel: uniknąć sytuacji, w której pilotaż działa, a produkcja się dławi. Szukaj konkretu o przepustowości, nie „skaluje się elastycznie".

Kategoria 4: Exit i ciągłość

Sześć pytań, które zwykle wypadają z zapytań, a decydują o tym, czy za trzy lata jesteś zakładnikiem dostawcy. Ta kategoria najczęściej obnaża prawdziwe intencje vendora.

19. Jak wygląda proces wyjścia i w jakim formacie zwracacie nasze dane? Cel: potwierdzić, że dane są przenośne. Standardowy, otwarty format i jasny proces to dwa punkty.

20. Co dzieje się z modelem, fine-tuningiem i embeddingami zbudowanymi na naszych danych po zakończeniu umowy? Cel: ustalić, czy zabierasz ze sobą wypracowaną wartość, czy zostaje u dostawcy. To częsta pułapka lock-inu.

21. Jakie są zależności od komponentów zamkniętych lub własnościowych, które utrudniają migrację? Cel: zmapować warstwy lock-inu. Uczciwy vendor wskaże je sam.

22. Jaki jest okres wypowiedzenia i czy są opłaty za wyjście lub migrację? Cel: wychwycić kary kontraktowe, które zniechęcają do odejścia. Długi lock-in czasowy plus opłata migracyjna to czerwona flaga.

23. Co się dzieje, jeśli zakończycie działalność albo zostaniecie przejęci? Cel: zabezpieczyć ciągłość. Pytaj o depozyt kodu, prawo do dalszego użycia i plan awaryjny.

24. Jak wygląda wsparcie w okresie przejściowym, jeśli migrujemy do innego rozwiązania? Cel: sprawdzić, czy wyjście jest wspierane, czy sabotowane. Zapisane zobowiązanie do współpracy przy migracji dużo mówi o dostawcy.

Jak zważyć wynik i gdzie są czerwone flagi

Po zebraniu odpowiedzi policz wynik per kategoria, nie jako jedną sumę. Maksimum to 12 punktów w każdej z czterech kategorii.

Trzy sygnały, które przeważają nad wysokim wynikiem ogólnym. Pierwszy: zero w kategorii exit. Dostawca, który nie potrafi opisać, jak od niego odejść, projektuje uzależnienie. Drugi: przerzucanie całej odpowiedzialności compliance na ciebie w pytaniach 8 i 11. To znaczy, że nie rozumie roli w łańcuchu dostaw albo świadomie ją bagatelizuje. Trzeci: same deklaracje bez dowodu w security i regulacjach, czyli „jesteśmy zgodni" bez certyfikatu, numeru i daty.

Odwrotny sygnał, pozytywny: vendor, który sam wskazuje własne ograniczenia i warstwy lock-inu, zwykle jest bardziej wiarygodny niż ten, który na wszystko odpowiada gładkim „tak".

Traktuj RFP jako filtr, nie jako wyrok. Jego zadaniem jest zawęzić pole do dwóch, trzech dostawców wartych proof of concept i technicznego due diligence.

// co tu nie pokrywamCzego tu nie pokrywam

Ten szkielet dotyczy fazy zapytania ofertowego, nie całego procesu zakupowego. Nie omawiam tu negocjacji cenowej ani modelu licencyjnego, bo to zależy od skali i budżetu. Nie wchodzę w szczegóły technicznej oceny jakości modelu, ewaluacji retrievalu ani benchmarków, bo to etap proof of concept, po RFP. Nie omawiam wewnętrznego procesu zakupowego, ścieżki akceptacji budżetu ani prawa zamówień, bo różnią się między organizacjami. Pomijam też szczegóły konkretnych vendorów, bo to zapytanie ma być narzędziem, nie rankingiem.

// disclosure i biasesDisclosure i biases

Piszę z perspektywy on-prem i architektury dla podmiotów pod NIS2, więc pytania o lokalizację danych, izolację i exit mają u mnie większą wagę niż w typowym RFP na oprogramowanie SaaS. To świadomy wybór, nie neutralność. Jeśli twój kontekst regulacyjny jest lżejszy, część kategorii exit i security możesz osłabić. Szkielet nie jest poradą prawną. Zakres obowiązków pod NIS2, AI Act i RODO ustalasz z własnym działem prawnym i compliance, bo zależy od klasyfikacji podmiotu i zastosowania systemu.

Powiązane notatki

• Vendor security review AI: 12 pytań przed podpisaniem MSA
• TCO on-prem AI vs chmura: jak liczyć w 3-letnim horyzoncie
• Vendor lock-in w AI: trzy warstwy, dwie pułapki kontraktowe
• DPA dla AI vendora: 8 klauzul, których brak wywróci audyt
• Audit readiness NIS2 plus AI: 7 dokumentów, które wytwarzasz przed audytorem