Wdrożenie AI w firmie - od czego zacząć: najpierw proces, potem narzędzie

Wdrożenie AI w firmie - od czego zacząć, czyli dlaczego narzędzie jest ostatnie

Ten schemat rozpoznaje się od razu, gdy widziało się go kilka razy. Firma decyduje, że potrzebuje AI, wybiera narzędzie i organizuje spotkanie, żeby znaleźć dla niego zajęcie. Wybór pada zwykle na proces, który dobrze wygląda na demie: widoczny, łatwy do opowiedzenia na zarządzie i bezpiecznie daleko od wszystkiego, co przy pomyłce kosztowałoby realne pieniądze. Sześć tygodni później stoi pilot, którego nikt nie otwiera, a wniosek brzmi, że AI jeszcze nie dorosło. Technologia nie była tu problemem. Problemem był wybór procesu.

Proces wart automatyzacji zgłasza się sam, zanim powstanie linijka kodu. Dzieje się często i za każdym razem przebiega mniej więcej tak samo. Ktoś potrafi jasno powiedzieć, jak wygląda poprawna odpowiedź. Jego dane wejściowe leżą już tam, skąd maszyna może je przeczytać. Wszystkie cztery własności da się sprawdzić w tym tygodniu, stoperem i kartką, i mówią one o losie projektu więcej niż wybór modelu.

Z zaczynania od procesu wynikają dwie rzeczy. Po pierwsze, większość pożytecznej roboty nie ma nic wspólnego z AI: liczenie, mierzenie, spisanie reguł, doprowadzenie danych do jednego czytelnego miejsca. Po drugie, spór o własne rozwiązanie kontra gotowe narzędzie, który firmy uwielbiają toczyć na starcie, jest w rzeczywistości decyzją ostatnią, bo ma sens dopiero wtedy, gdy znasz kształt pracy. Opisaliśmy osobno progi, które rozstrzygają własny system czy gotowe narzędzie, ale nie pomogą ci, dopóki ta część nie jest zrobiona.

Cztery testy, które rozstrzygają, czy proces warto automatyzować

Każdy test jest pomiarem, a nie opinią, i każdy może wypaść negatywnie. O to właśnie chodzi: test, który nie może się nie udać, jest hasłem, a hasło bez oporów wprowadzi cię w długi projekt. Bierz jeden proces naraz, zapisuj odpowiedzi tam, gdzie zobaczą je inni, i bądź surowy przy porażkach.

Nie uśredniaj tych czterech wyników w jedną ocenę. Wolumen i powtarzalność są bramkami: oblej którąkolwiek, a projekt nie ma ekonomii, choćby technologia wyglądała najciekawiej. Test kosztu niczego nie dyskwalifikuje, tylko ustawia kształt - drogi błąd, którego nikt by nie wyłapał, oznacza, że system przygotowuje, a człowiek zatwierdza. Test danych jest natomiast testem harmonogramu, bo jeśli danych nie ma jeszcze w systemie, to właśnie jest twój pierwszy projekt i warto go zrobić nawet bez AI w tle.

Jeśli reguły nie mieszczą się na kartce, model zacznie zgadywać

Powtarzalność jest najtańszym testem i tym, z którego najłatwiej się wykręcić, bo spisanie reguł na jedną kartkę wygląda na papierologię dokładnie do momentu, w którym się spróbuje. Pipeline, który publikuje artykuły do wiki gry bez człowieka w pętli, działa dlatego, że taka kartka istniała, zanim pojawił się jakikolwiek model: artykuły trzymają się stałego szablonu i konwencji platformy, a reguła linkowania jest na tyle jednoznaczna, że maszyna umie jej pilnować - linkuj wyłącznie do stron, które są w żywej sitemapie. Każdy termin przychodzi też z własnym kontekstem, aż po adres usługi, na który ma prowadzić wezwanie do działania. Model wypełnia znany kształt, a nie rozstrzyga, czym jest dobry artykuł.

Zrób to samo ćwiczenie na procesie, w którym reguły siedzą w czyjejś ocenie, a kartka wyjdzie jako lista wyjątków. To nie dyskwalifikuje procesu, tylko go zawęża: zautomatyzuj tę część, która idzie po szablonie, a wyjątki zostaw osobie, która je rozpoznaje. Reguły, które przetrwały spisanie, są zwykle też regułami, które maszyna umie potem sprawdzić, w rodzaju „link prowadzi do istniejącej strony” albo „liczba zgadza się z rekordem”, więc ich spisanie po cichu odpowiada też na sporą część testu kosztu.

