← Blog / Strategia i koszty

Dlaczego wdrożenia AI utykają między pilotażem a produkcją

Opublikowano: 21 września 2026 Aktualizacja: 14 października 2026

59% średnich i dużych firm w Polsce deklaruje formalną strategię lub roadmapę AI, a mimo to mniej więcej połowa doświadcza rozczarowania albo niepełnego zwrotu z inwestycji, wynika z trzeciej edycji raportu EY „Jak polskie firmy wdrażają AI?”, opartej na odpowiedziach 497 firm. Piotr Ciepiela z EY Polska opisuje to jako problem „ostatniej mili”: zbudowanie prototypu jest relatywnie proste, a wdrożenie AI do codziennej pracy zespołów stanowi 90% wysiłku. Podobny obraz daje sierpniowe badanie SAP Polska na próbie 411 osób na stanowiskach kierowniczych: 70% z nich mówi, że AI jest wpisana w strategię ich obszaru, ale zwrot z inwestycji analizuje tylko 28%, a 30% widzi u siebie wdrożenia fasadowe, w których narzędzia są dostępne, lecz używane okazjonalnie.

EY tłumaczy rozczarowania przede wszystkim słabym zarządzaniem zmianą. Ten tekst dotyczy innej części wysiłku opisanego w raporcie, którą w firmach z SAP i Salesforce najczęściej się niedoszacowuje: warstwy integracji, czyli tego, skąd model bierze dane, kto odpowiada za połączenie i gdzie trafia wynik.

Pilotaż na eksporcie nie mówi nic o produkcji

Typowy pilotaż wygląda tak: ktoś z działu sprzedaży lub controllingu wyciąga z SAP listę zamówień, otwartych pozycji albo historii reklamacji, zapisuje ją do pliku, a zespół innowacji podłącza ten plik do modelu. Wyniki są dobre, bo dane zostały wybrane ręcznie, są z jednego dnia i nikt nie musiał pytać o uprawnienia. Na komitecie sterującym prezentacja wypada przekonująco.

W produkcji ten sam przypadek użycia potrzebuje stanu z tej chwili: czy klient ma blokadę kredytową, czy towar jest w magazynie, czy zamówienie już wyszło z rampy. Eksport tego nie zapewni. Trzeba wywołania API, które działa przy kilku tysiącach zapytań dziennie, ma obsługę błędów i nie obciąża systemu w godzinach zamknięcia miesiąca. Tego elementu w pilotażu zwykle nie ma, więc koszt i czas wdrożenia są liczone bez niego.

Raport MIT The GenAI Divide z 2025 roku opisuje ten sam lejek w skali globalnej: 60% organizacji oceniało narzędzia AI klasy enterprise, do pilotażu doszło 20%, a do produkcji 5%. Autorzy przypisują większość porażek kruchym procesom, braku kontekstu i niedopasowaniu do codziennej pracy, a o rozwiązaniach budowanych na zamówienie piszą wprost, że stają z powodu złożoności integracji.

Dochodzi do tego zmiana po stronie SAP. W polityce API opublikowanej 27 kwietnia 2026 roku SAP zastrzega, że masowa ekstrakcja danych i integracja z autonomicznymi agentami AI mają przechodzić przez architektury, które SAP wskazuje: A2A do agentów Joule, MCP Gateway w SAP Integration Suite oraz SAP Business Data Cloud. Poprawka bezpieczeństwa udostępniona 9 czerwca 2026 roku blokuje wyprowadzanie danych do narzędzi zewnętrznych przez ODP i RFC, a firmy, które z tej drogi korzystają, mogą ją czasowo zawiesić najdłużej do 31 grudnia 2026 roku. Pilotaż zasilany replikacją przez ODP-RFC może więc działać dziś i nie mieć drogi do produkcji w tej samej postaci.

Warto oddzielić to od jakości danych pod AI. Dane mogą być uporządkowane i nadal nieosiągalne w momencie, w którym proces ich potrzebuje.

Interfejs bez właściciela

