Pod koniec pierwszego kwartału zarząd pyta: „Co nam to AI przyniosło?" Inżynier, który prowadził pilot, zaczyna kartkować notatnik. Treści powstawały szybciej. Agenci przejmowali część e-maili. Raporty trafiają do odbiorców wcześniej. Ale konkretna liczba — ile godzin, ile euro, jaka różnica w stosunku do sytuacji sprzed — nie istnieje. Nie dlatego, że projekt się nie powiódł. Lecz dlatego, że nikt przed startem nie zmierzył, jak wyglądał stan wyjściowy.
Ta sytuacja jest w praktyce częstsza, niż powinna być. Większość źródeł podaje, że 75–95 % projektów AI nie osiąga planowanej wartości biznesowej. Jedną z kluczowych przyczyn nie jest niska jakość technologii, ale brak mierzalnych ram: nie ma baseline'u, nie ma z góry uzgodnionych metryk, a gdy przychodzi czas oceny, porównujemy coś z niczym. Ten artykuł opisuje, jak zrobić to właściwie — od definicji baseline'u przez realne pozycje kosztowe aż po decyzję, kiedy projekt rzeczywiście ma sens.
Dlaczego baseline jest najważniejszym krokiem
Przed każdym wdrożeniem AI istnieje stan, który chcecie poprawić. Ten stan — baseline — jest wartością referencyjną, względem której będziecie mierzyć każde usprawnienie. Bez niego nie macie ROI. Macie tylko historię do opowiedzenia.
Baseline powinien uchwycić:
- Czas — ile godzin tygodniowo konkretny zespół poświęca na dane zadanie (nie szacowany, lecz realnie zmierzony lub udokumentowany z trackera)
- Błędowość — jaki jest aktualny wskaźnik błędów, powtarzanej pracy lub eskalacji
- Koszty — koszty pracy na daną agendę, ewentualnie opłaty zewnętrzne (outsourcing, licencje)
- Latencja — jak długo trwa przetwarzanie zgłoszenia od wejścia do wyjścia
Problem polega na tym, że firmy zazwyczaj tych liczb nie mają pod ręką. Czas spędzany na e-mailach nie jest logowany. Błędowość przy przetwarzaniu dokumentów nigdy nie była liczona. Dlatego jest jak najbardziej w porządku, gdy baseline zbiera się specjalnie przed projektem — nawet retrospektywnie za ostatnie trzy miesiące. Kluczowe jest, by istniał zanim wystartuje pilot.
W przypadku projektów, gdzie pomiar jest trudny (np. asystent AI wspierający procesy decyzyjne), istnieją pośrednie metryki proxy: czas od wpływu zapytania do ostatecznej decyzji, liczba iteracji potrzebnych do zatwierdzenia dokumentu, odsetek przypadków, w których wynik był bezpośrednio używalny bez edycji.
Co wchodzi w całkowite koszty
Tu właśnie większość wewnętrznych biznesowych uzasadnień zniekształca obraz rzeczywistości. Do prezentacji trafia cena tokenów API i ewentualnie licencja oprogramowania. Reszta jest przemilczana lub odkładana na później. Prawdziwe koszty projektu AI obejmują kilka warstw:
Wytworzenie i integracja
- Wewnętrzny czas inżynierów lub zewnętrzny dostawca odpowiedzialny za wytworzenie, integrację z istniejącymi systemami i testy
- Prototypowanie i eksperymenty, które nie trafiły do produkcji (są realnym kosztem projektu)
- Przygotowanie danych — czyszczenie, anotacja, strukturyzowanie danych wejściowych
Eksploatacja — tokeny i infrastruktura
W przypadku modeli cloud API są to koszty tokenów — przy prostym copilocie mogą być marginalne, przy rozwiązaniach agentic z dziesiątkami wywołań dziennie rosną szybko. W przypadku wdrożeń lokalnych jest to sprzęt (serwer GPU), energia i utrzymanie. Szczegółową kalkulację omawia artykuł o kosztach agenta AI w produkcji.
Ludzie i procesy
- Change management — czas na szkolenie, adaptację zespołu, zmianę workflow
- Przegląd i nadzór — przy wynikach trafiających do produkcji (umowy, raporty, e-maile) ktoś musi kontrolować. Ten czas jest w kalkulacjach ROI systematycznie niedoszacowany.
- Dostrajanie promptów systemowych, monitorowanie jakości, obsługa awarii i regresji
Utrzymanie i aktualizacje
Modele się zmieniają, API są aktualizowane, procesy firmowe ewoluują. Wdrożony system AI to nie gotowy produkt — to żywy komponent, który wymaga regularnego dostrajania. Realistyczny szacunek to 15–30 % rocznych kosztów eksploatacji w stosunku do pierwotnych kosztów wytworzenia.
Dobra wiadomość jest taka, że właśnie ten rejestr kosztów zmusza do dokładniejszego myślenia. Widzieliśmy projekty, w których po rozłożeniu na wszystkie pozycje okazywało się, że copilot dla jednego operatora jest efektywniejszy niż rozbudowany system multi-agent — ponieważ całkowite koszty były wielokrotnie niższe przy podobnym mierzalnym przyniesieniu korzyści.
Jak liczyć korzyści — ilościowe i jakościowe
Gdy macie baseline i koszty, następuje druga strona równania: mierzalne korzyści.
Bezpośrednie oszczędności
Najłatwiejsza do policzenia kategoria:
- Zaoszczędzony czas × stawka godzinowa = oszczędność na kosztach pracy. Jeśli agent zastąpi 4 godziny pracy ręcznej dziennie przy stawce 25 €/godz., roczna oszczędność wynosi ~26 000 €.
- Zmniejszona błędowość — jeśli kontrola dokumentów przez AI obniżyła odsetek błędów z 8 % do 2 %, policzcie koszt naprawy każdego błędu i pomnóżcie przez różnicę.
- Szybkość przetwarzania — skrócenie czasu od zapytania klienta do odpowiedzi można przełożyć na zmniejszenie liczby eskalacji lub zachowanie sprzedaży.
Korzyści pośrednie
Są realne, ale trudniejsze do zmierzenia. Należą do nich: zwiększona przepustowość zespołu (ludzie realizują zadania wyższej wartości zamiast rutynowych), wyższe zadowolenie klientów, szybsze podejmowanie decyzji. Uwzględnijcie te korzyści w uzasadnieniu biznesowym, ale nie wyrażajcie ich jako precyzyjnej liczby — kwantyfikujcie je ostrożnie lub określajcie jako jakościowe.
Wartość strategiczna
Niektóre projekty nie opłacają się czysto finansowo, ale mają wartość strategiczną: redukcja zależności od konkretnego dostawcy, zgodność z regulacjami (EU AI Act, RODO), poprawa infrastruktury danych, która ma wartość również dla innych projektów. Te korzyści są uprawnioną częścią uzasadnienia biznesowego — oznaczycie je jednak wyraźnie jako strategiczne, nie finansowe.
Payback i ROI — jak je czytać realistycznie
Gdy macie liczby, obliczenie jest proste:
- ROI (%) = (Łączne korzyści − Łączne koszty) / Łączne koszty × 100
- Okres zwrotu = Łączne koszty / Miesięczne korzyści
Miejscem, gdzie większość uzasadnień biznesowych się sypie, jest horyzont czasowy. 84 % dyrektorów generalnych realistycznie zakłada, że na pozytywny zwrot trzeba czekać dłużej niż 6 miesięcy. W przypadku złożonych przypadków użycia (nie tylko copilot, ale agentic workflow, RAG oparty na dokumentacji firmowej, integracja z ERP) realistyczny horyzont wynosi 12–24 miesiące. Piloty z paybackiem „poniżej trzech miesięcy" są realne wyłącznie przy bardzo prostych automatyzacjach z niskimi kosztami implementacji.
Kilka praktycznych wskazówek przy pracy z liczbami:
- 1.Używajcie konserwatywnych szacunków korzyści i realistycznych (nie optymistycznych) szacunków kosztów
- 2.Podajcie scenariusze: najlepszy przypadek, przypadek bazowy, najgorszy przypadek — z różnymi założeniami dotyczącymi adopcji
- 3.Oddzielcie koszty jednorazowe (wytworzenie, integracja) od powtarzających się (tokeny, utrzymanie, ludzie)
- 4.Nie zapomnijcie o fazie rozruchu — pierwsze miesiące po wdrożeniu są typowo mniej efektywne, dopóki zespół się nie zaadaptuje
Powiązany przegląd o tym, dlaczego piloty AI się nie udają, pokazuje, że brak mierzalnych celów przed startem jest jedną z najczęstszych przyczyn niepowodzenia.
Kiedy projekt nie ma uzasadnienia biznesowego
Uczciwa część każdych ram ROI to również decyzja, kiedy wdrożenie AI nie ma sensu. Widzieliśmy projekty, w których ta decyzja nie została podjęta na czas — a efektem było pół roku zmarnowanego czasu z zerowym wynikiem.
Sygnały, że projekt nie ma wystarczającego uzasadnienia biznesowego:
- Zbyt mała skala — jeśli agenda zajmuje zespołowi mniej niż 5 godzin tygodniowo, koszty wdrożenia i utrzymania rzadko osiągają zwrot w rozsądnym horyzoncie
- Brak danych — system AI bez wysokiej jakości danych wejściowych nie produkuje użytecznych wyników. Jeśli danych nie ma, najpierw zainwestujcie w infrastrukturę danych
- Proces nie jest zdefiniowany — AI automatyzuje proces, nie chaos. Jeśli ludzie nie potrafią opisać kroków, w jaki sposób wykonują zadanie ręcznie, AI go za nich nie rozwiąże
- Zbyt wysoki nadzór — jeśli każdy wynik AI musi przechodzić tak samo szczegółowy przegląd jak przed wdrożeniem AI, efektywna korzyść jest bliska zeru
Odrzucenie projektu na podstawie analizy ROI nie jest porażką — to zaoszczędzony czas i pieniądze, które można skierować tam, gdzie realny przypadek istnieje.
Miękkie korzyści — jak je przedstawić w uzasadnieniu biznesowym
Kategoria „miękkich korzyści" jest w prezentacjach używana do zakrycia słabej historii ilościowej. To nie znaczy, że nie istnieją — istnieją, ale muszą być nazwane inaczej.
Zamiast „poprawa zadowolenia klientów" napiszcie: „z badania przeprowadzonego przed wdrożeniem: 62 % klientów oceniało czas odpowiedzi jako zbyt długi; po wdrożeniu copilota średni czas odpowiedzi spadł z 4,2 godziny do 47 minut." To jest mierzalne — nawet jeśli jest to metryka proxy, a nie bezpośrednia liczba finansowa.
Zamiast „wyższa efektywność zespołu" napiszcie: „przed wdrożeniem zespół spędzał średnio 12 godzin tygodniowo na przygotowaniu raportów statusowych; po wdrożeniu 2,5 godziny." Jeśli nie potraficie tego przeliczyć na euro, podajcie to jako faktyczną oszczędność przepustowości — nie jako korzyść finansową.
Korzyści, które są naprawdę tylko odczuciowe (lepsze morale, bardziej nowoczesny wizerunek firmy), umieśćcie w sekcji strategicznej i nie przypisujcie im wartości liczbowej.
Monitorowanie ROI po wdrożeniu — dlaczego różni się od uzasadnienia biznesowego
Uzasadnienie biznesowe sporządza się przed projektem. Monitorowanie ROI po wdrożeniu to odrębna dyscyplina — i większość firm wykonuje ją jedynie powierzchownie.
Produkcyjny system AI powinien mieć metryki monitorowania na żywo, które są regularnie oceniane:
- Wolumen przetwarzanych zadań (i trend)
- Wskaźnik akceptacji wyników bez ludzkiej edycji (acceptance rate)
- Odsetek błędów lub eskalacji
- Rzeczywisty czas poświęcony na nadzór (w stosunku do pierwotnego założenia)
Te dane służą dwóm celom: po pierwsze, potwierdzają lub obalają założenia z uzasadnienia biznesowego; po drugie, pokazują, gdzie system degeneruje — model się starzeje, zmieniają się dane wejściowe, rośnie dryft względem pierwotnego przypadku użycia. Observability systemów AI to temat sam w sobie; podstawą jest logowanie każdego wejścia, wyjścia i decyzji agenta.
Dla firm, które rozważają kilka projektów AI równolegle, monitorowanie ROI na poziomie portfela jest kluczowe: nie tylko który projekt ma najwyższy ROI, ale też które projekty kanibalizują przepustowość zespołu bez mierzalnej korzyści.
Najczęstsze pytania
Jak zdefiniować baseline, gdy nie mamy danych historycznych?
Zbierajcie dane przed uruchomieniem pilota — nawet 4–6 tygodni wystarczy na odpowiednią próbkę dla większości procesów. Jeśli nie jest to możliwe, przeprowadźcie ustrukturyzowane wywiady z członkami zespołu: „Ile godzin tygodniowo poświęcacie na to zadanie? Ile przypadków obsługujecie miesięcznie?" Połączcie to z istniejącymi logami systemowymi (system ticketowy, metadane e-maili, zapisy ERP). Szacunek z jawnie nazwaną niepewnością jest lepszy niż brak baseline'u.
Jaki jest realistyczny horyzont zwrotu dla projektu AI w firmie przemysłowej?
Dla prostego copilota (asystent do dokumentacji, e-maili, raportowania): 6–12 miesięcy. Dla RAG opartego na dokumentacji firmowej lub analityki predyktywnej: 12–18 miesięcy. Dla złożonego systemu agentic zintegrowanego z ERP/SCADA: 18–36 miesięcy. Skrót „poniżej 6 miesięcy" jest uzasadniony wyłącznie przy niskich kosztach implementacji i dużej skali — na przykład gdy jeden agent zastępuje setki ręcznych operacji dziennie.
Jak uwzględnić w ROI koszty fine-tuningu lub infrastruktury RAG?
Tak — i powinny być wykazane oddzielnie od kosztów eksploatacji. Fine-tuning to koszt jednorazowy (przygotowanie datasetu, czas trenowania, ewaluacja), ale model wymaga okresowego odświeżania — planujcie coroczne powtórzenie. Infrastruktura RAG (baza wektorowa, pipeline embeddingów, dostrajanie retrieval) to koszt stały z niskim elementem zmiennym. Oba są inwestycją w fundament, który może służyć wielu przypadkom użycia — rozłóżcie je na projekty, które z nich korzystają.
Co zrobić, jeśli pilot pokazał korzyści, ale wdrożenie produkcyjne ich nie replikuje?
To częsty scenariusz — większość pilotów działa na starannie dobranych danych wejściowych i kontrolowanych warunkach. Pierwsze pytanie: jaki jest acceptance rate rzeczywistych wyników (bez edycji)? Jeśli wyraźnie spadł w stosunku do pilota, problemem jest albo przesunięcie rozkładu danych wejściowych, albo zakres pilota nie reprezentował rzeczywistej zmienności produkcyjnej. Rozwiązanie: analiza przypadków niepowodzeń, poszerzenie próbki treningowej lub zawężenie zakresu do podzbioru przypadków, w których system działa niezawodnie.
Kiedy warto przeprowadzić analizę build vs. buy przed wyliczeniem ROI?
Zawsze. ROI zależy od tego, czy system budujecie wewnętrznie, kupujecie gotowe rozwiązanie, czy łączycie oba podejścia. Każdy wariant ma inny profil kosztowy i inny payback. Szczegółowo build vs. buy omawia odrębny artykuł poświęcony tej decyzji — polecamy go jako krok wstępny przed finalizacją jakiegokolwiek uzasadnienia biznesowego.
*Jeśli pracujecie nad uzasadnieniem biznesowym dla projektu AI i potrzebujecie pomocy przy ustalaniu metryk, baseline'u lub modelu kosztowego — właśnie z tym pomagamy klientom z przemysłu, zanim przystąpią do wytwarzania. Skontaktujcie się z nami, by umówić bezpłatną konsultację.*