Wolumen to nie średni dzień, tylko twoja najgorsza minuta

Najczystszy zdany test wolumenu, jaki zmierzyliśmy, siedzi w tym samym pipelinie treści. Napisanie jednego artykułu ręcznie zabierało pisarzowi 20 do 40 minut: strukturalne ciało HTML, linki wewnętrzne do stron, które naprawdę istnieją, slug, meta description i wezwanie do działania, wszystko zgodne z konwencjami platformy. Jeden artykuł w tej cenie jest w porządku. Katalog setek terminów, który wciąż rośnie, już nie, a praca jest powtarzalna i oparta na regułach od początku do końca. Czas na sztukę razy liczba sztuk w miesiącu to cały argument i policzysz go, zanim się na cokolwiek zdecydujesz.

Wolumen łatwo jednak niedoszacować, bo ludzie liczą złą jednostkę. Bot na Telegramie, który prowadzimy na kanałach ze zleceniami, z zewnątrz wygląda trywialnie: obserwuj kanał i wysyłaj dalej to, co się pojawi. Przy tysiącach użytkowników, z których każdy ustawia własne filtry, jedno nowe ogłoszenie potrafi pasować do setek naraz, więc pojedyncze zdarzenie staje się setkami wysyłek, wszystkimi w kilka sekund i wszystkimi pod limitem tempa. Tak właśnie system dochodzi do milionów wiadomości dziennie. Liczbą wartą zmierzenia nie jest liczba zdarzeń na dzień, tylko liczba akcji na zdarzenie, przemnożona.

Wolumen rzadko przychodzi też równym strumieniem. Na backendzie platformy streamingowej OTT ograniczeniem projektowym jest start meczu na żywo i ponad dziesięć tysięcy widzów naciskających play w tej samej minucie. System, który czuje się dobrze przy średnim obciążeniu i składa się w szczycie, jest systemem złym, bo szczyt to jedyny moment, który wszyscy potem pamiętają. Twoja wersja tej minuty jest mniejsza i równie realna: wsad faktur na koniec miesiąca, poniedziałkowa kolejka zgłoszeń, godzina po wysyłce kampanii.

Mierz więc najbardziej zapchaną godzinę najbardziej zapchanego dnia, a nie miesięczną sumę podzieloną przez trzydzieści. Automatyzacja, która tej godziny nie wytrzyma, zostanie wyłączona dokładnie w tym tygodniu, w którym miała się zwrócić - i już nikt jej nie włączy z powrotem.

To, jak wyłapiesz błędną odpowiedź, decyduje o kontroli, którą budujesz

Trzeci test jest tym, na który odpowiada się za szybko. „Musi być poprawne” nie jest pomiarem. Użyteczne pytanie jest węższe: jeśli ten wynik będzie błędny, co to zauważy i po jakim czasie?

W asystencie RAG nad bazą wiedzy z 500 tys. rekordów tryb awarii był precyzyjny. Zapytaj o liczbę, a model odpowiadał konkretną wartością wyciągniętą z własnej pamięci, a nie z pobranych danych - pewnie i precyzyjnie błędną. Po ogólnikową odpowiedź ktoś jeszcze sięgnie i ją sprawdzi. Precyzyjną wkleja się do dokumentu i wysyła dalej, i dlatego jest tym droższym rodzajem błędu. Poprawką nie był lepszy model. Każda liczbowa deklaracja jest weryfikowana względem źródłowego fragmentu, z którego rzekomo pochodzi, zanim odpowiedź trafi do użytkownika, a deklaracja bez możliwego do pobrania źródła jest odrzucana albo oznaczana, nigdy wygładzana w płynne zdanie. Sam retrieval jest hybrydowy, wektory dense i BM25 łączone i potem rerankowane, więc do finalnego kontekstu trafiają zarówno trafienia po dokładnej nazwie, jak i semantyczne.

