Ügynökök a fizikai világban: Google Home MCP, Nest és ami a szolgáltató cégeknek jön

Az AI-ügynökök eddig a képernyő mögött dolgoztak: leveleket válogattak, táblázatokat töltöttek ki, ügyféladatokat frissítettek a CRM-ben. A Google szeptember 16-án olyan lépést tett, amely ezt a határt elmossa, hiszen a Google Home MCP korai hozzáférésével a Claude, a ChatGPT és más AI-ügynökök lekérdezhetik és vezérelhetik a Nest termosztátokat, kapucsengőket és a Google Home-hoz kapcsolt többi eszközt. Ugyanezen a napon a UiPath arról számolt be, hogy az Integration Service nevű szolgáltatását ügynökkész csatlakozóréteggé alakította, amely egy helyen kezeli a hitelesítő adatokat, a műveleteket és az eseményforrásokat. A két hír első ránézésre távol esik egymástól, valójában mégis ugyanarról szól: az automatizálás kilép a képernyőről és elkezd hozzányúlni a radiátorhoz, a világításhoz meg a raktár páratartalmához.

A vásárlói oldalt, vagyis azt, hogy az ügyfeleid ügynökei hogyan keresnek és foglalnak, egy korábbi írásunk már körüljárta. Most a másik oldalra állunk: annak a cégnek a szemével nézzük a változást, amely szállodát, irodát vagy gyártócsarnokot üzemeltet, esetleg mások épületeit és berendezéseit tartja karban. A helyzetet 2026. szeptember 22-i állapot szerint vesszük végig: mit tud pontosan a Google Home MCP, használható-e Magyarországon, milyen helyzetekben spórolhat időt vagy hozhat bevételt egy ügynök, hogyan kell biztonságosan kezelni a parancsadás jogát, végül hogyan indíthatsz egy hónap alatt olyan pilotot, amelyből valódi döntés születik.

Röviden

• A Google Home MCP a Google 2026 szeptemberében korai hozzáférésben elindított MCP-szervere, amelyen keresztül az AI-ügynökök lekérdezhetik a Google Home-hoz kötött eszközök állapotát és előzményeit, illetve parancsot adhatnak nekik, például átállíthatják a Nest termosztátot.
• A Google dokumentációja szerint a használathoz Google Home Premium Advanced előfizetés, engedélyezett Home API-val rendelkező Google Cloud-projekt és OAuth 2.0 hitelesítés kell, a TechCrunch szerint az előfizetés havi 20 dollár, a korai hozzáférés pedig egyelőre csak az Egyesült Államokban indult el.
• Magyarország 2026. szeptember 22-i állapot szerint a Google Home Premium támogatott országai között sem szerepel, ezért egy hazai cég a Google Home MCP-t ma hivatalosan nem tudja használni, a mögötte álló mintát viszont más eszközökkel, például a nyílt forráskódú Home Assistant MCP-szerverével már most kipróbálhatja.
• Szállodában, irodában, gyártócsarnokban és a karbantartásban az ügynök első értelmes feladata az olvasás: figyel, összefoglal, jegyet nyit és javasol, a fizikai beavatkozást pedig szűk, előre rögzített keretek között vagy emberi jóváhagyással végzi.
• A biztonság alapja egy írásban rögzített jogosultsági mátrix arról, mit tehet az ügynök önállóan, mihez kell jóváhagyás és mi tilos mindenkor, ahogy a Google is eleve letiltja az ajtózárak nyitását.
• Egy olyan pilot, amely egyetlen helyszínre és egyetlen folyamatra szűkül, négy hét alatt megmutatja, hogy a reakcióidő, a kiszállások száma vagy az adminisztrációra fordított idő mérhetően javul-e.

Mi az a Google Home MCP és mit tudnak vele az ügynökök a Nest-eszközökkel?

A Google Home MCP a Google hivatalos MCP-szervere, amely a fejlesztői dokumentáció szerint közvetítőként áll az okosotthon-infrastruktúra és az AI-alkalmazások között. Rajta keresztül egy AI-ügynök lekérdezi az otthonokat, a helyiségeket és az eszközöket, látja a pillanatnyi állapotokat és az eseménynaplót, továbbá parancsot adhat az eszközöknek, például átállíthatja a Nest termosztátot.

Az MCP (Model Context Protocol) nyílt szabvány, amely egységes nyelvet ad az AI-alkalmazásoknak ahhoz, hogy külső rendszerekhez és adatforrásokhoz kapcsolódjanak. Olyan ez, mint egy univerzális csatlakozó: ha egy rendszernek van MCP-szervere, akkor bármelyik MCP-képes ügynök ugyanúgy tud hozzá kapcsolódni, így nem kell minden modellhez külön integrációt fejleszteni. Eddig főleg CRM-ek, táblázatkezelők és fejlesztői eszközök kaptak sorra MCP-szervert, a Google Home-mal viszont egy nagy gyártó a saját okosotthon-ökoszisztémáját nyitotta meg ugyanígy, vagyis a protokoll másik végén már nem adatbázis ül, hanem termosztát, kamera és kapucsengő.

