AI w firmie bez hype: co naprawdę działa, co zawodzi i ile to kosztuje

O sztucznej inteligencji mówi się dziś dwoma językami. Pierwszy obiecuje, że zaraz wszystko zrobi się samo. Drugi straszy, że nic z tego nie działa i wszyscy stracą pracę. Oba są bezużyteczne, gdy trzeba podjąć decyzję o wydaniu firmowych pieniędzy.

Ten tekst jest długi, bo temat nie mieści się w liście dziesięciu punktów. Przechodzę po kolei: co modele językowe robią naprawdę dobrze, gdzie się mylą i dlaczego to nie zniknie, ile to kosztuje po doliczeniu rzeczy, o których nie mówi się na demo, oraz jak ocenić konkretny pomysł, zanim wydacie na niego złotówkę.

Co AI naprawdę robi dobrze#

Zacznijmy od rzeczy, które działają na tyle dobrze, że można na nich oprzeć proces biznesowy. Jest ich mniej, niż sugerują reklamy, ale więcej, niż sądzą sceptycy.

Pierwsza kategoria to przekształcanie tekstu z jednej postaci w drugą. Streszczenie długiego maila do trzech zdań. Wyciągnięcie z zamówienia numeru, ilości i terminu do struktury, którą przyjmie system. Przepisanie notatki ze spotkania na listę zadań. To zadania, w których wejście i wyjście są jasno określone, a model nie musi niczego wymyślać — ma tylko przełożyć.

Druga kategoria to klasyfikacja. Czy to zapytanie jest reklamacją, zapytaniem ofertowym czy spamem? Do którego działu skierować zgłoszenie? Czy ten opis produktu pasuje do kategorii „elektronika" czy „AGD"? Model radzi sobie z tym lepiej niż reguły oparte na słowach kluczowych, bo rozumie kontekst, a nie tylko dopasowuje ciągi znaków.

Trzecia to generowanie pierwszej wersji. Szkic oferty, wstępny opis produktu, propozycja odpowiedzi na typowe pytanie. Nikt tego nie wyśle bez przeczytania, ale różnica między pustą stroną a szkicem do poprawienia jest ogromna. Przy powtarzalnych dokumentach oszczędność bywa większa niż połowa czasu.

Czwarta, najmniej doceniana, to wyszukiwanie po znaczeniu. Klasyczna wyszukiwarka znajdzie dokument zawierający dokładnie wpisane słowa. Wyszukiwanie oparte na modelu znajdzie dokument o tym samym, napisany innymi słowami. Przy bazie wiedzy zbieranej latami przez różne osoby to bywa różnica między „mamy to gdzieś" a „proszę, tutaj".

Gdzie się myli i dlaczego to nie zniknie#

Model językowy nie wie, że czegoś nie wie. To nie jest wada implementacji, którą naprawi kolejna wersja — to wynika ze sposobu, w jaki te systemy działają. Przewidują najbardziej prawdopodobny ciąg dalszy, a prawdopodobny nie znaczy prawdziwy.

W praktyce oznacza to, że model poproszony o numer przepisu, datę wejścia w życie ustawy albo parametr techniczny podaje coś, co wygląda dokładnie jak poprawna odpowiedź. Format się zgadza, ton jest pewny, szczegół jest zmyślony. To groźniejsze niż odmowa odpowiedzi, bo nie wzbudza czujności.

Druga rodzina błędów dotyczy liczb. Modele nie liczą — one przewidują, jak wygląda wynik liczenia. Przy prostych działaniach zwykle trafiają, przy złożonych bywa różnie, a najgorsze jest to, że pomyłka wygląda tak samo jak trafienie. Jeżeli w procesie pojawia się arytmetyka, powinna ją wykonać zwykła funkcja, a nie model.

Trzecia to niestabilność. To samo pytanie zadane dwa razy potrafi dać dwie różne odpowiedzi. Dla szkicu tekstu to bez znaczenia. Dla procesu, w którym każde zgłoszenie ma trafić do właściwego działu, to poważny problem — i powód, dla którego przy klasyfikacji ogranicza się model do zamkniętej listy odpowiedzi, zamiast pozwalać mu pisać cokolwiek.