Ta sama zasada rozstrzygnęła, czy design-to-code w ogóle da się zautomatyzować. W pipelinie zamieniającym pliki Figmy w kod frontendu skrajne przypadki auto-layoutu rozjeżdżały mniej więcej 15% klatek. Nie ten procent jest tu ciekawy. Proces dało się bezpiecznie zautomatyzować dlatego, że maszyna potrafi rozpoznać zły wynik: wygenerowany kod renderuje się ponownie headlessowo i porównuje piksel po pikselu z oryginalną klatką, a co nie przejdzie, wraca do kolejki ze swoim diffem, więc kolejne podejście celuje w konkretną rozbieżność. Wcześniej działa bramka strukturalna: każda nazwa komponentu, prop i import muszą się resolvować, zanim powstanie choć jeden plik.

Praktyczna postać testu kosztu jest więc pytaniem o wykrywalność. Skąd maszyna miałaby wiedzieć, że ten wynik jest błędny? Jeśli odpowiedź brzmi „porównaj każdą liczbę z rekordem, z którego pochodzi” albo „odpytaj adres i sprawdź, czy istnieje”, cała pętla może działać bez nadzoru. Jeśli brzmi „doświadczona osoba wyczuje, że coś jest nie tak”, automatyzacja kończy się na wersji roboczej, którą podpisuje człowiek. Oba wyniki są dobre. Pomylenie ich to sposób, w jaki wdrożenia cichną, co rozłożyliśmy awaria po awarii w tekście o tym, dlaczego wdrożenia AI się nie udają.

Jeśli danych nie ma jeszcze w systemie, to jest twój pierwszy projekt

Czwarty test ustawia harmonogram bardziej niż cokolwiek innego z listy. Gdy dane są już adresowalne, robota to głównie hydraulika i sprawdzanie. Głosowy inżynier wyścigowy do sesji na żywo musi odpowiedzieć kierowcy w niecałe dwie sekundy, gdy auto jedzie, co brzmi nierealnie, dopóki nie zauważysz, że dane nigdy nie były przeszkodą: symulator je udostępnia. Budowa polegała na uformowaniu tego strumienia w 19 narzędzi, które agent może wywołać, odpytywaniu co 100 ms i trzymaniu ukończonych okrążeń wszystkich 64 aut w bazie zamiast w kontekście modelu.

W małej firmie znacznie częstszy jest przypadek odwrotny. W asystencie zbudowanym dla władz uczelni liczby istniały, ale siedziały w silosach: rekrutacja i zapisy w jednym systemie, frekwencja i wyniki w drugim, dane kadrowe i raporty wydziałów w trzecim. Władze widziały je tylko jako okresowe raporty składane ręcznie, więc obraz był nieaktualny, zanim zdążył się złożyć. Pierwsza połowa tego projektu nie miała nic wspólnego z modelem. Polegała na jednym interfejsie nad tym wszystkim, żeby pytanie dało się odpowiedzieć z bieżących danych, a nie z zeszłomiesięcznego arkusza.

Przełożone na czternastoosobową firmę brzmi to zwykle tak: odpowiedź leży w dwóch arkuszach, ERP, z którego nikt nie eksportuje, i skrzynce jednej osoby. Wtedy pierwszym projektem nie jest agent. Jest doprowadzenie tych danych do czytelnej postaci, cyklicznie. Robota niewdzięczna i tańsza, niż się wydaje. Bez niej nic, co zbudujesz później, się nie klei. Czasem regulacja robi tę część za ciebie. Faktury sprzedażowe i zakupowe krążą już jako ustrukturyzowany XML przez KSeF, a nie jako PDF w załączniku, więc test danych jest zdany od pierwszego dnia, a prawdziwa praca przesuwa się dalej, w dopasowanie i dekretację - pipeline, który rozrysowaliśmy w przewodniku po KSeF.

Jest jeszcze druga część testu danych, o której w Polsce warto pomyśleć od razu. Jeśli w danych wejściowych są dane osobowe, pytanie brzmi nie tylko „czy da się to wyeksportować”, ale też „co wolno wysłać do modelu, dokąd to leci i jak długo tam leży”. To decyzja architektoniczna, a nie zapis w regulaminie, i dużo taniej podjąć ją przed budową niż po pierwszym audycie.

Część procesów zasługuje na akceptację człowieka, a nie na odmowę

