Pytania dotyczące bezpieczeństwa dla dostawców platform negocjacyjnych dla przedsiębiorstw

Kupujący oceniający bezpieczeństwo platformy negocjacyjnej powinni wymagać od dostawców dowodów — a nie samych zapewnień — na to, jak izolują dane klientów, kontrolują ich retencję i usuwanie, stosują szyfrowanie, ograniczają uprawnienia oraz tworzą wiarygodne ścieżki audytu. Kontrole te powinny obejmować całą architekturę platformy negocjacyjnej, w tym prompty, załączniki, embeddingi, kopie zapasowe, narzędzia wsparcia, integracje i podwykonawców przetwarzania.

W przypadku bezpieczeństwa negocjacji AI i prywatności danych na platformie negocjacyjnej kwestionariusz to dopiero początek. Zespoły ds. zakupów w przedsiębiorstwach potrzebują diagramów architektury, wyników testów, demonstracji konfiguracji, przykładowych logów, zobowiązań umownych oraz zatwierdzenia ryzyka rezydualnego przez odpowiedzialne osoby. Certyfikat może wesprzeć ocenę, ale nie zastąpi dowodów dotyczących konkretnego produktu.

Krótka odpowiedź

Zapytaj, jak dostawca oddziela dane każdego klienta, jakie dane przechowuje i usuwa, gdzie stosuje szyfrowanie, kto może wykonywać wrażliwe działania oraz które zdarzenia klienci mogą audytować. Zażądaj diagramów architektury, wyników testów, harmonogramów retencji, szczegółów zarządzania kluczami, macierzy uprawnień i przykładowych logów. Następnie przekształć zaakceptowane odpowiedzi w zobowiązania umowne, a wyjątki poddaj zatwierdzeniu przez osoby odpowiedzialne za bezpieczeństwo, prywatność, kwestie prawne, zakupy i działalność biznesową.

Pięć obszarów kontroli, pięć wymagań dowodowych

Skorzystaj z tego podsumowania, aby uporządkować pierwsze spotkanie z dostawcą.

NIST Cybersecurity Framework 2.0 określa autoryzację dostępu, ochronę danych i generowanie logów jako rezultaty działań z zakresu cyberbezpieczeństwa. To przydatny punkt odniesienia, ale nie dowód, że konkretny dostawca skutecznie wdrożył te rozwiązania.

1. Sprawdź izolację w całej architekturze

Izolacja tenantów oznacza uniemożliwienie jednemu klientowi lub obciążeniu dostępu do danych innego klienta albo wpływania na nie. Dostawca może twierdzić, że każdy rekord w bazie danych ma identyfikator klienta, ale taka odpowiedź pomija indeksy wyszukiwania, pamięci podręczne, analitykę, przechowywanie plików, integracje i usługi AI.

Poproś dostawcę o wskazanie wszystkich komponentów, w których mogą współistnieć informacje klientów:

• Usługi aplikacyjne i interfejsy API
• Bazy danych, repliki i hurtownie danych
• Przechowywanie obiektów i załączników
• Pamięci podręczne i kolejki komunikatów
• Indeksy wyszukiwania i wyszukiwania informacji
• Systemy analityczne i diagnostyczne
• Prompty, wyniki, embeddingi i dane ewaluacyjne
• Środowiska programistyczne, testowe, demonstracyjne i wsparcia
• Dostawcy modeli i inni podwykonawcy przetwarzania

Następnie zapytaj, jak tożsamość tenanta jest weryfikowana przy każdym żądaniu dotyczącym obiektu i każdym wywołaniu API. Czy izolację egzekwuje infrastruktura, konta, schematy, polityki baz danych czy kod aplikacji? W którym miejscu błąd programistyczny może doprowadzić do przekroczenia granicy izolacji?

NIST SP 800-53 Release 5.2.0 obejmuje kontrole dotyczące dostępu, współdzielonych zasobów i ochrony przechowywanych informacji. Towarzysząca mu publikacja oceniająca, NIST SP 800-53A, wspiera ważną zasadę zakupową: żądaj dowodów, że kontrola została wdrożona i działa, a nie tylko polityki mówiącej, że powinna istnieć.

