Jak wybrać firmę wdrażającą AI: 12 pytań

1. Jaki problem biznesowy rozwiązujemy?

Dobra odpowiedź opisuje obecny proces, koszt, właściciela i oczekiwaną zmianę. Słaba odpowiedź zaczyna się od nazw modeli oraz listy funkcji. Dostawca powinien umieć powiedzieć, kiedy AI nie jest potrzebne. Czasem prosty formularz, reguła lub integracja daje lepszy wynik.

2. Jak zmierzymy wynik bazowy i wynik po wdrożeniu?

Bez pomiaru bazowego każda oszczędność staje się opinią. Ustal czas pracy, liczbę spraw, błędy, przychód, konwersję lub czas cyklu. Wskaźnik zależy od procesu. Model może mieć wysoką trafność techniczną i nadal nie zmienić wyniku firmy.

3. Które dane są potrzebne i skąd pochodzą?

Poproś o mapę źródeł, właścicieli i retencji. Dostawca powinien wskazać dane wrażliwe, sposób ograniczenia dostępu oraz zasady użycia danych przez podwykonawców. Pytanie o dane zadane dopiero po podpisaniu umowy jest sygnałem złej diagnozy.

4. Co się dzieje, gdy model nie wie?

Odpowiedź powinna zawierać próg, eskalację, bezpieczny stan oraz zapis zdarzenia. System, który zawsze odpowiada, jest trudniejszy do kontrolowania niż system potrafiący zatrzymać akcję. Zapytaj o konflikt źródeł, brak pola, awarię integracji i nietypową prośbę.

5. Jak testujecie jakość przed uruchomieniem?

Szukaj testów na prawdziwych, zanonimizowanych przypadkach oraz osobnego zbioru do oceny. Demo przygotowane przez wykonawcę nic nie mówi o wyjątkach. Kryteria akceptacji powinny być zapisane przed budową, nie po pierwszej prezentacji.

6. Co dokładnie obejmuje cena?

Porównuj zakres, nie samą kwotę. Oferta ma wskazać analizę, projekt, integracje, migrację, testy, szkolenie, dokumentację, utrzymanie i koszty narzędzi. MIDAS pracuje w modelu fixed-price dla uzgodnionego zakresu. Nie oznacza to, że fixed-price zawsze jest lepszy. Wymaga dobrze opisanych granic i sposobu obsługi zmian.

7. Kto odpowiada za integracje i awarie?

System AI działa pomiędzy usługami. Awaria może leżeć w CRM, API, danych, dostawcy modelu lub kodzie integracji. Umowa i architektura powinny wskazać monitoring, reakcję, kopie danych oraz odpowiedzialność za każdy element.

8. Czy będziemy zależni od jednego dostawcy?

Zapytaj, które części można przenieść, w jakim formacie otrzymasz dane i dokumentację oraz kto ma prawa do kodu. Pełna niezależność bywa droga i nie zawsze potrzebna. Zależność powinna być jednak jawna, wyceniona i możliwa do oceny.

9. Jak chronicie dane i uprawnienia?

Minimum to dostęp według roli, osobne środowiska, zarządzanie sekretami, logi, kopie i procedura odebrania dostępu. Agent nie potrzebuje prawa zapisu tylko dlatego, że API je oferuje. Uprawnienia zaczynają się od najmniejszego zakresu.

10. Jak wygląda praca po uruchomieniu?

Modele, dane, procesy i API się zmieniają. Ustal właściciela po stronie firmy, zakres monitoringu, częstotliwość przeglądów i sposób zgłaszania zmian. Projekt bez planu utrzymania kończy się systemem, którego nikt nie chce dotknąć.

11. Jakie macie dowody z podobnej pracy?

Proś o publiczny opis problemu, zakresu i wyniku. Logo bez kontekstu nie jest dowodem. MIDAS publikuje case Kanaste: 13,000,000 PLN przychodu w 24 miesiące od 100,000 PLN kapitału startowego, oraz SOMA: 700,000 PLN przychodu bez pracowników. Te liczby pokazują doświadczenie operacyjne. Nie gwarantują wyniku nowego projektu.

12. Kiedy przerwiecie projekt?

