Podejście firm do wykorzystania AI w systemach SAP uległo zmianie w ostatnim czasie. Czas eksperymentów się zakończył, obecnie budżety na wdrożenia są bardziej nastawione na wyniki, a SAP przebudował swoją narrację dookoła Autonomous Enterprise. Co się nie zmieniło, to pytanie: którymi drzwiami wchodzimy?
Jest 5 głównych dróg na włączenie sztucznej inteligencji w ekosystem SAP. Zazwyczaj mówi się o każdej z osobna. Brakuje mapy: możliwych dróg zestawionych ze sobą, ile każda kosztuje, jeśli chodzi o umiejętności zespołu, nakład na governance i dokąd każda z nich prowadzi. Poniższy artykuł jest taką mapą i otwiera serię, w której każda z dróg będzie dokładnie omówiona.
Większość organizacji będzie decydowała się na połączenie kilku z tych dróg, więc naszym celem jest ich przedstawienie, a nie wskazanie najlepszej.

Droga pierwsza: wykorzystaj to, co jest już dostępne
Najszybsza droga to AI, które masz już w pakiecie. Joule, asystent SAP, jest dostępny w S/4HANA Cloud, SuccessFactors, Ariba i pozostałych produktach chmurowych, a coraz szerszy zestaw funkcji embedded AI jest wbudowany bezpośrednio w procesy biznesowe: od rozliczania płatności w finansach po asystenta mapowania w usługach SAP BTP i narzędziach developerskich. Ich aktywacja wymaga jedynie konfiguracji, często nieprzekraczającej kilku dni.
Ceną za tę szybkość jest kontrola. Embedded AI działa tak, jak zaprojektował je SAP, rozwija się zgodnie z roadmapą SAP i jest rozliczane w modelu AI Units, który wymaga dokładnej analizy, zanim ktokolwiek obieca zarządowi szybkie efekty. Jako punkt wyjścia ta droga sprawdza się dobrze, natomiast przy konkretnym problemie biznesowym zwykle kończy się o krok za wcześnie, i właśnie tam zaczynają się kolejne drogi.
Droga druga: rozszerz platformę
Gdy funkcje embedded AI nie pokrywają twojego przypadku użycia, kolejną drogą jest budowanie na platformie AI od SAP, bez wychodzenia poza nią. To obszar SAP Business AI Platform: Joule Studio do własnych agentów i ich umiejętności, SAP Build do workflow i aplikacji wokół nich, a za tożsamość, dostęp i osadzenie w danych biznesowych odpowiada SAP.
Dla porządku dwie uwagi. Edytor workflow n8n, który SAP wbudowuje w Joule Studio jako warstwę orkiestracji, ma być ogólnie dostępny w trzecim kwartale 2026 roku, ale w chwili pisania tego tekstu jeszcze się nie pojawił. Nie trzeba jednak czekać: instancję self-hosted n8n możesz już dziś podłączyć do swojego BTP, a nawet uruchomić tam jako kontener.
Ta droga będzie odpowiednia dla organizacji, które chcą budować własne rozwiązania AI, ale ciężar governance wolą zostawić platformie. W praktyce wymaga to kompetencji BTP we własnym zespole albo partnera, który je wnosi.
Droga trzecia: zbuduj własne rozwiązanie
Niektóre problemy są na tyle specyficzne, że żaden gotowy agent ich nie rozwiąże. Na takie przypadki SAP udostępnia narzędzia do uruchamiania własnych modeli i aplikacji: SAP AI Core do wdrażania i utrzymania rozwiązań AI, Generative AI Hub do kontrolowanego dostępu do modeli bazowych oraz SAP HANA Cloud do wyszukiwania wektorowego i osadzania w danych.
To najbardziej wymagająca droga i zarazem ta z największym potencjałem. Dane pozostają w twoim BTP, rozwiązanie robi dokładnie to, czego potrzebuje twój proces, a wynik pracy pozostaje w firmie jako jej własne rozwiązanie, a nie jako subskrypcja usługi. Ceną są realne zasoby inżynierskie: utrzymanie modeli, ewaluacja promptów, zarządzanie cyklem życia rozwiązania. Dlatego ta droga jest zwykle drugim lub trzecim etapem wdrażania AI w organizacji, a rzadko pierwszym.
Droga czwarta: wyjdź poza ekosystem SAP
Rzetelna mapa pokazuje też drogi wyprowadzające poza ekosystem SAP: self-hosted n8n dla zespołów, którym wystarczy sam edytor workflow bez platformy, Workato do automatyzacji między aplikacjami z krokami AI, albo usługi AI hyperscalerów i bezpośredni dostęp przez API do najnowszych modeli, połączone z systemami SAP przez SAP Integration Suite.
Za tą drogą przemawiają konkretne powody: istniejące kompetencje, już wykupione licencje, przypadki użycia realizowane i tak głównie poza SAP. Przed decyzją trzeba jednak sprawdzić dwie rzeczy. Pierwsza to governance: poza ekosystemem SAP kontrola tożsamości, audytu i dostępu, którą droga druga zapewnia domyślnie, staje się obowiązkiem twojego zespołu. Druga jest nowsza i mniej znana: polityka API SAP, zaktualizowana w kwietniu 2026 roku, wprost ogranicza autonomiczne i generatywne systemy AI, które planują i wykonują sekwencje wywołań API na systemach SAP, do ścieżek zatwierdzonych przez SAP. Zanim wybierzesz tę drogę, sprawdź, czy planowany wzorzec mieści się w zatwierdzonej ścieżce i co trzeba zrobić, żeby się w niej zmieścił.
Droga piąta: kup gotowe rozwiązanie od partnera
Ostatnia droga to ta, którą działy IT dużych firm znają najlepiej: ktoś już to zbudował. SAP Store oferuje rosnący katalog rozwiązań AI od partnerów, instalowanych w twoim własnym subkoncie BTP, co znacząco skraca rozmowy o lokalizacji danych i o zakupach. Znamy tę drogę z obu stron, bo sami wprowadziliśmy do SAP Store produkt, który w całości powstał drogą trzecią.
Zakup ma sens, gdy problem jest na tyle powszechny, że istnieje na niego gotowy produkt, i na tyle specyficzny, że sama konfiguracja Joule go nie rozwiąże. Pytania przy ocenie są klasyczne: gdzie trafiają dane, co dzieje się przy odnowieniu umowy i kto odpowiada za wsparcie, gdy coś przestanie działać.
Jak wybrać w praktyce
W praktyce o wyborze decyduje sześć pytań:
- Clean core. Mniej zależy tu od tego, którą drogę wybierzesz, a bardziej od tego, w jaki sposób rozwiązanie dotyka rdzenia systemu. Każda z opcji pozwala zachować czysty rdzeń, o ile korzysta z opublikowanych API i oficjalnych punktów rozszerzeń.
- Lokalizacja danych (data residency). Gdzie fizycznie trafiają prompty, kontekst i wyniki? Drogi pierwsza i druga utrzymują dane w granicach SAP, natomiast na drodze czwartej granicę tę wyznacza już twoja organizacja.
- Umiejętności zespołu. Droga pierwsza wymaga umiejętności administracyjnych, druga praktyków BTP, a trzecia pełnego zespołu inżynierskiego. Oceń realistycznie, którymi z nich twoja organizacja faktycznie dysponuje.
- Model kosztów. AI Units, kredyty BTP rozliczane za zużycie, zewnętrzne subskrypcje i wewnętrzne koszty utrzymania zachowują się w skali zupełnie inaczej. Pilot, który w sandboxie wyglądał tanio, na produkcji może okazać się najdroższą pozycją w budżecie.
- Czas do efektu. Dni na drodze pierwszej, tygodnie na drugiej i piątej, miesiące na trzeciej. Dopasuj drogę do cierpliwości sponsorów projektu.
- Governance. Kto może zobaczyć to, co widziało AI, i kto zatwierdził to, co zrobiło? Na oba pytania trzeba odpowiedzieć przed go-live, bo dokładanie ścieżek audytu do działającego już rozwiązania AI jest drogie i rzadko kompletne.
W praktyce najczęstszą odpowiedzią jest połączenie kilku dróg: Joule aktywowany tam, gdzie przynosi korzyść, własny agent dla procesu, który naprawdę tego wymaga, gotowy produkt tam, gdzie problem został już rozwiązany, oraz integracja, która to wszystko łączy i pozwala monitorować.
A jeśli nadal pracujesz na ECC
Spora część firm, które pytają o AI, pracuje na SAP ECC, a większość publikowanych wskazówek dotyczy edycji chmurowych. Faktyczny obraz jest taki: droga pierwsza jest na ECC w dużej mierze zamknięta, bo Joule i funkcje embedded AI należą do edycji chmurowych. Jeden niuans: S/4HANA Cloud Private Edition w ramach RISE dostaje Joule, udostępniany przez subkonto BTP, a nie w samym systemie, ale to nie obejmuje ECC ani klasycznych instalacji on-premise. Pozostałe drogi są otwarte: druga, trzecia i piąta działają na BTP obok dowolnego rdzenia, a czwarta nigdy nie zależała od wersji twojego ERP.