Czwarta, najbardziej podstępna, to uprzejmość. Modele są trenowane tak, żeby być pomocne, więc rzadko mówią „nie da się" albo „brakuje danych". Poproszony o analizę na podstawie niekompletnych informacji model wypełni luki założeniami i nie zaznaczy, które fragmenty są pewne, a które zgadnięte.

Wniosek nie brzmi „nie używać". Brzmi: nie oddawać modelowi decyzji, których błąd jest kosztowny i trudny do wykrycia. Wszędzie tam, gdzie człowiek i tak czyta wynik przed użyciem, ryzyko jest niewielkie. Wszędzie tam, gdzie odpowiedź idzie prosto do klienta albo do systemu księgowego, potrzebna jest kontrola.

Ile to naprawdę kosztuje#

Cennik modeli wygląda tanio i to prawda — ale tylko dla samego wywołania. Przetworzenie tysiąca zapytań klientów miesięcznie to zwykle koszt rzędu kilkudziesięciu do kilkuset złotych. Przy takich liczbach cena modelu przestaje być czynnikiem decyzyjnym.

Prawdziwy koszt leży gdzie indziej. Pierwszy składnik to przygotowanie danych. Model odpowiadający na pytania o Waszą ofertę musi mieć skąd wiedzieć, jaka ona jest. Jeżeli opisy usług są w trzech miejscach i częściowo nieaktualne, ktoś musi je najpierw uporządkować. To zwykle najdroższa i najbardziej pomijana część projektu.

Drugi składnik to integracja. Model, który nie ma dostępu do CRM-u, kalendarza i systemu zamówień, jest ciekawostką. Podłączenie go do nich to normalna praca programistyczna, wyceniana tak jak każda inna, i to ona zwykle stanowi większość budżetu.

Trzeci to testy. Nie sprawdza się tego jednym przejściem. Trzeba przygotować kilkadziesiąt realnych przypadków, przepuścić je przez system i przejrzeć wyniki ręcznie. Przy klasyfikacji zgłoszeń to jeden dzień pracy, przy generowaniu ofert — kilka.

Czwarty, ciągły, to utrzymanie. Oferta się zmienia, procesy się zmieniają, dostawca modelu wypuszcza nową wersję i zachowanie systemu delikatnie się przesuwa. Bez kogoś, kto raz na kwartał to przejrzy, jakość spada niezauważalnie, aż ktoś zgłosi problem.

Uczciwa reguła: koszt samego modelu to zwykle mniej niż dziesiąta część całości. Jeżeli oferta wdrożenia opiera się głównie na cenniku tokenów, to znaczy, że nie policzono reszty.

Ukryte koszty, o których nie mówi się na demo#

Demo zawsze wygląda dobrze, bo pokazuje przypadek, który został dobrany. Kilka rzeczy ujawnia się dopiero po wdrożeniu.

Pierwsza to obsługa wyjątków. W demo zapytanie jest kompletne i sformułowane po polsku, jednym zdaniem. W rzeczywistości przychodzą wiadomości bez kontekstu, z załącznikiem zamiast treści, w dwóch językach naraz albo napisane wielkimi literami przez zdenerwowanego klienta. Każdy taki przypadek trzeba przewidzieć albo świadomie odesłać do człowieka.

Druga to zmiana przyzwyczajeń zespołu. Nowe narzędzie działa tylko wtedy, gdy ludzie go używają. Jeżeli handlowiec nadal odpisuje ręcznie, bo tak szybciej, to system stoi. Wdrożenie kończy się w dniu, w którym zespół zaczyna z niego korzystać bez przypominania — nie w dniu uruchomienia.

Trzecia to potrzeba wyjaśnienia. Klient, który dostał odpowiedź od systemu, czasem pyta, dlaczego akurat taką. Jeżeli nie zapisujecie, co poszło na wejściu i co wróciło, nie odpowiecie. Logowanie to kilka godzin pracy przy wdrożeniu i jedyny sposób, żeby później cokolwiek zbadać.