Dojrzały wykonawca potrafi nazwać warunki stopu: brak danych, niespełniona jakość, zbyt duże ryzyko, brak dostępu lub koszt wyższy od korzyści. Zapytaj, co dostaniesz po zatrzymaniu i jak rozliczony zostanie etap. Gotowość do przerwania złego projektu jest cenniejsza niż pewność sprzedawcy na pierwszej rozmowie.

Jak porównać oferty bez technicznego zespołu

Poproś każdego wykonawcę o jedną stronę z diagramem procesu, zakresem danych, punktami decyzji i odpowiedzialnością. Następnie zaproś osobę, która wykonuje pracę dzisiaj. Powinna rozpoznać własny proces i wskazać brakujące wyjątki. W osobnej tabeli zapisz koszt budowy, koszty miesięczne, pracę po stronie firmy oraz założenia wolumenu. Nie pozwól łączyć opłaty za usługę z hipotetyczną oszczędnością w jedną atrakcyjną liczbę. Poproś o pokazanie wersji systemu po awarii, nie tylko podczas poprawnego scenariusza. Rozmowa o błędach odsłania dojrzałość szybciej niż lista certyfikatów.

Co powinno znaleźć się w umowie i odbiorze

Umowa powinna odsyłać do konkretnego zakresu, kryteriów akceptacji, harmonogramu decyzji i procedury zmian. Zapisz prawa do danych, kodu, konfiguracji oraz materiałów przygotowanych w projekcie. Odbiór obejmuje testy, dokumentację, dostęp administracyjny, instrukcję awaryjną i listę znanych ograniczeń. Ustal, co oznacza błąd, jak jest klasyfikowany i w jakim trybie dostawca reaguje. Jeśli projekt korzysta z usług zewnętrznych, potrzebujesz listy tych usług oraz kosztów. Najtańsza oferta przed podpisaniem może być najdroższa po pierwszej zmianie, gdy granice nie zostały zapisane.

Poproś też o próbny odbiór przed końcem projektu. Twój zespół powinien sam wykonać typową operację, znaleźć log błędu i uruchomić procedurę awaryjną. Jeśli każda czynność wymaga obecności wykonawcy, zależność jest większa niż pokazuje oferta. Ustal koszt oraz termin przekazania systemu innemu zespołowi. To pytanie nie zakłada konfliktu. Sprawdza, czy dokumentacja i własność są realne.

Na koniec sprawdź sposób komunikacji podczas projektu. Potrzebujesz regularnego zapisu decyzji, ryzyk i wykonanej pracy, nie serii prezentacji bez dostępu do wersji roboczej. Zapytaj, kto będzie pracował po podpisaniu umowy oraz ile projektów prowadzi ten zespół. Osoba sprzedająca może nie uczestniczyć w budowie. Im wcześniej poznasz odpowiedzialnych ludzi, tym łatwiej ocenisz tempo decyzji i jakość współpracy.

Wyślij te same 12 pytań każdemu dostawcy i oceniaj odpowiedzi w jednym arkuszu. Najlepsza firma nie musi mieć najdłuższej prezentacji. Powinna najwcześniej odkryć ryzyko, którego inni nie zauważyli. Przed rozmową przeczytaj ile kosztuje wdrożenie AI i od czego zacząć wdrożenie AI. Zakres MIDAS opisuje strona wdrożenia agentów AI.

Jak utrzymać wynik po wdrożeniu

Właściciel procesu powinien raz w miesiącu przejrzeć losową próbkę wyników, wszystkie eskalacje oraz koszt wykonania jednej sprawy. Zmiana modelu, instrukcji, formularza albo źródła danych uruchamia ponowny zestaw testów. Każda poprawka dostaje datę, autora, powód i wynik porównania z poprzednią wersją. Dzięki temu zespół rozwija system na podstawie danych, a nie pamięci o kilku udanych przypadkach.

Plan awaryjny jest częścią produktu. Opisuje ręczne obejście, osobę dyżurną, kanał zgłoszeń i warunek wyłączenia automatyzacji. Po incydencie zespół sprawdza źródło błędu, liczbę dotkniętych spraw i sposób naprawy. Dopiero wtedy wraca większy wolumen. Taki rytm chroni klienta, dane oraz wynik biznesowy, gdy integracja lub model zachowuje się inaczej niż w testach.