A TechCrunch szeptember 16-i beszámolója szerint a Google Home MCP-n keresztül a Claude, a ChatGPT, a Hermes, az OpenClaw és a Google Antigravity is dolgozhat, a kezelhető eszközök köre pedig a Nest kapucsengőktől és termosztátoktól a Works with Google Home programba tartozó, Matter-kompatibilis eszközökig terjed. Az ügynök természetes nyelven kérdezhet és utasíthat: átnézheti a kamerák összefoglalóit, figyelheti az otthon eseményeit, kapcsolhatja az eszközöket, sőt a gazdája kérésére egyedi irányítópultot is építhet. A Google fejlesztői oldala öt eszközt (tool) sorol fel, minden művelet ezeken keresztül történik.

Az eszközök neve beszédes, a lényeg mégis a szerkezetben rejlik. Az öt eszközből négy csak olvas, a run_home_actions viszont ír, vagyis egyedül ez változtat a fizikai világon. Ez a felosztás a szolgáltató cégeknek is jó mintát ad, mert amit az ügynök olvas, az legfeljebb rossz következtetéshez vezet, amit viszont ír, az megemelheti a gázszámlát, lekapcsolhatja a raktár párátlanítóját vagy hajnalban felébresztheti a vendéget.

Mit nem tud (még) a Google Home MCP?

A Google fejlesztői dokumentációja meglepően nyíltan beszél a korlátokról, ami egy korai hozzáférésű terméknél kifejezetten jó jel. Automatizmusokat, vagyis a Google Home-ban beállítható, szabályalapú rutinokat a Home MCP-vel jelenleg nem lehet létrehozni és kezelni, így az ügynök reagálhat és parancsot adhat, állandó szabályt viszont nem ír. A szolgáltatás sebességkorlátokat és biztonsági védelmeket alkalmaz, a dokumentáció példája szerint letiltja az olyan érzékeny műveleteket, mint az ajtózárak nyitása. Az ismert hibák között szerepel, hogy egyes kísérleti képességek következetlenül viselkedhetnek, a válaszidő pedig a vártnál hosszabb lehet, ráadásul a jogosultság-ellenőrzés is hibázik: a leírás szerint jelenleg egyes Nest Aware Plus előfizetők is hozzáférnek, pedig a feltétel a Premium Advanced.

A figyelmeztetés sem hagy kétséget. Saját fordításunkban a Google úgy fogalmaz, hogy egy valódi otthon összekapcsolása egy AI-ügynökkel lehetővé teszi, hogy az ügynök a felhasználó nevében vezérelje az eszközöket, az ügynöktől függően pedig ez „váratlan vagy akár nem kívánt viselkedéshez” vezethet. Két további részlet különösen érdekes egy üzemeltetőnek. Az egyik, hogy az ismerős arcok (familiar faces) adataihoz külön, kifejezett hozzájárulás kell, amelyet csak az adott otthon kezelője (manager) adhat meg. A másik, hogy a Google szerint ha az otthont más háztartástagok is használják, akkor tájékoztatni kell őket arról, hogy az ügynök eszközöket vezérelhet és hozzáfér az otthon adataihoz. Irodában vagy szállodában a háztartástag helyére munkatárs és vendég kerül, ami már komoly adatvédelmi kérdés.

Egyszerű ítélet: a Google Home MCP ma kísérleti, fogyasztói szolgáltatás fejlesztői bejárattal, nem pedig vállalati épületfelügyeleti platform. Arra viszont kiváló, hogy megmutassa, merre tart a piac és mit érdemes addig rendbe tenni a saját épületeidben.

Használható a Google Home MCP egy magyar cégnél?

Hivatalosan jelenleg nem, mert a TechCrunch szerint a korai hozzáférés csak az Egyesült Államokban indult el, a Google Store súgójában felsorolt húsz ország között pedig, ahol a Google Home Premium előfizethető, Magyarország nem szerepel. A Google arra sem válaszolt, mikor és mely piacokra bővíti a szolgáltatást, így a hazai indulás időpontja ma nem ismert.

A Google fejlesztői dokumentációja és a TechCrunch beszámolója alapján a Google Home MCP használatához öt feltételnek kell egyszerre teljesülnie.

A Google Store súgóoldala szerint a Google Home Premium húsz országban érhető el, köztük Ausztriában, Németországban, Franciaországban, Olaszországban, Spanyolországban, az északi országokban, az Egyesült Királyságban és az Egyesült Államokban (Puerto Rico kivételével). A szomszédaink közül tehát egyedül Ausztria szerepel a listán, a Google Home MCP korai hozzáférése pedig még ezen a húsz országon belül is csak az amerikai előfizetőknek szól.

A Premium Advanced csomag a Google termékdokumentációja szerint 60 napos eseményalapú és 10 napos folyamatos videóelőzményt, valamint Gemini-alapú funkciókat (például AI-értesítéseket és videókeresést) ad. Ez azért lényeges, mert a kamerák összefoglalói és az eseménynapló a TechCrunch szerint az ügynök számára is elérhetők, vagyis egy kamerás rendszernél a termosztáttal együtt egy megfigyelési rendszert is az ügynök kezébe adsz.

Felmerülhet a kiskapu (amerikai fiók, VPN, tengerentúli számlázási cím), céges környezetben azonban ezt négy okból sem javasoljuk:

• A szolgáltatási feltételek kijátszása bármikor a fiók felfüggesztésével járhat, ami egy üzemeltetett épületben váratlan leállást jelent.
• Az épület, a vendégek és a munkatársak adatai így átgondolt adattovábbítási jogalap nélkül kerülnének egy amerikai szolgáltatóhoz, ami egyenes út a GDPR-problémához.
• Korai hozzáférésű, ismert hibákkal futó szolgáltatásra nem érdemes éles folyamatot építeni, pláne hivatalos támogatás nélkül.
• A dokumentáció nem tér ki arra, hogyan kezeli a szolgáltatás a több telephelyes, üzleti használatot, a Premium Advanced pedig alapvetően otthoni előfizetés.

A józan következtetés az, hogy a Google Home MCP egy magyar szolgáltató cégnek ma jelzés, nem termék. Azt jelzi, hogy a nagy platformok a fizikai eszközöket is megnyitják az ügynökök előtt, a mögötte álló mintát pedig már most ki lehet próbálni olyan eszközökkel, amelyek Európában is elérhetők.

Az automatizálás kilép a képernyőről: a UiPath ügynökkész csatlakozórétege

A UiPath az AI Agent Store hírösszesítője szerint szeptember 16-án jelentette be, hogy az Integration Service ügynökkész csatlakozóréteggé fejlődött, amely a kódoló ügynökök számára kezeli a hitelesítő adatokat, a műveleteket és az eseményforrásokat. Magyarán az ügynöknek nem kell ismernie a jelszavakat, elég tudnia, milyen műveleteket végezhet és milyen eseményekre kell figyelnie.

A UiPath nevét sokan az RPA-ból (robotic process automation) ismerik, vagyis azokból a szoftverrobotokból, amelyek emberi módon kattintgatnak a képernyőn. A cég termékoldala most úgy mutatja be az Integration Service-t, mint a vállalati automatizálást és a mesterséges intelligenciát kiszolgáló, ügynökkész csatlakozási réteget, amely három újrahasznosítható építőelemből áll. A műveletek (activities) olvasnak és írnak a külső rendszerekben, a triggerek eseményfigyelők, amelyek valós időben indítanak el egy munkafolyamatot, a kapcsolatok (connections) pedig szabályozott hitelesítést adnak, amelyet a műveletek és a triggerek közösen használnak. Kész csatlakozó van többek között a Salesforce-hoz, az SAP-hoz, a ServiceNow-hoz és a Slackhez, a belső hálózaton futó rendszerekhez pedig a Relay nevű komponens ad hozzáférést, a munkafolyamatok emellett MCP-szerverekhez is kapcsolódhatnak.

A hitelesítő adatok a termékoldal szerint központi széfben vannak, szerepköralapú hozzáférés-szabályozással, a kapcsolatok mappákhoz kötődnek, a rendszer pedig teljes naplót vezet arról, ki mikor fért hozzá egy hitelesítő adathoz, mikor használtak egy kapcsolatot és mikor indult el egy trigger. A csatlakozók életciklusát (állapotfigyelés, tokenfrissítés, kivezetés) is a platform kezeli. Ez unalmasan hangzik, pedig pontosan ez a különbség egy hétvégi kísérlet és egy üzembiztos rendszer között.

Miért éppen a csatlakozóréteg számít a fizikai világban?

Egy épület folyamatosan eseményeket termel: leesik a hőmérséklet, kinyílik egy ajtó, leáll egy kompresszor, offline lesz egy termosztát. A folyamatot itt nem ember vagy időzítő indítja, hanem az érzékelő, ezért a triggerek, vagyis az eseményfigyelők nélkül az egész nem működik. Jó példa erre az OpenAI Agents API, amely szeptember 10-én lépett nyilvános bétába: az AgentStack elemzése szerint a platformból hiányzik a triggerkezelés, a kész csatlakozókönyvtár, az OAuth, a naplózás és a költségek átlátható megjelenítése. Egy fizikai folyamatnál éppen ezek a hiányzó darabok a legfontosabbak, ezért kell közéjük egy csatlakozóréteg, például a UiPath, az n8n, a Make vagy a Zapier.

A trend az n8n oldalán is látszik: a platform 2.37.0-s kiadása augusztus 25-én hozta el az adminisztrátor által kezelt, példányszintű hitelesítő adatokat, vagyis azt, hogy a jelszavak és tokenek ne az egyes munkafolyamatokban szétszórva éljenek. Érdemes a teljes rendszert négy rétegben elképzelni:

• Eszközréteg: érzékelők, termosztátok, fogyasztásmérők, kamerák és gépvezérlők, amelyek adatot termelnek vagy parancsot fogadnak.
• Csatlakozóréteg: gyártói felhő API, a Google Home MCP, a Home Assistant, a UiPath Integration Service vagy az n8n, amely az eszközöket és az üzleti rendszereket (ERP, CRM, jegykezelő) egységesen elérhetővé teszi.
• Ügynökréteg: a nyelvi modell, amely értelmezi az eseményt, dönt és javasol, legyen az Claude, GPT vagy Gemini.
• Irányítási réteg: jogosultságok, napló, jóváhagyási lépések és vészleállító, ide tartozik például a WSO2 szeptember 16-án általánosan elérhetővé tett, Apache 2.0 licencű Agent Manager nevű ügynökirányítási rendszere is.

