Metodyka wdrożenia AI

Cztery fazy, konkretny rezultat na koniec każdej z nich i jasny podział decyzji. Łącznie z tym, czego większość stron nie pisze: w jakich sytuacjach powiemy, że nie warto zaczynać.

Cztery fazy

Każda faza kończy się dokumentem i decyzją, czy przechodzimy dalej. To nie jest formalność — projekt może się skończyć po fazie pierwszej albo drugiej i jest to przewidziany wynik, a nie zerwana współpraca. Poniższy podział dotyczywdrożenia AI w firmie niezależnie od tego, czy chodzi o automatyzację procesu, asystenta dla zespołu czy integrację z istniejącym systemem.

FazaCo powstaje
1–2 tyg.Audyt i wybór procesuLista procesów kandydujących z oszacowaniem czasu i kosztu, wskazanie jednego procesu na początek wraz z uzasadnieniem, oraz mierzalne kryteria sukcesu ustalone przed budową czegokolwiek.
2–4 tyg.PilotażDziałające rozwiązanie na Twoich prawdziwych danych, nie na przykładowych, oraz pomiar względem kryteriów z fazy pierwszej. Tu zapada decyzja „produkcja albo koniec”.
4–12 tyg.Wdrożenie produkcyjneIntegracja z systemami, obsługa przypadków brzegowych i błędów, logowanie i monitorowanie jakości, dokumentacja techniczna oraz ścieżka zgłaszania problemów.
ciągłePrzekazanie i rozwójSzkolenie zespołu, przekazanie kodu i dokumentacji, ustalenie kto i po czym pozna, że coś przestało działać, oraz plan kolejnych procesów oparty już na danych z tego wdrożenia.

Terminy są orientacyjne i najczęściej wydłużają je nie prace inżynierskie, tylko dostęp do danych i decyzje po stronie klienta. Co realnie napędza koszt, rozkładamy na czynniki w tekście o tym,ile kosztuje wdrożenie AI.

Kto o czym decyduje

Większość projektów, które grzęzną, grzęźnie nie na technologii, tylko na tym, że nikt nie ma prawa rozstrzygnąć sporu o to, jak proces ma wyglądać po zmianie. Dlatego podział ustalamy na starcie:

  • Właściciel procesu (po Twojej stronie) — decyduje, jak proces ma działać, co jest błędem, a co dopuszczalnym wyjątkiem, i akceptuje wynik pilotażu. To jedna konkretna osoba, nie komitet.
  • My — projektujemy rozwiązanie i rekomendujemy model, architekturę oraz sposób obsługi błędów. Wybór dostawcy modelu zatwierdzasz Ty, bo jest on jednocześnie wyborem dalszego podmiotu przetwarzającego. Odpowiadamy za to, że system robi to, co uzgodniliśmy, i że da się go utrzymać po naszym odejściu.
  • Wspólnie — kryteria sukcesu, zakres pilotażu, decyzja o przejściu do produkcji i decyzja o zatrzymaniu projektu. Żadnej z tych czterech nie podejmujemy sami.

Kiedy powiemy, że nie warto

Wdrażanie AI tam, gdzie problem nie ma z nią nic wspólnego, to najprostsza droga do przepalenia budżetu. Poniższe warunki sprawdzamy w fazie pierwszej i jeśli któryś jest spełniony, mówimy o tym od razu — zanim wystawimy fakturę za budowę.

  • Proces nie jest ustabilizowany. Jeśli pięć osób wykonuje go na pięć sposobów i żaden nie jest opisany, nie ma czego automatyzować. Najpierw trzeba uzgodnić proces, a to praca organizacyjna, nie informatyczna.
  • Dane nie istnieją albo są nieosiągalne. Historia decyzji w cudzej głowie, w załącznikach do maili albo w systemie bez API to nie są dane, na których da się oprzeć wdrożenie w rozsądnym budżecie.
  • Oszczędność nie pokrywa utrzymania. Każdy system AI ma koszt stały: model, monitorowanie, poprawki. Jeśli proces zajmuje dwie godziny miesięcznie, prawie na pewno nie warto — i lepiej usłyszeć to na początku.
  • Nie ma właściciela procesu. Bez osoby, która rozstrzyga, projekt zatrzyma się na pierwszym sporze o to, co jest błędem.
  • Regulacje wykluczają dany scenariusz. Części zastosowań AI Act zakazuje wprost, a część wymaga przygotowania, którego koszt zmienia sens projektu. Sprawdzamy to waudycie gotowości na AI Act, zanim ruszy budowa, a nie po.