Czwarta to uzależnienie od dostawcy. Zmiana modelu na inny to nie jest podmiana adresu URL — zachowanie się zmienia i trzeba przejść testy od nowa. Warto to wiedzieć zawczasu i budować tak, żeby dostawca był podmienialny, nawet jeśli nigdy go nie zmienicie.

Dane: co wychodzi z firmy#

Każde zapytanie wysłane do modelu w chmurze to dane opuszczające Waszą infrastrukturę. Przy publicznych treściach marketingowych to nie problem. Przy danych klientów, wycenach czy dokumentacji technicznej — już tak.

Trzy rzeczy warto sprawdzić w regulaminie, zanim cokolwiek podłączycie. Czy dostawca używa Waszych zapytań do trenowania modeli. Jak długo je przechowuje. W jakim kraju stoją serwery, bo to przesądza o zgodności z RODO.

Różnica między planem darmowym a płatnym bywa tu zasadnicza. U większości dostawców darmowy poziom oznacza zgodę na wykorzystanie danych do ulepszania usługi, a płatny tego nie robi. Przy treści bloga to bez znaczenia. Przy bazie klientów to różnica między zgodnym a niezgodnym z prawem przetwarzaniem.

Alternatywą jest model uruchomiony na własnym serwerze. Dane nie wychodzą, koszt jest stały zamiast zmiennego, ale jakość jest niższa niż u najlepszych dostawców chmurowych, a ktoś musi to utrzymywać. Dla większości małych firm to nadmiar — chyba że przetwarzacie dane, których po prostu nie wolno wysłać.

Jest też droga pośrednia, często najrozsądniejsza: usuwać dane osobowe przed wysłaniem. Model streszczający reklamację nie potrzebuje nazwiska ani numeru zamówienia. Wystarczy podmienić je na znaczniki, a po otrzymaniu odpowiedzi wstawić z powrotem.

Ludzie: co się dzieje z zespołem#

Najczęstsza obawa brzmi: czy to zabierze pracę. W małych firmach usługowych zwykle nie zabiera, tylko przesuwa. Znika przepisywanie danych i pisanie tych samych odpowiedzi, zostaje rozmowa z klientem, ocena nietypowych przypadków i decyzje.

Ale przesunięcie też jest zmianą i warto ją nazwać. Osoba, która przez trzy lata była najszybsza w wystawianiu ofert, traci coś, w czym była dobra. Jeżeli nikt o tym nie porozmawia, opór pojawi się i tak, tylko w formie „to nie działa" zamiast „nie chcę".

Druga rzecz to spadek czujności. Gdy system w dziewięciu przypadkach na dziesięć ma rację, człowiek przestaje sprawdzać dziesiąty. To znany efekt i dotyczy każdej automatyzacji, nie tylko AI. Dlatego kontrola musi być wbudowana w proces, a nie oparta na dobrych chęciach.

Trzecia, pozytywna: modele bywają świetnym narzędziem do wdrażania nowych osób. Asystent znający Waszą dokumentację odpowiada na pytania, których nowy pracownik wstydzi się zadać po raz trzeci. To rzadko trafia do wyliczeń zwrotu z inwestycji, a bywa jedną z najbardziej odczuwalnych zmian.

Trzy sposoby użycia modelu i kiedy który#

W rozmowach o wdrożeniach mieszają się trzy zupełnie różne podejścia, które kosztują od siebie dziesięciokrotnie. Warto je rozróżniać, bo od tego zależy budżet.

Pierwsze i najtańsze to sama instrukcja. Model dostaje polecenie, przykłady poprawnych odpowiedzi i pracuje. Żadnego trenowania, żadnej infrastruktury. Wdrożenie liczy się w dniach, a nie tygodniach. To wystarcza do klasyfikacji, streszczania i przekształcania tekstu — czyli do większości tego, co ma sens w małej firmie.