Oblany test kosztu nie znaczy, że praca zostaje ręczna na zawsze. Znaczy, że maszyna przygotowuje, a człowiek decyduje. Wyrysowanie tej granicy wprost jest tym, co utrzymuje system w użyciu tam, gdzie pomyłki są drogie, i zwykle stanowi różnicę między narzędziem, którego ludzie używają, a takim, do którego po cichu tracą zaufanie.

Asystent uczelniany działa tak z założenia: przygotowuje, przypomina i raportuje, ale przydziały i decyzje zatwierdza człowiek, a każde działanie jest logowane, więc zostaje czytelny ślad, kto co zaakceptował. Inżynier wyścigowy rysuje tę samą linię w dużo szybszym otoczeniu. Odczyt telemetrii jest w pełni autonomiczny, a komendy pit-stopu przechodzą przez bramkę człowieka, zanim cokolwiek trafi do auta. Odczyt jest tani do zautomatyzowania. Bramkę stawia się tam, gdzie system działa na zewnątrz.

W Polsce ta granica ma też wymiar formalny i lepiej znać go przed budową. RODO daje człowiekowi prawo, by nie podlegać decyzji opartej wyłącznie na zautomatyzowanym przetwarzaniu, jeśli wywołuje ona skutki prawne lub podobnie istotnie na niego wpływa, a tam, gdzie taka decyzja jest dopuszczalna, wymaga zapewnienia prawa do interwencji człowieka i zakwestionowania rozstrzygnięcia. AI Act idzie w tę samą stronę dla systemów wysokiego ryzyka: artykuł 14 wymaga, żeby dało się je skutecznie nadzorować, czyli żeby człowiek rozumiał ograniczenia systemu, wychwytywał anomalie i mógł nadpisać albo zatrzymać jego działanie. Log akceptacji i możliwość cofnięcia decyzji to więc nie ozdobniki, tylko część projektu.

Reszta decyzji mieści się w tabeli. Dopasuj swój proces do wiersza, a wybór zwykle robi się oczywisty, gdy cztery testy są już spisane.

Jedno zastrzeżenie do drugiego wiersza. Krok akceptacji pomaga tylko wtedy, gdy osoba zatwierdzająca szybko odróżnia dobre od złego. Jeśli potwierdzenie jednej sztuki trwa tyle co zrobienie jej ręcznie, dołożyłeś krok, zamiast go usunąć, a uczciwą poprawką jest zawęzić to, czego system się podejmuje, aż wynik da się sprawdzić rzutem oka.

Policzony przykład, od pomiaru do końca

Ten scenariusz jest ilustracyjny, to złożenie typowych sytuacji, a nie wynik klienta. Jedyną zmierzoną liczbą jest w nim czas pisania na sztukę z pipeline'u treści powyżej; cała reszta to arytmetyka, którą przeliczysz na własnych danych.

Czternastoosobowy dystrybutor części przemysłowych sprzedaje z katalogu około czterystu produktów. Każdy nowy albo zmieniony produkt potrzebuje strony opisu: krótkiego podsumowania specyfikacji, informacji o kompatybilności i linków do powiązanych części, które już są na stronie. Pisze je jedna osoba między innymi obowiązkami, a w miesiącu przechodzi około trzydziestu pozycji.

Przejdź testy. Wolumen zdany, choć skromnie: trzydzieści uruchomień miesięcznie, za każdym razem to samo zadanie. Powtarzalność zdana, bo opisy trzymają się szablonu, a specyfikacja pochodzi ze stałego zestawu pól. Koszt błędnej odpowiedzi jest wysoki, bo błędna liczba w specyfikacji kończy się zwrotami, a czytelnik tego nie wyłapie, ale jest wykrywalny maszynowo, bo każda liczba w tekście powinna występować w rekordzie produktu, z którego pochodzi. Dostępność danych też zdana: specyfikacja leży w ERP i da się ją wyeksportować, a strona ma sitemapę, więc linki do powiązanych części da się zweryfikować. Cztery zdane testy, przy czym trzeci przechodzi wyłącznie dlatego, że sprawdzanie może wykonać maszyna.