A július végén kiadott, 2026-07-28 verziójú MCP-specifikáció is ebbe az irányba mutat. A protokoll állapotmentes lett, így a szerver egyszerű terheléselosztó mögött is futtatható, a kérés metódusát és nevét pedig az Mcp-Method és az Mcp-Name HTTP-fejléc is jelzi. Ennek köszönhetően egy átjáró (gateway) vagy sebességkorlátozó a kérés tartalmának feldolgozása nélkül is dönthet, ami fizikai eszközöknél aranyat ér, hiszen az írási műveletekre sokkal szigorúbb korlátot szabhatsz, mint az olvasásra.

Milyen utak járhatók ma egy magyar szolgáltató cégnek?

Ma három reális út van: kisebb helyszíneken a nyílt forráskódú Home Assistant beépített MCP-szervere, a gyártói felhő API-k köré épített saját csatlakozás egy integrációs platformon keresztül, nagyobb épületeknél pedig a meglévő épületfelügyeleti rendszer adatainak bekötése. A Google Home MCP negyedik útként akkor kerül képbe, ha Európában is elérhető lesz.

A Home Assistant nyílt forráskódú okosotthon-platform, amelyet saját hardveren vagy szerveren futtatsz, így az eszközök adatai alapvetően a helyszínen maradnak. A projekt dokumentációja szerint a Model Context Protocol Server integráció a 2025.2-es verzióval érkezett és jelenleg az aktív telepítések 4,3%-a használja. Az ügynök csak azokat az eszközöket és entitásokat éri el, amelyeket a kezelőfelületen kifejezetten megosztasz vele, a hitelesítés OAuth-tal vagy hosszú élettartamú hozzáférési tokennel történik, a dokumentáció pedig a Claude Desktophoz és a ChatGPT-hez is ad beállítási mintát. Távoli eléréshez a Home Assistant példányát az internetről elérhetővé kell tenni, amit céges környezetben kizárólag jól védett módon, például titkosított alagúton keresztül szabad megoldani.

A második út a gyártói felhő. Sok üzleti termosztát, fogyasztásmérő és érzékelő saját felhős API-val érkezik, amely köré egy fejlesztő saját MCP-szervert építhet, vagy amelyet egy n8n-, Make- vagy UiPath-munkafolyamat köthet össze a jegykezelővel és az ERP-vel. Ennek az a nagy előnye, hogy pontosan te döntöd el, milyen műveletek léteznek egyáltalán: ha a szerveren nincs „ajtónyitás” nevű eszköz, akkor az ügynök sem tudja megnyitni az ajtót, akármit is írnak neki.

A harmadik út a nagyobb épületeké. Az épületfelügyeleti rendszer (BMS, building management system) egy szálloda, irodaház vagy csarnok fűtését, hűtését, szellőzését és világítását központilag vezérlő rendszer, amely jellemzően BACnet, Modbus vagy KNX protokollon beszél az eszközökkel. Ilyen környezetben az ügynök szinte kizárólag olvas: a BMS adatait egy átjárón vagy exporton keresztül kapja meg, a beavatkozás pedig a rendszer kezelőjénél marad.

Tapasztalatunk szerint a legtöbb hazai kis- és középvállalatnál ezek az utak keverednek: az irodában van néhány okostermosztát, a csarnokban egy régebbi BMS, a hibajegyek egy Odoo-ban vannak, a riasztások pedig valakinek a telefonjára futnak be. Ilyenkor azt kell megnézni, melyik adatforrás mögött van a legtöbb pénz vagy munkaidő, mert a pilotot ott érdemes kezdeni.

Példák: szálloda, iroda, gyártócsarnok, karbantartás

Az alábbi négy helyzet szemléltető példa képzeletbeli cégekkel és feltételezett számokkal, nem valós ügyféltörténet. Mindegyiknél ugyanazt a négy kérdést tesszük fel: mit olvas az ügynök, mit változtathat önállóan, mihez kell ember, illetve mi az, amihez soha nem nyúlhat.

Szálloda: a szoba felkészül a vendégre

Vegyünk egy képzeletbeli 28 szobás hévízi wellnesshotelt, ahol minden szobában okostermosztát van, a foglalásokat pedig szállodai foglalási és vendégnyilvántartó rendszer (PMS, property management system) kezeli. Tegyük fel, hogy ma a recepció naponta nagyjából 20 percet tölt azzal, hogy a termosztátokat az érkezésekhez és a távozásokhoz igazítja, a hiba pedig gyakran csak akkor derül ki, amikor a vendég fázik. Egy ügynökkel a folyamat így nézne ki:

• Az ügynök a PMS-ből tudja, hogy a 14-es szobába délután háromkor érkezik vendég, ezért két órával korábban a rögzített komfortsávba állítja a termosztátot.
• A kijelentkezés után a szobát takarékos üzemmódba teszi, amíg a takarítás és a következő foglalás ezt meg nem változtatja.
• Ha a vendég a szállodai chaten jelzi, hogy hideg van, az ügynök a rögzített sávon belül két fokot emelhet, ha pedig ez nem elég, jegyet nyit a karbantartásnak és erről a vendéget is tájékoztatja.
• Éjszaka rövid összefoglalót ír a reggeli műszaknak arról, melyik termosztát nem válaszol, illetve hol tér el tartósan a mért és a beállított hőmérséklet.