Pytania o dowody dotyczące izolacji

1. Czy zakres testów penetracyjnych wyraźnie obejmuje dostęp między tenantami?
2. Czy testowano ścieżki API, wyszukiwania, eksportu, pamięci podręcznej i przechowywania plików?
3. Czy dane produkcyjne są kiedykolwiek kopiowane do środowisk nieprodukcyjnych?
4. W jaki sposób pracownicy dostawcy uzyskują tymczasowy dostęp do środowiska produkcyjnego?
5. Czy dostęp jest zatwierdzany, ograniczony czasowo, rejestrowany i poddawany przeglądom?
6. Czy prompty AI, indeksy wyszukiwania, wyniki i embeddingi są izolowane między tenantami?
7. Czy u dostawcy doszło do potwierdzonego lub podejrzewanego ujawnienia danych między klientami i jak zareagowano?

Ogólne pismo potwierdzające wykonanie testów penetracyjnych nie wystarczy, jeśli zakupiony produkt, region wdrożenia, funkcje AI lub granice między tenantami nie były objęte zakresem testów.

2. Określ retencję, zanim uzgodnisz usuwanie

Prywatność danych na platformie negocjacyjnej zależy od czegoś więcej niż obietnicy „usunięcia danych klienta po zakończeniu umowy”. Negocjacje zakupowe mogą obejmować oferty, załączniki od dostawców, wewnętrzne notatki, historię zatwierdzeń, prompty, wyniki modeli i wrażliwe metadane handlowe. Kopie mogą znajdować się również w logach, replikach, zgłoszeniach do pomocy technicznej, kopiach zapasowych i systemach podwykonawców przetwarzania.

Przed zaakceptowaniem proponowanych warunków dostawcy przygotuj macierz retencji:

Nie kopiuj uniwersalnego okresu retencji z listy kontrolnej. Odpowiednie okresy zależą od potrzeb związanych z dochodzeniami, terminów rozstrzygania sporów, polityki firmy, obowiązków prawnych, wrażliwości danych i ról stron.

Jeśli zastosowanie mają przepisy RODO dotyczące podmiotów przetwarzających, umowy zasadniczo muszą regulować zwrot lub usunięcie danych osobowych oraz wsparcie audytowe. Rozporządzenie ustanawia również zasadę ograniczenia przechowywania. Zob. oficjalny tekst RODO. Prawnik powinien ustalić, czy i w jaki sposób przepisy te mają zastosowanie do konkretnego wdrożenia.

Pytania umowne dotyczące retencji

• Czy kupujący może konfigurować retencję dla poszczególnych kategorii danych?
• Co faktycznie usuwa dostępna dla użytkownika funkcja usuwania?
• Jak szybko usuwane są aktywne kopie, pamięci podręczne i repliki?
• Kiedy wygasają niezmienne kopie zapasowe?
• Czy usuwanie obejmuje pochodne indeksy i embeddingi?
• Jakie dane mogą pozostać z powodu blokady prawnej?
• Czy dostawca zapewni pomoc w eksporcie danych przed zakończeniem umowy?
• Kto podpisuje potwierdzenie usunięcia danych?
• Czy równoważne wymagania są przekazywane podwykonawcom przetwarzania?

Wytyczne FTC dotyczące bezpieczeństwa dostawców zalecają określenie w umowie oczekiwań dotyczących wykorzystania, retencji, udostępniania i usuwania danych przez dostawcę — oraz sprawdzanie zgodności z tymi wymaganiami zamiast polegania na zapewnieniach.

3. Nie poprzestawaj na haśle o szyfrowaniu

Stwierdzenie „szyfrowanie AES-256” nie wyjaśnia, gdzie stosuje się szyfrowanie, kto kontroluje klucze ani co dzieje się, gdy aplikacja używa danych w postaci jawnej. Szyfrowanie nie zapobiega nadużyciom ze strony upoważnionej aplikacji, administratora ani przejętego konta.

