← Blog / AI i dane

Granice autonomii AI w SAP i Salesforce: mapa akceptacji

Opublikowano: 16 października 2026

Według badania SAP Polska, opublikowanego 22 września 2026 roku, pełną autonomię w niektórych procesach dopuszcza najwyżej co trzeci menedżer. To odpowiedź na pytanie, ilu polskich menedżerów zgadza się na pełną autonomię AI w procesach firmy: mniejszość, i to tylko w wybranych procesach.

Wcześniejszy wpis opisywał ogólnie, co agenty AI mogą zrobić w ERP i CRM bez człowieka. Ten nie powtarza tamtych ustaleń, tylko dodaje to, czego tam brakuje: polską liczbę, inwentarz interfejsów zapisu i macierz akceptacji dla procesu order-to-cash.

Co pokazał AI Readiness Index

Badanie nosi tytuł „AI Readiness Index. Droga do autonomicznego przedsiębiorstwa”. SAP odczytuje wynik jako ostrożność i odpowiedzialne podejście do zmiany, a nie sceptycyzm. Według komunikatu, który powtarza także ITwiz, badani chętniej powierzają AI procesy przewidywalne, mierzalne i oparte na jasnych regułach niż zadania wymagające szerszego kontekstu i odpowiedzialności za decyzje.

Inne komunikaty z tej serii dopełniają obraz: 70% badanych ma AI w strategii swojego obszaru, ale tylko 28% mierzy zwrot z inwestycji (według komunikatu SAP Polska), a wdrożenia idą wolniej, niż zakładano.

Znamy komunikaty, nie pełny raport. Według nich badanie przeprowadziła w sierpniu 2026 roku firma UCE Research metodą CAWI na próbie 411 menedżerów z firm zatrudniających co najmniej 50 osób, którzy mają wpływ na wydatki na IT. Nie wiemy natomiast, jak badani rozumieli „pełną autonomię” ani o jakie procesy ich pytano, więc nie rozstrzygamy, które procesy mieli na myśli. Wynik nie wskazuje też miejsca akceptacji w procesie. Tu stawiamy tezę: miejsce akceptacji wynika nie tylko z polityki firmy, ale także z tego, które interfejsy pozwalają agentowi zapisywać dane.

Punkt akceptacji jest decyzją integracyjną

Agent może działać samodzielnie tylko tam, gdzie interfejs dopuszcza zapis, a o tym decyduje architektura integracji. Polityka firmy może zabronić agentowi zmiany ceny, ale jeśli agent ma użytkownika z prawem zapisu i bezpośrednią ścieżkę do systemu, zakaz istnieje wyłącznie na papierze.

Dostęp agenta do systemu ma w praktyce trzy postaci. Pierwsza to odczyt, czyli zapytanie do źródła. Druga to zapis przez standardowe API lub zdarzenie, z walidacją po stronie systemu. Trzecia to zapis bezpośredni do bazy albo przez własny skrypt, bez walidacji i bez śladu, i dla niej nie da się sensownie zaprojektować akceptacji.

Po stronie SAP w grę wchodzi dodatkowo polityka API z kwietnia 2026 roku. Według komentatorów, między innymi autorów CustomerThink, ogranicza ona autonomiczne sekwencje wywołań API wykonywane przez systemy AI do ścieżek zatwierdzonych przez SAP. Komentatorzy odwołują się do SAP API Policy w wersji v4/2026, sekcja 2.2.2. Nie cytujemy tu jej brzmienia, więc dokładny zakres ograniczenia trzeba sprawdzić w oryginalnym dokumencie SAP.

Po stronie Salesforce o tym, co agent może zapisać, decydują uprawnienia użytkownika, w którego imieniu działa, oraz reguły i przepływy zatwierdzeń. Salesforce Help opisuje akcję „Submit for Approval”, która kieruje rekord do klasycznego procesu zatwierdzania, a Flow Approval Orchestration pozwala przypisać zatwierdzających i zablokować rekord na czas decyzji.

Tam, gdzie zapis przechodzi przez warstwę integracyjną, krok zatwierdzenia można wstawić bez zmiany któregokolwiek systemu. Gdzie ta warstwa powstaje, zależy od wyboru platformy, o którym piszemy w porównaniu MuleSoft czy SAP Integration Suite.

Jakie procesy można powierzyć agentowi bez zatwierdzania

Bez człowieka nadają się procesy odwracalne, o niskiej wartości i z jednoznacznymi regułami po stronie systemu. To wniosek z logiki opisanej wyżej i z obserwacji SAP o preferencji dla procesów przewidywalnych, a nie wynik badania: SAP nie pytał o poszczególne kroki.

Do tej grupy należą odczyt i podsumowanie statusu zamówienia z SAP w Salesforce, uzupełnianie pól opisowych i notatek w CRM oraz klasyfikacja zgłoszeń. Błąd agenta jest w nich tani i łatwy do cofnięcia, a o tym, co ma zobaczyć handlowiec, piszemy w tekście o statusie zamówienia z SAP w Salesforce.