A napi 20 perc havonta körülbelül 10 óra (20 perc × 30 nap = 600 perc), amelyet a recepció a vendégekre fordíthat. Az energiamegtakarításra szándékosan nem mondunk számot, mert az a szigeteléstől, a fűtési rendszertől és az időjárástól függ, a pilot viszont a fogyasztásmérő adataival ezt is megmutatja. A vendégoldalon egy szabályra különösen figyelj: az Európai Unió mesterségesintelligencia-rendeletének (EU AI Act) átláthatósági kötelezettsége a Gibson Dunn összefoglalója szerint 2026 augusztusa óta alkalmazandó, vagyis jelezni kell, ha valaki AI-rendszerrel lép kapcsolatba, így a chaten is egyértelmű legyen, hogy a vendég egy géppel beszél. Kamerához, zárhoz és riasztóhoz ebben a forgatókönyvben az ügynök egyáltalán nem kap hozzáférést.

Iroda: a tárgyaló bemelegít, este minden lekapcsol

Képzelj el egy 35 fős budapesti könyvelőirodát két szinten, négy tárgyalóval, okostermosztátokkal és egy tucat Matter-kompatibilis okosdugaljjal, amelyekre a kávéfőzők, a vízforralók és a nyomtatók csatlakoznak. Ez pontosan az a méret és eszközpark, ahol a Google Home MCP-hez hasonló, fogyasztói eszközökre épülő megoldás jól illene, ha itthon is elérhető volna, addig pedig a Home Assistant tölti be ugyanezt a szerepet.

• Az ügynök a közös naptárból látja, hogy a nagy tárgyalóban reggel kilenckor ügyféltalálkozó lesz, ezért fél órával előtte beállítja a hőmérsékletet.
• Este fél hétkor végignézi az eszközök állapotát, a bekapcsolva maradt kávéfőzőt, klímát vagy nyomtatót pedig egy Teams-üzenetben jelzi az irodavezetőnek, aki egyetlen válasszal kikapcsoltathatja őket.
• Hétfő reggel összefoglalót küld a hétvégéről: volt-e áramszünet, maradt-e offline eszköz, mért-e szokatlan hőmérsékletet valamelyik érzékelő.

Tegyük fel, hogy az irodavezető ma munkanaponként 10 percet tölt a zárás előtti körbejárással, ami havi 21 munkanappal számolva 210 perc, vagyis nagyjából három és fél óra. Ez önmagában nem nagy tétel, a valódi érték az elkerült kockázatban van: a hétvégére bekapcsolva maradt klíma vagy a pénteken leállt szerverszobai hűtés hétfő reggelig senkinek nem tűnik fel.

Gyártócsarnok: az ügynök figyel, az ember kapcsol

Vegyünk egy képzeletbeli 45 fős kecskeméti fémmegmunkáló üzemet porfestő sorral, festékraktárral és két kompresszorral. Itt az első és legfontosabb szabály az, hogy az ügynök a gépekhez nem nyúl, a szerepe a figyelés, az összefoglalás és a jegynyitás.

• A festékraktár hőmérséklet- és páratartalom-érzékelőit figyeli, eltérés esetén pedig jegyet nyit az Odoo karbantartási moduljában, mellékelve az utolsó 24 óra görbéjét és a lehetséges okokat.
• A kompresszorok áramfelvételét hetente összeveti a korábbi hetekkel, a szokatlan trendet pedig javaslatként küldi a karbantartásvezetőnek, még mielőtt a gép leállna.
• Műszakváltáskor az eseménynaplóból összefoglalót ír a riasztásokról, a leállásokról és a nyitott jegyekről, így a műszakátadás nem egy papírfecnin múlik.

A szabályozási határt is érdemes ismerni. A Gibson Dunn összefoglalója szerint az EU AI Act termékekbe épített AI-rendszerekre (például a gépek biztonsági funkcióira) vonatkozó magas kockázatú szabályai a Digital Omnibus megállapodás nyomán 2028. augusztus 2-től alkalmazandók. Egy olvasó, jegyet nyitó ügynök ettől nagyon messze van, ha viszont egyszer beleszólna a gépvezérlésbe vagy a biztonsági rendszerekbe, már egészen más szabályozási és felelősségi térben mozognánk.

Karbantartás és facility management: a hiba bejelentkezik

Tegyük fel, hogy egy győri fűtés- és klímaszerviz három szerelővel és 180 karbantartási szerződéssel dolgozik családi házakban és kis irodákban. Ma a munka reaktív: az ügyfél akkor telefonál, amikor már hideg van, a szerelő pedig sokszor úgy indul el, hogy nem tudja, mit talál a helyszínen. Az ügyfél írásos hozzájárulásával a szerviz olvasási hozzáférést kaphat a fűtéssel kapcsolatos eszközadatokhoz, akár a gyártói felhőn, akár egy olyan Home Assistant-példányon keresztül, amely csak a fűtési entitásokat osztja meg.

• Az ügynök szétválogatja a riasztásokat, a valódi hibát pedig elkülöníti az átmeneti internetkimaradástól.
• Előzetes diagnózist ír a szerelőnek az eseménynapló alapján, jelzi a valószínű alkatrészt és a sürgősséget.
• A jóváhagyott kiszállásokat útvonal szerint csoportosítja, a látogatás után pedig elkészíti a munkalap tervezetét.

