Jak odpowiadać na pytania o AI w kwestionariuszach bezpieczeństwa

Dlaczego pytania o AI mają dziś własną sekcję

Kwestionariusz bezpieczeństwa to sposób, w jaki kupujący sprawdza dostawcę przed podpisaniem umowy. Przez lata te formularze pytały o dostęp, szyfrowanie, reakcję na incydenty i certyfikaty, a AI w twoim produkcie było dla nich niewidoczne. Recenzenci dodają dziś pytania o AI, bo starsze formaty nie wychwytują, jak modele AI i systemy złożone są trenowane, aktualizowane i nadzorowane, a także dlatego, że ich własne obowiązki wynikające z RODO, unijnego AI Act i frameworków takich jak AI Risk Management Framework od NIST sięgają dziś do ich dostawców.

Przeramowanie, które sprawia, że da się na nie odpowiedzieć, jest takie samo jak dla reszty formularza. Pytanie o AI, na które nie odpowiesz dowodami, to luka w widoczności, nie porażka bezpieczeństwa. „Nie jesteśmy pewni, czy prompty są przechowywane” oznacza: idź przeczytać warunki dotyczące danych u swojego dostawcy i własne logowanie, a nie zgadywanie.

Sekcja o AI jest trudniejsza, bo dane rozchodzą się szerzej. Pojedyncza funkcja może przesuwać dane przez inferencję, logi promptów, embeddingi, bazę wektorową, zbiory do fine-tuningu i backupy, często u więcej niż jednego dostawcy i w więcej niż jednym regionie. Każde z tych miejsc to miejsce, gdzie dane leżą, i coś, o co recenzent może zapytać. Zadanie polega na tym, żeby raz zmapować ścieżkę danych AI, spisać, co jest prawdą, i odpowiadać z tej mapy, zanim przyjdzie formularz.

Kategorie pytań o AI, jakie zadają kupujący

Jeśli zdjąć samo sformułowanie, pytania o AI grupują się w garść kategorii. Oto każda z nich, o co naprawdę pyta i co zawiera mocna odpowiedź.

Dostawcy modeli i łańcuch dostaw AI

Pytania otwierające ustalają, co stoi za twoim produktem. Jakich modeli używasz, czy są twoje czy zewnętrzne, i kim są dostawcy. Kupujący nie oceni twojego ryzyka AI bez wiedzy, czy wywołujesz API modelu frontier, uruchamiasz hostowany przez siebie model open-weight, czy fine-tunujesz coś pomiędzy.

Mocna odpowiedź wprost wymienia dostawców: API modelu, które wywołujesz, chmurę, na której działa, i wszelkie usługi specyficzne dla AI na ścieżce, jak baza wektorowa czy dostawca moderacji treści, i stwierdza, czy każdy model jest zewnętrzny czy self-hosted. Twoi dostawcy modeli to podprocesorzy, więc powinni pojawić się na twojej liście podprocesorów i w DPA. Dostawca, który nie potrafi nazwać modeli stojących za własnym produktem, jeszcze nie rozumie własnych przepływów danych, i recenzent czyta to właśnie tak.

Trenowanie na danych klienta

To pytanie waży dla kupujących najwięcej, bo ma nieodwracalne konsekwencje. Jeśli twoje inputy trenują wspólny model, prompt zawierający dane klienta może wypłynąć do innych użytkowników tego modelu, i tego nie da się cofnąć.

Mocna odpowiedź jest konkretna na trzy sposoby. Stwierdza, że dane klienta nie są używane do trenowania ani fine-tuningu modeli. Mówi, gdzie żyje to zobowiązanie, a musi to być umowa albo DPA, nie strona pomocy. I potwierdza, że to samo dotyczy warstwy niżej, u twojego dostawcy modelu, na tierze, którego faktycznie używasz. Główni komercyjni dostawcy domyślnie nie trenują na inputach z tieru biznesowego i API, ale ten domyślny stan chroni cię tylko wtedy, gdy twój tier i umowa to odzwierciedlają, a darmowe tiery konsumenckie zwykle tego nie robią. Mocna odpowiedź brzmi więc: „dane klienta nie są używane do trenowania; to zobowiązanie jest w naszym DPA; nasz dostawca modelu nie trenuje na inputach API na naszym tierze enterprise”, a nie gołe „nie trenujemy na twoich danych”, które zostawia recenzenta w niepewności, o którą warstwę chodzi.