Drugie to podanie modelowi dostępu do Waszych dokumentów. Zapytanie trafia najpierw do wyszukiwarki po znaczeniu, ta znajduje kilka najbardziej pasujących fragmentów dokumentacji, i dopiero one idą do modelu razem z pytaniem. Dzięki temu odpowiedź opiera się na Waszej ofercie, a nie na tym, co model zapamiętał z internetu. To standard dla asystentów odpowiadających o firmie i kosztuje kilka razy więcej niż sama instrukcja, głównie przez porządkowanie dokumentów.

Trzecie to douczanie modelu na własnych danych. Brzmi najpoważniej i prawie nigdy nie jest tym, czego potrzebuje mała firma. Wymaga setek albo tysięcy przykładów wysokiej jakości, kosztuje wielokrotnie więcej i trzeba to powtarzać przy każdej istotnej zmianie. Ma sens, gdy chodzi o bardzo specyficzny styl albo żargon branżowy, którego nie da się opisać instrukcją.

Praktyczna kolejność: zawsze zaczynajcie od pierwszego. Jeżeli nie wystarcza, przejdźcie do drugiego. Do trzeciego przechodzi się rzadko i dopiero po wyczerpaniu tamtych — a wykonawca, który proponuje douczanie na starcie, albo nie zrozumiał problemu, albo sprzedaje godziny.

Gdzie to działa w konkretnych działach#

Ogólniki są mało użyteczne, więc kilka konkretów z podziałem na obszary. To zestawienie tego, co realnie się wdraża w firmach kilkunasto- i kilkudziesięcioosobowych.

Sprzedaż: klasyfikacja przychodzących zapytań i kierowanie ich do właściwej osoby, wyciąganie z maila danych do CRM-u, szkic odpowiedzi na typowe pytanie o zakres i termin, streszczenie długiej korespondencji przed rozmową. Największa oszczędność siedzi zwykle w tym ostatnim — handlowiec przed telefonem nie czyta trzydziestu wiadomości, tylko akapit.

Obsługa klienta: odpowiedzi na pytania, które padają setny raz, wyłapywanie zgłoszeń pilnych spośród zwykłych, przygotowanie odpowiedzi do zaakceptowania przez człowieka. Warunek jest jeden i twardy: baza wiedzy musi istnieć i być aktualna. Bez niej asystent zmyśla.

Administracja: przepisywanie danych z faktur i zamówień do systemu, porównywanie dokumentów, przygotowanie protokołu ze spotkania na podstawie nagrania. Przy fakturach uwaga na liczby — model ma wyciągnąć wartość, a nie ją obliczyć.

Marketing i treść: szkice wpisów, opisy produktów z parametrów, przygotowanie kilku wariantów nagłówka do wyboru, tłumaczenia robocze. Tu ryzyko jest najniższe, bo nikt tego nie publikuje bez przeczytania, a oszczędność czasu największa.

Techniczne: wyszukiwanie w dokumentacji, wyjaśnianie fragmentów kodu, przygotowanie pierwszej wersji skryptu. Warto pamiętać, że model pisze kod prawdopodobny, a nie sprawdzony — testy są obowiązkowe tak samo jak przy kodzie pisanym ręcznie.

Przykład z liczbami#

Teoria jest tania, więc przejdźmy przez jeden przypadek do końca. Firma usługowa, dwanaście osób, dostaje mniej więcej sto dwadzieścia zapytań miesięcznie przez formularz i mailem.

Stan obecny: osoba z biura przegląda skrzynkę, ocenia, czego dotyczy zgłoszenie, przepisuje dane do CRM-u i przekazuje właściwemu handlowcowi. Średnio dwanaście minut na zgłoszenie, licząc przełączanie się między zadaniami. To dwadzieścia cztery godziny miesięcznie, czyli trzy pełne dni pracy.