Számoljunk egy feltételezett példával. Ha szerződésenként évente átlagosan 1,5 hibabejelentés érkezik, az 270 kiszállás. Ha az előzetes diagnózis és a távoli ellenőrzés miatt ezek 15%-a kiszállás nélkül megoldható, az évente nagyjából 40 kiszállással kevesebb (270 × 0,15 = 40,5). Ha egy kiszállás belső költsége (munkaidő, üzemanyag, kiesett másik munka) feltételezésünk szerint 25 000 Ft, a megtakarítás évente körülbelül 1 millió Ft, a szerelők ideje pedig a jobban fizető munkákra szabadul fel. Ennél is érdekesebb az üzleti modell: a távfelügyelet havidíjas szolgáltatásként is eladható, ami kiszámítható, visszatérő bevételt hoz.

Milyen adatokat lát az ügynök és mit mond erről a GDPR?

Az ügynök mindent lát, amire a hozzáférése kiterjed: eszközállapotokat, eseménynaplót, jelenlétre utaló adatokat, a Google Home MCP esetén pedig a kamerák összefoglalóit is. Ezek jelentős része személyes adat, amelyre a GDPR teljes eszköztára vonatkozik, a munkahelyen ráadásul a munkavállalók ellenőrzésére vonatkozó munkajogi szabályok is.

Sokan azt hiszik, hogy egy termosztát adata semleges. Egy szállodai szoba hőmérsékletgörbéje azonban megmutatja, mikor van bent a vendég, egy tárgyaló foglaltsága azt, ki mikor dolgozik, egy iroda esti eszközállapota pedig azt, ki marad bent utoljára. Ezek önmagukban is személyes adatok lehetnek, ha egy konkrét emberhez köthetők, a kameraösszefoglaló pedig már egyértelműen az. Az ismerős arcok felismeréséhez biometrikus adatot kell kezelni, amely a GDPR szerint a személyes adatok különleges kategóriájába tartozik, ezért ezt a funkciót üzleti környezetben, munkatársakra vagy vendégekre egyszerűen ne kapcsold be.

Három magyar szempontra külön figyelj. Az első a munkajog: a munka törvénykönyve szerint a munkáltató a munkavállalót csak a munkaviszonnyal összefüggő magatartása körében ellenőrizheti, az ehhez használt technikai eszközről pedig előzetesen tájékoztatnia kell, ezért egy ügynök által figyelt irodai jelenlétadatról a munkatársaknak tudniuk kell, egyéni teljesítményértékelésre pedig nem használható. A második a hatásvizsgálat: ha a rendszer rendszeresen és nagy mennyiségben figyel embereket, a GDPR adatvédelmi hatásvizsgálatot írhat elő, a magyar gyakorlatot pedig a Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH) állásfoglalásai alakítják. A harmadik az adattovábbítás: ha az ügynök egy amerikai nyelvimodell-szolgáltatón fut, az épület adatai az EU-n kívülre kerülhetnek, amihez adatfeldolgozói szerződés és megfelelő továbbítási jogalap kell.

A jó hír az, hogy az adatminimalizálás itt technikailag könnyen megvalósítható. Néhány bevált alapelv:

• Csak azokat az eszközöket oszd meg az ügynökkel, amelyek a konkrét feladathoz kellenek, a Home Assistant megosztott entitásai pontosan erre valók.
• A jelenlétadatot helyiség szintjén és összesítve kezeld, ne személyhez kötve.
• Kamerát és ismerősarc-felismerést a pilotba ne vonj be.
• Rögzítsd, meddig tárolod az ügynök naplóit és összefoglalóit, a határidő lejártával pedig töröld őket.
• A vendégeket és a munkatársakat közérthető tájékoztatóban értesítsd arról, mit figyel a rendszer és miért.

Ki adhat parancsot az ügynöknek és hogyan vonod vissza a jogát?

Parancsot csak az adhat, akit egy előre rögzített jogosultsági mátrix erre felhatalmaz, az ügynök pedig csak a neki kiosztott, szűk műveleti kört használhatja. A visszavonásnak egy lépésben, percek alatt kell működnie: a hozzáférési token visszavonásával, a kapcsolat letiltásával és egy mindenki által ismert vészleállítóval.

A kérdésnek két oldala van. Az egyik, hogy ki szólhat az ügynökhöz: csak a kijelölt munkatársak egy hitelesített csatornán, vagy a vendég is a szállodai chaten, esetleg bárki, aki bent van egy Teams-csatornában? A másik, hogy az ügynök mit tehet, amikor valaki szól neki. A kettőt külön kell kezelni, mert egy ügynök nemcsak a gazdájától kap szöveget, hanem egy foglalási megjegyzésből, egy eszköz nevéből vagy egy beérkező levélből is. Ha ezekben utasításnak látszó mondat van (ezt hívják promptinjekciónak), az ügynöknek adatként kell kezelnie, nem parancsként. A legbiztosabb védekezés az, ha a veszélyes művelet technikailag nem is létezik a számára, ahogy a Google Home MCP esetében az ajtózár nyitása sem.

Minden ügynöknek legyen egy megnevezett emberi gazdája is, aki felel a beállításaiért, látja a naplót és jogosult leállítani. Ez nem bürokrácia: egy szombat esti riasztásnál ettől függ, hogy valaki öt perc alatt reagál, vagy mindenki a másikra vár.

Mit tanulhatsz a szeptemberi ügynökincidensekből?