Pilotaż AI prowadzi zwykle zespół, który nie odpowiada ani za SAP, ani za Salesforce: dział innowacji, zespół danych, czasem dostawca z zewnątrz. Zespół SAP dowiaduje się o projekcie, gdy trzeba założyć użytkownika technicznego, a administrator Salesforce, gdy agent ma zapisywać coś w obiekcie Case.

Weźmy agenta w Salesforce, który odpowiada handlowcom o status zamówienia, pobierając go z S/4HANA przez SAP Integration Suite. Agent należy do zespołu CRM, iFlow do zespołu integracji, definicja statusu do działu obsługi zamówień, a użytkownik techniczny do bezpieczeństwa. Kiedy po aktualizacji S/4HANA odpowiedź API zmieni strukturę albo integracja zacznie zwracać błędy o drugiej w nocy, żadna z tych czterech grup nie odpowiada za naprawę całości. Handlowiec widzi tylko, że agent przestał odpowiadać.

EY zwraca uwagę, że projekty AI funkcjonują często jako inicjatywy technologiczne, a nie inwestycje biznesowe, przez co trudno przypisać je do KPI i P&L. Interfejs bez właściciela jest technicznym odpowiednikiem tego samego zjawiska: nikt nie ma budżetu na jego monitoring, testy regresji po aktualizacji ani zużycie komunikatów w Integration Suite.

Wynik, który nie wraca do procesu

Drugie miejsce, w którym wdrożenia utykają, jest na końcu łańcucha. Model generuje rekomendację w osobnym oknie czatu, a pracownik przepisuje ją do SAP albo nie przepisuje wcale. Wdrożenia fasadowe z badania SAP Polska, w których narzędzie jest dostępne, ale używane okazjonalnie, bywają skutkiem właśnie tego: skorzystanie z wyniku jest dodatkową pracą poza procesem.

Wynik AI ma wartość dopiero wtedy, gdy zmienia coś w systemie, w którym toczy się proces. Klasyfikacja reklamacji powinna ustawić kategorię i priorytet w obiekcie Case w Salesforce, tak żeby reguły przydziału i Flow zadziałały same. Propozycja blokady płatności dla podejrzanej faktury dostawcy powinna trafić do SAP jako powód blokady na dokumencie, z informacją, że zaproponował ją model, a zatwierdził konkretny człowiek. Podsumowanie historii klienta przed rozmową handlową ma sens w karcie szansy sprzedaży, do której handlowiec i tak zagląda przed spotkaniem.

Każdy taki zapis zwrotny to osobna integracja, z tymi samymi wymaganiami co każda inna: wywołanie udostępnionego API, obsługa odrzucenia przez SAP (zablokowany klient, zamknięty okres księgowy), ochrona przed podwójnym zapisem przy ponowieniu i ślad audytowy pokazujący, czy zmianę wprowadził człowiek, czy agent. W pilotażu tej części zwykle nie ma, bo pilotaż kończy się na pokazaniu odpowiedzi.

Bez zapisu w systemie trudno też cokolwiek zmierzyć. Jeśli rekomendacja żyje w oknie czatu, nie da się policzyć, ile z nich przyjęto i jaki był skutek, i część niskiego odsetka firm analizujących zwrot z inwestycji w badaniu SAP Polska może mieć to właśnie źródło.

Na czyje konto działa model

Pilotaż często działa na koncie z szerokimi uprawnieniami do odczytu, bo tak było szybciej. W produkcji to nie przejdzie przez dział bezpieczeństwa: handlowiec z jednego regionu nie może przez agenta zobaczyć marż innego regionu, jeśli w SAP ich nie widzi.

Obie platformy mają na to mechanizmy, tylko trzeba je świadomie wybrać. Dokumentacja SAP BTP o łączności opisuje propagację tożsamości (principal propagation), w której wywołanie trafia do systemu SAP w kontekście konkretnego użytkownika, więc obowiązują jego role. Alternatywą jest użytkownik techniczny z rolą zaprojektowaną dla danego przypadku użycia. Po stronie Salesforce dokumentacja Agentforce podaje, że agent obsługujący klientów działa jako osobny użytkownik agenta, który przy tworzeniu w kreatorze dostaje minimalne uprawnienia, a administrator dodaje mu dostęp, którego potrzebuje.