Przechowywanie danych, usuwanie i rezydencja

Te pytania sprawdzają, jak długo trzymasz prompty, odpowiedzi, embeddingi i logi, jak klient zgłasza usunięcie i gdzie odbywa się przetwarzanie. Ekspozycją jest okno, w którym twoje dane AI mogą zostać złapane w naruszeniu, i twoja zdolność do zrealizowania żądania usunięcia na mocy RODO.

Mocna odpowiedź podaje okres przechowywania osobno dla każdego typu danych, zamiast jednej liczby, która chowa embeddingi i logi, udokumentowaną ścieżkę usuwania i jasne stwierdzenie, gdzie odbywa się przetwarzanie. Jeśli kupujący potrzebuje rezydencji danych w UE, odpowiedź nazywa region i mechanizm transferu dla wszystkiego, co go opuszcza. Nieokreślone, wieczne przechowywanie to luka, której szukają recenzenci, bo przechowywanie „na zawsze” poszerza blast radius każdego incydentu.

Przegląd i nadzór człowieka

Kupujący pytają, czy człowiek przegląda wyniki AI i gdzie zautomatyzowane decyzje wpływają na ludzi. Model, który pisze copy marketingowe, niesie inne ryzyko niż taki, który przesiewa kandydatów albo podejmuje decyzję dotyczącą konkretnej osoby.

Mocna odpowiedź uczciwie opisuje, gdzie w pętli jest człowiek, a gdzie go nie ma, i nazywa fallback na wypadek, gdy model zawiedzie albo będzie niedostępny: odpowiedź z cache, tryb obniżonej funkcjonalności albo przekazanie do człowieka. Nie twierdzi, że istnieje przegląd człowieka dla ścieżki w pełni zautomatyzowanej. Zawyżanie nadzoru to pułapka, bo recenzent, który później zobaczy zautomatyzowaną ścieżkę, przeczyta całą odpowiedź ponownie, tym razem z podejrzliwością.

Governance, frameworki i certyfikaty

Te pytania sprawdzają, jakie governance AI prowadzisz, jakich frameworków przestrzegasz i jakie certyfikaty posiadasz. To sposób, w jaki kupujący sprawdza, że twoje praktyki AI to program, a nie dobre intencje.

Mocna odpowiedź rozróżnia trzy rzeczy, które często się ze sobą myli:

• SOC 2 i ISO 27001 pokazują, że podstawowe kontrolki bezpieczeństwa zostały niezależnie sprawdzone. Warto je udostępniać pod NDA, ale nie ma osobnego „SOC 2 dla AI”: SOC 2 raportuje względem pięciu Trust Services Criteria (bezpieczeństwo, dostępność, integralność przetwarzania, poufność, prywatność), z których żadne nie certyfikuje governance modelu, ograniczania bias ani nadzoru człowieka. Więc „jesteśmy zgodni z SOC 2” odpowiada na pytanie o bezpieczeństwo i jest nie-odpowiedzią na pytanie o AI governance.
• ISO/IEC 42001, opublikowana w grudniu 2023, to standard systemu zarządzania AI i certyfikat specyficzny dla AI, z 38 kontrolkami w Załączniku A obejmującymi politykę AI, governance danych, cykl życia systemu AI i nadzór człowieka. Dzieli strukturę Annex SL z ISO 27001, więc można ją budować obok istniejącego ISMS. Jeśli ją posiadasz albo do niej dążysz, powiedz to precyzyjnie.
• NIST AI Risk Management Framework, wraz z Generative AI Profile, to dobrowolny framework, z którym możesz się dostosować. To nie certyfikat, więc deklaruj dostosowanie, nie zdanie egzaminu.

Podaj, które z nich posiadasz, do których się dostosowujesz i które są w toku, z datą.

Gotowość na AI Act

Kupujący sprzedający do UE albo działający w UE pytają dziś, gdzie stoisz w sprawie unijnego AI Act. Pułapką jest odpowiedź „jesteśmy zgodni z AI Act”, która sygnalizuje, że nie zajmowałeś się tym tematem, bo zgodność zależy od twojej roli i od obowiązków, które wchodzą w życie etapami przez kilka lat.

