Agentowa AI w ERP: co naprawdę zmierzył architekt SAP-a

Najciekawsza liczba to ta, która wygląda źle

15 października 2025 r. IEEE Access opublikował pracę Siara Sarferaza, głównego architekta oprogramowania w dziale badań i rozwoju ERP w SAP-ie. Opisuje ona framework do budowy agentowej AI wewnątrz systemu ERP, wyprowadzony z analizy 26 przypadków użycia agentowej AI z różnych modułów ERP i sprawdzony na działającym wdrożeniu w ERP SAP-a.

Diagram architektury nie jest tu najciekawszy. Taki diagram ma dziś każdy dostawca.

Najciekawsze jest porównanie schowane w części ewaluacyjnej. Scenariusz dotyczy sporów rozliczeniowych: agent czyta reklamacje, konfrontuje je z warunkami umowy i proponuje faktury korygujące. Klasyfikował spory poprawnie w 81,7% przypadków. Podejście nieagentowe osiągnęło w tych samych kontrolowanych testach 97,3%.

To architekt dostawcy publikujący liczbę, która podkopuje najprostszą wersję narracji sprzedażowej. Autor pisze wprost, że skuteczność jest „akceptowalna, ale nie przewyższyła podejścia nieagentowego”. Właśnie dlatego warto uważnie przeczytać resztę pracy.

Praca broni systemu hybrydowego, nie autonomicznego

Ujęcie jest ostrożniejsze niż branżowa rozmowa, która się wokół niego toczy. Procesy w ERP są bardzo różne: część jest ustrukturyzowana i oparta na regułach, część niejednoznaczna i zależna od danych. Klasyczne programowanie jest dla pierwszej grupy niezawodne i wyjaśnialne. Agenci radzą sobie z nieustrukturyzowanym wejściem w drugiej. Wniosek to system hybrydowy, a nie zamiana logiki deterministycznej na probabilistyczną.

Praca odnotowuje też coś, co rzadko przetrwa prezentację produktu: w kontekście ERP człowiek zwykle pozostaje w pętli decyzyjnej ze względu na zgodność z prawem.

Pytanie przy szacowaniu projektu nie brzmi więc, czy agent bije kod. Brzmi, które decyzje faktycznie wymagają oceny nieustrukturyzowanego wejścia, a które są tylko regułami, których nikt jeszcze nie zapisał.

Co agent od sporów zrobił dobrze, a gdzie zawiódł

Scenariusz jest mały i konkretny: abonent płacący 200 € miesięcznie widzi na fakturze 211,40 € i pisze reklamację, podczas gdy umowa dopuszcza 2% podwyżki rocznie, czyli do 204 €. Agent musi przeczytać wiadomość, zdecydować, czy to spór, otworzyć sprawę, sięgnąć po historię rozliczeń i warunki umowy, wyliczyć różnicę 7,40 € i zaproponować fakturę korygującą.

Raportowane wyniki dzielą się wyraźnie na dwie grupy.

Gdzie agent wypadł dobrze:

• Przepustowość. Paczkę 1000 historycznych spraw przeanalizowano w 0,9 godziny, wobec szacowanych 128 godzin pracy ludzkiej przy podejściu nieagentowym. Porównanie nie obejmuje czasu potrzebnego na weryfikację wyników agenta, a przy tej skuteczności taka weryfikacja jest konieczna (o tym w sekcji 03).
• Koszt. Wydatek operacyjny na rozstrzygnięty spór spadł o 67%.
• Opóźnienia. Autor pisze, że standardowa analiza sporu mieściła się poniżej 1000 ms, ale w tym samym zdaniu podaje, że w docelowym progu zmieściło się 81% prostych spraw, więc pierwszą deklarację trzeba czytać jako typową, a nie jako regułę. Złożone spory obejmujące kilka umów trwały średnio około 3100 ms. Praca określa to jako wynik „znacznie poniżej” progu 3000 ms dla interakcji złożonych, choć w rzeczywistości jest nieco powyżej niego.
• Skalowanie. Testy obciążeniowe z symulowanymi 50–500 równoległymi sprawami wykazały liniowe skalowanie: średni czas odpowiedzi wzrósł z 847 ms do 2340 ms.