Decyzja, które akcje idą na tożsamość użytkownika, a które na tożsamość agenta, kto zatwierdza nową rolę w SAP i kto przegląda ją po roku, potrafi zająć kilka tygodni w dziale bezpieczeństwa i u audytora. Rzadko jest ujęta w harmonogramie pilotażu.

Dla porządku: nie wiadomo, jaka część rozczarowanych firm z badania EY utknęła właśnie na integracji. Publiczne podsumowanie raportu wymienia jako główne bariery jakość danych, operacyjność strategii i deficyt kompetencji, a tak szczegółowego podziału przyczyn nie podaje.

Pytania do zadania, zanim pilotaż dostanie zielone światło

Jeśli Twoja firma planuje kolejny pilotaż AI na danych z SAP lub Salesforce, odpowiedzi na te pytania warto mieć na piśmie przed jego startem:

  1. Przez jakie API model będzie czytał dane w produkcji i czy jest to droga, którą SAP i Salesforce wspierają dla tego zastosowania.
  2. Kto z nazwiska jest właścicielem każdego interfejsu, kto odbiera alert o błędzie i z czyjego budżetu idzie utrzymanie.
  3. W którym polu, statusie albo dokumencie zapisze się wynik.
  4. Na czyje konto działa model i kto zatwierdził tę rolę.
  5. Po czym poznasz, że działa. Wskaźnik musi dać się policzyć z danych w systemie, nie z ankiety wśród użytkowników.

Pilotaż, który nie ma odpowiedzi na pierwsze cztery pytania, nadal może mieć sens jako test modelu. Wtedy jednak trzeba go tak nazwać i nie liczyć na to, że przejdzie do produkcji bez drugiego projektu. Gdy decyzja trafia na posiedzenie zarządu, przydaje się dłuższa lista pytań przed zatwierdzeniem, obejmująca też koszt i EU AI Act.

Gdzie Twój pilotaż AI spotyka się z SAP i Salesforce?

Weź na Zintegrowany Biznes 2026 listę swoich pilotaży i w rozmowach z innymi uczestnikami sprawdź, które z nich mają już odpowiedź na pytanie o dane, właściciela interfejsu i zapis wyniku. Spotykamy się 25.11.2026 w Warszawie.

Zarejestruj się za darmo ↗

FAQ

Dlaczego pilotaż AI działa, a wdrożenie produkcyjne nie?

Pilotaż zwykle pracuje na ręcznie przygotowanym eksporcie danych, na koncie z szerokimi uprawnieniami i bez zapisu wyniku w systemie. Produkcja wymaga dostępu do aktualnych danych przez API, właściciela interfejsu, kontroli uprawnień i zapisu wyniku w SAP lub Salesforce. Tych elementów w pilotażu najczęściej nie ma, więc wdrożenie okazuje się osobnym projektem.

Kto powinien być właścicielem integracji AI z ERP i CRM?

Jedna wskazana osoba lub zespół dla każdego interfejsu, z budżetem na monitoring i utrzymanie. Najczęściej jest to zespół integracji, który już utrzymuje połączenia między SAP a Salesforce, a zespół AI odpowiada za model i jego zachowanie. Ważne, żeby podział był zapisany przed startem produkcji, bo przy pierwszej awarii nikt nie będzie miał czasu go negocjować.

Na jakich uprawnieniach powinien działać agent AI w SAP lub Salesforce?

Na najwęższych, które pozwalają wykonać jego zadanie. W SAP oznacza to wybór między propagacją tożsamości użytkownika a użytkownikiem technicznym z osobną rolą, w Salesforce agent obsługujący klientów działa jako osobny użytkownik agenta, któremu administrator nadaje dostęp. Rolę agenta powinien zatwierdzić dział bezpieczeństwa tak samo jak rolę każdego pracownika.