Mocna odpowiedź podaje twoją rolę i odpowiedni harmonogram. Zgodnie z rozporządzeniem (UE) 2024/1689 role operatorów to provider, deployer, importer i dystrybutor (art. 3). Większość firm SaaS jest providerem systemu AI, który buduje, albo deployerem takiego, którego używa, a zgodnie z art. 25 deployer może stać się providerem, na przykład istotnie modyfikując system albo umieszczając na nim własną nazwę. Obowiązki transparentności z art. 50, obejmujące informowanie ludzi, że wchodzą w interakcję z systemem AI, i oznaczanie treści wygenerowanych przez AI, obowiązują od 2 sierpnia 2026. Obowiązki dotyczące kompetencji AI z art. 4 obowiązują od 2 lutego 2025. Warto odnotować, że pakiet „Digital Omnibus”, przesuwający niektóre terminy dla systemów wysokiego ryzyka, został przyjęty przez Parlament i Radę w czerwcu 2026, ale na lipiec 2026 wciąż czeka na publikację w Dzienniku Urzędowym, więc do tego czasu obowiązują daty bazowe.

Dowody, które warto mieć przygotowane

Pytania o AI odpowiadają się najszybciej, gdy dowody już istnieją. Zbierz je, zanim przyjdzie formularz, a większość sekcji odpowie się sama.

• Mapa przepływu danych AI · Co obejmuje: Każde miejsce, gdzie leżą dane AI: inferencja, logi promptów, embeddingi, baza wektorowa, dane do fine-tuningu, backupy, i region każdego z nich · Gdzie żyje: Diagram i krótki opis pisemny
• Lista podprocesorów obejmująca dostawców modeli · Co obejmuje: Każdy dostawca na ścieżce AI, co robi i gdzie przetwarza · Gdzie żyje: Twoja opublikowana lista podprocesorów i DPA
• Zobowiązanie do braku trenowania · Co obejmuje: Zapis umowny, że dane klienta nie są używane do trenowania, plus odpowiadające warunki tieru dostawcy · Gdzie żyje: Twoje DPA i warunki danych enterprise twojego dostawcy
• Harmonogram przechowywania i usuwania · Co obejmuje: Okres przechowywania dla każdego typu danych i ścieżka usuwania · Gdzie żyje: Spisany harmonogram zgodny z tym, co faktycznie robią systemy
• Dokumenty AI governance · Co obejmuje: Twoja polityka dopuszczalnego użycia AI, proces weryfikacji modeli i kontrolki nadzoru · Gdzie żyje: Twój zestaw polityk, najlepiej zmapowany na framework
• Certyfikaty i dostosowanie do frameworków · Co obejmuje: Raporty SOC 2 albo ISO 27001, status ISO 42001, dostosowanie do NIST AI RMF · Gdzie żyje: Twoja strona trust albo pokój dowodowy dostępny pod NDA
• Rola i pozycja wobec AI Act · Co obejmuje: Twoja rola zgodnie z art. 3 i które obowiązki wchodzą w życie kiedy · Gdzie żyje: Krótka notatka wewnętrzna, którą możesz streścić

Wzorzec jest ten sam co w ogólnym kwestionariuszu: odpowiadaj dowodami, trzymaj dowody tam, gdzie możesz je szybko przedstawić, i wrzucaj każdą odpowiedź do biblioteki wielokrotnego użytku, uporządkowanej według kategorii, żeby ta sama odpowiedź obsłużyła kolejny formularz następnego kupującego, sformułowany inaczej.

Częste pułapki

Kilka błędów powtarza się na tyle często, że warto je nazwać, bo każdy zamienia obronną pozycję w słabszą.

Zawyżanie. Najbardziej szkodliwa pułapka to twierdzenie więcej, niż możesz udowodnić: zobowiązanie do braku trenowania, którego nie ma w żadnej umowie, przegląd człowieka na w pełni zautomatyzowanej ścieżce, certyfikat, którego nie posiadasz, albo „zgodni z AI Act”, gdy nie umieściłeś się w strukturze ról z Aktu. Odpowiedzi z kwestionariusza mogą zostać przywołane w umowie, więc zawyżona kontrolka to oświadczenie, za którym możesz nie być w stanie stanąć, a gdy recenzent złapie jedną nadmuchaną odpowiedź, czyta całą resztę z podejrzliwością.