Gdzie zawiódł i dlaczego:

• 12,3% awarii w obsłudze sporów wynikało z niekompletnego parsowania wiadomości e-mail.
• 5,8% z nieprawidłowych odwołań do danych umownych.
• 3,2% z przekroczeń czasu po stronie modelu generatywnego w szczycie obciążenia.

Praca przedstawia te wartości jako udziały w awariach, ale sumują się one do 21,3%, a nie do 100%, i tekst nie wyjaśnia tej różnicy. Traktujmy je więc jako wagi względne, a nie pełny rozkład.

Warto przeczytać te tryby awarii jeszcze raz. Tylko przekroczenia czasu są czysto infrastrukturalnym problemem. Niekompletne parsowanie maili jest po części problemem modelu, bo czytanie nieustrukturyzowanych wiadomości to właśnie zadanie agenta, ale też skutkiem chaotycznego, niekompletnego wejścia. Nieprawidłowe odwołania do danych umownych to problem jakości danych w samym ERP. Dwa z trzech trybów awarii pojawiają się na styku agenta z danymi, czyli tam, gdzie od zawsze zawodzą projekty integracyjne. Środki zaradcze opisane w pracy wskazują ten sam kierunek: ostrzejsza walidacja danych, awaryjne ścieżki wykonania i ciągłe douczanie modelu na przypadkach błędów.

81,7% to liczba do triażu, nie do wykonania

Wskaźnik skuteczności znaczy coś dopiero wtedy, gdy zestawi się go z konsekwencjami błędu.

Przy 81,7% agent, który przygotowuje wstępną klasyfikację do zatwierdzenia przez pracownika, jest naprawdę użyteczny. Mniej więcej cztery na pięć spraw trafiają do człowieka już przeanalizowane, a on weryfikuje wynik, zamiast zaczynać od zera. W tym trybie zysk z przepustowości ma sens, choć do 0,9 godziny trzeba doliczyć czas weryfikacji.

Przy 81,7% agent, który wystawia faktury korygujące bez weryfikacji, jest ryzykiem. Mniej więcej co piąta decyzja błędna, na dużą skalę, w finansach.

Rozwiązanie opisane w pracy to uwzględnia. Agent może wygenerować fakturę korygującą automatycznie, ale tylko w ramach zdefiniowanych progów akceptacji. Przy mniejszych kwotach może ją wystawić bez udziału człowieka. Sprawy złożone i wymagające oceny wykraczającej poza zdefiniowane parametry agenta trafiają do pracownika.

To jest ten prawdziwy wzorzec projektowy i nie jest efektowny: autonomia rośnie odwrotnie do stawki. Decyzje tanie, odwracalne i masowe idą do agenta. Kosztowne albo nieodwracalne trafiają do człowieka. Praca inżynierska polega na precyzyjnym wyznaczeniu tej granicy i jej egzekwowaniu, a nie na modelu.

Model jest najtańszą częścią systemu

Praca podaje twarde liczby dotyczące narzutu w czasie działania, zmierzone w kontrolowanych środowiskach testowych ERP, i są one niewielkie.

• Koszt inferencji między 0,002 a 0,008 dolara na jedno wywołanie agenta, zależnie od złożoności promptu i klasy modelu.
• Około 1,2 GB dodatkowej pamięci na 100 równolegle działających agentów.
• Wzrost obciążenia CPU o 1–2% na orkiestrację, zarządzanie stanem i obsługę API.
• 50–80 KB ruchu sieciowego na wywołanie.

Gdyby to był cały koszt, każdy ERP byłby już pełen agentów.

Nie jest i praca pokazuje, dlaczego. Zanim przejdzie do architektury, wylicza dwadzieścia wymagań wyprowadzonych z tych 26 przypadków użycia. Wybór:

• Zgodność prawna. Ochrona danych, zgody, logowanie dostępu do odczytu i mechanizmy, dzięki którym audytor może sprawdzić, jak agent podjął decyzję.
• Walidacja treści. Kontrola tego, co wchodzi do agenta i co z niego wychodzi, wraz z ochroną przed wejściem przygotowanym pod atak.
• Obsługa błędów. Logowanie, monitoring anomalii i ścieżki awaryjne na wypadek, gdy agent zwróci niewiarygodny wynik.
• Wyjaśnialność. Prześledzalna logika i źródła danych za każdą rekomendacją, przechowywane na tyle rzetelnie, by przetrwać kontrolę regulatora.
• Rozszerzalność. Rozszerzenia klienta, które muszą przetrwać aktualizacje produktu.
• Cykl życia, skalowalność, rozliczanie użycia, lokalizacja, konfiguracja, przetwarzanie masowe.

Ta lista to jest właściwy projekt. Agent to jego niewielka część. Sekcja ograniczeń w tej samej pracy mówi to samo z drugiej strony: dodatkowe środowiska uruchomieniowe i warstwy orkiestracji podnoszą złożoność systemu, wprowadzają ryzyko opóźnień przy dużym obciążeniu i tworzą narzut administracyjny, który zamienia się w dług technologiczny, jeśli nikt nim nie zarządza.

Jeden argument w pracy się nie broni

Autor twierdzi, że skoro wszystkie języki programowania są zupełne w sensie Turinga, framework sprawdzony w SAP-owym środowisku ABAP da się odtworzyć na dowolnej innej platformie ERP. Dla języków ogólnego przeznaczenia to formalnie prawda, ale praktyczny wniosek z tego nie wynika. Zupełność Turinga mówi, że platforma docelowa potrafi wyrazić tę logikę. Nie mówi nic o tym, czy istnieje tam odpowiednik środowiska uruchomieniowego, modelu uprawnień, warstwy metadanych i infrastruktury audytowej. Kilka zdań dalej autor sam przyznaje, że praktyczne przeniesienie wymaga systematycznego mapowania architektury i uwzględnienia ograniczeń konkretnej platformy.

Ograniczenia podane w pracy warto przenieść do każdego planu projektu. Ewaluacja obejmuje głównie krótkoterminową wykonalność, poprawność techniczną i pierwsze wdrożenie. Długoterminowe utrzymanie i dryf modelu autor wskazuje jako kwestie otwarte, a zarządzania zmianą, akceptacji użytkowników, nadzoru nad AI i ładu zarządczego w ogóle nie badał.

Pytanie brzmi, który proces się kwalifikuje, a nie który produkt kupić

Nic w tej pracy nie sugeruje, że wystarczy podłączyć agenta do ERP i czekać. Opisany scenariusz nie jest zarezerwowany dla jednego dostawcy, a o tym, czy zadziała, decyduje charakter procesu, nie produktu.

Proces jest sensownym kandydatem, gdy większość poniższych jest prawdziwa:

• Wejście jest naprawdę nieustrukturyzowane: e-maile, notatki, dokumenty, skany formularzy.
• Wolumen jest na tyle duży, że godziny ludzkiej pracy to realny koszt.
• Poprawną odpowiedź da się zweryfikować wobec danych, które system już posiada.
• Błędna odpowiedź zostanie wychwycona, zanim wyrządzi szkodę, przez próg, akceptację albo uzgodnienie.
• Istnieje już ślad audytowy, w który da się wpisać decyzje agenta.

Proces jest złym kandydatem, gdy reguły są znane i stabilne, gdy błędna odpowiedź nieodwracalnie przesuwa pieniądze, gdy prawdziwym problemem jest jakość danych albo gdy nikt nie umie powiedzieć, co znaczy „poprawnie”, na tyle dokładnie, żeby to zmierzyć. Ten ostatni przypadek jest najczęstszy: większość operacji, które chcą agenta, najpierw potrzebuje kogoś, kto zapisze decyzję, jaką ten agent miałby podejmować.

Zapytaj, na czym proces stoi w tej chwili

Ta praca jest wartościowa, bo jest wystarczająco konkretna, żeby się z nią spierać: działająca architektura, zmierzony scenariusz, profil kosztowy, uczciwie podana luka w skuteczności i lista tego, czego nie sprawdzono.