Po wdrożeniu: model klasyfikuje zgłoszenie do jednej z sześciu kategorii, wyciąga nazwę firmy, zakres i termin, tworzy wpis w CRM-ie i przypisuje handlowca według reguł. Człowiek sprawdza wynik i poprawia, gdy trzeba. Realnie: dwie i pół minuty na zgłoszenie, w tym te przypadki, przy których trzeba poprawić.

Oszczędność: dziewiętnaście godzin miesięcznie. Przy stu złotych za godzinę to tysiąc dziewięćset złotych. Koszt wdrożenia dla takiego zakresu to zwykle od siedmiu do dwunastu tysięcy, więc zwrot wychodzi w cztery do siedmiu miesięcy.

Koszt bieżący: sto dwadzieścia zapytań miesięcznie to jakieś trzydzieści złotych za wywołania modelu. Utrzymanie liczone ostrożnie: dwie godziny kwartalnie na przegląd i poprawki.

Czego ten rachunek nie obejmuje, a warto dopisać po swojej stronie: dwa tygodnie równoległego działania na początku, gdy zespół robi jedno i drugie, oraz spadek dokładności przez pierwszy miesiąc, zanim reguły zostaną dostrojone. To nie jest ukryty koszt — to normalny etap, tylko rzadko trafia do prezentacji.

Sygnały ostrzegawcze u wykonawcy#

Rynek jest młody i rozgrzany, więc trafiają się oferty, które wyglądają dobrze na papierze. Kilka rzeczy warto potraktować jako sygnał ostrzegawczy.

Wykonawca nie pyta o Wasze dane. Jeżeli po pierwszej rozmowie potrafi podać cenę, nie wiedząc, ile macie zgłoszeń, jak wyglądają i gdzie trzymacie dokumentację, to wycenia szablon, a nie Wasz problem.

Obiecuje stuprocentową skuteczność. Nie da się jej zagwarantować przy modelu językowym. Uczciwa odpowiedź brzmi „na Waszych dwudziestu przykładach osiągniemy tyle a tyle, resztę odsyłamy do człowieka".

Nie chce rozmawiać o tym, co się dzieje przy błędzie. Brak planu na nieudany przebieg to nie oszczędność, tylko odłożony problem.

Proponuje douczanie modelu na starcie. Jak wyżej — to rzadko jest pierwszy krok i zwykle znaczy, że rozmowa poszła w stronę technologii zamiast procesu.

Nie pokazuje, gdzie będą trzymane dane i czy dostawca ich używa. To pytanie o zgodność z prawem, nie o preferencje.

I odwrotnie, dobry sygnał: wykonawca, który po analizie mówi, że w Waszym przypadku to się nie opłaci. Taki wykonawca liczy, a nie sprzedaje.

Kiedy AI ma sens#

Zbierzmy to w konkretne warunki. Zadanie nadaje się do modelu, gdy spełnia większość z poniższych.

Powtarza się często — co najmniej kilkadziesiąt razy w miesiącu. Poniżej tego progu koszt wdrożenia i utrzymania nie zwróci się przed zmianą procesu.

Wejście jest tekstem, a wyjście też. Wszędzie tam, gdzie chodzi o przekształcenie, streszczenie, klasyfikację albo wyszukanie, modele są mocne.

Błąd jest tani i widoczny. Źle zaproponowany szkic oferty ktoś poprawi. Źle wysłana faktura to inna kategoria problemu.

Człowiek i tak patrzy na wynik. To najmocniejszy pojedynczy warunek. Jeżeli w procesie jest naturalny moment, w którym ktoś czyta rezultat przed użyciem, ryzyko spada niemal do zera.

Istnieje źródło prawdy. Model odpowiadający o Waszej ofercie musi mieć ją opisaną w jednym miejscu i aktualną. Bez tego nie ma z czego korzystać.

Kiedy lepiej odpuścić#

Symetrycznie — sygnały, że to nie jest dobry pomysł, przynajmniej na razie.

Proces nie jest opisany i każdy robi go inaczej. Automatyzacja utrwali jeden z wariantów, niekoniecznie najlepszy. Najpierw ustalcie, jak to ma wyglądać.

