Znam kilka firm, które zapłaciły setki tysięcy złotych za system AI, który ostatecznie trafił do szuflady. Za każdym razem ten sam wzorzec. Zapytanie ofertowe zostało napisane według szablonu z poprzedniego projektu IT. Dostawcy wypełnili checkboxy. Zarząd wybrał najtańszą ofertę. Po sześciu miesiącach okazało się, że system robi coś zupełnie innego, niż myśleliśmy, a jego „dokładność” na naszych danych jest dramatycznie niższa niż na slajdach.
Ten artykuł jest dla Ciebie, jeśli Twoja firma dopiero zaczyna myśleć o pierwszym kontrakcie na system AI. Pokażę, dlaczego klasyczny RFP nie działa dla AI, co musi się w nim dodatkowo znaleźć i na jakie sygnały patrzeć w odpowiedziach dostawców. Jeśli chcesz zobaczyć szerszy kontekst zakupowy, od diagnozy gotowości po skalowanie, zajrzyj do przewodnika o transformacji biznesowej i wdrażaniu AI.
Dlaczego RFP na AI jest inny niż na tradycyjne IT
Klasyczne zapytanie ofertowe wyrosło w świecie, w którym oprogramowanie robi to, co jest w specyfikacji. Faktura idzie z punktu A do punktu B. Przycisk „zapisz” zapisuje. Testujesz, odbierasz, wdrażasz. Systemy AI działają inaczej. Są z natury probabilistyczne, co oznacza, że ten sam system, na tych samych danych, może w dwóch różnych dniach dawać różne wyniki. A to przekłada się bezpośrednio na kształt dokumentu zakupowego.
Są trzy rzeczy, których nie znajdziesz w tradycyjnym RFP, a które muszą trafić do RFP na AI.
- PoC na danych produkcyjnych jako warunek kontraktu. Nie demo na danych dostawcy. Twoje dane, Twoje przypadki brzegowe, zdefiniowane Go/No-Go przed startem.
- SLA na dokładność modelu, nie tylko dostępność. System może być „up” w 99,9% czasu i jednocześnie działać z dramatycznie spadającą precyzją. Bez wpisanej w kontrakt dokładności nie masz dźwigni.
- Polityka treningu modelu. Czy Twoje dane będą używane do trenowania modelu, z którego potem skorzysta Twoja konkurencja? To pytanie trzeba zadać wprost, bo domyślnie odpowiedź brzmi „tak”.
Każda z tych trzech rzeczy wykracza poza standardowy szablon IT. I każda, pominięta, może się zemścić w sposób, który kosztuje więcej niż całe wdrożenie.
Zanim napiszesz RFP: diagnoza i use case
Największy błąd firm wdrażających AI po raz pierwszy to napisanie zapytania ofertowego za wcześnie. Zanim w ogóle zaczniesz formułować wymagania, musisz wiedzieć o sobie samym kilka rzeczy. Według analiz Gartnera i praktyków AI 63% organizacji nie dysponuje danymi, które są gotowe do użycia przez AI. Jeżeli Twoja firma jest w tej grupie, żaden dostawca Ci tego nie powie w ofercie.
Drugi błąd to pisanie zapytania na „AI dla całej firmy”. Dostawcy potraktują to jako zaproszenie do sprzedania swojego najdroższego pakietu. Zamiast tego wybierz jeden konkretny use case, który spełnia pięć warunków: ma mierzalny baseline KPI (czas, koszt, liczba), jest powtarzalny i wolumenowy, ma dostępne dane produkcyjne, ma właściciela z mandatem do zmiany sposobu pracy, a jego compliance da się ogarnąć na etapie pilotażu.
Konkret dobrego use case’u: automatyczna kategoryzacja zgłoszeń do biura obsługi klienta. Mierzalny KPI to średni czas obsługi. Dane to historia zgłoszeń. Właściciel to kierownik działu CS. Zły use case brzmi tak: „chcemy asystenta AI dla całej firmy”. Brak problemu, brak KPI, brak właściciela, brak szans na powodzenie.
Co musi się znaleźć w RFP na AI
Dobre RFP na system AI ma siedem sekcji, ale zamiast opisywać każdą z osobna (zrobili to już dziesiątki poradników), pokażę Ci sześć rzeczy, które decydują o tym, czy dostaniesz użyteczne oferty, czy stertę marketingu.
Rozróżnij AI-assisted i AI-automated
System, który rekomenduje decyzję do akceptacji człowieka, wymaga innej architektury, innych SLA i innej polityki danych niż system, który samodzielnie tę decyzję podejmuje. To rozróżnienie powinno być na pierwszej stronie Twojego RFP. Bez niego dostawcy wyceniają różne rzeczy, a Ty nie masz jak porównać ofert.
Rozdziel must-have od nice-to-have
Najczęstszy grzech RFP to lista 120 wymagań, wszystkie oznaczone jako konieczne. Dla dostawcy oznacza to, że żadne nie jest konieczne. Podziel je brutalnie: must-have (bez tego kontraktu nie ma) i nice-to-have (zyski przy równych warunkach). Rzadko pomaga więcej niż 10-15 punktów must-have.
Zadaj twarde pytania o dane i model
To sekcja, którą firmy wdrażające AI po raz pierwszy traktują skrótowo i tego żałują. Wymagaj konkretów, nie deklaracji „jesteśmy GDPR-compliant”.
- Gdzie fizycznie przechowywane są dane? Czy mogę wybrać region UE?
- Jak długo dostawca przechowuje moje dane i co się z nimi dzieje po zakończeniu umowy?
- Czy moje dane są wykorzystywane do trenowania modelu? Czy można to wyłączyć zapisem w umowie?
- Kto jest subprocesorem (podwykonawcą) i gdzie przetwarza dane?
- Czy dostawca podpisuje DPA (umowę powierzenia przetwarzania)?
- Jakie posiada certyfikaty: SOC 2, ISO 27001?
Wymagaj wyjaśnialności
Jeśli system AI wpływa na decyzje dotyczące klientów, pracowników albo finansów, musisz wiedzieć, dlaczego podejmuje taką a nie inną decyzję. To nie jest tylko wymóg etyczny. EU AI Act dla systemów wysokiego ryzyka nakłada obowiązek dokumentacji, śladu audytowego i możliwości wyjaśnienia decyzji. Zapytaj o ślad audytowy, wyjaśnienia w języku naturalnym, poziom zaufania (confidence score) i mechanizm ludzkiej korekty. Jeżeli dostawca nie umie odpowiedzieć na te pytania, jest za wcześnie na kontrakt z nim.
Zakontraktuj dokładność, nie tylko dostępność
Standardowe SLA (99,9% uptime) są warunkiem koniecznym, ale niewystarczającym. Dla AI potrzebujesz dodatkowych metryk: minimalnej akceptowalnej precyzji na Twoich danych, maksymalnego czasu odpowiedzi, czasu reakcji na incydent spadku dokładności oraz monitoringu zjawiska „model drift” (degradacji jakości w czasie). I jedno twarde pytanie: jakie są kary umowne za niedotrzymanie SLA dotyczących dokładności? Tradycyjni dostawcy IT często odmawiają wpisania takich metryk. To jest sygnał, nie przeszkoda w negocjacjach.
Policz TCO na trzy lata
Koszty tokenów w systemach opartych na modelach językowych stanowią tylko 20-35% rzeczywistego kosztu całkowitego. Pozostałe 65-80% to infrastruktura, integracje, szkolenia i governance. Poproś każdego dostawcę o wypełnienie jednego wspólnego szablonu TCO na 36 miesięcy: koszty jednorazowe (implementacja, migracja, szkolenia), koszty operacyjne (subskrypcja, API, wsparcie) i koszty skalowania (dodatkowi użytkownicy, transakcje). Bez wspólnego szablonu nie da się porównać ofert.
Czerwone flagi w ofertach dostawców
Kiedy zaczynasz czytać odpowiedzi na RFP, kilka sygnałów powinno zapalić Ci lampkę ostrzegawczą. Z mojego doświadczenia te się pojawiają najczęściej.
- Obietnica pełnej automatyzacji bez opisu nadzoru ludzkiego i obsługi wyjątków.
- Brak referencji z podobnego sektora lub niechęć do udostępnienia kontaktu do klienta referencyjnego.
- Odmowa przeprowadzenia PoC na Twoich danych (dostawca proponuje tylko demo na swoich).
- Oświadczenie „jesteśmy GDPR-compliant” bez szczegółów o lokalizacji przetwarzania i subprocesorach.
- Brak odpowiedzi na pytania o model drift i procedurę przy spadku dokładności.
- Model rozliczenia z ukrytymi progami (opłaty za przekroczenie wolumenu bez limitu w umowie).
- Niechęć do kontraktowego zapisania SLA na dokładność modelu.
Żadna z tych flag nie dyskwalifikuje automatycznie. Ale jeśli widzisz dwie lub trzy na raz w jednej ofercie, dalsze rozmowy to strata czasu, bo kontrakt z takim dostawcą będzie później równie trudny jak wybór w ciemno.
Od diagnozy do kontraktu: dziesięć kroków procesu
Samo RFP to fragment procesu zakupowego. Oto dziesięć kroków, które od lat powtarzają się w dobrze prowadzonych projektach zakupu AI, niezależnie od branży.
- Audyt gotowości (dane, procesy, kompetencje, kultura).
- Wybór jednego konkretnego use case’u z mierzalnym KPI.
- Opcjonalne RFI do 10-15 firm, żeby zbudować shortlistę.
- Pisanie dokumentu wg struktury opisanej wyżej.
- Wysyłka do 4-7 dostawców, termin minimum 2-3 tygodnie.
- Sesja Q&A z publicznymi odpowiedziami dla wszystkich uczestników.
- Ocena ofert według wcześniej zdefiniowanych wag.
- Shortlista 2-3 dostawców do PoC.
- PoC na danych produkcyjnych, 4-8 tygodni, kryteria Go/No-Go zdefiniowane zawczasu.
- Negocjacje i kontrakt z zapisanymi SLA, polityką danych i warunkami exit.
Jeżeli siedzisz dziś nad pierwszym RFP na AI i masz poczucie, że zbyt wiele tu zmiennych, to masz rację. Pierwszy projekt AI jest zawsze trochę nauką. Ale różnica między firmą, która napisze zapytanie według szablonu z 2018 roku, a firmą, która dorzuci PoC, SLA na dokładność i politykę danych, nie polega na szlifie. Polega na tym, czy w ogóle wróci kiedyś do tego dostawcy, czy po roku będzie szukała drugiego, bo pierwszego się nie da rozsądnie wypiąć.
Jeśli chcesz przejść przez cały proces zakupowy AI z pozycji managera, a nie tylko zebrać wymagania do dokumentu, zobacz pełny program w kursie Future Leaders: AI dla Liderów. Dobry kontrakt to dopiero początek. Później jest wdrożenie, change management i skalowanie, a każdy z tych etapów ma własny zestaw pułapek.
