Checklista diligence vendora AI

Krótka odpowiedź

Ta checklista pomaga oddzielić realny system AI od prezentacji sprzedażowej. Nie ocenia, czy vendor jest “dobry”; pokazuje, jakie dowody trzeba zobaczyć przed podpisaniem umowy, pilotażem albo wpisaniem claimu AI do tezy inwestycyjnej.

Najważniejsze pytanie brzmi: co stanie się z danymi, procesem i odpowiedzialnością, jeśli system zacznie działać na prawdziwym wolumenie, a nie w demo?

Jak użyć szablonu

1. Zbierz odpowiedzi vendora na piśmie, nie tylko z rozmowy sprzedażowej.
2. Oznacz każdy obszar jako: potwierdzony, warunkowy, niejasny albo ryzykowny.
3. Wróć do pytań, które dotyczą danych, review człowieka, loggingu i kosztu utrzymania.
4. Nie podpisuj zakresu produkcyjnego, jeśli vendor nie potrafi opisać granic systemu.

Obszar	Pytanie do vendora	Dowód, którego warto poprosić
Dane wejściowe	Jakie dane system przyjmuje i gdzie są przetwarzane?	Opis przepływu danych, retencja, role dostępu.
Output	Co system zwraca i kto zatwierdza wynik?	Próbki outputów, ekrany review, ścieżka eskalacji.
Monitoring	Jak wykrywane są błędy i drift jakości?	Logi, alerty, metryki jakości, procedura incidentów.
Vendor lock-in	Jak wygląda eksport danych i wyjście z usługi?	Format eksportu, warunki umowy, zależności API.
Granice claimu	Czego system nie robi i kiedy wymaga człowieka?	Lista ograniczeń, fallback, przykłady błędów brzegowych.

Czerwone flagi

• Vendor odpowiada tylko językiem marketingowym i nie pokazuje śladu działania systemu.
• Demo działa na danych dobranych przez vendora, bez próbki z realnego procesu.
• Brakuje jasnego właściciela błędu: vendor, klient, użytkownik albo reviewer.
• Nie ma odpowiedzi na pytanie, gdzie przechowywane są dane i kto może je zobaczyć.
• Koszt po pilotażu zależy od zmiennych, których vendor nie potrafi policzyć.

Następny krok

Jeśli kilka pól zostaje niejasnych, nie przechodź od razu do wdrożenia. Najpierw zrób krótkie diligence AI: granice systemu, dane, vendor risk, output i warunki kontrolowanego pilota.