Poproś dostawcę o omówienie każdego stanu danych:

• Podczas przesyłania: sesje przeglądarki, API, integracje, połączenia z dostawcami modeli, kanały wsparcia i eksport danych
• W spoczynku: bazy danych, załączniki, logi, repliki, kopie zapasowe, indeksy i embeddingi
• Podczas użycia: wyszukiwanie, analityka, wnioskowanie modelu, przetwarzanie dokumentów i generowanie rekomendacji

Zarządzanie kluczami powinno obejmować ich generowanie, przechowywanie, dostęp, rotację, unieważnianie, tworzenie kopii zapasowych i niszczenie. Ten cykl życia opisuje definicja zarządzania kluczami NIST.

Pytania dotyczące szyfrowania i zarządzania kluczami

1. Jakie protokoły i algorytmy chronią poszczególne kategorie przechowywanych danych i ścieżki przepływu danych?
2. Czy klucze są rozdzielone według klienta, środowiska, usługi lub regionu?
3. Kto może administrować kluczami lub z nich korzystać?
4. Czy operacje na kluczach są rejestrowane i podlegają zasadzie podwójnej kontroli?
5. Czy kupujący może używać kluczy zarządzanych przez klienta i które dane pozostają poza tą kontrolą?
6. Czy unieważnienie klucza uniemożliwia dostęp do odpowiednich danych?
7. W jaki sposób klucze są niszczone po zakończeniu umowy?
8. Które dokładnie moduły kryptograficzne zostały niezależnie zwalidowane?

Jeśli dostawca deklaruje walidację FIPS, poproś o numer certyfikatu, wersję produktu, moduł i środowisko operacyjne. FIPS 140-3 dotyczy modułów kryptograficznych; samo użycie zatwierdzonego algorytmu nie dowodzi, że wdrożony produkt został zwalidowany.

4. Oddziel dostęp od uprawnień do podejmowania decyzji

Systemy negocjacyjne dla przedsiębiorstw potrzebują czegoś więcej niż podstawowych ról administratora i użytkownika. Uprawnienia mogą wymagać zróżnicowania według dostawcy, jednostki biznesowej, negocjacji, pola i działania.

Zażądaj demonstracji na żywo obejmującej:

• Logowanie jednokrotne SAML lub OIDC
• Wymuszanie uwierzytelniania wieloskładnikowego
• SCIM lub równoważne nadawanie i odbieranie uprawnień
• Role oparte na zasadzie domyślnej odmowy i minimalnych uprawnień
• Role niestandardowe i szczegółowe zakresy uprawnień
• Ograniczenia eksportu i pobierania zbiorczego
• Przypisanie właścicieli kont usługowych i rotację tokenów
• Ograniczony czasowo dostęp pracowników wsparcia
• Okresową certyfikację dostępu
• Alerty dotyczące eskalacji uprawnień, podszywania się i masowego eksportu

Najważniejszym testem jest rozdzielenie obowiązków. Użytkownik przygotowujący ofertę nie powinien automatycznie móc jej zatwierdzić i wysłać. Podobnie usługa AI może rekomendować warunki, ale nie powinna mieć uprawnień do zaciągania zobowiązań w imieniu przedsiębiorstwa.

Wytyczne CISA dotyczące bezpieczeństwa wbudowanego w projekt i domyślnego zalecają MFA dla użytkowników uprzywilejowanych, SSO oparte na standardach oraz użyteczne logi audytowe dostępne dla klientów. Kupujący powinni również ustalić, czy te kontrole są dostępne w rozważanym, komercyjnie opłacalnym planie produktu.

Aby szerzej przyjrzeć się temu, jak bezpieczeństwo wpisuje się w proces operacyjny, zapoznaj się z materiałem AI negotiations oraz powiązanym przewodnikiem dotyczącym gotowości danych dla platformy negocjacyjnej. Kupujący porównujący procesy związane z zaopatrzeniem mogą również sprawdzić oprogramowanie do negocjacji zakupowych.

5. Wymagaj audytowalności, a nie tylko „logowania”

