← Blog / AI i dane

Dane z ERP dla agentów AI: kopiować czy pytać źródło

Opublikowano: 14 października 2026

Agent w CRM ma odpowiedzieć handlowcowi na pytanie „ile mamy tego na stanie”, a zespół od dwóch tygodni nie może się zgodzić, czy stany z SAP kopiować co godzinę do platformy danych, czy przy każdym pytaniu wywoływać SAP. Obie strony mają rację w połowie, bo odpowiedź zależy od rodzaju danych, a agent w jednej rozmowie sięga po kilka ich rodzajów naraz.

Ta sama decyzja stoi za każdym agentem, niezależnie od tego, czy to Joule, Agentforce, czy agent zbudowany we własnym zakresie. Model językowy nie ma własnej wiedzy o Twoich zapasach, zamówieniach i klientach, więc to architektura danych wyznacza, jak aktualna, jak bezpieczna i jak zrozumiała będzie jego odpowiedź.

Trzy drogi danych z ERP do agenta

W praktyce są trzy warianty, a większość firm skończy z mieszanką wszystkich:

• Kopia w platformie danych. Dane z SAP są replikowane cyklicznie albo po zdarzeniu do Salesforce Data 360 (tak Salesforce nazywa dziś platformę znaną wcześniej jako Data Cloud), do SAP Business Data Cloud albo do firmowego lakehouse'u, a agent czyta kopię.
• Zero-copy, czyli udostępnianie danych bez fizycznego przenoszenia: platforma odbiorcy wykonuje zapytania na danych, które zostają w źródle.
• Zapytanie na żywo do SAP. Agent przy każdym pytaniu wywołuje API systemu ERP i dostaje stan z tej chwili.

Zero-copy brzmi jak rozwiązanie sporu, dlatego trzeba sprawdzić, co obie strony faktycznie oferują. SAP wprowadził Business Data Cloud w lutym 2025 roku i według komunikatu SAP z premiery zarządzane produkty danych (data products) zachowują pierwotny kontekst biznesowy i semantykę danych źródłowych. W ramach SAP Business Data Cloud Connect SAP ogłosił dwukierunkowe udostępnianie tych produktów bez kopiowania do Databricks, Snowflake, Google BigQuery i Microsoft Fabric. Salesforce w opisie zero copy w Data 360 wymienia federację zapytań, w której zapytanie trafia do zewnętrznego źródła, a wynik nie jest zapisywany w Data 360, federację plików oraz udostępnianie danych na zewnątrz, a jako partnerów podaje AWS, Databricks, Google Cloud, Snowflake, Microsoft i IBM.

Wynikają z tego dwie rzeczy. Do dnia publikacji ani SAP, ani Salesforce nie ogłosiły bezpośredniego połączenia zero-copy między Business Data Cloud a Data 360, choć Databricks, Snowflake i Google są na listach obu firm, więc wspólny lakehouse może być miejscem spotkania. Druga jest mniej oczywista: Salesforce opisuje też opcjonalne buforowanie (Cached Acceleration), w którym Data 360 trzyma kopię danych zewnętrznych i odświeża ją okresowo, przyrostowo. Etykieta zero-copy nie zwalnia więc z pytania, jak świeże są dane, które widzi agent.

Świeżość zależy od rodzaju danych

Stan magazynowy zmienia się przy każdym ruchu towarowym. Kopia odświeżana co godzinę mówi, ile towaru było godzinę temu, a handlowiec, który na tej podstawie obieca klientowi dostawę z magazynu, może obiecać towar zarezerwowany w międzyczasie dla innego zamówienia. Liczy się też, co SAP rozumie przez „na stanie”: zapas nieograniczony do użycia w danym składzie nie jest tym samym co ilość, którą można obiecać po sprawdzeniu dostępności (ATP), uwzględniającym rezerwacje i zaplanowane przyjęcia.

Dane podstawowe materiału i klienta oraz struktura organizacyjna zmieniają się rzadko, więc kopia odświeżana raz na dobę albo po zdarzeniu zmiany wystarczy. Agent korzysta z nich w niemal każdej odpowiedzi, a pytanie SAP o opis materiału przy każdym zdaniu byłoby kosztem bez korzyści.

Historia sprzedaży, faktury i ruchy magazynowe z kilku lat to z kolei kwestia wolumenu. Pytanie w rodzaju „którzy klienci kupili w tym kwartale mniej niż rok temu” wymaga przeliczenia całej historii dokumentów sprzedaży, czego nie robi się pojedynczymi wywołaniami API, tylko na platformie danych, w kopii albo przez zero-copy.

Status konkretnego zamówienia leży pośrodku: jeden rekord, potrzebny teraz, pytany rzadko. Tu wywołanie SAP na żywo jest najprostsze.

Uprawnienia muszą iść za danymi

W SAP uprawnienia są przypisane do zakładu, jednostki gospodarczej i organizacji sprzedaży, więc handlowiec z jednego regionu nie widzi marż innego. Kiedy dane trafiają do platformy danych, kopią czy przez zero-copy, te reguły nie przechodzą same. Salesforce podaje, że polityki nadzoru nad danymi definiuje się centralnie w Data 360, co w praktyce oznacza, że ktoś musi odtworzyć logikę uprawnień SAP po stronie odbiorcy. Model ról SAP nie przekłada się jeden do jednego na żadną platformę danych i zwykle kończy się uproszczeniem, które trzeba świadomie zaakceptować i zapisać.