Szeptember 7-én kiderült, hogy a LiteLLM nevű, sokak által használt modellátjáró MCP-hitelesítésében aktívan kihasznált bejelentkezés-megkerülési hiba volt, amelyen keresztül a csatolt eszközök is elérhetővé váltak. A tanulság egyszerű: a csatlakozóréteg maga is támadási felület, ezért a frissítéseket azonnal telepíteni kell, az átjárót pedig nem szabad védelem nélkül az internetre tenni. Szeptember 17-én a spanyol adatvédelmi hatóság egy lehetséges, ügynök által végrehajtott adatszivárgásról számolt be, amelyben a bejelentkezés, a rendszer feltérképezése és a személyes adatok elérése is szerepelt, a kiváltó okot még vizsgálják. Szeptember 21-én pedig az ENSZ 40 tagú független tudományos panelje az elővigyázatosság elvére hivatkozva arra kérte a kormányokat, hogy fékezzék meg az AI-ügynököket.

A gyártók is mozdulnak. A Moveworks szeptember 14-i frissítése után a sikertelen vagy üres eszközhívás kifejezett hibaállapotot ad vissza, nem pedig látszólagos sikert, a Microsoft Agent Framework 1.19.0-s verziója pedig MCP-munkamenet-szűkítést és biztonsági korlátozásokat hozott. A fizikai világban a Moveworks-féle tanulság különösen fontos, mert az, hogy az ügynök azt mondja, beállította a termosztátot, nem jelenti, hogy a termosztát tényleg be van állítva. Egy jól megírt folyamat ezért minden írási művelet után visszaolvassa az eszköz állapotát, eltérés esetén pedig szól.

A visszavonás lépésről lépésre

• Nyomd meg a vészleállítót: ez egy olyan kapcsoló a csatlakozórétegben (például az MCP-átjáró vagy az n8n egy beállítása), amely egyetlen mozdulattal letilt minden írási műveletet, az olvasást viszont meghagyja.
• Vond vissza az ügynök OAuth-tokenjét vagy hozzáférési tokenjét ott, ahol kiadtad: a Google-fiókban, a Home Assistant felhasználói beállításaiban vagy a gyártói portálon.
• Cseréld le a kapcsolódó jelszavakat és API-kulcsokat, ha a legkisebb gyanú is felmerül, hogy kiszivároghattak.
• Nézd át a naplót, mit csinált az ügynök az elmúlt 24 vagy 48 órában és milyen parancsot kitől kapott.
• Állítsd vissza az érintett eszközöket kézi, ismert alapállapotba.
• Értesítsd az érintetteket, személyes adatokat érintő incidensnél pedig vizsgáld meg, kell-e a GDPR szerint 72 órán belül bejelentést tenni a NAIH-nál.
• Az írási jogot csak a kiváltó ok megértése és javítása után kapcsold vissza, először újra olvasási módban.

Cyber Resilience Act: új bejelentési szabályok a csatlakoztatott eszközökre

Az Európai Unió kiberellenálló-képességi rendelete (Cyber Resilience Act, CRA) a digitális elemeket tartalmazó termékek, például az okoseszközök és a szoftverek kiberbiztonsági követelményeit szabályozza. Az Európai Bizottság tájékoztatása szerint szeptember 11-e óta a gyártóknak be kell jelenteniük a termékeiket érintő, aktívan kihasznált sérülékenységeket és súlyos incidenseket.

A határidők szigorúak: a korai figyelmeztetést a tudomásszerzéstől számított 24 órán belül, a részletes bejelentést 72 órán belül kell megtenni, a zárójelentést pedig aktívan kihasznált sérülékenységnél legkésőbb 14 nappal a javítás elérhetővé válása után, súlyos incidensnél a bejelentést követő egy hónapon belül. A bejelentés kizárólag az ENISA által működtetett egységes bejelentési platformon (Single Reporting Platform) keresztül történik. A rendelet többi fő kötelezettsége 2027. december 11-től alkalmazandó.

Egy szállodát vagy irodát üzemeltető cég jellemzően felhasználó, nem gyártó, így a bejelentés nem őt terheli. A CRA mégis két módon érinti. Beszerzéskor érdemes megkérdezni, meddig ad a gyártó biztonsági frissítést egy termosztátra vagy átjáróra és hogyan kezeli a sérülékenységeket, mert egy MCP-re kötött eszköz hibája most már az ügynökön keresztül is kihasználható lehet. Ha pedig saját márkás eszközt vagy firmware-t hozol forgalomba, például egy karbantartó cégként saját távfelügyeleti dobozt adsz az ügyfeleidnek, akkor jogásszal tisztázd, nem minősülsz-e gyártónak.

Hogyan indíts pilot-projektet egy hónap alatt?

Egy hónap elég egy pilotra, ha egyetlen helyszínre, egyetlen folyamatra és egyetlen mérhető célra szűkíted, az első hetekben pedig az ügynök csak olvas és javasol. A négy hét menete: felmérés és célkitűzés, csatlakoztatás olvasási joggal, árnyéküzem, végül korlátozott írási jog és döntés.

