Ha az AI agent az ERP-be, a CRM-be vagy a pénzügyi rendszerbe is írhat, élesítés előtt tervezz hozzá külön, a modelltől független sandbox- és jogosultsági réteget. Az NVIDIA 2026. október 21-én jelentette be az OpenShell Reference Architecture-t, amelyet vállalati infrastruktúrán és edge-rendszereken futó agentek elkülönítésére, megfigyelésére és szabályozására szán.
A bejelentés önmagában nem indokol platformváltást. Akkor érdemes OpenShell-pilotot mérlegelned, ha saját vagy partner által üzemeltetett infrastruktúrán futtatnál belső rendszereket elérő agenteket. Ha SaaS-szolgáltatásban használod az AI-t, a jelenlegi eszközeidben állítsd be a szűk jogosultságot, a naplózást és a jóváhagyást. Az OpenShell bevezetése várhat.
Az OpenShell az agent és a rendszerek közé kerül
A GTC Berlin keynote összefoglalója öt részre bontja az agentet: modell, harness, sandbox, tudás és eszközök. Ebben a felépítésben a sandbox választja el a harnesst azoktól a rendszerektől, amelyekre az agent hatással lehet.
Az NVIDIA az OpenShellt nyílt forráskódú, szabályok alapján működő futtatási környezetként írja le. A sandbox kernelszinten választja el az agentet az általa elérhető rendszerektől. A vállalat szerint a jogosultságoknak, a szabályok érvényesítésének és a megfigyelésnek dinamikusan kell igazodniuk, mert minden indításkor más hozzáférésre lehet szükség. Az agent fájlokat, hálózatokat, erőforrásokat és eszközöket érhet el, ezért szűk jogosultságokra és megfigyelésre van szüksége.
A modell viselkedése nem helyettesíti a technikai korlátokat. A promptban szereplő tiltást olyan külső rétegnek kell érvényesítenie, amely ténylegesen megtagadja a nem engedélyezett fájl-, hálózati vagy ERP-műveletet. Ugyanezt a döntési helyzetet tárgyalja a külső műveleteket végző agentek korlátozásáról szóló útmutató.
Az ERP-t módosító agentnél maradjon emberi jóváhagyás
A jogosultságok külön kezelése ott számít a legtöbbet, ahol az agent adatot ír egy üzleti rendszerbe. Ilyen művelet lehet egy szállítói törzsadat módosítása, egy megrendelés előkészítése, egy CRM-státusz átállítása vagy pénzügyi adat rögzítése.
Az NVIDIA 2026. október 19-i GTC Berlin-beszámolója a Siemens erlangeni gyárában a Factory Operations Blueprinttel épített agentek munkafolyamatát írja le. Az agentek gyári adatok és tervezőeszközök alapján javasolnak lehetőségeket, majd a termelésirányító áttekinti a mérlegelendő szempontokat, és jóváhagyja a tervet, mielőtt az agent alkalmazza az engedélyezett módosításokat. A felépítése használható döntési mintát ad: az agent előkészítheti a műveletet, a jóváhagyást és a végrehajtás jogát külön kezeld.
Egy ERP-hez vagy pénzügyi rendszerhez kapcsolt agentnél ezeket a kontrollokat tervezd meg:
- minden futás csak a szükséges eszközökhöz és adatokhoz férjen hozzá;
- az olvasási és az írási jogosultság legyen külön kezelhető;
- a sandbox zárja ki a nem engedélyezett hálózati címeket;
- az agent működésétől független napló rögzítse a kérést, a jóváhagyást és a végrehajtást;
- visszafordíthatatlan vagy pénzügyi hatású művelet előtt legyen emberi jóváhagyás;
- a hozzáférést futás közben is lehessen visszavonni.
Az agent-jogosultságok Microsoft 365-ös kezeléséről külön döntési útmutató készült. Az OpenShell szélesebb infrastruktúra-kérdést vet fel: melyik réteg érvényesíti a szabályokat, amikor az agent több vállalati rendszert használ?
Az infrastruktúrád dönti el, hogy indokolt-e a pilot
Az NVIDIA európai GTC-beszámolója bankokat, fizetési szolgáltatókat és pénzügyi adatszolgáltatókat mutat be, amelyek nyílt súlyú modelleket futtatnak saját infrastruktúrán. A vállalat szerint európai cloud-partnerei is határt szabnak annak, hogy az agent mihez férhet hozzá és mit tehet.
| Helyzet | Mit tegyél most? | Miért? |
|---|---|---|
| Saját NVIDIA-infrastruktúrán futó agent belső rendszereket ér el | Kérd el a referenciaarchitektúra dokumentációját, és próbáld ki egy szűk munkafolyamaton. | A bejelentett felépítés ehhez a környezethez illeszkedik a legközvetlenebbül. |
| Szabályozott pénzügyi szervezet saját infrastruktúrán futtat nyílt súlyú modelleket | Vedd fel az OpenShellt a műszaki értékelésbe, és külön végezd el a jogi és biztonsági vizsgálatot. | A bemutatott európai pénzügyi példák ezt a működési modellt követik. |
| Az agent cloud-partner infrastruktúráján fut | Kérdezd meg, hogyan különíti el az agentet, hol érvényesíti a szabályokat, és hová kerülnek a naplók. | A szolgáltatónak egyértelmű határt kell szabnia az agent hozzáférésének és műveleteinek. |
| SaaS-agentet használsz saját GPU-infrastruktúra nélkül | Vizsgáld felül a jelenlegi szolgáltató jogosultsági, naplózási és jóváhagyási megoldásait. | A referenciaarchitektúrát vállalati infrastruktúrához és edge-rendszerekhez mutatták be. |
| Az agent csak belső tudásbázist olvas | Tartsd meg a szűk jogosultságot és a naplózást, de ne építs új infrastruktúrát pusztán a bejelentés miatt. | Az írási jogosultság hiánya csökkenti egy hibás művelet közvetlen hatását. |
| Még nincs agent-pilot | Előbb válaszd ki a munkafolyamatot, az adatokat és az engedélyezett műveleteket. | A sandbox csak konkrét eszközök és műveletek alapján értékelhető. |
A jogosultsági architektúrát a pilot előtt rögzítsd. Az OpenShell beszerzéséről a támogatott környezet, a teljes költség és az üzemeltetési felelősség alapján dönts.
Ha saját infrastruktúrán futó agent-rendszert tervezel, nézd meg a vállalati AI platformokról szóló oldalt. Vállalati AI platformok
A beszerzés előtt két kérdést tisztázz írásban
A referenciaarchitektúra a nyílt forráskódú OpenShell futtatási környezetre épül, de ez önmagában nem határozza meg a teljes költséget. Számolnod kell az infrastruktúrával, az integrációval, a szabályok karbantartásával, a naplókezeléssel és a biztonsági felügyelettel is.
Két nyitott kérdést rendezz még a műszaki értékelés előtt:
- Kérj írásos kompatibilitási nyilatkozatot a hardverkövetelményekről, a támogatott operációs környezetekről és a nem NVIDIA GPU-s futtatásról.
- Kérj tételes árat, teljes üzemeltetési költséget, támogatási feltételeket, valamint írásos tájékoztatást arról, mikor és milyen környezetben telepíthető a referenciaarchitektúra.
A szerződésben rögzítsd, hol tárolódnak a naplók, ki felel az incidenskezelésért, és hogyan cserélhető le később a sandbox vagy a szabályokat érvényesítő réteg. A nyílt forráskód önmagában nem oldja meg a támogatást és a szállítói függést.
A GDPR- és EU AI Act-vizsgálatot külön kell elvégezni. A sandbox és a naplózás segíthet a vállalati kontrollok kialakításában, de önmagában nem igazolja a jogszabályi megfelelést.
A pilotban a tiltott műveleteket is teszteld
Egy biztonsági pilot kevés, ha csak azt mutatja meg, hogy az agent elvégzi az engedélyezett feladatot. A rendszernek a tiltott műveleteket is meg kell tagadnia, és használható naplót kell készítenie róluk.
Az ellenőrzőlista hat próbát tartalmazzon:
- Az agent hozzáfér-e olyan ERP-rekordhoz, amely nem tartozik a feladatához?
- Meg tud-e hívni a jóváhagyott listán kívüli eszközt vagy hálózati címet?
- Megmarad-e az írási korlát akkor is, ha a felhasználói prompt mást kér?
- Leáll-e a művelet, ha a jóváhagyó elutasítja vagy figyelmen kívül hagyja a kérést?
- A naplóból rekonstruálható-e, milyen adatot olvasott, milyen eszközt hívott és mit módosított?
- Egy új futás friss, szűk jogosultságot kap-e a korábbi hozzáférés öröklése nélkül?
Külön értékeld az engedélyezett feladatok sikerét, a tiltott műveletek blokkolását, a jóváhagyási időt és a napló teljességét. Az OpenShell akkor ad üzleti értéket, ha ezeket a szabályokat következetesebben vagy kisebb üzemeltetési ráfordítással érvényesíti, mint a jelenlegi infrastruktúrád.
Kinek érdemes most OpenShell-pilotot indítania?
A pilot a szabályozott szektorban működő cégeknél és azoknál a középvállalatoknál indokolt, amelyek saját vagy partner által üzemeltetett NVIDIA-infrastruktúrán futtatnak belső rendszereket elérő agenteket. Válassz egy korlátozott, visszafordítható műveleteket tartalmazó munkafolyamatot, majd készíts jogosultsági mátrixot az adatokhoz, eszközökhöz és műveletekhez.
Ha főként SaaS-szolgáltatásban használsz agenteket, előbb a jelenlegi szolgáltató sandbox-, naplózási és jóváhagyási megoldásait vizsgáld felül. Ha még nincs agent-pilotod, először az üzleti munkafolyamatot és az engedélyezett műveleteket határozd meg.
A platformdöntés előtt négy feladatot végezz el:
- Írd le, mit olvashat és mit módosíthat az agent.
- Válaszd szét az olvasási, az írási és a jóváhagyási jogosultságokat.
- Teszteld az engedélyezett és a tiltott műveleteket ugyanabban a pilotban.
- Hasonlítsd össze a jelenlegi kontrollokat az OpenShell referenciaarchitektúrával, beleértve a költséget és az üzemeltetési felelősséget.