W każdym z tych przypadków dostajesz uzasadnienie na piśmie i, jeśli to możliwe, wskazanie taniejszej drogi do tego samego celu. Odradzenie projektu jest tańsze dla obu stron niż wdrożenie, które nie zostanie użyte.

Czego potrzebujemy od Ciebie

  • Jednej osoby znającej proces i mającej prawo decydować o zmianach w nim.
  • Dostępu do danych, na których proces realnie działa — nie do próbki demonstracyjnej.
  • Kontaktu po stronie IT do spraw dostępów, integracji i zasad bezpieczeństwa obowiązujących w firmie.
  • Zgody na to, że pilotaż może zakończyć się wnioskiem negatywnym. Bez tej zgody pilotaż zamienia się w formalność, a jego jedyną funkcją jest właśnie możliwość powiedzenia „nie”.

Czego nie robimy

  • Nie budujemy własnych modeli od zera. Dla zdecydowanej większości zastosowań biznesowych to droga kilkukrotnie droższa od dostrojenia gotowego modelu i obudowania go dobrym oprogramowaniem.
  • Nie prowadzimy projektów bez fazy pomiaru. Wdrożenie, którego efektu nikt nie mierzy, nie daje się obronić przy kolejnym budżecie.
  • Nie doradzamy prawnie. Przygotowujemy materiał techniczny, na którym opiera się ocena zgodności; klasyfikację i interpretację przepisów zostawiamy prawnikowi. Jak dzielimy się danymi i jakie decyzje o nich podejmujemy w projekcie, opisujemy w części obezpieczeństwie danych i RODO.

Najczęstsze pytania

Ile trwa całe wdrożenie?

Od pierwszej rozmowy do działającego procesu produkcyjnego zwykle od dwóch do czterech miesięcy, przy czym najwięcej czasu zajmuje nie budowa, tylko dostęp do danych i decyzje po stronie klienta. Sam pilotaż to zazwyczaj dwa do czterech tygodni. Jeśli ktoś obiecuje dwa tygodnie na całość, prawdopodobnie mówi o demie, nie o wdrożeniu.

Czy można zacząć od jednego procesu, zamiast od strategii AI?

Tak i zwykle właśnie tak zaczynamy. Strategia napisana przed pierwszym wdrożeniem opiera się na założeniach, których nikt jeszcze nie sprawdził. Uruchomienie jednego procesu produkcyjnie daje twarde dane o tym, ile to naprawdę kosztuje i gdzie w Twojej organizacji leży wąskie gardło — i dopiero na tym warto budować plan na resztę.

Co się dzieje, jeśli pilotaż nie wyjdzie?

Kończymy na pilotażu i dostajesz raport z tego, czego się dowiedzieliśmy: gdzie model zawodził, jakiej jakości były dane i czy problem leżał w technologii, czy w samym procesie. To jest przewidziany wynik, nie porażka projektu — dlatego pilotaż jest osobną fazą z osobną decyzją, a nie zaliczką na wdrożenie.

Kto po naszej stronie musi być zaangażowany?

Jedna osoba znająca proces od środka i mająca prawo decydować o zmianach w nim, oraz ktoś z IT do spraw dostępów i integracji. Bez pierwszej z tych osób projekt się nie uda — nie dlatego, że brakuje rąk, tylko dlatego, że nie ma kto rozstrzygnąć, jak proces ma wyglądać po zmianie.

Czy przekazujecie kod i dokumentację, czy uzależniacie nas od siebie?

Kod, konfiguracja i dokumentacja są Twoje i przekazujemy je na koniec wdrożenia. Uważamy to za warunek uczciwej współpracy: jeśli utrzymanie ma sens tylko dlatego, że nikt inny nie rozumie systemu, to nie jest utrzymanie, tylko blokada.

Czym ta metodyka różni się od zwykłego projektu IT?

Dwiema rzeczami. Po pierwsze, wynik jest probabilistyczny — model bywa zawodny, więc od początku projektujemy, co się dzieje, gdy się pomyli, zamiast zakładać, że nie będzie. Po drugie, jakość zależy od danych bardziej niż od kodu, więc audyt danych jest fazą, a nie punktem w analizie przedwdrożeniowej.

Zacznijmy od fazy pierwszej

Bezpłatna konsultacja, po której wiadomo, który proces ma sens jako pierwszy — albo czy w ogóle warto zaczynać.