vendor risk
Co poprosić od vendora AI przed podpisaniem umowy
To nie jest porada prawna. To memo decyzyjne o systemach, danych, ryzyku wdrożeniowym i pytaniach, które warto zabrać do zarządu, prawnika albo dostawcy.
Krótka odpowiedź
Przed podpisaniem umowy z vendorem AI trzeba poprosić o materiały, które pokazują nie tylko funkcję, ale granice systemu: dane, ograniczenia, review, monitoring, fallback, eksport i koszt utrzymania. W AI vendor risk największe straty często wynikają z zależności, których nie widać w demo.
Dobra lista pytań nie służy do blokowania zakupu. Służy do rozróżnienia: kupić teraz, kupić po pilocie, renegocjować warunki, ograniczyć zakres albo zatrzymać projekt.
Kiedy to ma znaczenie
To memo jest przydatne, gdy vendor obiecuje automatyzację dokumentów, obsługi klienta, analityki, scoringu, generowania treści, agentów lub integrację z danymi firmy. Im bliżej system jest decyzji, danych osobowych lub krytycznego workflow, tym mniej wystarcza samo demo.
Test decyzyjny
| Obszar | Pytanie do vendora | Co powinna zobaczyć firma |
|---|---|---|
| Dane | Jakie dane system czyta, zapisuje, przechowuje i wysyła dalej? | Data flow, retencja, regiony, subprocessors, masking. |
| Output | Kto zatwierdza wynik i co dzieje się przy błędzie? | Human review, fallback, logi, tryb zatrzymania. |
| Jakość | Jak mierzona jest skuteczność i jak monitoruje się pogorszenie? | Evals, metryki, przykłady błędów, monitoring. |
| Zależność | Jak wyjść z systemu albo zmienić model/dostawcę? | Export path, API limits, contract exit, format danych. |
| Koszt | Co zmienia się przy większym wolumenie? | Cennik operacyjny, koszt inference, support, SLA. |
Dowody do zebrania
- Dokumentacja system boundary i data flow.
- Instrukcje użycia, ograniczenia modelu i warunki bezpiecznego zastosowania.
- Przykłady outputów, błędów, edge cases i reakcji supportu.
- Dane o monitoringu, logach, human review i incident path.
- Warunki eksportu danych, przeniesienia konfiguracji i zamknięcia usługi.
- Odpowiedzialność za zmiany modelu, region danych, podprocesorów i koszty.
Czerwone flagi
- Vendor mówi, że dane są “bezpieczne”, ale nie pokazuje przepływu danych.
- Brakuje ścieżki eksportu albo opis brzmi jak ręczne wsparcie po wypowiedzeniu umowy.
- Nie ma rozdzielenia między model accuracy, workflow accuracy i business outcome.
- Vendor unika rozmowy o edge cases, fallbacku i znanych ograniczeniach.
- Koszty rosną wraz z wolumenem, ale nie ma symulacji przy realnym użyciu.
Czego nie wyciągać jako wniosku
Brak pełnej odpowiedzi vendora nie zawsze oznacza zły produkt. Może oznaczać, że zakup powinien zacząć się od ograniczonego pilota z jasnymi warunkami stop/go, a nie od pełnego rollout’u.