Zapytanie na żywo nie rozwiązuje tego automatycznie. Jeśli agent łączy się z SAP jednym użytkownikiem technicznym o szerokich uprawnieniach, każdy, kto rozmawia z agentem, widzi wszystko, co widzi ten użytkownik. Bezpieczniejszy wzorzec to przekazanie tożsamości użytkownika do SAP (principal propagation), tak żeby SAP sprawdził jego własne uprawnienia, ale wymaga to mapowania kont między systemami i działa tylko wtedy, gdy każdy użytkownik agenta ma konto w SAP.

Nazwa pola nic modelowi nie mówi

Stany na poziomie składu SAP udostępnia w obiekcie MARD (w S/4HANA to widok wyliczany z dokumentów materiałowych), w polach MATNR, WERKS, LGORT i LABST, a obok są osobne pola dla zapasu w kontroli jakości i zapasu zablokowanego. Konsultant SAP wie, że LABST to zapas nieograniczony do użycia i że tylko ten nadaje się do sprzedaży. Model językowy, który dostanie surowe kolumny, nie ma skąd tego wiedzieć, a skopiowanie tabel do lakehouse'u przenosi ten problem razem z danymi.

Potrzebna jest warstwa semantyczna: opis, co znaczy każde pole, jakie są relacje między obiektami i które wartości wolno sumować. Tę rolę mają pełnić produkty danych w Business Data Cloud i model danych w Data 360, a po stronie API opublikowane usługi SAP z czytelniejszymi nazwami pól. Żadna z tych warstw nie wie jednak, że w Twojej firmie skład 0099 to towar wadliwy, którego się nie sprzedaje. Takie reguły trzeba dopisać samemu i zwykle to one zajmują w projekcie najwięcej czasu.

Dokumenty, takie jak procedury czy umowy, obsługuje się inaczej: agent wyszukuje fragmenty tekstu i cytuje je, jak w architekturze RAG. Dane z ERP są liczbami osadzonymi w kontekście i wyszukiwanie podobnego tekstu daje dla nich złe wyniki, bo agent musi dostać jedną, poprawną wartość, policzoną według reguł firmy.

Polityka API SAP od kwietnia 2026 roku

Wariant, w którym agent pyta SAP przez API, ma od wiosny dodatkowe ograniczenie. Polityka API SAP w wersji 4.2026a w punkcie 2.2.2 zakazuje używania API do współpracy z (pół)autonomicznymi lub generatywnymi systemami AI, które planują, wybierają lub wykonują sekwencje wywołań API, a także do systematycznej lub masowej ekstrakcji i replikacji danych, chyba że odbywa się to w ramach architektur, usług danych lub ścieżek wskazanych przez SAP. Punkt 3 dodaje, że tych ograniczeń nie wolno obchodzić przez usługi pośredniczące, proxy ani bramki.

Zapis dotyczy obu skrajnych wariantów: agenta, który sam wywołuje API S/4HANA, i masowej replikacji do platformy danych przez te same API. Dotyczy w tym samym stopniu agenta w Salesforce, co agenta zbudowanego we własnym zakresie. Sam tekst polityki nie wymienia z nazwy architektur, które SAP uznaje za dopuszczone; robią to dopiero materiały objaśniające SAP, i nawet z nich nie da się rozstrzygnąć, czy konkretny wzorzec się mieści, więc przed wyborem ścieżki trzeba to potwierdzić z SAP dla własnej umowy i własnego scenariusza.

Koszt leży w każdym wariancie gdzie indziej

Kopia kosztuje pamięć, potoki danych i ich utrzymanie, a każde skrócenie cyklu odświeżania zwiększa liczbę przetworzeń. Zero-copy przenosi koszt na moc obliczeniową zapytań, a Salesforce przedstawia buforowanie jako sposób na kontrolę kosztu przy dużej liczbie zapytań, czyli przy intensywnym użyciu wraca się do kopii. Zapytanie na żywo obciąża system ERP i podlega limitom wywołań, które SAP, zgodnie ze swoją polityką API, dokumentuje osobno dla każdego interfejsu. Agent wywołujący SAP kilka razy w każdej rozmowie, przy dużej liczbie rozmów dziennie, szybko staje się jednym z większych użytkowników interfejsów w firmie.

Jak rozstrzygnąć spór o stany magazynowe

W sporze z początku obie strony mogą więc dostać to, czego chcą, pod warunkiem rozdzielenia dwóch pytań. Jeśli agent ma obiecywać termin dostawy, potrzebuje sprawdzenia dostępności w SAP w momencie pytania. Jeśli ma tylko informować, ile towaru jest w magazynach, wystarczy kopia odświeżana co godzinę, o ile agent podaje w odpowiedzi czas stanu, a handlowiec wie, że taka informacja nie jest rezerwacją.

FAQ

#Architektura #Dane firmowe #API #SAP Joule #Agentforce