Sprawdzonym wzorcem jest side-by-side. Zreplikuj lub udostępnij potrzebne dane poza rdzeń, na przykład do SAP HANA Cloud, i zbuduj rozwiązanie AI tam, a nie bezpośrednio na ECC. Rozwiązanie komunikuje się z warstwą danych i z API, więc wersja ERP, która za nimi stoi, nie ma dla niego znaczenia. Ten szczegół jest o tyle istotny, że agent lub aplikacja zbudowane w ten sposób mają dużą szansę przejść późniejszą migrację na S/4HANA bez zmian, podczas gdy wszystko, co zostało wpięte bezpośrednio w ECC, będzie trzeba przebudować. Przy takim podejściu prace nad AI stają się pierwszym etapem przygotowań do migracji.
Od czego zacząć
Środowisko hybrydowe brzmi jak więcej decyzji, ale w praktyce sprowadza się do jednej: co wdrożyć najpierw. Zacznij od przypadku użycia i nazwij, czym on właściwie jest: asystentem, którego aktywujesz, agentem, którego budujesz, workflow, który orkiestrujesz, czy aplikacją, którą rozwijasz. Samo nazwanie zwykle zawęża wybór z pięciu dróg do dwóch. Na pierwsze wdrożenia właśnie takich elementów istnieją dziś programy finansowania prowadzone przez partnerów, które opłaca się sprawdzić przed jakąkolwiek rozmową o budżecie.
W kolejnych częściach serii omówimy drogi po kolei: czym naprawdę jest SAP Business AI Platform, co Joule Studio potrafi dziś, a czego jeszcze nie, czego nauczyło nas budowanie na AI Core, gdzie AI realnie pomaga w utrzymaniu integracji i jak wypadają rozwiązania poza ekosystemem SAP.
W Sygeon mamy kompetencję SAP Business AI Platform Expert, najwyższy poziom w programie kompetencji partnerskich SAP, i pracujemy na każdej z dróg z tej mapy, również tych wyprowadzających poza ekosystem SAP. Jeśli zastanawiasz się, którymi drzwiami wejść, skontaktuj się z nami, a pomożemy ci podjąć tę decyzję.