W polskiej logistyce sztucznej inteligencji używa 0,8 procent firm. To najniższy wynik ze wszystkich obszarów działalności zbadanych przez GUS w 2025 roku, przy 5,0 procent w marketingu i sprzedaży. Jeżeli prowadzisz firmę transportową albo spedycyjną, działasz w branży najmniej nasyconej tą technologią w kraju.
Zanim przejdziemy dalej, jedno rozróżnienie, bez którego połowa tego tekstu będzie o czymś innym, niż szukasz. Wyrażenie „AI software development” oznacza dwie różne rzeczy. Pierwsza to wytwarzanie oprogramowania z pomocą sztucznej inteligencji, czyli sytuacja, w której model pisze kod, a odpowiada za niego inżynier. Opisaliśmy ją osobno we wpisie o AI-assisted engineering. Druga to budowa systemu, który ma model w środku i używa go w codziennej pracy firmy. Ten tekst jest o drugiej.
Poniżej przebieg takiego projektu w pięciu etapach, widziany od strony zamawiającego. Do każdego etapu dołożyliśmy liczby z dwóch systemów, które zbudowaliśmy dla siebie, ponieważ przy własnych projektach możemy podać również to, co poszło źle.
Pięć etapów i miejsce, w którym projekty się zatrzymują
Projekt, w którym powstaje system z modelem w środku, przechodzi przez definicję problemu, pracę z danymi, budowę i integrację, odbiór oraz utrzymanie. Rozkład trudności jest inny, niż podpowiada intuicja: najdłuższy bywa etap drugi, a najdroższy w skali lat piąty.
Wiadomo także, gdzie projekty się zatrzymują. RAND Corporation w raporcie z sierpnia 2024 roku wymienia pięć przyczyn porażek, w kolejności od najczęstszej: źle zrozumiany lub źle zakomunikowany problem, brak odpowiednich danych, sięgnięcie po technologię zamiast rozwiązania problemu, brak infrastruktury do wdrożenia oraz problem zbyt trudny dla dzisiejszej techniki. Badanie jest jakościowe, oparte na 65 wywiadach z przemysłem i uczelniami, więc czyta się je jako opis mechanizmu, nie jako pomiar. Wniosek autorów brzmi jednak jednoznacznie: przyczyny są organizacyjne, a nie techniczne.
Etap 1: problem, nie technologia. I pytanie, czy model jest potrzebny
Pierwsze pytanie projektu nie brzmi „którego modelu użyjemy”, tylko „czy model jest tu do czegokolwiek potrzebny”. Reguły są tańsze, szybsze, przewidywalne i dają się wytłumaczyć audytorowi. Model ma sens wtedy, gdy wzorce są złożone albo zmienne, a danych jest dużo.
Dwa nasze systemy odpowiedziały na to pytanie przeciwnie.
W systemie finansowym Forteca kategoryzacja transakcji przebiega trzystopniowo. Najpierw reguły, potem historia wcześniejszych decyzji użytkownika, a dopiero na końcu model językowy. Model jest pytany wyłącznie o te transakcje, których dwa pierwsze stopnie nie rozpoznały, przez co odpowiada za ułamek rachunku i za ułamek ryzyka.
W systemie obsługi faktur było odwrotnie. Reguły wystarczają, gdy dokumenty przychodzą w przewidywalnej formie, a tam część faktur nie przychodzi wcale, część zaś ukrywa się w wiadomościach wyglądających jak potwierdzenia zakupu. Rdzeniem systemu musiał zostać model czytający treść wiadomości i wnioskujący, czego brakuje.
Ta sama firma, dwa projekty, dwie różne odpowiedzi. Progu liczbowego, od którego opłaca się model, nie policzył nikt, przynajmniej nie w sposób nadający się do zacytowania. Wzorzec, który powtarza się w praktyce, jest hybrydowy: model do rozpoznawania i przewidywania, reguły jako warstwa zabezpieczająca oraz ta część logiki, którą trzeba umieć wytłumaczyć.
Co z tego wynika dla Ciebie: poproś dostawcę o mapę procesu z zaznaczeniem, które decyzje podejmują reguły, a które model. Jeżeli model odpowiada za wszystko, ktoś nie zadał sobie tego pytania.
Etap 2: dane. Najdłuższy odcinek, którego nie ma w ofercie
Anaconda w badaniu z 2021 roku na próbie 2030 osób ustaliła, że przygotowanie i czyszczenie danych zajmuje 39 procent czasu specjalistów, czyli więcej niż trening modelu, wybór modelu i wdrożenie razem wzięte. W edycji z 2020 roku wychodziło około 45 procent. RAND wymienia brak odpowiednich danych jako drugą przyczynę porażek.
W ofertach ten etap zwykle nie występuje, ponieważ trudno go wycenić przed rozpoczęciem i nikt nie lubi zaczynać rozmowy od zdania „najpierw trzeba uporządkować Wasze dane”.
W systemie obsługi faktur osobnym krokiem projektu była kalibracja na danych z ostatnich miesięcy: rozpoznanie, który dostawca trafia do której skrzynki, odfiltrowanie regulaminów i potwierdzeń niebędących fakturami, parowanie biletów kolejowych z fakturami oraz liczenie przychodu według daty sprzedaży. To nie jest praca techniczna w potocznym rozumieniu, tylko właśnie ta, która decyduje o jakości wyniku.
Dla firmy transportowej z arkuszami kalkulacyjnymi i systemem odziedziczonym po poprzedniej dekadzie ten odcinek będzie najdłuższy. Sam proces wychodzenia z arkuszy opisaliśmy osobno, na przykładzie floty: jak wyeliminować Excel z zarządzania flotą. Tutaj też pojawia się ochrona danych osobowych. W Fortecy, zanim cokolwiek trafi do modelu językowego, system wycina z tytułu przelewu oraz z danych kontrahenta numery PESEL i telefony, a dane wrażliwe zamienia na skróty. Model dostaje tyle, ile potrzebuje do rozpoznania kategorii, i nic ponadto.
Etap 3: budowa. Model jest najmniejszą częścią systemu
Zespół badawczy Google opisał w 2015 roku na konferencji NeurIPS zjawisko, które nie zestarzało się do dzisiaj: kod odpowiadający za uczenie maszynowe stanowi mały fragment całości, a reszta to konfiguracja, zbieranie i weryfikacja danych, infrastruktura serwowania oraz monitoring. Autorzy piszą o powszechnych, znacznych kosztach utrzymania systemów uczących się w warunkach produkcyjnych. Przejście od demonstracji do produkcji jest trudniejsze niż samo zbudowanie demonstracji.
Nasze dwa przykłady pokazują rozpiętość, jaka się tu mieści.
System obsługi faktur powstał w dwie do trzech godzin czystej pracy. Było to jednak drugie podejście. Pierwsze, podjęte dwa do trzech miesięcy wcześniej, nie zakończyło się niczym, co dałoby się uruchomić. Różnicy nie zrobił lepszy model ani nowsze narzędzia, tylko zawężenie problemu oraz przeniesienie zmienności do pliku konfiguracyjnego, czyli do checklisty, którą można poprawić bez dotykania kodu.
Forteca zajęła 20 do 30 godzin pracy jednej osoby, przy czym działający system stanął na produkcji pierwszego dnia, a pozostały czas poszedł na kolejne funkcje oraz 34 poprawki w dwóch transzach.
Etap 4: odbiór. Jak sprawdzić, że to działa, zanim podpiszesz
Tutaj system z modelem w środku różni się od zwykłego oprogramowania najbardziej. Program księgowy albo działa poprawnie, albo ma błąd. System oparty na modelu ma skuteczność, a to znaczy, że odbiór polega na pomiarze, a nie na obejrzeniu demonstracji.
Skuteczność automatycznej kategoryzacji w Fortecy wynosi 94,7 procent i została zmierzona na 720 transakcjach z dwunastu miesięcy. Podanie liczby przypadków jest tu równie istotne jak sam wynik, ponieważ te same 94,7 procent uzyskane na trzydziestu transakcjach nie znaczyłoby nic.
W systemie obsługi faktur odbiór wyglądał inaczej, bo inny był materiał. Przeprowadziliśmy test wsteczny na miesiącu już zamkniętym, porównując wynik systemu z folderem prowadzonym przez biuro rachunkowe. System zebrał automatycznie 23 z 27 kosztów oraz 2 z 2 przychodów. Pozostałe cztery pozycje zostały świadomie po stronie człowieka. Osobno działa bramka decyzji: dokumenty spoza listy trafiają do przeglądu, a w testowanym miesiącu było ich pięć i wszystkie zostały odrzucone jako oferty, duplikat, koszt prywatny oraz faktura pro forma.
Co z tego wynika dla Ciebie: metryka bez podanej próby niewiele znaczy, również nasza. Pytaj o liczbę przypadków, o okres, z którego pochodzą, oraz o to, co system robi z tym, czego nie rozpoznał. Odpowiedź „przekazuje do decyzji człowieka” oznacza, że ta ścieżka została zaprojektowana; odpowiedź „zgaduje” oznacza, że nie.
Etap 5: utrzymanie, czyli rachunek, który biegnie dalej
Dwie rzeczy dzieją się po wdrożeniu i rzadko trafiają do rozmowy przed podpisaniem umowy.
Model traci jakość z upływem czasu. Zespół badaczy z Harvard Medical School, MIT oraz Whitehead Institute opisał to w 2022 roku w „Scientific Reports” na 32 zbiorach danych z czterech branż, w tym z transportu. Degradacja bywa stopniowa, bywa gwałtowna, a co istotniejsze, nie daje się wyjaśnić wyłącznie zmianami w danych wejściowych. Monitoring skuteczności oraz zaplanowany ponowny trening są więc częścią systemu, a nie dodatkową usługą.
Rachunek zależy od liczby zapytań, nie od ceny modelu. Koszt jednostkowy spadł w tempie, które trudno porównać z czymkolwiek w informatyce: według raportu AI Index przygotowanego przez Stanford HAI w 2025 roku cena za milion tokenów dla poziomu jakości odpowiadającego GPT-3.5 spadła z 20 dolarów w listopadzie 2022 roku do 7 centów w październiku 2024. Argument „poczekam, aż to stanieje” jest więc spóźniony o dwa lata. Rośnie natomiast to, ile razy dziennie system pyta model.
Nasze rachunki wyglądają tak. Utrzymanie Fortecy kosztuje 0,65 dolara miesięcznie, przy czym audyt zgodności infrastruktury pochłania 0,61, przechowywanie plików 2 centy, a model kategoryzujący wszystkie transakcje kolejne 2 centy. System obsługi faktur kosztuje około 0,42 dolara miesięcznie, z czego 0,40 to przechowywanie sekretów, czyli haseł i kluczy do skrzynek.
W obu przypadkach model jest najtańszą pozycją rachunku, a płaci się za infrastrukturę i za zgodność. Skala tych systemów jest niewielka, bo obsługują jedną firmę, i przy tysiącach zapytań dziennie proporcje się zmienią. Kierunek pozostaje jednak ten sam: pytanie „ile kosztuje model” jest mniej istotne niż pytanie „ile razy dziennie będziemy go pytać oraz co jeszcze musi wokół niego działać”.
Ile takich projektów zawodzi. Cztery liczby, które nie są porównywalne
W obiegu funkcjonują cztery statystyki i bywają używane zamiennie, mimo że mierzą różne rzeczy na różnych próbach.
95 procent pilotaży generatywnej AI nie przynosi mierzalnego zwrotu w rachunku wyników. Liczba pochodzi z raportu MIT Project NANDA z 2025 roku, opartego na 52 wywiadach z kadrą kierowniczą, 153 odpowiedziach ankietowych oraz przeglądzie ponad 300 publicznych wdrożeń. Raport jest wstępny i nierecenzowany, a przyjęta definicja sukcesu jest wąska, ponieważ dotyczy wpływu na rachunek wyników, a nie tego, czy projekt się udał.
Ponad 80 procent projektów AI zawodzi, mniej więcej dwa razy częściej niż projekty informatyczne bez AI. Tak podaje raport RAND z 2024 roku, oparty na 65 wywiadach, czyli badanie jakościowe.
42 procent firm porzuca większość swoich inicjatyw AI, wobec 17 procent rok wcześniej. Dane pochodzą z badania S&P Global Market Intelligence z 2025 roku obejmującego ponad tysiąc firm w Ameryce Północnej i Europie. Średnio 46 procent projektów pilotażowych nie dochodzi do produkcji.
85 procent to najczęściej przekręcana z tych liczb. Gartner ogłosił w styczniu 2019 roku prognozę, zgodnie z którą do 2022 roku 85 procent projektów AI będzie dawać błędne wyniki z powodu uprzedzeń w danych, algorytmach albo w zespołach. Prognoza dotyczyła jakości wyników, a nie upadku projektów, i była prognozą, a nie pomiarem.
Uśrednianie tych liczb daje wartość, która nie opisuje niczego. Wspólny wniosek jest natomiast spójny z raportem RAND i brzmi tak, że projekty przewracają się na definicji problemu, na danych i na braku przygotowania organizacji, a nie na jakości modelu.
Umowa i zgodność: co negocjować, skoro standardu nie ma
Umowa wdrożeniowa w informatyce ma charakter mieszany, łącząc elementy umowy o dzieło z umową starannego działania. Przy systemie opartym na modelu dostawca będzie naciskał na model starannego działania, korzystniejszy dla siebie, ponieważ trudno zagwarantować rezultat w postaci określonej skuteczności. Zamawiającemu zostają do wynegocjowania trzy rzeczy: definicja odbioru, mierzalne progi jakości oraz zobowiązanie do ponownego treningu, gdy skuteczność spadnie poniżej ustalonego poziomu.
Gotowych wzorców takich klauzul w polskim obrocie nie ma, podobnie jak orzecznictwa dotyczącego skuteczności modelu. Jest to luka rynkowa, a nie zaniedbanie po stronie dostawcy, natomiast pierwszy projekt lepiej rozpisać na etapy z odbiorem po każdym z nich niż na jeden odbiór końcowy.
Po stronie zgodności z prawem zamawiającego dotyczą trzy rzeczy z rozporządzenia o sztucznej inteligencji. Obowiązek zapewnienia kompetencji w zakresie AI osobom obsługującym takie systemy działa od 2 lutego 2025 roku i obejmuje każdy poziom ryzyka, czyli także zastosowania najprostsze. Artykuł 25 opisuje sytuację, w której firma korzystająca z cudzego systemu staje się jego dostawcą wraz z całą listą obowiązków, na przykład wtedy, gdy istotnie go modyfikuje albo umieszcza na nim własną markę. Obowiązki dla systemów wysokiego ryzyka wejdą 2 grudnia 2027 roku, po przesunięciu terminu pakietem Digital Omnibus. Typowy system operacyjny firmy, czyli obsługa zleceń transportowych, obieg faktur albo panel produkcji, nie jest systemem wysokiego ryzyka. Klasyfikacja zależy jednak od zastosowania, a nie od technologii, więc na przykład narzędzie wspierające rekrutację kierowców będzie traktowane inaczej.
Gdzie naprawdę jest polski rynek
Sztucznej inteligencji używa 8,7 procent polskich firm, wobec 5,9 procent rok wcześniej. Najczęstszym sposobem jej pozyskania jest zakup gotowego rozwiązania komercyjnego, który deklaruje 6,4 procent firm. Zlecenie budowy na zewnątrz pozostaje najrzadsze i dotyczy 2,1 procent. Polski Instytut Ekonomiczny dodaje do tego obrazu, że 77 procent firm niekorzystających z AI nie planuje wdrożenia, dopóki nie stanie się ono konieczne.
W większości przypadków kupienie gotowego narzędzia jest dobrą decyzją. Abonament kosztuje mniej niż projekt, wdraża się szybciej, a odpowiedzialność za utrzymanie zostaje po stronie producenta. Porównanie trzech dróg dla firmy z flotą, czyli software house’u, abonamentu i systemu dedykowanego, opisaliśmy we wpisie o wyborze między nimi.
Budowa własnego systemu ma sens w dwóch sytuacjach. Pierwsza to proces, który stanowi Twoją przewagę i którego nie chcesz upodabniać do procesu konkurencji korzystającej z tego samego abonamentu. Druga to sytuacja, w której gotowe narzędzie nie zna Twoich danych, ponieważ pracujesz na własnym układzie zleceń, tras albo dokumentów, a próba dopasowania go do standardu kosztuje więcej niż zbudowanie rzeczy pod siebie. Rozróżnienie czterech rodzajów oprogramowania z AI opisaliśmy w osobnym wpisie o rodzajach oprogramowania AI, a wybór dostawcy na stronie o AI software house.
Najczęstsze pytania
Czym jest AI software development? Budową oprogramowania, które używa modelu uczącego się w swojej codziennej pracy: do rozpoznawania dokumentów, klasyfikacji, przewidywania albo generowania treści. Wyrażenie bywa też używane w drugim znaczeniu, czyli wytwarzania oprogramowania z pomocą AI, i wtedy dotyczy metody pracy zespołu, a nie produktu.
Co wchodzi w zakres takiego projektu? Definicja problemu wraz z decyzją, czy model jest potrzebny, praca z danymi, budowa i integracja z systemami, które już masz, odbiór z pomiarem skuteczności oraz utrzymanie obejmujące monitoring i ponowny trening.
Czy potrzebuję własnego modelu? W większości zastosowań biznesowych nie. Systemy budowane dzisiaj korzystają z modeli dostępnych przez interfejs programistyczny, a praca projektowa polega na tym, co dzieje się wokół modelu: na danych, regułach, zabezpieczeniach i integracji.
Ile kosztuje utrzymanie? Zależy od liczby zapytań oraz od tego, jakie elementy otaczają model. W naszych dwóch systemach obsługujących jedną firmę rachunek wynosi 0,65 oraz 0,42 dolara miesięcznie, a model odpowiada w nim za około 2 centy. Przy większej skali proporcje się zmieniają, natomiast pytanie pozostaje to samo: ile razy dziennie system pyta model.
Co się dzieje z moimi danymi? To ustala się na etapie projektu i zapisuje w umowie. W Fortecy dane wrażliwe są usuwane albo zamieniane na skróty, zanim cokolwiek trafi do modelu, więc model widzi tylko to, co jest potrzebne do rozpoznania kategorii.
Skąd mam wiedzieć, że system działa? Z pomiaru na Twoich danych, wykonanego przed odbiorem, z podaną liczbą przypadków oraz z opisem tego, co system robi z sytuacjami, których nie rozpoznał.
Od czego zacząć
Od jednego procesu, który zabiera czas co miesiąc i który potrafisz opisać w trzech zdaniach. Jeżeli po opisaniu okaże się, że wystarczą reguły, to jest dobry wynik takiej rozmowy, a nie jej porażka.
Sprawdź, czy Twój proces potrzebuje modelu
Bezpłatny audyt cyfrowy trwa jeden do dwóch dni i kończy się diagnozą, nie ofertą. Usłyszysz również wtedy, gdy wystarczą reguły i model nie jest do niczego potrzebny.
Umów bezpłatny audyt →