Wynik idzie prosto do klienta albo do systemu finansowego bez kontroli. Da się to zbudować, ale wymaga zabezpieczeń, których koszt zwykle przewyższa korzyść w małej firmie.

Liczy się dokładność co do przecinka. Rozliczenia, terminy ustawowe, parametry techniczne — tu potrzebne są reguły i baza danych, nie model przewidujący prawdopodobny ciąg dalszy.

Wolumen jest mały. Pięć zgłoszeń miesięcznie nie jest problemem do automatyzacji. Jeżeli boli obsługa pięciu zgłoszeń, problemem jest coś innego.

Nikt w firmie nie będzie tego pilnował. System bez właściciela degraduje się cicho. Lepiej nie zaczynać, niż zbudować coś, czemu za pół roku nikt nie ufa.

Jak ocenić konkretny pomysł#

Zanim zapytacie o wycenę, warto przejść przez cztery kroki samodzielnie. Zajmują dzień i oszczędzają miesiące.

Krok pierwszy: zmierzcie stan obecny. Ile razy w miesiącu, ile minut na raz, kto to robi. Nie z pamięci — przez tydzień zapisujcie. Pamięć wybiera to, co irytujące, a nie to, co kosztowne.

Krok drugi: zbierzcie dwadzieścia realnych przypadków z ostatniego miesiąca. Nie wymyślonych, nie wybranych jako reprezentatywne. Dwadzieścia kolejnych, razem z tymi dziwnymi. To będzie Wasz zestaw testowy i to na nim ocenicie każde rozwiązanie.

Krok trzeci: ustalcie, co znaczy „działa". Osiemnaście na dwadzieścia poprawnie? Wszystkie poprawnie, ale z możliwością odmowy odpowiedzi? Bez tej definicji ocena wdrożenia sprowadzi się do wrażeń.

Krok czwarty: policzcie próg opłacalności. Ile miesięcy przy Waszych liczbach. Jeżeli wychodzi więcej niż rok, odłóżcie temat — wcześniej zmieni się proces i inwestycja przepadnie.

Dopiero z tymi czterema rzeczami rozmowa z wykonawcą ma sens. Zamiast „chcemy AI" mówicie „mamy trzydzieści zgłoszeń miesięcznie, po czterdzieści pięć minut, oto dwadzieścia przykładów, sukces to osiemnaście poprawnych klasyfikacji". Na takie zapytanie da się odpowiedzieć uczciwą wyceną.

Strona prawna, w skrócie i bez paniki#

Wokół regulacji narosło sporo strachu, więc uporządkujmy, co realnie dotyczy małej firmy usługowej korzystającej z gotowych modeli.

Pierwsza rzecz to ochrona danych osobowych. Nie zmieniła jej żadna nowa regulacja o sztucznej inteligencji — obowiązuje tak samo jak przy każdym innym narzędziu w chmurze. Jeżeli wysyłacie do modelu dane klientów, potrzebujecie podstawy prawnej, umowy powierzenia z dostawcą i wpisu w rejestrze czynności przetwarzania. To nie jest nic egzotycznego; identycznie postępujecie z hostingiem poczty.

Druga to obowiązek informowania. Gdy klient rozmawia z systemem, a nie z człowiekiem, powinien to wiedzieć. Wystarczy zdanie na starcie rozmowy. To akurat leży też w Waszym interesie — klient, który myśli, że pisze z konsultantem, ocenia odpowiedzi znacznie surowiej.

Trzecia to kwestia odpowiedzialności. Za odpowiedź wysłaną przez Wasz system odpowiadacie Wy, nie dostawca modelu. „Tak powiedziała sztuczna inteligencja" nie jest argumentem wobec klienta ani wobec urzędu. To kolejny powód, żeby przy decyzjach o konsekwencjach finansowych trzymać człowieka w procesie.