Logowanie polega na tworzeniu zapisów. Audytowalność wymaga, aby zapisy były wystarczająco kompletne, wiarygodne, chronione, przechowywane i dostępne, tak by można było odtworzyć zdarzenie.

Zapytaj, czy platforma negocjacyjna rejestruje:

• Udane i nieudane logowania
• Zmiany MFA, użytkowników, ról i uprawnień
• Dostęp pracowników wsparcia dostawcy i podszywanie się pod użytkowników
• Wyświetlanie, tworzenie, edytowanie i usuwanie rekordów
• Historię ofert, kontrofert i zatwierdzeń
• Przesyłanie, pobieranie, udostępnianie i eksport zbiorczy
• Aktywność API i kont usługowych
• Zmiany konfiguracji i zasad retencji
• Rekomendacje wygenerowane przez AI
• Akceptację, edycję lub odrzucenie wyników AI przez człowieka
• Zmiany ustawień logowania

Każde istotne zdarzenie powinno wskazywać, kto lub co wykonało działanie, kiedy je wykonano, jakiego obiektu dotyczyło, na czym polegało i czy zakończyło się powodzeniem. Poproś o zsynchronizowane znaczniki czasu, najlepiej w UTC, udokumentowane schematy oraz automatyczny eksport do SIEM.

W dokumencie Cloud Security Technical Reference Architecture CISA zauważa, że klienci SaaS mogą być ograniczeni do logów udostępnianych przez dostawcę. Dokument zaleca automatyczne przesyłanie logów oraz podkreśla znaczenie scentralizowanego logowania i spójnych znaczników czasu.

Lista kontrolna do wykorzystania podczas weryfikacji bezpieczeństwa

Skorzystaj z poniższej listy kontrolnej podczas negocjacji z dostawcą dla przedsiębiorstwa. Oznacz każdy punkt jako Zweryfikowany, Częściowo, Niezweryfikowany lub Nie dotyczy. Status „Zweryfikowany” oznacza, że przeanalizowano dowody — nie tylko uzyskano twierdzącą odpowiedź dostawcy.

Architektura i izolacja

• Dostarczono aktualne diagramy architektury i przepływu danych
• Zidentyfikowano wszystkie współdzielone warstwy przechowywania i przetwarzania
• Wyjaśniono sposób egzekwowania izolacji tenantów dla żądań z interfejsu użytkownika i API
• Przetestowano izolację wyszukiwania, pamięci podręcznej, załączników, analityki i eksportu
• Zapewniono izolację promptów AI, wyników, embeddingów i indeksów wyszukiwania
• Oddzielono środowiska produkcyjne i nieprodukcyjne
• Dostęp uprzywilejowany pracowników wsparcia jest zatwierdzany, ograniczony czasowo i rejestrowany
• Zakres niedawnej oceny obejmuje testy dostępu między tenantami

Wykorzystanie, retencja i usuwanie danych

• Dostarczono kompletny wykaz danych
• Udokumentowano cel przetwarzania dla każdej kategorii danych
• Udokumentowano zasady wtórnego wykorzystania danych i trenowania modeli
• Określono okresy retencji według kategorii danych i warstwy przechowywania
• Określono termin usuwania danych z aktywnych systemów
• Określono terminy wygaśnięcia replik, pamięci podręcznych i kopii zapasowych
• Udokumentowano postępowanie w przypadku blokady prawnej
• Potwierdzono obowiązki podwykonawców przetwarzania dotyczące usuwania danych
• W proponowanych warunkach uwzględniono eksport danych i potwierdzenie ich usunięcia

Szyfrowanie i klucze

• Określono zakres szyfrowania podczas przesyłania, w spoczynku, w kopiach zapasowych i podczas przetwarzania
• Udokumentowano protokoły i algorytmy
• Wyjaśniono własność kluczy i mechanizmy kontroli dostępu
• Udokumentowano rotację, unieważnianie, tworzenie kopii zapasowych i niszczenie kluczy
• Operacje na kluczach są rejestrowane
• Ujawniono ograniczenia dotyczące kluczy zarządzanych przez klienta
• Deklarowane certyfikaty FIPS dotyczą wdrożonego modułu i środowiska