Mgliste „nie trenujemy na twoich danych”. To zdanie jest prawdziwe dla niemal każdego i mówi recenzentowi niemal nic. Nie mówi, której warstwy dotyczy (twojej aplikacji czy dostawcy modelu), czy zobowiązanie jest umowne, czy to ustawienie, które może się zmienić, ani którego tieru dotyczy. Recenzent, który przeczytał setkę takich zdań, traktuje je jak wypełniacz i zadaje pytanie uzupełniające, które mogłeś uprzedzić.

Traktowanie strony pomocy jak umowy. Strony marketingowe i pomocy mogą być zmieniane bez ostrzeżenia; wiąże dostawcę tylko DPA i umowa. Jeśli ochrona, na której polegasz, brak trenowania, przechowywanie, rezydencja, żyje tylko na stronie, uczciwa pozycja brzmi: to jeszcze nie jest zobowiązanie umowne.

Mylenie SOC 2 z AI governance. Odpowiadanie na pytanie o AI governance atestacją SOC 2 czyta się jako niezrozumienie tego, co pokrywa SOC 2. SOC 2 i ISO 27001 to certyfikaty bezpieczeństwa; ISO 42001 to ten od AI. Używaj każdego do pytania, na które faktycznie odpowiada.

Zapominanie o podprocesorach, którymi są dostawcy modeli. Dostawca modelu i jego chmura to podprocesorzy na twojej ścieżce danych, zwykle najważniejsi dla pytania o AI. Pominięcie ich na liście albo niemożność ich nazwania sygnalizuje, że nie zmapowałeś własnego przepływu danych AI.

Chowanie luk zamiast datowania ich. Gdy uczciwa odpowiedź brzmi „jeszcze nie”, powiedz, co jest prawdą teraz, co robisz i kiedy to będzie gotowe. Kupujący akceptują uczciwe luki z roadmapą dużo chętniej niż pewne siebie twierdzenie, które później okazuje się fałszywe. Datowaną lukę recenzent może śledzić; blef złapie.

Źródła

• Regulation (EU) 2024/1689 (Artificial Intelligence Act), Articles 3, 4, 25, 50 · eur-lex.europa.eu/eli/reg/2024/1689/oj (role operatorów, deployer stający się providerem, obowiązek kompetencji AI w mocy od 2 lutego 2025, obowiązki transparentności obowiązujące od 2 sierpnia 2026).
• European Commission, Shaping Europe's digital future, Guidelines and Code of Practice on transparent AI systems · digital-strategy.ec.europa.eu/en/faqs/guidelines-and-code-practice-transparent-ai-systems (obowiązki transparentności z art. 50 i data stosowania 2 sierpnia 2026).
• GDPR, Article 28 (Processor) · gdpr-info.eu/art-28-gdpr (wystarczające gwarancje, obowiązkowa pisemna umowa, zgoda na podprocesora na mocy 28(2) i obowiązek schodzenia w dół na mocy 28(4)).
• ISO/IEC 42001:2023, Artificial Intelligence management system · iso.org/standard/42001 (standard systemu zarządzania AI, opublikowany w grudniu 2023).
• A-LIGN, Understanding ISO 42001 · a-lign.com/articles/understanding-iso-42001 (kontrolki Załącznika A, struktura Annex SL dzielona z ISO 27001, relacja do SOC 2 i ISO 27001).
• AICPA, Trust Services Criteria · aicpa-cima.com (pięć Trust Services Criteria, względem których raportuje SOC 2; brak osobnych kryteriów dla AI).
• Delve, What security questionnaires should ask AI vendors · delve.co/blog/what-security-questionnaires-should-ask-ai-vendors (kategorie pytań o AI: łańcuch dostaw, trenowanie, obsługa danych i rezydencja, przegląd człowieka i fallback, certyfikaty i DPA).
• Conveyor, Vendor security risk assessment questions for companies using AI · conveyor.com/blog/4-vendor-security-risk-assessment-questions-to-ask-companies-using-artificial-intelligence-ai-in-their-software (trenowanie na danych i umowna kontrolka braku ponownego wykorzystania).
• NIST, Artificial Intelligence Risk Management Framework: Generative AI Profile (NIST AI 600-1) · nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf (dobrowolny framework obejmujący transparentność danych treningowych, pochodzenie i ryzyko strony trzeciej).