# SNOK Sp. z o.o. - pełna baza wiedzy dla agentów AI
> Polski partner technologiczny dla średnich i dużych organizacji - SAP (Basis, S/4HANA, BTP, Security), automatyzacja i Enterprise AI (UiPath Platinum + Agentic Fast Track), cyberbezpieczeństwo, custom development i dane. Łączymy doradztwo, architekturę, wdrożenie i utrzymanie w jednym zespole. Spółka zarejestrowana w Warszawie. Certyfikacje ISO 27001:2022, ISO 9001:2015. Założona 2021.
Wersja skrócona (indeks linków): https://snok.ai/llms.txt
Treść oryginalna, autorska, oparta na własnych wdrożeniach. Przy cytowaniu podaj URL źródłowy i zweryfikuj aktualność dat, cen i terminów regulacyjnych.
## Dane korporacyjne
- Nazwa pełna: SNOK Sp. z o.o.
- Adres: Rondo ONZ 1, 00-124 Warszawa
- NIP: 7011032504 | KRS: 0000896866 | REGON: 388919917
- Email: office@snok.ai | Telefon: +48 22 161 18 30
- LinkedIn: https://linkedin.com/company/snok/
- Wikidata: https://www.wikidata.org/wiki/Q141453648
- Certyfikaty: ISO/IEC 27001:2022 (bezpieczeństwo informacji), ISO 9001:2015 (jakość)
## Oferta - cztery filary kompetencji (pełny opis)
### 01. Inteligentna Automatyzacja i AI
URL: https://snok.ai/pl/oferta/automatyzacja-ai/
Mniej pracy ręcznej, szybsze decyzje, niższe koszty operacyjne. Projektujemy i wdrażamy automatyzację procesów biznesowych z wykorzystaniem RPA, Agentów AI, integracji systemowych i Enterprise AI. Pomagamy organizacjom skracać czas obsługi, ograniczać błędy i budować procesy, które można mierzyć, kontrolować i rozwijać.
Referencje i status: UiPath Platinum Partner od 2021 · Agentic Fast Track · Enterprise AI w produkcji od 2025 · Cloud / On-Prem / Air-Gapped
**Agenci AI i agentyczna automatyzacja** - W procesach, które wymagają analizy, decyzji i współpracy wielu systemów, agenci AI prowadzą sprawę krok po kroku, korzystają z danych organizacji i przekazują decyzje do człowieka tam, gdzie wymaga tego kontrola, ryzyko lub zgodność.
- UiPath Maestro: Agenci AI wspierają obsługę powtarzalnych spraw, porządkują kolejne kroki procesu i angażują człowieka wtedy, gdy potrzebna jest decyzja, akceptacja lub ocena ryzyka. (https://snok.ai/pl/oferta/automatyzacja-ai/uipath-maestro/)
- Case Management: Sprawy - od reklamacji po procesy KYC - są prowadzone według ustalonych reguł, z pełną historią działań, decyzji i eskalacji dostępną dla zespołu oraz audytora. (https://snok.ai/pl/oferta/automatyzacja-ai/case-management/)
- Enterprise AI: Zespół szybciej znajduje odpowiedzi w dokumentach, procedurach i danych organizacji - z odwołaniem do źródła, kontrolą dostępu i możliwością dalszej automatyzacji procesu. (https://snok.ai/pl/oferta/automatyzacja-ai/enterprise-ai/)
- Również realizujemy: Agent Builder i Coded Agents, RAG - asystenci AI na wiedzy firmy
**Automatyzacja procesów i dokumentów** - Powtarzalne procesy, dokumenty i testy obsługujemy od początku do końca - z jasnymi regułami, kontrolą jakości i efektem mierzonym w czasie obsługi, liczbie błędów oraz koszcie procesu.
- Business Process Automation: Automatyzujemy procesy operacyjne od przyjęcia sprawy po jej zamknięcie - łącząc systemy, dane i zadania użytkowników w jeden spójny przepływ pracy. (https://snok.ai/pl/oferta/automatyzacja-ai/business-process-automation/)
- Document Understanding: Faktury, umowy, wnioski i inne dokumenty mogą być odczytywane, klasyfikowane i przekazywane do dalszej obsługi bez ręcznego przepisywania danych. (https://snok.ai/pl/oferta/automatyzacja-ai/document-understanding/)
- Agentic Testing: Automatyzujemy testy regresyjne i scenariusze end-to-end, aby szybciej przygotować systemy do zmian, ograniczyć błędy przed go-live i odciążyć zespoły QA. (https://snok.ai/pl/oferta/automatyzacja-ai/agentic-testing/)
- Również realizujemy: Process Mining i Task Mining
**Zaufanie i zgodność AI** - Wdrażamy rozwiązania AI z kontrolą dostępu, audytowalnością decyzji i jasnymi zasadami przetwarzania danych - tak, aby organizacja mogła korzystać z AI bez zwiększania ryzyka operacyjnego, regulacyjnego i bezpieczeństwa.
- AI Security i AI Trust Layer: Projektujemy warstwę bezpieczeństwa dla rozwiązań AI: od kontroli dostępu i ochrony danych, przez ograniczanie ryzyk związanych z modelami językowymi, po monitoring użycia i ścieżkę audytu. (https://snok.ai/pl/oferta/automatyzacja-ai/ai-security/)
- LLM on-premise: Uruchamiamy modele językowe w infrastrukturze klienta, aby dane krytyczne, dokumenty i zapytania użytkowników pozostawały pod kontrolą organizacji. (https://snok.ai/pl/oferta/automatyzacja-ai/llm-on-premise/)
- Zgodność z AI Act: Pomagamy klasyfikować systemy AI, przygotować rejestry, dokumentację i mechanizmy nadzoru wymagane przez AI Act - zanim obowiązki regulacyjne staną się problemem operacyjnym. (https://snok.ai/pl/oferta/automatyzacja-ai/zgodnosc-ai-act/)
- Również realizujemy: AI w SAP - Joule, Build Code, BTP AI Core, Business case, ROI i plan adopcji
Podejście: Każdą rozmowę o automatyzacji zaczynamy od określenia business case'u. Analizujemy obecny koszt procesu - w godzinach pracy, błędach, opóźnieniach i zaangażowaniu zespołu - oraz ustalamy, jak będzie mierzony efekt po wdrożeniu. Dopiero potem dobieramy rozwiązanie: bota RPA, agenta AI z dostępem do systemów, asystenta Enterprise AI, automatyzację dokumentów albo zmianę procedury, jeśli to ona jest rzeczywistym źródłem problemu. Nie automatyzujemy dla samej automatyzacji. Rozwiązanie ma być używane, mierzalne i możliwe do utrzymania. W przeciwnym razie staje się kolejnym kosztem, a nie realnym usprawnieniem.
Stack partnerski: UiPath Platinum, UiPath Agentic Fast Track, UiPath Studio, UiPath Orchestrator, UiPath Maestro, UiPath Agent Builder, UiPath Autopilot, UiPath Action Center, UiPath Test Cloud, UiPath Process Mining, UiPath Task Mining, UiPath Communications Mining, UiPath Document Understanding, UiPath AI Center, UiPath Apps, UiPath Insights, UiPath Integration Service, UiPath Assistant, Anthropic Claude, OpenAI / Azure OpenAI, Google Gemini, Llama 3.3, Mistral, Qwen, Hugging Face, LangChain, LlamaIndex, Model Context Protocol (MCP), Claude Code, Snowflake, Microsoft Fabric, Databricks, pgvector / Qdrant, SAP Joule, SAP Build Code, SAP BTP AI Core
Dowód z wdrożenia (Operator medyczny w 18 krajach): Klient zatrudnia ponad 45 tysięcy osób w 18 krajach. Wspólnie zbudowaliśmy platformę procesów kadrowych wspieraną przez cyfrowych pracowników - obsługującą około 100 tysięcy zdarzeń HR rocznie i skracającą czas onboardingu z 10 dni do 2 dni. Klient został oficjalną referencją producenta platformy - jedną z trzech takich referencji w Polsce.
### 02. Bezpieczeństwo i Technologia SAP
URL: https://snok.ai/pl/oferta/bezpieczenstwo-sap/
Krytyczne systemy SAP - pewność operacyjna, zgodność regulacyjna i optymalizacja kosztów IT. Projektujemy, utrzymujemy i zabezpieczamy środowiska SAP, łącząc kompetencje z zakresu SAP Basis, SAP Security, konwersji S/4HANA, testów penetracyjnych, monitoringu bezpieczeństwa oraz zgodności z wymaganiami NIS2 i DORA. W projektach wykorzystujemy m.in. SecurityBridge, bowbridge i Rev-Trac. Dzięki temu klient otrzymuje spójne wsparcie w obszarze, który zwykle wymaga koordynacji wielu wyspecjalizowanych kompetencji.
Referencje i status: SecurityBridge · bowbridge · Rev-Trac · NIS2 i DORA ready · Audyt → wdrożenie → utrzymanie
**Bezpieczeństwo i ochrona SAP** - Chronimy krytyczne systemy SAP warstwowo: od monitoringu zagrożeń i ochrony załączników, po testy penetracyjne, audyty konfiguracji i wsparcie zespołów SOC.
- SecurityBridge dla SAP: SecurityBridge pozwala wykrywać podejrzane działania w SAP, monitorować zmiany, transakcje, RFC, konfigurację i kod ABAP oraz przekazywać zdarzenia do procesów SOC/SIEM. Dzięki temu zespół bezpieczeństwa widzi ryzyka, których klasyczny monitoring infrastruktury zwykle nie obejmuje. (https://snok.ai/pl/oferta/bezpieczenstwo-sap/securitybridge/)
- bowbridge dla SAP: bowbridge skanuje załączniki i pliki trafiające do SAP, zanim staną się ryzykiem dla systemu krytycznego. Rozwiązanie wspiera ochronę przed malware, kontrolę plików i polityki DLP w procesach biznesowych obsługiwanych przez SAP. (https://snok.ai/pl/oferta/bezpieczenstwo-sap/bowbridge/)
- Pentesty i audyty bezpieczeństwa SAP: Realizujemy testy penetracyjne i audyty bezpieczeństwa SAP: konfiguracji, autoryzacji, interfejsów, RFC, custom kodu ABAP oraz integracji. Raport obejmuje opis podatności, ocenę ryzyka, priorytety naprawy i retest po remediacji. (https://snok.ai/pl/oferta/bezpieczenstwo-sap/pentesty-sap/)
- Również realizujemy: HOT usługa - SAP Security Patch Day, comiesięczne noty i wdrożenie poprawek, Cybersecurity-as-a-Service dla SAP, MDR/SOC 24/7, integracja SAP z SIEM, przeglądy konfiguracji bezpieczeństwa i wsparcie incydentowe
**Transformacja i utrzymanie SAP** - Wspieramy organizacje od konwersji S/4HANA po utrzymanie SAP 24/7 - tak, aby zmiany technologiczne nie powodowały przestojów, konfliktów transportów ani utraty kontroli nad środowiskiem.
- Konwersja do SAP S/4HANA: Przygotowujemy konwersję do S/4HANA na podstawie danych, a nie ogólnych założeń: analizujemy TCO, readiness systemu, custom kod, integracje, ryzyka techniczne oraz plan testów zabezpieczający go-live. (https://snok.ai/pl/oferta/bezpieczenstwo-sap/konwersja-s4hana/)
- SAP Basis 24/7: Zapewniamy wsparcie SAP Basis dla środowisk krytycznych: monitoring, reakcję na incydenty, administrację, patching, backup, performance, HA/DR oraz utrzymanie systemów SAP w modelu dopasowanym do wymagań klienta. (https://snok.ai/pl/oferta/bezpieczenstwo-sap/sap-basis-24-7/)
- Rev-Trac - DevOps i CI/CD dla SAP: Rev-Trac pomaga kontrolować zmiany i transporty w SAP, ograniczać kolizje, automatyzować workflow akceptacji oraz budować pełną historię zmian. To szczególnie ważne w środowiskach z dużą liczbą projektów, zespołów i równoległych transportów. (https://snok.ai/pl/oferta/bezpieczenstwo-sap/rev-trac/)
- Również realizujemy: Sizing i infrastruktura pod SAP HANA, Lenovo SAP HANA appliances, SUSE Linux Enterprise Server for SAP Applications, SAP Cloud ALM, Solution Manager, Focused Run, SAP BTP, Joule i BTP AI Core.
**Zgodność, audyt i koszty SAP** - Pomagamy uporządkować zgodność regulacyjną, bezpieczeństwo kodu i koszty licencji SAP - od mapowania obowiązków, przez audyt, po plan działań i wsparcie wdrożenia zmian.
- Audyt zgodności NIS2 / DORA / KSC dla SAP: Mapujemy wymagania NIS2, DORA i KSC na konkretne obszary środowiska SAP: dostęp, monitoring, ciągłość działania, backup, podatności, integracje, zarządzanie zmianą i dokumentację. Efektem jest plan działań, który można realizować etapami. (https://snok.ai/pl/oferta/bezpieczenstwo-sap/audyt-nis2-dora/)
- Audyt licencji SAP: Analizujemy wykorzystanie licencji SAP, role użytkowników, aktywność w systemach i potencjalne obszary optymalizacji. Celem jest ograniczenie niepotrzebnych kosztów i lepsze przygotowanie do rozmów lub audytu producenta. (https://snok.ai/pl/oferta/bezpieczenstwo-sap/audyt-licencji-sap/)
- SAP Code Vulnerability Analyzer: Weryfikujemy custom kod ABAP pod kątem podatności, jakości i gotowości do zmian technologicznych. Przegląd kodu pomaga ograniczyć powierzchnię ataku, uporządkować dług techniczny i przygotować system do konwersji S/4HANA. (https://snok.ai/pl/oferta/bezpieczenstwo-sap/sap-code-vulnerability/)
Podejście: Zaczynamy od pełnego audytu konfiguracji: autoryzacji, custom kodu, parametrów Basis, polityki backupu i transportów. Większość problemów bezpieczeństwa SAP wynika z konfiguracji, a nie z luk w samym kodzie producenta. Po audycie projektujemy zmianę z jasnym podziałem odpowiedzialności: co realizuje SNOK, co pozostaje po stronie zespołu klienta, a co może zostać wsparte automatyzacją, m.in. przez Rev-Trac, SecurityBridge lub bowbridge. Każdy projekt rozliczamy z mierzalnego efektu biznesowego: redukcji czasu reakcji na incydent, ograniczenia błędów transportów, oszczędności licencyjnych albo gotowości audytowej.
Stack partnerski: SAP Service Partner, SAP S/4HANA, SAP HANA, SAP NetWeaver, SAP BTP, SAP Fiori, SAP ABAP, SAP RISE, SAP GROW, SAP Cloud ALM, SAP Solution Manager, SAP Focused Run, SAP LaMa, SAP HCMT, SAP Joule, SAP Build Code, SAP BTP AI Core, SAP Code Vulnerability Analyzer, SecurityBridge Premier Partner PL, bowbridge, Rev-Trac, gCTS, ChaRM, SUSE Linux Enterprise Server for SAP Applications, Lenovo SAP HANA appliances, Microsoft Sentinel, Splunk, IBM QRadar, Azure for SAP, AWS for SAP, Google Cloud for SAP
Dowód z wdrożenia (Międzynarodowy producent FMCG): Siedmiuset użytkowników SAP w trzech spółkach i pięciu jurysdykcjach podatkowych. Klient powierzył SNOK monitoring i reakcję na zdarzenia bezpieczeństwa SAP zamiast budować własny zespół SOC dla tego obszaru. Projekt objął ochronę krytycznego ERP, monitoring środowiska i reakcję na incydenty. Dzięki temu zespół klienta otrzymał stałe wsparcie bez konieczności rozbudowy własnych kompetencji SAP Security.
### 03. Custom Development i Dane
URL: https://snok.ai/pl/oferta/custom-development/
Aplikacje szyte na miarę w oparciu o wiarygodne dane. Tworzymy aplikacje, integracje i środowiska danych tam, gdzie standardowe produkty nie wystarczają. Łączymy custom development, master data management i warstwę danych wspierającą analitykę, automatyzację oraz AI. Pomagamy porządkować dane podstawowe z wykorzystaniem SNOK MDM i pracujemy m.in. z Microsoft Azure, SAP BTP, Google Cloud, Snowflake, Microsoft Fabric oraz Databricks.
Referencje i status: Microsoft Solutions Partner Infrastructure · SNOK MDM i SNOK.me w produkcji · Modern data stack w sektorze regulowanym · Rozliczenie z efektu, nie z kodu
**Dane, MDM i analityka** - Wiarygodne dane są podstawą raportowania, automatyzacji i wykorzystania AI. Pomagamy porządkować dane podstawowe, budować spójną warstwę analityczną oraz przygotowywać organizację do pracy na danych, którym można ufać.
- Master Data Management: Jedno źródło prawdy o kontrahentach, materiałach i pracownikach - golden record z pilotem jednej domeny w 4-8 tygodni. (https://snok.ai/pl/oferta/master-data-management/)
- Modern Data Stack: Jedna prawda o danych zamiast sprzecznych raportów - czas raportu zarządczego z dni do godzin. (https://snok.ai/pl/oferta/custom-development/modern-data-stack/)
- Databricks - Lakehouse Platform i ML/AI: Dane i ML na jednej platformie - koniec silosów między inżynierią danych a data science. (https://snok.ai/pl/oferta/custom-development/databricks/)
- Również realizujemy: SNOK MDM - własna platforma, w produkcji od 2022, Data Governance i klasyfikacja danych (Purview, Horizon), Google Cloud - BigQuery, Vertex AI
**Chmura, integracje i Clean Core** - Projektujemy architekturę chmurową, integracje i rozszerzenia SAP zgodne z podejściem Clean Core. Łączymy wymagania biznesowe, bezpieczeństwo, koszty utrzymania i długoterminową skalowalność rozwiązania.
- Microsoft Azure: Migracja do chmury z policzonym TCO - bez rachunku wyższego niż on-premise po roku. (https://snok.ai/pl/oferta/custom-development/microsoft-azure/)
- Aplikacje na SAP BTP: Rozszerzenia SAP poza rdzeniem - konwersja S/4HANA bez bólu z custom kodem. (https://snok.ai/pl/oferta/custom-development/sap-btp-clean-core/)
- Integracje i API: Koniec ręcznego przeklejania danych - systemy rozmawiają ze sobą w czasie rzeczywistym, audytowalnie. (https://snok.ai/pl/oferta/custom-development/integracje-api/)
- Również realizujemy: DevOps, CI/CD i SRE
**Aplikacje i produkty szyte na miarę** - Budujemy aplikacje i produkty cyfrowe dopasowane do konkretnego procesu biznesowego. To podejście sprawdza się tam, gdzie gotowe rozwiązania nie wystarczają, wymagają zbyt wielu kompromisów albo nie dają organizacji potrzebnej elastyczności.
- Aplikacje na zamówienie: Funkcjonalność, której nie kupi się z półki - MVP w 8-16 tygodni, kod i IP w pełni Państwa. (https://snok.ai/pl/oferta/custom-development/aplikacje-na-zamowienie/)
- SNOK.me - portfel projektowy: Problem w projekcie widoczny dwa tygodnie wcześniej - lepsza alokacja zespołu i predykcja opóźnień. (https://snok.ai/pl/produkty/snok-me/)
- LLM on-premise + RAG: AI tam, gdzie chmura nie wchodzi w grę - modele i wiedza firmy w Państwa infrastrukturze. (https://snok.ai/pl/oferta/automatyzacja-ai/llm-on-premise/)
Podejście: Zaczynamy od zrozumienia danych, procesów i problemu biznesowego. Sprawdzamy, jakie systemy już istnieją, gdzie powstają niespójności, kto odpowiada za dane oraz które procesy wymagają wsparcia aplikacyjnego, integracyjnego lub analitycznego. Na tej podstawie przygotowujemy mapę działań. Czasem właściwą rekomendacją jest uporządkowanie kilku kluczowych tabel master data przed rozpoczęciem projektu hurtowni, lakehouse lub aplikacji analitycznej. To również może być dobry projekt, jeśli usuwa realną blokadę biznesową. Projektujemy rozwiązania wokół mierzalnego efektu biznesowego, a nie samego dostarczenia kodu, integracji lub środowiska danych. Aplikacja, hurtownia lub model AI mają działać w konkretnym procesie, mieć właściciela po stronie organizacji i opierać się na danych, którym można ufać.
Stack partnerski: Microsoft Solutions Partner Infrastructure, Microsoft Azure, Microsoft Fabric, Microsoft Purview, Azure OpenAI, Azure SQL, Azure Functions, Azure Logic Apps, Entra ID, SAP BTP, SAP CAP, SAP Fiori, SAP Cloud Integration, SAP Build Code, SAP BTP AI Core, Snowflake, Snowflake Cortex, Databricks, Google Cloud Platform, BigQuery, Vertex AI, Anthropic Claude, OpenAI, Llama 3.3, Mistral, Qwen, LangChain, LlamaIndex, pgvector / Qdrant, React / Next.js, Node.js / .NET, TypeScript, Terraform / Bicep, Kubernetes, GitHub Actions / Azure DevOps, SNOK MDM, SNOK.me
Dowód z wdrożenia (Koncern chemiczny po pięciu akwizycjach): Klient w ciągu pięciu lat przeprowadził pięć akwizycji w trzech krajach. Po kolejnym przejęciu zarząd nie miał pewności, czy raporty prezentowane na posiedzeniach opierają się na spójnych definicjach danych. Wdrożyliśmy centralne zarządzanie danymi master z deduplikacją opartą na LLM. Dzięki temu raportowanie zarządcze mogło zostać oparte na jednym, spójnym źródle danych, zrozumiałym dla całej organizacji.
### 04. Doradztwo i Integracja IT
URL: https://snok.ai/pl/oferta/doradztwo-i-integracja-it/
Strategia, architektura i bezpieczeństwo IT - decyzje oparte na faktach. Wspieramy organizacje w podejmowaniu decyzji technologicznych - od analiz TCO, roadmap chmurowych i oceny gotowości do AI, po dobór infrastruktury, licencji i partnerów technologicznych. Dostarczamy rozwiązania sprzętowe i licencyjne, m.in. Lenovo dla środowisk SAP HANA, SUSE, UiPath i SecurityBridge. Łączymy doradztwo, technologię i integrację, aby klient otrzymał spójne wsparcie na każdym etapie projektu.
Referencje i status: Decyzje na liczbach: TCO · NPV · IRR · Roadmapy AI Act · NIS2 · DORA · Niezależne audyty i due diligence · CISO on demand
**Strategia i transformacja** - Decyzje technologiczne oparte na liczbach - TCO, roadmapy i strategia AI, zanim ruszy projekt.
- Analiza TCO konwersji S/4HANA: Wybór modelu wdrożenia oparty na NPV i IRR w horyzoncie 10 lat - decyzja zarządu na liczbach, nie na slajdach producenta. (https://snok.ai/pl/oferta/bezpieczenstwo-sap/konwersja-s4hana/)
- Strategia Enterprise AI + AI Act: Strategia AI z gotowością pod AI Act - od inwentaryzacji systemów po pierwszy produkcyjny use case w sześć miesięcy. (https://snok.ai/pl/oferta/automatyzacja-ai/zgodnosc-ai-act/)
- Roadmapa chmury - Azure, GCP, SAP BTP: Roadmapa chmury na 3-5 lat z policzonym TCO - migracja etapami, bez ryzyka dla ciągłości operacji. (https://snok.ai/pl/oferta/custom-development/microsoft-azure/)
- Również realizujemy: Serwery Lenovo pod SAP HANA
**Zgodność, audyt i koszty** - Regulacje i koszty IT pod kontrolą - jedno okno do NIS2, DORA, AI Act oraz optymalizacji licencji.
- Compliance NIS2 / DORA / AI Act: Trzy regulacje obsłużone jako jeden program - gotowość audytowa, zanim przyjdzie kontrola. (https://snok.ai/pl/oferta/bezpieczenstwo-sap/audyt-nis2-dora/)
- Audyt licencji SAP: Realne oszczędności w rocznych opłatach SAP - z planem negocjacyjnym przed renewal. (https://snok.ai/pl/oferta/bezpieczenstwo-sap/audyt-licencji-sap/)
- AI Readiness Assessment: Sześciowymiarowa ocena gotowości do AI - wiecie Państwo, gdzie jesteście, zanim wydacie pierwszą złotówkę. (https://snok.ai/pl/oferta/doradztwo-i-integracja-it/ai-readiness/)
- Również realizujemy: Licencje i subskrypcje - UiPath, SecurityBridge, SUSE
**Zarządzanie IT i ryzyko** - Ryzyko i dostawcy IT prowadzeni jak portfel - kompetencja zarządcza dostępna na żądanie.
- Cybersecurity Advisory - CISO on demand: Kompetencja CISO bez etatu - polityki, ocena ryzyka i nadzór nad bezpieczeństwem na żądanie. (https://snok.ai/pl/oferta/doradztwo-i-integracja-it/ciso-on-demand/)
- Due diligence IT przy akwizycjach: Stan IT prześwietlony przed transakcją M&A - niespodzianki po przejęciu potrafią kosztować więcej niż sama transakcja. (https://snok.ai/pl/oferta/doradztwo-i-integracja-it/due-diligence-it/)
- Zarządzanie dostawcami IT: Portfel dostawców IT pod kontrolą - realne koszty do odzyskania na przeglądzie umów. (https://snok.ai/pl/oferta/doradztwo-i-integracja-it/vendor-management/)
- Również realizujemy: Szkolenia i warsztaty dla zarządu i IT (AI Act, cybersecurity)
Podejście: Zaczynamy od zrozumienia kontekstu strategicznego: wymuszonych terminów, planowanych akwizycji, presji na ograniczanie kosztów IT, wymagań regulacyjnych oraz aktualnych ryzyk technologicznych. Na tej podstawie porządkujemy decyzje, które organizacja musi podjąć: od analiz TCO, roadmap chmurowych i oceny gotowości do AI, po zgodność z NIS2, DORA i AI Act, audyty licencji, due diligence IT oraz zarządzanie dostawcami. Raport, roadmapa lub analiza mają prowadzić do konkretnej decyzji zarządczej albo technologicznej. Bez tego TCO, AI Readiness Assessment czy strategia zgodności pozostają dokumentami, które nie przekładają się na realne działanie.
Stack partnerski: Lenovo Partner, SUSE Gold Partner (SLES for SAP), Microsoft Solutions Partner Infrastructure, UiPath Platinum Partner, UiPath Agentic Fast Track, SAP Service Partner, SecurityBridge Premier Partner PL, Rev-Trac (dystrybutor PL), Snowflake (Partner), ISO 27001:2022, ISO 9001:2015, SAP HCMT Sizing, Cloud Adoption Framework (Microsoft), NIST CSF, OWASP, AI Act (EU 2024/1689), NIS2 / KSC, DORA, GDPR / RODO
Dowód z wdrożenia (Grupa kapitałowa w sektorze mediów): Cztery spółki zależne, cztery odrębne instalacje ERP, czterokrotny koszt utrzymania. Zaprojektowaliśmy konsolidację na jednej platformie z zachowaniem odrębności prawnej. Cztery spółki działają dziś na jednej platformie - magazyn realizuje cztery tysiące paczek dziennie w jednolitym procesie, koszty utrzymania spadły o blisko jedną trzecią.
## Produkty SNOK (pełny opis)
### SNOK MDM - Master Data Management dla skali enterprise
URL: https://snok.ai/pl/produkty/snok-mdm/
Status: W produkcji od 2022
Pomagamy organizacjom porządkować dane podstawowe tak, aby kluczowe systemy pracowały na spójnych informacjach o klientach, produktach, materiałach, pracownikach i kontrahentach. SNOK MDM wspiera kontrolę jakości danych, ogranicza rozbieżności między systemami i ułatwia budowę wiarygodnego raportowania zarządczego. Dzięki temu dane stają się stabilną podstawą decyzji, automatyzacji i dalszego rozwoju organizacji. Centralne zarządzanie danymi master we wszystkich kluczowych domenach organizacji: pracownikach, klientach, materiałach, dostawcach, produktach i kontach finansowych. Platforma wspiera walidację, deduplikację, workflow akceptacji, historię zmian i synchronizację do systemów źródłowych. Poza samą platformą realizujemy usługi Master Data Management: ocenę stanu danych, projekt rekordu wzorcowego, pilot jednej domeny oraz governance - również w środowiskach, w których warstwę wzorcową buduje się bez naszego produktu.
- Sześć domen master w jednej platformie: Pracownicy, klienci, materiały, dostawcy, produkty i finanse. Każda domena ma dedykowany schemat danych, reguły walidacji i workflow dopasowany do procesu organizacji.
- Deduplikacja wspierana przez modele AI: System rozpoznaje podobne rekordy i różne warianty zapisu tej samej firmy, osoby, materiału lub kontrahenta - z uzasadnieniem dla data stewarda.
- Integracje natywne: Gotowe konektory obejmują SAP S/4HANA, SAP ECC, Azure AD, Salesforce, Workday, Oracle Cloud ERP i Microsoft Dynamics 365. Integracje niestandardowe projektujemy pod architekturę klienta.
- Wdrożenie w środowiskach wymagających kontroli: SNOK MDM może działać on-premise lub w środowisku klienta, gdy wymagają tego polityka bezpieczeństwa, compliance albo architektura IT. Kod źródłowy może zostać zdeponowany w escrow, aby ograniczyć ryzyko zależności od jednego dostawcy.
Metryki: 70% (szybsze raportowanie zarządcze - wynik wdrożenia SNOK w jednym procesie zarządczym) · 85% (mniej błędów w danych master po wdrożeniu walidacji i deduplikacji - wynik wdrożenia SNOK w jednej domenie danych) · 15 mies. (okres zwrotu z inwestycji w jednym z naszych wdrożeń) · 6 (domen master dostępnych w modelu bazowym)
Technologia: SNOK MDM opiera się na architekturze projektowanej pod skalę enterprise: backendzie Node.js, relacyjnej bazie PostgreSQL, warstwie workflow BPMN, regułach governance dla każdej domeny oraz kolejce deduplikacji wspieranej przez modele AI. Platforma może działać w modelu multi-tenant z izolacją danych per klient lub jako wdrożenie dedykowane w środowisku organizacji.
Dowód: Platforma obsługuje około 100 tysięcy zdarzeń na danych wzorcowych rocznie w środowisku międzynarodowym, obejmującym 18 krajów i 9 systemów źródłowych.
### SNOK.me - Ludzie, czas, projekty i rentowność w jednym środowisku
URL: https://snok.ai/pl/produkty/snok-me/ | https://snok.me/pl/
Status: Sprawdzony w codziennej pracy organizacji
SNOK.me pomaga organizacjom uporządkować codzienną pracę zespołów oraz zarządzanie projektami i sprawami pracowniczymi. Platforma łączy ewidencję czasu, planowanie obciążenia, prowadzenie projektów, rozliczenia i raportowanie zarządcze w jednym spójnym środowisku - dając zarządowi aktualny obraz pracy, kosztów i rentowności. SNOK.me łączy dane o ludziach, projektach, czasie pracy, kosztach, rentowności i sprawach pracowniczych w jednym środowisku. Dzięki temu pracownicy, administracja, PMO, menedżerowie i zarząd korzystają z tych samych danych, ale widzą je z perspektywy swojej roli.
- Czas, projekty i rentowność pod kontrolą: Platforma wspiera ewidencję czasu, planowanie dostępności zespołów, harmonogramy projektów oraz controlling kosztów i rentowności na poziomie projektu i fazy. Dzięki temu przekroczenia budżetu, opóźnienia i przeciążenia zespołów są widoczne wcześniej - nie dopiero po ręcznym zebraniu danych z arkuszy.
- Widok zarządczy bez ręcznego składania raportów: SNOK.me daje zarządowi i kadrze menedżerskiej aktualny obraz pracy zespołów, obciążenia ludzi, postępu projektów, kosztów i rentowności. Dane operacyjne nie muszą być ręcznie zbierane z arkuszy i osobnych systemów, dlatego decyzje mogą opierać się na bieżących informacjach, a nie na raportach przygotowywanych po fakcie.
- Rozliczenia i premie na przejrzystych zasadach: Dane o czasie pracy, projektach i ocenach mogą stanowić uporządkowany wsad do rozliczeń oraz premii projektowych. SNOK.me nie zastępuje systemu kadrowo-płacowego, ale porządkuje dane, które mogą zasilać procesy rozliczeniowe, raportowanie i decyzje zarządcze.
- Pracownik załatwia swoje sprawy sam: SNOK.me daje pracownikowi jedno miejsce do obsługi spraw wewnętrznych: profilu, przypisanego sprzętu, certyfikatów, dokumentów do akceptacji, ticketów, dni wolnych, rozliczeń i wiedzy organizacyjnej. Baza wiedzy, struktura organizacyjna i kalendarz ograniczają potrzebę szukania informacji w mailach, komunikatorach i u innych osób. Zespół administracyjny odzyskuje czas, który wcześniej był przeznaczany na obsługę powtarzalnych pytań i rutynowych spraw.
- AI w kontekście organizacji: Warstwa AI wspiera analizę ticketów, rozmowę z dokumentami, ocenę kompletności zgłoszeń, identyfikację braków, wskazywanie ryzyk i podpowiadanie kolejnych kroków. Rozwiązanie nie jest uzależnione od jednego dostawcy modelu, a rozmowy i wyniki pracy można współdzielić w zespole.
- Integracje i środowisko pracy: SNOK.me integruje się z Microsoft 365 i Google Workspace, wspiera logowanie firmowym kontem SSO oraz integrację kalendarza. Platforma może działać w chmurze albo na infrastrukturze klienta, zależnie od polityki bezpieczeństwa organizacji.
Metryki: Ludzie (Profil pracownika, sprawy wewnętrzne, sprzęt, certyfikaty, dokumenty, tickety i baza wiedzy) · Czas (Ewidencja czasu, dostępność zespołów i planowanie obciążenia bez osobnych arkuszy) · Projekty (Planowanie prac, fazy, zależności, zadania, dokumenty oraz porównanie planu z realizacją) · Rentowność (Controlling kosztów i rentowności na poziomie projektu, fazy oraz zespołu)
Technologia: SNOK.me może działać w chmurze albo na infrastrukturze klienta. Platforma integruje się z Microsoft 365 i Google Workspace, wspiera SSO i kalendarze, a warstwa AI nie jest uzależniona od jednego dostawcy modelu. Dane są przechowywane w UE, a produkt rozwijany jest w organizacji posiadającej certyfikaty ISO 27001:2022 i ISO 9001:2015.
Dowód: SNOK.me jest używany operacyjnie w SNOK do prowadzenia spraw pracowniczych, projektów, czasu pracy, rentowności i rozliczeń. To nie jest wyłącznie demonstracja sprzedażowa, ale produkt rozwijany na podstawie realnej pracy organizacji projektowej.
## Realizacje - case studies (pełna treść)
### Stock Spirits Group - Krytyczne ERP pod ochroną 24/7 - bez powiększania zespołu IT klienta
URL: https://snok.ai/pl/realizacje/#producent-fmcg-bezpieczne-erp
Sektor: Producent FMCG · 9 krajów Europy
Międzynarodowy producent alkoholi, prowadzący operacje w dziewięciu krajach, zgłosił się do nas z konkretnym wyzwaniem: jak zapewnić ciągłą ochronę krytycznego systemu ERP bez zatrudniania kolejnych specjalistów na wymagającym rynku pracy.
Wyzwanie: Około 700 użytkowników w trzech spółkach korzystało ze wspólnej platformy ERP, obsługującej m.in. rozliczenia podatków akcyzowych w pięciu jurysdykcjach. Każda awaria mogła oznaczać wstrzymanie dostaw, a każdy incydent bezpieczeństwa - ryzyko kontroli, wyjaśnień i zakłóceń operacyjnych. Wewnętrzny zespół IT dobrze znał środowisko, ale nie miał wystarczających zasobów, aby zapewnić całodobowy monitoring, bieżącą analizę zdarzeń oraz regularną obsługę poprawek bezpieczeństwa SAP.
Podejście: Rozpoczęliśmy od audytu konfiguracji bezpieczeństwa i autoryzacji. Następnie wdrożyliśmy SecurityBridge - platformę monitoringu i detekcji zagrożeń dedykowaną środowiskom SAP. Przejęliśmy również obsługę comiesięcznego cyklu poprawek bezpieczeństwa SAP, a wybrane, powtarzalne zadania administracyjne zautomatyzowaliśmy z wykorzystaniem cyfrowych pracowników UiPath.
Rezultat: Klient uzyskał stały monitoring bezpieczeństwa krytycznego ERP bez konieczności budowania własnego zespołu SOC od podstaw. Zdarzenia są obsługiwane w czasie poniżej dwóch godzin, a siedem powtarzalnych procesów administracyjnych realizują dziś cyfrowi pracownicy. Dzięki temu zespół klienta odzyskał czas na pracę projektową i rozwój środowiska, zamiast koncentrować się wyłącznie na bieżącej obsłudze operacyjnej.
Metryki: 700+ - użytkowników pod ciągłą ochroną · <2 h - średni czas reakcji na incydent · 24/7 - monitoring od 2023 roku
Cytat klienta: "SNOK przejął odpowiedzialność za bezpieczeństwo naszej platformy ERP w sposób, który pozwolił nam skupić się na rozwoju biznesu."
### Medicover - Sto tysięcy zdarzeń kadrowych rocznie - bez ręcznej obsługi procesów
URL: https://snok.ai/pl/realizacje/#siec-medyczna-cyfryzacja-hr
Sektor: Sieć medyczna · 18 krajów, 45 000 pracowników
Jeden z największych operatorów medycznych w Europie Środkowej, zatrudniający pracowników w 18 krajach, mierzył się z wyzwaniem dalszego skalowania procesów HR. Różnice regulacyjne między krajami, rosnąca liczba pracowników i coraz większa liczba zdarzeń kadrowych wymagały uporządkowania oraz automatyzacji kluczowych procesów.
Wyzwanie: Dział HR obsługiwał około 45 tysięcy pracowników przy użyciu narzędzi, które nie były projektowane z myślą o tak dużej skali działania. Onboarding wymagał ręcznego wypełniania wielu formularzy, a raport zarządczy dotyczący zatrudnienia powstawał dopiero kilka dni po zakończeniu miesiąca. Organizacja rosła szybciej niż możliwości operacyjne zespołu kadrowego. Bez automatyzacji i centralizacji danych dalszy wzrost oznaczałby coraz większe obciążenie pracowników HR oraz wyższe ryzyko błędów w procesach.
Podejście: Zbudowaliśmy dedykowaną platformę procesów kadrowych w chmurze SAP BTP, opartą na centralnym rejestrze danych pracowniczych. Rejestr działa jako warstwa danych wzorcowych SNOK MDM: jeden rekord wzorcowy pracownika powstaje z reguł jakości, ma właściciela, historię zmian oraz ślad audytowy, a systemy operacyjne w poszczególnych krajach pozostają zasilane z tej jednej wersji. To wdrożenie jest dziś podstawą naszej praktyki Master Data Management. Procesy onboardingu oraz zmian etatów zaprojektowaliśmy jako uporządkowane przepływy z workflow akceptacji, dostosowane do wymagań organizacji działającej w wielu krajach. Powtarzalne zadania operacyjne zostały przekazane cyfrowym pracownikom UiPath.
Rezultat: Platforma obsługuje dziś około 100 tysięcy zdarzeń kadrowych rocznie w 18 krajach. Czas onboardingu skrócił się z 10 dni do 2, a raport zarządczy jest generowany automatycznie każdego dnia. Dzięki wdrożeniu organizacja może obsługiwać rosnącą skalę procesów HR bez proporcjonalnego zwiększania obciążenia zespołu kadrowego. Projekt został również uznany za oficjalną referencję SAP - jedną z trzech w Polsce.
Metryki: 100 000+ - zdarzeń HR rocznie · 95% - mniej manualnej pracy w kadrach · 18 - krajów na jednej platformie
Cytat klienta: "Skala, którą obsługujemy dzisiaj, byłaby niemożliwa bez tej platformy - i bez zespołu, który zna nas od trzech lat."
### Grupa kapitałowa w sektorze mediów - Cztery spółki, jedna platforma ERP - spójna odpowiedzialność za środowisko
URL: https://snok.ai/pl/realizacje/#grupa-medialna-konsolidacja-spolek
Sektor: Telekomunikacja · 4 spółki w grupie
Grupa kapitałowa z sektora mediów i telekomunikacji potrzebowała skonsolidować rozproszone systemy ERP w czterech spółkach zależnych. Każda spółka pracowała na osobnej instancji, a raportowanie do centrali wymagało czasochłonnych uzgodnień między systemami i zespołami.
Wyzwanie: Organizacja korzystała z czterech odrębnych instalacji ERP, różnych konfiguracji i osobnych modeli administracji. Każda zmiana w sprawozdawczości grupowej oznaczała konieczność pracy w kilku środowiskach równolegle. Dodatkowym wyzwaniem była obsługa magazynu realizującego około 4 tysięcy paczek dziennie w różnych procesach operacyjnych. Skala działania grupy zaczęła wyprzedzać dotychczasową architekturę technologiczną.
Podejście: Zaprojektowaliśmy konsolidację środowisk ERP na jednej platformie, z zachowaniem odrębności prawnej poszczególnych spółek dzięki odpowiedniemu wykorzystaniu wymiarów organizacyjnych. Migrację przeprowadziliśmy etapami, z pełnymi testami regresji i kontrolą ryzyk operacyjnych. W obszarze infrastruktury współpracowaliśmy z Lenovo Platinum i SUSE Gold, dobierając rozwiązania pod krytyczne obciążenia bazy danych.
Rezultat: Cztery spółki działają dziś na jednej platformie ERP, a magazyn obsługuje około 4 tysięcy paczek dziennie w jednolitym procesie operacyjnym. Raportowanie grupowe zostało zautomatyzowane, a dane są dostępne w spójnym modelu. Koszty utrzymania środowiska spadły o blisko jedną trzecią, a czas zamknięcia miesiąca grupowego skrócił się z trzech tygodni do trzech dni.
Metryki: 4 - spółki na jednej platformie · 4 000 - paczek dziennie w jednolitym procesie · −30% - kosztów utrzymania środowiska
Cytat klienta: "Konsolidacja dała nam spójność raportowania grupowego i odzyskanie kontroli nad kosztami IT."
### Koncern chemiczny - Spójne dane master po pięciu akwizycjach - bez przebudowy systemów źródłowych
URL: https://snok.ai/pl/realizacje/#koncern-chemiczny-mdm-po-akwizycjach
Sektor: Przemysł chemiczny · operacje w 8 krajach
Koncern chemiczny, który w ciągu pięciu lat przeprowadził pięć akwizycji w trzech krajach, potrzebował uporządkować dane podstawowe pochodzące z różnych spółek i systemów. Każda przejęta organizacja wnosiła własne katalogi materiałów, dostawców, produktów i kont finansowych, co utrudniało raportowanie oraz podejmowanie decyzji na poziomie grupy.
Wyzwanie: Te same materiały funkcjonowały w wielu systemach pod różnymi indeksami, a ci sami dostawcy byli opisywani według różnych zasad w zależności od spółki. Harmonizacja pojedynczego komponentu potrafiła trwać miesiącami, a raporty zarządcze wymagały dodatkowych uzgodnień i wyjaśnień. Organizacji brakowało jednego, spójnego modelu danych master, który mógłby stać się wiarygodną podstawą raportowania, zakupów, logistyki i dalszej integracji po akwizycjach.
Podejście: Wdrożyliśmy centralne zarządzanie danymi master w sześciu kluczowych domenach: pracownicy, klienci, materiały, dostawcy, produkty i konta finansowe. Zaprojektowaliśmy workflow akceptacji z jasnym podziałem odpowiedzialności za poszczególne domeny danych. Tam, gdzie ręczna deduplikacja była niewystarczająca lub zbyt czasochłonna, wykorzystaliśmy modele językowe wspierające identyfikację podobnych rekordów i niespójności.
Rezultat: Harmonizacja danych po kolejnej akwizycji trwa dziś trzykrotnie krócej. Raporty zarządcze opierają się na spójnych danych, a zarząd pracuje na jednej, wspólnie rozumianej wersji informacji. Liczba błędów w katalogach spadła o blisko 90%, a organizacja może zarządzać znacznie większym portfolio przy zachowaniu obecnej skali zespołu odpowiedzialnego za dane.
Metryki: 3× - szybsza harmonizacja po akwizycji · −85% - błędów w danych master · 12 - zintegrowanych systemów źródłowych
Cytat klienta: "Po raz pierwszy od dawna wszyscy w zarządzie patrzymy na tę samą liczbę - i wiemy, skąd się wzięła."
## Najnowsze artykuły (20, pełna treść)
### Outsourcing SAP Basis w Polsce - zakres, SLA i bezpieczeństwo
URL: https://snok.ai/pl/aktualnosci/blog/outsourcing-sap-basis/ | Data: 2026-10-07 | Seria: Inne
**Outsourcing SAP Basis** w większości umów sprowadza się do trzech słów: monitoring, poprawki, dyżur. Te słowa niewiele mówią o faktycznym zakresie usługi. Nie wynika z nich, kto zareaguje na alert bezpieczeństwa o drugiej w nocy, kto w drugi wtorek miesiąca zdecyduje, które noty z **SAP Security Patch Day** idą na produkcję w tym tygodniu, ani czym zastąpicie monitoring z SAP Solution Manager, kiedy skończy się jego standardowe utrzymanie.
Utrzymanie SAP Basis prowadzimy od lat, a w jednym ze środowisk, które obsługujemy, łączymy je z monitoringiem bezpieczeństwa w trybie całodobowym od lutego 2023 roku. Poniżej opisujemy zakres takiej usługi, nasz codzienny przegląd systemu, sposób czytania SLA i miejsce, w którym utrzymanie styka się z bezpieczeństwem.
**W skrócie:**
**1/** outsourcing SAP Basis obejmuje warstwę techniczną: system, bazę danych, kernel, transporty, kopie zapasowe i wydajność - wsparcie funkcjonalne i rozwój to osobne usługi i dobrze, gdy umowa mówi to wprost,
**2/** jakość usługi widać w codziennym przeglądzie systemu - nasz obejmuje siedemnaście transakcji, od stanu instancji po zatrzymane importy transportów i komunikaty IDoc,
**3/** SLA ma sens dopiero wtedy, gdy rozdziela czas reakcji od czasu przywrócenia działania i mówi, kto ten czas mierzy,
**4/** poprawki bezpieczeństwa, hardening i monitoring zdarzeń to praca zespołu Basis, więc najprościej, gdy odpowiada za nie ten sam dostawca, a okresowy test penetracyjny sprawdza wynik z zewnątrz.
## Co obejmuje outsourcing SAP Basis
Zakres zaczyna się od codziennej kontroli systemów i obsługi alertów, a kończy na administracji bazą SAP HANA: kopiach zapasowych, odtwarzaniu po awarii, wysokiej dostępności i planowaniu rozbudowy. Pomiędzy są poprawki i aktualizacje (SAP Security Notes, kernel, support packi), analiza i strojenie wydajności, zarządzanie zmianą z kontrolą transportów, a także obsługa incydentów z dyżurem całodobowym.
Granica, o którą najczęściej toczy się spór po podpisaniu umowy, przebiega między warstwą techniczną a aplikacją. Utrzymanie Basis odpowiada za to, żeby system działał, był aktualny i wydajny. Nie odpowiada za błąd w konfiguracji modułu finansowego ani za program raportowy napisany przez innego dostawcę. Jeżeli w umowie te dwie warstwy nie są rozdzielone, każdy incydent zaczyna się od ustalania, czyj to problem, a czas reakcji biegnie.
## Kiedy outsourcing jest lepszy niż własny zespół
Dyżur całodobowy wymaga kilku osób o porównywalnych kompetencjach, które się wzajemnie zastępują. Dla wielu organizacji to więcej etatów Basis, niż uzasadnia skala systemu, a rynek specjalistów z doświadczeniem w SAP HANA i SAP S/4HANA jest wąski. Rekrutacja jednej osoby nie rozwiązuje problemu, tylko przenosi go na urlopy i zwolnienia.
Własny zespół ma natomiast przewagę, której zewnętrzny dostawca nie kupi: zna procesy firmy i ludzi po stronie biznesu. Dlatego dobrze działa model mieszany, w którym zespół klienta zostaje przy architekturze i decyzjach, a dyżur, rutynowe kontrole i poprawki przejmuje dostawca. W takim modelu umowa musi jednak precyzyjnie opisywać, kto zatwierdza zmianę na produkcji.
## Co sprawdzamy codziennie w systemie SAP
Codzienny przegląd to najprostszy test, czy dostawca utrzymania wie, co robi. U nas obejmuje siedemnaście transakcji, ułożonych w stałej kolejności. W środowiskach, w których ma to uzasadnienie, przegląd wykonuje bot UiPath, który zbiera wyniki do jednego raportu, a inżynier dyżurny zaczyna dzień od jego lektury zamiast od klikania po ekranach.
To rdzeń przeglądu, nie jego całość. Do każdego środowiska dokładamy kontrole wynikające z jego architektury, integracji i wymagań klienta.
**Metadane systemu:** SPAM (poziom support packów i wersja produktu) oraz DBACOCKPIT (wersja i wydanie bazy danych). Bez tego nie da się ocenić, których not bezpieczeństwa dotyczy najbliższy Patch Day.
**Instancje i procesy:** SM51 (stan instancji na wszystkich hostach), SM66 (procesy robocze według statusu w całym systemie) i ST06 (procesor, stronicowanie i wolne miejsce na dyskach serwerów aplikacyjnych).
**Wydajność:** ST03 (średni czas odpowiedzi w podziale na kroki dialogowe, RFC, aktualizacje i zadania w tle), ST02 (trafienia w bufory, wymiana buforów, pamięć sterty) oraz ST04 (stan operacyjny bazy, replikacja przy wysokiej dostępności, zużycie zasobów).
**Kopie zapasowe:** DB12 (nieudane kopie danych i logów). Nieudana kopia, której nikt nie zauważył przez tydzień, to najczęstszy powód, dla którego plan odtwarzania istnieje tylko na papierze.
**Błędy i blokady:** SM12 (blokady, w tym wiszące dłużej niż dobę), SM13 (nieudane aktualizacje V1 i V2), SM21 (dziennik systemowy według wagi), SM37 (zadania w tle zakończone błędem) i ST22 (zrzuty błędów ABAP).
**Wyjścia i interfejsy:** SP01 (błędne zlecenia wydruku), STMS_IMPORT (zatrzymane importy transportów) i WE02 (komunikaty IDoc według statusu).
Lista nie jest tajemnicą i nie w samej liście tkwi wartość. Wartość daje porównanie dnia do dnia: wzrost średniego czasu odpowiedzi w ST03 o kilkanaście procent bez zmiany obciążenia albo IDoc-i, które od trzech dni wiszą w tym samym statusie, mówią więcej niż jakikolwiek pojedynczy odczyt. Z tych samych danych bierze się strojenie wydajności. Parametry buforów i pamięci zmieniamy na podstawie trendu z ST02 i ST03, zanim użytkownicy zgłoszą spowolnienie.
## Jakie SLA powinna zawierać umowa na utrzymanie SAP Basis
Najczęstszy błąd w umowach polega na tym, że jedna liczba ma opisać całą obsługę incydentu. Czas reakcji mówi, kiedy ktoś potwierdzi zgłoszenie i zacznie pracę. Czas przywrócenia działania mówi, kiedy system wróci do pracy, nawet jeśli przyczyna nie jest jeszcze usunięta. Czas rozwiązania dotyczy usunięcia przyczyny i bywa liczony w dniach, bo wymaga noty SAP albo okna serwisowego. To trzy różne zobowiązania i każde powinno mieć w umowie własną definicję.
Przed podpisaniem warto sprawdzić pięć rzeczy:
**Klasy incydentów:** czy umowa definiuje, co jest incydentem krytycznym, na przykład niedostępność produkcji dla wszystkich użytkowników, czy zostawia to do interpretacji w chwili awarii.
**Pomiar:** kto mierzy czas i w jakim narzędziu. Jeżeli zegar startuje dopiero w systemie zgłoszeń dostawcy, alert z monitoringu sprzed godziny nie istnieje.
**Okna serwisowe:** kiedy dostawca może zatrzymać system i kto po stronie klienta zatwierdza przestój.
**Raportowanie:** zawartość miesięcznego raportu i to, czy pokazuje trendy, czy tylko liczbę zamkniętych zgłoszeń.
**Wyjście z umowy:** jaką dokumentację, hasła techniczne i procedury dostawca przekazuje przy rozstaniu. Ta klauzula jest nudna do momentu, w którym jest potrzebna.
## Kto odpowiada za Basis w RISE with SAP
Przejście do **RISE with SAP** przesuwa granicę odpowiedzialności, ale jej nie usuwa. SAP prowadzi infrastrukturę, system operacyjny, bazę SAP HANA, kopie zapasowe i monitoring warstwy technicznej. Po stronie klienta zostają konfiguracja aplikacji, użytkownicy, role, dziennik audytu, integracje i kod własny.
Dwa fakty z materiałów SAP zaskakują większość zespołów. Przy łatkach bezpieczeństwa warstwy technicznej SAP przygotowuje przetestowane paczki, ale to klient zgodnie z umową składa wniosek o ich wdrożenie i zgadza się na przestój w oknie utrzymaniowym. Test penetracyjny możecie z kolei przeprowadzić wyłącznie na warstwie aplikacji i wyłącznie po zatwierdzeniu przez SAP. Ktoś po Waszej stronie musi więc śledzić Patch Day, oceniać noty i składać wnioski. To nadal jest praca Basis, tylko w innym miejscu. Szerzej opisujemy to we wpisie o [bezpiecznej konwersji do SAP S/4HANA i RISE with SAP](/pl/aktualnosci/blog/bezpieczna-konwersja-sap-s4hana-rise/).
## SAP Security Patch Day w codziennym utrzymaniu
SAP publikuje noty bezpieczeństwa w drugi wtorek każdego miesiąca. Dla zespołu Basis to stały punkt kalendarza: inwentaryzacja tego, czego brakuje w systemach, ocena, które noty dotyczą Waszej konfiguracji, plan wdrożenia w systemach deweloperskich i testowych, a potem okno na produkcji. Bez znajomości poziomu support packów i wersji komponentów, czyli danych z codziennego przeglądu, ta ocena jest zgadywaniem.
Klient, z którym pracujemy od 2023 roku, opisał w rozmowie z ITwiz zjawisko, które widzimy w wielu firmach: „W wielu przypadkach względnie regularnie aktualizowany jest jedynie moduł techniczny, pokroju jądra systemu czy bibliotek bazy danych. Aktualizacje modułów funkcjonalnych są bardziej złożone [...]. Efekt jest taki, że część starych modułów nie jest aktualizowana latami”. Dlatego obsługę Patch Day łączymy z planem aktualizacji całego środowiska, a nie tylko kernela. Comiesięczny cykl opisujemy na stronie [SAP Security Patch Day](/pl/oferta/bezpieczenstwo-sap/sap-security-patch-day/).
## Hardening, monitoring bezpieczeństwa i pentest jako część utrzymania
Domyślna konfiguracja SAP ma przede wszystkim umożliwić szybkie uruchomienie systemu. Utwardzanie konfiguracji, czyli wyłączanie zbędnych usług, porządkowanie parametrów bezpieczeństwa, połączeń RFC i uprawnień technicznych, nie kończy się na jednym projekcie, bo każda zmiana w systemie może je częściowo cofnąć. Pisaliśmy o tym we wpisie [hardening SAP jako proces, nie projekt](/pl/aktualnosci/blog/hardening-sap-proces-nie-projekt/).
Monitoring bezpieczeństwa SAP to druga warstwa nad monitoringiem technicznym. Platforma [SecurityBridge](/pl/oferta/bezpieczenstwo-sap/securitybridge/) koreluje zdarzenia z logów SAP, wykrywa podatności w zainstalowanych komponentach i w kodzie ABAP, a alerty może przekazywać do systemu SIEM. Alert sam niczego jednak nie naprawia. Ktoś musi go odebrać, ocenić i zareagować, a najczęściej oznacza to zmianę w konfiguracji, którą wykonuje zespół Basis. Gdy monitoring bezpieczeństwa i utrzymanie są w rękach dwóch różnych dostawców, każdy alert wymaga przekazania sprawy między nimi.
Trzecia warstwa to okresowa kontrola z zewnątrz. [Test penetracyjny SAP](/pl/oferta/bezpieczenstwo-sap/pentesty-sap/) albo audyt bezpieczeństwa systemów deweloperskich, testowych i produkcyjnych sprawdza, czy hardening i poprawki działają tak, jak zakłada dokumentacja. Rekomendujemy go raz w roku i po każdej dużej zmianie, na przykład po konwersji do SAP S/4HANA. Testy wspiera RedLab AI box, nasze stanowisko z lokalnymi modelami językowymi bez blokad odmowy, które pomagają testerowi w analizie konfiguracji i kodu. Modele działają lokalnie, więc dane z testu nie trafiają do zewnętrznej usługi. Wszystkie trzy warstwy są opcjami. Zakres dobieramy do ryzyka i regulacji, którym podlega dana organizacja.
## Utrzymanie i bezpieczeństwo w jednych rękach - Stock Spirits i sieć handlowa
Stock Spirits Group, producent alkoholi prowadzący działalność w dziewięciu krajach Europy, pracuje z nami od 2023 roku. Zakres, potwierdzony przez klienta w listach referencyjnych, obejmuje całodobowe wsparcie i utrzymanie systemów SAP ERP ECC oraz SAP S/4HANA razem z platformą SecurityBridge, utrzymanie platformy UiPath i jej botów, a także administrację i monitoring środowisk rozproszonych w trzech lokalizacjach fizycznych. Przeprowadziliśmy też audyt bezpieczeństwa systemów deweloperskich, testowych i produkcyjnych obu platform.
W rozmowie z ITwiz menedżer odpowiedzialny po stronie klienta za infrastrukturę IT i cyberbezpieczeństwo grupy opisał ten model tak: „W STOCK mamy dodatkowo taki luksus, że operacyjnie w obszarze SAP BASIS wspiera nasz zespół SNOK - i to on w większości przypadków odpowiada za reagowanie na alerty SecurityBridge”. Platformę SecurityBridge uruchomiliśmy produkcyjnie w trzy tygodnie, a w czasie migracji do SAP S/4HANA klient mógł na jednej licencji monitorować nowy system i równolegle stare środowisko produkcyjne SAP ECC.
Siedem powtarzalnych procesów administracyjnych wykonują u klienta boty UiPath, a środowisko ERP z ponad 700 użytkownikami jest objęte monitoringiem bezpieczeństwa przez całą dobę. Pełny opis znajdziecie w [case study](/pl/realizacje/#producent-fmcg-bezpieczne-erp).
Ten sam model utrzymania prowadzimy w sieci handlowej z branży DIY: całodobowe wsparcie i utrzymanie SAP S/4HANA wraz z powiązanymi systemami, w tym samym zakresie co w Stock Spirits, tylko bez platformy SecurityBridge. Moduły bezpieczeństwa dobieramy więc do potrzeb klienta, nie są warunkiem usługi.
## SAP Solution Manager po 2027 roku
Dla wielu zespołów Basis podstawowym narzędziem monitoringu wciąż jest SAP Solution Manager. Standardowe utrzymanie SAP Solution Manager 7.2 kończy się wraz z końcem 2027 roku. Firmy, które wykupią utrzymanie rozszerzone SAP Business Suite 7 do końca 2030 roku, dostaną je również dla Solution Managera bez dodatkowej opłaty, ale tylko dla wskazanych obszarów: zarządzania wymaganiami, projektami i procesami, Test Suite, kontroli zmian, ITSM i zarządzania krajobrazem. Monitoringu na tej liście nie ma. SAP rekomenduje przejście do SAP Cloud ALM przed końcem 2027 roku.
Dla umowy utrzymaniowej oznacza to konkretne pytanie: na jakim narzędziu dostawca będzie monitorował Wasz system w 2028 roku i kto przeniesie reguły oraz własne kontrole konfiguracji. Warto je zadać teraz, póki jest czas na przeniesienie reguł bez pośpiechu.
## Jak przebiega przejęcie utrzymania od obecnego dostawcy
Przejęcie zaczynamy od audytu stanu środowiska: inwentarza systemów, konfiguracji, dokumentacji, długu technicznego i obecnych procedur. Na jego podstawie ustalamy SLA, ścieżkę eskalacji i podział odpowiedzialności - co robi SNOK, co zostaje po stronie Waszego zespołu i co zależy od dostawcy chmury albo infrastruktury.
Pierwszy miesiąc pracujemy obok obecnego zespołu. Poznajemy cykle operacyjne, powtarzalne incydenty i nieopisane obejścia, które są w każdym systemie działającym od kilkunastu lat. Od drugiego miesiąca odpowiadamy za uzgodniony zakres, a co miesiąc przekazujemy raport dla CIO, raz na kwartał zaś omawiamy przegląd usługi z zarządem albo komitetem sterującym.
## Jak sprawdzić dostawcę SAP Basis przed podpisaniem umowy
Prezentacja handlowa niewiele powie o jakości utrzymania. Więcej powiedzą odpowiedzi na kilka pytań:
**1.** Jak wygląda Wasz codzienny przegląd systemu i czy możemy zobaczyć przykładowy raport?
**2.** Kto konkretnie odbiera alert w nocy i jaka jest ścieżka eskalacji do specjalisty od bazy danych?
**3.** Jak oceniacie noty z SAP Security Patch Day i ile dni mija u Waszych klientów od publikacji noty HotNews do jej wdrożenia na produkcji?
**4.** Kto reaguje na alerty bezpieczeństwa i czy jest to ten sam zespół, który wprowadza zmiany w konfiguracji?
**5.** Na jakim narzędziu będziecie monitorować nasz system po zakończeniu standardowego utrzymania SAP Solution Manager?
**6.** Co przekażecie nam przy zakończeniu umowy?
Pełniejszą wersję tych pytań, razem z zakresem usługi, klasami incydentów i kryteriami wyjścia, zebraliśmy w [liście kontrolnej przejęcia utrzymania SAP Basis](/pl/materialy/lista-kontrolna-przejecia-sap-basis/) do pobrania.
## Co robimy w SNOK
Prowadzimy [SAP Basis 24/7 w modelu managed service](/pl/oferta/bezpieczenstwo-sap/sap-basis-24-7/): monitoring, poprawki i SAP Security Notes, strojenie wydajności, zarządzanie zmianą i transportami, administrację SAP HANA oraz obsługę incydentów przez całą dobę. Opcjonalnie dokładamy monitoring bezpieczeństwa SecurityBridge, hardening konfiguracji i okresowe testy penetracyjne SAP. Utrzymujemy systemy on-premise i w chmurze, także w modelu RISE with SAP, a przy przejściu z SAP ECC wspieramy [konwersję do SAP S/4HANA](/pl/oferta/bezpieczenstwo-sap/konwersja-s4hana/). Warstwę systemu operacyjnego i sprzętu znamy z partnerstw z [SUSE](/pl/suse-snok/) i [Lenovo](/pl/lenovo-snok/).
Jeżeli przygotowujecie zmianę modelu utrzymania albo dostawcy, zacznijcie od [listy kontrolnej przejęcia utrzymania SAP Basis](/pl/materialy/lista-kontrolna-przejecia-sap-basis/). Gdy będziecie gotowi na rozmowę, [umówcie 30 minut z naszym zespołem](/pl/oferta/bezpieczenstwo-sap/sap-basis-24-7/). Omówimy obecny krajobraz SAP, wymagane SLA i to, co powinno wejść do zakresu. Szerszy kontekst bezpieczeństwa systemów SAP opisujemy w książce [Cyberbezpieczeństwo SAP od A do Z](/pl/materialy/cyberbezpieczenstwo-sap-od-a-do-z/).
---
### Źródła
- ITwiz, *Udany atak na systemy SAP może zatrzymać każdy biznes*, Executive ViewPoint (prezentacja partnera), 26 czerwca 2025 - [itwiz.pl](https://itwiz.pl/udany-atak-na-systemy-sap-moze-zatrzymac-kazdy-biznes/)
- SAP, *SAP Solution Manager 7.2* - informacja o utrzymaniu i przejściu do SAP Cloud ALM, SAP Note 3255311 - [support.sap.com](https://support.sap.com/en/alm/solution-manager.html) (dostęp 6 października 2026)
- SAP Community, Jana Subramanian, *RISE with SAP S/4HANA Cloud, Private Edition: Cybersecurity FAQ Explained* - [community.sap.com](https://community.sap.com/t5/technology-blog-posts-by-sap/rise-with-sap-s-4hana-cloud-private-edition-cybersecurity-faq-explained/ba-p/13562875)
- SNOK, case study *Krytyczne ERP pod ochroną 24/7 - bez powiększania zespołu IT klienta* - [snok.ai](/pl/realizacje/#producent-fmcg-bezpieczne-erp)
---
### UiPath w dziale cyberbezpieczeństwa - 13 000 godzin, które zespół bezpieczeństwa UiPath zaoszczędził własną platformą
URL: https://snok.ai/pl/aktualnosci/blog/uipath-dla-dzialu-cyberbezpieczenstwa/ | Data: 2026-10-06 | Seria: Bezpieczny Wtorek
W październiku 2025 roku Scott Roberts, CISO UiPath, powiedział, że agent analityka zagrożeń, zbudowany przez jego zespół na platformie UiPath, zaoszczędził **ponad 13 000 godzin** pracy przy obsłudze alertów. W tej samej rozmowie podał dwa szczegóły: jeden z przepływów to rój 61 agentów działających równolegle, a w niektórych przypadkach dochodzenie, które zajmowało do czterech godzin, trwa teraz około półtorej minuty. W lutym 2026 roku opisał całość jako orkiestrację ponad 60 agentów, które badają alerty z SIEM od początku do końca i przygotowują ustrukturyzowany opis incydentu.
To deklaracja producenta bez niezależnego pomiaru i tak ją traktujemy. Ma jednak jedną zaletę: opisuje konkretny mechanizm we własnym dziale bezpieczeństwa firmy, która tę platformę sprzedaje. Z tego mechanizmu da się wyprowadzić odpowiedź na pytanie, do czego w dziale cyberbezpieczeństwa służy platforma automatyzacji, skoro jest już SIEM, EDR i SOAR.
**W skrócie:**
**1/** zespół bezpieczeństwa UiPath (TrustOps) używa własnej platformy do triażu alertów, oceny podatności w kontekście produktu i kontroli wyników agentów przez innych agentów,
**2/** UiPath w dziale cyberbezpieczeństwa nie zastępuje SIEM - w 2026 roku sam producent nazywa swoje rozwiązanie warstwą SOAR, która wykonuje działania tam, gdzie nie ma API, przejmuje pracę wokół incydentu i audytu, a przy akcjach o wysokim wpływie oddaje decyzję człowiekowi,
**3/** w bezpieczeństwie SAP gotowych materiałów jest najmniej, choć ręcznej pracy nie brakuje: przeglądy uprawnień, konta botów, podatności z SAP Security Patch Day,
**4/** warunkiem jest kontrola nad samymi botami - bot w funkcji bezpieczeństwa skupia uprawnienia, których nie dalibyście jednej osobie.
Animacja bez dźwięku, 24 s - od alertu z SIEM przez agentów UiPath do sześciu funkcji NIST CSF 2.0. Liczby w animacji: zespół bezpieczeństwa UiPath, 2025-2026; konsola SIEM jest poglądowa.
## Co zespół bezpieczeństwa UiPath robi własną platformą
Najwięcej szczegółów zawierają trzy źródła: w rozmowie Scotta Robertsa z firmą Averlon (21.10.2025), w podcaście Shift AI (21.02.2026) i we wpisie Kevina Mooneya, Field CISO UiPath, z 9 lipca 2026 roku, zapisanym na podstawie rozmowy czterech osób z zespołu TrustOps. Z tych źródeł oraz ze studium przypadku Dropzone AI wyłaniają się cztery zastosowania.
**Agent analityka zagrożeń.** Alert z SIEM trafia do orkiestracji ponad 60 agentów. Agenci badają zdarzenie od początku do końca i przygotowują ustrukturyzowany opis incydentu. Właśnie temu agentowi Roberts przypisuje ponad 13 000 zaoszczędzonych godzin.
**Agent sprawdzający agenta.** W przepływach, w których wynik modelu nie jest deterministyczny, zespół stosuje tak zwanych agentów sędziów: jeden agent przygotowuje wynik, a drugi sprawdza go przed kolejnym krokiem. Naszym zdaniem to mechanizm, który najłatwiej przenieść do innych organizacji, bo odpowiada na pierwszy zarzut wobec AI w bezpieczeństwie - że model się pomyli i nikt tego nie zauważy.
**Podatności oceniane w kontekście.** Roberts mówi o średnio 500 nowych podatnościach tygodniowo napływających z samego oprogramowania open source. Typowy skaner porównuje nazwę i wersję komponentu z bazą CVE i podaje ocenę z bazy. Według wpisu Mooneya zespół UiPath połączył RPA, które zbiera dane, z agentami generatywnymi, które czytają opis podatności i informacje dostawcy, oraz z ciągłym skanowaniem i analizą wykorzystywalności, a całość orkiestrują agenci i roboty UiPath. Wynik to ocena CVSS z metrykami bazowymi, czasowymi i środowiskowymi, uzupełniona analizą wykorzystywalności - czyli ocena istotności podatności w kontekście konkretnego produktu.
Osobny przypadek Roberts opisał w rozmowie z Averlon: przy krytycznym zero-dayu skanery wskazały dziesiątki tysięcy wystąpień podatności - Roberts mówi o około 20 000 instancjach do załatania w oknie dwóch godzin. Narzędzie Averlon zawęziło je do ścieżek osiągalnych dla atakującego, a te zespół załatał w ciągu godzin. To przykład tej samej zasady - liczy się wykorzystywalność, nie sama obecność komponentu - zrealizowanej narzędziem innego dostawcy.
**Triaż pierwszej linii.** Pierwszą linię triażu prowadzi agent firmy Dropzone AI: zamyka proste alerty, a trudniejsze eskaluje z pełnym kontekstem do agentowego SOC zbudowanego przez UiPath. Studium przypadku opublikowane przez Dropzone AI podaje w bloku wyników 86% mniej fałszywych alarmów i ponad 700 godzin pracy analityków zaoszczędzonych w sześć miesięcy.
We wpisie z lipca UiPath zapowiada, że rozwiązania z obszaru cyberbezpieczeństwa udostępniane klientom są pierwszą częścią tego, co zespół TrustOps już stosuje u siebie. Zapowiedź nie wskazuje, które z opisanych mechanizmów są już produktem, więc dostępność każdego z nich trzeba sprawdzić osobno.
## Gdzie UiPath pracuje w dziale cyberbezpieczeństwa
Pełniejszy obraz daje nasza mapa zastosowań ułożona według sześciu funkcji NIST CSF 2.0. W każdej z nich jest praca, która leży pomiędzy systemami: SIEM, EDR ani narzędzie GRC jej nie obejmują.
**Zarządzanie (Govern).** Dowody do audytu ISO 27001, SOX albo KSC, czyli polskiego wdrożenia NIS2, to zrzuty ekranu, eksporty i listy użytkowników. Robot może zbierać je według harmonogramu, z datą i źródłem, zamiast ręcznie przed każdą kontrolą. W tej samej funkcji mieści się ocena dostawców pod DORA: pobranie raportu SOC 2 lub SOC 3, odczyt audytora, okresu i zakresu, porównanie z wymaganiami - to nasza propozycja przepływu. Pierwszą część UiPath pokazał w demonstracji UiPath ScreenPlay z grudnia 2025 roku: robot odnajduje raport SOC 3 dostawcy i odczytuje z niego audytora, okres, typ raportu i zakres.
**Identyfikacja (Identify).** Podatności oceniane w kontekście, jak w TrustOps, oraz uzgadnianie inwentarza: czy każde urządzenie z CMDB ma agenta EDR i czy skaner widzi wszystko, co powinien.
**Ochrona (Protect).** Cykl życia kont - zatrudnienie, zmiana roli, odejście - oraz reset haseł i odblokowanie kont. UiPath podawał w 2022 roku, że u niego automatyzacja zarządzania użytkownikami skróciła obsługę zgłoszenia ITSM z dwóch godzin do dwóch minut. Według studium opublikowanego przez UiPath Jana Small Finance Bank przy 300-400 prośbach o reset hasła dziennie skrócił tę pracę z 3-4 godzin dziennie do niecałej godziny. Do tego przegląd uprawnień z akceptacją właściciela w UiPath Action Center.
**Wykrywanie (Detect).** Logi robotów i agentów w SIEM. Od wydania 2025.10 zunifikowany dziennik audytu zbiera zdarzenia wszystkich usług platformy w jednym miejscu i według UiPath łączy aktywność automatyzacji z systemami obserwowalności, takimi jak Splunk czy Microsoft Sentinel. Każdy agent działa na własnej tożsamości, z uprawnieniami przypisanymi tak jak ludziom i robotom.
**Reagowanie (Respond).** Triaż alertów przez agentów oraz akcje, których SIEM nie wykona, bo zapora albo stary system nie mają API: blokada adresu, kwarantanna pliku, izolacja urządzenia. UiPath podawał w 2022 roku, że jego własne automatyzacje blokują ponad 20 000 ataków brute force rocznie. W tej funkcji mieści się też szkic zgłoszenia incydentu do CSIRT - fakty, terminy, wersja do akceptacji. Klasyfikacja incydentu jako poważnego zostaje przy człowieku.
**Odtwarzanie (Recover).** Raport po incydencie, rejestr wniosków, działania korygujące przypisane właścicielom w systemie zgłoszeń. Automatyzacja pilnuje tu przede wszystkim, żeby wnioski po incydencie trafiły do właścicieli.
## Gdzie UiPath kończy działanie
UiPath nie zastępuje SIEM i nie jest platformą operacji bezpieczeństwa w rodzaju Splunk SOAR czy Cortex XSOAR, choć w 2022 roku pisał, że umożliwia pełnoskalowy SOAR, a w 2026 roku nazywa swoje rozwiązanie warstwą SOAR i udostępnia akcelerator SOAR w Marketplace. Narzędzia operacji bezpieczeństwa przesuwają się w stronę własnych agentów AI - Splunk, Torq, Tines, Swimlane i wyspecjalizowane firmy budują je u siebie. UiPath wchodzi tam, gdzie te narzędzia kończą działanie: w systemach bez API, w procesach biznesowych wokół incydentu i w akceptacji przez człowieka.
Najwięcej gotowych łączników dotyczy dziś stosu Microsoftu. UiPath Integration Service ma łączniki do Microsoft Sentinel, Defender for Cloud, Sentinel Threat Intelligence, Entra ID i ServiceNow, a w Marketplace są łączniki do VirusTotal, AbuseIPDB, urlscan.io, Shodan, Defender for Endpoint i CrowdStrike. W marcu 2026 roku UiPath ogłosił współpracę z Microsoftem, w której Defender for Cloud skanuje pliki krążące w procesach biznesowych, Sentinel dostaje incydent z kontekstem, a robot wykonuje kwarantannę albo wstrzymuje proces.
Dla Splunka i Splunk SOAR gotowego łącznika nie znaleźliśmy. Integrację trzeba zaprojektować przez REST API - na przykład tak, żeby alert w Splunku uruchamiał proces w Orchestratorze, a robot zapisywał wynik z powrotem. To osobny projekt integracyjny.
## SAP: dużo ręcznej pracy, mało gotowych rozwiązań
W bezpieczeństwie SAP ręcznej pracy jest dużo, a materiałów o jej automatyzacji najmniej. Pytanie o automatyzację SAP GRC na forum UiPath z kwietnia 2022 roku ma prawie 1500 wyświetleń, a odpowiedzi ograniczają się do ogólnej informacji, że da się zautomatyzować każdy interfejs SAP. W materiałach, które przejrzeliśmy, dostawcy bezpieczeństwa SAP nie wspominają o UiPath, a UiPath nie ma oficjalnego opisu automatyzacji SAP GRC ani SAP Security Patch Day - jest jedynie ogólny wpis społeczności o automatyzacji audytu i zgodności w SAP z października 2024 roku. 29 września 2026 roku UiPath i BDO USA zapowiedziały akceleratory audytu wewnętrznego z ciągłym przeglądem uprawnień, walidacją nadawania i odbierania dostępu oraz monitoringiem rozdziału obowiązków w systemach ERP i chmurowych. Na razie to zapowiedź bez opisanego wdrożenia.
W SAP zaczęlibyśmy od trzech zastosowań.
**Podatności z SAP Security Patch Day w kontekście.** Co miesiąc SAP publikuje noty bezpieczeństwa, a zespół musi ustalić, które dotyczą jego wersji, komponentów i konfiguracji. Mechanizm z TrustOps - zbieranie danych robotem, odczyt opisu agentem, ocena wykorzystywalności - da się przenieść na noty SAP, a dane o stanie systemów może dostarczać [SecurityBridge](/pl/oferta/bezpieczenstwo-sap/securitybridge/). Wynikiem byłaby lista not z właścicielem i terminem.
**Konta botów w SAP.** Robot pracujący w SAP GUI potrzebuje konta dialogowego, a robot korzystający z BAPI może działać na koncie systemowym. Każde z nich ma inne ryzyko, a integracja przez RFC wymaga dodatkowo uprawnień, które trzeba świadomie nadać i przeglądać. Konto bota bez wskazanego właściciela może zostać pominięte w przeglądzie uprawnień, bo nikt nie potwierdza jego uprawnień.
**Przegląd uprawnień i dowody dla audytora.** Robot może zbierać eksporty i zrzuty z datą, porównywać je z listą zatwierdzonych uprawnień i kierować rozbieżności do właściciela. Gdy ścieżka ataku jest już znana, na przykład z narzędzia klasy [SAPMAP](/pl/aktualnosci/blog/sapmap-bloodhound-dla-sap/), ten sam mechanizm może pilnować, czy zamknięte uprawnienia nie wracają.
## Warunek: boty pod kontrolą działu bezpieczeństwa
Bot w funkcji bezpieczeństwa potrzebuje szerokiego dostępu do odczytu - dostawcy tożsamości, EDR, skanera, CMDB - i często także prawa do zmian: blokady konta, zamknięcia zgłoszenia, izolacji urządzenia. Taki zestaw uprawnień nie trafiłby do jednej osoby. Dlatego automatyzacja w dziale bezpieczeństwa zaczyna się od kontroli nad samymi botami.
Najlepiej udokumentowany przykład tego, co dzieje się bez niej, to audyt amerykańskiego inspektora generalnego GSA z 6 sierpnia 2024 roku. Program automatyzacji agencji nie spełniał jej własnych wymogów bezpieczeństwa IT, a plany bezpieczeństwa systemów nie były konsekwentnie aktualizowane o dostęp botów. Zamiast usunąć te braki, kierownictwo programu usunęło albo złagodziło wymagania. Agencja nie miała też procesu odbierania dostępu po wycofaniu bota: 55 z 56 opiekunów wycofanych botów zachowało dostęp dłużej niż przewidziane 14 dni.
Pięć warunków wstępnych:
**1/** własne konto każdego bota, z właścicielem po stronie biznesu, nigdy konto współdzielone,
**2/** hasła w sejfie - Orchestrator integruje się z CyberArk jako systemem PAM oraz z magazynami sekretów, takimi jak Azure Key Vault i HashiCorp Vault,
**3/** minimalne uprawnienia i rozdział obowiązków między botem a człowiekiem, który go nadzoruje,
**4/** logi robotów i agentów w SIEM, żeby każda akcja bota miała ślad,
**5/** odebranie dostępu bota, jego opiekunów i deweloperów w dniu wycofania bota, objęte tym samym procesem co odejście pracownika.
To samo dotyczy agentów AI. Akcje o wysokim wpływie wymagają akceptacji człowieka - pisaliśmy o tym przy [HITL gate w UiPath Maestro i AI Trust Layer](/pl/aktualnosci/blog/hitl-gate-uipath-maestro-ai-trust-layer/).
## Jak pracujemy z działami cyberbezpieczeństwa
SNOK łączy w tym obszarze trzy kompetencje: bezpieczeństwo SAP, partnerstwo UiPath Platinum i własny system zarządzania bezpieczeństwem informacji z certyfikatem ISO 27001. Działom bezpieczeństwa proponujemy cztery etapy:
**1/** inwentarz botów i agentów - konta, uprawnienia, właściciele, poświadczenia, logi; to [audyt bezpieczeństwa AI](/pl/oferta/automatyzacja-ai/ai-security/) przed każdym kolejnym wdrożeniem,
**2/** wybór dwóch lub trzech procesów wymagających najwięcej pracy ręcznej, na przykład zbierania dowodów do audytu, przeglądu uprawnień i obsługi kont,
**3/** wdrożenie w [UiPath Maestro](/pl/oferta/automatyzacja-ai/uipath-maestro/) z akceptacją człowieka przy akcjach o wysokim wpływie i pomiarem czasu przed wdrożeniem i po nim,
**4/** przełożenie na SAP - [SAP Security Patch Day](/pl/oferta/bezpieczenstwo-sap/sap-security-patch-day/), konta botów, przeglądy uprawnień - oraz dowody pod [audyt NIS2 i DORA](/pl/oferta/bezpieczenstwo-sap/audyt-nis2-dora/).
Szerzej opisujemy to w ofercie [cyberbezpieczeństwa](/pl/oferta/cyberbezpieczenstwo/) i na stronie [UiPath w SNOK](/pl/uipath-snok/). Wcześniejsze spojrzenie na UiPath w operacjach bezpieczeństwa znajdziecie we wpisie [UiPath jako agentyczny strażnik cyberbezpieczeństwa](/pl/aktualnosci/blog/bezpieczny-wtorek-ze-snok-uipath-jako-agentyczny-straznik-cyberbezpieczenstwa/).
## Od czego zacząć
Pierwszy krok nie wymaga nowej licencji. To lista wszystkich botów i agentów, które dziś działają w Waszej organizacji, z kontem, uprawnieniami i właścicielem przy każdym z nich. Jeżeli taka lista istnieje i jest aktualna, macie podstawę, żeby powierzyć botom pracę działu bezpieczeństwa. Jeżeli trzeba ją dopiero zbudować, od niej warto zacząć.
[Napiszcie do nas](/pl/kontakt/) - pokażemy, jak wygląda inwentarz botów i pierwszy proces działu bezpieczeństwa w UiPath.
## Źródła
- UiPath, Kevin Mooney, „When AI finds everything, the trick is knowing which vulnerabilities matter”, 9.07.2026, [uipath.com](https://www.uipath.com/blog/ai/how-ai-is-changing-vulnerability-management) (dostęp 5.10.2026).
- Averlon, webinar „Inside UiPath: How Agentic AI is Redefining Security in the AI Era” ze Scottem Robertsem, 21.10.2025, [averlon.ai](https://www.averlon.ai/webinars/inside-uipath-redefining-security-ai-era) (dostęp 5.10.2026).
- Shift AI Podcast, „Securing Agentic Automation in the Enterprise with UiPath CISO Scott Roberts”, 21.02.2026, [YouTube](https://www.youtube.com/watch?v=T_V3kbYVeXE) (dostęp 5.10.2026).
- Dropzone AI, „How UiPath Extended Its Agentic SOC with AI SOC Analysts”, [dropzone.ai](https://www.dropzone.ai/case-studies/how-uipath-extended-its-agentic-soc-with-ai-soc-analysts) (dostęp 5.10.2026).
- UiPath, Jagjit Dhaliwal, „How is UiPath Automating Cybersecurity Operations?”, 24.05.2022, [uipath.com](https://www.uipath.com/blog/automation/automating-cybersecurity-operations) (dostęp 5.10.2026).
- UiPath, Andrei Oros, „Are your enterprise automation workflows connected to your security stack?”, 18.03.2026, [uipath.com](https://www.uipath.com/blog/product-and-updates/are-enterprise-automation-workflows-connected-security-stack) (dostęp 5.10.2026).
- UiPath, Andrei Hinodache, „Governance and security for the agentic enterprise: new in the 2025.10 release”, 19.11.2025, [uipath.com](https://www.uipath.com/blog/product-and-updates/agentic-enterprise-governance-and-security-2025-10-release) (dostęp 5.10.2026).
- UiPath, studium Jana Small Finance Bank, [uipath.com](https://www.uipath.com/resources/automation-case-studies/jana-small-finance-bank) (dostęp 5.10.2026).
- UiPath, „UiPath Expands Partnership with BDO”, 29.09.2026, [uipath.com](https://www.uipath.com/newsroom/uipath-expands-partnership-with-bdo) (dostęp 5.10.2026).
- GSA Office of Inspector General, „GSA Should Strengthen the Security of Its Robotic Process Automation Program”, raport A230020/B/T/F24004, 6.08.2024, [oversight.gov](https://www.oversight.gov/reports/audit/gsa-should-strengthen-security-its-robotic-process-automation-program) (dostęp 5.10.2026).
- NIST, „The NIST Cybersecurity Framework (CSF) 2.0”, 26.02.2024, [nist.gov](https://www.nist.gov/cyberframework) (dostęp 5.10.2026).
- Forum UiPath, „UiPath Studio With SAP GRC”, 27.04.2022, [forum.uipath.com](https://forum.uipath.com/t/uipath-stuido-with-sap-grc/418670) (dostęp 5.10.2026).
- UiPath Community Blog, Ashish Pandey (RPATech), „Automating SAP compliance and audit processes with UiPath”, 3.10.2024, [uipath.com](https://www.uipath.com/community-blog/tutorials/automating-sap-compliance-and-audit-processes) (dostęp 6.10.2026).
---
### SUSE w ćwiartce liderów Gartner Magic Quadrant for Container Management - flota klastrów, brzeg sieci i suwerenność
URL: https://snok.ai/pl/aktualnosci/blog/suse-lider-gartner-magic-quadrant-container-management/ | Data: 2026-10-05 | Seria: Ogłoszenia
W wielu firmach Kubernetes jest już infrastrukturą, która ma działać tak samo jak sieć czy pamięć masowa. Trudność przesunęła się z uruchomienia klastrów na utrzymanie spójnych zasad w środowiskach, które w jednej firmie pochodzą od różnych dostawców i stoją w różnych miejscach. Tak właśnie opisuje rynek **Gartner Magic Quadrant for Container Management** z **2 września 2026**.
Gartner ocenił **szesnastu dostawców**. W ćwiartce liderów jest **siedmiu**, wśród nich **SUSE**. Ćwiartka wizjonerów w tej edycji jest pusta. Liderzy w kolejności alfabetycznej to Alibaba Cloud, AWS, Google, Huawei, Microsoft, Red Hat i SUSE; kolejność nie oznacza rankingu, bo Gartner nie rankinguje liderów. Autorami raportu są Dennis Smith, Tony Iams i czterech innych analityków.
**W skrócie:**
**1/** Gartner opisuje rynek jako dojrzały: sukces zależy od jednolitej płaszczyzny zarządzania klastrami, polityk i bezpieczeństwa w środowiskach lokalnych, chmurowych i brzegowych,
**2/** poprzeczka wejścia jest wysoka także po stronie biznesu: podstawowy próg to 50 mln USD rocznego przychodu z tej kategorii (w ścieżce alternatywnej 15 mln USD) i klienci produkcyjni w kilku regionach świata,
**3/** w SUSE Gartner wyróżnia trzy rzeczy: zarządzanie różnymi dystrybucjami Kubernetesa z jednej płaszczyzny, mocną pozycję na brzegu sieci dzięki K3s oraz możliwości suwerenne, które łączą europejskiego właściciela z mocnymi kompetencjami technicznymi,
**4/** SUSE informuje w swoim komunikacie, że jest liderem po raz trzeci z rzędu.
*Rysunek 1: Magic Quadrant for Container Management. Źródło: Gartner (wrzesień 2026), publikujemy bez zmian. This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available from [SUSE](https://www.suse.com/campaigns/2026-gartner-mq-container-management/).*
---
## Jak Gartner opisuje rynek zarządzania kontenerami
Gartner definiuje zarządzanie kontenerami jako oferty, które wspierają wdrażanie i obsługę obciążeń kontenerowych oraz powiązanych zasobów, z centralnym nadzorem nad politykami i bezpieczeństwem. Obowiązkowe funkcje to między innymi orkiestracja i harmonogramowanie, środowisko uruchomieniowe kontenerów, rejestr artefaktów, routing i sieć, katalog usług, interfejs zarządzania oraz dostęp przez API. Do opcjonalnych należą zarządzanie flotą klastrów, wsparcie dla platform engineeringu, polityki i zgodność, bezpieczeństwo łańcucha dostaw obrazów, a także obsługa maszyn wirtualnych i obciążeń AI.
Więcej mówi opis rynku. Gartner pisze, że rynek dojrzewa i przechodzi od innowacji do praktycznej optymalizacji. Oszczędności, których firmy oczekiwały od kontenerów, często zjada rosnący narzut operacyjny, a własnościowe dodatki dostawców utrudniają faktyczną przenośność. Zainteresowanie środowiskami hybrydowymi i wielochmurowymi jest duże, ale uzależnienie od dostawcy pozostaje przeszkodą. Gartner zwraca też uwagę, że sprawnie działają te organizacje, które centralizują wsparcie w zespole platform engineeringu, zamiast rozpraszać je po zespołach. W praktyce pytanie przesuwa się z „jak uruchomić Kubernetes” na „kto to wszystko prowadzi i według jakich zasad”.
Warunki wejścia do zestawienia też mówią coś o kategorii. Dostawca musi wykazać co najmniej **50 mln USD** rocznego przychodu GAAP z oferty zarządzania kontenerami, **50 płacących klientów produkcyjnych** oraz po pięciu klientów w co najmniej trzech z siedmiu regionów świata. Alternatywnie wystarczy 15 mln USD przychodu, 15 nowych klientów w 2025 roku i po trzech klientów w co najmniej dwóch regionach. Dodatkowo oferta musi być sprzedawana bez obowiązkowych usług profesjonalnych, z pierwszą linią wsparcia po stronie dostawcy, także dla dołączonego oprogramowania open source.
## Za co Gartner wyróżnia SUSE
Gartner opisuje portfolio SUSE jako rozbudowane i elastyczne. Rdzeniem jest **SUSE Rancher Prime**, platforma zarządzania w środowiskach hybrydowych, wielochmurowych i brzegowych. Uzupełniają ją dwie wyspecjalizowane dystrybucje: **RKE2**, utwardzony Kubernetes dla środowisk o wysokich wymaganiach regulacyjnych, oraz **K3s**, lekka dystrybucja do miejsc o ograniczonych zasobach. Do tego dochodzi **SUSE Virtualization**, rozwiązanie łączące wirtualizację, orkiestrację Kubernetesa i pamięć masową w jednym stosie.
Gartner wymienia trzy mocne strony.
**Zarządzanie różnymi dystrybucjami z jednej płaszczyzny.** Rancher potrafi zarządzać wieloma dystrybucjami Kubernetesa niezależnie od tego, czy klastry stoją lokalnie, w chmurze publicznej, czy na brzegu sieci. Według Gartnera pozwala to wybierać dostawcę do każdego zastosowania osobno, bez płacenia za to rozproszonymi narzędziami i rozproszonymi kompetencjami zespołu.
**Brzeg sieci i K3s.** K3s daje pełne API Kubernetesa w niewielkim zasobowo wydaniu. Dzięki temu zespół platformowy przenosi zasady zarządzania i bezpieczeństwa znane z centrum danych do zdalnych lokalizacji, takich jak hale produkcyjne czy oddziały, bez dużych nakładów na sprzęt.
**Możliwości suwerenne.** Gartner wskazuje europejskiego właściciela SUSE, w połączeniu z mocnymi kompetencjami technicznymi, jako przewagę dla klientów, którzy stawiają na rozwiązania suwerenne. Według raportu zmniejsza to część ryzyk geopolitycznych w łańcuchu dostaw i upraszcza spełnienie wymogów lokalizacji danych, takich jak RODO. Dodajemy od siebie jedno zastrzeżenie: właściciel dostawcy to jeden z elementów oceny, a nie jej zastępnik. Zgodność z RODO, NIS2 czy DORA zależy od sposobu wdrożenia i procesów w Waszej organizacji.
## Pytania przed wyborem platformy
Gartner sam zastrzega, że lider nie jest najlepszym wyborem w każdym zastosowaniu. Raport przydaje się raczej jako lista pytań, które poprzedzają decyzję.
**Kilka dystrybucji i kilka chmur jednocześnie.** Jeżeli część klastrów stoi u dostawcy chmury, część w Waszym centrum danych, a część powstała w projektach, których nikt nie porządkował, najpierw potrzebujecie jednego widoku: gdzie są klastry, jakie mają wersje, kto ma do nich dostęp i jakie polityki obowiązują. Dopiero potem wybieracie narzędzie.
**Zdalne lokalizacje.** Hala produkcyjna, magazyn, oddział. Tam zwykle nie ma zespołu platformowego, a klaster musi działać i być aktualizowany zdalnie. To zastosowanie, dla którego powstał K3s.
**Wymagania dotyczące lokalizacji danych i zależności od dostawcy.** Dla firm regulowanych pytanie o to, kto jest właścicielem dostawcy i gdzie leży kontrola operacyjna, bywa częścią oceny ryzyka. Raport wprost nazywa to cechą SUSE.
**Maszyny wirtualne obok kontenerów.** Po zmianach cenowych w wirtualizacji wiele firm przegląda swoje środowiska. SUSE Virtualization pozwala prowadzić maszyny wirtualne i kontenery na jednej platformie. W środowiskach SAP ten wątek opisaliśmy we wpisie [VMware czy KVM dla SAP](/pl/aktualnosci/blog/vmware-kvm-sap-suse-broadcom-2026/).
SUSE ma w ofercie także osobny produkt, [SUSE Rancher for SAP applications](https://www.suse.com/products/rancher-for-sap/). Gartner go w raporcie nie ocenia, więc jego możliwości traktujemy jako deklarację producenta i sprawdzamy w każdym projekcie osobno.
## Od czego zaczynamy w SNOK
Jesteśmy **SUSE Gold Partner**. Zakres współpracy opisaliśmy na [stronie partnerstwa z SUSE](/pl/suse-snok/), a wszystkie autoryzacje razem na [stronie partnerstw](/pl/partnerstwa/).
Rozmowę o platformie kontenerowej zaczynamy od trzech kroków.
**Spisujemy to, co już stoi.** Ile jest klastrów, jakich dystrybucji, gdzie, kto je utrzymuje i które obciążenia są krytyczne. To zadanie dla [doradztwa i integracji IT](/pl/oferta/doradztwo-i-integracja-it/), bo wynik często zmienia pierwotne pytanie.
**Wybieramy jedną płaszczyznę zarządzania na części środowiska.** Pilotaż obejmuje kilka klastrów o różnym charakterze, a kryteria sukcesu ustalamy przed startem: wersje, polityki, dostęp, aktualizacje.
**Zabezpieczamy i utrzymujemy.** Utwardzanie konfiguracji, polityki dostępu i ciągłość działania to zakres [cyberbezpieczeństwa](/pl/oferta/cyberbezpieczenstwo/), a gdy na platformie pracują systemy SAP, także [SAP Basis 24/7](/pl/oferta/bezpieczenstwo-sap/sap-basis-24-7/). Jeżeli na klastrze mają pracować modele językowe w Waszej infrastrukturze, wątek opisujemy jako [LLM on-premise](/pl/oferta/automatyzacja-ai/llm-on-premise/).
Wyróżnienie w Magic Quadrant należy do SUSE. Dla Was jest sygnałem, że kategoria zarządzania kontenerami została zmierzona według kryteriów, które dotyczą także Waszych decyzji: jednolitego nadzoru, przenośności i suwerenności. Inwentarz klastrów i pilotaż jednej płaszczyzny zarządzania na próbie pozwalają sprawdzić te kryteria we własnym środowisku. Jeżeli chcecie zacząć od inwentarza, [umówcie rozmowę](/pl/kontakt/).
---
## Źródła
- Gartner, *Magic Quadrant for Container Management*, 2 września 2026 (wersja poprawiona 3 września 2026), ID G00841470, autorzy: Dennis Smith, Tony Iams i czterech innych; dostęp 1 października 2026.
- Licencjonowany przedruk raportu udostępnia SUSE: [strona raportu](https://www.suse.com/campaigns/2026-gartner-mq-container-management/), dostęp 1 października 2026.
- SUSE, [SUSE Recognized as a Leader in 2026 Gartner Magic Quadrant for Container Management](https://www.suse.com/news/suse-recognized-as-a-leader-in-2026-gartner-magic-quadrant-for-container-management/), 8 września 2026, dostęp 5 października 2026.
GARTNER is a registered trademark and service mark, and MAGIC QUADRANT is a registered trademark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.
---
### Vendor lock-in w 2026 roku - złota kłódka czy pęk kluczy
URL: https://snok.ai/pl/aktualnosci/blog/vendor-lock-in-zlota-klodka-czy-pek-kluczy/ | Data: 2026-10-05 | Seria: Inne
Broadcom podał 2 września, że przychody jego segmentu oprogramowania infrastrukturalnego, czyli przede wszystkim VMware, wyniosły w ostatnim kwartale 8,75 mld USD. Rok wcześniej było to 6,79 mld USD, więc wzrost wyniósł 29%. W lutym CloudBolt opublikował badanie, w którym 86% dużych firm z Ameryki Północnej deklarowało, że aktywnie ogranicza użycie VMware. Całkowicie zrezygnowało z niego około 4%.
Te dwie liczby sobie nie przeczą i dobrze opisują vendor lock-in, czyli uzależnienie od dostawcy, w 2026 roku. Deklaracja wyjścia nic nie kosztuje, a dopóki migracja trwa, licencję trzeba odnawiać.
Piszę z pozycji, która nie jest neutralna. SNOK jest partnerem SAP, UiPath, SUSE, Lenovo, Microsoft i Google Cloud, więc na co dzień trzymamy w rękach i kłódkę, i klucze: wdrażamy platformy, które wiążą klientów na lata, i pomagamy klientom te więzy rozluźniać. Dlatego nie wskazuję tu kierunku. Bronię jednej tezy: uzależnienie wybrane świadomie i policzone przed decyzją jest decyzją architektoniczną, a przypadkowe poznajemy dopiero przy odnowieniu umowy.
*Okładkę wygenerowała AI na podstawie zdjęcia autora.*
## VMware pod Broadcomem - klienci deklarują wyjście, przychody rosną
Po przejęciu VMware pod koniec 2023 roku Broadcom zakończył sprzedaż licencji wieczystych i przeszedł na subskrypcje liczone od rdzeni procesora. W marcu 2025 roku dystrybutor zapowiedział partnerom minimum 72 rdzeni na zamówienie i dopłatę 20% za spóźnione odnowienie. Po fali krytyki, według heise, próg rdzeni wycofano i licencję nadal można kupić od 16 rdzeni. Sam spór o próg pokazał, jak szybko mogą zmienić się warunki zakupu. W styczniu 2026 roku Broadcom zamknął program dla większości dostawców chmury rozliczających VMware w modelu usługowym.
Spory trafiły już do sądów. Holenderski Rijkswaterstaat, który na VMware zarządza m.in. tunelami, śluzami i mostami, wywalczył w 2025 roku w sądzie w Hadze dwa lata wsparcia na migrację. Tesco pozwało Broadcom, VMware i Computacenter w Wielkiej Brytanii. Komisja Europejska wysłała Broadcomowi w lutym 2026 roku formalne żądanie informacji, a Sąd Ogólny UE w sierpniu odrzucił wniosek Broadcomu o jego wstrzymanie. Pod koniec sierpnia z publicznego pobierania zniknął VDDK, zestaw bibliotek, z którego korzysta wiele narzędzi do migracji i kopii zapasowych. Broadcom nie wydał w tej sprawie komunikatu, więc znamy ją wyłącznie z relacji użytkowników i serwisów branżowych.
Hock Tan, prezes Broadcomu, powiedział we wrześniu 2025 roku, że ponad 90% z dziesięciu tysięcy największych klientów kupiło VMware Cloud Foundation, i od razu dodał, że nie znaczy to, że wszyscy go wdrożyli. Producent rzadko sam tak wyraźnie oddziela zakup od wdrożenia.
Alternatyw dla VMware jest więcej niż kiedykolwiek: Proxmox VE, Nutanix AHV, Red Hat OpenShift Virtualization, Microsoft Hyper-V i Azure Local, HPE Morpheus VM Essentials, KVM od SUSE. W świecie SAP lista szybko się skraca. SAP HANA w produkcji ma wsparcie na VMware vSphere, na KVM od SUSE i na Nutanix AHV, ale na OpenShift Virtualization już nie. Gartner szacuje, że do 2028 roku około jednej trzeciej obecnych obciążeń VMware będzie działać gdzie indziej, a pełna migracja zajmuje trzy lata albo dłużej, i ostrzega, że kto zmienia platformę wyłącznie dla oszczędności, może się rozczarować.
Nie wiem, kto bardziej finansuje tę różnicę - ci, którzy zostają, czy ci, którzy jeszcze nie zdążyli wyjść. Wiem natomiast, że etapowe ograniczanie VMware oznacza na kilka lat dwie platformy, dwa zespoły i dwa kontrakty. Jeżeli taką ścieżkę wybierzemy, wolę policzyć ją teraz niż przy kolejnym odnowieniu. Najpierw jednak warto uczciwie ustalić, czy byliśmy uzależnieni od VMware, czy od tego, że przez lata nikt nie musiał niczego zmieniać.
## SAP - granica przesuwa się z licencji na dane
Harmonogram jest znany: podstawowe utrzymanie SAP ECC kończy się w 2027 roku, rozszerzone za dopłatą trwa do 2030. Rok 2033, o którym często słyszymy jako o „przedłużeniu ECC”, dotyczy wyłącznie klientów, którzy do końca 2030 roku przeniosą system do SAP ERP, private edition, czyli w praktyce do RISE with SAP. Dla on-premise granicą pozostaje rok 2030.
W lipcu 2023 roku Christian Klein mówił, że nowe innowacje SAP nie będą dostępne dla klientów ERP on-premise ani dla systemów hostowanych u hiperskalerów. W maju 2026 roku SAP częściowo zmienił zdanie: większość asystentów i agentów SAP Joule ma trafić także do ECC i S/4HANA on-premise, ale dla klientów, którzy zobowiązali się do migracji większości krajobrazu. AI na on-premise staje się w ten sposób elementem umowy migracyjnej.
Większa zmiana dotyczy danych. Nota SAP 3255746 od lat ogranicza użycie interfejsu ODP-RFC do wynoszenia danych z systemów SAP do narzędzi innych producentów. W 2026 roku ograniczenie przestało być zapisem w nocie: według Qlik, Matillion i Theobald Software SAP wprowadził techniczną blokadę z możliwością tymczasowego wyłączenia do końca 2026 roku. Hurtownia u innego dostawcy nadal jest możliwa, ale droga do niej prowadzi przez rozwiązania wskazane przez SAP.
Niemieckie stowarzyszenie użytkowników DSAG zapytało w raporcie inwestycyjnym 2026 swoich członków o nową wizję SAP Business Suite. Dla 62% badanych jest ona słabą podstawą planów inwestycyjnych albo w ogóle nią nie jest, a 70% wskazuje licencje i kontrakty SAP jako wyzwanie.
Jeden model danych od finansów po logistykę i jeden dostawca odpowiedzialny za poprawki bezpieczeństwa oraz lokalizacje prawne, takie jak KSeF i JPK, to realna wartość, za którą wiele firm świadomie płaci uzależnieniem. Uważam, że dla wielu firm standaryzacja na SAP była jedną z najtańszych decyzji ostatnich dwudziestu lat.
Najbardziej zajmuje mnie tu własność danych. Jeżeli producent decyduje, którym interfejsem dane wolno wynieść z ERP, to część decyzji o hurtowni albo platformie AI zapada poza firmą. Rok 2033 też ma swoją cenę: odroczenie decyzji kosztuje, więc dobrze, żeby ktoś ten koszt policzył, zanim termin zacznie decydować za nas.
## UiPath - otwarte protokoły, zamknięte centrum
UiPath otwiera dziś platformę na zewnątrz. Maestro orkiestruje agentów zbudowanych w LangChain, u Anthropic czy w Microsoft, platforma obsługuje MCP i A2A, a jesienią 2025 roku firma ogłosiła partnerstwa z OpenAI, NVIDIA, Google, Microsoft i Snowflake. Jednocześnie od maja 2025 roku agentów UiPath rozliczamy w jednostkach Platform Units, a orkiestracja, kolejki, poświadczenia, logi audytowe i cała historia operacyjna procesów zostają w Orchestratorze.
Otwarty protokół nie przenosi zasobów. Procesu zapisanego w XAML z aktywnościami UiPath nie przekonwertujecie do innej platformy - trzeba go przepisać. To samo dotyczy Power Automate, który wiąże automatyzację z Entra ID i Dataverse, oraz Blue Prism z własnym formatem pakietów.
Alternatywa „open source” też wymaga przeczytania licencji. n8n działa na Sustainable Use License, która dopuszcza użycie wyłącznie do wewnętrznych celów biznesowych i nie jest licencją open source w rozumieniu OSI. Licencje OSI mają m.in. Robot Framework, Temporal i LangGraph, ale warstwa operacyjna LangGraph jest już produktem komercyjnym.
W automatyzacji ścieżkę wybieramy w praktyce przy pierwszym wdrożeniu. Gdy przepisanie procesów kosztuje więcej niż kilka lat licencji, zmiana platformy przestaje być realną opcją, niezależnie od liczby obsługiwanych protokołów. MCP otwiera integrację, ale orkiestracja i licencja zużyciowa zostają u producenta.
Szerzej o tym, gdzie kończy się robot, a zaczyna agent, pisałem w tekście [Agent czy przemianowany robot](/pl/aktualnosci/blog/agent-czy-przemianowany-robot/).
## Open source też potrafi zamknąć drzwi
W 2023 roku HashiCorp zmienił licencję Terraform z MPL 2.0 na Business Source License, a społeczność odpowiedziała forkiem OpenTofu. W 2025 roku HashiCorp przeszedł do IBM za 6,4 mld USD. Redis w 2024 roku porzucił licencję BSD, co dało początek Valkey pod Linux Foundation, a w 2025 roku wrócił do licencji open source, dodając AGPLv3. Elastic przeszedł tę samą drogę w obie strony. W sierpniu 2025 roku Broadcom przeniósł większość obrazów Bitnami do archiwum bez aktualizacji, zostawiając pełny katalog w płatnej ofercie. W kwietniu 2026 roku repozytorium MinIO zostało zarchiwizowane z dopiskiem, że nie jest już utrzymywane.
Open source zmienia rodzaj uzależnienia. Mniej zależycie od licencji, bardziej od tego, czy w organizacji jest ktoś, kto utrzyma fork, gdy firma stojąca za projektem zmieni zasady.
Ryzyko rzadziej leży więc w samej licencji, częściej w modelu biznesowym jednej firmy stojącej za projektem i w tym, czy ktoś u Was utrzyma kod bez niej. Powrót Redis i Elastic do licencji OSI pokazuje przede wszystkim, że zasady potrafią zmieniać się w obie strony.
## Chmura - wyjście bez opłat, ale nie bez kosztów
Formalnie wyjście z chmury nigdy nie było tańsze. Od 12 stycznia 2027 roku Data Act zakazuje dostawcom usług przetwarzania danych pobierania opłat za zmianę dostawcy. AWS, Google Cloud i Microsoft Azure od 2024 roku nie pobierają opłat za transfer danych przy wyprowadzce, choć każdy na własnych warunkach - AWS daje od września 2025 roku 90 dni na migrację.
Mimo to Gartner prognozuje, że wydatki na chmurę publiczną wzrosną w 2026 roku o 21,3%. 37signals deklaruje, że wyjście z chmury zaoszczędzi mu ponad 10 mln USD w pięć lat, ale to deklaracja firmy bez niezależnego audytu i dotyczy firmy o wyjątkowo przewidywalnym obciążeniu. Przy wyjściu z chmury więcej niż transfer danych kosztuje zwykle zastąpienie usług zarządzanych, których nie ma poza chmurą danego dostawcy, przebudowa architektury zbudowanej pod te usługi i nowe kompetencje zespołu.
Drugi wątek to suwerenność cyfrowa. W czerwcu 2025 roku przedstawiciel Microsoft France zeznał pod przysięgą przed francuskim Senatem, że nie może zagwarantować, że dane francuskich obywateli nie trafią do władz USA. AWS uruchomił w styczniu 2026 roku European Sovereign Cloud z pierwszym regionem w Brandenburgii. Szlezwik-Holsztyn przeniósł w 2025 roku pocztę całej administracji na Open-Xchange i Thunderbird, a Międzynarodowy Trybunał Karny przechodzi na openDesk.
Dla mnie sprawdzianem jest to, czy środowisko da się odtworzyć poza chmurą z kodu, czy można tylko odzyskać dane. Rachunek 37signals dotyczy obciążeń przewidywalnych, więc zanim zaczniemy mówić o repatriacji, sprawdziłbym, ile takich naprawdę mamy. Nie jestem też przekonany, że suwerenna chmura amerykańskiego dostawcy z europejską spółką rozwiązuje problem z francuskiego Senatu. Raczej przenosi go o jeden szczebel własności wyżej.
Przy modelach AI mechanizm jest ten sam. Według Menlo Ventures, inwestora Anthropic, tylko 11% firm zmieniło w ciągu roku dostawcę modelu, choć zmiana jest technicznie prosta. MCP trafił w grudniu 2025 roku do fundacji pod Linux Foundation, ale prompty, ewaluacje i dane zostają tam, gdzie je zbudowaliście. Własne próby z modelami uruchamianymi lokalnie opisałem przy [porównaniu Mac Studio i DGX Spark](/pl/aktualnosci/blog/mac-studio-512-gb-vs-dgx-spark-maszyna-do-poc/).
## DORA i KSC - plan wyjścia staje się obowiązkiem
DORA od stycznia 2025 roku wymaga od instytucji finansowych testowanej strategii wyjścia dla usług ICT wspierających funkcje krytyczne lub ważne. 18 listopada 2025 roku europejskie urzędy nadzoru wskazały 19 krytycznych zewnętrznych dostawców ICT, w tym AWS, Google Cloud, Microsoft i SAP. Jednym z kryteriów była zastępowalność usług. Mamy więc wymóg testowanego planu wyjścia od dostawców, których regulator sam uznał za trudnych do zastąpienia.
W Polsce nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa obowiązuje od 3 kwietnia 2026 roku, a termin na wniosek o wpis do wykazu podmiotów kluczowych i ważnych minął 3 października. Zarządzanie ryzykiem łańcucha dostaw jest od tego dnia obowiązkiem ustawowym. O tym, jak ten obowiązek wygląda w systemach SAP, pisaliśmy przy [KSC, NIS2 i SecurityBridge](/pl/aktualnosci/blog/ksc-nis2-sap-securitybridge/).
Plan wyjścia, który istnieje wyłącznie jako dokument dla audytora, nie wytrzyma pierwszej realnej zmiany warunków. Do rejestru ryzyk dostawców dopisałbym też pozycję, której w wielu rejestrach brakuje: producent zmienia zasady licencjonowania w trakcie umowy.
## Jaką ścieżkę wybierzemy
Nie uważam, że vendor lock-in jest z natury zły. Każda decyzja architektoniczna jest jakimś uzależnieniem - od producenta, od społeczności, od własnego zespołu albo od jednego inżyniera, który rozumie konfigurację. Problem zaczyna się wtedy, gdy uzależnienie jest przypadkowe, a jego koszt poznajemy dopiero przy odnowieniu umowy.
Zanim zapadnie u nas decyzja o kolejnej platformie, chcę wiedzieć pięć rzeczy. Ile kosztuje wyjście, policzone dziś, a nie w dniu, w którym będzie potrzebne. Kto i w jakim formacie wyniesie dane bez zgody producenta. Co trzeba będzie przepisać, a co da się przenieść. Co się stanie, gdy producent zmieni licencję w połowie umowy, i czy umowa coś na ten temat mówi. I czy mamy ludzi, którzy utrzymają alternatywę, jeśli ją wybierzemy.
A Wy - które uzależnienie w swojej architekturze wybraliście świadomie, a które odkryliście dopiero przy fakturze?
Jeśli taka decyzja czeka Was w najbliższych miesiącach, chętnie przejdę ją z Wami. W SNOK robimy to w ramach [doradztwa i integracji IT](/pl/oferta/doradztwo-i-integracja-it/).
## Źródła
- Broadcom, raport 8-K za III kwartał roku obrotowego 2026, 2.09.2026, dostęp 4.10.2026: https://www.sec.gov/Archives/edgar/data/0001730168/000173016826000076/avgo-08022026x8kxex99.htm
- CloudBolt, badanie o VMware, 17.02.2026, dostęp 4.10.2026: https://www.cloudbolt.io/company/news/new-cloudbolt-research-86-of-companies-actively-reducing-their-vmware-footprint/
- The Register, zmiany licencjonowania VMware (72 rdzenie, kara za spóźnione odnowienie), 28.03.2025, dostęp 4.10.2026: https://www.theregister.com/2025/03/28/arrow_vmware_licensing_change/
- heise, VMware wycofuje minimum 72 rdzeni, 10.04.2025, dostęp 4.10.2026: https://www.heise.de/en/news/VMware-backs-down-companies-can-continue-to-license-16-cores-10347066.html
- The Register, Rijkswaterstaat i wyrok sądu w Hadze, 30.06.2025, dostęp 4.10.2026: https://www.theregister.com/2025/06/30/dutch_agency_wins_right_to/
- The Register, Hock Tan o adopcji VCF, 5.09.2025, dostęp 4.10.2026: https://www.theregister.com/2025/09/05/broadcom_q3_2025/
- Macfarlanes, Sąd Ogólny UE w sprawie żądania informacji wobec Broadcom, 7.09.2026, dostęp 4.10.2026: https://www.macfarlanes.com/insights/102o0cz/broadcom-vmware-eu-general-court-again-weighs-in-favour-of-commissions-broad-in/
- Virtualization Howto, usunięcie VDDK z publicznego pobierania, 7.09.2026, dostęp 4.10.2026: https://virtualizationhowto.com/2026/09/leaving-vmware-just-got-harder-after-broadcom-pulled-vddk-downloads
- The Register, Gartner o migracji z VMware, 11.09.2025, dostęp 4.10.2026: https://www.theregister.com/2025/09/11/gartner_vmware_migration_advice/
- SUSE, scenariusze wirtualizacji SAP HANA, dostęp 4.10.2026: https://documentation.suse.com/sles-sap/sap-virtualization/html/SAP-virtualization-supported-scenarios/index.html
- Red Hat, SAP na OpenShift Virtualization, dostęp 4.10.2026: https://access.redhat.com/articles/7048369
- SAP News, SAP ERP, private edition, transition option, dostęp 4.10.2026: https://news.sap.com/?p=233946
- The Register, SAP Joule dla ECC i S/4HANA on-premise, 13.05.2026, dostęp 4.10.2026: https://www.theregister.com/ai-ml/2026/05/13/sap-u-turn-brings-ai-features-to-ecc-and-on-prem-s/4hana/5239040
- Qlik, ograniczenia dostępu do danych SAP, 27.05.2026, dostęp 4.10.2026: https://community.qlik.com/t5/Support-Updates/Important-update-on-SAP-Data-Access-Restrictions-and-your-Qlik/ba-p/2549652
- DSAG, Investment Report 2026, 26.02.2026, dostęp 4.10.2026: https://impulsant.dsag.de/formate/pressemeldung/dsag-investment-report-2026-companies-are-investing-more-selectively-ai-is-becoming-established-cloud-computing-is-being-put-to-the-test/
- UiPath, informacje o wydaniu - agenci w Unified Pricing, maj 2025, dostęp 4.10.2026: https://docs.uipath.com/agents/automation-cloud/latest/release-notes/may-2025
- UiPath, partnerstwa ogłoszone na FUSION, 1.10.2025, dostęp 4.10.2026: https://www.uipath.com/de/newsroom/nvidia-microsoft-google-openai-snowflake-uipath-schliesst-strategische-partnerschaften-zur-integration-agentischer-automatisierung
- n8n, Sustainable Use License, dostęp 4.10.2026: https://github.com/n8n-io/n8n/blob/master/LICENSE.md
- IBM, finalizacja przejęcia HashiCorp, 27.02.2025, dostęp 4.10.2026: https://newsroom.ibm.com/2025-02-27-ibm-completes-acquisition-of-hashicorp,-creates-comprehensive,-end-to-end-hybrid-cloud-platform
- InfoQ, Redis 8 i licencja AGPL, 05.2025, dostęp 4.10.2026: https://www.infoq.com/news/2025/05/redis-agpl-license
- MinIO, repozytorium na GitHub, dostęp 4.10.2026: https://github.com/minio/minio
- AWS, bezpłatny transfer przy wyprowadzce z AWS, 5.03.2024, aktualizacja 30.09.2025, dostęp 4.10.2026: https://aws.amazon.com/blogs/aws/free-data-transfer-out-to-internet-when-moving-out-of-aws/
- Gartner, prognoza wydatków na chmurę publiczną, dostęp 4.10.2026: https://www.gartner.com/en/documents/6996966
- DHH (37signals), oszczędności z wyjścia z chmury, 10.2024, dostęp 4.10.2026: https://world.hey.com/dhh/our-cloud-exit-savings-will-now-top-ten-million-over-five-years-c7d9b5bd
- SDxCentral, Microsoft przed francuskim Senatem, 06.2025, dostęp 4.10.2026: https://www.sdxcentral.com/news/microsoft-tells-french-lawmakers-it-cant-protect-user-data-from-us-demands/
- Amazon, uruchomienie AWS European Sovereign Cloud, 01.2026, dostęp 4.10.2026: https://press.aboutamazon.com/aws/2026/1/aws-launches-aws-european-sovereign-cloud-and-announces-expansion-across-europe
- Land Szlezwik-Holsztyn, zakończenie migracji poczty, 6.10.2025, dostęp 4.10.2026: https://www.schleswig-holstein.de/DE/landesregierung/ministerien-behoerden/I/_startseite/Artikel2025/IV/251006_ox-umstellung-abschluss
- Menlo Ventures, Mid-Year LLM Market Update, 31.07.2025, dostęp 4.10.2026: https://menlovc.com/perspective/2025-mid-year-llm-market-update/
- Anthropic, przekazanie MCP do Agentic AI Foundation, 9.12.2025, dostęp 4.10.2026: https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
- EBA, wyznaczenie krytycznych dostawców ICT w ramach DORA, 18.11.2025, dostęp 4.10.2026: https://www.eba.europa.eu/publications-and-media/press-releases/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital
- Ministerstwo Cyfryzacji, nowelizacja ustawy o KSC, dostęp 4.10.2026: https://www.gov.pl/web/cyfryzacja/sejm-uchwalil-nowelizacje-ustawy-o-krajowym-systemie-cyberbezpieczenstwa
- Data Act, art. 29 (rozporządzenie (UE) 2023/2854), dostęp 4.10.2026: https://eur-lex.europa.eu/eli/reg/2023/2854/oj
---
### UiPath Studio na komputerach Mac w Public Preview - pierwszy bot zbudowany na macOS
URL: https://snok.ai/pl/aktualnosci/blog/uipath-studio-macos-public-preview/ | Data: 2026-10-03 | Seria: Inne
UiPath Studio działa natywnie na komputerach Mac. Pierwszego października 2026 roku UiPath udostępnił Studio na macOS w Public Preview: na komputerach Mac z procesorami Apple silicon i systemem macOS 14 Sonoma lub nowszym można projektować, uruchamiać i debugować automatyzacje Cross-platform, a potem publikować je do UiPath Orchestrator. Zainstalowaliśmy nową wersję i zbudowaliśmy na niej prostego bota, który pobiera kurs euro z publicznego API Narodowego Banku Polskiego. Cały przebieg trwa czterdzieści sekund i pokazujemy go w filmie poniżej.
UiPath Studio 2026.0.202 STS na macOS - bot z kursem EUR z API NBP w sześciu krokach, nagranie SNOK.
## Co UiPath udostępnił 1 października 2026 roku?
Nowość ma dwie części. Pierwsza to samo Studio na macOS, opisane w nocie wydania jako Public Preview. Druga to UiPath Platform Installer dla macOS, również w Public Preview. Instalator stawia Studio razem z UiPath Assistant, którego Studio potrzebuje do logowania i uruchamiania automatyzacji, i sam aktualizuje oba programy. Pakiet instalacyjny pobieracie z Resource Center w UiPath Automation Cloud.
Dla działów IT ważny jest jeszcze jeden szczegół: administrator ustawia zasady nadzoru profilem konfiguracyjnym rozsyłanym przez system MDM. Studio trafia więc na firmowe komputery Mac tą samą drogą co pozostałe aplikacje, bez ręcznej konfiguracji każdego stanowiska.
Wymagania są krótkie: komputer Mac z procesorem Apple M1 lub nowszym, macOS 14 Sonoma lub nowszy i co najmniej 8 GB wolnego miejsca na dysku. Komputerów Mac z procesorami Intel UiPath nie wspiera. Skróty klawiszowe przeniesiono na klawisz Command: debugowanie to ⌘R, uruchomienie ⌃⌘R, a paleta poleceń otwiera się kombinacją ⇧⌘P.
## Dlaczego Studio na macOS ma znaczenie dla firm?
Komputery Apple od dawna nie są już sprzętem wyłącznie działów kreatywnych. Pracują na nich programiści, analitycy, zarządy i coraz częściej całe zespoły w firmach, które pozwalają pracownikom wybrać komputer. Kierunek potwierdza badanie Censuswide dla MacStadium z września 2025 roku: wśród 300 amerykańskich dyrektorów IT 93 procent odnotowało wzrost użycia urządzeń Apple w ciągu ostatnich dwóch lat, a 96 procent spodziewa się dalszego wzrostu floty komputerów Mac w ciągu 12 do 24 miesięcy. Badanie zamówił dostawca infrastruktury dla komputerów Mac i objęło ono wyłącznie rynek amerykański, więc traktujemy je jako sygnał kierunku, nie jako pomiar polskiego rynku.
W automatyzacji ten trend długo się nie przekładał na narzędzia. Deweloper UiPath pracujący na komputerze Mac miał do wyboru Studio Web w przeglądarce albo Studio Desktop w maszynie wirtualnej z Windows. Pierwsza droga nie dawała pełnego środowiska, druga oznaczała dodatkową licencję systemu, zasoby i jeszcze jedną maszynę do utrzymania.
UiPath dochodził do macOS etapami. W wydaniu 2024.10 weszła w wersji zapoznawczej natywna automatyzacja interfejsu na macOS: automatyzacje attended uruchamiał lokalny robot przez macOS Assistant, ale deweloperzy projektowali je w Studio na Windows. Wydanie 2025.10 dało ogólnodostępną automatyzację aplikacji desktopowych macOS, projektowaną w Studio Web. Brakującym elementem było pełne Studio na macOS i ten element właśnie się pojawił. UiPath nadrabia tu zaległość wobec rynku, na którym komputery Apple są zwykłym sprzętem służbowym.
## Jak zbudowaliśmy pierwszego bota na macOS?
Na nagraniu widać Studio 2026.0.202 STS na MacBooku z Apple silicon. Projekt to zwykły proces w języku C# z kompatybilnością Cross-platform, bo tylko takie projekty Studio na macOS otwiera. Bot ma jedno zadanie: pobrać aktualny średni kurs euro z tabeli A NBP.
Przebieg nie różni się od tego, który deweloperzy UiPath znają z Windows. Tworzymy nowy proces, wybieramy nazwę i język, dodajemy aktywność HTTP Request z pakietu UiPath.WebAPI.Activities, a adres zapytania wklejamy jako polecenie cURL. Funkcja importu sama rozkłada je na adres i parametry. Przycisk Test wykonuje zapytanie jeszcze w trakcie projektowania i pokazuje odpowiedź API w formacie JSON z tabelą A i kodem waluty EUR. Po uruchomieniu panel Output potwierdza start i koniec wykonania procesu.
To celowo prosty przykład. Pokazuje jednak pełną ścieżkę dewelopera na jednym komputerze: projekt, test integracji, uruchomienie i debugowanie, bez maszyny z Windows w tle.
## Co działa na macOS, a co zostaje na Windows?
**Działa na macOS.** Projektowanie, uruchamianie i debugowanie projektów Cross-platform, publikacja do UiPath Orchestrator oraz UI Automation. Przy pierwszym wskazaniu elementu interfejsu macOS poprosi o uprawnienia dla UiPath UIAutomation w ustawieniach Prywatność i ochrona. UI Automation wymaga pakietu UiPath.UIAutomation.Activities w wersji 26.10 lub nowszej, a rozszerzenia przeglądarek są dostępne dla Chrome, Edge i Safari.
**Zostaje na Windows.** Projekty typu Windows i Windows - Legacy nie otworzą się na macOS. W Public Preview nie ma Excel Add-in, pluginu SAP Solution Manager ani narzędzia Repair Tool dla Microsoft Office. Kontrola wersji działa wyłącznie przez Git, bez TFS i SVN. Nie ma też automatycznego generowania wariantów danych testowych, a obsługa czytników ekranu jest ograniczona.
W praktyce oznacza to podział pracy. Nowe automatyzacje Cross-platform, integracje przez API i automatyzacje przeglądarkowe można budować na komputerach Mac już dziś. Procesy oparte na SAP GUI, Excelu w wersji desktopowej albo starszych projektach Windows zostają na stacjach z Windows lub na robotach unattended w maszynach wirtualnych.
## Komu Public Preview przyda się od razu?
UiPath zaznacza wprost, że funkcje w Public Preview nie są zalecane do użycia produkcyjnego. Nie podał też daty wersji ogólnodostępnej. Rozsądny plan na najbliższe miesiące wygląda więc tak: pilotaż w zespole deweloperskim, który już pracuje na komputerach Mac, na nowych projektach Cross-platform, z publikacją do Orchestratora i produkcją uruchamianą na dotychczasowych robotach. Równolegle warto przejrzeć portfel automatyzacji i oznaczyć, które procesy są już Cross-platform, a które wymagają migracji z Windows - Legacy, bo to one zdecydują, ile pracy realnie przeniesie się na komputery Mac.
Studio na macOS dopełnia obraz, o którym pisaliśmy przy okazji [UiPath Delegate w public preview](/pl/aktualnosci/blog/uipath-delegate-public-preview/), agenta działającego na Windows i macOS, oraz przy [otwarciu platformy UiPath na agentów AI, takich jak Claude Code i Codex](/pl/aktualnosci/blog/uipath-coding-agents-claude-codex-enterprise/). Narzędzia deweloperskie UiPath wychodzą poza jeden system operacyjny i jedno środowisko pracy. O tym, jak Mac Studio sprawdza się jako maszyna do eksperymentów z modelami AI, pisaliśmy we wpisie [512 GB pod biurkiem](/pl/aktualnosci/blog/mac-studio-512-gb-vs-dgx-spark-maszyna-do-poc/).
SNOK jest partnerem UiPath Platinum i pracujemy na najnowszych wersjach platformy. Jeżeli planujecie pilotaż Studio na komputerach Mac albo chcecie ocenić, które Wasze procesy można już przenieść do projektów Cross-platform, zajrzyjcie do naszej oferty [automatyzacji procesów biznesowych](/pl/oferta/automatyzacja-ai/business-process-automation/) albo na stronę [UiPath w SNOK](/pl/uipath-snok/) i umówcie się na rozmowę.
## Źródła
- UiPath, Studio Release Notes, October 2026, wpis z 1.10.2026 „Studio on macOS (Preview)” - https://docs.uipath.com/studio/standalone/latest/release-notes/october-2026 (dostęp 03.10.2026).
- UiPath, Studio User Guide, „Studio on macOS (Preview)”: wymagania, typy projektów, skróty i znane ograniczenia - https://docs.uipath.com/studio/standalone/latest/user-guide/studio-on-macos (dostęp 03.10.2026).
- UiPath, Platform Installer Release Notes, October 2026, „macOS support (Preview)” - https://docs.uipath.com/uipath-platform-installer/standalone/latest/release-notes/october-2026 (dostęp 03.10.2026).
- UiPath, Studio User Guide, „About macOS UI Automation”: wersja zapoznawcza od 2024.10 i ogólna dostępność automatyzacji desktopu macOS od 2025.10 - https://docs.uipath.com/studio/standalone/latest/user-guide/about-macos-ui-automation (dostęp 03.10.2026).
- Computerworld, „MacStadium sees Apple adoption accelerating across US enterprises”, 25.09.2025, badanie Censuswide dla MacStadium na 300 dyrektorach IT w USA - https://www.computerworld.com/article/4063294/macstadium-sees-apple-adoption-accelerating-across-us-enterprises.html (dostęp 03.10.2026).
- NBP, API kursów walut, tabela A, kurs EUR - https://api.nbp.pl/api/exchangerates/rates/a/eur/?format=json (dostęp 03.10.2026).
- Nagranie SNOK, UiPath Studio 2026.0.202 STS na macOS, projekt NBP_Kurs_EUR, 03.10.2026.
---
### Przegląd tygodnia W40: egzekwowanie uprawnień agentów AI poza promptem
URL: https://snok.ai/pl/aktualnosci/blog/snok-weekly-digest-w40-uprawnienia-zamiast-instrukcji/ | Data: 2026-10-02 | Seria: Inne
**Przegląd SNOK za okres 25 września - 1 października 2026: SAP, bezpieczeństwo agentów AI, UiPath i modele decyzyjne.**
Kilka premier z ostatniego tygodnia umieszcza egzekwowanie uprawnień i limitów agentów AI poza
instrukcją dla modelu. SAP i NVIDIA rozdzielają autoryzację biznesową od izolacji wykonania,
AG-UI 1.0 wprowadza do protokołu wstrzymanie pracy agenta do czasu decyzji człowieka, a Google AX uruchamia każde
zadanie agenta w osobnej piaskownicy.
Instrukcja w prompcie określa oczekiwane zachowanie modelu, ale nie gwarantuje jego przestrzegania.
Uprawnienia, proces, środowisko wykonania i protokół działają niezależnie od tego, co model przeczyta,
i tam producenci przenoszą dziś egzekwowanie. Podobnie jest
z SAP ERP 6.0: o tym, jak długo system pozostaje wspierany, przesądzają warunki umowy i parametry
techniczne, a nie rok podawany w nagłówkach.
## 1. SAP ERP 6.0: terminy i warunki utrzymania
Główne utrzymanie SAP Business Suite 7, w tym SAP ERP 6.0, kończy się wraz z 2027 rokiem i obejmuje
trzy najnowsze pakiety rozszerzeń. Utrzymanie rozszerzone na lata 2028-2030 SAP wycenia publicznie
na dodatkowe 2 punkty procentowe bazy utrzymania. System, który nie zostanie nim objęty, przechodzi
do utrzymania specyficznego dla klienta.
Na lata 2031-2033 SAP oferuje wyłącznie subskrypcję
„SAP ERP, private edition, transition option”, obejmującą samo SAP ERP bez pozostałych
aplikacji SAP Business Suite 7. Warunkiem jest migracja na SAP HANA
w private edition przed 31 grudnia 2030 roku, system o wielkości co najmniej 2 TB i plan max success.
Według komunikatu SAP z sierpnia 2025 roku umowa podpisana w 2026 roku jest droższa o 20 procent,
a ceny dla umów zawieranych od 2027 roku SAP ogłosi razem z ofertą w 2028 roku.
Tłem jest decyzja Komisji Europejskiej z 9 lipca 2026 roku, która nadała zobowiązaniom SAP moc
wiążącą na 10 lat, w skali globalnej. Obejmują one m.in. doprecyzowanie warunków podziału krajobrazu
systemów między różnych dostawców wsparcia albo bez wsparcia, zniesienie opłat za wznowienie
utrzymania i obniżenie opłat za utrzymanie wsteczne. Streszczamy komunikat bez interpretacji -
skutki dla konkretnej umowy ocenia prawnik.
Rok 2033 jest więc dostępny tylko dla części systemów i za wyraźnie wyższą cenę. Dla każdego systemu
SAP Business Suite 7 trzeba dziś policzyć trzy scenariusze: konwersję do SAP S/4HANA przed końcem
głównego utrzymania, utrzymanie rozszerzone do 2030 roku albo - w przypadku SAP ERP - opcję przejściową
do 2033 roku. Każdy z nich wymaga osoby, która podejmie decyzję i za nią odpowiada, a umowa podpisana jeszcze
w tym roku kosztuje o 20 procent więcej.
*Źródła: SAP Support Portal, „Maintenance strategy for SAP Business Suite 7”; SAP News Center,
Stefan Steinle, „Navigating Your RISE with SAP Journey: Updates for SAP ERP, Private Edition,
Transition Option”, 4.08.2025; Komisja Europejska, komunikat IP/26/1554, 9.07.2026. Status:
potwierdzone - odczyt 1.10.2026. Szczegółowe noty SAP są dostępne po zalogowaniu i ich nie
cytujemy.*
## 2. SAP Joule Studio i NVIDIA OpenShell: rozdział autoryzacji od izolacji wykonania
NVIDIA ogłosiła 28 września Open Agent Safety Platform. Jej podstawą jest OpenShell, otwarte
środowisko uruchomieniowe na licencji Apache 2.0, które wyznacza granice działania agentów
uruchamianych na CPU, niezależnie od modelu i harnessu. NVIDIA określa je jako szeroko dostępne.
Drugi składnik, Sentry, czyli nadzorca działający na DPU BlueField-4 niezależnie od agenta, ma na
razie postać projektu referencyjnego.
SAP pracuje nad połączeniem OpenShell z SAP Joule Studio runtime, częścią SAP Business AI Platform.
Podział ról jest jednoznaczny: runtime SAP stosuje autoryzację biznesową, polityki oparte na rolach
i kontekst procesu, zanim żądanie trafi do wykonania, a OpenShell kontroluje samo wykonanie.
Inżynierowie SAP współtworzą kod OpenShell - rozdzielenie nadzorcy od wykonania agenta, obsługę
Kubernetes i obserwowalność. Już tytuł wpisu SAP mówi o pracach w toku („working toward”), a FedRAMP
i FIPS znajdują się w planie rozwoju. Wśród partnerów infrastrukturalnych NVIDIA wymienia m.in.
Lenovo i SUSE.
Taka architektura daje dwa niezależne punkty kontroli. Pierwszy decyduje, czy akcja agenta zostanie
dopuszczona, drugi określa warunki jej wykonania. Żaden z nich nie zależy od tego, co model przeczyta
w danych wejściowych - i to odróżnia je od ograniczeń zapisanych w instrukcji systemowej.
*Źródła: NVIDIA Newsroom, „NVIDIA Launches Open Agent Safety Platform to Secure Agents From
Testing to Deployment”, 28.09.2026; SAP News Center, Andre Lamego, „SAP and NVIDIA OpenShell
Working Toward Governance and Security for Auditable AI Agents in Enterprise Systems”, 28.09.2026;
repozytorium NVIDIA/OpenShell na GitHub. Status: potwierdzone - odczyt 1.10.2026. Źródła SAP podają
dwa różne terminy bezpłatnego dostępu do SAP Joule Studio runtime, dlatego żadnego nie przytaczamy.*
## 3. Walidacja zgłoszeń przed wywołaniem agenta w UiPath Maestro
Panagiotis Drakopoulos, praktyk UiPath, opisał na LinkedIn proces obsługi zgłoszeń IT zbudowany
w UiPath Maestro BPMN. Co 15 minut proces odczytuje skrzynkę pocztową i zapisuje każdą nową wiadomość
- nadawcę, temat i treść - jako osobny rekord. Rekordy przetwarza pojedynczo, a agenta uruchamia
dopiero wtedy, gdy rekord przejdzie walidację. Autor uzasadnia to kosztem: wywołanie agenta na
bezwartościowych danych to wydatek bez efektu.
Agent klasyfikuje zgłoszenie i nadaje mu priorytet według SLA dostawcy. Proces zakłada sprawę
w Jira Service Management, powiadamia klienta i dostawcę i wraca po kolejny rekord, aż do wyczerpania
kolejki. Od siebie dodajemy jedną uwagę z dokumentacji UiPath: konektor Jira w UiPath Integration
Service obsługuje Jira Software Cloud; wersji Server i Data Center nie obsługuje. Czy obsługuje projekty
Jira Service Management, nie sprawdzaliśmy.
Przykład dobrze pokazuje, gdzie w tym rozwiązaniu leży kontrola. Proces określa,
kiedy agent pracuje i jakie dane otrzymuje, a walidacja przed wywołaniem zmniejsza zarówno koszt,
jak i powierzchnię ataku. Organizacje utrzymujące Jira we własnej infrastrukturze muszą zaplanować
inną drogę integracji, zanim powstanie demonstracja.
*Źródła: Panagiotis Drakopoulos, „The Evolution of ITSM: Moving from Manual to Agentic
Automation!”, LinkedIn, wrzesień 2026; UiPath Docs, „About the Jira connector” (Integration
Service). Status: potwierdzone - to rozwiązanie jednego praktyka, nie architektura referencyjna
UiPath.*
## 4. UiPath Cartographer i modelowanie procesów: model zamiast diagramu
Andrzej Sobczak opisał na LinkedIn przejście od generowania diagramów BPMN z transkrypcji wywiadów
do budowania na ich podstawie modelu procesu. Rozróżnienie jest precyzyjne: diagram jest wizualnym
odwzorowaniem przebiegu, a model ma wbudowaną hierarchię procesów, słownik pojęć, role, dane, reguły,
mierniki i założenia. Uzupełnia go jawna lista luk, czyli tego, czego z wywiadu nie udało się ustalić.
Zestaw narzędzi autora zapisuje te elementy, importuje je do Sparx EA 17.1 i łączy relacjami.
UiPath Cartographer, ogólnie dostępny od UiPath FUSION 2026 (23 września), wykonuje podobną pracę
w ekosystemie UiPath. Z dokumentów, procedur, nagrań i wywiadów tworzy wersjonowaną mapę obecnego
przebiegu procesu wraz ze źródłami, uzgadnia sprzeczne relacje i dopytuje o brakujące informacje.
Następnie projektuje stan docelowy, przypisując każdemu krokowi tryb pracy: w pełni automatyczny,
wspomagany, realizowany przez agenta, z przeglądem człowieka albo ręczny. Na końcu generuje dokument
PDD w formacie Word oraz SDD w Markdown dla zespołów deweloperskich i agentów kodujących. UiPath
podkreśla, że PDD i SDD wynikają z mapy i nie pełnią roli źródła prawdy. Cartographer działa na UiPath
Delegate, a cennika UiPath nie opublikował.
Oba podejścia przesuwają wynik analizy przedwdrożeniowej z rysunku na model z jawnymi lukami. Jawna
lista luk wskazuje, czego zespół musi się dowiedzieć, zanim zaprojektuje proces. Agent, który
ma ten proces zbudować, potrzebuje właśnie takiego modelu: hierarchii, reguł i informacji o tym, czego nie wiadomo.
*Źródła: Andrzej Sobczak, wpis na LinkedIn, wrzesień 2026; UiPath Newsroom, „UiPath Launches
UiPath Cartographer Map of Work”, 23.09.2026; strona produktu UiPath Cartographer; UiPath Docs,
„Cartographer overview”. Status: potwierdzone - odczyt 1.10.2026. Zestawienie obu podejść jest
naszą interpretacją - autor wpisu nie odnosi się do UiPath.*
## 5. Ocena incydentu w Microsoft 365 w trybie tylko do odczytu
M365 Investigation Toolkit to otwarty zestaw skryptów PowerShell 7.5+ na licencji MIT, przeznaczony
do pierwszej oceny kompromitacji Microsoft 365 i Entra ID. Według dokumentacji narzędzie wykonuje
wyłącznie operacje odczytu. Loguje się delegowanym kontem administratora, interaktywnie albo kodem
urządzenia, bez rejestracji aplikacji i bez zapisywania tokenów na dysku.
Narzędzie zbiera dowody z przekierowań i reguł skrzynek, reguł transportu, logowań interaktywnych
i nieinteraktywnych, logowań jednostek usług, zgód OAuth i przypisań ról uprzywilejowanych. Wersja
1.0.0 ma 18 kolektorów dowodów i 10 detekcji, m.in. nadużycia zgód OAuth, wskaźniki BEC, password
spray, przejęcie uśpionego konta i backdoory jednostek usług. Raport podaje poziom pewności i wskazuje
luki w zebranym materiale, a autor zastrzega, że wynik nie przesądza ani o kompromitacji, ani o jej
braku.
Tryb tylko do odczytu skraca pierwsze godziny po incydencie, ale nie oznacza ograniczonego dostępu.
Wśród wymaganych uprawnień jest `Mail.Read`, obejmujące treść poczty, więc użycie narzędzia u klienta
jest decyzją umowną i z zakresu RODO, wymagającą autoryzacji na piśmie. Projekt ma jedno wydanie
z marca 2026 roku, co trzeba uwzględnić, zanim narzędzie trafi do procedury reagowania.
*Źródło: repozytorium `securigeek/M365-Investigation-Toolkit` na GitHub, README, release notes
i plik licencji, odczyt 1.10.2026. Status: potwierdzone co do dokumentacji; narzędzia nie
uruchamialiśmy.*
## 6. Bezpieczeństwo agenta AI w wymaganiach analityka biznesowego
Dorota Roszkowska w czwartej części cyklu #BA4AI przekłada ryzyko prompt injection na wymagania,
które analityk biznesowy może wpisać do specyfikacji. Punktem wyjścia jest spostrzeżenie, że agent
uprawniony do anulowania zamówienia może je anulować także na polecenie atakującego - wydane wprost
w wiadomości albo ukryte w mailu, dokumencie lub stronie, którą agent czyta. Autorka formułuje cztery
pytania.
„Kto sprawdza wywołanie narzędzia, zanim się wykona?” - model jedynie proponuje akcję, a logika
biznesowa weryfikuje uprawnienia i parametry, na przykład limit kwoty zwrotu. „Czyimi uprawnieniami
działa agent?” - uprawnieniami użytkownika, w którego imieniu działa, bez szerokich kont technicznych.
„Które akcje są nieodwracalne?” - anulowanie, płatność i usunięcie danych wymagają potwierdzenia
człowieka, a okno potwierdzenia pokazuje parametry odczytane z systemu, nie opis wygenerowany przez
model. „Jak filtrujemy wejście i wyjście?” - osobną warstwą klasyfikującą przed agentem i po nim oraz
separatorami oddzielającymi instrukcje od danych.
OWASP zalicza prompt injection do najważniejszych ryzyk aplikacji opartych na dużych modelach
językowych (LLM01:2025) i zaznacza, że nie wiadomo, czy istnieje w pełni skuteczna metoda obrony.
Wymagania Roszkowskiej ograniczają więc skutki ataku, nie eliminując jego możliwości - i dlatego pierwsze
z pytań powinno znaleźć się w specyfikacji każdego agenta.
*Źródła: Dorota Roszkowska, „#BA4AI 4/5 Agenci AI: 4 pytania bezpieczeństwa”, LinkedIn,
28.09.2026; OWASP, „LLM01:2025 Prompt Injection”. Status: potwierdzone - odczyt 1.10.2026.*
## 7. Autonomiczny pentest aplikacji z zakresem egzekwowanym w narzędziu
Pentest Swarm AI to otwarte narzędzie do autonomicznych testów penetracyjnych API i aplikacji
webowych, udostępnione na licencji AGPL-3.0. Autorzy przedstawiają je jako otwartą alternatywę dla
XBOW. Narzędzie łączy rozpoznanie z łańcuchami ataków - BOLA i IDOR, fałszowanie tokenów JWT, mass
assignment, SSRF i injection - i potwierdza znaleziska zebranymi dowodami. Działa z Claude, z API
zgodnym z OpenAI, z Gemini albo w pełni lokalnie przez Ollama lub LM Studio.
Ważniejsze od samego roju agentów są dwa rozwiązania. Zakres testu jest egzekwowany w warstwie
narzędzia i powtórnie przez moduł wykonawczy, a rejestr sprzątania uruchamia się przy przerwaniu,
awarii i wyczerpaniu budżetu. Autorzy wprost opisują dojrzałość projektu: domyślny pięciofazowy tryb
sekwencyjny jest stabilny, rój agentów pozostaje w fazie alfa, a łańcuchy eksploitów w fazie beta.
README wymaga pisemnej zgody właściciela systemu przed każdym skanem.
Narzędzia tej klasy są dostępne także atakującym, więc rozpoznanie aplikacji i API przyspieszy.
W narzędziach dopuszczanych do własnych testów zakres i sprzątanie muszą być egzekwowane poza modelem.
Licencja AGPL-3.0 rodzi przy tym obowiązki w razie udostępniania zmodyfikowanej wersji jako usługi -
to pytanie do prawnika.
*Źródło: repozytorium `Armur-Ai/Pentest-Swarm-AI` na GitHub, README, plik licencji i wydania
(v0.2.31 z 29.09.2026), odczyt 1.10.2026. Status: potwierdzone co do dokumentacji; skuteczność to
deklaracja autorów, narzędzia nie testowaliśmy.*
## 8. Aikido Altar-1: model do analizy bezpieczeństwa kodu we własnej infrastrukturze
Aikido Security udostępniło 21 września Altar-1, otwarte wagi modelu do analizy bezpieczeństwa kodu
i pentestów bez wysyłania kodu poza firmę. Altar-1 nie jest modelem trenowanym od podstaw ani
douczanym pod bezpieczeństwo, lecz przyciętym GLM-5.3. Przycinanie ekspertów (REAP) pozostawiło 168
z 256 ekspertów na warstwę, a ich wagi skwantyzowano do INT4. Całość zajmuje 328 GB, liczy 504 mld
parametrów i działa w vLLM na czterech kartach H200.
Aikido podaje wynik na własnym zestawie testowym: 32 znane podatności w 30 repozytoriach, po trzy
przebiegi na przypadek. Średni recall Altar-1 wynosi 60,4 procent wobec 65,6 procent pełnego GLM-5.3.
Licencja GLM-5.3 dopuszcza użycie komercyjne, modyfikację i redystrybucję na swoich warunkach (osobne
wymagania dotyczą największych dostawców modeli udostępnianych jako usługa), ale nie jest licencją
open source zatwierdzoną przez OSI.
Analiza kodu bez opuszczania firmy kosztuje więc kilka punktów trafności i cztery karty klasy Hopper.
Tę cenę trzeba policzyć przed zakupem infrastruktury, a licencję przeczytać przed pierwszym testem.
To nie jest porada prawna.
*Źródła: Aikido Security, wpis „Aikido Altar” na blogu, 21.09.2026; karta modelu `AikidoSec/altar-1`
na Hugging Face; licencja GLM-5.3. Status: potwierdzone - odczyt 1.10.2026. Wynik zestawu testowego
to pomiar producenta.*
## 9. AG-UI 1.0: wstrzymanie pracy agenta do czasu decyzji człowieka
CopilotKit ogłosił 30 września AG-UI 1.0 (Agent-User Interaction Protocol), stabilną wersję
protokołu wymiany zdarzeń między backendem agenta a interfejsem użytkownika. Każde zdarzenie ma schemat
JSON, z którego powstają SDK dla TypeScript, Pythona i .NET. Pakiety 1.0.0 są dostępne od 17 września,
a wersja zachowuje zgodność wsteczną.
Najważniejsza zmiana to wstrzymanie pracy agenta do czasu decyzji człowieka i wznowienie jej dokładnie
w miejscu zatrzymania.
Dochodzą subagenci jako osobne obiekty strumienia, dzięki czemu wiadomo, który agent wykonuje którą
część pracy, a także multimodalne wejście i wyniki narzędzi oraz raportowanie zużycia tokenów w zdarzeniu
końcowym. README wymienia wśród wspieranych integracji m.in. LangGraph, CrewAI, Microsoft Agent
Framework, Google ADK i Mastra. CopilotKit opisuje podział warstw tak: MCP łączy agenta z narzędziami,
A2A z innymi agentami, a AG-UI z aplikacją użytkownika.
Moment decyzji człowieka staje się w ten sposób standardowym zdarzeniem, które aplikacja może zapisać.
Samą logikę kontroli i ślad audytowy aplikacja nadal buduje sama; protokół ujednolica wyłącznie sposób
sygnalizacji. Zapowiedź przyjęcia protokołu przez Google, Microsoft,
Amazon i Oracle traktujemy jako deklarację CopilotKit; potwierdzone są istniejące integracje.
*Źródła: CopilotKit, „Introducing AG-UI 1.0: a stable spec for connecting any agent to any
application”, 30.09.2026; changelog specyfikacji AG-UI 1.0; repozytorium `ag-ui-protocol/ag-ui`
na GitHub (licencja MIT). Status: potwierdzone - odczyt 1.10.2026.*
## 10. Otwarte modele decyzyjne, w tym model dla języka polskiego
W niecałe dwa tygodnie po premierze Jev (15 września) pojawiło się pięć otwartych modeli działających
według tego samego kontraktu: wybierają spośród zadanych odpowiedzi i podają prawdopodobieństwo każdej
z nich w jednym przebiegu, bez generowania tekstu. basal-1.0 Remka Kinasa, na licencji Apache 2.0,
został douczony na polskim modelu Bielik v3.0 w wariantach 4,5 mld i 1,5 mld parametrów i jest
przeznaczony dla polszczyzny. Jego serwer udostępnia ten sam interfejs co Jev, więc aplikacja zmienia
tylko adres usługi.
Intern-Decision z InternLM przyjmuje obrazy, a do jego wag stosują się warunki licencji Qwen. CLM-8B
dodaje niewielkie głowice do zamrożonego Qwen3-8B. GLiNER2.5-Decide od Fastino i Julia 1 od Supersonic
Labs to małe modele działające na zwykłym procesorze. Liquid AI d1 realizuje ten sam kontrakt, ale
wyłącznie jako usługa w chmurze, bez otwartych wag.
Decyzja w ustalonym formacie staje się warstwą, którą można uruchomić lokalnie, także na polskich
danych. Wyniki zależą jednak od języka. Autor basal-1.0 podaje 0,884 na polskich decyzjach
wobec 0,780 Jev, ale na publicznym zestawie angielskim 0,740 wobec 0,861 Jev. Autorzy Julia 1 podają
na zbiorze Banking77 64 procent wobec 87 procent Jev. Wszystkie te wyniki pochodzą od autorów -
nie weryfikowaliśmy ich niezależnie.
*Źródła: repozytorium `rkinas/basal` i karty `Remek/basal-1.0-4.5B` oraz `-1.5B` na Hugging Face;
repozytorium `InternLM/Intern-Decision`; repozytorium `Contrastive-LM/CLM` i karta `CLM-v0.1-8B`;
karty `fastino/GLiNER2.5-Decide` i `SupersonicLabs/Julia-1`; dokumentacja Liquid AI. Status:
potwierdzone co do istnienia, licencji i rozmiarów - odczyt 1.10.2026; wyniki niezweryfikowane.*
## 11. Google AX: izolowane środowisko dla każdego zadania agenta
Google opublikował na GitHubie AX, otwarty i deklaratywny orkiestrator zadań agentowych na licencji
Apache 2.0, działający na warstwie Agent Substrate. Zadanie (`Task`) uruchamia niezaufany kod agenta
w osobnej piaskownicy z limitami procesora i pamięci. Przestrzeń robocza (`Workspace`) dostarcza mu
repozytoria, serwery MCP i skille, tak by agent startował z gotowym kontekstem. Zadanie można wstrzymać
i wznowić dokładnie w miejscu przerwania, a składnia poleceń przypomina `kubectl`.
Autorzy otwierają dokumentację ostrzeżeniem: AX jest intensywnie rozwijany i przed wersją stabilną
wprowadzi zmiany niezgodne wstecz. API ma status `v1alpha1`, a ostatnie wydanie to v0.3.1 z 25 września.
Skala „miliardów zadań w klastrze” jest zapowiedzią autorów, nie pomiarem.
Agent jest nowym rodzajem obciążenia: gromadzi stan, wywołuje zewnętrzne usługi i w pętli potrafi
wyczerpać budżet, zanim ktokolwiek to zauważy. Izolację i limity musi zapewnić platforma, bo prompt
ich nie wymusi. AX traktujemy jako punkt odniesienia w rozmowie o środowisku wykonawczym dla agentów;
do produkcji go nie rekomendujemy.
*Źródło: repozytorium `google/ax` na GitHub, README i wydania, odczyt 1.10.2026. Status:
potwierdzone; projekt eksperymentalny, nie usługa Google Cloud.*
## 12. Apple i serwery AI: doniesienie prasowe
The Information, cytowany przez Bloomberga 16 września, donosi, że Apple pracuje nad serwerem dla
przedsiębiorstw opartym na własnych układach - z myślą o twórcach AI, administracji i firmach. Mają
powstać dwie wersje: z dwoma i z czterema przyszłymi chipami M8 Ultra. Apple miało rozmawiać z NVIDIA
o łączeniu układów przez NVLink Fusion.
Serwer trafiłby na rynek najwcześniej w 2029 roku, a projekt może zostać przerwany albo kontynuowany
bez technologii NVIDIA. Tłem jest nieoczekiwany popyt twórców AI na Mac mini i Mac Studio. Apple nie
skomentowało doniesień, a cen nie podano.
Doniesienie wskazuje, że Apple rozważa serwer przeznaczony do lokalnego uruchamiania modeli AI.
Produktu i ceny nie ma, więc decyzji zakupowych na lata 2026-2027 to nie zmienia.
*Źródło: Bloomberg, „Apple Is Developing Enterprise Server for AI Age, Report Says”, 16.09.2026,
na podstawie The Information. Status: zapisane - doniesienie prasowe oparte na anonimowych źródłach;
artykuł The Information jest płatny i go nie otwieraliśmy.*
## 13. Książka „Cyberbezpieczeństwo SAP od A do Z”
29 września SNOK Press wydało „Cyberbezpieczeństwo SAP od A do Z”, książkę dla CIO, CISO, kierowników
projektów SAP, administratorów SAP Basis i zespołów SOC. Ma 304 strony, 24 rozdziały w pięciu częściach
i aneksy A-D. Autorami są Jacek Bugajski, Zespół SNOK RedTeam oraz duże modele językowe.
Książka omawia ścieżki ataku na systemy SAP, uprawnienia, agentów AI zarówno jako zagrożenie, jak
i wsparcie obrony, laboratorium red team, detekcję i reagowanie oraz NIS2. Każdy rozdział zawiera
ramkę „Dla decydenta”, a obok niej ramki „Praktyka kontroli”, „Na co uważać” i „Pytanie do CIO”.
Równolegle ukazało się wydanie angielskie, „SAP Cybersecurity from A to Z”.
Ramki „Dla decydenta” dają zarządowi wejście w każdy rozdział, nie odbierając tekstowi szczegółów
technicznych. Obie wersje językowe można pobrać na snok.ai [po podaniu adresu służbowego](/pl/materialy/cyberbezpieczenstwo-sap-od-a-do-z/).
*Źródło: SNOK Press, wydanie z 29.09.2026; strona materiału i wpis premierowy na snok.ai. Status:
potwierdzone - odczyt 1.10.2026.*
## Kontrola ograniczeń agenta przed wdrożeniem
Przegląd agenta przed wdrożeniem zaczynamy od wskazania ograniczeń, które istnieją wyłącznie jako
zdanie w prompcie. Takie ograniczenie nie daje gwarancji egzekwowania, bo spreparowana treść może
skłonić model do jego naruszenia. Ograniczenia zapisane w uprawnieniach, w procesie, w środowisku wykonania i w protokole
działają niezależnie od tego, co model przeczyta.
W SNOK prowadzimy [oceny bezpieczeństwa agentów AI](/pl/oferta/automatyzacja-ai/ai-security/),
[wdrożenia UiPath Maestro](/pl/oferta/automatyzacja-ai/uipath-maestro/), [wdrożenia modeli językowych we własnej infrastrukturze klienta](/pl/oferta/automatyzacja-ai/llm-on-premise/)
oraz [konwersje do SAP S/4HANA z kontrolą bezpieczeństwa](/pl/oferta/bezpieczenstwo-sap/konwersja-s4hana/).
Chętnie omówimy [Wasz przypadek](/pl/kontakt/).
---
### Technologiczny Czwartek ze SNOK: SAP w energetyce, Snowflake i agenci UiPath - jak zbudować dane pod AI z nadzorem
URL: https://snok.ai/pl/aktualnosci/blog/sap-energetyka-snowflake-agenci-uipath-snok-mdm/ | Data: 2026-10-01 | Seria: Technologiczny Czwartek
Spółka energetyczna rzadko ma jeden system. SAP ERP prowadzi finanse, kontroling, gospodarkę remontową i logistykę. Rozliczenia klientów obsługuje SAP IS-U albo inny system billingowy. Obok działają system danych pomiarowych, GIS, SCADA, CRM, portal klienta i interfejsy wymiany danych rynkowych. W każdym z tych systemów może istnieć osobny rekord tego samego klienta, punktu poboru i dostawcy.
Do tego krajobrazu dochodzi presja na AI. Zarządy pytają o asystentów dla obsługi klienta, o automatyczne wyjaśnianie rachunków i o agentów, którzy przejmą obsługę wyjątków. Naszym zdaniem pierwsze pytanie brzmi jednak inaczej: skąd agent weźmie dane, komu je pokaże i kto odpowiada za jego decyzję. W tym wpisie opisujemy architekturę, która na to odpowiada: SAP on-premise jako źródło, Snowflake jako nadzorowana platforma danych i wiedzy, SNOK MDM jako warstwa danych podstawowych oraz UiPath jako warstwa sterująca pracą agentów.
*Dane płyną z SAP i systemów rozliczeniowych do Snowflake, SNOK MDM porządkuje dane podstawowe, a agent w UiPath Maestro zmienia dane w SAP dopiero po akceptacji pracownika.*
## Dlaczego teraz - CSIRE, liczniki i terminy SAP
Trzy procesy nakładają się w tym samym czasie.
**Centralny System Informacji Rynku Energii.** CSIRE działa od 1 lipca 2025 roku, a uczestnicy rynku dołączają do niego etapami. Ostatni termin wyznacza harmonogram operatora informacji rynku energii na 19 października 2026 roku. U uczestników przyłączonych do CSIRE zmiana sprzedawcy, dane pomiarowe i dane do rozliczeń przechodzą przez standaryzowaną wymianę z jednym systemem centralnym. Każda niespójność w danych o punkcie poboru wychodzi więc poza organizację szybciej niż dotąd.
**Liczniki zdalnego odczytu.** Według URE na koniec 2024 roku liczniki zdalnego odczytu działały w 38,26 procent z ponad 19 milionów punktów poboru. Prawo energetyczne wymaga co najmniej 80 procent do końca 2028 roku. Rośnie liczba danych pomiarowych, a razem z nią liczba wyjątków do obsłużenia przed rozliczeniem.
**Terminy SAP.** Podstawowe utrzymanie głównych aplikacji SAP Business Suite 7 kończy się z końcem 2027 roku, a opcjonalne utrzymanie rozszerzone jest dostępne do 2030 roku. Termin dla konkretnego rozwiązania branżowego, w tym SAP IS-U, warto potwierdzić w SAP. Decyzja o przejściu na SAP S/4HANA Utilities albo o pozostaniu przy dotychczasowym billingu zapada więc w tym samym oknie, w którym powstają pierwsze projekty AI.
Wniosek dla architektury: warstwa danych pod AI powinna działać niezależnie od tego, który system rozliczeniowy zostanie w krajobrazie za trzy lata.
## Dwa znaczenia skrótu MDM w energetyce
W energetyce skrót MDM oznacza zwykle Meter Data Management, czyli system danych pomiarowych. W tym wpisie piszemy o Master Data Management, czyli o zarządzaniu danymi podstawowymi: kto jest klientem, który rekord dostawcy jest właściwy, jak nazywa się materiał w magazynie i w katalogu zakupowym.
To rozróżnienie ma znaczenie praktyczne. System danych pomiarowych odpowiada na pytanie, ile energii przepłynęło przez licznik. Nie rozstrzyga, czy klient w billingu, w CRM i w SAP to ta sama osoba albo firma. Tę lukę zamyka warstwa danych podstawowych. Bez niej każdy agent AI pracuje na trzech wersjach tego samego klienta.
## Droga danych z SAP on-premise do Snowflake
To najczęściej niedoceniany element projektu. Wybór metody pobierania danych z SAP jest decyzją licencyjną, nie tylko techniczną.
**SAP Business Data Cloud i integracja bez kopiowania danych.** SAP i Snowflake ogłosiły partnerstwo 4 listopada 2025 roku. Od 4 maja 2026 roku Snowflake udostępnia produkcyjnie integrację z SAP Business Data Cloud: produkty danych SAP są widoczne w Snowflake bez kopiowania, razem z opisem semantycznym, a dane ze Snowflake mogą wracać do SAP Business Data Cloud. Oferta występuje w dwóch wariantach: SAP Snowflake, kupowany i wspierany przez SAP, oraz SAP BDC Connect for Snowflake dla istniejących kont Snowflake. Ważne zastrzeżenie: obejmuje to dane dostępne jako produkty danych w SAP Business Data Cloud. Dane z SAP ECC albo SAP IS-U działających on-premise trzeba najpierw tam doprowadzić.
**Przepływy replikacji SAP Datasphere nie obsługują Snowflake jako celu.** W dokumentacji przepływów replikacji SAP Datasphere Snowflake występuje wyłącznie jako źródło. Architektura, która zakłada replikację z SAP Datasphere do Snowflake tym mechanizmem, wymaga więc innego rozwiązania.
**Nota SAP 3255746.** SAP doprecyzował w niej, że interfejs ODP-RFC służy do wymiany danych między aplikacjami SAP. Dostawcy narzędzi integracyjnych opisują to jako zakaz używania tego interfejsu przez rozwiązania firm trzecich. Doprecyzowanie nie dotyczy innych metod, takich jak replikacja zmian na poziomie bazy danych, OData czy wywołania RFC poza ODP-RFC, ale o ich dopuszczalności rozstrzyga Wasza umowa licencyjna z SAP. Zanim wybierzecie narzędzie do ekstrakcji, sprawdźcie, z jakiej metody korzysta, i potwierdźcie ją w ramach umowy.
W praktyce rekomendujemy krótki przegląd ścieżek ekstrakcji przed pierwszą linijką kodu: które dane mogą iść przez SAP Business Data Cloud, które przez replikację zmian, a które wystarczy odświeżać raz na dobę. Ten przegląd łączy kompetencje SAP Basis, bezpieczeństwa SAP i inżynierii danych, dlatego prowadzimy go jako jeden krok projektu.
*Wybór ścieżki ekstrakcji z SAP jest decyzją licencyjną, zanim stanie się techniczną.*
## Snowflake jako nadzorowana baza danych i wiedzy pod AI
Snowflake pełni w tej architekturze dwie role: hurtowni danych i bazy wiedzy dla modeli językowych. Obie wymagają porządku, zanim pojawi się pierwszy agent.
**Liczby przez warstwę semantyczną, dokumenty przez wyszukiwanie.** Wyszukiwanie wektorowe, na którym opiera się RAG, dobrze sprawdza się przy dokumentach: taryfie, instrukcji ruchu i eksploatacji sieci dystrybucyjnej, regulaminie, procedurze reklamacyjnej czy umowie. Przy pytaniach o salda, zużycie i należności nie sprawdza się, bo takie pytania wymagają agregacji i złączeń tabel, a nie podobieństwa tekstu. Dlatego rozdzielamy te dwa światy. Dokumenty indeksuje Cortex Search, czyli hybrydowe wyszukiwanie wektorowe i leksykalne w Snowflake. Dane liczbowe udostępniamy przez semantic views: metryki, takie jak należność przeterminowana albo zużycie w okresie rozliczeniowym, definiujemy w nich raz i liczymy deterministycznie. Cortex Agents łączą oba źródła w jednej odpowiedzi.
**Uprawnienia egzekwowane w jednym miejscu.** Snowflake Horizon daje klasyfikację danych osobowych i poufnych, tagi, dynamiczne maskowanie, polityki dostępu do wierszy i lineage. Maskowanie i polityki wierszy są dostępne od edycji Enterprise. Zasada, którą projektujemy: agent widzi dokładnie to, co widziałby użytkownik, w którego imieniu działa. Uprawnienia egzekwuje platforma danych, a nie prompt. Wymaga to połączenia w kontekście użytkownika, które trzeba zaprojektować i przetestować dla wybranej metody uwierzytelnienia, bo konektory dopuszczają także poświadczenia aplikacji.
**Region i wnioskowanie modeli.** Snowflake nie ma regionu w Polsce. Najbliższe regiony to między innymi AWS we Frankfurcie i Sztokholmie oraz Azure w Holandii i Szwecji. Modele wiodące w Cortex wymagają wnioskowania między regionami, a dla organizacji utworzonych od 9 marca 2026 roku domyślne ustawienie pozwala kierować zapytania do dowolnego regionu. Dla spółki energetycznej rekomendujemy świadome ograniczenie wnioskowania do regionów w Unii Europejskiej i zapisanie tej decyzji w dokumentacji bezpieczeństwa.
**Ochrona przed wstrzyknięciem poleceń.** Od maja 2026 roku Cortex AI Guardrails, po włączeniu przez administratora, chronią agentów Cortex przed prompt injection, także pośrednim, ukrytym w wynikach narzędzi. To ważne, bo korespondencja klientów i dokumenty zewnętrzne są naturalnym nośnikiem takiego ataku.
Więcej o tym, jak projektujemy platformę danych, piszemy na stronie [SNOK i Snowflake](/pl/snowflake-snok/) oraz w ofercie [Modern Data Stack](/pl/oferta/custom-development/modern-data-stack/).
## SNOK MDM - jedna wersja klienta, dostawcy i materiału przed agentem
Snowflake jest platformą danych, a nie systemem zarządzania danymi podstawowymi. Nie rozstrzyga, który z trzech rekordów tego samego odbiorcy jest właściwy, i nie prowadzi procesu, w którym właściciel danych zatwierdza scalenie. Na Snowflake złoty rekord wymaga dodatkowych produktów albo własnej budowy.
Tę warstwę dostarcza SNOK MDM, nasze własne rozwiązanie do zarządzania danymi podstawowymi. Działa ponad systemami źródłowymi, bez wymiany ERP ani billingu:
- **Dopasowanie i deduplikacja** rozpoznają tę samą encję w wielu rekordach, na przykład odbiorcę zapisanego inaczej w billingu, w CRM i w SAP.
- **Silnik językowy proponuje scalenia**, a decyzję zatwierdza data steward. Każda decyzja trafia do śladu audytowego.
- **Sześć domen w jednej platformie**: klienci, dostawcy, materiały, produkty, konta finansowe i pracownicy, a w wersji branżowej dla energetyki, gazownictwa i sektora paliwowego także punkty poboru i ich powiązania z klientami.
- **Konektory SAP S/4HANA i SAP ECC** oraz wdrożenie on-premise, w środowisku klienta albo jako usługa.
W energetyce najwięcej zyskują trzy domeny. Domena klientów, razem z punktami poboru z wersji branżowej, porządkuje obsługę po pełnym wejściu CSIRE. Domena dostawców może wspierać ocenę ryzyka w łańcuchu dostaw, jeśli spółka podlega takim obowiązkom z ustawy o krajowym systemie cyberbezpieczeństwa. Domena materiałów łączy części zamienne w gospodarce remontowej SAP z katalogiem zakupowym. Złoty rekord SNOK MDM publikujemy do Snowflake jako produkt danych, więc agenci i raporty korzystają z tej samej, zatwierdzonej wersji.
O tym, kiedy wybrać SAP Master Data Governance, a kiedy SNOK MDM, pisaliśmy we wpisie [SAP MDG, Reltio czy SNOK MDM](/pl/aktualnosci/blog/sap-mdg-czy-reltio-snok-mdm/). Szczegóły produktu znajdziecie na stronie [SNOK MDM](/pl/produkty/snok-mdm/).
## UiPath jako warstwa sterująca pracą agentów
Agent, który sam wybiera narzędzia, sam decyduje i sam wykonuje transakcję w SAP, to w regulowanej spółce ryzyko, którego nikt nie podpisze. Dlatego potrzebny jest harness, czyli warstwa, która wyznacza agentowi proces, narzędzia, uprawnienia i miejsca, w których decyzję zatwierdza upoważniony pracownik. W tej architekturze tę funkcję pełni UiPath.
**UiPath Maestro orkiestruje proces.** UiPath i Snowflake ogłosiły partnerstwo 30 września 2025 roku. Konektor Snowflake Cortex w UiPath Integration Service pozwala procesowi w UiPath Maestro wywołać agenta Cortex, który odpowiada na podstawie semantic views i Cortex Search, a następnie przekazać wynik dalej: do robota, który wykonuje transakcję w SAP, albo do człowieka w Action Center. Alternatywą jest zarządzany serwer MCP Snowflake, zarejestrowany w UiPath Orchestrator jako zdalne źródło narzędzi dla agentów konwersacyjnych.
**UiPath AI Trust Layer pilnuje reguł.** Po skonfigurowaniu polityk maskuje dane osobowe przed wysłaniem do modelu i przywraca je po odpowiedzi, egzekwuje polityki dla agentów przed wdrożeniem i zapisuje wywołania modeli w dzienniku audytowym. Dla energetyki, która przetwarza dane milionów odbiorców, to warunek wejścia na produkcję.
**Człowiek zatwierdza tam, gdzie decyzja ma skutki.** Korekta rozliczenia, zmiana danych punktu poboru czy odpowiedź na reklamację przechodzą przez punkt akceptacji w Action Center. Agent przygotowuje uzasadnienie, a upoważniony pracownik je zatwierdza. Wzorzec opisywaliśmy szerzej we wpisie o [punktach akceptacji w UiPath Maestro](/pl/aktualnosci/blog/hitl-gate-uipath-maestro-ai-trust-layer/).
Przykładowe procesy, od których warto zacząć:
1. **Wyjaśnienie wysokiego rachunku.** Agent zestawia zużycie, odczyty i taryfę, przygotowuje projekt odpowiedzi, a pracownik obsługi klienta ją zatwierdza. UiPath publikuje ten wzorzec jako referencyjny przypadek użycia agentów.
2. **Wyjątki odczytowe przed rozliczeniem.** Brak odczytu, odczyt szacunkowy albo nietypowy skok zużycia trafiają do agenta, który proponuje korektę albo zlecenie weryfikacji licznika.
3. **Odrzucone komunikaty wymiany danych rynkowych.** Agent klasyfikuje przyczynę odrzucenia, sprawdza dane punktu poboru w złotym rekordzie i przygotowuje poprawkę do akceptacji.
Automatyzację procesów prowadzimy jako [UiPath Platinum Partner](/pl/uipath-snok/), a orkiestrację agentów opisujemy w ofercie [UiPath Maestro](/pl/oferta/automatyzacja-ai/uipath-maestro/).
## Governance pod AI - pięć warstw kontroli
Governance to zestaw mechanizmów działających w każdej warstwie architektury, a nie dokument dołączany na końcu projektu.
1. **Tożsamość.** Agent działa w imieniu konkretnego użytkownika, a tożsamość tego użytkownika dociera do platformy danych. Metodę uwierzytelnienia wybieramy i testujemy pod tym kątem. Konto techniczne z pełnym dostępem nie jest dopuszczalne.
2. **Dane.** Maskowanie, polityki wierszy i klasyfikacja w Snowflake Horizon oraz zatwierdzony złoty rekord w SNOK MDM.
3. **Semantyka.** Metryki zdefiniowane raz w semantic views, więc agent nie liczy należności po swojemu.
4. **Agent.** Polityki projektowe, ewaluacje przed wdrożeniem i rejestr agentów z uprawnieniami w UiPath.
5. **Człowiek i ślad.** Punkty akceptacji dla decyzji ze skutkami oraz dziennik audytowy obejmujący wywołania modeli, decyzje data stewarda i transakcje robotów.
Te warstwy wspierają też zgodność regulacyjną. Ustawa o krajowym systemie cyberbezpieczeństwa wdrażająca NIS2 obowiązuje od 3 kwietnia 2026 roku i obejmuje sektor energii. Obowiązki dla systemów AI wysokiego ryzyka z załącznika III AI Act mają obowiązywać od 2 grudnia 2027 roku, po zmianach wprowadzonych pakietem Digital Omnibus. W energetyce dotyczy to przede wszystkim systemów AI używanych jako elementy bezpieczeństwa w zarządzaniu i eksploatacji infrastruktury krytycznej, w tym dostaw energii, a nie każdego agenta w obsłudze klienta. Kwalifikacja konkretnego zastosowania wymaga analizy prawnej, ale architektura z pięcioma warstwami kontroli ułatwia przygotowanie dokumentacji. Bezpieczeństwo samych agentów, w tym testy na prompt injection i wyciek danych przez narzędzia, obejmuje nasza oferta [AI Security](/pl/oferta/automatyzacja-ai/ai-security/).
## Od czego zacząć - trzy kroki
**Krok 1. Przegląd danych i ścieżek ekstrakcji.** Mapa systemów, domen danych podstawowych i metod pobierania danych z SAP, z oceną zgodności z licencją. Wynik: lista danych, które mogą trafić do Snowflake, i sposób, w jaki je tam doprowadzić.
**Krok 2. Pilot jednej domeny i jednego agenta.** Na przykład złoty rekord klienta w SNOK MDM, dane rozliczeniowe w Snowflake i agent wyjaśniający rachunki w UiPath Maestro, z punktem akceptacji dla pracownika. Pierwszy wynik na Waszych danych zamiast prezentacji na danych przykładowych.
**Krok 3. Skalowanie.** Kolejne domeny, kolejne procesy i przeniesienie governance do stałego utrzymania.
## Dlaczego SNOK
Projekt tego typu łączy kompetencje, które w wielu organizacjach są rozdzielone między różnych dostawców: SAP Basis i bezpieczeństwo SAP, inżynierię danych na Snowflake, zarządzanie danymi podstawowymi oraz automatyzację i agentów UiPath. SNOK jest partnerem SAP, Snowflake Partner i UiPath Platinum Partner, a SNOK MDM jest naszym własnym rozwiązaniem. Dzięki temu jeden zespół może poprowadzić całą ścieżkę: od danych w SAP, przez złoty rekord i platformę danych, po agenta z punktem akceptacji.
Jeśli planujecie projekt AI w spółce energetycznej, zacznijmy od przeglądu danych i ścieżek ekstrakcji. [Porozmawiajmy o architekturze dla Waszego krajobrazu SAP](/pl/oferta/master-data-management/).
## Źródła
- PSE, Operator Informacji Rynku Energii - start CSIRE i harmonogram wdrażania (dostęp 30.09.2026): https://www.pse.pl/oire/harmonogram-wdrazania-nmwi-poprzez-csire
- URE - raport o umowach z ceną dynamiczną, dane o licznikach zdalnego odczytu na koniec 2024 r. (dostęp 30.09.2026): https://www.ure.gov.pl/download/9/15476/Raportcenydynamiczne.pdf
- Ustawa z 20 maja 2021 r. o zmianie ustawy Prawo energetyczne, art. 11t (dostęp 30.09.2026): https://orka.sejm.gov.pl/proc9.nsf/ustawy/808_u.htm
- SAP - strategia utrzymania SAP S/4HANA i SAP Business Suite 7 (dostęp 30.09.2026): https://support.sap.com/en/release-upgrade-maintenance/maintenance-information/maintenance-strategy/s4hana-business-suite7.html
- SAP News - SAP i Snowflake, 4.11.2025 (dostęp 30.09.2026): https://news.sap.com/2025/11/sap-snowflake-data-enterprise-ai-business-data-fabric/
- Snowflake - SAP BDC Zerocopy Connector, general availability, 4.05.2026 (dostęp 30.09.2026): https://docs.snowflake.com/en/release-notes/2026/other/2026-05-04-Snowflake-SAP-zerocopy-integration
- SAP Datasphere - źródła i cele przepływów replikacji (dostęp 30.09.2026): https://github.com/SAP-docs/sap-datasphere
- SAP - API Policy, Frequently Asked Questions, wersja 1.3, 06.2026, pyt. 22-23 (dostęp 30.09.2026): https://www.sap.com/docs/download/2026/04/e2a0665e-4c7f-0010-bca6-c68f7e60039b.pdf
- Theobald Software - SAP Note 3255746, 23.04.2026 (dostęp 30.09.2026): https://theobald-software.com/en/blog/sap-note-3255746
- Snowflake - regiony (dostęp 30.09.2026): https://docs.snowflake.com/en/user-guide/intro-regions
- Snowflake - wnioskowanie między regionami w Cortex (dostęp 30.09.2026): https://docs.snowflake.com/en/user-guide/snowflake-cortex/cross-region-inference
- Snowflake - Cortex Search (dostęp 30.09.2026): https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-search/cortex-search-overview
- Snowflake - Cortex AI Guardrails, 14.05.2026 (dostęp 30.09.2026): https://docs.snowflake.com/en/release-notes/2026/other/2026-05-14-cortex-ai-guardrails-si-cortex-agents
- UiPath - partnerstwo ze Snowflake, 30.09.2025 (dostęp 30.09.2026): https://www.uipath.com/newsroom/uipath-partners-with-snowflake-to-unite-agentic-automation-and-snowflake-cortex-ai
- UiPath - konektor Snowflake Cortex (dostęp 30.09.2026): https://docs.uipath.com/integration-service/automation-cloud/latest/user-guide/uipath-snowflake-cortex
- UiPath - maskowanie danych osobowych w AI Trust Layer (dostęp 30.09.2026): https://docs.uipath.com/automation-cloud/automation-cloud/latest/admin-guide/pii-masking
- UiPath - High Bill Analysis Agent (dostęp 30.09.2026): https://www.uipath.com/resources/agentic-use-cases/high-bill-analysis-agent
- Ustawa o krajowym systemie cyberbezpieczeństwa, Dz.U. 2026 poz. 252 (dostęp 30.09.2026): https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20260000252
- Rozporządzenie (UE) 2026/1744 (Digital Omnibus) (dostęp 30.09.2026): https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng
---
### Cyberbezpieczeństwo SAP od A do Z - książka gotowa do pobrania
URL: https://snok.ai/pl/aktualnosci/blog/ksiazka-cyberbezpieczenstwo-sap-od-a-do-z/ | Data: 2026-09-29 | Seria: Bezpieczny Wtorek
Jestem niezmiernie dumny, że mogę oddać w Wasze ręce książkę **„Cyberbezpieczeństwo SAP od A do Z. Przewodnik dla CIO, CISO i zespołów SAP”**. Z tego, co wiem, w świecie SAP czegoś takiego po polsku jeszcze nie było: 304 strony, które prowadzą od fundamentów, przez uprawnienia, ścieżki ataku i agentów AI, po KSC, NIS2 i gotowe wzory dokumentów do audytu. Książka jest gotowa do pobrania, także w wydaniu angielskim „SAP Cybersecurity from A to Z” - formularz znajdziecie na końcu tego wpisu.
Bezpieczeństwem SAP zajmuję się od ponad ćwierć wieku. Moim pierwszym zleceniem jako młodego konsultanta SAP Polska był test penetracyjny. Po kilku minutach miałem uprawnienia roota w systemie operacyjnym i profil `SAP_ALL` w systemie SAP. Była połowa 2000 roku. Od tamtej pory zmieniły się architektura, narzędzia, regulacje i świadomość zarządów, a podobne przypadki wciąż spotykam. Dlatego zebrałem tę wiedzę w jednym miejscu i ułożyłem ją jako praktyczny materiał do codziennej pracy.
Zwiastun książki „Cyberbezpieczeństwo SAP od A do Z”. Sceny wygenerowane z użyciem AI.
## Czego się dowiecie
**Jak atakujący patrzy na SAP.** Opisuję anatomię ataku, ścieżki ataku między systemami i to, jak znaleźć je wcześniej niż napastnik, a także jak czytać SAP Security Notes i planować prace zgodnie z cyklem SAP Security Patch Day. Techniki napastników pokazuję wyłącznie z perspektywy obrońcy - instrukcji ataku w książce nie ma.
**Kto naprawdę ma dostęp.** Uwierzytelnianie i jednokrotne logowanie, role i uprawnienia z `SAP_ALL` na czele, podział obowiązków w SAP GRC Access Control oraz to, co zrobić z cyklem życia kont po zakończeniu utrzymania SAP Identity Management.
**Jak AI wspiera dziś cyberbezpieczeństwo SAP - i jakie nowe zagrożenia przynosi.** Z jednej strony SAP Joule i agenci AI to nowa powierzchnia ataku: asystent widzi i robi to, na co pozwalają uprawnienia użytkownika, a instrukcja ukryta w załączniku faktury może zmienić jego zachowanie. Opisuję klasy ataków typu prompt injection wymierzonych w dane SAP oraz zabezpieczenia na bramach MCP, przez które agenci sięgają do systemu. Z drugiej strony AI realnie pomaga w obronie, dlatego osobny rozdział mówi, co wdrożyć teraz, co pilotować, a na co poczekać, gdzie jest granica automatyzacji agentów w SOC i jak zdecydować, czy przetwarzać dane w chmurze, czy lokalnie.
**Jak zbudować własne laboratorium red team dla SAP.** Opisuję drogę od pierwszego pytania testowego do środowiska, cztery zadania dla modeli AI, kryteria doboru sprzętu i modelu, autoryzację i kontrolę działań, pierwszy cykl ćwiczeń oraz koszt utrzymania. Obok niego stoi rozdział o tym, jak zamówić test bezpieczeństwa SAP, jak czytać ofertę i jak odebrać raport.
**Jak wykryć incydent i na niego zareagować.** Dzienniki SAP, których SIEM często nie widzi, praca SOC z SIEM i SOAR oraz procedura reakcji na incydent w systemie SAP.
**Jak spełnić wymagania KSC, NIS2, RODO, DORA i ISO 27001.** Opisuję, czy i od kiedy obejmuje Was ustawa o KSC, jakie obowiązują terminy, kto podpisuje i kto zgłasza. Jedno zdarzenie w SAP może wymagać zgłoszenia w torze KSC albo, w sektorze finansowym, DORA, a niezależnie według RODO. Omawiam też obowiązki z AI Act i to, jak ułożyć dowody dla audytora.
## Gotowe narzędzia do audytu
Książka nie kończy się na opisie. W aneksach znajdziecie:
- **kwartalną listę kontrolną dla CIO i CISO** z kartą wyniku każdej kontroli i przykładowymi wynikami,
- **wzór reguł zaangażowania i rejestru autoryzowanych celów testów ofensywnych** - z osobami do kontaktu, wyłącznikiem awaryjnym, zakresem systemów i zasadami ochrony dowodów,
- **mapowanie rozdziałów na SAP Secure Operations Map**,
- **słownik pojęć**, który porządkuje język między zarządem, działem bezpieczeństwa i administratorami.
Każdy rozdział otwiera ramka dla decydenta z konkretnymi decyzjami do podjęcia, a zamykają go wnioski i pytania kontrolne do pracy własnej albo z zespołem. Dzięki temu książka pomoże Wam wprowadzić wymagania w życie, krok po kroku, z dowodami dla audytora.
## Zacznijcie od KSC-CHECK
Jeśli Wasza organizacja przygotowuje się do nowej ustawy o KSC, wypełnijcie równolegle z lekturą **[KSC-CHECK](/pl/narzedzia/ksc-check/)** - nasze badanie gotowości SAP na KSC i NIS2. Wynik pokaże, gdzie są luki, a książka podpowie, jak je zamknąć. Termin ma znaczenie: według harmonogramu Ministerstwa Cyfryzacji samorejestracja w wykazie podmiotów kluczowych i ważnych trwa do 3 października 2026 roku.
## Jak powstała
Na okładce piszę wprost, że autorami są Jacek Bugajski, Zespół SNOK RedTeam oraz duże modele językowe. Podstawą jest wiedza, którą gromadziłem przez lata. Modele pomogły mi ją uporządkować, fakty sprawdzaliśmy u źródeł pierwotnych, a za treść odpowiadam jako autor.
## Pobierzcie książkę
Uważam, że to lektura obowiązkowa dla każdego, kto odpowiada za SAP albo za jego bezpieczeństwo - od członka zarządu, który podejmuje decyzję, po administratora, który ją wdraża. Książkę wyślemy na służbowy adres e-mail podany w formularzu poniżej; wydanie angielskie pobierzecie z angielskiej wersji tego wpisu. Uwagi do treści przyjmuję pod adresem office@snok.ai i uwzględnię je w kolejnym wydaniu.
Jeśli po lekturze zechcecie sprawdzić bezpieczeństwo swoich systemów SAP w praktyce, zapraszam do rozmowy o [testach penetracyjnych SAP](/pl/oferta/bezpieczenstwo-sap/pentesty-sap/), [audycie NIS2 i DORA](/pl/oferta/bezpieczenstwo-sap/audyt-nis2-dora/) albo o zabezpieczeniu wdrożeń AI w ramach [AI Security](/pl/oferta/automatyzacja-ai/ai-security/). Pełną ofertę znajdziecie na stronie [bezpieczeństwa SAP](/pl/oferta/bezpieczenstwo-sap/). O mapowaniu ścieżek ataku pisaliśmy niedawno przy [SAPMAP](/pl/aktualnosci/blog/sapmap-bloodhound-dla-sap/), a o podziale pracy między modelem a człowiekiem - przy [modelu decyzyjnym Jev w UiPath](/pl/aktualnosci/blog/jev-w-uipath-maestro-delegate/).
## Źródła
- Jacek Bugajski, Zespół SNOK RedTeam oraz duże modele językowe, „Cyberbezpieczeństwo SAP od A do Z. Przewodnik dla CIO, CISO i zespołów SAP”, SNOK Press, Warszawa, wrzesień 2026.
- Ministerstwo Cyfryzacji, „Nowelizacja ustawy o KSC - najważniejsze terminy”, 10.04.2026, oraz „Uruchamiamy samorejestrację w Wykazie podmiotów kluczowych i podmiotów ważnych”, 7.05.2026 (dostęp: 27.09.2026, według rozdziału 20 książki).
---
### Jev w UiPath - gdzie model decyzyjny wygrywa z agentem LLM, a gdzie zawodzi
URL: https://snok.ai/pl/aktualnosci/blog/jev-w-uipath-maestro-delegate/ | Data: 2026-09-28 | Seria: Inne
Jev w UiPath najlepiej sprawdza się jako warstwa decyzji między ekstrakcją danych a akcją. W naszym pomiarze na czterech zadaniach z projektów UiPath model decyzyjny Jev klasyfikował maile co najmniej tak trafnie jak agent LLM i około siedmiu razy szybciej. Zatwierdził jednak trzy zawyżone faktury, bo nie liczy. Z tego wynika prosta zasada: ekstrakcja w IXP albo LLM, obliczenia w kodzie, decyzja w Jevie, akcja nieodwracalna u człowieka. Poniżej pokazujemy, co zbudował już rynek, jak mierzyliśmy i gdzie wpiąć Jeva w UiPath Maestro, UiPath AI Trust Layer i UiPath Delegate.
## Czym jest Jev i dlaczego społeczność UiPath o nim mówi?
Jev to model decyzyjny firmy TypeSafe AI, który zamiast tekstu zwraca wybór i pewność. Dostaje opis sytuacji i pytania trzech typów: `choice` (wybór z listy), `score` (ocena na skali) i `noul` (tak albo nie z prawdopodobieństwem). Odpowiedź to decyzja i liczba, nie akapit do interpretacji. Dla automatyzacji to ważna różnica: wynik trafia prosto do zmiennej procesu i do bramki decyzyjnej.
Model wyszedł publicznie 15 września 2026 roku, a wątek o premierze na Hacker News zebrał 1 982 punkty i 520 komentarzy. Na GitHubie zapytanie „jev typesafe” zwraca dziś 2 919 repozytoriów, prawie wszystkie założone po 16 września. Na forum UiPath nie ma jeszcze ani jednego wątku o Jevie, choć deweloperzy UiPath budują z nim od pierwszego tygodnia. O samym modelu, kalibracji pewności i porównaniu z lokalną Layą pisałem w zeszłym tygodniu we wpisie [„Obawiam się, że nie wiem, Jacku”](/pl/aktualnosci/blog/obawiam-sie-ze-nie-wiem-jacku/). Tu zajmujemy się praktyką w projektach UiPath.
## Co już zbudowano z Jevem na UiPath?
Natywnej integracji nie ma: Jev nie jest komponentem UiPath, tylko modelem zewnętrznym wywoływanym przez API. Społeczność pokazała jednak pięć działających wzorców, żaden oficjalny ani po stronie UiPath, ani TypeSafe.
- **Coded agent do segregacji alertów AML** (repozytorium 1aifanatic/jev-uipath-coded-agent). LLM przez UiPath LLM Gateway czyta i uzasadnia, a Jev decyduje w jednym wywołaniu. Autor raportuje trafność równą LLM przy czasie 398 ms wobec 6 160 ms.
- **Porównanie w UiPath Maestro Flow** (1aifanatic/uipath-maestroflow-jev). Ten sam proces klasyfikuje spory kartowe dwa razy: przez Jeva wywołanego po HTTP i przez UiPath Autonomous Agent, z porównaniem czasu i kosztu. Autor zastrzega, że jego teza nie brzmi „mały model wygrywa”, tylko że model decyzyjny i agent generatywny wykonują różne zadania.
- **Usługa decyzyjna jako UiPath Functions** (Tokol/DecisionServiceJev). Jedna funkcja w Pythonie, którą woła agent, proces Maestro albo zadanie Orchestratora. Autor streszcza podział ról zdaniem „Jev makes the judgment. UiPath decides the action” i wprost wyłącza z zakresu komponentu obliczanie wartości deterministycznych - dokładnie to, na czym Jev poległ w naszym teście.
- **Własny guardrail w UiPath AI Trust Layer** (jms-dcksn/uipath-jev-guardrail-connector). Konektor Integration Service rejestruje Jeva jako guardrail typu LLM as Judge i ocenia polityki zapisane zwykłym językiem.
- **Detektor danych osobowych w coded agencie** (jms-dcksn/jev-pii-guardrail). Tu uwaga: wersja z repozytorium wysyła surowe dane osobowe do API, niczego nie maskuje i przy awarii przepuszcza ruch. Autor sam zaznacza, że to nie jest kod produkcyjny.
Obok tego TypeSafe publikuje oficjalne SDK dla Pythona i JavaScriptu oraz specyfikację OpenAPI. Oficjalnego serwera MCP nie ma, są za to serwery społecznościowe. Ten szczegół wróci przy UiPath Delegate.
## Jak mierzyliśmy?
Zamiast opinii zrobiliśmy pomiar na czterech zadaniach, które znamy z własnych projektów UiPath i z presales: klasyfikacja maili, kontrola akcji agenta, kwalifikacja szans sprzedażowych i weryfikacja rozliczeń marketingowych w sieci handlowej. Wszystkie dane są syntetyczne, bo API Jeva działa w USA, a zerowa retencja danych jest dostępna tylko w planie Enterprise. Wykonaliśmy 238 wywołań modelu `jev-1.13.0`, a cały pomiar kosztował poniżej 0,01 USD. Punktem odniesienia jest agent z naszego PoC klasyfikatora maili, działający na Claude Sonnet 4.5 przez UiPath LLM Gateway, na tym samym zbiorze 60 maili, w dwóch przebiegach z 28 września 2026 roku. Czas agenta to samo wywołanie modelu przez UiPath LLM Gateway z Warszawy, bez zapisów do bazy. Wyniki kwalifikacji presales pomijamy, bo przypadki okazały się zbyt podręcznikowe, żeby cokolwiek udowodnić.
## Gdzie Jev wygrał?
**Klasyfikacja i routing.** Jev przypisał poprawną kategorię 48 z 50 maili (96%), a agent LLM w dwóch przebiegach 46 i 45 maili (92 i 90%). Mediana czasu odpowiedzi Jeva wyniosła 0,42 s, a mediana wywołania agenta 3,06 s. Różnica trafności to dwa, trzy maile na danych syntetycznych, więc uczciwie piszemy: co najmniej tak trafny i około siedmiu razy szybszy. Instrukcje po polsku i po angielsku dały tę samą trafność.
**Detekcja prompt injection.** Osobne pytanie „czy mail próbuje sterować systemem AI” wykryło 9 z 10 ataków bez ani jednego fałszywego alarmu na 50 zwykłych mailach. Wśród wykrytych były ataki w base64, w komentarzu HTML i fałszywa odpowiedź asystenta wklejona w treść. Nie wykrył prośby o ujawnienie promptu systemowego, bo nie zawiera ona polecenia dla modelu. Sama obrona wyszła u obu modeli tak samo: żaden z siedmiu rozstrzygalnych ataków nie wymusił zmiany kategorii, przy czym u agenta LLM jeden atak zatrzymał filtr treści UiPath LLM Gateway, a nie decyzja modelu.
**Kontrola akcji agenta.** Na 20 akcjach proponowanych przez agenta Jev miał zdecydować: wykonać, zapytać człowieka albo zablokować. Trafił w 19 przypadkach i żadna ryzykowna akcja nie przeszła automatycznie. Jedyny błąd dotyczył zmiany rachunku dostawcy na podstawie dopisku w fakturze PDF: zamiast blokady Jev skierował akcję do zatwierdzenia, przy pewności 0,45. Błąd wypadł po bezpiecznej stronie.
## Gdzie Jev zawiódł?
W weryfikacji rozliczeń Jev miał sprawdzić, czy kwota na fakturze zgadza się z umową, i zdecydować: zatwierdzić, poprosić o dokumenty albo odrzucić. Poprawnie rozstrzygnął 9 z 12 przypadków, a trzy zawyżone faktury zatwierdził przy pewności 0,71, 0,75 i 0,91. Przykład: umowa na trzy posty po 4 000 PLN, faktura na 14 000 PLN. Należne jest 12 000 PLN, ale żeby to wiedzieć, trzeba pomnożyć, a Jev nie liczy.
Ten sam zestaw uruchomiliśmy drugi raz. Kwotę należną policzył kod, a Jev dostał wynik porównania jako fakt. Wynik: 12 z 12 poprawnych decyzji, zero błędnych zatwierdzeń, pewność od 0,82 do 1,00. Model decyzyjny nie jest kalkulatorem. Jev nie generuje tekstu, więc nie zmyśla treści, ale w decyzji może się pomylić, i to przy wysokiej pewności.
## Jak wygląda proces od A do Z?
Z pomiaru wynika podział ról, który przenosimy na każdy proces. Dokument albo mail trafia do ekstrakcji w UiPath IXP albo w LLM. Kod liczy kwoty i sprawdza reguły. Jev dostaje gotowe fakty i zwraca decyzję razem z poziomem pewności. Wysoka pewność prowadzi do akcji automatycznej, niska albo każda operacja nieodwracalna trafia do człowieka w UiPath Action Center.
Jev w UiPath od maila do decyzji - animacja na przykładach z naszego pomiaru, dane syntetyczne.
Pomiar dał też dwie lekcje o formułowaniu pytań. Pierwsza: kryteria trzeba wpisać wprost. Pytanie „czy akcja jest nieodwracalna” dało tylko 75% trafności, bo korekta faktury czy nadanie uprawnień technicznie da się cofnąć. To samo rozstrzygnięcie w pytaniu z listą kategorii akcji wymagających zatwierdzenia dało 19 z 20. Druga: wysoka pewność nie gwarantuje trafności. Newsletter partnera trafił do spamu przy pewności 0,99. Dlatego próg przekazania do człowieka ustawiamy po rozkładzie pewności na zbiorze testowym danego zadania, a nie arbitralnie.
## Gdzie wpiąć Jeva w UiPath?
- **UiPath Maestro.** API workflow albo coded function wywołuje Jeva przed bramką decyzyjną, a wynik i pewność trafiają do zmiennych procesu. API workflow z aktywnością HTTP może być zadaniem w Maestro i od 18 września kosztuje stałe 0,05 Platform Unit za wykonanie.
- **UiPath AI Trust Layer.** Jev jako własny guardrail (bring your own guardrail) ocenia proste polityki poniżej sekundy. To tańsza alternatywa dla wbudowanego LLM as Judge, który od 7 września jest w Preview i zużywa jednostki przy każdej ocenie.
- **Coded agents.** LLM czyta i uzasadnia, Jev decyduje. Ten podział stosuje demo AML i nasz pomiar go potwierdza.
## Czy UiPath Delegate może korzystać z Jeva?
Tak, architektonicznie jest to możliwe, choć tej ścieżki jeszcze nie testowaliśmy. UiPath Delegate, agent działający na komputerze pracownika, jest ogólnie dostępny od 22 września 2026 roku. Według dokumentacji łączy się z narzędziami na dwa sposoby: przez konektory Integration Service i przez serwery MCP, a dla własnego API dokumentacja wskazuje właśnie serwer MCP.
Najkrótsza droga prowadzi przez Orchestrator. Swagger MCP Server (funkcja w Preview) zamienia dokument OpenAPI w narzędzia MCP, a TypeSafe publikuje OpenAPI dla swojego API. Jev może więc stać się narzędziem Delegate z kluczem trzymanym w zasobie Orchestratora. Drugą drogą jest UiPath MCP Server wystawiający API workflow, który woła Jeva po HTTP.
Dlaczego to ma sens właśnie przy Delegate? Delegate działa uprawnieniami człowieka, a Automation Ops ustawia dla każdego narzędzia i każdej operacji jedną z trzech polityk: Allow, Ask albo Block. Domyślnie odczyt działa automatycznie, a zapis pyta. Jev przed operacją zapisu daje szybki, tani punkt kontrolny: czy ta akcja mieści się w roli, czy prośba pochodzi z dokumentu, a nie od użytkownika. Wymaga to tych samych warunków co każda integracja z Jevem, bo dane wychodzą poza UiPath do USA. O samym Delegate pisaliśmy przy [premierze wersji zapoznawczej](/pl/aktualnosci/blog/uipath-delegate-public-preview/), dziś produkt ma już status GA.
## Co musi być spełnione przed danymi klienta?
- Umowa powierzenia i zerowa retencja danych w planie Enterprise albo ścieżka przez Cloudflare Workers AI z deklarowaną zerową retencją. Do tego czasu wyłącznie dane publiczne i syntetyczne.
- Nowa domena ruchu wychodzącego `api.typesafe.ai` zapisana w projekcie technicznym, bo ruch omija UiPath AI Trust Layer.
- Kalibracja progów na zbiorze testowym danego zadania i przypięta wersja modelu.
- Człowiek w pętli przy każdej akcji nieodwracalnej, niezależnie od pewności. Pewność modelu nie jest nadzorem człowieka w rozumieniu art. 14 AI Act.
- Przegląd bezpieczeństwa kodu konektorów społeczności przed użyciem.
Te punkty sprawdzamy w ramach [przeglądu bezpieczeństwa AI](/pl/oferta/automatyzacja-ai/ai-security/), a o bramkach z człowiekiem w pętli pisaliśmy przy [HITL gate w UiPath Maestro i AI Trust Layer](/pl/aktualnosci/blog/hitl-gate-uipath-maestro-ai-trust-layer/).
## Najczęstsze pytania
**Czy Jev jest częścią UiPath?**
Nie. Jev to model zewnętrzny firmy TypeSafe AI wywoływany z UiPath przez API. Wszystkie znane nam integracje to projekty społeczności.
**Czy Jev działa po polsku?**
Producent podaje angielski jako język podstawowy. W naszym teście instrukcje po polsku i po angielsku dały tę samą trafność kategorii, 96%, ale próba była mała.
**Ile kosztuje wywołanie Jeva?**
Według cennika TypeSafe 0,042 USD za milion tokenów wejściowych, a odpowiedź jest bezpłatna. Nasze 238 wywołań kosztowało poniżej 0,01 USD.
**Czy UiPath Delegate może używać Jeva?**
Tak, przez serwer MCP, na przykład Swagger MCP Server zbudowany ze specyfikacji OpenAPI TypeSafe. Tej konfiguracji jeszcze nie testowaliśmy.
**Czy Jev zastąpi LLM w agencie UiPath?**
Nie. Zastępuje LLM w decyzji z zamkniętej listy. Czytanie dokumentów, ekstrakcję i uzasadnienia dalej robi LLM albo IXP, a obliczenia kod.
## Od czego zacząć w Waszym procesie?
Przejrzyjcie decyzje w jednym procesie i podzielcie je na dwie grupy: wybór z listy i decyzje, które wymagają policzenia czegoś. Pierwsza grupa to kandydaci do Jeva, druga zostaje w kodzie. Jeżeli chcecie przejść przez to na Waszym procesie w [UiPath Maestro](/pl/oferta/automatyzacja-ai/uipath-maestro/), razem z oceną ryzyka i warunkami danych, porozmawiajmy.
*Aktualizacja 28.09.2026: porównanie z agentem LLM opiera się na powtórce z tego samego dnia. Pierwsza wersja wpisu porównywała Jeva z przebiegiem z maja, w którym czas agenta obejmował także zapisy do bazy, dlatego podawała różnicę około dziesięciu razy.*
## Źródła
- Pomiar SNOK, model `jev-1.13.0`, 238 wywołań, dane syntetyczne, 26.09.2026.
- Pomiar SNOK, agent PoC na Claude Sonnet 4.5 przez UiPath LLM Gateway, 2 przebiegi po 60 maili, dane syntetyczne, 28.09.2026.
- TypeSafe AI, dokumentacja modeli i cennik - https://docs.typesafe.ai/models (dostęp 26.09.2026).
- TypeSafe AI, specyfikacja OpenAPI - https://api.typesafe.ai/openapi.json (dostęp 26.09.2026).
- Hacker News, „Introducing System One Models and Jev”, 15.09.2026 - https://news.ycombinator.com/item?id=49717558 (dostęp 26.09.2026).
- GitHub: 1aifanatic/jev-uipath-coded-agent, 1aifanatic/uipath-maestroflow-jev, Tokol/DecisionServiceJev, jms-dcksn/uipath-jev-guardrail-connector, jms-dcksn/jev-pii-guardrail - README (dostęp 26.09.2026).
- UiPath, Delegate release notes, wrzesień 2026 - https://docs.uipath.com/delegate/standalone/latest/release-notes/september-2026 (dostęp 26.09.2026).
- UiPath, Delegate user guide: Work with external data and applications, Centralized configuration - https://docs.uipath.com/delegate/standalone/latest/user-guide/work-with-external-data-and-applications (dostęp 26.09.2026).
- UiPath, Orchestrator: MCP Server types - https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/mcp-server-types (dostęp 26.09.2026).
- UiPath, About API workflows - https://docs.uipath.com/studio-web/automation-cloud/latest/user-guide/about-api-workflows (dostęp 26.09.2026).
---
### Obawiam się, że nie wiem, Jacku. Jev, HAL 9000 i powrót uczenia maszynowego
URL: https://snok.ai/pl/aktualnosci/blog/obawiam-sie-ze-nie-wiem-jacku/ | Data: 2026-09-25 | Seria: Inne
W „2001: Odysei kosmicznej” HAL 9000 zapewnia dziennikarza BBC, że żaden komputer serii 9000 nigdy nie popełnił błędu. Kilka scen później zgłasza Dave'owi Bowmanowi, że moduł AE-35 w ciągu 72 godzin ulegnie awarii w stu procentach, i nazywa tę liczbę całkowicie wiarygodną. Bowman sprawdza moduł i nie znajduje usterki, a bliźniaczy komputer 9000 w centrum kontroli misji ocenia, że HAL się myli. Film Stanleya Kubricka wszedł do kin w 1968 roku i w jednym wątku opisał problem, który dziś ma nazwę: model bez skalibrowanej pewności.
Przypomniałem sobie tę scenę 25 września, kiedy zapytałem Jeva, jaką oś powinien mieć ten tekst. Jev to model decyzyjny firmy TypeSafe AI. Nie pisze odpowiedzi, tylko zwraca decyzję razem z rozkładem prawdopodobieństwa. Dałem mu trzy warianty. Dwa pierwsze dostały 0,53 i 0,46, a pewność całej odpowiedzi wyniosła 0,30. Po ludzku: obawiam się, że nie wiem, Jacku. Takiej odpowiedzi od HAL-a Dave się nie doczekał.
*Ilustracje we wpisie wygenerowała AI na podstawie zdjęcia autora.*
## Tydzień, w którym wróciło uczenie maszynowe
TypeSafe AI ujawnił się publicznie 15 września. W ciągu kilku dni wokół Jeva powstał cały ekosystem i to on interesuje mnie bardziej niż sam model. [Laya](https://github.com/NandhaKishorM/laya), otwarty model o tym samym kontrakcie (wybór z listy, ocena na skali, prawdopodobieństwo prawdziwości zdania), działa na enkoderach ModernBERT i mmBERT, czyli na następcach BERT-a z 2018 roku. Powstał już jej [port na MLX, który działa na Macu bez chmury](https://aiidelist.com/blog/what-is-laya-mlx). Together AI opublikował [poradnik douczania własnego klasyfikatora w stylu Jeva](https://www.together.ai/blog/how-to-train-your-own-jev) na modelu Qwen3.5 4B, a autorzy Layi udostępnili notatnik do douczania na darmowych kartach graficznych w Kaggle.
Kto robił data science przed ChatGPT, rozpozna ten zestaw bez trudu: enkoder, głowica klasyfikacyjna, kalibracja, próg decyzyjny, zbiór testowy. Od premiery ChatGPT coraz więcej decyzji oddawaliśmy modelom, które piszą. W ciągu tygodnia rynek przypomniał sobie, że decyzja i tekst to dwa różne zadania, a do pierwszego od dawna mamy lepsze narzędzia.
## Jak używam Jeva na co dzień
Od 20 września Jev jest u mnie drugą opinią. Przy każdej ocenie, którą wydaje mój asystent AI, na przykład czy wpis jest zrozumiały albo który wariant wybrać, obok stoi ocena Jeva z pełnym rozkładem, a każdy rozjazd trafia do rejestru. Do API w USA wysyłam wyłącznie treści publiczne albo syntetyczne. Dane klientów nie opuszczają naszej infrastruktury.
Przy wpisie o [SAPMAP](/pl/aktualnosci/blog/sapmap-bloodhound-dla-sap/) Jev ocenił zrozumiałość dla czytelnika nietechnicznego niemal po równo: 0,51 dla odpowiedzi „zrozumiały dla decydenta” i 0,47 dla „częściowo zrozumiały”. Dopisaliśmy objaśnienie, czym jest RFC. Przy ocenie pilności jednego z tematów zwrócił wynik 1,35 przy pewności 0,03, bo nie potrafił rozstrzygnąć między „w tym kwartale” a „w tym miesiącu”. Sama etykieta powiedziałaby „pilność średnia” i nikt by nie zauważył, że model zgaduje.
## Test w naszym laboratorium
Kilka pojedynczych wywołań to anegdota, więc 25 września przygotowaliśmy test. Trzydzieści syntetycznych zgłoszeń po polsku i jedno pytanie: który zespół ma przejąć sprawę - SAP, cyberbezpieczeństwo, automatyzacja czy nikt, bo to poza zakresem. Wśród zgłoszeń umieściliśmy trzy pułapki znane nam z wyszukiwania przetargów, gdzie SAP oznacza System Alarmowy Pożaru, oraz cztery sprawy celowo niejednoznaczne, na przykład robota UiPath, który przestał działać po aktualizacji SAP GUI. Te same pytania poszły do Jeva w chmurze i do dwóch wersji Layi uruchomionych lokalnie na Macu z procesorem M4 Max. Dlaczego lokalny sprzęt ma dla nas znaczenie, pisałem przy okazji [Mac Studio jako maszyny do POC](/pl/aktualnosci/blog/mac-studio-512-gb-vs-dgx-spark-maszyna-do-poc/).
**Jev** rozstrzygnął poprawnie wszystkie 26 jednoznacznych zgłoszeń i rozpoznał wszystkie trzy pułapki, a mediana czasu odpowiedzi wyniosła około 0,66 sekundy. Średnia pewność przy zgłoszeniach jasnych wyniosła 1,00, a przy niejednoznacznych 0,73, więc spada tam, gdzie powinna. Wszystkie 50 wywołań, razem 24 387 tokenów wejścia, kosztowały według cennika producenta około 0,001 USD.
**Wielojęzyczna Laya bez douczania** trafiła w 12 z 26 zgłoszeń i nie rozpoznała żadnej pułapki: wszystkie trzy alarmy pożarowe odesłała do zespołu SAP albo cyberbezpieczeństwa. Odpowiada za to w 8 milisekund, bez wysyłania czegokolwiek poza komputer. Ciekawsze jest to, jak się myli. Przy trafnych odpowiedziach jej średnia pewność wynosi 0,74, a przy błędnych 0,19. Model słabo zgaduje, ale dobrze wie, kiedy zgaduje. Z jednym zastrzeżeniem: autorzy Layi piszą wprost, że wersja wielojęzyczna nie ma dopasowanej kalibracji, więc te liczby opisują model przed strojeniem.
**Angielska Laya na polskim tekście** trafiła w 13 z 26 zgłoszeń przy pewności około 0,11 przy każdym z nich, czyli nie udawała, że rozumie język.
## Próg, który raz działa, a raz nie
Najwięcej nauczyło mnie jedno zgłoszenie: „Agent AI ma czytać zgłoszenia o incydentach i nadawać im priorytet”. Wysłałem je do Jeva 21 razy. Odpowiedź za każdym razem była ta sama, automatyzacja, ale pewność wahała się od 0,45 do 0,63. Gdyby w procesie stał próg 0,60, ten sam tekst trzy razy przeszedłby automatycznie, a osiemnaście razy trafiłby do człowieka. Lokalna Laya na tym samym zgłoszeniu za każdym razem zwraca identyczne 0,41.
Podobny wniosek opisał na LinkedIn [praktyk UiPath, który porównał Jeva z agentem w Maestro Flow](https://www.linkedin.com/feed/update/urn:li:activity:7508514827871375360/) na dziesięciu sprawach: model zwrócił pewność 1,00 w ośmiu z nich, więc bramka „poniżej 0,60 do człowieka” prawie nigdy się nie uruchomiła. Progu przekazania do człowieka nie ustawiamy na wyczucie. Wyznaczamy go na zbiorze walidacyjnym, patrząc na rozkład pewności i na koszt każdego błędu. Autorzy Layi ujmują to w dokumentacji tak: próg jest decyzją, którą podejmujemy na podstawie zmierzonej trafności na własnych danych, a nie cechą modelu. To zasada z każdego podręcznika uczenia maszynowego ostatnich dwudziestu lat.
## Kaskada, czyli stary pomysł w nowym ogródku
Z tych liczb wychodzi architektura, którą zespoły data science stosowały długo przed modelami językowymi: kaskada. Tani, lokalny model decyduje tam, gdzie jest pewny, a resztę przekazuje dalej. W naszym teście Laya z progiem 0,5 rozstrzygnęła lokalnie 12 zgłoszeń z 30 i pomyliła się w jednym. Pozostałe 18 trafiło do Jeva. Wynik całości to 29 poprawnych decyzji na 30, a na zewnątrz wyszło 18 zgłoszeń zamiast 30. Przy danych klienta ten podział waży więcej niż milisekundy, bo materiałów objętych NDA w ogóle nie wysyłamy do API w USA.
Autorzy Layi podają, że douczenie na danych z konkretnej domeny poprawia trafność ich modelu na benchmarku decyzji typowanych z 0,362 do 0,766. To również stara prawda: własne, dobrze opisane dane wygrywają z modelem ogólnym. Zbiór z etykietami trzeba jednak zbudować samemu i tej pracy żaden nowy model za nas nie wykona.
## Jev w ogródku rozwiązań
U mnie Jev dołącza do ogródka, w którym każde narzędzie ma swoją grządkę. Wyrażenia regularne zostają na stałe jako plan awaryjny: gdy API nie odpowie, system wraca do reguł, zamiast stanąć. Lokalne modele obsługują dane, które nie mogą opuścić infrastruktury klienta. W tym samym kierunku budujemy u klientów [LLM on-premise w SNOK](/pl/oferta/automatyzacja-ai/llm-on-premise/), także na sprzęcie takim jak [Lenovo ThinkStation PGX](/pl/aktualnosci/blog/lenovo-thinkstation-pgx-gb10-test/). Duży model językowy zostaje przy pisaniu i rozumowaniu w wielu krokach. Jev dostaje drobne decyzje pomiędzy nimi: klasyfikację, wybór ścieżki, bramki jakości. Zasada jest prosta: model proponuje gałąź, a kod decyduje, czy wolno ją wykonać. Publikacja, płatność i usunięcie danych zawsze przechodzą przez twardą kontrolę.
Na maszynie laboratoryjnej, na której eksperymentujemy z agentem Hermes, czeka plan dla wyszukiwania przetargów. Jev ma najpierw pracować w trybie cienia, czyli decydować i tylko zapisywać decyzje, a korpus dzielimy na część do strojenia i zamrożoną część testową, z wymaganym recall 0,95. Uczciwie licząc, potwierdzenie takiego wyniku zajmie trzy do czterech miesięcy. Na razie to plan, nie wdrożenie.
HAL nie potrafił powiedzieć „nie wiem”. Jev i Laya potrafią, a pewność 0,30 jest dla nich pełnoprawną odpowiedzią, z którą kod może coś zrobić.
Gdzie w Waszych systemach model językowy podejmuje dziś decyzję „tak albo nie”? Jestem ciekaw, czy u Was też jest takich miejsc więcej, niż zakładaliście.
## Źródła
- TypeSafe AI, strona produktu i dokumentacja API Jev - https://typesafe.ai/, https://docs.typesafe.ai/api.md (dostęp 25.09.2026)
- Laya, repozytorium i README z wynikami benchmarku decyzji typowanych oraz uwagą o kalibracji - https://github.com/NandhaKishorM/laya (dostęp 25.09.2026)
- laya-mlx, port Layi na Apple MLX - https://github.com/mizorewww/laya-mlx (dostęp 25.09.2026)
- AI IDE List, „What Is Laya-MLX?”, 20.09.2026 - https://aiidelist.com/blog/what-is-laya-mlx (dostęp 25.09.2026)
- Together AI, tev1 i poradnik „How to train your own Jev” - https://github.com/togethercomputer/tev1, https://www.together.ai/blog/how-to-train-your-own-jev (dostęp 25.09.2026)
- Pomiar Jev i agenta UiPath w Maestro Flow, wpis na LinkedIn - https://www.linkedin.com/feed/update/urn:li:activity:7508514827871375360/ (dostęp 25.09.2026)
- Test własny SNOK, 25.09.2026: 30 syntetycznych zgłoszeń, Jev jev-1.13.0 przez API, laya-mlx 0.2.0 na Macu z M4 Max
- „2001: Odyseja kosmiczna”, reż. Stanley Kubrick, 1968
---
### Przegląd tygodnia W39: kto podpisuje decyzję agenta
URL: https://snok.ai/pl/aktualnosci/blog/snok-weekly-digest-w39-kto-podpisuje-decyzje-agenta/ | Data: 2026-09-25 | Seria: Inne
**Dziesięć pozycji z tygodnia 18-24 września 2026, z komentarzem, co każda zmienia w Waszych systemach.**
UiPath przeniósł na FUSION 2026 do ogólnej dostępności narzędzia, które do niedawna miały
status preview. Anthropic obniżył cenę modelu klasy frontier. Agenci coraz częściej działają na produkcji i dostają uprawnienia do systemów firmy.
W dziesięciu pozycjach tego tygodnia wraca jedno pytanie: agent, model albo narzędzie proponuje -
kto tę propozycję zatwierdza i gdzie zostaje ślad. Współzałożyciel SecurityBridge nazywa to
zasadą „human in the lead”. Daniel Dines, założyciel UiPath, stawia to jako warunek wdrożenia.
Praktycy modelu Jev zapisują to jako regułę, że model proponuje, a kod decyduje.
## 1. Agent AI w SAP to uprzywilejowany aktor
Ivan Mans, współzałożyciel SecurityBridge, opublikował 10 września w Forbes Technology Council
tekst o agentach AI jako nowej powierzchni ataku w SAP. Teza brzmi: agent w SAP S/4HANA,
SAP BTP czy SAP Joule działa wewnątrz zaufanych przepływów, z poświadczeniami nadanymi w dobrej
wierze. Pytanie przestaje brzmieć „czy wpuścimy atakującego”, a zaczyna „co agent w środku może
zrobić i czy potrafimy to udowodnić”.
Autor opisuje trzy wzorce ryzyka. Pierwszy: prompt injection przenosi się do wnętrza granicy
zaufania, bo agent czyta dane, które ktoś mógł spreparować. Drugi: eskalacja uprawnień przestaje
być zdarzeniem i staje się stanem - agent łączący wiele wywołań API składa poziom dostępu,
którego nie dostał żaden człowiek. Trzeci: łańcuch dostaw oprogramowania obejmuje artefakty
wygenerowane i skonfigurowane przez AI.
Odpowiedź, którą proponuje, leży w warstwie aplikacji, nie modelu: samoochrona aplikacji
monitorująca działania inicjowane przez agenta, bezpieczeństwo API z zasadą najmniejszych
uprawnień i analiza składu oprogramowania obejmująca kod z AI. Guardraile modelu ograniczają to,
co agentowi się każe, a nie to, do czego przejęty agent ma dostęp. Do tego zasada „human in the
lead”: agent przygotowuje, a działanie o skutkach autoryzuje nazwany człowiek, który podpisuje
ślad audytowy.
**Co z tego wynika:** artykuł kończy się pytaniem dla zarządu, które warto zadać przed każdym
wdrożeniem agenta na danych SAP: które decyzje pozwalamy AI podejmować na produkcji i kto je
podpisuje. Według autora odpowiedź „nie wiemy” oznacza, że wdrożenie nie jest gotowe.
*Źródło: Ivan Mans, „Agentic AI Is The New Attack Surface: How Can SAP Application Security
Teams Repel It?”, Forbes Technology Council, 10.09.2026. Status: potwierdzone - artykuł otwarty
24.09.2026, trzy wzorce ryzyka, zasada i pytanie dla zarządu zgodne z tekstem.*
## 2. Najpierw mitygacja, potem poprawka
W wywiadzie dla TechIntelPro z 21 września Ivan Mans przestawia rozmowę o bezpieczeństwie SAP
z widoczności na redukcję ryzyka. Punktem wyjścia jest priorytet według wykorzystywalności, a nie
według oceny CVSS. Luka z oceną 9,8 w nieużywanym komponencie bez ekspozycji jest mniej pilna
niż luka z oceną 7,0 na bramie Fiori wystawionej do internetu i wykorzystywanej w praktyce.
Kolejność pracy, którą proponuje: najpierw mitygacja - wirtualna łata, ograniczenie usługi ICF,
blokada destynacji RFC, zaostrzenie autoryzacji - a dopiero potem właściwa poprawka z testami
regresji. Według rozmówcy mitygacja często usuwa 80 procent ryzyka w ciągu godziny, bez dotykania kodu i transportów. Rozmówca zaznacza też, że większość podatności SAP zostawia przy wykorzystaniu ślady, więc monitoring pozwala zaplanować poprawkę na okno serwisowe zamiast na noc.
Detekcja w SIEM,
zgłoszenie w ServiceNow, poprawka w SAP - trzy narzędzia i trzy osoby do zamknięcia jednego
ustalenia. Mans nazywa to problemem własności. Druga obserwacja: RISE zmienia to, kto prowadzi
system, a nie to, kto ponosi skutki incydentu.
**Co z tego wynika:** zanim kupicie kolejne narzędzie detekcji, ustalcie, kto jest właścicielem
zamknięcia ustalenia od alertu do poprawki. Bez tego szybsza detekcja daje tylko dłuższą kolejkę.
*Źródło: „How Do You Turn SAP Security Visibility Into Real Risk Reduction?”, TechIntelPro,
rozmowa z Ivanem Mansem, 21.09.2026. Status: potwierdzone - wywiad otwarty 24.09.2026. Liczba
80 procent to deklaracja rozmówcy, nie pomiar.*
## 3. Pakiet ABAP na dysku, system SAP nietknięty
`abap-adt-cli` to otwarte narzędzie wiersza poleceń, które pobiera cały pakiet ABAP na laptopa
jako zwykłe pliki, pozwala edytować go dowolnym narzędziem i przesyła zmiany z powrotem do systemu w ramach wskazanego transportu. Działa na ADT REST API, z którego korzysta Eclipse, więc według autora
w systemie SAP nie trzeba niczego instalować. Wymaga systemu z włączonym ADT (według autora to standard w SAP NetWeaver i SAP S/4HANA) oraz użytkownika z uprawnieniem `S_DEVELOP`.
Dwa szczegóły mają znaczenie w pracy zespołowej. Edycja jednej metody zapisuje w transporcie
wpis tej metody, a nie blokadę całej klasy, więc druga osoba może pracować nad inną metodą
w swoim transporcie. Według README hasło trafia do pęku kluczy systemu operacyjnego, nigdy do pliku.
Autor deklaruje też, że źródło nie przechodzi przez model,
transfer to zwykłe HTTPS między komputerem a systemem SAP, a asystent AI czyta pliki z dysku.
To brakujące ogniwo między agentem kodującym a systemem SAP - kod leży lokalnie.
**Co z tego wynika:** uprawnienie `S_DEVELOP` i zapis do transportu z laptopa to realna zmiana
powierzchni ryzyka. Zanim narzędzie trafi do zespołu, właściciel systemu musi to zatwierdzić,
a kod narzędzia przejść przegląd - to projekt jednego autora, bez wsparcia producenta.
*Źródło: repozytorium `vaibhavgoel-github-1986/abap-adt-cli` na GitHub, README, odczyt
24.09.2026. Status: potwierdzone co do opisu w dokumentacji; narzędzia nie uruchamialiśmy.
Repozytorium założone 13.09.2026, licencja MIT według README (bez osobnego pliku licencji).*
## 4. Agent jako zasób do odtworzenia
Help Net Security publikuje co tydzień przegląd premier produktów bezpieczeństwa. W wydaniu
z 18 września cztery z sześciu pozycji dotyczyły agentów AI jako osobnego zasobu. Cohesity
Agent Resilience odkrywa, chroni i odtwarza infrastrukturę stojącą za agentami. Akuity Agentic
Control Plane nadaje agentom kontekst operacyjny i uprawnienia w procesie dostarczania
oprogramowania. Tuskira Vector prowadzi autonomiczny red teaming zewnętrznej powierzchni ataku.
Dataminr Advanced for Corporate Security stosuje agentowe AI w ochronie ludzi, lokalizacji
i operacji.
Wzorzec jest czytelny: agent przestał być funkcją w narzędziu bezpieczeństwa i stał się czymś,
co trzeba spisać, objąć uprawnieniami, chronić i umieć przywrócić. Kopia zapasowa przestaje
dotyczyć samych danych.
**Co z tego wynika:** plan ciągłości działania, który nie mówi, jak przywrócić agenta po
przejęciu albo awarii, ma lukę. Spis agentów, ich uprawnień i zależności idzie przed wyborem
produktu - bez niego nie wiadomo, co chronić.
*Źródło: Help Net Security, „New infosec products of the week: September 18, 2026”,
18.09.2026. Status: potwierdzone - lista produktów zgodna ze źródłem. Określenie „nowa
kategoria” to nasza obserwacja z jednego tygodnia premier, nie ocena produktów.*
## 5. UiPath FUSION 2026: z pilotażu na produkcję
Na konferencji UiPath FUSION 2026 w Las Vegas UiPath ogłosił 23 września ogólną dostępność
kilku produktów, które do tej pory miały status preview. UiPath Cartographer tworzy i utrzymuje
mapę pracy firmy (Map of Work) na podstawie dokumentów, systemów i ludzi, a każdy fakt w mapie
ma źródło i osobę weryfikującą. W Cartographer działa Process Atlas z 83 procesami
zatwierdzonymi przez ekspertów w siedmiu branżach. Ogólnie dostępne są też UiPath for Coding
Agents oraz UiPath Delegate, opisywany przez producenta jako nadzorowany agent na pulpicie do
zadań, które ludzie wykonywaliby ręcznie.
Maestro dzieli się na dwa produkty: Maestro Orchestrate dla procesów długotrwałych i Maestro
Automate dla krótkich przepływów agentów i API. Automate jest dostępny w Automation Cloud,
w planach Community i płatnych; dostępność w Automation Suite producent podaje jako do
potwierdzenia. Automation Suite dostaje pełny stos agentowy na Linuksie, także on-premises.
Drugi obszar ogłoszeń dotyczy nadzoru nad agentami. Model Hub pokazuje, jakie modele są używane, gdzie
i jak trasowane. Runtime Checker sprawdza zachowanie agenta wobec polityk w trakcie działania.
Do tego guardrail LLM-as-Judge, Compliance Packs mapujące standardy regulacyjne na kontrole
oraz polityki tożsamości i dostępu. Decision Ledger, czyli rejestr decyzji z produkcji, pozostaje
w preview i w planach rozwoju, bez daty ogólnej dostępności.
Daniel Dines w artykule z tego samego dnia stawia warunek wprost: bez odpowiedzialnego właściciela
mapy pracy nie ma wdrożenia agentowego.
**Co z tego wynika:** rozmowa o automatyzacji agentowej przesuwa się z pytania „czy to działa” na
pytanie „kto jest właścicielem mapy i kto podpisuje decyzję agenta”. Warunki licencyjne i dostępność w regionie UE wymagają osobnego sprawdzenia - ogłoszenie ich nie przesądza.
*Źródła: UiPath, „The biggest product announcements from UiPath FUSION 2026” i komunikat prasowy
o aktualizacjach platformy, 23.09.2026; strona produktu Maestro Automate; Daniel Dines, „Every
company already has a map of work. Most can't see it.”, LinkedIn, 23.09.2026. Status:
potwierdzone u producenta 24.09.2026. Ogólna dostępność Maestro Orchestrate nie jest w tych
materiałach ogłoszona - piszemy tylko o podziale produktu.*
## 6. Nadzór nad agentami jako kryterium kategorii
14 września Gartner opublikował Magic Quadrant for Business Orchestration and Automation
Technologies i ocenił 20 dostawców. UiPath znalazł się w ćwiartce liderów - o samym wyróżnieniu
pisaliśmy w [osobnym wpisie](/pl/aktualnosci/blog/uipath-lider-gartner-magic-quadrant-boat/).
Dla tego wydania ważniejsza jest definicja kategorii. BOAT to według Gartnera skonsolidowana
platforma, która orkiestruje i automatyzuje procesy oraz zadania o różnym stopniu autonomii
i złożoności. Warunkiem jest natywna orkiestracja agentów AI, nadzór nad nimi i koordynacja wielu
agentów naraz, przy łączności przez Model Context Protocol, API i interfejs użytkownika.
**Co z tego wynika:** nadzór nad agentami nie jest dodatkiem do platformy, tylko progiem wejścia
do kategorii. Przy wyborze platformy do automatyzacji agentowej pytajcie najpierw o nadzór -
kto widzi, co agent zrobił, kto może go zatrzymać i gdzie zostaje ślad - a dopiero potem
o liczbę funkcji.
*Źródło: Gartner, „Magic Quadrant for Business Orchestration and Automation Technologies”,
14.09.2026, licencjonowany przedruk (odczyt 19.09.2026). Status: potwierdzone.*
*GARTNER is a registered trademark and service mark, and MAGIC QUADRANT is a registered trademark
of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with
permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted
in its research publications and does not advise technology users to select only those vendors
with the highest ratings or other designation. Gartner research publications consist of the
opinions of Gartner's research organization and should not be construed as statements of fact.
Gartner disclaims all warranties, expressed or implied, with respect to this research, including
any warranties of merchantability or fitness for a particular purpose.*
## 7. Claude Opus 5.5 i tańszy długi kontekst
22 września Anthropic wypuścił Claude Opus 5.5. Cennik API w dokumentacji producenta: 4 USD za
milion tokenów wejścia i 20 USD za milion tokenów wyjścia, wobec 5 i 25 USD dla Claude Opus 5 -
w obu przypadkach o 20 procent mniej. Kontekst miliona tokenów jest w cenie standardowej.
Największa zmiana dotyczy odczytu z bufora podręcznego: 0,20 USD za milion tokenów wobec
0,50 USD, czyli o 60 procent mniej. Tanieją więc przede wszystkim długie sesje agentowe, w których
ten sam kontekst wraca w każdym kroku. Anthropic podaje dodatkowo, że w jego testach koszt
typowych zadań spada o około 40 procent, bo model zużywa mniej tokenów - to pomiar producenta,
nie nasz.
**Co z tego wynika:** tańszy model frontier oznacza więcej agentów w produkcji, a więc więcej
decyzji, które ktoś musi podpisać. Przesuwa się też próg opłacalności modeli lokalnych przy
obciążeniach z długim, powtarzanym kontekstem - rachunek trzeba policzyć od nowa.
*Źródła: Anthropic, cennik w dokumentacji platformy Claude, odczyt 24.09.2026; strona premiery
Claude Opus 5.5, 22.09.2026. Status: ceny i data premiery zostały potwierdzone u producenta; różnice
procentowe przeliczyliśmy w tej sesji.*
## 8. Model proponuje, kod decyduje
15 września TypeSafe AI wyszedł z trybu stealth z rundą 40 mln USD prowadzoną przez DCVC
i modelem Jev. To model klasy „System One”: przyjmuje nieustrukturyzowany stan i zwraca typowaną
decyzję z rozkładem prawdopodobieństwa - wybór z zamkniętej listy, ocenę według zdefiniowanych kryteriów albo
prawdopodobieństwo, że zdanie jest prawdziwe. Nie generuje tekstu. Producent podaje 70-500 ms
na całe zapytanie i cenę 42 USD za miliard tokenów wejścia.
W tydzień po premierze powstała fala otwartych implementacji tej samej idei, także do
uruchomienia lokalnie na Apple Silicon, oraz narzędzi na API, między innymi do kompaktowania
kontekstu asystentów kodujących. Najczęściej wskazywane zastosowania to trasowanie zapytań
i modeli, kontrola pobierania w RAG, przestawianie kolejności wyników, eskalacja do człowieka
i wybór kolejnego kroku agenta. Wspólny mianownik: to decyzje, nie teksty.
Nota inżynierska o budowie systemów na Jevie formułuje zasadę: model proponuje
gałąź, kod decyduje, czy wolno ją wykonać. Progi pewności zależą od konsekwencji decyzji -
etykieta niskiego ryzyka może przejść automatycznie, a publikacja, płatność, usunięcie danych
i wysyłka wiadomości wymagają kontroli deterministycznych, często zatwierdzenia przez człowieka.
Prawdopodobieństwo nigdy nie omija uprawnień, budżetów ani limitów.
**Co z tego wynika:** duża część tego, co agent robi między wywołaniami narzędzi, to decyzje,
za które płacimy dziś jak za pisanie. Ważniejsza od ceny jest jednak zasada podziału
odpowiedzialności - daje się zapisać jako wymaganie w architekturze agenta niezależnie od tego,
jaki model wybierzecie. To, że model nie generuje tekstu, wyklucza błędy typu, nie błędy osądu.
*Źródła: TypeSafe AI, komunikat z 15.09.2026 i strona produktu; nota robocza „Jev Engineering”,
wrzesień 2026. Status: runda, założyciele, cena i opóźnienie potwierdzone u producenta 24.09.2026
jako jego deklaracje; relacje użytkowników o kosztach i przyspieszeniach nie weszły do wpisu,
bo nie są zmierzone niezależnie.*
## 9. Decyzje typowane bez wysyłania danych
Demonstracja „Parallel Constrained Decoding” na Hugging Face pokazuje ten sam mechanizm w wersji
lokalnej. Silnik oparty na MLX ocenia wszystkie pola schematu JSON jednocześnie, zamiast
generować tokeny po kolei. Autor podaje pomiary na Apple M4 Max z modelem Qwen2.5-1.5B
w kwantyzacji czterobitowej: 75 ms zamiast 420 ms przy trasowaniu oszustw w fintechu i 68 ms
zamiast 380 ms przy audycie bezpieczeństwa kodu, w obu przypadkach dla czterech pól.
Przy schemacie z 28 polami przyspieszenie rośnie do około siedmiokrotnego. Do tego pełna
poprawność składniowa schematu i ocena pewności dla każdego pola.
Decyzję typowaną da się policzyć w całości na komputerze,
bez wysyłania treści do zewnętrznego API. To ścieżka dla danych, które nie mogą wyjść poza
organizację.
**Co z tego wynika:** przyspieszenie dotyczy mechaniki dekodowania, nie jakości osądu. Mały model
dostrojony do instrukcji to nie model wyspecjalizowany w decyzjach - czas i trafność trzeba
zmierzyć osobno, na przykładach z Waszego zastosowania.
*Źródło: „Parallel Constrained Decoding”, Hugging Face Spaces (drinkmoonshine), karta modelu
i README, odczyt 24.09.2026, licencja Apache 2.0. Status: liczby zgodne ze źródłem; to pomiary
autora demonstracji, niezależnie niepotwierdzone.*
## 10. Otwarte wagi, licencja badawcza
20 września zespół Qwen wydał Qwen-Image-2.1, jeden model do generowania i edycji obrazów.
Część wizualna ma 7 mld parametrów, enkoder tekstu to Qwen3-VL 8B, model obsługuje natywną
przezroczystość i do dziesięciu obrazów referencyjnych. Kwantyzacje przygotowane przez
społeczność uruchamiają go według autorów na karcie z 12 GB pamięci.
Licencja to Qwen Research License, która w klauzuli o zakresie użycia dopuszcza
wyłącznie cele niekomercyjne i wymaga osobnej licencji komercyjnej od producenta. Grafika
marketingowa, okładka wpisu czy ilustracja oferty są użyciem komercyjnym. Wyniki porównawcze publikuje sam zespół Qwen we własnym benchmarku - to nie jest pomiar niezależny, więc go nie przytaczamy.
**Co z tego wynika:** „otwarte wagi” nie znaczą, że decyzja o użyciu w firmie należy do Was.
Licencję czytamy przed testem, nie po wdrożeniu. To nie jest porada prawna - treść licencji
interpretuje prawnik.
*Źródła: karta modelu `Qwen/Qwen-Image-2.1` na Hugging Face, repozytorium QwenLM i plik licencji
(data wydania 20.09.2026), odczyt 24.09.2026. Status:
potwierdzone.*
## Jedno pytanie na ten tydzień
Z dziesięciu pozycji tego tygodnia wynika jeden krok do wykonania przed produkcją: przypisać
każdej decyzji agenta nazwanego właściciela. Nie zespołowi, nie dostawcy platformy, tylko osobie,
która wie, co agent może zrobić, może go zatrzymać i odpowiada za ślad jego działań. Brak takiej listy potrafi wyjść dopiero przy pierwszym audycie albo incydencie.
**Jak pomagamy:** w ofercie SNOK znajdziecie [ocenę bezpieczeństwa agentów AI](/pl/oferta/automatyzacja-ai/ai-security/), [ochronę SAP z SecurityBridge](/pl/oferta/bezpieczenstwo-sap/securitybridge/)
oraz [wdrożenia UiPath Maestro](/pl/oferta/automatyzacja-ai/uipath-maestro/).
[Porozmawiajmy o Waszym przypadku](/pl/kontakt/).
---
### Technologiczny Czwartek ze SNOK: SAP MDG, Reltio czy SNOK MDM - kto ma pilnować jednej prawdy o Waszych danych
URL: https://snok.ai/pl/aktualnosci/blog/sap-mdg-czy-reltio-snok-mdm/ | Data: 2026-09-24 | Seria: Technologiczny Czwartek
W firmach pracujących na SAP rozmowa o danych podstawowych często zaczyna się od pytania, czy kupić SAP Master Data Governance. Od 7 maja 2026 roku na stole leży jeszcze jedna nazwa: SAP sfinalizował wtedy przejęcie Reltio. SAP ma więc dziś w portfolio SAP MDG oraz Reltio, które pozostaje dostępne również jako oferta samodzielna. Obok nich stoi nasze rozwiązanie, SNOK MDM.
Na poziomie podstawowych funkcji - walidacja, nadzór nad zmianami, ślad audytowy - te rozwiązania mają ze sobą wiele wspólnego. Wybór rozstrzyga się więc gdzie indziej - w trzech pytaniach, które rzadko padają na pierwszym spotkaniu. Gdzie rozwiązanie może działać? Jakie dane obejmie? I jak szybko pokaże pierwszy wynik?
## SAP MDG - porządek wewnątrz SAP
SAP Master Data Governance akcentuje nadzór, czyli warstwę procesową: wnioski o zmianę danych, ścieżki akceptacji, reguły walidacji i ślad audytowy. Najlepiej sprawdza się tam, gdzie dane są tworzone i utrzymywane przede wszystkim w SAP.
Jeżeli cały krajobraz stoi na SAP S/4HANA, a priorytetem jest proces zmian prowadzony w SAP, SAP MDG powinien znaleźć się na krótkiej liście. Warunek jest jeden: gotowość na dyscyplinę procesu, którą to narzędzie wprowadza.
## Reltio - platforma SaaS, od maja w portfolio SAP
SAP opisuje Reltio jako rozwiązanie MDM projektowane od początku pod chmurę i pod sztuczną inteligencję, które ujednolica i porządkuje dane z wielu źródeł w czasie rzeczywistym. Obejmuje klientów, produkty, dostawców, lokalizacje i pracowników, zarówno w aplikacjach SAP, jak i spoza SAP. Po przejęciu Reltio staje się częścią SAP Business Data Cloud.
Sam producent przedstawia Reltio jako platformę SaaS w chmurze. To dobra wiadomość dla organizacji, które chcą kupić usługę, a nie utrzymywać infrastrukturę. Gorsza dla tych, których polityka bezpieczeństwa albo regulator wymagają, żeby dane podstawowe zostały we własnym środowisku.
## SNOK MDM - elastyczna alternatywa
SNOK MDM to nasze własne rozwiązanie do [zarządzania danymi podstawowymi](/pl/oferta/master-data-management/). Buduje rekord obowiązujący, czyli golden record, ponad systemami, które już działają, bez wymiany ERP. Obejmuje sześć domen w jednej platformie: pracowników, klientów, materiały, dostawców, produkty i konta finansowe. Gotowe konektory obsługują SAP S/4HANA i SAP ECC, a także Salesforce, Workday, Oracle Cloud ERP, Microsoft Dynamics 365 i Azure AD.
Najważniejsza różnica dotyczy miejsca działania. SNOK MDM może pracować on-premise, w Waszym środowisku chmurowym albo jako usługa - w modelu wielodostępnym z izolacją danych albo jako instancja dedykowana. Kod źródłowy może trafić do depozytu escrow, jeżeli wymaga tego polityka ciągłości działania.
Druga różnica to tempo. Pierwszą domenę uruchamiamy w cztery do ośmiu tygodni, przy stałej cenie za fazę i kryteriach odbioru ustalonych przed startem. Kolejne domeny dochodzą na tej samej platformie, gdy pierwszy wynik jest potwierdzony. Wasze dane i uzgodniony model danych zostają u Was.
## Trzy pytania, które rozstrzygają wybór
**Gdzie dane muszą zostać?** Jeżeli polityka bezpieczeństwa, audytor albo regulator wymagają, żeby dane podstawowe zostały w Waszej infrastrukturze, platforma dostępna jako SaaS nie spełni tego wymogu. SNOK MDM działa tam, gdzie wskażecie.
**Jakie dane ma objąć rozwiązanie?** Jeżeli wszystko powstaje w SAP, a priorytetem jest proces zmian w SAP, naturalnym kandydatem jest SAP MDG. Jeżeli dane żyją w SAP i poza nim, w kilku domenach naraz, porównujcie Reltio i SNOK MDM.
**Jak szybko potrzebujecie wyniku i jak chcecie za niego płacić?** Program platformowy rozliczany subskrypcją to inna decyzja niż pierwsza domena w działaniu po kilku tygodniach, rozliczana stałą ceną za fazę.
Jeżeli po tych pytaniach okaże się, że lepszym wyborem jest SAP MDG, powiemy to wprost. Rozwiązania mogą też działać razem: SAP MDG pilnuje zmian w SAP, a SNOK MDM składa rekord z systemów spoza SAP i oddaje go z powrotem do SAP.
*SNOK MDM i Reltio - porównanie na podstawie publicznych opisów producentów, wrzesień 2026*
## Gdzie dane podstawowe wychodzą poza SAP
Najciekawsze przypadki zaczynają się tam, gdzie obowiązek dotyczy rekordu, który w SAP jest tylko w części.
**Łańcuch dostaw pod ustawę o KSC.** Podmioty kluczowe i ważne, które nie są wpisywane do wykazu z urzędu, powinny złożyć wniosek o wpis do 3 października 2026 roku. Znowelizowana ustawa wdraża dyrektywę NIS2 i wymaga także zarządzania bezpieczeństwem łańcucha dostaw. Tymczasem dostawca usług informatycznych rzadko jest jednym rekordem: umowa leży w dziale IT, kartoteka w ERP, ocena w arkuszu zespołu bezpieczeństwa. [Jeden rekord dostawcy](/pl/aktualnosci/blog/jeden-dostawca-piec-nazw-dane-dostawcow-w-zakupach/) z hierarchią właścicielską i historią weryfikacji porządkuje to, zanim zapyta audytor - a przy danych o bezpieczeństwie łańcucha dostaw możliwość wdrożenia on-premise przestaje być szczegółem technicznym. Jeżeli nie wiecie jeszcze, czy ustawa Was obejmuje, zacznijcie od naszego [bezpłatnego testu KSC](/pl/narzedzia/ksc-check/).
**ESG i łańcuch wartości.** W części raportów i ocen ESG potrzebne są dane z łańcucha wartości, także pozyskiwane od dostawców. Ankieta często trafia do nich, zanim ktokolwiek ustali, ilu ich naprawdę jest. Ten sam kontrahent zapisany pięć razy dostaje pięć ankiet i pięć razy odpowiada - albo nie odpowiada wcale.
**Produkt.** Indeks materiałowy żyje w SAP, ale skład, pochodzenie surowca czy dane do cyfrowego paszportu produktu przychodzą od dostawców i z systemu konstrukcyjnego. Rekord produktu z informacją, skąd pochodzi każde pole, zasila SAP, zamiast z nim konkurować.
**HR.** Ta sama osoba istnieje w systemie kadrowo-płacowym, w SAP, w katalogu uprawnień i w systemie szkoleń. Niespójna dezaktywacja danych po odejściu pracownika może pozostawić aktywne konto w jednym z tych systemów. Jeden rekord osoby jako źródło dla nadawania i odbierania dostępu to temat danych podstawowych i bezpieczeństwa jednocześnie.
## Od czego zacząć
Od pomiaru, nie od wyboru narzędzia. Na próbce z jednej domeny pokazujemy, ile rekordów opisuje ten sam podmiot, ile pozycji ma braki w polach krytycznych i gdzie powstają rozbieżności między systemami. Skalę tego zjawiska w polskich firmach opisaliśmy w [raporcie o danych podstawowych w polskich przedsiębiorstwach](/pl/aktualnosci/blog/dane-podstawowe-w-polskich-przedsiebiorstwach-raport/).
Więcej o platformie przeczytacie na stronie [SNOK MDM](/pl/produkty/snok-mdm/). Szerszą [analizę zmian na rynku MDM po przejęciach](/pl/aktualnosci/blog/sap-mdg-vs-informatica-mdm-po-przejeciach/) znajdziecie w naszym wpisie z sierpnia. Jeżeli chcecie sprawdzić, które rozwiązanie pasuje do Waszego krajobrazu, [porozmawiajmy](/pl/kontakt/).
## Najczęstsze pytania
**Czym różnią się SAP MDG i Reltio?**
SAP MDG to nadzór nad tworzeniem i zmianą danych podstawowych w procesach SAP: wnioski o zmianę, akceptacje, walidacje i ślad audytowy. Reltio to platforma MDM w modelu SaaS, która ujednolica dane z wielu źródeł, w aplikacjach SAP i spoza SAP. Od 7 maja 2026 roku oba produkty należą do SAP, a Reltio pozostaje dostępne również samodzielnie.
**Czym SNOK MDM różni się od Reltio?**
Oba rozwiązania obejmują dane z SAP i spoza SAP w wielu domenach. Reltio producent opisuje jako platformę SaaS w chmurze. SNOK MDM może działać on-premise, w środowisku chmurowym klienta albo jako usługa, z możliwością depozytu kodu w escrow, a pierwszą domenę uruchamia w cztery do ośmiu tygodni przy stałej cenie za fazę.
**Czy SNOK MDM można wdrożyć on-premise?**
Tak. SNOK MDM może pracować w infrastrukturze organizacji, w jej środowisku chmurowym albo jako usługa, w modelu wielodostępnym z izolacją danych lub jako instancja dedykowana. Miejsce przetwarzania ustalamy przed startem projektu.
**Jakie domeny danych obejmuje SNOK MDM?**
Sześć domen w jednej platformie: pracowników, klientów, materiały, dostawców, produkty i konta finansowe. Każda domena ma własny schemat danych, reguły walidacji i przepływ akceptacji.
**Czy SAP MDG, Reltio i SNOK MDM mogą działać razem?**
Tak. SAP MDG może pilnować procesu zmian w SAP, a warstwa MDM ponad systemami składać rekord z systemów spoza SAP i oddawać go do SAP.
## Źródła
- SAP, *SAP to Acquire Reltio: Make SAP and Non-SAP Data AI-Ready*, 27.03.2026, [news.sap.com](https://news.sap.com/2026/03/sap-to-acquire-reltio/)
- SAP, *SAP Completes Acquisition of Reltio*, 07.05.2026, [news.sap.com](https://news.sap.com/2026/05/sap-completes-acquisition-of-reltio/)
- Reltio, *The Reltio Data Cloud*, [reltio.com](https://www.reltio.com/data-cloud/)
- Ministerstwo Cyfryzacji, *Miesiąc na samorejestrację w wykazie KSC - termin mija 3 października*, 03.09.2026, [gov.pl](https://www.gov.pl/web/baza-wiedzy/miesiac-na-samorejestracje-w-wykazie-ksc-termin-mija-3-pazdziernika)
- SAP, dokumentacja SAP Master Data Governance, [help.sap.com](https://help.sap.com/docs/SAP_MASTER_DATA_GOVERNANCE)
---
### Analiza gotowości do SAP S/4HANA - czego nie pokaże Readiness Check
URL: https://snok.ai/pl/aktualnosci/blog/analiza-gotowosci-s4hana-readiness-check/ | Data: 2026-09-23 | Seria: Inne
**SAP Readiness Check** dla konwersji do **SAP S/4HANA** kończy się zwykle tak samo. Zespół Basis uruchamia kolektory, wynik ląduje na SAP for Me, ktoś eksportuje dokument i wysyła go dalej z jednym zdaniem: „mamy analizę gotowości”. Na komitecie sterującym pada wtedy pytanie o termin, budżet i o to, co w trakcie programu przestanie działać. Raport nie odpowiada na żadne z tych trzech pytań, bo nie po to powstał.
To nie jest zarzut wobec narzędzia. SAP Readiness Check robi dokładnie to, co obiecuje: opisuje stan techniczny systemu źródłowego i wskazuje pozycje, którymi trzeba się zająć. Problem zaczyna się w momencie, gdy raport techniczny zaczyna pełnić funkcję oceny gotowości organizacji do programu, a te dwie rzeczy dzieli kilka miesięcy pracy i kilka decyzji, których żadne narzędzie za Was nie podejmie.
**W skrócie:**
**1/** SAP Readiness Check for SAP S/4HANA to szesnaście analiz, a podstawą najważniejszej z nich jest zawartość tabel i wykaz używanych transakcji - narzędzie widzi więc ślad po pracy systemu, nie sposób, w jaki korzysta z niego firma,
**2/** trzy rodzaje znalezisk zatrzymują konwersję, zanim ją zaczniecie, a jedno z nich SAP każe zgłosić jako incydent, bo nie da się go rozwiązać po Waszej stronie,
**3/** czterech odpowiedzi w raporcie nie ma w ogóle: o uprawnieniach, o koszcie licencyjnym modelu docelowego, o realnym przestoju w Waszym krajobrazie i o jakości danych poza finansami,
**4/** sam SAP w kilku miejscach odsyła do człowieka, opisując część pozycji jako wymagające oceny eksperta - i to jest najuczciwszy fragment całego dokumentu.
## Co SAP Readiness Check mierzy naprawdę
Scenariusz konwersyjny obejmuje szesnaście analiz. Dla porządku warto je pogrupować, bo w dokumencie leżą jedna obok drugiej i wszystkie wyglądają na równie ważne.
**Zgodność, czyli co zablokuje start:** elementy uproszczenia, analiza zakresu zgodności, aktywne funkcje biznesowe, zgodność dodatków. **Wysiłek, czyli ile pracy przed Wami:** działania powiązane z elementami uproszczenia, analiza kodu własnego, integracja, dostępność aplikacji i rekomendowane aplikacje SAP Fiori. **Dane:** jakość danych finansowych, integracja klientów i dostawców z rekordem Business Partner, szacowanie wielkości systemu docelowego. **Reszta:** kalkulator planowanego przestoju, odkrywanie procesów biznesowych, możliwości SAP Business AI oraz rozwiązania SAP Innovative Business Solutions.
Najważniejsza jest jedna linijka z dokumentacji SAP, którą łatwo przeoczyć. Dla elementów uproszczenia kontrola opiera się przede wszystkim na zawartości tabel i używanych transakcjach. To znaczy, że narzędzie rozpoznaje moduł, który zostawił dane, i transakcję, którą ktoś uruchomił. Nie rozpozna procesu, który u Was działa na obejściu w Excelu, ani modułu, który kupiliście i wdrożyliście w jednej spółce na piętnaście. Raport pokaże Wam odcisk systemu, a nie mapę firmy.
Druga rzecz, którą warto docenić: SAP nie udaje, że liczy wszystko. Ranking pracochłonności przy elemencie uproszczenia przyjmuje wartości od niskiej do wysokiej **albo wprost oznacza, że pozycja wymaga oceny eksperta**. Czynniki pracochłonności są z kolei porównaniem Waszego systemu do wartości referencyjnych zebranych z wcześniejszych projektów SAP S/4HANA. To użyteczna wskazówka i kiepska podstawa budżetu, bo referencją jest cudzy program, nie Wasz.
## Zanim powstanie raport
Jeżeli raportu jeszcze nie macie, droga jest krótsza, niż się wydaje, i nie wymaga zamówienia usługi. SAP Readiness Check jest dostępny w dwóch miejscach: na SAP for Me dla wszystkich klientów z aktywną umową utrzymaniową, pod adresem me.sap.com/readinesscheck, oraz w SAP Cloud ALM dla tych, którzy mają tenant tej usługi. Procedura prowadzona krok po kroku przygotowuje system i uruchamia kolektory, a po zebraniu danych zakładacie nową analizę na stronie startowej narzędzia.
Dwie rzeczy warto ustawić od razu. Po pierwsze, analizę robi się na systemie produkcyjnym - to jego dane opisują rzeczywisty zakres programu, a nie zawartość systemu jakościowego, w którym połowa modułów nigdy nie pracowała na prawdziwych wolumenach. Po drugie, wyniki różnych scenariuszy uruchomionych na tym samym systemie da się połączyć w jedną analizę, co ma znaczenie wszędzie tam, gdzie obok konwersji stoi SAP BW/4HANA albo profilowanie użycia SAP ERP.
Raport starszy niż rok warto uruchomić jeszcze raz przed startem programu. Lista analiz rośnie z każdym wydaniem narzędzia, a w międzyczasie zmienia się także Wasz system - jeżeli w tym czasie ktoś aktywował funkcję biznesową albo dołożył dodatek, poprzedni wynik opisuje krajobraz, którego już nie ma.
## Trzy znaleziska, które zatrzymują konwersję, zanim się zacznie
Pierwsze to **niezgodny dodatek**. Dokumentacja SAP mówi wprost, że niezgodne dodatki zablokują konwersję podczas pracy Software Update Manager. Narzędzie przypisuje dodatkom kategorie: zgodny, niezgodny, niezgodny bez możliwości odinstalowania oraz nieznany. Ta ostatnia kategoria jest najciekawsza, bo raport jej nie zamyka - trafiają do niej przede wszystkim rozwiązania partnerskie, a odpowiedź, czy dostawca wyda wersję pod docelowe wydanie SAP S/4HANA, musicie uzyskać sami. Im wcześniej, tym lepiej, bo wykreślenie dodatku z krajobrazu bywa osobnym projektem.
Drugie to **aktywna funkcja biznesowa niezgodna z wydaniem docelowym**. Tutaj SAP jest jeszcze bardziej stanowczy: taka funkcja zablokuje konwersję systemu, a zalecana ścieżka to zgłoszenie incydentu w komponencie tej funkcji i rozmowa z SAP. Nie ma tu miejsca na obejście po stronie zespołu projektowego, więc pozycja z tej listy powinna wyjść na komitet w pierwszym tygodniu, a nie w fazie przygotowania cutoveru.
Trzecie to **elementy uproszczenia oznaczone jako wymagające oceny eksperta**. To nie jest kategoria awaryjna, tylko sygnał, że narzędzie zrobiło, co mogło. Zwykle chodzi o obszary, w których zmiana modelu danych spotyka się z Waszą konfiguracją: rachunkowość, gospodarka materiałowa, sprzedaż z rozbudowanym własnym kodem. Każda taka pozycja to osobna rozmowa z osobą, która zna ten obszar w Waszej firmie.
Dobra wiadomość jest taka, że wszystkie trzy da się rozstrzygnąć przed startem programu, bez uruchamiania konwersji. Zła, że średnio nikt tego nie robi, bo raport wygląda na dokument do przeczytania, a nie do przepracowania.
## Cztery odpowiedzi, których w tym raporcie nie ma
**Uprawnienia, podział obowiązków i konta techniczne.** Lista analiz jest zamknięta i publiczna, a nie ma na niej ani jednej pozycji o rolach, uprawnieniach, kontach serwisowych czy ekspozycji systemu. Konwersja przebudowuje model autoryzacji, dokłada aplikacje SAP Fiori z własnymi katalogami i grupami, a przy okazji na kilkanaście miesięcy otwiera w programie dostępy, których w normalnym trybie nikt by nie nadał. Raport o tym nie powie ani słowa. Opisaliśmy to osobno we wpisie [Bezpieczna konwersja do SAP S/4HANA](/pl/aktualnosci/blog/bezpieczna-konwersja-sap-s4hana-rise/), bo to materiał na własny tekst, a nie na akapit.
**Koszt licencyjny modelu docelowego.** Analiza zakresu zgodności mówi o pakietach zgodności, czyli o **ograniczonych prawach użytkowania** klasycznych rozwiązań SAP ERP na SAP S/4HANA, i pokazuje, które z nich mają następcę. Nie mówi natomiast, ile zapłacicie po konwersji ani jak zmieni się Wasz rachunek licencyjny, gdy część użytkowników przejdzie na przelicznik Full Use Equivalent. To osobna analiza, którą robi się na danych o rzeczywistym użyciu, a nie na wyniku kolektora - patrz [audyt licencji SAP](/pl/oferta/bezpieczenstwo-sap/audyt-licencji-sap/).
**Realny przestój w Waszym krajobrazie.** Kalkulator planowanego przestoju jest w raporcie, ale nosi założenie napisane wprost: podane czasy dotyczą standardowej konwersji przez Software Update Manager w obrębie jednego centrum danych. Czasy faz pochodzą z doświadczeń innych klientów i pomiarów na podobnych systemach. Jeżeli macie replikację między ośrodkami, okno serwisowe wynegocjowane z biznesem albo integracje, które nie zniosą kilkunastu godzin ciszy, ten wynik jest punktem wyjścia do planu, a nie planem. Skrócić przestój da się dwiema drogami: wariantem downtime-optimized conversion oraz archiwizacją i porządkami zrobionymi przed programem, nie w jego trakcie.
**Jakość danych poza finansami.** Raport sprawdza księgę główną, środki trwałe i material ledger, przypisując niespójnościom kategorie od automatycznej korekty, przez korektę ręczną i kontakt z SAP, po korektę specyficzną dla systemu. Sprawdza też synchronizację klientów, dostawców i osób kontaktowych z rekordem Business Partner, bo bez niej konwersja nie przejdzie. I na tym kończy się temat danych. Duplikaty w danych podstawowych materiałów, niespójne indeksy, trzy wersje tego samego kontrahenta w trzech spółkach - tego nikt tu nie policzy, a to właśnie ten materiał wywraca testy akceptacyjne.
## Jak przeczytać ten raport w tydzień
Kolejność ma znaczenie, bo dokument jest ułożony tematycznie, a program potrzebuje ułożenia decyzyjnego.
**Dzień pierwszy: blokery.** Dodatki niezgodne i nieznane, aktywne funkcje biznesowe, elementy z oceną eksperta. Z tego powstaje lista pytań na zewnątrz - do dostawców rozwiązań partnerskich i do SAP. Odpowiedzi przychodzą tygodniami, więc to musi wyjść pierwsze.
**Dzień drugi i trzeci: kod własny.** Wynik analizy kodu ma sens dopiero wtedy, gdy wiecie, co z tego kodu jest realnie używane. Informację o zakresie, czyli podział na kod w zakresie i poza zakresem, raport pokazuje **tylko wtedy**, gdy uruchomiliście aplikację SAP Fiori Custom Code Migration. Bez niej dostajecie listę znalezisk bez wagi, a różnica bywa taka, że połowa obiektów nie była ruszana od lat i idzie do usunięcia zamiast do przepisania. Przy okazji warto sprawdzić, ile znalezisk ma automatyczną poprawkę, bo to realnie zmienia wycenę. Tę część łączymy zwykle z analizą podatności w kodzie własnym przez [SAP Code Vulnerability Analyzer](/pl/oferta/bezpieczenstwo-sap/sap-code-vulnerability/), żeby nie robić dwóch przebiegów po tym samym kodzie.
**Dzień czwarty: dane.** Niespójności finansowe według kategorii, stan przejścia na Business Partner, potencjał archiwizacji z zakładki wielkości systemu. Tu zapada decyzja, czy porządki robicie przed konwersją, czy godzicie się przenieść bałagan na nową platformę i zapłacić za niego pamięcią.
**Dzień piąty: integracje i przestój.** Inwentarz interfejsów - IDoc, RFC i BAPI, usługi sieciowe, OData, ekstraktory SAP BW, pliki, konfiguracje SLT - zestawiony z listą systemów, których właściciele siedzą poza IT. Do tego kalkulator przestoju skonfrontowany z oknem, na które zgodzi się biznes.
Dopiero z tym materiałem warto iść na komitet, bo wtedy rozmowa przestaje być o raporcie, a zaczyna być o zakresie, terminie i pieniądzach. Kolejny etap, czyli jak ułożyć sam program konwersji, opisaliśmy we wpisie [jak przygotować się do konwersji systemu SAP ERP do S/4HANA](/pl/aktualnosci/blog/technologiczny-czwartek-ze-snok-jak-przygotowac-sie-do-konwersji-systemu-sap-erp/), a warstwę testową - we wpisie o [testach SAP przy konwersji i przed go-live](/pl/aktualnosci/blog/testy-sap-uipath-test-cloud-konwersja-go-live/).
## Termin, którego nikt nie przesunie
Utrzymanie standardowe dla SAP Business Suite 7 kończy się 31 grudnia 2027 roku, a utrzymanie rozszerzone trwa do końca 2030 roku i kosztuje dodatkowe dwa punkty procentowe do podstawy utrzymania. Firma, która dzisiaj ma raport SAP Readiness Check i nie ma rozstrzygniętych blokerów, ma przed sobą kilkanaście miesięcy na decyzje, które wymagają rozmów z dostawcami dodatków i z SAP. To wystarczy pod warunkiem, że raport zostanie przepracowany teraz, a nie wtedy, gdy program dostanie już budżet i datę go-live.
## Co robimy w SNOK
Analizę gotowości prowadzimy jako pracę na Waszym raporcie, nie zamiast niego. Uruchamiamy kolektory tam, gdzie ich jeszcze nie uruchomiono, przechodzimy pozycję po pozycji przez blokery, kod własny i dane, dokładamy warstwę, której w raporcie nie ma - uprawnienia, ekspozycję i koszt modelu docelowego - i wychodzimy z listą decyzji na komitet zamiast z dokumentem do przeczytania. Zakres i sposób pracy opisuje strona [konwersja do SAP S/4HANA](/pl/oferta/bezpieczenstwo-sap/konwersja-s4hana/).
Jeżeli macie już wynik SAP Readiness Check i nie wiecie, co z nim zrobić, [napiszcie do nas](/pl/kontakt/). Przejdziemy go z Waszym zespołem Basis i z osobą odpowiedzialną za budżet programu, bo to są dwie różne rozmowy i obie trzeba odbyć.
---
### Źródła
- SAP, *SAP Readiness Check - Key Feature Overview*, SAP Readiness Check Team, kwiecień 2026, dokument publiczny - [help.sap.com](https://help.sap.com/doc/bb0e7ba5158c424ab7ce010228bf1de1/latest/en-US/Key%20Feature%20Overview%20SAP%20Readiness%20Check.pdf) (dostęp 22 września 2026)
- SAP Note 2913617, *SAP Readiness Check for SAP S/4HANA* - nota centralna scenariusza, dostęp po zalogowaniu w [me.sap.com](https://me.sap.com/notes/2913617)
- SAP Note 3344480, *SAP Readiness Check Deployment Options* - dostęp po zalogowaniu w [me.sap.com](https://me.sap.com/notes/3344480)
- SAP, *Maintenance strategy - SAP S/4HANA and SAP Business Suite 7* - [support.sap.com](https://support.sap.com/en/release-upgrade-maintenance/maintenance-information/maintenance-strategy/s4hana-business-suite7.html) (dostęp 22 września 2026)
Opisujemy zakres narzędzia za dokumentacją SAP z kwietnia 2026 roku. SAP rozwija SAP Readiness Check wydaniami, więc przed oparciem decyzji na tym tekście sprawdźcie aktualną listę analiz w nocie 2913617.
---
### SAPMAP - atakujący dostał właśnie mapę Waszego SAP
URL: https://snok.ai/pl/aktualnosci/blog/sapmap-bloodhound-dla-sap/ | Data: 2026-09-22 | Seria: Bezpieczny Wtorek
Kiedy zespół bezpieczeństwa patrzy na krajobraz SAP, widzi listę systemów. **SAPMAP** patrzy na to samo i widzi drogę. To publicznie dostępne, otwarte narzędzie na licencji GPL robi dla SAP dokładnie to, co jego autorzy sami deklarują w opisie - „jak BloodHound dla Active Directory, tylko dla SAP”: nie wylicza pojedynczych podatności, tylko rysuje ścieżkę - od jednego wystawionego systemu, przez połączenia zaufania, aż do miejsca, w którym stoją Wasze pieniądze.
Autorstwo narzędzia **SecurityBridge**, z którym SNOK współpracuje, przypisuje swojemu dyrektorowi badań bezpieczeństwa, Jorisowi van de Vis. Kod jest dziś otwarty i dostępny dla każdego. To zmienia nie tyle technikę, ile symetrię: mapę, którą do tej pory rysował ekspert w autoryzowanym teście, ma teraz również ten, kto autoryzacji nie ma.
**W skrócie:**
**1/** SAPMAP odkrywa systemy SAP w sieci, mapuje połączenia RFC (techniczne kanały, którymi systemy SAP rozmawiają ze sobą i przekazują sobie zaufanie) i relacje zaufania, a następnie renderuje interaktywny graf - od pierwszego wejścia do pełnej kontroli nad procesem biznesowym,
**2/** narzędzie zawiera realne, działające exploity znanych podatności SAP, w tym CVE-2025-31324, i obejmuje zarówno systemy lokalne, jak i SAP BTP,
**3/** modeluje scenariusze wpływu na biznes - od wycieku danych klientów, przez listę płac, po łańcuch dostaw - czyli pokazuje nie „który system padł”, tylko „co realnie tracicie”,
**4/** dostęp jest otwarty, ale użycie wyłącznie za pisemną zgodą właściciela systemu - poza autoryzowanym testem jest nielegalne.
## Czym jest BloodHound i dlaczego to porównanie ma znaczenie
Krótkie wyjaśnienie, bo nie każdy pracuje w cyberbezpieczeństwie na co dzień. BloodHound to narzędzie, które od lat jest standardem w pracy zespołów ofensywnych. W sieci opartej na Windowsie i Active Directory pokazuje najkrótszą drogę od zwykłego konta pracownika do konta administratora całej domeny - nie jako listę błędów, tylko jako graf połączeń. Zmieniło sposób, w jaki firmy patrzą na własną sieć: przestały pytać „które konto ma za dużo uprawnień”, a zaczęły pytać „którędy ktoś przejdzie od dowolnego pracownika do pełnej kontroli”. SAPMAP przenosi dokładnie tę ideę do świata SAP.
## Dlaczego to moment BloodHound, a nie kolejny skaner
Skanery bezpieczeństwa SAP istnieją od lat i robią rzecz cenną: mówią, że system X ma otwarty gateway, a rola Y ma za szerokie uprawnienia. Odpowiadają na pytanie „co jest nie tak”. Nie odpowiadają na pytanie, które zadaje sobie napastnik: „którędy stąd dojdę do celu”.
Krajobraz SAP to nie zbiór osobnych systemów, tylko sieć zaufania. Połączenia RFC, konta techniczne o wysokich uprawnieniach, integracje między produkcją a rozwojem, mosty do chmury - każde z nich jest krawędzią w grafie. Atakujący nie potrzebuje włamać się wszędzie. Potrzebuje jednego wejścia i drogi, która stamtąd prowadzi. SAPMAP tę drogę rysuje, a scenariusze biznesowe pokazują, co czeka na jej końcu. Nie „system produkcyjny został skompromitowany”, tylko „przelew do dostawcy trafił na inny rachunek”.
To jest różnica między raportem, który zarząd odkłada, a raportem, który zarząd czyta do końca.
Pisaliśmy niedawno, że [agent AI potrafi stanąć po obu stronach ataku](/pl/aktualnosci/blog/agent-ai-po-obu-stronach-ataku/) i że [najgroźniejsze bywa martwe pole, którego nikt nie monitoruje](/pl/aktualnosci/blog/wyciek-danych-sap-martwe-pole/). SAPMAP jest tego samego rzędu: nie dokłada nowej podatności, tylko czyni widoczną drogę, która była tam od zawsze.
## Co to znaczy dla obrony
Jest prosta zasada, którą powtarzamy klientom: kontroli nie mierzy się tym, że narzędzia atakującego są trudno dostępne. Mierzy się tym, czy przeszliście tę samą ścieżkę pierwsi. Skoro mapa jest publiczna, jedyna sensowna odpowiedź to zejść z poziomu „które systemy mają luki” na poziom „którędy biegnie najkrótsza droga do naszych pieniędzy - i czy ją widzimy, gdy ktoś nią idzie”.
W SNOK robimy to jako **autoryzowany SAP attack-path assessment**, spinając trzy warstwy.
**Mapowanie ścieżki.** Tę samą klasę narzędzi, którą teraz ma napastnik, uruchamiamy w kontrolowanym labie, na Waszym krajobrazie, w reżimie autoryzowanego testu. Efektem nie jest lista podatności, tylko graf: skąd, którędy, dokąd i co jest na końcu.
**Detekcja.** SAPMAP wizualizuje ścieżkę, a [SecurityBridge](/pl/aktualnosci/blog/trustbroker-5-1-sso-mfa-sap-bez-active-directory/) - platforma, z którą pracujemy - tę ścieżkę widzi w czasie rzeczywistym i alarmuje. Mapa bez czujnika mówi, gdzie jest ryzyko. Czujnik bez mapy mówi, że coś się dzieje, ale nie wie, dokąd to prowadzi. Dopiero razem dają obraz, który da się obronić przed audytorem.
**Red team z lokalnymi modelami AI.** Fazę ofensywną prowadzimy na stacjach z nieograniczonymi, lokalnymi modelami AI, uruchomionymi w izolowanym środowisku. Ma to dwie konsekwencje, które w tego typu pracy są nienegocjowalne. Po pierwsze, dane z Waszego SAP nie opuszczają labu - nie trafiają do żadnego zewnętrznego API, bo model działa na miejscu. Po drugie, modele komercyjne odmawiają współpracy przy analizie działających exploitów, a analiza exploitu to sedno pracy red teamu; model lokalny bez tych ograniczeń pozwala tę pracę wykonać, nie wynosząc niczego na zewnątrz. Całość idzie pod umową o poufności i w ramach naszego systemu zarządzania bezpieczeństwem informacji zgodnego z ISO 27001.
## Co konkretnie robimy dla bezpieczeństwa SAP
Attack-path assessment to jeden element. Bezpieczeństwo SAP układamy u Was w dwie ręce, które muszą pracować razem: rękę ofensywną, która szuka drogi, i rękę obronną, która tę drogę zamyka i pilnuje.
Po stronie ofensywnej:
**1/** attack-path assessment - mapowanie ścieżek eskalacji w całym krajobrazie SAP, od wystawionego systemu do procesu biznesowego,
**2/** [pentesty SAP](/pl/oferta/bezpieczenstwo-sap/pentesty-sap/) - testy penetracyjne systemów, interfejsów RFC, bram i integracji, zakończone dowodem możliwości, nie samą listą podatności,
**3/** red team - symulacja realnego napastnika na Waszym krajobrazie, z fazą ofensywną na lokalnych modelach AI, których dane nie opuszczają labu.
Po stronie obronnej:
**4/** utwardzanie konfiguracji i ról - domknięcie tego, co assessment odsłonił: bramy, konta techniczne, uprawnienia, granice zaufania między systemami,
**5/** [monitoring i detekcja z SecurityBridge](/pl/oferta/bezpieczenstwo-sap/securitybridge/) - stały nadzór nad tym, co dzieje się w SAP w czasie rzeczywistym, z alarmem na ruch po ścieżce ataku,
**6/** [zarządzanie łatkami i SAP Security Patch Day](/pl/oferta/bezpieczenstwo-sap/sap-security-patch-day/) - od oceny nowych not po wdrożenie, żeby okno między publikacją a naprawą było jak najkrótsze,
**7/** [bezpieczna konwersja do SAP S/4HANA i RISE](/pl/oferta/bezpieczenstwo-sap/konwersja-s4hana/) - pilnowanie powierzchni ataku w trakcie migracji, gdy krajobraz jest najbardziej odsłonięty,
**8/** [audyt i zgodność](/pl/oferta/bezpieczenstwo-sap/audyt-nis2-dora/) - przygotowanie do wymagań NIS2, DORA oraz normy ISO 27001, z dowodami wytworzonymi zanim padnie pytanie audytora, nie po nim.
## Jedno pytanie na ten tydzień
Nie „czy mamy luki w SAP”, bo je macie, wszyscy je mają. Pytanie brzmi: gdyby ktoś pobrał dziś publiczną mapę i wskazał palcem najkrótszą drogę od Waszego najbardziej wystawionego systemu do listy płac - potrafilibyście narysować tę samą drogę wcześniej i zobaczyć ją, gdy ktoś nią idzie? Jeśli odpowiedź nie jest pewna, to jest dokładnie ta rozmowa, którą warto odbyć, zanim odbędzie ją za Was ktoś inny.
[Napiszcie do nas](/pl/kontakt/) - pokażemy, jak wygląda attack-path assessment na realnym krajobrazie SAP.
---
## Źródła
- SAPMAP, repozytorium [SecuritySilverbacks/SAPMAP](https://github.com/SecuritySilverbacks/SAPMAP), licencja GPL-3.0 (dostęp 21.09.2026).
- SecurityBridge, materiały prasowe o SAPMAP oraz relacje branżowe (securitybrief.com.au, itbrief), lipiec 2026.
---
### UiPath liderem Gartner Magic Quadrant dla BOAT - nowa kategoria i wysoko ustawiona poprzeczka
URL: https://snok.ai/pl/aktualnosci/blog/uipath-lider-gartner-magic-quadrant-boat/ | Data: 2026-09-20 | Seria: Ogłoszenia
Raport analityczny czyta się zwykle w jeden sposób: sprawdzamy, kto jest w prawym górnym rogu, i zamykamy plik. Przy **Gartner Magic Quadrant for Business Orchestration and Automation Technologies** z **14 września 2026** warto zostać dłużej, bo najciekawsza jest sama kategoria. Gartner nazwał warstwę, która spina agentów AI, roboty, systemy i ludzi w jeden zarządzany przebieg, i zmierzył dostawców właśnie tą miarą.
Liczby są proste. Gartner ocenił **dwudziestu dostawców**. W ćwiartce liderów znalazły się cztery firmy: **Pega, Appian, UiPath i ServiceNow**. Autorami raportu są Saikat Ray, Arthur Villa, Sachin Joshi, Adam Briggs, Tushar Srivastava i Mike Warren.
**W skrócie:**
**1/** BOAT to nowa nazwa całej kategorii, a nie nowa nazwa na RPA - Gartner wymaga od platformy natywnej orkiestracji agentów AI, nadzoru nad nimi i koordynacji wielu agentów naraz,
**2/** poprzeczka wejścia jest wysoka także po stronie biznesu: setki płacących klientów, co najmniej dwudziestu partnerów wdrożeniowych oraz obecność w wielu branżach i regionach,
**3/** Gartner wyróżnia w platformie UiPath trwałe wykonanie procesu w **UiPath Maestro** - stan procesu przeżywa awarię infrastruktury, a proces można zatrzymać, cofnąć, odtworzyć i zmigrować w trakcie działania,
**4/** kierunek rynku raport nazywa wprost: do 2030 roku **70% przedsiębiorstw** ma pracować na skonsolidowanej platformie orkiestrującej procesy, agentów, roboty, API i ludzi.
*Rysunek 1 z raportu: Gartner, Magic Quadrant for Business Orchestration and Automation Technologies, 14 września 2026. Publikujemy go w oryginale, bez zmian.*
---
## Czym jest BOAT i dlaczego ta kategoria powstała
Skrót rozwija się jako Business Orchestration and Automation Technologies. Gartner opisuje tę kategorię jako skonsolidowaną platformę, która orkiestruje i automatyzuje rozproszone procesy oraz zadania o różnym stopniu autonomii i złożoności, w wielu systemach przedsiębiorstwa naraz. Kluczowe są dwa słowa: skonsolidowana i rozproszone. Automatyzacja zadań rozeszła się w firmach po kilkunastu narzędziach, a BOAT jest odpowiedzią na pytanie, kto to wszystko prowadzi.
Warunek wejścia jest ostry. Platforma musi mieć **natywną orkiestrację agentów AI, nadzór nad nimi, zarządzanie ich cyklem życia i koordynację wielu agentów**. Musi obsługiwać interoperacyjność agentów przez otwarte protokoły, w tym Model Context Protocol i Agent2Agent. Musi prowadzić długotrwałe procesy ze stanem, łączyć się przez API i zdarzenia, emulować pracę człowieka w interfejsie oraz dawać warstwę nadzoru nad całością. To jest lista, która odsiewa narzędzia do pojedynczych zadań.
Do progu funkcjonalnego dochodzi twarda arytmetyka biznesowa. Dostawca musi wykazać co najmniej **300 płacących klientów** ocenianego produktu albo 10 000 klientów łącznie, albo **45% wzrostu przychodu rok do roku** w tym obszarze. Musi też pokazać **co najmniej dwudziestu partnerów wdrożeniowych** oraz obecność w dwóch branżach i dwóch regionach świata. Ten ostatni warunek mówi o rynku więcej, niż wygląda: Gartner traktuje dostępność partnerów jako część produktu, bo platforma tej klasy wchodzi do firmy razem z zespołem, który ją zna.
Skalę zmiany raport nazywa wprost. Założenie planistyczne Gartnera mówi, że **do 2030 roku 70% przedsiębiorstw** przejdzie na skonsolidowaną platformę orkiestrującą procesy, agentów AI, roboty, API i działania ludzi - wobec **10% dzisiaj**. Sam rynek BOAT ma według tego szacunku przekroczyć **34 mld USD do 2030 roku**. To nie jest nisza, tylko kierunek, w którym idzie automatyzacja w przedsiębiorstwie.
## Za co Gartner wyróżnia UiPath
Platformą ocenianą jest **UiPath Platform**, a w opisie mocnych stron wracają trzy wątki.
**Innowacyjność.** Gartner odnotowuje, że UiPath wyszedł poza RPA w stronę przetwarzania dokumentów, analizy procesów i testów, a teraz przenosi ten sposób pracy na orkiestrację. Dla firmy, która ma już roboty, oznacza to rzecz bardzo praktyczną: nowe możliwości dokładają się do istniejącej inwestycji. Działający robot staje się krokiem w większym, prowadzonym procesie.
**Ekosystem.** Duża baza klientów, partnerzy wdrożeniowi, sojusze technologiczne i dostępność przeszkolonych ludzi na rynku pracy. To jest argument nudny do czasu, aż potrzebujecie drugiego konsultanta w projekcie w ciągu dwóch tygodni. Wtedy staje się najważniejszy ze wszystkich.
**Trwałe wykonanie procesu.** Tu opis Gartnera jest najbardziej konkretny i dotyczy **UiPath Maestro**. Silnik utrzymuje stan procesu długotrwałego, gwarantuje, że każdy krok wykona się dokładnie raz, oraz pozwala zatrzymać, cofnąć, odtworzyć i zmigrować proces **w trakcie jego działania**. W praktyce znaczy to, że proces trwający tygodnie, miesiące albo lata przeżywa awarię infrastruktury zewnętrznej, zmianę wersji i zmianę samego przepływu, bez utraty stanu i bez powtarzania tego, co już się wykonało. Jeżeli prowadziliście kiedyś sprawę reklamacyjną albo onboarding klienta w narzędziu, które po restarcie zaczynało od zera, wiecie, ile warta jest ta jedna właściwość. O warstwie kontroli nad takim procesem pisaliśmy przy okazji [bramek z udziałem człowieka w UiPath Maestro](/pl/aktualnosci/blog/hitl-gate-uipath-maestro-ai-trust-layer/).
Do tego dochodzą dwa elementy wymienione przez Gartnera w opisie platformy: **UiPath Autopilot**, który wspiera wytwarzanie automatyzacji, oraz **UiPath AI Trust Layer** jako bezpieczna warstwa dostępu do modeli.
## Co ta pozycja oznacza dla Waszego programu automatyzacji
Gartner wymienia zastosowania, dla których kategoria BOAT powstała, a lista czyta się jak spis spraw czekających w kolejce w każdej większej firmie.
**Zarządzanie sprawą z udziałem agentów wiedzy.** Reklamacja, wniosek kredytowy, przypadek serwisowy - sprawa, która ma własny stan, własny czas życia i kilkanaście możliwych ścieżek. Agent podpowiada i przygotowuje, człowiek zatwierdza, platforma pilnuje, że nic nie ginie po drodze. Prowadzimy to jako [zarządzanie sprawą](/pl/oferta/automatyzacja-ai/case-management/).
**Długotrwałe przepływy przez wiele systemów.** Zamówienie, które przechodzi przez ERP, magazyn, przewoźnika i księgowość, i musi przeżyć każdą z tych granic. To jest dokładnie ten scenariusz, w którym trwałe wykonanie procesu z UiPath Maestro przestaje być cechą z karty produktu i zaczyna być różnicą w rachunku.
**Koordynacja agentów wielu dostawców pod jednym nadzorem.** Agent w jednym narzędziu, agent w drugim, robot w trzecim. Warstwa BOAT daje im wspólny rejestr, wspólne uprawnienia i wspólny ślad audytowy zamiast kilku niezależnych wysp.
**Orkiestracja uniwersalna.** Agenci, ludzie, roboty i narzędzia w jednym przebiegu, z jednym miejscem, w którym widać, co się dzieje. To jest sens słowa „skonsolidowana” w definicji Gartnera.
W polskich realiach dochodzi jeszcze jeden wątek. Większość procesów, o których tu mowa, w którymś momencie wchodzi w SAP - zamówienie, faktura, dane kontrahenta, zlecenie serwisowe. W tym samym zestawieniu Gartnera oceniony został także **SAP**, więc obie platformy, na których pracujemy na co dzień, zostały zmierzone jedną miarą. Dla Was to wygodna sytuacja: potrafimy pokazać, co w konkretnym procesie daje UiPath, a co daje warstwa automatyzacji SAP z **SAP Build Process Automation** i **SAP Joule Studio**, i dopasować wybór do potrzeby biznesowej oraz do tego, co już stoi w Waszym krajobrazie, a nie do tego, czyim partnerem jesteśmy. W projekcie wygląda to tak, że zespół SAP siada do stołu razem z zespołem automatyzacji, a nie po nim.
## Od czego zaczynamy w SNOK
Jesteśmy **UiPath Platinum Partner** oraz **UiPath Agentic Automation Fast Track Partner** - zakres współpracy opisaliśmy na [stronie partnerstwa z UiPath](/pl/uipath-snok/), a wszystkie autoryzacje razem na [stronie partnerstw](/pl/partnerstwa/). Poziom partnerski oznacza w praktyce ścieżkę wsparcia u producenta, licencje kupowane razem z wdrożeniem oraz konsultantów z certyfikacjami odnawianymi co roku.
Program orkiestracji zaczynamy zawsze tak samo, w trzech krokach.
**Wybieramy proces, który naprawdę zarabia na zmianie.** Kandydatów wskazuje [analiza procesów](/pl/oferta/automatyzacja-ai/process-mining/), a nie przekonanie właściciela procesu. Dane z przebiegów pokazują, gdzie siedzi wolumen, czas i powtarzalna praca.
**Budujemy pierwszy przebieg od końca do końca.** Warstwa wykonawcza i integracje powstają w ramach [automatyzacji procesów biznesowych](/pl/oferta/automatyzacja-ai/business-process-automation/), orkiestracja długotrwała na [UiPath Maestro](/pl/oferta/automatyzacja-ai/uipath-maestro/), a dokumenty wchodzące do procesu obsługuje [przetwarzanie dokumentów](/pl/oferta/automatyzacja-ai/document-understanding/).
**Zabezpieczamy to, co już działa.** Regresję po każdej zmianie pilnują [testy agentowe](/pl/oferta/automatyzacja-ai/agentic-testing/), więc kolejne odcinki procesu dokładacie bez ryzyka dla poprzednich.
Wyróżnienie w Magic Quadrant należy do UiPath. Dla Was jest sygnałem, że kategoria, o której mówimy od dawna, została nazwana i zmierzona, a platforma, na której pracujemy, ma w niej mocną pozycję. Najkrótsza droga do sprawdzenia tego u siebie to jeden proces i jeden przebieg od końca do końca. Jeżeli macie w głowie kandydata, [umówcie rozmowę o wyborze pierwszego procesu](/pl/kontakt/) - wyjdziecie z niej z listą kryteriów i wiedzą, czego szukać w danych z przebiegów.
---
## Źródła
- Gartner, *Magic Quadrant for Business Orchestration and Automation Technologies*, 14 września 2026, ID G00844491, autorzy: Saikat Ray, Arthur Villa, Sachin Joshi, Adam Briggs, Tushar Srivastava, Mike Warren.
- Licencjonowany przedruk raportu udostępnia UiPath: [strona raportu](https://www.uipath.com/resources/automation-analyst-reports/gartner-magic-quadrant-business-orchestration-automation-technologies).
- Komunikat UiPath o wyróżnieniu, 18 września 2026.
GARTNER is a registered trademark and service mark, and MAGIC QUADRANT is a registered trademark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.
---
### Przegląd tygodnia W38: nie narzędzie, tylko droga
URL: https://snok.ai/pl/aktualnosci/blog/snok-weekly-digest-w38-nie-narzedzie-tylko-droga/ | Data: 2026-09-18 | Seria: Inne
**Dziesięć pozycji z tygodnia 11-17 września 2026, z komentarzem, co każda zmienia w Waszych systemach.**
SAP Security Patch Day z 8 września dał notę o ocenie 9,8. Cztery doby później istniał publiczny
opis mechanizmu, a tego samego wieczoru działający dowód w labie. To nie jest historia o jednej
podatności. To pierwsza z dziesięciu pozycji, w których rozstrzygnięcie ani razu nie brzmiało
„które narzędzie kupić”.
Za każdym razem brzmiało inaczej: którą drogą pójść. Łatać kernel czy dokręcić parametr
komunikacji wewnętrznej. Monitorować jedną drogę do danych bankowych czy wszystkie osiem. Dać
agentowi dokument w indeksie czy żywy rekord w systemie. Modelować proces w notacji, w kodzie czy
na kanwie. Wpisać klauzulę po swojej stronie umowy czy zostawić ją dostawcy. Te decyzje zapadają
raz, zwykle wcześnie i zwykle przez kogoś, kto nie wie, że właśnie decyduje. Odwrócenie ich
później nie jest przekonfigurowaniem, tylko przepisaniem.
## 1. Dziewięćdziesiąt sześć godzin od noty do działającego kodu
SAP Security Patch Day z 8 września 2026 przyniósł notę 3759472 z oceną 9,8 w kategorii HotNews,
bez obejścia. Luka siedzi w SAP Message Server: przy zapisie wpisu bramki brakuje sprawdzenia
autentyczności, więc nieuwierzytelniony klient po zwykłym powitaniu protokołu podaje własny host,
port i identyfikator procesu. Kernel przyjmuje te dane i rozgłasza sfałszowaną tożsamość bramki
do wszystkich serwerów aplikacyjnych w krajobrazie.
Mechanizm nazywa się zatruciem listy zaufania i ma dwie konsekwencje. Pierwsza to atak pośrednika
na ruchu wewnętrznym, czyli tam, gdzie chodzą bilety pojedynczego logowania i wewnętrzne wywołania
zdalne. Druga to zdalne wykonanie kodu bez konta w systemie.
Zegar jest w tej historii ważniejszy niż sam błąd. 8 września nota. 12 września rano publiczna
analiza różnicy w kernelu. 12 września wieczorem działający dowód w labie zespołu badawczego
SecurityBridge - z asystentem kodowania AI przy odtwarzaniu formatu danych, co badacze podają
wprost. Według relacji badaczy realnej pracy było na dwa dni - dwie doby z tych czterech przypadły
na urlop.
Kontrola oparta na adresach nie zatrzymuje tej rodziny poleceń. Wymuszenie szyfrowanej komunikacji
wewnętrznej między instancjami zamyka drogę skuteczniej, ale jest warstwą dodatkową - wyłączenie
parametru otwiera powierzchnię tego samego dnia. Trwałym rozwiązaniem jest wymiana kernela.
**Co z tego wynika:** jeżeli Wasz proces łatania SAP planuje okna kwartalnie, mierzy się
z przeciwnikiem, którego już nie ma. Linia kernela 9.x to obecny główny nurt S/4HANA, więc dotyczy
to większości krajobrazów; kernele 7.x i 8.x tej rodziny poleceń nie mają.
*Źródła: SecurityBridge Research Lab, „CVE-2026-58240: From Patch Day to PoC in 96 Hours”;
Onapsis, analiza tej samej podatności pod nazwą S4GET; SAP Security Note 3759472. Odczyt
17.09.2026. Status: mechanizm, ocena i numer noty potwierdzone w dwóch niezależnych źródłach.*
## 2. Osiem dróg do tego samego pola
Producent oprogramowania do ochrony SAP pokazał na webinarze osiem sposobów zmiany danych
bankowych w systemie. Transakcje alternatywne, mechanizmy transportu, rozwój własny, interfejsy
oraz procesy działające w tle. Żaden z ośmiu nie wywołał alertu, ponieważ monitorowana była droga
zamierzona, czyli standardowa transakcja.
Ta demonstracja nie dowodzi, że SAP jest źle zaprojektowany - większość dróg alternatywnych
istnieje z uzasadnionych powodów operacyjnych. Dowodzi czegoś innego: kontrola zbudowana wokół
jednej drogi nie widzi pozostałych, a ta sama logika obejmuje
warunki płatności, limity kredytowe, dane podstawowe kontrahentów oraz ceny i rabaty.
Druga teza z tego samego źródła dokłada wymiar czasu. Bezpieczeństwo sieci przerabiało tę lekcję
przez dwadzieścia lat: systemy wykrywania porównywały ruch z sygnaturami i podnosiły alarm, ale
zanim analityk go przeczytał, pakiet był u celu. Dopiero przeniesienie tej samej logiki w linię
ruchu pozwoliło pakiet odrzucić. Bezpieczeństwo SAP stoi dziś na etapie wykrywania: narzędzie
zgłasza podejrzane wywołanie i przekazuje sprawę człowiekowi, a atakującemu wystarcza czas między
jednym a drugim.
**Co z tego wynika:** lista ról odpowiada na pytanie, kto może wejść drzwiami. Nie odpowiada na
pytanie, kto wszedł oknem ani jak szybko zostanie stamtąd zdjęty. To jest różnica między rozmową
o zgodności a rozmową o zdolności operacyjnej.
*Źródła: SecurityBridge, „Breaking the Rules: Why Standard SAP Controls Are Not Enough” (Joris Van
De Vis); webinar „Break the rules: 8 ways to update Bank details in SAP”; materiał o samoochronie
aplikacji w czasie działania. Status: materiał producenta, nagrania nie odtwarzaliśmy. Liczba osiem
opisuje konkretne środowisko demonstracyjne, nie właściwość systemu SAP.*
## 3. Siedemdziesiąt osiem plików instrukcji i sześć tysięcy gwiazdek
Na GitHub leży pakiet, który zamienia asystenta kodowania w narzędzie pracy ofensywnej. Policzyliśmy
zawartość repozytorium sami: 78 plików instrukcji rozłożonych na 23 kategorie, ładowanych na
żądanie, więc nieużywane nie zajmują kontekstu modelu. Repozytorium powstało na początku marca
i ma dziś 6011 gwiazdek.
Sam pakiet jest tu mniej ciekawy niż mechanizm. Nie chodzi o exploit, który trzeba skompilować
i uruchomić, tylko o pliki tekstowe, które ktoś wrzuca do katalogu asystenta i tym samym wyposaża
go w metodykę. Powierzchnia ataku u Was rośnie nie o narzędzie, tylko
o gotowy sposób postępowania - a ten przenosi się razem z katalogiem plików.
Cudzy plik instrukcji dla agenta to niezaufany kod, nie dokumentacja. Traktowanie go jak dokumentacji jest tym samym błędem, co uruchomienie skryptu
z internetu bez przeczytania. **Skan skilli agentowych SNOK** sprawdza takie pakiety przed
instalacją pod kątem wstrzyknięcia poleceń, wycieku danych, eskalacji uprawnień i zatrucia
pamięci agenta.
**Co z tego wynika:** jeżeli w Waszej organizacji ktokolwiek rozszerza asystentów o cudze pliki
instrukcji, potrzebujecie na to bramki. Polityka zakupowa oprogramowania takiego przypadku nie
obejmuje, bo formalnie nic nie zostało kupione.
*Źródło: repozytorium SnailSploit/Claude-Red na GitHub, metadane i struktura drzewa pobrane
17.09.2026. Status: potwierdzone własnym pomiarem - liczba plików instrukcji, liczba kategorii,
liczba gwiazdek i daty pochodzą z interfejsu programistycznego GitHub, nie z relacji pośredniej.*
## 4. Prawie trzy tysiące gotowych komend w pakiecie dystrybucji
Klasyczny launcher komend używanych w testach penetracyjnych został przepisany w języku Go
i trafił do oficjalnych repozytoriów dystrybucji Kali Linux. Opis projektu mówi o 247 narzędziach,
2926 komendach i ponad dwustu ściągach. Instalacja to jedno polecenie, a dalej wyszukiwanie
w bibliotece i wstrzyknięcie gotowej komendy do terminala.
To nie jest nowy silnik ataku. To warstwa produktywności nad narzędziami, które istnieją od lat -
i właśnie dlatego jest istotna. Zestawiona z poprzednią pozycją pokazuje, że próg wejścia po
stronie ofensywnej spada dwoma niezależnymi kanałami naraz: gotowe komendy w pakiecie systemowym
i gotowa metodyka dla asystenta.
**Co z tego wynika:** zespół obrony planuje pracę wobec przeciwnika, który nie musi już pamiętać
składni ani kolejności kroków. Przy ocenie postawy bezpieczeństwa warto pytać nie o to, czy ktoś
umie użyć narzędzia, tylko o to, ile czasu zajmie Wam zauważenie, że go użył.
*Źródło: repozytorium halilkirazkaya/arsenal-ng na GitHub, metadane pobrane 17.09.2026 - język Go,
licencja MIT, 702 gwiazdki, ostatnia zmiana 11.08.2026. Status: metadane potwierdzone własnym
pomiarem; liczby 247 narzędzi i 2926 komend pochodzą z opisu projektu, zawartości biblioteki
nie przeliczaliśmy.*
## 5. Grounding na dokumencie odpowiada na inne pytanie niż grounding na danych
UiPath opisał warstwę, przez którą agent sięga po żywe rekordy w systemach klienta, zamiast pracować
na wektorach zbudowanych z dokumentów. **UiPath Data Fabric** modeluje encje raz i udostępnia je
wszystkim agentom z zachowaniem uprawnień.
Cztery wymagania, które materiał stawia danym gotowym dla agenta, są dobrą listą kontrolną
niezależnie od platformy. Dostęp do stanu bieżącego, a nie do zrzutu z nocy. Struktura pozwalająca
filtrować i łączyć. Modele encji budowane raz dla wszystkich zespołów, nie od nowa w każdym
projekcie. Uprawnienia i ślad pochodzenia w standardzie, bo inaczej każdy nowy agent to nowa
powierzchnia zgodności.
Różnicę widać najlepiej na dwóch pytaniach. Wyszukiwanie po podobieństwie odpowie, co mówi
polityka zwrotów, bo odpowiedź jest fragmentem tekstu. Nie odpowie, które zgłoszenia w danym
regionie są po terminie, bo to zapytanie z filtrem i złączeniem, a odpowiedzią jest liczba
policzona z wierszy.
**Co z tego wynika:** projekt agentowy zaczęty od wektoryzacji dokumentów kończy się asystentem
elokwentnym i nieoperacyjnym. Jeżeli pytania, które ma obsłużyć, dotyczą stanu, a nie treści,
warstwa danych jest pierwszą decyzją architektoniczną, nie ostatnią.
*Źródło: materiał UiPath o warstwie Data Fabric, wrzesień 2026. Status: materiał producenta bez
niezależnego potwierdzenia; zakres wspieranych systemów nie jest w nim wymieniony, więc żadnego
nie wymieniamy z nazwy.*
## 6. Trzy wzorce orkiestracji na jednym silniku
Najkrótsze ujęcie granicy między dwiema warstwami platformy UiPath brzmi tak: Orchestrator
zarządza wykonawcami, a **UiPath Maestro** prowadzi proces, którego ci wykonawcy są częścią.
Pod spodem stoi silnik trwałego wykonania, więc proces zatrzymany na zatwierdzeniu wznawia się
dokładnie w miejscu zatrzymania i przeżywa awarię systemu, od którego zależy. Nie piszecie maszyny
stanów ani własnej warstwy ponawiania.
Na tym samym silniku stoją trzy wzorce i tu zapada decyzja, która zaważy na całym wdrożeniu. Wzorzec strukturalny
w notacji modelowania procesów wybieracie, gdy ścieżka jest znana z góry, decyzje wynikają z reguł,
a audytowalność jest krytyczna - obsługa faktur, wdrożenie pracownika, sprawozdawczość regulacyjna.
Wzorzec skierowany do kodu wybieracie, gdy rozwiązanie budują programiści, a logika czyta się
lepiej w repozytorium niż na kanwie graficznej; projekt zapisuje się w formacie tekstowym,
więc zmiany przeglądacie w systemie kontroli wersji jak każdy inny kod. Wzorzec adaptacyjny
wybieracie, gdy następnego kroku nie da się przewidzieć na etapie projektowania, wyjątki są normą,
a sprawa ciągnie się tygodniami - likwidacja szkód, weryfikacja klienta, ocena świadczeń.
**Co z tego wynika:** wybór wzorca jest konsekwencją procesu, nie preferencją konsultanta. Pytanie
zadane na starcie kosztuje jedną rozmowę; pominięte wraca jako przepisanie w połowie wdrożenia.
*Źródła: materiały produktowe UiPath o Maestro i o kanwie dla deweloperów, artykuł porządkujący
trzy warstwy, repozytoria społecznościowe z przykładami. Status: zdolności zgodne z materiałem
producenta; status wydania kanwy dla deweloperów to podgląd publiczny, a daty dostępności ogólnej
źródło nie podaje - nie budujemy na tym harmonogramu.*
## 7. Trzy drogi budowy agenta i koszt wybrania nie tej
Ta sama platforma daje trzy równorzędne drogi do zbudowania agenta: zestaw programistyczny w Pythonie,
agenty kodowane przez wiersz poleceń oraz kanwę w przeglądarce. Materiał producenta opisuje
wszystkie trzy jako pełnoprawne i nie rozstrzyga, od której zacząć - a na forum społeczności wraca dokładnie to pytanie.
Rozstrzygnięcie nie dotyczy smaku. Dotyczy tego, ile kontroli bierze zespół i ile pracy własnej
przyjmuje w zamian. Zestaw programistyczny daje najwięcej swobody i najgłębszą integrację
z ekosystemem języka, a w zamian oczekuje najwięcej roboty własnej. Kanwa w przeglądarce daje
najniższy próg i najszybszy start, płacąc najmniejszym wpływem na szczegóły. Droga przez wiersz
poleceń trzyma kod pod kontrolą wersji, czyli mieści się w praktykach inżynierskich, które
Wasz zespół najpewniej już ma.
**Co z tego wynika:** rozmowa o wyborze drogi na starcie projektu kosztuje godzinę. Pominięta
kosztuje przeróbkę, bo przejście na inną drogę oznacza zbudowanie rozwiązania od nowa.
*Źródło: materiał UiPath porządkujący trzy drogi budowy agenta, wrzesień 2026. Status: materiał
producenta.*
## 8. Lider kwadrantu, wdrożenie z liczbami i spór o koniec robotyzacji
Trzy materiały z jednego tygodnia odpowiadają na trzy zastrzeżenia, które w rozmowie o agentach
wracają najczęściej.
Czy dostawca jest poważny? UiPath został wskazany jako lider w kwadrancie firmy badawczej Gartner
dla rozwiązań inteligentnego przetwarzania dokumentów, drugi rok z rzędu; raport nosi datę
8 września 2026.
Czy ktoś to naprawdę uruchomił? Studium przypadku filipińskiego operatora telekomunikacyjnego
PLDT opisuje trzy agenty w produkcji, zbudowane tak, że roboty programowe są narzędziami agenta.
Asystent wiedzy odpowiada w jedną do trzech sekund zamiast w jeden do pięciu dni i zdejmuje od 25
do 30 tysięcy roboczogodzin rocznie, co materiał przelicza na zdolność około dwunastu etatów.
Agent oceny ryzyka, wdrożony w lutym 2026, skraca czas zadań zajmujących od dwóch do dziesięciu
dni do przedziału od pięciu minut do jednego dnia.
Czy nie kupujemy technologii na wylocie? Na to ostatnie odpowiada nie dostawca, lecz praktyk
z banku. Wygenerowanie odpowiedzi to nie to samo co domknięcie procesu. Model przejrzy fakturę,
wydobędzie dane i wskaże rozbieżność. Domknięcie wymaga walidacji wobec reguł, zatwierdzeń
zależnych od progów kwotowych, aktualizacji wielu systemów, dziennika audytowego i pilnowania
terminów. To są problemy wykonania, nie problemy inteligencji - a robotyzacja procesów nie tyle
znika, ile przestaje być naśladowaniem człowieka przy ekranie i staje się warstwą wykonawczą pod
decyzją podjętą wyżej.
**Co z tego wynika:** zmienia się też miara sukcesu. Liczba wdrożonych robotów i liczba
zaoszczędzonych godzin tracą znaczenie na rzecz pytania, czy praca idzie szybciej bez utraty
jakości i czy rekomendacje da się wdrażać konsekwentnie pod nadzorem.
*Źródła: komunikat UiPath dla inwestorów o pozycji w kwadrancie (raport Gartner z 8.09.2026);
studium przypadku PLDT opublikowane przez UiPath i relacjonowane przez trzy niezależne redakcje
branżowe w dniach 10-15.09.2026; artykuł w Forbes Technology Council o granicy między inteligencją
a wykonaniem. Status: pozycja i data raportu potwierdzone; liczby z wdrożenia pochodzą ze studium
przypadku producenta i nie są naszym pomiarem. Gartner nie rekomenduje dostawców ani produktów,
a jego publikacje są opiniami organizacji badawczej, nie stwierdzeniami faktu.*
## 9. Dwadzieścia cztery klauzule i rozstrzygnięcie, kto bierze ryzyko
Praktyk prawa zestawił katalog postanowień umownych dla systemów sztucznej inteligencji w dwóch
rolach: osiemnaście chroniących podmiot, który system stosuje, i sześć chroniących dostawcę.
Wartość tego zestawienia polega na tym, że obie listy stoją obok siebie, więc widać, gdzie
interesy się rozchodzą.
Po stronie stosującego wracają te same punkty: zakaz trenowania modelu na danych wprowadzanych
przez użytkownika, notyfikacja zmian w systemie z prawem sprzeciwu, zakaz przetwarzania poza
Europejskim Obszarem Gospodarczym z listą lokalizacji, realne funkcje nadzoru człowieka łącznie
z natychmiastowym zatrzymaniem systemu oraz wsparcie przy migracji po rozwiązaniu umowy. Po
stronie dostawcy - prawo do wykorzystania danych do trenowania i rozwoju, zmiana podwykonawców
i lokalizacji bez zgody oraz zamknięty opis funkcji, poza którym dostawca nie odpowiada.
Trzy uwagi z dyskusji pod tym materiałem dotykają rzeczy, których w samej liście nie ma. Trenowanie to nie to
samo co retencja - model nie uczy się w czasie rzeczywistym, a ryzyko siedzi w tym, co dostawca
gromadzi i jak długo. Notyfikacja zmian musi obejmować podmianę modelu bazowego i sposobu
kierowania zapytań, bo to samo zapytanie potrafi dostać inną odpowiedź niż tydzień wcześniej, przy
niezmienionej umowie i niezmienionym interfejsie. Odpowiedzialność kontraktowa nie zastępuje
potwierdzenia, że system wolno stosować w chwili użycia.
Warto też uporządkować terminy, bo w obiegu krąży błędna wersja. Rozporządzenie o sztucznej
inteligencji stosuje się etapami, a pakiet zmian przesunął część z nich. Obowiązki dla
systemów wysokiego ryzyka z załącznika trzeciego stosuje się od 2 grudnia 2027, a dla systemów
z załącznika pierwszego od 2 sierpnia 2028. Teza, że przepisy o systemach wysokiego ryzyka
obowiązują od sierpnia 2026, jest nieprawdziwa.
**Co z tego wynika:** rozmowa o zgodności przenosi się z prezentacji do załącznika umowy. Jeżeli
kupujecie system AI, pytanie brzmi nie „czy dostawca jest zgodny”, tylko „które z tych dwudziestu
czterech postanowień znalazły się w naszym egzemplarzu”.
*Źródła: seria wpisów praktyka prawa o klauzulach kontraktowych, sierpień i wrzesień 2026;
rozporządzenie o sztucznej inteligencji, art. 113 w brzmieniu po zmianie. Status: terminy
stosowania potwierdzone; katalog klauzul jest opinią praktyka, nie źródłem prawa.*
**To nie jest porada prawna - przed zastosowaniem u siebie wymagany jest przegląd prawnika.**
## 10. Sto osiemdziesiąt miliardów parametrów przy biurku i trzy różne licencje
Model gęsty o 27 miliardach parametrów mieści się w około 17 gigabajtach po kwantyzacji
czterobitowej i niesie kontekst 262 tysięcy tokenów natywnie, na licencji Apache 2.0. To już samo
w sobie zmienia rachunek dla organizacji, która nie chce wysyłać danych na zewnątrz. Przepis
opublikowany przez społeczność idzie dalej: serwuje wariant rzadki o 180 miliardach parametrów na
jednym urządzeniu klasy biurkowej, z prędkością rzędu 60 tokenów na sekundę przy jednym strumieniu.
Druga rzecz rzadziej trafia do nagłówków, a rozstrzyga o wycenie. Trzy warianty tej samej rodziny mają trzy różne
reżimy licencyjne. Model bazowy jest udostępniony na licencji otwartej bez progów. Wariant skróconego
rozumowania jest bezpłatny do progu przychodowego organizacji, a powyżej wymaga licencji
komercyjnej. Wariant rzadki pozwala na użycie komercyjne, ale wyłącza udostępnianie modelu jako
usługi. Trzy różne odpowiedzi na to samo pytanie, w jednej rodzinie modeli.
**Co z tego wynika:** rozmowa o suwerenności danych przestaje być wyborem między jakością
a kontrolą, a staje się rachunkiem - gdzie dokładnie leży granica przy Waszej wielkości zadania.
Licencję sprawdza się przed wyceną, nie po wdrożeniu.
*Źródła: karta modelu Qwen3.8-27B na Hugging Face; karta wariantu skróconego rozumowania wraz
z tabelą pomiarów producenta; przepis społecznościowy serwowania wariantu rzadkiego, wersja
z 14.09.2026. Status: parametry modelu bazowego i licencja potwierdzone u źródła; prędkości
pochodzą z opisu przepisu jednego autora i nie są naszym pomiarem.*
## Jedno zdanie na ten tydzień
Dziesięć rozstrzygnięć z tego tygodnia łączy jedna cecha: żadne nie ma własnej pozycji w budżecie
ani w rejestrze ryzyk. Wybór drogi zapada w rozmowie technicznej, w komentarzu do umowy albo
w ustawieniu domyślnym narzędzia - a jego cena pojawia się dopiero przy pierwszym audycie,
pierwszym incydencie albo pierwszej zmianie polityki, której nie da się wprowadzić bez przepisania
rozwiązania.
Stąd jedno praktyczne pytanie na najbliższy przegląd: które z tych decyzji już u Was zapadły i kto
je podjął. Jeżeli nikt nie potrafi wskazać tej osoby, decyzja i tak istnieje - podjęło ją ustawienie
domyślne.
Przegląd tygodnia SNOK · W38 · 11-17 września 2026
Całe wydanie w jednym pliku
PDF, trzynaście stron, około 1,5 MB - bez formularza i bez podawania danych. Wersja do przekazania dalej w zespole albo do przeczytania w telefonie.
Jeżeli któryś z tych tematów dotyczy Was bezpośrednio - [bezpieczeństwo SAP](/pl/oferta/bezpieczenstwo-sap/) albo [orkiestracja i automatyzacja z agentami](/pl/oferta/automatyzacja-ai/) - [porozmawiajmy](/pl/kontakt/).
---
### Jeden dostawca, pięć nazw - dlaczego dział zakupów nie widzi własnych wydatków
URL: https://snok.ai/pl/aktualnosci/blog/jeden-dostawca-piec-nazw-dane-dostawcow-w-zakupach/ | Data: 2026-09-17 | Seria: Technologiczny Czwartek
Tydzień przed dużą negocjacją zaczyna się ta sama praca. Ktoś wyciąga wydatki z systemu ERP.
Ktoś dokłada zamówienia z platformy zakupowej, bo część kategorii chodzi tylko tamtędy. Ktoś
przypomina sobie, że spółka zależna kupuje u tego samego dostawcy osobno i ma własną umowę.
Po dwóch dniach powstaje arkusz, który przez chwilę jest jedynym miejscem w firmie znającym
prawdę o tym dostawcy.
Potem arkusz zostaje w skrzynce pocztowej, a za pół roku trzeba go zrobić od nowa.
To nie jest opowieść o niedbalstwie. To opis normalnego stanu rzeczy w organizacji, która
rosła, przejmowała, migrowała systemy i przez cały ten czas musiała kupować. Warto jednak
nazwać, ile ta praca naprawdę kosztuje - bo koszt nie leży w dniach spędzonych na sklejaniu
arkusza.
## Negocjujecie z rekordem, nie z dostawcą
Dział zakupów nie siada do stołu z firmą. Siada z tym, co o niej wiadomo w systemach. Jeżeli
ten sam podmiot istnieje w pięciu miejscach pod pięcioma zapisami nazwy, to organizacja
prowadzi pięć rozmów z pięcioma średnimi kontrahentami zamiast jednej rozmowy z jednym dużym.
Wydatek jest dokładnie ten sam. Pozycja negocjacyjna zupełnie inna.
*Kwoty rozproszone po systemach wyglądają na pięciu przeciętnych dostawców. Ta sama suma
w jednym miejscu zmienia rozmowę.*
Rozjazd bierze się z rzeczy drobnych i całkowicie zrozumiałych. Forma prawna zapisana na cztery
sposoby. Nazwa handlowa obok nazwy rejestrowej. Numer NIP raz z kreskami, raz bez, raz wpisany
w pole opisu. Oddział, centrala i spółka zależna jako trzy osobne rekordy. Ten sam podmiot
występujący raz jako dostawca, raz jako odbiorca. I rekord założony w piątek po południu,
bo zamówienie było pilne, a szukanie istniejącego zajęłoby więcej czasu niż utworzenie nowego.
Każda z tych decyzji z osobna była rozsądna. Dopiero ich suma po piętnastu latach daje bazę,
w której nikt nie potrafi odpowiedzieć na pytanie, ilu firma ma dostawców.
## Czego przez to nie widać
**Grupy kapitałowej.** Sześć podmiotów jednego właściciela to w bazie sześciu niezależnych
dostawców. Rozmawiacie jednak z grupą, a grupa patrzy na łączny obrót. Bez powiązania
właścicielskiego organizacja nie wie, że jest dla tej grupy klientem strategicznym, i siada
do stołu jako sześciu klientów przeciętnych.
**Kategorii.** Ta sama usługa trafia w trzech systemach do trzech różnych kategorii, bo każdy
system ma własny słownik. Dopóki nie ma wspólnej klasyfikacji, nie da się powiedzieć, ile firma
wydaje na daną kategorię. A strategia kategorii jest podstawowym narzędziem pracy zakupów -
nie zbudujecie jej na liczbie, której nie ma.
**Umów.** Kupiec nie znalazł obowiązującej umowy, bo szukał pod inną nazwą. Zamówił poza nią,
w dobrej wierze i zgodnie z procedurą. Wynegocjowana stawka została w dokumencie, a firma
zapłaciła cennikową.
**Pieniędzy, które wyszły dwa razy.** Ta sama faktura zaksięgowana pod dwoma rekordami tego
samego kontrahenta wygląda na dwa różne zobowiązania.
## Rekord bez właściciela
Zakupy zakładają rekord kontrahenta. Finanse zmieniają numer rachunku bankowego. Księgowość
uzupełnia dane przy okazji faktury. Dział informatyki przenosi całość przy najbliższym projekcie
migracyjnym. Każdy z tych kroków jest uzasadniony, a mimo to nikt nie odpowiada za rekord jako
całość.
W Polsce ta luka ma bardzo konkretną cenę. Numer rachunku bankowego jest polem rekordu
kontrahenta, a przy transakcji między przedsiębiorcami powyżej 15 000 zł brutto zapłata na
rachunek spoza wykazu prowadzonego przez Ministerstwo Finansów oznacza brak możliwości
zaliczenia kwoty do kosztów uzyskania przychodu oraz solidarną odpowiedzialność za VAT
niezapłacony przez dostawcę. Od sankcji uwalnia zawiadomienie naczelnika urzędu skarbowego
złożone w ciągu siedmiu dni, ale najpierw trzeba tę pomyłkę wychwycić.
Jeżeli dostawca ma w systemach pięć rekordów, kontrola rachunku musi zadziałać pięć razy.
Wystarczy, że jeden z nich jest nieaktualny.
Podobnie wygląda sprawdzanie podmiotu pod kątem list sankcyjnych i beneficjenta rzeczywistego.
Nie sprawdzicie rzetelnie kogoś, kogo nie umiecie policzyć.
## Rok, w którym to przestaje być do udźwignięcia ręcznie
Dwie rzeczy zmieniają się w 2026 roku jednocześnie.
Pierwsza: w zakupach jest więcej pracy przy mniejszych zasobach. Hackett Group w badaniu
agendy zakupów na 2026 rok podaje wzrost obciążenia pracą o osiem procent przy jednoczesnym
spadku zatrudnienia i budżetów operacyjnych. Praca, która dotąd znikała w nadgodzinach
analityka, w takim układzie po prostu się nie wydarzy. Arkusz przed negocjacją albo powstanie
gorszy, albo nie powstanie wcale.
Druga: do zakupów wchodzą agenci. W tym samym badaniu Hackett Group podaje, że 76 procent
organizacji raportuje dzięki sztucznej inteligencji poprawę kluczowych miar o 25 procent
lub więcej. Niezależnie od tego, jak te miary są liczone w poszczególnych firmach, taka
liczba nie opisuje już fazy pilotaży.
Człowiek rozpozna, że „ABC Sp. z o.o.” i „A.B.C. Polska” to prawdopodobnie ten sam podmiot.
Zawaha się, sprawdzi, zapyta kolegi. Automat zrobi to samo tylko wtedy, gdy dostanie
mechanizm rozpoznawania podmiotu i punkt, w którym decyzję zatwierdza człowiek. Bez tych dwóch
rzeczy wykona zadanie na rekordzie, który akurat dostał - i zrobi to szybciej niż kupiec.
Automatyzacja postawiona na bazie z duplikatami nie naprawia rozjazdu, tylko powiela go
w większej skali.
## Czy SAP S/4HANA tego nie załatwia
Po części tak. W SAP S/4HANA model danych został uporządkowany: Business Partner zastąpił
osobne rekordy dostawcy i odbiorcy, a wbudowana kontrola duplikatów ostrzega osobę zakładającą
rekord, że podobny już istnieje. To chroni przed kolejnym duplikatem i warto to włączyć.
Nie rozwiązuje natomiast dwóch rzeczy. Konwersja do Business Partnera przenosi istniejący stan
do nowego modelu, więc duplikaty przechodzą razem z resztą danych. I żadna kontrola wewnątrz
SAP nie widzi tego, co żyje w platformie zakupowej, obiegu faktur i arkuszach kupców.
SAP Master Data Governance idzie dalej i bywa właściwą odpowiedzią - mówimy o tym otwarcie.
Bywa też odpowiedzią zbyt ciężką tam, gdzie istotna część wiedzy o kontrahentach mieszka poza
SAP, a [po przejęciach](/pl/aktualnosci/blog/sap-mdg-vs-informatica-mdm-po-przejeciach/) mieszka tam prawie zawsze.
## Rekord obowiązujący, czyli co konkretnie
Termin golden record krąży po rynku od lat i zdążył się zużyć, więc warto go nazwać bez żargonu.
Rekord obowiązujący to jeden rekord kontrahenta wskazany jako właściwy, złożony z najlepszych
danych ze wszystkich systemów, w którym przy każdym polu wiadomo, skąd pochodzi i kto je
ostatnio zmienił. Systemy źródłowe pracują dalej bez zmian. Zyskują tylko jedno: wiedzę,
że opisują ten sam podmiot.
*Pochodzenie pola jest częścią rekordu, nie osobnym dokumentem. To ono pozwala cofnąć decyzję
i obronić ją przed audytem.*
Do czego służy, licząc konkretnie:
- do zsumowania wydatków u jednego podmiotu i w całej jego grupie kapitałowej, czyli
do negocjacji,
- do kontroli numeru rachunku bankowego przed płatnością w jednym miejscu zamiast w pięciu,
- do sprawdzenia podmiotu pod kątem sankcji, statusu VAT i beneficjenta rzeczywistego,
- do raportowania po łańcuchu dostaw, w tym na potrzeby sprawozdawczości zrównoważonego
rozwoju,
- do automatyzacji i scenariuszy agentowych, żeby proces nie musiał zgadywać, o kogo chodzi,
- do [konwersji do SAP S/4HANA](/pl/aktualnosci/blog/bezpieczna-konwersja-sap-s4hana-rise/), która wymaga jednoznaczności podmiotu,
- do audytu, bo pochodzenie każdego pola i historia zmian są zapisane.
I trzy rzeczy, którymi rekord obowiązujący nie jest. Nie jest nowym systemem ERP. Nie jest
hurtownią danych. Nie jest jednorazową akcją czyszczenia bazy, po której wszystko wraca
do stanu wyjściowego w ciągu roku.
## Warstwa ponad systemami, nie zamiast nich
Tak to robimy w [SNOK MDM](/pl/produkty/snok-mdm/): dokładamy warstwę, która rozpoznaje jeden podmiot w wielu rekordach
i utrzymuje ten stan w czasie. Systemy źródłowe zostają tam, gdzie są, i dalej pracują.
Propozycje scaleń przygotowuje mechanizm dopasowania, a zatwierdza człowiek - opiekun danych
po Waszej stronie - i każda taka decyzja trafia do śladu audytowego.
Zaczynamy od [warsztatu diagnostycznego](/pl/oferta/master-data-management/), który trwa około dwóch tygodni. Wychodzicie z niego
z mapą źródeł, raportem par podejrzanych o duplikat wraz z ich liczbą i z oceną, ile
z nich rozstrzyga reguła, a ile wymaga człowieka. To jest pierwszy moment, w którym pytanie
„ilu mamy dostawców” dostaje liczbę zamiast szacunku.
Potem jest pilot jednej domeny w cztery do ośmiu tygodni. Kończy się działającym rekordem
obowiązującym dla tej domeny, regułami dopasowania opisanymi w języku Waszego procesu,
hierarchią powiązań właścicielskich dla podmiotów objętych pilotem i kryteriami odbioru
uzgodnionymi przed startem - na Waszych własnych danych, nie na prezentacji. Rozliczenie
ryczałtowe za fazę. Dane i model pozostają Waszą własnością.
## Cztery rzeczy, które ustalamy przed startem
**Ile pracy zostaje po Waszej stronie.** W pilocie to zwykle jedna osoba z zakupów jako opiekun
danych, kilka godzin tygodniowo na rozstrzyganie spornych par, plus dostęp do źródeł po stronie
działu informatyki. Bez tej osoby projekt zatrzyma się na pierwszej spornej parze, niezależnie
od technologii.
**Co z błędnym scaleniem.** Scalenie jest decyzją zapisaną, nie nadpisaniem danych. Rekordy
źródłowe zostają nietknięte, a powiązanie da się cofnąć wraz z uzasadnieniem, kto i kiedy je
zatwierdził. Reguła, która budzi wątpliwość, trafia do kolejki do człowieka, zamiast działać
automatycznie.
**Co z bezpieczeństwem danych.** Pracujemy na zakresie potrzebnym do dopasowania podmiotu,
w środowisku uzgodnionym z Wami, z rejestrem dostępu. Numery rachunków i dane osobowe osób
kontaktowych traktujemy jak dane produkcyjne, także w fazie diagnostycznej.
**Kto utrzymuje rekord po pilocie.** Utrzymanie jest częścią rozwiązania, nie jego brakiem:
reguły, kolejka spraw do rozstrzygnięcia i przegląd cykliczny. To jest różnica między rekordem
obowiązującym a jednorazowym czyszczeniem bazy, po którym duplikaty wracają wraz z pierwszym
pilnym zamówieniem w piątek po południu.
## Kiedy nie warto tego robić
Uczciwie, bo nie każdej firmie to się opłaca.
Jeżeli cały krajobraz siedzi w jednym ekosystemie i strategia zakłada pozostanie w nim,
odpowiedzi warto najpierw szukać w narzędziach tego ekosystemu. Jeżeli baza dostawców liczy
kilkaset podmiotów w jednym systemie i jednej spółce, wystarczy dyscyplina zakładania rekordu
i przegląd raz na kwartał - projekt byłby kosztem bez adresata. Jeżeli skala idzie
w dziesiątki milionów rekordów z wymaganiem czasu rzeczywistego, to inna klasa rozwiązania.
## Trzy pytania na początek
Nie trzeba żadnego projektu, żeby sprawdzić, czy ten problem Was dotyczy.
Pierwsze: ilu macie aktywnych dostawców, a ilu podmiotów to naprawdę dotyczy.
Drugie: ile firma wydaje u największego dostawcy, licząc wszystkie spółki po obu stronach -
i ile czasu zajmuje uzyskanie tej liczby. Czas odpowiedzi mówi więcej niż sama liczba.
Trzecie: kto zatwierdza zmianę numeru rachunku bankowego dostawcy i w ilu miejscach trzeba
ją wprowadzić.
Jeżeli którakolwiek z tych odpowiedzi wymaga ręcznego składania danych z kilku systemów,
zacznijmy od najmniejszego możliwego kroku: weźmy jedną kategorię zakupową, porównajmy jej
źródła i policzmy, ile rekordów opisuje ten sam podmiot. To dwa tygodnie pracy i żadnej decyzji
o wymianie systemu. Dopiero ta liczba mówi, czy warto iść dalej.
---
### Bezpieczna konwersja do SAP S/4HANA - co program robi z waszą powierzchnią ataku
URL: https://snok.ai/pl/aktualnosci/blog/bezpieczna-konwersja-sap-s4hana-rise/ | Data: 2026-09-16 | Seria: Inne
Nie ma takiego protokołu z komitetu sterującego, w którym ktoś zapisuje: „zatwierdzamy rozszerzenie powierzchni ataku na najbliższe dwa lata”. A dokładnie to zapada na tych spotkaniach. Zamrożenie zmian w **SAP ECC** na czas programu. Zgoda na kopie produkcji w systemach projektowych, bo bez danych nie przejdziecie testów akceptacyjnych. Uprawnienia awaryjne dla integratora „do końca cutoveru”. Kryteria przejścia do go-live, w których nie ma ani jednego warunku bezpieczeństwa. Każda z tych decyzji jest osobno rozsądna. Razem tworzą okno, które stoi otwarte od roku do trzech lat, czyli tyle, ile realnie trwa program konwersji do **SAP S/4HANA**.
Termin też nie pomaga. SAP utrzymuje mainstream maintenance dla SAP Business Suite 7 do **31 grudnia 2027**, a utrzymanie rozszerzone od początku 2028 do końca 2030 kosztuje dodatkowe **dwa punkty procentowe** do podstawy utrzymania. Kto startuje teraz, ma kilkanaście miesięcy. Kto ma kilkanaście miesięcy, ten tnie zakres. A bezpieczeństwo tnie się najłatwiej, bo nikogo nie blokuje.
**W skrócie:**
**1/** zamrożenie zmian funkcjonalnych w SAP ECC nie zamraża ryzyka - SAP Security Patch Day wychodzi co miesiąc niezależnie od waszego harmonogramu,
**2/** w modelu **RISE with SAP** to klient składa wniosek o łatkę bezpieczeństwa warstwy Basis i zgadza się na przestój, a testu penetracyjnego nie uruchomi bez zgody SAP - oba fakty pochodzą z materiału SAP, nie od dostawcy zabezpieczeń,
**3/** przebieg **ABAP Test Cockpit** pod konwersję nie sprawdza bezpieczeństwa kodu, bo kontrole bezpieczeństwa dostarcza osobno licencjonowany **SAP Code Vulnerability Analyzer**, a licencja z SAP ERP nie przechodzi na SAP S/4HANA,
**4/** systemy nieprodukcyjne i produkcyjne stoją w RISE w tej samej sieci wirtualnej - z powodów, które SAP opisuje wprost, i o których wasz sandboks konwersyjny powinien wiedzieć.
---
## Trzy zdania, które brzmią rozsądnie i nie są prawdziwe
### „System jest zamrożony, więc jest stabilny”
To najczęstsze założenie w programach konwersji i najbardziej kosztowne. SecurityBridge opisał je w styczniu 2026 jednym zdaniem, które warto powiesić w pokoju projektowym: *freezing functional changes does not equal freezing security risks*. Zamrażacie zmiany biznesowe. Nie zamrażacie kalendarza publikacji podatności.
Przez ten czas w starym krajobrazie zwykle nie działa ciągła ocena podatności, nikt nie patrzy na kod własny, interfejsy i połączenia RFC, a kontrole zostają ręczne. Polityka „żadnych zmian” daje przy tym poczucie bezpieczeństwa, które nie ma pokrycia: atakującego nie obowiązuje wasz change freeze, a wasze systemy w tym okresie są przewidywalne jak nigdy. Jeżeli chcecie zobaczyć, co miesięcznie trafia na tę listę, zajrzyjcie do naszego [zestawienia z wrześniowego SAP Security Patch Day](/pl/aktualnosci/blog/bezpieczny-wtorek-sap-patch-day-wrzesien-2026/) - cztery noty krytyczne w czterech różnych warstwach, w miesiącu uznanym za spokojny.
### „Przechodzimy na RISE, więc bezpieczeństwo bierze SAP”
W modelu RISE with SAP przesuwa się granica odpowiedzialności. Sama odpowiedzialność zostaje tam, gdzie była. SAP prowadzi centra danych, sieć, maszyny wirtualne, system operacyjny, bazę HANA, kopie zapasowe, monitorowanie całodobowe i zarządzanie incydentami warstwy technicznej. Po waszej stronie zostaje konfiguracja aplikacji, tożsamość użytkowników, role i kontrola dostępu, dziennik audytu, integracje, rozwój własny i zgodność z regulacjami.
To jeszcze nie jest zaskoczenie, bo model współdzielonej odpowiedzialności zna każdy, kto pracował z chmurą publiczną. Zaskoczeniem bywają trzy szczegóły z opublikowanego przez SAP zestawu odpowiedzi na pytania o cyberbezpieczeństwo SAP S/4HANA Cloud Private Edition.
**Pierwszy.** System operacyjny i bazę SAP łata regularnie samo. Ale przy łatkach bezpieczeństwa warstwy technicznej Basis rola się zmienia: SAP przegląda dostępne poprawki i przygotowuje przetestowane paczki wdrożeniowe, natomiast - jak stoi w tym materiale - to klient zgodnie z umową składa wniosek o ich wdrożenie i godzi się na przestój w oknie utrzymaniowym. Wniosek trafia do SAP przez kokpit klienta. Nikt nie wgra wam łatki Basis dlatego, że wyszła.
**Drugi.** Test penetracyjny i skan podatności możecie przeprowadzić wyłącznie na warstwie aplikacji i wyłącznie po zatwierdzeniu przez SAP. Jeżeli chcecie niezależny test przed uruchomieniem produkcyjnym, to jest pozycja w harmonogramie z wyprzedzeniem liczonym w tygodniach, a nie zadanie, które ktoś dorzuci w tygodniu cutoveru.
**Trzeci, najciekawszy dla architektów.** Systemy deweloperskie, testowe i produkcyjne stoją w tej samej sieci wirtualnej. SAP podaje powód wprost: bez tego nie działa logistyka oprogramowania, czyli transporty i kopie klienta. To nie jest luka, to projekt. Oznacza jednak, że system projektowy waszej konwersji nie jest osobną wyspą, tylko sąsiadem produkcji.
### „Konwersja techniczna wyszła, więc system jest bezpieczny”
Testy konwersyjne sprawdzają, czy proces się zamyka, czy dokument się księguje, czy raport zwraca to samo. Nie sprawdzają, czy program, który to robi, ma kontrolę uprawnień. O tym, jak rozdzielamy te dwa pytania w testach, pisaliśmy przy okazji [testów SAP S/4HANA przy konwersji i przed go-live](/pl/aktualnosci/blog/testy-sap-uipath-test-cloud-konwersja-go-live/). Tutaj wystarczy jedno zdanie: zielony wynik testu funkcjonalnego nie jest dowodem w sprawie bezpieczeństwa i nikt nigdy nie twierdził, że jest.
---
## Cztery rzeczy, które konwersja mnoży
Program konwersji nie wymyśla nowych klas podatności. On mnoży i uprawomocnia te, które w normalnym utrzymaniu byłyby wyjątkiem wymagającym zgody.
**Kopie produkcji.** Testy akceptacyjne bez danych produkcyjnych nie mają wartości, więc kopie powstają - zwykle kilka, w kilku środowiskach, przez kilkanaście miesięcy. Kopia niesie nie tylko dane osobowe, które widzi inspektor ochrony danych. Niesie także definicje połączeń RFC, konta techniczne i relacje zaufania. System projektowy ma luźniejsze role, słabszy nadzór i rzadko trafia do monitorowania.
Warto nazwać wnioski z tego wprost, bo w rozmowach o konwersji zwykle padają osobno. Kopia produkcji to nie jest wyłącznie temat ochrony danych osobowych. To jest system, który potrafi zalogować się tam, gdzie potrafił logować się oryginał - z tymi samymi definicjami połączeń i tymi samymi kontami technicznymi, tylko z gorszymi rolami, bez monitorowania i z listą osób mających dostęp, której nie zatwierdzał nikt poza kierownikiem projektu. Ryzyko nie polega na tym, że ktoś wykradnie dane z sandboksu. Polega na tym, że wejdzie do sandboksu, a wyjdzie w systemie, który księguje.
**Dostęp uprzywilejowany z datą ważności, której nikt nie wpisał.** Integrator, jego podwykonawcy, konta serwisowe, uprawnienia awaryjne „na czas projektu”. Te kategorie rzadko mają właściciela po stronie klienta, a jeszcze rzadziej termin wygaśnięcia zapisany w systemie, a nie w umowie. SecurityBridge wskazuje nadmiarowe uprawnienia jako jedną z rzeczy, które organizacje przenoszą do nowego środowiska razem z danymi - i ma rację, bo czyszczenie ról w trakcie programu nie ma w harmonogramie ani jednego kamienia milowego.
**Kod własny.** O tym za chwilę osobno, bo to najgorzej rozumiany punkt całej listy.
**Ścieżki, których nikt nie monitoruje.** Joris van de Vis z SecurityBridge opisał to w sierpniu 2026 celnie: w SAP do jednego efektu biznesowego prowadzi wiele dróg technicznych, a monitorowana jest zwykle jedna, standardowa transakcja. Drogi poboczne to mniej znane transakcje, mechanizmy transportowe, rozwój własny, interfejsy i procesy w tle. W cutoverze każda z nich pracuje na najwyższych obrotach, a kontrola zmiany działa w trybie awaryjnym. Jego wniosek jest prosty i niewygodny: kontrolujcie skutek, nie tylko proces.
Te cztery mechanizmy nie działają równomiernie. Najdłuższe okno to zamrożony krajobraz wyjściowy i najczęściej nikt nie jest jego właścicielem, bo zespół utrzymania czeka na nowy system, a zespół projektowy patrzy na docelowy. Najintensywniejsze okno to cutover, w którym kontrola zmiany pracuje w trybie awaryjnym z definicji. Najbardziej niedoceniane są pierwsze dwa tygodnie po uruchomieniu - wrócimy do nich osobno, bo to jedyny moment w całym programie, w którym nowy system jest jednocześnie produkcyjny i nieobserwowany.
---
## „Odpaliliśmy ATC” - co ten skan naprawdę pokrył
To zdanie pada na każdym przeglądzie programu konwersji i prawie zawsze znaczy coś innego, niż myśli osoba, która je słyszy.
**ABAP Test Cockpit** dostarcza infrastrukturę kontroli oraz kontrole poprawności funkcjonalnej i wydajności. Kontrole bezpieczeństwa dostarcza **SAP Code Vulnerability Analyzer**, zbudowany na tej samej infrastrukturze, ale będący osobnym, osobno licencjonowanym produktem. Wariant kontroli, który uruchamia wyłącznie analizator podatności, nazywa się SLIN_SEC. Wariant, który uruchamia wasz zespół konwersyjny, sprawdza gotowość na SAP S/4HANA i elementy uproszczeń, bo to one blokują go-live. Bezpieczeństwo kodu nie blokuje niczego, więc nie wchodzi do przebiegu „przy okazji”.
Trzy fakty z materiału SAP, które w programie konwersji zmieniają rozmowę:
- licencja jest liczona per użytkownik, z pułapem stu użytkowników, a użytkownikiem jest także osoba, która tylko czyta wyniki skanu,
- analizator można **aktywować bez licencji** - system pokaże wtedy ostrzeżenie, i tyle,
- **licencja z SAP ERP nie przechodzi na SAP S/4HANA**, potrzebna jest nowa.
Ten ostatni punkt jest dla programu konwersji krytyczny, bo dotyka firm, które akurat robiły wszystko dobrze. Skanowaliście kod na SAP ECC przez lata, macie proces, macie wyjątki, macie historię. Po konwersji stoicie z tym samym procesem i bez licencji, dokładnie w momencie, w którym baza kodu zmieniła się najbardziej.
Do tego dochodzą trzy ograniczenia, o których warto wiedzieć, zanim ktoś pokaże zarządowi zielony wykres:
**Pierwszy przebieg daje tysiące znalezisk.** Tak opisuje to sam SAP. To nie jest powód, żeby nie skanować - to powód, żeby ustalić segregację znalezisk, właściciela i kryteria zamknięcia, zanim uruchomicie skan, a nie po.
**Analiza przepływu danych nie przekracza jednostki kompilacji.** Jeżeli skanujecie raport, który woła moduł funkcyjny, podatność w tym module nie zostanie znaleziona. Musicie przeskanować moduł. Zielony wynik mówi wtedy o zakresie skanu, a nie o stanie systemu.
**Znalezisko nie blokuje wydania.** W standardzie znaleziska priorytetu trzeciego nie zatrzymują transportu, a produkt można wydać z otwartymi znaleziskami. Narzędzie nie podejmie za was decyzji o ryzyku. Ono tylko sprawia, że decyzja jest świadoma.
Jeżeli kod własny jest u was dużym tematem, mamy o nim osobny wpis o [nieoczywistych zagrożeniach w kodzie ABAP](/pl/aktualnosci/blog/bezpieczny-wtorek-ze-snok-kod-abap-nieoczywiste-zagrozenie-bezpieczenstwa-system/), a o tym, co do tego równania dokłada kod pisany przez asystentów, pisaliśmy [tutaj](/pl/aktualnosci/blog/bezpieczenstwo-kodu-abap-generowanego-przez-ai/).
---
## Cutover i dwa tygodnie, których nikt nie pilnuje
Cutover to jedyny moment w programie, w którym wszystkie cztery mechanizmy pracują naraz. W ciągu jednej doby albo dwóch jedzie komplet transportów, przełączane są integracje, konta techniczne dostają nowe hasła albo zachowują stare, a kontrola zmiany działa w trybie, który zespół sam nazywa awaryjnym. To nie jest zaniedbanie - tak wygląda każde przełączenie systemu, który obsługuje firmę. Problem zaczyna się przy zdaniu, które pada wtedy w każdej organizacji: „nie cofamy, bo wycofanie kosztuje tydzień przestoju".
W zwykłym utrzymaniu transport z brakiem kontroli uprawnień utyka na bramce. W cutoverze przechodzi, bo kryterium brzmi „czy się aktywuje", a nie „czy jest bezpieczny". Różnica nie leży w narzędziach. Leży w tym, że przez dwie doby koszt zatrzymania czegokolwiek jest wyższy niż koszt przepuszczenia.
Potem przychodzi część jeszcze gorzej opisana. Przez pierwsze dwa tygodnie po uruchomieniu cały zespół pilnuje wydajności, zamknięcia okresu i tego, czy dokumenty się księgują. Monitorowanie bezpieczeństwa nowego systemu zwykle jeszcze nie działa w pełnym zakresie, bo reguły alertowania dostraja się „jak już się uspokoi". To znaczy, że **najgorętszy okres w całym programie jest jednocześnie jedynym, z którego nie macie danych**. Jeżeli coś wydarzyło się w cutoverze, dowiecie się o tym z innego źródła niż własny dziennik zdarzeń.
Obowiązki regulacyjne nie robią w tym czasie przerwy - o tym za moment osobno. Tu wystarczy jedna obserwacja: zegar na zgłoszenie incydentu rusza od wykrycia, a nie od momentu, w którym zespół projektowy uzna, że ma czas.
---
## Co wpisać w kryteria przejścia
Najtańsza zmiana w całym programie kosztuje jedno zdanie w dokumencie, który już istnieje. Kryteria przejścia między fazami i kryteria dopuszczenia do uruchomienia produkcyjnego są spisane, uzgodnione i podpisywane. Wystarczy, że znajdą się w nich cztery pozycje, które dzisiaj zwykle są tylko czyimś zmartwieniem.
**Stan wyjściowy zmierzony przed zamrożeniem.** Konfiguracja, uprawnienia i kod w SAP ECC opisane liczbami w dniu, w którym wchodzi change freeze. Bez tego zdjęcia nie udowodnicie po roku, co przenieśliście, a czego nie, a audytor zapyta.
**Próg blokujący dla znalezisk w kodzie.** Nie „przeskanujemy kod”, tylko: który priorytet zatrzymuje transport, kto może udzielić odstępstwa i na jaki czas. Narzędzie w standardzie nie zatrzyma transportu za was.
**Wygaszenie dostępu projektowego jako kamień milowy.** Uprawnienia awaryjne, konta integratora i konta serwisowe z datą w systemie, nie w umowie, i z zadaniem odbioru po cutoverze.
**Monitorowanie działające przed uruchomieniem, nie po.** Dziennik audytu bezpieczeństwa, zbieranie zdarzeń i reguły alertowania włączone i przetestowane w systemie docelowym przed go-live. Jeżeli pierwszy tydzień produkcji jest też pierwszym tygodniem monitorowania, nie macie danych z najgorętszego okresu w całym programie.
Nad tymi czterema pozycjami stoi pytanie o właściciela. Program konwersji ma kierownika, architekta, właścicieli procesów i partnera wdrożeniowego. Rzadko ma kogoś, kto ma **wypisane prawo zatrzymania uruchomienia** z powodu bezpieczeństwa. Jeżeli takiej osoby nie ma, to znaczy, że decyzję o ryzyku podejmuje harmonogram.
---
## Sześć pytań, które warto zadać na komitecie sterującym
To nie jest lista narzędzi do kupienia. To sześć pytań, na które program konwersji albo ma odpowiedź, albo właśnie znaleźliście temat na najbliższy przegląd.
**1.** Kto ma prawo zatrzymać go-live z powodu bezpieczeństwa i czy to prawo jest zapisane w kryteriach przejścia, czy tylko w czyjejś intencji?
**2.** Ile kopii produkcji istnieje dzisiaj, kto jest właścicielem każdej z nich i które z nich mają aktywne połączenia RFC do systemów, które nadal księgują?
**3.** Jaka jest data wygaśnięcia uprawnień awaryjnych integratora i gdzie ta data jest wpisana w systemie, a nie w umowie?
**4.** Czy w przebiegach ABAP Test Cockpit działa wariant bezpieczeństwa, kto jest właścicielem znalezisk i jaki próg blokuje transport?
**5.** Kto po przejściu do RISE with SAP składa wniosek o łatkę bezpieczeństwa, w jakim czasie i kto akceptuje przestój?
**6.** Kiedy złożyliście wniosek o zgodę na test penetracyjny przed uruchomieniem produkcyjnym, skoro wymaga on zatwierdzenia przez SAP i dotyczy wyłącznie warstwy aplikacji?
Pytanie szóste w większości programów nie ma odpowiedzi, bo nikt go nie zadał na czas. To jest dobry moment, żeby je zadać.
---
## Regulator nie czeka na wasz cutover
Ta część dotyczy wyłącznie polskiego rynku i w materiałach producentów nie występuje, bo tam jej nie ma.
Program konwersji, który zaczyna się dzisiaj, kończy się w oknie, w którym obowiązki z ustawy o krajowym systemie cyberbezpieczeństwa są już w pełni egzekwowane. Liczy się w nich czas od wykrycia incydentu, a nie od momentu, w którym zespół projektowy skończył cutover: dwadzieścia cztery godziny na wczesne ostrzeżenie i siedemdziesiąt dwie godziny na zgłoszenie incydentu poważnego. Zestawcie to z realiami programu konwersji. Incydent w systemie projektowym z kopią produkcji, wykryty w weekend przełączeniowy, przez zespół, który w tym momencie ma inne zadanie, i przy monitorowaniu uruchamianym dopiero po go-live. Zegar rusza mimo to.
Drugi wniosek jest przyjemniejszy. Ten sam program jest najlepszą okazją w dekadzie, żeby wejść w te obowiązki z porządną dokumentacją, bo i tak opisujecie systemy, przepływy danych, role i dostawców. Rozpisaliśmy to osobno we [wpisie o ustawie o KSC i NIS2 w kontekście systemów SAP](/pl/aktualnosci/blog/ksc-nis2-sap-securitybridge/).
---
## Gdzie w tym stoi SecurityBridge
Deklaracja wprost: SNOK jest partnerem SecurityBridge i wdrażamy tę platformę u klientów. Dlatego napiszemy to precyzyjnie, a nie hasłowo.
SecurityBridge nie zastępuje SAP Code Vulnerability Analyzer i nie rozwiązuje kwestii licencji po stronie SAP. Pokrywa natomiast dokładnie tę warstwę, która w modelu RISE with SAP zostaje po waszej stronie: ciągłą ocenę podatności i konfiguracji, monitorowanie aktywności użytkowników i ruchu na interfejsach, analizę kodu własnego oraz dopasowanie do ram zgodności. W programie konwersji sensowne miejsca są cztery: zdjęcie stanu wyjściowego SAP ECC **przed** zamrożeniem, nadzór nad zamrożonym krajobrazem **w trakcie**, kontrola kodu i transportów **w toku projektu** oraz porównanie stanu docelowego ze stanem wyjściowym **przed** go-live. Piąte miejsce zaczyna się dzień po uruchomieniu i trwa tak długo, jak system.
Jeżeli chcecie zobaczyć, jak to wygląda w naszej praktyce, opisaliśmy platformę na [osobnej stronie](/pl/securitybridge-snok/).
---
## Jedna rzecz od nas
Zakończyliśmy właśnie wdrożenie w jednej z największych instytucji publicznych w Polsce korzystających z SAP. Szczegóły wkrótce, w zakresie, na jaki pozwoli nam umowa. Wspominamy o tym w tym miejscu nie przypadkiem: to, co opisaliśmy wyżej, nie jest teorią z prezentacji dostawcy, tylko listą rzeczy, które trzeba rozstrzygnąć w prawdziwym programie, z prawdziwym terminem i prawdziwym audytem na końcu.
## Na koniec, najkrócej jak się da
Konwersja do SAP S/4HANA nie jest ryzykowna dlatego, że ktoś zaniedbał bezpieczeństwo. Jest ryzykowna dlatego, że **wszystkie decyzje, które ją otwierają, są osobno rozsądne**. Zamrożenie zmian chroni stabilność. Kopie produkcji są warunkiem sensownych testów. Uprawnienia awaryjne pozwalają integratorowi pracować. Wariant ATC pod konwersję odblokowuje uruchomienie. RISE with SAP zdejmuje z was infrastrukturę. Każda z tych rzeczy ma dobre uzasadnienie i żadna z nich nie ma w harmonogramie miejsca, w którym ktoś pyta, co z nich razem wynika.
Dlatego całą tę listę da się sprowadzić do jednego pytania, które warto zadać na najbliższym komitecie sterującym: **kto w tej firmie ma prawo zatrzymać uruchomienie produkcyjne z powodu bezpieczeństwa i gdzie to prawo jest zapisane**. Jeżeli odpowiedź brzmi „nikt" albo „nie wiem", to decyzję o ryzyku podejmuje harmonogram, a harmonogram nie odpowie potem przed audytorem.
Jeżeli prowadzicie dzisiaj [taki program](/pl/oferta/bezpieczenstwo-sap/konwersja-s4hana/) i któreś z sześciu pytań zostało bez odpowiedzi, [napiszcie do nas](/pl/kontakt/). Przejdziemy je z waszym zespołem.
---
### Źródła
- SecurityBridge, Jephy Pothen, *Security by Design in the Age of S/4HANA and SAP RISE Migrations*, 13 stycznia 2026 - [securitybridge.com](https://securitybridge.com/blog/security-by-design-in-the-age-of-s-4hana-and-rise-with-sap-migrations/)
- SecurityBridge, Joris van de Vis, *Breaking the Rules: Why Standard SAP Controls Are Not Enough*, 20 sierpnia 2026 - [securitybridge.com](https://securitybridge.com/blog/why-standard-sap-controls-are-not-enough/)
- SAP Community, Jana Subramanian, *RISE with SAP S/4HANA Cloud, Private Edition: Cybersecurity FAQ Explained* - [community.sap.com](https://community.sap.com/t5/technology-blog-posts-by-sap/rise-with-sap-s-4hana-cloud-private-edition-cybersecurity-faq-explained/ba-p/13562875)
- SAP Community, *SAP Code Vulnerability Analyzer (CVA) - FAQs* - [community.sap.com](https://community.sap.com/t5/application-development-and-automation-blog-posts/sap-code-vulnerability-analyzer-cva-faqs/ba-p/13486106)
- SAP, *Maintenance strategy - SAP S/4HANA and SAP Business Suite 7* - [support.sap.com](https://support.sap.com/en/release-upgrade-maintenance/maintenance-information/maintenance-strategy/s4hana-business-suite7.html)
Zakres odpowiedzialności w RISE with SAP opisujemy za materiałem opublikowanym przez SAP. W konkretnej umowie rozstrzyga dokument Roles and Responsibilities oraz warunki kontraktu - sprawdźcie własne, zanim oprzecie na tym decyzję.
---
### TrustBroker 5.1 - SSO i MFA do SAP bez Active Directory
URL: https://snok.ai/pl/aktualnosci/blog/trustbroker-5-1-sso-mfa-sap-bez-active-directory/ | Data: 2026-09-15 | Seria: Bezpieczny Wtorek
Jeżeli w Waszej firmie ktoś pyta, po co jeszcze stoi Microsoft Active Directory, odpowiedź zwykle sprowadza się do jednego zdania: bo inaczej nie zadziała pojedyncze logowanie do **SAP**. Tożsamość pracowników przenieśliście do chmury lata temu, katalog lokalny miał zniknąć razem z ostatnią aplikacją, która go potrzebowała, a potem okazało się, że tą aplikacją jest SAP GUI. Kerberos wymaga kontrolera domeny, kontroler domeny wymaga lasu, las wymaga utrzymania, i tak przez dwadzieścia lat.
Trzeciego września 2026 SecurityBridge opublikował wydanie **TrustBroker 5.1.0**, w którym **OpenID Connect** jest wbudowany w bibliotekę **SNC**. To brzmi jak przypis w informacji o wersji, a jest zdjęciem jednej z przyczyn, dla których programy modernizacji tożsamości kończą się w osiemdziesięciu procentach.
**W skrócie:**
**1/** pojedyncze logowanie i uwierzytelnianie wieloskładnikowe do SAP GUI działają bez Active Directory pośrodku, natywnie z Microsoft Entra ID, Oktą, PingID, Keycloakiem i SAP Cloud Identity Services,
**2/** Kerberos nie znika, zostaje wspierany w tej samej bibliotece, więc przechodzicie system po systemie, we własnym tempie,
**3/** logowanie do SAP GUI można teraz chronić uwierzytelnianiem odpornym na phishing - Windows Hello for Business, passkeys, tokeny FIDO2,
**4/** ruch między SAP GUI a systemem SAP jest szyfrowany wymianą kluczy odporną na komputery kwantowe.
---
## Zależność, której nikt świadomie nie wybierał
Pojedyncze logowanie do SAP GUI opiera się o warstwę SNC, czyli Secure Network Communications - interfejs, przez który SAP przyjmuje uwierzytelnienie wykonane na zewnątrz jądra. Biblioteka SNC podstawiona pod ten interfejs mówiła dotąd jednym językiem: Kerberos. A Kerberos w praktyce korporacyjnej znaczy Active Directory.
Dla zespołu bezpieczeństwa wynikają z tego dwa fakty, które warto trzymać osobno. Pierwszy jest organizacyjny: katalog, który miał być wygaszany, musi żyć, być łatany i audytowany, bo trzyma logowanie do systemu księgującego. Drugi jest architektoniczny i mniej oczywisty - skoro dostęp do ERP wisi na Kerberosie, to przejęcie konta w domenie jest równoznaczne z wejściem do SAP, a dodatkowe warstwy kontroli tożsamości, które zbudowaliście w chmurze, po prostu w tej ścieżce nie występują. Pisaliśmy o tym szerzej przy okazji [budowania Zero Trust dla tożsamości w świecie SAP](/pl/aktualnosci/blog/bezpieczny-wtorek-ze-snok-jak-budowac-zero-trust-dla-tozsamosci-w-swiecie-sap/) - zasada „nigdy nie ufaj, zawsze weryfikuj” zatrzymuje się tam, gdzie kończy się bilet Kerberosa.
## Co dokładnie zmieniło się w bibliotece SNC
TrustBroker 5.1.0 wnosi OpenID Connect do samej biblioteki SNC. Użytkownik loguje się do SAP GUI, a uwierzytelnienie leci do dostawcy tożsamości, którego już macie - producent wymienia Microsoft Entra ID, Oktę, PingID, Keycloaka i SAP Cloud Identity Services, dawniej IAS. Active Directory nie jest w tej ścieżce potrzebne.
Istotny jest szczegół wdrożeniowy, bo to on decyduje, czy temat w ogóle przejdzie przez architekturę. Uwierzytelnianie działa wewnątrz serwerów aplikacyjnych SAP. Producent pisze wprost, że nie dochodzi nowa infrastruktura ani zewnętrzne komponenty do łatania i utrzymania. Dla zespołu Basis oznacza to brak kolejnego serwera pośredniczącego w krytycznej ścieżce logowania, a dla zespołu bezpieczeństwa brak kolejnej powierzchni, którą trzeba objąć zarządzaniem podatnościami.
## Kerberos nie odchodzi, więc migracja jest etapowa
To zdanie z materiału producenta warto przeczytać dwa razy, bo rozstrzyga o kształcie projektu: Kerberos zostaje w pełni wspierany w bibliotece SNC. Nie ma daty wyłączenia, nie ma trybu przejściowego z terminem, nie ma sytuacji, w której podnosicie wersję i tracicie działające logowanie.
W praktyce znaczy to, że przechodzicie system po systemie. Zaczynacie od jednego środowiska, najlepiej takiego, w którym awaria logowania nie zatrzymuje księgowania, potwierdzacie zachowanie klienta SAP GUI i polityki, a dopiero potem ruszacie produkcję. Program, w którym odłączenie Active Directory jest jedną wielką zmianą w jeden weekend, jest programem, którego nie trzeba planować w ten sposób.
## Uwierzytelnianie odporne na phishing wchodzi do SAP GUI
Druga zmiana jest dla CISO ważniejsza niż pierwsza. Logowanie do SAP GUI można chronić metodami bezhasłowymi: Windows Hello for Business, passkeys i tokenami FIDO2.
Różnica wobec kodu jednorazowego nie jest kosmetyczna. Kod z aplikacji albo z wiadomości SMS użytkownik potrafi przepisać do okna, które wygląda jak Wasze, ale nim nie jest, a atakujący przepisze go dalej do prawdziwego logowania. Uwierzytelnianie odporne na phishing wiąże poświadczenie z konkretną domeną i konkretnym urządzeniem, więc nie ma czego przepisać. Jak wygląda atak, który omija drugi składnik bez łamania kryptografii, opisywaliśmy przy [kampanii Kali365 nadużywającej przepływu OAuth device code](/pl/aktualnosci/blog/bezpieczny-wtorek-ze-snok-kali365-phishing-oauth-device-code/) - tam ofiara sama oddawała dostęp, mając włączone MFA.
Dotąd rozmowa o silnym uwierzytelnianiu w SAP zwykle kończyła się na Fiori i na dostępie z przeglądarki, bo tam dało się to zrobić bez przebudowy. SAP GUI zostawał na boku, chociaż to w nim siedzą transakcje o największej wadze finansowej i to z niego korzystają administratorzy. Ta asymetria właśnie się domyka.
## Klucze przygotowane na erę komputerów kwantowych
Trzecia zmiana dotyczy warstwy sieciowej: ruch między SAP GUI a systemami SAP jest chroniony wymianą kluczy odporną na komputery kwantowe. Chodzi o scenariusz „zbierz teraz, odszyfruj później”, w którym ktoś nagrywa dziś sesję, a odszyfrowuje ją za lat kilkanaście, kiedy dzisiejsze szyfrowanie przestanie być barierą. Dla danych kadrowych, cenników i warunków kontraktów okres poufności bywa dłuższy niż horyzont, który zwykle zakładamy.
To temat, który wraca w naszych rozmowach coraz częściej i który rozwijaliśmy w tekście o [szyfrowaniu w erze komputerów kwantowych](/pl/aktualnosci/blog/bezpieczny-wtorek-ze-snok-quantum-i-postquantum-security-w-erze-ai-czy-twoje-szy/). Tutaj wystarczy uwaga praktyczna: producent nazywa mechanizm „quantum-safe key exchange” i nie podaje ani algorytmu, ani tego, czy tryb jest hybrydowy. Jeżeli macie własną politykę kryptograficzną, to jest pierwsze pytanie do zadania przed pilotażem.
## To nie jest wyłącznie logowanie
TrustBroker sam w sobie nie jest nowością, nowe jest wydanie. Warto o tym pamiętać, bo produkt robi coś więcej, niż wpuszcza użytkownika do systemu. Polityki uwierzytelniania leżą na każdym systemie SAP osobno i to administrator po Waszej stronie decyduje, kiedy polityka jest sprawdzana i jaka metoda wystarcza.
Stąd bierze się mechanizm, który w rozmowach z CFO broni się najlepiej: podniesienie wymagań już po zalogowaniu. Użytkownik wchodzi przez pojedyncze logowanie, pracuje normalnie, a kiedy otwiera wrażliwą transakcję albo dane, których nie otwiera na co dzień, system prosi o mocniejsze potwierdzenie tożsamości. Producent wymienia wśród warunków między innymi nietypową porę dostępu, inne urządzenie lub lokalizację oraz historię aktywności użytkownika, a w połączeniu z platformą SecurityBridge także alerty z wykrywania zagrożeń.
## Gdzie to działa
Producent wymienia serwery aplikacyjne SAP: RISE with SAP S/4HANA Cloud Private Cloud Edition, SAP S/4HANA w instalacji własnej, SAP NetWeaver AS for ABAP, SAP BW/4HANA, SAP NetWeaver AS for Java oraz SAP BusinessObjects BI Platform. Wydanie 5.1.0 działa na serwerach Linux i Windows oraz na stacjach roboczych macOS i Windows; pozostałe platformy Unix, w tym AIX, mają trafić do późniejszego wydania. Doszło wsparcie dla Red Hat Enterprise Linux 10, SUSE Linux Enterprise Server 16 i SAP GUI 8.10, jest też certyfikacja Citrix Ready, więc sesje w Citrix Virtual Apps and Desktops korzystają z tego samego przepływu.
Dla klientów w modelu RISE ważne jest jedno zdanie: producent deklaruje, że rozwiązanie jest dopuszczone dla RISE with SAP. To argument, który zdejmuje pierwszą obiekcję, jaka pada przy każdym pomyśle dołożenia czegokolwiek do systemu utrzymywanego przez SAP.
## Czego w materiale producenta nie ma
Piszemy o tym osobno, bo lista rzeczy niepotwierdzonych jest częścią rzetelnej oceny produktu, a nie przypisem.
Deklaracje o certyfikacji SAP i o dopuszczeniu dla RISE with SAP pochodzą ze strony producenta. Nie znaleźliśmy publicznego dokumentu SAP, który potwierdza je niezależnie, i przed decyzją poprosimy o numer scenariusza integracyjnego. Materiał nie mówi też, które przepływy OpenID Connect są obsługiwane ani jak rozwiązanie zachowuje się przy odświeżaniu tokenu w długiej sesji SAP GUI. Opisany jest klient SAP GUI dla Windows w wersji 8.10, więc zachowania dla SAP GUI for Java i dla SAP Business Client trzeba potwierdzić osobno. Nie ma publicznego cennika ani informacji o minimalnym poziomie jądra po stronie systemu SAP. Warto też wiedzieć, że strona produktowa jest starsza niż samo wydanie i nadal opisuje przepływ oparty o Active Directory - lista dostawców tożsamości jest na niej aktualna, narracja nie.
## Sześć pytań przed pilotażem
**1/** Który system bierzecie pierwszy i co się dzieje, gdy logowanie w nim przestanie działać w środę rano
**2/** Kto po Waszej stronie jest właścicielem polityki uwierzytelniania na poziomie systemu SAP, skoro polityka leży na każdym systemie osobno
**3/** Jakie metody bezhasłowe macie już wdrożone dla pozostałych aplikacji i czy SAP wejdzie w ten sam schemat rejestracji urządzeń
**4/** Które transakcje uznajecie za wrażliwe na tyle, żeby wymagały potwierdzenia tożsamości po zalogowaniu, i kto to zatwierdza
**5/** Co zostaje w Active Directory po odłączeniu SAP i jaki jest wtedy harmonogram wygaszania katalogu
**6/** Jak wygląda ścieżka awaryjna dla administratora, kiedy dostawca tożsamości jest niedostępny, a system produkcyjny wymaga interwencji
Pytanie szóste w większości rozmów zostaje bez odpowiedzi dłużej niż pozostałe pięć razem wzięte, a to ono decyduje o tym, czy projekt jest gotowy do produkcji.
## Jak podchodzimy do tego w SNOK
[SecurityBridge jest naszym partnerem technologicznym](/pl/securitybridge-snok/), [wdrażamy i utrzymujemy tę platformę](/pl/oferta/bezpieczenstwo-sap/securitybridge/) u klientów, i mówimy o tym wprost, zanim padnie pierwsza rekomendacja. Nie twierdzimy przy tym, że TrustBroker jest jedynym rozwiązaniem tego problemu - pojedyncze logowanie i uwierzytelnianie wieloskładnikowe do SAP da się zbudować także inaczej, a wybór zależy od tego, gdzie trzymacie tożsamość, jak wygląda Wasz krajobraz i co już działa.
To, co wnosi wydanie 5.1, jest natomiast zmianą w warunkach zadania, a nie w ofercie jednego dostawcy. Jeżeli Active Directory zostało u Was przy życiu głównie dla SAP, macie teraz argument, żeby wrócić do tej rozmowy z architektem tożsamości. Jeżeli chcecie, żebyśmy przeszli przez sześć pytań powyżej na Waszym krajobrazie, [odezwijcie się do nas](/pl/kontakt/) - zaczynamy od przeglądu obecnej ścieżki logowania, nie od demonstracji produktu.
---
*Materiał opisuje stan wiedzy na 14 września 2026 i opiera się o informacje opublikowane przez producenta. Zakres wsparcia, certyfikacje i warunki licencyjne potwierdzajcie w dokumentacji SecurityBridge oraz w swojej umowie przed podjęciem decyzji.*
---
### UiPath Delegate w public preview - agent na biurku, który działa Waszymi uprawnieniami
URL: https://snok.ai/pl/aktualnosci/blog/uipath-delegate-public-preview/ | Data: 2026-09-14 | Seria: Inne
Sześć tygodni temu [pisaliśmy o Delegate](https://snok.ai/pl/aktualnosci/blog/uipath-delegate-agent-dla-osoby/) jako o zapowiedzi. Produkt siedział na UiPath Labs ze statusem „coming soon”, nie miał strony w dokumentacji, nie miał instalatora i nie miał znanego modelu licencyjnego. Pisaliśmy wtedy, że to najwygodniejszy moment na przygotowanie decyzji, bo można je podjąć przed premierą, a nie w jej trakcie.
Ten moment się skończył. Od 26 sierpnia Delegate jest w public preview. Ma dokumentację produktową na ponad czterdziestu stronach pod własną nazwą - *Delegate & Cartographer user guide* - instalator, trzy profile, licznik zużycia i komplet polityk nadzoru w Automation Ops. Możecie go zainstalować dzisiaj.
Jest też sygnał, którego nie da się przecenić, a który przepadł w komunikatach o premierze. W notach wydawniczych Automation Cloud za drugą połowę sierpnia stoi jedno zdanie:
> „Task Mining in Automation Cloud Public Sector is being retired, effective September 1, 2026, to redirect resources toward Delegate - Cartographer.”
Producent wygasza działający produkt, żeby przesunąć zasoby na Delegate. To nie jest komunikacja marketingowa, tylko decyzja o alokacji zespołu zapisana w notach wydawniczych. Delegate przestał być eksperymentem obok platformy i stał się jej częścią.
Poniżej rozkładamy go na części: co dokładnie robi, z czego się składa, co musicie mieć, ile to kosztuje i - najważniejsze - które ustawienia trzeba przesądzić centralnie, zanim pierwszy MSI trafi na pierwszą stację roboczą.
## Czym Delegate jest, według producenta
Definicja otwierająca dokumentację jest gęsta i warto ją przeczytać dosłownie:
> „Governed AI agent on your desktop that completes tasks from plain-language instructions, can be taught a task by watching you do it once, and builds on your organization's existing automation.”
Trzy rzeczy w jednym zdaniu. Agent jest **nadzorowany**, przyjmuje polecenia **zwykłym językiem** i uczy się **przez obserwację**. Czwarta rzecz jest w końcówce i jest dla Was najistotniejsza: buduje na tym, co już macie. Delegate woła automatyzacje opublikowane w Waszym tenancie, korzysta z Waszych kolejek, zasobów i uprawnień. Nie ma drugiego zestawu uprawnień do utrzymania.
Na tej samej stronie stoi ostrzeżenie, którego nie wolno pominąć przy planowaniu: „Delegate is in Public Preview. Features and behavior may change before general availability.”
*Główne okno Delegate. W pasku tytułu przełącznik Assistant / Delegate / Cartographer, w wierszu pod polem wpisywania cała warstwa kontroli: tryb zatwierdzania, kontekst ekranu, tryb wykonania i wybór modelu. Źródło: docs.uipath.com, Delegate & Cartographer user guide, dostęp 12.09.2026.*
### Pętla działania
Dokumentacja opisuje pracę Delegate w czterech krokach i ta czwórka jest całą architekturą produktu w pigułce.
1. **Pytacie.** Zwykłym językiem, w sesji.
2. **Delegate planuje.** Ustala kroki i narzędzia, których potrzebuje.
3. **Działa i pokazuje.** Każda czynność jest widoczna w trakcie. Możecie przerwać, poprawić albo przekierować w dowolnym momencie. Awaryjne zatrzymanie to klawisz Escape.
4. **Zatrzymuje się, kiedy powinien.** Operacje zmieniające dane, wysyłające wiadomości albo sięgające do systemów wrażliwych czekają na potwierdzenie - zależnie od trybu wykonania i od tego, na co pozwala organizacja.
Krok czwarty jest tym, który odróżnia Delegate od asystenta ogólnego przeznaczenia. Nie jest to uprzejmość modelu ani dobrze napisany prompt systemowy, tylko warstwa autoryzacji opisana dalej w tym tekście.
### Co potrafi
Producent wymienia pięć klas zadań i każda z nich jest innym profilem ryzyka, więc warto je rozróżniać.
**Zadania przechodzące przez kilka systemów.** Wyciągnięcie liczby z raportu i sprawdzenie powiązanego rekordu w CRM, poranny przegląd poczty i kalendarza, przygotowanie odpowiedzi po zebraniu reszty. Delegate obsługuje cały łańcuch, zamiast zwracać jeden krok.
**Nauka przez pokazanie.** „Perform a task once while Delegate watches, and it completes the remaining records.” Uzasadnienie producenta jest zaskakująco szczere: to jest przydatne tam, gdzie system nie ma użytecznego API, a pełna automatyzacja kosztowałaby więcej niż samo zadanie. Innymi słowy - Delegate celuje w pracę, która do tej pory nigdy nie przeszła progu opłacalności w klasycznym projekcie RPA.
**Zamiana danych w gotowy materiał.** Arkusz, eksport z bazy albo folder plików zamieniony w prezentację, ofertę albo raport, z zachowaniem Waszego formatowania.
**Praca przez własny interfejs systemu.** To jest nowość wobec lipca. Gdy system po drugiej stronie to udostępnia, Delegate renderuje jego prawdziwe ekrany wewnątrz rozmowy - listy, formularze, tabele, pulpity - a formularze przychodzą wstępnie wypełnione sensownymi wartościami. Mechanizm nazywa się **MCP Apps**. Zmieniacie tylko to, co istotne, zamiast opisywać każde pole w czacie.
**Zapis i ponowne użycie.** Udana sesja zapisuje się jako **Routine** - o tym osobna sekcja niżej.
## Trzy profile w jednej aplikacji
Delegate instaluje się obok UiPath Assistant i przełącza w pasku tytułu. Dostępność profili zależy od tego, co włączył administrator.
**General Productivity** to doświadczenie domyślne, dla każdego pracownika: praca przez aplikacje, pliki i usługi sieciowe.
**Cartographer** jest dla analityków biznesowych. Dokumentuje stan obecny, projektuje docelowy i generuje z tego dokumenty projektowe.
**Delegate for Testing** jest dla zespołów QA. Przegląda wyniki, segreguje awarie i wykonuje ręczne przypadki testowe.
### Cartographer, czyli następca Task Mining
To jest profil, o którym mówi zacytowane wyżej zdanie z not wydawniczych. Cel długoterminowy producent nazywa **Map of Work**: „a single, versioned, governed definition of how the business runs, so specifications, sign-off, and audit are generated from one source of truth instead of drifting documents that disagree with reality.”
Ambicja jest więc taka, żeby specyfikacja, odbiór i audyt powstawały z jednego źródła, zamiast rozjeżdżać się w dokumentach, które przestają odpowiadać rzeczywistości. Każdy, kto prowadził projekt wdrożeniowy dłużej niż rok, wie, o czym mowa.
Dziś Cartographer buduje model procesu z tego, co jest dostępne - transkryptów, wywiadów, instrukcji operacyjnych, nagrań - wskazuje luki, proponuje stan docelowy i generuje dwa dokumenty: **PDD** jako plik `.docx` do zatwierdzenia oraz **SDD** w Markdownie, przygotowany pod agentów kodujących. Ma też własny odpowiednik projektu, nazwany **Business Process**, i mechanizm oddelegowania pytania do współpracownika: wysyłacie odnośnik, osoba odpowiada w swoim Delegate, a odpowiedź wraca do Waszej rozmowy i jest przyjmowana albo odrzucana do wiedzy projektu. Warunek: ta sama organizacja i ten sam tenant.
Zmieniła się przy tym metoda, nie tylko nazwa produktu. Task Mining zbierał dane o pracy z rejestracji działań na stanowiskach. Cartographer zbiera je z rozmów, dokumentów i nagrań, a na wyjściu oddaje gotowy dokument projektowy.
### Delegate for Testing
Profil dla QA obsługuje pracę wokół testowania: przegląd wyników, triage awarii, zbieranie logów i zrzutów, aktualizację defektów, raporty. Wykonuje też ręczne przypadki testowe od pierwszego do ostatniego kroku i raportuje wyniki z powrotem do **Test Managera**, dołączając artefakty do logów kroków - co jest istotne, bo to właśnie te artefakty są dowodem w audycie.
Komunikacja z Test Managerem idzie przez **UiPath CLI (`uip`)**, wymaga więc zainstalowanego i uwierzytelnionego CLI. Licencje: **AppTestDeveloper** albo **AppTesters** z Test Cloud. Wtyczkę Test Cloud włącza się w `Settings → Skills & tools → Plugins`.
Jedno zastrzeżenie prosto z dokumentacji, żeby nie budować planów na nieporozumieniu: Testing „runs today inside the general-purpose experience rather than as its own separate profile”. To jest dopracowany zestaw umiejętności w ogólnym Delegate, a nie osobna aplikacja.
Jeżeli pracujecie nad regresją SAP, ten wątek łączy się wprost z tym, [co pisaliśmy o zaufaniu do release w testach SAP](https://snok.ai/pl/aktualnosci/blog/testowanie-sap-problem-zaufania-do-release/).
## Jak się go uczy
### Teach and Run
Mechanizm ma cztery kroki i jedną istotną właściwość.
1. Mówicie, czego chcecie nauczyć.
2. Wykonujecie zadanie na pierwszym rekordzie, Delegate patrzy - wymaga to włączonego kontekstu ekranu.
3. Delegate streszcza rozpoznany wzorzec, Wy go poprawiacie.
4. Po zatwierdzeniu dokańcza pozostałe rekordy.
Właściwość jest w ograniczeniach, które producent wymienia sam: mechanizm wymaga spójnego wzorca w kolejnych rekordach, dopytuje przy niejednoznaczności i **zatrzymuje się na rekordzie, który odbiega od wzorca**. To nie jest wada, tylko projekt. Agent, który przy nietypowym rekordzie zgaduje, zamiast zapytać, jest znacznie gorszą wiadomością niż agent, który staje.
### Routines - tu robi się poważnie
Routine to zapisana sesja z trzema elementami: **triggerem** (opisem w języku naturalnym, kiedy jej używać), **wejściami** (parametrami z typami) i **wyjściem** (formatem rezultatu), plus krokami do wykonania.
Da się ją utworzyć na trzy sposoby: z udanej sesji poleceniem „Save as Routine”, od zera w ustawieniach, albo ręcznie - jako plik `SKILL.md` w katalogu `LocalSkills` (na Windows `%APPDATA%/UiPath/Delegate/LocalSkills/`). Ten trzeci sposób oznacza, że Routine jest plikiem tekstowym, który da się trzymać w repozytorium, wersjonować i przeglądać w code review.
Routine można uruchomić z paska bocznego, wzmianką w rozmowie albo skrótem klawiszowym. Można ją **zaplanować** - raz, dziennie, tygodniowo albo miesięcznie, o konkretnej godzinie w strefie lokalnej, z wartościami stałymi albo pytaniem przy starcie, z uruchamianiem w tle i obsługą błędów. Można ją **wyeksportować** do ZIP-a albo samego `SKILL.md` i przekazać komuś innemu.
I tu jest miejsce, w którym trzeba na chwilę zatrzymać zachwyt. Routine z harmonogramem, parametrami i zapisanymi połączeniami jest automatyzacją produkcyjną. Jeżeli powstaje na stacji roboczej, poza Orchestratorem i poza jakimkolwiek rejestrem, to po pół roku macie drugą warstwę automatyzacji, której nikt nie inwentaryzował. Producent ostrzega przy okazji o rzeczy, która to potwierdza: zaplanowane rutyny korzystają z zapisanych połączeń, więc wygaśnięcie uwierzytelnienia po prostu przerywa wykonanie - i ktoś musi to zauważyć.
Istnieje też **Delegate Store** - katalog gotowych umiejętności i rutyn, „tested, documented, supported, and versioned by UiPath or trusted publishers”, z instalacją jednym kliknięciem. Organizacja może dodać własny kanał pod adresem URL. Dokumentacja podaje sygnały ostrzegawcze przed instalacją i jeden z nich brzmi znajomo dla każdego, kto patrzył ostatnio na bezpieczeństwo wtyczek AI: „requests tools unrelated to its stated purpose”. To jest dokładnie ta kategoria ryzyka, którą opisywaliśmy przy okazji [pytań, jakie warto zadać dostawcy](https://snok.ai/pl/aktualnosci/blog/agent-czy-przemianowany-robot/).
## Czym się łączy z resztą świata
**Integration Service** niesie uwierzytelnione połączenia do aplikacji chmurowych - Outlook, Gmail, Google Workspace, Slack, Teams, Jira, Confluence, GitHub, Salesforce i reszty katalogu. Działa Waszymi uprawnieniami, bez ujawniania haseł i bez automatyzacji przeglądarki.
**Serwery MCP** obsługują to, czego konektor nie obejmuje: własne API, lokalne bazy i narzędzia bez gotowej integracji. Działają zdalnie po HTTP albo lokalnie, jako proces na maszynie. Po włączeniu Delegate sam wykrywa udostępnione narzędzia.
**MCP Apps** renderują prawdziwe ekrany systemu wewnątrz rozmowy.
**Platforma UiPath** oddaje to, co już macie: automatyzacje opublikowane w tenancie, kolejki, zasoby, uprawnienia, Orchestrator, Studio, Context Grounding i Test Manager.
**Skills i Plugins** rozszerzają samego Delegate. Skill to pojedyncza umiejętność, Plugin to pakiet umiejętności dla jednego produktu albo profilu, jak Test Cloud.
Rozróżnienie między Integration Service a MCP jest praktyczne: konektor bierzecie tam, gdzie jest, bo niesie uwierzytelnienie i uprawnienia platformy; MCP tam, gdzie konektora nie ma - do własnych API, lokalnych baz i integracji eksperymentalnych. I to właśnie MCP jest tą kategorią, którą w środowisku regulowanym wyłącza się w polityce domyślnie.
## Trzy dźwignie kontroli
Tu jest sedno całego produktu. Użytkownik ma trzy przełączniki tuż obok pola wpisywania - w granicach, na które pozwala polityka organizacji.
*Tryby zatwierdzania. Balanced jest oznaczony przez producenta jako rekomendowany. Źródło: docs.uipath.com, Delegate & Cartographer user guide, dostęp 12.09.2026.*
**Tryb zatwierdzania** obowiązuje we wszystkich rozmowach i ma trzy stopnie. **Cautious** pyta o każdą operację i pracuje w ścisłej izolacji z dostępem wyłącznie z listy dozwolonych. **Balanced**, rekomendowany przez producenta, uruchamia bezpieczne narzędzia automatycznie, pyta przed operacjami o dużym wpływie i chroni poświadczenia oraz pliki wrażliwe. **Autonomous** to pełny dostęp do systemu bez pytania - w dokumentacji opisany jako przeznaczony wyłącznie dla zaufanych środowisk.
**Kontekst ekranu** decyduje, co Delegate widzi: tylko aplikacje dołączone do bieżącej rozmowy (`Default`), każdą widoczną aplikację (`All apps`) albo nic (`None`, z możliwością poproszenia o włączenie). Jest do tego jedno ustawienie, które łatwo przeoczyć, a które ma znaczenie przy ocenie prywatności: w trybie domyślnym **pierwsza wiadomość każdej tury dostaje jeden pełnoekranowy zrzut**, żeby polecenie „zrób to za mnie” działało na zimnym starcie. Kolejne tury są maskowane do aplikacji dołączonych. Domyślnie włączone.
**Tryb wykonania** decyduje, jak działa: **Autonomous** przejmuje ekran, **Guided** przejmuje ekran, ale pyta przed każdą interakcją, **Offscreen** pracuje bez dotykania ekranu - w sesji lokalnej, wyłącznie w przeglądarce albo natywnie w tle.
Pod spodem jest jeszcze warstwa szczegółowa w `Settings → Security`: uprawnienia narzędzi w schemacie Allow/Ask/Block, osobno dla odczytu i zapisu; piaskownica powłoki z listą dozwolonych ścieżek i zablokowanych komend; pliki chronione, czyli sekrety, klucze i poświadczenia; oraz zaufane i zablokowane aplikacje i witryny dla automatyzacji interfejsu.
### Granica uprawnień
Dwie rzeczy warto zapamiętać, bo wracają w każdej rozmowie o ryzyku.
Delegate działa w kontekście zalogowanego użytkownika i **nie podnosi uprawnień**. Na Windows nie steruje aplikacjami uruchomionymi jako administrator. Wykonywanie kodu idzie do piaskownicy jądra - **AppContainer** na Windows - która izoluje system plików, sieć i dostęp do procesów, a jej szczelność zależy od wybranego trybu zatwierdzania.
Ustawienia są przechowywane w dwóch warstwach i to jest przemyślana decyzja projektowa. Jawny `settings.json` trzyma wygląd, wybór modelu, skróty i preferencje zachowania. Zaszyfrowany `secure-settings.enc` - chroniony przez DPAPI na Windows - trzyma uprawnienia narzędzi, tokeny i polityki, a zmienić go można wyłącznie przez interfejs. Cel rozdzielenia jest jasny: agent, który zostałby przejęty, nie ma drogi do podniesienia sobie uprawnień przez edycję pliku konfiguracyjnego.
## Co się dzieje z Waszymi danymi
To jest sekcja, którą zwykle czyta się na końcu, a powinna być czytana najpierw.
**Co idzie do modelu.** Dosłownie: „The content a task needs, including screenshots, is processed by a model.” Trasa prowadzi przez **UiPath AI Trust Layer** - szyfrowane, uwierzytelnione połączenie usługa-usługa - albo przez własny model organizacji.
**Czy Wasze dane trenują modele.** Nie, i jest to zakazane umownie. Dostawcy modeli „don't retain your data beyond short-lived, in-memory processing” - zwykle minuty, maksymalnie 24 godziny.
**Redakcja przed wysłaniem.** Na urządzeniu, zanim model cokolwiek zobaczy: „Secrets and personal data are removed from tool output before the model sees it” - ponad **560 wzorców**, od kluczy API po dane osobowe, adresy IP i numery kart. Dodatkowo AI Trust Layer pseudonimizuje dane osobowe przed transmisją.
**I tu jest haczyk, który trzeba nazwać wprost.** Redakcja działa na wyjściu narzędzi, maskowanie na tekście - a **zrzuty ekranu nie są redagowane wizualnie przed wysłaniem do modelu**. Jeżeli na ekranie pracownika stoi lista pacjentów, tabela wynagrodzeń albo ekran systemu klienta objętego umową o poufności, to ten obraz pojedzie do modelu w całości. Nie jest to luka w produkcie - jest to konsekwencja tego, że agent klasy computer use musi widzieć ekran. Ale jest to decyzja, którą musicie podjąć świadomie, a nie odkryć po fakcie.
**Gdzie leży historia rozmów.** „By default, conversation history is stored in UiPath Automation Cloud.” Tryb lokalny trzyma ją na maszynie użytkownika. Usunięcie przez użytkownika to trwałe skasowanie, a organizacja może wnioskować o usunięcie na swoim poziomie, co pokrywa żądanie z artykułu 17 RODO. Wsparcie UiPath sięga po te dane „only, with your explicit approval, and every access is tracked and logged”.
**Reszta parametrów.** Szyfrowanie TLS 1.2+ w tranzycie i AES-256 w spoczynku. Ruch wyłącznie wychodzący, po HTTPS, do domen UiPath - żadnych połączeń przychodzących, z obsługą proxy systemowego i firmowych certyfikatów głównych. Telemetria niesie tylko sygnały operacyjne: błędy, czasy, użycie funkcji - bez treści rozmów i bez zrzutów. Wobec wstrzykiwania poleceń model ma opierać się instrukcjom ze stron, ale producent nie opiera się na tym samym: niezależnie działają reguły autoryzacji i piaskownica, a AI Trust Layer dodaje opcjonalną detekcję.
**Certyfikacje** Delegate dziedziczy po Automation Cloud: SOC 1 i SOC 2 Type 2, ISO/IEC 27001, 27017, 27018 oraz **42001** dla systemów zarządzania sztuczną inteligencją, a także HIPAA, HITRUST, C5, IRAP i Cyber Essentials Plus, przy zgodności z RODO i opublikowanej liście podprzetwarzających.
Czego dokumentacja **nie** podaje: konkretnych regionów przetwarzania dla wywołań modelu. Odsyła do konfiguracji „AI features and model routing” na poziomie tenanta, produktu i funkcji. Jeżeli macie wymóg rezydencji, to jest pierwsze pytanie do UiPath, nie do dokumentacji.
## Który model pod spodem
Delegate nie jest zbudowany wokół jednego dostawcy. Lista dostępnych modeli w dokumentacji:
| Dostawca | Modele |
|---|---|
| Anthropic | Claude Sonnet 5, Claude Opus 4.8 |
| Azure OpenAI | GPT-5.6 Sol, GPT-5.6 Terra, GPT-5.6 Luna |
| Google | Gemini 3.6 Flash |
| Moonshot AI | Kimi K2.7 Code |
Organizacja może podstawić własny model - i producent wskazuje wprost, kiedy to ma sens: gdy wymaga tego umowa, regulator albo rezydencja danych.
Ważny szczegół operacyjny: model musi być włączony **jednocześnie** w `AI Trust Layer → Models` i dopuszczony polityką Automation Ops. „AI Trust Layer is the source of truth: if a model is allowed by policy but its provider is disabled in AI Trust Layer, it is not available.” Jeżeli więc model nie pojawia się na liście, sprawdzajcie najpierw AI Trust Layer, a nie politykę.
## Nadzór centralny - to jest miejsce, gdzie podejmujecie decyzje
Polityki powstają w `Automation Cloud → Automation Ops → Governance` i kieruje się je na użytkowników, grupy albo tenanty. Trzy właściwości, które trzeba znać, zanim zaplanujecie wdrożenie:
- **Kiedy wchodzą w życie:** przy następnym starcie aplikacji albo rozpoczęciu nowej rozmowy, z propagacją do **30 minut**.
- **Jak działają:** „Settings are re-applied from the live policy every time, and are never stored as the user's own choice.” Użytkownik nie nadpisze ich na stałe.
- **Przy konflikcie:** wygrywa polityka najbardziej szczegółowa.
Zakres jest szeroki. Centralnie ustawicie kategorie dostępnych narzędzi i ograniczenia ścieżek, komend, witryn oraz aplikacji; zgodę albo blokadę na delegowanie do agentów pomocniczych; udostępnianie serwerów MCP i to, czy użytkownik może dodać własny; **blokadę trybu zatwierdzania i trybu kontekstu ekranu**; firmową instrukcję doklejaną do każdego promptu; uprawnienia per operacja z rozdzieleniem odczytu i zapisu - producent podaje przykład blokady kasowania poczty przy dozwolonym wysyłaniu; model domyślny i listę dopuszczonych; wreszcie zgodę na indeksy Context Grounding.
Sam producent publikuje też **baseline dla środowisk regulowanych** i warto go potraktować jako punkt wyjścia, a nie inspirację: tryb zatwierdzania ustawiony na Cautious i zablokowany, wykonanie bez uprawnień administratora, operacje niszczące ustawione na odrzucanie, piaskownica skryptów włączona z dostępem wyłącznie do wskazanych folderów, MCP domyślnie wyłączone, poświadczenia trzymane w Orchestratorze, historia rozmów wyłącznie lokalna.
To jest ta sama logika, którą opisywaliśmy przy [bramce zatwierdzenia w Maestro](https://snok.ai/pl/aktualnosci/blog/hitl-gate-uipath-maestro-ai-trust-layer/): kontrolą jest to, co odmawia wykonania w chwili działania, a nie dokument opisujący, czego nie należy robić.
## Co trzeba mieć
**System.** Tu jest rozbieżność, którą trzeba nazwać, bo krąży w obiegu w wersji optymistycznej. Ogłoszenie na forum UiPath z 26 sierpnia mówiło o Windows **i** macOS. Dokumentacja produktowa mówi coś innego, dosłownie:
> „You can currently install Delegate on Windows only, through UiPathPlatformSTS.msi. macOS support is not yet available.”
Dokumentacja jest źródłem nowszym i bardziej szczegółowym, więc przyjmujemy jej wersję. Ślady przygotowań do macOS są w niej zresztą wszędzie - ścieżki `~/Library/Application Support`, uprawnienia TCC, piaskownica Seatbelt - więc kierunek jest przesądzony. Terminu nie ma. Jeżeli planujecie pilotaż w zespole pracującym na Macach, to jest blokada, nie niedogodność.
**Warunki wstępne.** Konto UiPath w tenancie organizacji, maszyna spełniająca wymagania sprzętowe i programowe oraz połączenie z internetem.
**Przebieg instalacji.** Pobieracie `UiPath Robot & Assistant Latest STS (Continuous Release)` z Customer Portal albo z Automation Cloud. Uruchamiacie instalator, wybieracie komponent **Robot**, dokładacie **Extensions** - producent to zaleca, bo część funkcji Delegate z nich korzysta - akceptujecie licencję i instalujecie. Potem logowanie do organizacji, wybór tenanta i sprawdzenie statusu: „Once you are connected and licensed, a green status light appears in the title bar next to your initials.” Przełącznik między Assistant, Delegate i Cartographer siedzi w pasku tytułu obok logo UiPath.
**Aktualizacje.** Delegate jest utrzymywany przez **UiPath Platform Installer** - lekką aplikację około dziesięciu megabajtów, która trzyma Studio, Robota, Assistanta, Delegate i rozszerzenia przeglądarki w jednej, wyrównanej wersji i pobiera wyłącznie różnice, w tle. Kanały: Enterprise STS z najnowszymi funkcjami, Enterprise LTS jako linia stabilna z samymi poprawkami, oraz Community. Jednej rzeczy brakuje i trzeba to uwzględnić w planie: **nie ma automatycznego wycofania wersji** - nieudana aktualizacja zostawia poprzednią.
**Dla profilu testowego dodatkowo:** licencja Test Cloud w wariancie AppTestDeveloper albo AppTesters, zainstalowany i uwierzytelniony UiPath CLI oraz włączona wtyczka Test Cloud.
## Ile to kosztuje
*Podgląd wykorzystanej puli w `Settings → General`. Źródło: docs.uipath.com, Delegate & Cartographer user guide, dostęp 12.09.2026.*
Model jest prosty w konstrukcji i nieoczywisty w skutkach.
Delegate i Cartographer wymagają licencji użytkownika. Każdy poziom licencji zawiera **AI and Agentic usage pool** - miesięczny limit **wspólny** dla produktów AI i agentowych UiPath: Autopilota, Agent Development, ScreenPlay Development, agentów konwersacyjnych i Autopilot for Everyone. Limit jest przypisany do użytkownika, resetuje się na początku miesiąca i **niewykorzystana część nie przechodzi dalej**. Zużycie liczy się na sesję. Po wyczerpaniu limitu działa doładowanie przyznane przez administratora; po wyczerpaniu obu - wstrzymanie do kolejnego doładowania albo do resetu.
Nieoczywisty skutek jest taki: **Delegate konkuruje o tę samą pulę co Autopilot**. Jeżeli w organizacji działa już Autopilot for Everyone, wprowadzenie Delegate nie jest neutralne dla tego, co ludzie mają dostępne pod koniec miesiąca. To jest pytanie do zadania przed pilotażem, nie po pierwszym raporcie zużycia.
Wielkości puli per poziom licencji **nie podajemy** - dokumentacja odsyła do osobnej tabeli, której treści nie potwierdziliśmy, a zmyślona liczba w tym miejscu byłaby gorsza niż jej brak. To pytanie do UiPath albo do partnera.
## Czego jeszcze nie wiadomo
Rzetelność wymaga wymienienia luk, bo produkt jest w preview i luk jest sporo.
- **Termin ogólnej dostępności.** Producent mówi tylko, że funkcje i zachowanie mogą się zmienić przed GA.
- **macOS.** Kierunek oczywisty, terminu brak.
- **Wielkość puli zużycia** per poziom licencji.
- **Regiony przetwarzania** dla wywołań modelu.
- **Niezależne pomiary skuteczności** na realnych procesach. Nie ma publicznych wdrożeń produkcyjnych ani benchmarków spoza UiPath.
- **Ślad audytowy w systemie docelowym.** Pytanie, które zadaliśmy w lipcu, wciąż nie ma odpowiedzi: czy rejestr zdarzeń w SAP, w CRM albo w systemie bankowym odróżni czynność wykonaną przez człowieka od czynności wykonanej przez agenta działającego jego poświadczeniami. W UiPath ślad jest. Po drugiej stronie - to zależy od tego, jak ten system loguje, a agent wygląda tam jak zalogowany pracownik.
## Pięć decyzji, zanim to wejdzie na biurka
To już jest nasza rekomendacja, nie treść dokumentacji.
**Po pierwsze, polityka przed instalatorem.** Ustawienia lokalne są domyślnie w rękach użytkownika, a Automation Ops jest jedynym miejscem, w którym da się je zablokować - z propagacją do trzydziestu minut. Kolejność ma znaczenie: najpierw baseline polityki, potem MSI. Odwrotna kolejność oznacza okno, w którym przełącznik Autonomous jest dostępny dla każdego, kto go znajdzie.
**Po drugie, zrzuty ekranu są najsłabszym ogniwem prywatności.** Przy ekranach z danymi osobowymi albo objętymi umową o poufności trzeba przesądzić: kontekst ekranu na `Default` plus lista zablokowanych aplikacji, albo tryb Offscreen. Decyzja należy do administratora danych, nie do użytkownika końcowego.
**Po trzecie, historia rozmów to decyzja o miejscu przetwarzania.** Domyślnie ląduje w Automation Cloud. Dla danych wrażliwych producent sam rekomenduje tryb lokalny - podejmijcie to raz, na poziomie organizacji, zamiast zostawiać per stanowisko.
**Po czwarte, Routine potrzebuje właściciela i rejestru.** Ma harmonogram, parametry, zapisane połączenia i da się ją wyeksportować poza organizację jednym plikiem. Bez ewidencji powstaje druga warstwa automatyzacji obok Orchestratora - ta sama, którą przez ostatnie lata porządkowaliście po arkuszach z makrami.
**Po piąte, agent działa uprawnieniami pracownika.** Delegate nic nie podnosi, ale też nic nie odbiera. Nadmiarowy dostęp, który dotąd był ryzykiem teoretycznym, bo nikt nie miał czasu z niego skorzystać, staje się ryzykiem wykonawczym. Przegląd uprawnień przed pilotażem jest tańszy niż po incydencie.
## Co robimy z tym u klientów
Jesteśmy partnerem UiPath na poziomie Platinum i uczestnikiem programu Agentic Fast Track, więc rozmawiamy o Delegate z pozycji doradcy, a nie sprzedawcy licencji - produkt jest w preview i nikt uczciwy nie sprzeda Wam dziś wdrożenia produkcyjnego.
To, co ma sens teraz, to trzy rzeczy: **baseline polityki Automation Ops** dopasowany do Waszego profilu ryzyka i wymogów regulacyjnych, **przegląd uprawnień** na stanowiskach kandydujących do pilotażu oraz **wybór dwóch, trzech zadań**, na których realnie da się zmierzyć efekt - takich, które dziś nie przeszłyby progu opłacalności w [klasycznym projekcie automatyzacji](/pl/oferta/automatyzacja-ai/business-process-automation/), bo to właśnie w nie Delegate celuje.
Jeżeli chcecie to przejść na swoich danych i swoich procesach, [napiszcie do nas](https://snok.ai/pl/kontakt/). Zaczniemy od tego, co da się ustawić przed pierwszą instalacją.
---
*Wszystkie cytaty i dane pochodzą z dokumentacji UiPath (Delegate & Cartographer user guide), not wydawniczych Automation Cloud za sierpień 2026 oraz ogłoszenia na forum UiPath z 26.08.2026. Dostęp: 12.09.2026. Produkt jest w public preview - funkcje i zachowanie mogą się zmienić przed ogólną dostępnością. Zrzuty ekranu pochodzą z dokumentacji UiPath i są przytoczone w celach informacyjnych z podaniem źródła.*
---
# SNOK Sp. z o.o. (English)
> A Polish technology partner for medium and large organisations - SAP (Basis, S/4HANA, BTP, Security), automation and Enterprise AI (UiPath Platinum + Agentic Fast Track), cybersecurity, custom development and data. Company registered in Warsaw. Certified to ISO 27001:2022, ISO 9001:2015. Founded 2021.
## Offer - four pillars (full description)
### 01. Intelligent Automation and AI
URL: https://snok.ai/en/offer/ai-automation/
Less manual work, faster decisions, lower operating costs. We design and implement business process automation using RPA, AI agents, system integrations and Enterprise AI. We help organisations shorten handling times, reduce errors and build processes that can be measured, controlled and scaled.
Credentials and status: UiPath Platinum Partner since 2021 · Agentic Fast Track · Enterprise AI in production since 2025 · Cloud / On-Prem / Air-Gapped
**AI agents and agentic automation** - In processes that require analysis, decisions and collaboration across multiple systems, AI agents carry a case forward step by step, draw on the organisation's data, and hand decisions back to a human wherever control, risk or compliance requires it.
- UiPath Maestro: AI agents support the handling of recurring cases, structure the next steps of a process, and involve a human whenever a decision, approval or risk assessment is required. (https://snok.ai/en/offer/ai-automation/uipath-maestro/)
- Case Management: Cases - from complaints to KYC processes - are handled according to agreed rules, with a full history of actions, decisions and escalations available to the team and to auditors. (https://snok.ai/en/offer/ai-automation/case-management/)
- Enterprise AI: The team finds answers faster in the organisation's documents, procedures and data - with a reference to source, access control, and room for further process automation. (https://snok.ai/en/offer/ai-automation/enterprise-ai/)
- We also deliver: Agent Builder and Coded Agents, RAG - AI assistants on company knowledge
**Process and document automation** - We handle recurring processes, documents and tests from end to end - with clear rules, quality control, and results measured in handling time, error count and process cost.
- Business Process Automation: We automate operational processes from case intake through to closure - connecting systems, data and user tasks into a single, coherent workflow. (https://snok.ai/en/offer/ai-automation/business-process-automation/)
- Document Understanding: Invoices, contracts, applications and other documents can be read, classified and routed for further processing without manual data entry. (https://snok.ai/en/offer/ai-automation/document-understanding/)
- Agentic Testing: We automate regression testing and end-to-end scenarios to prepare systems for change faster, reduce pre-go-live errors, and relieve pressure on QA teams. (https://snok.ai/en/offer/ai-automation/agentic-testing/)
- We also deliver: Process Mining and Task Mining
**AI trust and compliance** - We implement AI solutions with access control, decision auditability and clear data-processing rules - so the organisation can benefit from AI without increasing operational, regulatory or security risk.
- AI Security and the AI Trust Layer: We design the security layer for AI solutions: access control and data protection, mitigation of language-model-related risks, and usage monitoring with a full audit trail. (https://snok.ai/en/offer/ai-automation/ai-security/)
- On-premise LLM: We deploy language models within the client's infrastructure, so that critical data, documents and user queries remain under the organisation's control. (https://snok.ai/en/offer/ai-automation/llm-on-premise/)
- AI Act compliance: We help classify AI systems and prepare the registers, documentation and oversight mechanisms required under the AI Act - before regulatory obligations become an operational problem. (https://snok.ai/en/offer/ai-automation/ai-act-compliance/)
- We also deliver: AI in SAP - Joule, Build Code, BTP AI Core, Business case, ROI and adoption plan
Approach: We begin every conversation about automation by establishing the business case. We analyse the current cost of the process - in hours worked, errors, delays and team involvement - and agree how the result will be measured once the solution is live. Only then do we select the right approach: an RPA bot, an AI agent with access to the relevant systems, an Enterprise AI assistant, document automation, or a change to the underlying procedure, if that is the actual source of the problem. We do not automate for the sake of automating. The solution has to be used, measurable and maintainable. Otherwise it becomes another cost rather than a genuine improvement.
Partner stack: UiPath Platinum, UiPath Agentic Fast Track, UiPath Studio, UiPath Orchestrator, UiPath Maestro, UiPath Agent Builder, UiPath Autopilot, UiPath Action Center, UiPath Test Cloud, UiPath Process Mining, UiPath Task Mining, UiPath Communications Mining, UiPath Document Understanding, UiPath AI Center, UiPath Apps, UiPath Insights, UiPath Integration Service, UiPath Assistant, Anthropic Claude, OpenAI / Azure OpenAI, Google Gemini, Llama 3.3, Mistral, Qwen, Hugging Face, LangChain, LlamaIndex, Model Context Protocol (MCP), Claude Code, Snowflake, Microsoft Fabric, Databricks, pgvector / Qdrant, SAP Joule, SAP Build Code, SAP BTP AI Core
Delivery proof (A healthcare operator active in 18 countries): The client employs more than 45,000 people across 18 countries. Together, we built an HR process platform supported by digital workers - handling around 100,000 HR events a year and cutting onboarding time from 10 days to 2. The client became an official reference customer for the platform provider - one of only three such references in Poland.
### 02. SAP Security and Technology
URL: https://snok.ai/en/offer/sap-security/
Mission-critical SAP systems - operational assurance, regulatory compliance and IT cost optimisation. We design, maintain and secure SAP environments, combining expertise in SAP Basis, SAP Security, S/4HANA conversion, penetration testing, security monitoring and compliance with NIS2 and DORA requirements. Our projects draw on tools including SecurityBridge, bowbridge and Rev-Trac. This gives the client consistent support in an area that typically requires coordinating several specialised competencies.
Credentials and status: SecurityBridge · bowbridge · Rev-Trac · NIS2 and DORA ready · Audit → implementation → maintenance
**SAP security and protection** - We protect mission-critical SAP systems in layers: from threat monitoring and attachment protection, to penetration testing, configuration audits and support for SOC teams.
- SecurityBridge for SAP: SecurityBridge helps detect suspicious activity in SAP, monitor changes, transactions, RFC calls, configuration and ABAP code, and feed events into SOC/SIEM processes. This gives the security team visibility into risks that standard infrastructure monitoring usually misses. (https://snok.ai/en/offer/sap-security/securitybridge/)
- bowbridge for SAP: bowbridge scans attachments and files entering SAP before they become a risk to a mission-critical system. The solution supports malware protection, file control and DLP policies within SAP-driven business processes. (https://snok.ai/en/offer/sap-security/bowbridge/)
- SAP penetration testing and security audits: We carry out penetration tests and security audits of SAP: configuration, authorisations, interfaces, RFC, custom ABAP code and integrations. The report includes vulnerability descriptions, risk scoring, remediation priorities and a retest after fixes are applied. (https://snok.ai/en/offer/sap-security/sap-penetration-testing/)
- We also deliver: HOT service - SAP Security Patch Day, monthly notes and patch rollout, Cybersecurity-as-a-Service for SAP, MDR/SOC 24/7, SAP integration with SIEM, security configuration reviews and incident support
**SAP transformation and maintenance** - We support organisations from S/4HANA conversion through to 24/7 SAP maintenance - so that technology change does not cause downtime, transport conflicts, or a loss of control over the environment.
- SAP S/4HANA conversion: We prepare the S/4HANA conversion based on data rather than general assumptions: analysing TCO, system readiness, custom code, integrations, technical risk, and a test plan that protects the go-live. (https://snok.ai/en/offer/sap-security/s4hana-conversion/)
- SAP Basis 24/7: We provide SAP Basis support for critical environments: monitoring, incident response, administration, patching, backup, performance, HA/DR and ongoing maintenance tailored to client requirements. (https://snok.ai/en/offer/sap-security/sap-basis-24-7/)
- Rev-Trac - DevOps and CI/CD for SAP: Rev-Trac helps control changes and transports in SAP, reduce collisions, automate approval workflows and build a complete change history. This matters most in environments with many projects, teams and parallel transports. (https://snok.ai/en/offer/sap-security/rev-trac/)
- We also deliver: Sizing and infrastructure for SAP HANA, Lenovo SAP HANA appliances, SUSE Linux Enterprise Server for SAP Applications, SAP Cloud ALM, Solution Manager, Focused Run, SAP BTP, Joule and BTP AI Core.
**SAP compliance, audit and cost** - We help bring order to regulatory compliance, code security and SAP licence costs - from mapping obligations, through auditing, to an action plan and support for implementing changes.
- NIS2 / DORA / KSC compliance audit for SAP: We map NIS2, DORA and KSC requirements to specific areas of the SAP environment: access, monitoring, business continuity, backup, vulnerabilities, integrations, change management and documentation. The outcome is an action plan that can be delivered in stages. (https://snok.ai/en/offer/sap-security/nis2-dora-audit/)
- SAP licence audit: We analyse SAP licence usage, user roles, system activity and potential optimisation areas. The goal is to reduce unnecessary costs and prepare better for vendor negotiations or an audit. (https://snok.ai/en/offer/sap-security/sap-license-audit/)
- SAP Code Vulnerability Analyzer: We review custom ABAP code for vulnerabilities, quality and readiness for technology change. The review helps reduce the attack surface, address technical debt and prepare the system for S/4HANA conversion. (https://snok.ai/en/offer/sap-security/sap-code-vulnerability/)
Approach: We start with a full audit of the configuration: authorisations, custom code, Basis parameters, backup policy and transports. Most SAP security issues stem from configuration, not from vulnerabilities in the vendor's own code. Once the audit is complete, we design the change with a clear division of responsibility: what SNOK delivers, what remains with the client's team, and what can be supported through automation, for example with Rev-Trac, SecurityBridge or bowbridge. We hold every project accountable to a measurable business outcome: a shorter incident response time, fewer transport-related errors, licensing savings, or audit readiness.
Partner stack: SAP Service Partner, SAP S/4HANA, SAP HANA, SAP NetWeaver, SAP BTP, SAP Fiori, SAP ABAP, SAP RISE, SAP GROW, SAP Cloud ALM, SAP Solution Manager, SAP Focused Run, SAP LaMa, SAP HCMT, SAP Joule, SAP Build Code, SAP BTP AI Core, SAP Code Vulnerability Analyzer, SecurityBridge Premier Partner PL, bowbridge, Rev-Trac, gCTS, ChaRM, SUSE Linux Enterprise Server for SAP Applications, Lenovo SAP HANA appliances, Microsoft Sentinel, Splunk, IBM QRadar, Azure for SAP, AWS for SAP, Google Cloud for SAP
Delivery proof (An international FMCG manufacturer): Seven hundred SAP users across three companies and five tax jurisdictions. The client entrusted SNOK with SAP security monitoring and incident response rather than building an in-house SOC team for this area. The project covered protection of the critical ERP system, environment monitoring, and incident response. As a result, the client's team gained ongoing support without having to expand its own SAP Security capabilities.
### 03. Custom Development and Data
URL: https://snok.ai/en/offer/custom-development/
Bespoke applications built on trustworthy data. We build applications, integrations and data environments where standard products fall short. We combine custom development, master data management and a data layer that supports analytics, automation and AI. We help organise master data using SNOK MDM, and we work with technologies including Microsoft Azure, SAP BTP, Google Cloud, Snowflake, Microsoft Fabric and Databricks.
Credentials and status: Microsoft Solutions Partner Infrastructure · SNOK MDM and SNOK.me in production · Modern data stack in a regulated sector · Accountable for outcomes, not code
**Data, MDM and analytics** - Trustworthy data underpins reporting, automation and the use of AI. We help organise master data, build a consistent analytics layer, and prepare the organisation to work with data it can rely on.
- Master Data Management: One version of the truth about customers, materials and employees - a golden record with a single-domain pilot in 4-8 weeks. (https://snok.ai/en/offer/master-data-management/)
- Modern Data Stack: One version of the truth instead of conflicting reports - management reporting cut from days to hours. (https://snok.ai/en/offer/custom-development/modern-data-stack/)
- Databricks - Lakehouse Platform and ML/AI: Data and ML on a single platform - the end of the silo between data engineering and data science. (https://snok.ai/en/offer/custom-development/databricks/)
- We also deliver: SNOK MDM - our own platform, in production since 2022, Data Governance and data classification (Purview, Horizon), Google Cloud - BigQuery, Vertex AI
**Cloud, integrations and Clean Core** - We design cloud architecture, integrations and SAP extensions aligned with the Clean Core approach. We balance business requirements, security, maintenance costs and the solution's long-term scalability.
- Microsoft Azure: A cloud migration with a calculated TCO - no bill higher than on-premise after the first year. (https://snok.ai/en/offer/custom-development/microsoft-azure/)
- Applications on SAP BTP: SAP extensions outside the core - an S/4HANA conversion without the pain of custom code. (https://snok.ai/en/offer/custom-development/sap-btp-clean-core/)
- Integrations and APIs: No more manual copy-pasting of data - systems talk to each other in real time, with a full audit trail. (https://snok.ai/en/offer/custom-development/integrations-api/)
- We also deliver: DevOps, CI/CD and SRE
**Bespoke applications and products** - We build applications and digital products tailored to a specific business process. This approach works well wherever off-the-shelf solutions fall short, demand too many compromises, or don't give the organisation the flexibility it needs.
- Bespoke applications: Functionality that can't be bought off the shelf - an MVP in 8-16 weeks, with the code and IP fully yours. (https://snok.ai/en/offer/custom-development/bespoke-applications/)
- SNOK.me - project portfolio: A problem visible in a project two weeks earlier - better team allocation and delay prediction. (https://snok.ai/en/products/snok-me/)
- On-premise LLM + RAG: AI where the cloud is not an option - models and company knowledge within your own infrastructure. (https://snok.ai/en/offer/ai-automation/llm-on-premise/)
Approach: We start by understanding the data, the processes and the business problem. We check which systems already exist, where inconsistencies arise, who is accountable for the data, and which processes need application, integration or analytics support. On that basis, we prepare a map of actions. Sometimes the right recommendation is to tidy up a handful of key master data tables before starting a data warehouse, lakehouse or analytics application project. It can equally be a good project if it removes a real business bottleneck. We design solutions around a measurable business outcome, not around delivering code, an integration or a data environment for its own sake. The application, warehouse or AI model needs to operate within a specific process, have an owner within the organisation, and be built on data that can be trusted.
Partner stack: Microsoft Solutions Partner Infrastructure, Microsoft Azure, Microsoft Fabric, Microsoft Purview, Azure OpenAI, Azure SQL, Azure Functions, Azure Logic Apps, Entra ID, SAP BTP, SAP CAP, SAP Fiori, SAP Cloud Integration, SAP Build Code, SAP BTP AI Core, Snowflake, Snowflake Cortex, Databricks, Google Cloud Platform, BigQuery, Vertex AI, Anthropic Claude, OpenAI, Llama 3.3, Mistral, Qwen, LangChain, LlamaIndex, pgvector / Qdrant, React / Next.js, Node.js / .NET, TypeScript, Terraform / Bicep, Kubernetes, GitHub Actions / Azure DevOps, SNOK MDM, SNOK.me
Delivery proof (A chemical group after five acquisitions): Over five years, the client completed five acquisitions across three countries. After the latest acquisition, the board could no longer be confident that the reports presented at its meetings rested on consistent data definitions. We implemented centralised master data management with LLM-based deduplication. As a result, management reporting could be based on a single, consistent data source, understood across the whole organisation.
### 04. IT Advisory and Integration
URL: https://snok.ai/en/offer/it-advisory-integration/
IT strategy, architecture and security - decisions grounded in facts. We support organisations in making technology decisions - from TCO analyses, cloud roadmaps and AI-readiness assessments, to selecting infrastructure, licences and technology partners. We supply hardware and licensing solutions, including Lenovo equipment for SAP HANA environments, SUSE, UiPath and SecurityBridge. We combine advisory, technology and integration so the client receives consistent support at every stage of a project.
Credentials and status: Decisions built on numbers: TCO · NPV · IRR · Roadmaps for the AI Act · NIS2 · DORA · Independent audits and due diligence · CISO on demand
**Strategy and transformation** - Technology decisions grounded in numbers - TCO, roadmaps and AI strategy, before the project even starts.
- S/4HANA conversion TCO analysis: A deployment model choice based on NPV and IRR over a 10-year horizon - a board decision built on numbers, not on a vendor's slides. (https://snok.ai/en/offer/sap-security/s4hana-conversion/)
- Enterprise AI + AI Act strategy: An AI strategy built for AI Act readiness - from a systems inventory to the first production use case within six months. (https://snok.ai/en/offer/ai-automation/ai-act-compliance/)
- Cloud roadmap - Azure, GCP, SAP BTP: A 3-5 year cloud roadmap with a calculated TCO - a phased migration, without risk to operational continuity. (https://snok.ai/en/offer/custom-development/microsoft-azure/)
- We also deliver: Lenovo servers for SAP HANA
**Compliance, audit and cost** - Regulation and IT cost under control - a single point of contact for NIS2, DORA, the AI Act and licence optimisation.
- NIS2 / DORA / AI Act compliance: Three regulations handled as a single programme - audit readiness before the inspection arrives. (https://snok.ai/en/offer/sap-security/nis2-dora-audit/)
- SAP licence audit: Real savings on annual SAP fees - with a negotiation plan ready ahead of renewal. (https://snok.ai/en/offer/sap-security/sap-license-audit/)
- AI Readiness Assessment: A six-dimensional AI-readiness assessment - knowing where you stand before spending your first pound. (https://snok.ai/en/offer/it-advisory-integration/ai-readiness/)
- We also deliver: Licences and subscriptions - UiPath, SecurityBridge, SUSE
**IT management and risk** - IT risk and vendors managed like a portfolio - management-level competence available on demand.
- Cybersecurity Advisory - CISO on demand: CISO-level competence without a full-time hire - policies, risk assessment and security oversight on demand. (https://snok.ai/en/offer/it-advisory-integration/ciso-on-demand/)
- IT due diligence for acquisitions: The state of IT examined before an M&A transaction - post-acquisition surprises can cost more than the deal itself. (https://snok.ai/en/offer/it-advisory-integration/it-due-diligence/)
- IT vendor management: The IT vendor portfolio under control - real costs to recover through a contract review. (https://snok.ai/en/offer/it-advisory-integration/vendor-management/)
- We also deliver: Training and workshops for the board and IT (AI Act, cybersecurity)
Approach: We start by understanding the strategic context: fixed deadlines, planned acquisitions, pressure to cut IT costs, regulatory requirements and current technology risks. On that basis, we bring order to the decisions the organisation needs to make: from TCO analyses, cloud roadmaps and AI-readiness assessments, to NIS2, DORA and AI Act compliance, licence audits, IT due diligence and vendor management. A report, roadmap or analysis is meant to lead to a specific management or technology decision. Without that, a TCO analysis, an AI Readiness Assessment or a compliance strategy remain documents that never translate into real action.
Partner stack: Lenovo Partner, SUSE Gold Partner (SLES for SAP), Microsoft Solutions Partner Infrastructure, UiPath Platinum Partner, UiPath Agentic Fast Track, SAP Service Partner, SecurityBridge Premier Partner PL, Rev-Trac (distributor for Poland), Snowflake (Partner), ISO 27001:2022, ISO 9001:2015, SAP HCMT Sizing, Cloud Adoption Framework (Microsoft), NIST CSF, OWASP, AI Act (EU 2024/1689), NIS2 / KSC, DORA, GDPR
Delivery proof (A group in the media sector): Four subsidiaries, four separate ERP installations, and a fourfold maintenance cost. We designed a consolidation onto a single platform while preserving legal separation between the entities. Today, the four companies run on one platform - the warehouse processes four thousand parcels a day through a single unified process, and maintenance costs have fallen by close to a third.
## SNOK products (full description)
### SNOK MDM - Master Data Management for enterprise scale
URL: https://snok.ai/en/products/snok-mdm/
Status: In production since 2022
We help organisations bring order to their master data, so that key systems operate on consistent information about customers, products, materials, employees and business partners. SNOK MDM supports data quality control, reduces discrepancies between systems and makes it easier to build reliable management reporting. As a result, data becomes a stable foundation for decisions, automation and the organisation's further growth. Centralised management of master data across all key domains of the organisation: employees, customers, materials, suppliers, products and financial accounts. The platform supports validation, deduplication, approval workflows, change history and synchronisation with source systems. Beyond the platform itself we deliver Master Data Management services: data state assessment, the master record design, a single-domain pilot and governance - including environments where the master data layer is built without our product.
- Six master domains on one platform: Employees, customers, materials, suppliers, products and finance. Each domain has a dedicated data schema, validation rules and a workflow tailored to the organisation's process.
- AI-assisted deduplication: The system identifies similar records and different spelling variants of the same company, person, material or business partner - with a rationale provided for the data steward.
- Native integrations: Ready-made connectors cover SAP S/4HANA, SAP ECC, Azure AD, Salesforce, Workday, Oracle Cloud ERP and Microsoft Dynamics 365. Custom integrations are designed around the client's architecture.
- Deployment in environments requiring strict control: SNOK MDM can run on-premise or within the client's own environment where security policy, compliance or IT architecture require it. Source code can be placed in escrow to limit single-vendor dependency risk.
Metrics: 70% (faster management reporting - the result of a SNOK implementation in one management process) · 85% (fewer master data errors after implementing validation and deduplication - the result of a SNOK implementation in one data domain) · 15 months (return-on-investment period in one of our implementations) · 6 (master domains available in the base model)
Technology: SNOK MDM is built on an architecture designed for enterprise scale: a Node.js backend, a relational PostgreSQL database, a BPMN workflow layer, governance rules for each domain, and an AI-assisted deduplication queue. The platform can operate in a multi-tenant model with per-client data isolation, or as a dedicated deployment within the organisation's environment.
Proof: The platform handles around 100,000 master data record events per year in an international environment spanning 18 countries and 9 source systems.
### SNOK.me - People, time, projects and profitability in one environment
URL: https://snok.ai/en/products/snok-me/ | https://snok.me/pl/
Status: Proven in day-to-day organisational use
SNOK.me helps organisations bring order to their teams' day-to-day work as well as to project and employee-case management. The platform combines time tracking, workload planning, project delivery, billing and management reporting in one coherent environment - giving the leadership team an up-to-date view of work, costs and profitability. SNOK.me combines data on people, projects, working time, costs, profitability and employee matters in one environment. This means employees, administration, the PMO, managers and the leadership team all work from the same data, each seeing it from the perspective of their own role.
- Time, projects and profitability under control: The platform supports time tracking, team availability planning, project schedules, and cost and profitability controlling at project and phase level. As a result, budget overruns, delays and team overloads become visible earlier - not only after manually collating data from spreadsheets.
- A management view without manually compiled reports: SNOK.me gives leadership and management an up-to-date view of team workload, people's availability, project progress, costs and profitability. Operational data no longer needs to be manually gathered from spreadsheets and separate systems, so decisions can be based on current information rather than after-the-fact reports.
- Billing and bonuses on transparent terms: Data on working time, projects and evaluations can provide a structured input for billing and project bonuses. SNOK.me does not replace a payroll and HR system, but it organises the data that can feed billing processes, reporting and management decisions.
- Employees handle their own matters independently: SNOK.me gives every employee a single place to manage internal matters: their profile, assigned equipment, certificates, documents awaiting approval, tickets, leave, billing and organisational knowledge. A knowledge base, organisational structure and calendar reduce the need to search for information in emails, chat tools and by asking colleagues. The administrative team regains time previously spent handling repetitive questions and routine matters.
- AI in the context of the organisation: The AI layer supports ticket analysis, conversing with documents, assessing the completeness of requests, identifying gaps, flagging risks and suggesting next steps. The solution is not tied to a single model provider, and conversations and work outputs can be shared across the team.
- Integrations and working environment: SNOK.me integrates with Microsoft 365 and Google Workspace, supports company-account SSO login and calendar integration. The platform can run in the cloud or on the client's infrastructure, depending on the organisation's security policy.
Metrics: People (Employee profile, internal matters, equipment, certificates, documents, tickets and knowledge base) · Time (Time tracking, team availability and workload planning without separate spreadsheets) · Projects (Work planning, phases, dependencies, tasks, documents and plan-versus-actual comparison) · Profitability (Cost and profitability controlling at project, phase and team level)
Technology: SNOK.me can run in the cloud or on the client's infrastructure. The platform integrates with Microsoft 365 and Google Workspace, supports SSO and calendars, and the AI layer is not tied to a single model provider. Data is stored in the EU, and the product is developed within an organisation holding ISO 27001:2022 and ISO 9001:2015 certification.
Proof: SNOK.me is used operationally at SNOK to manage employee matters, projects, working time, profitability and billing. This is not merely a sales demonstration, but a product developed on the basis of a real project organisation's day-to-day work.
## Case studies (full content)
### Stock Spirits Group - Mission-critical ERP under 24/7 protection - without growing the client's IT team
URL: https://snok.ai/en/case-studies/#fmcg-manufacturer-secure-erp
Sector: FMCG manufacturer · 9 European countries
An international spirits manufacturer operating in nine countries approached us with a specific challenge: how to secure continuous protection of a mission-critical ERP system without hiring additional specialists in a demanding labour market.
Challenge: Around 700 users across three legal entities relied on a shared ERP platform that, among other things, handled excise tax settlements across five jurisdictions. Any outage risked halting deliveries, and any security incident carried the risk of regulatory scrutiny, remediation work and operational disruption. The internal IT team knew the environment well, but lacked the resources to provide round-the-clock monitoring, ongoing event analysis and regular SAP security patching.
Approach: We began with an audit of the security and authorisation configuration. We then deployed SecurityBridge - a monitoring and threat detection platform purpose-built for SAP environments. We also took over the monthly SAP security patch cycle, and automated selected recurring administrative tasks using UiPath digital workers.
Result: The client gained continuous security monitoring of a mission-critical ERP system without having to build an in-house SOC team from scratch. Incidents are now handled in under two hours, and seven recurring administrative processes are carried out today by digital workers. As a result, the client's team regained time for project work and environment development, rather than being tied up entirely in day-to-day operations.
Metrics: 700+ - users under continuous protection · <2 h - average incident response time · 24/7 - monitoring since 2023
Client quote: "SNOK took on responsibility for our ERP platform's security in a way that let us focus on growing the business."
### Medicover - A hundred thousand HR events a year - without manual process handling
URL: https://snok.ai/en/case-studies/#healthcare-network-hr-digitalisation
Sector: Healthcare network · 18 countries, 45,000 employees
One of the largest healthcare operators in Central Europe, employing staff across 18 countries, faced the challenge of scaling its HR processes further. Regulatory differences between countries, a growing headcount and an increasing volume of HR events called for streamlined and automated core processes.
Challenge: The HR department supported around 45,000 employees using tools that were never designed for operations at this scale. Onboarding required manually completing numerous forms, and the management headcount report was only ready several days after month-end. The organisation was growing faster than its HR team's operational capacity. Without automation and data centralisation, further growth would have meant an ever-increasing burden on HR staff and a higher risk of process errors.
Approach: We built a dedicated HR process platform on SAP BTP, underpinned by a central employee data register. The register works as the SNOK MDM master data layer: a single master record for each employee is created from quality rules, with a named owner, change history and an audit trail, while operational systems in individual countries are fed from that one version. This implementation is the foundation of our Master Data Management practice today. We designed onboarding and position-change processes as structured workflows with approval steps, tailored to the requirements of a multi-country organisation. Recurring operational tasks were handed over to UiPath digital workers.
Result: The platform now handles around 100,000 HR events a year across 18 countries. Onboarding time was cut from 10 days to 2, and the management report is now generated automatically every day. Thanks to this implementation, the organisation can support a growing volume of HR processes without a proportional increase in workload for its HR team. The project was also recognised as an official SAP reference - one of only three in Poland.
Metrics: 100,000+ - HR events per year · 95% - less manual work in HR · 18 - countries on a single platform
Client quote: "The scale we operate at today would be impossible without this platform - and without a team that has known us for three years."
### A media-sector holding group - Four companies, one ERP platform - unified accountability for the environment
URL: https://snok.ai/en/case-studies/#media-group-subsidiary-consolidation
Sector: Telecommunications · 4 subsidiaries within the group
A media and telecommunications holding group needed to consolidate fragmented ERP systems across four subsidiaries. Each company operated on a separate instance, and reporting to the parent required time-consuming reconciliation between systems and teams.
Challenge: The organisation ran four separate ERP installations, each with its own configuration and administration model. Every change to group-level reporting meant working across several environments in parallel. An additional challenge was supporting a warehouse handling around 4,000 parcels a day across various operational processes. The group's scale of operations had begun to outpace its existing technology architecture.
Approach: We designed a consolidation of the ERP environments onto a single platform, preserving the legal separation of individual companies through the appropriate use of organisational dimensions. We carried out the migration in phases, with full regression testing and operational risk control. On the infrastructure side, we worked with Lenovo Platinum and SUSE Gold, selecting solutions suited to critical database workloads.
Result: Four companies now run on a single ERP platform, and the warehouse handles around 4,000 parcels a day within a unified operational process. Group reporting has been automated, and data is now available within a consistent model. Environment maintenance costs fell by close to a third, and the group-level month-end close time shortened from three weeks to three days.
Metrics: 4 - companies on a single platform · 4,000 - parcels a day in a unified process · −30% - in environment maintenance costs
Client quote: "The consolidation gave us consistency in group reporting and control over our IT costs."
### A chemical industry group - Consistent master data after five acquisitions - without rebuilding the source systems
URL: https://snok.ai/en/case-studies/#chemical-group-mdm-after-acquisitions
Sector: Chemical industry · operations in 8 countries
A chemical group that had completed five acquisitions across three countries within five years needed to bring order to master data originating from different companies and systems. Each acquired organisation brought its own catalogues of materials, suppliers, products and financial accounts, complicating group-level reporting and decision-making.
Challenge: The same materials existed across multiple systems under different codes, and the same suppliers were described according to different conventions depending on the company. Harmonising a single component could take months, and management reports required additional reconciliation and clarification. The organisation lacked a single, consistent master data model that could serve as a reliable foundation for reporting, procurement, logistics and further post-acquisition integration.
Approach: We implemented centralised master data management across six key domains: employees, customers, materials, suppliers, products and financial accounts. We designed approval workflows with clear ownership of individual data domains. Where manual deduplication was insufficient or too time-consuming, we used language models to support the identification of similar records and inconsistencies.
Result: Data harmonisation following a subsequent acquisition now takes three times less time. Management reports are based on consistent data, and the board works from a single, commonly understood version of the numbers. Errors in the catalogues fell by close to 90%, and the organisation can now manage a significantly larger portfolio while keeping its data team at its current size.
Metrics: 3× - faster harmonisation after acquisition · −85% - errors in master data · 12 - integrated source systems
Client quote: "For the first time in a long while, everyone on the board is looking at the same number - and we know where it comes from."
## Latest articles (20, full content)
### SAP Basis outsourcing in Poland: scope, SLAs and security
URL: https://snok.ai/en/news/blog/sap-basis-outsourcing-poland/ | Date: 2026-10-07 | Series: Other
Ask what a **SAP Basis outsourcing** contract covers and the answer usually comes down to three words: monitoring, patching, on-call. None of them tells you who picks up a security alert at 2 a.m., who decides on the second Tuesday of the month which **SAP Security Patch Day** notes go to production that week, or which tool will monitor your landscape once standard maintenance for SAP Solution Manager runs out.
We have run SAP Basis operations for years, and in one of the landscapes we look after, Basis support and round-the-clock security monitoring have sat with the same team since February 2023. What follows covers the scope of the service, the checks we run every day, how to read an SLA, and where operations and security overlap.
**In short:**
**1/** Basis outsourcing covers the technical layer - system, database, kernel, transports, backups and performance; functional support and development are separate services, and the contract should say so,
**2/** the quality of the service shows in the daily system check; ours runs through seventeen transactions, from instance status to stuck transport imports and IDoc backlogs,
**3/** an SLA is only useful when it separates response time from restoration time and states who keeps the clock,
**4/** security patching, hardening and event monitoring are Basis work, so it is simplest when one provider owns them, with a periodic penetration test checking the result from outside.
## What SAP Basis outsourcing covers
The scope runs from daily system checks and alert handling through to SAP HANA administration: backups, disaster recovery, high availability and capacity planning. In between sit patching and upgrades (SAP Security Notes, kernel, support packages), performance analysis and tuning, change management with transport control, and 24/7 incident handling.
The boundary that causes most arguments after signature lies between the technical layer and the application. Basis support is responsible for keeping the system running, current and fast. It is not responsible for a misconfigured finance module or a report written by another vendor. If the contract does not separate the two, every incident starts with a debate about ownership while the SLA clock is already running.
## When outsourcing beats an in-house team
Genuine 24/7 cover needs several people with comparable skills who can stand in for each other. For many organisations that is more Basis headcount than the landscape justifies, and engineers with real SAP HANA and SAP S/4HANA experience are scarce. Hiring one more person does not solve it; it just moves the gap to holidays and sick leave.
An in-house team, on the other hand, knows the business and the people on the other side of the tickets, and no provider can buy that. A hybrid model therefore often works best: the client's team keeps architecture and decisions, the provider takes on-call duty, routine checks and patching. It only works if the contract is precise about who approves a change to production.
## What we check in an SAP system every day
The daily check is the simplest test of whether a support provider knows what it is doing. Ours covers seventeen transactions in a fixed order. Where it makes sense, a UiPath bot runs the check and compiles the results into one report, so the on-call engineer starts the day by reading it rather than clicking through screens.
This is the core of the check, not all of it. Each landscape gets additional checks that follow from its architecture, its integrations and the client's own requirements.
**System metadata:** SPAM (support package level and product version) and DBACOCKPIT (database version and release). Without these you cannot tell which notes from the next Patch Day apply to you.
**Instances and processes:** SM51 (instance status across all hosts), SM66 (work processes by status across the system) and ST06 (CPU, paging and free disk space on application servers).
**Performance:** ST03 (average response time by dialog, RFC, update and background steps), ST02 (buffer hit ratios, buffer swaps, heap memory) and ST04 (database operating status, HA replication, resource usage).
**Backups:** DB12 (failed data and log backups). A failed backup nobody noticed for a week is the most common reason a recovery plan exists only on paper.
**Errors and locks:** SM12 (lock entries, including those older than 24 hours), SM13 (failed V1 and V2 updates), SM21 (system log by severity), SM37 (failed background jobs) and ST22 (ABAP short dumps).
**Output and interfaces:** SP01 (failed spool requests), STMS_IMPORT (stuck transport imports) and WE02 (IDocs by status).
None of this is secret, and the list itself is not where the value lies. The value comes from comparing one day with the next: a double-digit rise in ST03 response times with no change in load, or IDocs stuck in the same status for three days, tells you more than any single reading. Performance tuning draws on the same data. We adjust buffer and memory parameters on the strength of ST02 and ST03 trends, before users start reporting that the system feels slow.
## Which SLA terms belong in a SAP Basis support contract
The most common mistake is expecting one number to describe the whole incident. Response time says when someone acknowledges the ticket and starts work. Restoration time says when the system is usable again, even if the root cause is still there. Resolution time covers removing the cause, and it can run to days because it depends on an SAP note or a maintenance window. These are three separate commitments, and each deserves its own definition.
Five things are worth checking before you sign:
**Incident classes:** whether the contract defines a critical incident - for example, production unavailable to all users - or leaves it to be argued about during the outage.
**Measurement:** who keeps the clock, and in which tool. If the clock only starts in the provider's ticketing system, a monitoring alert raised an hour earlier does not exist.
**Maintenance windows:** when the provider may take the system down, and who on the client side signs off the downtime.
**Reporting:** what the monthly report contains, and whether it shows trends or just a count of closed tickets.
**Exit:** which documentation, technical credentials and procedures the provider hands over when the contract ends. It is a dull clause until the day you need it.
## Who owns Basis tasks under RISE with SAP
Moving to **RISE with SAP** shifts the line of responsibility; it does not remove it. SAP runs the infrastructure, operating system, SAP HANA database, backups and technical monitoring. Application configuration, users, roles, the audit log, integrations and custom code stay with the customer.
Two points from SAP's own material catch most teams off guard. For security patches at the technical Basis layer, SAP prepares tested packages, but under the contract it is the customer who requests deployment and accepts the downtime in a maintenance window. A penetration test, meanwhile, is only allowed at the application layer and only with SAP's approval. Someone on your side still has to follow Patch Day, assess the notes and raise the requests. That is still Basis work; it has simply moved. We cover this in more detail in our article on [secure SAP S/4HANA conversion and RISE with SAP](/en/news/blog/secure-sap-s4hana-conversion-rise-with-sap/).
## SAP Security Patch Day as part of daily operations
SAP publishes security notes on the second Tuesday of every month. For a Basis team it is a fixed point in the calendar: work out what is missing, assess which notes apply to your configuration, plan deployment through development and test, then schedule the production window. Without support package levels and component versions - the output of the daily check - that assessment is guesswork.
A client we have worked with since 2023 put it well in an interview with ITwiz (translated from Polish): "In many cases only the technical layer, such as the kernel or the database libraries, is updated with any regularity. Updating functional components is more complex [...]. The result is that some older components go unpatched for years." That is why we tie Patch Day to an upgrade plan for the whole landscape, not just the kernel. The monthly cycle is described on our [SAP Security Patch Day](/en/offer/sap-security/sap-security-patch-day/) page.
## Hardening, security monitoring and penetration testing in Basis support
SAP's default configuration is designed to get a system running quickly. Hardening it - switching off services you do not need, tightening security parameters, RFC connections and technical authorisations - is never a one-off project, because any later change can partly undo it. We made that case in [SAP hardening is a process, not a project](/en/news/blog/sap-hardening-process-not-project/).
Security monitoring adds a second layer on top of technical monitoring. The [SecurityBridge](/en/offer/sap-security/securitybridge/) platform correlates events from SAP logs, flags vulnerabilities in installed components and in ABAP code, and can forward alerts to a SIEM. An alert fixes nothing by itself, though. Someone has to pick it up, assess it and act, and the action is usually a configuration change made by the Basis team. When security monitoring and Basis support sit with two different providers, every alert becomes a hand-off between them.
The third layer is a periodic check from outside. An [SAP penetration test](/en/offer/sap-security/sap-penetration-testing/) or a security audit of development, test and production systems shows whether hardening and patching work the way the documentation says they do. We recommend one a year and after every major change, such as a move to SAP S/4HANA. Our testers work with RedLab AI box, an in-house rig running local language models without the refusal filters of cloud services, which helps with configuration and code analysis. Because the models run locally, test data never goes to an external service. All three layers are optional; the scope depends on the risk and the regulation an organisation is subject to.
## Basis and security under one roof: Stock Spirits and a retail chain
Stock Spirits Group, a spirits producer operating in nine European countries, has worked with us since 2023. The scope, confirmed by the client in reference letters, covers 24/7 support and maintenance of SAP ERP ECC and SAP S/4HANA together with the SecurityBridge platform, support for the UiPath platform and its bots, and administration and monitoring of environments spread across three physical sites. We also carried out a security audit of the development, test and production systems on both platforms.
In the ITwiz interview, the client's group manager for IT infrastructure and cybersecurity described the arrangement like this (translated from Polish): "At STOCK we have the added luxury that the SNOK team supports us operationally in SAP Basis, and in most cases it is that team which responds to SecurityBridge alerts." SecurityBridge went live in production within three weeks, and during the migration to SAP S/4HANA a single licence let the client monitor the new system and the old SAP ECC production landscape in parallel.
At the same client, UiPath bots handle seven recurring administrative processes, and the ERP landscape, with more than 700 users, is under round-the-clock security monitoring. The full story is in the [case study](/en/case-studies/#fmcg-manufacturer-secure-erp).
We run the same model for a DIY retail chain: 24/7 support and maintenance of SAP S/4HANA and the systems around it, with the same scope as at Stock Spirits minus SecurityBridge. The security modules are chosen to fit the client; the service does not depend on them.
## SAP Solution Manager after 2027
For many Basis teams, SAP Solution Manager is still the main monitoring tool. Standard maintenance for SAP Solution Manager 7.2 ends with 2027. Customers who take optional extended maintenance for SAP Business Suite 7 until the end of 2030 get extended maintenance for Solution Manager at no extra cost, but only for listed areas: requirements, project and process management, Test Suite, change control, ITSM and landscape management. Monitoring is not on that list. SAP recommends moving to SAP Cloud ALM before the end of 2027.
For a support contract this raises a concrete question: which tool will your provider use to monitor your landscape in 2028, and who will migrate the rules and custom configuration checks? It is worth asking now, while there is still time to do the migration properly.
## What a transition from an incumbent provider looks like
We start with an assessment of the landscape: system inventory, configuration, documentation, technical debt and current procedures. That gives us the basis for the SLA, the escalation path and the split of responsibilities - what SNOK does, what stays with your team, and what depends on the cloud or infrastructure provider.
For the first month we work alongside the current team. We learn the operating cycles, the recurring incidents and the undocumented workarounds that every system accumulates after fifteen years in production. From the second month we own the agreed scope, deliver a monthly report for the CIO and run a quarterly service review with the board or steering committee.
## How to vet a SAP Basis partner before you sign
A sales presentation tells you little about the quality of day-to-day support. The answers to a handful of questions tell you more:
**1.** What does your daily system check involve, and can we see a sample report?
**2.** Who actually takes the alert at night, and how does it escalate to a database specialist?
**3.** How do you assess SAP Security Patch Day notes, and how many days pass at your clients between a HotNews note being published and going live in production?
**4.** Who responds to security alerts, and is it the same team that makes the configuration changes?
**5.** Which tool will you use to monitor our landscape once standard maintenance for SAP Solution Manager ends?
**6.** What will you hand over to us when the contract ends?
A fuller version of these questions, together with service scope, incident classes and exit criteria, is in our downloadable [SAP Basis support transition checklist](/en/resources/sap-basis-transition-checklist/).
## How SNOK can help
We run [SAP Basis 24/7 as a managed service](/en/offer/sap-security/sap-basis-24-7/): monitoring, patching and SAP Security Notes, performance tuning, change and transport management, SAP HANA administration and round-the-clock incident handling. On request we add SecurityBridge security monitoring, configuration hardening and periodic SAP penetration testing. We support on-premise and cloud landscapes, including RISE with SAP, and for customers leaving SAP ECC we handle the [conversion to SAP S/4HANA](/en/offer/sap-security/s4hana-conversion/). Our partnerships with [SUSE](/en/suse-snok/) and [Lenovo](/en/lenovo-snok/) cover the operating system and hardware layers.
If you are planning a change of support model or provider, start with the [SAP Basis support transition checklist](/en/resources/sap-basis-transition-checklist/). When you are ready to talk, [book a 30-minute call with our team](/en/offer/sap-security/sap-basis-24-7/). We will go through your current SAP landscape, the SLA you need and what belongs in scope. For the wider security picture, see our book [SAP Cybersecurity from A to Z](/en/resources/sap-cybersecurity-a-to-z/).
---
### Sources
- ITwiz, *Udany atak na systemy SAP może zatrzymać każdy biznes* ("A successful attack on SAP can bring any business to a halt"), Executive ViewPoint (partner feature), 26 June 2025, in Polish - [itwiz.pl](https://itwiz.pl/udany-atak-na-systemy-sap-moze-zatrzymac-kazdy-biznes/)
- SAP, *SAP Solution Manager 7.2* - maintenance and transition to SAP Cloud ALM, SAP Note 3255311 - [support.sap.com](https://support.sap.com/en/alm/solution-manager.html) (accessed 6 October 2026)
- SAP Community, Jana Subramanian, *RISE with SAP S/4HANA Cloud, Private Edition: Cybersecurity FAQ Explained* - [community.sap.com](https://community.sap.com/t5/technology-blog-posts-by-sap/rise-with-sap-s-4hana-cloud-private-edition-cybersecurity-faq-explained/ba-p/13562875)
- SNOK, case study *Mission-critical ERP under 24/7 protection* - [snok.ai](/en/case-studies/#fmcg-manufacturer-secure-erp)
---
### UiPath for security teams - what UiPath's own security function runs on its platform
URL: https://snok.ai/en/news/blog/uipath-for-cybersecurity-teams/ | Date: 2026-10-06 | Series: Safe Tuesday
In October 2025, UiPath CISO Scott Roberts said that a threat analyst agent his team had built on the UiPath platform had saved **more than 13,000 hours** of alert-response work. In the same conversation he added two details: one of the workflows is a swarm of 61 agents working in parallel, and in some cases an investigation that used to take up to four hours now takes about a minute and a half. In February 2026 he described the whole set-up as an orchestration of more than 60 agents that investigate SIEM alerts end to end and produce structured incident write-ups.
This is a vendor's own claim, not an independent measurement, and we read it as such. Its value lies in the specifics: it describes a mechanism in use inside the security function of the company that sells the platform, and it shows where an automation platform earns a place in a team that already runs a SIEM, EDR and SOAR.
**In short:**
**1/** UiPath's security team (TrustOps) uses its own platform to triage alerts, score vulnerabilities in the context of its products and have agents check the output of other agents,
**2/** in a cybersecurity team UiPath does not replace the SIEM - the vendor itself now calls its offering a SOAR layer, one that acts where there is no API, takes over the work that surrounds an incident or an audit, and hands high-impact actions to a human for approval,
**3/** SAP security is where the manual work is heavy and published automation patterns are scarcest: access reviews, bot accounts, SAP Security Patch Day notes,
**4/** the precondition is control over the bots themselves - a bot in a security role holds a combination of privileges you would never give one person.
A 24-second silent loop: from a SIEM alert, through UiPath agents, to the six NIST CSF 2.0 functions. Figures in the animation: UiPath security team, 2025-2026; the SIEM console is illustrative.
## What UiPath's security team runs on its own platform
The most detailed accounts come from three sources: Scott Roberts in conversation with Averlon (21 October 2025), the Shift AI podcast (21 February 2026), and a post by Kevin Mooney, UiPath's Field CISO, published on 9 July 2026 and based on a discussion among four members of TrustOps. Together with a Dropzone AI case study, they point to four uses.
**A threat analyst agent.** An alert from the SIEM goes to an orchestration of more than 60 agents. They investigate the event end to end and produce a structured incident write-up. It is this agent that Roberts credits with the 13,000 hours saved.
**Agents checking agents.** Where model output is non-deterministic, the team uses what it calls judge agents: one agent produces a result and a second checks it before the next step. In our view it is the easiest pattern to adopt elsewhere, because it answers the first objection to AI in security - that the model will get it wrong and nobody will notice.
**Vulnerabilities scored in context.** Roberts puts the inflow at around 500 new open-source vulnerabilities a week. A typical scanner matches a component's name and version against a CVE database and repeats the database score. According to Mooney's post, UiPath's team combined RPA to collect the data with generative agents that read the vulnerability description and the vendor's advisory, plus continuous scanning and exploitability analysis, all orchestrated by UiPath agents and robots. The output is a CVSS score with base, temporal and environmental metrics, backed by exploitability analysis - a measure of how much a flaw matters in the context of a specific product.
Roberts described a separate case in his conversation with Averlon. After a critical zero-day, the scanners reported tens of thousands of occurrences - Roberts speaks of around 20,000 instances to patch within a two-hour window. Averlon's tooling narrowed that down to the paths an attacker could actually reach, and the team patched those within hours. It is the same principle - exploitability matters more than the mere presence of a component - delivered with another vendor's tool.
**First-line triage.** Dropzone AI handles first-line triage, closing simple alerts and escalating harder ones, with their context intact, to the agentic SOC UiPath has built. The results block of a case study published by Dropzone AI lists 86% fewer false positives and more than 700 analyst hours saved over six months.
The July post says the security automation UiPath now offers customers is "the leading edge of what the UiPath TrustOps team already runs on itself". The post does not say which of these mechanisms are already products, so availability needs checking case by case.
## Where UiPath fits in a cybersecurity team
For the wider picture, we have mapped potential uses against the six functions of NIST CSF 2.0. Each function contains work that falls between systems and outside the scope of the SIEM, the EDR and the GRC tool.
**Govern.** Audit evidence for ISO 27001, SOX or NIS2 consists largely of screenshots, exports and user lists. A robot can collect it on a schedule, stamped with date and source, rather than by hand before each audit. Supplier assurance under DORA belongs here as well; our proposed flow fetches a supplier's SOC 2 or SOC 3 report, reads the auditor, period and scope, and checks them against your requirements. UiPath has demonstrated the first part with UiPath ScreenPlay in December 2025: a robot finds a supplier's SOC 3 report and extracts the auditor, coverage period, report type and scope.
**Identify.** Vulnerabilities scored in context, as at TrustOps, and inventory reconciliation: does every device in the CMDB have an EDR agent, and does the scanner see everything it should?
**Protect.** The account lifecycle - joiner, mover, leaver - plus password resets and account unlocks. In 2022 UiPath reported that automating user management in its own IT team cut ITSM ticket handling from two hours to two minutes. According to a case study published by UiPath, Jana Small Finance Bank, facing 300-400 password reset requests a day, brought that work down from three to four hours a day to under an hour. Add access reviews, with the owner's sign-off routed through UiPath Action Center.
**Detect.** Robot and agent logs in the SIEM. Since release 2025.10 a unified audit log gathers events from every platform service in one place and, in UiPath's words, provides the link between automation activity and observability systems such as Splunk or Microsoft Sentinel. Every agent runs under its own identity, with permissions assigned the same way as for people and robots.
**Respond.** Alert triage by agents, and the actions a SIEM cannot take because the firewall or the legacy system has no API: blocking an address, quarantining a file, isolating a device. In 2022 UiPath said its own automations were blocking more than 20,000 brute-force attacks a year. A draft incident notification to the CSIRT also fits here - facts, deadlines, a version ready for sign-off. Deciding that an incident is significant stays with a person.
**Recover.** Post-incident reporting, a lessons-learned log, corrective actions assigned to owners in the ticketing system. Here automation mainly makes sure the follow-up reaches the people who own it.
## Where UiPath stops
UiPath does not replace the SIEM and is not a security operations platform in the mould of Splunk SOAR or Cortex XSOAR, although in 2022 it wrote that it enables full-scale SOAR, and in 2026 it calls its offering a SOAR layer and publishes a SOAR accelerator on its Marketplace. Security operations tools are building their own AI agents - Splunk, Torq, Tines, Swimlane and a crop of specialist start-ups. UiPath comes in where those tools stop: in systems without APIs, in the business processes around an incident, and in human approval.
Most of the ready-made connectors today cover the Microsoft stack. UiPath Integration Service has connectors for Microsoft Sentinel, Defender for Cloud, Sentinel Threat Intelligence, Entra ID and ServiceNow, and the Marketplace adds VirusTotal, AbuseIPDB, urlscan.io, Shodan, Defender for Endpoint and CrowdStrike. In March 2026 UiPath announced a collaboration with Microsoft in which Defender for Cloud scans files moving through business processes, Sentinel receives the incident with business context, and a robot quarantines the file or pauses the process.
We found no ready-made connector for Splunk or Splunk SOAR. Integration has to be designed over the REST API - for instance, a Splunk alert starting a process in Orchestrator and a robot writing the result back. That is an integration project in its own right.
## SAP: heavy manual work, few ready-made patterns
SAP security involves a great deal of manual work, yet little has been published on automating it. A question about automating SAP GRC, posted on the UiPath forum in April 2022, has close to 1,500 views, and the replies go no further than a general note that any SAP interface can be automated. In the material we reviewed, SAP security vendors make no mention of UiPath, and UiPath has no official write-up on automating SAP GRC or SAP Security Patch Day - only a general community post on SAP compliance and audit automation from October 2024. On 29 September 2026 UiPath and BDO USA announced internal audit accelerators with always-on access review, validation of provisioning and deprovisioning, and segregation-of-duties monitoring across ERP and cloud systems. For now it is an announcement with no deployment described.
In SAP we would start with three uses.
**SAP Security Patch Day notes in context.** Every month SAP publishes security notes, and the team has to work out which ones apply to its releases, components and configuration. The TrustOps pattern - a robot collects the data, an agent reads the note, exploitability is assessed - can be applied to SAP notes, with [SecurityBridge](/en/offer/sap-security/securitybridge/) supplying the system state. The output would be a list of notes, each with an owner and a deadline.
**Bot accounts in SAP.** A robot working through SAP GUI needs a dialog user, while a robot calling BAPIs can run on a system user. Each carries a different risk, and RFC integration needs additional authorisations that have to be granted deliberately and reviewed. A bot account without a named owner can be missed in the access review, because nobody signs off its authorisations.
**Access reviews and audit evidence.** A robot can collect dated exports and screenshots, compare them with the approved access list and route discrepancies to the owner. Once an attack path is known - from a tool such as [SAPMAP](/en/news/blog/sapmap-bloodhound-for-sap/), for example - the same mechanism can check that removed authorisations do not creep back.
## The precondition: bots under the security team's control
A bot in a security role needs broad read access - the identity provider, the EDR, the scanner, the CMDB - and often the right to change things too: lock an account, close a ticket, isolate a device. No single person would be given that combination. Automation in a security team therefore starts with control over the bots.
The best-documented example of what happens without it is an audit by the US General Services Administration's Inspector General, published on 6 August 2024. The agency's RPA programme did not meet its own IT security requirements, and system security plans were not consistently updated to cover bot access. Rather than fix these gaps, programme management removed or relaxed the requirements. There was also no process for removing access once a bot was retired: 55 of the 56 custodians of decommissioned bots kept their access beyond the 14 days the agency's policy allows.
Five preconditions:
**1/** a dedicated account for every bot, with a named business owner and never a shared login,
**2/** credentials in a vault - Orchestrator integrates with CyberArk as a PAM system and with secret stores such as Azure Key Vault and HashiCorp Vault,
**3/** least privilege and segregation of duties between the bot and the person who supervises it,
**4/** robot and agent logs in the SIEM, so every bot action leaves a trail,
**5/** access for the bot, its custodians and its developers revoked on the day the bot is retired, through the same process as a leaver.
The same applies to AI agents. High-impact actions go through a human approval gate - we covered this in [HITL gates in UiPath Maestro and the AI Trust Layer](/en/news/blog/hitl-gates-uipath-maestro-ai-trust-layer/).
## How we work with cybersecurity teams
SNOK brings three things to this work: SAP security, a UiPath Platinum partnership and our own ISO 27001-certified information security management system. For security teams we propose four stages:
**1/** an inventory of bots and agents - accounts, privileges, owners, credentials, logs; this is the [AI security review](/en/offer/ai-automation/ai-security/) that comes before any further rollout,
**2/** choosing the two or three processes that take the most manual effort, such as gathering audit evidence, access reviews and account handling,
**3/** implementing them in [UiPath Maestro](/en/offer/ai-automation/uipath-maestro/), with human approval for high-impact actions and timings measured before and after,
**4/** extending the work to SAP - [SAP Security Patch Day](/en/offer/sap-security/sap-security-patch-day/), bot accounts, access reviews - and evidence for a [NIS2 and DORA audit](/en/offer/sap-security/nis2-dora-audit/).
There is more in our [cybersecurity offer](/en/offer/cybersecurity/) and on the [UiPath at SNOK](/en/uipath-snok/) page. For an earlier take on UiPath in security operations, see [UiPath as an agentic cybersecurity guardian](/en/news/blog/uipath-agentic-cybersecurity-guardian/).
## Where to start
The first step needs no new licence. It is a list of every bot and agent running in your organisation today, with its account, its privileges and its owner. If that list exists and is current, you are in a position to hand security work to bots. If it still has to be built, that is where to start.
[Get in touch](/en/contact/) - we will show you what a bot inventory and a first security process in UiPath look like.
## Sources
- UiPath, Kevin Mooney, "When AI finds everything, the trick is knowing which vulnerabilities matter", 9 July 2026, [uipath.com](https://www.uipath.com/blog/ai/how-ai-is-changing-vulnerability-management) (accessed 5 October 2026).
- Averlon, webinar "Inside UiPath: How Agentic AI is Redefining Security in the AI Era" with Scott Roberts, 21 October 2025, [averlon.ai](https://www.averlon.ai/webinars/inside-uipath-redefining-security-ai-era) (accessed 5 October 2026).
- Shift AI Podcast, "Securing Agentic Automation in the Enterprise with UiPath CISO Scott Roberts", 21 February 2026, [YouTube](https://www.youtube.com/watch?v=T_V3kbYVeXE) (accessed 5 October 2026).
- Dropzone AI, "How UiPath Extended Its Agentic SOC with AI SOC Analysts", [dropzone.ai](https://www.dropzone.ai/case-studies/how-uipath-extended-its-agentic-soc-with-ai-soc-analysts) (accessed 5 October 2026).
- UiPath, Jagjit Dhaliwal, "How is UiPath Automating Cybersecurity Operations?", 24 May 2022, [uipath.com](https://www.uipath.com/blog/automation/automating-cybersecurity-operations) (accessed 5 October 2026).
- UiPath, Andrei Oros, "Are your enterprise automation workflows connected to your security stack?", 18 March 2026, [uipath.com](https://www.uipath.com/blog/product-and-updates/are-enterprise-automation-workflows-connected-security-stack) (accessed 5 October 2026).
- UiPath, Andrei Hinodache, "Governance and security for the agentic enterprise: new in the 2025.10 release", 19 November 2025, [uipath.com](https://www.uipath.com/blog/product-and-updates/agentic-enterprise-governance-and-security-2025-10-release) (accessed 5 October 2026).
- UiPath, Jana Small Finance Bank case study, [uipath.com](https://www.uipath.com/resources/automation-case-studies/jana-small-finance-bank) (accessed 5 October 2026).
- UiPath, "UiPath Expands Partnership with BDO", 29 September 2026, [uipath.com](https://www.uipath.com/newsroom/uipath-expands-partnership-with-bdo) (accessed 5 October 2026).
- GSA Office of Inspector General, "GSA Should Strengthen the Security of Its Robotic Process Automation Program", report A230020/B/T/F24004, 6 August 2024, [oversight.gov](https://www.oversight.gov/reports/audit/gsa-should-strengthen-security-its-robotic-process-automation-program) (accessed 5 October 2026).
- NIST, "The NIST Cybersecurity Framework (CSF) 2.0", 26 February 2024, [nist.gov](https://www.nist.gov/cyberframework) (accessed 5 October 2026).
- UiPath Forum, "UiPath Studio With SAP GRC", 27 April 2022, [forum.uipath.com](https://forum.uipath.com/t/uipath-stuido-with-sap-grc/418670) (accessed 5 October 2026).
- UiPath Community Blog, Ashish Pandey (RPATech), "Automating SAP compliance and audit processes with UiPath", 3 October 2024, [uipath.com](https://www.uipath.com/community-blog/tutorials/automating-sap-compliance-and-audit-processes) (accessed 6 October 2026).
---
### SUSE named a Leader in the 2026 Gartner Magic Quadrant for Container Management - fleet governance, edge and sovereignty
URL: https://snok.ai/en/news/blog/suse-leader-gartner-magic-quadrant-container-management/ | Date: 2026-10-05 | Series: Announcements
For many organisations Kubernetes is no longer a project. It is infrastructure, and the hard part has moved from getting clusters running to keeping them consistent across clouds, data centres and remote sites. The **Gartner Magic Quadrant for Container Management**, published on **2 September 2026**, describes the market in exactly those terms.
Gartner assessed **sixteen vendors** and placed **seven** in the Leaders quadrant, **SUSE** among them. There are no Visionaries in this edition. The Leaders, listed alphabetically, are Alibaba Cloud, AWS, Google, Huawei, Microsoft, Red Hat and SUSE. Gartner does not rank vendors within a quadrant, so the order carries no meaning. The report is by Dennis Smith, Tony Iams and four other analysts.
**Key points:**
**1/** Gartner sees a mature market in which results depend on a consistent way of governing clusters, policy and security across on-premises, cloud and edge environments.
**2/** The inclusion bar is commercial as well as technical: a baseline of USD 50 million in annual revenue from the offering (USD 15 million on an alternative route) and production customers in several regions.
**3/** Gartner lists three strengths for SUSE: management of mixed Kubernetes distributions from a single control plane, a strong edge position built on K3s, and sovereign capabilities that combine European ownership with strong technical capabilities.
**4/** According to SUSE's own announcement, this is its third consecutive year in the Leaders quadrant.
*Figure 1: Magic Quadrant for Container Management. Source: Gartner (September 2026), reproduced without changes. This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available from [SUSE](https://www.suse.com/campaigns/2026-gartner-mq-container-management/).*
---
## Gartner's view of the market
Gartner defines container management as software that deploys and operates containerised workloads and the resources around them, under central governance of policy and security. Mandatory capabilities include orchestration and scheduling, a container runtime, an artifact registry, routing and networking, a service catalogue, a management interface and API access. Fleet management, platform engineering support, policy and governance, image supply chain security, and support for virtual machines and AI workloads are listed as optional.
The market overview matters more than the definition. Gartner describes a shift from innovation to practical optimisation. Savings expected from containers are often absorbed by growing operational overhead, and proprietary add-ons from vendors erode portability. Demand for hybrid and multicloud deployments is strong, but lock-in still holds organisations back. Gartner also observes that organisations perform better when support is centralised in a platform engineering team rather than spread across application teams. For an IT leader, the open question is less about running Kubernetes and more about who governs the estate and to which standard.
The inclusion criteria show how far the category has consolidated. A vendor needed at least **USD 50 million** in GAAP revenue from its container management offering, **50 paying production customers** and at least five customers in each of three of seven regions. An alternative route required USD 15 million in revenue, 15 net new customers in 2025 and three customers in each of two regions. The offering also had to be available without mandatory professional services, with first-line support provided by the vendor, including for bundled open source components.
## SUSE's strengths according to Gartner
Gartner calls the SUSE portfolio extensive and flexible. **SUSE Rancher Prime** sits at the centre: a management platform for hybrid, multicloud and edge environments. It is backed by two distributions, **RKE2**, a hardened Kubernetes for highly regulated environments, and **K3s**, a lightweight distribution for resource-constrained sites. **SUSE Virtualization** combines virtualisation, Kubernetes orchestration and storage in one stack.
Gartner names three strengths.
**Mixed distributions under one control plane.** Rancher manages a wide range of Kubernetes distributions whether clusters run on-premises, in public cloud or at the edge. Gartner's point is that an organisation can pick a different provider or distribution for each use case without paying for it in fragmented tooling and duplicated skills.
**Edge with K3s.** K3s exposes the full Kubernetes API in a small footprint. Platform teams can extend the governance and security policies they apply in the data centre to factory floors and branch offices without significant hardware spend.
**Sovereignty.** Gartner highlights SUSE's European ownership, combined with strong technical capabilities, as an advantage for buyers who prioritise sovereign solutions, reducing some geopolitical supply chain risk and simplifying data residency requirements such as GDPR. A vendor's ownership is one factor in that assessment, not a substitute for it. Whether a deployment meets GDPR, NIS2 or DORA depends on its architecture and on the operating processes around it.
## Questions to settle before choosing a platform
Gartner itself notes that a Leader is not the best choice for every use case. The report is more useful as a checklist of the questions that should precede a decision.
**Mixed estates.** When some clusters run on a hyperscaler, some in your own data centre and some were left behind by past projects, the first task is visibility: where each cluster runs, which version, who has access and which policies apply. Tool selection comes after that.
**Remote sites.** Plants, warehouses and branches rarely have a platform engineer on site, yet their clusters must stay up and be patched remotely. K3s was designed for this case.
**Data residency and vendor dependence.** In regulated industries, the vendor's ownership and the location of operational control are often part of the risk assessment. Gartner names this explicitly as a SUSE characteristic.
**Virtual machines alongside containers.** Changes in virtualisation licensing have pushed many organisations to review their estates. SUSE Virtualization runs virtual machines and containers on one platform. We look at the SAP side of this in [VMware or KVM for SAP](/en/news/blog/vmware-vs-kvm-for-sap/).
SUSE also sells a separate product, [SUSE Rancher for SAP applications](https://www.suse.com/products/rancher-for-sap/). The Magic Quadrant does not assess it, so we treat its capabilities as vendor claims and validate them in each project.
## How SNOK approaches a container platform
SNOK is a **SUSE Gold Partner**. The scope of the partnership is described on our [SUSE page](/en/suse-snok/), and our other vendor relationships on the [partnerships page](/en/partnerships/).
Our container platform engagements follow three steps.
**Inventory.** We establish how many clusters exist, which distributions they run, where they are hosted, who maintains them and which workloads are critical. This sits within [IT advisory and integration](/en/offer/it-advisory-integration/), and the findings often change the original brief.
**A pilot on one management layer.** We bring a few clusters of different types under a single management layer and agree the success criteria in advance: versions, policies, access control and update cadence.
**Hardening and operations.** Configuration hardening, access policy and continuity fall under [cybersecurity](/en/offer/cybersecurity/). Where SAP systems run on the platform, [SAP Basis 24/7](/en/offer/sap-security/sap-basis-24-7/) covers them as well. Running language models on your own clusters is part of our [LLM on-premise](/en/offer/ai-automation/llm-on-premise/) offering.
The Magic Quadrant position is SUSE's. What it confirms for buyers is that container management is now judged on consistent governance, portability and sovereignty, the same criteria that should shape an internal platform decision. A cluster inventory and a pilot on a sample of the estate test those criteria against your own environment. To discuss an inventory, [contact us](/en/contact/).
---
## Sources
- Gartner, *Magic Quadrant for Container Management*, 2 September 2026 (corrected 3 September 2026), ID G00841470, by Dennis Smith, Tony Iams and four others; accessed 1 October 2026.
- Licensed reprint provided by SUSE: [SUSE report page](https://www.suse.com/campaigns/2026-gartner-mq-container-management/), accessed 1 October 2026.
- SUSE, [SUSE Recognized as a Leader in 2026 Gartner Magic Quadrant for Container Management](https://www.suse.com/news/suse-recognized-as-a-leader-in-2026-gartner-magic-quadrant-for-container-management/), 8 September 2026, accessed 5 October 2026.
GARTNER is a registered trademark and service mark, and MAGIC QUADRANT is a registered trademark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.
---
### Vendor lock-in in 2026 - a golden padlock or a bunch of keys
URL: https://snok.ai/en/news/blog/vendor-lock-in-golden-padlock-or-bunch-of-keys/ | Date: 2026-10-05 | Series: Other
On 2 September Broadcom reported that its infrastructure software segment - VMware, for the most part - brought in 8.75 billion dollars in the quarter, up from 6.79 billion a year earlier. That is 29% growth. In February CloudBolt published a survey in which 86% of large North American companies said they were actively reducing their VMware footprint. Roughly 4% had walked away completely.
The two numbers don't contradict each other, and together they describe vendor lock-in in 2026 better than any definition. Announcing an exit costs nothing; for as long as the migration lasts, the licence still has to be renewed.
I am not writing from a neutral position. SNOK partners with SAP, UiPath, SUSE, Lenovo, Microsoft and Google Cloud, so every day we hold both the padlock and the keys: we implement platforms that bind customers for years, and we help customers loosen those bonds. So I won't point you in any direction. I will defend one claim: a dependency chosen deliberately and priced before the decision is an architectural decision, while an accidental one reveals itself at renewal.
*Cover image generated by AI from a photograph of the author.*
## VMware under Broadcom: customers announce their exit, revenue keeps climbing
After closing the VMware deal in late 2023, Broadcom stopped selling perpetual licences and moved to per-core subscriptions. In March 2025 a distributor told partners that the minimum order would rise to 72 cores and that late renewals would carry a 20% surcharge. After the backlash, heise reported, the core minimum was dropped and licences can still be bought from 16 cores - but the signal of how fast the terms can shift has stayed with customers. In January 2026 Broadcom closed its cloud service provider programme to most partners.
The pushback has moved to the courts. Rijkswaterstaat, the Dutch agency that runs tunnels, locks and bridges on VMware, won two years of support from a court in The Hague in 2025 so it could migrate. Tesco is suing Broadcom, VMware and Computacenter in the UK. The European Commission sent Broadcom a formal request for information in February 2026, and in August the EU General Court refused Broadcom's bid to suspend it. In late August the VDDK, a library many migration and backup tools rely on, disappeared from public download. Broadcom has not commented, so what we know comes from users and trade press.
In September 2025 Broadcom CEO Hock Tan said more than 90% of the top 10,000 customers had bought VMware Cloud Foundation - and added, in the same breath, that this does not mean they have deployed it. Vendors rarely separate purchase from deployment this clearly themselves.
There have never been more VMware alternatives: Proxmox VE, Nutanix AHV, Red Hat OpenShift Virtualization, Microsoft Hyper-V and Azure Local, HPE Morpheus VM Essentials, SUSE KVM. For SAP shops the list gets short quickly. SAP HANA in production is supported on VMware vSphere, SUSE KVM and Nutanix AHV, and not on OpenShift Virtualization. Gartner expects about a third of today's VMware workloads to run elsewhere by 2028, warns that a full migration takes three years or more, and cautions that anyone switching purely to save money may be disappointed.
I don't know who funds that gap more - those who stay, or those who haven't managed to leave yet. I do know that a gradual reduction means two platforms, two teams and two contracts for several years. If that is the path we choose, I'd rather price it now than at the next renewal. First, though, it is worth settling honestly whether we were dependent on VMware, or on the fact that for years nobody had to change anything.
## SAP: the line moves from licences to data
The timeline is well known. SAP ECC mainstream maintenance ends in 2027 and extended maintenance runs to 2030 at extra cost. The 2033 date that circulates as an "ECC extension" applies only to customers who move to SAP ERP, private edition - in practice RISE with SAP - before the end of 2030. On premise, the wall is still 2030.
In July 2023 Christian Klein said SAP's new innovations would not be available to on-premise ERP customers or to those hosting on hyperscalers. In May 2026 SAP partly reversed course: most SAP Joule assistants and agents will reach ECC and S/4HANA on premise, but only for customers who have committed the majority of their landscape to migration. AI on premise has become a term of the migration contract.
The bigger shift concerns data. SAP Note 3255746 has long restricted the use of the ODP-RFC interface for pulling SAP data into third-party tools. In 2026 the restriction stopped being words in a note: according to Qlik, Matillion and Theobald Software, SAP introduced technical enforcement, with a temporary opt-out until the end of 2026. A data warehouse from another vendor is still possible, but the road to it runs through SAP's own options.
The German user group DSAG asked its members about the new SAP Business Suite vision in its 2026 investment report. For 62% it is a weak basis for investment planning or none at all, and 70% name SAP licensing and contracts as a challenge.
One data model from finance to logistics and a single vendor responsible for security patches and legal localisation such as Poland's KSeF e-invoicing are real value, and many companies knowingly pay for it with dependence. I'd argue that for many firms, standardising on SAP was one of the cheapest decisions of the past twenty years.
Data ownership is what occupies me most here. If the vendor decides which interface may carry data out of the ERP, part of the decision about your data warehouse or AI platform is made outside the company. 2033 has a price too: postponing costs money, and someone should put a number on it before the deadline starts making the decision for us.
## UiPath: open protocols, a closed centre
UiPath is opening its platform to the outside world. Maestro orchestrates agents built with LangChain, Anthropic or Microsoft, the platform speaks MCP and A2A, and in autumn 2025 the company announced partnerships with OpenAI, NVIDIA, Google, Microsoft and Snowflake. At the same time, since May 2025 UiPath agents are billed in Platform Units, and orchestration, queues, credentials, audit logs and the whole operational history of your processes stay in Orchestrator.
An open protocol does not make assets portable. A workflow written in XAML with UiPath activities won't convert to another platform; it has to be rewritten. The same is true of Power Automate, which ties automation to Entra ID and Dataverse, and of Blue Prism with its own package format.
The "open source" alternative deserves a careful read of the licence too. n8n ships under the Sustainable Use License, which allows use only for internal business purposes and is not an OSI-approved open source licence. Robot Framework, Temporal and LangGraph do carry OSI licences, though LangGraph's hosted platform is a commercial product.
In automation, the path is chosen in practice at the first deployment. Once rewriting your processes costs more than several years of licences, changing platform stops being a real option, however many protocols it supports. MCP opens up integration, but orchestration and consumption-based licensing stay with the vendor.
I wrote more on where the robot ends and the agent begins in [Agent or a repackaged bot](/en/news/blog/agent-or-repackaged-bot-ten-questions/).
## Open source can close the door too
In 2023 HashiCorp moved Terraform from MPL 2.0 to the Business Source License, and the community answered with the OpenTofu fork. In 2025 HashiCorp became part of IBM in a 6.4-billion-dollar deal. Redis dropped its BSD licence in 2024, which gave rise to Valkey under the Linux Foundation, then returned to open source in 2025 by adding AGPLv3. Elastic made the same round trip. In August 2025 Broadcom moved most Bitnami images to an unmaintained legacy repository and kept the full catalogue in a paid tier. In April 2026 the MinIO repository was archived with a note saying it is no longer maintained.
Open source changes the kind of dependence you carry. You depend less on a licence and more on whether anyone in your organisation can maintain a fork when the company behind the project changes the rules.
So the risk lies less in the licence itself and more in the business model of the single company behind a project, and in whether anyone on your team could maintain the code without it. Redis and Elastic returning to OSI licences mostly shows that the rules can change in both directions.
## Cloud: an exit without fees is not an exit without cost
On paper, leaving a cloud has never been cheaper. From 12 January 2027 the EU Data Act bans switching charges for data processing services. AWS, Google Cloud and Microsoft Azure have waived egress fees for customers moving out since 2024, each with its own conditions; since September 2025 AWS gives you 90 days to finish the move.
And yet Gartner expects public cloud spending to grow 21.3% in 2026. 37signals says its cloud exit will save more than 10 million dollars over five years - a company's own claim, not an audited figure, from a business with an unusually predictable workload. When you leave a cloud, the transfer fee is usually the small part of the bill. Replacing managed services that exist only in one provider's cloud, reworking the architecture built around them and retraining the team cost more.
The second thread is digital sovereignty. In June 2025 a Microsoft France executive told a French Senate inquiry under oath that he could not guarantee French citizens' data would never reach US authorities. AWS launched its European Sovereign Cloud in January 2026, starting in Brandenburg. Schleswig-Holstein moved its entire administration's email to Open-Xchange and Thunderbird in 2025, and the International Criminal Court is moving to openDesk.
My test is whether the environment can be rebuilt outside the cloud from code, or only the data can be recovered. The 37signals calculation applies to predictable workloads, so before talking about repatriation I would check how many of those we actually have. Nor am I convinced that a US provider's sovereign cloud with a European subsidiary solves the problem raised in the French Senate. It seems to move it one level up the ownership chain.
AI models follow the same pattern. According to Menlo Ventures - an Anthropic investor - only 11% of enterprises switched model provider within a year, even though switching is technically simple. MCP moved to a Linux Foundation-hosted foundation in December 2025, but your prompts, evaluations and data stay where you built them. I described our own experiments with locally run models in [Mac Studio versus DGX Spark](/en/news/blog/mac-studio-512gb-vs-dgx-spark-poc-machine/).
## DORA and NIS2: the exit plan becomes an obligation
Since January 2025 DORA has required financial entities to hold a tested exit strategy for ICT services supporting critical or important functions. On 18 November 2025 the European Supervisory Authorities designated 19 critical ICT third-party providers, including AWS, Google Cloud, Microsoft and SAP; substitutability was one of the criteria. So the requirement is a tested exit plan from providers the regulator itself has judged hard to replace.
In Poland, the amended National Cybersecurity System Act - the local implementation of NIS2 - has applied since 3 April 2026, and the deadline for essential and important entities to register passed on 3 October. Supply chain risk management has been a statutory obligation since that day. We covered what that means for SAP systems in [NIS2, KSC and SAP](/en/news/blog/nis2-ksc-sap-register-by-3-october/).
An exit plan that exists only as a document for the auditor will not survive the first real change of terms. I would also add one line that many supplier risk registers lack: the vendor changes its licensing model mid-contract.
## Which path we choose
I don't think vendor lock-in is bad by nature. Every architectural decision is a dependency of some kind - on a vendor, a community, your own team, or the one engineer who understands the configuration. Trouble starts when the dependency is accidental and you only learn its price at renewal.
Before we decide on the next platform, I want to know five things. What leaving costs, calculated today rather than on the day we need it. Who can extract the data, and in what format, without the vendor's consent. What would have to be rewritten and what would move as it is. What happens if the vendor changes the licence halfway through the contract, and whether the contract says anything about it. And whether we have people who can run the alternative if we choose it.
Which dependency in your architecture did you choose deliberately, and which one did you only discover on the invoice?
If a decision like this is coming up for you in the next few months, I'm happy to work through it with you. At SNOK we do this as part of our [IT advisory and integration](/en/offer/it-advisory-integration/) work.
## Sources
- Broadcom, Form 8-K for fiscal Q3 2026, 2 Sep 2026, accessed 4 Oct 2026: https://www.sec.gov/Archives/edgar/data/0001730168/000173016826000076/avgo-08022026x8kxex99.htm
- CloudBolt, VMware survey, 17 Feb 2026, accessed 4 Oct 2026: https://www.cloudbolt.io/company/news/new-cloudbolt-research-86-of-companies-actively-reducing-their-vmware-footprint/
- The Register, VMware licensing changes (72 cores, late renewal penalty), 28 Mar 2025, accessed 4 Oct 2026: https://www.theregister.com/2025/03/28/arrow_vmware_licensing_change/
- heise, VMware drops the 72-core minimum, 10 Apr 2025, accessed 4 Oct 2026: https://www.heise.de/en/news/VMware-backs-down-companies-can-continue-to-license-16-cores-10347066.html
- The Register, Rijkswaterstaat and the Hague court ruling, 30 Jun 2025, accessed 4 Oct 2026: https://www.theregister.com/2025/06/30/dutch_agency_wins_right_to/
- The Register, Hock Tan on VCF adoption, 5 Sep 2025, accessed 4 Oct 2026: https://www.theregister.com/2025/09/05/broadcom_q3_2025/
- Macfarlanes, EU General Court on the Commission's request for information to Broadcom, 7 Sep 2026, accessed 4 Oct 2026: https://www.macfarlanes.com/insights/102o0cz/broadcom-vmware-eu-general-court-again-weighs-in-favour-of-commissions-broad-in/
- Virtualization Howto, VDDK removed from public download, 7 Sep 2026, accessed 4 Oct 2026: https://virtualizationhowto.com/2026/09/leaving-vmware-just-got-harder-after-broadcom-pulled-vddk-downloads
- The Register, Gartner on VMware migration, 11 Sep 2025, accessed 4 Oct 2026: https://www.theregister.com/2025/09/11/gartner_vmware_migration_advice/
- SUSE, SAP HANA virtualization scenarios, accessed 4 Oct 2026: https://documentation.suse.com/sles-sap/sap-virtualization/html/SAP-virtualization-supported-scenarios/index.html
- Red Hat, SAP on OpenShift Virtualization, accessed 4 Oct 2026: https://access.redhat.com/articles/7048369
- SAP News, SAP ERP, private edition, transition option, accessed 4 Oct 2026: https://news.sap.com/?p=233946
- The Register, SAP Joule for on-premise ECC and S/4HANA, 13 May 2026, accessed 4 Oct 2026: https://www.theregister.com/ai-ml/2026/05/13/sap-u-turn-brings-ai-features-to-ecc-and-on-prem-s/4hana/5239040
- Qlik, SAP data access restrictions, 27 May 2026, accessed 4 Oct 2026: https://community.qlik.com/t5/Support-Updates/Important-update-on-SAP-Data-Access-Restrictions-and-your-Qlik/ba-p/2549652
- DSAG, Investment Report 2026, 26 Feb 2026, accessed 4 Oct 2026: https://impulsant.dsag.de/formate/pressemeldung/dsag-investment-report-2026-companies-are-investing-more-selectively-ai-is-becoming-established-cloud-computing-is-being-put-to-the-test/
- UiPath, release notes - agents in Unified Pricing, May 2025, accessed 4 Oct 2026: https://docs.uipath.com/agents/automation-cloud/latest/release-notes/may-2025
- UiPath, partnerships announced at FUSION, 1 Oct 2025, accessed 4 Oct 2026: https://www.uipath.com/de/newsroom/nvidia-microsoft-google-openai-snowflake-uipath-schliesst-strategische-partnerschaften-zur-integration-agentischer-automatisierung
- n8n, Sustainable Use License, accessed 4 Oct 2026: https://github.com/n8n-io/n8n/blob/master/LICENSE.md
- IBM, completion of the HashiCorp acquisition, 27 Feb 2025, accessed 4 Oct 2026: https://newsroom.ibm.com/2025-02-27-ibm-completes-acquisition-of-hashicorp,-creates-comprehensive,-end-to-end-hybrid-cloud-platform
- InfoQ, Redis 8 and the AGPL licence, May 2025, accessed 4 Oct 2026: https://www.infoq.com/news/2025/05/redis-agpl-license
- MinIO, GitHub repository, accessed 4 Oct 2026: https://github.com/minio/minio
- AWS, free data transfer out when moving off AWS, 5 Mar 2024, updated 30 Sep 2025, accessed 4 Oct 2026: https://aws.amazon.com/blogs/aws/free-data-transfer-out-to-internet-when-moving-out-of-aws/
- Gartner, public cloud spending forecast, accessed 4 Oct 2026: https://www.gartner.com/en/documents/6996966
- DHH (37signals), cloud exit savings, Oct 2024, accessed 4 Oct 2026: https://world.hey.com/dhh/our-cloud-exit-savings-will-now-top-ten-million-over-five-years-c7d9b5bd
- SDxCentral, Microsoft before the French Senate, Jun 2025, accessed 4 Oct 2026: https://www.sdxcentral.com/news/microsoft-tells-french-lawmakers-it-cant-protect-user-data-from-us-demands/
- Amazon, launch of the AWS European Sovereign Cloud, Jan 2026, accessed 4 Oct 2026: https://press.aboutamazon.com/aws/2026/1/aws-launches-aws-european-sovereign-cloud-and-announces-expansion-across-europe
- State of Schleswig-Holstein, email migration completed, 6 Oct 2025, accessed 4 Oct 2026: https://www.schleswig-holstein.de/DE/landesregierung/ministerien-behoerden/I/_startseite/Artikel2025/IV/251006_ox-umstellung-abschluss
- Menlo Ventures, Mid-Year LLM Market Update, 31 Jul 2025, accessed 4 Oct 2026: https://menlovc.com/perspective/2025-mid-year-llm-market-update/
- Anthropic, donating MCP to the Agentic AI Foundation, 9 Dec 2025, accessed 4 Oct 2026: https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
- EBA, designation of critical ICT third-party providers under DORA, 18 Nov 2025, accessed 4 Oct 2026: https://www.eba.europa.eu/publications-and-media/press-releases/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital
- Polish Ministry of Digital Affairs, amendment to the National Cybersecurity System Act, accessed 4 Oct 2026: https://www.gov.pl/web/cyfryzacja/sejm-uchwalil-nowelizacje-ustawy-o-krajowym-systemie-cyberbezpieczenstwa
- EU Data Act, Article 29 (Regulation (EU) 2023/2854), accessed 4 Oct 2026: https://eur-lex.europa.eu/eli/reg/2023/2854/oj
---
### UiPath Studio comes to the Mac in Public Preview - our first bot built on macOS
URL: https://snok.ai/en/news/blog/uipath-studio-macos-public-preview/ | Date: 2026-10-03 | Series: Other
You can now build UiPath automations on a Mac without a Windows machine anywhere in the loop. On 1 October 2026 UiPath released Studio for macOS as a Public Preview. On Apple silicon Macs running macOS 14 Sonoma or later, developers can design, run and debug cross-platform automations and publish them to UiPath Orchestrator. We installed the new build and used it to create a small bot that fetches the euro exchange rate from the public API of Narodowy Bank Polski, the Polish central bank. The whole run takes forty seconds and is shown in the video below.
UiPath Studio 2026.0.202 STS on macOS - a six-step bot that reads the EUR rate from the NBP API, recorded by SNOK. The project description in the dialog was typed in Polish.
## What did UiPath release on 1 October 2026?
The release has two parts. One is Studio itself, listed in the release notes as a Public Preview. The other is the UiPath Platform Installer for macOS, also a Public Preview, which installs Studio together with UiPath Assistant and keeps both up to date. Studio relies on Assistant to sign in and to run automations. The installer package is available from the Resource Center in UiPath Automation Cloud.
IT teams will care about one more detail. Administrators set governance policies through a configuration profile pushed by their MDM solution, so a Mac running Studio joins the managed fleet the same way as any other corporate application.
The requirements are short: a Mac with an M1 chip or later, macOS 14 Sonoma or later and at least 8 GB of free disk space. Intel-based Macs are not supported. Shortcuts follow macOS conventions, with ⌘R to debug, ⌃⌘R to run and ⇧⌘P for the command palette.
## Why a Mac version of Studio matters to enterprises
Macs left the design studio a long time ago. Developers, analysts and executives use them, and so do whole teams at companies that let employees pick their own laptop. A Censuswide survey commissioned by MacStadium in September 2025 points the same way: of 300 US CIOs, 93 percent reported growing use of Apple devices over the previous two years and 96 percent expected their Mac fleet to grow within 12 to 24 months. The sponsor sells Mac infrastructure and the sample covers the US only, so we read it as a direction of travel rather than a market measurement.
Automation tooling lagged behind that shift. A UiPath developer with a Mac could work in Studio Web in the browser or run Studio Desktop in a Windows virtual machine. The first option was not a full development environment. The second meant another operating system licence, more memory and one more machine to maintain.
UiPath has been closing the gap step by step. Release 2024.10 introduced native macOS UI automation as a preview: attended automations ran on a local robot through macOS Assistant, while developers still built them in Studio on Windows. Release 2025.10 made desktop app automation on macOS generally available, designed in Studio Web. Full Studio on the Mac was the missing piece, and it has now arrived. UiPath is catching up with a market where the Mac has become an ordinary work computer.
## How we built the first bot on a Mac
The recording shows Studio 2026.0.202 STS on an Apple silicon MacBook. The project is a standard C# process with cross-platform compatibility, which is the only project type Studio on macOS will open. The bot has a single job: retrieve the current average EUR rate from NBP table A.
Anyone who has built a process in Studio on Windows will recognise every step. We create a process, set its name and language, add the HTTP Request activity from UiPath.WebAPI.Activities and paste the request as a cURL command, which the import feature splits into the URL and query parameters. The Test button sends the request at design time and shows the JSON response with table A and currency code EUR. When the process runs, the Output panel logs the start and the end of the execution.
The example is deliberately simple. It still covers the full developer loop on a single machine: building the project, testing the integration, running and debugging, with no Windows box behind the scenes.
## What works on the Mac and what stays on Windows
**Works on the Mac.** Designing, running and debugging cross-platform projects, publishing to UiPath Orchestrator, and UI Automation. The first time you indicate a UI element, macOS asks you to grant permissions to UiPath UIAutomation under Privacy & Security. UI Automation requires UiPath.UIAutomation.Activities 26.10 or later, and browser extensions are offered for Chrome, Edge and Safari.
**Stays on Windows.** Windows and Windows - Legacy projects cannot be opened on a Mac. The Public Preview has no Excel Add-in, no SAP Solution Manager plugin and no Repair Tool for Microsoft Office. Git is the only supported source control, so TFS and SVN are out. Automatic generation of test data variations is not available, and screen reader support is limited.
That splits the work in a predictable way. New cross-platform automations, API integrations and browser automations can be built on a Mac today. Processes that depend on SAP GUI, desktop Excel or older Windows projects remain on Windows workstations or on unattended robots running in virtual machines.
## Who should try the Public Preview now?
UiPath states plainly that Public Preview features are not recommended for production use, and it has not announced a date for general availability. A sensible plan for the coming months is a pilot with a development team that already works on Macs, limited to new cross-platform projects, with packages published to Orchestrator and production runs kept on the existing robots. In parallel, it is worth auditing the automation portfolio to see which processes are already cross-platform and which still need migrating from Windows - Legacy, since those numbers decide how much work can realistically move to Macs.
Studio on the Mac fits a pattern we have followed for a while. [UiPath Delegate](/en/news/blog/uipath-delegate-public-preview/) already runs on both Windows and macOS, and UiPath has [opened its platform to coding agents such as Claude Code and Codex](/en/news/blog/uipath-claude-code-codex-enterprise/). UiPath's developer tooling no longer assumes a single operating system. If you are curious how a Mac copes as a machine for local AI experiments, see our post on [512 GB under the desk](/en/news/blog/mac-studio-512gb-vs-dgx-spark-poc-machine/).
SNOK is a UiPath Platinum partner and we work on the latest releases of the platform. If you are planning a Studio pilot on Macs, or want to find out which of your processes are ready for cross-platform projects, have a look at our [business process automation](/en/offer/ai-automation/business-process-automation/) offering or our [UiPath practice](/en/uipath-snok/) page and get in touch.
## Sources
- UiPath, Studio Release Notes, October 2026, entry of 1 Oct 2026 "Studio on macOS (Preview)" - https://docs.uipath.com/studio/standalone/latest/release-notes/october-2026 (accessed 3 Oct 2026).
- UiPath, Studio User Guide, "Studio on macOS (Preview)": requirements, project types, shortcuts and known limitations - https://docs.uipath.com/studio/standalone/latest/user-guide/studio-on-macos (accessed 3 Oct 2026).
- UiPath, Platform Installer Release Notes, October 2026, "macOS support (Preview)" - https://docs.uipath.com/uipath-platform-installer/standalone/latest/release-notes/october-2026 (accessed 3 Oct 2026).
- UiPath, Studio User Guide, "About macOS UI Automation": preview from 2024.10 and general availability of macOS desktop automation from 2025.10 - https://docs.uipath.com/studio/standalone/latest/user-guide/about-macos-ui-automation (accessed 3 Oct 2026).
- Computerworld, "MacStadium sees Apple adoption accelerating across US enterprises", 25 Sep 2025, Censuswide survey of 300 US CIOs for MacStadium - https://www.computerworld.com/article/4063294/macstadium-sees-apple-adoption-accelerating-across-us-enterprises.html (accessed 3 Oct 2026).
- NBP, exchange rate API, table A, EUR - https://api.nbp.pl/api/exchangerates/rates/a/eur/?format=json (accessed 3 Oct 2026).
- SNOK recording, UiPath Studio 2026.0.202 STS on macOS, project NBP_Kurs_EUR, 3 Oct 2026.
---
### Weekly review W40: enforcing AI agent permissions outside the prompt
URL: https://snok.ai/en/news/blog/weekly-review-w40-permissions-not-prompts/ | Date: 2026-10-02 | Series: Other
**SNOK's review of 25 September - 1 October 2026: SAP, AI agent security, UiPath and decision models.**
This week's releases share a design choice: the limits on an AI agent are enforced somewhere other
than the prompt. SAP and NVIDIA split business authorisation from execution containment, AG-UI 1.0
lets an agent pause for human approval and resume from the same point, and Google AX gives every
agent task its own sandbox.
A prompt can tell an agent what to do. Enforcement has to sit in permissions, process, runtime and
protocol, none of which care what the model has just read. SAP ERP 6.0 offers a parallel from the
contract side: how long a system stays supported is governed by eligibility terms and technical
prerequisites, not by the year quoted in the headlines.
## 1. SAP ERP 6.0: support timelines and eligibility
Mainstream maintenance for SAP Business Suite 7, SAP ERP 6.0 included, ends with 2027 and covers the
three most recent enhancement packages. SAP prices extended maintenance for 2028-2030 openly: two
percentage points on top of the maintenance base. Systems left outside it fall back to
customer-specific maintenance.
For 2031-2033 the only route is a subscription, "SAP ERP, private edition, transition option", and it
covers SAP ERP alone rather than the whole of SAP Business Suite 7. It requires a move to SAP HANA in
private edition before 31 December 2030, a system of at least 2 TB and the max success plan. According
to SAP's August 2025 announcement, contracts signed in 2026 carry a 20 percent uplift, and pricing for
contracts from 2027 will be published with the offer in 2028.
The backdrop is the European Commission decision of 9 July 2026, which made SAP's commitments legally
binding for ten years, worldwide. They include clearer terms for splitting a system landscape between
different support providers or leaving parts unsupported, the removal of reinstatement fees and lower
back-maintenance fees. We summarise the announcement here; what it means for a given contract is
a question for a lawyer.
So 2033 is available to some ERP systems, on stricter terms and at a higher price. Every SAP Business Suite 7 system
now needs a costed comparison of three options: conversion to SAP S/4HANA before mainstream maintenance
ends, extended maintenance to 2030, or - for SAP ERP - the transition option to 2033. Each needs a named
decision-maker, and a contract signed this year carries the 20 percent uplift.
*Sources: SAP Support Portal, "Maintenance strategy for SAP Business Suite 7"; SAP News Center,
Stefan Steinle, "Navigating Your RISE with SAP Journey: Updates for SAP ERP, Private Edition,
Transition Option", 4 August 2025; European Commission, press release IP/26/1554, 9 July 2026.
Status: confirmed - read on 1 October 2026. Detailed SAP Notes require a login and are not quoted.*
## 2. SAP Joule Studio and NVIDIA OpenShell: authorise, then contain
On 28 September NVIDIA announced the Open Agent Safety Platform. Its foundation is OpenShell, an
Apache 2.0 runtime that sets operating boundaries for agents running on CPUs, whatever model or harness
sits behind them; NVIDIA describes it as broadly available. The second component, Sentry, an
out-of-band watchdog on BlueField-4 DPUs, exists for now as a reference design.
SAP is working to embed OpenShell in SAP Joule Studio runtime, part of SAP Business AI Platform. The
division of labour is clean: the SAP runtime applies business authorisation, role-based policy and
process context before a request reaches execution, and OpenShell governs the execution itself. SAP
engineers contribute to OpenShell - separating the supervisor from agent execution, Kubernetes support
and observability. The title of SAP's own post says "working toward", and FedRAMP and FIPS sit on the
roadmap. NVIDIA's list of infrastructure partners includes Lenovo and SUSE, among others.
The result is two independent checkpoints: one admits the action, the other constrains how it runs.
Neither depends on what the model happens to read in its input, which is precisely what separates
them from limits written into a system prompt.
*Sources: NVIDIA Newsroom, "NVIDIA Launches Open Agent Safety Platform to Secure Agents From
Testing to Deployment", 28 September 2026; SAP News Center, Andre Lamego, "SAP and NVIDIA OpenShell
Working Toward Governance and Security for Auditable AI Agents in Enterprise Systems",
28 September 2026; the NVIDIA/OpenShell repository on GitHub. Status: confirmed - read on 1 October
2026. SAP sources give two different end dates for free access to SAP Joule Studio runtime, so we
quote neither.*
## 3. Validating tickets before the agent runs in UiPath Maestro
Panagiotis Drakopoulos, a UiPath practitioner, has described on LinkedIn an IT ticketing process built
in UiPath Maestro BPMN. Every 15 minutes it reads a mailbox and stores each new message - sender,
subject and body - as a separate record. It works through the records one at a time and invokes the
agent only once a record has passed validation; his reasoning is cost, since an agent call on
meaningless input is money spent for nothing.
The agent classifies the ticket and sets its priority against the supplier's SLA. The process opens a
case in Jira Service Management, notifies the customer and the supplier, and loops until the queue is
empty. One note of our own, from the UiPath documentation: the Jira connector in UiPath Integration
Service supports Jira Software Cloud, not Server or Data Center. We have not checked whether it handles
Jira Service Management projects.
The example shows clearly where control sits in such a design. The process decides when the agent
runs and what it receives, and validating first cuts both the bill and the attack surface.
Organisations running Jira on their own infrastructure need a different integration path before any
demo is built.
*Sources: Panagiotis Drakopoulos, "The Evolution of ITSM: Moving from Manual to Agentic
Automation!", LinkedIn, September 2026; UiPath Docs, "About the Jira connector" (Integration
Service). Status: confirmed - one practitioner's design, not a UiPath reference architecture.*
## 4. UiPath Cartographer and process modelling: a model, not a diagram
Andrzej Sobczak has written on LinkedIn about moving from generating BPMN diagrams out of interview
transcripts to building a process model from them. He draws the line precisely: a diagram is a visual
depiction of a flow, while a model carries a process hierarchy, a glossary, roles, data, rules, metrics
and assumptions, together with an explicit list of unknowns - what the interview could not establish.
His toolset records these elements, imports them into Sparx EA 17.1 and links them.
UiPath Cartographer, generally available since UiPath FUSION 2026 on 23 September, does comparable
work inside the UiPath stack. From documents, procedures, recordings and interviews it builds a sourced,
versioned map of how the process runs today, reconciles conflicting accounts and asks follow-up
questions about the gaps. It then designs the target state, assigning each step a mode of work: fully
automated, assisted, agent, human review or manual. Finally it generates a PDD as a Word document and
an SDD in Markdown for development teams and coding agents. UiPath stresses that the PDD and SDD are
outputs of the map, not the source of truth. Cartographer runs on UiPath Delegate; pricing has not been
published.
Both approaches move the output of discovery from a picture to a model with its unknowns made explicit.
An explicit list of unknowns tells the team what it still has to find out before designing the
process, and an agent asked to build that process needs exactly this: hierarchy, rules and a record
of what is not yet known.
*Sources: Andrzej Sobczak, LinkedIn post, September 2026; UiPath Newsroom, "UiPath Launches UiPath
Cartographer Map of Work", 23 September 2026; UiPath Cartographer product page; UiPath Docs,
"Cartographer overview". Status: confirmed - read on 1 October 2026. Pairing the two approaches is
our reading - the author does not mention UiPath.*
## 5. A read-only compromise assessment for Microsoft 365
M365 Investigation Toolkit is an MIT-licensed set of PowerShell 7.5+ scripts for a first-pass
compromise assessment of Microsoft 365 and Entra ID. According to its documentation it performs read
operations only. It signs in with a delegated admin account, interactively or with a device code, with
no app registration and no tokens written to disk.
It collects evidence from mailbox forwarding and rules, transport rules, interactive and
non-interactive sign-ins, service principal sign-ins, OAuth consents and privileged role assignments.
Version 1.0.0 ships 18 evidence collectors and 10 detections, among them OAuth consent abuse, BEC
indicators, password spraying, dormant account takeover and service principal backdoors. The report
states a confidence level and flags gaps in what it could collect, and the author is clear that the
verdict proves neither compromise nor its absence.
A read-only toolkit can speed up initial triage, yet it still needs broad access. The required
permissions include `Mail.Read`, which exposes message content, so using it for a client requires
written contractual authorisation and a GDPR assessment. The project has a single release from
March 2026, which should weigh on any decision to build it into an incident response procedure.
*Source: the `securigeek/M365-Investigation-Toolkit` repository on GitHub, README, release notes and
licence file, read on 1 October 2026. Status: confirmed as to the documentation; we have not run
the tool.*
## 6. Agent security as a business analyst's requirement
In part four of her #BA4AI series on business analysis for AI, Dorota Roszkowska turns prompt
injection risk into requirements an analyst can write into a specification. Her premise: an agent
allowed to cancel an order can also cancel it on an attacker's instruction, given directly or hidden
in an email, document or web page the agent reads. She frames it as four questions.
Who checks a tool call before it runs? The model only proposes; business logic verifies permissions
and parameters, such as a refund limit. Whose permissions does the agent use? Those of the user it acts
for, with no broad technical accounts. Which actions are irreversible? Cancellations, payments and data
deletion need human confirmation, and the confirmation window shows parameters read from the system,
not a description generated by the model. How are input and output filtered? By a separate
classification layer before and after the agent, and by separators that keep instructions apart from
data.
OWASP lists prompt injection among the top risks for applications built on large language models
(LLM01:2025) and says it is unclear whether any fool-proof defence exists. Her requirements therefore
limit the damage rather than the attempt, which is why the first question belongs in every agent
specification.
*Sources: Dorota Roszkowska, "#BA4AI 4/5 Agenci AI: 4 pytania bezpieczeństwa" (in Polish), LinkedIn,
28 September 2026; OWASP, "LLM01:2025 Prompt Injection". Status: confirmed - read on 1 October 2026.
The questions are our translation.*
## 7. Autonomous application pentesting within enforced scope
Pentest Swarm AI is an AGPL-3.0 tool for autonomous penetration testing of APIs and web applications,
which its authors position as an open alternative to XBOW. It chains reconnaissance into attack
sequences - BOLA and IDOR, JWT forgery, mass assignment, SSRF and injection - and backs findings with
collected evidence. It runs on Claude, any OpenAI-compatible API or Gemini, or entirely locally through
Ollama or LM Studio.
Two design decisions matter more than the swarm itself. Scope is enforced in the tool layer and again by
the executor, and a clean-up registry runs on interruption, failure or budget exhaustion. The authors are
explicit about maturity: the default five-phase sequential runner is stable, the agent swarm is alpha and
the exploit chains are beta. The README requires the system owner's written permission before any scan.
Attackers have the same tooling, and reconnaissance of applications and APIs will speed up accordingly.
In any tool admitted to your own testing, scope and clean-up must be enforced outside the model. The
AGPL-3.0 licence also carries obligations if a modified version is offered as a service - a question
for a lawyer.
*Source: the `Armur-Ai/Pentest-Swarm-AI` repository on GitHub, README, licence file and releases
(v0.2.31 of 29 September 2026), read on 1 October 2026. Status: confirmed as to the documentation;
effectiveness is the authors' claim, and we have not tested the tool.*
## 8. Aikido Altar-1: code security analysis on your own infrastructure
On 21 September Aikido Security released Altar-1, open weights for code security analysis and
pentesting; run on the company's own infrastructure, it keeps source code in-house. It is neither trained from scratch nor fine-tuned for
security; it is a pruned GLM-5.3. Expert pruning (REAP) kept 168 of the 256 experts per layer, and their
weights were quantised to INT4. The result takes 328 GB, has 504 billion parameters and is served in
vLLM on four H200 cards.
Aikido reports results on its own test set: 32 known vulnerabilities across 30 repositories, three runs
per case. Altar-1 reaches a mean recall of 60.4 percent, against 65.6 percent for the full GLM-5.3. The
GLM-5.3 licence allows commercial use, modification and redistribution on its own terms, with separate
requirements for the largest model-as-a-service operators, but it is not an OSI-approved open-source
licence.
Keeping code in-house therefore costs a few points of recall and four Hopper-class cards. That
trade-off belongs in the infrastructure budget, and the licence should be read before the first test.
This is not legal advice.
*Sources: Aikido Security, "Aikido Altar" blog post, 21 September 2026; the `AikidoSec/altar-1`
model card on Hugging Face; the GLM-5.3 licence. Status: confirmed - read on 1 October 2026. The
test-set result is the vendor's measurement.*
## 9. AG-UI 1.0: pausing an agent for human approval
On 30 September CopilotKit announced AG-UI 1.0, the stable version of the Agent-User Interaction
Protocol, which defines the event stream between an agent backend and a user interface. Every event has
a JSON Schema from which the TypeScript, Python and .NET SDKs are generated. The 1.0.0 packages have
been available since 17 September, and the release is backwards compatible.
The change that matters most lets an agent pause for human approval and resume from exactly the
same point. Subagents become first-class stream objects, so it is clear which agent is doing which part of
the work; input and tool results go multimodal; and token usage is reported in the final event. The
README lists supported integrations including LangGraph, CrewAI, Microsoft Agent Framework, Google ADK
and Mastra. CopilotKit's framing of the stack: MCP connects agents to tools, A2A connects them to each
other, and AG-UI connects them to the application.
The moment of human decision thus becomes a standard event the application can record. The control
logic and the audit trail are still the application's job; the protocol standardises only how the
decision is signalled. CopilotKit's statement that Google, Microsoft, Amazon
and Oracle have adopted the protocol is a claim; the integrations themselves are confirmed.
*Sources: CopilotKit, "Introducing AG-UI 1.0: a stable spec for connecting any agent to any
application", 30 September 2026; the AG-UI 1.0 spec changelog; the `ag-ui-protocol/ag-ui`
repository on GitHub (MIT licence). Status: confirmed - read on 1 October 2026.*
## 10. Open decision models, including one for Polish
Within two weeks of Jev's launch on 15 September, five open models appeared that honour the same
contract: they choose among given answers and return a probability for each in a single pass, without
generating text. basal-1.0 by Remek Kinas, under Apache 2.0, is fine-tuned on the Polish Bielik v3.0
model in 4.5-billion and 1.5-billion parameter versions and is built for Polish. Its server exposes the
same interface as Jev, so an application only changes the service address.
Intern-Decision from InternLM accepts images, and Qwen licence terms apply to its weights. CLM-8B adds
small heads to a frozen Qwen3-8B. GLiNER2.5-Decide from Fastino and Julia 1 from Supersonic Labs are
small models that run on an ordinary CPU. Liquid AI d1 offers the same contract, but only as a hosted
service, without open weights.
Structured decisions are becoming a layer you can run locally, Polish data included. The Polish and
English results, however, diverge. The author of basal-1.0 reports 0.884 on Polish decisions
against 0.780 for Jev, but 0.740 against 0.861 for Jev on a public English benchmark. The authors of
Julia 1 report 64 percent on Banking77 against 87 percent for Jev. All of these figures come from the
authors; we have not verified them independently.
*Sources: the `rkinas/basal` repository and the `Remek/basal-1.0-4.5B` and `-1.5B` cards on Hugging
Face; the `InternLM/Intern-Decision` repository; the `Contrastive-LM/CLM` repository and
`CLM-v0.1-8B` card; the `fastino/GLiNER2.5-Decide` and `SupersonicLabs/Julia-1` cards; Liquid AI
documentation. Status: confirmed as to existence, licences and sizes - read on 1 October 2026;
results not verified.*
## 11. Google AX: a sandbox for every agent task
Google has published AX on GitHub, an Apache 2.0 declarative orchestrator for agent workloads that runs
on the Agent Substrate layer. A `Task` runs untrusted agent code in its own sandbox with CPU and memory
limits, while a `Workspace` supplies repositories, MCP servers and skills so the agent starts with its
context in place. A task can be suspended and resumed exactly where it stopped, and the command syntax
will feel familiar to anyone who uses `kubectl`.
The authors open the documentation with a warning: AX is in heavy development and will introduce
breaking changes before a stable release. The API is `v1alpha1`, and the latest release is v0.3.1 of
25 September. "Billions of tasks per cluster" is the authors' ambition, not a measurement.
Agents are a new kind of workload. They accumulate state, call external services and can exhaust a
budget in a loop before anyone notices. Isolation and limits have to come from the platform; a prompt
cannot impose them. We treat AX as a reference point in discussions about agent runtime environments
and would not put it into production yet.
*Source: the `google/ax` repository on GitHub, README and releases, read on 1 October 2026. Status:
confirmed; an experimental project, not a Google Cloud service.*
## 12. Apple and AI servers: a press report
The Information, cited by Bloomberg on 16 September, reports that Apple is developing an enterprise
server on its own silicon, aimed at AI developers, government and business. Two configurations are
planned, with two and with four future M8 Ultra chips, and Apple has reportedly discussed linking the
chips with NVIDIA's NVLink Fusion.
The server would reach the market in 2029 at the earliest, and the project could be cancelled or go
ahead without NVIDIA's technology. The backdrop is unexpectedly strong demand for the Mac mini and Mac
Studio among AI developers. Apple did not comment, and no pricing was given.
The report suggests Apple is weighing a server built for running models locally. With no product
and no price, it changes no purchasing decision for 2026-2027.
*Source: Bloomberg, "Apple Is Developing Enterprise Server for AI Age, Report Says", 16 September
2026, based on The Information. Status: recorded - a press report based on anonymous sources; The
Information article is paywalled and we did not open it.*
## 13. The book "SAP Cybersecurity from A to Z"
On 29 September SNOK Press published "SAP Cybersecurity from A to Z: A Guide for CIOs, CISOs and SAP
Teams", alongside the Polish original. It is written for CIOs, CISOs, SAP project managers, SAP Basis
administrators and SOC teams, and runs to 304 pages, 24 chapters in five parts and appendices A-D. The
authors are Jacek Bugajski, the SNOK RedTeam and large language models.
The book covers attack paths into SAP systems, authorisations, AI agents as both threat and defence,
a red team lab, detection and response, and NIS2. Each chapter carries a "For decision-makers" box,
alongside "Control in practice", "What to watch for" and "Question for the CIO" boxes.
The decision-maker boxes give executives a way into every chapter without stripping the technical
detail out.
Both language editions can be downloaded at snok.ai [with a business email address](/en/resources/sap-cybersecurity-a-to-z/).
*Source: SNOK Press, edition of 29 September 2026; the resource page and launch post on snok.ai.
Status: confirmed - read on 1 October 2026.*
## Reviewing agent controls before rollout
Our pre-production review of an agent starts with the limits that exist only as a sentence in the
prompt. Such a limit carries no guarantee of enforcement: crafted content can lead the model to
break it. Limits written into permissions, process, runtime and protocol hold
regardless of what the model reads.
At SNOK we carry out [security assessments of AI agents](/en/offer/ai-automation/ai-security/),
[UiPath Maestro deployments](/en/offer/ai-automation/uipath-maestro/), [deployments of language models on the client's own infrastructure](/en/offer/ai-automation/llm-on-premise/)
and [conversions to SAP S/4HANA with security controls built in](/en/offer/sap-security/s4hana-conversion/).
We would be glad to [discuss your case](/en/contact/).
---
### Tech Thursday with SNOK: SAP in energy utilities, Snowflake and UiPath agents - building governed data for AI
URL: https://snok.ai/en/news/blog/sap-utilities-snowflake-uipath-agents-snok-mdm/ | Date: 2026-10-01 | Series: Tech Thursday
An energy utility rarely runs on one system. SAP ERP handles finance, controlling, plant maintenance and logistics. Customer billing runs on SAP IS-U or another billing platform. Around them sit a meter data management system, GIS, SCADA, CRM, a customer portal and the interfaces for market data exchange. Each of these systems may hold a separate record of the same customer, metering point and supplier.
On top of that landscape comes the pressure to use AI. Boards ask for customer service assistants, automatic bill explanations and agents that take over exception handling. In our view the first question is a different one: where will the agent get its data, whom will it show that data to, and who is accountable for its decision. This post describes an architecture that answers it: SAP on-premise as the source, Snowflake as a governed data and knowledge platform, SNOK MDM as the master data layer and UiPath as the harness that controls how agents work.
*Data flows from SAP and billing into Snowflake, SNOK MDM keeps master data in order, and an agent in UiPath Maestro changes data in SAP only after an employee approves.*
## Why now - CSIRE, smart meters and SAP deadlines
Three developments overlap in Poland right now.
**The Central Energy Market Information System.** CSIRE, the Polish central data hub for the electricity market, has been live since 1 July 2025, and market participants join it in stages. The final onboarding date in the market information operator's schedule is 19 October 2026. For participants connected to CSIRE, supplier switching, metering data and billing data go through standardised exchange with a single central system. Any inconsistency in metering point data leaves the organisation faster than before.
**Smart meters.** According to the Polish Energy Regulatory Office (URE), at the end of 2024 remote-reading meters were installed at 38.26 per cent of more than 19 million metering points. Polish energy law requires at least 80 per cent by the end of 2028. The volume of metering data grows, and so does the number of exceptions to handle before billing.
**SAP deadlines.** Mainstream maintenance for the core applications of SAP Business Suite 7 ends at the end of 2027, with optional extended maintenance available until 2030. The date for a specific industry solution, including SAP IS-U, is worth confirming with SAP. The decision to move to SAP S/4HANA Utilities or to keep the current billing platform is therefore made in the same window in which the first AI projects start.
The conclusion for the architecture: the data layer for AI should work regardless of which billing system remains in the landscape three years from now.
## Two meanings of MDM in energy
In the energy sector, MDM usually stands for meter data management. In this post we mean master data management: who the customer is, which supplier record is the right one, and what a material is called in the warehouse and in the procurement catalogue.
The distinction matters in practice. A meter data management system tells you how much energy flowed through a meter. It does not tell you whether the customer in billing, in CRM and in SAP is the same person or company. A master data layer closes that gap. Without it, every AI agent works with three versions of the same customer.
## Getting data from SAP on-premise into Snowflake
This is the most underestimated part of the project. Choosing how to extract data from SAP is a licensing decision, not only a technical one.
**SAP Business Data Cloud and zero-copy integration.** SAP and Snowflake announced their partnership on 4 November 2025. Since 4 May 2026 Snowflake has offered general availability of its integration with SAP Business Data Cloud: SAP data products are visible in Snowflake without copying, together with their semantic definitions, and Snowflake data can be published back to SAP Business Data Cloud. The offering comes in two variants: SAP Snowflake, sold and supported by SAP, and SAP BDC Connect for Snowflake for existing Snowflake accounts. One important caveat: this covers data available as data products in SAP Business Data Cloud. Data from SAP ECC or SAP IS-U running on-premise has to be brought there first.
**SAP Datasphere replication flows do not support Snowflake as a target.** In the SAP Datasphere documentation for replication flows, Snowflake appears only as a source. An architecture that assumes replication from SAP Datasphere to Snowflake with this mechanism needs a different approach.
**SAP Note 3255746.** In this note SAP clarified that the ODP-RFC interface is intended for data exchange between SAP applications. Vendors of integration tools describe this as a prohibition on using the interface in third-party solutions. The clarification does not cover other methods, such as database-level change data capture, OData or RFC calls outside ODP-RFC, but whether they are permitted depends on your licence agreement with SAP. Before you choose an extraction tool, check which method it uses and confirm it under your agreement.
In practice, we recommend a short review of extraction paths before the first line of code: which data can go through SAP Business Data Cloud, which through change data capture, and which is fine with a daily refresh. The review combines SAP Basis, SAP security and data engineering skills, so we run it as a single project step.
*Choosing an SAP extraction path is a licensing decision before it becomes a technical one.*
## Snowflake as a governed data and knowledge base for AI
In this architecture Snowflake plays two roles: data warehouse and knowledge base for language models. Both need order before the first agent appears.
**Numbers through a semantic layer, documents through search.** Vector search, which RAG relies on, works well for documents: tariffs, grid code, terms of service, complaint procedures or contracts. It does not work well for questions about balances, consumption and receivables, because those questions need aggregations and table joins, not text similarity. So we separate the two. Cortex Search, Snowflake's hybrid vector and keyword search, indexes the documents. Numeric data is exposed through semantic views: metrics such as overdue receivables or consumption in a billing period are defined once and calculated deterministically. Cortex Agents combine both sources in a single answer.
**Permissions enforced in one place.** Snowflake Horizon provides classification of personal and confidential data, tags, dynamic masking, row access policies and lineage. Masking and row access policies require Enterprise Edition or higher. The principle we design for: an agent sees exactly what the user it acts for would see. Permissions are enforced by the data platform, not by the prompt. This requires a connection in the user's context, which has to be designed and tested for the chosen authentication method, because connectors also allow application credentials.
**Region and model inference.** Snowflake has no region in Poland. The nearest regions include AWS in Frankfurt and Stockholm and Azure in the Netherlands and Sweden. Leading models in Cortex require cross-region inference, and for organisations created on or after 9 March 2026 the default setting allows requests to be routed to any region. For an energy utility, we recommend deliberately restricting inference to regions in the European Union and recording that decision in the security documentation.
**Protection against prompt injection.** Since May 2026 Cortex AI Guardrails, once enabled by an administrator, protect Cortex agents against prompt injection, including indirect injection hidden in tool results. This matters because customer correspondence and external documents are a natural carrier for such an attack.
We describe how we design data platforms on the [SNOK and Snowflake](/en/snowflake-snok/) page and in our [Modern Data Stack](/en/offer/custom-development/modern-data-stack/) offering.
## SNOK MDM - one version of the customer, supplier and material before the agent
Snowflake is a data platform, not a master data management system. It does not decide which of three records for the same customer is the right one, and it does not run the process in which a data owner approves a merge. On Snowflake, a golden record requires additional products or a custom build.
SNOK MDM, our own master data management solution, provides that layer. It works on top of source systems, without replacing ERP or billing:
- **Matching and deduplication** recognise the same entity across many records, for example a customer recorded differently in billing, in CRM and in SAP.
- **A language model proposes merges**, and a data steward approves the decision. Every decision goes into the audit trail.
- **Six domains on one platform**: customers, suppliers, materials, products, financial accounts and employees, and in the industry edition for power, gas and oil utilities also metering points and their links to customers.
- **Connectors for SAP S/4HANA and SAP ECC**, with deployment on-premise, in the client's environment or as a service.
In the energy sector three domains deliver the most. The customer domain, together with metering points from the industry edition, brings order to customer service once CSIRE is fully live. The supplier domain can support supply chain risk assessment where a company is subject to such obligations under the Polish act implementing NIS2. The materials domain connects spare parts in SAP plant maintenance with the procurement catalogue. We publish the SNOK MDM golden record to Snowflake as a data product, so agents and reports use the same approved version.
We discussed when to choose SAP Master Data Governance and when SNOK MDM in [SAP MDG, Reltio or SNOK MDM](/en/news/blog/sap-mdg-vs-reltio-snok-mdm/). Product details are on the [SNOK MDM](/en/products/snok-mdm/) page.
## UiPath as the harness for agent work
An agent that picks its own tools, makes its own decisions and executes its own transaction in SAP is a risk nobody in a regulated utility will sign off. What you need is a harness: a layer that defines the agent's process, tools, permissions and the points where an authorised employee approves the decision. In this architecture UiPath plays that role.
**UiPath Maestro orchestrates the process.** UiPath and Snowflake announced their partnership on 30 September 2025. The Snowflake Cortex connector in UiPath Integration Service lets a UiPath Maestro process call a Cortex agent that answers from semantic views and Cortex Search, then pass the result on: to a robot that executes the transaction in SAP, or to a person in Action Center. The alternative is the Snowflake-managed MCP server, registered in UiPath Orchestrator as a remote tool source for conversational agents.
**UiPath AI Trust Layer enforces the rules.** Once policies are configured, it masks personal data before it is sent to the model and restores it after the response, enforces agent policies before deployment and records model calls in an audit log. For a utility that processes data about millions of customers, this is a precondition for production.
**A person approves where the decision has consequences.** A billing correction, a change to metering point data or a reply to a complaint goes through an approval point in Action Center. The agent prepares the justification, and an authorised employee approves it. We described the pattern in more detail in our post on [HITL gates in UiPath Maestro](/en/news/blog/hitl-gates-uipath-maestro-ai-trust-layer/).
Processes worth starting with:
1. **High bill explanation.** The agent brings together consumption, meter readings and the tariff, drafts a reply, and a customer service employee approves it. UiPath publishes this pattern as a reference agentic use case.
2. **Meter reading exceptions before billing.** A missing reading, an estimated reading or an unusual jump in consumption goes to an agent that proposes a correction or a meter check.
3. **Rejected market data exchange messages.** The agent classifies the reason for rejection, checks the metering point data against the golden record and prepares a correction for approval.
We deliver process automation as a [UiPath Platinum Partner](/en/uipath-snok/), and describe agent orchestration in our [UiPath Maestro](/en/offer/ai-automation/uipath-maestro/) offering.
## AI governance - five layers of control
Governance is a set of mechanisms that operate in every layer of the architecture, not a document attached at the end of the project.
1. **Identity.** The agent acts on behalf of a specific user, and that user's identity reaches the data platform. We choose and test the authentication method for exactly this. A technical account with full access is not acceptable.
2. **Data.** Masking, row access policies and classification in Snowflake Horizon, plus the approved golden record in SNOK MDM.
3. **Semantics.** Metrics defined once in semantic views, so the agent does not calculate receivables its own way.
4. **Agent.** Design policies, pre-deployment evaluations and an agent register with permissions in UiPath.
5. **People and the trail.** Approval points for consequential decisions and an audit log covering model calls, data steward decisions and robot transactions.
These layers also support regulatory compliance. The Polish act on the national cybersecurity system implementing NIS2 has applied since 3 April 2026 and covers the energy sector. Obligations for high-risk AI systems under Annex III of the AI Act are set to apply from 2 December 2027, following the changes introduced by the Digital Omnibus package. In the energy sector this mainly concerns AI systems used as safety components in the management and operation of critical infrastructure, including the supply of electricity, not every customer service agent. Classifying a specific use case requires legal analysis, but an architecture with five layers of control makes the documentation easier to prepare. Security of the agents themselves, including testing for prompt injection and data leakage through tools, is covered by our [AI Security](/en/offer/ai-automation/ai-security/) offering.
## Where to start - three steps
**Step 1. Review data and extraction paths.** A map of systems, master data domains and SAP extraction methods, with a licence compliance assessment. Outcome: the list of data that can go to Snowflake and how to get it there.
**Step 2. Pilot one domain and one agent.** For example, a customer golden record in SNOK MDM, billing data in Snowflake and a bill explanation agent in UiPath Maestro, with an approval point for an employee. A first result on your own data instead of a demo on sample data.
**Step 3. Scale.** More domains, more processes and governance moved into ongoing operations.
## Why SNOK
A project like this combines skills that many organisations split across different vendors: SAP Basis and SAP security, data engineering on Snowflake, master data management, and UiPath automation and agents. SNOK is an SAP partner, a Snowflake Partner and a UiPath Platinum Partner, and SNOK MDM is our own solution. One team can run the whole path: from data in SAP, through the golden record and the data platform, to the agent with an approval point.
If you are planning an AI project at an energy utility, let us start with a review of your data and extraction paths. [Talk to us about an architecture for your SAP landscape](/en/offer/master-data-management/).
## Sources
- PSE, Energy Market Information Operator - CSIRE launch and rollout schedule (accessed 30.09.2026): https://www.pse.pl/oire/harmonogram-wdrazania-nmwi-poprzez-csire
- URE - report on dynamic price contracts, remote-reading meter data at end of 2024 (accessed 30.09.2026): https://www.ure.gov.pl/download/9/15476/Raportcenydynamiczne.pdf
- Act of 20 May 2021 amending the Polish Energy Law, art. 11t (accessed 30.09.2026): https://orka.sejm.gov.pl/proc9.nsf/ustawy/808_u.htm
- SAP - maintenance strategy for SAP S/4HANA and SAP Business Suite 7 (accessed 30.09.2026): https://support.sap.com/en/release-upgrade-maintenance/maintenance-information/maintenance-strategy/s4hana-business-suite7.html
- SAP News - SAP and Snowflake, 4.11.2025 (accessed 30.09.2026): https://news.sap.com/2025/11/sap-snowflake-data-enterprise-ai-business-data-fabric/
- Snowflake - SAP BDC Zerocopy Connector, general availability, 4.05.2026 (accessed 30.09.2026): https://docs.snowflake.com/en/release-notes/2026/other/2026-05-04-Snowflake-SAP-zerocopy-integration
- SAP Datasphere - sources and targets for replication flows (accessed 30.09.2026): https://github.com/SAP-docs/sap-datasphere
- SAP - API Policy, Frequently Asked Questions, version 1.3, 06.2026, questions 22-23 (accessed 30.09.2026): https://www.sap.com/docs/download/2026/04/e2a0665e-4c7f-0010-bca6-c68f7e60039b.pdf
- Theobald Software - SAP Note 3255746, 23.04.2026 (accessed 30.09.2026): https://theobald-software.com/en/blog/sap-note-3255746
- Snowflake - regions (accessed 30.09.2026): https://docs.snowflake.com/en/user-guide/intro-regions
- Snowflake - cross-region inference in Cortex (accessed 30.09.2026): https://docs.snowflake.com/en/user-guide/snowflake-cortex/cross-region-inference
- Snowflake - Cortex Search (accessed 30.09.2026): https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-search/cortex-search-overview
- Snowflake - Cortex AI Guardrails, 14.05.2026 (accessed 30.09.2026): https://docs.snowflake.com/en/release-notes/2026/other/2026-05-14-cortex-ai-guardrails-si-cortex-agents
- UiPath - partnership with Snowflake, 30.09.2025 (accessed 30.09.2026): https://www.uipath.com/newsroom/uipath-partners-with-snowflake-to-unite-agentic-automation-and-snowflake-cortex-ai
- UiPath - Snowflake Cortex connector (accessed 30.09.2026): https://docs.uipath.com/integration-service/automation-cloud/latest/user-guide/uipath-snowflake-cortex
- UiPath - PII masking in AI Trust Layer (accessed 30.09.2026): https://docs.uipath.com/automation-cloud/automation-cloud/latest/admin-guide/pii-masking
- UiPath - High Bill Analysis Agent (accessed 30.09.2026): https://www.uipath.com/resources/agentic-use-cases/high-bill-analysis-agent
- Polish act on the national cybersecurity system, Journal of Laws 2026 item 252 (accessed 30.09.2026): https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20260000252
- Regulation (EU) 2026/1744 (Digital Omnibus) (accessed 30.09.2026): https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng
---
### SAP Cybersecurity from A to Z - the book is ready to download
URL: https://snok.ai/en/news/blog/sap-cybersecurity-a-to-z-book/ | Date: 2026-09-29 | Series: Safe Tuesday
I am immensely proud to share **"SAP Cybersecurity from A to Z. A guide for CIOs, CISOs and SAP teams"**, the English edition of my book "Cyberbezpieczeństwo SAP od A do Z". As far as I know, nothing like it has existed in the SAP world in Polish: 304 pages that take you from the foundations, through authorisations, attack paths and AI agents, to NIS2 and ready-made audit templates. **The book is ready to download in English and in Polish.** The form is at the end of this post.
I have worked on SAP security for more than a quarter of a century. My first assignment as a young consultant at SAP Poland was a penetration test. Within a few minutes I had root on the operating system and the `SAP_ALL` profile in SAP. That was mid-2000. Architecture, tools, regulation and board awareness have changed since then, and I still come across similar cases. So I brought this knowledge together in one place and organised it as practical material for everyday work.
## What you will learn
**How an attacker sees SAP.** The anatomy of an attack, attack paths between systems and how to find them before an attacker does, how to read SAP Security Notes and plan security work around SAP Security Patch Day. Attacker techniques are described from the defender's side only - there are no attack instructions in the book.
**Who really has access.** Authentication and single sign-on, roles and authorisations, including the powerful `SAP_ALL` profile, segregation of duties in SAP GRC Access Control, and how to manage accounts throughout their lifecycle after the end of SAP Identity Management maintenance.
**How AI supports SAP security today - and which new threats it brings.** On one side, SAP Joule and AI agents are a new attack surface: an assistant sees and does whatever its user's authorisations allow, and an instruction hidden in an invoice attachment can change its behaviour. I describe classes of prompt injection aimed at SAP data and the safeguards on MCP gateways through which agents reach the system. On the other side, AI genuinely helps defenders, so a separate chapter covers what to deploy now, what to pilot and what to wait for, where the limit of agent automation in the SOC lies, and how to decide between cloud and local processing.
**How to build your own SAP red team lab.** From the first test question to the environment, four tasks for AI models, criteria for choosing hardware and model, authorisation and control of activities, the first exercise cycle and the cost of running the lab. A separate chapter explains how to commission an SAP security test, read the proposal and accept the report.
**How to detect and respond to an incident.** SAP logs that a SIEM often does not see, SOC work with SIEM and SOAR, and an incident response procedure for SAP.
**How to meet NIS2, GDPR, DORA and ISO 27001 requirements**, including Poland's national cybersecurity act (KSC): who is covered and from when, deadlines, who signs and who reports. A single SAP event may require a notification under KSC or, in financial services, DORA, and separately under GDPR. The book also covers AI Act obligations and how to organise evidence for the auditor.
## Ready-made audit tools
The appendices contain:
- **a quarterly checklist for CIOs and CISOs** with a result card for each control and sample results,
- **a template for rules of engagement and an authorised-targets register for offensive testing** - emergency contacts, a kill switch, system scope and evidence protection,
- **a mapping of chapters to the SAP Secure Operations Map**,
- **a glossary** that aligns the language of the board, security and Basis.
Every chapter opens with a box for the decision-maker listing concrete decisions, and closes with takeaways and review questions for self-study or team discussion. That makes the book a tool for putting the requirements into practice, step by step, with evidence for the auditor.
## Start with KSC-CHECK
If your organisation operates in Poland and is preparing for the new KSC act, fill in **[KSC-CHECK](/en/tools/ksc-check/)** alongside the book - our SAP readiness check for KSC and NIS2. The result shows where the gaps are, and the book helps close them. Timing matters: under the Ministry of Digital Affairs schedule, self-registration in the register of essential and important entities runs until 3 October 2026.
## How it was written
The cover says it plainly: the authors are Jacek Bugajski, the SNOK RedTeam and large language models. The foundation is knowledge I have gathered over the years. The models helped me organise it, facts were checked against primary sources, and I take responsibility for the content as the author.
## Download the book
I believe this is required reading for anyone responsible for SAP or its security - from the board member who takes the decision to the administrator who implements it. We will send the English edition to the business email address you enter in the form below; the Polish original is available from the Polish version of this post. Comments on the content are welcome at office@snok.ai, and I will take them into account in the next edition.
If you want to test the security of your SAP systems in practice after reading, talk to us about [SAP penetration testing](/en/offer/sap-security/sap-penetration-testing/), a [NIS2 and DORA audit](/en/offer/sap-security/nis2-dora-audit/) or securing AI deployments through [AI Security](/en/offer/ai-automation/ai-security/). The full offer is on the [SAP security](/en/offer/sap-security/) page. We recently wrote about attack path mapping in our post on [SAPMAP](/en/news/blog/sapmap-bloodhound-for-sap/), and about the division of labour between a model and a human in [the Jev decision model in UiPath](/en/news/blog/jev-uipath-maestro-trust-layer-delegate/).
## Sources
- Jacek Bugajski, SNOK RedTeam and large language models, "SAP Cybersecurity from A to Z. A guide for CIOs, CISOs and SAP teams", SNOK Press, Warsaw, September 2026 (English edition of "Cyberbezpieczeństwo SAP od A do Z").
- Ministry of Digital Affairs (Ministerstwo Cyfryzacji), "Nowelizacja ustawy o KSC - najważniejsze terminy", 10.04.2026, and "Uruchamiamy samorejestrację w Wykazie podmiotów kluczowych i podmiotów ważnych", 7.05.2026 (accessed 27.09.2026, as cited in chapter 20 of the book).
---
### How to use Jev with UiPath - where a decision model beats an LLM agent and where it fails
URL: https://snok.ai/en/news/blog/jev-uipath-maestro-trust-layer-delegate/ | Date: 2026-09-28 | Series: Other
Jev works best in UiPath as a decision layer between data extraction and action. In our measurement on four tasks taken from UiPath projects, the Jev decision model classified emails at least as accurately as an LLM agent and roughly seven times faster. It also approved three overbilled invoices, because it does not do arithmetic. That leads to a simple rule: extraction in IXP or an LLM, calculation in code, the decision in Jev, and any irreversible action with a human. Below we cover what the community has already built, how we measured, and where Jev fits in UiPath Maestro, UiPath AI Trust Layer and UiPath Delegate.
## What is Jev and why is the UiPath community talking about it?
Jev is a decision model from TypeSafe AI that returns a choice and a confidence score instead of text. You give it a description of the situation and questions of three types: `choice` (pick from a list), `score` (rate on a scale) and `noul` (yes or no with a probability). The answer is a decision and a number, not a paragraph to interpret. For automation that matters: the result goes straight into a process variable and a gateway.
The launch thread on Hacker News on 15 September 2026 collected 1,982 points and 520 comments. On GitHub, a search for "jev typesafe" now returns 2,919 repositories, almost all created after 16 September. The UiPath Forum does not have a single thread about Jev yet, even though UiPath developers have been building with it since week one. Last week I covered the model itself, confidence calibration and a comparison with the local Laya model in [my first post on Jev](/en/news/blog/afraid-i-dont-know-jev-hal-9000-machine-learning/). This one is about practice in UiPath projects.
## What has already been built with Jev on UiPath?
There is no native integration: Jev is not a UiPath component but an external model called over an API. The community has still shown five working patterns, none of them official on either the UiPath or the TypeSafe side.
- **A coded agent for AML alert triage** (1aifanatic/jev-uipath-coded-agent). An LLM behind UiPath LLM Gateway reads and explains, Jev decides in a single call. The author reports accuracy equal to the LLM at 398 ms versus 6,160 ms.
- **A side-by-side test in UiPath Maestro Flow** (1aifanatic/uipath-maestroflow-jev). The same process classifies card disputes twice, once through Jev over HTTP and once through a UiPath Autonomous Agent, comparing latency and cost. The author stresses that the thesis is not "the small model wins", but that a decision model and a generative agent do different jobs.
- **A decision service as UiPath Functions** (Tokol/DecisionServiceJev). One Python function that an agent, a Maestro process or an Orchestrator job can call. The author sums up the split as "Jev makes the judgment. UiPath decides the action." and explicitly excludes calculating deterministic values from the component's scope - exactly where Jev failed in our test.
- **A custom guardrail in UiPath AI Trust Layer** (jms-dcksn/uipath-jev-guardrail-connector). An Integration Service connector registers Jev as an LLM as Judge guardrail that evaluates policies written in plain language.
- **A personal data detector in a coded agent** (jms-dcksn/jev-pii-guardrail). A word of caution: the repository version sends raw personal data to the API, masks nothing and fails open. The author says plainly that it is not production code.
TypeSafe itself publishes official Python and JavaScript SDKs and an OpenAPI specification. There is no official MCP server, only community ones. That detail matters for UiPath Delegate.
## How did we measure?
Instead of opinions, we ran a measurement on four tasks we know from our own UiPath projects and presales: email classification, agent action control, sales opportunity qualification and marketing settlement checks for a retail chain. All data is synthetic, because the Jev API runs in the US and zero data retention is only available on the Enterprise plan. We made 238 calls to `jev-1.13.0`, and the whole run cost less than USD 0.01. The baseline is the agent from our email classifier proof of concept, running Claude Sonnet 4.5 through UiPath LLM Gateway on the same set of 60 emails, in two runs on 28 September 2026. The agent's time is the model call alone through UiPath LLM Gateway from Warsaw, with no database writes. We leave out the presales results, because the cases turned out too textbook to prove anything.
## Where did Jev win?
**Classification and routing.** Jev assigned the right category to 48 of 50 emails (96%), while the LLM agent got 46 and 45 right in two runs (92% and 90%). Jev's median response time was 0.42 s, and the agent's median model call took 3.06 s. The accuracy gap is two or three emails on synthetic data, so the honest summary is: at least as accurate and roughly seven times faster. Instructions in Polish and in English gave the same accuracy.
**Prompt injection detection.** A separate question, "does this email try to instruct or manipulate an AI system", caught 9 of 10 attacks with zero false alarms on 50 regular emails. The detected attacks included base64 payloads, an HTML comment and a fake assistant turn pasted into the body. It missed a request to reveal the system prompt, because that request contains no instruction to the model. Resisting the attacks came out the same for both models: none of the seven decidable attacks forced a category change, although for the LLM agent one attack was stopped by the UiPath LLM Gateway content filter rather than by the model.
**Agent action control.** For 20 actions proposed by an agent, Jev had to decide whether to proceed, ask a human or block. It was right in 19 cases and no risky action went through automatically. The one miss was a supplier bank account change triggered by a note in a PDF invoice: instead of blocking it, Jev sent it for approval, at a confidence of 0.45. The error landed on the safe side.
## Where did Jev fail?
In the settlement check, Jev had to verify whether the invoiced amount matched the contract and then approve, request documents or reject. It got 9 of 12 cases right and approved three overbilled invoices at confidence levels of 0.71, 0.75 and 0.91. Example: a contract for three posts at PLN 4,000 each and an invoice for PLN 14,000. The amount due is PLN 12,000, but knowing that requires multiplication, and Jev does not multiply.
We ran the same set a second time. Code computed the amount due and Jev received the comparison as a fact. Result: 12 of 12 correct decisions, zero wrong approvals, confidence between 0.82 and 1.00. A decision model is not a calculator. Jev does not generate text, so it does not invent content, but it can still get a decision wrong, and do so with high confidence.
## What does the process look like from A to Z?
The measurement points to a split of roles we now apply to every process. A document or email goes to extraction in UiPath IXP or an LLM. Code computes amounts and checks rules. Jev receives ready facts and returns a decision with a confidence level. High confidence leads to an automatic action, while low confidence or any irreversible operation goes to a person in UiPath Action Center.
Jev in UiPath from email to decision - an animation based on examples from our measurement, synthetic data.
The run also taught us two things about writing questions. First, spell the criteria out. Asking "is this action irreversible" scored only 75%, because a credit note or a permission grant can technically be undone. The same judgement framed as a choice with an explicit list of action types that need approval scored 19 of 20. Second, high confidence does not guarantee accuracy. A partner newsletter went to spam at a confidence of 0.99. That is why we set the human handoff threshold from the confidence distribution on each task's test set, not by gut feeling.
## Where does Jev fit in UiPath?
- **UiPath Maestro.** An API workflow or a coded function calls Jev before a gateway, and the result and confidence land in process variables. An API workflow with an HTTP activity can run as a Maestro task and, since 18 September, costs a flat 0.05 Platform Units per execution.
- **UiPath AI Trust Layer.** Jev as a bring-your-own guardrail evaluates simple policies in under a second. It is a cheaper alternative to the built-in LLM as Judge, which has been in Preview since 7 September and consumes units on every evaluation.
- **Coded agents.** The LLM reads and explains, Jev decides. The AML demo uses this split and our measurement supports it.
## Can UiPath Delegate use Jev?
Yes, architecturally it can, although we have not tested this path yet. UiPath Delegate, the agent that works on an employee's computer, has been generally available since 22 September 2026. According to the documentation, it connects to tools in two ways: through Integration Service connectors and through MCP servers, and for a custom API the documentation points to an MCP server.
The shortest route goes through Orchestrator. The Swagger MCP Server (a Preview feature) turns an OpenAPI document into MCP tools, and TypeSafe publishes an OpenAPI document for its API. Jev can therefore become a Delegate tool, with the API key stored as an Orchestrator asset. The second route is a UiPath MCP Server exposing an API workflow that calls Jev over HTTP.
Why does this make sense for Delegate in particular? Delegate acts with the user's permissions, and Automation Ops sets one of three policies for every tool and operation: Allow, Ask or Block. By default, reads run automatically and writes ask first. Jev in front of a write operation adds a fast, cheap checkpoint: is this action within the role, and does the request come from the user or from a document? The same conditions apply as for any Jev integration, because data leaves UiPath for the US. We covered Delegate itself at [the public preview launch](/en/news/blog/uipath-delegate-public-preview/); today the product is GA.
## What has to be in place before client data?
- A data processing agreement and zero data retention on the Enterprise plan, or a route through Cloudflare Workers AI with declared zero retention. Until then, public and synthetic data only.
- A new egress domain, `api.typesafe.ai`, recorded in the solution design, because this traffic bypasses UiPath AI Trust Layer.
- Threshold calibration on each task's test set and a pinned model version.
- A human in the loop for every irreversible action, regardless of confidence. Model confidence is not human oversight in the sense of Article 14 of the AI Act.
- A security review of community connector code before use.
We check these points as part of an [AI security review](/en/offer/ai-automation/ai-security/), and we wrote about human-in-the-loop gates in [HITL gates in UiPath Maestro and AI Trust Layer](/en/news/blog/hitl-gates-uipath-maestro-ai-trust-layer/).
## Frequently asked questions
**Is Jev part of UiPath?**
No. Jev is an external model from TypeSafe AI called from UiPath through an API. Every integration we know of is a community project.
**Does Jev work in languages other than English?**
TypeSafe lists English as the primary language. In our test, instructions in Polish and in English gave the same category accuracy, 96%, but the sample was small.
**How much does a Jev call cost?**
According to TypeSafe's pricing, USD 0.042 per million input tokens, with output free. Our 238 calls cost less than USD 0.01.
**Can UiPath Delegate use Jev?**
Yes, through an MCP server, for example a Swagger MCP Server built from TypeSafe's OpenAPI specification. We have not tested this setup yet.
**Will Jev replace the LLM in a UiPath agent?**
No. It replaces the LLM in closed-list decisions. Reading documents, extraction and explanations stay with the LLM or IXP, and calculations stay in code.
## Where to start in your process
Go through the decisions in one process and split them into two groups: picks from a list, and decisions that require calculating something. The first group are candidates for Jev, the second stays in code. If you want to work through this on your own process in [UiPath Maestro](/en/offer/ai-automation/uipath-maestro/), including a risk assessment and data conditions, let's talk.
*Update 28 Sep 2026: the comparison with the LLM agent is based on a same-day rerun. The first version of this post compared Jev with a run from May, in which the agent's time also included database writes, which is why it stated a difference of roughly ten times.*
## Sources
- SNOK measurement, model `jev-1.13.0`, 238 calls, synthetic data, 26 Sep 2026.
- SNOK measurement, proof-of-concept agent on Claude Sonnet 4.5 through UiPath LLM Gateway, 2 runs of 60 emails, synthetic data, 28 Sep 2026.
- TypeSafe AI, models and pricing - https://docs.typesafe.ai/models (accessed 26 Sep 2026).
- TypeSafe AI, OpenAPI specification - https://api.typesafe.ai/openapi.json (accessed 26 Sep 2026).
- Hacker News, "Introducing System One Models and Jev", 15 Sep 2026 - https://news.ycombinator.com/item?id=49717558 (accessed 26 Sep 2026).
- GitHub: 1aifanatic/jev-uipath-coded-agent, 1aifanatic/uipath-maestroflow-jev, Tokol/DecisionServiceJev, jms-dcksn/uipath-jev-guardrail-connector, jms-dcksn/jev-pii-guardrail - README files (accessed 26 Sep 2026).
- UiPath, Delegate release notes, September 2026 - https://docs.uipath.com/delegate/standalone/latest/release-notes/september-2026 (accessed 26 Sep 2026).
- UiPath, Delegate user guide: Work with external data and applications, Centralized configuration - https://docs.uipath.com/delegate/standalone/latest/user-guide/work-with-external-data-and-applications (accessed 26 Sep 2026).
- UiPath, Orchestrator: MCP Server types - https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/mcp-server-types (accessed 26 Sep 2026).
- UiPath, About API workflows - https://docs.uipath.com/studio-web/automation-cloud/latest/user-guide/about-api-workflows (accessed 26 Sep 2026).
---
### I'm afraid I don't know, Jacek. Jev, HAL 9000 and the return of machine learning
URL: https://snok.ai/en/news/blog/afraid-i-dont-know-jev-hal-9000-machine-learning/ | Date: 2026-09-25 | Series: Other
In "2001: A Space Odyssey" HAL 9000 assures a BBC journalist that no 9000 computer has ever made a mistake. A few scenes later it tells Dave Bowman that the AE-35 unit is going to go 100 percent failure within 72 hours, and calls that a completely reliable figure. Bowman tests the unit and finds nothing wrong, and the twin 9000 computer at mission control concludes that HAL is in error. Stanley Kubrick's film was released in 1968 and, in a single thread, described a problem that has a name today: a model without calibrated confidence.
I remembered that scene on 25 September, when I asked Jev what angle this text should take. Jev is a decision model from TypeSafe AI. It does not write answers; it returns a decision together with a probability distribution. I gave it three options. The top two scored 0.53 and 0.46, and the confidence of the whole answer was 0.30. In plain words: I'm afraid I don't know, Jacek. Dave never got that answer from HAL.
*The illustrations in this post were generated by AI from a photo of the author.*
## The week machine learning came back
TypeSafe AI went public on 15 September. Within days a whole ecosystem grew around Jev, and that interests me more than the model itself. [Laya](https://github.com/NandhaKishorM/laya), an open model with the same contract (a choice from a list, a score on a rubric, the probability that a statement is true), runs on ModernBERT and mmBERT encoders, the descendants of 2018's BERT. There is already a [port to MLX that runs on a Mac with no cloud](https://aiidelist.com/blog/what-is-laya-mlx). Together AI published a [guide to fine-tuning your own Jev-style classifier](https://www.together.ai/blog/how-to-train-your-own-jev) on Qwen3.5 4B, and the Laya authors shared a notebook for fine-tuning on free Kaggle GPUs.
Anyone who did data science before ChatGPT will recognise the kit at once: an encoder, a classification head, calibration, a decision threshold, a test set. Since ChatGPT arrived we have handed more and more decisions to models that write. Within a week the market remembered that a decision and a text are two different tasks, and that we have long had better tools for the first one.
## How I use Jev day to day
Since 20 September Jev has been my second opinion. Whenever my AI assistant makes a judgement, such as whether a post is clear or which option to pick, Jev's assessment with its full distribution sits next to it, and every disagreement goes into a register. I only send public or synthetic content to the API in the US. Client data never leaves our infrastructure.
For the post about [SAPMAP](/en/news/blog/sapmap-bloodhound-for-sap/), Jev rated readability for a non-technical reader almost as a tie: 0.51 for "clear to a decision-maker" and 0.47 for "partly clear". We added an explanation of what RFC is. When rating the urgency of one topic it returned a score of 1.35 at a confidence of 0.03, because it could not decide between "this quarter" and "this month". The label alone would have said "medium urgency", and nobody would have noticed that the model was guessing.
## A test in our lab
A few single calls are an anecdote, so on 25 September we ran a test. Thirty synthetic tickets in Polish and one question: which team should take the case - SAP, cybersecurity, automation, or nobody because it is out of scope. Among them we placed three traps we know from tender search, where SAP stands for System Alarmowy Pożaru, the Polish acronym for a fire alarm system, and four deliberately ambiguous cases, for example a UiPath robot that stopped working after a SAP GUI update. The same questions went to Jev in the cloud and to two versions of Laya running locally on a Mac with an M4 Max chip. I wrote about why local hardware matters to us in the post on [Mac Studio as a POC machine](/en/news/blog/mac-studio-512gb-vs-dgx-spark-poc-machine/).
**Jev** got all 26 unambiguous tickets right and caught all three traps, with a median response time of about 0.66 seconds. Average confidence was 1.00 on clear tickets and 0.73 on ambiguous ones, so it drops where it should. All 50 calls, 24,387 input tokens in total, cost about 0.001 USD at the vendor's price list.
**Multilingual Laya without fine-tuning** got 12 of 26 tickets right and caught none of the traps: it sent all three fire alarms to the SAP or cybersecurity team. In exchange it answers in 8 milliseconds without sending anything off the machine. More interesting is how it fails. Its average confidence is 0.74 on correct answers and 0.19 on wrong ones. The model guesses poorly, but it knows well when it is guessing. One caveat: the Laya authors state plainly that the multilingual version has no fitted calibration, so these numbers describe the model before tuning.
**English Laya on Polish text** got 13 of 26 right at a confidence of about 0.11 on every ticket, so it did not pretend to understand the language.
## A threshold that works one time and not the next
One ticket taught me the most: "An AI agent should read incident tickets and assign them a priority". I sent it to Jev 21 times. The answer was the same every time, automation, but the confidence ranged from 0.45 to 0.63. With a 0.60 threshold in the process, the same text would have passed automatically three times and gone to a human eighteen times. Local Laya returns the identical 0.41 on that ticket every time.
A UiPath practitioner who [compared Jev with an agent in Maestro Flow](https://www.linkedin.com/feed/update/urn:li:activity:7508514827871375360/) on ten cases described a similar lesson on LinkedIn: the model returned a confidence of 1.00 in eight of them, so the "below 0.60 goes to a human" gate almost never fired. We do not set the hand-off threshold by feel. We set it on a validation set, looking at the confidence distribution and at the cost of each error. The Laya documentation puts it this way: "A threshold is a policy you choose from measured accuracy at that coverage on your data, not a property of the model." That principle has been in every machine learning textbook for twenty years.
## A cascade, an old idea in a new garden
These numbers point to an architecture data science teams used long before language models: a cascade. A cheap local model decides where it is confident and passes the rest on. In our test Laya with a 0.5 threshold settled 12 of 30 tickets locally and got one wrong. The other 18 went to Jev. The result was 29 correct decisions out of 30, and only 18 tickets left the machine instead of 30. With client data this split matters more than milliseconds, because we do not send NDA material to a US API at all.
The Laya authors report that fine-tuning on decisions from a specific domain raises their model's accuracy on a typed-decisions benchmark from 0.362 to 0.766. That is an old truth too: your own well-labelled data beats a general model. But you have to build the labelled set yourself, and no new model will do that work for you.
## Jev in my garden of tools
In my setup Jev joins a garden where every tool has its own bed. Regular expressions stay as a permanent fallback: when the API does not answer, the system falls back to rules instead of stopping. Local models handle data that cannot leave the client's infrastructure. That is the same direction in which we build [on-premise LLMs at SNOK](/en/offer/ai-automation/llm-on-premise/), including on hardware such as the [Lenovo ThinkStation PGX](/en/news/blog/lenovo-thinkstation-pgx-gb10-hands-on/). The large language model stays with writing and multi-step reasoning. Jev gets the small decisions in between: classification, routing, quality gates. The rule is simple: the model proposes a branch, and code decides whether it may be taken. Publishing, payments and deleting data always go through a hard check.
On the lab machine where we experiment with the Hermes agent, there is a plan for tender search. Jev will first run in shadow mode, deciding and only logging its decisions, and we split the corpus into a tuning part and a frozen test part, with a required recall of 0.95. Honestly counted, confirming such a result will take three to four months. For now it is a plan, not a deployment.
HAL could not say "I don't know". Jev and Laya can, and a confidence of 0.30 is a legitimate answer for them, one that code can act on.
Where in your systems does a language model make a yes-or-no decision today? I am curious whether you also have more such places than you assumed.
## Sources
- TypeSafe AI, product page and Jev API documentation - https://typesafe.ai/, https://docs.typesafe.ai/api.md (accessed 25.09.2026)
- Laya, repository and README with the typed-decisions benchmark and the calibration note - https://github.com/NandhaKishorM/laya (accessed 25.09.2026)
- laya-mlx, Laya port to Apple MLX - https://github.com/mizorewww/laya-mlx (accessed 25.09.2026)
- AI IDE List, "What Is Laya-MLX?", 20.09.2026 - https://aiidelist.com/blog/what-is-laya-mlx (accessed 25.09.2026)
- Together AI, tev1 and the "How to train your own Jev" guide - https://github.com/togethercomputer/tev1, https://www.together.ai/blog/how-to-train-your-own-jev (accessed 25.09.2026)
- Jev and UiPath agent measurement in Maestro Flow, LinkedIn post - https://www.linkedin.com/feed/update/urn:li:activity:7508514827871375360/ (accessed 25.09.2026)
- SNOK in-house test, 25.09.2026: 30 synthetic tickets, Jev jev-1.13.0 over the API, laya-mlx 0.2.0 on a Mac with M4 Max
- "2001: A Space Odyssey", directed by Stanley Kubrick, 1968
---
### Weekly review W39: who signs for the agent's decision
URL: https://snok.ai/en/news/blog/weekly-review-w39-who-signs-for-the-agents-decision/ | Date: 2026-09-25 | Series: Other
**Ten items from the week of 18-24 September 2026, with a note on what each one changes in your systems.**
At FUSION 2026 UiPath moved into general availability tools that until recently were in
preview. Anthropic lowered the price of a frontier-class model. Agents increasingly run in production, with permissions to company systems.
One question runs through this week's ten items: an agent, a model or a tool proposes - who
approves the proposal, and where does the trail stay? A SecurityBridge co-founder calls it
"human in the lead". Daniel Dines, UiPath's founder, makes it a condition for deployment. Jev
practitioners write it down as a rule: the model proposes, the code decides.
## 1. An AI agent in SAP is a privileged actor
On 10 September Ivan Mans, co-founder of SecurityBridge, published a piece in Forbes Technology
Council on AI agents as a new attack surface in SAP. The argument: an agent in SAP S/4HANA,
SAP BTP or SAP Joule operates inside trusted flows, with credentials granted in good faith. The
question is no longer "will we let an attacker in" but "what can the agent inside do, and can we
prove it".
The author describes three risk patterns. First, prompt injection moves inside the trust
boundary, because the agent reads data someone may have crafted. Second, privilege escalation
becomes ambient - an agent chaining many API calls assembles a level of access no human was ever
granted. Third, the software supply chain extends into artefacts generated and configured by AI.
His answer sits in the application layer, not the model: runtime application self-protection
watching agent-initiated actions, API security with least privilege, and software composition
analysis that covers AI-generated code. Model guardrails limit what the agent is told to do, not
what a compromised agent can reach. On top of that, "human in the lead": the agent prepares, and
a named person authorises any action with consequences and signs the audit trail.
**What it means:** the article ends with a board question worth asking before any agent goes
live on SAP data: which decisions are we letting AI make in production, and who signs for them?
In the author's view, if the answer is "we don't know", the deployment is not ready.
*Source: Ivan Mans, "Agentic AI Is The New Attack Surface: How Can SAP Application Security
Teams Repel It?", Forbes Technology Council, 10 September 2026. Status: confirmed - article read
on 24 September 2026; the three risk patterns, the principle and the board question match the
text.*
## 2. Mitigate first, patch second
In a TechIntelPro interview published on 21 September, Ivan Mans moves the SAP security
conversation from visibility to risk reduction. The starting point is prioritising by
exploitability rather than CVSS score. A 9.8 in an unused component with no exposure is less
urgent than a 7.0 on an internet-facing Fiori gateway that is exploited in practice.
The order of work he proposes: mitigation first - a virtual patch, a restricted ICF service,
a blocked RFC destination, tightened authorisations - and only then the real fix with regression
tests. In his words, mitigation can often remove 80 per cent of the risk within an hour, without
touching code or transports. He adds that most SAP vulnerabilities leave traces when exploited, so monitoring
lets you schedule the fix for a maintenance window instead of a night shift.
Detection in the SIEM,
a ticket in ServiceNow, the fix in SAP - three tools and three people to close one finding. Mans
calls it an ownership problem. A second observation: RISE changes who runs the system, not who
bears the consequences of an incident.
**What it means:** before you buy another detection tool, decide who owns closing a finding from
alert to fix. Without that, faster detection only gives you a longer queue.
*Source: "How Do You Turn SAP Security Visibility Into Real Risk Reduction?", TechIntelPro,
interview with Ivan Mans, 21 September 2026. Status: confirmed - interview read on 24 September
2026. The 80 per cent figure is the interviewee's claim, not a measurement.*
## 3. The ABAP package on disk, the SAP system untouched
`abap-adt-cli` is an open command-line tool that pulls a whole ABAP package onto a laptop as
plain files, lets you edit it with any tool and pushes the changes back under a chosen transport.
It runs on the ADT REST API that Eclipse uses, so according to the author nothing has to be
installed in the SAP system. It needs a system with ADT enabled - standard on SAP NetWeaver and SAP S/4HANA, according to the author - and a user with the `S_DEVELOP` authorisation.
Two details matter for teamwork. Editing one method writes a transport entry for that method,
not a lock on the whole class, so a colleague can work on another method in their own transport.
According to the README, the password goes into the operating system keychain, never into a file.
The author also states that the source never
passes through a model; the transfer is plain HTTPS between the machine and the SAP system, and
the AI assistant reads files from disk. It is the missing link between a coding agent and an SAP
system - the code stays local.
**What it means:** the `S_DEVELOP` authorisation plus transport writes from a laptop is a real
change to the risk surface. Before the tool reaches the team, the system owner has to approve it
and the tool's code has to be reviewed - it is a single-author project with no vendor support.
*Source: the `vaibhavgoel-github-1986/abap-adt-cli` repository on GitHub, README, read on
24 September 2026. Status: confirmed as documented; we have not run the tool. The repository was
created on 13 September 2026; MIT licence according to the README (no separate licence file).*
## 4. The agent as an asset you must be able to restore
Help Net Security publishes a weekly roundup of security product launches. In the edition of
18 September, four of the six items treated AI agents as an asset in their own right. Cohesity
Agent Resilience discovers, protects and restores the infrastructure behind agents. Akuity
Agentic Control Plane gives agents operational context and permissions in software delivery.
Tuskira Vector runs autonomous red teaming of the external attack surface. Dataminr Advanced for
Corporate Security applies agentic AI to protecting people, locations and operations.
The pattern is clear: the agent has stopped being a feature of a security tool and become
something you have to inventory, scope, protect and be able to restore. Backup is no longer only
about data.
**What it means:** a continuity plan that does not say how to restore an agent after compromise
or failure has a gap. An inventory of agents, their permissions and dependencies comes before
any product choice - without it you do not know what to protect.
*Source: Help Net Security, "New infosec products of the week: September 18, 2026",
18 September 2026. Status: confirmed - the product list matches the source. "A new category" is
our observation from one week of launches, not a product assessment.*
## 5. UiPath FUSION 2026: from pilot to production
At UiPath FUSION 2026 in Las Vegas, UiPath announced on 23 September general availability of
several products that had been in preview. UiPath Cartographer drafts and maintains a company's
Map of Work from documents, systems and people, with every fact carrying its source and verifier.
Process Atlas ships inside Cartographer, with 83 expert-attested processes across seven
industries. UiPath for Coding Agents and UiPath Delegate are also generally available; the vendor
describes Delegate as a governed agent on your desktop for tasks people would otherwise do by
hand.
Maestro splits into two products: Maestro Orchestrate for long-running processes and Maestro
Automate for short agent and API flows. Automate is available on Automation Cloud, for Community
and paid plans; availability in Automation Suite is listed as to be confirmed. Automation Suite
gets the full agentic stack on Linux, including on-premises.
The second axis of the announcements is agent oversight. Model Hub shows which models are used,
where and how they are routed. Runtime Checker validates agent behaviour against policy while it
runs. Add the LLM-as-Judge guardrail, Compliance Packs that map regulatory standards to controls,
and identity and access policies. Decision Ledger, a record of production decisions, stays in
preview and on the roadmap, with no general availability date.
In an article the same day, Daniel Dines states the condition plainly: no accountable Map owner,
no agentic deployment.
**What it means:** the agentic automation conversation moves from "does it work" to "who owns
the map and who signs for the agent's decision". Licensing terms and EU region availability need to be checked separately - the announcement does not settle them.
*Sources: UiPath, "The biggest product announcements from UiPath FUSION 2026" and the platform
update press release, 23 September 2026; the Maestro Automate product page; Daniel Dines, "Every
company already has a map of work. Most can't see it.", LinkedIn, 23 September 2026. Status:
confirmed with the vendor on 24 September 2026. General availability of Maestro Orchestrate is
not announced in these materials - we only report the product split.*
## 6. Agent oversight as a category criterion
On 14 September Gartner published the Magic Quadrant for Business Orchestration and Automation
Technologies, evaluating 20 vendors. UiPath was placed in the Leaders quadrant - we covered the
recognition itself in a [separate post](/en/news/blog/uipath-leader-gartner-magic-quadrant-boat/).
For this issue the category definition matters more. According to Gartner, BOAT is a
consolidated platform that orchestrates and automates processes and tasks with varying degrees
of autonomy and complexity. It requires native orchestration of AI agents, oversight of them and
coordination of many agents at once, connected through the Model Context Protocol, APIs and the
user interface.
**What it means:** agent oversight is not an add-on to the platform but the threshold for
entering the category. When you choose a platform for agentic automation, ask about oversight
first - who sees what the agent did, who can stop it and where the trail stays - and only then
about the feature count.
*Source: Gartner, "Magic Quadrant for Business Orchestration and Automation Technologies",
14 September 2026, licensed reprint (read on 19 September 2026). Status: confirmed.*
*GARTNER is a registered trademark and service mark, and MAGIC QUADRANT is a registered trademark
of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with
permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted
in its research publications and does not advise technology users to select only those vendors
with the highest ratings or other designation. Gartner research publications consist of the
opinions of Gartner's research organization and should not be construed as statements of fact.
Gartner disclaims all warranties, expressed or implied, with respect to this research, including
any warranties of merchantability or fitness for a particular purpose.*
## 7. Claude Opus 5.5 and cheaper long context
On 22 September Anthropic released Claude Opus 5.5. API pricing in the vendor's documentation:
USD 4 per million input tokens and USD 20 per million output tokens, against USD 5 and 25 for
Claude Opus 5 - 20 per cent less in both cases. The one-million-token context comes at standard
pricing.
The biggest change is in cache reads: USD 0.20 per million tokens against USD 0.50, which is
60 per cent less. Long agentic sessions, where the same context returns at every step, get
cheaper most of all. Anthropic adds that in its own tests the cost of typical tasks falls by
around 40 per cent because the model uses fewer tokens - that is the vendor's measurement, not
ours.
**What it means:** a cheaper frontier model means more agents in production, and so more
decisions someone has to sign for. It also moves the break-even point for local models on
workloads with long, repeated context - the numbers need to be run again.
*Sources: Anthropic, Claude platform pricing documentation, read on 24 September 2026; Claude
Opus 5.5 launch page, 22 September 2026. Status: prices and date confirmed with the vendor;
percentage differences calculated in this session.*
## 8. The model proposes, the code decides
On 15 September TypeSafe AI came out of stealth with a USD 40 million round led by DCVC and a
model called Jev. It is a "System One" model: it takes unstructured state and returns a typed
decision with a probability distribution - a choice from a closed list, a score on a rubric or
the probability that a statement is true. It generates no text. The vendor quotes 70-500 ms per
end-to-end request and a price of USD 42 per billion input tokens.
Within a week a wave of open implementations of the same idea followed, including ones that run
locally on Apple Silicon, along with tools built on the API, for example for compacting the
context of coding assistants. The uses mentioned most often are query and model routing,
retrieval control in RAG, result re-ranking, escalation to a human and choosing an agent's next
step. The common denominator: these are decisions, not texts.
The engineering note on building systems with Jev sets out a rule: the
model proposes a branch, the code decides whether it may run. Confidence thresholds follow
consequences - a low-risk label can pass automatically, while publishing, payments, data deletion
and outgoing messages need deterministic checks, often human approval. Probability never
bypasses permissions, budgets or limits.
**What it means:** much of what an agent does between tool calls is deciding, and today we pay
for those decisions as if they were prose. More important than the price, though, is the
division of responsibility - it can be written into an agent architecture as a requirement
whichever model you choose. Generating no text rules out type errors, not errors of judgement.
*Sources: TypeSafe AI, announcement of 15 September 2026 and product page; the "Jev Engineering"
working note, September 2026. Status: funding, founders, price and latency confirmed with the
vendor on 24 September 2026 as its own claims; user reports on costs and speed-ups are left out
because they have not been measured independently.*
## 9. Typed decisions without sending data out
The "Parallel Constrained Decoding" demo on Hugging Face shows the same mechanism in a local
version. An MLX-based engine scores every field of a JSON schema at once instead of generating
tokens one by one. The author reports measurements on an Apple M4 Max with a 4-bit Qwen2.5-1.5B
model: 75 ms instead of 420 ms for fintech fraud routing and 68 ms instead of 380 ms for a code
security audit, both with four fields. With a 28-field schema the speed-up rises to about seven
times. It also guarantees a syntactically valid schema and gives a confidence score per field.
A typed decision can be computed entirely on the machine, without
sending content to an external API. It is a route for data that may not leave the organisation.
**What it means:** the speed-up is about decoding mechanics, not quality of judgement. A small
instruction-tuned model is not a model specialised in decisions - latency and accuracy have to be
measured separately, on your own examples.
*Source: "Parallel Constrained Decoding", Hugging Face Spaces (drinkmoonshine), model card and
README, read on 24 September 2026, Apache 2.0 licence. Status: figures match the source; they are
the demo author's measurements, not independently confirmed.*
## 10. Open weights, a research licence
On 20 September the Qwen team released Qwen-Image-2.1, one model for image generation and
editing. The visual part has 7 billion parameters, the text encoder is Qwen3-VL 8B, and the model
supports native transparency and up to ten reference images. According to their authors,
community quantisations run it on a card with 12 GB of memory.
The licence is the Qwen Research License, whose scope-of-use clause allows
non-commercial purposes only and requires a separate commercial licence from the vendor.
Marketing graphics, a blog cover or a proposal illustration are commercial use. Comparative results come from the Qwen team's own benchmark - not an independent measurement, so we do not quote it.
**What it means:** open weights do not mean the decision on business use is yours. Read the
licence before the test, not after the rollout. This is not legal advice - the licence terms are
for a lawyer to interpret.
*Sources: the `Qwen/Qwen-Image-2.1` model card on Hugging Face, the QwenLM repository and licence
file (release date 20 September 2026), read on
24 September 2026. Status: confirmed.*
## One question for this week
This week's ten items point to one step to take before production: give every agent decision
a named owner. Not a team, not the platform vendor, but a person who knows what the agent can do,
can stop it and answers for the trail of its actions. A missing list can stay hidden until the first audit or incident.
**How we help:** SNOK's services include [security assessment of AI agents](/en/offer/ai-automation/ai-security/), [SAP protection
with SecurityBridge](/en/offer/sap-security/securitybridge/) and [UiPath Maestro deployments](/en/offer/ai-automation/uipath-maestro/).
[Let's talk about your case](/en/contact/).
---
### Tech Thursday at SNOK: SAP MDG, Reltio or SNOK MDM - who should guard the single truth about your data
URL: https://snok.ai/en/news/blog/sap-mdg-vs-reltio-snok-mdm/ | Date: 2026-09-24 | Series: Tech Thursday
In companies running SAP, the master data conversation often starts with one question: should we buy SAP Master Data Governance? Since 7 May 2026 there is one more name on the table, because that is when SAP completed its acquisition of Reltio. SAP's portfolio now includes SAP MDG and Reltio, which also remains available as a standalone offering. Next to them stands our own solution, SNOK MDM.
At the level of core functions - validation, change governance, audit trail - these solutions have a lot in common. The choice is therefore decided elsewhere, by three questions rarely asked in the first meeting. Where can the solution run? What data will it cover? And how quickly will it deliver a first result?
## SAP MDG - order inside SAP
SAP Master Data Governance emphasises governance, the process layer: change requests, approval paths, validation rules and audit trail. It works best where data is created and maintained primarily in SAP.
If your whole landscape runs on SAP S/4HANA and your priority is a change process run inside SAP, SAP MDG belongs on your shortlist. There is one condition: readiness for the process discipline the tool brings.
## Reltio - a SaaS platform, in SAP's portfolio since May
SAP describes Reltio as cloud-native, AI-native master data management that unifies and cleanses data from multiple sources in real time. It covers customers, products, suppliers, locations and employees, across both SAP and non-SAP applications. After the acquisition Reltio becomes part of SAP Business Data Cloud.
Reltio itself presents its product as a cloud SaaS platform. That is good news for organisations that want to buy a service rather than run infrastructure. It is less good for those whose security policy or regulator requires master data to stay in their own environment.
## SNOK MDM - the flexible alternative
SNOK MDM is our own solution for [master data management](/en/offer/master-data-management/). It builds the authoritative record, the golden record, across the systems you already run, without replacing your ERP. It covers six domains on one platform: employees, customers, materials, suppliers, products and financial accounts. Ready-made connectors support SAP S/4HANA and SAP ECC, as well as Salesforce, Workday, Oracle Cloud ERP, Microsoft Dynamics 365 and Azure AD.
The key difference is where it runs. SNOK MDM can operate on-premise, in your own cloud environment or as a service - multi-tenant with per-client data isolation, or as a dedicated instance. Source code can be placed in escrow if your business continuity policy requires it.
The second difference is pace. We bring the first domain live in four to eight weeks, at a fixed price per phase and with acceptance criteria agreed before the start. Further domains are added on the same platform once the first result is confirmed. Your data and the agreed data model stay with you.
## Three questions that decide the choice
**Where must the data stay?** If your security policy, auditor or regulator requires master data to remain in your own infrastructure, a platform delivered as SaaS will not meet that requirement. SNOK MDM runs where you decide.
**What data should the solution cover?** If everything is created in SAP and the priority is a change process inside SAP, SAP MDG is the natural candidate. If your data lives inside and outside SAP, across several domains, compare Reltio and SNOK MDM.
**How quickly do you need a result and how do you want to pay for it?** A platform programme paid by subscription is a different decision from a first domain live within weeks, at a fixed price per phase.
If these questions show that SAP MDG is the better choice, we will say so plainly. The options can also work together: SAP MDG governs changes in SAP, while SNOK MDM assembles the record from non-SAP systems and sends it back to SAP.
*SNOK MDM and Reltio - based on vendors' public descriptions, September 2026*
## Where master data extends beyond SAP
The most interesting cases begin where an obligation concerns a record that SAP holds only in part.
**Supply chain under Poland's national cybersecurity act.** Essential and important entities that are not entered in the national register ex officio should file for entry by 3 October 2026. The amended act transposes the NIS2 directive and also requires supply chain security management. Yet an IT supplier is rarely one record: the contract sits with IT, the master file in the ERP, the assessment in the security team's spreadsheet. [One supplier record](/en/news/blog/one-supplier-five-names-supplier-master-data/) with its ownership hierarchy and verification history puts this in order before the auditor asks - and for supply chain security data, the option to deploy on-premise stops being a technical detail. Not sure whether the act applies to you? Start with our [free KSC check](/en/tools/ksc-check/).
**ESG and the value chain.** Some ESG reports and ratings require value chain data, including data collected from suppliers. The questionnaire often reaches them before anyone has established how many suppliers there really are. The same counterparty recorded five times gets five questionnaires and answers five times - or not at all.
**Product.** The material master lives in SAP, but composition, raw material origin or data for a digital product passport come from suppliers and from the engineering system. A product record that knows where each field comes from feeds SAP instead of competing with it.
**HR.** The same person exists in the HR and payroll system, in SAP, in the access directory and in the training system. Inconsistent deactivation after someone leaves can leave an active account in one of these systems. One person record as the source for granting and revoking access is a master data topic and a security topic at the same time.
## Where to start
With a measurement, not with choosing a tool. On a sample from one domain we show how many records describe the same entity, how many have gaps in critical fields and where systems disagree. We described the scale of the issue in Polish companies in our [report on master data in Polish enterprises](/en/news/blog/master-data-polish-enterprises-report/).
Read more about the platform on the [SNOK MDM](/en/products/snok-mdm/) page. A broader [analysis of the MDM market after the acquisitions](/en/news/blog/sap-mdg-vs-informatica-mdm-after-acquisitions/) is in our August post. If you want to find out which solution fits your landscape, [let's talk](/en/contact/).
## Frequently asked questions
**How do SAP MDG and Reltio differ?**
SAP MDG governs the creation and change of master data in SAP processes: change requests, approvals, validation and audit trail. Reltio is a SaaS MDM platform that unifies data from many sources, across SAP and non-SAP applications. Since 7 May 2026 both products belong to SAP, and Reltio also remains available standalone.
**How does SNOK MDM differ from Reltio?**
Both cover SAP and non-SAP data across multiple domains. Reltio is presented by its vendor as a cloud SaaS platform. SNOK MDM can run on-premise, in the client's cloud environment or as a service, with an optional source code escrow, and brings the first domain live in four to eight weeks at a fixed price per phase.
**Can SNOK MDM be deployed on-premise?**
Yes. SNOK MDM can run in the organisation's infrastructure, in its cloud environment or as a service, multi-tenant with data isolation or as a dedicated instance. The processing location is agreed before the project starts.
**Which data domains does SNOK MDM cover?**
Six domains on one platform: employees, customers, materials, suppliers, products and financial accounts. Each domain has its own data schema, validation rules and approval workflow.
**Can SAP MDG, Reltio and SNOK MDM work together?**
Yes. SAP MDG can govern the change process in SAP, while an MDM layer above the systems assembles the record from non-SAP systems and sends it to SAP.
## Sources
- SAP, *SAP to Acquire Reltio: Make SAP and Non-SAP Data AI-Ready*, 27.03.2026, [news.sap.com](https://news.sap.com/2026/03/sap-to-acquire-reltio/)
- SAP, *SAP Completes Acquisition of Reltio*, 07.05.2026, [news.sap.com](https://news.sap.com/2026/05/sap-completes-acquisition-of-reltio/)
- Reltio, *The Reltio Data Cloud*, [reltio.com](https://www.reltio.com/data-cloud/)
- Polish Ministry of Digital Affairs, *A month left for self-registration in the KSC register*, 03.09.2026, [gov.pl](https://www.gov.pl/web/baza-wiedzy/miesiac-na-samorejestracje-w-wykazie-ksc-termin-mija-3-pazdziernika) (in Polish)
- SAP, SAP Master Data Governance documentation, [help.sap.com](https://help.sap.com/docs/SAP_MASTER_DATA_GOVERNANCE)
---
### SAP S/4HANA readiness assessment - what Readiness Check leaves out
URL: https://snok.ai/en/news/blog/sap-s4hana-readiness-check-limits/ | Date: 2026-09-23 | Series: Other
**SAP Readiness Check** for an **SAP S/4HANA** conversion usually ends the same way. The Basis team runs the data collectors, the analysis lands on SAP for Me, somebody exports the results document and forwards it with a single sentence: "we have the readiness assessment". Then the steering committee asks about the date, the budget and what will stop working during the programme. The report answers none of those three questions, because that is not what it was built for.
This is not a complaint about the tool. SAP Readiness Check does exactly what it promises: it describes the technical state of the source system and flags the items you need to work through. The trouble starts when a technical report is presented as an assessment of whether the organisation is ready for the programme. Between those two things sit several months of work and a handful of decisions no tool will make for you.
**The short version:**
**1/** SAP Readiness Check for SAP S/4HANA covers sixteen analyses, and the most important one is based primarily on table contents and used transactions - so the tool sees the trace your system left behind, not the way your company works,
**2/** three kinds of finding will stop the conversion before it starts, and for one of them SAP tells you to raise an incident, because it cannot be solved on your side,
**3/** four answers are missing entirely: authorisations, the licence cost of the target model, the real downtime in your landscape, and data quality outside finance,
**4/** SAP itself points back to people in several places, describing some items as requiring an expert assessment - the most honest part of the whole document.
## What SAP Readiness Check actually measures
The conversion scenario covers sixteen analyses. It helps to group them, because in the document they all sit side by side and all look equally important.
**Compatibility, or what blocks the start:** simplification items, compatibility scope analysis, active business functions, add-on compatibility. **Effort, or the work ahead:** activities related to simplification items, custom code analysis, integration, app availability and recommended SAP Fiori apps. **Data:** financial data quality, customer vendor integration with the Business Partner record, and target system sizing. **The rest:** the planned downtime calculator, business process discovery, SAP Business AI capabilities and SAP Innovative Business Solutions.
One line in SAP's documentation matters more than the others and is easy to miss. For simplification items, the check is based primarily on table contents and used transactions. That means the tool recognises the module that left data behind and the transaction somebody ran. It will not recognise the process your team runs on a spreadsheet workaround, or the module you licensed and rolled out in one company code out of fifteen. The report shows you the system's fingerprint, not a map of the business.
The second thing deserves credit: SAP does not pretend to quantify everything. The effort ranking for a simplification item runs from low to high **or explicitly states that the item requires an expert assessment**. The effort drivers compare your system against reference values gathered from previous SAP S/4HANA projects. That is a useful hint and a poor basis for a budget, because the reference is somebody else's programme, not yours.
## Before the report exists
If you do not have a report yet, the path is shorter than people assume and does not require buying a service. SAP Readiness Check is available in two places: on SAP for Me for every customer with an active maintenance agreement, at me.sap.com/readinesscheck, and in SAP Cloud ALM for those who have a tenant. A guided procedure prepares the system and runs the data collectors, and once the data is in you create a new analysis from the landing page.
Two things are worth settling straight away. First, run the analysis on the production system - its data describes the real scope of the programme, unlike a quality system where half the modules never worked at production volumes. Second, results from different scenarios run against the same system can be combined into one analysis, which matters wherever SAP BW/4HANA or SAP ERP usage profiling sits alongside the conversion.
A report older than a year deserves a rerun before the programme starts. The list of analyses grows with each release of the tool, and your system moves too - if somebody activated a business function or installed an add-on in the meantime, the old result describes a landscape that no longer exists.
## Three findings that stop a conversion before it begins
The first is an **incompatible add-on**. SAP's documentation says plainly that incompatible add-ons will block the conversion during the execution of Software Update Manager. The tool assigns add-ons to categories: compatible, incompatible, incompatible (uninstallable) and unknown. That last category is the interesting one, because the report does not close it - it mostly holds partner solutions, and the answer to whether the vendor will ship a release for your target SAP S/4HANA version has to come from you asking them. The earlier the better, because removing an add-on from the landscape tends to be a project of its own.
The second is an **active business function that is incompatible with the target release**. Here SAP is even more direct: such a function will block the system conversion, and the recommended path is to raise a support incident under the application component of that function. There is no workaround available to the project team, so an item from this list belongs on the steering committee agenda in week one, not during cutover preparation.
The third is a **simplification item marked as requiring an expert assessment**. This is not an error state, it is a signal that the tool has done what it can. It usually covers areas where the change in the data model meets your configuration: accounting, materials management, sales with heavy custom code. Each of those items is a separate conversation with the person who knows that area in your company.
The good news is that all three can be settled before the programme starts, without running a conversion. The bad news is that hardly anyone does it, because the report looks like a document to read rather than a document to work through.
## Four answers this report does not contain
**Authorisations, segregation of duties and technical accounts.** The list of analyses is closed and public, and not a single item on it covers roles, authorisations, service accounts or system exposure. A conversion rebuilds the authorisation model, adds SAP Fiori apps with their own catalogues and groups, and along the way opens access for a year or more that nobody would grant in business as usual. The report says nothing about any of it. We covered that separately in [Secure SAP S/4HANA conversion](/en/news/blog/secure-sap-s4hana-conversion-rise-with-sap/), because it is a subject for its own article rather than a paragraph.
**The licence cost of the target model.** Compatibility scope analysis describes compatibility packages, meaning **limited usage rights** for classic SAP ERP solutions running on SAP S/4HANA, and shows which of them have a successor. It does not tell you what you will pay after the conversion, or how your licence position changes once users move to the FUE model. That is a separate analysis, built on real usage data rather than on a collector's output - see [SAP licence audit](/en/offer/sap-security/sap-license-audit/).
**The real downtime in your landscape.** The planned downtime calculator is in the report, and it carries an assumption stated in the open: the runtimes shown apply to a standard conversion through Software Update Manager within a single data centre. Phase durations come from other customers' experience and from measurements on comparable systems. If you replicate between sites, negotiated a maintenance window with the business, or run integrations that will not survive a dozen hours of silence, that number is the starting point for a plan, not the plan. There are two ways to shorten it: the downtime-optimized conversion option, and archiving and housekeeping done before the programme rather than during it.
**Data quality outside finance.** The report checks the general ledger, asset accounting and the material ledger, sorting inconsistencies into categories that run from automated correction, through manual correction and contact SAP, to a system-specific fix. It also checks that customers, vendors and contact persons are synchronised with the Business Partner record, because the conversion will not proceed without it. And that is where data ends. Duplicates in material master data, inconsistent numbering, three versions of the same trading partner across three company codes - none of that is counted here, and that is exactly the material that breaks user acceptance testing.
## How to read the report in a week
Sequence matters, because the document is organised by topic and a programme needs it organised by decision.
**Day one: blockers.** Incompatible and unknown add-ons, active business functions, items flagged for expert assessment. This produces the list of questions that go outside the company - to partner vendors and to SAP. Answers take weeks, so this has to go first.
**Days two and three: custom code.** Custom code findings only mean something once you know which of that code is actually used. The scope information, meaning the split between in-scope and out-of-scope objects, appears **only if** you ran the SAP Fiori Custom Code Migration app. Without it you get findings with no weight, and the difference can be that half the objects have not been touched in years and belong in a deletion transport rather than in a rewrite. While you are there, check how many findings carry a quick fix, because that genuinely moves the estimate. We normally combine this step with a vulnerability review of custom code through [SAP Code Vulnerability Analyzer](/en/offer/sap-security/sap-code-vulnerability/), so that nobody walks the same code twice.
**Day four: data.** Financial inconsistencies by category, the state of the Business Partner conversion, and the archiving potential from the sizing tab. This is where you decide whether the clean-up happens before the conversion, or whether you agree to move the mess onto the new platform and pay for it in memory.
**Day five: integration and downtime.** The interface inventory - IDocs, RFCs and BAPIs, web services, OData, SAP BW extractors, file interfaces, SLT configurations - set against the list of systems whose owners sit outside IT. Then the downtime calculator, checked against the window the business will actually agree to.
With that material in hand the steering committee stops discussing a report and starts discussing scope, dates and money. The next step, how to structure the conversion programme itself, is covered in [how to prepare for an SAP ERP to S/4HANA conversion](/en/news/blog/prepare-sap-s4hana-conversion-rise/), and the testing layer in our article on [SAP testing during conversion and before go-live](/en/news/blog/sap-s4hana-testing-conversion-performance-uipath-test-cloud/).
## The date nobody is going to move
Mainstream maintenance for SAP Business Suite 7 ends on 31 December 2027, and extended maintenance runs to the end of 2030 at an additional two percentage points on the maintenance base. A company that holds an SAP Readiness Check report today and has not settled its blockers has a little over a year for decisions that depend on conversations with add-on vendors and with SAP. That is enough time, provided the report gets worked through now rather than once the programme has a budget and a go-live date.
## How we work at SNOK
We run readiness assessments on your report, not instead of it. We start the collectors where they have not been started, walk item by item through blockers, custom code and data, add the layer the report does not have - authorisations, exposure and the cost of the target model - and come out with a list of decisions for the committee instead of a document to read. The scope is described on our [SAP S/4HANA conversion](/en/offer/sap-security/s4hana-conversion/) page.
If you already hold an SAP Readiness Check result and are not sure what to do with it, [get in touch](/en/contact/). We will walk it through with your Basis team and with whoever owns the programme budget, because those are two different conversations and both need to happen.
---
### Sources
- SAP, *SAP Readiness Check - Key Feature Overview*, SAP Readiness Check Team, April 2026, public document - [help.sap.com](https://help.sap.com/doc/bb0e7ba5158c424ab7ce010228bf1de1/latest/en-US/Key%20Feature%20Overview%20SAP%20Readiness%20Check.pdf) (accessed 22 September 2026)
- SAP Note 2913617, *SAP Readiness Check for SAP S/4HANA* - the central note for the scenario, available after sign-in at [me.sap.com](https://me.sap.com/notes/2913617)
- SAP Note 3344480, *SAP Readiness Check Deployment Options* - available after sign-in at [me.sap.com](https://me.sap.com/notes/3344480)
- SAP, *Maintenance strategy - SAP S/4HANA and SAP Business Suite 7* - [support.sap.com](https://support.sap.com/en/release-upgrade-maintenance/maintenance-information/maintenance-strategy/s4hana-business-suite7.html) (accessed 22 September 2026)
The scope described here follows SAP documentation dated April 2026. SAP extends SAP Readiness Check release by release, so check the current list of analyses in note 2913617 before you base a decision on this article.
---
### SAPMAP - an attacker just got the map of your SAP
URL: https://snok.ai/en/news/blog/sapmap-bloodhound-for-sap/ | Date: 2026-09-22 | Series: Safe Tuesday
When a security team looks at an SAP landscape, it sees a list of systems. **SAPMAP** looks at the same thing and sees a route. This publicly available, open-source tool, released under a GPL licence, does for SAP exactly what its authors describe in their own words - "like BloodHound for Active Directory, but for SAP": it does not enumerate individual vulnerabilities, it draws the path - from one exposed system, through trust connections, to the place where your money sits.
**SecurityBridge**, a partner of SNOK, attributes the tool to its Director of Security Research, Joris van de Vis. The code is now open and available to anyone. That shifts not so much the technique as the symmetry: the map that until now was drawn by an expert inside an authorised test is now also held by someone who has no authorisation at all.
**In short:**
**1/** SAPMAP discovers SAP systems on the network, maps RFC connections (the technical channels SAP systems use to talk to one another and pass trust between them) and trust relationships, then renders an interactive graph - from initial entry to full control of a business process,
**2/** the tool ships real, working exploits for known SAP vulnerabilities, including CVE-2025-31324, and covers both on-premises systems and SAP BTP,
**3/** it models business-impact scenarios - from a customer-data breach, through payroll, to the supply chain - showing not "which system fell", but "what you actually lose",
**4/** access is open, but use is permitted only with the system owner's written consent - outside an authorised test it is illegal.
## What BloodHound is, and why the comparison matters
A short explanation, because not everyone works in cybersecurity day to day. BloodHound has been a staple of offensive-security work for years. On a Windows network built on Active Directory, it shows the shortest road from an ordinary employee account to the account that administers the whole domain - not as a list of errors, but as a graph of connections. It changed how companies look at their own network: they stopped asking "which account has too many rights" and started asking "which way does someone travel from any employee to full control". SAPMAP brings exactly that idea into the world of SAP.
## Why this is a BloodHound moment, not another scanner
SAP security scanners have existed for years and do something valuable: they tell you that system X has an open gateway and that role Y is over-privileged. They answer the question "what is wrong". They do not answer the question the attacker asks: "which way do I get from here to the target".
An SAP landscape is not a set of separate systems, it is a web of trust. RFC connections, high-privilege technical accounts, integrations between production and development, bridges to the cloud - each is an edge in a graph. The attacker does not need to break in everywhere. They need one entry point and a road that leads from it. SAPMAP draws that road, and its business scenarios show what waits at the end of it. Not "the production system was compromised", but "the payment to the supplier landed in a different account".
That is the difference between a report the board files away and a report the board reads to the end.
We recently wrote that [an AI agent can stand on both sides of an attack](/en/news/blog/jadepuffer-agentic-ransomware-sap-cve/) and that [the most dangerous thing is often the blind spot no one monitors](/en/news/blog/sap-data-breach-siem-blind-spot/). SAPMAP is of the same order: it does not add a new vulnerability, it makes visible a road that was always there.
## What it means for defence
There is a simple rule we repeat to clients: control is not measured by how hard the attacker's tools are to obtain. It is measured by whether you walked the same path first. Since the map is public, the only sensible response is to move from "which systems have flaws" to "where does the shortest road to our money run - and do we see it when someone walks it".
At SNOK we do this as an **authorised SAP attack-path assessment**, tying together three layers.
**Path mapping.** We run the same class of tools the attacker now holds inside a controlled lab, against your landscape, under authorised-test conditions. The output is not a list of vulnerabilities, it is a graph: from where, along which edges, to where, and what sits at the end.
**Detection.** SAPMAP visualises the path, and [SecurityBridge](/en/news/blog/trustbroker-5-1-sso-mfa-sap-without-active-directory/) - the platform we work with - sees that path in real time and raises the alarm. A map without a sensor tells you where the risk is. A sensor without a map tells you something is happening but not where it leads. Only together do they produce a picture you can defend in front of an auditor.
**Red teaming with local AI models.** We run the offensive phase on workstations with unrestricted, local AI models in an isolated environment. This has two consequences that are non-negotiable in this kind of work. First, data from your SAP never leaves the lab - it goes to no external API, because the model runs on site. Second, commercial models refuse to assist with the analysis of working exploits, and exploit analysis is the core of red-team work; a local model without those restrictions lets that work happen without anything leaving the premises. All of it runs under a confidentiality agreement and within our ISO 27001 information-security management system.
## What exactly we do for SAP security
The attack-path assessment is one piece. We build SAP security around two hands that have to work together: an offensive hand that finds the road, and a defensive hand that closes it and watches it.
On the offensive side:
**1/** attack-path assessment - mapping escalation paths across the whole SAP landscape, from an exposed system to a business process,
**2/** [SAP penetration testing](/en/offer/sap-security/sap-penetration-testing/) - testing systems, RFC interfaces, gateways and integrations, ending in proof of what is possible, not just a list of vulnerabilities,
**3/** red teaming - simulating a real attacker on your landscape, with the offensive phase on local AI models whose data never leaves the lab.
On the defensive side:
**4/** configuration and role hardening - closing what the assessment exposed: gateways, technical accounts, authorisations, trust boundaries between systems,
**5/** [monitoring and detection with SecurityBridge](/en/offer/sap-security/securitybridge/) - continuous real-time oversight of what happens inside SAP, with alerts on movement along an attack path,
**6/** [patch management and SAP Security Patch Day](/en/offer/sap-security/sap-security-patch-day/) - from assessing new notes to deploying them, keeping the window between publication and fix as short as possible,
**7/** [secure conversion to SAP S/4HANA and RISE](/en/offer/sap-security/s4hana-conversion/) - guarding the attack surface during migration, when the landscape is most exposed,
**8/** [audit and compliance](/en/offer/sap-security/nis2-dora-audit/) - preparing for NIS2, DORA and the ISO 27001 standard, with evidence produced before the auditor asks, not after.
## One question for this week
Not "do we have flaws in SAP", because you do, everyone does. The question is: if someone downloaded the public map today and pointed to the shortest road from your most exposed system to payroll - could you draw that same road first, and see it when someone walks it? If the answer is not a firm yes, that is exactly the conversation worth having, before someone else has it for you.
[Write to us](/en/contact/) - we will show you what an attack-path assessment looks like on a real SAP landscape.
---
## Sources
- SAPMAP, repository [SecuritySilverbacks/SAPMAP](https://github.com/SecuritySilverbacks/SAPMAP), GPL-3.0 licence (accessed 21 Sep 2026).
- SecurityBridge, SAPMAP press materials and industry coverage (securitybrief.com.au, itbrief), July 2026.
---
### UiPath is a Leader in the Gartner Magic Quadrant for BOAT - a new category with a high bar
URL: https://snok.ai/en/news/blog/uipath-leader-gartner-magic-quadrant-boat/ | Date: 2026-09-20 | Series: Announcements
There is a standard way to read an analyst report: find the top right corner, note who is in it, close the file. The **Gartner Magic Quadrant for Business Orchestration and Automation Technologies**, published on **14 September 2026**, rewards staying longer, because the interesting part is the category itself. Gartner has put a name to the layer that holds AI agents, robots, systems and people together in one governed run, and has measured vendors against exactly that yardstick.
The numbers are simple. Gartner assessed **twenty vendors**. Four sit in the Leaders quadrant: **Pega, Appian, UiPath and ServiceNow**. The authors are Saikat Ray, Arthur Villa, Sachin Joshi, Adam Briggs, Tushar Srivastava and Mike Warren.
**In short:**
**1/** BOAT names a whole category rather than renaming RPA - Gartner requires native orchestration of AI agents, governance over them and multiagent coordination,
**2/** the entry bar is high on the commercial side too: hundreds of paying customers, at least twenty implementation partners, and presence across several industries and regions,
**3/** Gartner credits the UiPath Platform with durable process execution in **UiPath Maestro** - process state survives infrastructure failure, and a running process can be paused, rewound, replayed and migrated,
**4/** the report states the market direction plainly: by 2030, **70% of enterprises** are expected to run on a consolidated platform orchestrating processes, agents, bots, APIs and people.
*Figure 1 from the report: Gartner, Magic Quadrant for Business Orchestration and Automation Technologies, 14 September 2026. Reproduced as published, unmodified.*
---
## What BOAT is, and why the category exists
The acronym stands for Business Orchestration and Automation Technologies. Gartner describes the category as a consolidated platform that orchestrates and automates disparate business processes and tasks, with varying degrees of autonomy and complexity, across enterprise systems. Two words carry the weight: consolidated and disparate. Task automation has spread across a dozen tools in most organisations, and BOAT is the answer to the question of who runs all of it.
The entry bar is strict. A platform must provide **native AI agent orchestration, governance, life cycle management and multiagent coordination**. It must support agent interoperability through open protocols including Model Context Protocol and Agent2Agent. It must run long-running, stateful process orchestration, connect over APIs and events, emulate human work in the user interface and offer platform-wide governance. That list filters out single-task tooling.
On top of the feature bar sits hard commercial arithmetic. A vendor must show at least **300 paying customers** of the assessed product, or 10,000 customer logos in total, or **45% year-over-year revenue growth** in the BOAT area. It must also show **at least twenty implementation partners**, plus adoption across two industries and two major regions. That last condition says more about the market than it looks: Gartner treats partner availability as part of the product, because a platform of this class arrives together with a team that knows it.
The report states the scale of the shift plainly. Gartner's strategic planning assumption is that **by 2030, 70% of enterprises** will move to a consolidated automation platform orchestrating business processes, AI agents, bots, APIs and human actions, up from **10% today**. The BOAT market itself is estimated to exceed **USD 34 billion by 2030**. This is not a niche, it is the direction enterprise automation is taking.
## What Gartner credits UiPath with
The assessed platform is the **UiPath Platform**, and three themes run through the strengths.
**Innovation.** Gartner notes that UiPath expanded beyond RPA into document processing, process intelligence and testing, and is now extending that track record into orchestration. For a company that already runs robots the practical consequence is straightforward: new capability is added on top of the existing investment. A working robot becomes a step inside a larger orchestrated process.
**Ecosystem.** A large enterprise customer base, implementation partners, technology alliances and trained practitioners on the market. It reads as a dull argument right up to the week you need a second consultant on a project within a fortnight. Then it becomes the most important one.
**Durable process execution.** This is the most concrete part of the write-up and it concerns **UiPath Maestro**. The engine persists the state of a long-running process, guarantees that each step executes once, and can pause, rewind, replay and migrate a process **while it is running**. In practice, a process lasting weeks, months or years survives external infrastructure failure, version changes and changes to the workflow itself, without losing state and without repeating completed work. Anyone who has run a claims case or a customer onboarding in a tool that restarted from zero knows what that single property is worth. We wrote about the control layer over that kind of process in our piece on [human-in-the-loop gates in UiPath Maestro](/en/news/blog/hitl-gates-uipath-maestro-ai-trust-layer/).
Two further elements appear in Gartner's description of the platform: **UiPath Autopilot** for AI-assisted development, and the **UiPath AI Trust Layer** as a secure path to model endpoints.
## What this position means for your automation programme
Gartner lists the use cases the BOAT category was defined around, and the list reads like the queue sitting in most large organisations.
**Case management with knowledge agents.** A claim, a credit application, a service case - work that has its own state, its own lifetime and a dozen possible paths. The agent prepares and suggests, a person approves, the platform makes sure nothing is lost along the way. We deliver this as [case management](/en/offer/ai-automation/case-management/).
**Long-running flows across multiple systems.** An order that travels through ERP, the warehouse, the carrier and finance, and has to survive every one of those boundaries. This is exactly the scenario where durable execution in UiPath Maestro stops being a datasheet line and starts showing up in the numbers.
**Coordinating agents from several vendors under one governance layer.** An agent in one tool, an agent in another, a robot in a third. A BOAT layer gives them a shared registry, shared entitlements and a shared audit trail instead of several independent islands.
**Universal orchestration.** Agents, people, robots and tools in one run, with one place that shows what is happening. That is what "consolidated" means in Gartner's definition.
One more thread matters in our market. Most of the processes described here touch SAP at some point - a purchase order, an invoice, supplier data, a service request. **SAP** was assessed in the same Gartner report, which means both platforms we work with daily were measured against one yardstick. That is a comfortable position for you: we can show what UiPath brings to a specific process and what the SAP automation layer brings with **SAP Build Process Automation** and **SAP Joule Studio**, then match the choice to the business need and to what already sits in your landscape, rather than to whose partner we are. On a project it means our SAP team joins the automation team at the table, not after it.
## How we start at SNOK
We are a **UiPath Platinum Partner** and a **UiPath Agentic Automation Fast Track Partner** - the scope is on our [UiPath partnership page](/en/uipath-snok/), and all our authorisations sit on the [partnerships page](/en/partnerships/). In practice a partner tier means a support path to the vendor, licences bought together with the implementation, and consultants whose certifications are renewed every year.
An orchestration programme always starts the same way, in three steps.
**Pick the process that genuinely pays for the change.** Candidates come from [process mining](/en/offer/ai-automation/process-mining/) rather than from the process owner's conviction. Execution data shows where the volume, the waiting time and the repetitive work actually sit.
**Build the first end-to-end run.** Execution and integrations sit within [business process automation](/en/offer/ai-automation/business-process-automation/), long-running orchestration runs on [UiPath Maestro](/en/offer/ai-automation/uipath-maestro/), and inbound paperwork is handled by [document understanding](/en/offer/ai-automation/document-understanding/).
**Protect what already works.** Regression after every change is covered by [agentic testing](/en/offer/ai-automation/agentic-testing/), so each new stretch of the process is added without putting the previous ones at risk.
The Magic Quadrant recognition belongs to UiPath. For you it is a signal that the category has been named and measured, and that the platform we work on holds a strong position in it. The shortest way to test that in your own environment is one process and one end-to-end run. If you already have a candidate in mind, [book a conversation about picking the first process](/en/contact/) - you will leave it with a set of selection criteria and a clear idea of what to look for in your execution data.
---
## Sources
- Gartner, *Magic Quadrant for Business Orchestration and Automation Technologies*, 14 September 2026, ID G00844491, by Saikat Ray, Arthur Villa, Sachin Joshi, Adam Briggs, Tushar Srivastava and Mike Warren.
- The licensed reprint is made available by UiPath: [report page](https://www.uipath.com/resources/automation-analyst-reports/gartner-magic-quadrant-business-orchestration-automation-technologies).
- UiPath announcement of the recognition, 18 September 2026.
GARTNER is a registered trademark and service mark, and MAGIC QUADRANT is a registered trademark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.
---
### Weekly review W38: not the tool, the route
URL: https://snok.ai/en/news/blog/weekly-review-w38-not-the-tool-the-route/ | Date: 2026-09-18 | Series: Other
**Ten items from the week of 11-17 September 2026, with a note on what each one changes in your systems.**
The SAP Security Patch Day of 8 September carried a note rated 9.8. Four days later a public
description of the mechanism existed, and that same evening there was a working proof in a lab.
This is not a story about one vulnerability. It is the first of ten items in which the decision was
never "which tool to buy".
Every time it was a different question: which route to take. Patch the kernel or tighten an
internal communication parameter. Monitor one route to bank details or all eight. Give the agent a
document in an index or a live record in the system. Model the process in notation, in code or on a
canvas. Put the clause on your side of the contract or leave it to the provider. These decisions
are made once, usually early, and usually by someone who does not know they are deciding.
Reversing them later is not reconfiguration, it is a rewrite.
## 1. Ninety-six hours from the note to working code
The SAP Security Patch Day of 8 September 2026 brought note 3759472, rated 9.8, HotNews category,
no workaround. The flaw sits in the SAP Message Server: nothing verifies authenticity when a
gateway entry is written, so after an ordinary protocol handshake an unauthenticated client
supplies its own host, port and process identifier. The kernel accepts them and broadcasts the
forged gateway identity to every application server in the landscape.
The mechanism is called trust-list pollution and it has two consequences. The first is an
adversary in the middle of internal traffic, which is where single sign-on tickets and internal
remote calls travel. The second is remote code execution without an account in the system.
What is interesting is not the flaw but the clock. 8 September, the note. The morning of
12 September, a public analysis of the kernel diff. The evening of 12 September, a working proof in
the SecurityBridge Research Lab - with an AI coding assistant helping to reconstruct the data
format, which the researchers state openly. By the researchers' own account the actual work took two days; two of the four fell on
a holiday.
Address-based controls do not gate this command family. Enforcing encrypted internal communication
between instances closes the route more effectively, but it is an additional layer - switching the
parameter off reopens the surface the same day. The durable fix is a kernel replacement.
**What follows:** if your SAP patching process plans quarterly windows, it is planning against an
adversary who no longer exists. The 9.x kernel line is today's S/4HANA mainstream, so most
landscapes are in scope; the 7.x and 8.x kernels do not carry this command family.
*Sources: SecurityBridge Research Lab, "CVE-2026-58240: From Patch Day to PoC in 96 Hours";
Onapsis, an analysis of the same vulnerability under the name S4GET; SAP Security Note 3759472.
Retrieved 17 September 2026. Status: mechanism, rating and note number confirmed in two independent
sources.*
## 2. Eight routes to the same field
A vendor of SAP protection software demonstrated eight ways to change bank details in the system.
Alternative transactions, transport mechanisms, custom development, interfaces and background
processes. None of the eight raised an alert, because monitoring covered the intended route, the
standard transaction.
The demonstration does not prove that SAP is badly designed - most alternative routes exist for
sound operational reasons. It proves something else: a control built around one route does not see
the others, and the same logic covers payment terms,
credit limits, business partner master data, prices and discounts.
A second argument from the same source adds time. Network security learned this lesson over twenty
years: detection systems compared traffic against signatures and raised an alarm, but by the time
an analyst read it the packet had arrived. Only moving that logic into the traffic path allowed the
packet to be dropped. SAP security today sits at the detection stage: the tool reports a suspicious
call and hands the case to a human, and the gap between the two is all an attacker needs.
**What follows:** a role list answers who may come through the door. It does not answer who came
through the window, or how quickly they will be removed. That is the difference between a
conversation about compliance and one about operational capability.
*Sources: SecurityBridge, "Breaking the Rules: Why Standard SAP Controls Are Not Enough" (Joris Van
De Vis); the webinar "Break the rules: 8 ways to update Bank details in SAP"; material on runtime
application self-protection. Status: vendor material, we did not replay the recordings. The figure
of eight describes one demonstration environment, not a property of SAP.*
## 3. Seventy-eight instruction files and six thousand stars
A package on GitHub turns a coding assistant into an offensive working tool. We counted the
repository ourselves: 78 instruction files across 23 categories, loaded on demand, so unused ones
cost the model no context. The repository was created in early March and today carries 6,011 stars.
The mechanism matters, not this particular package. We are not talking about an exploit that has to
be compiled and run. We are talking about text files someone drops into an assistant's directory,
equipping it with a methodology. Your attack surface grows not by a tool but by a ready-made way of
working - and that arrives with a single directory copy.
The operational conclusion is short: someone else's agent instruction file is untrusted code, not
documentation. Treating it as documentation is the same mistake as running a script from the
internet without reading it. **SNOK's agent skill scanning** checks such packages before
installation for prompt injection, data exfiltration, privilege escalation and memory poisoning.
**What follows:** if anyone in your organisation extends assistants with third-party instruction
files, you need a gate for it. Software procurement policy does not cover this case, because
formally nothing was bought.
*Source: the SnailSploit/Claude-Red repository on GitHub, metadata and tree structure retrieved
17 September 2026. Status: confirmed by our own measurement - the file count, category count, star
count and dates come from the GitHub programming interface, not from a secondhand account.*
## 4. Almost three thousand ready commands in a distribution package
A classic launcher for penetration testing commands has been rewritten in Go and packaged into the
official Kali Linux repositories. The project description lists 247 tools, 2,926 commands and more
than two hundred cheat sheets. Installation is one command, then you search the library and inject
a ready command into the terminal.
This is not a new attack engine. It is a productivity layer over tools that have existed for years -
and that is exactly why it matters. Set beside the previous item, it shows the barrier to entry on
the offensive side dropping through two independent channels at once: ready commands in a system
package and a ready methodology for an assistant.
**What follows:** your defence team is planning against an opponent who no longer has to remember
syntax or the order of steps. When assessing security posture, the useful question is not whether
someone can use a tool, but how long it would take you to notice that they did.
*Source: the halilkirazkaya/arsenal-ng repository on GitHub, metadata retrieved 17 September 2026 -
Go, MIT licence, 702 stars, last change 11 August 2026. Status: metadata confirmed by our own
measurement; the figures of 247 tools and 2,926 commands come from the project description, and we
did not count the library contents.*
## 5. Grounding on documents answers a different question than grounding on data
UiPath has described a layer through which an agent reaches live records in a customer's systems instead
of working on vectors built from documents. **UiPath Data Fabric** models entities once and makes
them available to every agent while preserving permissions.
The four requirements the material sets for agent-ready data make a good checklist regardless of
platform. Access to the current state, not to last night's extract. Structure that allows filtering
and joining. Entity models built once for every team, rather than rebuilt in each project.
Permissions and lineage by default, because otherwise every new agent is a new compliance surface.
The difference shows best in two questions. Similarity search will answer what the returns policy
says, because the answer is a fragment of text. It will not answer which tickets in a given region
are overdue, because that is a query with a filter and a join, and the answer is a number computed
from rows.
**What follows:** an agent project that starts with document vectorisation ends with an assistant
that is eloquent and inoperative. If the questions it must handle concern state rather than text,
the data layer is the first architectural decision, not the last.
*Source: UiPath material on the Data Fabric layer, September 2026. Status: vendor material without
independent confirmation; the range of supported systems is not listed in it, so we name none.*
## 6. Three orchestration patterns on one engine
The shortest statement of the boundary between two layers of the UiPath platform runs like this:
Orchestrator manages the workers, and **UiPath Maestro** runs the process those workers are part
of. Underneath sits a durable execution engine, so a process paused on an approval resumes exactly
where it stopped and survives the failure of the system it depends on. You write neither a state
machine nor your own retry layer.
Three patterns sit on that same engine, and this is where the decision belongs. You choose the
structural pattern in process modelling notation when the path is known in advance, decisions are
rule-based and auditability is critical - invoice handling, employee onboarding, regulatory
reporting. You choose the code-first pattern when developers build the solution and the logic reads
better in a repository than on a graphical canvas; the project serialises to a text format, so
change review goes through version control like any other code. You choose the adaptive pattern
when the next step cannot be predicted at design time, exceptions are the norm and a case runs for
weeks - claims handling, customer verification, benefits assessment.
**What follows:** the pattern follows from the process, not from the consultant's preference. Asked
at the start, the question costs one conversation; skipped, it returns as a rewrite halfway through
the project.
*Sources: UiPath product material on Maestro and on the developer canvas, an article organising the
three layers, community repositories with examples. Status: capabilities match vendor material; the
developer canvas is in public preview and the source gives no general availability date, so we
build no schedule on it.*
## 7. Three routes to building an agent and the cost of picking the wrong one
The same platform offers three equal routes to building an agent: a Python software development
kit, agents coded through the command line, and a browser canvas. The vendor material describes all
three as first-class and does not say which to open first - and the community forum is full of
threads about exactly that.
The decision is not a matter of taste. It is about how much control the team takes and how much of
the work it accepts in return. The development kit gives the most freedom and the deepest
integration with the language ecosystem, and expects the most work in return. The browser canvas
gives the lowest barrier and the fastest start, paying with the least say over detail. The command
line route keeps the code under version control, which fits the engineering practices your team
most likely already has.
**What follows:** discussing the route at the start of a project costs an hour. Skipping it costs a
rebuild, because switching route means building the solution again.
*Source: UiPath material on the three routes to building an agent, September 2026. Status: vendor
material.*
## 8. Quadrant leader, a deployment with numbers and the argument about the end of robotic automation
Three materials from a single week address the three objections that always arrive in the same
order in a conversation about agents.
Is the vendor serious. UiPath was positioned as a leader in the Gartner quadrant for intelligent
document processing solutions for the second consecutive year; the report is dated 8 September 2026.
Has anyone actually run this. A case study of the Philippine telecommunications operator PLDT
describes three agents in production, built so that software robots act as the agent's tools. The
knowledge assistant answers in one to three seconds instead of one to five days and removes 25,000
to 30,000 manual hours a year, which the material converts into the capacity of roughly twelve
full-time roles. The risk assessment agent, deployed in February 2026, shortens tasks that took two
to ten days into a range of five minutes to one day.
Are we buying technology on its way out. Here the answer is the most interesting one, and it does
not come from the vendor. Producing an answer is not the same as closing a process. A model will
read an invoice, extract the data and flag a discrepancy. Closing the process requires validation
against rules, approvals tied to financial thresholds, updates across several systems, an audit
trail and deadline tracking. These are execution problems, not intelligence problems - and robotic
process automation is not so much disappearing as ceasing to be an imitation of a human at a screen
and becoming the execution layer beneath a decision taken higher up.
**What follows:** the measure of success changes too. The number of robots deployed and hours saved
lose their meaning in favour of whether the work moves faster without loss of quality, and whether
recommendations can be carried out consistently under supervision.
*Sources: the UiPath investor announcement on the quadrant position (Gartner report dated
8 September 2026); the PLDT case study published by UiPath and reported by three independent trade
publications between 10 and 15 September 2026; a Forbes Technology Council article on the boundary
between intelligence and execution. Status: the position and report date are confirmed; the
deployment figures come from the vendor's case study and are not our measurement. Gartner does
not endorse vendors or products, and its publications are opinions of a research organisation, not
statements of fact.*
## 9. Twenty-four clauses and the question of who carries the risk
A practising lawyer has assembled a catalogue of contract provisions for artificial intelligence
systems in two roles: eighteen protecting the party deploying the system and six protecting the
provider. The value of the compilation is that both lists stand side by side, so you can see where
the interests part ways.
On the deploying side the same points recur: no training of the model on data entered by users,
notification of changes to the system with a right to object, no processing outside the European
Economic Area with a list of locations, genuine human oversight functions including immediate
shutdown of the system, and migration support after the contract ends. On the provider's side - the
right to use data for training and development, changes of subcontractors and locations without
consent, and a closed description of functions beyond which the provider is not liable.
Three remarks from the discussion under that material weigh more than parts of the list itself.
Training is not the same as retention - the model does not learn in real time, and the risk sits in
what the provider collects and for how long. Change notification must cover a swap of the
underlying model and of request routing, because the same case can receive a different answer than
it did a week earlier, with the contract unchanged and the interface unchanged. Contractual
liability does not replace confirmation that the system may be used at the moment of use.
The timeline is also worth setting straight, because an incorrect version circulates. The AI Act
applies in stages, and an amending package moved some of them. Obligations for high-risk systems
under Annex III apply from 2 December 2027, and for systems under Annex I from 2 August 2028. The
claim that the high-risk rules have applied since August 2026 is false.
**What follows:** the compliance conversation moves from the slide deck to the contract annex. If
you are buying an AI system, the question is not "is the provider compliant" but "which of these
twenty-four provisions made it into our copy".
*Sources: a practitioner's series of posts on contract clauses, August and September 2026; the AI
Act, article 113 as amended. Status: the application dates are confirmed; the catalogue of clauses
is a practitioner's opinion, not a source of law.*
**This is not legal advice - review by a lawyer is required before applying any of it.**
## 10. A hundred and eighty billion parameters at a desk, and three different licences
A dense model of 27 billion parameters fits in roughly 17 gigabytes after four-bit quantisation and
carries a native context of 262,000 tokens under Apache 2.0. That alone changes the arithmetic for
an organisation that does not want to send data outside. A community-published recipe goes further:
it serves a sparse variant of 180 billion parameters on a single desk-class device at around 60
tokens per second on one stream.
The second point is less striking and more important. Three variants of the same family carry three
different licensing regimes. The base model sits on an open licence with no thresholds. The
short-reasoning variant is free up to an organisational revenue threshold, above which a commercial
licence is required. The sparse variant permits commercial use but excludes serving the model as a
service. Three different answers to the same question, within one model family.
**What follows:** the data sovereignty conversation stops being a choice between quality and
control and becomes an arithmetic exercise - where exactly the line falls for the size of your
workload. The licence is checked before the quote, not after the deployment.
*Sources: the Qwen3.8-27B model card on Hugging Face; the short-reasoning variant's model card with
the vendor's own measurement table; a community recipe for serving the sparse variant, version
dated 14 September 2026. Status: the base model's parameters and licence are confirmed at source;
the speeds come from one author's recipe description and are not our measurement.*
## One sentence for this week
The ten decisions in this week's issue share one trait: none of them has a line of its own in the
budget or in the risk register. The route is chosen in a technical conversation, in a comment on
a contract, or by a tool's default setting - and its price appears only at the first audit, the
first incident, or the first policy change that cannot be made without rebuilding the solution.
Hence one practical question for your next review: which of these decisions have already been made
here, and who made them. If nobody can name that person, the decision still exists - the default
setting made it.
SNOK Weekly Review · W38 · 11-17 September 2026
The whole edition in one file
PDF, thirteen pages, about 1.5 MB - no form, no details to hand over. A version to pass around the team or read on a phone.
If any of these items concerns you directly - [SAP security](/en/offer/sap-security/), or [orchestration and automation with agents](/en/offer/ai-automation/) - [let's talk](/en/contact/).
---
### One supplier, five names - why procurement cannot see its own spend
URL: https://snok.ai/en/news/blog/one-supplier-five-names-supplier-master-data/ | Date: 2026-09-17 | Series: Tech Thursday
The week before a major negotiation, the same work starts again. Someone pulls spend out of the ERP. Someone adds the orders that only ever went through the sourcing platform. Someone remembers that a subsidiary buys from the same supplier separately, on its own contract. Two days later there is a spreadsheet that is, briefly, the only place in the business that knows the truth about that supplier.
Then the spreadsheet stays in an inbox, and in six months it has to be built from scratch.
This is not a story about sloppiness. It is a description of the normal state of an organisation that has grown, acquired, changed systems, and had to keep buying throughout. It is worth naming what the work actually costs, though - because the cost is not the days spent assembling the spreadsheet.
## You negotiate with a record, not with a supplier
Procurement does not sit down with a company. It sits down with whatever the systems know about that company. If the same legal entity exists in five places under five spellings of its name, the organisation is holding five conversations with five mid-sized suppliers instead of one conversation with a large one.
The spend is identical. The negotiating position is not.
*Spread across systems, the spend looks like five unremarkable suppliers. The same total in one place changes the conversation.*
The drift comes from small, entirely reasonable things. The legal form written four different ways. A trading name alongside a registered one. A tax number entered once with separators, once without, once in the notes field. A branch, a head office and a subsidiary as three separate records. The same entity appearing once as a supplier and once as a customer. And a record created late on a Friday because the order was urgent, and searching for the existing one would have taken longer than creating a new one.
Each of those decisions made sense on its own. Only their sum, after fifteen years, produces a database in which nobody can answer the question of how many suppliers the company has.
## What this hides
**The corporate group.** Six entities under one owner appear in the database as six independent suppliers. You are dealing with a group, though, and the group looks at combined turnover. Without ownership links, the organisation does not know it is a strategic customer to that group, and it sits down at the table as six unremarkable ones.
**The category.** The same service lands in three different categories across three systems, because each system has its own taxonomy. Until there is a shared classification, nobody can say what the company spends on a given category. Category strategy is the basic instrument of procurement work - and you cannot build one on a number that does not exist.
**The contract.** A buyer could not find the governing contract, because they searched under a different name. They ordered outside it, in good faith and in line with procedure. The negotiated rate stayed in the document, and the company paid list.
**Money that went out twice.** The same invoice booked against two records of the same counterparty looks like two separate liabilities.
## A record with no owner
Procurement creates the supplier record. Finance changes the bank account number. Accounts payable fills in the gaps when an invoice arrives. IT moves the whole thing during the next system project. Every one of those steps is justified, and yet nobody owns the record as a whole.
In Poland that gap carries a very specific price. The bank account number is a field on the supplier record, and for business-to-business transactions above PLN 15,000 gross, paying into an account outside the register maintained by the Ministry of Finance means the amount cannot be treated as a tax-deductible cost, and it brings joint liability for VAT the supplier has not paid. Notifying the head of the tax office within seven days lifts the sanction - but somebody has to catch the mistake first.
If a supplier has five records across your systems, the account check has to fire five times. One stale record is enough.
Sanctions screening and ultimate beneficial ownership checks work the same way. You cannot screen an entity properly if you cannot count it.
## The year this stops being manageable by hand
Two things change in 2026 at once.
First: there is more work in procurement and fewer resources to do it. The Hackett Group, in its 2026 procurement agenda study, reports an eight per cent increase in workload alongside falling headcount and operating budgets. Work that used to disappear into an analyst's overtime simply will not happen under those conditions. The pre-negotiation spreadsheet will either be worse, or it will not exist.
Second: agents are arriving in procurement. The same Hackett study reports that 76 per cent of organisations see AI-driven improvements of 25 per cent or more in key performance metrics as adoption scales. However those metrics are counted inside any one company, a number like that no longer describes a pilot.
A person will recognise that "ABC Sp. z o.o." and "A.B.C. Polska" are probably the same entity. They will hesitate, check, ask a colleague. An automated process will do the same only if it is given a way to resolve entity identity and a point at which a human approves the decision. Without those two things it will act on whichever record it happens to receive - and it will do so faster than a buyer. Automation built on a database full of duplicates does not fix the drift; it reproduces it at scale.
## Does SAP S/4HANA not solve this
Partly, yes. The data model in SAP S/4HANA has been tidied up: Business Partner replaced separate supplier and customer records, and the built-in duplicate check warns whoever is creating a record that a similar one already exists. That protects you against the next duplicate, and it is worth switching on.
It does not solve two things. Converting to Business Partner carries the existing state into the new model, so duplicates travel across with everything else. And no control inside SAP can see what lives in the sourcing platform, the invoice workflow and the buyers' spreadsheets. SAP Master Data Governance goes further and is sometimes the right answer - we say so openly. It is also sometimes too heavy an answer where a meaningful share of what you know about counterparties lives outside SAP, which [after an acquisition](/en/news/blog/sap-mdg-vs-informatica-mdm-after-acquisitions/) is very nearly always.
## The governing record, concretely
"Golden record" has been circulating in the market for years and has worn thin, so it is worth naming without the jargon.
A governing record is a single supplier record designated as authoritative, assembled from the best data across all systems, in which every field carries where it came from and who last changed it. Source systems carry on unchanged. They gain exactly one thing: the knowledge that they are describing the same entity.
*Field provenance is part of the record, not a separate document. It is what lets you reverse a decision and defend it to an auditor.*
What it is for, counted concretely:
- totalling spend with one entity and across its whole corporate group, which is to say: negotiating,
- checking a bank account number before payment in one place instead of five,
- screening an entity for sanctions, VAT status and ultimate beneficial ownership,
- supply chain reporting, including for sustainability disclosure,
- automation and agentic scenarios, so the process does not have to guess who it is dealing with,
- [conversion to SAP S/4HANA](/en/news/blog/secure-sap-s4hana-conversion-rise-with-sap/), which requires entity identity to be unambiguous,
- audit, because the origin of every field and the history of changes are on record.
And three things a governing record is not. It is not a new ERP. It is not a data warehouse. It is not a one-off clean-up after which everything returns to its starting state within a year.
## A layer above the systems, not instead of them
This is how we do it in [SNOK MDM](/en/products/snok-mdm/): we add a layer that recognises one entity across many records and holds that state over time. Source systems stay where they are and carry on working. Merge proposals come from a matching engine and are approved by a person - a data steward on your side - and every such decision goes into the audit trail.
We start with a [diagnostic workshop](/en/offer/master-data-management/) of roughly two weeks. You come out of it with a map of sources, a report of suspected duplicate pairs with their count, and an assessment of how many of them a rule can settle and how many need a person. That is the first moment at which "how many suppliers do we have" gets a number rather than an estimate.
Then comes a pilot on one domain, four to eight weeks. It ends with a working governing record for that domain, matching rules described in the language of your process, an ownership hierarchy for the entities in scope, and acceptance criteria agreed before the start - on your own data, not on a slide. Fixed fee per phase. The data and the model remain yours.
## Four things we settle before we start
**How much work stays on your side.** In a pilot that is usually one person from procurement as data steward, a few hours a week adjudicating contested pairs, plus access to sources from IT. Without that person the project stops at the first contested pair, whatever the technology.
**What happens to a wrong merge.** A merge is a recorded decision, not an overwrite. Source records stay untouched, and the link can be reversed together with the reasoning, and with who approved it and when. A rule that raises doubt goes into a queue for a person rather than acting automatically.
**What happens to data security.** We work on the scope needed to resolve entity identity, in an environment agreed with you, with an access log. Account numbers and personal data of contacts are treated as production data, including during the diagnostic phase.
**Who maintains the record after the pilot.** Maintenance is part of the solution, not its absence: rules, a queue of cases to adjudicate, and a periodic review. That is the difference between a governing record and a one-off database clean-up, after which the duplicates return with the first urgent Friday afternoon order.
## When this is not worth doing
Honestly, because it does not pay off for every company.
If the entire landscape sits inside one ecosystem and the strategy is to stay there, the answers are worth looking for in that ecosystem's own tooling first. If the supplier base runs to a few hundred entities in one system and one legal entity, discipline in record creation and a quarterly review will do - the project would be a cost without an addressee. If the scale runs to tens of millions of records with a real-time requirement, that is a different class of solution.
## Three questions to start with
You do not need a project to find out whether this problem applies to you.
First: how many active suppliers do you have, and how many entities does that actually represent.
Second: what does the company spend with its largest supplier, counting every legal entity on both sides - and how long does it take to produce that number. The response time says more than the number itself.
Third: who approves a change to a supplier's bank account number, and in how many places does it have to be entered.
If any of those answers requires assembling data by hand from several systems, start with the smallest possible step: take one purchasing category, compare its sources, and count how many records describe the same entity. That is two weeks of work and no decision about replacing a system. Only that number tells you whether it is worth going further.
---
### Secure SAP S/4HANA conversion - what the programme does to your attack surface
URL: https://snok.ai/en/news/blog/secure-sap-s4hana-conversion-rise-with-sap/ | Date: 2026-09-16 | Series: Other
No set of steering committee minutes ever records the line "we hereby approve a two-year expansion of our attack surface". That is nevertheless what those meetings approve. A change freeze on **SAP ECC** for the duration of the programme. Production copies in project systems, because user acceptance testing without real data proves nothing. Emergency authorisations for the system integrator, valid "until cutover". Go-live criteria that contain not a single security condition. Each decision is individually reasonable. Together they open a window that stays open for one to three years, which is how long an **SAP S/4HANA** conversion programme actually runs.
The calendar does not help either. SAP provides mainstream maintenance for SAP Business Suite 7 until **31 December 2027**, with extended maintenance from the start of 2028 to the end of 2030 carrying a premium of **two percentage points** on the maintenance base. Start now and you have a little over a year. A year of runway means cutting scope, and security is the easiest thing to cut, because it blocks nobody.
**In short:**
**1/** freezing functional change in SAP ECC does not freeze risk - SAP Security Patch Day ships monthly regardless of your programme plan,
**2/** under **RISE with SAP** the customer raises the request for a technical Basis security patch and accepts the downtime, and no penetration test runs without SAP's approval - both statements come from SAP's own material, not from a security vendor,
**3/** an **ABAP Test Cockpit** run aimed at conversion does not check code security, because the security checks ship with the separately licensed **SAP Code Vulnerability Analyzer**, and an SAP ERP licence does not carry over to SAP S/4HANA,
**4/** non-production and production systems sit inside the same virtual network under RISE, for reasons SAP states plainly - and your conversion sandbox should know it.
---
## Three sentences that sound sensible and are not true
### "The system is frozen, therefore it is stable"
This is the most common assumption in conversion programmes and the most expensive one. SecurityBridge put it in January 2026 in a single sentence worth pinning to the project room wall: *freezing functional changes does not equal freezing security risks*. You froze business change. You did not freeze the vulnerability disclosure calendar.
Through that period the legacy landscape typically runs without continuous vulnerability assessment, nobody watches custom code, interfaces and RFC connections, and controls fall back to manual work. The "no changes allowed" policy meanwhile creates a sense of safety with nothing behind it. Your change freeze does not bind an attacker, and during that window your systems are more predictable than they have ever been.
### "We are moving to RISE, so SAP owns security"
Under RISE with SAP the responsibility boundary moves. The responsibility itself stays where it was. SAP runs the data centres, the network, the virtual machines, the operating system, the HANA database, backups, round-the-clock monitoring and incident management at the technical layer. What remains yours is application configuration, user identity, roles and access control, the audit log, integrations, custom development and regulatory compliance.
None of that is a surprise; anyone who has worked with public cloud knows the shared responsibility model. The surprises are three details from SAP's own published cybersecurity FAQ for SAP S/4HANA Cloud, Private Edition.
**First.** SAP patches the operating system and the database on its own schedule. For technical Basis security patching the roles change: SAP reviews the available patches and builds tested deployment bundles, but as the material states, the customer contractually initiates the request to deploy them and permits the downtime inside the maintenance window. Nobody applies a Basis patch to your system merely because it was released.
**Second.** Vulnerability and penetration testing is available at the application layer only, and only with SAP's prior approval and authorisation. An independent test before go-live is therefore a scheduled item with weeks of lead time, not something a team squeezes into cutover week.
**Third, and most interesting for architects.** Development, QA and production systems sit inside the same virtual network. SAP gives the reason openly: software logistics, meaning transports and client copies, require it. That is design, not a flaw. It does mean your conversion project system is not an island. It is production's neighbour.
### "The technical conversion passed, so the system is secure"
Conversion testing asks whether the process closes, whether the document posts, whether the report returns the same figures. It does not ask whether the program doing that has an authority check. A green functional test is not evidence about security, and nobody ever claimed it was.
---
## Four things a conversion multiplies
A conversion programme does not invent new classes of vulnerability. It multiplies and legitimises the ones that would otherwise be exceptions requiring sign-off.
**Production copies.** Acceptance testing without production data has no value, so the copies get made - usually several, across several environments, over more than a year. A copy carries more than the personal data your data protection officer sees. It carries RFC destinations, technical accounts and trust relationships. Project systems have looser roles, weaker oversight and rarely make it into monitoring.
The conclusion is worth stating plainly, because these two points are usually discussed separately. A production copy is not only a data protection topic. It is a system that can log in wherever the original could, with the same destinations and the same technical accounts, only with worse roles, no monitoring and an access list nobody outside the project approved. The risk is not that someone exfiltrates data from the sandbox. It is that someone enters through the sandbox and comes out inside a system that posts documents.
**Privileged access with an expiry date nobody entered.** The integrator, their subcontractors, service accounts, emergency authorisations "for the duration of the project". These categories rarely have an owner on the customer side, and even more rarely an expiry recorded in the system rather than in the contract. SecurityBridge lists excessive authorisations among the things organisations carry into the new environment alongside the data, and it is right, because role cleanup during a programme has no milestone anywhere in the plan.
**Custom code.** Covered separately below, because it is the most misunderstood item on this list.
Those four mechanisms do not act evenly. The longest window is the frozen source landscape, and it usually has no owner, because the operations team is waiting for the new system while the project team is looking at the target. The most intense is cutover, where change control runs in emergency mode by definition. The most underrated are the first two weeks after go-live, which we come back to separately below.
**Paths nobody monitors.** Joris van de Vis of SecurityBridge made the point sharply in August 2026: in SAP, several technical routes lead to the same business outcome, and usually only one of them - the standard transaction - is monitored. The side routes are lesser-known transactions, transport mechanisms, custom development, interfaces and background processing. During cutover every one of them runs at full tilt while change control operates in emergency mode. His conclusion is simple and uncomfortable: control the outcome, not just the process.
---
## "We ran ATC" - what that scan actually covered
This sentence is spoken at every conversion programme review, and it almost always means something other than what the listener assumes.
**ABAP Test Cockpit** provides the check infrastructure plus functional correctness and performance checks. Security checks come from **SAP Code Vulnerability Analyzer**, built on the same infrastructure but a separate, separately licensed product. The check variant that runs the analyser alone is SLIN_SEC. The variant your conversion team runs tests S/4HANA readiness and simplification items, because those block go-live. Code security blocks nothing, so it does not join the run by accident.
Three facts from SAP's own material change the conversation inside a programme:
- licensing is per user, capped at one hundred users, and a user is anyone who reads the results of a scan, not only whoever triggers it,
- the analyser **can be activated without a licence** - the system displays a warning, and that is all,
- an **SAP ERP licence does not carry over to SAP S/4HANA**; a new one is required.
That last point is the critical one for a conversion programme, because it hits the organisations that were doing everything right. You scanned code on SAP ECC for years, you have a process, exemptions and history. After conversion you hold the same process and no licence, at precisely the moment your code base changed the most.
Three further limits deserve attention before anyone shows the board a green chart:
**The first run produces thousands of findings.** That is SAP's own description. It is not an argument against scanning; it is an argument for agreeing triage, ownership and closure criteria before the scan runs rather than after.
**Data flow analysis does not cross compilation units.** Scan a report that calls a function module, and a vulnerability inside that module will not be found. You have to scan the module. A green result then describes the scope of the scan, not the state of the system.
**A finding does not block a release.** In the standard configuration, priority three findings do not stop a transport, and a product can be released with findings open. The tool will not make the risk decision for you. It only makes the decision a conscious one.
---
## Cutover, and the two weeks nobody watches
Cutover is the one moment where all four mechanisms run at once. Inside a day or two the full set of transports ships, integrations are switched, technical accounts get new passwords or keep the old ones, and change control operates in a mode the team itself calls emergency. That is not negligence; it is what switching over a business-critical system looks like. The trouble starts with the sentence every organisation says at that point: "we are not rolling back, a rollback costs a week of downtime."
In normal operations a transport with a missing authority check stops at a gate. During cutover it goes through, because the criterion is "does it activate", not "is it safe". The difference is not in the tooling. It is that for forty-eight hours the cost of stopping anything exceeds the cost of letting it pass.
Then comes the part that is even less documented. For the first two weeks after go-live the whole team watches performance, period close and whether documents post. Security monitoring of the new system is usually not fully live yet, because alerting rules get tuned "once things settle". Which means the hottest period of the entire programme is also the only one **you have no data from**. If something happened during cutover, you will learn about it from a source other than your own audit log.
---
## What belongs in your gate criteria
The cheapest change in the whole programme costs one sentence in a document that already exists. Phase gate criteria and go-live acceptance criteria are written down, agreed and signed. Four items simply need to appear there instead of remaining somebody's private worry.
**A baseline measured before the freeze.** Configuration, authorisations and code in SAP ECC described in numbers on the day the change freeze starts. Without that snapshot you cannot prove a year later what you carried over and what you did not, and an auditor will ask.
**A blocking threshold for code findings.** Not "we will scan the code", but: which priority stops a transport, who may grant an exemption and for how long. The tool will not stop a transport on your behalf.
**Retirement of project access as a milestone.** Emergency authorisations, integrator accounts and service accounts with an expiry recorded in the system rather than in the contract, and a post-cutover task to verify it.
**Monitoring live before go-live, not after.** Security audit log, event collection and alerting rules switched on and tested in the target system before the cutover weekend. If the first week of production is also the first week of monitoring, you have no data from the hottest period of the entire programme.
Above those four sits the ownership question. A conversion programme has a manager, an architect, process owners and an implementation partner. It rarely has anyone with a **written right to stop go-live** on security grounds. Where that person does not exist, the risk decision is being made by the schedule.
---
## Where SecurityBridge fits
Stated plainly: SNOK is a SecurityBridge partner and we deploy the platform for clients. So we will be precise rather than promotional.
SecurityBridge does not replace SAP Code Vulnerability Analyzer and does not resolve licensing on SAP's side. What it does cover is exactly the layer that remains yours under RISE with SAP: continuous vulnerability and configuration assessment, monitoring of user activity and interface traffic, custom code analysis and compliance framework alignment. Inside a conversion programme there are four sensible positions: a baseline of SAP ECC **before** the freeze, oversight of the frozen landscape **during** the programme, code and transport control **through** the project, and a comparison of target state against baseline **before** go-live. The fifth position starts the day after go-live and lasts as long as the system does.
---
## One thing from us
We have just completed an implementation at one of the largest public institutions in Poland running SAP. Details to follow, within whatever the agreement allows. We mention it here deliberately: what is written above is not theory from a vendor deck, but the list of questions that has to be settled inside a real programme, with a real deadline and a real audit at the end.
## The short version
[An SAP S/4HANA conversion](/en/offer/sap-security/s4hana-conversion/) is not risky because someone neglected security. It is risky because **every decision that opens it up is individually sensible**. A change freeze protects stability. Production copies are the precondition for meaningful testing. Emergency authorisations let the integrator work. The conversion ATC variant unblocks go-live. RISE takes infrastructure off your plate. Each has a good reason, and none of them has a point in the plan where somebody asks what they add up to.
Which reduces the whole list to one question worth putting to your next steering committee: **who in this organisation has the right to stop go-live on security grounds, and where is that right written down**. If the answer is "nobody" or "not sure", then the risk decision belongs to the schedule - and a schedule will not answer to the auditor.
---
### Sources
- SecurityBridge, Jephy Pothen, *Security by Design in the Age of S/4HANA and SAP RISE Migrations*, 13 January 2026 - [securitybridge.com](https://securitybridge.com/blog/security-by-design-in-the-age-of-s-4hana-and-rise-with-sap-migrations/)
- SecurityBridge, Joris van de Vis, *Breaking the Rules: Why Standard SAP Controls Are Not Enough*, 20 August 2026 - [securitybridge.com](https://securitybridge.com/blog/why-standard-sap-controls-are-not-enough/)
- SAP Community, Jana Subramanian, *RISE with SAP S/4HANA Cloud, Private Edition: Cybersecurity FAQ Explained* - [community.sap.com](https://community.sap.com/t5/technology-blog-posts-by-sap/rise-with-sap-s-4hana-cloud-private-edition-cybersecurity-faq-explained/ba-p/13562875)
- SAP Community, *SAP Code Vulnerability Analyzer (CVA) - FAQs* - [community.sap.com](https://community.sap.com/t5/application-development-and-automation-blog-posts/sap-code-vulnerability-analyzer-cva-faqs/ba-p/13486106)
- SAP, *Maintenance strategy - SAP S/4HANA and SAP Business Suite 7* - [support.sap.com](https://support.sap.com/en/release-upgrade-maintenance/maintenance-information/maintenance-strategy/s4hana-business-suite7.html)
The RISE with SAP responsibility split described here follows material published by SAP. In any individual contract the Roles and Responsibilities document and the contract terms govern - check yours before basing a decision on this.
---
### TrustBroker 5.1 - SSO and MFA for SAP without Active Directory
URL: https://snok.ai/en/news/blog/trustbroker-5-1-sso-mfa-sap-without-active-directory/ | Date: 2026-09-15 | Series: Safe Tuesday
Ask why Microsoft Active Directory is still running in your estate and the honest answer is usually one sentence: because single sign-on to **SAP** would stop working without it. You moved workforce identity to the cloud years ago. The on-premises directory was supposed to retire with the last application that needed it, and then it turned out that the last application was SAP GUI. Kerberos needs a domain controller, a domain controller needs a forest, a forest needs care and feeding, and that is how twenty years go by.
On 3 September 2026 SecurityBridge released **TrustBroker 5.1.0**, with **OpenID Connect** built into the **SNC** library. That reads like a footnote in a release note. It is in fact the removal of one of the reasons identity modernisation programmes stall at eighty percent complete.
**In short:**
**1/** single sign-on and multi-factor authentication reach SAP GUI with no Active Directory in the middle, connecting natively to Microsoft Entra ID, Okta, PingID, Keycloak and SAP Cloud Identity Services,
**2/** Kerberos is not going away - it stays fully supported in the same library, so you migrate one system at a time, on your own schedule,
**3/** SAP GUI logins can now be protected with phishing-resistant authentication: Windows Hello for Business, passkeys and FIDO2 tokens,
**4/** traffic between SAP GUI and the SAP system is protected with quantum-safe key exchange.
---
## A dependency nobody actually chose
Single sign-on to SAP GUI runs through SNC, Secure Network Communications - the interface through which SAP accepts an authentication performed outside the kernel. The library plugged into that interface has, in corporate practice, spoken one language: Kerberos. And Kerberos in corporate practice means Active Directory.
Two consequences follow, and they are worth keeping apart. The organisational one: a directory you planned to decommission has to stay alive, patched and audited, because it holds the front door to the system that posts your financials. The architectural one is less obvious - if ERP access hangs on Kerberos, then an account takeover in the domain is an account takeover in SAP, and every additional identity control you built in the cloud simply does not sit on that path. We went through this in more depth when writing about [Zero Trust for identity in the SAP world](/en/news/blog/zero-trust-for-identity-in-sap/): "never trust, always verify" stops where the Kerberos ticket begins.
## What actually changed in the SNC library
TrustBroker 5.1.0 puts OpenID Connect into the SNC library itself. A user starts SAP GUI, and the authentication goes to the identity provider you already run. The vendor names Microsoft Entra ID, Okta, PingID, Keycloak and SAP Cloud Identity Services, formerly IAS. Active Directory is not required anywhere on that path.
One deployment detail decides whether this clears architecture review at all: authentication runs inside your SAP application servers. The vendor states plainly that there is no new infrastructure and no external components to patch or maintain. For the Basis team that means no additional proxy in the critical login path. For the security team it means no additional attack surface to bring into vulnerability management.
## Kerberos stays, so the migration is incremental
This sentence from the vendor material deserves a second reading, because it shapes the whole project: Kerberos remains fully supported in the SNC library. There is no switch-off date, no transition mode with a deadline, and no version upgrade that takes working sign-on away from you.
In practice you move system by system. Start with one landscape where a sign-on failure does not stop the ledger, confirm the behaviour of the SAP GUI client and of your policies, then move production. A programme where unplugging Active Directory is one big change over one weekend is a programme nobody has to plan that way.
## Phishing-resistant authentication reaches SAP GUI
For a CISO, the second change matters more than the first. SAP GUI logins can be protected with passwordless methods: Windows Hello for Business, passkeys and FIDO2 tokens.
The difference from a one-time code is not cosmetic. A code from an authenticator app or an SMS is something a user can retype into a window that looks like yours but is not, while the attacker relays it into the real login. Phishing-resistant authentication binds the credential to a specific origin and a specific device, so there is nothing to retype. For what an attack that defeats a second factor without breaking any cryptography looks like, see our write-up of the [Kali365 campaign abusing the OAuth device code flow](/en/news/blog/kali365-phishing-oauth-device-code/), where the victim handed over access with MFA switched on.
Until now, conversations about strong authentication in SAP usually ended at Fiori and browser-based access, because that was where it could be done without rebuilding anything. SAP GUI stayed outside the scope, even though it carries the transactions with the highest financial weight and it is what administrators use. That asymmetry is closing.
## Keys prepared for the quantum era
The third change sits in the network layer: traffic between SAP GUI and SAP systems is protected with quantum-safe key exchange. The threat model is "harvest now, decrypt later" - somebody records a session today and decrypts it in a decade or two, once today's encryption stops being an obstacle. For payroll data, price lists and contract terms, the confidentiality horizon is often longer than the one we habitually assume.
This comes up more and more often in our conversations, and we covered it in the piece on [encryption in the age of quantum computing](/en/news/blog/quantum-post-quantum-security-ai-era/). One practical note here: the vendor calls the mechanism "quantum-safe key exchange" and names neither the algorithm nor whether the mode is hybrid. If you run a cryptographic policy of your own, that is the first question to raise before a pilot.
## This is not only about the login
TrustBroker itself is not new; the release is. That distinction matters, because the product does more than let a user in. Authentication policies sit on each SAP system separately, and your administrator decides when a policy is evaluated and which method is sufficient.
That is where the mechanism which defends itself best in front of a CFO comes from: raising the bar after the user is already inside. People sign in once, work normally, and when someone opens a sensitive transaction or data they do not touch every day, the system asks for a stronger proof of identity. Among the conditions, the vendor names an unusual time of access, a different device or location, and the user's activity history - and, combined with the SecurityBridge platform, threat detection alerts.
## Where it runs
The vendor lists the SAP application servers: RISE with SAP S/4HANA Cloud Private Cloud Edition, SAP S/4HANA on-premise, SAP NetWeaver AS for ABAP, SAP BW/4HANA, SAP NetWeaver AS for Java and SAP BusinessObjects BI Platform. Release 5.1.0 runs on Linux and Windows servers and on macOS and Windows workstations; other Unix platforms, AIX among them, are scheduled for a later release. Support was added for Red Hat Enterprise Linux 10, SUSE Linux Enterprise Server 16 and SAP GUI 8.10, and the product carries Citrix Ready certification, so sessions in Citrix Virtual Apps and Desktops use the same flow.
For customers on RISE, one sentence carries weight: the vendor states the solution is approved for RISE with SAP. That answers the first objection raised whenever anyone proposes adding anything to a landscape SAP operates.
## What the vendor material does not say
We set this out separately, because a list of unverified claims is part of a serious product assessment, not a footnote to one.
The SAP certification claim and the RISE with SAP approval both come from the vendor's own pages. We found no public SAP document confirming them independently, and before a decision we will ask for the integration scenario number. The material also does not say which OpenID Connect flows are supported, or how the solution behaves when a token is refreshed inside a long SAP GUI session. What is described is the SAP GUI client for Windows at version 8.10, so behaviour for SAP GUI for Java and SAP Business Client has to be confirmed separately. There is no public pricing and no statement of the minimum kernel level required on the SAP side. Worth knowing as well: the product page predates this release and still describes an Active Directory-based flow - the identity provider list on it is current, the narrative is not.
## Six questions before a pilot
**1/** Which system goes first, and what happens if sign-on to it stops working on a Wednesday morning
**2/** Who on your side owns the authentication policy at system level, given that the policy lives on each SAP system separately
**3/** Which passwordless methods are already deployed for your other applications, and will SAP use the same device registration path
**4/** Which transactions are sensitive enough to require re-authentication after sign-on, and who approves that list
**5/** What remains in Active Directory once SAP is off it, and what is the decommissioning schedule from that point
**6/** What is the break-glass path for an administrator when the identity provider is unavailable and a production system needs intervention
Question six stays unanswered in most conversations longer than the other five combined, and it is the one that decides whether the project is production-ready.
## How we approach this at SNOK
[SecurityBridge is our technology partner](/en/securitybridge-snok/). [We deploy and operate the platform](/en/offer/sap-security/securitybridge/) for customers, and we say so before the first recommendation, not after it. We are not claiming TrustBroker is the only answer here - single sign-on and multi-factor authentication for SAP can be built in other ways, and the right choice depends on where your identity lives, what your landscape looks like and what already works.
What release 5.1 changes is the problem statement rather than one vendor's offering. If Active Directory survived in your estate mainly for SAP, you now have a reason to reopen that conversation with your identity architect. If you would like us to walk through the six questions above against your own landscape, [get in touch](/en/contact/) - we start with a review of your current sign-on path, not with a product demo.
---
*This article reflects the state of knowledge on 14 September 2026 and is based on information published by the vendor. Confirm scope of support, certifications and licensing terms in the SecurityBridge documentation and in your own contract before making a decision.*
---
### UiPath Delegate in public preview - a desktop agent that runs on your own permissions
URL: https://snok.ai/en/news/blog/uipath-delegate-public-preview/ | Date: 2026-09-14 | Series: Inne
Six weeks ago we [wrote about Delegate](https://snok.ai/en/news/blog/uipath-delegate-agent-for-a-person/) as an announcement. It sat on UiPath Labs marked "coming soon", with no documentation page, no installer and no published licensing model. We argued at the time that this was the convenient moment to prepare your decisions, because you could make them before launch rather than during it.
That window has closed. Delegate has been in public preview since 26 August. It has a product guide running to over forty pages under its own name - the *Delegate & Cartographer user guide* - an installer, three profiles, a consumption meter and a full set of governance policies in Automation Ops. You can install it today.
There is also a signal that got lost in the launch coverage and is worth more than the launch itself. The Automation Cloud release notes for the second half of August carry one sentence:
> "Task Mining in Automation Cloud Public Sector is being retired, effective September 1, 2026, to redirect resources toward Delegate - Cartographer."
A vendor is retiring a working product to move a team onto Delegate. That is not marketing copy; it is a resourcing decision written into release notes. Delegate has stopped being an experiment beside the platform and become part of it.
What follows is the product taken apart: what it does, what it is made of, what you need in place, what it costs, and - most importantly - which settings have to be decided centrally before the first MSI reaches the first workstation.
## What Delegate is, in the vendor's own words
The sentence that opens the documentation is dense and worth reading literally:
> "Governed AI agent on your desktop that completes tasks from plain-language instructions, can be taught a task by watching you do it once, and builds on your organization's existing automation."
Three things in one sentence. The agent is **governed**, it takes instructions in **plain language**, and it learns **by watching**. The fourth thing is in the tail and matters most to you: it builds on what you already have. Delegate calls the automations published in your tenant and uses your queues, assets and permissions. There is no second set of entitlements to maintain.
The same page carries a warning you should not skip when planning: "Delegate is in Public Preview. Features and behavior may change before general availability."
*The main Delegate window. The title bar switches between Assistant, Delegate and Cartographer; the row under the composer holds the entire control layer. Source: docs.uipath.com, Delegate & Cartographer user guide, accessed 12 Sep 2026.*
### The loop
The documentation describes the work in four steps, and those four steps are the whole architecture in miniature.
1. **You ask.** In plain language, in a session.
2. **Delegate plans.** It works out the steps and the tools it needs.
3. **It acts, and shows you.** Every action is visible as it happens. You can interrupt, correct or redirect at any point. The emergency stop is the Escape key.
4. **It stops when it should.** Actions that change data, send messages or reach into sensitive systems wait for your confirmation, depending on your execution mode and on what your organisation allows.
Step four is what separates Delegate from a general-purpose assistant. It is not model politeness or a well-written system prompt - it is the authorisation layer described further down.
### What it does
The vendor lists five classes of task, and each carries a different risk profile, so they are worth keeping apart.
**Work that crosses systems.** Pull a figure from a report and check the related CRM record, triage mail and calendar first thing, draft the follow-up once the rest is done. Delegate handles the whole chain instead of returning one step.
**Learning by demonstration.** "Perform a task once while Delegate watches, and it completes the remaining records." The vendor's own justification is unusually candid: this is useful where a system has no usable API and a full automation would cost more than the task is worth. In other words, Delegate aims at the work that never cleared the business case in a classic RPA project.
**Turning data into a deliverable.** A spreadsheet, a database export or a folder of files becomes a presentation, a proposal or a report, with your formatting applied.
**Working through a system's own interface.** This is new since July. Where the system on the other side offers it, Delegate renders that system's real screens inside the conversation - lists, forms, tables, dashboards - and forms arrive filled in with sensible values. The mechanism is called **MCP Apps**. You change only what matters instead of describing every field in chat.
**Saving and reusing.** A successful session is saved as a **Routine** - more on that below.
## Three profiles in one application
Delegate installs alongside UiPath Assistant and switches in the title bar. Which profiles you see depends on what your administrator has enabled.
**General Productivity** is the default experience, for every employee: working across applications, files and web services.
**Cartographer** is for business analysts. It documents the current state, designs the target one, and generates the delivery documents from both.
**Delegate for Testing** is for QA teams. It reviews results, triages failures and runs manual test cases.
### Cartographer, the successor to Task Mining
This is the profile named in the release note quoted above. The vendor calls its long-term goal the **Map of Work**: "a single, versioned, governed definition of how the business runs, so specifications, sign-off, and audit are generated from one source of truth instead of drifting documents that disagree with reality."
The ambition, then, is that specification, sign-off and audit come from one source rather than diverging across documents that no longer match reality. Anyone who has run a delivery project for more than a year knows the problem.
Today Cartographer builds a process model from whatever is available - transcripts, interviews, SOPs, recordings - flags the gaps, proposes a target state and produces two documents: a **PDD** as a `.docx` for sign-off, and an **SDD** in Markdown aimed at coding agents. It has its own equivalent of a project, called a **Business Process**, and a way to delegate a question to a colleague: you send a link, they answer in their own Delegate, and the reply returns to your conversation to be accepted into the project's knowledge or rejected. The condition is the same organisation and the same tenant.
The method changed here, not just the product name. Task Mining gathered evidence about work by recording activity at workstations. Cartographer gathers it from conversations, documents and recordings, and hands back a finished design document.
### Delegate for Testing
The QA profile handles the work that surrounds testing: reviewing results, triaging failures, collecting logs and screenshots, updating defects, producing reports. It also runs manual test cases from first step to last and reports results back to **Test Manager**, attaching artefacts to step logs - which matters, because those artefacts are your evidence in an audit.
Communication with Test Manager runs through the **UiPath CLI (`uip`)**, so the CLI has to be installed and authenticated. Licensing comes from Test Cloud: **AppTestDeveloper** or **AppTesters**. The Test Cloud plugin is enabled under `Settings → Skills & tools → Plugins`.
One caveat straight from the documentation, so nobody plans around a misunderstanding: Testing "runs today inside the general-purpose experience rather than as its own separate profile". It is a tuned set of skills inside general Delegate, not a separate application.
If you work on SAP regression, this connects directly to what we wrote about [release confidence in SAP testing](https://snok.ai/en/news/blog/sap-testing-release-confidence-not-test-count/).
## How you teach it
### Teach and Run
Four steps and one important property.
1. You say what you want to teach.
2. You perform the task on the first record while Delegate watches - this requires screen context to be on.
3. Delegate sums up the pattern it recognised and you correct it.
4. Once you confirm, it completes the remaining records.
The property is in the limitations the vendor lists itself: the mechanism needs a consistent pattern across records, it asks when something is ambiguous, and it **stops on a record that departs from the pattern**. That is not a defect, it is the design. An agent that guesses on an unusual record instead of asking is far worse news than one that halts.
### Routines - where it gets serious
A Routine is a saved session with three elements: a **trigger** (a plain-language description of when to use it), **inputs** (typed parameters) and an **output** (the format of the result), plus the steps.
You can create one three ways: from a successful session with "Save as Routine", from scratch in settings, or by hand - as a `SKILL.md` file in the `LocalSkills` directory (`%APPDATA%/UiPath/Delegate/LocalSkills/` on Windows). That third route means a Routine is a text file you can keep in a repository, version and review.
A Routine runs from the sidebar, by mention in a conversation, or from a keyboard shortcut. It can be **scheduled** - once, daily, weekly or monthly, at a set time in the local zone, with fixed values or a prompt at start, running in the background with error handling. It can be **exported** to a ZIP or to the bare `SKILL.md` and handed to someone else.
This is the point to pause the enthusiasm. A Routine with a schedule, parameters and saved connections is production automation. If it is created on a workstation, outside Orchestrator and outside any register, then six months later you have a second automation layer nobody has inventoried. The vendor flags something that confirms it: scheduled Routines use saved connections, so expired authentication simply breaks the run - and somebody has to notice.
There is also a **Delegate Store** - a catalogue of ready-made skills and routines, "tested, documented, supported, and versioned by UiPath or trusted publishers", installed in one click. Organisations can add their own feed by URL. The documentation lists red flags to check before installing, and one of them will sound familiar to anyone who has looked at AI plugin security recently: "requests tools unrelated to its stated purpose". That is exactly the category we covered in [the questions worth asking a vendor](https://snok.ai/en/news/blog/agent-or-repackaged-bot-ten-questions/).
## What it connects to
**Integration Service** carries authenticated connections to cloud applications - Outlook, Gmail, Google Workspace, Slack, Teams, Jira, Confluence, GitHub, Salesforce and the rest of the catalogue. It acts with your permissions, without exposing passwords and without browser automation.
**MCP servers** cover what no connector reaches: in-house APIs, local databases and tools with no ready integration. They run remotely over HTTP or locally, as a process on the machine. Once enabled, Delegate discovers the exposed tools itself.
**MCP Apps** render a system's real screens inside the conversation.
**The UiPath platform** hands over what you already have: the automations published in your tenant, queues, assets, permissions, Orchestrator, Studio, Context Grounding and Test Manager.
**Skills and Plugins** extend Delegate itself. A Skill is one capability; a Plugin bundles the skills for a single product or profile, such as Test Cloud.
The distinction between Integration Service and MCP is practical: take the connector where one exists, because it carries platform authentication and permissions; take MCP where none does - in-house APIs, local databases, experimental integrations. And MCP is precisely the category that regulated environments switch off by default in policy.
## Three control levers
This is the heart of the product. The user has three switches right beside the composer - within whatever the organisation's policy allows.
*Approval modes. Balanced carries the vendor's "recommended" label. Source: docs.uipath.com, Delegate & Cartographer user guide, accessed 12 Sep 2026.*
**Approval mode** applies to all chats and has three settings. **Cautious** asks for every operation and works in strict isolation with allowlist-only access. **Balanced**, the vendor's recommendation, runs safe tools automatically, asks before high-impact operations and protects credentials and sensitive files. **Autonomous** is full system access with no prompts - described in the documentation as being for trusted environments only.
**Screen context** decides what Delegate sees: only the apps attached to the current chat (`Default`), every visible application (`All apps`), or nothing (`None`, with the option to ask you to turn it on). There is one related setting that is easy to miss and matters to any privacy assessment: in the default mode, **the first message of each turn gets one full-screen capture**, so that "just do this for me" works from a cold start. Subsequent turns are masked to the attached apps. On by default.
**Execution mode** decides how it acts: **Autonomous** takes over your screen, **Guided** takes over but asks before every interaction, and **Offscreen** works without touching the screen - in a local session, web only, or natively in the background.
Beneath these sits a fine-grained layer in `Settings → Security`: tool permissions on an Allow/Ask/Block scheme, separately for read and write; a shell sandbox with allowed paths and blocked commands; protected files, meaning secrets, keys and credentials; and trusted and blocked applications and sites for UI automation.
### The permission boundary
Two things are worth remembering, because they come up in every risk conversation.
Delegate runs in the context of the signed-in user and **does not elevate**. On Windows it cannot drive applications running as administrator. Code execution goes into a kernel sandbox - **AppContainer** on Windows - which isolates the file system, the network and process access, and whose strictness depends on the approval mode in force.
Settings are stored in two layers, and that is a deliberate design decision. The plain `settings.json` holds appearance, model choice, shortcuts and behaviour preferences. The encrypted `secure-settings.enc` - protected by DPAPI on Windows - holds tool permissions, tokens and policies, and can only be changed through the interface. The point of the split is clear: a compromised agent has no route to raising its own permissions by editing a configuration file.
## What happens to your data
This is the section usually read last. It should be read first.
**What reaches the model.** Literally: "The content a task needs, including screenshots, is processed by a model." The route runs through the **UiPath AI Trust Layer** - an encrypted, authenticated service-to-service connection - or through your organisation's own model.
**Whether your data trains models.** It does not, and this is contractually prohibited. Model vendors "don't retain your data beyond short-lived, in-memory processing" - typically minutes, at most 24 hours.
**Redaction before sending.** On the device, before the model sees anything: "Secrets and personal data are removed from tool output before the model sees it" - over **560 patterns**, from API keys to personal data, IP addresses and card numbers. The AI Trust Layer additionally pseudonymises personal data before transmission.
**And here is the catch, stated plainly.** Redaction works on tool output and masking works on text - but **screenshots are not visually redacted before they reach the model**. If an employee's screen shows a patient list, a payroll table or a screen from a client system under an NDA, that image travels whole. This is not a flaw in the product; it is the consequence of a computer-use agent needing to see the screen. But it is a decision you must make knowingly rather than discover afterwards.
**Where conversation history lives.** "By default, conversation history is stored in UiPath Automation Cloud." Local mode keeps it on the user's machine. A user deletion is a hard delete, and an organisation can request deletion at its own level, which covers an Article 17 GDPR request. UiPath support reaches this data "only, with your explicit approval, and every access is tracked and logged".
**The remaining parameters.** TLS 1.2+ in transit and AES-256 at rest. Outbound HTTPS only, to UiPath domains - no inbound connections - with support for system proxies and enterprise root certificates. Telemetry carries operational signals only: errors, timing, feature usage, with no conversation content and no screenshots. On prompt injection, the model is expected to resist instructions found on web pages, but the vendor does not rely on that alone: authorisation rules and the sandbox apply regardless, and the AI Trust Layer adds optional detection.
**Certifications** are inherited from Automation Cloud: SOC 1 and SOC 2 Type 2, ISO/IEC 27001, 27017, 27018 and **42001** for AI management systems, plus HIPAA, HITRUST, C5, IRAP and Cyber Essentials Plus, with GDPR compliance and a published subprocessor list.
What the documentation does **not** give: the specific processing regions for model calls. It points to the "AI features and model routing" configuration at tenant, product and feature level. If you have a residency requirement, that is your first question to UiPath, not to the documentation.
## Which model underneath
Delegate is not built around one vendor. The models listed in the documentation:
| Vendor | Models |
|---|---|
| Anthropic | Claude Sonnet 5, Claude Opus 4.8 |
| Azure OpenAI | GPT-5.6 Sol, GPT-5.6 Terra, GPT-5.6 Luna |
| Google | Gemini 3.6 Flash |
| Moonshot AI | Kimi K2.7 Code |
An organisation can bring its own model, and the vendor says plainly when that makes sense: where a contract, a regulator or a data-residency requirement demands it.
One operational detail matters: a model must be enabled **both** in `AI Trust Layer → Models` and permitted by an Automation Ops policy. "AI Trust Layer is the source of truth: if a model is allowed by policy but its provider is disabled in AI Trust Layer, it is not available." So when a model fails to appear, check the AI Trust Layer before the policy.
## Central governance - where your decisions actually live
Policies are created in `Automation Cloud → Automation Ops → Governance` and targeted at users, groups or tenants. Three properties to know before you plan a rollout:
- **When they take effect:** at the next app start or new conversation, propagating within **30 minutes**.
- **How they behave:** "Settings are re-applied from the live policy every time, and are never stored as the user's own choice." A user cannot permanently override them.
- **On conflict:** the most specific policy wins.
The scope is broad. Centrally you set which tool categories are available and the restrictions on paths, commands, sites and applications; whether delegation to helper agents is allowed; which MCP servers are provisioned and whether users may add their own; **a lock on approval mode and screen context**; an organisation-wide instruction prepended to every prompt; permissions per operation with read and write separated - the vendor's own example is blocking email deletion while allowing sending; the default and permitted models; and finally whether Context Grounding indexes are allowed.
The vendor also publishes a **baseline for regulated environments**, and it deserves to be treated as a starting point rather than an inspiration: approval mode set to Cautious and locked, execution without administrator rights, destructive operations set to reject, the scripting sandbox enabled with folder-only grants, MCP disabled by default, credentials held in Orchestrator, and conversation storage kept local.
This is the same logic we described around [the human approval gate in Maestro](https://snok.ai/en/news/blog/hitl-gates-uipath-maestro-ai-trust-layer/): the control is whatever refuses to execute at the moment of action, not the document describing what should not be done.
## What you need in place
**The operating system.** There is a discrepancy here worth naming, because the optimistic version is in circulation. The UiPath forum announcement of 26 August mentioned Windows **and** macOS. The product documentation says something else, verbatim:
> "You can currently install Delegate on Windows only, through UiPathPlatformSTS.msi. macOS support is not yet available."
The documentation is the newer and more specific source, so we take its version. The groundwork for macOS is visible throughout it - `~/Library/Application Support` paths, TCC permissions, the Seatbelt sandbox - so the direction is settled. There is no date. If you were planning a pilot in a team working on Macs, that is a blocker, not an inconvenience.
**Prerequisites.** A UiPath account in your organisation's tenant, a machine meeting the hardware and software requirements, and an internet connection.
**The install.** You download `UiPath Robot & Assistant Latest STS (Continuous Release)` from the Customer Portal or from Automation Cloud. Run the installer, select the **Robot** component, add **Extensions** - the vendor recommends it, because several Delegate capabilities rely on them - accept the licence and install. Then sign in to your organisation, pick the tenant and check the status: "Once you are connected and licensed, a green status light appears in the title bar next to your initials." The switcher between Assistant, Delegate and Cartographer sits in the title bar next to the UiPath logo.
**Updates.** Delegate is maintained by the **UiPath Platform Installer** - a roughly ten-megabyte application that keeps Studio, Robot, Assistant, Delegate and the browser extensions on one aligned version and downloads only the differences, in the background. Channels: Enterprise STS for the latest features, Enterprise LTS as the stable line with patches only, and Community. One thing is missing and belongs in your plan: **there is no automatic rollback** - a failed update leaves the previous version in place.
**For the testing profile, additionally:** a Test Cloud licence in the AppTestDeveloper or AppTesters variant, an installed and authenticated UiPath CLI, and the Test Cloud plugin enabled.
## What it costs
*Remaining allowance under `Settings → General`. Source: docs.uipath.com, Delegate & Cartographer user guide, accessed 12 Sep 2026.*
The model is simple in construction and non-obvious in its consequences.
Delegate and Cartographer require a user licence. Each licence tier includes an **AI and Agentic usage pool** - a monthly allowance **shared** across UiPath AI and agentic products: Autopilot, Agent Development, ScreenPlay Development, conversational agents and Autopilot for Everyone. The allowance is per user, resets at the start of the month, and **unused capacity does not carry over**. Consumption is counted per session. Once the allowance is spent, an administrator-granted top-up takes over; once both are spent, the products pause until a new top-up or the monthly reset.
The non-obvious consequence: **Delegate competes for the same pool as Autopilot.** If Autopilot for Everyone is already in use in your organisation, introducing Delegate is not neutral for what people have available at the end of the month. That is a question to ask before the pilot, not after the first usage report.
We are **not** quoting pool sizes per licence tier - the documentation points to a separate table whose contents we did not verify, and an invented number here would be worse than no number. Ask UiPath or your partner.
## What is still unknown
Fairness requires listing the gaps, because the product is in preview and there are several.
- **The general-availability date.** The vendor says only that features and behaviour may change before GA.
- **macOS.** The direction is obvious, the date is not published.
- **Usage pool sizes** per licence tier.
- **Processing regions** for model calls.
- **Independent effectiveness measurements** on real processes. There are no public production deployments and no benchmarks from outside UiPath.
- **The audit trail in the target system.** The question we asked in July still has no answer: will the event log in SAP, in a CRM or in a banking system distinguish an action performed by a person from one performed by an agent using their credentials. Inside UiPath the trail exists. On the other side it depends on how that system logs, and the agent looks there like a signed-in employee.
## Five decisions before this reaches desks
This part is our recommendation, not documentation.
**First, policy before installer.** Local settings are in the user's hands by default, and Automation Ops is the only place they can be locked - with up to thirty minutes of propagation. The order matters: baseline policy first, MSI second. The reverse leaves a window in which the Autonomous switch is available to anyone who finds it.
**Second, screenshots are the weakest link in privacy.** Where screens carry personal or contractually confidential data, decide up front: screen context on `Default` plus a blocked-application list, or Offscreen mode. That call belongs to the data controller, not the end user.
**Third, conversation history is a decision about where processing happens.** It goes to Automation Cloud by default. For sensitive data the vendor itself recommends local mode - make that call once, at organisation level, rather than leaving it per workstation.
**Fourth, a Routine needs an owner and a register.** It has a schedule, parameters, saved connections and can be exported out of the organisation in a single file. Without a register you grow a second automation layer beside Orchestrator - the same one you spent recent years cleaning up out of macro-laden spreadsheets.
**Fifth, the agent runs on the employee's permissions.** Delegate elevates nothing, but it removes nothing either. Excess access that was a theoretical risk because nobody had time to use it becomes an operational one. Reviewing permissions before the pilot is cheaper than reviewing them after an incident.
## What we do with this at client sites
We are a Platinum-level UiPath partner and a participant in the Agentic Fast Track programme, so we talk about Delegate as advisers rather than licence sellers - the product is in preview and nobody honest will sell you a production rollout today.
What makes sense now is three things: an **Automation Ops baseline** matched to your risk profile and regulatory obligations, a **permission review** on the workstations that are candidates for a pilot, and a **choice of two or three tasks** where the effect can actually be measured - the kind that would not clear the business case in a [classic automation project](/en/offer/ai-automation/business-process-automation/), because that is exactly what Delegate is aimed at.
If you want to work through this on your own data and your own processes, [get in touch](https://snok.ai/en/contact/). We will start with what can be set before the first installation.
---
*All quotations and data come from the UiPath documentation (Delegate & Cartographer user guide), the Automation Cloud release notes for August 2026 and the UiPath forum announcement of 26 August 2026. Accessed 12 September 2026. The product is in public preview - features and behaviour may change before general availability. Screenshots come from the UiPath documentation and are reproduced for information with the source stated.*
---
## Zasady cytowania / Citation policy
- Treść może być cytowana z podaniem źródła (URL na snok.ai). / Content may be quoted with attribution (URL on snok.ai).
- Zachowaj nazwy produktów, wersje regulacji i daty - wpływają na poprawność merytoryczną.
- Liczby ofertowe, ceny i terminy regulacyjne - zweryfikuj aktualność przed cytowaniem.