Po drugiej stronie stoją księgowanie, zmiana cen i warunków płatności, blokady kredytowe oraz zwolnienie dostawy. CustomerThink zaleca bramki z człowiekiem dla finansów, zakupów, danych dostawców, cen, płatności i zapasów, i jest to zalecenie autora, nie wymóg SAP.

Cztery kryteria porządkują ten podział: odwracalność, kwota, wpływ na klienta i to, czy istnieje API zapisu z walidacją po stronie systemu. Ostatnie jest tym, co odróżnia podejście integracyjne od czysto organizacyjnego, bo brak takiego API przesuwa proces na stronę „z zatwierdzeniem”, nawet jeśli reguły są proste.

Sztywnego podziału nie da się wiarygodnie ustalić bez inwentaryzacji interfejsów, a granice w poszczególnych firmach będą się różnić.

Jedno zamówienie, trzy poziomy: agent czyta, proponuje, działa

Weźmy proces order-to-cash i przejdźmy przez trzy poziomy autonomii. To model poglądowy, nie opis konkretnego wdrożenia.

Poziom 1, odczyt. Agent w Salesforce pobiera z SAP status zamówienia, stan dostawy i fakturę. Wystarczą mu uprawnienia tylko do odczytu i aktualne dane, przy czym trzeba zdecydować, czy pracuje na kopii, czy pyta źródło, co omawiamy w tekście o danych z ERP dla agentów AI.

Poziom 2, propozycja. Agent przygotowuje zmianę terminu dostawy lub korektę zamówienia jako szkic, a człowiek zatwierdza ją w Salesforce lub w SAP. Potrzebny jest obszar roboczy na szkice i komunikat zwrotny do agenta o decyzji. Przykładem jest akcja Agentforce, która tworzy w Salesforce szkic wniosku o zmianę terminu dostawy i kieruje go do procesu zatwierdzania, a po decyzji przekazuje wynik do SAP.

Poziom 3, działanie. Agent sam zapisuje zmianę przez API z walidacją po stronie SAP. Zgodnie z polityką API SAP taki autonomiczny zapis musi przechodzić ścieżką zatwierdzoną przez SAP, na przykład przez własnego agenta SAP lub warstwę integracyjną, albo mieć potwierdzoną zgodność z sekcją 2.2.2; bez tego ten wzorzec może być niedozwolony. Wymaga to także użytkownika technicznego z wąskimi uprawnieniami, dziennika zmian i możliwości cofnięcia. Dla SAP lepszym rozwiązaniem niż współdzielone konta serwisowe są tokeny OAuth z propagacją tożsamości użytkownika (principal propagation), a po stronie Salesforce uprawnienia agenta da się ograniczyć do konkretnych obiektów i akcji Flow.

Poniższa tabela zbiera te poziomy w jednej macierzy. To szkic do dopasowania w firmie, bez nazw konkretnych interfejsów.

Dokładne nazwy usług i dostępność mechanizmów zależą od wersji i konfiguracji systemu SAP, więc przed wdrożeniem trzeba je sprawdzić w dokumentacji własnej wersji.

Jak ustawić punkty akceptacji w SAP i Salesforce

Zacznij od spisu operacji zapisu, które agent mógłby wywołać, a dopiero potem decyduj o poziomach autonomii. Kolejność ma znaczenie, bo punkty akceptacji dopasowuje się do tego, co system faktycznie przyjmie.

1. Spisz operacje zapisu, które agent mógłby wywołać, i przypisz do każdej interfejs.
2. Przypisz poziom autonomii według odwracalności i wartości operacji.
3. Wymuś zatwierdzenie tam, gdzie technicznie da się je wstawić: w procesie zatwierdzania lub we Flow Approval Orchestration w Salesforce, w SAP Flexible Workflow albo Business Workflow w S/4HANA, albo w kroku warstwy integracji, a zapis zamówień sprzedaży kieruj przez standardowe usługi OData. Dostępność i nazwy tych mechanizmów różnią się między wersjami SAP, więc sprawdź je w dokumentacji własnej wersji.
4. Ogranicz uprawnienia użytkownika technicznego do konkretnych obiektów i pól.
5. Zapisuj każdą akcję agenta razem z identyfikatorem osoby zatwierdzającej.
6. Mierz odsetek odrzuconych propozycji i na tej podstawie przesuwaj granicę autonomii.

Ostatni krok wiąże się z liczbą z komunikatu SAP: skoro tylko 28% menedżerów mierzy zwrot z AI, w większości firm brakuje danych, by uzasadnić poszerzenie autonomii. Odsetek odrzuceń jest tanim sposobem, żeby je zebrać.

Z komunikatów nie wynika, jak badani rozumieli „pełną autonomię”: jako brak jakiegokolwiek zatwierdzania czy jako brak zatwierdzania w konkretnych krokach. Do tego czasu liczbę najwyżej jednej trzeciej traktujemy jako wskaźnik ostrożności, a nie wzorzec do naśladowania.

Dla zarządu wystarczy jednostronicowa macierz z kolumnami: proces, interfejs zapisu, poziom autonomii, kto zatwierdza. To dokument, który można przedstawić do głosowania i do którego wraca się przy kolejnych rozszerzeniach.

FAQ

#Agenty AI #Agentforce #Zatwierdzanie #SAP API