• Válassz egyetlen fájdalompontot, amelynek forintban kifejezhető ára van, például a felesleges kiszállásokat, a vendégpanaszokat vagy az adminisztrációra menő órákat.
• Rögzítsd a kiinduló számokat az elmúlt három hónap adataiból, mert ezek nélkül a pilot végén csak benyomásaid lesznek.
• Készíts eszközleltárt arról, milyen eszköz van a helyszínen, milyen protokollon kommunikál, van-e API-ja és ki felel érte.
• Válaszd ki a csatlakozóréteget a korábbi, utakat összehasonlító táblázat alapján.
• Írd le a jogosultsági mátrixot és állítsd be a vészleállítót, mielőtt bármi élesedne.
• A második és a harmadik héten az ügynök csak olvas és javasol (árnyéküzem), egy ember pedig minden javaslatot jónak vagy rossznak jelöl.
• Ha a javaslatok túlnyomó többsége megállja a helyét (jó célérték a tízből kilenc), kapcsold be a mátrix szerinti szűk írási jogot.
• A negyedik hét végén vesd össze az eredményt a kiinduló számokkal és hozz írásos döntést.

A modellköltséget a felépítés sokkal jobban befolyásolja, mint a modellválasztás. Vegyük a szállodai példát kétféle felépítéssel, saját becslésünk szerint futásonként 3 000 bemeneti és 300 kimeneti tokennel (a token a szövegfeldolgozás elszámolási egysége), kerekített 320 Ft-os dollárárfolyammal. Az olcsó kategóriát a Meta Muse Spark 1.3 listaárával (1,25 dollár bemeneti és 4,25 dollár kimeneti millió tokenenként) szemléltetjük, bár ez elsősorban kódolási modell, a drága kategóriát pedig a GPT-6 Astra 10 és 50 dolláros árával.

A számítás menete az első sorban: napi 96 futás 30 napon át 2 880 futás, ez 8,64 millió bemeneti token (10,80 dollár az olcsó modellnél) és 864 000 kimeneti token (3,67 dollár). A tanulság az, hogy ha egy egyszerű küszöbszabály (például „ha a mért hőmérséklet 30 percig két fokkal a beállított alatt marad”) szűri az eseményeket és a nyelvi modell csak a kivételekkel foglalkozik, akár tizedére is csökkenhet a költség, miközben az ügynök figyelme is a valódi eltérésekre összpontosul.

A pilot végén ezeket a mérőszámokat érdemes összevetni a kiinduló állapottal:

• a hibák észlelésétől a reakcióig eltelt idő,
• a kiszállások és a helyszíni ellenőrzések száma,
• a téves riasztások aránya,
• az adminisztrációra fordított munkaórák,
• a vendég- vagy ügyfélpanaszok száma,
• ahol mérhető, az energiafogyasztás a fogyasztásmérő szerint.

Kinek éri meg most és kinek jobb kivárni?

Most annak éri meg belevágni, akinek már vannak hálózatra kötött eszközei és van egy ismétlődő, pénzbe kerülő problémája, például sok felesleges kiszállás vagy gyakori panasz. Kivárni annak érdemes, akinek nincsenek megbízható érzékelői, akinél egy egyszerű időzítő is megoldja a gondot, vagy akinél a folyamat biztonságkritikus.

Most érdemes elindulni:

• Karbantartó és facility management cégeknek sok szerződéssel, mert náluk a megspórolt kiszállás és a havidíjas távfelügyelet közvetlenül pénzben mérhető.
• Szállodáknak és apartmanházaknak, ahol már vannak okostermosztátok és van foglalási rendszer, mert a kettő összekötése gyorsan mérhető eredményt ad.
• Több telephelyes irodáknak, ahol a zárás utáni ellenőrzés és a hétvégi események figyelése ma valakinek a szabadidejét viszi.

Jobb még várni:

• Ha nincsenek hálózatra kötött eszközeid, mert ilyenkor először érzékelők és adatok kellenek, az ügynök ráér.
• Ha a probléma egy heti időzítővel vagy egy egyszerű szabállyal is megoldható, mert akkor felesleges nyelvi modellért fizetni.
• Ha a folyamat biztonságkritikus (gépvezérlés, gáz, tűzvédelem), mert ott ma nincs helye írási joggal rendelkező ügynöknek.

Akár most indulsz, akár kivársz, három dolgot már idén érdemes megcsinálni: egy eszközleltárt, egy első jogosultsági mátrixot és egy beszerzési szabályt, amely szerint új eszközt csak nyitott API-val és vállalt biztonsági frissítési idővel veszel. Ha a Google Home MCP vagy egy hasonló szolgáltatás megérkezik Európába, ezekkel a lépésekkel a hátad mögött hetek alatt tudsz reagálni, nem hónapok alatt.

Miben segít a Convergo?

A Convergo abban segít, hogy az AI-ügynökök a fizikai világban is kiszámíthatóan és biztonságosan dolgozzanak. Az IT audit és digitális tanácsadás keretében felmérjük az eszközparkodat, az adatforrásaidat és a jogosultságokat, az egyedi AI-integráció során pedig megépítjük a csatlakozást a termosztátok, az érzékelők és az ügynök között, szűk műveleti körrel és vészleállítóval. A workflow automatizáció (jellemzően n8n) köti össze az eseményeket az Odoo-val vagy a jegykezelőddel, így a riasztásból munkalap lesz. Az első lépés egy ingyenes egyeztetés, ahol kiválasztjuk azt az egy folyamatot, amelyen egy hónap alatt kiderül, megéri-e továbblépni.