Tożsamość, uprawnienia i zatwierdzenia

• Zademonstrowano SSO i MFA
• Przetestowano automatyczne nadawanie uprawnień i ich natychmiastowe odbieranie
• Dostarczono macierz ról i uprawnień
• Można ograniczyć dostęp według jednostki biznesowej, dostawcy, negocjacji i działania
• Rozdzielono obowiązki tworzenia, modyfikowania, zatwierdzania i wysyłania
• Zademonstrowano mechanizmy kontroli eksportu, tokenów API i kont usługowych
• Okresowo weryfikuje się dostęp uprzywilejowany
• AI nie może zaciągnąć wiążącego zobowiązania bez zatwierdzenia przez upoważnioną osobę

Logowanie i zapewnienie bezpieczeństwa

• Dostarczono przykładowe logi i schemat zdarzeń
• Rejestrowane są zdarzenia administratorów, wsparcia, API, AI, eksportu i zatwierdzeń
• Logi zawierają unikatowe identyfikatory i wiarygodne znaczniki czasu
• Logi są chronione przed zwykłą modyfikacją administracyjną
• Zademonstrowano automatyczny eksport do SIEM
• Retencja logów odpowiada wymaganiom kupującego
• Zakres niezależnego audytu odpowiada zakupionej usłudze
• Ustalenia z testów penetracyjnych mają przypisanych właścicieli i określony status naprawy
• Przeanalizowano procedury reagowania na incydenty i powiadamiania klientów
• Przeanalizowano dowody testów ciągłości działania i odtwarzania po awarii

Umowa i zakończenie współpracy

• Zaakceptowane kontrole uwzględniono w umowie lub załączniku dotyczącym bezpieczeństwa
• Załącznik dotyczący bezpieczeństwa ma pierwszeństwo przed mniej rygorystycznymi zasadami na stronie internetowej
• Uzgodniono procedurę powiadamiania o podwykonawcach przetwarzania i zgłaszania sprzeciwu
• Istotne ograniczenie kontroli wymaga powiadomienia
• Określono dostęp do dowodów, działania naprawcze i prawa audytowe
• Określono przesłanki incydentu i terminy powiadamiania
• Określono pomoc w eksporcie i usuwaniu danych
• Wyznaczona osoba odpowiedzialna po stronie kupującego zatwierdza każdy wyjątek

Przekształć dowody w dokumentację decyzji

Praktyczna karta oceny powinna zachowywać informacje o niepewności, zamiast ukrywać ją za pojedynczym wynikiem procentowym.

Nie uśredniaj niezaliczonej kontroli obowiązkowej. Dopracowany raport z audytu nie rekompensuje nieprzetestowanej granicy między tenantami, a silne szyfrowanie nie rekompensuje nadmiernych uprawnień.

Przykład hipotetyczny: ocena procesu negocjacyjnego z użyciem AI

Przykład hipotetyczny — nie jest to twierdzenie dotyczące żadnego dostawcy: Zespół ds. zakupów w przedsiębiorstwie chce używać platformy do analizowania ofert dostawców i sugerowania możliwych odpowiedzi. Rekordy obejmują ceny dostawców, wewnętrzne cele, załączniki i tożsamości użytkowników.

Podczas oceny dostawca demonstruje kontrolę tenantów na poziomie bazy danych i SSO. Nie przedstawia jednak dowodów na to, czy embeddingi są rozdzielone między tenantami, czy określono termin usuwania danych diagnostycznych ani czy podszywanie się przez pracowników wsparcia jest widoczne w logach dostępnych klientowi.

Zespół nie powinien uznawać tych niewiadomych za zaliczone. Może:

1. Oznaczyć te trzy kwestie jako niezweryfikowane.
2. Zażądać szczegółów architektury i ukierunkowanych dowodów z testów.
3. Przeprowadzić test skonfigurowanego procesu z użyciem danych nieprodukcyjnych.
4. Wymagać, aby dostęp pracowników wsparcia był zatwierdzany, tymczasowy i rejestrowany.
5. Dodać retencję danych diagnostycznych i usuwanie embeddingów do załącznika dotyczącego bezpieczeństwa.
6. Wstrzymać użycie produkcyjne do czasu zatwierdzenia dowodów przez osobę odpowiedzialną za bezpieczeństwo albo formalnego zaakceptowania ryzyka rezydualnego.

Jeśli w tym procesie zakupowym rozważano by Negotiations.AI, platforma powinna podlegać takiej samej ocenie opartej na dowodach. Rozpoznawalność marki ani dopasowanie do procesu nie zwalniają kupującego z obowiązku zweryfikowania zakupionego wdrożenia.

Co jest zweryfikowane, założone, szacunkowe i zalecane?

Zweryfikowane fakty

• NIST opublikował CSF 2.0 26 lutego 2024 r.; obejmuje on rezultaty dotyczące autoryzacji, ochrony danych i logów.
• NIST opublikował wersje 5.2.0 dokumentów SP 800-53 i SP 800-53A 27 sierpnia 2025 r.
• FIPS 140-3 określa wymagania bezpieczeństwa dla modułów kryptograficznych.
• CISA zaleca bezpieczne ustawienia domyślne, MFA dla użytkowników uprzywilejowanych, SSO oparte na standardach oraz dostępne logi wysokiej jakości.
• Umowy z podmiotami przetwarzającymi, do których ma zastosowanie RODO, zasadniczo regulują usuwanie lub zwrot danych oraz wsparcie audytowe.

Podane źródła pierwotne potwierdzają te stwierdzenia; żadne z nich nie dowodzi, że konkretny dostawca jest bezpieczny.

Założenia

Te ramy zakładają wielodostępną platformę negocjacyjną SaaS, która przetwarza wrażliwe dane handlowe i dane dotyczące tożsamości. Zakładają również, że niektóre wdrożenia korzystają z generatywnej AI, optymalizacji lub usług rekomendacyjnych. Wdrożenie prywatne, dedykowane dla jednego klienta lub lokalne może wymagać innego zestawu dowodów.

Szacunki

Na podstawie przywołanych standardów nie można obliczyć prawdopodobieństwa naruszenia, uniwersalnego wyniku bezpieczeństwa ani powszechnie bezpiecznego okresu retencji. Cele odtwarzania, okresy retencji i czas przechowywania logów należy określić w kontekście potrzeb kupującego.

Zalecenia

Traktuj izolację jako kontrolę obowiązkową; dokumentuj cykle życia danych; testuj granice uprawnień; wymagaj eksportowalnych logów; i uwzględniaj zaakceptowane zobowiązania w umowie. Są to zalecenia, a nie ustalenia, że każda organizacja musi wdrożyć identyczne rozwiązania.

Gdzie zatwierdzenie przez odpowiedzialną osobę pozostaje obowiązkowe

Bezpieczeństwo negocjacji AI to kwestia zarządzania, a nie wynik automatycznego kwestionariusza. Odpowiedzialne osoby muszą zdecydować:

• Czy platforma może przetwarzać informacje objęte tajemnicą zawodową, regulacjami, kontrolą eksportu lub o wysokim stopniu poufności
• Czy raporty poświadczające bezpieczeństwo obejmują zakupiony produkt, funkcje, region i podwykonawców przetwarzania
• Które okresy retencji i wyjątki dotyczące blokady prawnej są akceptowalne
• Czy klucze zarządzane przez dostawcę lub współdzielona infrastruktura powodują akceptowalne ryzyko rezydualne
• Kto może zatwierdzać uprzywilejowany i awaryjny dostęp pracowników wsparcia
• Czy uzasadniony jest wyjątek od rozdzielenia obowiązków
• Czy rekomendacje AI mogą wspierać, ale nigdy autoryzować, istotne ceny, warunki, wybór dostawcy lub zobowiązania
• Czy incydent wymaga powiadomienia kierownictwa, klientów, działu prawnego lub organów regulacyjnych
• Kto akceptuje każdy nierozwiązany wyjątek umowny lub techniczny