Zanim cokolwiek powstanie, zmierz stoperem dziesięć realnych pozycji. Na wdrożonym pipelinie, który mierzyliśmy, jeden porównywalny artykuł zajmował pisarzowi 20 do 40 minut. Załóżmy, że ta firma mieści się w tym samym przedziale i przyjmuje trzydzieści minut jako wartość roboczą. Trzydzieści pozycji miesięcznie po pół godziny to około piętnastu godzin miesięcznie na jednym zadaniu i tę liczbę warto zapisać, bo tylko ona pozwala potem uczciwie ocenić wynik. Pożyczenie naszej liczby zamiast zmierzenia własnej to sposób, w jaki wyliczenia ROI stają się fikcją.

Budowa idzie potem za testami, a nie za narzędziem. Pobierz rekord produktu z ERP. Wygeneruj z niego opis. Sprawdź, czy każda liczba w tekście zgadza się z polem w rekordzie i czy każdy link wewnętrzny prowadzi do istniejącej strony, czyli dokładnie tę samą kontrolę linków na żywo, którą pipeline treści robi przed publikacją. Pozycje, które przeszły, idą na stronę. Pozycje, które nie przeszły, wracają z opisem konkretnej rozbieżności, a resztą zajmuje się człowiek.

Zdefiniuj koniec, zanim zaczniesz, i zdefiniuj go tak, żeby dało się go nie osiągnąć. Działająca postać: odłóż pięćdziesiąt pozycji, których system nigdy nie widział, przepuść je i wymagaj, żeby każda opublikowana liczba zgadzała się z ERP, a każdy link prowadził do istniejącej strony, przy czym cała reszta idzie do człowieka. „Pisze dobre opisy” nie może wypaść negatywnie, więc w ogóle nie jest kryterium. Gdy koniec jest zdefiniowany, możliwa staje się też rozmowa o budżecie, a gdzie faktycznie idą pieniądze, rozpisaliśmy w tekście o kosztach wdrożenia AI.

Co zrobić w najbliższe dwa tygodnie

Nic z tego nie wymaga dostawcy, nas w tym również. Poniższa kolejność mieści się obok normalnej pracy, a pierwszy krok zmienia najwięcej.

1. Wypisz każdy proces, który poszedł w zeszłym miesiącu więcej niż dwadzieścia razy. Kalendarz, kolejka zgłoszeń i folder wysłanych są tu lepszym źródłem niż jakikolwiek warsztat.

2. Weź trzy najbardziej czasochłonne i spisz dla każdego reguły na jedną stronę, tak jakby czytał je ktoś, kto zaczyna w poniedziałek. Ten, którego nie umiesz spisać, na razie odpada, i to jest informacja, a nie porażka.

3. Dla każdego, który przetrwał, odpowiedz na piśmie na pytanie o wykrywalność. Skąd maszyna miałaby wiedzieć, że wynik jest błędny, i z jakim źródłem miałaby go porównać?

4. Znajdź system, w którym leżą dane wejściowe, i wyeksportuj z niego tydzień realnych danych. Jeśli takiego systemu nie ma, zatrzymaj się tutaj i zrób z tego projekt.

5. Zmierz stoperem dziesięć realnych uruchomień i zachowaj liczby. To jest twoje „przed”. Bez tego każda deklaracja o oszczędnościach jest opowieścią.

6. Narysuj na kartce granicę akceptacji: co system może zrobić sam, co potwierdza człowiek i co w obu przypadkach trafia do logu.

7. Dopiero teraz otwórz pytanie o własne rozwiązanie kontra gotowe i o cenę. W tej kolejności oferty, które dostajesz, dotyczą twojego procesu, a nie czyjegoś produktu.

8. Sprawdź, czy pierwsze wdrożenie łapie się na dofinansowanie, zanim cokolwiek podpiszesz - co realnie kupuje grant danej wielkości, rozpisaliśmy w tekście o dotacjach na AI dla firm.

Najważniejszy krok nic nie kosztuje: lista procesów z realnymi liczbami uruchomień i realnymi czasami obok. Większość decyzji o automatyzacji robi się prostsza w chwili, gdy ta lista istnieje, a kilka projektów na niej umiera, i po to właśnie się ją pisze.

(Budowanie takich systemów to nasza robota, więc uprzedzam o stronniczości.) Jeśli wolisz mieć drugą parę oczu na krótkiej liście, krótki audyt to niskostawkowy sposób, żeby ją mieć - wychodzisz z dwoma czy trzema procesami, które najpewniej się zwrócą, i kontrolami, których każdy z nich potrzebuje.

FAQ