Wniosek nie brzmi „dodajcie agentów do ERP”. Brzmi tak: deterministyczne części operacji nadal lepiej obsługuje deterministyczne oprogramowanie, a agent zarabia na siebie tam, gdzie proces zatrzymuje się na człowieku czytającym coś nieustrukturyzowanego, zanim można zastosować jakąkolwiek regułę. To znacznie mniejszy cel, niż sugeruje nazwa całej kategorii. I jest do zbudowania.

W TailoredByte właśnie tak szacujemy takie projekty: znajdujemy konkretną decyzję, która blokuje proces, sprawdzamy, czy jej wynik da się skonfrontować z danymi, które firma już ma, i obudowujemy deterministyczną logiką te fragmenty, które nigdy nie potrzebowały modelu. W tym kierunku rozwijamy też własne rozwiązanie: warstwę integracyjną, która obejmuje wszystkie systemy firmy, zamiast siedzieć w jednym z nich, tak żeby agent mógł sprawdzić własną odpowiedź wobec wszystkiego, co firma już wie, zanim cokolwiek zrobi. Więcej o tym jeszcze w tym roku.

Najczęstsze pytania

Czy agent w ERP potrzebuje dostępu do danych poza ERP?

Często tak, a częściowo przemawia za tym opublikowana analiza błędów. Główne przyczyny awarii to niekompletne parsowanie maili i nieprawidłowe odwołania do danych umownych. Agent, który może porównać swoją odpowiedź z większą liczbą rejestrów firmy, w ERP i poza nim, ma więcej okazji, by wychwycić własny błąd, zanim trafi on do klienta. Praca nie testuje tego wprost; to nasza interpretacja jej analizy błędów.

Czy agentowa AI jest lepsza od klasycznej automatyzacji w ERP?

Nie pod względem skuteczności, jeśli trzymać się opublikowanych danych. W ewaluacji sporów rozliczeniowych podejście agentowe klasyfikowało sprawy poprawnie w 81,7% przypadków, wobec 97,3% dla podejścia nieagentowego (praca nie opisuje szczegółowo, na czym polegało to drugie). Przewagą agenta była przepustowość (1000 spraw w 0,9 godziny wobec szacowanych 128 godzin pracy ludzkiej) i o 67% niższy koszt operacyjny rozstrzygnięcia sporu.

Gdzie agenci AI w ERP faktycznie zawodzą?

W raportowanej analizie błędów największy udział miało niekompletne parsowanie przychodzących wiadomości, potem nieprawidłowe odwołania do danych umownych, a przekroczenia czasu modelu były dopiero na trzecim miejscu. Dwa z trzech trybów dotyczą styku agenta z wejściem i danymi, a nie samego rozumowania modelu.

Ile kosztuje utrzymanie agentów AI w ERP?

Koszt działania jest niski: około 0,002–0,008 dolara na wywołanie agenta, przy około 1,2 GB dodatkowej pamięci na 100 równoległych agentów i wzroście obciążenia CPU o 1–2%. Prawdziwy koszt siedzi w zgodności prawnej, logowaniu audytowym, wyjaśnialności, obsłudze błędów, ścieżkach awaryjnych, zarządzaniu cyklem życia i rozszerzeniach, które przetrwają aktualizację.

Czy agent w ERP może decydować bez akceptacji człowieka?

W określonych granicach, a granice powinny wynikać z konsekwencji błędu. Opisany framework pozwala agentowi automatycznie wystawiać faktury korygujące na niskie kwoty w ramach zdefiniowanych progów, a sprawy złożone przekazuje pracownikom. W procesach regulowanych człowiek w pętli jest zwykle wymogiem zgodności, nie preferencją projektową.

Czy ten framework jest specyficzny dla SAP-a?

Wdrożenie tak. Autor argumentuje przenośność tym, że wszystkie języki programowania mają równą siłę wyrazu, ale w praktyce przenośność zależy od tego, czy platforma docelowa oferuje porównywalne środowisko uruchomieniowe, uprawnienia, metadane i infrastrukturę audytową. Sam autor przyznaje, że wymaga to systematycznego mapowania architektury i uwzględnienia ograniczeń danej platformy.