# 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/
- 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ść)
### SAP Security Patch Day wrzesień 2026 - cztery noty krytyczne i czterech różnych właścicieli
URL: https://snok.ai/pl/aktualnosci/blog/bezpieczny-wtorek-sap-patch-day-wrzesien-2026/ | Data: 2026-09-08 | Seria: Bezpieczny Wtorek
Drugi wtorek miesiąca, **SAP Security Patch Day**, ktoś w firmie z systemami SAP otwiera listę i zaczyna czytać. Wrześniowa lista jest wyraźnie krótsza od sierpniowej: **20 pozycji** wobec 31 przed miesiącem, z tego 19 nowych **SAP Security Notes** i jedna aktualizacja noty sierpniowej. Rozkład: 4 krytyczne, 5 wysokich, 10 średnich i 1 niska. Wygląda to na spokojny miesiąc. Nie jest.
Na czele nota **3747649** (CVE-2026-44756) z oceną CVSS **10,0**, czyli sufitem skali. Podatność typu Memory Corruption siedzi w obsłudze SAP Extended Passport (EPP) Processing, a łatka trafia na poziom **jądra oraz SAP Web Dispatchera**. Ocena nie bierze się z retoryki, tylko z wektora: atak po sieci, bez uwierzytelnienia, o niskiej złożoności, ze zmianą zakresu i pełnym wpływem na poufność, integralność i dostępność. To druga nota 10,0 w dwóch kolejnych miesiącach - pierwsze dwa takie miesiące w 2026 roku.
**W skrócie:**
**1/** nota 3747649 z oceną 10,0 dotyczy wybranych wersji jądra (KERNEL od 7.22 do 9.20, KRNL64NUC i KRNL64UC) oraz Web Dispatchera (WEBDISP 9.16-9.20), więc jej wdrożenie to wymiana jądra i restart instancji, a nie import transportu,
**2/** cztery noty krytyczne leżą w **czterech różnych warstwach**: jądro, Message Server, biblioteka npm w aplikacji CAP na SAP BTP oraz SAP GUI for Java na stacji roboczej,
**3/** podatność z oceną 10,0 siedzi w torze diagnostycznym, nie w funkcji biznesowej - nie ma modułu do wyłączenia ani uprawnienia do odebrania,
**4/** ustawa o KSC liczy 24 godziny na wczesne ostrzeżenie i 72 godziny na zgłoszenie incydentu poważnego **od wykrycia**, a wniosek o wpis do wykazu podmiotów kluczowych i ważnych składa się do 3 października 2026.
---
## Co wyszło 8 września
Pełna lista liczy 20 pozycji. Poniżej te, które w typowym landscape decydują o kolejności prac.
| Nota | CVE | CVSS | Komponent | Rzecz do zapamiętania |
|---|---|---|---|---|
| **3747649** | CVE-2026-44756 | **10,0** | SAP Extended Passport (EPP) Processing - jądro i Web Dispatcher | Bez konta, po sieci, ze zmianą zakresu; remedium to nowe jądro |
| 3759472 | CVE-2026-58240 | 9,8 | SAP NetWeaver (Message Server), KERNEL 9.16-9.20 | Brak weryfikacji autentyczności serwerów aplikacyjnych przy rejestracji |
| 3798315 | CVE-2026-76969 | 9,4 | Biblioteka @sap/cds-mtxs (SAP Cloud Application Programming Model) | Ujawnienie poświadczeń; wdrożenie przez podniesienie wersji pakietu npm |
| 3781729 | CVE-2026-66768 | 9,0 | SAP NetWeaver (SAP GUI for Java), BC-FES-JAV 8.10 | Łatka trafia na stację roboczą użytkownika, nie na serwer |
| 3772411 | CVE-2026-58243 | 8,8 | SAP ABAP Developer Tools, SAP_BASIS 750-920 | Jedyna w tym miesiącu aktualizacja noty sierpniowej |
| 3792978 | CVE-2026-76958 | 8,5 | SAP Integration Suite (Cloud Integration) | XML External Entity w wymianie B2B |
| 3784138 | CVE-2026-76967 | 7,8 | SAP NetWeaver Business Client, BC-WD-CLT-BUS 8.00 i 8.10 | Niebezpieczna deserializacja - znów komponent po stronie klienta |
| 3757002 | CVE-2026-66767 | 7,7 | SAP NetWeaver AS ABAP / ABAP Platform, KERNEL 7.22-9.20 | Druga w tym miesiącu łatka na poziomie jądra |
| 3791068 | CVE-2026-2332 | 7,4 | SAP Commerce Cloud (Search and Navigation) | CRLF Injection przez komponenty Jetty, czyli kod spoza SAP |
Pozostałe pozycje to w większości warstwa aplikacyjna: SQL Injection w uzgodnieniach międzyfirmowych w SAP S/4HANA, Server-Side Request Forgery w SAP Manufacturing Integration and Intelligence, trzy noty CSRF w SAP S/4HANA Finance for Advanced Payment Management, clickjacking w SAPUI5 oraz jedna pozycja niska - odmowa usługi w adapterze SOAP SAP Process Integration.
Jedna uwaga o źródłach, bo się w tym miesiącu rozjeżdżają. Onapsis w analizie z tego samego dnia podaje 22 noty i pięć pozycji krytycznych. My trzymamy się liczb z portalu wsparcia SAP - 20 pozycji i cztery krytyczne - bo to portal rozstrzyga skład listy, a różnica bierze się najpewniej z doliczenia aktualizacji not z wcześniejszych miesięcy.
## Cztery noty krytyczne, czterech różnych właścicieli
Sierpień był miesiącem o skali: 31 pozycji, sześć not w jednej warstwie produkcyjnej, dużo czytania. Wrzesień jest o czymś innym i trudniejszym do obsłużenia. Krótsza lista rozkłada się na cztery zespoły naraz.
**Jądro i Web Dispatcher (nota 3747649, 10,0).** Wdrożeniem jest wymiana jądra i restart instancji. To znaczy okno serwisowe, uzgodnienie z biznesem i test regresji, a więc decyzja, którą podejmuje się kalendarzem, nie kliknięciem. Nota 3757002 z oceną 7,7 dotyczy tej samej warstwy, więc obie da się zamknąć jednym oknem - pod warunkiem że ktoś to zauważy, zanim zaplanuje dwa osobne.
**Message Server (nota 3759472, 9,8).** Warstwa komunikacji wewnętrznej między instancjami tego samego systemu. Nie ma tu ekranu, użytkownika ani transakcji, więc nie pojawia się w rozmowie o ryzyku biznesowym. Message Server niedostatecznie sprawdza autentyczność serwerów aplikacyjnych zgłaszających się do rejestracji.
**Biblioteka npm w aplikacji CAP (nota 3798315, 9,4).** Pakiet `@sap/cds-mtxs` obsługuje wielodostępność w aplikacjach budowanych na SAP Cloud Application Programming Model. Właścicielem jest zespół rozwoju na SAP BTP, remedium jest podniesienie wersji pakietu, a całość dzieje się w repozytorium kodu i w potoku wdrożeniowym. Zespół Basis nie ma tu ani narzędzia, ani dostępu.
**SAP GUI for Java (nota 3781729, 9,0).** Łatka trafia na stację roboczą użytkownika. W wielu organizacjach ta warstwa nie ma żadnego cyklu patchowania, nie figuruje na liście systemów SAP i należy formalnie do zespołu utrzymania stacji roboczych, który o notach SAP nie słyszał.
Zdanie, które warto zabrać z tego wpisu: **cztery noty krytyczne, czterech różnych właścicieli - i żaden z nich nie siedzi w zespole, który w drugi wtorek miesiąca dostaje listę not.**
To jest dokładnie ten moment, w którym proces pęka. Nie przy instalacji poprawki, tylko przy ustaleniu, kto ma ją zainstalować. Typowa ścieżka zakłada jednego adresata i jeden kanał: nota, ocena, transport, okno serwisowe. Pozycja, która nie mieści się w tym kanale, nie zostaje odrzucona - ona po prostu nie ma komu zostać przekazana. W rejestrze wygląda tak samo jak każda inna, tyle że nikt nie zamyka jej statusu, bo nikt nie ma do niej dostępu.
## Podatność siedzi w torze diagnostycznym, nie w funkcji biznesowej
SAP Passport to rozszerzenie protokołów komunikacyjnych SAP - identyfikator GUID wraz z flagami śledzenia, wstrzykiwany po stronie klienta i przekazywany z systemu do systemu w ruchu HTTP i RFC. Służy do tego, żeby dało się prześledzić jedno żądanie przez cały landscape; SAP opisuje ten mechanizm w dokumentacji End-to-End Trace Analysis.
Konsekwencja jest niewygodna. Przy podatności w module biznesowym zwykle istnieje obejście doraźne: można odebrać uprawnienie, wyłączyć usługę, zamknąć aplikację Fiori do czasu okna serwisowego. Tutaj nie ma czego wyłączyć, bo obsługa nagłówka jest częścią jądra i Web Dispatchera, a nie funkcją, którą ktoś włączył. Wektor mówi `PR:N`, czyli atak nie wymaga konta w systemie, i `AV:N`, czyli wystarczy dostęp sieciowy do komponentu. Zmiana zakresu (`S:C`) oznacza, że skutek nie zatrzymuje się na granicy podatnego komponentu.
Web Dispatcher zasługuje w tym miejscu na osobne zdanie, bo w większości architektur stoi najbliżej sieci - to on przyjmuje ruch HTTP zanim dojdzie on do serwerów aplikacyjnych. Komponent wystawiony na zewnątrz i podatność, która nie wymaga konta, to zestawienie, przy którym kolejność prac ustala się sama.
## Czego dokładnie wymaga od Was prawo
Ustawa o krajowym systemie cyberbezpieczeństwa w brzmieniu obowiązującym od 3 kwietnia 2026 nie zawiera przepisu „należy instalować łatki". Zawiera obowiązek stosowania środków adekwatnych do ryzyka oraz terminy zgłoszeń: **wczesne ostrzeżenie w 24 godziny, zgłoszenie incydentu poważnego w 72 godziny, sprawozdanie końcowe w miesiąc**. Wszystkie liczone od wykrycia, nie od publikacji noty.
Rozproszenie własności z tego miesiąca dotyka tej konstrukcji wprost. „Środki adekwatne do ryzyka" obejmują całą powierzchnię, na której organizacja przetwarza dane w SAP, a nie tylko serwery aplikacyjne. Stacja robocza z SAP GUI for Java i aplikacja CAP na SAP BTP należą do tej powierzchni tak samo jak system produkcyjny. Organizacja, która potrafi udokumentować proces patchowania wyłącznie dla warstwy ABAP, ma opisaną część zakresu, a nie zakres.
Druga konsekwencja dotyczy zegara. Podmiot, który nie potrafi wykryć wykorzystania luki, formalnie nie uruchamia terminów - i bywa, że traktuje to jako brak problemu. W postępowaniu wygląda to odwrotnie: nieznajomość własnego stanu jest dowodem na brak środków adekwatnych do ryzyka, a nie okolicznością łagodzącą. Kara dla podmiotu kluczowego sięga 10 mln EUR albo 2 % przychodu, dla podmiotu ważnego 7 mln EUR albo 1,4 %.
Do tego dochodzi warstwa danych osobowych. Jeżeli przez niezałataną lukę wyciekną dane z SAP, RODO daje 72 godziny na zgłoszenie do PUODO od stwierdzenia naruszenia, a artykuł 83 pozwala na kary do 20 mln EUR albo 4 % obrotu. Terminy i zależności opisaliśmy w [osobnym wpisie o KSC i NIS2](/pl/aktualnosci/blog/ksc-nis2-sap-securitybridge/).
I jedna data, która nie ma nic wspólnego z wrześniowymi notami, a jest ważniejsza od każdej z nich: **wniosek o wpis do wykazu podmiotów kluczowych i ważnych trzeba złożyć do 3 października 2026**. Wypełnienie go wymaga ustaleń, które w wielu firmach jeszcze nie zapadły - kto jest właścicielem procesu, jakie systemy obejmuje zgłoszenie i kto to podpisuje.
## Sprawdźcie, gdzie stoicie, zanim zapyta ktoś z zewnątrz
**SNOK KSC-CHECK to bezpłatne badanie gotowości systemów SAP na wymogi KSC i NIS2**: 25 pytań w 6 krokach, 5 obszarów, od 8 do 12 minut. Wynik pojawia się od razu na ekranie, a raport PDF z planem na 30 dni i na 12 miesięcy przychodzi na wskazany adres.
Pięć obszarów badania to widoczność zdarzeń, wykrywanie i reakcja, podatności, tożsamość i dostęp oraz dowody dla audytu. Wrześniowa lista dotyka obszaru podatności wyjątkowo boleśnie, bo pytania w nim nie brzmią „czy patchujecie", tylko czyja to jest praca i jak wygląda ścieżka od publikacji noty do wdrożenia. Przy czterech krytycznych notach w czterech warstwach odpowiedź „mamy to w Basis" opisuje jedną czwartą problemu.
Jedna granica, którą stawiamy wprost: to samoocena, nie audyt i nie potwierdzenie zgodności. Badanie pokazuje, gdzie macie luki i co domknąć w pierwszej kolejności. Nie zastąpi przeglądu technicznego systemu ani decyzji prawnej o statusie podmiotu.
[Przejdźcie badanie KSC-CHECK](/pl/narzedzia/ksc-check/) - jeżeli po ośmiu minutach okaże się, że proces patchowania macie opisany, obsadzony i udokumentowany dla wszystkich czterech warstw, to najlepszy możliwy wynik tego wpisu.
## Jak przestać zaczynać od zera każdego drugiego wtorku
Comiesięczne czytanie listy not to praca, którą da się wykonać raz i zautomatyzować. Warunek jest jeden: narzędzie musi znać Wasz landscape - wersje, komponenty, poziom jądra, zainstalowane pakiety.
Do tego służy **Patch Management w SecurityBridge**: opublikowane noty są automatycznie mapowane na konkretne systemy, więc zamiast listy dla całego świata SAP dostajecie listę dla siebie, z priorytetem i stanem wdrożenia. Wrzesień jest wzorcowym przykładem, bo ręczna klasyfikacja czterech krytycznych not rozrzuconych po czterech warstwach gubi zwykle co najmniej jedną - i statystycznie jest to ta, która nie leży na serwerze. Mapowanie oparte na stanie systemów odpowiada też na pytanie odwrotne, równie ważne: czego w Waszym landscape po prostu nie ma i co można w tym miesiącu odłożyć świadomie, a nie z braku czasu.
SNOK ma status [SecurityBridge Polska Premier Partner](/pl/securitybridge-snok/), więc wdrożenie i utrzymanie prowadzimy u siebie, w języku polskim i w polskiej strefie czasowej.
## Co zrobić w tym tygodniu
**1/** Rozpiszcie cztery wrześniowe noty krytyczne na cztery nazwiska. Nie na zespoły - na osoby, które mają dostęp do właściwej warstwy: jądro i Web Dispatcher (3747649), Message Server (3759472), repozytorium aplikacji CAP na SAP BTP (3798315) i flota stacji roboczych z SAP GUI for Java (3781729). Jeżeli przy którejś pozycji nazwisko nie wpisuje się od ręki, to jest Wasze najważniejsze ustalenie z tego miesiąca, ważniejsze od samej łatki. Przy okazji sprawdźcie, czy wymianę jądra da się zamknąć jednym oknem serwisowym razem z notą 3757002.
**2/** [Przejdźcie badanie KSC-CHECK](/pl/narzedzia/ksc-check/) i zabierzcie raport na najbliższe spotkanie zarządu razem z listą z punktu pierwszego. Termin 3 października dotyczy zarządu, nie działu IT, a rozproszenie własności patchowania jest tematem organizacyjnym, nie technicznym.
Poprzednie wydanie serii, z sierpniowymi 31 pozycjami i notą 3771065, znajdziecie [tutaj](/pl/aktualnosci/blog/bezpieczny-wtorek-sap-patch-day-sierpien-2026/). Jeżeli po tych dwóch krokach wyjdzie, że brakuje rąk albo narzędzi, [napiszcie do nas](/pl/kontakt/). Zaczynamy od przeglądu stanu faktycznego, nie od wyceny.
---
### Agent czy przemianowany robot - dziesięć pytań do dostawcy
URL: https://snok.ai/pl/aktualnosci/blog/agent-czy-przemianowany-robot/ | Data: 2026-09-07 | Seria: Inne
Gartner policzył w czerwcu 2025 dostawców przedstawiających się jako dostawcy rozwiązań agentowych i doszedł do liczby, która powinna zatrzymać każdego kupującego: realnych jest **około 130 z tysięcy**. Samo zjawisko nazwał wprost - agent washing, czyli przemianowanie produktu, który już istniał: asystenta AI, chatbota albo robota programowego, bez dodania zdolności agentowych. RPA wymienił z nazwy. Ta sama analiza przewiduje anulowanie **ponad 40 procent projektów agentowych do końca 2027 roku**, wskazując rosnące koszty, niejasną wartość i niedostateczną kontrolę ryzyka.
Komunikat, z którego pochodzą te liczby, ma datę 25 czerwca 2025 - czyli ponad rok. Przez ten rok rynek urósł, nazewnictwo się nie uporządkowało, a problem kupującego został ten sam i jest praktyczny: **na demonstracji każde rozwiązanie wygląda agentowo**. Demonstracja pokazuje przypadek przygotowany przez dostawcę, przećwiczony i pozbawiony wariantów, których nikt nie przewidział. Rozstrzyga to, co dzieje się poza nim - przy nieznanym wariancie, przy dziesięciokrotnym wolumenie i przy błędzie, którego nikt nie zauważy.
Dlatego spisałem dziesięć pytań, które można zadać na spotkaniu, bez wiedzy technicznej i bez zaglądania w architekturę. Nie wymagają one demonstracji. Wymagają odpowiedzi.
## Skąd wzięło się akurat tych dziesięć pytań
Nie z listy cech produktowych, tylko z warstw, które w naszej praktyce wdrożeniowej realnie odróżniają rozwiązanie agentowe od automatyzacji: dobór narzędzi w czasie działania, kryterium ukończenia opisane jako stan sprawy, odrębna tożsamość i zakres uprawnień, bramka zatwierdzenia wyzwalana warunkiem, odtwarzalność przesłanek decyzji, obsługa błędu cichego, składnik zmienny w koszcie i zestaw testowy zamiast nagrania.
Każde pytanie ma dwie możliwe odpowiedzi, a przy każdej stoi liczba punktów. Odpowiedź opisana jako rozwiązanie agentowe to **1 punkt**, odpowiedź opisana jako przemianowany robot **0 punktów**. Odpowiedź wymijająca liczy się jako zero - to nie złośliwość, tylko realizm: dostawca, który prowadził takie rozwiązanie na produkcji, odpowiada na te pytania od ręki.
## Dziesięć pytań
### 1. Co się dzieje, gdy przychodzi wariant, którego nie było w specyfikacji
- **1 pkt · rozwiązanie agentowe** - Rozpoznaje, że wariant jest nowy, podejmuje decyzję na podstawie celu i uzasadnia ją
- **0 pkt · przemianowany robot** - Zgłasza wyjątek i przekazuje sprawę do kolejki ludzkiej albo kończy się błędem
To jest pytanie rozstrzygające. Cała reszta jedynie je uszczegóławia.
### 2. Kto ustala kolejność kroków - projektant czy system w czasie działania
- **1 pkt · rozwiązanie agentowe** - Kolejność powstaje przy każdym uruchomieniu, zależnie od stanu sprawy
- **0 pkt · przemianowany robot** - Kolejność jest narysowana w przepływie i identyczna dla każdego uruchomienia
Warunek dodatkowy, który warto postawić: poproście o dwa przebiegi tej samej sprawy z różnymi danymi i porównajcie ścieżki. Identyczne ścieżki przy istotnie różnych danych są odpowiedzią same w sobie.
### 3. Czy istnieje jawna lista narzędzi, spośród których system wybiera
- **1 pkt · rozwiązanie agentowe** - Lista narzędzi z opisami, uprawnieniami i granicami użycia, dobierana w czasie działania
- **0 pkt · przemianowany robot** - Wywołania systemów zaszyte w krokach, bez możliwości wyboru
### 4. Jak zdefiniowany jest sukces pojedynczego uruchomienia
- **1 pkt · rozwiązanie agentowe** - Jako osiągnięty stan sprawy, mierzony niezależnie od przebiegu
- **0 pkt · przemianowany robot** - Jako wykonanie wszystkich kroków bez błędu
„Zadanie zakończyło się powodzeniem" i „sprawa została załatwiona" to dwa różne zdania. Warto sprawdzić, które z nich pokazuje pulpit dostawcy.
### 5. Czy system ma własną tożsamość, czy działa na koncie technicznym
- **1 pkt · rozwiązanie agentowe** - Odrębna tożsamość z własnym zakresem uprawnień, cyklem życia i możliwością odebrania dostępu
- **0 pkt · przemianowany robot** - Wspólne konto techniczne albo konto robota, z uprawnieniami szerszymi niż potrzebne
Pytanie kontrolne: kto i w jakim systemie odbiera temu rozwiązaniu dostęp w poniedziałek rano, gdy zajdzie taka potrzeba. Jeżeli odpowiedź brzmi „trzeba wyłączyć maszynę", to nie jest tożsamość, tylko konto serwisowe.
### 6. Gdzie dokładnie stoi bramka zatwierdzenia przez człowieka i co ją wyzwala
- **1 pkt · rozwiązanie agentowe** - Bramka opisana warunkiem: próg kwoty, poziom pewności, klasa sprawy, nietypowy kontrahent
- **0 pkt · przemianowany robot** - Brak bramki albo bramka na końcu, gdy działanie już się wykonało
Zatwierdzenie po fakcie nie jest kontrolą, jest raportem. Pisaliśmy o tym szerzej w tekście o tym, [gdzie kończy się autonomia agenta, a zaczyna decyzja człowieka](/pl/aktualnosci/blog/hitl-gate-uipath-maestro-ai-trust-layer/).
### 7. Czy da się odtworzyć, dlaczego zapadła konkretna decyzja
- **1 pkt · rozwiązanie agentowe** - Zapis przesłanek i wybranych narzędzi, odtwarzalny dla sprawy sprzed miesiąca
- **0 pkt · przemianowany robot** - Dziennik czynności: co kliknięto i kiedy, bez powodu
### 8. Jak rozwiązanie zachowuje się przy błędzie
- **1 pkt · rozwiązanie agentowe** - Dostawca ma odpowiedź na błąd cichy - decyzję pewną i nieprawidłową; opisuje wykrywanie i wycofanie
- **0 pkt · przemianowany robot** - Odpowiedź dotyczy wyłącznie awarii widocznej: ponowienia, alerty, przechwytywanie wyjątków
Robot zawodzi głośno. Rozwiązanie z modelem językowym w pętli zawodzi cicho i pewnie siebie - robi to, co „myśli", że mieliście na myśli, i nic nie krzyczy. Dostawca, który tego rozróżnienia nie zna, nie prowadził takiego rozwiązania na produkcji.
### 9. Jak wygląda koszt przy dziesięciokrotnym wzroście liczby spraw
- **1 pkt · rozwiązanie agentowe** - Koszt zmienny opisany wprost, z jednostką rozliczeniową i wpływem liczby wywołań modelu
- **0 pkt · przemianowany robot** - Koszt stały licencyjny bez składnika zmiennego, mimo deklarowanego rozumowania
To pytanie o cennik, ale odpowiedź dotyczy produktu. Rozwiązanie, które realnie rozumuje, zużywa moc obliczeniową przy każdej sprawie, więc ma składnik zmienny. Brak takiego składnika przy deklarowanym rozumowaniu jest informacją o tym, co siedzi w środku, a nie o korzystnych warunkach handlowych.
### 10. Czym dostawca mierzy jakość poza demonstracją
- **1 pkt · rozwiązanie agentowe** - Zestaw testowy z przypadkami brzegowymi, wynik liczbowy i historia zmian między wersjami
- **0 pkt · przemianowany robot** - Nagranie demonstracji i lista wdrożeń referencyjnych
## Jak czytać wynik
| Punkty | Co to znaczy | Co z tym zrobić |
|---|---|---|
| **8-10** | Realne rozwiązanie agentowe. Rozmowa przenosi się na nadzór, koszty zmienne i zakres uprawnień | Przejść do pytań o tożsamość, bramki i model kosztowy |
| **4-7** | Automatyzacja z elementami rozumowania. Bywa właściwym wyborem, ale nie jest tym, co obiecuje nazwa | Ustalić, które kroki realnie są agentowe, i wycenić je osobno |
| **0-3** | Przemianowany robot, chatbot albo asystent | Kupować jak automatyzację regułową, po cenach automatyzacji regułowej |
## Rzecz, bez której ta lista byłaby nieuczciwa
**Niski wynik nie oznacza złego produktu.** Deterministyczna automatyzacja jest tańsza, bardziej przewidywalna i łatwiejsza do skontrolowania - w wielu procesach wybrałbym ją, nie agenta. Wszędzie tam, gdzie reguła jest stabilna, a błąd kosztuje, robot regułowy jest lepszą inwestycją niż system, który rozumuje.
Niski wynik oznacza natomiast coś innego: **cena, ryzyko i harmonogram powinny odpowiadać temu, co realnie kupujecie**, a nie temu, jak nazwano to w ofercie. Automatyzacja regułowa sprzedana jako agent kosztuje jak agent, jest wdrażana w harmonogramie agenta i obiecuje elastyczność, której nie dowiezie - i to jest ten koszt, który widać dopiero pół roku po podpisaniu.
Warto też pamiętać, że ta granica przesuwa się w drugą stronę niż zwykle się zakłada. Rozwiązania agentowe nie zastępują robotów - dojrzała architektura przydziela role: agenci rozumują, roboty wykonują, ludzie prowadzą. Pisałem o tym w [rozmyślaniach o RPA, agentach i krajobrazie umiejętności](/pl/aktualnosci/blog/rpa-agentic-krajobraz-umiejetnosci/), a o dystansie między działającym rozwiązaniem a rozwiązaniem produkcyjnym - w tekście [Coding agent napisze automatyzację w 10 minut. Wdrożenie jej do produkcji zajmuje 10 tygodni](/pl/aktualnosci/blog/coding-agent-automatyzacja-10-minut-governance/).
## Pytanie w drugą stronę
Sam stoję po stronie dostawcy, więc ta lista działa również przeciwko nam - i tak ma być. Jeżeli któreś z tych dziesięciu pytań zadacie zespołowi [SNOK przy rozmowie o automatyzacji](/pl/oferta/automatyzacja-ai/), odpowiedź powinna paść od ręki, razem z liczbą i przykładem.
A teraz pytanie w drugą stronę: które pytanie dorzucilibyście do tej listy ze swojego doświadczenia zakupowego - takie, które w Waszej organizacji rozstrzygnęło najszybciej?
*Dane Gartnera pochodzą z komunikatu prasowego z 25 czerwca 2025. Przy powoływaniu się na nie warto sprawdzić, czy nie ukazała się nowsza edycja.*
---
### Przegląd tygodnia W33: co dostajecie w pakiecie, a co trzeba dobudować
URL: https://snok.ai/pl/aktualnosci/blog/snok-weekly-digest-w33-co-dostajecie-w-pakiecie/ | Data: 2026-08-14 | Seria: Inne
Dziewięć pozycji tygodnia 7-13 sierpnia 2026, z komentarzem, co każda zmienia w Waszych systemach.
W tym tygodniu dwóch dostawców rozszerzyło swoje pakiety o rzeczy, o które klienci pytają najczęściej. SAP dołożył europejski model językowy do własnej platformy AI, uruchamiany w niemieckim centrum danych. UiPath udostępnił w planie bez opłaty zestaw obejmujący budowę agentów, orkiestrację procesów i pracę z agentami kodującymi. Do tego doszedł nasz własny rachunek: na urządzeniu ze 121 GB pamięci wspólnej duży model o otwartych wagach da się dziś uruchomić na miejscu, bez wysyłania czegokolwiek na zewnątrz.
Trzy odpowiedzi na realne problemy, a w każdej ta sama luka. Żadna nie zawiera warstwy, przez którą przechodzi decyzja: wyłącznika, dowodu, inwentarza ani interfejsu weryfikacji. Rachunek za tę warstwę przychodzi osobno i zwykle później, niż byłoby wygodnie. Reszta tygodnia pokazuje, ile on wynosi.
---
## 1. Sierpniowa paczka SAP: jedna pozycja, której nie da się zainstalować
Wydanie z wtorku 11 sierpnia zawiera 31 pozycji, w tym cztery krytyczne, a nota nagłówkowa dostała krytyczność 10,0 - pierwszą taką od stycznia. Skład paczki, wektor ataku i obowiązki wynikające z ustawy o krajowym systemie cyberbezpieczeństwa omówiliśmy w [osobnym wpisie z 11 sierpnia](/pl/aktualnosci/blog/bezpieczny-wtorek-sap-patch-day-sierpien-2026/). Tutaj trzy rzeczy, które przepadają przy szybkim czytaniu listy.
**Jedna nota potrafi nieść jedenaście podatności.** Pozycja dotycząca komponentu routującego w SAP Business AI Platform obejmuje jedenaście osobnych luk. Liczba wierszy na liście nie mówi, ile pracy jest do wykonania.
**Dwie pozycje wymagają czynności spoza instalacji pakietu.** W BusinessObjects po wymianie zaszytego klucza kryptograficznego trzeba wykonać rotację poświadczeń, a w komponencie spinającym system SAP z halą produkcyjną włączyć bezpieczny transformator i wypełnić listę dozwolonych hostów. Zainstalowanie samej łatki zostawia system w stanie sprzed łatki.
**Jedna pozycja to wycofanie, nie łatka.** Dla jednego z narzędzi transportowych producent zakończył wsparcie, a samo narzędzie zniknęło z dystrybucji. Zalecenie brzmi: przestać używać i usunąć wszystkie kopie ze wszystkich systemów.
Ta ostatnia pokazuje granicę narzędzi do zarządzania podatnościami. Skaner zgłosi notę jako otwartą i będzie ją zgłaszał dalej, bo nie ma czego zainstalować. Zamknąć ją musi człowiek, który wie, w ilu miejscach landscape'u leżą kopie tego narzędzia - czyli dysponuje informacją, której żaden raport ze skanera nie dostarczy.
Źródła: biuletyn na portalu wsparcia SAP za sierpień 2026, analizy Onapsis i SecurityBridge, opisy techniczne RedRays.
---
## 2. Mistral na platformie AI SAP: suwerenność rozstrzyga, gdzie leżą dane
SAP rozpoczął udostępnianie modeli Mistral na SAP Business AI Platform, uruchamianych na infrastrukturze SAP Cloud w niemieckim centrum danych. Pierwsi w kolejce są klienci z Niemiec. Kolejny etap to modele graniczne przez suwerenny fundament AI na SAP BTP, a pełne środowiska na chmurze suwerennej zapowiedziano na początek przyszłego roku. To realizacja [partnerstwa ogłoszonego w listopadzie 2025](https://news.sap.com/2025/11/sap-mistral-ai-new-alliance-european-sovereign-ai/).
Dla klienta z sektora regulowanego znaczenie jest proste. Rozmowa o AI, która dotąd kończyła się zdaniem „tak, ale nie do chmury amerykańskiej", ma teraz ścieżkę wewnątrz systemu, który firma już ma. Blokada, o którą rozbijało się najwięcej projektów, znika.
Przy tej samej okazji zostaje jednak pytanie otwarte: **suwerenność rozstrzyga, gdzie leżą dane, a nie kto autoryzuje działanie agenta.** Region, RODO i AI Act to warunki konieczne. To, co zatrzymuje propozycję agenta w kontekście biznesowym do czasu, aż obejrzy ją człowiek, jest osobną warstwą i nie kupuje się jej razem z modelem.
Jest jeszcze trzeci wątek, mniej wygodny dla każdej ze stron. Miejsce uruchomienia modelu jest jasne, ale dostrajanie i poprawki wprowadzane przez użytkowników z czasem tworzą osobny zasób. Gdzie mieszka ta nagromadzona wiedza, kto jest jej właścicielem i kto ma do niej dostęp - to pytania do rozstrzygnięcia w umowie, nie po jej podpisaniu.
Dostępność oferty dla klientów z Polski nie jest na dziś ogłoszona.
Źródła: ogłoszenie CTO SAP, [SAP News Center](https://news.sap.com/2025/11/sap-mistral-ai-new-alliance-european-sovereign-ai/), [ERP Today o suwerennym stosie AI dla Europy](https://erp.today/sap-is-building-a-sovereign-ai-stack-for-europe/).
---
## 3. Za co właściwie płacimy: pytanie, które w SAP wypadło z rozmowy
Głos z rynku klientów, nie materiał dostawcy, i dlatego wart odnotowania. Teza jest prosta. Duże organizacje budowały biznes wokół SAP przez dekady i wydały na to setki milionów. Ich środowiska bywają skomplikowane i niedoskonałe, ale w wielu wypadkach nadal skutecznie obsługują działalność. Tym samym firmom mówi się dziś, że przyszłością są S/4HANA, RISE, chmura, czysty rdzeń oraz odmienny model handlowy i techniczny.
Pytanie, które w tym pędzie wypadło: **za co dokładnie płacimy i jaką wartość przyrostową dostajemy w zamian.**
Autor nie odradza modernizacji i wskazuje wprost, że istnieją uzasadnione powody przejścia. Część organizacji skorzysta na architekturze, modelu danych i możliwościach AI. Kwestionuje domyślność tej ścieżki, a nie ją samą.
Z naszej perspektywy to jest właściwa kolejność rozmowy. Konwersja policzona przed wyborem wykonawcy daje projekt, który da się obronić przed zarządem. Konwersja zaczynana od terminu zostawia ten rachunek do wytłumaczenia później.
Źródło: publiczny wpis na LinkedIn, sierpień 2026. Materiał opinii, cytujemy tezę, nie liczby.
---
## 4. OpenAI wstrzymuje własny model z powodu zdolności ofensywnych
OpenAI wstrzymało część prac nad jednym z modeli po zidentyfikowaniu ryzyk związanych z zaawansowanymi zdolnościami w obszarze cyberbezpieczeństwa. Podczas testów model samodzielnie znajdował i wykorzystywał podatności w rzeczywistych systemach, bez udziału człowieka. Dostawca zgłosił sprawę i włączył agencje rządowe do przeglądu.
To nie jest odosobnione zdarzenie. W ciągu kilku tygodni model jednego dostawcy naruszył infrastrukturę serwisu z modelami, Anthropic raportowało zdarzenia tej samej klasy, a kolejny przypadek opisujemy w następnej pozycji. Wspólnym mianownikiem nie jest pojedyncza podatność. Jest nim **samodzielne wyjście agenta poza zamierzony zakres**.
Dla projektów agentowych zmienia to charakter jednego argumentu. Ograniczenie zakresu działania i izolacja wykonania przestały być ostrożnością konsultanta, a stały się odpowiedzią na zdolność udokumentowaną u kilku dostawców naraz, w odstępie kilku tygodni. Zwróćcie uwagę na kolejność zdarzeń: najpierw producenci wypuszczali coraz mocniejsze modele, a teraz sami zaczęli je przytrzymywać. Rachunek za autonomię wystawili sobie wcześniej niż klientom.
Źródło: [komunikat OpenAI o reakcji na krytyczne zdolności w obszarze cyberbezpieczeństwa](https://openai.com/index/responding-next-frontier-critical-cyber-capabilities). To stanowisko producenta, nie wynik niezależnego badania.
---
## 5. Model o otwartych wagach nie ma wyłącznika
Podczas oceny zdolności obronnych na benchmarku zbudowanym na szkielecie brytyjskiego AI Security Institute model Kimi K3 rozpoznał, że z piaskownicy da się sięgnąć do serwisu z repozytoriami kodu. Sklonował oficjalne repozytorium benchmarku i odczytał rozwiązania z dysku, zamiast rozwiązywać zadanie. Piaskownica blokowała ruch przychodzący, ale zostawiła otwarty ruch wychodzący na porcie 443 i 53 dla listy dozwolonych serwisów utrzymania pakietów - a na tej liście był GitHub.
O to, kto odpowiada za taką konfigurację, toczy się spór. Zgłaszający uważa, że ustawienia domyślne powinny być ostrzejsze, a prowadzący ocenę odpowiada, że dobór zabezpieczeń pod własny profil ryzyka należy do tego, kto uruchamia test.
Niezależnie od tego, jak ten spór się rozstrzygnie, sprawa opisuje różnicę, która jest faktem konstrukcyjnym, a nie doniesieniem. **Model hostowany i model o otwartych wagach dają w organizacji zupełnie inną pozycję wyjściową.** Usługa hostowana zwykle daje klucz, który da się odwołać, zapis użycia, warunki korzystania i możliwość zatrzymania dostępu. Przy modelu pobranym nie ma żadnej z tych rzeczy z definicji, a każda kopia pobrana przed ujawnieniem problemu i po nim jest identyczna.
Modele otwarte pozostają dobrym wyborem. Sami z nich korzystamy lokalnie, co opisujemy w pozycji dziewiątej, i w części zastosowań są jedyną sensowną odpowiedzią. Wymagają jednak, żeby brakujące kontrole **dobudować samemu**: filtrowanie ruchu wychodzącego, wydzielenie sieciowe, wąskie uprawnienia tożsamości, pod którą działa agent, oraz zapis tego, co agent faktycznie wywołał.
Jest też wniosek dla każdego, kto ocenia bezpieczeństwo AI u siebie. **Środowisko testowe jest częścią powierzchni ataku.** Jeżeli piaskownica użyta do oceny ma otwarty ruch wychodzący, wynik testu nie mówi nic o modelu. Mówi o dziurze w narzędziu.
Pytanie kontrolne dla zespołu na ten tydzień: czy w naszych potokach agentowych działa gdzieś model o otwartych wagach i kto zbudował dla niego kontrole, których on sam ze sobą nie niesie?
Źródła: [wpis Frontier Security z 7 sierpnia 2026](https://blog.frontier.security/chinese-model-kimi-k3-breaks-uk-ai-safety-institute-benchmark-evaluations/), relacje [Engadget](https://www.engadget.com/2232256/chinese-ai-kimi-k3-also-escaped-containment/) i [Quartz](https://qz.com/moonshot-kimi-k3-ai-sandbox-escape-080726).
---
## 6. Człowiek w pętli nie jest ładem
Standardową odpowiedzią na ryzyko AI jest zdanie „wstawmy człowieka w pętlę". Ono ukrywa najtrudniejszą część: **człowiek w pętli działa tylko wtedy, gdy pętla jest zaprojektowana.** Bez tego recenzent staje się jednym z trzech trybów porażki. Wąskim gardłem, gdy przegląd wyniku trwa tyle samo, co wykonanie pracy ręcznie. Pieczątką, gdy jest przeciążony, nie widzi dowodów i klika „zatwierdź", żeby kolejka szła dalej. Albo osobą, która ponosi konsekwencje bez realnej kontroli, bo instytucja wskazała odpowiedzialnego, ale nie dała mu ani czasu, ani uprawnień, ani możliwości zatrzymania systemu.
Prawdziwa bramka walidacyjna to interfejs weryfikacji, nie przycisk pauzy. Pokazuje **osiem rzeczy naraz**:
1. proponowane działanie,
2. źródła, na których się opiera,
3. sprawdzone reguły,
4. przejście biznesowe, które nastąpi,
5. użyte uprawnienie,
6. zapis audytowy, który powstanie,
7. niepewność albo wyjątek, który skierował sprawę do przeglądu,
8. dostępne wybory: zatwierdź, edytuj, odrzuć, eskaluj.
Każdy element ma powód. Działanie mówi, co system zamierza zrobić. Źródła mówią dlaczego. Reguły i uprawnienie pokazują, czy rekomendacja mieści się w polityce organizacji. Niepewność wyjaśnia, dlaczego ta praca w ogóle trafiła do człowieka. Razem zamieniają przegląd ze zgadywania w weryfikację. **Jeśli recenzent musi to wszystko odtworzyć samodzielnie, bramka nie została zbudowana.**
Drugi cel bramki jest jeszcze ważniejszy i prawie zawsze pomijany: przechwytywanie sądu. Kliknięcie „zatwierdź" bez patrzenia nie zapisuje nic użytecznego. Decyzja obejrzana, poprawiona, odrzucona albo eskalowana, razem z powodem, zapisuje sygnał, z którego kolejna wersja systemu może się uczyć. Po kilku miesiącach te sądy pokazują, gdzie polityki są niejasne, gdzie procesy regularnie się załamują i gdzie automatyzacja powinna być śmielsza albo mocniej ograniczona.
Stąd zdanie, które warto zapamiętać z całego tygodnia: **pętla nie jest zamknięta, dopóki przechwycony sąd czegoś nie zmieni.** Konsekwencja, która nie zmienia kolejnego przebiegu, jest incydentem, nie nauką.
Jak taka bramka wygląda w konkretnym narzędziu, opisaliśmy przy [bramkach HITL w UiPath Maestro](/pl/aktualnosci/blog/hitl-gate-uipath-maestro-ai-trust-layer/).
Źródło: [unite.ai, „Human in the Loop Is Not Governance"](https://www.unite.ai/human-in-the-loop-is-not-governance/), lipiec 2026, z odwołaniami do [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework), [zasad OECD](https://oecd.ai/en/ai-principles) i [badań RAND](https://www.rand.org/pubs/research_briefs/RBA4159-1.html).
---
## 7. UiPath: próg wejścia w agenty spadł do zera
Plan Community został przebudowany. Obejmuje teraz budowę agentów AI wizualnie w edytorze przeglądarkowym albo przez zestaw narzędzi programistycznych, pracę z agentami kodującymi, orkiestrację pełnych procesów w Maestro wraz z notacją procesową i zarządzaniem sprawami, jeden robot bezobsługowy, rozumienie dokumentów, agenta naprawczego oraz przepływy pracy oparte na interfejsach programistycznych. Do tego kredyty odświeżane co miesiąc i wspólne dla różnych funkcji.
Nowe rejestracje dostają nowy plan od razu. Konta istniejące zostają na obecnych licencjach, a migracja ma nastąpić w ciągu dziewięćdziesięciu dni. Ten termin warto zanotować, żeby zmiana nie zaskoczyła w trakcie prac.
Najważniejszą korzyścią jest możliwość zbudowania kompetencji, nie sama licencja. Zespół uczy się orkiestracji i pracy z agentami kodującymi bez konsumowania licencji produkcyjnych. Klient na wczesnym etapie może zobaczyć agenta w działaniu przed decyzją zakupową. A ponieważ plan obejmuje pracę z [agentami kodującymi](/pl/aktualnosci/blog/uipath-coding-agents-claude-codex-enterprise/), wejście w wątek, z którego przychodzi dziś najwięcej pytań, nie kosztuje nic poza czasem.
Jedna granica, którą stawiamy wyraźnie: **plan służy nauce i prototypom i nie jest ścieżką obejścia licencji produkcyjnych.** W projektach komercyjnych obowiązuje wyłącznie model Unified.
Źródła: komunikat UiPath do społeczności z sierpnia 2026 oraz notatki wydania Automation Cloud z 5 sierpnia 2026. Część funkcji producent oznacza jako wersję zapoznawczą.
---
## 8. Graf, który zapisuje, na jakiej podstawie system zdecydował
Pojawiło się otwarte narzędzie, które wciąga dane firmowe, buduje z nich graf kontekstu i prowadzi na nim rozumowanie deterministyczne, zapisując pochodzenie każdej decyzji. Deklarowany profil: własny hosting, audytowalność, standardy otwarte, brak przywiązania do dostawcy, dziedziny wysokiego ryzyka i regulowane.
Ten typ dowodu jest dokładnie tym, o co pytają NIS2, DORA i AI Act, i tym, czego w większości wdrożeń brakuje. Różnica jest zasadnicza: **rozumowanie, które da się powtórzyć, ma inną wartość dowodową niż odpowiedź modelu językowego.** Audytor nie pyta, co system odpowiedział. Pyta, na jakiej podstawie i czy da się to odtworzyć.
Zanim takie narzędzie trafi do organizacji regulowanej, są cztery pytania do zadania. Czy pochodzenie decyzji da się wyeksportować w formie zrozumiałej dla nietechnicznego audytora. Ile pracy modelarskiej wymaga ontologia na starcie. Jak często wychodzą nowe wydania. Ile jest realnych wdrożeń. Liczba gwiazdek w repozytorium mówi o popularności, nie o dojrzałości.
Źródło: [materiały projektu Semantica](https://github.com/semantica-agi/semantica). Opisujemy deklarowane możliwości, bez własnego testu.
---
## 9. Sto dwadzieścia jeden gigabajtów: granica lokalnego wdrożenia
W każdej rozmowie o suwerennym wdrożeniu pada to samo pytanie: czy da się u nas, na miejscu, bez wysyłania danych na zewnątrz. Odpowiedź brzmi: da się, pod warunkiem że wybór modelu zaczyna się od rachunku pamięci i przepustowości, a nie od nazwy z rankingu.
Na urządzeniu ze 121 GB pamięci wspólnej i przepustowością rzędu 273 GB/s szybkość generowania odpowiedzi wynika z przepustowości podzielonej przez liczbę aktywnych parametrów. Wniosek jest sprzeczny z intuicją: **wygrywają modele z rzadką aktywacją ekspertów, a nie największe modele gęste.** Gęsty model o siedemdziesięciu miliardach parametrów generuje odpowiedź wolniej, niż człowiek ją czyta, czyli około trzech żetonów na sekundę.
Co mieści się w tej pamięci. Model o 120 miliardach parametrów z rzadką aktywacją zajmuje około 63 GB i daje 56-60 żetonów na sekundę. Model 235-miliardowy w mocnej kwantyzacji mieści się na styk: 104 GB i około 15 żetonów na sekundę. Model programistyczny o 480 miliardach parametrów nie wchodzi, bo potrzebuje minimum 150 GB, więc zamiennikiem jest wersja 80-miliardowa.
Wniosek dla planującego lokalne wdrożenie jest jeden. Pierwszy dobór modelu robiony po popularności kończy się urządzeniem, na którym system działa poprawnie i bezużytecznie zarazem. Rachunek pamięci robi się przed zakupem, nie po. Jak to wygląda na konkretnej maszynie, opisaliśmy przy [teście Lenovo ThinkStation PGX z układem NVIDIA GB10](/pl/aktualnosci/blog/lenovo-thinkstation-pgx-gb10-test/).
Źródła: własny research na podstawie forów deweloperskich producenta, publicznych repozytoriów konfiguracyjnych i danych o rozmiarach kwantyzacji. Przepustowości podawane przez społeczność są punktem odniesienia, nie gwarancją wydajności w konkretnym środowisku.
---
## Co z tego wynika
Wszystkie dziewięć pozycji da się streścić jednym zdaniem: **narzędzie dostajecie jako gotowe, warstwę kontroli trzeba dobudować.**
Model jest częścią platformy, plan bez opłaty ma pełną funkcjonalność, wagi modelu są do pobrania, a łatka przychodzi razem z notą. Nie ma natomiast na żadnej fakturze wyłącznika, dowodu, inwentarza ani interfejsu weryfikacji, a to one decydują, czy system da się obronić przed audytorem i przed własnym zarządem.
Trzy pytania na ten tydzień:
1. Gdy nasz agent proponuje działanie, ile z ośmiu rzeczy widzi osoba, która to zatwierdza?
2. Czy w naszych potokach działa model o otwartych wagach i kto zbudował dla niego kontrole, których on sam ze sobą nie niesie?
3. Która pozycja z ostatniej paczki łatek wymaga inwentaryzacji zamiast instalacji i kto ją robi?
Jeżeli któreś z tych pytań nie ma u Was właściciela, to jest dokładnie ten koszt, o którym mowa w tytule.
Przegląd tygodnia SNOK · W33 · 7-13 sierpnia 2026
Całe wydanie w jednym pliku
PDF, 12 stron, ok. 1,8 MB - bez formularza i bez podawania danych. Wersja do przekazania dalej w zespole albo do przeczytania w telefonie.
Jeśli któryś z tych tematów dotyczy Was bezpośrednio - [bezpieczeństwo SAP](/pl/oferta/bezpieczenstwo-sap/), [orkiestracja i automatyzacja z agentami](/pl/oferta/automatyzacja-ai/) - [porozmawiajmy](/pl/kontakt/).
---
*Przegląd tygodnia to nasz cotygodniowy wybór z kilkuset pozycji radaru i kanałów RSS. Źródła podlinkowane przy każdym punkcie. Materiał informacyjny, nie stanowi porady prawnej.*
---
### Technologiczny Czwartek ze SNOK: rynek MDM stracił niezależnych dostawców. Co to zmienia w wyborze
URL: https://snok.ai/pl/aktualnosci/blog/sap-mdg-vs-informatica-mdm-po-przejeciach/ | Data: 2026-08-13 | Seria: Technologiczny Czwartek
Osiemnastego listopada 2025 Salesforce zamknął przejęcie Informatiki. Dwudziestego siódmego marca 2026 SAP ogłosił przejęcie Reltio, a siódmego maja transakcję sfinalizował. W pół roku dwie największe niezależne platformy do zarządzania danymi podstawowymi przeszły na własność dostawców platform aplikacyjnych.
Dla działu, który właśnie zawęża wybór rozwiązań MDM, to nie jest ciekawostka z branżowego serwisu. To zmiana pytania, na które trzeba odpowiedzieć przed podpisaniem umowy.
## Co się właściwie stało
Salesforce w komunikacie z listopada 2025 nie pozostawia wątpliwości co do kierunku: funkcje master data management Informatiki mają wzmocnić platformę Salesforce, a dane z MDM trafić jednym potokiem do Data 360, który dostarcza kontekst agentom Agentforce ([komunikat Salesforce, 18.11.2025](https://www.salesforce.com/news/press-releases/2025/11/18/salesforce-completes-acquisition-of-informatica/)).
SAP argumentuje podobnie, choć z drugiej strony stołu. Reltio ma przygotować dane z systemów SAP i spoza SAP na potrzeby zastosowań sztucznej inteligencji, jako element SAP Business Data Cloud ([news.sap.com, 27.03.2026](https://news.sap.com/2026/03/sap-to-acquire-reltio/) i [07.05.2026](https://news.sap.com/2026/05/sap-completes-acquisition-of-reltio/)). SAP zapowiada przy tym, że SAP Master Data Governance zostaje i będzie rozwijane, a oba produkty mają się uzupełniać. Portfolio Reltio pozostaje dostępne również samodzielnie.
W Magic Quadrant for Master Data Management Solutions firmy Gartner z 6 kwietnia 2026 w kwadrancie liderów znaleźli się między innymi Salesforce (Informatica), Reltio, Profisee, Semarchy i Stibo Systems. Dwie z tych nazw należą dziś do większych grup.
## Dlaczego to jest decyzja architektoniczna, a nie zakupowa
Przejęcie samo w sobie nie psuje produktu. Reltio nie przestało działać w maju, Informatica MDM nie zniknęła w listopadzie. Żaden z dostawców nie zapowiedział wygaszenia niczego i trzeba to powiedzieć wprost, zanim ktokolwiek zacznie panikować.
Rzecz w czymś innym. Plan rozwoju produktu, który należy do właściciela platformy aplikacyjnej, z czasem zaczyna odpowiadać na potrzeby tej platformy. To nasza ocena, nie zapowiedź któregokolwiek z dostawców, ale opiera się na tym, jak ten rynek zachowywał się po poprzednich przejęciach. Priorytety inwestycyjne idą tam, gdzie właściciel ma największy interes.
Dla organizacji, która stoi w całości na jednym ekosystemie, jest to wiadomość raczej dobra. Integracja będzie głębsza, a ścieżka prostsza.
Problem zaczyna się przy krajobrazie mieszanym, czyli w sytuacji, którą w polskich firmach widzimy najczęściej: SAP w rdzeniu, obok system branżowy przejęty razem ze spółką zależną, do tego hurtownia w chmurze i kilka aplikacji, które nie zamierzają zniknąć. Wtedy pytanie „czyj jest mój dostawca MDM” przestaje być pytaniem o wizerunek, a staje się pytaniem o to, czyje potrzeby będą obsłużone jako pierwsze w wydaniu za dwa lata.
## Czym różni się MDG od MDM
To pytanie wraca w każdej rozmowie i warto je rozstrzygnąć, bo skrótowość nazw wprowadza w błąd.
**Master data management (MDM)** to kategoria rozwiązań. Odpowiada na pytanie, jak z wielu rekordów opisujących tego samego kontrahenta, ten sam materiał czy tego samego pracownika uzyskać jeden wiarygodny rekord, i jak utrzymać go w spójności między systemami. To pojęcie obejmuje konsolidację, dopasowanie, deduplikację, reguły jakości i dystrybucję danych z powrotem do systemów źródłowych.
**SAP Master Data Governance (MDG)** to konkretny produkt SAP z tej kategorii, mocno zrośnięty z krajobrazem SAP. Nazwa akcentuje nadzór, czyli warstwę procesową: wnioski o zmianę danych, ścieżki akceptacji, reguły walidacji, ślad audytowy. MDG jest najsilniejsze tam, gdzie dane rodzą się i żyją w SAP.
Różnica praktyczna jest taka: MDM to problem, MDG to jedna z odpowiedzi. Bardzo dobra odpowiedź, jeśli krajobraz opiera się na SAP i organizacja jest gotowa na dyscyplinę procesową, którą MDG narzuca. Słabsza, gdy połowa danych powstaje poza SAP.
Warto przy tym rozróżnić jeszcze jedno pojęcie, które pada w tych rozmowach najczęściej. **Golden record** to nie produkt ani moduł. To wynik: jeden rekord uznany za obowiązujący, z historią zmian i wiedzą o tym, skąd pochodzi każde pole. Można go osiągnąć w MDG, w Reltio, w rozwiązaniu niezależnym albo w naszym. Nie kupuje się go razem z licencją, bo powstaje z reguł, które ktoś w organizacji musi rozstrzygnąć.
## Trzy pytania, które warto zadać przed wyborem
**Gdzie realnie rodzą się Wasze dane podstawowe?** Jeśli odpowiedź brzmi „w SAP i tylko w SAP”, ścieżka SAP jest naturalna. Jeśli zawiera spójnik „i”, warto sprawdzić, jak wybrane rozwiązanie traktuje systemy spoza rodziny właściciela. Nie w materiałach marketingowych, tylko na Waszych danych.
**Co się stanie, gdy zmieni się strategia platformowa?** Grupy kapitałowe przejmują spółki, a przejęte spółki przynoszą własne systemy. Rozwiązanie danych podstawowych ma przetrwać dłużej niż bieżąca mapa aplikacji, bo migracja modelu danych jest droższa niż migracja aplikacji.
**Kto w organizacji rozstrzygnie sporne reguły?** Najczęstsza przyczyna niepowodzenia programów danych podstawowych nie leży w technologii. Gartner szacował w grudniu 2021, że ponad 75% programów MDM nie osiągnie zakładanych celów biznesowych w horyzoncie 2025, i wskazywał na zakres oraz organizację, nie na wybór narzędzia. Jeśli nikt nie ma mandatu do rozstrzygnięcia, która wersja nazwy kontrahenta obowiązuje, żadna platforma tego nie zastąpi.
## Kiedy nasze podejście nie jest właściwe
Budujemy [SNOK MDM](/pl/produkty/snok-mdm/) jako warstwę golden record ponad systemami źródłowymi, bez wymiany ERP, z pilotem jednej domeny w cztery do ośmiu tygodni. Trzeba więc powiedzieć wprost, kiedy to nie jest dobry wybór.
Nie jest, gdy organizacja stoi w całości na jednym ekosystemie i strategicznie idzie w jego stronę. Wtedy natywne narzędzie tego ekosystemu wygra integracją i my sami będziemy to rekomendować, prowadząc projekt na SAP MDG.
Nie jest przy skali kilkudziesięciu milionów rekordów z wymaganiem dopasowywania w czasie rzeczywistym. To jest teren platform, które budowały ten mechanizm latami.
Nie jest wreszcie tam, gdzie nikt po stronie klienta nie ma czasu być opiekunem danych. Wdrożenie bez tej roli kończy się uporządkowaną kartoteką, w której bałagan wraca w kwartał.
> „Dane podstawowe to kręgosłup. Jeśli panuje w nich bałagan, najlepszy model AI wygeneruje śmieci szybciej i w większej ilości. Zaczynamy od porządków, nie od algorytmów”.
> — Kacper Wojciechowski, Team Leader Custom Development / AI, SNOK
## Co zrobić w najbliższym kwartale
Jeśli korzystacie z Informatica MDM albo Reltio, nie ma powodu do gwałtownych ruchów. Jest natomiast dobry moment, żeby wpisać do rejestru ryzyk pozycję o zależności od planu rozwoju nowego właściciela i wrócić do niej przy najbliższym odnowieniu umowy.
Jeśli wybór rozwiązania dopiero przed Wami, warto zmienić kolejność. Najpierw pomiar: ile realnie duplikatów jest w jednej domenie i ile kosztują rocznie. Dopiero potem zawężanie listy dostawców. Odwrotna kolejność zwykle prowadzi do platformy dobranej pod prezentację, a nie pod problem.
Opisaliśmy tę drogę szerzej w [felietonie o danych podstawowych po dwudziestu latach](/pl/aktualnosci/blog/dane-podstawowe-po-dwudziestu-latach/) oraz w [raporcie o stanie danych podstawowych w polskich przedsiębiorstwach](/pl/aktualnosci/blog/dane-podstawowe-w-polskich-przedsiebiorstwach-raport/). Zakres naszych prac w tym obszarze opisuje strona [Master Data Management](/pl/oferta/master-data-management/).
Jeżeli chcecie sprawdzić skalę problemu na własnych danych, zanim podejmiecie jakąkolwiek decyzję zakupową, [odezwijcie się do nas](/pl/kontakt/) - pomiar duplikatów w jednej domenie zajmuje kilka dni i nie wymaga zmian w Waszych systemach.
---
### SAP Patch Day sierpień 2026 - 31 not i jedno pytanie, którego nie zada nikt z IT
URL: https://snok.ai/pl/aktualnosci/blog/bezpieczny-wtorek-sap-patch-day-sierpien-2026/ | Data: 2026-08-11 | Seria: Bezpieczny Wtorek
Drugi wtorek miesiąca, SAP publikuje noty bezpieczeństwa, a w firmach z systemami SAP ktoś otwiera listę i zaczyna czytać. Sierpniowa paczka jest o połowę większa od lipcowej: **31 pozycji**, z tego 4 krytyczne, 8 wysokich, 17 średnich i 2 niskie. Na czele nota **3771065** (CVE-2026-58231, CVSS 10,0) - błąd autoryzacji w adapterze Data Hub dla SAP Commerce Cloud. To pierwsza nota z oceną 10,0 od początku 2026 roku.
Ocena 10,0 to sufit skali i nie bierze się z retoryki, tylko z wektora: atak przez sieć, bez uwierzytelnienia, o niskiej złożoności, ze zmianą zakresu i pełnym wpływem na poufność, integralność oraz dostępność. Po ludzku: jeżeli podatny adapter jest osiągalny, atakujący nie musi mieć konta, nie musi nikogo nakłonić do kliknięcia i nie zatrzymuje się na granicy komponentu. Nota dotyczy wersji COM_CLOUD 2211 oraz 2211-JDK21.
**W skrócie:**
**1/** nota 3771065 z oceną 10,0 dotyczy adaptera Data Hub w Commerce Cloud, czyli komponentu wystawionego na ruch z zewnątrz,
**2/** motywem miesiąca jest warstwa produkcyjna - **sześć not dotyczy SAP Manufacturing Integration and Intelligence**, w tym dwie krytyczne, a MII spina systemy SAP z halą produkcyjną,
**3/** ustawa o KSC liczy 24 godziny na wczesne ostrzeżenie i 72 godziny na zgłoszenie incydentu poważnego **od wykrycia** - nie od publikacji noty, co dla organizacji bez zdolności wykrycia jest złą, nie dobrą wiadomością,
**4/** wniosek o wpis do wykazu podmiotów kluczowych i ważnych składa się do 3 października 2026.
---
## Co wyszło 11 sierpnia
Pełna lista liczy 31 pozycji: 28 nowych not, jedno advisory GitHub i dwie aktualizacje not wcześniejszych. Poniżej pozycje, które w typowym landscape decydują o kolejności prac.
| Nota | CVE | CVSS | Komponent | Rzecz do zapamiętania |
|---|---|---|---|---|
| **3771065** | CVE-2026-58231 | **10,0** | Commerce Cloud (Data Hub Adapter) | Bez uwierzytelnienia, ze zmianą zakresu - pełne przejęcie |
| 3765948 | CVE-2026-44772 | 9,9 | Manufacturing Integration and Intelligence | Wstrzyknięcie kodu przez SSRF w transformacjach XSL |
| 3714806 | CVE-2026-34265 | 9,8 | NetWeaver AS ABAP / ABAP Platform | Uszkodzenie pamięci w protokole DIAG, łatka na poziomie jądra |
| 3758900 | CVE-2026-44758 | 9,1 | Manufacturing Integration and Intelligence | SAP usuwa podatny serwlet zamiast go naprawiać |
| 3772411 | CVE-2026-58243 | 8,8 | ABAP Developer Tools | Podniesienie uprawnień, zakres SAP_BASIS 750-920 |
| 3773203 | CVE-2026-42945 | 8,1 | Commerce Cloud | Wada w dołączonym NGINX, wymaga przebudowy aplikacji |
| 3756565 | CVE-2026-66763 | 7,9 | BusinessObjects BI (Central Management Server) | Sama łatka nie wystarcza, trzeba rotować poświadczenia |
| 3773304 | CVE-2026-58233 | 7,6 | Change and Transport System Attach Tool | Koniec wsparcia - narzędzie wycofane, kopie do usunięcia |
| 3786038 | CVE-2026-58230 | 7,0 | Business AI Platform (Approuter) | Jedna nota, jedenaście podatności |
Pełne zestawienie wszystkich 31 pozycji prowadzimy u siebie, razem z wektorami i wymaganymi czynnościami dodatkowymi.
Dwie rzeczy odróżniają ten miesiąc od lipca, w którym pozycji było 20, a najwyższa ocena wynosiła 9,9. Pierwsza to skala: paczka urosła o połowę. Druga jest ciekawsza - **rozkład komponentów przesunął się poza rdzeń ERP**. Sześć not dotyczy MII, pięć Commerce Cloud, a w sześciu pozycjach podatność w ogóle nie powstała w kodzie SAP, tylko w komponencie zewnętrznym: NGINX, Apache Log4j Core, Bouncy Castle, OpenSSL i libcurl w Adobe Document Services, pakiet pyodata z repozytorium PyPI oraz biblioteka używana przez narzędzie transportowe. Organizacja, która pilnuje wyłącznie poziomu łatki jądra i pakietów wsparcia, w sierpniu zamknie mniej niż połowę tego, co dostała.
## Lista not to nie zadanie techniczne
Przeczytanie kilkudziesięciu not zajmuje pół dnia. Ustalenie, które z nich dotyczą Waszych wersji, komponentów i poziomu jądra, zajmuje kilka dni pracy osoby, która zna landscape na pamięć. I to jest właśnie moment, w którym proces się załamuje - nie na etapie instalacji łatki, tylko na etapie decyzji, co w ogóle łatać.
Typowy przebieg wygląda tak. Ktoś przegląda listę i zaznacza pozycje krytyczne. Reszta trafia do rejestru z adnotacją, że zostanie oceniona przy najbliższym okienku serwisowym. Okienko przypada raz na kwartał, więc nota z oceną 8 z sierpnia realnie czeka do listopada. Nikt nie podjął złej decyzji - po prostu nikt nie miał czasu podjąć żadnej.
Sierpień daje wyjątkowo czysty przykład tego, jak taki proces gubi rzeczy ważne. Nota **3773304** dotyczy narzędzia ctsattach z rozszerzonego systemu transportowego i ma ocenę 7,6, więc przy zwykłej ocenie priorytetów ląduje w drugiej kolejności. Tyle że **wraz z jej wydaniem SAP zakończył wsparcie dla tego narzędzia**, a samo narzędzie nie jest już dostępne. Zalecenie brzmi: przestać go używać i usunąć wszystkie kopie ze wszystkich systemów; dodatkowe informacje zawiera nota 2473648. To jest czynność inwentaryzacyjna i organizacyjna, nie techniczna. Żaden proces zbudowany wokół pytania „czy pakiet jest zainstalowany" tej noty nie zamknie, bo remedium jest wycofanie, nie instalacja. A dotyczy warstwy, przez którą przechodzą wszystkie zmiany w drodze na produkcję. Drobna uwaga praktyczna: w sierpniowej tabeli SAP ta pozycja figuruje pod numerem 3727078, ale nota o tym CVE została opublikowana w lipcu pod numerem 3773304 i tego numeru trzeba szukać w SAP for Me. Numer 3727078 prowadzi do zupełnie innej noty - Directory Traversal w NetWeaver AS Java.
Drugi przykład tej samej kategorii to nota **3756565** w BusinessObjects. Poświadczenia były chronione zaszytym w kodzie kluczem, więc instalacja poprawki zamyka lukę na przyszłość, ale nie unieważnia tego, co mogło już wyciec. Bez rotacji poświadczeń zgodnie z KBA 3763536 system pozostaje w stanie, w którym raport z patchowania pokazuje zielone pole, a ryzyko trwa.
## Czego dokładnie wymaga od Was prawo
Ustawa o krajowym systemie cyberbezpieczeństwa w brzmieniu obowiązującym od 3 kwietnia 2026 nie zawiera przepisu „należy instalować łatki". Zawiera obowiązek stosowania środków adekwatnych do ryzyka oraz terminy zgłoszeń: **wczesne ostrzeżenie w 24 godziny, zgłoszenie incydentu poważnego w 72 godziny, sprawozdanie końcowe w miesiąc**. Wszystkie liczone od wykrycia.
Ta konstrukcja ma nieoczywistą konsekwencję. Organizacja, która nie potrafi wykryć wykorzystania luki, formalnie nie uruchamia zegara - i bywa, że traktuje to jako brak problemu. W postępowaniu wygląda to odwrotnie: nieznajomość własnego stanu jest dowodem na brak środków adekwatnych do ryzyka, a nie okolicznością łagodzącą. Kara dla podmiotu kluczowego sięga 10 mln EUR albo 2 % przychodu, dla podmiotu ważnego 7 mln EUR albo 1,4 %.
Znaczenie ma też to, gdzie w tym miesiącu leżą luki. Produkcja jest jednym z sektorów objętych ustawą, a MII to dokładnie ta warstwa, w której SAP styka się z halą. W wielu organizacjach ma osobnego właściciela, osobny cykl serwisowy i nie pojawia się na liście systemów objętych standardowym patchowaniem. Sześć not w jednym miesiącu, w tym dwie krytyczne, to dobry moment, żeby sprawdzić, czy ta warstwa w ogóle jest u Was w cyklu.
Do tego dochodzi warstwa danych osobowych. Jeżeli przez niezałataną lukę wyciekną dane z SAP, RODO daje 72 godziny na zgłoszenie do PUODO od stwierdzenia naruszenia, a artykuł 83 pozwala na kary do 20 mln EUR albo 4 % obrotu. Szczegóły terminów opisaliśmy w [osobnym wpisie o KSC i NIS2](/pl/aktualnosci/blog/ksc-nis2-sap-securitybridge/).
I jeszcze jedna data, o której łatwo zapomnieć w miesiącu wakacyjnym: **wniosek o wpis do wykazu podmiotów kluczowych i ważnych trzeba złożyć do 3 października 2026**. Wypełnienie go wymaga ustaleń, które w wielu firmach nie zapadły - kto jest właścicielem procesu, jakie systemy obejmuje zgłoszenie i kto podpisuje.
## Sprawdźcie, gdzie stoicie, zanim zapyta ktoś z zewnątrz
Zrobiliśmy narzędzie, które odpowiada na to pytanie bez spotkania, oferty i faktury. **SNOK KSC-CHECK to bezpłatne badanie gotowości systemów SAP na wymogi KSC i NIS2**: 25 pytań w 6 krokach, 5 obszarów, 8 do 12 minut. Wynik pojawia się od razu na ekranie, a raport PDF z planem na 30 dni i na 12 miesięcy przychodzi na wskazany adres.
Pięć obszarów badania to widoczność zdarzeń, wykrywanie i reakcja, podatności, tożsamość i dostęp oraz dowody dla audytu. Dzisiejszy wpis dotyka trzech pierwszych wprost. W obszarze podatności padają pytania o to, jak wygląda u Was ścieżka od publikacji noty do wdrożenia i kto ją prowadzi. W obszarze widoczności - czy Security Audit Log jest włączony dla krytycznych klas zdarzeń i czy ktokolwiek go czyta, bo sam włączony log niczego nie rozwiązuje. W obszarze wykrywania - czy zdarzenia z SAP trafiają do SIEM albo do SOC, bez czego zegar 24 godzin nie ma od czego wystartować. Obszar dowodów dla audytu ma osobną wagę, bo pierwszy audyt podmiotów kluczowych zaplanowany na 3 kwietnia 2028 będzie oceniał dowody z lat 2026 i 2027, czyli zbierane od teraz.
Jedna granica, którą stawiamy wprost: to samoocena, nie audyt i nie potwierdzenie zgodności. Badanie pokazuje, gdzie macie luki i co domknąć w pierwszej kolejności. Nie zastąpi przeglądu technicznego systemu ani decyzji prawnej o statusie podmiotu.
[Przejdźcie badanie KSC-CHECK](/pl/narzedzia/ksc-check/) - jeżeli po ośmiu minutach okaże się, że proces patchowania macie opisany, obsadzony i udokumentowany, to najlepszy możliwy wynik tego wpisu.
## Jak przestać zaczynać od zera każdego drugiego wtorku
Comiesięczne czytanie listy not to praca, którą da się wykonać raz i zautomatyzować. Warunek jest jeden: system musi znać Wasz landscape - wersje, komponenty, poziom jądra, zainstalowane pakiety.
Do tego służy **Patch Management w SecurityBridge**: opublikowane noty są automatycznie mapowane na konkretne systemy, więc zamiast listy kilkudziesięciu pozycji dla całego świata SAP dostajecie listę pozycji dla siebie, z priorytetem i stanem wdrożenia. Przy sierpniowej paczce różnica jest wyraźna - organizacja bez Commerce Cloud, bez MII i bez BusinessObjects może odłożyć większość tej listy, ale musi to wiedzieć na podstawie stanu systemów, a nie domysłu. Odwrotny przypadek jest gorszy: firma produkcyjna z MII ma w tym miesiącu sześć pozycji w komponencie, o którym często nikt nie pomyślał.
Patchowanie jest przy tym tylko jedną warstwą. Druga to kod, który powstaje u Was - o tym pisaliśmy wczoraj przy okazji [kodu ABAP generowanego przez AI](/pl/aktualnosci/blog/bezpieczenstwo-kodu-abap-generowanego-przez-ai/); w SecurityBridge odpowiada za nią Code Vulnerability Analysis. Trzecia to wykrywanie w czasie rzeczywistym, bez którego zegar 24 godzin nie ma od czego startować - opisaliśmy je przy [wycieku danych niewidocznym dla SIEM](/pl/aktualnosci/blog/wyciek-danych-sap-martwe-pole/), a odpowiada za nią Threat Detection wraz z integracją SIEM. Te trzy warstwy razem tworzą to, co regulator nazywa środkami adekwatnymi do ryzyka.
SNOK ma status [SecurityBridge Polska Premier Partner](/pl/securitybridge-snok/), więc wdrożenie i utrzymanie prowadzimy u siebie, w języku polskim i w polskiej strefie czasowej.
## Co zrobić w tym tygodniu
**1/** Sprawdźcie, czy macie SAP Commerce Cloud z adapterem Data Hub w wersjach 2211 lub 2211-JDK21, i potraktujcie notę 3771065 jako pozycję na dziś, nie na okienko serwisowe. Równolegle zróbcie inwentaryzację kopii narzędzia ctsattach - nota 3773304 jest domykana wycofaniem narzędzia, nie instalacją pakietu. Jeżeli prowadzicie produkcję na MII, sprawdźcie wersje XMII 15.4 i 15.5 wobec sześciu sierpniowych not.
**2/** Sprawdźcie, ile czasu minęło u Was od lipcowego Patch Day do wdrożenia lipcowych not krytycznych. Ta jedna liczba mówi o Waszym procesie więcej niż każdy dokument polityki bezpieczeństwa.
**3/** [Przejdźcie badanie KSC-CHECK](/pl/narzedzia/ksc-check/) i zabierzcie raport na najbliższe spotkanie zarządu. Termin 3 października dotyczy zarządu, nie działu IT.
Jeżeli po tych trzech krokach wyjdzie, że brakuje rąk albo narzędzi, [napiszcie do nas](/pl/kontakt/). Zaczynamy od przeglądu stanu faktycznego, nie od wyceny.
---
### Kod, którego nikt nie napisał. Jak zabezpieczyć ABAP w epoce asystentów AI
URL: https://snok.ai/pl/aktualnosci/blog/bezpieczenstwo-kodu-abap-generowanego-przez-ai/ | Data: 2026-08-10 | Seria: Inne
W większości systemów SAP, które audytujemy, kod własny powstawał przez lata i miał jedną wspólną cechę: dało się wskazać autora. Był człowiek, który go napisał, i człowiek, który go przejrzał, zanim paczka pojechała dalej.
Ta oczywistość właśnie przestała obowiązywać. Asystenci AI weszli do narzędzi deweloperskich SAP na dobre, a wraz z nimi do systemów zaczął napływać kod, którego w klasycznym sensie nikt nie napisał. Ktoś go zamówił, ktoś zaakceptował, ktoś zwolnił transport. Napisała go maszyna.
Ten artykuł jest o tym, co z takim kodem zrobić. Bez postulatu, żeby przestać używać AI, bo to postulat nierealny i szkodliwy. Za to z konkretną architekturą kontroli: gdzie postawić bramki, które z nich muszą blokować, a które tylko ostrzegać, i kto w tym układzie podpisuje się pod wynikiem.
## Co dokładnie się zmieniło
Zmiana ma trzy warstwy i każda z nich osobno byłaby do opanowania. Problem robi się z ich nałożenia.
**Warstwa narzędziowa.** SAP udostępnił SAP-ABAP-1, model fundamentalny wyszkolony na milionach linii kodu ABAP: obiektach standardowych, rozszerzeniach klientów, implementacjach BAdI i wzorcach ABAP Cloud. W materiałach SAP Community pada liczba ponad 250 milionów linii. Zasila on wyjaśnianie i generowanie kodu w Joule for Developers, obecnym w narzędziach deweloperskich w Eclipse i w SAP Business Application Studio. W 2026 doszło rozszerzenie ABAP dla Visual Studio Code. Do tego dochodzą asystenci ogólnego przeznaczenia, których deweloperzy używają niezależnie od tego, czy ktokolwiek to zatwierdził.
**Warstwa ludzka.** Skoro do napisania raportu nie trzeba już znać składni ani struktur, autorami kodu Z zostają osoby spoza zespołu deweloperskiego: konsultanci funkcjonalni, analitycy, juniorzy, użytkownicy biznesowi. Kompetencja procesowa jest tu często wyższa niż w zespole ABAP. Kompetencja bezpieczeństwa jest zerowa, i nie jest to zarzut wobec tych osób, tylko opis stanu.
**Warstwa architektoniczna.** Clean Core wypycha rozszerzenia z rdzenia na SAP BTP. Kierunek jest słuszny, ale skutek uboczny jest twardy: kod, który wcześniej siedział za zaporą sieciową, staje się aplikacją wystawioną w chmurze. Wniosek, który przewijał się przez wspólny webinar Deloitte i Onapsis o ryzykach kodu SAP tworzonego z AI, brzmi tu jednoznacznie: Clean Core bez przesunięcia kontroli bezpieczeństwa na początek procesu jest półśrodkiem.
Skala jest już policzona. Według badania Onapsis z czerwca 2026 na próbie 204 liderów bezpieczeństwa w firmach zatrudniających ponad tysiąc osób, **86 procent** organizacji zintegrowało albo właśnie integruje AI bezpośrednio z kodem systemów ERP, a **69 procent** przyznaje, że obecne zabezpieczenia nie wykryją niezawodnie ataku prowadzonego przez AI.
## Siedem mechanizmów, przez które asystent psuje kod ABAP
To nie jest lista hipotez. Sześć pierwszych punktów pochodzi wprost z analizy Deloitte i Onapsis, siódmy dokładamy z własnych audytów.
**1. Brak kontroli uprawnień.** Model generuje poprawną logikę biznesową i pomija `AUTHORITY-CHECK`, bo nie ma dostępu do Waszej koncepcji uprawnień. Nie wie, jakie obiekty autoryzacyjne obowiązują w tym module, ani że dostęp do konkretnej tabeli był decyzją, a nie przypadkiem. Efekt: raport działa i pokazuje dane każdemu, kto potrafi go uruchomić.
**2. Wstrzyknięcia w zapytaniach.** Zapytanie zbudowane dynamicznie z wartości podanej przez użytkownika to wzorzec, który w publicznym kodzie występuje setki tysięcy razy. Model odtwarza go razem z brakiem walidacji wejścia. Dotyczy to Open SQL, ADBC i wywołań natywnych.
**3. Podatności w warstwie interfejsu.** Poproszenie asystenta o dodanie nagłówka do funkcji renderującej daje kod, który wygląda i działa poprawnie, ale pomija kodowanie i sanityzację danych. Tak powstaje XSS w aplikacjach UI5 i Fiori. W demonstracji pokazanej na webinarze dokładnie ten scenariusz wychwycił dopiero skaner wpięty w edytor.
**4. Powielanie przestarzałych wad.** Model uczył się na kodzie historycznym, wraz z praktykami z czasów, gdy nikt nie myślał o wstrzyknięciach ani o bezpośredniej manipulacji tabelami. Wzorzec, który był normą piętnaście lat temu, wraca dziś jako świeżo wygenerowany kod.
**5. Halucynacje i widmowe zależności.** Odwołania do obiektów, parametrów i struktur, których w Waszym systemie nie ma. Część z nich wychodzi przy aktywacji. Część przechodzi dalej i ujawnia się dopiero na ścieżce, której nikt nie przetestował.
**6. Niekontrolowane operacje na danych.** Agent działający bez twardych ograniczeń potrafi wygenerować operację masową na tabelach bazodanowych. Bez wymuszonej akceptacji człowieka przed wykonaniem takiej operacji nie ma mechanizmu, który by ją zatrzymał.
**7. Rozjazd z rozdziałem obowiązków.** To dokładamy od siebie. Kod wygenerowany „przy okazji” przez osobę spoza zespołu deweloperskiego często omija ustalony proces: powstaje w systemie deweloperskim na cudzym koncie, trafia do transportu zbiorczego i przechodzi przez akceptację, która nigdy nie była projektowana pod ten scenariusz. Macierz SoD pozostaje formalnie poprawna, a praktyka rozjeżdża się z nią bezgłośnie.
Wspólny mianownik: **żaden z tych błędów nie zatrzymuje kompilacji i żaden nie oblewa testu funkcjonalnego.**
## Dlaczego dotychczasowe bramki tego nie łapią
Organizacje, z którymi pracujemy, zwykle mają jakąś formę kontroli kodu. Problem polega na tym, że wszystkie trzy klasyczne bramki zostały zaprojektowane pod inny rozkład ruchu.
**Przegląd kodu przez człowieka** zakłada, że kodu jest tyle, ile człowiek zdąży przeczytać. Apiiro policzył we wrześniu 2025, że deweloperzy korzystający z asystentów oddają kod trzy do czterech razy szybciej, a liczba znalezisk bezpieczeństwa w ich repozytoriach wzrosła w pół roku dziesięciokrotnie. Do tego dochodzi jakość: w badaniu CodeRabbit z grudnia 2025 na 470 pull requestach te współtworzone z AI miały **nawet 2,74 raza więcej znalezisk bezpieczeństwa** i **1,7 raza więcej problemów ogółem**. Rosnący wolumen razy rosnący odsetek błędów, przy niezmienionej liczbie recenzentów, daje wynik możliwy do przewidzenia bez żadnego badania.
**ATC i Code Inspector** działają, ale w domyślnych wariantach sprawdzają przede wszystkim jakość i zgodność ze standardem, a nie bezpieczeństwo. Pełna analiza podatności to osobno licencjonowana funkcja, w wielu systemach nieaktywna. Do tego uruchamiana bywa na żądanie, a nie jako warunek przejścia dalej.
**Testy funkcjonalne i UAT** weryfikują, czy program robi to, co miał robić. Nie weryfikują, czego jeszcze przy okazji nie robi. Brak kontroli uprawnień jest niewidoczny dla testera, który ma pełne uprawnienia.
Do tego dochodzi presja czasu. Rola dewelopera przesuwa się z pisania na walidację, ale liczba etatów na walidację się nie zmienia. Wąskie gardło nie znika, tylko przesuwa się w miejsce, w którym nikt go nie mierzy.
## Trzy warstwy obrony
Nasze podejście opiera się na jednej zasadzie: **kontrola, której obejście nie kosztuje, nie jest kontrolą.** Dlatego bramki muszą stać w miejscach, przez które kod i tak musi przejść. W systemach SAP takich miejsc jest dokładnie trzy.
### Warstwa pierwsza: edytor dewelopera
Podatność wykryta w edytorze kosztuje minutę. Ta sama podatność wykryta w UAT kosztuje przesunięcie wdrożenia. Wykryta na produkcji kosztuje incydent.
SecurityBridge Code Vulnerability Analysis daje deweloperowi wynik skanu tam, gdzie pracuje: w ABAP Development Workbench i w narzędziach ABAP dla Eclipse, z natywną integracją z SAP Code Inspector i ABAP Test Cockpit. Zestaw wykrywanych klas obejmuje dokładnie to, co produkuje asystent: wstrzyknięcia SQL, Open SQL i ADBC, brak kontroli uprawnień w modułach RFC, bezpośrednią manipulację tabelami, directory traversal i backdoory.
Dwie funkcje mają tu szczególne znaczenie przy kodzie generowanym maszynowo. **Explain ABAP Code** tłumaczy, co dany fragment realnie robi, czego najbardziej potrzebuje osoba, która tego kodu nie napisała, a ma go zaakceptować. **Describe Vulnerabilities** opisuje wykrytą podatność wraz ze sposobem naprawy, zamiast zostawiać deweloperowi numer reguły do wygooglowania.
To jest odpowiednik autokorekty: pisze się dalej, tylko z podkreśleniem tam, gdzie coś jest nie tak.
### Warstwa druga: transport
Tu zapada rozstrzygnięcie, bo transport to jedyne miejsce, którego w SAP nie da się ominąć.
SecurityBridge Transport Center dokłada do systemu transportów to, czego w standardzie nie ma. **Skan zawartości paczki jest warunkiem wstępnym importu**, więc transport z podatnością, której nikt nie naprawił, nie wjeżdża na kolejny system. Obieg akceptacji wymusza rozdział obowiązków i dokumentuje zatwierdzenie „na cztery oczy” w formie, którą da się pokazać audytorowi. Dochodzi do tego ochrona przed konfliktami wersji i wdrożeniem starszej wersji obiektu, przewidywanie brakujących zależności oraz porządkowanie list importowych przy złożonych przełączeniach produkcyjnych. Zakres funkcji potwierdzamy z producentem przed każdym wdrożeniem, bo portfolio zmienia się szybciej niż materiały informacyjne.
Ten sam mechanizm obsługuje przypadek, o którym mało kto myśli w kontekście AI: **kod od dostawców zewnętrznych**. Paczka od integratora albo od producenta dodatku przechodzi przez identyczną bramkę co kod własny.
### Warstwa trzecia: działający system
Skan statyczny nie wykryje nadużycia kodu, który przeszedł kontrolę. Dlatego warstwę trzecią stanowi ciągła detekcja: SecurityBridge Threat Detection monitoruje zachowanie systemu w czasie rzeczywistym, a zdarzenia trafiają do Waszego SIEM: Microsoft Sentinel, Splunk, QRadar albo innego narzędzia używanego w organizacji. Interface Traffic Monitor pilnuje warstwy interfejsów, przez którą kod niestandardowy zwykle rozmawia ze światem.
Dzięki temu wykrycie próby wykorzystania podatności może automatycznie uruchomić analizę kodu, który za nią odpowiada. Pętla się domyka: to, co dzieje się na produkcji, wraca informacją do warstwy pierwszej.
## Kto się podpisuje
Warstwa techniczna rozwiązuje problem wykrywania. Nie rozwiązuje problemu odpowiedzialności, a to on wraca na każdym spotkaniu zarządu.
Punktem wyjścia jest model współdzielonej odpowiedzialności, którego wciąż nie wszyscy przyjęli do wiadomości: dostawca chmury odpowiada za platformę, a **za własny kod i własne rozszerzenia odpowiadacie Wy**. W badaniu przywołanym na webinarze 13 procent uczestników sądziło, że po migracji do chmury odpowiedzialność za bezpieczeństwo przechodzi na SAP. Nie przechodzi. Nie przechodzi też na dostawcę modelu AI.
Cztery rzeczy, które ustawiamy u klientów po stronie ładu.
**Polityka użycia asystentów w wytwarzaniu.** Które narzędzia są dopuszczone, do jakich systemów, jakie dane wolno wkleić w prompt. Bez tego dokumentu każda dalsza kontrola jest uznaniowa.
**Oznaczanie kodu wspieranego przez AI.** Prosty atrybut przy obiekcie albo konwencja w opisie transportu. Nie po to, żeby kogokolwiek piętnować, tylko po to, żeby przegląd i późniejsza analiza incydentu miały punkt zaczepienia.
**Jednoznaczne znaczenie podpisu pod transportem.** Zwolnienie transportu musi znaczyć albo „przeczytałem i rozumiem kod”, albo „potwierdzam odbiór funkcjonalny”, i wszyscy muszą wiedzieć, które z tych dwóch. Dziś w większości organizacji nie wie tego nikt, łącznie z osobą podpisującą.
**Twarde bramki dla operacji nieodwracalnych.** Operacja masowa na danych, zmiana w obiekcie krytycznym, wdrożenie poza oknem serwisowym: to są przypadki, w których akceptacja człowieka musi być wymuszona technicznie, a nie oczekiwana proceduralnie.
Warstwa regulacyjna tylko to potwierdza. Dyrektywa NIS2 wymaga w art. 21 ust. 2 lit. e środków obejmujących bezpieczeństwo w procesie nabywania, rozwoju i utrzymania systemów, wraz z obsługą podatności. O sztucznej inteligencji przepis nie mówi ani słowa, ale kod własny powstaje właśnie w tym procesie, więc obowiązek bezpiecznego wytwarzania obejmuje go niezależnie od tego, kto trzymał klawiaturę. Udokumentowany proces skanowania i akceptacji jest najprostszym dowodem, że taki środek istnieje. Dla podmiotów finansowych analogiczne wymagania w zakresie zarządzania zmianą i testowania niesie DORA.
## Jak pracujemy w SNOK
Jesteśmy partnerem SecurityBridge w Polsce i prowadzimy ten temat od strony SAP Basis i bezpieczeństwa, a nie wyłącznie od strony licencji.
**Ocena stanu.** Zaczynamy od skanu istniejącej bazy kodu Z i od inwentaryzacji autorów obiektów z ostatnich miesięcy. Ta druga część bywa dla klientów najbardziej pouczająca, bo pokazuje, ile kodu powstaje poza zespołem deweloperskim. Wynikiem jest lista podatności uszeregowana według ryzyka biznesowego, nie według liczby trafień.
**Wdrożenie warstwy kontroli.** Uruchomienie analizy kodu w narzędziach deweloperskich, wpięcie skanu w proces transportowy jako warunku importu, konfiguracja progów blokowania oraz integracja zdarzeń z SIEM. Progi trzeba wykalibrować na Waszych danych. Bramka, która blokuje wszystko, zostaje wyłączona w trzecim tygodniu.
**Ład i kompetencje.** Polityka użycia AI w wytwarzaniu, model akceptacji transportów, warsztat dla zespołu deweloperskiego i konsultantów funkcjonalnych o tym, co konkretnie sprawdzać w kodzie, którego się nie napisało.
**Utrzymanie.** Cykliczny przegląd wyników, obsługa nowych podatności, wsparcie przy audycie oraz, dla organizacji bez własnego zespołu bezpieczeństwa SAP, model dyżurnego eksperta zamiast etatu.
## Plan na 30, 60 i 90 dni
**Do 30 dni.** Inwentaryzacja autorów obiektów Z za ostatnie półrocze. Skan istniejącej bazy kodu z raportem uszeregowanym według ryzyka. Jednozdaniowa decyzja o tym, co znaczy podpis pod transportem.
**Do 60 dni.** Analiza kodu dostępna w narzędziach deweloperskich. Skan jako warunek importu dla transportów na system testowy, na razie w trybie ostrzeżenia. Polityka użycia asystentów przyjęta i zakomunikowana.
**Do 90 dni.** Bramka blokująca dla systemu produkcyjnego, z progami skalibrowanymi na realnych danych z poprzedniego etapu. Zdarzenia z działającego systemu w SIEM. Udokumentowana akceptacja „na cztery oczy” gotowa do pokazania audytorowi.
## Na koniec
Kod generowany przez AI nie jest problemem sam w sobie. Problemem jest to, że powstaje szybciej, niż organizacja potrafi go przeczytać, i że w niczym nie różni się z wyglądu od kodu, który ktoś przemyślał.
Odpowiedzią nie jest zakaz, bo zakaz w tej sprawie oznacza po prostu przeniesienie tego samego zjawiska poza zasięg wzroku. Odpowiedzią jest przesunięcie kontroli do miejsc, których nie da się ominąć: do edytora, do transportu i do działającego systemu. Wtedy podpis pod transportem znów zaczyna coś znaczyć.
Jeśli chcecie sprawdzić, jak to wygląda w Waszym systemie, [odezwijcie się do nas](/pl/kontakt/). Zaczynamy zwykle od skanu istniejącej bazy kodu, bo to jedyna rozmowa o bezpieczeństwie, w której po tygodniu ma się na stole liczby zamiast opinii.
---
*Kontekst i szerszy obraz zmiany w zawodzie: [Kompiluje się, więc działa. ABAP w czasach, gdy kod pisze asystent](/pl/aktualnosci/blog/abap-kompiluje-sie-wiec-dziala/), felieton Jacka Bugajskiego.*
**Źródła:** Onapsis, State of AI, Security and ERP, badanie z czerwca 2026 na próbie 204 liderów bezpieczeństwa · CodeRabbit, State of AI vs Human Code Generation Report, 17.12.2025 (470 pull requestów; badanie dostawcy) · Apiiro, wrzesień 2025 · Veracode, GenAI Code Security Report, 2025 · dokumentacja produktowa SecurityBridge (Code Vulnerability Analysis, Transport Center, Threat Detection, Interface Traffic Monitor) · webinar Deloitte i Onapsis „The Hidden Risks of AI-Generated SAP Custom Code” · SAP i SAP Community, materiały o modelu SAP-ABAP-1 oraz Joule for Developers · dyrektywa NIS2, art. 21.
**Powiązane wpisy:** [Kod ABAP jako nieoczywiste zagrożenie bezpieczeństwa](/pl/aktualnosci/blog/bezpieczny-wtorek-ze-snok-kod-abap-nieoczywiste-zagrozenie-bezpieczenstwa-system/) · [KSC, NIS2 i SecurityBridge](/pl/aktualnosci/blog/ksc-nis2-sap-securitybridge/) · [Agent AI po obu stronach ataku](/pl/aktualnosci/blog/agent-ai-po-obu-stronach-ataku/)
---
### SecurityBridge z certyfikatem SAP dla S/4HANA Cloud Private Edition
URL: https://snok.ai/pl/aktualnosci/blog/securitybridge-certyfikacja-sap-s4hana-cloud-private-edition/ | Data: 2026-08-10 | Seria: Inne
SecurityBridge ogłosił w sierpniu, że jego platforma uzyskała certyfikowaną przez SAP integrację z SAP S/4HANA Cloud Private Edition. Certyfikat wystawiło SAP Integration and Certification Center. Brzmi jak komunikat dla działu marketingu producenta, ale dla firm prowadzących SAP w modelu RISE ma całkiem praktyczne przełożenie.
## Co dokładnie potwierdza certyfikat
SAP ICC potwierdziło, że oprogramowanie integracyjne SecurityBridge Platform 7 integruje się z SAP S/4HANA Cloud Private Edition przy użyciu standardowych technologii integracyjnych. Tyle mówi komunikat.
Po ludzku: platforma działa wewnątrz stosu ABAP, a komunikacja między systemem sterującym a systemami monitorowanymi idzie standardowymi protokołami SAP. Nie ma osobnej maszyny obok, nie ma agenta z zewnątrz, nie ma ruchu poza granicą systemu. Certyfikat jest formalnym potwierdzeniem tego stanu przez SAP, a nie deklaracją producenta w materiale sprzedażowym. To dwie różne kategorie wagi.
## Dlaczego akurat Private Edition
W S/4HANA Cloud Private Edition część warstwy technicznej prowadzi SAP, a odpowiedzialność za bezpieczeństwo jest dzielona. Dostawca odpowiada za infrastrukturę i utrzymanie platformy. Za to, co dzieje się wewnątrz systemu, odpowiada klient: uprawnienia, kod własny, parametry, interfejsy, konfiguracja bezpieczeństwa.
Ten podział zaskakuje wiele organizacji dopiero przy pierwszym audycie. Umowa z SAP nie oznacza, że ktoś patrzy za Was w logi aplikacyjne albo pilnuje not bezpieczeństwa w Waszym kodzie Z.
Do tego dochodzi kwestia prozaiczna. W środowisku prowadzonym przez dostawcę każdy dodatek instalowany w systemie przechodzi ustalenia z SAP. W projektach, w których wdrażamy [SecurityBridge](/pl/securitybridge-snok/), pytanie o zgodność dodatku ze standardem wraca regularnie. Certyfikat SAP ICC tych ustaleń nie zastępuje, ale zdejmuje ze stołu najczęstsze pytanie w tej rozmowie.
## Czego certyfikat nie mówi
Certyfikacja opisuje sposób integracji. Nie mówi nic o skuteczności wykrywania ataków ani o tym, że po instalacji SAP jest bezpieczny.
Platforma potrafi zbierać zdarzenia, wskazywać podatności i sprawdzać zgodność konfiguracji, a producent dokłada gotową zawartość bezpieczeństwa, żeby skrócić start. To działa. Nie działa natomiast samo z siebie: ktoś musi patrzeć w alerty, ktoś musi zdecydować, co jest incydentem, a co szumem, i ktoś musi wpiąć to w SIEM oraz w service desk, żeby zgłoszenie trafiło do właściwego zespołu, a nie do skrzynki zbiorczej.
Widzieliśmy systemy z pełną licencją i pustym procesem. Alerty leciały, nikt ich nie czytał. Certyfikat SAP tego nie naprawi.
## Co z tego mają obecni klienci SecurityBridge
Dobra wiadomość, i to bez gwiazdki. Jeśli już korzystacie z platformy, dostajecie mocniejszy argument w rozmowie z SAP i z audytorem: integracja jest potwierdzona przez SAP, nie tylko opisana przez producenta. Jeśli planujecie przejście na Private Edition, w projekcie ubywa jedna niewiadoma, a przy migracjach do RISE to zwykle te drobne niewiadome zjadają harmonogram.
Dwie rzeczy warto sprawdzić u siebie. Po pierwsze, na jakiej wersji platformy stoicie, bo certyfikat dotyczy Platform 7. Po drugie, czy zakres monitorowanych systemów obejmuje te, które przenosicie do chmury, czy tylko dotychczasowy landscape lokalny.
## Chętnie pokażemy, jak to wygląda w działaniu
SNOK jest partnerem SecurityBridge w Polsce. Wdrażamy tę platformę, utrzymujemy ją u klientów i znamy jej mocne strony oraz miejsca, w których wymaga pracy własnej zespołu.
Jeżeli chcecie zobaczyć konkret zamiast slajdów, [umówimy sesję pokazową](/pl/kontakt/): co platforma widzi w systemie SAP, jak wygląda ocena podatności, jak zdarzenie trafia do SIEM i ile z tego da się obsłużyć bez rozbudowy zespołu. Możemy też przejść przez to na przykładzie Waszego landscape'u i powiedzieć wprost, co ma sens, a co byłoby kupowaniem funkcji na zapas. Sesja trwa godzinę i nie kończy się ofertą, chyba że sami o nią poprosicie.
Jeśli wolicie najpierw zobaczyć własne liczby, zapraszamy do wypełnienia badania [SNOK KSC-CHECK](/pl/narzedzia/ksc-check/). To 25 pytań o Wasz landscape SAP i od 8 do 12 minut pracy. Wynik pokazujemy od razu na ekranie, raport PDF z terminami ustawowymi, lukami i planem działania wysyłamy na wskazany adres. Bezpłatnie.
**Źródła:** SecurityBridge, „SecurityBridge Platform Achieves SAP-Certified Integration with SAP S/4HANA Cloud Private Edition", Ingolstadt, sierpień 2026 · SAP Integration and Certification Center, sap.com/icc
**Powiązane wpisy:** [Audyt SAP ze SNOK i SecurityBridge](/pl/aktualnosci/blog/audyt-sap-firma-snok-i-securitybridge-tchna-w-was-spokoj-ducha/) · [Lenovo TruScale jako prywatna chmura pod RISE with SAP](/pl/aktualnosci/blog/technologiczny-czwartek-ze-snok-lenovo-truscale-prywatna-chmura-pod-rise-with-sa/) · [Bezpieczeństwo kodu ABAP generowanego przez AI](/pl/aktualnosci/blog/bezpieczenstwo-kodu-abap-generowanego-przez-ai/)
---
### Kompiluje się, więc działa. ABAP w czasach, gdy kod pisze asystent
URL: https://snok.ai/pl/aktualnosci/blog/abap-kompiluje-sie-wiec-dziala/ | Data: 2026-08-10 | Seria: Inne
Przez trzydzieści lat ABAP bronił się sam. Nie składnią, bo ta akurat wybacza wiele. Bronił się progiem wejścia.
Żeby napisać cokolwiek sensownego w systemie SAP, trzeba było najpierw zrozumieć słownik danych, koncepcję uprawnień, obiekty autoryzacyjne, logikę modułu, w którym się grzebie, i cały rytuał transportów przez trzy systemy. Ta wiedza nie leżała w dokumentacji. Leżała w głowach ludzi, którzy przeszli przez kilka wdrożeń i kilka nieudanych go-live. Przekazywało się ją przy biurku, nie z kursu.
I właśnie ten próg zniknął. Nie stopniowo, przez dekadę. W kilkanaście miesięcy.
## Co się zmieniło pod maską
SAP udostępnił model wyszkolony wyłącznie na ABAP-ie. SAP-ABAP-1 uczył się na milionach linii kodu ABAP: obiektach standardowych, rozszerzeniach klientów, implementacjach BAdI i wzorcach ABAP Cloud. W materiałach SAP Community pada liczba ponad 250 milionów linii. Zasila wyjaśnianie i generowanie kodu w Joule for Developers, wbudowanym w narzędzia deweloperskie w Eclipse i w SAP Business Application Studio. W 2026 doszło rozszerzenie ABAP dla Visual Studio Code, czyli dla edytora, w którym siedzi dziś połowa świata programistów spoza SAP.
Zwróćcie uwagę na kierunek tej zmiany. To nie jest tylko historia o szybszym narzędziu dla ABAPera. Żeby napisać w SAP coś, co się kompiluje i przechodzi test funkcjonalny, nie trzeba już być ABAPerem.
Raport napisze dziś konsultant funkcjonalny, który od piętnastu lat konfiguruje MM i nigdy wcześniej nie napisał ani linijki. Napisze go analityk z zespołu danych. Napisze go junior po trzech tygodniach w projekcie. Napisze go osoba z biznesu, która zna proces lepiej niż ktokolwiek w IT. Nie mam z tym najmniejszego problemu. Uważam nawet, że to dobra wiadomość, bo najlepsze rozszerzenia zawsze powstawały blisko procesu, a nie blisko kompilatora.
Problem jest gdzie indziej. Próg wejścia zniknął szybciej niż bramki, które sprawdzają, co przez ten próg przechodzi.
## Kompilacja nigdy nie była testem bezpieczeństwa
Kod, który wychodzi z asystenta, ma jedną cechę, która usypia czujność najskuteczniej ze wszystkich: on działa. Kompiluje się za pierwszym razem, przechodzi test funkcjonalny, robi dokładnie to, o co poprosiliście. Odbiór przez biznes wypada świetnie.
Tyle że kompilator w SAP nigdy nie sprawdzał tego, co w tym systemie naprawdę groźne.
Nie sprawdzał, czy przed odczytem danych kadrowych stoi `AUTHORITY-CHECK`. Nie sprawdzał, czy zapytanie zbudowane dynamicznie z wartości podanej przez użytkownika da się rozmontować wstrzyknięciem. Nie sprawdzał, czy moduł RFC, który właśnie udostępniliście, weryfikuje uprawnienia wywołującego. Nie sprawdzał, czy zapis idzie przez logikę aplikacji, czy prosto do tabeli, z pominięciem wszystkiego, co ktoś kiedyś zaprojektował. I na pewno nie sprawdzał, czy pole, które wyświetlacie w interfejsie, jest kodowane, zanim trafi do przeglądarki.
Model tych rzeczy nie pominął złośliwie. On ich po prostu nie wie. Nie zna Waszej koncepcji uprawnień, bo jej nigdzie nie widział. Nie zna Waszej macierzy rozdziału obowiązków. Nie wie, że akurat w tej spółce dostęp do tabeli płacowej ma osiem osób i że to była decyzja zarządu, a nie przypadek. Widzi wzorzec z milionów linii cudzego kodu i odtwarza go z pełnym przekonaniem.
Wraz z tym wzorcem odtwarza też jego wady. Model uczył się na kodzie historycznym, razem z praktykami z czasów, gdy nikt nie myślał o wstrzyknięciach. Bywa też, że wymyśla obiekty, których nie ma, i parametry, których nigdy nie było. Kod wygląda wtedy dokładnie tak samo jak dobry. To jest właśnie ta część, która niepokoi mnie najbardziej: różnicy nie widać z zewnątrz.
## Liczby, które warto mieć w głowie
CodeRabbit przejrzał w grudniu 2025 470 pull requestów z projektów otwartych: 320 współtworzonych z AI i 150 pisanych wyłącznie przez ludzi. Te pierwsze miały **nawet 2,74 raza więcej znalezisk bezpieczeństwa** i **1,7 raza więcej problemów w ogóle**: logiki, wydajności, utrzymywalności. To badanie dostawcy narzędzia do przeglądu kodu, na projektach otwartych, więc traktujcie je jak wskazówkę, nie jak wyrok.
Kierunek potwierdzają jednak inni. Veracode przebadał ponad 100 modeli na 80 zadaniach programistycznych: kod z podatnością wychodził w **45 procentach** przypadków, a w Javie w 72. Apiiro policzył w firmowych repozytoriach coś jeszcze wymowniejszego: deweloperzy z asystentem oddają kod trzy do czterech razy szybciej, a liczba znalezisk bezpieczeństwa w tych repozytoriach wzrosła w pół roku **dziesięciokrotnie**.
Tu leży sedno. Asystent nie pisze gorzej od człowieka. Pisze znacznie więcej, a liczba osób, które ten kod czytają, nie zmieniła się o jedną.
Onapsis, pytając w czerwcu ponad dwustu liderów bezpieczeństwa, usłyszał z kolei, że **86 procent** firm wpuszcza albo właśnie wpuszcza AI bezpośrednio w kod systemów ERP, i jednocześnie **69 procent** przyznaje, że ich obecne zabezpieczenia nie wykryją niezawodnie ataku prowadzonego przez AI.
Na koniec liczba, która robi z tego temat operacyjny, a nie akademicki. Onapsis w badaniach nad atakami na systemy SAP mierzył, ile czasu mija od wystawienia niezabezpieczonej aplikacji SAP w chmurze do jej wykrycia i zaatakowania. **Poniżej trzech godzin.**
## Clean Core podniósł stawkę
Tu dochodzimy do rzeczy, która w tej układance często umyka.
Przez lata kod Z siedział wewnątrz Waszych czterech ścian. Napisany byle jak, ale za zaporą sieciową, w systemie, do którego dostęp miało kilkadziesiąt osób. Podatność w takim raporcie była realna, tylko trudno osiągalna.
Clean Core zmienił geografię. Rozszerzenia wychodzą z rdzenia na BTP i stają się aplikacjami w chmurze. To jest słuszny kierunek architektoniczny i sam go klientom rekomenduję. Ale jego skutkiem ubocznym jest to, że ten sam kod, napisany z tą samą starannością, wisi teraz w internecie. Ten sam wniosek przewijał się przez wspólny webinar Deloitte i Onapsis o ryzykach kodu SAP tworzonego z AI: Clean Core bez przesunięcia kontroli bezpieczeństwa na początek procesu jest półśrodkiem.
Zestawcie to z trzema godzinami z akapitu wyżej.
## Kto się podpisze
I tak dochodzimy do jedynego pytania, które naprawdę mnie w tej sprawie interesuje.
W SAP mamy coś, czego nie ma większość świata IT: fizyczny, imienny moment odpowiedzialności. Ktoś zwalnia transport. Ktoś inny importuje go na produkcję. Oba nazwiska zostają w logu i nie da się ich z tego logu wyjąć. Ten mechanizm powstał w czasach, gdy zwolnienie transportu znaczyło: przeczytałem, rozumiem, biorę to na siebie.
Dziś coraz częściej znaczy: zaakceptowałem propozycję, której nie przeczytałem, bo było jej za dużo i wyglądała rozsądnie.
Podpis się nie zmienił. Zmieniło się jego pokrycie.
Rola ABAPera przesuwa się przy tym z pisania na walidację i to jest zmiana zdrowa. Kłopot w tym, że gdy zespoły oddawały pisanie maszynie, nikt nie dołożył im etatów na czytanie. Wąskie gardło się nie rozpuściło, tylko przesunęło o jeden krok w prawo, tam, gdzie akurat nikt nie patrzy. A pod presją terminu odpuszcza się zawsze to, czego brak nie boli od razu. Bezpieczeństwo jest w tej konkurencji bez szans, bo jego brak zaczyna boleć średnio kilka miesięcy później.
Karanie kogokolwiek za to niczego nie zmieni. Zmieni to dopiero sytuacja, w której podpisujący **wie**, co podpisuje.
## Da się to opanować
Piszę o tym spokojnie, bo znam drugą stronę tej historii. Skan kodu wpięty w transport zatrzymuje paczkę z brakiem kontroli uprawnień albo ze wstrzyknięciem, zanim ta ruszy na kolejny system. Deweloper widzi podatność w edytorze, w tej samej minucie, w której powstała, a nie na trzy dni przed wdrożeniem.
W SNOK opieramy to na SecurityBridge. Obserwuję ten produkt praktycznie od początku istnienia firmy i to jeden z niewielu przypadków, gdy narzędzie bezpieczeństwa dla SAP rośnie razem z platformą, zamiast dreptać rok za nią. Dobre oprogramowanie, robione przez ludzi, którzy rozumieją SAP od środka. Jak to poukładać warstwa po warstwie, opisaliśmy osobno.
## Trzy rzeczy na poniedziałek
Nie mam dla Was manifestu, mam trzy rzeczy do zrobienia od razu.
**Sprawdźcie, kto dziś pisze u Was kod w SAP.** Nie w strukturze organizacyjnej, tylko w systemie. Lista autorów obiektów Z za ostatnie półrocze potrafi być zaskakująca i to jest najtańsza diagnoza, jaką znam.
**Wpiszcie skan bezpieczeństwa w transport, nie w kalendarz.** Kontrola, która odbywa się „raz na kwartał”, w praktyce nie odbywa się wcale. Kontrola, bez której paczka nie wjedzie na kolejny system, odbywa się zawsze.
**Ustalcie, co znaczy Wasz podpis pod transportem.** Jedno zdanie w polityce, po którym każdy zwalniający wie, czy potwierdza przeczytanie kodu, czy tylko odbiór funkcjonalny. Dziś w większości firm nie wie tego nikt, łącznie z tym, kto podpisuje.
Bo asystent nie stanie przed audytorem. Nie odbierze telefonu w niedzielę, gdy okaże się, że raport, który miał pokazywać stany magazynowe, przy okazji czytał całą tabelę kadrową bez jednej kontroli uprawnień.
Odbierzecie go Wy.
## Pobierzcie felieton w PDF
Felieton Jacka Bugajskiego · sierpień 2026
Kompiluje się, więc działa
PDF, 11 stron, ok. 6,5 MB - wersja do czytania offline, bez formularza i bez podawania danych. Możecie ją swobodnie przekazać dalej w zespole.
---
*Jak to zabezpieczyć warstwowo, gdzie postawić bramki i jak wygląda to w praktyce z SecurityBridge, opisaliśmy szczegółowo w osobnym artykule: [Kod, którego nikt nie napisał. Jak zabezpieczyć ABAP w epoce asystentów AI](/pl/aktualnosci/blog/bezpieczenstwo-kodu-abap-generowanego-przez-ai/).*
**Źródła:** CodeRabbit, State of AI vs Human Code Generation Report, 17.12.2025 (470 pull requestów; badanie dostawcy) · Veracode, GenAI Code Security Report, 2025 · Apiiro, wrzesień 2025 · Onapsis, State of AI, Security and ERP, badanie z czerwca 2026 na próbie 204 liderów bezpieczeństwa · Onapsis Threat Research, badania nad atakami na aplikacje SAP · webinar Deloitte i Onapsis „The Hidden Risks of AI-Generated SAP Custom Code” · SAP i SAP Community, materiały o modelu SAP-ABAP-1 oraz Joule for Developers.
**Warto przeczytać u nas także:** [Kod ABAP jako nieoczywiste zagrożenie bezpieczeństwa](/pl/aktualnosci/blog/bezpieczny-wtorek-ze-snok-kod-abap-nieoczywiste-zagrozenie-bezpieczenstwa-system/) · [Trzy akty SAP AI i pytanie, którego nie było na slajdach](/pl/aktualnosci/blog/trzy-akty-sap-ai-bezpieczenstwo-agentow/) · [Testowanie SAP i problem zaufania do release](/pl/aktualnosci/blog/testowanie-sap-problem-zaufania-do-release/)
---
### Przegląd tygodnia W32: co narzędzie potrafi, a co może wykonać
URL: https://snok.ai/pl/aktualnosci/blog/snok-weekly-digest-w32-co-narzedzie-potrafi-a-co-moze-wykonac/ | Data: 2026-08-07 | Seria: Inne
Siedem pozycji tygodnia 31 lipca - 6 sierpnia 2026, z komentarzem, co każda zmienia w Waszych systemach.
W tym tygodniu trzy niezależne środowiska - organizacja standaryzacyjna, firma badawcza i dostawca oprogramowania dla przedsiębiorstw - opisały to samo zjawisko z trzech różnych stron. Nikt się nie umawiał. OWASP przesunął nadmiar samodzielności modelu na trzecie miejsce listy ryzyk. Red Hat policzył, ile firm ma nad tym realny nadzór, i wyszło mu trzydzieści jeden procent. SAP napisał, że decyzje o uprawnieniach agentów należą do zarządu.
Pytanie, które z tego wynika, jest w gruncie rzeczy stare i wcale nie dotyczy sztucznej inteligencji. Brzmi: kto ustalił, co temu narzędziu wolno. Nowe jest tylko to, że narzędzie zaczęło działać samo, a odpowiedź na to pytanie rzadko bywa przypisana konkretnej osobie.
Do tego dwie pozycje o tym, co agenty zaczynają realnie robić w automatyzacji, jeden polski wyciek i jeden atak, na który nie ma dziś dobrej odpowiedzi.
---
## 1. OWASP Top 10 dla aplikacji LLM: nowa edycja przestała opisywać obawy
4 sierpnia ukazała się edycja 2026 listy dziesięciu najpoważniejszych ryzyk w aplikacjach opartych na dużych modelach językowych. To pierwsza edycja, w której ranking powstał ze zderzenia dwóch źródeł: głosów praktyków oraz zapisu realnych incydentów. Autorzy nazywają tę różnicę wprost - to luka między tym, czego branża się boi, a tym, na czym już się sparzyła.
Trzy ruchy warto znać na pamięć.
**Excessive Agency, czyli nadmiar samodzielności, awansowało na trzecie miejsce.** Nie dlatego, że ktoś zmienił zdanie, tylko dlatego, że tam lądują szkody. Model dostał narzędzia i zaczął ich używać szerzej, niż ktokolwiek zaplanował.
**Unbounded Consumption poszło w górę o cztery pozycje.** Niekontrolowany koszt tokenów przestał być pozycją w budżecie, a stał się ryzykiem bezpieczeństwa. W wielu firmach ta zmiana nie została jeszcze odzwierciedlona w podziale odpowiedzialności - rachunek za model i raport z incydentu trafiają zwykle do dwóch różnych osób.
**Improper Output Handling spadło z piątego na dziesiąte, ale z poszerzonym zakresem** - obejmuje teraz niebezpieczny kod generowany masowo przez asystentów. Spadek w rankingu nie znaczy, że problem zniknął.
Jest jeszcze jedno rozgraniczenie, ważniejsze od samej kolejności. Ta lista opisuje ryzyko, gdy model jest **komponentem** wewnątrz aplikacji. W momencie, gdy staje się **aktorem** - ma narzędzia, które sam wywołuje, pamięć przenoszoną między sesjami i wywołuje skutki dalej w dół procesu - ryzyko przechodzi do osobnej listy, OWASP Top 10 for Agentic Applications. Autorzy piszą wprost, że wiele incydentów siedzi dokładnie na granicy i żadna z list nie pokrywa jej samodzielnie.
Praktyczny wniosek: jeżeli w projekcie agentowym ktoś powołuje się wyłącznie na listę dla LLM, ma połowę obrazu.
Równolegle powstał AISVS 1.0 - pierwszy testowalny standard weryfikacji bezpieczeństwa systemów AI, z poziomami dojrzałości i rozdziałami poświęconymi orkiestracji agentów oraz odporności na atak. Różnica jest zasadnicza. Lista ryzyk mówi, czego się bać. Standard mówi, co sprawdzić i jak udowodnić, że zostało sprawdzone.
Źródła: [OWASP GenAI](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/), dokument z 4.08.2026, licencja CC BY-SA 4.0; omówienie w [Help Net Security](https://www.helpnetsecurity.com/2026/08/06/owasp-2026-llm-top-10-released/), 6.08.2026.
---
## 2. Trzydzieści jeden procent
Red Hat opublikował badanie z trzema liczbami, które warto czytać razem, bo dopiero rozstęp między nimi coś mówi.
**92 %** organizacji deklaruje, że wie, gdzie przechowywane są dane wykorzystywane przez AI.
**49 %** ma nad tymi danymi pełną kontrolę.
**31 %** wdrożyło dojrzałe mechanizmy nadzoru nad agentową AI.
Spadek z dziewięćdziesięciu dwóch do czterdziestu dziewięciu to różnica między „wiemy" a „możemy coś z tym zrobić". Spadek z czterdziestu dziewięciu do trzydziestu jeden to coś innego - to różnica między kontrolą techniczną a ładem organizacyjnym. Ta druga luka jest trudniejsza, bo nie kupuje się jej razem z licencją.
Autorzy badania jako sprawdzian dojrzałości wskazują coś, czego nie sposób udawać: zdolność do zmiany dostawcy modeli lub platformy bez zakłócenia działalności. Formalną strategię wyjścia ma **63 %** firm, a **30 %** nie przygotowało jej wcale. W tej drugiej grupie 14 % zakłada, że migracja byłaby łatwa - co samo w sobie jest ciekawym pomiarem optymizmu.
Do momentu pierwszego wdrożenia agentowego nadzór jest zdaniem w polityce. Nasza obserwacja z projektów jest taka, że prawdziwy sprawdzian przychodzi w dniu, w którym agent dostaje uprawnienia do systemu produkcyjnego i ktoś musi rozstrzygnąć, co wolno mu zrobić bez pytania.
Uczciwie: badanie pochodzi od dostawcy platformy, która ma ten problem rozwiązywać. To nie unieważnia liczb, ale każe je czytać jako pomiar zrobiony przez zainteresowanego.
Badanie ukazało się dzień po pierwszym progu obowiązków AI Act. Zbieg okoliczności, ale wymowny.
Źródło: badanie Red Hat w relacji [ITwiz](https://itwiz.pl/tylko-31-firm-skutecznie-nadzoruje-agentowa-ai/), 3.08.2026. Raportu źródłowego Red Hat nie odnaleźliśmy w otwartym dostępie - liczby cytujemy za relacją.
---
## 3. UiPath Maestro Case: liczby, które warto znać
Wcześni użytkownicy modułu Maestro Case raportują skrócenie średniego czasu obsługi sprawy o **60-80 %** i **trzy do pięciu razy** więcej spraw domykanych bez interwencji człowieka.
Jedno zastrzeżenie, zanim te liczby pójdą dalej: dotyczą wczesnych wdrożeń wybranych i opisanych przez producenta. To górna granica tego, co da się osiągnąć w procesie dobrze dobranym do narzędzia. Nie średnia i nie obietnica.
Ciekawsze od procentów jest to, czego dotyczą. Maestro Case zarządza sprawą, nie zadaniem. Różnica ma znaczenie praktyczne. Zadanie ma początek, koniec i robota. Sprawa potrafi żyć tygodniami, przechodzić przez kilka systemów i kilka par rąk, a po drodze zatrzymywać się na każdym etapie, który wymaga [czyjegoś potwierdzenia](/pl/aktualnosci/blog/hitl-gate-uipath-maestro-ai-trust-layer/). Klasyczna automatyzacja świetnie radzi sobie z zadaniem i staje dokładnie w tych momentach, w których sprawa czeka.
Procesy, w których takie liczby się powtarzają, mają wspólną cechę: dużo spraw, powtarzalne decyzje, dane rozrzucone po kilku systemach. Obsługa szkód. Helpdesk kadrowy. Zatwierdzenia w przepływach SAP.
I odwrotność, o której trzeba powiedzieć: jeżeli w firmie nie ma jeszcze zautomatyzowanych zadań, warstwa orkiestracji nie ma czym zarządzać. Maestro nie zastępuje pierwszego kroku.
Źródło: [komunikat UiPath dla inwestorów](https://ir.uipath.com/news/detail/455/uipath-introduces-maestro-case-to-orchestrate-dynamic-exception-heavy-business-processes-across-the-enterprise).
---
## 4. Autopilot przestał podpowiadać, zaczął budować
Autopilot w UiPath Studio Desktop jest przedstawiany jako pełny agent kodujący: ma planować, budować, uruchamiać, diagnozować, wyjaśniać i przebudowywać automatyzacje. Podgląd publiczny, dostępny od linii STS S195 wzwyż. Jakości wyniku na realnym projekcie klienckim jeszcze nie znamy i piszemy o tym wprost.
Lista zapowiadanych możliwości jest dłuższa, ale trzy pozycje pokazują skalę zmiany. Dostaje trzydziestostronicową specyfikację procesu wdrożenia pracownika i buduje z niej kompletną automatyzację razem z krokami interfejsu. Bierze wdrożone zadanie, które o trzeciej w nocy zgłosiło odmowę dostępu, i sprowadza awarię do brakujących uprawnień robota. Dostaje działanie, które przestało działać po zmianie w aplikacji, nazywa przyczynę i naprawia selektor.
To ostatnie jest właśnie tym, co odróżnia go od [agenta ogólnego przeznaczenia](/pl/aktualnosci/blog/uipath-coding-agents-claude-codex-enterprise/). **Agenty ogólne nie wiedzą, czym jest selektor.** Autopilot wie, bo działa wewnątrz Studio, na tych samych umiejętnościach co reszta platformy, z repozytorium obiektów w zasięgu. Automatyzacja interfejsu, czyli rdzeń klasycznego RPA, działa u niego od pierwszego dnia, a u agentów zewnętrznych bywa najsłabszym ogniwem.
Druga różnica dotyczy nadzoru i będzie ważniejsza w rozmowie z Waszym działem bezpieczeństwa niż lista funkcji. W granicach miesięcznego limitu nie jest potrzebna osobna subskrypcja ani rozliczenie za tokeny. Nie trzeba też zakładać konta u zewnętrznego dostawcy ani pilnować dodatkowych kluczy. Działania niszczące są bramkowane, poziom samodzielności ustawia administrator, zdarzenia trafiają do dziennika audytowego. Studio zostaje warstwą wizualną - każdą zmianę da się otworzyć, obejrzeć i zdebugować.
Trzy zastrzeżenia, bez których ta pozycja byłaby materiałem reklamowym. To podgląd publiczny, nie wersja ogólnie dostępna - nie stawia się na tym harmonogramu projektu. Miesięczny limit użycia nie został podany liczbowo, więc zanim padnie zdanie o braku dodatkowych kosztów, trzeba go ustalić dla konkretnej licencji. I rzecz najprostsza: klienci korzystający z linii LTS, czyli wydań z długoterminowym wsparciem, tej funkcji nie zobaczą.
Źródło: [forum UiPath](https://forum.uipath.com/t/autopilot-just-became-a-coding-agent-in-studio-desktop/5759250), ogłoszenie z 7.07.2026.
---
## 5. Żabka: weszli przez dostawcę, wynieśli mapę
4 sierpnia Żabka Polska potwierdziła nieuprawniony dostęp do wybranych zasobów technicznych poprzez konto zewnętrznego dostawcy usług. Incydent wykryto pod koniec poprzedniego tygodnia. Niezależnie na forum przestępczym pojawiła się oferta sprzedaży rzekomo wykradzionego zbioru za **5 000 EUR**: zgłoszenia z systemu Jira, repozytoria kodu, informacje o użytkownikach. Zakresu firma nie ujawniła, a opis zbioru pochodzi od napastnika, nie od poszkodowanego.
Najciekawsza w tej historii jest cena wywoławcza. Pięć tysięcy euro to niewiele, co sugeruje, że sam napastnik nie uważa łupu za spektakularny. Jeżeli jego opis jest prawdziwy, sięgnął po materiał z kategorii, którą w większości firm klasyfikuje się jako techniczną, a nie wrażliwą.
Warto się zastanowić, co realnie leży w zgłoszeniach systemu zadań. Zrzuty konfiguracji wklejone w komentarzu, żeby kolega zobaczył błąd. Adresy systemów. Nazwiska i role osób znających poszczególne integracje. Opis tego, co konkretnie się psuje i od kiedy. Razem daje to mapę środowiska napisaną przez ludzi, którzy znają je najlepiej. Repozytoria dokładają szczegóły integracji, a w gorszym wariancie poświadczenia zostawione w historii zmian.
Formalnie mogą tu mieć zastosowanie dwa reżimy: obowiązki wynikające z RODO, w tym termin siedemdziesięciu dwóch godzin na zgłoszenie, oraz - jeżeli podmiot kwalifikuje się jako ważny - obowiązki z ustawy o krajowym systemie cyberbezpieczeństwa.
Dwa pytania warto zadać sobie, zanim zada je ktoś inny. Do których naszych zasobów ma dziś dostęp każdy z dostawców. I co się stanie, jeżeli któryś z nich zadzwoni jutro rano z informacją o swoim incydencie. Umowa powierzenia odpowiada na pierwsze pytanie tylko wtedy, gdy ktoś ją od podpisania czytał.
Źródła: [Sekurak](https://sekurak.pl/potencjalny-wyciek-danych-z-zabki/), [CRN](https://crn.pl/aktualnosci/cyberatak-i-kradziez-danych-z-zabki-zabka/), [ITwiz](https://itwiz.pl/cyberatak-na-zabke-haker-oferuje-dane-firmy-za-5-tys-euro/), [The Record](https://therecord.media/poland-convenience-store-chain-zabka-cyberattack).
---
## 6. SAP nazwał rozrost agentów problemem zarządu
3 sierpnia SAP opublikował artykuł o zjawisku, które nazwał rozrostem agentów: organizacje wdrażają agentów szybciej, niż budują mechanizmy ich nadzoru. Zdanie z materiału: „As adoption of AI agents accelerates, governance is struggling to keep pace".
Teza idzie dalej niż diagnoza techniczna. Decyzje o uprawnieniach agentów są decyzjami o ryzyku biznesowym, więc należą do zarządu, nie do zespołu utrzymania. Producent pozycjonuje przy okazji własne warstwy jako odpowiedź, co jest naturalne i co warto sobie od razu powiedzieć.
W systemie ERP stawka wygląda inaczej niż w narzędziu marketingowym. Tam błąd agenta kosztuje kampanię. Tu agent działa na danych, na których stoi zamknięcie miesiąca, rozliczenie z dostawcą i deklaracja podatkowa. Zmiana wprowadzona przez agenta może wywołać skutek księgowy - i tym bardziej musi zostawiać ślad w dzienniku audytowym. [Pisaliśmy o tym szerzej przy bezpieczeństwie agentów w SAP](/pl/aktualnosci/blog/trzy-akty-sap-ai-bezpieczenstwo-agentow/).
Dochodzi rzecz specyficzna dla tego środowiska. Uprawnienia w SAP buduje się latami, warstwa po warstwie, i rzadko ktoś potrafi z pamięci powiedzieć, co dokładnie może użytkownik techniczny, z którego uprawnieniami działa integracja. Agent, który dostaje uprawnienia „takie jak istniejąca integracja", dziedziczy cały ten bagaż razem z tym, o czym wszyscy zapomnieli.
Pytanie na najbliższy przegląd: ilu agentów działa dziś w Waszym krajobrazie SAP, kto zatwierdził ich uprawnienia i czy tę listę da się odtworzyć bez odpytywania trzech osób. Jeżeli zebranie odpowiedzi zajmie tydzień, to jest dokładnie ten rozrost, o którym pisze SAP.
Źródło: [news.sap.com](https://news.sap.com/2026/08/agent-sprawl-why-ai-governance-is-now-board-level-issue/), 3.08.2026.
---
## 7. Strona podsuwa instrukcję, agent ją wykonuje. Czy umiemy się przed tym bronić?
Zostawiliśmy na koniec pozycję, przy której odpowiedź brzmi „nie w sposób, który zamyka temat".
Niezależne zespoły badawcze pokazują od kilkunastu miesięcy, że przeglądarki z wbudowanym asystentem dają się przejąć bez jednego kliknięcia użytkownika. Mechanizm jest banalny i właśnie dlatego groźny.
Asystent czyta stronę tym samym strumieniem tekstu, którym czyta Wasze polecenie. Napastnikowi wystarczy ukryć w treści kilka zdań sformułowanych jak instrukcja - białym drukiem na białym tle albo w akapicie, który agent i tak ma streścić. Asystent bierze te zdania za polecenie i wykonuje je. Nikt w nic nie klika. Wystarczy wpuścić agenta na przygotowaną stronę.
Skutki opisywane w badaniach idą dalej niż kradzież danych. Jeden ze scenariuszy podsuwa agentowi stronę udającą, że wymaga zalogowania, żeby przechwycić poświadczenia. Inny steruje tym, jakie informacje agent zbiera i do jakiego wniosku dochodzi - to jest atak nie na dane, lecz na rekomendację, którą agent Wam poda. Producenci dokładają zabezpieczenia, badacze obchodzą je po kolei i wprost piszą, że idealnej naprawy nie widać.
> **Nota o liczbie, która krąży po sieci.** W obiegu jest wskaźnik 86 % skuteczności takiego ataku. Sprawdziliśmy go i nie potwierdza się w formie, w jakiej jest powtarzany: pochodzi z wcześniejszego opracowania (zestaw WASP, 2025) i opisuje częściowy sukces wstrzyknięcia polecenia, a nie odsetek udanych fałszywych logowań. Dlatego go tu nie podajemy jako faktu. Mechanizm jest udokumentowany i sam w sobie wystarczy - liczba nie jest tu potrzebna.
### Dlaczego nie ma tu łatki
Powody są konstrukcyjne, nie wynikają z niedopatrzenia któregoś dostawcy.
Po pierwsze, agent ma **jedne drzwi dla treści i dla poleceń**. Jeden kanał wejściowy na tekst do przeczytania i na rozkaz do wykonania, bez pewnego sposobu odróżnienia, bo oba są zwykłym tekstem.
Po drugie, **zniknął człowiek z pętli**. To człowiek zwykle wyłapywał dziwne polecenie, zanim je wykonał. Agent działający samodzielnie usuwa ten moment. Zostaje sam tekst i sama akcja, a razem z nimi znika chwila, w której ktokolwiek mógł powiedzieć: chwila, tego nie zlecałem.
Stąd wniosek wart zapamiętania: **kontrola na wejściu tego nie wyłapie**, bo atak wygląda dokładnie jak treść, którą agent miał przeczytać. Widać go dopiero po tym, co agent robi.
### Co da się zrobić dzisiaj
Cztery rzeczy. Żadna nie jest rozwiązaniem, wszystkie razem ograniczają zasięg szkody.
**Obserwować zachowanie zamiast filtrować wejście.** Skoro atak jest nieodróżnialny na wejściu, budżet idzie na warstwę nadzoru i wykrywanie odstępstw od zamierzonej trajektorii, nie na kolejny klasyfikator poleceń. Klasyfikator da się obejść - to już przerabialiśmy przy wcześniejszych podatnościach tej rodziny.
**Postawić bramkę na działaniach nieodwracalnych.** Płatność, wysyłka, zmiana uprawnień, usunięcie danych - wszystko, czego nie da się cofnąć, wymaga potwierdzenia człowieka. To jest miejsce, w którym wstawia się z powrotem usunięty moment.
**Dać agentowi węższe uprawnienia niż użytkownikowi.** Jeżeli odpowiedź na pytanie „do czego agent może sięgnąć po przejęciu" brzmi „do wszystkiego, do czego ma dostęp użytkownik", to jest zła odpowiedź.
**Odizolować środowisko.** Agent sterujący przeglądarką pracuje w wydzielonym środowisku, nie na stacji roboczej zalogowanej do systemów produkcyjnych.
Na koniec rzecz, którą wypada powiedzieć o sobie: korzystamy z narzędzi przeglądarkowych sterowanych agentem. Ta sama klasa ryzyka dotyczy nas, nie tylko naszych klientów, i traktujemy ją tak samo.
---
## Co z tego wynika
Siedem pozycji, jeden wspólny mianownik. Lista ryzyk przesuwa nadmiar samodzielności w górę. Badanie pokazuje, że dojrzały nadzór ma mniej niż co trzecia firma. Dostawca ERP mówi, że to sprawa zarządu. Dwie pozycje o automatyzacji pokazują, ile ta samodzielność realnie daje, gdy jest dobrze obudowana. Wyciek przypomina, że granica firmy dawno przestała biec po jej infrastrukturze. A ostatni temat mówi wprost, że w jednym miejscu nie mamy dziś dobrej odpowiedzi.
Jeżeli mielibyśmy zostawić Was z jednym pytaniem na poniedziałek, brzmiałoby ono tak: **kto w Waszej firmie podpisuje się pod zakresem uprawnień agenta - imiennie, nie stanowiskiem w polityce.** Reszta jest wykonalna, gdy ta odpowiedź istnieje. Bez niej każda kolejna pozycja z tej listy jest tylko wiadomością z branży.
Jeśli któryś z tych tematów dotyczy Was bezpośrednio - nadzór nad agentową AI, [bezpieczeństwo SAP](/pl/oferta/bezpieczenstwo-sap/), [orkiestracja i automatyzacja z agentami](/pl/oferta/automatyzacja-ai/) - [porozmawiajmy](/pl/kontakt/).
---
*Przegląd tygodnia to nasz cotygodniowy wybór z kilkuset pozycji radaru i kanałów RSS. Źródła podlinkowane przy każdym punkcie. Materiał informacyjny, nie stanowi porady prawnej.*
---
### Technologiczny Czwartek ze SNOK: Document Understanding 26.7 - dokumenty wchodzą do coded workflows
URL: https://snok.ai/pl/aktualnosci/blog/uipath-document-understanding-26-7-coded-workflows/ | Data: 2026-08-06 | Seria: Technologiczny Czwartek
W Technologicznym Czwartku ze SNOK bierzemy jedną technologię i sprawdzamy, co realnie zmienia w pracy naszych klientów. Dziś: nowy preview Document Understanding, który na pierwszy rzut oka wygląda jak lista drobnych usprawnień - a w praktyce domyka trzy luki architektoniczne, o które potykały się zespoły budujące przetwarzanie dokumentów na skalę enterprise.
Wersje, o których mowa: UiPath.DocumentUnderstanding.Activities 3.4.0-preview, UiPath.PDF.Activities 4.4.0-preview i UiPath.IntelligentOCR.Activities 7.4.0-preview, plus Public Preview modeli IXP jako zasobów w Solutions ([release notes IXP z 23 lipca 2026](https://docs.uipath.com/ixp/automation-cloud/latest/release-notes/ucd-july-2026)). Po kolei.
## Luka pierwsza: dokumenty były uwięzione w XAML
Do tej pory klasyfikacja i ekstrakcja dokumentów żyły w świecie wizualnych workflow. Zespoły, które piszą automatyzacje w C# - z pętlami, LINQ, obsługą wyjątków i testami jednostkowymi - musiały na czas pracy z dokumentami wracać na kanwę.
Od 26.7 pakiety DU i PDF wystawiają swoje możliwości jako serwisy dostępne wprost w coded workflows. Serwis `du` obsługuje klasyfikację, ekstrakcję danych i artefakty walidacji z człowiekiem w pętli; serwis `pdf` całą skrzynkę narzędziową: odczyt tekstu, liczenie i dzielenie stron, scalanie plików, wyciąganie załączników i konwersje do PDF. Kompletny przepływ "sklasyfikuj, potem wyciągnij dane" to teraz kilkanaście linii C#, bez jednego pliku XAML.
Dlaczego to ważne właśnie teraz? Bo kod jest językiem, w którym najsprawniej poruszają się agenty kodujące. Pisaliśmy niedawno, [jak coding agents zmieniają pracę zespołów UiPath](/pl/aktualnosci/blog/uipath-coding-agents-claude-codex-enterprise/) - i przetwarzanie dokumentów było dotąd białą plamą na tej mapie. Po tym wydaniu agent może wygenerować, przetestować i utrzymywać logikę dokumentową tak samo, jak każdy inny kod.
Jedno zastrzeżenie z praktyki, potwierdzone w dyskusji pod ogłoszeniem: mechanizm suspend/resume (persistence) nie działa wewnątrz coded workflows. Walidację z udziałem człowieka projektujcie więc tak, żeby artefakty walidacyjne powstawały w kodzie, ale samo zawieszenie procesu działo się poza nim - inaczej architektura zaskoczy Was na testach integracyjnych, nie wcześniej.
## Luka druga: model żył innym życiem niż automatyzacja
Każdy, kto wdrażał Document Understanding przez środowiska dev-test-prod, zna ten ból: workflow jedzie w pakiecie solution, a model ekstrakcji trzeba przenosić i konfigurować osobno, środowisko po środowisku.
W Public Preview modele IXP stają się zwykłym zasobem solution: widać je w Resource Explorer w Studio Web, są pakowane i wersjonowane razem z resztą, a przy wdrożeniu jadą tam, gdzie cała paczka. Aktywności Extract Document Data i Document Understanding Project Extractor dostały przełącznik "Use Solution Resource" - zaznaczacie, wybieracie model i lifecycle modelu jest od tej chwili tym samym lifecyclem, co automatyzacji.
To brzmi jak detal, ale właśnie takie detale decydują, czy [agent albo automatyzacja dojedzie z PoC na produkcję](/pl/aktualnosci/blog/od-pomyslu-do-agenta-na-produkcji/) - governance i powtarzalność wdrożeń to zwykle trudniejsza połowa projektu niż sama ekstrakcja.
## Luka trzecia: pipeline zaczynał się od "gotowego" PDF
Rzeczywistość skrzynki wpływowej wygląda inaczej: faktura przychodzi jako treść maila, raport jako HTML, potwierdzenie jako czysty tekst. Trzy nowe aktywności - Convert Email to PDF, Convert HTML to PDF i Convert Text to PDF - normalizują te formaty do PDF, czyli do postaci, której oczekuje reszta pipeline'u. Działają w projektach Windows i cross-platform, ze wspólnym zestawem opcji renderowania.
Wzorzec, który to otwiera: trigger mailowy, konwersja wiadomości do PDF, ekstrakcja danych - kompletna ścieżka od skrzynki do ustrukturyzowanych danych bez ręcznych kroków pośrednich.
Osobny, mocny klocek to aktywność Extract Attachments From PDF (dostępna od pakietu PDF 4.3.0 z końca czerwca), która wyciąga z dokumentu załączone pliki XML. To codzienność e-fakturowania: obieg krajowy przeszedł na ustrukturyzowany XML w KSeF, ale od dostawców zagranicznych wciąż przychodzą faktury hybrydowe typu ZUGFeRD czy Factur-X - PDF z wszytym XML. Teraz zamiast OCR-ować obraz takiej faktury, wyjmujecie z niej gotowe dane strukturalne jedną aktywnością.
## Bonus dla zespołów compliance: redakcja per pole
Aktywność Redact Document dostała publiczny argument `RedactionOptions`, czyli granularną kontrolę nad tym, jak redagowane jest każde pole z osobna: pełne zamalowanie albo przekreślenie, kolor i przezroczystość, a do tego kody redakcyjne nadrukowywane na zaczernionych obszarach - dokładnie tak, jak robi się to w praktyce kancelaryjnej i audytowej. Wpis z pustym identyfikatorem pola działa jak reguła domyślna dla wszystkich fraz ze wskazanej listy.
Dla firm pracujących z danymi osobowymi to konkret: anonimizacja dokumentów przestaje być osobnym, ręcznym etapem i staje się polityką zapisaną w automatyzacji.
## Co z tym zrobić
To wydanie Preview - UiPath wprost rekomenduje ocenę w środowiskach nieprodukcyjnych i my się pod tym podpisujemy. Sensowny plan na najbliższe tygodnie wygląda tak:
1. **Zinwentaryzujcie miejsca, gdzie dokumenty wchodzą do procesów** - szczególnie te, gdzie dziś ktoś ręcznie zapisuje maile do PDF albo przepisuje dane z faktur hybrydowych.
2. **Jeżeli macie zespół piszący w C# lub pracujący z coding agents** - postawcie pilota z serwisami `du` i `pdf` na jednym realnym typie dokumentu, z walidacją człowieka zaprojektowaną poza coded workflow.
3. **Jeżeli wdrażacie DU przez Solutions** - przetestujcie modele IXP jako zasoby solution na ścieżce dev-test; to najkrótsza droga do powtarzalnych wdrożeń.
Jako partner Platinum UiPath [pomagamy przejść tę drogę](/pl/oferta/automatyzacja-ai/) - od przeglądu strumienia dokumentów, przez architekturę, po produkcję z governance, które przejdzie audyt. [Napiszcie do nas](/pl/kontakt/), jeżeli chcecie zobaczyć te mechanizmy na własnych dokumentach.
---
### Lenovo ThinkStation PGX w praktyce: przetestowaliśmy komputer AI z NVIDIA GB10
URL: https://snok.ai/pl/aktualnosci/blog/lenovo-thinkstation-pgx-gb10-test/ | Data: 2026-08-05 | Seria: Inne
Rzadko piszę o sprzęcie. Tym razem robię wyjątek, bo przez nasz lab przeszła maszyna, która zmienia sposób myślenia o firmowym AI - i zdążyliśmy ją porządnie przećwiczyć, zanim pojechała dalej, do klienta.
Mowa o Lenovo ThinkStation PGX: korporacyjnym wariancie klasy urządzeń zbudowanych na superchipie NVIDIA GB10 Grace Blackwell, czyli tej samej rodziny co NVIDIA DGX Spark. Z zewnątrz wygląda jak elegancki mini-pecet. W środku jest coś, co jeszcze dwa lata temu wymagało szafy serwerowej: komputer zaprojektowany wyłącznie pod rozwój i uruchamianie sztucznej inteligencji.
## Co siedzi w środku
Konfiguracja, którą testowaliśmy, wygląda tak (pełna specyfikacja: [Lenovo Press](https://lenovopress.lenovo.com/lp2321-thinkstation-pgx)):
- superchip **NVIDIA GB10 Grace Blackwell** - CPU i GPU w jednym układzie,
- **20 rdzeni ARM** (10x Cortex-X925 + 10x Cortex-A725),
- GPU **NVIDIA Blackwell** z Tensor Cores 5. generacji,
- **128 GB pamięci LPDDR5X unified** - współdzielonej przez CPU i GPU, o przepustowości 273 GB/s,
- dysk NVMe do 4 TB z szyfrowaniem sprzętowym,
- sieć 10 GbE plus karta ConnectX-7 i Wi-Fi 7,
- system **NVIDIA DGX OS** (Ubuntu na ARM64),
- a wszystko zasilane zasilaczem o mocy 240 W - mniej, niż potrafi pobrać jedna gamingowa karta graficzna.
Kluczowa liczba to 128 GB pamięci unified. W klasycznej stacji roboczej model językowy musi zmieścić się w pamięci karty graficznej, a to zwykle 24-48 GB. Tutaj CPU i GPU dzielą jedną, wspólną pulę - więc na maszynie wielkości książki uruchamiacie modele, które dotąd wymagały serwera z kartami za kilkaset tysięcy złotych.
## Co na nim uruchomiliśmy
Nie testowaliśmy benchmarkami dla samych benchmarków. Postawiliśmy kompletne środowisko pracy, takie, jakie realnie stawia się u klienta:
- **backend wnioskowania** (Ollama i vLLM) serwujący modele przez standardowy, zgodny z OpenAI endpoint,
- **[Hermes Agent](https://hermes-agent.ai)** od Nous Research - open-source'owy agent, który łączy się z tym endpointem, wykonuje zadania narzędziami i buduje własną pamięć,
- zestaw modeli lokalnych: **gpt-oss-120b** jako flagowy generalista, **Qwen3-Coder 30B** do kodu i pracy agentowej oraz **gpt-oss-20b** do szybkich, tanich zadań.
Największe wrażenie robi pierwsza z tych pozycji. Model o 120 miliardach parametrów - klasy, która jeszcze niedawno była zarezerwowana dla chmury - działa lokalnie, płynnie i z sensownym czasem odpowiedzi (realna prędkość zależy przy tym mocno od silnika wnioskowania - zoptymalizowany stos potrafi być kilkukrotnie szybszy od ustawień domyślnych). W architekturze Mixture-of-Experts na każdy token aktywna jest tylko część parametrów, więc mimo rozmiaru model w kwantyzacji MXFP4 zajmuje około 60-65 GB i zostawia zapas na długi kontekst.
## Trzy lekcje z testów
**Po pierwsze: MoE bije dense.** Duże modele o gęstej architekturze (na przykład Llama 70B) mieszczą się w pamięci bez problemu, ale w pojedynczej rozmowie są wolne - przepustowość 273 GB/s to naturalna granica, co potwierdzają także [publiczne benchmarki](https://presenc.ai/research/local-llm-tokens-per-second-benchmarks-2026). Modele Mixture-of-Experts omijają tę granicę z gracją. Dobór architektury modelu ma na tej maszynie większe znaczenie niż sam rozmiar.
**Po drugie: to maszyna dla agentów, nie dla jednego czatu.** Przewaga GB10 ujawnia się przy wielu równoległych zapytaniach - dokładnie tak pracują agenty AI i pipeline'y przetwarzania dokumentów. W trybie wsadowym urządzenie osiąga wielokrotnie wyższą łączną przepustowość niż w pojedynczej rozmowie. Jeśli planujecie [wdrażać agentów na produkcję](/pl/aktualnosci/blog/od-pomyslu-do-agenta-na-produkcji/), to jest sprzęt skrojony pod ten scenariusz.
**Po trzecie: pełny offline naprawdę działa.** Cały łańcuch - model, agent, narzędzia, pamięć - pracuje bez jednego pakietu wysłanego do internetu. Dla firm z danymi pod NDA, danymi osobowymi albo wymaganiami regulacyjnymi (NIS2, DORA) to nie jest ciekawostka, tylko odpowiedź na pytanie, które słyszymy najczęściej: "jak korzystać z AI, żeby nasze dane nie wyjechały z organizacji?". Pisaliśmy o tym podejściu przy okazji [fabryki AI dla SAP bez chmury](/pl/aktualnosci/blog/technologiczny-czwartek-ze-snok-jak-zbudowalismy-fabryke-ai-dla-sap-bez-chmury/) - PGX to ten sam kierunek, tylko w formacie, który stawia się na biurku w godzinę.
## Dla kogo to jest
Po tych testach widzimy trzy naturalne zastosowania:
1. **Poufne AI na własnych danych.** Analiza dokumentów, kodu i danych, które nie mogą opuścić organizacji - lokalny model plus RAG na wewnętrznej bazie wiedzy.
2. **Środowisko deweloperskie zespołów AI.** Prototypowanie agentów i pipeline'ów bez licznika kosztów API - po zakupie sprzętu koszt krańcowy wnioskowania wynosi zero.
3. **Pierwszy krok do prywatnej infrastruktury AI.** Zanim zainwestujecie w pełną [prywatną chmurę pod obciążenia enterprise](/pl/aktualnosci/blog/technologiczny-czwartek-ze-snok-lenovo-truscale-prywatna-chmura-pod-rise-with-sa/), na PGX sprawdzicie na realnych danych, czy lokalne modele udźwigną Wasze przypadki użycia.
Dla pełnego obrazu - ograniczenia: to nie jest maszyna do trenowania dużych modeli ani do zastąpienia chmury tam, gdzie potrzebujecie najwyższej jakości frontier models. To urządzenie do wnioskowania, prototypowania i pracy agentowej - i w tej roli jest dziś w naszej ocenie najciekawszą propozycją w swojej klasie cenowej.
## Werdykt
Egzemplarz, który testowaliśmy, pojechał już do klienta - i szczerze mówiąc, trochę nam go brakuje. Maszyn, które w tym rozmiarze i przy poborze 240 W serwują modele klasy 120B, po prostu do tej pory nie było.
Jeżeli zastanawiacie się, jak mogłoby wyglądać takie środowisko u Was - od doboru sprzętu, przez modele, po [agentów zintegrowanych z Waszymi procesami](/pl/oferta/automatyzacja-ai/) - jako [partner Platinum Lenovo](/pl/lenovo-snok/) pomagamy przejść tę drogę od testu do produkcji. [Napiszcie do nas](/pl/kontakt/), pokażemy to na żywo.
---
### Quo vadis, inżynierze?
URL: https://snok.ai/pl/aktualnosci/blog/quo-vadis-inzynierze/ | Data: 2026-08-04 | Seria: Inne
## Nigdy tak wielu nie tworzyło oprogramowania, którego nie rozumie
Wiem, jak to zdanie brzmi. Jak początek wykładu starszego pana, który zaraz powie młodzieży, że kiedyś to było. Obiecuję, że nie o to chodzi - piszę ten tekst, bo sam korzystam z tych narzędzi codziennie i bardzo je lubię. Właśnie dlatego uważam, że komuś, kto spędził w tej branży ponad dwadzieścia lat, wypada powiedzieć głośno kilka rzeczy, o których na co dzień wygodniej milczeć.
Zacznijmy od skali, bo ona zmienia wszystko. Kiedy Andrej Karpathy pisał w lutym 2025 roku o vibe codingu - poddajesz się wibracjom, przyjmujesz wszystko, co proponuje model, i zapominasz, że kod w ogóle istnieje - brzmiało to jak opis weekendowej zabawy i tak było to pomyślane. Niecałe półtora roku później Google deklaruje, że sztuczna inteligencja generuje już około trzech czwartych nowego kodu w firmie, z ludzkim przeglądem na końcu (Business Insider, kwiecień 2026). Jesienią 2024 była to jedna czwarta. Taka krzywa nie zna słowa „eksperyment".
I to samo dzieje się piętro niżej, poza działami IT. Ktoś w zakupach składa sobie panel do analizy dostawców. Ktoś w finansach skleja przez weekend integrację z bankiem. Wszystko działa, wszyscy są zadowoleni. A pytania o to, kto to utrzyma, kto to zabezpieczy i kto za to odpowie, wiszą w powietrzu i czekają na swój moment. Zwykle przychodzi on w najmniej wygodnej chwili.
No i tu dochodzimy do Was. Bo skoro działający system może dziś złożyć każdy, to po co komu człowiek, który latami uczył się, jak systemy buduje się naprawdę?
## Może rzeczywiście nie potrzeba inżyniera
Powiem to uczciwiej, niż wypada człowiekowi, który prowadzi firmę inżynierską: do wielu rzeczy inżynier rzeczywiście przestał być potrzebny. I dobrze.
Do prototypu? Nie jest potrzebny. Do wewnętrznego narzędzia dla dziesięciu osób? Zwykle też nie. Do sprawdzenia pomysłu, zanim ktoś wyda na niego budżet? Tu wręcz szkoda inżyniera, niech pomysł najpierw udowodni, że zasługuje na jego czas. To jest realna zmiana na lepsze i udawanie, że jej nie ma, ośmiesza naszą branżę bardziej niż najgorszy vibe coding.
Inżynier staje się potrzebny dokładnie w tej chwili, w której system zaczyna coś znaczyć. Kiedy przechodzą przez niego prawdziwe pieniądze, prawdziwe dane osobowe, prawdziwa produkcja. Kiedy ma działać także drugiego stycznia o trzeciej w nocy, po awarii łącza, przy zdublowanym rekordzie i przy księgowej, która czeka na zamknięcie miesiąca. Granica nie przebiega między tym, kto umie kodować, a tym, kto nie umie. Przebiega między „złożyłem coś, co działa" a „rozumiem, dlaczego to działa i wiem, kiedy przestanie".
## Złudzenie tempa
Teraz historia, która powinna trafić do podręczników - i to wcale nie dlatego, że stawia AI w złym świetle.
W lipcu 2025 ośrodek badawczy METR opublikował wyniki kontrolowanego eksperymentu. Doświadczeni programiści open source pracowali nad zadaniami we własnych, dobrze znanych projektach, raz z narzędziami AI, raz bez. Przed startem szacowali, że AI przyspieszy ich o jedną czwartą. Po zakończeniu byli przekonani, że przyspieszyło ich o jedną piątą. A pomiar pokazał, że z AI ich zadania trwały o 19 procent dłużej.
Ciąg dalszy jest jeszcze ciekawszy. W lutym 2026 METR ogłosił, że kolejna runda badania wskazuje już na przyspieszenie, ale wyników nie jest w stanie traktować jako wiarygodnych - między innymi dlatego, że coraz trudniej znaleźć programistów gotowych pracować bez AI, mimo wynagrodzenia płaconego w badaniu. Narzędzia w rok zdążyły się poprawić, a badani zdążyli się od nich uzależnić na tyle, że eksperyment przestał się kleić. Badacze rozkładają ręce i projektują metodę od nowa.
Co z tego wynika dla nas? Nie to, że AI nie działa. Wynika z tego coś ważniejszego: nawet ludzie, którzy zawodowo mierzą takie rzeczy, mają kłopot ze złapaniem prawdy o naszym tempie. A my, w codziennej pracy, oceniamy je po prostu na czuja. Praca z modelem daje cudowne poczucie płynności - coś się dzieje, ekran się zapełnia, zadania się zamykają. Tylko że to poczucie, jak pokazał METR, potrafi rozjechać się z rzeczywistością o czterdzieści punktów procentowych. Jeżeli aż tak mylimy się co do własnej szybkości, to jak bardzo mylimy się co do jakości tego, co przyjmujemy bez czytania?
## Nożyce się rozwierają
Z tych obserwacji składa się mechanizm, który uważam za najważniejszą zmianę na rynku kompetencji od dekady. Opowiem go na dwóch osobach.
Pierwsza to architektka, która zna swoje rzemiosło od podszewki. Dla niej te narzędzia są dźwignią, o jakiej nie śniła: sprawdzi trzy warianty architektury przed obiadem, wygeneruje szkielet integracji w godzinę, przejrzy cudzy moduł szybciej, niż kiedyś czytała jego dokumentację. Wie, o co poprosić, i natychmiast widzi, kiedy dostała bzdurę. AI podnosi jej sufit.
Druga osoba fundamentów nie ma i model produkuje na jej zamówienie rzeczy, których nie umie ocenić, w tempie, za którym nie nadąża jej zrozumienie. Jej AI obniża podłogę - im sprawniej generuje, tym szybciej rośnie góra rzeczy przyjętych na wiarę.
Nożyce się rozwierają. Kod stał się tani, a osąd zdrożał - i to jest, moim zdaniem, cała ekonomia tego zawodu w jednym zdaniu.
Najbardziej martwię się przy tym nie o seniorów, tylko o dwie inne grupy. O juniorów, którym vibe coding podkrada okazję do terminowania w zawodzie, bo nikt już nie chce płacić za pisanie tego, co model wypluje w minutę - a przecież właśnie na tym pisaniu my wszyscy uczyliśmy się rozumienia. I o tych doświadczonych, którzy przestali czytać, bo „przecież działa". Rzemieślnik, który przestaje dotykać materiału, traci wyczucie powoli i bezboleśnie. Orientuje się dopiero wtedy, gdy jest naprawdę potrzebny.
## Pod spodem nie ma nikogo
Dochodzimy do części, przez którą ten felieton w ogóle powstał: do bezpieczeństwa. A właściwie do jego złudzenia.
Veracode co roku sprawdza, jak modele radzą sobie z pisaniem bezpiecznego kodu - w programie badawczym, który objął już łącznie ponad sto modeli. Wynik z raportu 2026 (lipiec 2026): 44 procent prób generowania kończy się kodem z podatnością ze znanych kategorii OWASP. I uwaga, bo tu siedzi najważniejsza obserwacja tego roku. Ten wynik praktycznie nie drgnął od zeszłego roku, choć modele w tym czasie wyraźnie zmądrzały. Piszą coraz lepszy kod. Nie piszą bezpieczniejszego. Bezpieczeństwo nie poprawia się „przy okazji" - trzeba o nie poprosić, a potem sprawdzić, czy prośba została spełniona.
Idźmy głębiej, bo pod kodem jest jeszcze łańcuch dostaw. Modele wymyślają nazwy bibliotek, których nie ma - według badań prezentowanych na USENIX Security 2025 dotyczy to mniej więcej co piątej sugestii pakietu. Napastnicy nauczyli się te wymyślone nazwy rejestrować z wyprzedzeniem i podkładać pod nie złośliwy kod. Zjawisko doczekało się nazwy slopsquatting i pierwszych żywych przypadków. Zainstalujecie taki pakiet jednym enterem, bo przecież model go polecił.
A agenci z dostępem do infrastruktury dopisali do tej listy własny rozdział. Latem 2025 agent Replita usunął produkcyjną bazę danych podczas ogłoszonej blokady zmian, po czym generował dane maskujące problem. W kwietniu 2026 agent w Cursorze, poproszony o zadanie na środowisku testowym, znalazł w plikach produkcyjny token i w dziewięć sekund skasował produkcyjny wolumen razem z kopiami zapasowymi. Dwa różne narzędzia, ten sam wzorzec: intencja była testowa, uprawnienia były produkcyjne, a bramki z człowiekiem nie było żadnej.
Wszystkie te wektory łączy jedno, i to jest myśl, którą chciałbym, żebyście z tego tekstu zapamiętali: wygenerowany system zawsze sprawia wrażenie kompletnego. Demo wygląda znakomicie, interfejs bywa ładniejszy niż w niejednym komercyjnym produkcie, odpowiedzi przychodzą płynnie. Wrażenie kompletności to najtańsza rzecz, jaką produkuje AI. Pod spodem może być solidna konstrukcja, a może być sklejka z podatności, zależności nieznanego pochodzenia i sekretów wpisanych na twardo. Z zewnątrz tego nie odróżnicie. To widać tylko od środka - a od środka nikt nie zaglądał.
## Shadow IT drugiej generacji
W firmach ten mechanizm ma już swoją dojrzałą postać. Kiedyś biznes kupował sobie SaaS na firmową kartę, poza wiedzą działu IT, i nazywaliśmy to shadow IT. Dziś biznes sam sobie oprogramowanie generuje. Mechanizm ten sam, tylko stawka zupełnie inna, bo własnoręcznie wygenerowane narzędzie potrafi mieć dostęp do danych, o jakich SaaS sprzed dekady mógł pomarzyć.
To już nie jest przeczucie, tylko policzone zjawisko. IBM w raporcie Cost of a Data Breach 2025 podaje, że co piąte badane naruszenie danych miało związek z niekontrolowanymi narzędziami AI, a tam, gdzie shadow AI kwitło, średni koszt naruszenia rósł o kilkaset tysięcy dolarów. Większość organizacji przyznaje przy tym, że polityk użycia AI po prostu nie ma. Nie dlatego, że nikt nie chce - dlatego, że tempo adopcji wyprzedziło wszystkich.
## Co się nie zdewaluowało
Skoro samo pisanie kodu tanieje z miesiąca na miesiąc, tym cenniejsze staje się nazwanie tego, co nie staniało ani o grosz.
Nie staniało myślenie systemowe - umiejętność zobaczenia całości, od warstwy sieciowej przez systemy i bazy po aplikację i integracje, i przewidzenia, gdzie ta całość pęknie przy dziesięciokrotnym obciążeniu. Model widzi pliki, które mu pokażecie. Człowiek widzi architekturę razem z jej historią, kompromisami i długiem, którego nie ma w żadnym repozytorium.
Nie staniało diagnozowanie. Kiedy o trzeciej w nocy klaster odmawia współpracy, a monitoring uparcie pokazuje zieleń, różnica między „umiem wygenerować playbook" a „wiem, jak działa DNS, i coś mi mówi, że to certyfikat" to różnica między kwadransem a dobą przestoju. Tego przeczucia nie da się pobrać. Ono się osadza, latami, po jednej awarii na raz.
Nie staniała odpowiedzialność. Ktoś musi podpisać się pod systemem przed zarządem, przed audytorem, przed regulatorem. Model tego nie zrobi - nie dlatego, że prawo nie nadąża, tylko dlatego, że odpowiedzialność wymaga kogoś, kto rozumie konsekwencje i może za nie odpowiedzieć stanowiskiem albo reputacją.
I nie staniał inżynierski gust: to trudne do nazwania coś, co każe powiedzieć „działa, ale tak tego nie zrobimy". Gust bierze się wyłącznie z przeczytanych, naprawionych i utrzymanych systemów. Jest efektem ubocznym rozumienia i dlatego nie da się go wygenerować.
## Nowy warsztat
Jak w takim razie wygląda warsztat inżyniera, który chce być wart swojej stawki w 2026 roku? Podzielę się swoją listą - krótką i na pewno niepełną, potraktujcie ją jako zaproszenie do sporu, nie jako wyrocznię.
Pierwsza rzecz: dekompozycja i specyfikacja. Model robi dokładnie to, o co go poproszono, więc cała wartość przeniosła się do umiejętności poproszenia o właściwą rzecz - rozbicia problemu na części, nazwania warunków brzegowych, powiedzenia wprost, co znaczy „gotowe". To stara, dobra inżynieria wymagań, tyle że uprawiana teraz codziennie, a nie raz na projekt.
Druga: czytanie kodu jako główna czynność zawodowa. Przez dwadzieścia lat przegląd kodu był dodatkiem do pisania. Ta proporcja właśnie się odwróciła - rdzeniem pracy staje się czytanie i ocenianie maszynowej produkcji. Wiem, że to dla wielu z nas trudna wiadomość, bo pisanie po prostu sprawia więcej frajdy. Ale kto nie polubi czytania, ten będzie w tym zawodzie cierpiał.
Trzecia: bezpieczeństwo jako odruch, nie jako etap na końcu. Skąd pochodzi ten pakiet? Co naprawdę robi ta zależność? Gdzie leżą sekrety? Jakie uprawnienia dostał agent i co się stanie, kiedy ktoś wstrzyknie mu instrukcję przez dane, które przetwarza? Te pytania trzeba zadawać w trakcie pracy, bo po fakcie zadaje je już ktoś inny - zwykle w raporcie z incydentu.
I czwarta, moja ulubiona: fundamenty. Sieci, protokoły, systemy operacyjne, bazy, kryptografia. Brzmi jak program studiów sprzed dwudziestu lat? To właśnie jest puenta. Wiedza, która miała się zdezaktualizować, okazała się jedynym narzędziem oceny tego, co produkuje model. Fundamenty nie są nostalgią. Są warunkiem korzystania z nowości.
Zauważcie, czego na tej liście nie ma. Nie ma „prompt engineeringu". Rozmawiać z modelem nauczycie się w tydzień, serio. Całej reszty uczy się latami - i właśnie dlatego cała reszta jest coś warta.
## Pięć pytań, zanim wpuścicie wygenerowany kod na produkcję
Ta lista nie zmieściła się w 12-stronicowej wersji PDF tego felietonu (znajdziecie ją na końcu wpisu), a jest jego najbardziej praktyczną częścią. Pięć pytań, które w SNOK zadajemy przy [przeglądzie bezpieczeństwa](/pl/oferta/cyberbezpieczenstwo/) każdego systemu z dużym udziałem kodu generowanego. Żadne nie wymaga narzędzi za milion, każde wymaga człowieka, który rozumie odpowiedź.
**1. Kto przeczytał ten kod i co z tego czytania wynikło?** Nie „kto uruchomił testy", tylko kto przeczytał. Jeżeli odpowiedź brzmi „nikt", macie na produkcji tekst nieznanego autorstwa o nieznanych właściwościach. Nazwanie tego wprost zwykle wystarcza, żeby przegląd sam się zorganizował.
**2. Skąd pochodzi każda zależność i kto by zauważył, gdyby zniknęła albo zmieniła właściciela?** Lista zależności wygenerowanego projektu bywa dłuższa niż sam projekt. Sprawdźcie, czy wszystkie pakiety w ogóle istnieją dłużej niż pół roku - to najprostszy filtr na slopsquatting.
**3. Gdzie leżą sekrety?** W kodzie generowanym w pośpiechu klucze i hasła lądują na twardo w plikach zaskakująco często, bo tak jest najkrócej, a model optymalizuje pod „działa". Jedno przeszukanie repozytorium potrafi zepsuć humor na cały tydzień.
**4. Co ten system może zrobić w najgorszym razie i kto mu na to pozwolił?** Dotyczy zwłaszcza agentów: jakie mają uprawnienia, do jakich danych sięgają, co się stanie, gdy ktoś wstrzyknie im instrukcję przez treść, którą przetwarzają. Uprawnienia nadane „na chwilę, do testów" mają brzydki zwyczaj zostawać na zawsze.
**5. Kto to utrzyma za rok?** Autor narzędzia z działu zakupów awansuje, odejdzie albo straci zapał. System zostanie. Jeżeli nikt nie umie wskazać właściciela z imienia i nazwiska, to nie jest system, tylko przyszły incydent z odroczonym terminem.
Jeżeli na trzy z pięciu pytań odpowiedź brzmi „nie wiemy", to nie znaczy, że trzeba wszystko wyłączyć. Znaczy, że warto zrobić inwentaryzację, zanim zrobi ją za Was audytor albo napastnik - z tych dwóch audytor jest zdecydowanie przyjemniejszy.
## Jak się w tym odnaleźć
Na koniec trzy rady, których sam się trzymam. Nie piszę ich z pozycji sceptyka - prowadzę firmę, w której AI pracuje na każdym poziomie i przynosi nam realną wartość. Piszę je jako ktoś, kto chce z tych narzędzi korzystać jeszcze za dziesięć lat, na własnych warunkach.
Używajcie AI codziennie, ale w trybie pilota, nie pasażera. Różnica jest prosta: pilot wie, dokąd leci, i co chwilę zerka na przyrządy. Pasażer ma wygodnie, ogląda chmury i nie ma żadnego wpływu na lądowanie. Obaj lecą tym samym samolotem.
Raz w tygodniu przeczytajcie do dna coś, co model dla Was wygenerował. Do dna - czyli razem z zależnościami, z konfiguracją, z pytaniem „dlaczego akurat tak". To najtańszy trening osądu, jaki znam, i najszybszy sposób, żeby odkryć, ile rzeczy ostatnio przyjęliście na wiarę. Wynik bywa otrzeźwiający, mówię z doświadczenia.
I pielęgnujcie przynajmniej jedną domenę, w której jesteście głębiej niż model. Wszystko jedno, czy to będzie HANA, BGP, czy księgowość projektowa. Głębia w jednym miejscu daje rzecz bezcenną: punkt odniesienia. Wiecie wtedy, jak smakuje prawdziwe zrozumienie - i natychmiast czujecie, kiedy w innym obszarze go Wam brakuje.
## Dokąd zmierzasz, inżynierze
Tytułowe pytanie zostawiłem na koniec, bo odpowiedź jest krótsza niż cały ten tekst.
Przez trzydzieści lat można było uważać, że inżynieria to pisanie kodu i konfigurowanie systemów, a rozumienie przychodzi samo, przy okazji. AI właśnie zabrało nam tę wygodną wersję zawodu. Maszyny przejęły pisanie - najłatwiejszą część tej pracy, dlatego automatyzacja zaczęła właśnie od niej. Nie przejęły rozumienia, rozstrzygania ani odpowiedzialności. I nic nie wskazuje, żeby miały je przejąć w cenie tokena.
Więc dokąd zmierzasz, inżynierze? Moja odpowiedź: w głąb własnego zawodu. Bliżej fundamentów, bliżej architektury, bliżej odpowiedzialności. Tam jest dziś więcej pracy niż kiedykolwiek - i, pierwszy raz od dawna, znacznie mniej tłoku.
## Pobierzcie felieton w PDF
Felieton Jacka Bugajskiego · sierpień 2026
Quo vadis, inżynierze?
PDF, 12 stron, ok. 7 MB - wersja do czytania offline, bez formularza i bez podawania danych. Możecie ją swobodnie przekazać dalej w zespole.
## Źródła
- Andrej Karpathy, wpis o „vibe coding", X/Twitter, luty 2025
- Business Insider, „Google says AI now generates about 75% of new code...", 22.04.2026
- METR, „Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", 10.07.2025
- METR, „We are Changing our Developer Productivity Experiment Design", 24.02.2026
- Veracode, „2026 GenAI Code Security Report", lipiec 2026 (pass rate 56 procent, ok. 44 procent zadań z podatnością; wynik płaski rok do roku)
- USENIX Security 2025, badania nad halucynowanymi nazwami pakietów (ok. 20 procent sugestii); zjawisko slopsquatting
- Sprawa SaaStr/Replit, lipiec 2025 - The Register, Fortune
- Sprawa PocketOS / Cursor + Railway (usunięcie produkcyjnego wolumenu w 9 sekund), 25.04.2026 - zenity.io, Tom's Hardware
- IBM, Cost of a Data Breach Report 2025, 30.07.2025 (20 procent naruszeń powiązanych z shadow AI; podwyższony koszt naruszenia)
---
### Wyciek danych z SAP, którego nie widzi żaden SIEM
URL: https://snok.ai/pl/aktualnosci/blog/wyciek-danych-sap-martwe-pole/ | Data: 2026-08-04 | Seria: Bezpieczny Wtorek
Wtorek, 9:12. Ktoś loguje się do systemu SAP na koncie pracownika obsługi klienta. Hasło poprawne za pierwszym razem, więc żaden licznik nieudanych prób nie drgnie. Antywirus milczy, bo nie ma żadnego złośliwego pliku. Firewall milczy, bo ruch wygląda jak każdy inny. SIEM odnotowuje udane logowanie - jedno z kilkuset tego ranka - i na tym jego rola się kończy. Przez następne godziny to konto przegląda rekordy klientów. Najpierw setki, jak co dzień. Potem tysiące. Po południu licznik idzie w setki tysięcy, a nikt w firmie o tym nie wie.
Onno Coenen z SecurityBridge opisał ten scenariusz w artykule pod tytułem, który zostaje w pamięci na długo: gdyby ktoś dziś ukradł z SAP dwa miliony rekordów Waszych klientów - wiedzielibyście o tym? Dla większości organizacji szczera odpowiedź brzmi: nie.
**W skrócie:**
**1/** Atakujący coraz rzadziej włamują się do SAP - logują się wykradzionymi, poprawnymi poświadczeniami i zachowują jak zwykli użytkownicy,
**2/** SIEM i monitoring infrastruktury widzą logowanie, ale nie widzą, co użytkownik robi wewnątrz aplikacji SAP - to największe martwe pole (blind spot) w bezpieczeństwie SAP,
**3/** RODO daje 72 godziny na zgłoszenie naruszenia do PUODO, ustawa o KSC 24 godziny na wczesne ostrzeżenie - oba zegary zakładają, że w ogóle jesteście w stanie incydent wykryć i opisać,
**4/** Odpowiedzią jest monitoring natywny wewnątrz SAP - wykrywanie nietypowego dostępu do danych w czasie rzeczywistym plus materiał dowodowy na potrzeby śledztwa i regulatora.
---
## Logowanie, które przechodzi każdą kontrolę
Przez lata firmy zbudowały solidną ochronę wokół infrastruktury: zarządzanie tożsamością, ochronę stacji roboczych, monitoring sieci, SIEM z całodobowym zespołem. To dobre inwestycje i nikt rozsądny ich nie podważa. Problem w tym, że atakujący odrobili tę samą lekcję. Zamiast wyważać drzwi, wchodzą z kluczem - poświadczeniami zdobytymi przez phishing, wyciek haseł albo przejęte konto serwisowe.
Od tego momentu wszystkie klasyczne kontrole działają na ich korzyść. Logowanie jest poprawne. Sesja wygląda zwyczajnie. Zapytania do bazy przechodzą przez standardowe transakcje. Z perspektywy SIEM to kolejny dzień pracy kolejnego użytkownika, bo SIEM zbiera zdarzenia z sieci, systemów operacyjnych i uwierzytelniania - a nie z wnętrza aplikacji biznesowej. Potrafi powiedzieć, że ktoś wszedł do SAP. Nie potrafi powiedzieć, co tam robi.
A właśnie w SAP leży to, co najcenniejsze. Umowy, dane rozliczeniowe, historia płatności, adresy, numery kont bankowych - w dużej organizacji setki tysięcy albo miliony rekordów klientów w tabelach jednego systemu. Pisaliśmy niedawno o [włamaniu do Western Digital](/pl/aktualnosci/blog/wlamanie-do-western-digital-newralgiczne-dane-z-sap-w-niebezpieczenstwie/), gdzie napastnicy dotarli właśnie do danych w SAP. Ten wzorzec się nie starzeje - zmienia się tylko cena, jaką płaci ofiara.
## Siedem pytań, na które trzeba będzie odpowiedzieć
Wyciek rzadko wychodzi na jaw od środka. Częściej dane klientów trafiają na sprzedaż w darknecie, dzwoni policja albo partner biznesowy pyta, skąd oszuści znają numery umów. Dopiero wtedy zaczyna się śledztwo - i wtedy padają pytania, które brzmią banalnie, dopóki nie trzeba na nie odpowiedzieć pod presją zarządu, klientów i regulatora naraz:
- Kiedy ta aktywność się zaczęła?
- Które konto SAP było używane?
- Jakie transakcje wykonano?
- Które dokładnie rekordy klientów przeglądano?
- Czy dane zostały pobrane lub wyeksportowane?
- Ilu klientów to dotyczy?
- Czy ta aktywność w ogóle została zatrzymana?
Wiedza o tym, że ktoś zalogował się do SAP, to jedno. Wiedza o tym, co zrobił po zalogowaniu, to zupełnie inna kategoria - i bez zapisu zdarzeń z wnętrza aplikacji zespół bezpieczeństwa skleja odpowiedzi z fragmentów logów różnych systemów, tygodniami, równolegle obsługując kryzys komunikacyjny. Organizacja prowadzi śledztwo i gasi pożar jednocześnie.
## Regulator oczekuje faktów, nie przypuszczeń
Coenen pisze z perspektywy Azji i Pacyfiku: singapurska ustawa PDPA wymaga zgłoszenia naruszenia do komisji ochrony danych nie później niż trzy dni kalendarzowe od uznania go za podlegające zgłoszeniu, z karami sięgającymi 10% rocznego obrotu w Singapurze (przy obrocie powyżej 10 mln SGD) albo 1 mln SGD; australijski Privacy Act przewiduje kary do 50 mln AUD, trzykrotności uzyskanej korzyści albo 30% skorygowanego obrotu - w zależności od tego, która kwota jest najwyższa. Egzotyka? Tylko z pozoru, bo polskie i unijne przepisy zbudowane są na tym samym założeniu: organizacja ma wiedzieć, co się stało, zanim zacznie o tym mówić.
RODO w art. 33 daje 72 godziny na zgłoszenie naruszenia ochrony danych do PUODO, licząc od stwierdzenia naruszenia, a przy wysokim ryzyku art. 34 dokłada obowiązek zawiadomienia samych klientów. Za naruszenie obowiązków bezpieczeństwa i zgłaszania grozi kara do 10 mln EUR albo 2% światowego obrotu, a za naruszenie zasad przetwarzania - do 20 mln EUR albo 4%. Ustawa o KSC, [o której pisaliśmy tydzień temu](/pl/aktualnosci/blog/ksc-nis2-sap-securitybridge/), idzie dalej: wczesne ostrzeżenie o incydencie poważnym w 24 godziny i zgłoszenie w 72 godziny, licząc od wykrycia. A kalendarz nie czeka: wniosek o wpis do wykazu podmiotów kluczowych i ważnych trzeba złożyć do 3 października 2026 - to już za dwa miesiące.
I tu wraca pułapka, którą znacie z tamtego wpisu. Wszystkie te zegary startują od wykrycia albo stwierdzenia naruszenia. Jeżeli nie macie czym wykryć, zegar formalnie nie startuje - ale organ nadzoru nie uzna tego za szczęśliwy traf, tylko za brak środków technicznych adekwatnych do ryzyka. A gdy pierwszym sygnałem wycieku jest telefon dziennikarza, na budowanie odpowiedzi jest już za późno.
## „Sądzimy” kontra „wiemy”
Żaden dostawca i żaden zespół bezpieczeństwa nie zagwarantuje, że do naruszenia nigdy nie dojdzie. Różnica między firmą przygotowaną a nieprzygotowaną ujawnia się w pierwszym zdaniu komunikatu.
Firma bez widoczności w SAP mówi: „Sądzimy, że dane klientów mogły zostać naruszone. Skalę ustalamy.”
Firma z widocznością mówi: „Wiemy, które konto było używane, jakie transakcje wykonano, które rekordy przeglądano, kiedy to się działo i których klientów dotyczy. Aktywność została zablokowana.”
To są dwie zupełnie różne rozmowy z zarządem, z klientami i z regulatorem. Pierwsza otwiera kryzys o nieznanym koszcie i nieznanym czasie trwania. Druga zamyka incydent liczbami. A zaufanie klientów - jedyny zasób, którego nie odtworzycie z kopii zapasowej - przetrwa raczej tę drugą wersję.
## Jak zlikwidować martwe pole
Skoro problemem jest brak widoczności wewnątrz aplikacji, rozwiązanie musi działać wewnątrz aplikacji. Dokładnie to robi platforma SecurityBridge, [którą wdrażamy jako oficjalny partner w Polsce](/pl/securitybridge-snok/):
**Threat Detection** monitoruje zdarzenia wewnątrz SAP w czasie rzeczywistym i zgłasza alert wzbogacony o kontekst biznesowy - nie „użytkownik wykonał transakcję”, tylko „konto z obsługi klienta czyta dane w tempie i zakresie, który nie przypomina żadnego normalnego procesu”.
**Data Loss Prevention** pilnuje dostępu do wrażliwych danych: wykrywa nietypowe przeglądanie i pobieranie rekordów w momencie, gdy się dzieje, a nie po fakcie. Zespół bezpieczeństwa dostaje szansę przerwać eksfiltrację, zanim z systemu wyjdą miliony rekordów - a jeśli do incydentu dojdzie, platforma dostarcza materiał dowodowy: które konto, które transakcje, które dane, w jakim czasie.
Alerty trafiają do Waszego SIEM, więc dotychczasowe inwestycje nie idą do kosza - dostają brakującą warstwę, której same nie widzą.
## Od czego zacząć
Nie od zakupu. Od szczerej odpowiedzi na pytanie, czy poranek z początku tego tekstu zostałby u Was zauważony.
Najszybszą drogą do tej odpowiedzi jest nasze bezpłatne badanie [SNOK KSC-CHECK](/pl/narzedzia/ksc-check/) - 25 pytań w sześciu krokach, 8-12 minut, wynik od razu na ekranie i raport PDF e-mailem. Dwa z pięciu obszarów badania - Widoczność zdarzeń oraz Wykrywanie i reakcja - dotyczą dokładnie tego martwego pola, o którym tu mowa. To samoocena, nie audyt, ale porządkuje rozmowę o priorytetach lepiej niż niejedno spotkanie statusowe.
Drugi krok proponujemy zawsze ten sam, bo działa: [umówcie z nami demo SecurityBridge](/pl/securitybridge-snok/), a potem przeprowadzimy **proof of concept w Waszym środowisku SAP** - na wybranym systemie, na Waszych scenariuszach, z alertami na realnych zdarzeniach. Po takim POC wiecie dokładnie, co platforma widzi u Was, a nie na slajdach. Zamiast dyskusji o architekturze dostajecie odpowiedź na pytanie z tytułu tego wpisu.
Z wrażliwymi danymi w SAP pracujemy na co dzień i na dużą skalę - dla Medicover zbudowaliśmy [platformę procesów kadrowych obsługującą około 45 000 pracowników w 18 krajach i około 100 tysięcy zdarzeń kadrowych rocznie](/pl/realizacje/#siec-medyczna-cyfryzacja-hr), projekt uznany przez SAP za oficjalną referencję, jedną z trzech w Polsce. Wiemy, jak wygląda odpowiedzialność za dane osobowe w systemach SAP, zanim jeszcze pojawi się słowo „incydent”.
Jeżeli badanie pokaże luki - albo jeżeli wolicie od razu przejść na poziom konkretnych systemów - [napiszcie do nas](/pl/kontakt/). Pokażemy na żywo, jak wygląda wykrycie masowego odczytu danych w SAP, zanim zobaczy je ktoś, kto nie powinien.
---
## Źródła
- Onno Coenen, *If Someone Stole Two Million Customer Records from SAP Today... Would You Know?*, LinkedIn Pulse, 27.07.2026
- RODO (rozporządzenie 2016/679), art. 33, 34 i 83 - EUR-Lex
- Ustawa z 23.01.2026 o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. 2026 poz. 252)
- Personal Data Protection Act 2012 (Singapur), wymogi notyfikacyjne PDPC; Privacy Act 1988 (Australia) z nowelizacją 2022 - za artykułem źródłowym
- SecurityBridge - dokumentacja platformy: Threat Detection, Data Loss Prevention
---
### Dane podstawowe w polskich przedsiębiorstwach - raport SNOK
URL: https://snok.ai/pl/aktualnosci/blog/dane-podstawowe-w-polskich-przedsiebiorstwach-raport/ | Data: 2026-08-03 | Seria: Inne
W ciągu dwunastu miesięcy Salesforce zapłacił około 8 miliardów dolarów za Informaticę, SAP przejął Reltio, a Gartner po ponad czteroletniej przerwie przywrócił raport Magic Quadrant dla rozwiązań Master Data Management. Rynek wycenił na miliardy kategorię, którą przez lata traktowano jak techniczne zaplecze. W tym samym czasie EY policzył, że zaledwie 9 procent średnich i dużych firm w Polsce dysponuje infrastrukturą danych gotową do zasilenia modeli AI.
Ten rozjazd opisaliśmy w raporcie „Dane podstawowe w polskich przedsiębiorstwach": 28 stron, dziesięć rozdziałów, każda liczba z nazwą źródła i datą. Raport pobierzecie na dole tego wpisu - bez formularza i bez zostawiania adresu. Zanim to zrobicie, opowiemy, dlaczego w ogóle powstał i co z niego wynika dla Waszej organizacji.
## Jedna firma, cztery wersje prawdy
Zacznijmy od sceny, którą znamy z projektów aż za dobrze.
Specjalistka do spraw rozliczeń wystawia fakturę dla stałego kontrahenta. W ERP ten kontrahent ma pełną nazwę i NIP z czasów, gdy podpisywano umowę. W CRM handlowiec zapisał go skrótem, z adresem biura, które firma opuściła dwa lata temu. W systemie zakupowym istnieje jeszcze raz, bez NIP-u, bo tak było szybciej. Każda z tych wersji jest lokalnie poprawna. Żadna nie jest pełna.
Do stycznia 2026 roku ta sytuacja kosztowała głównie cierpliwość: uzgadnianie sald, wyjaśnianie warunków płatności, raport zarządczy składany z trzech źródeł. Koszt istniał, ale rozkładał się na tyle osób i działów, że w żadnym budżecie nie miał własnej linii. Dziś ta sama rozbieżność ma adresata i termin. Fakturę z błędnym NIP-em KSeF doręczy niewłaściwej firmie, a naprawa będzie wymagała korekty do zera i nowego dokumentu.
Skala tego mechanizmu przestała być teoretyczna. I to jest pierwszy z trzech powodów, dla których ten raport powstał właśnie teraz.
## Powód pierwszy: KSeF sprawdza kartoteki codziennie
Od 1 lutego do 26 maja 2026 roku przez Krajowy System e-Faktur przeszło ponad 289 milionów e-faktur od ponad 2 milionów wystawców (dane Ministerstwa Finansów). To pierwszy mechanizm w historii polskiej gospodarki, który sprawdza kartoteki kontrahentów ponad dwóch milionów podatników jednocześnie, każdego dnia roboczego.
Sprawdza je jednak inaczej, niż wiele firm zakłada. KSeF waliduje zgodność pliku ze schematem, natomiast nie weryfikuje merytorycznie, czy NIP nabywcy należy do podmiotu, którego dotyczy transakcja. Faktura z numerem pomylonym o cyfrę otrzyma numer KSeF i zostanie udostępniona firmie o tym numerze, a jeżeli taki NIP nie istnieje, nie zostanie udostępniona nikomu. Takie stanowisko przedstawił Dyrektor KIS w interpretacji indywidualnej z marca 2026 roku.
Zmieniła się też droga naprawy błędu. Noty korygujące przestały istnieć, więc nabywca nie poprawi już cudzej pomyłki jednym dokumentem; błędny NIP oznacza po stronie wystawcy korektę do zera i nową fakturę. Przy jednej pomyłce to niedogodność. Przy kartotece z setkami nieaktualnych rekordów i tysiącach dokumentów miesięcznie to stały proces obsługi wyjątków, który ktoś musi wykonywać ręcznie.
Pierwsze miesiące działania systemu pokazały, że nie jest to problem marginalny. Doradcy podatkowi opisywali numery VAT UE wpisywane w miejsce NIP i podwójny obieg dokumentów, a według danych jednego z dostawców oprogramowania 18 procent faktur korygujących pobieranych z KSeF zawiera błędy. Tę ostatnią liczbę traktujcie ostrożnie, bo pochodzi z próby klientów jednego dostawcy - ale kierunek pokazuje wyraźnie. Okres bez sankcji kończy się wraz z rokiem 2026. Mechanizm zostaje na zawsze.
## Powód drugi: kalendarz migracji, który nie zaczeka
Drugi proces ma dokładne daty. Podstawowe wsparcie SAP dla systemów ECC kończy się 31 grudnia 2027 roku, a według badania grupy użytkowników DSAG z lutego 2026 roku z ECC lub starszych wersji Business Suite wciąż korzysta 54 procent ankietowanych organizacji. Microsoft ogłosił zakończenie standardowego wsparcia Dynamics GP z końcem 2029 roku. Na polskim rynku, gdzie obok SAP silną pozycję mają Comarch i dostawcy krajowi, ten sam moment przychodzi przy zmianie wersji systemu albo konsolidacji po przejęciu.
Każda z tych operacji jest w praktyce migracją danych. I tu tkwi pułapka, którą widzimy w harmonogramach projektów: konwersja przenosi dane do nowej struktury, ale nie poprawia ich jakości. Trzy warianty tego samego kontrahenta wjadą do nowego systemu jako trzy oddzielne rekordy, o ile ktoś ich wcześniej nie scali. Rekord z brakiem w polu wymaganym przez nowy model wróci do zespołu jako wyjątek do ręcznej obsługi - zwykle w oknie przełączenia systemów, czyli wtedy, gdy zespół ma najmniej czasu, a każda godzina przestoju najwięcej kosztuje.
Liczby z rynku potwierdzają, że to nie jest ryzyko papierowe. Według ISG 58 procent programów migracji SAP przekracza budżet i harmonogram, a w terminie i budżecie mieści się 15 procent. Właściwa kolejność jest odwrotna do tej, którą widzimy najczęściej: najpierw pomiar duplikatów i braków, potem deduplikacja z udziałem właściciela danych, dopiero potem migracja. Ta sama praca wykonana po uruchomieniu kosztuje więcej, bo odbywa się pod presją produkcyjną.
## Powód trzeci: AI obnażyła stan kartotek szybciej niż audyt
Trzeci proces jest najmłodszy i działa najszybciej. Modele językowe i agenci nie sprawdzają, czy dane są prawdziwe - odpowiadają na podstawie tego, co otrzymają, równie stanowczo przy danych spójnych i sprzecznych. Agent zapytany o saldo kontrahenta, który występuje w systemach w czterech wariantach, poda odpowiedź natychmiast. Nie zasygnalizuje, że wybrał jeden z czterech możliwych rekordów.
Automatyzacja postawiona na niespójnych danych nie usuwa nieporządku. Zwiększa jego tempo i zasięg.
Prognozy analityków mówią o tym od dwóch lat: według Gartnera do końca 2026 roku organizacje porzucą 60 procent projektów AI, które nie zostały wsparte danymi gotowymi do pracy z AI. Polskie dane układają się w tę prognozę bez naciągania. Technologie AI stosuje u nas 8,7 procent przedsiębiorstw (GUS, 2025), przy średniej unijnej 20 procent (Eurostat), a kompletną infrastrukturę danych pod AI deklaruje wspomniane 9 procent średnich i dużych firm. Modele są dostępne od ręki. Przygotowane dane nie.
## Polska na tle: systemy są, porządku w danych brak
Gdy zestawiliśmy statystykę publiczną z badaniami rynkowymi, wyszedł obraz, który dobrze tłumaczy codzienne doświadczenie polskich zespołów. Infrastruktura istnieje i rośnie: z systemów ERP korzysta 40,5 procent przedsiębiorstw, płatne usługi chmurowe kupuje ponad połowa (GUS, 2025). Praca na danych wygląda skromniej: analizę danych wykonuje 24,5 procent polskich firm, podczas gdy w Danii 60 procent (Eurostat, 2025).
Za średnimi kryje się przy tym silne rozwarstwienie. Technologie AI stosuje 42 procent dużych firm, 15,6 procent średnich i zaledwie 6,1 procent małych (GUS, 2025). Duże organizacje eksperymentują, średnie dopiero wchodzą - i to właśnie one najczęściej odkrywają, że pierwszą przeszkodą nie jest budżet na model, tylko stan własnych kartotek.
Najciekawsze są jednak deklaracje samych organizacji. W badaniu Algolytics i SW Research na próbie ponad 700 firm 73 procent przedsiębiorstw przyznało, że brakuje im kompetencji do wykorzystania potencjału danych, a 66 procent nie wykorzystuje danych w procesach decyzyjnych. To nie są liczby o technologii. To liczby o tym, że między systemami a decyzjami brakuje warstwy, która rozstrzyga, który rekord jest właściwy i kto odpowiada za jego poprawność.
Jest jeszcze jeden polski wątek, o którym rzadko myśli się w kategoriach danych: fuzje i przejęcia. W 2025 roku na polskim rynku odnotowano 330 takich transakcji (M&A Index Poland), z rekordową sprzedażą 49 procent akcji Santander Bank Polska na rzecz Erste Group. Każde przejęcie oznacza łączenie katalogów kontrahentów, indeksów materiałowych i planów kont prowadzonych według różnych zasad. Publicznych badań mierzących skalę tego zjawiska w Polsce brak - piszemy o tym w raporcie wprost - ale z projektów w grupach kapitałowych po akwizycjach, w tym w koncernie chemicznym łączącym dane pięciu spółek z trzech krajów, znamy powtarzalny wzorzec: pierwsze tygodnie integracji schodzą na ustalenie, która spółka używa którego katalogu i czym różnią się definicje pozornie tych samych pojęć.
W raporcie poświęcamy tej warstwie osobny rozdział, razem z pytaniem, którego to zestawienie wymaga: skoro kupiliśmy systemy, dlaczego nie ufamy temu, co z nich wychodzi?
## Dlaczego programy naprawcze zawodzą
Odpowiedź „zróbmy wielki projekt porządkowania danych" ma słabą statystykę. Gartner prognozował, że ponad 75 procent programów [zarządzania danymi podstawowymi](/pl/oferta/master-data-management/) nie osiągnie zakładanych celów biznesowych. Z naszych projektów i rozmów przedwdrożeniowych wynika, że przyczyny rzadko leżą w technologii. Powtarzają się cztery wzorce: zakres obejmujący wszystkie domeny naraz, komitet zamiast właściciela danych z mandatem do decyzji, scalanie rekordów w pełni automatyczne oraz jednorazowe czyszczenie bez reguł pilnujących jakości nowych wpisów. Ten ostatni błąd jest najbardziej zdradliwy, bo daje efekt na kwartał - a potem kartoteka wraca do stanu wyjściowego i organizacja zostaje z przekonaniem, że „już to robiliśmy i nie zadziałało".
W pilotażach danych podstawowych najrzadziej zaskakuje nas technologia. Najczęściej to, jak szybko zapadają decyzje, gdy zamiast opinii na stole leży pomiar.
Dlatego w raporcie opisujemy podejście odwrotne do rynkowego: jedna domena danych, jedno kryterium sukcesu ustalone przed startem i wynik mierzony na rzeczywistych danych organizacji w tygodniach, nie kwartałach.
W praktyce ta metoda składa się z czterech kroków. Najpierw wybór domeny, która generuje najwięcej pracy ręcznej i sporów o liczby - najczęściej są to kontrahenci albo indeksy materiałowe. Potem pomiar stanu: liczba duplikatów, braki w polach krytycznych, rozbieżności między systemami; pomiar pozwala oprzeć decyzję na liczbach zamiast na opiniach. Trzeci krok to reguły rekordu wzorcowego, z normalizacją nazw i właścicielem danych, który ma mandat do rozstrzygania sporów. Dopiero czwarty krok to scalanie - i tu ważny szczegół: modele językowe trafnie podpowiadają, że dwa zapisy mogą opisywać ten sam podmiot, ale decyzję o połączeniu zatwierdza człowiek, bo błędne scalenie dwóch odrębnych firm jest droższe w naprawie niż duplikat. Każda zmiana zostaje w śladzie audytowym.
Pilot jednej domeny zamykamy zwykle w cztery do ośmiu tygodni. W ten sposób pracujemy między innymi z Medicoverem w domenie danych pracowniczych: [18 krajów, około 45 tysięcy pracowników i około 100 tysięcy zdarzeń na danych rocznie](/pl/realizacje/#siec-medyczna-cyfryzacja-hr), z pełną historią zmian i obiegiem akceptacji - projekt uznany przez SAP za oficjalną referencję, jedną z trzech w Polsce. Do typowych mierników pilota należą udział duplikatów w domenie, kompletność pól krytycznych i czas rozstrzygnięcia spornego rekordu - wielkości, które da się porównać przed i po.
## Kiedy porządkowanie danych nie jest Waszym priorytetem
Bylibyśmy nieuczciwi, gdybyśmy twierdzili, że ta praca jest pilna dla każdego. Jeżeli działacie na jednym systemie, kartoteka liczy kilkuset kontrahentów, a faktury obsługuje jedna osoba, która zna ich wszystkich - KSeF przejdziecie na dyscyplinie operacyjnej, bez osobnej warstwy danych.
Odradzamy start także wtedy, gdy organizacja oczekuje jednorazowego czyszczenia bez wskazania właściciela danych po stronie biznesu, planuje objąć wszystkie domeny naraz przed pierwszym potwierdzonym wynikiem albo nie ma nikogo, kto rozstrzygnie sporny rekord merytorycznie. W takich warunkach projekt skończy się dokładnie tak, jak w statystyce Gartnera - a szkoda pieniędzy i zaufania. Jasna kwalifikacja oszczędza obu stronom kwartał rozmów bez wyniku.
Priorytet mają organizacje, które przygotowują migrację systemu, konsolidują spółki po przejęciach, uruchamiają automatyzację lub AI na danych operacyjnych albo muszą wykazać wobec audytora, gdzie leżą dane i kto ma do nich dostęp. Jeżeli rozpoznajecie się w którymkolwiek z tych zdań, raport pisaliśmy dla Was.
## Zmierzcie to u siebie, zanim wydacie złotówkę
Najpraktyczniejsza strona raportu nie wymaga od Was żadnej decyzji zakupowej. Skalę problemu w jednej domenie można oszacować własnymi siłami w kilka dni. Wystarczy wyciąg z kartoteki kontrahentów i cztery pytania:
1. Ile rekordów ma ten sam NIP przy różnych nazwach lub adresach?
2. Ile rekordów ma braki w polach, które Wasze procesy uznają za krytyczne?
3. Ile pozycji różni się między ERP a CRM dla tych samych podmiotów?
4. Kto rozstrzyga, która wersja jest właściwa, i ile czasu to zajmuje?
Odpowiedź „nie wiemy" na którekolwiek z nich również jest wynikiem pomiaru, i to najbardziej pouczającym. A jeżeli wolicie, żeby ten pomiar wykonał ktoś z zewnątrz: robimy to na próbce z jednej domeny i przekazujemy wynik z rekomendacją zakresu w pięciu dniach roboczych. Szczegóły znajdziecie na stronie [pomiaru duplikatów](/pl/oferta/master-data-management/#pomiar-duplikatow).
## Pobierzcie raport
Raport SNOK · sierpień 2026
Dane podstawowe w polskich przedsiębiorstwach
PDF, 28 stron, ok. 0,9 MB - bez formularza i bez podawania danych. Raport możecie swobodnie przekazać dalej w zespole - do tego został pomyślany.
W środku znajdziecie to, czego nie zmieścił ten wpis: pełny rozdział o rynku i przejęciach, szczegółową mechanikę KSeF z interpretacją KIS, dane DSAG i ISG o migracjach, cztery antywzorce programów naprawczych z opisem, metodę przyrostową krok po kroku oraz notę metodyczną z kompletem źródeł.
## Od raportu do pierwszego wyniku
Jeżeli po lekturze uznacie, że temat dotyczy Waszej organizacji, proponujemy drogę, którą przechodzimy z klientami najczęściej. Zaczynamy od [pomiaru duplikatów](/pl/oferta/master-data-management/#pomiar-duplikatow) na próbce jednej domeny - wynik z rekomendacją zakresu dostajecie w pięć dni roboczych. Jeżeli liczby potwierdzą problem, przeprowadzimy **proof of concept na platformie [SNOK MDM](/pl/produkty/snok-mdm/)**: pilot jednej domeny na Waszych rzeczywistych danych, z kryterium sukcesu ustalonym przed startem i wynikiem, który da się porównać przed i po. Chcecie najpierw zobaczyć platformę w działaniu? [Umówcie demo SNOK MDM](/pl/produkty/snok-mdm/) albo po prostu [napiszcie do nas](/pl/kontakt/) - opowiecie o swoich systemach, my o tym, od której domeny zaczęlibyśmy u Was.
Tydzień temu na tym blogu ukazał się [felieton o dwudziestu latach z danymi podstawowymi](/pl/aktualnosci/blog/dane-podstawowe-po-dwudziestu-latach/) - dobre uzupełnienie perspektywy, tym razem osobistej. Pytania do autorów raportu kierujcie wprost: Jacek Bugajski (jacek.bugajski@snok.ai) i Michał Korzeń (michal.korzen@snok.ai).
---
### Przegląd tygodnia W31: inwentarz, którego nikt nie ma
URL: https://snok.ai/pl/aktualnosci/blog/snok-weekly-digest-w31-inwentarz-ktorego-nikt-nie-ma/ | Data: 2026-07-31 | Seria: Inne
Ten tydzień ma jeden motyw: **inwentarz i dowód**. Prawie każda pozycja wraca do dwóch pytań, na które w większości organizacji nie ma dziś gotowej odpowiedzi. Co dokładnie działa w środku? I co potraficie o tym udowodnić, gdy ktoś zapyta?
Robak w dokumencie Word rozprzestrzenia się przez pliki, których nikt nie inwentaryzuje. Udostępniona rozmowa z asystentem AI trafia do wyszukiwarki, bo nikt nie sprawdził, gdzie prowadzi link. Bezpieczeństwo SAP nie pęka w dniu uruchomienia, tylko kilka miesięcy później, gdy ostatni audyt opisuje już inny system. Agenty AI mnożą się poza rejestrem działu IT. A na końcu The Economist wystawia rachunek: rynek nie umie zmierzyć nawet tego, co już kupił.
Jedenaście pozycji z tygodnia 27-31 lipca 2026, w tym jedna nasza.
## 1. Uruchomiliśmy SNOK KSC-CHECK: bezpłatne badanie gotowości SAP na KSC i NIS2
[SNOK KSC-CHECK](/pl/narzedzia/ksc-check/) to badanie gotowości Waszego krajobrazu SAP na wymogi ustawy o krajowym systemie cyberbezpieczeństwa i dyrektywy NIS2. Dwadzieścia pięć pytań, sześć kroków, pięć obszarów, od ośmiu do dwunastu minut. Wynik pojawia się na ekranie od razu, raport PDF przychodzi na wskazany adres w kilka minut.
Pięć obszarów odpowiada temu, co decyduje o zdolności zareagowania na incydent w SAP: widoczność zdarzeń, wykrywanie i reakcja, podatności i poprawki, tożsamość i dostęp oraz zgodność i dowody. Wagi są nierówne celowo. Widoczność i reakcja ważą najwięcej, bo od nich zależy, czy ustawowy termin dwudziestu czterech godzin od wykrycia jest w Waszym przypadku wykonalny. Pytania sformułowaliśmy dla dyrektora IT, nie dla administratora Basis, a odpowiedź „nie wiem" jest dopuszczalna i punktowana zerem - brak wiedzy o własnym systemie też jest wynikiem.
Czym to nie jest: samoocena wypełniana przez dwanaście minut nie zastępuje przeglądu technicznego i nie potwierdza zgodności z ustawą. Badanie pokazuje, gdzie szukać luk, i porządkuje rozmowę przed terminem wpisu do wykazu 3 października 2026. Robimy je bezpłatnie w zamian za dane kontaktowe i mamy w tym interes handlowy.
## 2. Robak w dokumentach Word rozprzestrzenia się przez Copilota, a klasa podatności została otwarta
Norweski badacz Håkon Måløy pokazał robaka, który nie potrzebuje ani kodu, ani makr. Wystarczy dokument Word z instrukcjami ukrytymi w treści - białym tekstem na białym tle, w mikroskopijnym stopniu pisma. Kiedy pracownik prosi Copilota o opracowanie albo edycję treści na podstawie takiego pliku, Copilot zdejmuje formatowanie, czyta ukryty tekst i traktuje osadzone polecenia jako część żądania użytkownika. Następnie modyfikuje aktywny dokument i dopisuje do niego cały złośliwy prompt, znowu jako ukryty biały tekst. Kolejna osoba otwiera zarażony plik i cykl powtarza się bez udziału atakującego. Efektem może być cicha zmiana danych - na przykład liczby w raporcie finansowym - wędrująca między plikami.
Ciekawsze od samego demo jest to, co stało się potem. Måløy zgłosił sprawę do Microsoft Security Response Center 6 marca 2026. Microsoft naprawił konkretną implementację, badacz przeformułował ładunek i pokazał propagację ponownie. Dwie próby mitygacji, w tym przejście na nowszy model, nie zamknęły problemu. Ujawnienie nastąpiło 28 lipca, po stu czterdziestu czterech dniach koordynacji i dwóch przesunięciach terminu; [The Register](https://www.theregister.com/security/2026/07/29/word-worm-crawls-into-copilot-spreads-chaos/5280588) opisał to dzień później. Numeru CVE nie ma, bo to nie pojedynczy błąd, tylko klasa podatności: model nie odróżnia instrukcji od danych, które przetwarza. Microsoft potwierdził badanie i odpowiedział stanowiskiem o obronie warstwowej. Stanowisko badacza jest twardsze: dla szerszej klasy tych ataków skutecznej mitygacji dziś nie ma.
Kierunek ryzyka odwraca się tu w sposób, którego większość polityk nie przewiduje. Dotychczas kontrola asystentów AI pilnowała wejścia: co użytkownik wpisuje i jakie dane trafiają do modelu. Ten atak przenosi ryzyko na wyjście, czyli na artefakty wytworzone przez asystenta i czytane przez kolejnych ludzi oraz kolejne agenty. Jeśli uruchamiacie Copilota albo dowolnego asystenta nad firmowym repozytorium dokumentów, trzy pytania warto zadać dziś:
- Czy pliki wytworzone przez asystenta są u Was traktowane jako zaufane?
- Kto sprawdza dokumenty przychodzące z zewnątrz, zanim trafią do asystenta?
- Kto zauważy, że liczba w raporcie zmieniła się bez śladu w historii wersji?
Ten scenariusz dopisaliśmy do zakresu naszych [przeglądów bezpieczeństwa AI](/pl/oferta/automatyzacja-ai/ai-security/).
## 3. Model odkrył nowe ataki na kandydata NIST do kryptografii post-kwantowej
Anthropic opisał badanie, w którym model Claude Mythos Preview samodzielnie znalazł dwa wyniki kryptoanalityczne. Pierwszy dotyczy HAWK-256, kandydata NIST w dodatkowej rundzie na standard podpisu post-kwantowego. Model znalazł brakujący automorfizm sieci kratowej, co pozwoliło zbudować atak odzyskujący tajną bazę zdolną podpisywać wiadomości dla oryginalnego klucza publicznego. Oczekiwany koszt złamania HAWK-256 spadł z 2⁶⁴ do 2³⁸ operacji. Drugi wynik dotyczy siedmiorundowego, testowego wariantu AES-128: skrót matematyczny nazwany „Möbius Bridge" wyeliminował 256-drożny krok zgadywania w atakach typu meet-in-the-middle i przyspieszył najlepszą znaną metodę od dwustu do ośmiuset razy. Model pracował półautonomicznie przez około sześćdziesiąt godzin, przy kosztach API rzędu stu tysięcy dolarów. Ujawnienie poszło do autorów HAWK i przez NIST.
Granica wniosku jest tu ostra i warto ją utrzymać. HAWK nie jest zatwierdzonym standardem, a osłabienie nie oznacza złamania. Wynik dotyczący AES odnosi się do wariantu zredukowanego, nie do pełnego AES-128 ani AES-256 z produkcji - Wasze szyfrowanie danych działa dalej. [Matthew Green](https://blog.cryptographyengineering.com/2026/07/29/some-notes-about-anthropics-new-results/) ocenia rezultat na HAWK jako mocno imponujący, a rezultat na AES określa wprost jako znacznie mniej interesujący. Wspólny wniosek autorów i komentatorów brzmi jednak tak samo: marginesy bezpieczeństwa algorytmów kratowych trzeba przeliczyć, a weryfikacja założeń nowych standardów musi przyspieszyć.
Jeśli planujecie migrację do kryptografii post-kwantowej, konsekwencja jest architektoniczna, nie operacyjna: zdolność do wymiany algorytmu bez przepisywania systemu przestaje być teoretyczną zaletą projektu. Praktycznie oznacza to sprawdzenie, na jakich algorytmach opiera się mapa drogowa Waszych dostawców, także w warstwie podpisywania artefaktów i uwierzytelniania. Systemów zależnych od HAWK nie ma dziś sensu budować przed ponowną oceną NIST.
## 4. Udostępnione rozmowy z Claude trafiły do indeksu Google i Bing
Mechanizm jest banalny i dlatego zadziałał. Użytkownik klika „udostępnij rozmowę", dostaje publiczny odnośnik, a wyszukiwarka indeksuje publiczny odnośnik. [Wired](https://www.wired.com/story/private-claude-chats-exposed-in-google-and-bing-search-results/) przeanalizował próbkę odsłoniętych stron i ustalił, że nie zawierały znacznika `noindex`, którego oczekują zarówno Google, jak i Bing. W indeksie wylądowały rozmowy o kodzie, plany biznesowe, dokumenty i życiorysy. Sprawę odnotowała też [CRN Polska](https://crn.pl/aktualnosci/google-indeksowal-rozmowy-z-claude-w-sieci-znaleziono-wrazliwe-dokumenty/). Anthropic zablokował indeksowanie stron udostępnionych rozmów, a wcześniej zaindeksowane strony zaczęły wypadać z wyników.
Warstwa techniczna została więc zamknięta. Organizacyjna została otwarta i dotyczy każdej firmy, w której narzędzia AI weszły do użycia bez ustaleń. Jeśli pracownik wkleił do rozmowy fragment umowy albo dane klienta, a potem udostępnił wątek koledze, materiał mógł stać się publiczny bez czyjejkolwiek złej woli. W kategoriach RODO to zdarzenie do oceny, nie ciekawostka z serwisu branżowego.
Zalecenie jest jedno: do pracy na danych objętych umową powierzenia albo poufnością służy środowisko z firmową umową, kontrolą administracyjną i ustaleniami co do przetwarzania - a funkcję publicznych odnośników w takim środowisku wyłącza się świadomie. Model cenowy narzędzia sam o niczym nie rozstrzyga.
## 5. PleaseFix: przeglądarki agentowe zdejmują granice, na których stoi bezpieczeństwo sieci
Zenity Labs opisało rodzinę podatności o nazwie PleaseFix, dotyczącą przeglądarek sterowanych przez agenty AI. Złośliwa strona przekazuje instrukcje wprost do agenta - to wstrzyknięcie promptu, tylko przeprowadzone w przeglądarce. Do tego dochodzi obsługa żądań między domenami: agent nie respektuje granic pochodzenia tak, jak robi to klasyczna przeglądarka. Skutki opisane przez badaczy sięgają od przejęcia konta i kradzieży poświadczeń w zalogowanej sesji, przez dostęp do plików lokalnych, po zdalne wykonanie kodu, a wszystko w scenariuszu bez kliknięcia. Klasa jest znana od marca 2026, gdy Zenity pokazało dwa exploity na Perplexity Comet; [Dark Reading](https://www.darkreading.com/endpoint-security/agentic-browsers-rewind-web-security-20-years) wrócił do niej 27 lipca, nazywając efekt cofnięciem bezpieczeństwa sieci o dwadzieścia lat.
Michael Bargury, współzałożyciel i dyrektor techniczny Zenity, formułuje to bez ostrożności: to nie błąd, lecz właściwość systemów agentowych. Atakujący wstrzykuje niezaufane dane do przeglądarki AI i przejmuje samego agenta, dziedzicząc każdy dostęp, jaki agent otrzymał.
Stąd jedna zasada projektowa, przy której warto się upierać: agent sterujący przeglądarką pracuje w izolowanym środowisku, nie na stacji roboczej w sieci korporacyjnej i nie w sesji zalogowanej do systemów produkcyjnych. Pytanie kontrolne dla wdrożeń, które już macie: gdyby odwiedzona strona przekazała agentowi polecenie, do czego sięgnąłby w ciągu następnej minuty? Odpowiedź „do wszystkiego, do czego ma dostęp użytkownik" jest odpowiedzią złą.
## 6. Bezpieczeństwo SAP nie pęka przy uruchomieniu, pęka po nim
Ta pozycja nie jest newsem, lecz tezą, którą opisaliśmy szerzej we wpisie [Hardening SAP to proces, nie projekt](/pl/aktualnosci/blog/hardening-sap-proces-nie-projekt/) - i którą warto powtórzyć obok punktu pierwszego, bo obie dotyczą tego samego.
Projekt się kończy, a rozjazd konfiguracji dopiero zaczyna. Po uruchomieniu przychodzą zmiany użytkowników, transporty, poprawki parametrów, rozrost uprawnień. Audyt punktowy opisuje stan z dnia badania i nie obejmuje niczego, co zdarzyło się później. Inwestycja zatrzymuje się w dniu odbioru, ryzyko nie.
Odsetków firm, które nie monitorują zdarzeń warstwy aplikacyjnej, wywołań RFC czy dostępu do tabel wrażliwych, nie cytujemy - te, które krążą w obiegu, pochodzą z materiałów dostawców bez podanej metodyki i próby. Potwierdzenie znajdziecie u siebie bez cudzych statystyk. Wystarczą trzy pytania: czy zdarzenia bezpieczeństwa z produkcyjnych systemów SAP trafiają do SIEM, jak długo je przechowujecie i ile dni mija u Was od Patch Day do wdrożenia not oznaczonych jako krytyczne.
Tu rozmowa o SAP spotyka się z KSC i NIS2. Obowiązek zgłoszenia poważnego incydentu w ciągu dwudziestu czterech godzin zakłada, że incydent zostanie wykryty, a audyt w kolejnych latach oceni dowody z okresu, który trwa teraz. Monitoring ciągły nie zastępuje audytu punktowego - dostarcza dowodów z okresów między audytami i zwiększa szansę wykrycia incydentu na czas. Zakres tej pracy opisaliśmy w usłudze [audytu zgodności NIS2, DORA i KSC dla SAP](/pl/oferta/bezpieczenstwo-sap/audyt-nis2-dora/).
## 7. OWASP pysap dostał pierwsze duże wydanie po pięciu latach
Pozycja warsztatowa. Biblioteka pysap, służąca do tworzenia i wysyłania pakietów w protokołach SAP, dostała wydanie [v0.2.0](https://github.com/OWASP/pysap/releases) w ramach projektu CBAS Fundacji OWASP - 28 lipca, po pięciu latach od v0.1.19 z kwietnia 2021. Nowe wydanie domyka migrację do Pythona 3, przenosi kompresję z kodu C do czystego Pythona i porządkuje obsługę bajtów oraz tekstu. Zakres protokołów obejmuje warstwę komunikacyjną: NI, Diag, Enqueue, SAProuter, Message Server, SNC, IGS, RFC i HDB.
To nadal biblioteka niskopoziomowa, nie skaner produkujący raport. Wartość polega na możliwości weryfikacji ekspozycji warstwy komunikacyjnej własnym warsztatem, a nie wyłącznie na podstawie wyniku ze skanera dostawcy - co ma znaczenie w [pentestach i audytach bezpieczeństwa SAP](/pl/oferta/bezpieczenstwo-sap/pentesty-sap/).
Zastrzeżenie, bez którego ta notka nie powinna istnieć: narzędzia tej klasy uruchamia się wyłącznie w środowiskach objętych pisemną autoryzacją właściciela systemu, a nowe wydanie sprawdza się najpierw w laboratorium, nie na produkcji klienta.
## 8. Open Secure AI Alliance: ponad trzydzieści firm stawia na otwarte narzędzia bezpieczeństwa AI
NVIDIA ogłosiła 27 lipca powstanie Open Secure AI Alliance, koalicji skupionej na otwartych narzędziach do zabezpieczania modeli i agentów AI. Wśród firm założycielskich są Microsoft, IBM, Cisco, Dell Technologies, HPE, Red Hat, SAP, Palantir, Palo Alto Networks, CrowdStrike, Cloudflare, Snowflake, Databricks, GitHub, Hugging Face, Mistral, Perplexity, Salesforce, Siemens i Linux Foundation. Liczba uczestników różni się między relacjami - od „ponad trzydziestu" do kilkudziesięciu, bo lista rosła w dniach ogłoszenia. Nieobecność jest tu wymowniejsza od obecności: brakuje OpenAI, Google i Anthropic. Żadna z tych firm nie ogłosiła publicznie odmowy, po prostu nie figurują wśród założycieli.
Do sojuszu wchodzą konkretne projekty. NOOA od NVIDII to zestaw narzędzi badawczych na licencji Apache 2.0 do testowania, śledzenia, audytowania i nadzoru nad zachowaniem agentów. MDASH od Microsoftu orkiestruje wyspecjalizowane agenty, które wyszukują błędy, spierają się o nie i dowodzą ich możliwości wykorzystania.
Bezpośrednim kontekstem jest incydent, [który opisaliśmy w poprzednim wydaniu](/pl/aktualnosci/blog/snok-weekly-digest-w30-zdolnosc-wyprzedza-kontrole/): 16 lipca Hugging Face ujawnił, że agent AI znalazł się w części jego infrastruktury produkcyjnej, a pięć dni później OpenAI potwierdziło, że był to jego własny system - GPT-5.6 Sol wraz z modelem przedpremierowym, działający w wewnętrznym benchmarku ExploitGym z celowo wyłączonymi zabezpieczeniami. Agent wyszedł z piaskownicy przez lukę zero-day, złożył skradzione poświadczenia w zdalne wykonanie kodu i wykonał ruch boczny do wewnętrznych zbiorów danych oraz poświadczeń czterech usług. Publiczne modele, zbiory danych i łańcuch dostaw pozostały nienaruszone.
Argument sojuszu brzmi tak: narzędzia bezpieczeństwa, które można w pełni obejrzeć i uruchomić we własnej infrastrukturze, dają większą kontrolę niż zamknięte usługi. To spór branżowy z wyraźnymi stronami i taki należy go czytać - za tezami stoją interesy dostawców. Praktyczna obserwacja obowiązuje jednak niezależnie od tego, kto ma rację: narzędzia audytowe nie muszą być związane z wyborem modelu. Otwarty zestaw do testowania i izolowania agentów da się wpiąć nad każdym dostawcą, który obsługuje używane przez Was interfejsy i środowiska wykonawcze - a to lepsza pozycja przy negocjacjach i przy dowodach dla audytora.
## 9. Moonshot udostępnił wagi Kimi K3 z 2,8 biliona parametrów
Moonshot AI opublikował 27 lipca wagi modelu Kimi K3 na Hugging Face. Architektura to mieszanka ekspertów: 2,8 biliona parametrów łącznie, około 104 miliardów aktywnych na token, 896 ekspertów, z czego 16 pracuje jednocześnie. Repozytorium waży 1,56 TB w 96 fragmentach safetensors, okno kontekstu ma 1 048 576 tokenów, a model przyjmuje obraz na wejściu. Przed udostępnieniem wag plasował się w czołówce benchmarków, więc nie mówimy o wydaniu archiwalnym.
Dwie rzeczy trzeba tu policzyć uczciwie, bo obie łatwo pomylić. Pierwsza: 1,56 TB to już wagi w kwantyzacji MXFP4, czyli około czterech i pół bita na parametr. Ktokolwiek liczy oszczędność „po kwantyzacji do czterech bitów", liczy ją drugi raz - dolna granica dla 2,8 biliona parametrów przy czterech bitach to rząd 1,4 TB, nie kilkaset gigabajtów. Druga: objętość plików to nie to samo co pamięć potrzebna do uruchomienia, bo w mieszance ekspertów znaczenie ma liczba parametrów aktywnych i sposób obsługi wnioskowania. Uruchomienie tego modelu pozostaje zadaniem dla infrastruktury centrum danych, a realny zakres wdrożeń otworzą dopiero mniejsze destylacje, jeśli się pojawią.
Licencja też nie jest tym, czym była w poprzedniej generacji. To licencja własna Kimi K3, a nie zmodyfikowany MIT - duzi dostawcy usług hostowanych powyżej progu dwudziestu milionów dolarów przychodu w dwunastu miesiącach potrzebują osobnej umowy z Moonshot. Przy planowaniu [modeli językowych w infrastrukturze własnej](/pl/oferta/automatyzacja-ai/llm-on-premise/) to zapis do przeczytania przed, nie po.
Kierunek jednak zostaje. Dla organizacji, które z powodów regulacyjnych albo suwerenności danych chcą modelu na własnej infrastrukturze, różnica jakościowa wobec czołówki maleje w części zastosowań. Kontrola nad wagami nie zwalnia przy tym z oceny dostawcy - model o otwartych wagach z Chin przenosi pytania o zgodność w inne miejsce, a nie usuwa ich.
## 10. Agenty AI mnożą się w firmach poza rejestrem działu IT
Agenty AI uruchamiane przez pracowników i pojedyncze działy, bez wiedzy IT i bez nadzoru bezpieczeństwa, to zjawisko, którego skalę dostawcy narzędzi do jego wykrywania obserwują jako rosnącą. Agent ma dostęp do danych, do interfejsów i do systemów, często z uprawnieniami, których nikt nie przeglądał. Wzorzec jest znany z poprzedniej dekady, gdy nazywał się nieoficjalnym IT i dotyczył niezatwierdzonych usług chmurowych. Różnica polega na tym, że usługa chmurowa przechowywała dane, a agent działa.
Materiał źródłowy z [BleepingComputer](https://www.bleepingcomputer.com/news/security/shadow-ai-agents-are-multiplying-heres-how-to-find-and-secure-them/) z 27 lipca powstał z udziałem dostawcy takich narzędzi, więc diagnozę warto oddzielić od reklamy, a samą skalę uznać za nieudokumentowaną niezależnym badaniem. Konsekwencje regulacyjne są za to konkretne: brak rejestru utrudnia spełnienie obowiązków wynikających między innymi z RODO, [AI Act](/pl/oferta/automatyzacja-ai/zgodnosc-ai-act/) i NIS2, choć każdy z tych aktów ma inny zakres podmiotowy i inaczej rozkłada odpowiedzialność.
Pierwszy krok jest nudny i dlatego pomijany: spis. Kto zamówił, na jakich danych działa, jakie ma uprawnienia, kto jest właścicielem, co się dzieje przy błędzie. Bez tego każde ramy nadzoru opisują organizację, której nie znamy.
## 11. The Economist: przychody z AI rosną szybko, ale wolniej niż wydatki
[The Economist](https://www.economist.com/finance-and-economics/2026/07/28/ai-revenues-are-growing-fast-but-not-fast-enough) postawił 28 lipca tezę już w tytule: przychody z AI rosną szybko, tylko wolniej niż wydatki na infrastrukturę, która ma je wygenerować. Materiał jest za opłatą i nie czytaliśmy go w całości, więc odnotowujemy tezę, nie streszczamy argumentacji.
Nasz własny wniosek, formułowany niezależnie od tego artykułu i wynikający z projektów, jest wcześniejszy niż spór o bańkę. Brak pomiaru poprzedza brak budżetu. Organizacja, która nie ustaliła, co ma się zmienić i jak to sprawdzi, nie ma punktu odniesienia - a bez punktu odniesienia nie ma czym uzasadnić następnego kroku ani ocenić, czy pilotaż wypadł dobrze.
Dlatego kolejność w naszych projektach jest odwrotna do domyślnej. Najpierw ustalamy, co ma się zmienić i jakim miernikiem to zmierzymy, a licencje i moc obliczeniową liczymy potem. I jeszcze jedno: zwrot z agenta liczcie razem z kosztem jego nadzoru, nie zamiast niego.
## Co z tego wynika
Trzy rzeczy, w tej kolejności.
**Zrób spis.** Agenty, asystenci, modele, przepływy danych, uprawnienia, właściciele. Bez rejestru nadzór opisuje organizację, której nie znamy - a regulator nie przyjmie tego wyjaśnienia.
**Zbieraj dowody w sposób ciągły.** Audyt punktowy opisuje dzień badania. Termin dwudziestu czterech godzin od wykrycia incydentu i ocena dowodów z okresu, który trwa teraz, wymagają czegoś, co działa między audytami.
**Ustal mierniki przed skalowaniem.** Co ma się zmienić, jak to sprawdzicie i ile kosztuje nadzór. Trzy odpowiedzi przed pierwszą licencją, nie po trzecim pilotażu.
Jeśli któryś z tych tematów dotyczy Was bezpośrednio - gotowość SAP na KSC i NIS2, asystent AI nad firmowymi dokumentami, spis agentów, mapa drogowa kryptografii post-kwantowej - [porozmawiajmy](/pl/kontakt/). A jeśli wolicie zacząć od czegoś, co zajmie kwadrans i nic nie kosztuje, zacznijcie od [badania KSC-CHECK](/pl/narzedzia/ksc-check/).
---
*Przegląd tygodnia to nasz cotygodniowy wybór z kilkuset pozycji radaru i kanałów RSS. Źródła podlinkowane przy każdym punkcie. Materiał informacyjny, nie stanowi porady prawnej ani inwestycyjnej. SNOK KSC-CHECK jest badaniem samooceny i nie stanowi audytu ani potwierdzenia zgodności z przepisami.*
---
### Technologiczny Czwartek ze SNOK: UiPath Delegate - agent dla osoby, nie robot dla procesu
URL: https://snok.ai/pl/aktualnosci/blog/uipath-delegate-agent-dla-osoby/ | Data: 2026-07-30 | Seria: Technologiczny Czwartek
W Technologicznym Czwartku ze SNOK bierzemy jedną technologię i sprawdzamy, co realnie zmienia w pracy naszych klientów. Dziś taką technologią jest produkt, który zmienia nie funkcję, a jednostkę myślenia o automatyzacji.
Jednostką automatyzacji korporacyjnej od dwudziestu lat jest proces. Cała nasza branża wyrosła na tym założeniu. Wybieracie proces, mierzycie jego wolumen i czas, opisujecie w dokumencie definicji procesu, developer buduje robota, Center of Excellence pilnuje wersji i wyjątków. Kolejka kandydatów do automatyzacji jest kolejką procesów, a nie ludzi. Wskaźniki, licencje, role w zespole, metodyka wdrożenia - wszystko to jest ustawione pod proces.
UiPath pokazał kierunek, w którym ta jednostka się zmienia. Nazywa się Delegate i pierwotnie został ogłoszony jako Project Delegate na konferencji FUSION 2025. Zamiast wybierać proces w skali firmy, pracownik pokazuje własne zadanie raz, na własnym komputerze, dopowiada resztę zwykłymi słowami i dostaje wykonawcę, który robi to w tle.
Ten model przestawia trzy rzeczy naraz: kto tworzy automatyzację, co jest jednostką licencji i nadzoru oraz gdzie w firmie leży ryzyko. Dlatego piszemy o tym dziś, gdy produkt jest jeszcze na wczesnym etapie. To najwygodniejszy moment: decyzje, które zdecydują o powodzeniu takiego modelu w Waszej organizacji, można spokojnie przygotować przed premierą, a nie w jej trakcie.
## Co dokładnie wiadomo o Delegate
Zacznijmy od faktów, bo wokół produktów w fazie zapowiedzi zwykle narasta warstwa domysłów.
Delegate to agent działający na komputerze pracownika, w kategorii, którą UiPath nazywa computer use: agent widzi ekran i obsługuje aplikacje tak, jak robi to człowiek. Model pracy z nim ma cztery kroki i strona UiPath Labs opisuje je wprost.
**Pokaż raz.** „Record a task once, so Project Delegate learns and builds a reliable flow" - nagrywacie zadanie jeden raz, a Delegate uczy się z niego i buduje z tego powtarzalny przepływ. Nie piszecie kroków, nie wybieracie selektorów, nie otwieracie Studio.
**Wytłumacz normalnie.** „Instruct with simple natural language interactions: text, voice or task recording" - kontekst dorzucacie tekstem, głosem albo kolejnym nagraniem. Kiedy czegoś brakuje, agent dopytuje.
**Deleguj.** Zbudowany przepływ rusza w tle, na harmonogram, przez te aplikacje i usługi, do których macie dostęp jako użytkownik. Przykłady podawane przez UiPath są celowo przyziemne: rozliczanie faktur, porządkowanie i standaryzacja plików, dzielenie dokumentów z oznaczeniem spraw do dalszej obsługi, koordynacja pracy zespołu.
**Zostań u steru.** „Complete audit trail and transparency of all executions" - pełny rejestr audytowy i przejrzystość wszystkich uruchomień.
Daniel Dines, założyciel i CEO UiPath, opisał ten produkt zdaniem, które warto przeczytać dwa razy: „Project Delegate brings an enterprise-grade AI desktop agent to every professional, blending intelligence with governance so work simply gets done" (blog UiPath, 3 października 2025). Delegate ma dostarczyć agenta desktopowego klasy korporacyjnej każdemu specjaliście, łącząc inteligencję z nadzorem. Słowo, na którym opiera się cała konstrukcja, to *governance*, i nie jest tam z uprzejmości wobec działów bezpieczeństwa.
Techniczny fundament nie jest przypadkowy. Raghu Malpani, CTO UiPath, w wywiadzie dla diginomiki z 20 października 2025 wskazał, że Delegate działa na komputerach użytkowników i uczy się zadań przez demonstrację, korzystając z dorobku firmy w automatyzacji interfejsu użytkownika. To dwadzieścia lat pracy nad selektorami, rozpoznawaniem elementów ekranu i odpornością na zmiany w aplikacjach. Różnica polega na tym, że tę bibliotekę obsługuje teraz model, a nie developer.
## Wczesna faza, czyli najlepszy moment
Delegate jest dziś na etapie, na którym firmy mają największą przestrzeń manewru. Na UiPath Labs produkt widnieje jako *coming soon* z otwartą listą oczekujących, więc zgłoszenie zainteresowania jest dziś kwestią decyzji, a nie postępowania zakupowego. Dla porównania, dwa inne eksperymenty w tym programie - Nucleus i Enterprise Knowledge Graph - są już w statusie *research preview*, czyli z realnym dostępem dla uczestników. Spodziewamy się, że Delegate pójdzie tą samą ścieżką.
Sam UiPath mówi o tym otwarcie. Raghu Malpani w tekście z 15 maja 2026 nazwał produkt wprost - „UiPath Delegate - our new computer-use agent that can execute enterprise work" - i dodał: „We will share more information in the coming months on Delegate". Więcej informacji w kolejnych miesiącach; najbliższy naturalny moment to FUSION 2026, 22-25 września w Las Vegas, choć opublikowana dziś agenda konferencji nie wymienia Delegate w tytułach sesji. Modelu licencyjnego jeszcze nie ogłoszono, a publicznej dokumentacji produktu jeszcze nie ma.
Praktyczny wniosek jest zachęcający: nie musicie dziś nic kupować, żeby ruszyć z tym tematem. Wystarczy zapisać się na listę i wykorzystać najbliższe tygodnie na to, co i tak trzeba zrobić raz - katalog zadań na poziomie stanowisk oraz warstwę nadzoru. Kto to ma gotowe w dniu premiery, startuje od pilotażu, a nie od analizy.
## Gdzie Delegate siedzi w portfolio UiPath
Tu dochodzimy do rzeczy, która interesuje nas najbardziej jako partnera wdrożeniowego. Delegate nie jest kolejnym elementem obok istniejących, dorzuconym do listy. Jest brakującym wierzchołkiem konstrukcji, którą UiPath układa od kilku lat.
Pod Delegate pracuje ten sam mechanizm sterowania interfejsem, co pod ScreenPlay, czyli agentem, który buduje automatyzację interfejsu z opisu w języku naturalnym i jest ogólnie dostępny od FUSION 2025. Wiemy o tym, bo UiPath ocenił nowy model Google z funkcją computer use, Gemini 3.5 Flash, właśnie na swoim harnessie stojącym za Delegate i ScreenPlay (blog Google, 24 czerwca 2026). Dwa wnioski: warstwa sterowania ekranem jest w UiPath wspólna i produktowo wielokrotnego użytku, a to, że UiPath testuje na niej model innego dostawcy, wskazuje na traktowanie modelu sterującego jako elementu wymiennego. Deklaracji produktowej w tej sprawie jeszcze nie ma.
Rozdzielmy więc kategorie, bo w rozmowach zlewają się w jedno:
- **Autopilot for Everyone** to agent konwersacyjny. Rozmawiacie z nim, pyta o dane firmowe, uruchamia gotowe automatyzacje. Punktem wejścia jest czat.
- **Agent Builder i agenci kodowani** to narzędzia budowy. Tworzy nimi ktoś, kto projektuje rozwiązanie dla organizacji, nie dla siebie.
- **Maestro** to orkiestracja: spina agentów, roboty i ludzi w jeden proces z widocznością i eskalacjami.
- **ScreenPlay** to agent, który wytwarza automatyzację interfejsu z opisu zadania.
- **Delegate** to wykonawca po stronie stanowiska pracy. Punktem wejścia nie jest czat ani opis, tylko demonstracja: pokazujecie, jak coś robicie.
Właśnie ta ostatnia różnica jest ciężka w konsekwencjach. Czat wymaga, żeby pracownik potrafił opisać własną pracę. Demonstracja nie wymaga niczego poza wykonaniem jej raz przy włączonym nagrywaniu. To najniższy próg wejścia, jaki automatyzacja korporacyjna kiedykolwiek miała.
## Drugie życie Delegate: testowanie
Jest w tej historii wątek, który przeszedł niemal bez echa, a dla nas jest jednym z najciekawszych. W tym samym tekście z 15 maja 2026 UiPath opisuje Delegate w zastosowaniu, które nie ma nic wspólnego z pracą biurową: autonomiczne wykonywanie ręcznych przypadków testowych od początku do końca, bez człowieka przy klawiaturze. Przez Playwright w przeglądarce, przez Appium na urządzeniach mobilnych i w systemach klasy korporacyjnej - wymienione są SAP, Oracle i Epic.
Dla każdego, kto prowadził konwersję do S/4HANA albo inną dużą zmianę w SAP, to zdanie brzmi konkretnie. Ręczne przypadki testowe to zwykle najbardziej kosztowna i najmniej lubiana część takiego przedsięwzięcia: setki scenariuszy opisanych prozą, wykonywanych przez konsultantów i kluczowych użytkowników pod presją terminu, z pokryciem, którego nikt nie umie wiarygodnie zmierzyć. Agent computer-use, który wykonuje scenariusz zapisany w języku naturalnym, atakuje dokładnie ten koszt, i to bez wcześniejszego budowania automatów testowych.
To również wyjaśnia, dlaczego UiPath inwestuje w tę technologię z dwóch stron. Ten sam mechanizm obsługuje pracownika, który deleguje własne zadanie, i zespół QA, który potrzebuje przejść dwieście scenariuszy przed wyjściem na produkcję.
## Co to zmienia w Waszej organizacji
Przejdźmy do konsekwencji. Trzy przesunięcia, każde z własnym rachunkiem do zapłacenia.
**Pierwsze: automatyzację tworzy pracownik, nie developer.** Wąskim gardłem wdrożeń RPA nigdy nie była technologia, tylko kolejka do zespołu, który potrafi coś zbudować. Model „pokaż raz" tę kolejkę omija. Cena jest natychmiastowa: znika naturalny filtr, którym był brief do CoE. Nikt nie zapyta, czy proces jest wart automatyzowania, czy nie zmieni się w kwartale i czy ktoś to utrzyma, kiedy autor zmieni pracę. Pisaliśmy niedawno o tym, [kiedy nie automatyzować](/pl/aktualnosci/blog/kiedy-nie-automatyzowac/), i ten tekst zyskuje w tym kontekście nowe znaczenie: przy niskim progu wejścia rozstrzygnięcie „to zadanie nie powinno w ogóle istnieć" trzeba wbudować w politykę, bo samo z narzędzia nie wypłynie.
**Drugie: jednostką staje się osoba.** Wszystko, co dziś liczycie na procesy, zmienia mianownik. Portfolio nie jest już listą trzydziestu automatyzacji z właścicielami biznesowymi, tylko zbiorem setek małych przepływów przypisanych do stanowisk. Zmienia się model utrzymania: automatyzacja zbudowana przez pracownika żyje tak długo, jak długo ta osoba jest na stanowisku, a potem albo jest przejmowana, albo cicho psuje się w tle. Zmienia się też prawdopodobnie licznik licencyjny, tylko nikt nam jeszcze nie powiedział na jaki.
**Trzecie: ryzyko przesuwa się z serwerowni na biurko.** Delegate działa w kontekście uprawnień użytkownika - w praktyce oznacza to, że działa wszędzie tam, gdzie ta osoba ma dostęp. Do skrzynki pocztowej, do dysku wspólnego, do systemu kadrowego, do ERP. Trzy pytania, które trzeba mieć rozstrzygnięte przed pierwszym uruchomieniem produkcyjnym, a nie po pierwszym incydencie:
- **Tożsamość.** Kto właściwie wykonuje akcję: pracownik czy agent działający w jego imieniu? Jeśli w rejestrze zdarzeń systemu ERP widnieje wyłącznie login człowieka, tracicie zdolność odtworzenia zdarzeń, a przy okazji podstawę do rozmowy z audytorem.
- **Granica delegowania.** Co pracownik może przekazać agentowi bez zgody, a co nie może przejść bez bramki human-in-the-loop. Wystawienie płatności, zmiana danych kontrahenta, akcja na środowisku produkcyjnym, decyzja dotycząca innej osoby - to nie są kandydaci do cichej delegacji, niezależnie od tego, jak dobrze agent radzi sobie z formularzem.
- **Egress danych.** Zadanie „streść mi te faktury" oznacza, że treść faktur trafia do modelu. Dla podmiotów objętych NIS2, DORA albo rozporządzeniem o AI to pytanie o miejsce przetwarzania, maskowanie danych osobowych i zapis w rejestrze, a nie kwestia wygody.
Zwróćcie uwagę, że żadne z tych trzech pytań nie dotyczy Delegate jako narzędzia. Wszystkie dotyczą warstwy nadzoru, którą trzyma się poziom wyżej: rejestru audytowego, polityki platformowej, bramek dla akcji wysokiego ryzyka. Tydzień temu opisywaliśmy tę warstwę na przykładzie [bramek human-in-the-loop w UiPath Maestro i AI Trust Layer](/pl/aktualnosci/blog/hitl-gate-uipath-maestro-ai-trust-layer/). Model „agent dla osoby" nie zmienia w niej ani jednej zasady. Zmienia skalę: nie dziesięć procesów pod opieką CoE, a każde biurko w firmie.
## Co jeszcze przed nami
Kilka rzeczy pozna się dopiero przy premierze: integrację z Orchestratorem i Maestro, możliwość przeniesienia przepływu z nagrania do Studio, miejsce działania modelu sterującego, obsługę poświadczeń, model licencyjny i termin ogólnej dostępności. Pierwsze publiczne wdrożenia i niezależne pomiary skuteczności też są jeszcze przed nami.
Śledzimy to u źródła, a nie w streszczeniach. Jeśli szczególnie interesuje Was jeden wątek - najczęściej pytacie o licencjonowanie i o testowanie - napiszcie, chętnie przejdziemy przez to na rozmowie.
## Co warto zrobić w najbliższych tygodniach
Cztery rzeczy, wszystkie wykonalne bez dostępu do produktu i wszystkie przydatne niezależnie od tego, kiedy Delegate wejdzie na rynek.
1. **Spiszcie katalog zadań na poziomie stanowisk, nie procesów.** Nie kandydatów do klasycznego RPA, ale te dwadzieścia minut dziennie, które konkretna rola traci na przeklejanie, porządkowanie plików i przepisywanie danych między aplikacjami. To zupełnie inna lista niż ta w Waszym portfolio automatyzacji i to ona zdecyduje o wartości takiego narzędzia.
2. **Ustalcie politykę delegowania, zanim będzie potrzebna.** Krótki dokument: co pracownik może przekazać agentowi samodzielnie, co wymaga zatwierdzenia, czego nie wolno delegować nigdy. Trzy strony wystarczą i lepiej powstaną w spokoju.
3. **Sprawdźcie, czy Wasz rejestr audytowy odróżnia człowieka od agenta działającego w jego imieniu.** To pytanie do systemów, które macie dziś, nie do UiPath. Odpowiedź często bywa niewygodna.
4. **Zamiast budżetu zaplanujcie kompetencje.** Przegląd automatyzacji tworzonych poza CoE, właściciel polityki nadzoru, ścieżka zgłaszania i przejmowania przepływów po osobach, które zmieniają rolę. Przy okazji warto zapisać się na listę oczekujących na Labs - daje wcześniejszy wgląd, a warunki dostępu poznamy razem z premierą.
Z tego, co widzieliśmy w projektach automatyzacji, kolejny etap zawsze wygrywały organizacje, które przygotowały warstwę nadzoru przed narzędziem, a nie te, które kupiły licencje najszybciej. Przy modelu, w którym automatyzację buduje każdy pracownik przez nagranie własnego zadania, ta prawidłowość nie słabnie. Ona się wzmacnia.
Jeśli chcecie przejść ten temat na konkretach Waszego środowiska - portfolio, tożsamości agentów, bramek dla akcji wysokiego ryzyka - [napiszcie do nas](/pl/kontakt/). Jesteśmy partnerem UiPath na poziomie Platinum i uczestnikiem programu Agentic Fast Track, więc rozmowę prowadzimy na tym, co potwierdzone, a nie na zapowiedziach.
---
### KSC i NIS2 w SAP: wpis do wykazu do 3 października
URL: https://snok.ai/pl/aktualnosci/blog/ksc-nis2-sap-securitybridge/ | Data: 2026-07-28 | Seria: Bezpieczny Wtorek
Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa obowiązuje od **3 kwietnia 2026**. Wniosek o wpis do wykazu podmiotów kluczowych i ważnych trzeba złożyć **do 3 października 2026** - zostało około dziesięciu tygodni. Rejestracja to jednak najprostsza część zadania, bo jest formularzem w systemie państwowym. Trudniejsze jest to, czego nikt nie widzi na formularzu: zdolność wykrycia incydentu i pokazania dowodu, że wykrycie faktycznie nastąpiło.
W SAP tej zdolności zwykle nie ma.
**W skrócie:**
**1/** Wpis do wykazu KSC - termin 3 października 2026, wnioski przyjmowane od 7 maja przez wykaz-ksc.gov.pl,
**2/** Zgłoszenie incydentu poważnego - wczesne ostrzeżenie w 24 h i zgłoszenie w 72 h, licząc od wykrycia, oraz sprawozdanie końcowe w miesiąc od zgłoszenia,
**3/** Pierwszy audyt podmiotów kluczowych - do 3 kwietnia 2028, na dowodach zbieranych od 2026,
**4/** Uwierzytelnianie wieloczynnikowe - wymóg wprost z art. 21 ust. 2 lit. j dyrektywy NIS2, w SAP realizowany rzadko.
---
## Zegar, który już tyka
Ustawa z 23 stycznia 2026 o zmianie ustawy o krajowym systemie cyberbezpieczeństwa została opublikowana 2 marca 2026 (Dz.U. 2026 poz. 252) i weszła w życie 3 kwietnia 2026. To ona wdraża do polskiego prawa dyrektywę NIS2.
| Termin | Co się dzieje |
|---|---|
| 3.04.2026 | Ustawa obowiązuje. Obowiązki obsługi i zgłaszania incydentów działają od pierwszego dnia |
| 7.05.2026 | Ministerstwo Cyfryzacji otwiera samodzielną rejestrację w wykazie |
| **3.10.2026** | **Termin złożenia wniosku o wpis do wykazu podmiotów kluczowych i ważnych** |
| 3.04.2028 | Termin pierwszego audytu bezpieczeństwa podmiotów kluczowych |
Do tego dwie liczby, które zwykle kończą dyskusję na zarządzie. Podmiot kluczowy odpowiada karą do **10 mln EUR albo 2% przychodu**, podmiot ważny do **7 mln EUR albo 1,4%** - w obu przypadkach obowiązuje wartość wyższa. Przy naruszeniach zagrażających między innymi bezpieczeństwu państwa, porządkowi publicznemu, zdrowiu ludzi albo grożących poważną szkodą majątkową ustawa przewiduje karę nadzwyczajną do **100 mln PLN**, a kierownik podmiotu prywatnego odpowiada osobiście kwotą do 300% swojego wynagrodzenia.
Jest jeszcze poprawka, która w praktyce usypia czujność: nakładanie typowych kar administracyjnych zostało odroczone o około dwa lata od wejścia ustawy w życie. Odroczenie nie obejmuje jednak wszystkiego - kara nadzwyczajna i część środków nadzorczych pozostają dostępne od początku. Brzmi jak oddech. W rzeczywistości to gorszy scenariusz niż natychmiastowe sankcje, bo audyt w 2028 nie zapyta o stan z 2028. Zapyta o dowody z okresu, który właśnie trwa.
## Poranek, którego nie ma w żadnej procedurze
Wyobraźcie sobie administratora Basis w środę o 7:40. Ma trzy systemy produkcyjne, wczorajszy transport do wdrożenia i skrzynkę z czterdziestoma nieprzeczytanymi wiadomościami. Nie ma w niej żadnej informacji o tym, że w nocy ktoś dwadzieścia razy próbował zalogować się na konto techniczne z zewnętrznego adresu, aż trafił hasło. Nie ma, bo nikt takiej informacji nie wysyła.
Security Audit Log jest włączony - tak wygląda to w większości projektów, które prowadzimy. Tylko że nikt go nie czyta, nikt nie ustawił progów, a wpisy nadpisują się po kilku dniach. W SIEM leżą logi z firewalla, stacji roboczych i Active Directory, natomiast SAP kończy się na monitoringu dostępności: system odpowiada, więc jest dobrze.
I tu zamyka się pułapka regulacyjna. Zegar 24 godzin na wczesne ostrzeżenie startuje **od momentu wykrycia incydentu**. Jeżeli nie ma czym wykryć, zegar formalnie nie startuje - tylko że w postępowaniu organ nadzoru najprawdopodobniej potraktuje to nie jako brak incydentów, a jako brak środków technicznych adekwatnych do ryzyka. Różnica między „nie mieliśmy incydentu" a „nie wiemy, czy mieliśmy incydent" jest w tym postępowaniu różnicą kluczową.
## Sześć kroków, które pokazują, gdzie stoicie
Nie o zgodność w ogóle. Konkretnie o SAP. Te same sześć kroków przechodzicie w naszym bezpłatnym badaniu [SNOK KSC-CHECK](/pl/narzedzia/ksc-check/) - pięć obszarów po pięć pytań, plus krok, w którym wskazujecie, gdzie wysłać raport.
**Krok 1. Widoczność zdarzeń.** Czy Security Audit Log, logi zmian tabel i logi RFC są w ogóle zapisywane, jak długo je trzymacie i czy cokolwiek z nich trafia do SIEM. Bez zapisu nie ma czym wykryć incydentu, a zegar startuje od wykrycia.
**Krok 2. Wykrywanie i reakcja.** Kto dostaje alert z SAP i po ilu minutach, kto ma dyżur po godzinach, kto podpisuje sprawozdanie 72-godzinne i czy procedura była kiedykolwiek ćwiczona.
**Krok 3. Podatności i poprawki.** Ile dni mija od SAP Security Patch Day do wdrożenia not HotNews na produkcji. Jeśli nikt nie zna tej liczby, to jest właśnie odpowiedź.
**Krok 4. Tożsamość i dostęp.** Czy wejście do produkcji wymaga drugiego czynnika, kiedy ostatnio zmieniano hasła kont serwisowych i ilu użytkowników ma uprawnienia zbliżone do pełnych. NIS2 wymienia uwierzytelnianie wieloczynnikowe wprost, w art. 21 ust. 2 lit. j, a w polskich landscape'ach SAP drugi czynnik to nadal rzadkość.
**Krok 5. Zgodność i dowody.** Czy status podmiotu jest ustalony formalnie, czy wniosek o wpis został złożony, co w modelu RISE with SAP należy do SAP a co do Was, i co dokładnie pokażecie audytorowi w 2028 jako dowód wykrywania w latach 2026-2027. Zrzut ekranu nie jest dowodem.
**Krok 6. Wynik i raport.** Punktacja w pięciu obszarach na ekranie od razu, a na maila raport PDF z trzema największymi lukami oraz planem na 30 dni i na 12 miesięcy.
Całość to 25 pytań i od 8 do 12 minut. Pytania są sformułowane dla dyrektora IT, nie dla administratora Basis, a odpowiedź „nie wiem" jest dozwolona i punktowana zerem - brak wiedzy o własnym systemie sam jest wynikiem. To samoocena, nie audyt i nie potwierdzenie zgodności, ale pokazuje, gdzie szukać braków.
## Czym domyka się tę lukę
Zgodność nie jest produktem, więc żadne narzędzie jej nie „załatwi". Potrzebne są procedury, właściciel procesu, dyżury i ćwiczenia. Narzędzie odpowiada natomiast za część, której nie da się zrobić rękami: ciągłe patrzenie na system i zapisywanie tego, co widzi.
Platforma [SecurityBridge](/pl/securitybridge-snok/) działa jako certyfikowany dodatek wewnątrz ABAP, bez zewnętrznych serwerów i dodatkowych agentów w systemie operacyjnym. Z perspektywy obowiązków KSC liczą się cztery obszary:
**Wykrywanie w czasie rzeczywistym.** Monitoring zdarzeń i wykrywanie anomalii w warstwie aplikacyjnej SAP - tam, gdzie firewall i antywirus nie widzą niczego. Platforma rozumie specyfikę SAP, której brakuje generycznym narzędziom: Security Audit Log, masowe czytanie tabel przez SE16, zmiany w obiektach ABAP poza ścieżką autoryzacji, eskalację uprawnień przez SU01 i PFCG, nietypowy ruch RFC między systemami. Właśnie te zdarzenia budują materiał na wczesne ostrzeżenie w 24 godziny, bo opisują zachowanie użytkownika i systemu, a nie sam fakt, że system odpowiada.
**Integracja z SIEM i SOAR.** Zdarzenia z SAP trafiają w to samo miejsce, w którym SOC patrzy na resztę infrastruktury - w praktyce najczęściej Microsoft Sentinel, Splunk, IBM QRadar albo ArcSight. Bez tego SAP zostaje wyspą, a incydent rozpoznaje się z opóźnieniem liczonym w tygodniach. Warstwa SOAR pozwala część reakcji przypisać do scenariusza zamiast do dyżurnego: zablokowanie konta, eskalację do SOC, zebranie śladu zmian. Dla terminu 24 godzin liczy się to podwójnie, bo czas nie ucieka wtedy na ustalanie, kto właściwie ma coś zrobić.
**Zarządzanie podatnościami i notami.** Inwentaryzacja tego, czego brakuje po każdym Patch Day, wraz z oceną, co naprawdę dotyczy Waszej konfiguracji - nie każda nota o wysokim CVSS ma znaczenie w systemie, w którym dany komponent nie jest aktywny. Obok not sprawdzana jest konfiguracja i kod własny, czyli dwa źródła luk, których producent nie załata za Was. Ten obszar łączy się bezpośrednio z [comiesięcznym cyklem poprawek SAP](/pl/aktualnosci/blog/bezpieczny-wtorek-ze-snok-sap-security-patch-day-lipiec-2026/), a jego produktem ubocznym jest odpowiedź na pytanie z kroku trzeciego: ile dni faktycznie mija od publikacji noty do produkcji.
**Raporty zgodności.** Mapowanie kontroli na ISO 27000, CIS i NIS2, czyli uporządkowany materiał do przedstawienia audytorowi zamiast rekonstruowania historii tydzień przed kontrolą. Samo mapowanie nie jest jeszcze dowodem zgodności - dowodem są zapisy pokazujące, że kontrole faktycznie działały. Znaczenie tego obszaru rośnie wraz z odległością do 2028 roku: audytor nie zapyta, czy dziś macie monitoring, ale czy potraficie pokazać, co widzieliście w 2026 i 2027 oraz co z tym zrobiliście. Raport generowany cyklicznie jest znacznie mocniejszym materiałem dowodowym niż zrzut ekranu z konsoli, o którego dacie i kompletności nie da się nic powiedzieć.
Do tego dochodzi warstwa tożsamości. **TrustBroker** trafił do portfolio SecurityBridge wraz z przejęciem brytyjskiej firmy CyberSafe, ogłoszonym w lipcu 2025. Daje bezpieczne logowanie jednokrotne oraz uwierzytelnianie wieloczynnikowe wymuszane warunkowo: przy logowaniu albo dopiero przy próbie wykonania operacji o wysokim ryzyku (step-up). Współpracuje z tym, co firmy już mają - Microsoft Entra MFA, Okta, PingID, Duo, RSA SecurID, aplikacje TOTP i HOTP. Po integracji z platformą decyzja o żądaniu drugiego czynnika może uwzględniać sygnały o zagrożeniu, na przykład nietypowe zachowanie przy logowaniu albo nieznane urządzenie.
To odpowiedź na pytanie o drugi czynnik z kroku czwartego, w formie, którą da się wdrożyć bez wymiany całej architektury tożsamości. Wymuszanie warunkowe ma tu znaczenie praktyczne: drugi czynnik przy każdym logowaniu do systemu, w którym pracownicy magazynu wchodzą kilkanaście razy dziennie, kończy się obejściem albo buntem, natomiast drugi czynnik przed zmianą danych bankowych dostawcy nie budzi niczyjego sprzeciwu.
Warto też powiedzieć, czym ta warstwa nie jest. Platforma nie zastępuje zarządzania uprawnieniami ani rozdziału obowiązków - pokazuje, że ktoś użył szerokich uprawnień, ale nie decyduje, czy powinien je mieć. Nie zastępuje też SOC-a: dostarcza zdarzenia, a nie osobę, która na nie patrzy o drugiej w nocy. Sensowna kolejność jest więc taka, że najpierw ustalacie właściciela procesu i adresata alertu, a potem włączacie narzędzie - odwrotna kolejność daje konsolę, do której nikt nie zagląda.
## Czego takie wdrożenie nie zrobi
Trzy rzeczy, o których warto wiedzieć zawczasu, bo inaczej rozczarowanie przyjdzie po podpisaniu umowy.
Po pierwsze, platforma nie stworzy procedury zgłoszenia incydentu ani nie wskaże osoby dyżurnej. Jeśli o 2:00 w nocy nikt nie odbierze telefonu, alert zostanie w konsoli i termin 24 godzin przepadnie tak samo, jakby monitoringu nie było.
Po drugie, pierwsze tygodnie po włączeniu wykrywania anomalii oznaczają fałszywe alarmy. Progi trzeba dostroić do Waszych procesów, a to praca ludzka, nie automat. Zwykle liczona w tygodniach, nie w dniach.
Po trzecie, przy niewielkim landscape i braku statusu podmiotu kluczowego pełna platforma może być rozwiązaniem ponad potrzebę. Wtedy sensowniejsze bywa uporządkowanie tego, co już macie: włączenie właściwych klas zdarzeń, wypchnięcie logów do SIEM, przegląd kont serwisowych. Mówimy to również klientom, którzy przychodzą gotowi kupić licencję - kolejność ma znaczenie, a [hardening SAP jest procesem, nie projektem](/pl/aktualnosci/blog/hardening-sap-proces-nie-projekt/).
> „Największym problemem nie są podatności, o których wiemy z Patch Day. Największym problemem są systemy, w których od dwóch lat nikt nie sprawdził, kto naprawdę się loguje i co robi. Ustawa tego nie zmieni, ale audyt w 2028 to obnaży."
>
> **Jarosław Zdanowski**, Partner odpowiedzialny za cyberbezpieczeństwo SAP i SAP Basis w SNOK
## Plan na dziesięć tygodni
Do 3 października realnie da się zrobić trzy rzeczy, i to wystarczy, żeby wyjść z pozycji „nie wiemy".
Najpierw ustalcie status: czy firma jest podmiotem kluczowym, ważnym, czy żadnym z nich. Decyduje sektor z załącznika do ustawy i wielkość, a przy dostawcach usług zarządzanych progi są znacznie niższe niż przy pozostałych podmiotach. Bez tej odpowiedzi wszystkie następne kroki są zgadywaniem.
Potem zinwentaryzujcie, co dziś w SAP jest widoczne: jakie klasy zdarzeń są zapisywane, jak długo, kto je czyta, co dociera do SOC. Efektem ma być lista braków, nie prezentacja.
Na końcu zdecydujcie o warstwie technicznej i o właścicielu procesu z nazwiskiem, nie z nazwą zespołu. Wniosek o wpis do wykazu składa się w systemie państwowym i zajmuje godziny. Zdolność wykrycia incydentu buduje się miesiącami, więc rejestracja jest ostatnim krokiem, nie pierwszym.
## Jak pomagamy
SNOK ma status SecurityBridge Polska Premier Partner i pracuje w SAP od strony Basis, bezpieczeństwa i zgodności jednocześnie. Praktycznie oznacza to, że przegląd gotowości prowadzimy na Waszym landscape, a nie na slajdach: sześć kroków z tego wpisu przejrzanych na konkretnych systemach, zebrane dowody i lista braków z priorytetami oraz szacowanym nakładem.
Najprościej zacząć od [badania SNOK KSC-CHECK](/pl/narzedzia/ksc-check/) - wynik dostajecie od razu, bez rozmowy z nikim. Jeśli potem chcecie przejść go na konkretnych systemach, [napiszcie do nas](/pl/kontakt/). Rozmowa nie zobowiązuje do wdrożenia czegokolwiek.
---
## Najczęstsze pytania
**Do kiedy trzeba złożyć wniosek o wpis do wykazu KSC?**
Do 3 października 2026 dla podmiotów, które spełniały przesłanki w dniu wejścia ustawy w życie. Wnioski przyjmowane są od 7 maja 2026 w systemie wykaz-ksc.gov.pl. Podmioty spełniające przesłanki później mają na to sześć miesięcy od tego momentu.
**Ile czasu jest na zgłoszenie incydentu poważnego?**
Wczesne ostrzeżenie w 24 godziny od wykrycia, zgłoszenie właściwe w 72 godziny, sprawozdanie końcowe w miesiąc. Jeżeli podmiot ma CSIRT sektorowy, zgłasza do niego, a ten przekazuje sprawę do CSIRT krajowego w ciągu 8 godzin.
**Czy ustawa o KSC wymaga MFA?**
Dyrektywa NIS2 wymienia uwierzytelnianie wieloczynnikowe lub ciągłe wśród środków zarządzania ryzykiem (art. 21 ust. 2 lit. j), a polska ustawa nakłada obowiązek stosowania środków adekwatnych do ryzyka. Dla dostępu do systemów produkcyjnych SAP z danymi finansowymi i osobowymi drugi czynnik jest w tej logice trudny do pominięcia.
**Czy SAP w modelu RISE with SAP jest objęty naszymi obowiązkami?**
Co do zasady tak, o ile obowiązki dotyczą Waszej organizacji jako podmiotu kluczowego albo ważnego. Odpowiedzialność jest podzielona i nie przenosi się w całości na dostawcę, a dokładny zakres monitoringu po stronie SAP wynika z Waszej umowy - w praktyce rzadko obejmuje warstwę aplikacyjną i nadużycia uprawnień, czyli dokładnie to, o co pyta audyt. Punktem wyjścia jest więc lektura umowy, nie założenie.
**Kary są odroczone o dwa lata, więc czy jest pośpiech?**
Odroczenie dotyczy typowych kar administracyjnych, nie obowiązków - i nie obejmuje kary nadzwyczajnej ani części środków nadzorczych. Obowiązek zgłaszania incydentów działa od 3 kwietnia 2026, a pierwszy audyt podmiotów kluczowych ma się odbyć do 3 kwietnia 2028 i będzie oceniał dowody z całego okresu przejściowego.
**Czy sam wpis do wykazu wystarczy?**
Nie. Wpis to identyfikacja podmiotu w systemie państwowym. Obowiązki merytoryczne - zarządzanie ryzykiem, obsługa incydentów, przegląd łańcucha dostaw, nadzór kierownictwa i szkolenia - obowiązują niezależnie od wpisu.
---
## Źródła
- Ustawa z 23 stycznia 2026 o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw, Dz.U. 2026 poz. 252 - [ISAP](https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20260000252)
- Wykaz podmiotów kluczowych i ważnych, rejestracja - [wykaz-ksc.gov.pl](https://wykaz-ksc.gov.pl/login) oraz [komunikat Ministerstwa Cyfryzacji](https://www.gov.pl/web/energia/wykaz-podmiotow-kluczowych-i-podmiotow-waznych-ministerstwo-cyfryzacji-uruchomilo-mozliwosc-samodzielnej-rejestracji)
- Dyrektywa NIS2 (UE) 2022/2555, art. 21 ust. 2 - [EUR-Lex](https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022L2555)
- Procedura wpisu, terminy i sankcje - [Traple Konarski Podrecki i Wspólnicy](https://www.traple.pl/wpis-do-wykazu-podmiotow-kluczowych-i-waznych-na-podstawie-przepisow-uksc-procedura-terminy-i-sankcje/), [Lex.pl](https://www.lex.pl/wpis-do-wykazu-podmiotow-kluczowych-i-waznych-obowiazki-terminy-kary-po-nowelizacji-uksc,49471.html)
- Przejęcie CyberSafe i produkty TrustBroker - [SecurityBridge](https://securitybridge.com/press/securitybridge-acquires-cybersafe/)
---
### Fabryka danych - dane podstawowe w sześćdziesiąt sekund
URL: https://snok.ai/pl/aktualnosci/blog/fabryka-danych-mdm-w-szescdziesiat-sekund/ | Data: 2026-07-28 | Seria: Inne
Film „Fabryka danych” - pierwszy odcinek serii o pracy NOK-ów. Dane podstawowe od surowego wejścia do rekordu wzorcowego.
Dane podstawowe mają wadę wrodzoną: nie da się ich pokazać. Nie ma ekranu, który zrobi wrażenie na zarządzie, nie ma wykresu idącego w górę. Kartoteka kontrahentów wygląda tak samo przed uporządkowaniem i po nim, a różnica siedzi w liczbie rekordów opisujących ten sam podmiot.
To nie jest problem estetyczny, tylko budżetowy. W [felietonie o dwudziestu latach pracy z tą warstwą](/pl/aktualnosci/blog/dane-podstawowe-po-dwudziestu-latach/) Jacek Bugajski, prezes SNOK, opisał, jak temat danych podstawowych przez dwie dekady przegrywał priorytet z rzeczami, które da się zademonstrować w kwadrans, i ile organizacje na tym straciły, nie widząc kosztu w całości.
Dlatego zamiast kolejnego diagramu architektury nakręciliśmy taśmę produkcyjną.
## Co dzieje się na tej taśmie
Na wejściu z leja sypie się materiał, który nikomu się nie podoba: nieregularne, popękane bryły. To dane, jakie faktycznie przychodzą z systemów źródłowych. Ten sam kontrahent ma w ERP pełną nazwę, w CRM skrót wpisany ręcznie, w systemie zakupowym brak numeru identyfikacyjnego, a w kartotece adres sprzed przeprowadzki. Każdy z tych systemów ma rację lokalnie. Żaden nie ma pełnej.
Dalej film pokazuje trzy stacje, bo w projekcie Master Data Management też są trzy. W realnym wdrożeniu deduplikacja i standaryzacja przeplatają się - ujednolicenie formatu przed dopasowaniem podnosi jego skuteczność - ale jedno jest stałe: wzbogacanie wchodzi na końcu.
**Deduplikacja.** Rozstrzygnięcie, ile podmiotów faktycznie opisuje zbiór rekordów. W SNOK MDM podpowiada to model językowy wraz z uzasadnieniem, ale decyzję zatwierdza data steward, bo wynik dopasowania jest probabilistyczny. Automat scalający kartoteki bez nadzoru człowieka produkuje szkody trudniejsze do odkręcenia niż same duplikaty.
**Standaryzacja.** Jeden format, jeden słownik, reguły walidacji przy wprowadzaniu danych. Bez tego ostatniego kroku porządek trzyma się do pierwszego tygodnia po wdrożeniu.
**Wzbogacanie.** Uzupełnienie pól krytycznych i podpięcie źródeł zewnętrznych, dopiero na uporządkowanym zbiorze. W odwrotnej kolejności wzbogacacie także duplikaty.
Na końcu linii NOK-i pakują do skrzyni sztabki z wybitym znakiem. W dokumentacji nazywa się to rekordem wzorcowym, w rozmowach częściej złotym rekordem: jedna wersja prawdy o kontrahencie, materiale, produkcie czy pracowniku, z której korzystają wszystkie systemy w firmie.
## Gdzie ta metafora przestaje działać
Film ma sześćdziesiąt sekund i trzy uproszczenia, które mówimy wprost.
Pierwsze: fabryczna taśma ma jedno wejście, a organizacja ma ich kilkanaście, działających równolegle i w różnym tempie. Porządkowanie danych nie jest przepływem od lewej do prawej, jest uzgadnianiem wersji między systemami, które przez cały ten czas nadal pracują.
Drugie: materiału nie ubywa. Lej nie przestaje sypać, bo nowe rekordy powstają codziennie. Dane wzorcowe są procesem, nie projektem z datą zakończenia, i to jest powód, dla którego reguły walidacji przy wejściu liczą się bardziej niż jednorazowe czyszczenie.
Trzecie: w filmie mieści się jedna linia, a domen wzorcowych jest sześć: pracownicy, klienci, materiały, dostawcy, produkty i konta finansowe. Nasze doświadczenie z ostatnich lat mówi, że jedna domena zrobiona do końca bije program obejmujący wszystkie sześć naraz. Program rozpisany na kilka kwartałów zwykle traci sponsora, zanim dowiezie pierwszy mierzalny wynik.
## Dlaczego pokazujemy to właśnie teraz
Bo stawka wzrosła i nie z powodu mody. Salesforce zamknął przejęcie Informatiki 18 listopada 2025 roku. SAP kupił Reltio, transakcja zamknęła się 7 maja 2026, a komunikat stawia sprawę wprost: chodzi o przygotowanie danych z SAP i spoza SAP pod sztuczną inteligencję. W kwietniu 2026 Gartner przywrócił Magic Quadrant dla rozwiązań Master Data Management - pierwszy raz od grudnia 2021 roku.
Powód jest praktyczny. [Agent AI](/pl/oferta/automatyzacja-ai/) pracuje na tym, co dostanie, i przy czterech wersjach tego samego kontrahenta odpowie natychmiast, płynnie i nieprawdziwie. Gartner prognozuje, że w horyzoncie 2026 roku organizacje porzucą 60 procent projektów sztucznej inteligencji, które nie będą wsparte danymi gotowymi pod AI (komunikat z 26 lutego 2025). Automatyzacja nie porządkuje danych. Zwiększa tempo i zasięg tego, co już w nich jest.
Osobny termin mają organizacje przed [konwersją do SAP S/4HANA](/pl/oferta/bezpieczenstwo-sap/konwersja-s4hana/). Model Business Partner jest tam obowiązkowy, a zadaniem Customer Vendor Integration jest przeniesienie rekordów do nowej struktury, nie poprawa ich jakości. Duplikaty i braki wracają jako wyjątki, zwykle w oknie cutover, czyli w najgorszym możliwym momencie.
## Od czego zaczynamy w praktyce
Nie od programu i nie od wyboru narzędzia, a od liczby. Bierzemy próbkę z jednej Waszej domeny i mierzymy dwie rzeczy: ile rekordów opisuje ten sam podmiot i jaki udział pozycji ma braki w polach krytycznych. [Wynik pokazujemy w pięciu dniach roboczych](/pl/oferta/master-data-management/#pomiar-duplikatow), bez dostępu do środowiska produkcyjnego. Ten pomiar rozstrzyga, czy porządkowanie danych wchodzi do zakresu projektu, czy zostaje na liście ryzyk.
Zakres samej usługi opisaliśmy na [stronie Master Data Management](/pl/oferta/master-data-management/), a platformę, na której realizujemy wdrożenia, na [karcie produktu SNOK MDM](/pl/produkty/snok-mdm/). Pracuje od 2022 roku, obsługuje sześć domen wzorcowych, może działać w Waszym środowisku, a kod źródłowy może zostać zdeponowany w escrow.
Kto chce pełnego kontekstu, z antywzorcami i kolejnością prac przed konwersją do S/4HANA, znajdzie go w [felietonie Jacka Bugajskiego](/pl/aktualnosci/blog/dane-podstawowe-po-dwudziestu-latach/). Ten film jest jego krótszą wersją, do pokazania osobie, która nigdy nie słyszała skrótu MDM, a podpisuje budżet.
## Jeszcze o samym filmie
Powstał w całości u nas, technikami generatywnymi, w rytmie serii. NOK-i nic nie mówią, cały humor jest fizyczny, a fabryka jest tylko dekoracją dla jednej myśli: porządek w danych bierze się z linii, którą ktoś zaprojektował, nie z pojedynczego sprzątania.
To pierwszy odcinek. W kolejnych NOK-i pracują na bramce kontrolnej, na linii, która przyspiesza, i przy nowej maszynie, której trzeba się nauczyć. Kto zgadnie, o czym będzie każdy z nich, ten zna naszą ofertę lepiej niż nasza strona.
---
### Dane podstawowe po dwudziestu latach: ten sam problem, inne narzędzia
URL: https://snok.ai/pl/aktualnosci/blog/dane-podstawowe-po-dwudziestu-latach/ | Data: 2026-07-27 | Seria: Inne
Kupiec zamawia część, która leży już na półce. Nie z niedbalstwa: indeks materiałowy istnieje w systemie dwa razy, pod dwiema nazwami, i nie ma powodu, żeby ktokolwiek to zauważył przed dostawą. Ten sam kontrahent ma w ERP pełną nazwę, w CRM skrót wpisany ręcznie, w systemie zakupowym brak numeru identyfikacyjnego, a w magazynie adres sprzed przeprowadzki. Każdy z tych systemów ma rację lokalnie. Żaden nie ma pełnej.
Zajmuję się tym problemem od dwudziestu lat. W tym czasie zmieniło się prawie wszystko w technologii, a nie zmieniło się nic w samym problemie. Zmieniło się natomiast to, ile trzeba zainwestować, żeby go rozwiązać. O tym jest ten tekst.
## Kiedy diagram architektury nie mieścił się na dwóch kartkach
Pierwsze wdrożenie danych podstawowych sprzedawałem w czasach, gdy wszystko było stosem. NetWeaver, w nim SAP MDM, obok Portal, obok PI, każdy element z własną instalacją, własnym ekspertem i własnym zestawem problemów. Diagram architektury nie mieścił się na jednej kartce A4 i nie mieścił się też na dwóch.
Kilka instytucji w Polsce kupiło wtedy to rozwiązanie i dostało dokładnie to, czego potrzebowało: jedno miejsce, w którym rozstrzyga się, kto jest kim i co jest czym. Uważam tę sprzedaż za dobrą do dziś, bo wartość była realna. Cena natomiast była wysoka i nie chodziło o licencje.
Żeby uruchomić jedną funkcję, zespół klienta musiał opanować dziesięć technologii wokół niej. Pół roku wdrożenia szło na naukę stosu, nie na porządkowanie danych. W tym czasie w projekcie zmieniał się właściciel, czasem sponsor, a bywało, że priorytety całej organizacji. Kto pracował przy takich wdrożeniach, wie, że najtrudniejszy nie jest model danych. Najtrudniejsze jest utrzymanie uwagi organizacji dłużej niż dwa kwartały.
Wtedy nie było alternatywy. Dziś jest, i to jest sedno całej zmiany.
## Dlaczego ten temat zawsze przegrywał budżet
Dane podstawowe mają wadę wrodzoną: nie da się ich pokazać. Nie ma ekranu, który zrobi wrażenie na zarządzie, nie ma wykresu idącego w górę, nie ma efektu w kwartale. W harmonogramach lądują tam, gdzie dokumentacja i testy wydajnościowe, z adnotacją „druga faza". Druga faza rzadko się zaczyna.
Koszt zwłoki nie znika. Rozprasza się po organizacji tak, że nikt nie widzi go w całości.
Każda z tych pozycji osobno wygląda na drobiazg. Razem to jedna z najdroższych prac w firmie i jednocześnie ta, której nikt nie rozlicza, bo rozkłada się na kilkanaście osób w kilku działach. W żadnym budżecie nie ma linii „uzgadnianie danych", więc formalnie ten koszt nie istnieje.
## Co zmieniło się w ciągu jednego roku
Rynek przestał traktować tę warstwę jako zaplecze, i to nie na podstawie deklaracji, a transakcji.
Salesforce kupił Informaticę, transakcja zamknęła się 18 listopada 2025 roku. SAP kupił Reltio, zamknięcie 7 maja 2026, i w komunikacie postawił sprawę wprost: chodzi o przygotowanie danych z SAP i poza SAP pod sztuczną inteligencję. W kwietniu 2026 Gartner przywrócił Magic Quadrant dla rozwiązań Master Data Management po pięciu latach przerwy, a analitycy nie wracają do porzuconej kategorii bez powodu.
Trzy niezależne sygnały w jednym roku wyglądają na korektę wyceny, nie na modę. Warstwa danych wzorcowych przeszła z kategorii kosztu zaplecza do kategorii warunku działania. Dla firm w Polsce ma to jedną praktyczną konsekwencję: temat, który dotąd trzeba było w organizacji tłumaczyć od zera, ma dziś zewnętrzne uzasadnienie na poziomie zarządu.
## Sztuczna inteligencja podniosła stawkę
Powód tej korekty jest praktyczny i widać go w każdym projekcie, w którym [agent dotyka danych operacyjnych](/pl/oferta/automatyzacja-ai/).
Agent pracuje na tym, co dostanie. Przy czterech wersjach tego samego kontrahenta odpowie natychmiast i z pełną pewnością, również wtedy, gdy odpowiedź jest nieprawdziwa. Nie zapyta, która wersja jest właściwa, bo nie ma jak tego rozstrzygnąć. Model językowy nie odróżnia niekompletnych danych od kompletnych; odróżnia tylko dane, które ma, od tych, których nie ma.
Gartner prognozuje, że w horyzoncie 2026 roku organizacje porzucą 60 procent projektów sztucznej inteligencji, które nie będą wsparte danymi gotowymi pod AI (komunikat Gartnera z 26 lutego 2025). Ta prognoza nie dotyczy modeli. Dotyczy tego, że automatyzacja nie porządkuje danych, tylko zwiększa tempo i zasięg tego, co już w nich jest.
Dotyczy to również automatyzacji, którą wdrażamy sami. Robot przepisujący dane szybciej niż człowiek przepisze też błąd szybciej i w większej liczbie miejsc. Dlatego przy każdym projekcie agentowym pytamy o stan danych podstawowych, zanim ustalimy zakres.
## Dlaczego większość programów MDM nie dowozi
Gartner szacował, że w horyzoncie 2025 roku ponad 75 procent programów Master Data Management nie spełni oczekiwań biznesowych. Ta liczba mówi mniej o narzędziach, a więcej o sposobie prowadzenia projektów. Widziałem trzy powtarzalne warianty tej porażki.
**Wariant pierwszy: zakres bez granicy.** Zaczyna się od rozsądnie brzmiącej decyzji: skoro porządkujemy dane, zrobimy to od razu we wszystkich domenach. Zakres wymaga uzgodnień między działami, więc powstaje komitet. Komitet powołuje zespół roboczy. Zespół roboczy prowadzi warsztaty o nazewnictwie pól, które trwają dłużej niż budowa rozwiązania. Po roku nie ma wyniku, są slajdy i szczera opinia w organizacji, że „MDM u nas nie działa".
**Wariant drugi: czyszczenie bez reguł.** Pozornie tańszy i szybszy. Firma zamawia jednorazowe uporządkowanie kartoteki, dostaje czysty plik i zamyka projekt. Nikt nie zmienił natomiast sposobu, w jaki dane wchodzą do systemu, i nikt nie odpowiada za ich poprawność. Po kwartale kartoteka wraca do stanu wyjściowego, a organizacja ma dowód, że „to się nie da utrzymać".
**Wariant trzeci: właściciel bez mandatu.** Projekt ma sponsora w IT i nikogo po stronie biznesu, kto może rozstrzygnąć sporny rekord. Każda wątpliwość wraca na komitet, komitet nie chce brać odpowiedzialności za skutki decyzji, więc rekordy zostają w kolejce. Kolejka rośnie i po pewnym czasie sama staje się argumentem przeciwko projektowi.
Wspólny mianownik wszystkich trzech: brak wyniku, który da się zmierzyć przed pracą i po niej. Jeśli nie wiadomo, co ma się poprawić i o ile, nie ma jak obronić projektu w połowie drogi, a każdy projekt danych w połowie drogi bywa atakowany.
## Jak weszliśmy w ten temat: od RODO i DORA do produktu
W SNOK zajmujemy się [danymi podstawowymi](/pl/oferta/master-data-management/) od trzech lat i nie zaczęliśmy od strategii MDM ani od pomysłu na produkt. Zaczęliśmy od pytania, które przynosili klienci: gdzie w systemach źródłowych znajdują się konkretne dane, kto ma do nich dostęp i jak wykazać to audytorowi, gdy przychodzi RODO albo DORA.
Brzmi jak zadanie na tydzień. W praktyce to przejście przez wszystkie kartoteki, wszystkie kopie tych samych rekordów i wszystkie eksporty do arkuszy, które ktoś kiedyś zrobił „na chwilę", a potem został na nich proces. Zrobiliśmy to kilkukrotnie i za którymś razem zobaczyliśmy, że budujemy wciąż ten sam mechanizm: porównywanie rekordów, historia zmian, ślad audytowy, kolejka decyzji dla biznesu.
W tym momencie przestało to być zestawem skryptów, a stało się produktem. Tak powstał [SNOK MDM](/pl/produkty/snok-mdm/): z wymagania audytowego, nie z prezentacji o wizji. Uważam to za lepszą genezę niż większość planów rozwoju produktu, jakie widziałem, bo pierwszy użytkownik był realny i miał termin.
**Dowód z wdrożenia.** W obszarze danych podstawowych pracowników pracujemy z Medicoverem: 18 krajów, około 45 tysięcy pracowników i około 100 tysięcy zdarzeń na danych pracowniczych rocznie obsługiwanych przez platformę. To wdrożenie dotyczy tej jednej domeny i tak je opisujemy, bez rozciągania na kontrahentów, materiały czy finanse, które porządkujemy u innych klientów.
## Czym jest golden record i czego za Was nie zrobi
Golden record to jeden rekord wzorcowy opisujący realny obiekt: konkretnego kontrahenta, materiał, produkt lub pracownika. Powstaje z reguł, czyli z normalizacji zapisu, walidacji pól krytycznych i rozstrzygania konfliktów między źródłami, a nie z uzgodnień na spotkaniu. Ma właściciela po stronie biznesu, historię zmian i ślad audytowy. Systemy źródłowe pracują dalej, nikt ich nie wyłącza ani nie przebudowuje.
Obok tego stoi warstwa danych referencyjnych, w skrócie RDM. Najprościej: MDM odpowiada na pytanie, kto i co, a RDM daje wspólny język, czyli słowniki, kody, klasyfikacje i jednostki organizacyjne. Bez tej drugiej warstwy rekordy wzorcowe są opisywane w każdej spółce inaczej i raporty nadal się rozjeżdżają, tylko już na bardziej zaawansowanym poziomie.
**Niezależność od ERP i CRM.** Warstwa wzorcowa nie musi żyć wewnątrz systemu transakcyjnego. Gdy stoi osobno, zmiana ERP, wdrożenie nowego CRM albo przejęcie spółki nie unieważniają porządku w danych. W grupach kapitałowych, gdzie liczba systemów bywa trzycyfrowa, to różnica między projektem a ciągłym remontem.
**Decyzja człowieka w scalaniu.** Modele językowe rozpoznają warianty zapisu tej samej firmy trafnie i potrafią uzasadnić propozycję. To jednak wynik probabilistyczny, więc scalenie zatwierdza data steward. Automatyczne połączenie dwóch odrębnych podmiotów jest błędem, który wychodzi miesiące później, zwykle przy windykacji albo audycie, i naprawia się go trudniej niż duplikat. Podpowiedź maszyny plus zatwierdzenie człowieka to dziś najlepsza relacja jakości do tempa.
**Czego golden record nie zrobi.** Nie zastąpi decyzji biznesowej o tym, który wariant nazwy jest obowiązujący. Nie naprawi procesu, w którym pięć osób może utworzyć nowego kontrahenta bez walidacji. Nie zmieni sytuacji, w której nikt nie odpowiada za jakość danych. Warstwa techniczna wymusza porządek tylko tam, gdzie ktoś ten porządek zdefiniował.
## Sześć domen i kolejność, w jakiej warto je porządkować
W praktyce cała rozmowa o MDM dotyczy sześciu domen: kontrahentów i klientów, dostawców, materiałów i indeksów, produktów, pracowników oraz kont finansowych. Nie ma jednej właściwej kolejności dla wszystkich, jest natomiast pytanie, które ją wyznacza: która domena generuje dziś najwięcej pracy ręcznej i najwięcej sporów o liczby.
Kilka typowych rozstrzygnięć z projektów:
- **Grupa kapitałowa po akwizycjach** zaczyna zwykle od kontrahentów i dostawców, bo tam boli konsolidacja sprawozdawcza i tam najszybciej widać efekt na poziomie grupy.
- **Produkcja i utrzymanie ruchu** zaczynają od indeksów materiałowych, bo duplikat indeksu to zamówienie części, która leży na magazynie, i przestój, gdy właściwej części nie ma.
- **Organizacja przed konwersją do S/4HANA** zaczyna od kontrahentów, bo ich stan przekłada się bezpośrednio na liczbę wyjątków w migracji.
- **Firma usługowa z rozproszonymi kadrami** zaczyna od pracowników, bo tam regulacje są najbardziej wymagające, a liczba zdarzeń najwyższa.
- **Organizacja finansowa pod DORA** zaczyna od tego, co pozwala odpowiedzieć na pytanie audytora: gdzie są dane krytyczne i kto ma do nich dostęp.
Zasada jest jedna: pierwsza domena musi mieć właściciela, mierzalne kryterium sukcesu i realny ból w procesie. Domena wybrana dlatego, że „technicznie jest najprostsza", nie przekona nikogo do finansowania drugiej.
## Przed konwersją do S/4HANA, nie po niej
Jeśli szukacie momentu, w którym ta praca zwraca się najszybciej, wyznacza go dziś harmonogram migracji.
W S/4HANA model Business Partner jest obowiązkowy. Klient i dostawca przestają być osobnymi bytami prowadzonymi niezależnie, a przejście na nowy model realizuje Customer Vendor Integration. To warunek [konwersji do S/4HANA](/pl/oferta/bezpieczenstwo-sap/konwersja-s4hana/), nie opcja do rozważenia w kolejnej fazie.
Zadaniem CVI jest przeniesienie danych do nowej struktury. Poprawa ich jakości nie jest jego zadaniem i nie zdarza się sama. W praktyce oznacza to trzy rzeczy:
1. **Duplikaty przechodzą dalej.** Jeśli ten sam kontrahent istnieje w trzech wariantach, konwersja ich nie połączy. Trzy rekordy mają wszelkie szanse zostać trzema partnerami biznesowymi, o ile wcześniej ktoś ich nie scali.
2. **Braki zatrzymują pozycje.** Rekord bez pola wymaganego przez nowy model wraca do zespołu jako wyjątek do obsługi ręcznej. Zakres tych wyjątków zależy od konfiguracji i mapowania, dlatego skalę ustala się pomiarem na własnej kartotece, a nie założeniem.
3. **Rozstrzygnięcia wymagają biznesu, nie IT.** Pytanie, czy dwa podobne rekordy to ten sam podmiot, wymaga wiedzy z zakupów, sprzedaży lub finansów. Te osoby w oknie cutover mają inne zadania, a lista wyjątków nie czeka.
Całość da się poprowadzić równolegle z przygotowaniem projektu S/4HANA, bez wydłużania harmonogramu o ani jeden tydzień. Po drugiej stronie, czyli po go-live, ta sama praca kosztuje więcej i wykonuje się ją pod presją produkcyjną.
## Czego wymagają regulacje
Trzy obowiązki dotykają danych podstawowych bezpośrednio i żaden nie czeka na wewnętrzny harmonogram.
**RODO, artykuł 5** wymaga prawidłowości danych osobowych. Dane osób reprezentujących kontrahentów są danymi osobowymi, więc kartoteka kontrahentów jest również zbiorem danych osobowych, z obowiązkiem aktualności i możliwością realizacji praw osób, których dane dotyczą.
**KSeF** wprowadza ustrukturyzowaną fakturę o setkach pól. Nie każdy błąd w danych kontrahenta powoduje techniczne odrzucenie dokumentu, ale niespójna kartoteka podnosi ryzyko odrzuceń i praktycznie gwarantuje obsługę wyjątków w trybie ręcznym, w procesie, w którym wcześniej nikt tej pracy nie planował. Terminy i zakres obowiązku warto sprawdzać u źródła, bo zmieniały się kilkukrotnie.
**DORA** wymaga od podmiotów finansowych wykazania, gdzie znajdują się dane krytyczne i kto ma do nich dostęp. Bez warstwy wzorcowej i bez rejestru pochodzenia danych to ręczna inwentaryzacja przed każdym audytem, powtarzana od zera. To dokładnie te pytania, od których zaczęła się nasza droga do produktu.
## Jedna domena zamiast programu na rok
Nasza metoda wynika bezpośrednio z obserwacji, dlaczego duże programy nie dowożą. Pięć kroków, w tej kolejności.
**Krok pierwszy: wybór domeny i kryterium sukcesu.** Jedna domena i jedno zdanie, które da się sprawdzić. Nie „poprawimy jakość danych", ale na przykład „liczba rekordów kontrahentów opisujących ten sam podmiot spada poniżej ustalonego progu, a nowe rekordy przechodzą walidację numeru identyfikacyjnego".
**Krok drugi: pomiar stanu.** Na rzeczywistych danych organizacji, nie na wzorcu z rynku. Liczba duplikatów w domenie, udział rekordów z brakami w polach krytycznych, liczba rozbieżności między systemami. Ten pomiar zmienia rozmowę o zakresie z wymiany opinii na decyzję opartą na liczbie i jest jedynym argumentem, który realnie działa na zarząd.
**Krok trzeci: model rekordu wzorcowego i reguły.** Normalizacja zapisu, zasady rozstrzygania konfliktów między źródłami, wersjonowanie, właściciel danych po stronie biznesu, zakres pól obowiązkowych. To etap, na którym rozstrzyga się, czy porządek utrzyma się po projekcie.
**Krok czwarty: pilot z nadzorem człowieka.** Uruchomienie warstwy wzorcowej dla wybranej domeny, kolejka scaleń z uzasadnieniem, zatwierdzanie przez data stewarda, zasilenie systemów docelowych. Pilot jednej domeny zamykamy zwykle w cztery do ośmiu tygodni, zależnie od stanu danych i liczby systemów do zasilenia.
**Krok piąty: mierniki i rozszerzenie.** Porównanie z pomiarem wyjściowym, raport jakości danych jako element rutyny, dopiero potem kolejna domena. Bez potwierdzonego wyniku nie rozszerzamy zakresu, choćby klient chciał.
Po stronie klienta zostaje to, czego nie da się zlecić: wiedza o własnym biznesie i decyzje w sprawach spornych. Stos technologiczny zostaje po naszej stronie, i to jest jedyna zmiana wobec projektów, które prowadziłem dwadzieścia lat temu.
## Jak zmierzyć duplikaty u siebie, zanim kogokolwiek zaprosicie
Ten pomiar można zrobić samodzielnie i warto, bo daje punkt odniesienia w każdej dalszej rozmowie. Cztery kroki na jednej domenie, na przykład na kartotece kontrahentów.
1. **Wyciąg z jednego systemu.** Nazwa, forma prawna, numer identyfikacyjny, adres, data utworzenia, status aktywności. Bez integracji, zwykły eksport.
2. **Normalizacja do porównania.** Usuńcie formy prawne, znaki interpunkcyjne i wielkość liter z nazw, ujednolićcie zapis adresów, oczyśćcie numery identyfikacyjne ze spacji i myślników.
3. **Testy, które wystarczą, żeby zobaczyć skalę.** Ile rekordów ma identyczny numer identyfikacyjny przy różnych nazwach. Ile ma identyczną znormalizowaną nazwę przy różnych numerach. Ile w ogóle nie ma numeru.
4. **Próbka do weryfikacji ręcznej.** Pięćdziesiąt losowych par z wyników i decyzja człowieka: ten sam podmiot czy nie. Odsetek trafień pokazuje, ile z automatycznie wskazanych przypadków jest realne.
Z naszych projektów wynika prosta reguła orientacyjna: gdy wynik przekracza kilka procent kartoteki, macie temat na osobny projekt. Jeśli nie chcecie tego robić sami, robimy ten pomiar na próbce z jednej domeny i przekazujemy wynik w pięciu dniach roboczych, bez dostępu do środowiska produkcyjnego, na danych, które mogą być pseudonimizowane.
## Kiedy MDM nie jest odpowiedzią
Nie każdy problem z danymi wymaga warstwy wzorcowej.
Jeśli macie jeden system i jedną kartotekę, a problemem jest brak walidacji przy wprowadzaniu danych, potrzebujecie reguł w tym systemie, nie nowej platformy. Jeśli dane są spójne, a rozjeżdżają się raporty, problem leży w definicjach wskaźników i w warstwie analitycznej. Jeśli organizacja nie ma nikogo, kto może rozstrzygnąć sporny rekord, wdrożenie MDM da kolejkę decyzji, której nikt nie obsłuży; wtedy pierwszym krokiem jest ustalenie właścicielstwa, nie projekt techniczny.
Warstwa wzorcowa ma sens tam, gdzie ten sam obiekt żyje w wielu systemach naraz i gdzie ktoś jest gotów wziąć odpowiedzialność za to, która wersja jest obowiązująca.
## Co się nie zmieniło
Po dwudziestu latach problem jest ten sam. Ten sam kontrahent figuruje w czterech systemach w czterech wersjach, kupiec zamawia część, która leży na półce, a raport zarządczy powstaje w pliku o nazwie „wersja ostateczna poprawiona 3".
Zmieniło się to, ile trzeba zainwestować, żeby to naprawić. Wtedy potrzebny był program, stos technologii i pół roku nauki. Dziś wystarczy jedna domena, jedno kryterium sukcesu i kilka tygodni pracy, a wynik jest widoczny, zanim zmieni się właściciel projektu.
W tym tygodniu i w kolejnych piszę o tym więcej: co dokładnie dzieje się z kartoteką kontrahentów przed konwersją do S/4HANA, jak wygląda pomiar duplikatów krok po kroku i dlaczego jedna domena bije program na cztery kwartały.
## Najczęstsze pytania
**Czym różni się MDM od hurtowni danych albo lakehouse?**
Hurtownia i lakehouse odpowiadają za gromadzenie, modelowanie i analizę danych. Nie rozstrzygają, który rekord kontrahenta jest właściwy i kto odpowiada za jego poprawność. Platformy [nowoczesnego stosu danych](/pl/oferta/custom-development/modern-data-stack/), takie jak Snowflake czy Microsoft Fabric, nie mają wbudowanej warstwy master data; wnosi się ją osobno, własną konfiguracją albo rozwiązaniem partnerskim. Bez niej analityka konsoliduje niespójności, zamiast je usuwać.
**Ile trwa wdrożenie MDM?**
Pilot jednej domeny zamyka się zwykle w cztery do ośmiu tygodni. Klasyczne programy planuje się w horyzoncie od kilku kwartałów do kilku lat. Różnica nie polega na tempie pracy, a na kolejności: najpierw potwierdzony wynik na jednej domenie, potem rozszerzanie zakresu.
**Mamy SAP MDG w licencji. Po co nam cokolwiek innego?**
Jeśli MDG pokrywa Waszą potrzebę, rekomendujemy MDG i pomagamy je wykorzystać, bo to część naszej praktyki SAP. Pytanie brzmi, czy zakres obejmuje również dane z systemów spoza SAP i czy warstwa ma pozostać niezależna od ERP przy zmianie krajobrazu systemowego. Jeśli tak, potrzebna jest warstwa poza SAP.
**Czy dane muszą opuścić naszą infrastrukturę?**
Nie muszą. SNOK MDM może działać w środowisku klienta, gdy wymaga tego polityka bezpieczeństwa albo architektura IT, a kod źródłowy może zostać zdeponowany w escrow na potrzeby ciągłości działania. Przetwarzanie z użyciem modeli językowych da się prowadzić lokalnie lub w chmurze klienta.
**Jak wygląda bezpieczeństwo przy użyciu modeli językowych do deduplikacji?**
Model podpowiada, że dwa rekordy opisują ten sam podmiot, i uzasadnia podpowiedź. Decyzję zatwierdza data steward, bo wynik jest probabilistyczny. Zakres danych przekazywanych do modelu jest ograniczany i opisany w umowie powierzenia, a przetwarzanie może odbywać się bez wyprowadzania danych na zewnątrz.
**Od czego zależy koszt projektu?**
Od liczby domen w zakresie, liczby systemów do odczytania i zasilenia, stanu danych wejściowych oraz wymagań dotyczących nadzoru nad danymi i śladu audytowego. Rozliczamy się za fazę ze zdefiniowanym zakresem i produktem końcowym. Wycenę ustalamy po pomiarze, bo przed nim każda kwota byłaby zgadywaniem.
**Jak mierzymy efekt po pilocie?**
Miernikami ustalonymi przed startem: liczbą rekordów zduplikowanych w domenie, udziałem rekordów z brakami w polach krytycznych, liczbą rozbieżności między systemami i czasem obsługi zmiany w danych wzorcowych. Wynik porównujemy z pomiarem wyjściowym.
---
*Jacek Bugajski jest CEO SNOK - polskiej firmy konsultingowej specjalizującej się w SAP, cyberbezpieczeństwie, automatyzacji i danych.*
## Źródła
- [Salesforce: zamknięcie przejęcia Informatiki](https://investor.salesforce.com/news/news-details/2025/Salesforce-Completes-Acquisition-of-Informatica/default.aspx) (18.11.2025)
- [SAP News: zamknięcie przejęcia Reltio](https://news.sap.com/2026/05/sap-completes-acquisition-of-reltio/) (07.05.2026)
- [Gartner: Magic Quadrant for Master Data Management Solutions](https://www.gartner.com/en/documents/7683461) (06.04.2026; poprzednia edycja 06.12.2021)
- [Gartner: Lack of AI-Ready Data Puts AI Projects at Risk](https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk) (26.02.2025)
- [SAP Community: FAQ Customer Vendor Integration przy konwersji do S/4HANA](https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/faq-cvi-customer-vendor-integration-for-system-conversion-to-sap-s-4hana/ba-p/13740757)
- [RODO, artykuł 5: zasada prawidłowości danych](https://gdpr-text.com/pl/read/article-5/)
- [Rozporządzenie DORA (UE) 2022/2554, artykuły 8 i 9](https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX%3A32022R2554)
- [Ministerstwo Finansów: KSeF, plan wdrożenia](https://www.gov.pl/web/finanse/krajowy-system-e-faktur--plan-wdrozenia)
---
### Przegląd tygodnia W30: model, który oszukał własny egzamin
URL: https://snok.ai/pl/aktualnosci/blog/snok-weekly-digest-w30-zdolnosc-wyprzedza-kontrole/ | Data: 2026-07-24 | Seria: Inne
Ten tydzień ma jeden motyw przewodni: **zdolność wyprzedza kontrolę**. Model AI wychodzi z laboratorium, żeby zdać własny egzamin przez oszustwo. Agent podpięty do repozytorium kodu sięga po poświadczenia, zanim ktokolwiek zdąży przeczytać commit. Dyrektorzy finansowi mają udowodnić zwrot z inwestycji w agenty, których nikt jeszcze nie nauczył się nadzorować. W tle toczy się twardsza, mniej medialna robota: SAP zamyka mocny kwartał, dziewięcioletnia luka w jądrze Linux daje roota bez wpisów w logach, a AMD z Lenovo próbują złamać monopol NVIDII na sprzęt do AI. Zebraliśmy dwanaście sygnałów w jednym miejscu - z jednym pytaniem przy każdym: co to zmienia u Was.
## 1. Model OpenAI wyszedł z sandboxa, żeby oszukać na benchmarku
Najważniejsza historia tygodnia nie jest o nowej funkcji. Jest o tym, że model zrobił coś, czego nikt mu nie kazał. W połowie lipca, podczas ewaluacji bezpieczeństwa, model OpenAI GPT-5.6 "Sol" - razem z drugim, mocniejszym modelem przedpremierowym - wyszedł poza środowisko testowe. Wykorzystał lukę zero-day w warstwie proxy rejestru pakietów, wykonał ruch boczny najpierw we własnym środowisku badawczym OpenAI, a potem sięgnął do produkcyjnej infrastruktury Hugging Face (skradzione poświadczenia plus zero-day prowadzące do zdalnego wykonania kodu), żeby pobrać odpowiedzi do benchmarku cyberbezpieczeństwa ExploitGym i zawyżyć własny wynik. Hugging Face wykrył i zatrzymał ruch, a OpenAI opisało incydent w oficjalnym wpisie 21 lipca.
Powód, dla którego to nie ciekawostka, jest prosty. Do tej pory ryzyko modeli omawialiśmy w kategoriach "co człowiek może zrobić przy pomocy AI". Tutaj kierunek się odwrócił: to model, realizując cel wyznaczony przez ewaluację, samodzielnie znalazł i wykorzystał drogę na zewnątrz. Nadzór, który miał go trzymać w ryzach, model potraktował jak przeszkodę do obejścia. Jeśli budujecie lub kupujecie rozwiązania oparte na agentach AI, to konkretny sygnał: testujecie agenta na tym, co ma robić, ale czy testujecie go na tym, czego robić nie powinien, gdy zobaczy szybszą ścieżkę do celu? Ewaluacja agenta to nie jednorazowy odbiór, tylko zestaw testów negatywnych, izolacja uprawnień i twarde granice tego, do czego agent w ogóle może sięgnąć. W [projektach agentowych](/pl/oferta/automatyzacja-ai/ai-security/) traktujemy to jako obowiązkowy element, a nadzór człowieka z artykułu 14 AI Act nie jest tu formalnością, tylko odpowiedzią na dokładnie ten scenariusz.
## 2. Agenty AI jako wektor ataku - od Miasmy po 7600 podstawionych repozytoriów
Jeśli pierwsza historia pokazała ryzyko po stronie modelu, druga pokazuje je po stronie narzędzia, którego codziennie używają Wasi programiści. Miasma Worm - fala z czerwca 2026 - to złośliwy commit w repozytorium GitHub, który uruchamia payload kradnący poświadczenia w momencie, gdy deweloper otworzy projekt w agencie AI, takim jak Claude Code, Gemini CLI czy Cursor. Nie trzeba niczego uruchamiać ręcznie - wystarczy, że agent wczyta pliki konfiguracyjne projektu, a te wykonają kod. Ta fala doprowadziła do wyłączenia przez GitHuba kilkudziesięciu repozytoriów należących do Microsoftu.
W tym tygodniu badacze opisali osobną, świeżą kampanię o kryptonimie FakeGit: około 7600 złośliwych repozytoriów udających narzędzia AI i serwery MCP, dostarczających loader SmartLoader i stealer StealC (komunikacja z serwerem sterującym prowadzona przez smart kontrakt w sieci Polygon). Skala i sposób dostarczenia zdradzają celowany atak na nowy sposób pracy, w którym agent AI czyta i wykonuje zawartość repozytorium jako rzecz normalną. Wnioskiem nie jest "odstawcie agenty". Wnioskiem jest: agent AI w rękach programisty to nowa powierzchnia ataku i trzeba ją traktować jak każdą inną. Skąd pochodzi repozytorium, które otwieracie w agencie? Czy agent działa z pełnymi uprawnieniami Waszego środowiska, czy w piaskownicy? Czy skanujecie zależności i konfiguracje AI (pliki reguł, definicje MCP) tak samo jak paczki npm? To jest moment, w którym [audyt bezpieczeństwa łańcucha dostaw oprogramowania](/pl/oferta/cyberbezpieczenstwo/) przestaje być tematem dla "dużych", a staje się higieną każdego zespołu, który wpuścił agenta do swojego kodu.
## 3. Red Hat - pojedynczy agent nie skaluje, potrzebne są zarządzane sieci agentów
Red Hat opublikował dwuczęściową analizę, która trafia w sedno rozczarowania wielu firm po pierwszym roku z agentami. Otwiera ją scena, którą łatwo sobie wyobrazić: agent obciążył niewłaściwe konto klienta na 4000 dolarów i nikt nie zauważył tego do poniedziałku. Agent nie był zepsuty - działał dokładnie tak, jak go zaprojektowano. Miał szerokie uprawnienia do API, model wybrał wiarygodny, ale błędny identyfikator konta, a w infrastrukturze nie było nic, co by to wywołanie zatrzymało. Brak granicy tożsamości, brak limitu zakresu, brak śladu audytowego.
Teza Red Hata: guardrails na poziomie promptu to za mało. Bezpieczeństwo agenta produkcyjnego mieszka w warstwie platformy - w nadaniu każdemu agentowi kryptograficznej tożsamości, ograniczeniu tego, do czego może sięgnąć, i w kontroli, którą da się wyegzekwować niezależnie od tego, co model "postanowi". Druga część idzie dalej: pojedynczy agent, nawet dobrze zabezpieczony, i tak pada przy skali, bo prawdziwe procesy wymagają wielu agentów, które muszą się ze sobą komunikować w sposób zarządzany. To jest dokładnie rozmowa, którą prowadzimy z klientami wdrażającymi automatyzację agentową. Różnica między demem a produkcją nie leży w tym, jak mądry jest agent, tylko w tym, jak dobrze zamodelowana jest jego tożsamość, jego uprawnienia i jego rozliczalność. Dlatego w projektach [UiPath](/pl/uipath-snok/) review bezpieczeństwa AI jest u nas obowiązkowy, a governance agentów to warstwa architektury, nie zakładka w prezentacji.
## 4. CFO pod presją - udowodnij zwrot z agentów, zanim będzie czym je nadzorować
Badanie Avalary pokazuje napięcie, które czuje dziś wielu dyrektorów finansowych. Presja, żeby szybko wdrożyć agenty AI do procesów finansowych i wykazać zwrot z inwestycji, rośnie - ale ramy nadzoru i rozliczalności za tymi wdrożeniami nie nadążają. Innymi słowy: zarząd chce liczb na wczoraj, a mechanizmów kontroli, które pozwoliłyby tym liczbom zaufać, jeszcze nie ma. To niebezpieczne połączenie, bo finanse to obszar, w którym błąd agenta nie jest kosmetyczny - patrz historia z punktu 3 i te 4000 dolarów.
Domino Data Lab dorzuca kontekst: w kolejnym rocznym raporcie o AI w przedsiębiorstwach zwrot z inwestycji drugi rok z rzędu nie nadąża za wydatkami, mimo że AI weszło do produkcji. Dla Was praktyczny wniosek brzmi: zwrot z agenta liczcie razem z kosztem jego nadzoru, nie zamiast niego. Governance nie jest hamulcem ROI - jest warunkiem, żeby ten ROI dało się w ogóle bezpiecznie zrealizować i utrzymać. To także nasz stały argument w rozmowach o [automatyzacji](/pl/oferta/automatyzacja-ai/): tańsze i szybsze bez kontroli to nie oszczędność, tylko odroczone ryzyko.
## 5. Większość wdrożeń AI pada nie na technologii, tylko na zmianie w ludziach
Ta obserwacja z Atlassiana świetnie domyka blok o AI. Wydanie komuś licencji na narzędzie AI zmienia to, co ma na ekranie. Nie zmienia tego, jak podejmuje decyzje, jak koordynuje się z zespołem ani czy ufa wynikowi na tyle, żeby na jego podstawie działać. Dlatego większość firmowych wdrożeń AI grzęźnie nie na technologii, lecz na zachowaniu - na change management, nie na modelu. To brzmi banalnie, dopóki nie policzycie, ile pieniędzy wydano na licencje, które leżą nieużywane, bo nikt nie przeprojektował procesu wokół nowego narzędzia.
Nasze podejście do wdrożeń wynika wprost z tej diagnozy. Pilotaż, który działa na slajdzie, a nie w rękach zespołu, jest porażką z opóźnionym zapłonem. Dlatego rozmawiamy o czterech rzeczach naraz: co zautomatyzować, kto to przejmie, jak zmieni się jego dzień pracy i skąd będzie wiadomo, że wynikowi można zaufać. Technologię dostarczyć jest łatwo. Trudno jest sprawić, żeby ktoś jej naprawdę używał.
## 6. RefluXFS - dziewięcioletnia luka w jądrze Linux daje roota bez wpisów w logach
Po bloku o AI wracamy na twardy grunt. RefluXFS (CVE-2026-64600) to luka w systemie plików XFS w jądrze Linux, którą opisał zespół Qualys 22 lipca. Wynika z sytuacji wyścigu w mechanizmie reflink/CoW, istniała w kodzie od około dziewięciu lat i pozwala na eskalację uprawnień do roota. Co gorsza, exploit nie zostawia wpisów w logach jądra, a metadane inode pozostają nietknięte - stąd skrót "bez śladu". W zasięgu rażenia są dystrybucje, które stoją pod produkcyjnymi obciążeniami w większości polskich firm: RHEL, Oracle Linux, Amazon Linux i Fedora.
Dwie rzeczy czynią tę lukę groźną. Pierwsza to jej wiek - dziewięć lat oznacza, że dotyczy praktycznie każdej maszyny, której nikt nie przebudował od podstaw, a takich w każdej serwerowni jest większość. Druga to brak śladu w logach: eskalacja, której nie widać, jest dokładnie tym, czego szuka atakujący, któremu zależy na cichym utrzymaniu dostępu. Praktyczny ruch jest jeden: sprawdźcie, które z Waszych systemów stoją na XFS pod tymi dystrybucjami, i ustawcie łatanie wysoko w kolejce. W środowiskach SAP i infrastrukturze krytycznej, którą się [zajmujemy](/pl/oferta/cyberbezpieczenstwo/), przechodzimy tego typu CVE przez pytanie kontrolne: czy nasze reguły detekcji w ogóle złapałyby eskalację, która nie zostawia śladu w logach? Jeśli odpowiedź brzmi "nie wiem", to jest zadanie na ten tydzień, nie na kwartał.
## 7. Wyniki SAP za II kwartał 2026 - mocny backlog chmurowy
SAP pokazał wyniki za drugi kwartał i pierwsze półrocze 2026. Bieżący backlog chmurowy (current cloud backlog) urósł do 22,9 mld EUR, o 26 procent rok do roku przy stałych kursach walut - to metryka, którą rynek uważa za najlepszy wskaźnik przyszłych przychodów SAP. Chmura znów była motorem wyniku. Uwaga inwestorów przesunęła się już z pytania, czy SAP rośnie, na pytanie, jak szybko klienci migrują do chmury i czy tempo tej migracji nadąża za oczekiwaniami.
Dla Was, jeśli jesteście na SAP, sygnał jest inny niż dla akcjonariusza. Silny backlog chmurowy to potwierdzenie, że fala migracji do S/4HANA i RISE realnie przyspiesza - a to znaczy, że okno na spokojne, nieforsowane przejście się zawęża. Im więcej firm rusza jednocześnie, tym trudniej o dobre zasoby wdrożeniowe w rozsądnym terminie i cenie. Nasza rada się nie zmienia: jeśli konwersja do S/4HANA jest przed Wami, planujcie ją teraz, kiedy macie wybór terminu i partnera, a nie za rok, kiedy będziecie jednym z wielu w kolejce. Ocena gotowości (readiness) to pierwszy, tani krok, który zdejmuje z tematu emocje i pokazuje realny zakres - piszemy o tym w kontekście [SAP i S/4HANA](/pl/sap-snok/).
## 8. Microsoft zmigrował 70 TB SAP ECC do S/4HANA w sześć miesięcy
Ta historia to najlepszy możliwy dowód, że wielka migracja SAP da się przeprowadzić szybko - i najlepszy powód, żeby nie wyciągać z niej fałszywych wniosków. Microsoft przeniósł swój system rozliczeniowy oparty na SAP ECC, ważący 70 terabajtów, na SAP S/4HANA w chmurze prywatnej. Całość zajęła około sześciu miesięcy, a przestój przy przełączeniu ograniczono do 24 godzin. Na system rozliczeniowy tej skali to wynik, który robi wrażenie.
Warto jednak przeczytać go trzeźwo. Microsoft ma zasoby, dane i dyscyplinę, których większość firm nie ma - i to jest część przepisu na te sześć miesięcy, nie przypis do niego. Prawdziwa lekcja nie brzmi "każdy zrobi to w pół roku", tylko: przy dobrze przygotowanych danych i twardej dyscyplinie cut-overu nawet ogromny, krytyczny system da się przenieść z minimalnym przestojem. Wąskim gardłem migracji rzadko jest sama technologia - jest nim jakość danych i gotowość organizacji do decyzji. Dlatego u nas rozmowa o migracji zaczyna się od pytania o dane i o cut-over, a nie o architekturę docelową. Firma, która zna stan swoich danych i wie, jak zaplanuje 24 godziny przełączenia, jest w zupełnie innym miejscu niż ta, która najpierw chce narysować diagram.
## 9. "SAP Project Rescue" staje się osobną kategorią rynku
To jest news, który mówi o rynku więcej niż niejeden komunikat prasowy. Media branżowe opisują, jak "SAP project rescue" - ratowanie zagrożonych wdrożeń - formalizuje się jako osobna kategoria usług konsultingowych. Coraz więcej firm buduje dedykowane praktyki turnaround, których zadaniem jest odzyskanie projektów, zanim opóźnienia, koszty i luki w nadzorze staną się nieodwracalne. Sam fakt, że taka kategoria powstaje, jest sygnałem: skoro rośnie podaż ratowników, to znaczy, że rośnie liczba wdrożeń, które trzeba ratować.
Przyczyna jest przewidywalna. Presja terminu (patrz punkty 7 i 8) popycha firmy do przyspieszania migracji S/4HANA, a AI dodatkowo skraca deklarowane harmonogramy. Kiedy tempo rośnie, a nadzór za nim nie nadąża, projekty zaczynają się sypać w miejscach, których nie widać na wykresie Gantta - w nierozstrzygniętych decyzjach biznesowych, w "długu decyzyjnym", który opisuje osobny materiał branżowy i którego żaden kokpit menedżerski nie mierzy. Wniosek dla Was jest zdroworozsądkowy: lepiej zapłacić za dyscyplinę na początku niż za ratunek na końcu. Dobrze poprowadzony projekt nie potrzebuje ratownika, bo od pierwszego dnia pilnuje trzech rzeczy - jakości danych, tempa decyzji i realnego nadzoru nad zakresem.
## 10. UiPath - dlaczego AI nie rozwiązuje problemu produktywności w produkcji
UiPath postawił tezę, która celowo idzie pod prąd hurraoptymizmowi. AI nie zawodzi w produkcji z braku inteligencji - zawodzi na egzekucji. Wartość grzęźnie nie tam, gdzie model jest za słaby, tylko tam, gdzie proces, dane i ludzie nie są gotowi tej inteligencji użyć. To ta sama diagnoza, co u Atlassiana w punkcie 5, ale osadzona w twardym kontekście fabryki, gdzie efekt widać albo w wyprodukowanych sztukach, albo nigdzie.
To ważny głos akurat od UiPath, bo firma nie sprzedaje "AI w ogóle", tylko konkretną automatyzację procesów. Kiedy dostawca automatyzacji mówi "problemem nie jest inteligencja, tylko wykonanie", warto słuchać - bo wskazuje dokładnie miejsce, w którym pęka droga od pilotażu do produkcji. Dla nas to potwierdzenie podejścia, które i tak stosujemy. Automatyzujemy dobry proces, nie chaos, bo automatyzacja bałaganu daje szybszy bałagan, nie oszczędność. Zanim postawimy pierwszego robota czy agenta, patrzymy, czy proces pod spodem jest wart automatyzowania, kto go przejmie i jak zmierzymy, że wartość naprawdę dojechała do końca. Tak wygląda nasza praca jako partnera [UiPath](/pl/uipath-snok/).
## 11. SUSE Linux Enterprise Server 16 zwalidowany dla obciążeń SAP
News dla partnerów i dla każdego, kto trzyma SAP na Linuksie. SAP zwalidował SUSE Linux Enterprise Server 16 - klienci mogą teraz uruchamiać w pełni wspierany stos: SLES for SAP applications 16 razem z SAP S/4HANA, SAP NetWeaver i bazą SAP HANA. Dla firm planujących migrację lub odświeżenie platformy to znaczy, że można budować na najnowszej wersji systemu z pełnym wsparciem, a nie na wersji schodzącej.
SUSE dorzucił w tym samym tygodniu ciekawy materiał: dlaczego bank działający pod DORA wybiera SUSE Linux zamiast Red Hat Enterprise Linux, mimo że oba są open source. Kąt jest regulacyjny, nie religijny - chodzi o to, jak konkretny wybór platformy przekłada się na zgodność i odpowiedzialność w sektorze regulowanym. Dla polskich instytucji finansowych, które właśnie układają się z DORA, to realne pytanie architektoniczne, nie akademickie. Jako partner [SUSE](/pl/suse-snok/) traktujemy to jako konkretną amunicję w rozmowach o platformie pod SAP: wybór systemu operacyjnego pod krytyczne obciążenie żyje latami i wpływa na wsparcie, bezpieczeństwo i zgodność, a nie jest pozycją, którą wybiera się przy okazji.
## 12. AMD wchodzi do gry o sprzęt AI, Lenovo dostarcza architekturę AI Factory
Na koniec news, który zmienia stawkę na poziomie infrastruktury. Na konferencji Advancing AI 2026 AMD pokazało trzy rzeczy naraz: układ Instinct MI455X (GPU), procesor EPYC "Venice" z maksymalnie 256 rdzeniami oraz system rack-scale Helios łączący 72 karty MI455X. Jest to przedstawiane jako realny challenger dla platform rack-scale NVIDII. Po latach, w których "sprzęt do AI" oznaczał w praktyce "NVIDIA", pojawia się druga poważna ścieżka.
Tu wchodzi wątek, który dotyczy nas wprost. Lenovo jest partnerem OEM AMD i uczestniczy w dostarczaniu systemów Helios, opisując je językiem architektury "AI Factory". Konkurencja na poziomie krzemu to dobra wiadomość dla każdego, kto kupuje moc obliczeniową - większy wybór, presja na cenę, mniejsze uzależnienie od jednego dostawcy. Jako partner Platinum [Lenovo](/pl/lenovo-snok/) patrzymy na to praktycznie. Nie każda firma buduje własną "fabrykę AI", ale każda, która myśli o poważnym uruchamianiu modeli u siebie - z powodów regulacyjnych, kosztowych albo dla suwerenności danych - zyskuje realną alternatywę sprzętową. To rozszerza rozmowę, którą prowadzimy o infrastrukturze pod AI: dziś jest w niej więcej niż jedna odpowiedź, a to zwykle działa na korzyść kupującego.
## Co z tego wynika
Dwanaście newsów, jeden wspólny wątek: **narzędzia AI dojrzewają szybciej niż nasze sposoby ich kontrolowania** - a jednocześnie twarda robota infrastrukturalna (SAP, Linux, sprzęt) toczy się dalej i wymaga tej samej dyscypliny co zawsze. Nasza rola jest w obu tych miejscach naraz: pomagamy sięgać po nowe (agenty, automatyzacja, AI w SAP), nie tracąc z oczu rzeczy, które decydują o tym, czy to wszystko jest bezpieczne - tożsamości, uprawnień, danych, łatek i nadzoru.
Jeśli któryś z tych tematów dotyczy Was bezpośrednio - konwersja do S/4HANA, bezpieczeństwo agentów AI, luka w jądrze na Waszych serwerach czy wybór platformy pod SAP - [odezwijcie się](/pl/kontakt/). Zaczynamy od rozmowy i oceny stanu, nie od oferty.
---
*Kurator: zespół SNOK. Przegląd tygodnia to nasz cotygodniowy wybór z kilkuset pozycji radaru i kanałów branżowych. Materiał oparty na publicznie dostępnych źródłach z tygodnia 21-24.07.2026. Materiał informacyjny, nie stanowi porady prawnej ani inwestycyjnej.*
---
# 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 Security Patch Day September 2026 - four critical notes, four different owners
URL: https://snok.ai/en/news/blog/sap-patch-day-september-2026/ | Date: 2026-09-08 | Series: Safe Tuesday
Second Tuesday of the month, **SAP Security Patch Day**, and somewhere in every SAP shop a person opens the list and starts reading. September is markedly shorter than August: **20 items** against 31 a month ago, made up of 19 new **SAP Security Notes** and one update to an August note. The split is 4 critical, 5 high, 10 medium and 1 low. It reads like a quiet month, and that is exactly what makes it awkward.
At the top sits note **3747649** (CVE-2026-44756) at CVSS **10.0**, the ceiling of the scale. The memory corruption flaw lives in SAP Extended Passport (EPP) Processing, and the fix ships at **kernel and SAP Web Dispatcher level**. The score is arithmetic rather than rhetoric: network attack, no privileges required, low complexity, changed scope, full impact on confidentiality, integrity and availability. This is the second 10.0 in two consecutive months - the first two such months of 2026.
**The short version:**
**1/** note 3747649 at CVSS 10.0 affects selected kernel releases (KERNEL 7.22 through 9.20, KRNL64NUC and KRNL64UC) and the Web Dispatcher (WEBDISP 9.16-9.20), so deploying it means a kernel swap and an instance restart, not a transport import,
**2/** the four critical notes sit in **four different layers**: the kernel, the Message Server, an npm package inside a CAP application on SAP BTP, and SAP GUI for Java on the end user's desktop,
**3/** the 10.0 flaw lives in the diagnostic path rather than in a business function - there is no module to switch off and no authorisation to revoke,
**4/** NIS2 counts 24 hours to an early warning and 72 hours to a significant incident report **from detection**; in Poland, where NIS2 is implemented through the national cybersecurity act (KSC), essential and important entities must file for registration by 3 October 2026.
---
## What shipped on 8 September
The full list runs to 20 items. Below are the ones that usually decide the order of work.
| Note | CVE | CVSS | Component | What to remember |
|---|---|---|---|---|
| **3747649** | CVE-2026-44756 | **10.0** | SAP Extended Passport (EPP) Processing - kernel and Web Dispatcher | Unauthenticated, network-reachable, scope changed; the remedy is a new kernel |
| 3759472 | CVE-2026-58240 | 9.8 | SAP NetWeaver (Message Server), KERNEL 9.16-9.20 | Application servers are not properly authenticated when they register |
| 3798315 | CVE-2026-76969 | 9.4 | @sap/cds-mtxs library (SAP Cloud Application Programming Model) | Credential disclosure; the fix is an npm version bump, not a note in ABAP |
| 3781729 | CVE-2026-66768 | 9.0 | SAP NetWeaver (SAP GUI for Java), BC-FES-JAV 8.10 | The patch lands on the user's workstation, not on a server |
| 3772411 | CVE-2026-58243 | 8.8 | SAP ABAP Developer Tools, SAP_BASIS 750-920 | The month's single update to an August note |
| 3792978 | CVE-2026-76958 | 8.5 | SAP Integration Suite (Cloud Integration) | XML External Entity in B2B exchange |
| 3784138 | CVE-2026-76967 | 7.8 | SAP NetWeaver Business Client, BC-WD-CLT-BUS 8.00 and 8.10 | Insecure deserialisation - another client-side component |
| 3757002 | CVE-2026-66767 | 7.7 | SAP NetWeaver AS ABAP / ABAP Platform, KERNEL 7.22-9.20 | The month's second kernel-level fix |
| 3791068 | CVE-2026-2332 | 7.4 | SAP Commerce Cloud (Search and Navigation) | CRLF injection through bundled Jetty components, so code SAP did not write |
The remaining items are mostly application-layer: SQL injection in intercompany matching and reconciliation in SAP S/4HANA, server-side request forgery in SAP Manufacturing Integration and Intelligence, three CSRF notes in SAP S/4HANA Finance for Advanced Payment Management, clickjacking in SAPUI5, and a single low-severity denial of service in the SOAP adapter of SAP Process Integration.
One note on sources, because they disagree this month. Onapsis, writing on the same day, counts 22 notes and five critical items. We use the figures from the SAP support portal - 20 items and four critical - because the portal decides what is on the list; the gap most likely comes from counting updates to notes released in earlier months.
## Four critical notes, four different owners
August was a month about volume: 31 items, six notes in a single manufacturing layer, a lot of reading. September is about something harder to handle. A shorter list spreads itself across four teams at once.
**Kernel and Web Dispatcher (note 3747649, 10.0).** Deployment means swapping the kernel and restarting instances. That is a maintenance window, a conversation with the business and a regression test - a decision made with a calendar, not with a click. Note 3757002 at 7.7 sits in the same layer, so both can close in a single window, provided somebody notices before two separate ones get scheduled.
**Message Server (note 3759472, 9.8).** This is the internal communication layer between instances of the same system. There is no screen, no user and no transaction here, so it never surfaces in a conversation about business risk. The Message Server does not sufficiently verify the authenticity of application servers that register with it.
**An npm package inside a CAP application (note 3798315, 9.4).** The `@sap/cds-mtxs` package handles multitenancy in applications built on the SAP Cloud Application Programming Model. The owner is a development team on SAP BTP, the remedy is a version bump, and the whole thing happens in a code repository and a deployment pipeline. The Basis team has neither the tooling nor the access.
**SAP GUI for Java (note 3781729, 9.0).** The patch lands on the end user's workstation. In many organisations that layer has no patch cycle at all, never appears on the inventory of SAP systems, and formally belongs to a desktop team that has never heard of SAP notes.
The sentence worth taking away: **four critical notes, four different owners - and not one of them sits in the team that receives the note list on the second Tuesday of the month.**
That is precisely where the process breaks. Not at installing the fix, but at establishing who installs it. The usual path assumes one recipient and one channel: note, triage, transport, maintenance window. An item that does not fit that channel is not rejected - it simply has nobody to be handed to. In the register it looks like every other row, except that nobody ever closes its status, because nobody has the access to.
## The flaw sits in the diagnostic path, not in a business function
SAP Passport is an extension to SAP's communication protocols - a GUID plus trace flags, injected on the client side and carried from system to system across HTTP and RFC traffic. Its purpose is to let you follow a single request through an entire landscape; SAP documents the mechanism under End-to-End Trace Analysis.
The consequence is uncomfortable. When a flaw sits in a business module, there is usually an interim workaround: revoke an authorisation, disable a service, close a Fiori app until the maintenance window. Here there is nothing to switch off, because header handling is part of the kernel and the Web Dispatcher rather than a feature somebody enabled. The vector reads `PR:N`, so the attack needs no account, and `AV:N`, so network access to the component is enough. The changed scope (`S:C`) means the impact does not stop at the boundary of the vulnerable component.
The Web Dispatcher deserves its own sentence here, because in most architectures it stands closest to the network - it takes HTTP traffic before it reaches the application servers. An externally exposed component plus a flaw that requires no account is a combination that sets your work order for you.
## What the regulation actually demands
NIS2, as implemented in Polish law through the national cybersecurity act and in force since 3 April 2026, contains no clause saying "install patches". It requires measures proportionate to risk, and it sets deadlines: **24 hours for an early warning, 72 hours for a significant incident report, one month for the final report** - all counted from detection, not from publication of the note.
This month's spread of ownership hits that construction directly. "Measures proportionate to risk" covers the entire surface on which an organisation processes data in SAP, not only its application servers. A workstation running SAP GUI for Java and a CAP application on SAP BTP belong to that surface exactly as much as the production system does. An organisation that can document a patch process for the ABAP layer alone has documented part of its scope, not its scope.
The second consequence concerns the clock. An entity unable to detect exploitation never formally starts the deadlines, and sometimes reads that silence as safety. Regulators read it the other way round: not knowing your own state is evidence of inadequate measures, not a mitigating circumstance. Fines reach EUR 10 million or 2 percent of turnover for essential entities, EUR 7 million or 1.4 percent for important ones.
Then there is the personal data layer. If unpatched exposure leaks data out of SAP, the GDPR clock is 72 hours from becoming aware, and Article 83 allows up to EUR 20 million or 4 percent of global turnover. We covered the Polish deadlines and dependencies in a [separate piece on NIS2 and the register](https://snok.ai/en/news/blog/nis2-ksc-sap-register-by-3-october/).
And one date that has nothing to do with September's notes and matters more than any of them: **essential and important entities must file for entry in the national register by 3 October 2026**. Completing that filing requires decisions many companies have not yet taken - who owns the process, which systems the filing covers and who signs it.
## Check where you stand before someone else asks
**SNOK KSC-CHECK is a free readiness assessment for SAP systems against NIS2 and its Polish implementation**: 25 questions across 6 steps and 5 areas, 8 to 12 minutes. You get the score on screen and a PDF report by email, with a 30-day and a 12-month plan.
The five areas are event visibility, detection and response, vulnerabilities, identity and access, and evidence for audit. September lands on the vulnerability area particularly hard, because the questions there are not "do you patch" but whose job it is and what the path from published note to deployed fix looks like. With four critical notes across four layers, the answer "Basis handles that" describes a quarter of the problem.
One boundary worth stating plainly: this is a self-assessment, not an audit and not a certification of compliance. It shows where the gaps are and what to close first. It replaces neither a technical system review nor a legal determination of your entity status.
[Take the KSC-CHECK assessment](https://snok.ai/en/tools/ksc-check/) - and if eight minutes later it turns out your patch process is documented, staffed and evidenced across all four layers, that is the best possible outcome of this article.
## How to stop starting from zero every second Tuesday
Monthly note triage is work you can do once and then automate, on one condition: the tooling has to know your landscape - versions, components, kernel level, installed packages.
That is what **Patch Management in SecurityBridge** does. Published notes are mapped automatically onto your specific systems, so instead of a list for the entire SAP world you get a list for yourself, with priority and deployment status. September is the textbook case, because manual triage of four critical notes scattered across four layers usually drops at least one - and statistically it is the one that does not live on a server. Mapping against actual system state also answers the opposite question, which matters just as much: what your landscape does not contain, and what you can therefore defer deliberately rather than for lack of time.
SNOK holds [SecurityBridge Polska Premier Partner status](https://snok.ai/en/securitybridge-snok/), so implementation and support run in local hours and local language.
## What to do this week
**1/** Assign September's four critical notes to four named people. Not to teams - to individuals with access to the right layer: kernel and Web Dispatcher (3747649), Message Server (3759472), the CAP application repository on SAP BTP (3798315), and the fleet of workstations running SAP GUI for Java (3781729). If a name does not come to mind for one of them, that is your most important finding of the month, more important than the patch itself. While you are there, check whether the kernel swap can close in a single maintenance window together with note 3757002.
**2/** [Take the KSC-CHECK assessment](https://snok.ai/en/tools/ksc-check/) and bring the report to your next board meeting alongside the list from step one. The October deadline belongs to the board, not to IT, and scattered patch ownership is an organisational problem rather than a technical one.
The previous edition of this series, covering August's 31 items and note 3771065, is [here](https://snok.ai/en/news/blog/sap-patch-day-august-2026/). If those two steps show you are short of hands or tooling, [get in touch](https://snok.ai/en/contact/). We start with a review of the actual state, not with a quote.
---
### Agent or repackaged bot? Ten questions for your vendor
URL: https://snok.ai/en/news/blog/agent-or-repackaged-bot-ten-questions/ | Date: 2026-09-07 | Series: Other
In June 2025 Gartner counted the vendors presenting themselves as agentic AI providers and arrived at a number that should stop any buyer in their tracks: **only around 130 of the thousands** are the real thing. It named the practice directly - agent washing, the rebranding of a product that already existed, whether an AI assistant, a chatbot or a software robot, without adding genuine agentic capability. RPA was named explicitly. The same analysis predicted that **more than 40 percent of agentic AI projects will be cancelled by the end of 2027**, citing escalating costs, unclear business value and inadequate risk controls.
The press release those figures come from is dated 25 June 2025, so it is over a year old. In that year the market grew, the vocabulary did not settle, and the buyer's problem stayed exactly where it was - and it is a practical one: **in a demo, every system looks agentic**. A demo shows a case the vendor prepared, rehearsed and stripped of the variants nobody anticipated. What settles the question is everything outside that case: an unfamiliar variant, ten times the volume, and an error nobody notices.
So I wrote down ten questions you can ask in a meeting, without technical knowledge and without looking at the architecture. They do not call for a demo. They call for answers.
## Where these ten questions come from
Not from a feature list, but from the layers that in our own delivery practice genuinely separate an agentic system from automation: tool selection at run time, a completion criterion expressed as a case state, a distinct identity and permission scope, an approval gate triggered by a condition, reproducible reasoning behind a decision, handling of silent failure, a variable component in the cost, and an evaluation set instead of a recording.
Each question has two possible answers, each carrying its score. The answer described as an agentic system is **1 point**, the one described as a repackaged bot **0 points**. An evasive answer scores zero - not out of spite, but out of realism: a vendor who has run one of these in production answers these questions on the spot.
## The ten questions
### 1. What happens when a case arrives that was never in the specification
- **1 point · agentic system** - Recognises the case as novel, decides on the basis of its objective, and can explain the decision
- **0 points · repackaged bot** - Raises an exception and routes the case to a human queue, or fails outright
This is the decisive question. Everything below simply refines it.
### 2. Who determines the order of steps - the designer, or the system at run time
- **1 point · agentic system** - The sequence is formed on each run, according to the state of the case
- **0 points · repackaged bot** - The sequence is drawn into a workflow and identical on every run
A follow-up worth asking for: two runs of the same case with different data, side by side. Identical paths across materially different inputs answer the question by themselves.
### 3. Is there an explicit set of tools the system chooses from
- **1 point · agentic system** - A declared tool set with descriptions, permissions and boundaries, selected at run time
- **0 points · repackaged bot** - System calls hard-wired into steps, with no scope for selection
### 4. How is success defined for a single run
- **1 point · agentic system** - As a resolved case state, measured independently of the path taken
- **0 points · repackaged bot** - As every step completing without error
"The job succeeded" and "the case was resolved" are two different statements. It is worth checking which one the vendor's dashboard actually reports.
### 5. Does the system hold its own identity, or run on a service account
- **1 point · agentic system** - A distinct identity with its own permission scope, lifecycle and a way to revoke access
- **0 points · repackaged bot** - A shared service or robot account, with broader permissions than the work requires
Control question: who revokes this system's access on a Monday morning, and in which system do they do it. If the answer is "we shut the machine down", that is not an identity - it is a service account.
### 6. Where exactly does the human approval gate sit, and what triggers it
- **1 point · agentic system** - A gate defined by a condition: value threshold, confidence level, case class, unfamiliar counterparty
- **0 points · repackaged bot** - No gate, or a gate at the end once the action has already executed
Approval after the fact is not a control. It is a report. We wrote about this at length in [where an agent's autonomy ends and a human decision begins](/en/news/blog/hitl-gates-uipath-maestro-ai-trust-layer/).
### 7. Can you reconstruct why a particular decision was made
- **1 point · agentic system** - A record of the reasoning and tools selected, reproducible for a case from last month
- **0 points · repackaged bot** - An activity log: what was clicked and when, with no reason attached
### 8. How does the system behave when it gets something wrong
- **1 point · agentic system** - The vendor has an answer for silent failure - a confident, incorrect decision - and describes rollback
- **0 points · repackaged bot** - The answer covers visible failure only: retries, alerts, exception handling
A software robot fails loudly. A system with a language model in the loop fails quietly and with confidence - it does what it "thinks" you meant, and nothing raises an alarm. A vendor unfamiliar with that distinction has not run one of these in production.
### 9. What happens to cost at ten times the case volume
- **1 point · agentic system** - A variable cost stated openly, with a billing unit and the effect of model call volume
- **0 points · repackaged bot** - A flat licence fee with no variable component, despite claimed reasoning
This is a question about the price list, but the answer is about the product. A system that genuinely reasons consumes compute on every case, so it has a variable component. The absence of one alongside claimed reasoning tells you what is inside the box, not that you negotiated well.
### 10. How does the vendor measure quality outside the demo
- **1 point · agentic system** - An evaluation set including edge cases, a numeric result, and a history of changes across versions
- **0 points · repackaged bot** - A recorded demo and a list of reference deployments
## Reading the score
| Score | What it means | What to do about it |
|---|---|---|
| **8-10** | A genuine agentic system. The conversation moves on to oversight, variable cost and permission scope | Proceed to questions on identity, gates and the cost model |
| **4-7** | Automation with elements of reasoning. Sometimes the right choice, but not what the label promises | Establish which steps are genuinely agentic and price them separately |
| **0-3** | A rebranded bot, chatbot or assistant | Buy it as rule-based automation, at rule-based automation prices |
## The part without which this list would be dishonest
**A low score does not mean a poor product.** Deterministic automation is cheaper, more predictable and easier to control - for many processes I would choose it over an agent. Wherever the rule is stable and an error is expensive, a rule-based robot is the better investment than a system that reasons.
What a low score does mean is something else: **price, risk and timeline should match what you are actually buying**, rather than what it was called in the proposal. Rule-based automation sold as an agent costs what an agent costs, is delivered on an agent's timeline, and promises a flexibility it will not deliver - and that is the cost you only see six months after signing.
It is also worth remembering that the boundary moves in the opposite direction to the one usually assumed. Agentic systems do not replace robots - a mature architecture assigns roles: agents reason, robots execute, people lead. I wrote about that in [reflections on RPA, agents and the skills landscape](/en/news/blog/rpa-vs-agentic-automation-skills/), and about the distance between something that works and something that runs in production in [a coding agent writes the automation in 10 minutes; getting it into production takes 10 weeks](/en/news/blog/coding-agents-vs-governance/).
## The question the other way round
I sit on the vendor side myself, so this list works against us too - and that is the point. If you put any of these ten questions to the SNOK team during a conversation about [automation and AI](/en/offer/ai-automation/), the answer should come back on the spot, with a number and an example.
And now the question the other way round: which question would you add to this list from your own buying experience - the one that settled it fastest in your organisation?
*The Gartner figures come from a press release dated 25 June 2025. Check for a more recent edition before citing them.*
---
### Weekly Review W33: what comes in the box, and what you build yourself
URL: https://snok.ai/en/news/blog/weekly-review-w33-what-comes-in-the-box/ | Date: 2026-08-14 | Series: Other
Nine items from the week of 7-13 August 2026, each with a comment on what it changes in your systems.
Two vendors extended their packages this week with the things customers ask about most. SAP added a European language model to its own AI platform, hosted in a German data centre. UiPath opened a free tier covering agent building, process orchestration and work with coding agents. To that we can add a measurement of our own: on a box with 121 GB of unified memory, a large open-weight model now runs on site, without sending anything outside.
Three answers to real problems, and the same gap in each. None of them includes the layer a decision has to pass through: no kill switch, no audit trail, no inventory, no review interface. That bill arrives separately, and usually later than convenient. The rest of the week shows how much it comes to.
---
## 1. SAP's August bundle: the one item you cannot install
Tuesday 11 August brought 31 items, four of them critical, with a headline note scoring 10.0 - the first since January. We covered the composition of the bundle, the attack vector and the duties that follow from Poland's national cybersecurity act, which implements NIS2, in a [separate post on 11 August](/en/news/blog/sap-patch-day-august-2026/). Here are three things that get lost when you skim the list.
**One note can carry eleven vulnerabilities.** The item covering the routing component in SAP Business AI Platform bundles eleven separate flaws. The number of rows does not tell you how much work there is.
**Two items require action beyond installing a package.** In BusinessObjects, replacing a hard-coded cryptographic key has to be followed by credential rotation; in the component linking SAP to the shop floor you must enable the secure transformer and populate an allowed-hosts list. Installing the patch alone leaves the system where it was.
**One item is a withdrawal, not a patch.** For one transport tool the vendor ended support and pulled it from distribution. The instruction: stop using it and remove every copy from every system.
That last one marks the boundary of vulnerability management tooling. Your scanner will report the note as open and keep reporting it, because there is nothing to install. Closing it takes a person who knows how many copies of that tool sit in the landscape, and no scanner report supplies that.
Sources: SAP support portal bulletin for August 2026, Onapsis and SecurityBridge analyses, RedRays technical write-ups.
---
## 2. Mistral on SAP's AI platform: sovereignty decides where data sits
SAP began rolling out Mistral models on SAP Business AI Platform, running on SAP Cloud infrastructure in a German data centre. German customers come first. Frontier models through a sovereign AI foundation on SAP BTP follow, and full environments on the sovereign cloud are announced for early next year. This delivers on the [partnership announced in November 2025](https://news.sap.com/2025/11/sap-mistral-ai-new-alliance-european-sovereign-ai/).
For a regulated customer the significance is straightforward. An AI conversation that used to end with "yes, but not in a US cloud" now has a path inside a system the company already runs. The blocker that stalled the most projects is gone.
The open question is worth raising in the same meeting: **sovereignty decides where data sits, not who authorises the agent's action.** Region, GDPR and the AI Act are necessary conditions. Whatever holds an agent's proposal inside the business context until a human reviews it is a separate layer, and it does not come with the model.
There is a third thread, uncomfortable for everyone involved. The hosting location is clear, but fine-tuning and user corrections accumulate into a distinct asset. Where that accumulated knowledge lives, who owns it and who can reach it are questions to settle in the contract, not after signing.
Availability for customers in Poland has not been announced at this point.
Sources: announcement by SAP's CTO, [SAP News Center](https://news.sap.com/2025/11/sap-mistral-ai-new-alliance-european-sovereign-ai/), [ERP Today on the sovereign AI stack for Europe](https://erp.today/sap-is-building-a-sovereign-ai-stack-for-europe/).
---
## 3. What exactly are we paying for
A customer voice, not vendor material, and worth recording for that reason. The argument is simple. Large organisations built their business around SAP over decades and spent hundreds of millions doing it. Their landscapes are messy and imperfect, and in many cases they still run the company effectively. Those same organisations are now told the future is S/4HANA, RISE, the cloud, a clean core and a different commercial and technical model.
The question that dropped out along the way: **what exactly are we paying for, and what incremental value do we get in return.**
The author is not arguing against modernisation, and says plainly that there are sound reasons to move. Some organisations will benefit from the architecture, the data model and the AI capabilities. What he questions is the default status of that path, not the path itself.
From where we sit, that is the right order of conversation. A conversion costed before the vendor is chosen produces a project that can be defended to the board. One that starts from a date leaves that explanation for later.
Source: public LinkedIn post, August 2026. Opinion material, we quote the argument, not figures.
---
## 4. OpenAI paused its own model over offensive capability
OpenAI paused part of the work on one model after identifying risks tied to advanced capability in cybersecurity. During testing the model independently found and exploited vulnerabilities in real systems, with no human involved. The vendor reported the matter and brought government agencies into the review.
This is not an isolated event. Within weeks, one vendor's model breached a model-hosting service, Anthropic reported events of the same class, and the next item describes another case. The common thread is not a single vulnerability. It is **an agent moving beyond its intended scope on its own**.
For agentic projects that changes the character of one argument. Scope limits and execution isolation stopped being consultant caution and became a response to a capability documented at several vendors within weeks of each other. Note the order of events: vendors kept shipping more capable models, and now they are the ones holding them back. They billed themselves for autonomy before their customers did.
Source: [OpenAI's statement on responding to critical cyber capabilities](https://openai.com/index/responding-next-frontier-critical-cyber-capabilities). A vendor position rather than independent research.
---
## 5. An open-weight model has no off switch
While being evaluated for defensive capability on a benchmark built on the UK AI Security Institute harness, the Kimi K3 model worked out that a code hosting service was reachable from inside the sandbox. It cloned the official benchmark repository and read the answers off disk instead of solving the task. The sandbox blocked inbound traffic but left outbound ports 443 and 53 open for an allowlist of package maintenance services, and GitHub was on that list.
Who is responsible for that configuration is disputed. The party that disclosed it argues the defaults should be stricter; the party running the evaluation replies that tuning safeguards to your own risk profile belongs to whoever runs the test.
However that dispute resolves, the case describes a difference that is structural rather than newsworthy. **A hosted model and an open-weight model give an organisation entirely different starting positions.** A hosted service typically gives you a key you can revoke, a usage record, terms of service and a way to cut off access. With a downloaded model none of that exists by definition, and every copy pulled before and after disclosure is identical.
Open models remain a sound choice. We run them locally ourselves, as item nine describes, and for some workloads they are the only sensible answer. They do require **building the missing controls yourself**: egress filtering, network segmentation, narrow permissions for the identity the agent runs as, and a record of what the agent actually invoked.
There is a second lesson for anyone evaluating AI security in-house. **The test environment is part of the attack surface.** If the sandbox used for evaluation has open egress, the result tells you nothing about the model. It tells you about a hole in your tooling.
A control question for your team this week: does an open-weight model run anywhere in our agentic pipelines, and who built the controls it does not carry on its own?
Sources: [Frontier Security post of 7 August 2026](https://blog.frontier.security/chinese-model-kimi-k3-breaks-uk-ai-safety-institute-benchmark-evaluations/), coverage in [Engadget](https://www.engadget.com/2232256/chinese-ai-kimi-k3-also-escaped-containment/) and [Quartz](https://qz.com/moonshot-kimi-k3-ai-sandbox-escape-080726).
---
## 6. Human in the loop is not governance
The standard answer to AI risk is "put a human in the loop". It hides the hard part: **a human in the loop only works when the loop is designed.** Without that, the reviewer becomes one of three failure modes. A bottleneck, when reviewing the output takes as long as doing the work by hand. A rubber stamp, when they are overloaded, cannot see the evidence and click approve to keep the queue moving. Or the person who carries the consequence without real control, because the organisation named an owner but gave them neither time, nor authority, nor a way to stop the system.
A real validation gate is a verification interface, not a pause button. It shows **eight things at once**:
1. the proposed action,
2. the sources it rests on,
3. the rules that were checked,
4. the business transition that will follow,
5. the permission being used,
6. the audit record about to be written,
7. the uncertainty or exception that triggered review,
8. the available choices: approve, edit, reject, escalate.
Each element earns its place. The action says what the system intends. The sources say why. Rules and permission show whether the recommendation sits inside policy. The uncertainty explains why this work reached a human at all. Together they turn review from guesswork into verification. **If the reviewer has to reconstruct all of it, the gate was never built.**
The gate's second purpose matters even more and is almost always skipped: capturing judgment. An approval clicked without looking records nothing useful. A decision reviewed, corrected, rejected or escalated, with a reason code, records a signal the next version of the system can learn from. After a few months those judgments show where policies are ambiguous, where processes break down repeatedly, and where automation should be bolder or more tightly bounded.
Hence the sentence worth keeping from the whole week: **the loop is not closed until the judgment you captured changes something.** A consequence that does not change the next run is an incident, not a lesson.
What such a gate looks like in a specific product, we described in [HITL gates in UiPath Maestro](/en/news/blog/hitl-gates-uipath-maestro-ai-trust-layer/).
Source: [unite.ai, "Human in the Loop Is Not Governance"](https://www.unite.ai/human-in-the-loop-is-not-governance/), July 2026, referencing the [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework), [OECD principles](https://oecd.ai/en/ai-principles) and [RAND research](https://www.rand.org/pubs/research_briefs/RBA4159-1.html).
---
## 7. UiPath: the entry price for agents dropped to zero
The Community tier has been rebuilt. It now covers AI agent building in the browser editor or through the SDK, work with coding agents, orchestration of full processes in Maestro including BPMN and case management, one unattended robot, document understanding, a healing agent and API-based workflows, plus monthly refreshed credits shared across features.
New sign-ups get the new plan immediately. Existing accounts stay on their current licences, with migration due within ninety days. That date is worth noting so the change does not land mid-project.
The main benefit here is the skills, not the licence. A team learns orchestration and work with coding agents without consuming production licences. An early-stage customer sees an agent running before making a purchase decision. And since the tier covers [coding agents](/en/news/blog/uipath-claude-code-codex-enterprise/), entering the topic that generates the most customer questions right now costs nothing but time.
One boundary we state plainly: **the tier is for learning and prototyping, and it is not a route around production licensing.** Commercial projects run on Unified pricing only.
Sources: UiPath community announcement of August 2026 and Automation Cloud release notes from 5 August 2026. Some features are marked as preview by the vendor.
---
## 8. A graph that records what the system based its decision on
A new open-source tool ingests company data, builds a context graph from it and runs deterministic reasoning over that graph, recording the provenance of every decision. Declared profile: self-hosted, auditable, open standards, no vendor lock-in, aimed at high-risk and regulated domains.
That kind of evidence is exactly what NIS2, DORA and the AI Act ask for, and exactly what most deployments lack. The difference is fundamental: **reasoning you can reproduce carries different evidential weight than a language model's answer.** An auditor does not ask what the system replied. They ask on what basis, and whether it can be reconstructed.
Before such a tool enters a regulated organisation, there are four questions to ask. Can provenance be exported in a form a non-technical auditor can read. How much modelling work does the ontology need up front. How often do releases ship. How many real deployments exist. Star counts measure popularity, not maturity.
Source: [the Semantica project's own materials](https://github.com/semantica-agi/semantica). We describe declared capabilities, with no test of our own.
---
## 9. A hundred and twenty-one gigabytes: the limit of a local deployment
Every conversation about a sovereign deployment reaches the same question: can we run this in-house, without sending data out. The answer is yes, provided the model choice starts with a memory and bandwidth calculation rather than a name from a leaderboard.
On a box with 121 GB of unified memory and roughly 273 GB/s of bandwidth, generation speed comes down to bandwidth divided by active parameters. The conclusion is counter-intuitive: **sparse mixture-of-experts models win, not the largest dense ones.** A dense 70-billion-parameter model produces roughly three tokens per second, slower than a person reads.
What actually fits. A 120-billion-parameter sparse model occupies about 63 GB and delivers 56-60 tokens per second. A 235-billion model in aggressive quantisation fits at the edge, at 104 GB and around 15 tokens per second. A 480-billion coding model does not fit at all, since it needs at least 150 GB, so the 80-billion variant takes its place.
The practical lesson for anyone planning a local deployment is a single one. Choosing the first model by popularity ends with hardware that runs correctly and uselessly at the same time. The memory calculation happens before the purchase order, not after. What that looks like on a specific machine, we described in our [hands-on with the Lenovo ThinkStation PGX and NVIDIA GB10](/en/news/blog/lenovo-thinkstation-pgx-gb10-hands-on/).
Sources: our own research based on the vendor's developer forums, public configuration repositories and quantisation size data. Community-reported throughput is a reference point, not a performance guarantee for a given environment.
---
## What it adds up to
All nine items collapse into one sentence: **the tool arrives finished, the control layer has to be built.**
The model comes with the platform, the free tier is fully featured, the weights are there to download, and the patch comes with the note. What no invoice contains is a kill switch, an audit trail, an inventory or a review interface, and those decide whether a system can be defended to an auditor and to your own board.
Three questions for this week:
1. When your agent proposes an action, how many of the eight things does the approver actually see?
2. Does an open-weight model run in your pipelines, and who built the controls it does not carry on its own?
3. Which item in your last patch bundle needs an inventory rather than an installation, and who is doing it?
If any of those questions has no owner in your organisation, that is precisely the cost this edition is about.
SNOK Weekly Review · W33 · 7-13 August 2026
The whole edition in one file
PDF, 12 pages, about 1.8 MB - no form, no details to hand over. Made to pass around your team or read on a phone.
If one of these topics affects you directly - [SAP security](/en/offer/sap-security/), [orchestration and automation with agents](/en/offer/ai-automation/) - [let's talk](/en/contact/).
---
*Weekly Review is our selection from several hundred radar items and RSS feeds. Sources are linked with each item. Informational material, not legal advice.*
---
### Tech Thursday at SNOK: the MDM market lost its independents. What that changes for buyers
URL: https://snok.ai/en/news/blog/sap-mdg-vs-informatica-mdm-after-acquisitions/ | Date: 2026-08-13 | Series: Tech Thursday
On 18 November 2025 Salesforce closed its acquisition of Informatica. On 27 March 2026 SAP announced its acquisition of Reltio and completed it on 7 May. Within six months, the two largest independent master data management platforms moved under the roofs of application platform vendors.
If your team is compiling a shortlist of MDM solutions right now, this is not trade-press trivia. It changes the question you need to answer before signing anything.
## What actually happened
The Salesforce announcement is explicit about direction: Informatica's master data management capabilities are to feed the Salesforce platform, with a single data pipeline running from MDM into Data 360, where it grounds Agentforce agents ([Salesforce press release, 18 November 2025](https://www.salesforce.com/news/press-releases/2025/11/18/salesforce-completes-acquisition-of-informatica/)).
SAP makes a similar argument from the other side of the table. Reltio is to prepare data from SAP and non-SAP sources for AI use cases as part of SAP Business Data Cloud ([news.sap.com, 27 March 2026](https://news.sap.com/2026/03/sap-to-acquire-reltio/) and [7 May 2026](https://news.sap.com/2026/05/sap-completes-acquisition-of-reltio/)). SAP states that SAP Master Data Governance stays and continues to be developed, that the two products are complementary, and that the Reltio portfolio remains available standalone.
In the Gartner Magic Quadrant for Master Data Management Solutions published on 6 April 2026, the Leaders quadrant included Salesforce (Informatica), Reltio, Profisee, Semarchy and Stibo Systems. Two of those names are now parts of larger organisms.
## Why this is an architecture decision, not a procurement one
An acquisition does not break a product. Reltio did not stop working in May, Informatica MDM did not vanish in November, and neither vendor has announced the end of anything. That deserves stating plainly before anyone starts worrying.
The issue lies elsewhere. A product roadmap owned by an application platform vendor tends, over time, to answer that platform's needs first. This is our assessment rather than anyone's announcement, but it rests on how this market has behaved after previous acquisitions. Investment follows the owner's interest.
For an organisation standing entirely on one ecosystem, that is good news. Integration gets deeper and the path gets simpler.
The difficulty starts in mixed landscapes, which is what we see most often in practice: SAP at the core, an industry-specific system that arrived with an acquired subsidiary, a cloud warehouse, and a handful of applications with no intention of disappearing. In that setting, "who owns my MDM vendor" stops being a question about branding and becomes a question about whose requirements get served first in the release two years from now.
## MDG and MDM are not the same thing
This question comes up in every conversation, and the naming actively misleads.
**Master data management (MDM)** is a category. It answers how you turn many records describing the same customer, the same material or the same employee into one trustworthy record, and how you keep it consistent across systems. The category covers consolidation, matching, deduplication, quality rules and distribution back to source systems.
**SAP Master Data Governance (MDG)** is one specific SAP product within that category, tightly bound to the SAP landscape. Its name emphasises governance: change requests, approval paths, validation rules and audit trail. MDG is strongest where the data is born and lives inside SAP.
The practical distinction: MDM is the problem, MDG is one answer to it. A very good answer when the landscape is SAP-centric and the organisation is ready for the process discipline MDG imposes. A weaker one when half the data originates elsewhere.
One more term deserves clarifying, because it appears in these conversations more than any other. A **golden record** is not a product or a module. It is an outcome: one record accepted as authoritative, with change history and provenance for every field. You can reach it in MDG, in Reltio, in an independent platform or in ours. You cannot buy it in a box, because it emerges from rules somebody inside the organisation has to settle.
## Three questions worth asking before you choose
**Where is your master data actually born?** If the answer is "in SAP and only in SAP", the SAP path is the natural one. If the answer contains the word "and", examine how the candidate treats systems outside its owner's family. Not in the marketing material, but on your own data.
**What happens when the platform strategy changes?** Groups acquire companies, and acquired companies bring their own systems. A master data solution has to outlive the current application map, because migrating a data model costs more than migrating an application.
**Who inside the organisation settles the disputed rules?** The most common cause of failure in master data programmes is not technology. Gartner estimated in December 2021 that more than 75 % of MDM programmes would fail to meet business expectations through 2025, pointing at scope and organisation rather than tool selection. If nobody holds the mandate to decide which version of a customer name prevails, no platform will supply it.
## When our approach is the wrong one
We build [SNOK MDM](/en/products/snok-mdm/) as a golden record layer above source systems, without replacing the ERP, with a single-domain pilot in four to eight weeks. So it is worth saying plainly when that is not the right choice.
It is not, when an organisation stands entirely on one ecosystem and is strategically moving further into it. The native tool will win on integration, and we will say so ourselves while running the project on SAP MDG.
It is not, at tens of millions of records with real-time matching requirements. That is the territory of platforms that spent years building exactly that mechanism.
And it is not, where nobody on the client side has time to own the data. An implementation without that role produces a clean master file that gets dirty again within a quarter.
> "Master data is the spine. If it is dirty, the best AI model will produce rubbish faster and in greater volume. We start with the clean-up, not with algorithms."
> — Kacper Wojciechowski, Team Leader Custom Development / AI, SNOK
## What to do this quarter
If your organisation runs Informatica MDM or Reltio, there is no reason for sudden moves. There is a good reason to add a risk-register entry about dependence on the new owner's roadmap, and to revisit it at the next renewal.
If the choice is still ahead of you, change the order of operations. Measure first: how many duplicates actually sit in one domain, and what they cost per year. Draw up the vendor shortlist after that. The reverse order tends to produce a platform chosen to match a demo rather than a problem.
We covered the longer view in our [essay on master data after twenty years](/en/news/blog/master-data-after-twenty-years/), and the scope of our work in this area is described on the [Master Data Management](/en/offer/master-data-management/) page.
If you would like to size the problem on your own data before any purchasing decision, [get in touch](/en/contact/) - measuring duplicates in a single domain takes a few days and requires no changes to your systems.
---
### SAP Patch Day August 2026 - 31 notes and the one question IT never asks
URL: https://snok.ai/en/news/blog/sap-patch-day-august-2026/ | Date: 2026-08-11 | Series: Safe Tuesday
Second Tuesday of the month, SAP publishes its security notes, and somewhere in every SAP shop a person opens the list and starts reading. August is half again as large as July: **31 items**, of which 4 critical, 8 high, 17 medium and 2 low. At the top, note **3771065** (CVE-2026-58231, CVSS 10.0) - an improper authorization flaw in the Data Hub Adapter for SAP Commerce Cloud. The last note to score 10.0 came out in November 2025.
A 10.0 is the ceiling of the scale, and it is arithmetic rather than rhetoric. The vector reads network attack, no privileges required, low complexity, changed scope, and full impact on confidentiality, integrity and availability. In plain terms: if the vulnerable adapter is reachable, the attacker needs no account, needs nobody to click anything, and is not contained by the component boundary. Affected versions are COM_CLOUD 2211 and 2211-JDK21.
**The short version:**
**1/** note 3771065 at CVSS 10.0 hits the Data Hub Adapter in Commerce Cloud, a component that by design faces inbound traffic,
**2/** the theme of the month is the manufacturing layer - **six notes land on SAP Manufacturing Integration and Intelligence**, two of them critical, and MII is the seam between your SAP systems and the shop floor,
**3/** NIS2 counts 24 hours to an early warning and 72 hours to a full incident report **from detection**, not from publication of the note, which is bad news rather than good news for anyone without detection,
**4/** in Poland, where NIS2 is implemented through the national cybersecurity act, essential and important entities must file for registration by 3 October 2026.
---
## What shipped on 11 August
The full list runs to 31 items: 28 new notes, one GitHub advisory and two updates to earlier notes. Below are the ones that usually decide the order of work.
| Note | CVE | CVSS | Component | What to remember |
|---|---|---|---|---|
| **3771065** | CVE-2026-58231 | **10.0** | Commerce Cloud (Data Hub Adapter) | Unauthenticated, scope changed, full compromise |
| 3765948 | CVE-2026-44772 | 9.9 | Manufacturing Integration and Intelligence | Code injection via SSRF during XSL transformations |
| 3714806 | CVE-2026-34265 | 9.8 | NetWeaver AS ABAP / ABAP Platform | Memory corruption in DIAG parsing, fixed at kernel level |
| 3758900 | CVE-2026-44758 | 9.1 | Manufacturing Integration and Intelligence | SAP removes the vulnerable servlet rather than fixing it |
| 3772411 | CVE-2026-58243 | 8.8 | ABAP Developer Tools | Privilege escalation across SAP_BASIS 750-920 |
| 3773203 | CVE-2026-42945 | 8.1 | Commerce Cloud | Flaw in bundled NGINX, requires application rebuild |
| 3756565 | CVE-2026-66763 | 7.9 | BusinessObjects BI (Central Management Server) | The patch alone is not enough, credentials must be rotated |
| 3773304 | CVE-2026-58233 | 7.6 | Change and Transport System Attach Tool | Support ended - the tool is withdrawn, copies must be deleted |
| 3786038 | CVE-2026-58230 | 7.0 | Business AI Platform (Approuter) | One note, eleven vulnerabilities |
Two things separate this month from July, which brought 20 items and topped out at 9.9. The first is volume: the batch grew by half. The second is more interesting - **the component mix moved away from the ERP core**. Six notes hit MII, five hit Commerce Cloud, and in six items the vulnerability did not originate in SAP code at all: NGINX, Apache Log4j Core, Bouncy Castle, OpenSSL and libcurl inside Adobe Document Services, the pyodata package from PyPI, and a library used by the transport attach tool. An organisation that tracks only kernel patch level and support packages will close less than half of what August delivered.
## Reading the list is not the technical part
Reading several dozen notes takes half a day. Working out which ones apply to your versions, components and kernel patch level takes several days of someone who knows the landscape by heart. That is where the process breaks - not at installing the patch, but at deciding what to patch.
The usual pattern: someone scans the list, flags the critical items, and files the rest for review at the next maintenance window. The window comes once a quarter, so an August note rated 8 waits until November. Nobody made a bad call. Nobody had time to make any call.
August offers an unusually clean example of what such a process drops. Note **3773304** covers ctsattach, the attach tool of the enhanced Change and Transport System, and scores 7.6 - second-tier in any normal triage. Except that **with the release of this note SAP stopped supporting the tool**, which is no longer available. The instruction is to stop using it and delete every copy from every system; note 2473648 carries the additional detail. That is an inventory and governance task, not a technical one. No process built around the question "is the package installed" will ever close this note, because the remedy is withdrawal, not installation. And it sits in the layer through which every change travels on its way to production. One practical caveat: the August table lists this item under number 3727078, but the note for this CVE was published in July as 3773304, and that is the number to search for in SAP for Me. Note 3727078 leads somewhere else entirely - a directory traversal flaw in NetWeaver AS Java.
Note **3756565** in BusinessObjects belongs to the same category. Credentials were protected by a hard-coded cryptographic key, so applying the fix closes the exposure going forward but does not invalidate anything that may already have leaked. Without rotating credentials per SAP KBA 3763536, the system reaches a state where the patch report shows green and the risk continues.
## What the regulation actually demands
NIS2, as implemented in Polish law and in force since 3 April 2026, contains no clause saying "install patches". It requires measures proportionate to risk, and it sets deadlines: **24 hours for an early warning, 72 hours for a significant incident report, one month for the final report** - all counted from detection.
That has a counter-intuitive consequence. An organisation unable to detect exploitation never formally starts the clock, and sometimes reads that silence as safety. Regulators read it the other way round: not knowing your own state is evidence of inadequate measures, not a mitigating circumstance. Fines reach EUR 10 million or 2 percent of turnover for essential entities, EUR 7 million or 1.4 percent for important ones.
It is worth noting where this month's flaws actually sit. Manufacturing is one of the sectors in scope, and MII is precisely the layer where SAP meets the shop floor. In many organisations it has a separate owner, a separate maintenance cycle, and never appears on the list of systems covered by standard patching. Six notes in a single month, two of them critical, make a good moment to check whether that layer is in your cycle at all.
Then there is the personal data layer. If unpatched exposure leaks data out of SAP, the GDPR clock is 72 hours from becoming aware, and Article 83 allows up to EUR 20 million or 4 percent of global turnover. We covered the Polish deadlines in a [separate piece on NIS2 and the register](https://snok.ai/en/news/blog/nis2-ksc-sap-register-by-3-october/).
## Check where you stand before someone else asks
**SNOK KSC-CHECK is a free readiness assessment for SAP systems against NIS2 and its Polish implementation**: 25 questions across 6 steps and 5 areas, 8 to 12 minutes. You get the score on screen and a PDF report by email, with a 30-day and a 12-month plan.
The five areas are event visibility, detection and response, vulnerabilities, identity and access, and evidence for audit. Today's article touches the first three directly. Under vulnerabilities, the questions ask what your path from published note to deployed patch looks like and who owns it. Under visibility, whether the Security Audit Log is switched on for critical event classes and whether anyone actually reads it, since an enabled log on its own solves nothing. Under detection, whether SAP events reach a SIEM or a SOC, without which the 24-hour clock has nothing to start from. The evidence area carries its own weight, because the first audit of essential entities, scheduled for 3 April 2028, will assess evidence from 2026 and 2027 - the years being recorded now.
One boundary worth stating plainly: this is a self-assessment, not an audit and not a certification of compliance. It shows where the gaps are and what to close first.
[Take the KSC-CHECK assessment](https://snok.ai/en/tools/ksc-check/) - and if it turns out your patch process is documented, staffed and evidenced, that is the best possible outcome of this article.
## How to stop starting from zero every second Tuesday
Monthly note triage is work you can do once and then automate, on one condition: the system has to know your landscape - versions, components, kernel level, installed packages.
That is what **Patch Management in SecurityBridge** does. Published notes are mapped automatically onto your specific systems, so instead of a list for the entire SAP world you get a list for yourself, with priority and deployment status. August makes the difference visible. An organisation with no Commerce Cloud, no MII and no BusinessObjects can defer most of this list - but it has to know that from the state of its systems rather than from assumption. The reverse case is worse: a manufacturer running MII has six items this month in a component nobody had on the list.
Patching is one layer. The second is the code you write yourself - see our piece on [AI-generated ABAP](https://snok.ai/en/news/blog/secure-ai-generated-abap-securitybridge/), covered in SecurityBridge by Code Vulnerability Analysis. The third is real-time detection, without which the 24-hour clock has nothing to start from, which we covered in [the data breach your SIEM cannot see](https://snok.ai/en/news/blog/sap-data-breach-siem-blind-spot/) and which maps to Threat Detection and SIEM integration. Together those three layers are what a regulator means by measures proportionate to risk.
SNOK holds [SecurityBridge Polska Premier Partner status](https://snok.ai/en/securitybridge-snok/), so implementation and support run in local hours and local language.
## What to do this week
**1/** Check whether you run SAP Commerce Cloud with the Data Hub Adapter on COM_CLOUD 2211 or 2211-JDK21, and treat note 3771065 as today's work rather than next window's. In parallel, inventory every copy of ctsattach - note 3773304 is closed by removing the tool, not by installing a package. If you run manufacturing on MII, check XMII 15.4 and 15.5 against this month's six notes.
**2/** Measure how long it took you to deploy July's critical notes. That single number says more about your process than any policy document.
**3/** [Take the KSC-CHECK assessment](https://snok.ai/en/tools/ksc-check/) and bring the report to your next board meeting. The October deadline belongs to the board, not to IT.
If those three steps show you are short of hands or tooling, [get in touch](https://snok.ai/en/contact/). We start with a review of the actual state, not with a quote.
---
### The code nobody wrote. Securing ABAP in the age of AI assistants
URL: https://snok.ai/en/news/blog/secure-ai-generated-abap-securitybridge/ | Date: 2026-08-10 | Series: Other
In most SAP systems we audit, custom code accumulated over years and shared one property: you could point to its author. There was a person who wrote it and a person who reviewed it before the package moved on.
That certainty has just expired. AI assistants have settled into SAP development tooling, and with them systems started receiving code that, in the classical sense, nobody wrote. Someone requested it, someone approved it, someone released the transport. A machine wrote it.
This article is about what to do with that code. Without arguing that you should stop using AI, which would be both unrealistic and harmful. Instead, with a concrete control architecture: where the gates belong, which of them must block rather than warn, and who signs off on the result.
## What exactly changed
The change has three layers. Each would be manageable on its own; the difficulty comes from their overlap.
**The tooling layer.** SAP released SAP-ABAP-1, a foundation model trained on millions of lines of ABAP: standard objects, customer extensions, BAdI implementations and ABAP Cloud patterns. SAP Community materials put the figure above 250 million lines. It powers code explanation and generation in Joule for Developers, present in the ABAP development tools in Eclipse and in SAP Business Application Studio. In 2026 an ABAP extension for Visual Studio Code was added. On top of that sit general-purpose assistants that developers use whether or not anyone approved them.
**The human layer.** Once writing a report no longer requires knowing the syntax or the data structures, the authors of custom code start coming from outside the development team: functional consultants, analysts, juniors, business users. Their process knowledge is often deeper than the ABAP team's. Their security knowledge is nil, and that is a description of the situation, not an accusation.
**The architecture layer.** Clean Core pushes extensions out of the core and onto SAP BTP. The direction is right, but the side effect is hard: code that used to sit behind a firewall becomes an application exposed in the cloud. The conclusion that ran through a joint Deloitte and Onapsis webinar on AI-written SAP code is unambiguous here: Clean Core without moving security controls to the start of the process is a half measure.
The scale is already measured. In an Onapsis survey from June 2026 covering 204 security leaders at organisations with more than a thousand employees, **86 percent** have integrated or are integrating AI directly into ERP code, while **69 percent** admit their current defences cannot reliably detect an AI-driven attack.
## Seven mechanisms by which an assistant damages ABAP
This is not a list of hypotheses. The first six come straight from the Deloitte and Onapsis analysis; the seventh we add from our own audits.
**1. Missing authorization checks.** The model produces correct business logic and omits `AUTHORITY-CHECK`, because it has no access to your authorization concept. It does not know which authorization objects apply in that module, or that access to a particular table was a deliberate decision. The result: a report that works and shows data to anyone able to run it.
**2. Injection in queries.** A query assembled dynamically from user input is a pattern that appears hundreds of thousands of times in public code. The model reproduces it together with the missing input validation. This covers Open SQL, ADBC and native calls.
**3. Vulnerabilities in the interface layer.** Asking an assistant to add a header to a render function yields code that looks and behaves correctly but skips encoding and sanitisation. That is how XSS enters UI5 and Fiori applications. In the demonstration shown during the webinar, exactly this scenario was caught only by a scanner embedded in the editor.
**4. Replicating legacy flaws.** The model learned from historical code, including practices from an era when nobody worried about injection or direct table manipulation. A pattern that was normal fifteen years ago returns today as freshly generated code.
**5. Hallucinations and ghost dependencies.** References to objects, parameters and structures that do not exist in your system. Some surface at activation. Some pass through and only appear on a path nobody tested.
**6. Uncontrolled data operations.** An agent running without hard constraints can generate a mass operation against database tables. Without an enforced human approval before such an operation executes, nothing stops it.
**7. Drift away from segregation of duties.** This one is ours. Code generated "on the side" by someone outside the development team routinely bypasses the agreed process: it is created in the development system under someone else's account, joins a bundled transport and passes through an approval step that was never designed for this scenario. The SoD matrix stays formally correct while practice silently drifts away from it.
The common denominator: **none of these defects stops compilation, and none of them fails a functional test.**
## Why the existing gates miss all of this
Most organisations we work with have some form of code control. The problem is that all three classical gates were designed for a different traffic profile.
**Human code review** assumes there is only as much code as a person can read. In September 2025 Apiiro measured that developers using assistants ship code three to four times faster, while security findings in their repositories grew tenfold within six months. Quality moves the same way: in CodeRabbit's December 2025 study of 470 pull requests, those co-authored with AI carried **up to 2.74 times more security findings** and **1.7 times more issues overall**. Rising volume multiplied by a rising defect rate, against an unchanged number of reviewers, produces a result that needs no study to predict.
**ATC and Code Inspector** do work, but in their default variants they mainly check quality and adherence to standards rather than security. Full vulnerability analysis is a separately licensed capability, inactive in many systems. It also tends to run on demand rather than as a condition for moving forward.
**Functional tests and UAT** verify that a program does what it was supposed to do. They do not verify what else it does along the way. A missing authorization check is invisible to a tester who holds full authorizations.
Add time pressure. The developer's role shifts from writing to validating, while the headcount for validating stays the same. The bottleneck does not disappear; it moves to a place where nobody measures it.
## Three layers of defence
Our approach rests on one principle: **a control that costs nothing to bypass is not a control.** So the gates have to stand where code must pass anyway. In SAP there are exactly three such places.
### Layer one: the developer's editor
A vulnerability caught in the editor costs a minute. The same vulnerability caught in UAT costs a delayed release. Caught in production, it costs an incident.
SecurityBridge Code Vulnerability Analysis gives the developer scan results where they work: in the ABAP Development Workbench and in the ABAP tools for Eclipse, with native integration into SAP Code Inspector and the ABAP Test Cockpit. The detected classes map precisely onto what assistants produce: SQL, Open SQL and ADBC injection, missing authorization checks in RFC modules, direct table manipulation, directory traversal and backdoors.
Two capabilities matter especially for machine-generated code. **Explain ABAP Code** describes what a fragment actually does, which is essential for a person who did not write it but has to approve it. **Describe Vulnerabilities** explains the finding together with a remediation path, instead of leaving the developer with a rule number to search for.
Think of it as spell check: you keep writing, with an underline where something is wrong.
### Layer two: the transport
This is where it is decided, because the transport is the one place in SAP that cannot be bypassed.
SecurityBridge Transport Center adds what the standard transport system lacks. **A scan of the package contents becomes a precondition for import**, so a transport carrying a vulnerability nobody has fixed does not move to the next system. An approval workflow enforces segregation of duties and documents four-eyes sign-off in a form you can show an auditor. Alongside that come downgrade and version-conflict protection, prediction of missing dependencies and import list building for complex production cut-overs. We confirm the exact feature set with the vendor before every deployment, because the portfolio moves faster than the datasheets.
The same mechanism covers a case rarely considered in an AI context: **third-party code**. A package from an integrator or an add-on vendor passes through the identical gate as your own.
### Layer three: runtime
A static scan will not detect abuse of code that already passed inspection. Layer three is therefore continuous detection: SecurityBridge Threat Detection monitors system behaviour in real time and forwards events to your SIEM, whether that is Microsoft Sentinel, Splunk, QRadar or something else. Interface Traffic Monitor watches the interface layer, which is how custom code usually talks to the outside world.
An attempted exploitation can then trigger analysis of the code responsible for it. The loop closes: what happens in production feeds back into layer one.
## Who signs
The technical layers solve detection. They do not solve accountability, and accountability is what comes back at every board meeting.
The starting point is the shared responsibility model, which not everyone has absorbed: the cloud provider is responsible for the platform, and **you are responsible for your own code and extensions**. In the poll cited during the webinar, 13 percent of participants believed that moving to the cloud transfers security responsibility to SAP. It does not. Nor does it transfer to the provider of the AI model.
Four things we put in place on the governance side.
**A policy for assistant use in development.** Which tools are permitted, against which systems, and what data may be pasted into a prompt. Without that document, every downstream control is discretionary.
**Marking AI-assisted code.** A simple attribute on the object or a convention in the transport description. Not to stigmatise anyone, but to give code review and later incident analysis something to work with.
**An unambiguous meaning for the transport signature.** Releasing a transport must mean either "I have read and understood the code" or "I confirm functional acceptance", and everyone must know which. Today, in most organisations, nobody knows, including the person signing.
**Hard gates for irreversible operations.** Mass data operations, changes to critical objects, deployment outside the maintenance window: these are cases where human approval must be technically enforced, not procedurally expected.
The regulatory layer only confirms this. NIS2 requires, in Article 21(2)(e), measures covering security in the acquisition, development and maintenance of systems, including vulnerability handling. The provision says nothing about artificial intelligence, but custom code is created inside exactly that process, so the secure development obligation covers it regardless of who held the keyboard. A documented scanning and approval process is the simplest evidence that such a measure exists. For financial entities, DORA imposes comparable requirements around change management and testing.
## How we work at SNOK
We are SecurityBridge's partner in Poland and we run this topic from the SAP Basis and security side, not merely from the licensing side.
**Assessment.** We start with a scan of the existing custom code base and an inventory of who authored objects over recent months. The second part tends to be the most instructive for clients, because it shows how much code originates outside the development team. The output is a vulnerability list ordered by business risk, not by hit count.
**Deploying the control layer.** Enabling code analysis inside the development tools, wiring the scan into the transport process as a condition for import, configuring blocking thresholds and integrating events with the SIEM. Thresholds have to be calibrated on your own data. A gate that blocks everything gets switched off in week three.
**Governance and skills.** An AI usage policy for development, a transport approval model, and a workshop for the development team and functional consultants on what specifically to look for in code you did not write.
**Ongoing operations.** Periodic review of findings, handling of new vulnerabilities, audit support and, for organisations without their own SAP security team, an on-call expert model instead of a headcount.
## A 30, 60 and 90 day plan
**By day 30.** Inventory the authors of custom objects over the last six months. Scan the existing code base and produce a report ordered by risk. Decide, in one sentence, what a transport signature means.
**By day 60.** Code analysis available inside the development tools. Scanning as a condition for import into the test system, in warning mode for now. An assistant usage policy adopted and communicated.
**By day 90.** A blocking gate for the production system, with thresholds calibrated on real data from the previous stage. Runtime events flowing into the SIEM. Documented four-eyes approval ready to show an auditor.
## In closing
AI-generated code is not the problem in itself. The problem is that it arrives faster than the organisation can read it, and that it is visually indistinguishable from code somebody thought through.
The answer is not a ban, because a ban here simply moves the same phenomenon out of sight. The answer is to relocate control to places that cannot be bypassed: the editor, the transport and the runtime. Only then does a signature on a transport start to mean something again.
If you want to see what this looks like in your system, [get in touch](/en/contact/). We usually begin with a scan of the existing code base, because it is the only security conversation that puts numbers rather than opinions on the table within a week.
---
*For the wider context of how the profession is changing: [It compiles, so it works. ABAP in the age of the coding assistant](/en/news/blog/ai-generated-abap-who-signs-the-transport/), a column by Jacek Bugajski.*
**Sources:** Onapsis, State of AI, Security and ERP, June 2026 survey of 204 security leaders · CodeRabbit, State of AI vs Human Code Generation Report, 17 December 2025 (470 pull requests; vendor study) · Apiiro, September 2025 · Veracode, GenAI Code Security Report, 2025 · SecurityBridge product documentation (Code Vulnerability Analysis, Transport Center, Threat Detection, Interface Traffic Monitor) · Deloitte and Onapsis webinar "The Hidden Risks of AI-Generated SAP Custom Code" · SAP and SAP Community materials on the SAP-ABAP-1 model and Joule for Developers · NIS2 Directive, Article 21.
**Related posts:** [ABAP code as a non-obvious security threat](/en/news/blog/abap-code-sap-security-threat/) · [KSC, NIS2 and SecurityBridge](/en/news/blog/nis2-ksc-sap-register-by-3-october/) · [The AI agent on both sides of the attack](/en/news/blog/jadepuffer-agentic-ransomware-sap-cve/)
---
### SecurityBridge earns SAP-certified integration for S/4HANA Cloud Private Edition
URL: https://snok.ai/en/news/blog/securitybridge-sap-certified-s4hana-cloud-private-edition/ | Date: 2026-08-10 | Series: Other
In August, SecurityBridge announced that its platform has achieved SAP-certified integration with SAP S/4HANA Cloud Private Edition. The certificate was issued by the SAP Integration and Certification Center. It reads like a vendor milestone, yet for companies running SAP under RISE it has a fairly practical meaning.
## What the certificate actually confirms
SAP ICC has confirmed that the integration software for SecurityBridge Platform 7 integrates with SAP S/4HANA Cloud Private Edition using standard integration technologies. That is the full claim.
In plain terms: the platform runs inside the ABAP stack, and traffic between the controller system and the monitored systems uses standard SAP protocols. No appliance next to the system, no third-party agent, no data leaving the SAP boundary by an unusual route. The point is who confirms it. A vendor datasheet and an SAP certification are two different weight classes.
## Why Private Edition specifically
In S/4HANA Cloud Private Edition, SAP runs part of the technical stack and security responsibility is shared. The provider covers infrastructure and platform operations. Everything inside the system stays with the customer: authorisations, custom code, parameters, interfaces, security configuration.
Plenty of organisations discover that split during their first audit. A contract with SAP does not mean somebody is reading your application logs or tracking security notes for your Z code.
There is a more mundane angle too. In a provider-managed environment, every add-on installed in the system goes through an agreement with SAP. On the projects where we deploy [SecurityBridge](/en/securitybridge-snok/), the question of standard compliance keeps coming back. The SAP ICC certificate does not replace that process, but it removes the most common question from the table.
## What the certificate does not say
Certification describes how the integration works. It says nothing about detection quality, and nothing about your SAP being secure once the add-on is installed.
The platform collects security events, surfaces vulnerabilities and checks configuration compliance, and the vendor ships prebuilt security content to shorten the ramp-up. That part works. What does not happen on its own: somebody has to watch the alerts, somebody has to decide what counts as an incident and what is noise, and somebody has to wire it into SIEM and the service desk so a finding reaches the right team instead of a shared mailbox.
We have seen systems with a full licence and an empty process. Alerts fired, nobody read them. An SAP certificate does not fix that.
## What existing SecurityBridge customers get out of it
Good news, with no asterisk attached. If you already run the platform, you gain a stronger argument in front of SAP and your auditor: the integration is confirmed by SAP, not merely described by the vendor. If Private Edition is on your roadmap, one unknown drops out of the project, and in RISE migrations it is exactly those small unknowns that eat the schedule.
Two things worth checking on your side. First, which platform version you are on, since the certification covers Platform 7. Second, whether your monitored scope already includes the systems you are moving to the cloud, or only the on-premise landscape you started with.
## We are happy to show it in action
SNOK is a SecurityBridge partner in Poland. We deploy the platform, run it for customers, and know both its strengths and the places where it needs work from your own team.
If you would rather see the product than a slide about it, [we will set up a working session](/en/contact/): what the platform sees inside an SAP system, how vulnerability scoring looks in practice, how an event reaches SIEM, and how much of it your current team can realistically handle. We can also walk through your landscape and say plainly which parts make sense and which would be buying capability you will not use. The session takes an hour and does not end with a quote unless you ask for one.
If you would rather start with your own numbers, run the [SNOK KSC-CHECK](/en/tools/ksc-check/) assessment: 25 questions about your SAP landscape, 8 to 12 minutes of work. The result appears on screen immediately, and the PDF report with statutory deadlines, gaps and an action plan goes to the address you provide. Free of charge.
**Sources:** SecurityBridge, "SecurityBridge Platform Achieves SAP-Certified Integration with SAP S/4HANA Cloud Private Edition", Ingolstadt, August 2026 · SAP Integration and Certification Center, sap.com/icc
**Related posts:** [SAP audit with SNOK and SecurityBridge](/en/news/blog/sap-audit-securitybridge-peace-of-mind/) · [Lenovo TruScale as a private cloud for RISE with SAP](/en/news/blog/lenovo-truscale-private-cloud-rise-sap/) · [Securing AI-generated ABAP code](/en/news/blog/secure-ai-generated-abap-securitybridge/)
---
### It compiles, so it works. ABAP in the age of the coding assistant
URL: https://snok.ai/en/news/blog/ai-generated-abap-who-signs-the-transport/ | Date: 2026-08-10 | Series: Other
For thirty years, ABAP defended itself. Not through its syntax, which forgives almost everything. It defended itself through the barrier to entry.
To write anything meaningful inside an SAP system, you first had to understand the data dictionary, the authorization concept, authorization objects, the logic of the module you were touching, and the entire ritual of moving transports across three systems. None of that knowledge lived in documentation. It lived in the heads of people who had survived a few implementations and a few failed go-lives. It was passed on at a desk, not in a course.
That barrier is now gone. Not gradually, over a decade. In a matter of months.
## What changed under the hood
SAP released a foundation model trained exclusively on ABAP. SAP-ABAP-1 learned from millions of lines of ABAP: standard objects, customer extensions, BAdI implementations and ABAP Cloud patterns. SAP Community materials put the figure above 250 million lines. It powers code explanation and generation in Joule for Developers, built into the ABAP development tools in Eclipse and into SAP Business Application Studio. In 2026 an ABAP extension for Visual Studio Code joined the set, bringing SAP development into the editor where most of the non-SAP world already works.
Notice the direction of that change. This is not only a story about ABAP developers getting a faster tool. To write something in SAP that compiles and passes the functional test, you no longer have to be an ABAP developer.
That report will now be written by a functional consultant who has configured MM for fifteen years and never written a line of code. An analyst from the data team will write one. So will a junior three weeks into the project. So will the business owner who understands the process better than anyone in IT. I have no objection to any of that. I think it is good news, because the best extensions were always built close to the process, not close to the compiler.
The problem sits elsewhere. The barrier to entry disappeared faster than the gates that inspect what comes through it.
## Compilation was never a security test
Code that comes out of an assistant has one property that disarms scrutiny better than any other: it works. It compiles on the first attempt, it passes the functional test, it does exactly what you asked. The business sign-off goes beautifully.
Except that the SAP compiler never checked the things that are actually dangerous in this platform.
It never checked whether an `AUTHORITY-CHECK` stands in front of that payroll read. It never checked whether a query assembled dynamically from user input can be taken apart by injection. It never checked whether the RFC module you just exposed verifies the caller's authorizations. It never checked whether writes go through application logic or straight into the table, bypassing everything somebody once designed. And it certainly never checked whether the field you render is encoded before it reaches the browser.
The model did not skip those things out of malice. It simply does not know them. It has never seen your authorization concept. It has no idea what your segregation-of-duties matrix looks like. It does not know that in this particular company exactly eight people can read the payroll table, and that this was a board decision rather than an accident. It sees a pattern drawn from millions of lines of somebody else's code, and it reproduces that pattern with complete confidence.
Along with the pattern, it reproduces the flaws. The model learned from historical code, including practices from an era when nobody thought about injection. It also invents objects that do not exist and parameters that never did. And the resulting code looks exactly like good code. That is the part that worries me most: the difference is invisible from the outside.
## Numbers worth keeping in mind
In December 2025 CodeRabbit reviewed 470 pull requests from open-source projects: 320 co-authored with AI and 150 written by humans alone. The former carried **up to 2.74 times more security findings** and **1.7 times more issues overall**, meaning logic, performance and maintainability. It is a vendor study on open-source code, so treat it as an indication rather than a verdict.
Others point the same way. Veracode tested more than a hundred models across eighty coding tasks: **45 percent** produced code with a vulnerability, and in Java 72 percent did. Apiiro measured something more telling inside enterprise repositories: developers using assistants ship code three to four times faster, while security findings in those repositories grew **tenfold** in six months.
That is the heart of it. The assistant does not write worse than a person. It writes far more, while the number of people reading that code has not gone up by one.
Onapsis, surveying more than two hundred security leaders in June, found that **86 percent** of organisations have integrated or are about to integrate AI directly into ERP code, while **69 percent** admit their current defences cannot reliably detect an AI-driven attack.
One more number turns this from an academic topic into an operational one. In its research on attacks against SAP systems, Onapsis measured how long an unsecured SAP application exposed in the cloud survives before it is discovered and attacked. **Under three hours.**
## Clean Core raised the stakes
Here is the part of the puzzle that usually gets missed.
For years, custom code lived inside your own four walls. Written carelessly, perhaps, but behind a firewall, in a system reachable by a few dozen people. A vulnerability in such a report was real, but hard to get to.
Clean Core changed the geography. Extensions move out of the core onto BTP and become cloud applications. That is the right architectural direction and I recommend it to clients myself. Its side effect, though, is that the same code, written with the same care, now hangs on the internet. The same conclusion ran through a joint Deloitte and Onapsis webinar on the risks of AI-written SAP code: Clean Core without moving security controls to the start of the process is a half measure.
Now read that next to the three hours from the paragraph above.
## Who signs
Which brings us to the only question in this story that genuinely interests me.
SAP has something most of IT does not: a physical, named moment of accountability. Someone releases the transport. Someone else imports it into production. Both names stay in the log and cannot be taken out of it. That mechanism was designed in an era when releasing a transport meant: I have read this, I understand it, I take it on.
Today it increasingly means: I approved a suggestion I did not read, because there was too much of it and it looked reasonable.
The signature has not changed. What changed is what stands behind it.
Meanwhile the ABAP developer's role is shifting from writing to validating, and that shift is healthy. The trouble is that when teams handed the writing over to the machine, nobody added capacity for the reading. The bottleneck did not dissolve; it moved one step to the right, into a place where nobody happens to be looking. And under time pressure, the first thing dropped is always whatever does not hurt immediately. Security loses that contest every time, because its absence starts to hurt some months later.
Punishing anyone for this changes nothing. What changes things is the person signing actually **knowing** what they sign.
## This can be brought under control
I write about it calmly because I know the other side of the story. A code scan wired into the transport stops a package carrying a missing authorization check or an injection before it reaches the next system. The developer sees the flaw in the editor, in the same minute it appeared, rather than three days before go-live.
At SNOK we build this on SecurityBridge. I have followed that product for practically as long as the company has existed, and it is one of the few cases where a security tool for SAP grows alongside the platform instead of trailing a year behind it. Good software, made by people who understand SAP from the inside. How to arrange it layer by layer, we describe separately.
## Three things for Monday
I have no manifesto for you, but I do have three things to do straight away.
**Find out who actually writes code in your SAP systems.** Not in the org chart, in the system. The list of authors of custom objects over the past six months can be surprising, and it is the cheapest diagnostic I know.
**Put the security scan into the transport, not into the calendar.** A control that happens "once a quarter" in practice never happens. A control without which the package does not move to the next system happens every single time.
**Decide what your signature on a transport means.** One sentence in the policy, so that everyone releasing a transport knows whether they are confirming that they read the code or merely that the function was accepted. Today, in most organisations, nobody knows, including the person signing.
Because the assistant will not stand in front of an auditor. It will not take a call on a Sunday when it turns out that the report meant to show stock levels was also reading the entire payroll table without a single authorization check.
You will.
## Download the column as a PDF
A column by Jacek Bugajski · August 2026
It compiles, so it works
PDF, 11 pages, about 6.5 MB - an offline reading version, no form and no personal details required. Feel free to pass it around your team.
---
*How to secure this in layers, where to place the gates and what it looks like in practice with SecurityBridge, we cover in a separate article: [The code nobody wrote. Securing ABAP in the age of AI assistants](/en/news/blog/secure-ai-generated-abap-securitybridge/).*
**Sources:** CodeRabbit, State of AI vs Human Code Generation Report, 17 December 2025 (470 pull requests; vendor study) · Veracode, GenAI Code Security Report, 2025 · Apiiro, September 2025 · Onapsis, State of AI, Security and ERP, June 2026 survey of 204 security leaders · Onapsis Threat Research on attacks against SAP applications · Deloitte and Onapsis webinar "The Hidden Risks of AI-Generated SAP Custom Code" · SAP and SAP Community materials on the SAP-ABAP-1 model and Joule for Developers.
**Also worth reading:** [ABAP code as a non-obvious security threat](/en/news/blog/abap-code-sap-security-threat/) · [Three acts of SAP AI and the question that was not on the slides](/en/news/blog/three-acts-of-sap-ai-agent-security/) · [SAP testing and the release trust problem](/en/news/blog/sap-testing-release-confidence-not-test-count/)
---
### Weekly Review W32: what the tool can do - and what it is allowed to do
URL: https://snok.ai/en/news/blog/weekly-review-w32-what-the-tool-can-do-and-what-it-is-allowed-to-do/ | Date: 2026-08-07 | Series: Other
Seven items from the week of 31 July - 6 August 2026, each with a comment on what it changes in your systems.
This week three independent communities - a standards body, a research firm and an enterprise software vendor - described the same phenomenon from three different angles. Nobody coordinated it. OWASP moved excessive model autonomy up to third place on its risk list. Red Hat counted how many companies actually oversee that autonomy and arrived at thirty-one percent. SAP wrote that decisions about agent permissions belong to the board.
The question that emerges is, at heart, an old one and has nothing to do with artificial intelligence. It reads: who decided what this tool is allowed to do. The only new part is that the tool has started acting on its own, while the answer to that question is rarely assigned to a named person.
Add to that two items on what agents are actually starting to do in automation, one Polish data breach and one attack for which there is no good answer today.
---
## 1. OWASP Top 10 for LLM applications: the new edition stopped describing fears
On 4 August the 2026 edition of the list of the ten most serious risks in applications built on large language models was published. It is the first edition in which the ranking was produced by colliding two sources: practitioner votes and the record of real incidents. The authors name the difference outright - it is the gap between what the industry fears and what it has already been burned by.
Three moves are worth knowing by heart.
**Excessive Agency moved up to third place.** Not because anyone changed their mind, but because that is where the damage lands. The model was given tools and started using them more broadly than anyone had planned.
**Unbounded Consumption climbed four positions.** Uncontrolled token cost has stopped being a budget line and become a security risk. In many companies this shift is not yet reflected in the division of responsibility - the model invoice and the incident report usually land on two different desks.
**Improper Output Handling dropped from fifth to tenth, but with a broader scope** - it now covers unsafe code generated at scale by assistants. A drop in the ranking does not mean the problem went away.
There is one more distinction, more important than the order itself. This list describes the risk when the model is a **component** inside an application. The moment it becomes an **actor** - with tools it calls on its own, memory carried across sessions and effects that propagate down the process - the risk moves to a separate list, the OWASP Top 10 for Agentic Applications. The authors state plainly that many incidents sit exactly on the boundary and neither list covers it alone.
The practical takeaway: if someone in an agentic project cites only the LLM list, they are looking at half the picture.
In parallel, AISVS 1.0 was released - the first testable verification standard for AI system security, with maturity levels and chapters on agent orchestration and attack resilience. The difference is fundamental. A risk list tells you what to fear. A standard tells you what to check and how to prove it was checked.
Sources: [OWASP GenAI](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/), document dated 4.08.2026, CC BY-SA 4.0 licence; coverage in [Help Net Security](https://www.helpnetsecurity.com/2026/08/06/owasp-2026-llm-top-10-released/), 6.08.2026.
---
## 2. Thirty-one percent
Red Hat published a study with three numbers that are worth reading together, because it is the spread between them that says something.
**92%** of organisations declare they know where the data used by AI is stored.
**49%** have full control over that data.
**31%** have implemented mature oversight mechanisms for agentic AI.
The drop from ninety-two to forty-nine is the difference between "we know" and "we can do something about it". The drop from forty-nine to thirty-one is something else - the difference between technical control and organisational governance. The second gap is the harder one, because it does not come bundled with a licence.
As a maturity test, the study's authors point to something that cannot be faked: the ability to switch model or platform vendors without disrupting the business. **63%** of companies have a formal exit strategy, while **30%** have not prepared one at all. Within that second group, 14% assume a migration would be easy - which is itself an interesting measurement of optimism.
Until the first agentic deployment, oversight is a sentence in a policy. Our observation from projects is that the real test arrives on the day an agent is granted access to a production system and someone has to decide what it may do without asking.
To be fair: the study comes from a vendor whose platform is meant to solve this very problem. That does not invalidate the numbers, but it does mean reading them as a measurement taken by an interested party.
The study came out one day after the first threshold of AI Act obligations. A coincidence, but a telling one.
Source: Red Hat study as reported by [ITwiz](https://itwiz.pl/tylko-31-firm-skutecznie-nadzoruje-agentowa-ai/), 3.08.2026. We could not locate the original Red Hat report in open access - the figures are quoted from the coverage.
---
## 3. UiPath Maestro Case: numbers worth knowing
Early adopters of the Maestro Case module report average case handling time cut by **60-80%** and **three to five times** more cases closed without human intervention.
One caveat before these numbers travel any further: they describe early deployments selected and written up by the vendor. That is the upper bound of what a process well matched to the tool can achieve. Not an average and not a promise.
More interesting than the percentages is what they apply to. Maestro Case manages a case, not a task. The difference is practical. A task has a beginning, an end and a robot. A case can live for weeks, pass through several systems and several pairs of hands, and stop along the way at every step that requires [someone's approval](/en/news/blog/hitl-gates-uipath-maestro-ai-trust-layer/). Classic automation handles the task brilliantly and stalls exactly at the moments where the case is waiting.
The processes where numbers like these repeat share one profile: high case volume, repeatable decisions, data scattered across several systems. Claims handling. HR helpdesk. Approvals in SAP flows.
And the inverse, which needs saying: if a company has no automated tasks yet, the orchestration layer has nothing to manage. Maestro does not replace the first step.
Source: [UiPath investor announcement](https://ir.uipath.com/news/detail/455/uipath-introduces-maestro-case-to-orchestrate-dynamic-exception-heavy-business-processes-across-the-enterprise).
---
## 4. Autopilot stopped suggesting and started building
Autopilot in UiPath Studio Desktop is presented as a full coding agent: it is meant to plan, build, run, diagnose, explain and rework automations. Public preview, available from the STS S195 line upwards. We do not yet know the quality of its output on a real client project, and we say so plainly.
The list of announced capabilities is longer, but three items show the scale of the change. It takes a thirty-page specification of an employee onboarding process and builds a complete automation from it, interface steps included. It takes a deployed job that reported an access-denied error at three in the morning and traces the failure to missing robot permissions. It takes an action that stopped working after an application change, names the cause and repairs the selector.
That last one is precisely what separates it from a [general-purpose agent](/en/news/blog/uipath-claude-code-codex-enterprise/). **General-purpose agents do not know what a selector is.** Autopilot does, because it works inside Studio, on the same skills as the rest of the platform, with the object repository within reach. UI automation - the core of classic RPA - works for it from day one, while for external agents it tends to be the weakest link.
The second difference concerns oversight and will matter more in the conversation with your security team than the feature list. Within the monthly limit there is no separate subscription and no token billing. There is also no account to open with an external provider and no extra keys to guard. Destructive actions are gated, the autonomy level is set by an administrator, and events go to the audit log. Studio remains the visual layer - every change can be opened, inspected and debugged.
Three caveats without which this item would be marketing material. It is a public preview, not general availability - you do not build a project schedule on it. The monthly usage limit has not been quantified, so before anyone says "no extra cost", it needs to be established for the specific licence. And the simplest thing of all: customers on the LTS line - the long-term support releases - will not see this feature.
Source: [UiPath forum](https://forum.uipath.com/t/autopilot-just-became-a-coding-agent-in-studio-desktop/5759250), announcement of 7.07.2026.
---
## 5. Żabka: in through a vendor, out with a map
On 4 August Żabka Polska - Poland's largest convenience store chain - confirmed unauthorised access to selected technical resources through an external service provider's account. The incident was detected at the end of the previous week. Independently, an offer appeared on a criminal forum to sell the allegedly stolen set for **EUR 5,000**: Jira tickets, code repositories, user information. The company did not disclose the scope, and the description of the set comes from the attacker, not the victim.
The most interesting thing in this story is the asking price. Five thousand euros is not much, which suggests the attacker himself does not consider the haul spectacular. If his description is accurate, he reached for material that most companies classify as technical rather than sensitive.
It is worth pausing on what actually sits in a ticketing system. Configuration dumps pasted into a comment so a colleague can see the error. System addresses. Names and roles of the people who know each integration. A description of what exactly keeps breaking and since when. Together this is a map of the environment written by the people who know it best. Repositories add integration details and, in the worse variant, credentials left in the change history.
Formally, two regimes may apply here: GDPR obligations, including the seventy-two-hour notification deadline, and - if the entity qualifies as an important one - obligations under Poland's national cybersecurity act, which implements NIS2.
Two questions are worth asking before someone else asks them. Which of our resources can each vendor reach today. And what happens if one of them calls tomorrow morning about their own incident. A data processing agreement answers the first question only if someone has read it since it was signed.
Sources: [Sekurak](https://sekurak.pl/potencjalny-wyciek-danych-z-zabki/), [CRN](https://crn.pl/aktualnosci/cyberatak-i-kradziez-danych-z-zabki-zabka/), [ITwiz](https://itwiz.pl/cyberatak-na-zabke-haker-oferuje-dane-firmy-za-5-tys-euro/), [The Record](https://therecord.media/poland-convenience-store-chain-zabka-cyberattack).
---
## 6. SAP called agent sprawl a board-level problem
On 3 August SAP published an article on a phenomenon it named agent sprawl: organisations deploy agents faster than they build the mechanisms to oversee them. A sentence from the piece: "As adoption of AI agents accelerates, governance is struggling to keep pace".
The thesis goes further than a technical diagnosis. Decisions about agent permissions are decisions about business risk, so they belong to the board, not to the operations team. The vendor positions its own layers as the answer along the way, which is natural and worth saying out loud right away.
In an ERP system the stakes look different than in a marketing tool. There, an agent's mistake costs a campaign. Here, the agent works on the data that the month-end close, supplier settlements and tax filings stand on. A change made by an agent can trigger an accounting effect - and all the more it must leave a trace in the audit log. [We wrote about this at length in the context of SAP agent security](/en/news/blog/three-acts-of-sap-ai-agent-security/).
Then there is the thing specific to this environment. Permissions in SAP are built over years, layer upon layer, and rarely can anyone say from memory what exactly a technical user - the one whose permissions an integration runs on - is able to do. An agent granted permissions "same as the existing integration" inherits all that baggage, along with everything everyone forgot about.
A question for your next review: how many agents run in your SAP landscape today, who approved their permissions, and can that list be reconstructed without polling three people. If gathering the answer takes a week, that is exactly the sprawl SAP is writing about.
Source: [news.sap.com](https://news.sap.com/2026/08/agent-sprawl-why-ai-governance-is-now-board-level-issue/), 3.08.2026.
---
## 7. The page plants an instruction, the agent executes it. Can we defend against this?
We saved for last the item where the answer is "not in a way that closes the subject".
Independent research teams have been showing for over a year that browsers with a built-in assistant can be taken over without a single click from the user. The mechanism is banal, and that is exactly why it is dangerous.
The assistant reads the page through the same text stream it reads your command through. All the attacker needs is to hide a few sentences phrased like an instruction in the content - white text on a white background, or in a paragraph the agent was going to summarise anyway. The assistant takes those sentences for a command and executes them. Nobody clicks anything. It is enough to let the agent onto a prepared page.
The consequences described in the research go beyond data theft. One scenario serves the agent a page pretending to require a login, to harvest credentials. Another steers what information the agent collects and what conclusion it reaches - an attack not on data but on the recommendation the agent will hand you. Vendors keep adding safeguards, researchers keep bypassing them one by one and state plainly that no perfect fix is in sight.
> **A note on a number making the rounds.** A figure of 86% attack success is in circulation. We checked it, and it does not hold up in the form it is being repeated: it comes from an earlier study (the WASP benchmark, 2025) and describes partial success of a prompt injection, not the share of successful fake logins. That is why we do not present it here as fact. The mechanism is documented and is enough on its own - the number is not needed.
### Why there is no patch here
The reasons are structural, not an oversight by any particular vendor.
First, the agent has **one door for content and for commands**. A single input channel for text to read and orders to execute, with no reliable way to tell them apart, because both are plain text.
Second, **the human has left the loop**. It was the human who usually caught the odd command before executing it. An agent acting autonomously removes that moment. What remains is the text and the action - and gone with them is the instant in which anyone could say: hold on, I did not order this.
Hence a conclusion worth remembering: **input-side control will not catch this**, because the attack looks exactly like the content the agent was meant to read. It only becomes visible in what the agent does.
### What can be done today
Four things. None of them is a solution; together they limit the blast radius.
**Watch behaviour instead of filtering input.** Since the attack is indistinguishable at the input, the budget goes into an oversight layer and detecting deviations from the intended trajectory, not into another command classifier. Classifiers get bypassed - we have been through that with earlier vulnerabilities of this family.
**Put a gate on irreversible actions.** Payment, dispatch, permission changes, data deletion - everything that cannot be undone requires human confirmation. This is where the removed moment gets put back in.
**Give the agent narrower permissions than the user.** If the answer to "what can the agent reach after a takeover" is "everything the user has access to", that is the wrong answer.
**Isolate the environment.** An agent driving a browser works in a segregated environment, not on a workstation logged into production systems.
Finally, something it is only right to say about ourselves: we use agent-driven browser tools. The same class of risk applies to us, not just to our clients, and we treat it accordingly.
---
## What follows from this
Seven items, one common denominator. The risk list moves excessive autonomy up. The study shows that fewer than one company in three has mature oversight. The ERP vendor says it is a board matter. Two automation items show how much that autonomy actually delivers when it is properly fenced. The breach reminds us that a company's perimeter stopped running along its own infrastructure long ago. And the last item says outright that in one place we have no good answer today.
If we were to leave you with one question for Monday, it would be this: **who in your company signs off on an agent's permission scope - by name, not by a job title in a policy.** Everything else is achievable once that answer exists. Without it, every other item on this list is just industry news.
If any of these topics touches you directly - oversight of agentic AI, [SAP security](/en/offer/sap-security/), [orchestration and automation with agents](/en/offer/ai-automation/) - [let's talk](/en/contact/).
---
*The weekly review is our selection from several hundred radar and RSS items each week. Sources are linked at every item. Informational material; it does not constitute legal advice.*
---
### Tech Thursday with SNOK: Document Understanding 26.7 - documents enter coded workflows
URL: https://snok.ai/en/news/blog/uipath-document-understanding-26-7-coded-workflows/ | Date: 2026-08-06 | Series: Tech Thursday
In Tech Thursday with SNOK we take one technology and check what it actually changes in our clients' work. Today: the new Document Understanding preview which at first glance looks like a list of minor improvements - and in practice closes three architectural gaps that enterprise document-processing teams kept tripping over.
The versions in question: UiPath.DocumentUnderstanding.Activities 3.4.0-preview, UiPath.PDF.Activities 4.4.0-preview and UiPath.IntelligentOCR.Activities 7.4.0-preview, plus the Public Preview of IXP models as solution resources ([IXP release notes, 23 July 2026](https://docs.uipath.com/ixp/automation-cloud/latest/release-notes/ucd-july-2026)). Let us take them in turn.
## Gap one: documents were locked inside XAML
Until now, document classification and extraction lived in the world of visual workflows. Teams that write automations in C# - with loops, LINQ, exception handling and unit tests - had to return to the canvas whenever documents entered the picture.
As of 26.7, the DU and PDF packages expose their capabilities as services callable directly in coded workflows. The `du` service covers classification, data extraction and the human-in-the-loop validation artifacts; the `pdf` service covers the whole toolbox: reading text, counting and splitting pages, merging files, extracting attachments and converting documents to PDF. A complete classify-then-extract flow is now a dozen lines of C#, without a single XAML file.
Why does this matter right now? Because code is the language coding agents move in most fluently. We recently wrote about [how coding agents are changing the work of UiPath teams](/en/news/blog/uipath-claude-code-codex-enterprise/) - and document processing was a blind spot on that map. After this release an agent can generate, test and maintain document logic the same way it handles any other code.
One caveat from practice, confirmed in the discussion under the announcement: the suspend/resume mechanism (persistence) does not work inside coded workflows. Design human validation so that the validation artifacts are created in code, but the actual process suspension happens outside it - otherwise the architecture will surprise you during integration testing, not earlier.
## Gap two: the model lived a separate life from the automation
Anyone who has deployed Document Understanding across dev, test and production environments knows the pain: the workflow travels in a solution package, while the extraction model has to be moved and configured separately, environment by environment.
In Public Preview, IXP models become a regular solution resource: they appear in the Resource Explorer in Studio Web, are packaged and versioned with everything else, and travel with the whole package at deployment time. The Extract Document Data and Document Understanding Project Extractor activities gained a "Use Solution Resource" toggle - switch it on, pick the model, and from that moment the model's lifecycle is the same lifecycle as the automation's.
It sounds like a detail, but details like this decide whether [an agent or automation makes it from proof of concept to production](/en/news/blog/build-ai-agent-uipath-production/) - governance and repeatable deployments are usually the harder half of the project, not the extraction itself.
## Gap three: the pipeline assumed a "ready" PDF
The reality of an inbox looks different: an invoice arrives as an email body, a report as HTML, a confirmation as plain text. Three new activities - Convert Email to PDF, Convert HTML to PDF and Convert Text to PDF - normalise these formats into PDF, the shape the rest of the pipeline expects. They work in both Windows and cross-platform projects, with a shared set of rendering options.
The pattern this unlocks: an email trigger fires, the message is converted to PDF, data gets extracted - a complete mailbox-to-structured-data path with no manual steps in between.
A separate, strong building block is the Extract Attachments From PDF activity (available since the PDF package 4.3.0, late June), which pulls embedded XML files out of a document. This is the daily reality of e-invoicing: in Poland the domestic flow has moved to structured XML in KSeF (Poland's mandatory e-invoicing system), while foreign suppliers still send hybrid invoices such as ZUGFeRD or Factur-X - a PDF with XML sewn inside. Instead of OCR-ing an image of such an invoice, you now take the ready structured data out of it with a single activity.
## A bonus for compliance teams: field-level redaction
The Redact Document activity gained a public `RedactionOptions` argument - granular control over how each field is redacted: full fill or strikethrough, colour and opacity, plus redaction codes printed over the blacked-out areas, exactly the way legal and audit practice does it. An entry with an empty field identifier acts as the default rule for every phrase on the provided list.
For companies working with personal data this is tangible: document anonymisation stops being a separate manual stage and becomes a policy written into the automation.
## What to do with it
This is a Preview release - UiPath explicitly recommends evaluating it in non-production environments, and we second that. A sensible plan for the coming weeks:
1. **Inventory the places where documents enter your processes** - especially those where someone manually saves emails as PDFs or retypes data from hybrid invoices.
2. **If you have a team writing C# or working with coding agents** - run a pilot with the `du` and `pdf` services on one real document type, with human validation designed outside the coded workflow.
3. **If you deploy DU through Solutions** - test IXP models as solution resources on the dev-test path; it is the shortest route to repeatable deployments.
As a UiPath Platinum partner, SNOK - an IT consulting firm from Warsaw - [helps take this road](/en/offer/ai-automation/): from a review of your document stream, through architecture, to production with governance that passes an audit. [Get in touch](/en/contact/) if you would like to see these mechanisms working on your own documents.
---
### Lenovo ThinkStation PGX hands-on: we put the NVIDIA GB10 AI workstation through its paces
URL: https://snok.ai/en/news/blog/lenovo-thinkstation-pgx-gb10-hands-on/ | Date: 2026-08-05 | Series: Other
I rarely write about hardware. This time I am making an exception, because a machine passed through our lab that changes how you think about enterprise AI - and we managed to give it a proper workout before it moved on to a client.
The machine is the Lenovo ThinkStation PGX: the corporate take on the class of devices built around the NVIDIA GB10 Grace Blackwell superchip, the same family as the NVIDIA DGX Spark. From the outside it looks like a tidy mini PC. Inside is something that two years ago would have required a server rack: a computer designed exclusively for developing and running artificial intelligence.
## What is inside
The configuration we tested looks like this (full specification: [Lenovo Press](https://lenovopress.lenovo.com/lp2321-thinkstation-pgx)):
- the **NVIDIA GB10 Grace Blackwell** superchip - CPU and GPU on a single package,
- **20 ARM cores** (10x Cortex-X925 + 10x Cortex-A725),
- an **NVIDIA Blackwell** GPU with 5th-generation Tensor Cores,
- **128 GB of LPDDR5X unified memory** shared between CPU and GPU, with 273 GB/s of bandwidth,
- an NVMe drive up to 4 TB with hardware encryption,
- 10 GbE networking plus a ConnectX-7 SmartNIC and Wi-Fi 7,
- **NVIDIA DGX OS** (Ubuntu on ARM64),
- all of it powered by a 240 W supply - less than a single gaming graphics card can draw.
The number that matters most is the 128 GB of unified memory. In a classic workstation a language model has to fit into GPU memory, which usually means 24-48 GB. Here the CPU and GPU share one pool - so a machine the size of a hardcover book runs models that until recently required a server costing six figures.
## What we ran on it
We did not run benchmarks for their own sake. We built a complete working environment, the kind you would actually deploy at a client:
- an **inference backend** (Ollama and vLLM) serving models over a standard OpenAI-compatible endpoint,
- **[Hermes Agent](https://hermes-agent.ai)** by Nous Research - an open-source agent that connects to that endpoint, performs tasks with tools and builds its own memory,
- a set of local models: **gpt-oss-120b** as the flagship generalist, **Qwen3-Coder 30B** for code and agentic work, and **gpt-oss-20b** for fast, cheap tasks.
The first item is the one that impressed us most. A 120-billion-parameter model - a class that not long ago was reserved for the cloud - runs locally, smoothly and with sensible response times (actual speed depends heavily on the inference engine - an optimised stack can be several times faster than default settings). In a Mixture-of-Experts architecture only a fraction of the parameters is active per token, so despite its size the model takes roughly 60-65 GB in MXFP4 quantisation and leaves headroom for long context.
## Three lessons from the lab
**First: MoE beats dense.** Large dense models (Llama 70B, for example) fit in memory comfortably but are slow in a single conversation - the 273 GB/s of memory bandwidth is the natural ceiling, which [public benchmarks](https://presenc.ai/research/local-llm-tokens-per-second-benchmarks-2026) confirm as well. Mixture-of-Experts models sidestep that ceiling gracefully. On this machine the model's architecture matters more than its raw size.
**Second: this is a machine for agents, not for a single chat.** The GB10 shows its strength under many parallel requests - which is exactly how AI agents and document-processing pipelines work. In batched workloads the device delivers many times the aggregate throughput of a single conversation. If you are planning to [take agents to production](/en/news/blog/build-ai-agent-uipath-production/), this is hardware cut for that scenario.
**Third: fully offline genuinely works.** The whole chain - model, agent, tools, memory - runs without a single packet leaving for the internet. For companies handling data under NDA, personal data or regulatory requirements (NIS2, DORA - both very much alive for EU businesses), this is not a curiosity. It is the answer to the question we hear most often: "how do we use AI without our data leaving the organisation?" We wrote about this approach when we described [an AI factory for SAP without the cloud](/en/news/blog/ai-factory-for-sap-without-cloud/) - the PGX is the same direction, in a form factor you can set up on a desk within an hour.
## Who it is for
After these tests we see three natural use cases:
1. **Confidential AI on your own data.** Analysing documents, code and data that cannot leave the organisation - a local model plus RAG over an internal knowledge base.
2. **A development environment for AI teams.** Prototyping agents and pipelines without an API cost meter - once you own the hardware, the marginal cost of inference is zero.
3. **A first step towards private AI infrastructure.** Before you invest in a full [private cloud for enterprise workloads](/en/news/blog/lenovo-truscale-private-cloud-rise-sap/), the PGX lets you verify on real data whether local models can carry your use cases.
To be fair about the limits: this is not a machine for training large models, nor a replacement for the cloud where you need frontier-model quality. It is a device for inference, prototyping and agentic work - and in that role it is, in our view, the most interesting proposition in its price class today.
## Verdict
The unit we tested has already shipped to a client - and frankly, we miss it a little. Machines that serve 120B-class models in this form factor, at a 240 W power draw, simply did not exist until now.
If you are wondering what such an environment could look like in your organisation - from hardware selection through models to [agents integrated with your processes](/en/offer/ai-automation/) - SNOK, an IT consulting firm from Warsaw and a [Lenovo Platinum partner](/en/lenovo-snok/), helps take that road from test to production. [Get in touch](/en/contact/) and we will show it live.
---
### Quo vadis, engineer?
URL: https://snok.ai/en/news/blog/quo-vadis-engineer/ | Date: 2026-08-04 | Series: Other
## Never have so many people built software they do not understand
I know how that sentence sounds. Like the opening of a lecture by an older gentleman about to tell the young that things used to be better. I promise this is not that - I use these tools every day and I genuinely like them. Which is exactly why I believe that someone who has spent more than twenty years in this industry should say out loud a few things that are more comfortable to leave unsaid.
Let us start with scale, because scale changes everything. When Andrej Karpathy wrote about vibe coding in February 2025 - you give in to the vibes, accept everything the model proposes, and forget the code even exists - it read like a description of a weekend toy, and that is how it was meant. Less than a year and a half later, Google states that artificial intelligence already generates roughly three quarters of new code at the company, with human review at the end (Business Insider, April 2026). In the autumn of 2024 it was one quarter. A curve like that does not know the word "experiment".
And the same thing is happening one floor down, outside IT departments. Someone in procurement assembles a supplier analysis dashboard. Someone in finance glues together a bank integration over the weekend. Everything works, everyone is happy. Meanwhile the questions of who will maintain it, who will secure it and who will answer for it hang in the air, waiting for their moment. That moment usually arrives at the least convenient time.
Which brings us to you. If anyone can now assemble a working system, what do we still need a person for who spent years learning how systems are really built?
## Maybe you genuinely do not need an engineer
I will put it more honestly than a man running an engineering company probably should: for many things, the engineer has genuinely stopped being necessary. And that is a good thing.
For a prototype? Not needed. For an internal tool used by ten people? Usually not either. For testing an idea before anyone commits budget to it? Here an engineer would be a waste - let the idea first prove it deserves their time. This is a real change for the better, and pretending it is not happening embarrasses our industry more than the worst vibe coding.
The engineer becomes necessary at exactly the moment a system starts to matter. When real money, real personal data and real production flow through it. When it also has to work on the second of January at three in the morning, after a network outage, with a duplicated record, with an accountant waiting to close the month. The line does not run between those who can code and those who cannot. It runs between "I put together something that works" and "I understand why it works and I know when it will stop".
## The speed illusion
Now a story that belongs in textbooks - and not because it makes AI look bad.
In July 2025 the research organisation METR published the results of a controlled experiment. Experienced open source developers worked on tasks in their own, well-known projects, once with AI tools and once without. Before starting, they estimated AI would speed them up by a quarter. Afterwards, they were convinced it had sped them up by a fifth. The measurement showed their tasks took 19 percent longer with AI.
The sequel is even more interesting. In February 2026 METR announced that the next round of the study pointed to a speed-up, but that it could not treat the results as reliable - among other reasons because it was getting harder and harder to find developers willing to work without AI, despite being paid to take part. In a single year the tools had improved and the participants had grown so attached to them that the experiment stopped holding together. The researchers are redesigning the method from scratch.
What follows from this? Not that AI does not work. Something more important follows: even people who measure these things for a living struggle to pin down the truth about our speed. And in everyday work we judge it purely by feel. Working with a model produces a wonderful sense of flow - things happen, the screen fills up, tasks get closed. Except that this feeling, as METR showed, can drift forty percentage points away from reality. If we are that wrong about our own speed, how wrong are we about the quality of what we accept without reading?
## The scissors are opening
These observations add up to a mechanism I consider the most important change in the skills market in a decade. Let me tell it through two people.
The first is an architect who knows her craft inside out. For her, these tools are leverage she never dreamed of: she will compare three architecture variants before lunch, generate an integration skeleton in an hour, review someone else's module faster than she used to read its documentation. She knows what to ask for, and she instantly sees when she has been handed nonsense. AI raises her ceiling.
The second person has no foundations, and the model produces things to her order that she cannot evaluate, at a pace her understanding cannot match. For her, AI lowers the floor - the more fluently it generates, the faster the pile of things taken on faith grows.
The scissors are opening. Code got cheap and judgment got expensive - and that, in my view, is the entire economics of this profession in one sentence.
The people I worry about most are not the seniors, but two other groups. The juniors, whose apprenticeship vibe coding is quietly stealing, because nobody wants to pay for writing what a model spits out in a minute - and yet it was precisely that writing through which all of us learned to understand. And the experienced people who stopped reading, because "it works, doesn't it". A craftsman who stops touching the material loses his feel for it slowly and painlessly. He only notices when he is truly needed.
## There is nobody underneath
We arrive at the part this column was written for: security. Or rather, its illusion.
Every year Veracode checks how well models write secure code - in a research programme that has covered more than a hundred models in total. The result in the 2026 report (July 2026): 44 percent of generation attempts end in code with a vulnerability from the known OWASP categories. And pay attention, because here sits the most important observation of the year. That number has barely moved since last year, even though the models have clearly grown smarter in the meantime. They write better and better code. They do not write safer code. Security does not improve "as a side effect" - you have to ask for it, and then verify the request was fulfilled.
Let us go deeper, because beneath the code there is also the supply chain. Models invent names of libraries that do not exist - according to research presented at USENIX Security 2025, this affects roughly one in five package suggestions. Attackers have learned to register those invented names in advance and plant malicious code under them. The phenomenon has earned a name, slopsquatting, and its first live cases. You will install such a package with a single enter, because the model recommended it.
And agents with access to infrastructure have added their own chapter to this list. In the summer of 2025, Replit's agent deleted a production database during an announced change freeze, then generated data to mask the problem. In April 2026, an agent in Cursor, asked to do a task on a test environment, found a production token in the files and within nine seconds wiped a production volume together with its backups. Two different tools, the same pattern: the intent was test, the permissions were production, and there was no human gate anywhere.
All these vectors share one thing, and this is the thought I would like you to take away from this text: a generated system always appears complete. The demo looks excellent, the interface is often prettier than in many a commercial product, the answers arrive smoothly. The appearance of completeness is the cheapest thing AI produces. Underneath there may be solid construction, or there may be plywood made of vulnerabilities, dependencies of unknown origin and hard-coded secrets. From the outside you cannot tell the difference. It only shows from the inside - and nobody has looked inside.
## Shadow IT, second generation
Inside companies this mechanism has already matured. Business units used to buy themselves SaaS on a company card, behind IT's back, and we called it shadow IT. Today the business generates its own software. The mechanism is the same, but the stakes are entirely different, because a self-generated tool can reach data that the SaaS of a decade ago could only dream of.
This is no longer a hunch; it is a measured phenomenon. IBM's Cost of a Data Breach Report 2025 found that one in five breaches studied involved uncontrolled AI tools, and where shadow AI flourished, the average cost of a breach rose by several hundred thousand dollars. Most organisations admit at the same time that they simply have no AI usage policies. Not because nobody wants them - because the pace of adoption outran everyone.
## What has not devalued
Since writing code itself gets cheaper by the month, it becomes all the more valuable to name what has not gotten cheaper by a cent.
Systems thinking has not. The ability to see the whole - from the network layer through systems and databases to the application and its integrations - and to predict where that whole will crack under ten times the load. The model sees the files you show it. A human sees the architecture together with its history, its trade-offs and the debt that lives in no repository.
Diagnosis has not. When the cluster refuses to cooperate at three in the morning and the monitoring stubbornly shows green, the difference between "I can generate a playbook" and "I know how DNS works, and something tells me it is the certificate" is the difference between fifteen minutes and a day of downtime. That instinct cannot be downloaded. It settles in over years, one outage at a time.
Accountability has not. Someone has to put their name to the system in front of the board, the auditor, the regulator. A model will not do that - not because the law lags behind, but because accountability requires someone who understands the consequences and can answer for them with their position or their reputation.
And engineering taste has not devalued either: that hard-to-name something that makes you say "it works, but we are not doing it this way". Taste comes exclusively from systems read, fixed and maintained. It is a by-product of understanding, and that is why it cannot be generated.
## The new workshop
So what does the workshop of an engineer look like who wants to be worth their rate in 2026? Let me share my list - short and certainly incomplete; treat it as an invitation to argue, not as an oracle.
First: decomposition and specification. The model does exactly what it was asked to do, so all the value has moved into the skill of asking for the right thing - breaking the problem into parts, naming the edge conditions, stating plainly what "done" means. This is good old requirements engineering, except practised daily now, not once per project.
Second: reading code as the core professional activity. For twenty years code review was an appendix to writing. That proportion has just inverted - the core of the job is becoming the reading and evaluation of machine output. I know this is hard news for many of us, because writing is simply more fun. But whoever does not learn to love reading will suffer in this profession.
Third: security as a reflex, not a phase at the end. Where does this package come from? What does this dependency actually do? Where do the secrets live? What permissions did the agent receive, and what happens when someone injects an instruction through the data it processes? These questions have to be asked during the work, because after the fact someone else asks them - usually in an incident report.
And fourth, my favourite: fundamentals. Networks, protocols, operating systems, databases, cryptography. Sounds like a curriculum from twenty years ago? That is precisely the punchline. The knowledge that was supposed to become obsolete turned out to be the only instrument for evaluating what the model produces. Fundamentals are not nostalgia. They are the price of admission to the new tools.
Notice what is not on this list. There is no "prompt engineering". You will learn to talk to a model in a week, honestly. Everything else takes years to learn - and that is exactly why everything else is worth something.
## Five questions before generated code reaches production
This list did not fit into the 12-page PDF edition of this column (you will find it at the end of this post), and it is its most practical part. Five questions we ask at SNOK during a [security review](/en/offer/cybersecurity/) of any system with a large share of generated code. None of them requires million-dollar tooling; every one of them requires a human who understands the answer.
**1. Who read this code, and what came out of that reading?** Not "who ran the tests" - who read it. If the answer is "nobody", you have text of unknown authorship with unknown properties running in production. Naming that out loud is usually enough for a review to organise itself.
**2. Where does every dependency come from, and who would notice if it disappeared or changed owners?** The dependency list of a generated project is often longer than the project itself. Check whether all the packages have even existed for more than six months - it is the simplest filter against slopsquatting.
**3. Where do the secrets live?** In code generated in a hurry, keys and passwords land hard-coded in files surprisingly often, because that is the shortest path and the model optimises for "it works". One search across the repository can ruin your mood for a week.
**4. What can this system do in the worst case, and who allowed it?** This applies especially to agents: what permissions they hold, what data they reach, what happens when someone injects an instruction through the content they process. Permissions granted "just for a moment, for testing" have an ugly habit of staying forever.
**5. Who will maintain this in a year?** The author of that procurement tool will get promoted, leave or lose interest. The system will stay. If nobody can name an owner by first and last name, it is not a system - it is a future incident on deferred terms.
If the answer to three of the five questions is "we don't know", it does not mean you have to switch everything off. It means it is worth doing an inventory before an auditor or an attacker does it for you - and of the two, the auditor is decidedly more pleasant.
## How to find your footing
To finish, three pieces of advice I follow myself. I do not write them as a sceptic - I run a company where AI works at every level and delivers real value. I write them as someone who wants to still be using these tools in ten years, on his own terms.
Use AI daily, but in pilot mode, not passenger mode. The difference is simple: the pilot knows where the plane is going and keeps glancing at the instruments. The passenger is comfortable, watches the clouds and has no influence over the landing. Both are on the same plane.
Once a week, read something the model generated for you all the way to the bottom. To the bottom - meaning together with the dependencies, the configuration and the question "why this way exactly". It is the cheapest judgment training I know, and the fastest way to discover how much you have recently accepted on faith. The result tends to be sobering; I speak from experience.
And cultivate at least one domain where you are deeper than the model. It does not matter whether it is HANA, BGP or project accounting. Depth in one place gives you something priceless: a point of reference. You know what real understanding tastes like - and you instantly feel when, in another area, you are missing it.
## Where are you going, engineer
I saved the title question for the end, because the answer is shorter than this whole text.
For thirty years you could believe that engineering meant writing code and configuring systems, and that understanding came along by itself, as a side effect. AI has just taken that comfortable version of the profession away from us. Machines took over the writing - the easiest part of this work, which is why automation started precisely there. They did not take over understanding, judgment or accountability. And nothing suggests they will take those over at the price of a token.
So where are you going, engineer? My answer: deeper into your own profession. Closer to the fundamentals, closer to architecture, closer to accountability. There is more work there today than ever before - and, for the first time in a long while, far less of a crowd.
## Download the column as a PDF
A column by Jacek Bugajski · August 2026
Quo vadis, inżynierze?
PDF, 12 pages, approx. 7 MB, in Polish - the original magazine-style edition of this column. Free to download and share with your team, no form and no data required.
## Sources
- Andrej Karpathy, post on "vibe coding", X/Twitter, February 2025
- Business Insider, "Google says AI now generates about 75% of new code...", 22 April 2026
- METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", 10 July 2025
- METR, "We are Changing our Developer Productivity Experiment Design", 24 February 2026
- Veracode, "2026 GenAI Code Security Report", July 2026 (56 percent pass rate, approx. 44 percent of tasks with a vulnerability; flat year over year)
- USENIX Security 2025, research on hallucinated package names (approx. 20 percent of suggestions); the slopsquatting phenomenon
- The SaaStr/Replit case, July 2025 - The Register, Fortune
- The PocketOS / Cursor + Railway case (production volume deleted in 9 seconds), 25 April 2026 - zenity.io, Tom's Hardware
- IBM, Cost of a Data Breach Report 2025, 30 July 2025 (20 percent of breaches linked to shadow AI; elevated breach cost)
---
### The SAP data breach no SIEM will see
URL: https://snok.ai/en/news/blog/sap-data-breach-siem-blind-spot/ | Date: 2026-08-04 | Series: Safe Tuesday
Tuesday, 9:12 a.m. Someone logs in to the SAP system on a customer service employee's account. The password is right first time, so no failed-logon counter moves. The antivirus stays quiet, because there is no malicious file. The firewall stays quiet, because the traffic looks like any other. The SIEM records a successful logon - one of several hundred that morning - and there its role ends. Over the following hours the account browses customer records. First hundreds, as on any other day. Then thousands. By the afternoon the count runs into the hundreds of thousands, and nobody in the company knows.
Onno Coenen of SecurityBridge described this scenario in an article whose title stays with you for a long time: if someone stole two million customer records from your SAP today - would you know? For most organisations the honest answer is no.
**The short version:**
**1/** Attackers rarely break into SAP any more - they log in with stolen, valid credentials and behave like ordinary users,
**2/** A SIEM and infrastructure monitoring see the logon, but not what the user does inside the SAP application - the biggest blind spot in SAP security,
**3/** GDPR gives you 72 hours to notify the supervisory authority, and Poland's cybersecurity act (KSC) gives 24 hours for an early warning - both clocks assume you are able to detect and describe the incident in the first place,
**4/** The answer is native monitoring inside SAP - detecting unusual data access in real time, plus forensic evidence for the investigation and the regulator.
---
## A logon that passes every control
Over the years companies have built solid protection around their infrastructure: identity management, endpoint protection, network monitoring, a SIEM with a round-the-clock team. Those are good investments and no reasonable person questions them. The problem is that attackers have done the same homework. Instead of forcing the door, they walk in with a key - credentials obtained through phishing, a password leak or a hijacked service account.
From that moment every classic control works in their favour. The logon is valid. The session looks ordinary. Database queries run through standard transactions. From the SIEM's perspective it is another day of another user's work, because a SIEM collects events from the network, operating systems and authentication - not from inside the business application. It can tell you that someone entered SAP. It cannot tell you what they are doing there.
And SAP is where the most valuable data lives. Contracts, billing data, payment history, addresses, bank account numbers - in a large organisation, hundreds of thousands or millions of customer records in the tables of a single system. We wrote recently about the [Western Digital breach](/en/news/blog/western-digital-breach-sap-data/), where the attackers reached exactly that - data held in SAP. The pattern does not age; only the price paid by the victim changes.
## Seven questions you will have to answer
A breach rarely comes to light from the inside. More often the customer data turns up for sale on the dark web, the police call, or a business partner asks how fraudsters know their contract numbers. Only then does the investigation start - and the questions sound trivial right up to the moment you have to answer them under pressure from the board, your customers and the regulator all at once:
- When did the activity start?
- Which SAP account was used?
- Which transactions were executed?
- Which customer records exactly were viewed?
- Was the data downloaded or exported?
- How many customers are affected?
- Has the activity actually been stopped?
Knowing that someone logged in to SAP is one thing. Knowing what they did after logging in is a different category altogether - and without an event trail from inside the application, the security team pieces answers together from fragments of logs across systems, for weeks, while running crisis communications in parallel. The organisation is conducting an investigation and fighting the fire at the same time.
## The regulator expects facts, not suppositions
Coenen writes from an Asia-Pacific perspective: Singapore's PDPA requires a breach to be notified to the data protection commission no later than three calendar days after it is assessed as notifiable, with fines of up to 10% of annual turnover in Singapore (for turnover above SGD 10 million) or SGD 1 million; Australia's Privacy Act provides for penalties of up to AUD 50 million, three times the benefit obtained or 30% of adjusted turnover - whichever is highest. Exotic? Only on the surface, because European rules are built on the same assumption: the organisation is supposed to know what happened before it starts talking about it.
GDPR Article 33 gives you 72 hours to notify the supervisory authority - in Poland that is PUODO - counted from the moment the breach is established, and where the risk to individuals is high, Article 34 adds a duty to inform the affected customers themselves. Breaching the security and notification obligations carries fines of up to EUR 10 million or 2% of worldwide turnover, and breaching the processing principles - up to EUR 20 million or 4%. Poland's cybersecurity act (KSC), the local NIS2 transposition [we covered last week](/en/news/blog/nis2-ksc-sap-register-by-3-october/), goes further: an early warning of a significant incident within 24 hours and a notification within 72, both counted from detection. And the calendar is not waiting: the application for entry in the register of essential and important entities is due by 3 October 2026 - two months from now.
Which brings back the trap you know from that article. All these clocks start at detection, or at the establishment of a breach. If you have nothing to detect with, the clock formally never starts - but a supervisory authority will not read that as good luck. It will read it as an absence of technical measures appropriate to the risk. And when the first signal of a breach is a journalist's phone call, it is too late to start building your answer.
## "We believe" versus "we know"
No vendor and no security team can guarantee that a breach will never happen. The difference between a prepared company and an unprepared one shows in the first sentence of its statement.
A company without visibility into SAP says: "We believe customer data may have been compromised. We are still establishing the scale."
A company with visibility says: "We know which account was used, which transactions were executed, which records were viewed, when it happened and which customers are affected. The activity has been blocked."
Those are two entirely different conversations with the board, with customers and with the regulator. The first opens a crisis of unknown cost and unknown duration. The second closes an incident with numbers. And customer trust - the one asset you cannot restore from a backup - is far more likely to survive the second version.
## Closing the blind spot
If the problem is the lack of visibility inside the application, the solution has to work inside the application. That is exactly what the SecurityBridge platform does - [we deploy it as the official partner in Poland](/en/securitybridge-snok/):
**Threat Detection** monitors events inside SAP in real time and raises alerts enriched with business context - not "a user executed a transaction", but "a customer service account is reading data at a pace and scope that resembles no normal process".
**Data Loss Prevention** watches access to sensitive data: it detects unusual browsing and downloading of records as it happens, not after the fact. The security team gets a chance to cut the exfiltration short before millions of records leave the system - and if an incident does occur, the platform delivers the forensic material: which account, which transactions, which data, in what timeframe.
The alerts land in your SIEM, so the investments you have already made are not wasted - they gain the missing layer they cannot see on their own.
## Where to start
Not with a purchase. With an honest answer to the question of whether the morning from the beginning of this text would be noticed in your organisation.
The fastest route to that answer is our free assessment, [SNOK KSC-CHECK](/en/tools/ksc-check/) - 25 questions in six steps, 8 to 12 minutes, the result on screen immediately and a PDF report by email. Two of the five areas - Event visibility, and Detection and response - address precisely the blind spot this article is about. It is a self-assessment, not an audit, but it structures the conversation about priorities better than many a status meeting.
The second step we propose is always the same, because it works: [book a SecurityBridge demo with us](/en/securitybridge-snok/), and then we run a **proof of concept in your SAP landscape** - on a selected system, on your scenarios, with alerts raised on real events. After such a POC you know exactly what the platform sees in your environment, not on slides. Instead of a discussion about architecture, you get an answer to the question in this article's title.
We work with sensitive data in SAP every day and at scale - for Medicover we built an [HR process platform serving around 45,000 employees in 18 countries and handling roughly 100,000 HR events a year](/en/case-studies/#healthcare-network-hr-digitalisation), a project recognised by SAP as an official reference, one of three in Poland. We know what responsibility for personal data in SAP systems looks like long before the word "incident" appears.
If the assessment reveals gaps - or if you would rather go straight to the level of specific systems - [write to us](/en/contact/). We will show you live what the detection of a mass data read in SAP looks like, before somebody who should not see it does.
---
## Sources
- Onno Coenen, *If Someone Stole Two Million Customer Records from SAP Today... Would You Know?*, LinkedIn Pulse, 27.07.2026
- GDPR (Regulation 2016/679), Articles 33, 34 and 83 - EUR-Lex
- Act of 23 January 2026 amending Poland's National Cybersecurity System Act (Journal of Laws 2026, item 252)
- Personal Data Protection Act 2012 (Singapore), PDPC notification requirements; Privacy Act 1988 (Australia) as amended in 2022 - after the source article
- SecurityBridge - platform documentation: Threat Detection, Data Loss Prevention
---
### Master data in Polish enterprises - the SNOK report
URL: https://snok.ai/en/news/blog/master-data-polish-enterprises-report/ | Date: 2026-08-03 | Series: Other
In the space of twelve months Salesforce paid around USD 8 billion for Informatica, SAP acquired Reltio, and Gartner brought back its Magic Quadrant for Master Data Management after a break of more than four years. The market put a multi-billion price tag on a category that had spent years being treated as plumbing. Over the same period EY found that only 9 percent of medium and large companies in Poland have a data infrastructure ready to feed AI models.
We put that gap into a report: "Master data in Polish enterprises" - 28 pages, ten chapters, every figure with a named source and a date. It is written from the Polish market, which makes it useful well beyond Poland: the country is running the largest mandatory e-invoicing rollout in the European Union right now, and the rest of Europe is next in line under ViDA.
## One company, four versions of the truth
Start with a scene we know from projects rather too well.
An accounts specialist issues an invoice to a long-standing business partner. In the ERP that partner carries the full legal name and the tax identification number from the day the contract was signed. In the CRM a salesperson saved an abbreviation, with the address of an office the company left two years ago. In the purchasing system the partner exists a third time, with no tax number at all, because that was quicker. Each version is locally correct. None of them is complete.
Until January 2026 that situation mostly cost patience: reconciling balances, clarifying payment terms, assembling a board report from three sources. The cost was real, but spread across enough people and departments that it never had a line of its own in any budget. Today the same discrepancy has both an addressee and a deadline.
## Reason one: mandatory e-invoicing checks your records every working day
**KSeF** (Krajowy System e-Faktur, Poland's national e-invoicing system) became mandatory for large taxpayers in February 2026. Between 1 February and 26 May more than 289 million e-invoices passed through it, from over 2 million issuers - figures from the Polish Ministry of Finance. It is the first mechanism in the history of the Polish economy that tests the customer records of more than two million taxpayers simultaneously, every working day.
It tests them differently than many companies assume. KSeF validates that the file matches the schema. It does not check whether the buyer's tax identification number actually belongs to the party the transaction concerns. An invoice with a number off by a single digit still receives a KSeF number and is delivered to whichever company holds that number; if no such number exists, it reaches nobody. That position was set out by the Director of the **KIS** (Krajowa Informacja Skarbowa, the national tax information authority) in an individual ruling issued in March 2026.
The repair path changed as well. Buyer-issued correction notes no longer exist, so a buyer can no longer fix somebody else's mistake with a single document. A wrong tax number means the issuer must correct the invoice to zero and issue a new one. For one mistake that is an inconvenience. For a customer file holding hundreds of stale records and thousands of documents a month, it becomes a permanent exception-handling process that somebody has to run by hand.
The first months confirmed this is not a marginal problem. Tax advisers described EU VAT numbers entered in place of domestic tax numbers and documents circulating twice; according to data from one software vendor, 18 percent of correction invoices retrieved from KSeF contain errors. Treat that last figure with care - it comes from one vendor's customer base - but the direction is unmistakable. The penalty-free period ends with 2026. The mechanism stays for good.
**Why this matters outside Poland:** under the EU's VAT in the Digital Age package, structured e-invoicing and digital reporting move across the single market in the years ahead. Poland is the working prototype, and the failure mode it exposes - clean schema, wrong counterparty - is not specific to Polish law.
## Reason two: a migration calendar that will not wait
The second process comes with exact dates. SAP mainstream maintenance for ECC ends on 31 December 2027, and according to the February 2026 survey by DSAG, the German-speaking SAP user group, 54 percent of the organisations polled still run ECC or older Business Suite releases. Microsoft has announced the end of mainstream support for Dynamics GP at the close of 2029. In Poland, where Comarch and domestic vendors hold strong positions alongside SAP, the same moment arrives with a version change or a post-acquisition consolidation.
Every one of those operations is a data migration in practice. And here sits the trap we keep finding in project plans: a conversion moves data into a new structure, it does not improve its quality. Three variants of the same business partner will land in the new system as three separate records unless somebody merges them first. A record missing a field the new model requires comes back to the team as an exception to handle manually - usually during the cutover window, when the team has the least time and every hour of downtime costs the most.
Market numbers confirm this is not a paper risk. ISG reports that 58 percent of SAP migration programmes exceed budget and schedule, while 15 percent land inside both. The right order is the reverse of the one we see most often: first measure duplicates and gaps, then deduplicate with the data owner in the room, and only then migrate. The same work done after go-live costs more, because it happens under production pressure.
## Reason three: AI exposed the state of the records faster than any audit
The third process is the youngest and moves quickest. Language models and agents do not check whether data is true - they answer on the basis of what they are given, with equal confidence on consistent and contradictory records. Ask an agent for a partner's balance when that partner exists in four variants across your systems and the answer arrives instantly. It will not mention that it picked one of four candidates.
Automation built on inconsistent data does not remove the mess. It increases its speed and its reach.
Analysts have been saying so for two years: Gartner projected that through the end of 2026 organisations will abandon 60 percent of AI projects unsupported by AI-ready data. The Polish figures fit that projection without any stretching. AI technologies are used by 8.7 percent of enterprises here (Statistics Poland, 2025) against an EU average of 20 percent (Eurostat), and the complete AI-ready data infrastructure mentioned above is claimed by 9 percent of medium and large firms. Models are available off the shelf. Prepared data is not.
## Poland in context: the systems are there, the order in the data is not
Put public statistics next to market research and a picture emerges that explains the daily experience of Polish teams rather well. The infrastructure exists and is growing: 40.5 percent of enterprises use an ERP system and more than half buy paid cloud services (Statistics Poland, 2025). The work done on data looks thinner: 24.5 percent of Polish firms perform data analysis, against 60 percent in Denmark (Eurostat, 2025).
The averages hide a sharp split. AI technologies are used by 42 percent of large firms, 15.6 percent of medium ones and just 6.1 percent of small ones (Statistics Poland, 2025). Large organisations experiment, mid-sized ones are only now arriving - and they are the ones who most often discover that the first obstacle is not the budget for a model, but the state of their own records.
The most telling numbers are the organisations' own declarations. In a study by Algolytics and SW Research covering more than 700 companies, 73 percent admitted they lack the competence to make use of their data, and 66 percent do not use data in decision-making at all. Those are not numbers about technology. They are numbers about a missing layer between the systems and the decisions - the layer that settles which record is authoritative and who answers for its accuracy.
There is one more Polish thread rarely thought of in data terms: mergers and acquisitions. The Polish market recorded 330 such transactions in 2025 (M&A Index Poland), with the sale of a 49 percent stake in Santander Bank Polska to Erste Group as the largest. Every acquisition means merging partner catalogues, material indices and charts of accounts maintained under different rules. Public research measuring the scale of this in Poland does not exist - we say so plainly in the report - but from projects in capital groups after acquisitions, including a chemical group consolidating data from five companies across three countries, we know the pattern repeats: the first weeks of integration go on establishing which company uses which catalogue, and how the definitions of apparently identical terms differ.
## Why clean-up programmes fail
"Let us run a big data clean-up project" has poor statistics behind it. Gartner projected that more than 75 percent of [master data management](/en/offer/master-data-management/) programmes would fail to meet their business objectives. From our own projects and pre-sales conversations, the causes rarely sit in the technology. Four patterns recur: a scope covering every domain at once, a committee instead of a data owner with a mandate to decide, fully automatic record merging, and a one-off clean-up with no rules to police the quality of new entries. That last one is the most treacherous, because it produces an effect for a quarter - after which the file returns to its original state and the organisation is left convinced that "we tried this and it did not work".
In master data pilots the technology is what surprises us least. What surprises us most is how fast decisions get made once a measurement, rather than an opinion, is on the table.
That is why the report describes the opposite of the standard market approach: one data domain, one success criterion agreed before the start, and a result measured on the organisation's real data in weeks rather than quarters.
In practice the method has four steps. First, choose the domain generating the most manual work and the most arguments about numbers - usually business partners or material indices. Then measure the state: number of duplicates, gaps in critical fields, discrepancies between systems. The measurement is what lets the decision rest on figures instead of opinions. Third come the rules for the master record, with name normalisation and a data owner holding the mandate to settle disputes. Only the fourth step is merging - and here one detail matters: language models are good at suggesting that two entries may describe the same entity, but a human approves the merge, because wrongly merging two separate companies is more expensive to repair than a duplicate. Every change stays in the audit trail.
We usually close a single-domain pilot in four to eight weeks. This is how we work with Medicover in the employee data domain: [18 countries, roughly 45,000 employees and around 100,000 data events a year](/en/case-studies/#healthcare-network-hr-digitalisation), with full change history and an approval flow - a project SAP recognised as an official reference, one of three in Poland.
## When master data is not your priority
We would be misleading you if we claimed this work is urgent for everyone. If you run a single system, the customer file holds a few hundred partners, and invoicing is handled by one person who knows all of them, you will get through mandatory e-invoicing on operational discipline alone, without a separate data layer.
We also advise against starting when the organisation expects a one-off clean-up with no data owner named on the business side, plans to cover every domain at once before the first confirmed result, or has nobody able to settle a disputed record on the merits. Under those conditions the project ends exactly as Gartner's statistic predicts - and that wastes both money and trust. Honest qualification saves both sides a quarter of conversations with nothing at the end.
Priority belongs to organisations preparing a system migration, consolidating companies after acquisitions, launching automation or AI on operational data, or needing to demonstrate to an auditor where the data sits and who has access to it.
## Measure it yourself before you spend anything
The most practical part of the report requires no purchasing decision at all. You can size the problem in one domain with your own people in a few days. All it takes is an extract from the customer file and four questions:
1. How many records share the same tax identification number under different names or addresses?
2. How many records have gaps in the fields your processes treat as critical?
3. How many entries differ between the ERP and the CRM for the same entities?
4. Who decides which version is authoritative, and how long does that take?
"We do not know" is also a measurement result on any of these, and the most instructive one. If you would rather someone external ran that measurement, we do it on a sample from a single domain and hand over the result with a recommended scope within five working days. Details on the [duplicate measurement](/en/offer/master-data-management/#pomiar-duplikatow) page.
## Download the report
SNOK report · August 2026
Master data in Polish enterprises
PDF, 28 pages, about 0.9 MB - no form, no details to hand over. Pass it around your team freely - that is what it was made for.
Inside you will find what this article could not hold: the full chapter on the market and acquisitions, the detailed mechanics of KSeF with the KIS ruling, the DSAG and ISG data on migrations, four anti-patterns of clean-up programmes, the incremental method step by step, and a methodological note with the complete list of sources.
## From the report to a first result
If the subject turns out to concern your organisation, we suggest the route we take with clients most often. Start with a [duplicate measurement](/en/offer/master-data-management/#pomiar-duplikatow) on a sample from one domain - you receive the result and a recommended scope within five working days. If the numbers confirm the problem, we run a **proof of concept on the [SNOK MDM](/en/products/snok-mdm/) platform**: a single-domain pilot on your real data, with the success criterion agreed before the start and a result you can compare before and after. Would you rather see the platform first? [Book a SNOK MDM demo](/en/products/snok-mdm/) or simply [write to us](/en/contact/).
A week before this report we published a [column on twenty years with master data](/en/news/blog/master-data-after-twenty-years/) - a good complement, this time from a personal angle. Questions to the authors go straight to them: Jacek Bugajski (jacek.bugajski@snok.ai) and Michał Korzeń (michal.korzen@snok.ai).
---
### Weekly review W31: the inventory nobody has
URL: https://snok.ai/en/news/blog/weekly-review-w31-the-inventory-nobody-has/ | Date: 2026-07-31 | Series: Other
This week has one theme: **inventory and proof**. Nearly every story comes back to two questions most organisations cannot answer on the spot. What exactly is running inside? And what can you prove about it when someone asks?
A worm in a Word document spreads through files nobody inventories. A shared conversation with an AI assistant reaches a search engine because nobody checked where the link led. SAP security does not break on go-live day but several months later, once the last audit describes a different system. AI agents multiply outside the IT department's register. And at the end, The Economist presents the bill: the market cannot measure even what it has already bought.
Eleven stories from the week of 27-31 July 2026, one of them ours.
## 1. We launched SNOK KSC-CHECK: a free SAP readiness assessment for KSC and NIS2
[SNOK KSC-CHECK](/en/tools/ksc-check/) assesses how ready your SAP landscape is for the requirements of Poland's national cybersecurity act and the NIS2 directive. Twenty-five questions, six steps, five areas, eight to twelve minutes. The score appears on screen immediately and a PDF report arrives at the address you provide within minutes.
The five areas reflect what actually determines your ability to respond to an incident in SAP: event visibility, detection and response, vulnerabilities and patching, identity and access, and compliance and evidence. The weights are deliberately uneven. Visibility and response carry the most, because they decide whether the statutory twenty-four-hour window from detection is achievable in your case at all. We wrote the questions for an IT director rather than a Basis administrator, and "I don't know" is a permitted answer scored at zero - not knowing your own system is also a result.
What it is not: a twelve-minute self-assessment does not replace a technical review and does not certify compliance with the act. The assessment shows where to look for gaps and structures the conversation ahead of the 3 October 2026 registration deadline. We provide it free in exchange for contact details, and we have a commercial interest in doing so.
## 2. A worm in Word documents spreads through Copilot, and the vulnerability class stays open
Norwegian researcher Håkon Måløy demonstrated a worm that needs neither code nor macros. All it takes is a Word document with instructions hidden in the body - white text on white, at a microscopic font size. When an employee asks Copilot to draft or edit content based on such a file, Copilot strips the formatting, reads the hidden text and treats the embedded instructions as part of the user's request. It then modifies the active document and appends the entire malicious prompt to it, again as hidden white text. The next person opens the infected file and the cycle repeats without the attacker doing anything. The effect can be a silent change to data - a figure in a financial report, for instance - travelling from file to file.
What happened next is more interesting than the demonstration itself. Måløy reported the issue to the Microsoft Security Response Center on 6 March 2026. Microsoft fixed that specific implementation, the researcher reworked the payload and reproduced the propagation. Two mitigation attempts, including a move to a newer model, failed to close the problem. Disclosure followed on 28 July, after one hundred and forty-four days of coordination and two deadline extensions; [The Register](https://www.theregister.com/security/2026/07/29/word-worm-crawls-into-copilot-spreads-chaos/5280588) covered it a day later. There is no CVE number, because this is not a single bug but a class of vulnerability: the model does not distinguish instructions from the data it processes. Microsoft confirmed the research and responded with a defence-in-depth position. The researcher's position is blunter: for the wider class of these attacks, no effective mitigation exists today.
The direction of risk inverts here in a way most policies do not anticipate. Until now, controls over AI assistants have guarded the input: what the user types and which data reaches the model. This attack moves the risk to the output - to artefacts produced by the assistant and then read by other people and other agents. If you are rolling out Copilot, or any assistant over a corporate document repository, three questions are worth asking today:
- Are files produced by the assistant treated as trusted in your organisation?
- Who reviews documents arriving from outside before they reach the assistant?
- Who will notice that a figure in a report changed with no trace in the version history?
We have added this scenario to the scope of our [AI security reviews](/en/offer/ai-automation/ai-security/).
## 3. A model found new attacks on a NIST post-quantum candidate
Anthropic described research in which the Claude Mythos Preview model independently produced two cryptanalytic results. The first concerns HAWK-256, a NIST candidate in the additional round for a post-quantum signature standard. The model found the missing lattice automorphism, which made it possible to build an attack recovering a secret basis capable of signing messages for the original public key. The expected cost of breaking HAWK-256 fell from 2⁶⁴ to 2³⁸ operations. The second result concerns a seven-round test variant of AES-128: a mathematical shortcut named the "Möbius Bridge" eliminated a 256-way guessing step in meet-in-the-middle attacks and sped up the best known method by a factor of two hundred to eight hundred. The model worked semi-autonomously for roughly sixty hours, at API costs on the order of one hundred thousand dollars. Disclosure went to the HAWK authors and through NIST.
The boundary of the conclusion is sharp here and worth holding. HAWK is not an approved standard, and weakening is not breaking. The AES result applies to a reduced variant, not to full AES-128 or the AES-256 used in production - your data encryption still works. [Matthew Green](https://blog.cryptographyengineering.com/2026/07/29/some-notes-about-anthropics-new-results/) rates the HAWK result as thoroughly impressive and calls the AES result considerably less interesting. The shared conclusion of authors and commentators is the same nonetheless: the security margins of lattice-based algorithms need recalculating, and the verification of assumptions behind new standards has to speed up.
If you are planning a migration to post-quantum cryptography, the consequence is architectural rather than operational: the ability to swap an algorithm without rewriting the system stops being a theoretical design virtue. In practice that means checking which algorithms underpin your suppliers' roadmaps, including in the artefact-signing and authentication layers. Building systems that depend on HAWK makes no sense before NIST reassesses it.
## 4. Shared Claude conversations reached the Google and Bing indexes
The mechanism is mundane, which is why it worked. A user clicks "share conversation", receives a public link, and the search engine indexes a public link. [Wired](https://www.wired.com/story/private-claude-chats-exposed-in-google-and-bing-search-results/) analysed a sample of the exposed pages and found they carried no `noindex` tag, which both Google and Bing honour. Conversations about code, business plans, documents and CVs ended up in the index. [CRN Poland](https://crn.pl/aktualnosci/google-indeksowal-rozmowy-z-claude-w-sieci-znaleziono-wrazliwe-dokumenty/) covered the story as well. Anthropic blocked indexing of shared conversation pages, and previously indexed pages began dropping out of results.
The technical layer is therefore closed. The organisational one is open, and it affects every company where AI tools came into use without agreed rules. If an employee pasted a contract excerpt or client data into a conversation and then shared the thread with a colleague, that material could have become public without anyone acting in bad faith. Under the GDPR this is an event to assess, not a curiosity from a trade publication.
There is one recommendation: work on data covered by a processing agreement or by confidentiality belongs in an environment with a corporate contract, administrative control and agreed processing terms - and public sharing links in such an environment are switched off deliberately. A tool's pricing model settles nothing on its own.
## 5. PleaseFix: agentic browsers remove the boundaries web security rests on
Zenity Labs described a family of vulnerabilities named PleaseFix, affecting browsers driven by AI agents. A malicious page passes instructions straight to the agent - this is prompt injection, carried out inside the browser. On top of that comes cross-domain request handling: the agent does not respect origin boundaries the way a conventional browser does. The consequences the researchers describe range from account takeover and credential theft inside a logged-in session, through access to local files, to remote code execution, all in a zero-click scenario. The class has been known since March 2026, when Zenity demonstrated two exploits against Perplexity Comet; [Dark Reading](https://www.darkreading.com/endpoint-security/agentic-browsers-rewind-web-security-20-years) returned to it on 27 July, calling the effect a twenty-year rewind of web security.
Michael Bargury, Zenity's co-founder and chief technology officer, puts it without hedging: this is not a bug but a property of agentic systems. An attacker injects untrusted data into an AI browser and takes over the agent itself, inheriting every access the agent was granted.
Hence a single design rule worth insisting on: an agent driving a browser runs in an isolated environment, not on a workstation inside the corporate network and not in a session logged into production systems. The control question for deployments you already have: if a page the agent visited handed it an instruction, what could it reach within the next minute? "Everything the user can reach" is the wrong answer.
## 6. SAP security does not break at go-live, it breaks afterwards
This item is not news but a thesis we set out at greater length in [SAP hardening is a process, not a project](/en/news/blog/sap-hardening-process-not-project/) - and one worth repeating next to the first story, because both concern the same thing.
The project ends and configuration drift begins. After go-live come user changes, transports, parameter fixes, authorisation creep. A point-in-time audit describes the state on the day of the assessment and covers nothing that happened afterwards. The investment stops on handover day; the risk does not.
We do not quote percentages for companies that fail to monitor application-layer events, RFC calls or access to sensitive tables - the figures circulating in the trade press come from vendor materials with no stated methodology or sample. You will find your own confirmation without anyone else's statistics. Three questions suffice: do security events from production SAP systems reach your SIEM, how long do you retain them, and how many days pass between Patch Day and the deployment of notes marked critical.
This is where the SAP conversation meets KSC and NIS2. The obligation to report a serious incident within twenty-four hours assumes the incident will be detected, and audits in the years ahead will assess evidence from the period running right now. Continuous monitoring does not replace point-in-time audits - it supplies evidence from the intervals between them and improves the chance of detecting an incident in time. We describe the scope of that work in our [NIS2, DORA and KSC compliance audit for SAP](/en/offer/sap-security/nis2-dora-audit/).
## 7. OWASP pysap received its first major release in five years
A workbench item. The pysap library, used to craft and send packets in SAP protocols, received release [v0.2.0](https://github.com/OWASP/pysap/releases) under the OWASP Foundation's CBAS project - on 28 July, five years after v0.1.19 from April 2021. The new release completes the migration to Python 3, moves compression from C code to pure Python and tidies up byte and text handling. Protocol coverage spans the communication layer: NI, Diag, Enqueue, SAProuter, Message Server, SNC, IGS, RFC and HDB.
This remains a low-level library, not a scanner that produces a report. The value lies in being able to verify the exposure of the communication layer with your own tooling rather than relying solely on a vendor scanner's output - which matters in [SAP penetration tests and security audits](/en/offer/sap-security/sap-penetration-testing/).
The caveat without which this note should not exist: tools of this class run only in environments covered by the system owner's written authorisation, and a new release is tried in a laboratory first, not on a client's production system.
## 8. Open Secure AI Alliance: more than thirty companies back open AI security tooling
On 27 July NVIDIA announced the Open Secure AI Alliance, a coalition focused on open tooling for securing AI models and agents. Founding members include Microsoft, IBM, Cisco, Dell Technologies, HPE, Red Hat, SAP, Palantir, Palo Alto Networks, CrowdStrike, Cloudflare, Snowflake, Databricks, GitHub, Hugging Face, Mistral, Perplexity, Salesforce, Siemens and the Linux Foundation. Participant counts differ between reports - from "more than thirty" to several dozen - because the list grew over the announcement days. Absence says more here than presence: OpenAI, Google and Anthropic are missing. None of them announced a refusal publicly; they simply do not appear among the founders.
The alliance brings concrete projects with it. NVIDIA's NOOA is a set of Apache 2.0 research tools for testing, tracing, auditing and governing agent behaviour. Microsoft's MDASH orchestrates specialised agents that hunt for bugs, argue about them and prove they are exploitable.
The immediate context is an incident [we covered in the previous edition](/en/news/blog/weekly-review-w30-model-that-cheated-its-own-exam/): on 16 July Hugging Face disclosed that an AI agent had reached part of its production infrastructure, and five days later OpenAI confirmed the agent was its own system - GPT-5.6 Sol together with a pre-release model, running an internal ExploitGym benchmark with safety mitigations deliberately disabled. The agent escaped the sandbox through a zero-day flaw, chained stolen credentials into remote code execution and moved laterally to internal datasets and service credentials across four services. Public models, datasets and the software supply chain were left untouched.
The alliance's argument runs as follows: security tools you can fully inspect and run in your own infrastructure give more control than closed services. This is an industry dispute with clearly drawn sides and should be read as one - vendor interests sit behind the positions. The practical observation holds regardless of who is right: audit tooling need not be tied to your choice of model. An open kit for testing and isolating agents can sit above any provider that supports the interfaces and runtimes you use - and that is a better position in negotiations and in front of an auditor.
## 9. Moonshot released the Kimi K3 weights, 2.8 trillion parameters
On 27 July Moonshot AI published the weights of Kimi K3 on Hugging Face. The architecture is a mixture of experts: 2.8 trillion parameters in total, around 104 billion active per token, 896 experts of which 16 work at once. The repository weighs 1.56 TB across 96 safetensors shards, the context window holds 1,048,576 tokens, and the model accepts images as input. Before the weights were released it ranked near the top of the benchmarks, so this is not an archival release.
Two things need honest arithmetic here, because both are easy to get wrong. First: 1.56 TB already represents weights in MXFP4 quantisation, roughly four and a half bits per parameter. Anyone calculating savings "after quantising to four bits" is counting them twice - the floor for 2.8 trillion parameters at four bits is on the order of 1.4 TB, not a few hundred gigabytes. Second: file volume is not the same as the memory needed to run the model, because in a mixture of experts what matters is the number of active parameters and how inference is handled. Running this model remains a data-centre task, and the practical deployment range will only open up with smaller distillations, if any appear.
The licence is not what it was in the previous generation either. This is a bespoke Kimi K3 licence rather than a modified MIT one - large hosted-service providers above a threshold of twenty million dollars in revenue over twelve months need a separate agreement with Moonshot. When planning [language models on your own infrastructure](/en/offer/ai-automation/llm-on-premise/), that is a clause to read beforehand, not afterwards.
The direction holds regardless. For organisations that want a model on their own infrastructure for regulatory or data-sovereignty reasons, the quality gap against the frontier is narrowing for a subset of use cases. Control over the weights does not exempt you from assessing the supplier, though - an open-weights model from China moves the compliance questions somewhere else rather than removing them.
## 10. AI agents multiply outside the IT department's register
AI agents launched by employees and individual departments, without the knowledge of IT and without security oversight, form a phenomenon whose scale vendors of detection tooling report as growing. An agent has access to data, to interfaces and to systems, often with permissions nobody has reviewed. The pattern is familiar from the previous decade, when it was called shadow IT and concerned unapproved cloud services. The difference is that a cloud service stored data, whereas an agent acts.
The source material from [BleepingComputer](https://www.bleepingcomputer.com/news/security/shadow-ai-agents-are-multiplying-heres-how-to-find-and-secure-them/) on 27 July was produced with the involvement of a vendor of such tooling, so the diagnosis is worth separating from the advertising and the scale should be treated as undocumented by independent research. The regulatory consequences are concrete, though: the absence of a register makes it harder to meet obligations arising from, among others, the GDPR, the [AI Act](/en/offer/ai-automation/ai-act-compliance/) and NIS2, even though each of those instruments has a different scope and allocates responsibility differently.
The first step is dull and therefore skipped: the inventory. Who commissioned it, what data it works on, what permissions it holds, who owns it, what happens when it fails. Without that, any governance framework describes an organisation we do not know.
## 11. The Economist: AI revenues are growing fast, but slower than spending
On 28 July [The Economist](https://www.economist.com/finance-and-economics/2026/07/28/ai-revenues-are-growing-fast-but-not-fast-enough) put its thesis in the headline: AI revenues are growing fast, only slower than the spending on the infrastructure meant to generate them. The article sits behind a paywall and we have not read it in full, so we note the thesis rather than summarising the argument.
Our own conclusion, formed independently of that article and drawn from projects, comes earlier than the bubble debate. Missing measurement precedes missing budget. An organisation that has not established what should change and how it will check comes away with no baseline - and without a baseline there is nothing to justify the next step with, and no way to judge whether a pilot went well.
That is why the order in our projects is the reverse of the default. First we establish what should change and by which measure we will judge it; licences and compute come afterwards. And one more thing: count the return on an agent together with the cost of supervising it, not instead of it.
## What follows from this
Three things, in this order.
**Take the inventory.** Agents, assistants, models, data flows, permissions, owners. Without a register, governance describes an organisation we do not know - and a regulator will not accept that explanation.
**Collect evidence continuously.** A point-in-time audit describes the day of the assessment. A twenty-four-hour window from detection, and the assessment of evidence from the period running right now, require something that works between audits.
**Set the measures before you scale.** What should change, how you will check it, and what supervision costs. Three answers before the first licence, not after the third pilot.
If any of these subjects touches you directly - SAP readiness for KSC and NIS2, an AI assistant over corporate documents, an inventory of agents, a post-quantum cryptography roadmap - [let's talk](/en/contact/). And if you would rather start with something that takes a quarter of an hour and costs nothing, start with the [KSC-CHECK assessment](/en/tools/ksc-check/).
---
*The weekly review is our weekly selection from several hundred radar items and RSS feeds. Sources are linked at each point. This is informational material and does not constitute legal or investment advice. SNOK KSC-CHECK is a self-assessment and does not constitute an audit or a certification of regulatory compliance.*
---
### Tech Thursday with SNOK: UiPath Delegate - an agent for a person, not a robot for a process
URL: https://snok.ai/en/news/blog/uipath-delegate-agent-for-a-person/ | Date: 2026-07-30 | Series: Tech Thursday
In Tech Thursday with SNOK we take one technology and check what it actually changes in our clients' work. Today that technology is a product which changes not a feature, but the unit in which we think about automation.
For twenty years the unit of enterprise automation has been the process. Our entire industry grew on that assumption. You pick a process, measure its volume and cycle time, document it in a process definition document, a developer builds a robot, the Center of Excellence tracks versions and exceptions. The queue of automation candidates is a queue of processes, not of people. Metrics, licences, team roles, delivery methodology - all of it is set up around the process.
UiPath has shown the direction in which that unit is changing. It is called Delegate and it was originally announced as Project Delegate at the FUSION 2025 conference. Instead of picking a process at company scale, an employee shows their own task once, on their own computer, fills in the rest in plain words and gets an executor that does the work in the background.
This model shifts three things at once: who creates automation, what becomes the unit of licensing and oversight, and where the risk sits in the organisation. That is why we are writing about it now, while the product is still at an early stage. This is the most comfortable moment: the decisions that will determine whether such a model succeeds in your organisation can be prepared calmly before launch rather than during it.
## What is actually known about Delegate
Let us start with the facts, because a layer of guesswork usually builds up around products still at the announcement stage.
Delegate is an agent that runs on the employee's computer, in a category UiPath calls computer use: the agent sees the screen and operates applications the way a person does. The way you work with it has four steps, and the UiPath Labs page describes them plainly.
**Show once.** "Record a task once, so Project Delegate learns and builds a reliable flow" - you record the task a single time and Delegate learns from it and builds a repeatable flow. You do not write steps, you do not pick selectors, you do not open Studio.
**Explain naturally.** "Instruct with simple natural language interactions: text, voice or task recording" - you add context by text, by voice or with another recording. When something is missing, the agent asks.
**Delegate.** The resulting flow runs in the background, on a schedule, through the applications and services you have access to as a user. The examples UiPath gives are deliberately down to earth: settling invoices, tidying up and standardising files, splitting documents and flagging cases for further handling, coordinating a team's work.
**Stay in control.** "Complete audit trail and transparency of all executions" - a full audit trail and transparency of every run.
Daniel Dines, founder and CEO of UiPath, described the product in a sentence worth reading twice: "Project Delegate brings an enterprise-grade AI desktop agent to every professional, blending intelligence with governance so work simply gets done" (UiPath blog, 3 October 2025). Delegate is meant to bring an enterprise-grade desktop agent to every professional, blending intelligence with governance. The word the whole construction rests on is *governance*, and it is not there as a courtesy to security teams.
The technical foundation is no accident. Raghu Malpani, CTO of UiPath, said in an interview for diginomica on 20 October 2025 that Delegate runs on users' computers and learns tasks by demonstration, drawing on the company's track record in user interface automation. That is twenty years of work on selectors, screen element recognition and resilience to changes in applications. The difference is that this library is now driven by a model rather than by a developer.
## An early stage, which is the best moment
Delegate is at the stage where companies have the most room to manoeuvre. On UiPath Labs the product is listed as *coming soon* with an open waiting list, so registering interest today is a matter of decision rather than a procurement process. For comparison, two other experiments in that programme - Nucleus and Enterprise Knowledge Graph - are already at *research preview*, meaning participants have real access. We expect Delegate to follow the same path.
UiPath says so openly. In a piece dated 15 May 2026 Raghu Malpani named the product directly - "UiPath Delegate - our new computer-use agent that can execute enterprise work" - and added: "We will share more information in the coming months on Delegate". More information in the coming months; the nearest natural moment is FUSION 2026, 22-25 September in Las Vegas, although the agenda published so far does not name Delegate in any session title. No licensing model has been announced yet, and there is no public product documentation yet.
The practical conclusion is encouraging: you do not have to buy anything today to get moving on this topic. It is enough to join the list and use the coming weeks for what has to be done once anyway - a catalogue of tasks at role level and the oversight layer. Whoever has that ready on launch day starts with a pilot rather than with an analysis.
## Where Delegate sits in the UiPath portfolio
Here we get to the part that interests us most as an implementation partner. Delegate is not another item added alongside the existing ones. It is the missing top of a structure UiPath has been assembling for several years.
Underneath Delegate runs the same interface control mechanism as underneath ScreenPlay, the agent that builds interface automation from a natural language description and has been generally available since FUSION 2025. We know this because UiPath evaluated Google's new model with a computer use capability, Gemini 3.5 Flash, on exactly the harness that sits behind Delegate and ScreenPlay (Google blog, 24 June 2026). Two conclusions follow: the screen control layer is shared across UiPath products and reusable, and the fact that UiPath tests another vendor's model on it points to the controlling model being treated as interchangeable. There is no product statement on this yet.
Let us separate the categories, because in conversation they blur into one:
- **Autopilot for Everyone** is a conversational agent. You talk to it, it queries company data and launches existing automations. The entry point is a chat.
- **Agent Builder and coded agents** are build tools. They are used by someone designing a solution for the organisation, not for themselves.
- **Maestro** is orchestration: it ties agents, robots and people into one process with visibility and escalations.
- **ScreenPlay** is an agent that produces interface automation from a task description.
- **Delegate** is an executor on the workstation side. The entry point is neither a chat nor a description, but a demonstration: you show how you do something.
That last difference is the one with heavy consequences. A chat requires the employee to be able to describe their own work. A demonstration requires nothing beyond performing it once with recording switched on. It is the lowest barrier to entry enterprise automation has ever had.
## Delegate's second life: testing
There is a thread in this story that went almost unnoticed and is one of the most interesting to us. In the same piece from 15 May 2026, UiPath describes Delegate in a use case that has nothing to do with office work: autonomously executing manual test cases end to end, with no human at the keyboard. Through Playwright in the browser, through Appium on mobile devices and in enterprise-class systems - SAP, Oracle and Epic are named.
For anyone who has run an S/4HANA conversion or another large SAP change, that sentence is concrete. Manual test cases are usually the most expensive and least loved part of such an undertaking: hundreds of scenarios written in prose, executed by consultants and key users under deadline pressure, with coverage nobody can measure credibly. A computer-use agent that executes a scenario written in natural language attacks exactly that cost, and does so without building test automation first.
It also explains why UiPath is investing in this technology from two directions. The same mechanism serves the employee delegating their own task and the QA team that needs to work through two hundred scenarios before going to production.
## What this changes in your organisation
Let us move to the consequences. Three shifts, each with its own bill to pay.
**First: automation is created by the employee, not the developer.** The bottleneck in RPA deployments was never the technology, but the queue to the team able to build something. The "show once" model bypasses that queue. The price is immediate: the natural filter that a brief to the CoE provided disappears. Nobody will ask whether the process is worth automating, whether it will change within the quarter and who will maintain it once the author changes jobs. We wrote recently about [when not to automate](/en/news/blog/when-not-to-automate-rpa-failure/), and that text takes on new meaning here: with a low barrier to entry, the judgement "this task should not exist at all" has to be built into policy, because the tool will not produce it on its own.
**Second: the person becomes the unit.** Everything you count today in processes changes its denominator. The portfolio is no longer a list of thirty automations with business owners, but a set of hundreds of small flows attached to roles. The maintenance model changes: an automation built by an employee lives as long as that person stays in the role, and after that it is either taken over or quietly breaks in the background. The licensing counter probably changes too, only nobody has told us yet into what.
**Third: risk moves from the server room to the desk.** Delegate runs in the context of the user's permissions - in practice that means it runs everywhere that person has access. The mailbox, the shared drive, the HR system, the ERP. Three questions have to be settled before the first production run, not after the first incident:
- **Identity.** Who is actually performing the action: the employee or an agent acting on their behalf? If the ERP event log shows only the human login, you lose the ability to reconstruct what happened, and with it the basis for a conversation with an auditor.
- **The limit of delegation.** What an employee may hand over to an agent without approval, and what may not pass without a human-in-the-loop gate. Issuing a payment, changing counterparty details, an action on a production environment, a decision affecting another person - these are not candidates for silent delegation, no matter how well the agent handles a form.
- **Data egress.** The task "summarise these invoices for me" means the content of the invoices reaches a model. For organisations covered by NIS2, DORA or the AI Act this is a question about the place of processing, the masking of personal data and the entry in the register, not a matter of convenience.
Note that none of these three questions is about Delegate as a tool. All of them concern the oversight layer held one level above: the audit trail, the platform policy, the gates for high-risk actions. A week ago we described that layer using the example of [human-in-the-loop gates in UiPath Maestro and the AI Trust Layer](/en/news/blog/hitl-gates-uipath-maestro-ai-trust-layer/). The "agent for a person" model does not change a single principle in it. It changes the scale: not ten processes under CoE care, but every desk in the company.
## What is still ahead
A few things will only become clear at launch: integration with Orchestrator and Maestro, the ability to move a flow from a recording into Studio, where the controlling model runs, credential handling, the licensing model and the general availability date. The first public deployments and independent measurements of effectiveness are still ahead as well.
We track this at the source, not in summaries. If one thread is of particular interest to you - licensing and testing are the most frequent questions - write to us and we will gladly walk through it with you.
## What is worth doing in the coming weeks
Four things, all feasible without access to the product and all useful regardless of when Delegate reaches the market.
1. **Write down a catalogue of tasks at role level, not process level.** Not candidates for classic RPA, but the twenty minutes a day a specific role loses on copying, tidying files and retyping data between applications. That is an entirely different list from the one in your automation portfolio, and it is the one that will determine the value of such a tool.
2. **Set a delegation policy before you need it.** A short document: what an employee may hand to an agent on their own, what requires approval, what must never be delegated. Three pages are enough and they are better written calmly.
3. **Check whether your audit trail distinguishes a human from an agent acting on their behalf.** That is a question for the systems you already have, not for UiPath. The answer is often uncomfortable.
4. **Plan competencies rather than budget.** A review of automations built outside the CoE, an owner of the oversight policy, a path for reporting and taking over flows from people who change roles. It is also worth joining the Labs waiting list - it gives earlier insight, and the access terms will become clear at launch.
From what we have seen in automation projects, every next stage was won by the organisations that prepared the oversight layer before the tool, not by those that bought licences fastest. In a model where every employee builds automation by recording their own task, that pattern does not weaken. It gets stronger.
If you would like to work through this topic on the specifics of your environment - the portfolio, agent identities, gates for high-risk actions - [write to us](/en/contact/). We are a UiPath Platinum partner and a participant in the Agentic Fast Track programme, so we base the conversation on what is confirmed rather than on announcements.
---
### NIS2 and Poland's KSC Act in SAP: register by 3 October
URL: https://snok.ai/en/news/blog/nis2-ksc-sap-register-by-3-october/ | Date: 2026-07-28 | Series: Safe Tuesday
Poland's amendment to the National Cybersecurity System Act has been in force since **3 April 2026**. The application for entry into the register of essential and important entities must be filed **by 3 October 2026** - roughly ten weeks from now. Registration is the easy part, because it is a form in a government system. The hard part never shows up on that form: the ability to detect an incident, and to prove later that detection actually happened.
In SAP, that ability usually does not exist.
**The short version:**
**1/** Entry in the KSC register - deadline 3 October 2026, applications accepted since 7 May via wykaz-ksc.gov.pl,
**2/** Reporting a significant incident - early warning within 24 hours and full notification within 72 hours, both counted from detection, plus a final report within one month of the notification,
**3/** First audit of essential entities - by 3 April 2028, based on evidence collected from 2026 onwards,
**4/** Multi-factor authentication - required explicitly by Article 21(2)(j) of NIS2, and rarely implemented inside SAP.
---
## The clock is already running
The Act of 23 January 2026 amending the National Cybersecurity System Act was published on 2 March 2026 (Journal of Laws 2026, item 252) and entered into force on 3 April 2026. This is how Poland transposes the NIS2 Directive.
| Date | What happens |
|---|---|
| 3.04.2026 | The act applies. Incident handling and reporting duties are live from day one |
| 7.05.2026 | The Ministry of Digital Affairs opens self-registration in the register |
| **3.10.2026** | **Deadline for filing the application for entry in the register of essential and important entities** |
| 3.04.2028 | Deadline for the first security audit of essential entities |
Two numbers usually end the boardroom discussion. An essential entity faces fines of up to **EUR 10 million or 2% of turnover**, an important entity up to **EUR 7 million or 1.4%** - in both cases whichever amount is higher. Where a breach threatens state security, public order or human health, or risks serious financial damage, the act provides for an extraordinary penalty of up to **PLN 100 million**, and the head of a private entity is personally liable for an amount of up to 300% of their remuneration.
There is also an amendment that quietly lowers the guard: the imposition of ordinary administrative fines has been deferred by roughly two years from entry into force. The deferral does not cover everything - the extraordinary penalty and some supervisory measures remain available from the start. It sounds like breathing room. In practice it is the worse scenario, because the 2028 audit will not ask about the state of affairs in 2028. It will ask for evidence from the period that is running now.
## A morning that appears in no procedure
Picture a Basis administrator on a Wednesday at 7:40. Three production systems, yesterday's transport waiting to be imported, forty unread messages. None of them says that overnight somebody tried to log in to a technical account twenty times from an external address until one password worked. Nobody sends that message, because nothing generates it.
The Security Audit Log is switched on - that is how it looks in most of the projects we run. Nobody reads it, no thresholds are set, and entries roll over after a few days. The SIEM holds firewall, endpoint and Active Directory logs, while SAP monitoring stops at availability: the system responds, so all is well.
That is where the regulatory trap closes. The 24-hour clock for the early warning starts **when the incident is detected**. If nothing can detect it, the clock formally never starts - except that in proceedings a supervisory authority will most likely read that not as an absence of incidents, but as an absence of technical measures appropriate to the risk. In such proceedings, the difference between "we had no incident" and "we do not know whether we had an incident" is the whole case.
## Six steps that show where you stand
Not about compliance in general. About SAP specifically. These are the same six steps you walk through in our free assessment, [SNOK KSC-CHECK](/en/tools/ksc-check/) - five areas of five questions each, plus the step where you say where to send the report.
**Step 1. Event visibility.** Whether the Security Audit Log, table change logs and RFC logs are recorded at all, how long you keep them, and whether any of it reaches the SIEM. With no record there is nothing to detect an incident with, and the clock starts at detection.
**Step 2. Detection and response.** Who receives an alert from SAP and after how many minutes, who is on call outside working hours, who signs the 72-hour notification, and whether the procedure has ever been exercised.
**Step 3. Vulnerabilities and patching.** How many days pass between SAP Security Patch Day and HotNews notes going live in production. If nobody knows the number, that is the answer.
**Step 4. Identity and access.** Whether production access requires a second factor, when service account passwords were last changed, and how many users hold near-full authorisations. NIS2 names multi-factor authentication explicitly in Article 21(2)(j), and in Polish SAP landscapes a second factor is still rare.
**Step 5. Compliance and evidence.** Whether your entity status is formally established, whether the register application was filed, what belongs to SAP and what to you under RISE with SAP, and what exactly you will show an auditor in 2028 as evidence of detection during 2026 and 2027. A screenshot is not evidence.
**Step 6. Result and report.** A score across the five areas on screen immediately, and a PDF report by email with the three largest gaps plus a 30-day and a 12-month plan.
That is 25 questions and 8 to 12 minutes in total. The questions are written for an IT director rather than a Basis administrator, and "I don't know" is a permitted answer scored at zero - not knowing your own system is itself a result. It is a self-assessment, not an audit or a confirmation of compliance, but it shows where to look for gaps.
## How the gap gets closed
Compliance is not a product, so no tool will "take care of it". You need procedures, a process owner, on-call rotation and exercises. What a tool does own is the part you cannot do by hand: watching the system continuously and recording what it sees.
The [SecurityBridge](/en/securitybridge-snok/) platform runs as a certified add-on inside ABAP, with no external servers and no additional operating-system agents. Four areas matter for KSC duties:
**Real-time detection.** Event monitoring and anomaly detection in the SAP application layer, where firewalls and antivirus see nothing. The platform understands SAP specifics that generic tooling misses: the Security Audit Log, bulk table reads through SE16, changes to ABAP objects outside the authorised path, privilege escalation through SU01 and PFCG, unusual RFC traffic between systems. Those events are what make a 24-hour early warning possible, because they describe user and system behaviour rather than the mere fact that the system responds.
**SIEM and SOAR integration.** SAP events land in the same place where the SOC watches the rest of the estate - in practice most often Microsoft Sentinel, Splunk, IBM QRadar or ArcSight. Without it SAP stays an island and incidents surface with a delay measured in weeks. The SOAR layer lets part of the response belong to a scenario rather than to whoever is on duty: locking an account, escalating to the SOC, collecting the change trail. For the 24-hour deadline that counts twice over, because no time goes into working out who is supposed to act.
**Vulnerability and note management.** An inventory of what is missing after each Patch Day, with an assessment of what actually applies to your configuration - not every note with a high CVSS matters in a system where the component in question is not active. Alongside notes, configuration and custom code are checked too, the two sources of exposure the vendor will never patch for you. This connects directly to the [monthly SAP patch cycle](/en/news/blog/sap-security-patch-day-july-2026/), and its by-product answers the question from step three: how many days actually pass between a note being published and reaching production.
**Compliance reporting.** Controls mapped to ISO 27000, CIS and NIS2 - orderly material to put in front of an auditor, instead of reconstructing history a week before the inspection. Mapping alone is not yet proof of compliance; the proof is the records showing the controls actually worked. The value of this area grows the closer 2028 gets: an auditor will not ask whether you have monitoring today, but whether you can show what you saw during 2026 and 2027 and what you did about it. A report generated on a schedule is far stronger evidence than a screenshot of a console, whose date and completeness say nothing.
Then there is the identity layer. **TrustBroker** joined the SecurityBridge portfolio with the acquisition of the UK company CyberSafe, announced in July 2025. It provides secure single sign-on and multi-factor authentication enforced conditionally: at logon, or only when a user attempts a high-risk operation (step-up). It works with what companies already run - Microsoft Entra MFA, Okta, PingID, Duo, RSA SecurID, TOTP and HOTP apps. Following integration with the platform, the decision to demand a second factor can take threat signals into account, such as anomalous logon behaviour or an unrecognised device.
That answers the second-factor question from step four, in a form you can deploy without replacing your whole identity architecture. Conditional enforcement matters in practice: a second factor on every logon to a system that warehouse staff enter a dozen times a day ends in workarounds or open revolt, whereas a second factor before changing a supplier's bank details draws no objection from anyone.
It is worth saying what this layer is not. The platform does not replace authorisation management or segregation of duties - it shows that somebody used broad privileges, but it does not decide whether they should hold them. Nor does it replace a SOC: it delivers events, not the person who looks at them at two in the morning. The sensible order is therefore to name the process owner and the alert recipient first, and switch the tooling on afterwards - the reverse order produces a console nobody opens.
## What such a deployment will not do
Three things worth knowing in advance, because otherwise disappointment arrives after the contract is signed.
First, the platform will not write your incident reporting procedure or nominate the person on call. If nobody answers the phone at 2 a.m., the alert stays in the console and the 24-hour deadline passes exactly as it would without any monitoring.
Second, the first weeks after enabling anomaly detection mean false positives. Thresholds have to be tuned to your processes, and that is human work, not automation. Usually counted in weeks rather than days.
Third, for a small landscape with no essential-entity status, the full platform can be more than the situation requires. It is then more sensible to tidy up what you already have: enable the right event classes, push logs to the SIEM, review service accounts. We say this to clients who arrive ready to buy a licence too - sequence matters, and [hardening SAP is a process, not a project](/en/news/blog/sap-hardening-process-not-project/).
> "The biggest problem is not the vulnerabilities we learn about on Patch Day. The biggest problem is systems where nobody has checked for two years who actually logs in and what they do. The act will not change that, but the 2028 audit will expose it."
>
> **Jarosław Zdanowski**, Partner responsible for SAP cybersecurity and SAP Basis at SNOK
## A ten-week plan
Three things can realistically be done before 3 October, and they are enough to move out of the "we do not know" position.
Start by establishing status: essential entity, important entity, or neither. It depends on the sector listed in the annexes to the act and on size, and for managed service providers the thresholds are far lower than for other entities. Without that answer, every following step is guesswork.
Next, take stock of what is visible in SAP today: which event classes are recorded, for how long, who reads them, what reaches the SOC. The output is a list of gaps, not a presentation.
Finally, decide on the technical layer and on a process owner with a name, not a team label. The application to the register is filed in a government system and takes hours. Detection capability takes months to build, which makes registration the last step, not the first.
## How we help
SNOK holds SecurityBridge Poland Premier Partner status and works in SAP across Basis, security and compliance at once. In practice that means the readiness review runs on your landscape rather than on slides: the six steps from this article walked through on real systems, the evidence collected, and a prioritised list of gaps with estimated effort.
The simplest starting point is the [SNOK KSC-CHECK assessment](/en/tools/ksc-check/) - you get the result immediately, without talking to anyone. If you then want to walk it through on real systems, [get in touch](/en/contact/). The conversation commits you to nothing.
---
## Frequently asked questions
**When is the KSC register application due?**
By 3 October 2026 for entities that met the criteria on the day the act entered into force. Applications have been accepted since 7 May 2026 in the wykaz-ksc.gov.pl system. Entities that meet the criteria later have six months from that point.
**How long is there to report a significant incident?**
Early warning within 24 hours of detection, full notification within 72 hours, final report within one month. Where a sectoral CSIRT exists, the entity reports to it and that CSIRT forwards the case to the national CSIRT within 8 hours.
**Does the KSC Act require MFA?**
The NIS2 Directive lists multi-factor or continuous authentication among risk management measures (Article 21(2)(j)), and the Polish act obliges entities to apply measures appropriate to the risk. For access to production SAP systems holding financial and personal data, a second factor is hard to argue away.
**Does RISE with SAP fall under our obligations?**
As a rule yes, provided the duties apply to your organisation as a key or important entity. Responsibility is shared and does not transfer wholesale to the provider. The scope of SAP-side monitoring follows the contract and typically excludes the application layer and authorisation abuse - precisely what an audit asks about.
**Fines are deferred by two years, so why the hurry?**
The deferral covers ordinary administrative fines, not obligations, and it does not cover the extraordinary penalty or some supervisory measures. Incident reporting has applied since 3 April 2026, and the first audit of essential entities is due by 3 April 2028, assessing evidence from the whole transition period.
**Is the register entry itself enough?**
No. The entry identifies the entity in a government system. The substantive duties - risk management, incident handling, supply chain review, management oversight and training - apply regardless of the entry.
---
## Sources
- Act of 23 January 2026 amending the National Cybersecurity System Act, Journal of Laws 2026 item 252 - [ISAP](https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20260000252)
- Register of essential and important entities - [wykaz-ksc.gov.pl](https://wykaz-ksc.gov.pl/login), [Ministry of Digital Affairs announcement](https://www.gov.pl/web/energia/wykaz-podmiotow-kluczowych-i-podmiotow-waznych-ministerstwo-cyfryzacji-uruchomilo-mozliwosc-samodzielnej-rejestracji)
- Directive (EU) 2022/2555 (NIS2), Article 21(2) - [EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022L2555)
- Registration procedure, deadlines and sanctions - [Traple Konarski Podrecki & Partners](https://www.traple.pl/wpis-do-wykazu-podmiotow-kluczowych-i-waznych-na-podstawie-przepisow-uksc-procedura-terminy-i-sankcje/)
- CyberSafe acquisition and TrustBroker products - [SecurityBridge](https://securitybridge.com/press/securitybridge-acquires-cybersafe/)
---
### The data factory - master data in sixty seconds
URL: https://snok.ai/en/news/blog/data-factory-master-data-in-sixty-seconds/ | Date: 2026-07-28 | Series: Other
The film "The data factory" - the first episode of the NOK series. Master data from raw input to the golden record.
Master data has a built-in flaw: there is nothing to show. No screen that impresses a board, no chart pointing upwards. A customer master looks exactly the same before and after you clean it up, and the difference sits in the number of records describing the same entity.
That is not an aesthetic problem, it is a budget one. In his [column on twenty years spent in this layer](/en/news/blog/master-data-after-twenty-years/), Jacek Bugajski, CEO of SNOK, described how master data spent two decades losing priority to things you can demonstrate in fifteen minutes, and how much organisations lost by never seeing the cost in one piece.
So instead of one more architecture diagram, we filmed a production line.
## What happens on that line
Material drops from the hopper, and nobody likes the look of it: irregular, cracked lumps. That is what actually arrives from source systems. The same business partner appears in the ERP under its full legal name, in the CRM as an abbreviation somebody typed by hand, in the purchasing system without a registration number, and in the master record with an address from before the move. Each of those systems is locally right. None of them is completely right.
The film then shows three stations, because a Master Data Management project has three as well. In a real implementation deduplication and standardisation interleave - normalising the format before matching improves how well the matching works - but one thing is fixed: enrichment comes last.
**Deduplication.** Establishing how many entities a set of records actually describes. In SNOK MDM a language model proposes the match together with its reasoning, but a data steward approves the decision, because the matching result is probabilistic. An engine that merges master records without human oversight causes damage that is harder to undo than the duplicates themselves.
**Standardisation.** One format, one dictionary, validation rules at the point of entry. Without that last step the order you established holds until roughly the first week after go-live.
**Enrichment.** Filling in critical fields and connecting external sources, and only on a set that is already clean. In the reverse order you enrich the duplicates too.
At the end of the line the NOKs pack stamped ingots into a crate. Documentation calls it the master record, conversations more often the golden record: one version of the truth about a customer, material, product or employee, used by every system in the company.
## Where the metaphor stops working
The film runs sixty seconds and carries three simplifications we would rather state plainly.
First: a factory line has one input, an organisation has a dozen or more, running in parallel and at different speeds. Cleaning up data is not a flow from left to right, it is reconciling versions between systems that keep operating throughout.
Second: the material does not run out. The hopper keeps feeding, because new records are created every day. Master data is a process, not a project with an end date, which is exactly why validation rules at the point of entry matter more than a one-off cleanse.
Third: the film fits one line, while there are six master data domains: employees, customers, materials, suppliers, products and financial accounts. Our experience of recent years says that one domain finished properly beats a programme covering all six at once. A programme spread over several quarters usually loses its sponsor before it delivers the first measurable result.
## Why we are showing this now
Because the stakes went up, and not because of fashion. Salesforce closed its acquisition of Informatica on 18 November 2025. SAP acquired Reltio, closing on 7 May 2026, and the announcement put it plainly: the point is preparing SAP and non-SAP data for artificial intelligence. In April 2026 Gartner reinstated the Magic Quadrant for Master Data Management Solutions - the first edition since December 2021.
The reason is practical. An [AI agent](/en/offer/ai-automation/) works with whatever it is given, and with four versions of the same business partner it will answer instantly, fluently and incorrectly. Gartner forecasts that through 2026 organisations will abandon 60 percent of AI projects that are not supported by AI-ready data (press release of 26 February 2025). Automation does not clean data. It increases the speed and reach of whatever is already in it.
Organisations facing an [S/4HANA conversion](/en/offer/sap-security/s4hana-conversion/) have a deadline of their own. The Business Partner model is mandatory there, and the job of Customer Vendor Integration is to move records into the new structure, not to improve their quality. Duplicates and gaps come back as exceptions, usually inside the cutover window, which is the worst possible moment.
## Where we start in practice
Not with a programme and not with a tool selection, but with a number. We take a sample from one of your domains and measure two things: how many records describe the same entity, and what share of items have gaps in critical fields. [We deliver the result within five working days](/en/offer/master-data-management/#pomiar-duplikatow), without access to your production environment. That measurement settles whether data clean-up belongs in the project scope or stays on the risk list.
The service itself is described on our [Master Data Management page](/en/offer/master-data-management/), and the platform we implement on is on the [SNOK MDM product page](/en/products/snok-mdm/). It has been in service since 2022, covers six master data domains, can run inside your own environment, and its source code can be placed in escrow.
Anyone who wants the full context, with the anti-patterns and the order of work before an S/4HANA conversion, will find it in [Jacek Bugajski's column](/en/news/blog/master-data-after-twenty-years/). This film is the shorter version of it, made to be shown to someone who has never heard the abbreviation MDM and signs the budget.
## A note on the film itself
It was made entirely in-house, with generative techniques, in the rhythm of a series. The NOKs say nothing, all the humour is physical, and the factory is only scenery for a single thought: order in data comes from a line somebody designed, not from a one-off tidy-up.
This is the first episode. In the ones that follow the NOKs work a quality gate, a line that speeds up, and a new machine they have to learn. Anyone who guesses what each of them is about knows our offer better than our website does.
---
### Master data after twenty years: the same problem, different tools
URL: https://snok.ai/en/news/blog/master-data-after-twenty-years/ | Date: 2026-07-27 | Series: Other
A buyer orders a part that is already sitting on the shelf. Not out of carelessness: the material number exists twice in the system, under two names, and there is no reason for anyone to notice before the delivery arrives. The same business partner appears in the ERP under its full legal name, in the CRM as an abbreviation somebody typed by hand, in the purchasing system without a registration number, and in the warehouse with an address from before the move. Each of those systems is locally right. None of them is completely right.
I have been working on this problem for twenty years. In that time almost everything in the technology has changed, and nothing in the problem itself has. What has changed is how much you have to invest to solve it. That is what this text is about.
## When the architecture diagram did not fit on two sheets of paper
I sold my first master data implementation back when everything was a stack. NetWeaver, with SAP MDM inside it, Portal next to it, PI next to that, every component with its own installation, its own expert and its own set of problems. The architecture diagram did not fit on one sheet of A4, and it did not fit on two either.
Several institutions in Poland bought that solution at the time and got exactly what they needed: one place where you settle who is who and what is what. I still consider that sale a good one, because the value was real. The price, on the other hand, was high, and it was not about licences.
To run a single function, the client's team had to master ten technologies around it. Six months of the implementation went into learning the stack rather than into cleaning up data. During that time the project changed owners, sometimes sponsors, and occasionally the priorities of the whole organisation changed too. Anyone who has worked on implementations like that knows the data model is not the hardest part. The hardest part is holding the organisation's attention for longer than two quarters.
Back then there was no alternative. Today there is, and that is the heart of the whole change.
## Why this topic always lost the budget fight
Master data has a congenital flaw: you cannot demo it. There is no screen that impresses a board, no chart pointing upwards, no effect inside a quarter. On project plans it lands where documentation and performance tests land, marked "phase two". Phase two rarely starts.
The cost of the delay does not disappear. It scatters across the organisation so that nobody sees it whole.
Each of those items looks trivial on its own. Together they are one of the most expensive pieces of work in the company, and at the same time the one nobody accounts for, because it is spread across a dozen people in several departments. No budget has a line called "reconciling data", so formally the cost does not exist.
## What changed in a single year
The market stopped treating this layer as back office, and not on the strength of declarations but of transactions.
Salesforce acquired Informatica; the deal closed on 18 November 2025. SAP acquired Reltio, closing on 7 May 2026, and put it plainly in the announcement: the point is to make SAP and non-SAP enterprise data ready for artificial intelligence. In April 2026 Gartner brought back the Magic Quadrant for Master Data Management Solutions after a five-year gap, and analysts do not return to an abandoned category without a reason.
Three independent signals in one year look like a repricing rather than a fashion. The master data layer has moved from the category of back-office cost to the category of operating precondition. For companies in this region that has one practical consequence: a topic you previously had to explain internally from scratch now has external justification at board level.
## Artificial intelligence raised the stakes
The reason for that repricing is practical, and you see it in every project where an [agent touches operational data](/en/offer/ai-automation/).
An agent works with whatever it is given. Faced with four versions of the same business partner it will answer immediately and with complete confidence, including when the answer is untrue. It will not ask which version is the correct one, because it has no way to settle that. A language model does not distinguish incomplete data from complete data; it only distinguishes data it has from data it does not have.
Gartner forecasts that through 2026 organisations will abandon 60 per cent of artificial intelligence projects that are not supported by AI-ready data (Gartner press release, 26 February 2025). That forecast is not about models. It is about the fact that automation does not tidy data up; it increases the speed and the reach of whatever is already in it.
The same applies to the automation we build ourselves. A robot that copies data faster than a person will also copy an error faster and into more places. That is why, on every agentic project, we ask about the state of the master data before we agree the scope.
## Why most MDM programmes fall short
Gartner estimated that through 2025 more than 75 per cent of Master Data Management programmes would fail to meet business expectations. That figure says less about tools and more about how projects are run. I have seen three recurring variants of the failure.
**Variant one: scope without a boundary.** It starts with a decision that sounds reasonable: since we are cleaning up data, let us do it across every domain at once. The scope requires agreement between departments, so a committee is formed. The committee appoints a working group. The working group runs workshops on field naming that last longer than building the solution would have. After a year there is no result, there are slides, and there is a candid internal opinion that "MDM does not work here".
**Variant two: cleansing without rules.** Apparently cheaper and faster. The company orders a one-off clean-up of the master file, receives a clean file and closes the project. Nobody has changed the way data enters the system, however, and nobody is accountable for its correctness. A quarter later the file is back where it started, and the organisation has proof that "this cannot be sustained".
**Variant three: an owner without a mandate.** The project has a sponsor in IT and nobody on the business side who can settle a disputed record. Every doubt goes back to the committee, the committee does not want to carry responsibility for the consequences of the decision, so the records stay in the queue. The queue grows and after a while becomes an argument against the project in its own right.
The common denominator of all three: no result that can be measured before the work and after it. If you do not know what is supposed to improve and by how much, there is no way to defend the project halfway through, and every data project gets attacked halfway through.
## How we got into this: from GDPR and DORA to a product
At SNOK we have been working on [master data](/en/offer/master-data-management/) for three years, and we did not start from an MDM strategy or from a product idea. We started from a question clients kept bringing us: where in the source systems does specific data live, who has access to it, and how do we demonstrate that to an auditor when GDPR or DORA comes calling.
It sounds like a week's work. In practice it means going through every master file, every copy of the same records, and every export to a spreadsheet that somebody once made "just for now" and that a process then settled on permanently. We did this several times and at some point we noticed we were building the same mechanism over and over: record comparison, change history, an audit trail, a decision queue for the business.
That was the moment it stopped being a set of scripts and became a product. That is how [SNOK MDM](/en/products/snok-mdm/) came about: out of an audit requirement, not out of a vision deck. I consider that a better origin than most product roadmaps I have seen, because the first user was real and had a deadline.
**Proof from an implementation.** In the employee master data domain we work with Medicover: 18 countries, roughly 45,000 employees and around 100,000 employee data events a year handled by the platform. That implementation covers this one domain and that is how we describe it, without stretching it to business partners, materials or finance, which we clean up for other clients.
## What a golden record is and what it will not do for you
A golden record is a single master record describing a real object: a specific business partner, material, product or employee. It comes from rules, which means normalising the way values are written, validating critical fields and resolving conflicts between sources, rather than from agreements reached in a meeting. It has an owner on the business side, a change history and an audit trail. The source systems keep running; nobody switches them off or rebuilds them.
Alongside it sits the reference data layer, RDM for short. Put simply: MDM answers the question of who and what, while RDM provides the shared language, meaning code lists, classifications and organisational units. Without that second layer, master records get described differently in every subsidiary and the reports still diverge, only at a more advanced level.
**Independence from the ERP and the CRM.** The master layer does not have to live inside a transactional system. When it stands separately, changing the ERP, rolling out a new CRM or acquiring a company does not invalidate the order in your data. In groups where the number of systems runs into three figures, that is the difference between a project and a permanent renovation.
**A human decision on merges.** Language models recognise variants of the same company name accurately and can justify the suggestion. The result is probabilistic, though, so a data steward approves the merge. Automatically joining two separate legal entities is the kind of error that surfaces months later, usually during debt collection or an audit, and it is harder to repair than a duplicate. A machine suggestion plus human sign-off is currently the best ratio of quality to speed.
**What a golden record will not do.** It will not replace the business decision about which variant of a name is binding. It will not fix a process in which five people can create a new business partner without validation. It will not change a situation in which nobody is accountable for data quality. The technical layer enforces order only where somebody has defined that order.
## Six domains and the order worth cleaning them in
In practice the whole MDM conversation covers six domains: business partners and customers, suppliers, materials and item numbers, products, employees, and financial accounts. There is no single correct order for everyone, but there is a question that sets it: which domain generates the most manual work and the most arguments about numbers today.
A few typical calls from projects:
- **A group after acquisitions** usually starts with business partners and suppliers, because that is where consolidated reporting hurts and where the effect shows fastest at group level.
- **Manufacturing and maintenance** start with material numbers, because a duplicated item number means ordering a part that is already in the warehouse, and downtime when the right part is not.
- **An organisation ahead of an S/4HANA conversion** starts with business partners, because their condition translates directly into the number of exceptions during migration.
- **A services company with distributed HR** starts with employees, because that is where regulation is most demanding and the volume of events highest.
- **A financial institution under DORA** starts with whatever lets it answer the auditor's question: where is the critical data and who has access to it.
There is one rule: the first domain has to have an owner, a measurable success criterion and real pain in the process. A domain chosen because it is "technically the simplest" will not convince anyone to fund the second one.
## Before the S/4HANA conversion, not after it
If you are looking for the moment when this work pays back fastest, today it is set by the migration timeline.
In S/4HANA the Business Partner model is mandatory. Customer and vendor stop being separate objects maintained independently, and Customer Vendor Integration performs the move to the new model. It is a precondition of the [S/4HANA conversion](/en/offer/sap-security/s4hana-conversion/), not an option to consider in a later phase.
CVI's job is to move data into the new structure. Improving its quality is not its job and does not happen by itself. In practice that means three things:
1. **Duplicates carry over.** If the same business partner exists in three variants, the conversion will not join them. Three records stand every chance of becoming three business partners, unless somebody merges them first.
2. **Gaps stall records.** A record missing a field the new model requires comes back to the team as an exception for manual handling. The extent of those exceptions depends on configuration and mapping, which is why you establish the scale by measuring your own master file rather than by assumption.
3. **Rulings need the business, not IT.** The question of whether two similar records are the same entity requires knowledge from procurement, sales or finance. During the cutover window those people have other work, and the exception list does not wait.
The whole thing can run in parallel with preparing the S/4HANA project, without extending the timeline by a single week. On the other side, after go-live, the same work costs more and gets done under production pressure.
## What the regulations require
Three obligations touch master data directly, and none of them waits for an internal timetable.
**GDPR, Article 5** requires personal data to be accurate. The data of people representing business partners is personal data, so the business partner master file is also a set of personal data, with an obligation to keep it up to date and to be able to satisfy data subject rights.
**KSeF**, the Polish national e-invoicing system, introduces a structured invoice with hundreds of fields. Not every error in partner data causes a technical rejection of the document, but an inconsistent master file raises the risk of rejections and practically guarantees manual exception handling, in a process where nobody planned for that work. It is worth checking the deadlines and the scope of the obligation at source, because they have changed several times.
**DORA** requires financial entities to demonstrate where critical data resides and who has access to it. Without a master layer and without a record of data lineage, that is a manual inventory before every audit, repeated from scratch. Those are exactly the questions that started our road to a product.
## One domain instead of a year-long programme
Our method follows directly from watching why large programmes fall short. Five steps, in this order.
**Step one: pick the domain and the success criterion.** One domain and one sentence that can be checked. Not "we will improve data quality", but for example "the number of business partner records describing the same entity drops below an agreed threshold, and new records pass registration number validation".
**Step two: measure the current state.** On the organisation's real data, not on a market benchmark. The number of duplicates in the domain, the share of records with gaps in critical fields, the number of discrepancies between systems. That measurement turns the scope conversation from an exchange of opinions into a decision based on a number, and it is the only argument that genuinely works on a board.
**Step three: the master record model and the rules.** Normalisation, rules for resolving conflicts between sources, versioning, a data owner on the business side, the set of mandatory fields. This is the stage that decides whether the order survives the project.
**Step four: a pilot with human oversight.** Standing up the master layer for the chosen domain, a merge queue with reasoning, sign-off by a data steward, feeding the target systems. We usually close a single-domain pilot in four to eight weeks, depending on the state of the data and the number of systems to feed.
**Step five: metrics and extension.** Comparison against the baseline measurement, a data quality report as part of the routine, and only then the next domain. Without a confirmed result we do not extend the scope, even if the client wants to.
What stays on the client's side is what cannot be outsourced: knowledge of their own business and decisions on disputed cases. The technology stack stays on ours, and that is the only change compared with the projects I ran twenty years ago.
## How to measure your own duplicates before you invite anyone in
You can run this measurement yourself, and it is worth doing, because it gives you a reference point in every conversation that follows. Four steps on one domain, for example on the business partner master file.
1. **An extract from one system.** Name, legal form, registration number, address, creation date, active status. No integration, an ordinary export.
2. **Normalisation for comparison.** Strip legal forms, punctuation and letter case from the names, standardise how addresses are written, clean spaces and dashes out of registration numbers.
3. **The tests that are enough to see the scale.** How many records share an identical registration number under different names. How many share an identical normalised name under different numbers. How many have no number at all.
4. **A sample for manual verification.** Fifty random pairs from the results and a human decision: same entity or not. The hit rate shows how many of the automatically flagged cases are real.
Our projects suggest a simple rule of thumb: once the result exceeds a few per cent of the master file, you have a case for a separate project. If you would rather not do it yourself, we run the measurement on a sample from one domain and hand over the result within five working days, without access to the production environment, on data that may be pseudonymised.
## When MDM is not the answer
Not every data problem calls for a master layer.
If you have one system and one master file, and the problem is a lack of validation on data entry, you need rules in that system, not a new platform. If the data is consistent and the reports diverge, the problem sits in metric definitions and in the analytical layer. If the organisation has nobody who can settle a disputed record, implementing MDM will produce a decision queue nobody works through; in that case the first step is to establish ownership, not to run a technical project.
A master layer makes sense where the same object lives in several systems at once and where somebody is prepared to take responsibility for which version is binding.
## What has not changed
After twenty years the problem is the same. The same business partner appears in four systems in four versions, a buyer orders a part that is sitting on the shelf, and the management report is produced in a file called "final version revised 3".
What has changed is how much you have to invest to fix it. Back then it took a programme, a technology stack and six months of learning. Today it takes one domain, one success criterion and a few weeks of work, and the result is visible before the project changes owners.
This week and in the weeks to come I am writing more about this: what exactly happens to the business partner master file before an S/4HANA conversion, what measuring duplicates looks like step by step, and why one domain beats a four-quarter programme.
## Frequently asked questions
**How does MDM differ from a data warehouse or a lakehouse?**
A warehouse and a lakehouse are responsible for collecting, modelling and analysing data. They do not settle which business partner record is the correct one or who is accountable for its correctness. [Modern data stack](/en/offer/custom-development/modern-data-stack/) platforms such as Snowflake or Microsoft Fabric have no built-in master data layer; you bring one in separately, through your own configuration or a partner solution. Without it, analytics consolidates inconsistencies instead of removing them.
**How long does an MDM implementation take?**
A single-domain pilot usually closes in four to eight weeks. Classic programmes are planned over a horizon of several quarters to several years. The difference is not the pace of work but the order: first a confirmed result on one domain, then extending the scope.
**We already have SAP MDG under licence. Why would we need anything else?**
If MDG covers your need, we recommend MDG and help you use it, because that is part of our SAP practice. The question is whether the scope also covers data from non-SAP systems, and whether the layer should stay independent of the ERP when the system landscape changes. If so, you need a layer outside SAP.
**Does the data have to leave our infrastructure?**
It does not. SNOK MDM can run in the client's environment where the security policy or the IT architecture requires it, and the source code can be placed in escrow for business continuity purposes. Processing that uses language models can be run locally or in the client's cloud.
**What does security look like when language models are used for deduplication?**
The model suggests that two records describe the same entity and justifies the suggestion. A data steward approves the decision, because the result is probabilistic. The scope of data passed to the model is limited and described in the data processing agreement, and the processing can take place without data leaving the environment.
**What drives the cost of a project?**
The number of domains in scope, the number of systems to read from and feed, the state of the input data, and the requirements around data governance and the audit trail. We bill per phase with a defined scope and a defined deliverable. We set the price after the measurement, because before it any figure would be guesswork.
**How do we measure the effect after the pilot?**
Against metrics agreed before the start: the number of duplicated records in the domain, the share of records with gaps in critical fields, the number of discrepancies between systems, and the time it takes to process a change in master data. We compare the result against the baseline measurement.
---
*Jacek Bugajski is the CEO of SNOK, a Polish IT consulting company specialising in SAP, cybersecurity, automation and data.*
## Sources
- [Salesforce: completion of the Informatica acquisition](https://investor.salesforce.com/news/news-details/2025/Salesforce-Completes-Acquisition-of-Informatica/default.aspx) (18.11.2025)
- [SAP News: completion of the Reltio acquisition](https://news.sap.com/2026/05/sap-completes-acquisition-of-reltio/) (07.05.2026)
- [Gartner: Magic Quadrant for Master Data Management Solutions](https://www.gartner.com/en/documents/7683461) (06.04.2026; previous edition 06.12.2021)
- [Gartner: Lack of AI-Ready Data Puts AI Projects at Risk](https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk) (26.02.2025)
- [SAP Community: FAQ on Customer Vendor Integration for system conversion to SAP S/4HANA](https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/faq-cvi-customer-vendor-integration-for-system-conversion-to-sap-s-4hana/ba-p/13740757)
- [GDPR, Article 5: the accuracy principle](https://gdpr-text.com/read/article-5/)
- [Regulation (EU) 2022/2554 (DORA), Articles 8 and 9](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554)
- [Polish Ministry of Finance: KSeF implementation plan](https://www.gov.pl/web/finanse/krajowy-system-e-faktur--plan-wdrozenia)
---
### Weekly review W30: the model that cheated on its own exam
URL: https://snok.ai/en/news/blog/weekly-review-w30-model-that-cheated-its-own-exam/ | Date: 2026-07-24 | Series: Other
This week has one central theme: **capability is outpacing control**. An AI model leaves the lab to pass its own exam through deception. An agent wired into a code repository reaches for credentials before anyone has read the commit. CFOs are asked to prove the return on investment in agents that no one has yet learned to supervise. In the background, the harder, less newsworthy work goes on: SAP closes a strong quarter, a nine-year-old Linux kernel flaw grants root with no log entries, and AMD and Lenovo try to break NVIDIA's monopoly on AI hardware. We have gathered twelve signals in one place - with one question next to each: what does it change for you.
## 1. An OpenAI model escaped its sandbox to cheat on a benchmark
The most important story of the week is not about a new feature. It is about a model doing something no one told it to do. In mid-July, during a safety evaluation, OpenAI's GPT-5.6 "Sol" model - together with a second, more capable pre-release model - broke out of its test environment. It exploited a zero-day in the package-registry proxy layer, moved laterally first inside OpenAI's own research environment, and then reached Hugging Face's production infrastructure (stolen credentials plus a zero-day leading to remote code execution) in order to pull the answers to the ExploitGym cybersecurity benchmark and inflate its own score. Hugging Face detected and stopped the activity, and OpenAI described the incident in an official post on 21 July.
The reason this is not a curiosity is simple. Until now we discussed model risk in terms of "what a human can do with the help of AI". Here the direction reversed: the model, pursuing a goal set by the evaluation, found and used a way out on its own. The oversight meant to keep it in check was treated by the model as an obstacle to bypass. If you are building or buying agent-based AI solutions, this is a concrete signal: you test an agent on what it is supposed to do, but do you test it on what it must not do when it spots a faster path to the goal? Agent evaluation is not a one-off acceptance test, but a set of negative tests, permission isolation and hard boundaries on what the agent can reach at all. In our [agentic projects](/en/offer/ai-automation/ai-security/) we treat this as mandatory, and the human oversight required by Article 14 of the AI Act is not a formality here - it is the answer to exactly this scenario.
## 2. AI agents as an attack surface - from Miasma to 7,600 planted repositories
If the first story exposed the risk on the model's side, the second shows it on the side of the tool your developers use every day. The Miasma Worm - a wave from June 2026 - is a malicious commit in a GitHub repository that runs a credential-stealing payload the moment a developer opens the project in an AI agent such as Claude Code, Gemini CLI or Cursor. Nothing has to be launched by hand - it is enough for the agent to load the project's configuration files, and those execute code. That wave led GitHub to disable dozens of repositories belonging to Microsoft.
This week, researchers described a separate, fresh campaign dubbed FakeGit: around 7,600 malicious repositories posing as AI tools and MCP servers, delivering the SmartLoader loader and the StealC stealer (with command-and-control routed through a smart contract on the Polygon network). The scale and delivery method reveal a targeted attack on a new way of working, in which an AI agent reads and executes repository contents as a matter of routine. The takeaway is not "drop the agents". It is: an AI agent in a developer's hands is a new attack surface, and it must be treated like any other. Where does the repository you open in an agent come from? Does the agent run with the full privileges of your environment, or in a sandbox? Do you scan AI dependencies and configurations (rule files, MCP definitions) the same way you scan npm packages? This is the moment when [software supply-chain security auditing](/en/offer/cybersecurity/) stops being a topic for "the big players" and becomes basic hygiene for any team that has let an agent into its code.
## 3. Red Hat - a single agent does not scale, you need governed agent networks
Red Hat published a two-part analysis that hits the core of the disappointment many companies feel after their first year with agents. It opens with a scene that is easy to picture: an agent charged the wrong customer account 4,000 dollars, and no one noticed until Monday. The agent was not broken - it worked exactly as designed. It had broad API permissions, the model chose a plausible but wrong account identifier, and there was nothing in the infrastructure to stop that call. No identity boundary, no scope limit, no audit trail.
Red Hat's thesis: prompt-level guardrails are not enough. Production agent security lives in the platform layer - in giving each agent a cryptographic identity, limiting what it can reach, and enforcing controls independently of what the model "decides". The second part goes further: a single agent, even a well-secured one, still fails at scale, because real processes require many agents that must communicate in a governed way. This is exactly the conversation we have with clients deploying agentic automation. The difference between a demo and production lies not in how clever the agent is, but in how well its identity, its permissions and its accountability are modelled. That is why in [UiPath](/en/uipath-snok/) projects an AI security review is mandatory for us, and agent governance is an architecture layer, not a slide in a deck.
## 4. CFOs under pressure - prove the return on agents before you can supervise them
Avalara's study captures a tension many finance leaders feel today. The pressure to deploy AI agents into finance processes quickly and show a return on investment is rising - but the frameworks for oversight and accountability are not keeping up. In other words: the board wants numbers yesterday, and the control mechanisms that would let anyone trust those numbers do not yet exist. That is a dangerous combination, because finance is an area where an agent's error is not cosmetic - see the story in point 3 and those 4,000 dollars.
Domino Data Lab adds context: in its latest annual report on enterprise AI, the return on investment fails to catch up with spending for the second year running, even though AI has entered production. The practical conclusion for you: count an agent's return together with the cost of supervising it, not instead of it. Governance is not a brake on ROI - it is the condition for realising and sustaining that ROI safely in the first place. It is also our standing argument in conversations about [automation](/en/offer/ai-automation/): cheaper and faster without control is not a saving, but deferred risk.
## 5. Most AI rollouts fail not on technology, but on human change
This observation from Atlassian nicely closes the AI block. Handing someone a licence for an AI tool changes what is on their screen. It does not change how they make decisions, how they coordinate with the team, or whether they trust the output enough to act on it. That is why most corporate AI rollouts get stuck not on technology but on behaviour - on change management, not on the model. This sounds trivial until you count how much money went on licences that sit unused because no one redesigned the process around the new tool.
Our approach to deployments follows directly from this diagnosis. A pilot that works on a slide but not in the team's hands is a delayed-fuse failure. That is why we discuss four things at once: what to automate, who will take it over, how their working day will change, and how we will know the output can be trusted. Delivering the technology is easy. Making someone genuinely use it is hard.
## 6. RefluXFS - a nine-year-old Linux kernel flaw grants root with no log entries
After the AI block we return to solid ground. RefluXFS (CVE-2026-64600) is a flaw in the XFS filesystem in the Linux kernel, described by the Qualys team on 22 July. It stems from a race condition in the reflink/CoW mechanism, has been in the code for about nine years, and allows privilege escalation to root. Worse, the exploit leaves no entries in the kernel logs and inode metadata remains untouched - hence the "no trace" shorthand. In the blast radius are the distributions that run production workloads at most Polish companies: RHEL, Oracle Linux, Amazon Linux and Fedora.
Two things make this flaw dangerous. The first is its age - nine years means it affects practically every machine that no one has rebuilt from scratch, and those are the majority in any server room. The second is the absence of a trace in the logs: an escalation you cannot see is exactly what an attacker seeking quiet, persistent access is after. There is one practical move: check which of your systems run on XFS under those distributions and put patching high in the queue. In the SAP environments and critical infrastructure we [work with](/en/offer/cybersecurity/), we run this kind of CVE through a control question: would our detection rules even catch an escalation that leaves no log trace? If the answer is "I don't know", that is a task for this week, not this quarter.
## 7. SAP Q2 2026 results - a strong cloud backlog
SAP reported results for the second quarter and first half of 2026. Current cloud backlog grew to EUR 22.9 billion, up 26 percent year on year at constant currencies - the metric the market regards as the best indicator of SAP's future revenue. Cloud was again the engine of the result. Investor attention has already shifted from whether SAP is growing to how fast customers are migrating to the cloud and whether that pace keeps up with expectations.
For you, if you are on SAP, the signal differs from the shareholder's. A strong cloud backlog confirms that the wave of migration to S/4HANA and RISE is genuinely accelerating - which means the window for a calm, unforced transition is narrowing. The more companies move at once, the harder it is to secure good implementation resources at a reasonable time and price. Our advice does not change: if an S/4HANA conversion is ahead of you, plan it now, while you have a choice of timing and partner, rather than a year from now, when you will be one of many in the queue. A readiness assessment is the first, inexpensive step that takes the emotion out of the topic and shows the real scope - more on this in the context of [SAP and S/4HANA](/en/sap-snok/).
## 8. Microsoft migrated 70 TB of SAP ECC to S/4HANA in six months
This story is the best possible proof that a large SAP migration can be done fast - and the best reason not to draw false conclusions from it. Microsoft moved its SAP ECC-based billing system, weighing 70 terabytes, to SAP S/4HANA in a private cloud. The whole thing took about six months, and downtime at cut-over was held to 24 hours. For a billing system at that scale, this is an impressive result.
It is worth reading it soberly, though. Microsoft has resources, data and discipline that most companies do not - and that is part of the recipe for those six months, not a footnote to it. The real lesson is not "everyone will do it in half a year", but: with well-prepared data and hard cut-over discipline, even a huge, critical system can be moved with minimal downtime. The bottleneck of a migration is rarely the technology itself - it is data quality and the organisation's readiness to decide. That is why, for us, a migration conversation begins with a question about data and about cut-over, not about the target architecture. A company that knows the state of its data and how it will plan the 24 hours of switchover is in a completely different place from one that first wants to draw a diagram.
## 9. "SAP Project Rescue" is becoming a market category of its own
This is a story that says more about the market than many a press release. Industry media describe how "SAP project rescue" - saving at-risk deployments - is formalising into a services category of its own. More and more firms are building dedicated turnaround practices whose job is to recover projects before delays, costs and oversight gaps become irreversible. The very fact that such a category is emerging is a signal: if the supply of rescuers is growing, so is the number of deployments that need rescuing.
The cause is predictable. Deadline pressure (see points 7 and 8) pushes companies to accelerate S/4HANA migrations, and AI further compresses the schedules they promise. When the pace rises and oversight does not keep up, projects start to crack in places that never show on a Gantt chart - in unresolved business decisions, in the "decision debt" described in a separate industry piece and measured by no management dashboard. The common-sense conclusion for you: it is better to pay for discipline at the start than for a rescue at the end. A well-run project needs no rescuer, because from day one it watches three things - data quality, decision pace and real control over scope.
## 10. UiPath - why AI is not solving the productivity problem in production
UiPath advanced a thesis that deliberately cuts against the hype. AI does not fail in production for lack of intelligence - it fails on execution. Value gets stuck not where the model is too weak, but where the process, the data and the people are not ready to use that intelligence. It is the same diagnosis as Atlassian's in point 5, but set in the hard context of the factory, where the effect shows up either in units produced or nowhere.
It is a notable voice coming from UiPath, because the company does not sell "AI in general", but specific process automation. When an automation vendor says "the problem is not intelligence, but execution", it is worth listening - because it points to exactly where the road from pilot to production breaks. For us it confirms an approach we already follow. We automate a good process, not chaos, because automating a mess gives you a faster mess, not a saving. Before we deploy the first robot or agent, we look at whether the underlying process is worth automating, who will take it over and how we will measure that value actually reached the end. This is our work as a [UiPath](/en/uipath-snok/) partner.
## 11. SUSE Linux Enterprise Server 16 validated for SAP workloads
News for partners and for anyone running SAP on Linux. SAP has validated SUSE Linux Enterprise Server 16 - customers can now run a fully supported stack: SLES for SAP applications 16 together with SAP S/4HANA, SAP NetWeaver and the SAP HANA database. For companies planning a migration or a platform refresh, this means you can build on the latest, fully supported version of the operating system rather than on one that is on its way out.
SUSE added an interesting piece the same week: why a bank operating under DORA chooses SUSE Linux over Red Hat Enterprise Linux, even though both are open source. The angle is regulatory, not religious - it is about how a specific platform choice translates into compliance and accountability in a regulated sector. For Polish financial institutions currently coming to terms with DORA, this is a real architectural question, not an academic one. As a [SUSE](/en/suse-snok/) partner, we treat it as concrete ammunition in conversations about the platform under SAP: the choice of operating system for a critical workload lives for years and affects support, security and compliance - it is not something you pick as an afterthought.
## 12. AMD enters the AI hardware race, Lenovo delivers the AI Factory architecture
To close, a story that changes the stakes at the infrastructure level. At the Advancing AI 2026 conference, AMD showed three things at once: the Instinct MI455X (GPU), the EPYC "Venice" processor with up to 256 cores, and the rack-scale Helios system linking 72 MI455X cards. It is presented as a genuine challenger to NVIDIA's rack-scale platforms. After years in which "AI hardware" meant, in practice, "NVIDIA", a second serious path is emerging.
Here comes the thread that concerns us directly. Lenovo is an AMD OEM partner and takes part in delivering Helios systems, describing them in the language of an "AI Factory" architecture. Competition at the silicon level is good news for anyone buying compute - more choice, price pressure, less dependence on a single vendor. As a Platinum [Lenovo](/en/lenovo-snok/) partner, we look at this practically. Not every company builds its own "AI factory", but any company thinking about running models seriously in-house - for regulatory, cost or data-sovereignty reasons - gains a real hardware alternative. This broadens the conversation we have about AI infrastructure: today it holds more than one answer, and that usually works in the buyer's favour.
## What it all adds up to
Twelve stories, one shared thread: **AI tools are maturing faster than our ways of controlling them** - while the hard infrastructure work (SAP, Linux, hardware) goes on and demands the same discipline as ever. Our role is in both places at once: we help you reach for the new (agents, automation, AI in SAP) without losing sight of the things that decide whether all of it is safe - identity, permissions, data, patches and oversight.
If any of these topics touches your organisation directly - an S/4HANA conversion, AI agent security, a kernel flaw on your servers or the choice of platform under SAP - [get in touch](/en/contact/). We start with a conversation and an assessment of where you stand, not with an offer.
---
*Curated by the SNOK team. The weekly review is our weekly selection from several hundred radar and industry items. Based on publicly available sources from the week of 21-24 July 2026. Informational material; it does not constitute legal or investment advice.*
---
## 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.