# Vendor Due Diligence w AI: pytania, których firmy nie zadają
Ten artykuł to krok 1/3 procesu zakupowego AI: ocena vendora. Krok 2 (klauzule kontraktowe) opisuje `governance-ai-procurement-contract-clauses`, a krok 3 (bramki procesowe) `governance-ai-procurement-controls`.
Zakup rozwiązania AI nie przypomina klasycznego zakupu SaaS. W tradycyjnym narzędziu zwykle pytamy o bezpieczeństwo, dostępność, wsparcie i koszt. W AI trzeba dodatkowo zapytać o zachowanie modelu, jakość procesu uczenia, granice użycia danych, sposób aktualizacji i odpowiedzialność za skutki błędu. Jeśli te pytania nie padną przed podpisaniem umowy, firma kupuje nie tylko funkcję, ale również trudne do oszacowania ryzyko.
To jest sedno vendor due diligence dla AI: nie sprawdzamy wyłącznie dostawcy jako firmy. Sprawdzamy także, czy jego model operacyjny, techniczny i kontraktowy da się bezpiecznie osadzić w naszym procesie biznesowym. Procurement i legal są tu kluczowe, bo to one przekładają ambicję biznesową na warunki, które można egzekwować.
Centralna teza tego playbooka jest prosta: w AI due diligence musi obejmować dane, model, bezpieczeństwo, audytowalność, odpowiedzialność, subprocesorów i plan wyjścia, a nie tylko checklistę security i cenę licencji. Tylko wtedy organizacja może skalować użycie AI bez narastającego ryzyka operacyjnego i prawnego.
Dlaczego klasyczny proces zakupowy nie wystarcza
Wiele organizacji uruchamia AI przez szybkie pilotaże, a formalny procurement włącza później. To działa do momentu, gdy rozwiązanie ma wejść do procesu produkcyjnego, wpływać na decyzje wobec klienta lub pracownika, albo przetwarzać dane wrażliwe. Wtedy zaczynają się pytania, których nikt wcześniej nie przygotował.
Czy dostawca wykorzystuje nasze dane do dalszego trenowania modeli? Jak zarządza wersjami modelu i zmianami zachowania? Czy możemy odtworzyć, dlaczego system wygenerował daną odpowiedź? Kto odpowiada, jeśli błędna rekomendacja spowoduje stratę finansową? Jak szybko dostawca zgłosi incydent bezpieczeństwa? Czy wiemy, którzy subprocesorzy mają dostęp do danych i w jakiej jurysdykcji pracują?
Te pytania nie są "dodatkowe". To podstawowe warunki zarządzania ryzykiem. Zgodnie z podejściem NIST AI RMF zarządzanie ryzykiem AI powinno obejmować cały cykl życia systemu: od wyboru i wdrożenia po monitorowanie i zmiany. OECD AI Principles podkreślają transparentność, accountability i robust security jako warunki zaufanego użycia AI. AI Act dodatkowo przesuwa ciężar na wykazanie zgodności i kontrolę łańcucha dostaw dla systemów o wyższym ryzyku.
procurement i legal muszą stać się częścią governance AI. Jeśli nie wejdą wcześnie, firma szybko dojdzie do punktu, w którym technicznie "da się wdrożyć", ale kontraktowo i regulacyjnie nie da się tego obronić.
Kiedy uruchamiać AI Vendor Due Diligence
Playbook due diligence nie jest potrzebny dla każdego eksperymentu w tej samej skali. Powinien uruchamiać się obowiązkowo, gdy spełniony jest co najmniej jeden warunek: rozwiązanie ma wejść do produkcji, dotyczy danych poufnych lub osobowych, wpływa na decyzje biznesowe wobec klientów/pracowników, integruje się z krytycznym procesem lub będzie skalowane na wiele jednostek organizacji.
Dla niskiego ryzyka można stosować krótszą ścieżkę. Dla średniego i wysokiego ryzyka potrzebna jest pełna ocena: bezpieczeństwo, prywatność, model behavior, kontrakt, SLA, subprocesorzy, exit plan i mechanizmy audytu. Kluczowe jest rozróżnienie ścieżek, a nie jeden ciężki proces dla wszystkiego.
Praktyczna zasada: jeśli błąd modelu może wpłynąć na decyzję wobec osoby, finansów lub reputacji firmy, due diligence musi być pełne i udokumentowane. Jeśli użycie jest wewnętrzne i pomocnicze, proces może być lżejszy, ale nadal musi obejmować minimum bezpieczeństwa danych, warunki użycia i odpowiedzialność.
Framework 8 Obszarów AI Vendor Due Diligence
Najbardziej użyteczna struktura dla procurement i legal to osiem obszarów pytań. Każdy obszar kończy się decyzją: akceptacja, warunkowa akceptacja, renegocjacja, odrzucenie albo pilot z ograniczeniami.
### 1) Dane Treningowe i Dane Klienta
Trzeba ustalić, jakie dane były użyte do trenowania modelu, jakie ograniczenia licencyjne lub prawne mogą dotyczyć tych danych, oraz czy dane klienta są wykorzystywane do dalszego uczenia. W umowie powinno być jasno zapisane: cel przetwarzania, retencja, izolacja tenantów, możliwość usunięcia danych i zakaz wtórnego użycia bez zgody.
Pytania kontrolne: - Czy nasze dane będą użyte do trenowania modeli bazowych lub pochodnych? - Jak wygląda retencja promptów, logów i outputów? - Czy dostawca zapewnia pełne usunięcie danych po zakończeniu umowy?
### 2) Bezpieczeństwo i Odporność Operacyjna
Klasyczny security review trzeba rozszerzyć o zagrożenia specyficzne dla AI: prompt injection, data leakage przez kontekst, nadużycia uprawnień modelu, brak separacji środowisk i ryzyko łańcucha dostaw. Sam certyfikat bezpieczeństwa nie wystarcza bez praktyk operacyjnych i jasnej odpowiedzialności za incydenty.
Pytania kontrolne: - Jakie kontrole chronią przed wyciekiem danych przez input/output? - Jak wygląda proces wykrywania i raportowania incydentów? - Jakie są gwarantowane czasy reakcji i naprawy?
### 3) Audytowalność i Wyjaśnialność Decyzji
Dostawca powinien umożliwiać audyt: logi zdarzeń, ślad wersji modelu, zmian promptów/system prompts oraz możliwość odtworzenia kontekstu decyzji. audytowalność jest warunkiem zarządzania sporami, reklamacjami i incydentami.
Pytania kontrolne: - Czy możemy odtworzyć, która wersja modelu wygenerowała dany wynik? - Czy logi zawierają dane wystarczające do wewnętrznego audytu? - Jak długo logi są dostępne i w jakiej formie?
### 4) SLA, SLO i Jakość Usługi
W AI sama dostępność API nie opisuje jakości usługi. Potrzebne są uzgodnienia dotyczące latency, stabilności outputu, limitów kosztowych, eskalacji przy spadku jakości i mechanizmu zmian wersji modelu.
Pytania kontrolne: - Czy SLA obejmuje także parametry jakościowe, a nie tylko uptime? - Jak dostawca komunikuje zmiany modeli i ich wpływ na zachowanie? - Jakie są zasady rollbacku lub fallbacku?
### 5) Odpowiedzialność i Podział Ryzyka
Umowa powinna określać odpowiedzialność za naruszenia bezpieczeństwa, naruszenia praw osób, błędy systemowe, roszczenia IP i szkody wynikające z wadliwego działania. Brak jasnego podziału odpowiedzialności oznacza, że ryzyko zostaje po stronie kupującego.
Pytania kontrolne: - Jakie są limity odpowiedzialności i wyłączenia odpowiedzialności? - Kto odpowiada za roszczenia dotyczące danych treningowych i IP? - Czy istnieje obowiązek współpracy przy postępowaniu audytowym/regulacyjnym?
### 6) Subprocesorzy i Łańcuch Dostaw
wielu dostawców AI opiera się na kolejnych poddostawcach modeli, infrastruktury i narzędzi monitoringu. Trzeba wiedzieć, kto jest w łańcuchu, gdzie przetwarza dane i jakie standardy bezpieczeństwa stosuje.
Pytania kontrolne: - Jaka jest aktualna lista subprocesorów i jak jest aktualizowana? - Czy klient ma prawo sprzeciwu wobec nowych subprocesorów? - W jakich jurysdykcjach odbywa się przetwarzanie?
### 7) Zgodność Regulacyjna i Dokumentacja
AI Act, a także standardy typu ISO/IEC 42001, nie sprowadzają się do jednego checkboxa "compliant". Organizacja potrzebuje dowodów: polityk, procedur, zapisów testów, oceny ryzyka, mechanizmów monitoringu, informacji dla użytkowników i procesów reagowania.
Pytania kontrolne: - Jakie artefakty dokumentacyjne dostawca dostarcza klientowi? - Jak często aktualizowana jest ocena ryzyka systemu? - Czy dostawca wspiera klienta podczas audytów i zapytań regulatora?
### 8) Exit Plan i Portability
Najczęściej pomijany obszar. Organizacja powinna mieć możliwość migracji: danych, konfiguracji, promptów, logów i integracji. Bez tego vendor lock-in rośnie szybciej niż wartość biznesowa.
Pytania kontrolne: - Jak wygląda plan zakończenia usługi i terminy zwrotu/usunięcia danych? - Czy klient może wyeksportować artefakty potrzebne do migracji? - Jakie są koszty i ograniczenia wyjścia?
Realistyczny scenariusz: szybki pilotaż, wolne skalowanie
Firma usługowa uruchamia pilotaż asystenta AI dla działu obsługi klienta. Wyniki po miesiącu wyglądają dobrze: krótszy czas odpowiedzi i wyższa produktywność konsultantów. Biznes naciska na skalowanie. Dopiero wtedy procurement i legal dostają dokumenty dostawcy.
Okazuje się, że retencja logów jest dłuższa niż polityka firmy, lista subprocesorów jest niepełna, a umowa nie daje prawa do audytu ani pełnego eksportu danych przy wyjściu. Dodatkowo vendor planuje zmianę modelu bez twardego obowiązku wcześniejszego powiadomienia. Z perspektywy operacji wszystko "działa", ale ryzyko kontraktowe i regulacyjne jest nieakceptowalne.
Po zastosowaniu pełnego due diligence firma nie rezygnuje z projektu. Renegocjuje warunki: krótsza retencja, obowiązkowe notyfikacje zmian modelu, prawo audytu, precyzyjny incident SLA, pełna lista subprocesorów i zapisany plan migracji. Skalowanie rusza trzy miesiące później, ale na warunkach możliwych do obrony przed audytem i zarządem.
Lekcja jest praktyczna: due diligence nie ma "zabić" pilotażu. Ma zamienić szybki eksperyment w bezpieczny i skalowalny kontrakt operacyjny.
Minimalny proces dla procurement i legal
Skuteczny proces można oprzeć o pięć etapów:
1. **Intake i Klasyfikacja Ryzyka** Określ cel use case'u, typ danych, wpływ na decyzje i klasę ryzyka.
2. **Pakiet Wymagań AI-Specific** Wyślij dostawcy standardowy kwestionariusz 8 obszarów z wymaganymi dowodami.
3. **Ocena Krzyżowa** Procurement, legal, security, risk i właściciel biznesowy wspólnie oceniają odpowiedzi.
4. **Negocjacja Warunków Krytycznych** Wprowadź zapisy dotyczące danych, audytu, SLA, odpowiedzialności, subprocesorów i exit.
5. **Decision Gate i Monitoring Po Kontrakcie** Decyzja: approve / approve with conditions / reject oraz harmonogram przeglądów po wdrożeniu.
Najważniejsze: due diligence nie kończy się na podpisie. W AI dostawca i model zmieniają się w czasie. Konieczne są okresowe przeglądy kontraktu, jakości i ryzyka.
Najczęstsze błędy
Pierwszy błąd to traktowanie AI jak zwykłego SaaS. Drugi to pytanie wyłącznie o certyfikaty bez pytania o praktyki operacyjne. Trzeci to brak wspólnej ścieżki procurement-legal-security-risk, co prowadzi do sprzecznych decyzji.
Czwarty błąd to brak zapisów o zmianach modelu i ich wpływie na usługę. Piąty to nieuwzględnienie subprocesorów. Szósty to brak exit planu i testu przenaszalności. Siódmy to uruchamianie skalowania przed domknięciem warunków kontraktowych.
Każdy z tych błędów jest naprawialny, ale po wdrożeniu koszt naprawy rośnie. Dlatego due diligence powinno działać jako stage gate przed produkcją, nie jako audyt po incydencie.
Co zrobić teraz
Jeśli organizacja nie ma jeszcze AI vendor due diligence, zarząd powinien zacząć od jednej wspólnej checklisty 8 obszarów i prostego podziału ról: procurement prowadzi proces, legal negocjuje odpowiedzialność i warunki danych, security/risk ocenia kontrole, a business owner odpowiada za akceptację trade-offów.
Następnie trzeba połączyć tę checklistę z procesem zakupowym i governance AI: bez pozytywnej oceny nie ma przejścia do produkcji. Dla istniejących dostawców warto uruchomić retrospective review, zaczynając od systemów o najwyższym wpływie na klientów, pracowników i decyzje finansowe.
Wreszcie, zarząd powinien wprowadzić obowiązkowy przegląd roczny dla kluczowych vendorów AI: aktualizacja subprocesorów, zmiany modeli, incydenty, poziom SLA, status zgodności i gotowość exit planu. To najprostszy sposób, by utrzymać kontrolę nad ryzykiem przy rosnącej skali użycia.
Executive Takeaway
Co się zmieniło? Zakup AI przestał być zakupem wyłącznie funkcji technologicznej. To zakup zachowania modelu, łańcucha dostaw, ryzyka regulacyjnego i odpowiedzialności kontraktowej.
Dlaczego to ważne? Bez AI-specific due diligence organizacje skalują szybciej tylko pozornie. rośnie ekspozycja na incydenty, spory prawne, vendor lock-in i koszty naprawy po wdrożeniu.
Co liderzy powinni zrobić? Wdrożyć wspólny playbook procurement/legal oparty o 8 obszarów: dane, bezpieczeństwo, audytowalność, SLA, odpowiedzialność, subprocesorzy, zgodność i exit plan; a następnie powiązać go z decyzją stage gate przed produkcją.