Narzędzia bezpieczeństwa mogą gromadzić dowody i wskazywać luki. Nie mogą przejąć odpowiedzialności za akceptację ryzyka.

Ograniczenia tych ram

Ta lista kontrolna nie jest metodą certyfikacji. Zewnętrzne audyty mają ograniczony zakres i okres objęty przeglądem. Testy penetracyjne dostarczają dowodów dotyczących konkretnego momentu. Szyfrowanie nie zapobiega nadużyciom ze strony upoważnionych osób ani przejęciu punktów końcowych. Logi są przydatne tylko wtedy, gdy rejestrują ważne zdarzenia i są analizowane. Usunięcie danych z aktywnego systemu nie oznacza natychmiastowego zniszczenia niezmiennych kopii zapasowych.

Wymagania różnią się również w zależności od jurysdykcji, sektora, kategorii danych, modelu hostingu i relacji administrator–podmiot przetwarzający. Środowiska podlegające ścisłym regulacjom lub wymogom bezpieczeństwa narodowego mogą wymagać kontroli wykraczających poza zakres tego artykułu. Z kolei pytania dotyczące izolacji tenantów mogą mieć mniejsze znaczenie w przypadku rzeczywiście dedykowanej instalacji, choć nadal należy ocenić izolację środowisk, administratorów i sieci.

FAQ

Czy raport SOC wystarczy, aby zatwierdzić bezpieczeństwo platformy negocjacyjnej?

Nie. Może dostarczyć cennych, niezależnych zapewnień, ale kupujący powinni sprawdzić okres objęty raportem, jego zakres, wyjątki, podwykonawców przetwarzania, funkcje produktu i regiony wdrożenia. Nadal potrzebne są dowody dotyczące architektury, konfiguracji i testów konkretnego produktu.

Czy dane negocjacyjne powinny być wykorzystywane do trenowania modelu AI?

Tylko wtedy, gdy takie wykorzystanie jest w pełni zrozumiałe i zatwierdzone. Zapytaj, czy prompty, załączniki, wyniki, informacje zwrotne lub dane pochodne wspierają trenowanie modeli albo ulepszanie produktu. Wymagaj wiążących zapisów w tej sprawie i, w stosownych przypadkach, uzyskaj zgodę osób odpowiedzialnych za prywatność, bezpieczeństwo, kwestie prawne i działalność biznesową.

Jaka jest najważniejsza kontrola bezpieczeństwa negocjacji AI?

Nie ma jednej uniwersalnej kontroli. Izolacja tenantów ma podstawowe znaczenie w wielodostępnych usługach SaaS, ale słabe uprawnienia, niejasna retencja, niedostępne logi lub niekontrolowani podwykonawcy przetwarzania mogą niezależnie powodować niedopuszczalne ryzyko. Traktuj kontrole obowiązkowe jako warunki brzegowe, a nie elementy, które można wymieniać na punkty w ocenie.

Jak kupujący powinni postąpić, jeśli dostawca nie może ujawnić szczegółowych wyników testów?

Poproś o alternatywne dowody: zredagowany raport dla kierownictwa, poświadczenie audytora, kontrolowany przegląd, demonstrację konfiguracji na żywo lub umowne zobowiązanie do usunięcia problemów. Zapisz, co pozostaje nieznane. O tym, czy takie ryzyko rezydualne jest akceptowalne, musi zdecydować osoba odpowiedzialna za ryzyko po stronie kupującego, a nie dostawca.

Dalsza lektura

• NIST Cybersecurity Framework 2.0
• NIST SP 800-53: Security and Privacy Controls
• CISA: Principles and Approaches for Security-by-Design and Default
• Wytyczne FTC dotyczące cyberbezpieczeństwa dostawców

Zastrzeżenie: Ten artykuł zawiera ogólne informacje dotyczące zakupów i bezpieczeństwa; nie stanowi porady prawnej, dotyczącej prywatności, cyberbezpieczeństwa ani finansów.