Czwarta dotyczy praw autorskich do wygenerowanej treści. Sytuacja jest niejednoznaczna i różni się między krajami. W praktyce oznacza to, że tekstu wygenerowanego w całości przez model raczej nie ochronicie jako własnego utworu. Przy opisach produktów bez znaczenia, przy materiałach, na których budujecie markę — warto o tym pamiętać.

Piąta, praktyczna: zapisujcie, co system robi. Logi z wejściem i wyjściem to jedyny sposób, żeby cokolwiek wyjaśnić, gdy pojawi się reklamacja albo pytanie. To ta sama zasada co przy każdej automatyzacji, tylko konsekwencje są bardziej widoczne.

Czego natomiast raczej nie musicie się obawiać: większość obowiązków z regulacji o sztucznej inteligencji spada na twórców modeli i na zastosowania wysokiego ryzyka — rekrutację, ocenę zdolności kredytowej, systemy medyczne. Klasyfikacja zapytań ofertowych i streszczanie maili do tej kategorii nie należą.

Jak sprawdzić po trzech miesiącach, czy się udało#

Wdrożenie nie kończy się uruchomieniem. Bez pomiaru po fakcie zostajecie z wrażeniami, a wrażenia po wydaniu kilkunastu tysięcy złotych bywają optymistyczne.

Miara pierwsza i najważniejsza: czas. Ten sam pomiar, który zrobiliście przed wdrożeniem, powtórzony po. Ile minut na zgłoszenie, ile zgłoszeń w miesiącu. Jeżeli nie zmierzyliście stanu wyjściowego, nie macie do czego porównać — i to jest najczęstszy błąd całego procesu.

Miara druga: udział przypadków wymagających poprawki. Jeżeli człowiek poprawia co drugą odpowiedź, oszczędność jest pozorna, bo sprawdzanie cudzej pracy bywa wolniejsze niż zrobienie jej od zera. Zdrowy poziom to kilkanaście procent i malejąco.

Miara trzecia: nieudane przebiegi. Ile razy w miesiącu system się wywrócił i ile czasu zajęło zauważenie. Jeżeli awarie wychodzą dopiero po telefonie od klienta, brakuje powiadomień, a nie modelu.

Miara czwarta, jakościowa: czy zespół używa tego bez przypominania. To najlepszy pojedynczy wskaźnik. Narzędzie, do którego trzeba zaganiać, nie zostało wdrożone — zostało zainstalowane.

I decyzja, na którą warto się umówić z góry: co zrobicie, jeżeli po trzech miesiącach liczby nie wychodzą. Wyłączenie systemu, który nie zarabia, jest normalną decyzją biznesową. Utrzymywanie go, bo już się wydało pieniądze, jest błędem poznawczym z nazwą własną i kosztuje drugie tyle.

Od czego zacząć#

Jeżeli po tym wszystkim chcecie spróbować, najkrótsza droga do sensownej odpowiedzi wygląda tak.

Wybierzcie jeden proces, najlepiej nudny i dobrze opisany. Klasyfikacja przychodzących zapytań jest zwykle dobrym pierwszym krokiem: powtarzalna, tekstowa, a błąd oznacza najwyżej przekierowanie do niewłaściwej osoby.

Zbudujcie najmniejszą działającą wersję. Bez integracji z pięcioma systemami, bez panelu administracyjnego. Jedno wejście, jedno wyjście, wynik do sprawdzenia przez człowieka.

Puśćcie ją równolegle z obecnym procesem przez dwa tygodnie. Nie zamiast — obok. Porównajcie wyniki. To jedyny sposób, żeby dowiedzieć się, jak to działa na Waszych danych, a nie na czyimś demo.

Dopiero potem decydujcie o rozbudowie. Może się okazać, że warto, może że nie. Obie odpowiedzi są dobre, jeżeli oparte na dwóch tygodniach obserwacji zamiast na prezentacji.

I na koniec rzecz, którą łatwo przeoczyć w całym szumie: sztuczna inteligencja jest narzędziem, nie strategią. Firma z uporządkowanymi procesami zyska na niej dużo. Firma bez nich dostanie te same problemy, tylko szybciej.