A politika nem újdonság, hanem egységesítés
Az SAP, vállalva ügyfelei üzleti folyamatainak felhőbeli védelmét, most minden termékére egységes és átlátható szabályozást vezetett be az API-használatra. Sokan úgy értelmezték a megújított szabályozást, mintha további megkötéseket hozna, ám valójában nem új szabályokat vezet be, hanem összefog és pontosít egy már évek óta érvényben lévő rendszert a különböző SAP-megoldásokban. Olyan funkciókról van szó, amelyek eddig is léteztek, még ha nem voltak minden esetben teljesen egységesek.
Az SAP-n belül az olyan jelentős termékek esetében, mint az S/4HANA vagy a SuccessFactors, eddig is voltak részletes dokumentációval kísért, az API-kra vonatkozó mennyiségi és hozzáférési szabályozások. A mostani egységesítésre az MI-alapú autonóm ügynökök elterjedése miatt van szükség: ezek ugyanis olyan forgalmat és terhelést okozhatnak az API-felületeken, amelyekre azokat eredetileg nem tervezték.
Mit tiltanak és mit nem érintenek az új API-szabályok?
Sokan aggódtak, hogy évtizedekig fejlesztett saját SAP-bővítményeik, adatkapcsolataik vagy ABAP-interfészeik is tiltás alá kerülhetnek. Ez azonban félreértés: az SAP kizárólag a saját, belső, soha nem dokumentált és ügyfelek felé soha nem ajánlott API-jait fogja tiltani. A saját fejlesztésű interfészek – ha az úgynevezett Z-namespace-ben készültek – nem esnek a tilalom alá. Az SAP Private Cloud-ügyfelek eddig is szabadon fejleszthettek, ez a szabadság nem szűnik meg.
Az SAP kizárólag azokat a beépített, nem publikált, nem támogatott, például ODP-RFC típusú belső interfészeket minősíti szigorúan tiltottnak, amelyek már korábban is ilyen besorolásúak voltak. Ezeket az SAP jegyzetekben és automatikus eszközeiben is kiemelten jelzi, hogy az ügyfelek még a fejlesztés korai szakaszában felismerhessék a tiltott interfészek használatának veszélyét.
Az MI-alapú rendszerek kihívásai az integrációban
Ami ezután történt, az mindenkit meglepett: az MI-alapú rendszerek teljesen új szintre emelték az API-használatot. Korábban az integrációs eszközök kizárólag tranzakciós adatok lekérdezésére szolgáltak – például értékesítési rendelések, készletbevétel. Ezeket előre meghatározott, ember által irányított üzleti folyamatok hívták meg. Az MI-ügynökök azonban már képesek a teljes üzleti folyamatok, adatstruktúrák, kapcsolatok, jelentések szemantikai értelmezésére is: értik, hogy egy főkönyvi tétel miként kapcsolódik az üzleti eseményekhez, felismerik az entitások közötti kapcsolatokat. Az SAP üzleti objektummodelljének teljes szellemi tartalmát – vagyis a vállalat több évtizedes tudásának leképezését – is képesek elemzésre felhasználni.
Mindez olyan feszültséget teremt, amelyben az API-használat szabályai elengedhetetlenné válnak: nem lehet megengedni, hogy az MI-ügynökök nagy tömegben és ellenőrizetlenül kutassanak a rendszerekben.
Valós biztonsági fenyegetések: ellátási lánc, sebezhetőségek
A szoftverbiztonság szempontjából a helyzet nem elméleti: a szabályzat közzétételének hetében jelent meg például a Mini Shai-Hulud nevű npm-kártevő, amely több száz vállalati csomagot fertőzött meg. SAP-ökoszisztémához tartozó eszközök is érintettek lettek – ennek kezelésére az SAP azonnali biztonsági jegyzetet adott ki. Az LLM-alkalmazások biztonsági problémáit (pl. prompt injection, eszkalációs sebezhetőségek) rendszeresen dokumentálják. Friss kutatások szerint az MCP (Model Context Protocol) implementációk túlnyomó többsége statikus, hosszú életű hitelesítő adatokat használ, illetve számos azonosítható sebezhetőség található bennük; egyetlen kompromittált MCP-csomag akár százezres nagyságrendű fejlesztői környezetet veszélyeztethet.
Az MI-ügynökök, amelyek teljes hozzáférést kapnak az SAP-adatmodell értelmezéséhez, és MCP-szervereken keresztül működnek, új, emelt kockázati kategóriát képviselnek – ezek a rendszerek nem pusztán produktivitási eszközök, hanem ugródeszkát nyújtanak kibertámadóknak is.
Az SAP válasza: nyitott, de felügyelt integráció
A Model Context Protocol önmagában nem képes komplex SAP-üzleti folyamatokat lefuttatni. Egy egyszerű adathívásnál az MCP sokkal több erőforrást fogyaszt: például egy egyszerű menedzser-keresés a SuccessFactors rendszerben akár hét és félszeres költséget okoz az MCP-vel, mint egy jól hangolt, kontextusérzékeny módszerrel. Az MCP nem valódi automatizációt, hanem költséges és megbízhatatlan megoldást jelent komplex SAP-rendszerek esetén.
Az SAP válasza nem a zárkózás, hanem a megfelelő architektúrák létrehozása lett: az API-szabályzat dokumentált, közösen fejlesztett architektúrákra épül, amelyeket az SAP partnereivel közösen hoz létre, publikál az SAP Architecture Centerben, és folyamatosan frissít az ügyféligényekhez igazodva.
Kiemelt példa az SAP Joule és a Microsoft 365 Copilot együttműködése: két MI-rendszer integráltan, de egymás biztonsági alapelveit tiszteletben tartva működik. Az MI-ügynökök számára a hivatalos út az SAP Agent Gateway az A2A-protokollon át, amelyhez nyilvános referenciamodellek érhetők el. Az SAP Knowledge Graph, a Datasphere és a BDC szolgáltatják azt a kontextust, amellyel a kapcsolat üzletileg is értelmezhető lesz.
Az SAP aktív résztvevője a Linux Foundation égisze alatt futó A2A-szabványok kidolgozásának, társelnöke a hitelesítési és jogosultsági architektúracsoportnak, így irányítja, miként történjen az MI-ügynökök vállalati szintű hitelesítése és integrációja – nem kapuőri szerepet játszik, hanem valódi közösségi fejlesztő.
Az irány a felügyelt nyitottság
Az SAP nem zárja le az integrációs lehetőségeket, hanem biztosítja a megfelelő alapokat ahhoz, hogy az MI-ügynökök vállalati szinten, biztonságosan, fenntartható módon működjenek együtt SAP-rendszerekkel. Az új szabályozás arról gondoskodik, hogy a nyitottság mellett az ellenőrizhetőség, biztonság és megbízhatóság megmaradjon, valódi vállalati szintű garanciákat kínálva az MI-vezérelt jövőben is.
