Néhány hete készítettem egy rövid videót azoknak, akik most ismerkednek a Google Cloud-ökoszisztémával vagy a Geminivel, mert azt tapasztalom, hogy sokan itt akadnak el már az első lépésnél. Pedig ennél egyszerűbb dolog nem is lehetne.
Az első lépések nem egyszerűek, de itt más a helyzet: az ember azt hiszi, hogy a Google AI-hoz és a Google Cloudhoz külön-külön fiókokat kell létrehoznia. Ez nem igaz. Egy meglévő Gmail-fiók pontosan elég ahhoz, hogy az egész ökoszisztémát bejárd.
Négy URL, egy fiók
A videóban négy belépési pontot mutatok meg, mindegyiket ugyanazzal az e-mail-címmel:
Ez a négy hely gyakorlatilag lefedi a Google AI és Cloud ökoszisztémájának egészét. Nincs itt semmi extra regisztráció, nincs elveszett jelszó egy külön fejlesztői fiókhoz, nincs felesleges adminisztráció.
Miért fontos ez?
Aki most vág bele a felhő vagy az AI világába, annak az első akadály gyakran nem technikai, hanem szervezési: hova is kattintsak, melyik fiókkal, melyik felületen. Ha ez az első lépés egyszerű, sokkal nagyobb eséllyel megy tovább valaki a következőre is. Ez pontosan az a simplicity-elv, amit enterprise környezetben is vallok: előbb működjön egyszerűen, utána lehet bővíteni.
Mielőtt megnézed
Ha eddig azt hitted, hogy a Google Cloud vagy a Gemini kipróbálásához külön fiókra vagy bonyolult regisztrációra van szükséged, a videó pontosan azt mutatja meg, hogy ez nem így van. Egy fiók, négy URL, és már úton is vagy a felhő és az AI világába.
Az elmúlt két-három évben látványosan megváltozott az, ahogyan szoftvert fejlesztünk. A GitHub Copilot, a különböző AI-alapú kódgenerátorok és a nagyobb language modelek mára ott vannak szinte minden fejlesztőcsapat eszközkészletében. Gyorsabb a munka, több kód születik rövidebb idő alatt – és ezzel együtt egy olyan kérdés is egyre élesebb: ki felel azért, ami ebből a kódból „kijön”?
Az Európai Unió válasza erre egyértelmű. És hamarosan kötelező érvényű lesz.
Mi az EU Cyber Resilience Act, és kit érint?
Az EU Cyber Resilience Act, röviden CRA, az Európai Unió első olyan horizontális kiberbiztonsági rendelete, amely gyakorlatilag minden szoftver- és hardvertermékre vonatkozik, amelyet az EU-ban értékesítenek. Nem ágazatspecifikus, nem csupán a kritikus infrastruktúrára szól – a hatálya széles. Ha szoftvert fejlesztesz és az EU-ban értékesítesz, a CRA téged is érint.
Két dátumot érdemes most megjegyezni. 2026. szeptember 11-től életbe lépnek az aktívan kihasznált sebezhetőségek kötelező bejelentési előírásai. 2027. december 11-től pedig minden egyéb kötelezettség teljes egészében érvénybe lép – beleértve a biztonságos tervezési elvárásokat, a sebezhetőség-kezelési folyamatokat és a dokumentációs kötelezettségeket.
Mi változik a fejlesztési gyakorlatban?
A CRA lényege, hogy a biztonságot nem lehet utólag ráhúzni egy termékre. A rendelet előírja, hogy a biztonságnak a fejlesztési életciklus minden szakaszába be kell épülnie – a tervezéstől a kódoláson át az üzembe helyezésig és az azt követő karbantartásig. Ezt angolul „secure by design” elvnek nevezik, és a CRA ezt jogilag kikényszeríthetővé teszi.
Három területen érdemes különösen figyelni.
Az átláthatóság: A rendelet előírja az ún. Software Bill of Materials, röviden SBOM elkészítését. Ez lényegében egy részletes összetevőlista arról, hogy egy szoftvertermék milyen komponensekből áll – beleértve a felhasznált nyílt forráskódú könyvtárakat és harmadik féltől származó elemeket. Aki eddig ezt nem csinálta rendszeresen, annak el kell kezdenie.
A sebezhetőség-kezelés folyamata: A CRA nem csupán a termék kiadásakor elvárható biztonságot szabályozza, hanem az azt követő teljes támogatási időszakra kiterjeszti a kötelezettségeket. Ha egy sebezhetőség kerül felszínre – akár egy beépített open source komponensben –, azt kezelni és dokumentálni kell.
A gyors jelentési kötelezettség: Ha egy aktívan kihasznált sebezhetőség válik ismertté, azt 24 órán belül be kell jelenteni az EU kiberbiztonsági ügynökségének, az ENISA-nak. Ez nem ajánlás, hanem kötelezettség.
Miért különösen fontos ez az AI-generált kód esetén?
Ez az a pont, ahol a fejlesztők egy része meglepődik. Az EU CRA nem tesz különbséget aközött, hogy a kód emberi kézből vagy egy AI-eszközből származik. A felelősség a szoftver kiadójánál marad.
Az a gyakorlat, amelyet egyre több csapatnál látok – amikor az AI által generált kódot minimális ellenőrzés után élesbe küldik –, ebben a jogi környezetben komoly kockázatot jelent. A „nem tudtuk, az AI generálta” érv a szabályozói vizsgálaton nem fog megállni. A dokumentációs kötelezettség, az SBOM-követelmény és a sebezhetőség-kezelési elvárás mind vonatkozik az AI-generált kódra is, ha az részét képezi a terméknek.
Ez nem az AI-eszközök ellen szól. Hanem amellett, hogy a csapatoknak ki kell alakítaniuk azokat a folyamatokat, amelyekkel az AI kimenetét valóban ellenőrzik és dokumentálják – mielőtt az kijut a termékbe.
Mit érdemes most elkezdeni?
Három konkrét lépés van, amelyeket érdemes azonnal megtenni, függetlenül attól, hogy a csapat mekkora vagy milyen piacon dolgozik.
A teljes szoftverkészlet leltározása: Minden terméknek, minden függőségnek, minden felhasznált komponensnek láthatónak kell lennie. Az AI-generált kódrészletek is ide tartoznak.
A fejlesztési folyamatok dokumentálása: Ha egy folyamat nincs leírva és bizonyítható módon követve, a szabályozó azt feltételezi, hogy nem létezik. Ez nem bürokratikus igény, hanem a megfelelőség alapja.
Az SBOM-eszközök bevezetése: Ezek nem luxusmegoldások – mára elérhetők és beilleszthetők a meglévő fejlesztési pipeline-ba. Aki ezt most kezdi el, annak jó esélye van arra, hogy 2027-re valóban felkészülten érkezzen a teljes kötelezettség bevezetéséhez.
Összefoglalás
Az EU Cyber Resilience Act nem egy távoli, jövőbeli probléma. Az első kötelezettségek már 2026 szeptemberétől érvényesek. Aki szoftvert fejleszt és az EU-s piacon értékesít, annak most kell elkezdenie felkészülni – különösen akkor, ha a fejlesztési folyamatban AI-eszközök is szerepet kapnak.
A szabályozó nem az eszközre kíváncsi. Arra kíváncsi, hogy a szoftver biztonságos-e, és hogy ezt be tudod-e bizonyítani.
A DevOps és SRE világ egyik legrégibb fájdalma nem a leállás maga, hanem az, hogy a leállás mindig meglepetés. Nem azért, mert senki sem figyelt, hanem azért, mert a rendszerek közötti függőségek olyan szövevényessé váltak, hogy egy ember vagy akár egy egész csapat sem képes azt mindig fejben tartani.
Aki dolgozott már éles környezetben futó, több száz mikroszolgáltatásból álló alkalmazáson, az pontosan tudja ezt az érzést: valami leáll, és az első tíz perc azzal megy el, hogy egyáltalán megértsük, melyik ponton lehet a hiba.
Az AWS most érdemi frissítést adott ki a Resilience Hub következő generációjaként, és ez nem kozmetikai változás. Az eszköz eddig is segített mérni és értékelni az alkalmazások megbízhatóságát, de lényegében passzívan dolgozott: megmondta, hol állsz, és javasolt. Az új verzió aktívabb szerepet vesz fel.
Mi változott valójában?
Az első komolyabb változás a moduláris resilience policy. Korábban előre definiált sablonból kellett választani. Most a csapatok összerakhatják a saját elvárásrendszerüket: meghatározhatják például, hogy az alkalmazás 99,95%-os rendelkezésre állást kell teljesítsen, 15 perces RTO-val és 5 perces RPO-val, multi-region disaster recovery konfigurációval.
Ezt a policy-t aztán újra felhasználhatják több alkalmazáson is, ami nagyvállalati környezetben különösen hasznos.
A második változás az üzleti modell alapú szervezés. Az Resilience Hub most nem csak AWS-erőforrásokat lát, hanem üzleti logikát is próbál leképezni. Egy System egy teljes üzleti alkalmazást jelent, a „user journey”-k a kritikus üzleti folyamatokat írják le, a service-ek pedig ezeket alkotó telepíthető egységek. Ez az absztrakciós szint közelebb hozza az eszközt a valós döntési folyamatokhoz.
A harmadik, és valószínűleg a legfontosabb: a generatív AI-alapú „failure mode assessment”. Az elemzés nem csak az AWS Well-Architected keretrendszer elleőrzőlistáját futtatja le. A rendszer az alkalmazás topológiáját és a megadott házirendet figyelembe véve azonosítja a lehetséges hibamódokat, és konkrét, az adott service-re szabott javaslatokat ad. Ez az a pont, ahol az eszköz valóban új szintet jelent.
A negyedik az automatikus dependency discovery. A legtöbb csapat ezt manuálisan próbálja karbantartani, rendszerint sikertelenül. Az Resilience Hub a VPCDNS lekérdezési bejegyzéseket elemzi, és feltérképezi, hogy az alkalmazás valójában mitől függ: belső végpontoktól, más AWS szolgáltatásoktől, vagy éppen külső, harmadik fél által üzemeltetett végpontoktól. Azokat a cross-region hívásokat is megtalálja, amelyekről a csapat esetleg nem is tudott.
Miért érdekes ez SRE szempontból?
Az SRE-munka nagy részét az teszi nehézzé, hogy a megbízhatóság nem egy esemény, hanem egy folyamat. Folyamatosan változó rendszerekben folyamatosan kell tudni, hogy az elvárásokhoz képest hol tartunk. Erre eddig nem volt jó, skálázható eszköz AWS-en belül.
Az AWS Organizations integráció ezt a problémát oldja meg nagyvállalati szinten. Egy delegált administrator account-ból az összes szervezeti account resilience posture-je áttekinthető egyszerre, anélkül, hogy minden egyes fiókba be kellene lépni és külön riportokat kellene összefésülni. Száz alkalmazás esetén ez nem kényelmi funkció, hanem napi munkát érintő változás.
Hogy jobban értsük
Képzeld el, hogy egy pénzügyi alkalmazást üzemeltetsz AWS-en, több régióban. A payment service kommunikál egy külső banki API-val és egy belső fraud detection service-szel. A csapda ebben a helyzetben az, hogy a külső banki API-t senki sem monitorozza aktívan függőségként, mert egyszer valaki azt mondta, hogy az megbízható. Aztán az API elkezd belassulni, nő a válaszidő, a fraud detection service timeout-ot kap, a payment service hibát dob – és az ügyeletes kolléga egy olyan riasztást kap, amelyből nem derül ki egyértelműen, hogy mi a valódi ok.
A Resilience Hub a DNS naplókból azonosítja ezt a függőséget, és a hibaelemzés során felszínre hozza, hogy egy kritikus külső végpont nincs monitorozva. A javaslat konkrét: legyen megfelelő korlát beépítve, figyeljenek a válaszidőre, és határozzanak meg tartalék viselkedést arra az esetre, ha a külső szolgáltatás nem elérhető.
Ezt is érdemes tudni
Az Resilience Hub nem helyettesíti a Chaos Engineering eszközöket, és nem váltja le a részletes monitoring konfigurációt. Megmutatja, hogy hol vannak a gyenge pontok és mit kellene tenni, de a tényleges tesztelést, a kontrollált hibaszimulációt és a fokozatos verzióváltást ettől még a csapatnak kell elvégeznie.
Ez egy elemző és irányító eszköz, nem öngyógyító rendszer.
Az árazás is változott. Az új modell szolgáltatásonként számol, és havonta két ingyenes hibaelemzést tartalmaz minden egyes szolgáltatáshoz. A függőségtérkép automatikus feltérképezése opcionális, és külön kerül számlázásra.
Mikor hasznos valójában?
Azoknak, akik most találkoznak először az eszközzel: az Resilience Hub akkor éri meg megismerkedni, amikor az infrastruktúra már kellően komplex ahhoz, hogy a fejben tartott függőségi térkép megbízhatatlanná vált. Ahol SRE-szerep van, ahol van külön csapat a megbízhatóságért, ahol AWS Organizations-t használnak – ott ez az eszköz valódi értéket adhat.
Az, hogy generatív AI-t ültetnek bele az ilyen elemző folyamatokba, nem meglepő irány. Az viszont figyelemre méltó, hogy az AWS itt nem egy kísérleti feature-t dobott be, hanem egy meglévő, éles eszköz alapvető értékelési logikáját cserélte le AI-ra.
Van abban valami különösen jó érzés, amikor az ember nemcsak tanul valamit, hanem közben érzi is, hogy a korábbi tudása elkezd jobban összeállni. Mint tudjátok, idén egy olyan kihívást adtam magamnak, hogy az év első felében minden hónapban leteszek egy felhős vagy AI-hoz kapcsolódó vizsgát. Nem azért, mert a tanúsítvány önmagában mindent megold, hanem azért, mert szerettem volna újra és újra megmérettetni magam a nagy felhőszolgáltatók világában. Ezzel is inspirálni azokat, akik évek óta tanulnak, hogy időnként mérettessék meg magukat.
Februárban a Google Generative AI Leader vizsgára esett a választás. Ez logikus lépés volt, mert az AI-val már több mint három éve foglalkozom mélyebben, természetesen a cloud mellett. Márciusban jött az Azure AI-900, amely szintén sikeres lett. Áprilisban pedig következett az AWS Certified AI Practitioner, vagyis az AIF-C01 vizsga. Ezt is sikeresen teljesítettem.
Őszintén bevallom, hogy a három közül ezt élveztem a legjobban.
Nem mély technikai vizsga, de nem is üres elmélet
Az AWS Certified AI Practitioner nem fejlesztői vagy mély machine learning vizsga. Nem kell modelleket kódolni, nem kell ML pipeline-t építeni, és nem kell matematikai részletekben elveszni. Ettől viszont még nem nevezném könnyűnek.
A vizsga hivatalos leírása szerint az AIF-C01 célja, hogy igazolja az AI, ML, generative AI fogalmak, az AWS AI eszközök, a felelős AI használat, valamint a security, compliance és governance alapvető ismeretét. Ez nekem nagyon szimpatikus irány, mert pontosan erre van szüksége sok cégnek is: nem mindenki akar modellt tréningezni, de egyre több embernek kell értenie, mire jó az AI, mikor hasznos, mikor kockázatos, és milyen szolgáltatásokkal lehet elindulni.
A vizsga szerintem azoknak különösen hasznos, akik cloud, data, governance, security vagy üzleti technológiai irányból közelítenek az AI felé. Kezdőknek is jó lehet, de csak akkor, ha nem csak vizsgakérdéseket magolnak, hanem tényleg megértik az alapfogalmakat.
Ami miatt az AWS AI világa különösen izgalmas
A felkészülés közben újra feltűnt, mennyire sokféle AI szolgáltatás létezik AWS-en belül. Nem csak az Amazon Bedrockról van szó, bár kétségtelenül ez az egyik legfontosabb szolgáltatás a generative AI alkalmazások építéséhez.
Érdemes ismerni például az Amazon SageMaker AI-t, ha valaki modellek építésével, tanításával vagy deploymenttel foglalkozna a gépi tanulás világában (ML). Ott van az Amazon Q Business és az Amazon Q Developer, amelyek már sokkal inkább a vállalati tudás, fejlesztői munka és produktivitás irányából érdekesek. Az Amazon Nova az AWS saját foundation model családja. Az Amazon BedrockAgentCore és a Strands Agents SDK pedig már az agentic AI világ felé mutat.
És akkor még nem beszéltünk az olyan érdekesebb irányokról, mint az AWS Health AI Hub, amely az egészségügyi AI megoldásokra koncentrál, vagy az AI Stylist demó, amely jól megmutatja, hogyan lehet generative AI-t kiskereskedelmi vállalkozások és személyre szabott ajánlások köré építeni. A PartyRock pedig egy nagyon jó játszótér azoknak, akik kódolás nélkül szeretnének generative AI app-okat kipróbálni.
Miért volt ez nekem ennyire hasznos?
A legnagyobb értéke számomra az volt, hogy rendszerezte a korábbi tudásomat. Az AI világában nagyon könnyű elveszni a modellek, agentek, RAG megoldások, embeddingek, governance kérdések és platformszolgáltatások között. Ez a vizsga segíthet mindenkinek újra átlátni, melyik építőkocka mire való.
A felkészüléshez YouTube-on is találhatók ingyenes tananyagok vagy az Udemy-n fizetős képzések, de én azt javaslom, hogy senki ne csak egy forrásból készüljön. Érdemes mellé megnézni a hivatalos AWS exam guide-ot, az AWS Skill Builder anyagokat, és közben kipróbálni legalább néhány szolgáltatást. Nem kell mindent mélyen konfigurálni. Első körben bőven elég megérteni, mire való az Amazon Bedrock, hogyan illeszkedik ide a SageMaker AI, és milyen problémákra adnak gyors választ a purpose-built AI szolgáltatások. Ez utóbbira van már képzésem is a Mentor Klubnál.
Én nagyon élveztem a felkészülést, és maga a vizsga is jó élmény volt. Ha jól emlékszem, hamar végeztem. Ez nem azt jelenti, hogy minden kérdés triviális volt, hanem azt, hogy az elmúlt évek tapasztalata és a felkészülés alatt sikerült annyira összerakni a képet, hogy magabiztosan tudtam haladni.
Mi jön ezután?
Megvan ez a vizsgám is, és ennek nagyon örülök. Most már mindegyik felhő-szolgáltatónál sikerrel megmérettettem magam.
Májusban egy Google tanúsítvány megújítása következik. Erről is írni fogok, utána viszont egy rövid szünetet tartok a vizsgák világában. Ennek nagyon jó oka van: felkérést kaptam hat (6) AI képzés elkészítésére a Mentor Klubnál, és most erre szeretnék fókuszálni.
Hogy az AI mely területét fedik le ezek a képzések, az legyen egyelőre titok. Annyit azonban szívesen elárulok, hogy mindegyik a Google Cloud és a Gemini világába segít elmélyedni.
Tehát a cloud-os képzéseim mellett már az Mesterséges Intelligencia világába is elkalauzollak, ha tagja vagy a Mentor Klubnak.
Ha te is most ismerkedsz az AI és a cloud világával, szerintem az AWS Certified AI Practitioner jó irány lehet. Nem azért, mert ettől valaki azonnal AI architect lesz, hanem azért, mert segít tisztábban látni. Márpedig ma ez óriási érték, mert hamar el lehet veszni a hatalmas zajban.
Ha érdekelnek a felhős és AI-os tanulási utak, érdemes követned a következő bejegyzéseket is, mert hamarosan jön a Google tanúsítvány megújításának története, utána pedig még több gyakorlati AI és Cloud téma. Ugye Te is várod már?
Aki az elmúlt évek fejlesztői eszközeinek átalakulása során figyelemmel kísérte, hogyan változott a GitHub Copilot, az tudja, hogy ez az eszköz ma már egészen más valami, mint amivel 2022-ben találkoztunk.
Akkor még egy okos kódkiegészítő volt. Ma már autonóm módon képes végigmenni egy teljes repository módosításain, több lépéses feladatokat old meg önállóan, és elég jó nagy nyelvi modelleket használ közben. Ez a fejlődés szép, de számolni kell azzal, hogy komoly infrastrukturális igénnyel jár a hátterben.
Nem véletlen tehát, hogy a GitHub nemrég bejelentette: 2026. június 1-jétől az összes Copilot csomag áttér a felhasználás alapú számlázásra, angolul usage-based billing modellre. Ez az egyik legjelentősebb árképzési változás, ami az eszköz életében eddig történt. Érdemes pontosan megérteni, mit jelent ez a gyakorlatban.
Mi volt eddig, és mi változik
Az eddigi rendszer úgynevezett premium request unit-okra (PRU) épített. Minden Copilot csomag tartalmazott egy havi kvótát ezekből az egységekből, és ha valaki elfogyasztotta a keretét, egy olcsóbb modellre esett vissza, de tovább tudott dolgozni.
Június 1-jétől ezt a rendszert felváltják a GitHub AI Credits. A lényeg: a kreditfogyasztás token-alapon számolódik, beleértve a bemeneti, kimeneti és gyorsítótárazott tokeneket is, a GitHub által nyilvánosan közzétett API árak szerint. Fontos kiemelni, hogy az alap kódkiegészítés és a Next Edit Suggestions funkció nem fogyaszt kreditet – ezek minden csomagban megmaradnak korlátozás nélkül.
A visszaeső modellre való automatikus átkapcsolás viszont megszűnik. Ha valaki elfogy a kreditjeiből, a rendszergazda által beállított keret vagy a kreditvásárlás az egyetlen megoldás. Ez egy komoly szemléletváltás: az eddig „láthatatlan” korlát mostantól pénzben is megjelenik.
Mennyit kap mindenki a csomagjával
Az alaptervek ára nem változik, ez fontos. Amit kap az ember, az most már kredit formájában van meghatározva:
Csomag
Havi ár
Kapott havi AI Credit
Copilot Pro
10 USD
1 000 kredit
Copilot Pro+
39 USD
3 900 kredit
Copilot Business
19 USD/fő
1 900 kredit/fő
Copilot Enterprise
39 USD/fő
3 900 kredit/fő
Az átváltás egyértelmű: 1 AI Credit = 0,01 USD, tehát a Pro csomag 1 000 kreditje 10 USD értékű fogyasztást fed le. A különbség ott jelenik meg, ha valaki többet használ, mint amennyit a csomag tartalmaz: ekkor a GitHub nyilvánosan közzétett API árain lehet további kreditet vásárolni.
A Business és Enterprise ügyfelek egy átmeneti kedvezményes időszakot is kapnak. Június 1-jétől szeptember 1-jéig emelt kreditkeretet biztosít a GitHub: Business ügyfeleknek 3 000 kreditet, Enterprise ügyfeleknek 7 000 kreditet fejenként és havonta. A kreditek ráadásul nem egyénileg vannak elszámolva, hanem szervezeti szinten összeadódnak – ha egy Business csomagos cégnél 100 felhasználó van, az egy 190 000 kredites közös készletet jelent a normál időszakban, nem 100 különálló keretet.
Mit jelent ez vállalati szempontból
Aki enterprise környezetben dolgozik, annak ez az egyik legfontosabb változás. A GitHub most bevezeti az úgynevezett pooled usage modellt, ami azt jelenti, hogy a szervezeten belüli fel nem használt kreditek nem egyénileg „égnek el”, hanem egy közös készletbe kerülnek, amit más kollégák is felhasználhatnak. Ez egy nagyon is megfontolandó lépés: az eddigi rendszerben rengeteg vállalat fizetett license-eket, amelyek felét talán ki sem használták.
Mellé jön a rendszergazdai szintű budgetkontroll. Az adminisztrátorok mostantól vállalat, cost center és egyéni felhasználó szintjén is beállíthatnak kiadási küszöböt. Amikor a keret elfogy, eldönthetik, hogy a szervezet folytatja-e a használatot piaci áron, vagy kemény limitet állítanak be.
Amit én sok cégnél látok elkövetni: bevezetnek egy SaaS AI-eszközt, és aztán senki sem figyeli, hogy ki, mikor és mennyit használja. Usage-based modellnél ez a hozzáállás gyorsan fájni fog. A jó hír az, hogy a GitHub erre is gondolt: május elején elindít egy előnézeti számlázási felületet, ahol a felhasználók és az adminok előre láthatják, milyen várható költséget generál a jelenlegi használatuk, még mielőtt az éles rendszer június 1-jén elindul.
Hogyan érint ez egy fejlesztőt vagy karrierváltót
Ha valaki még most ismerkedik a Copilottal, és a Copilot Free csomagot használja, a változás egyelőre kevéssé érinti. A Free csomag az eddigi korlátok mellett marad, és az AI Credits rendszer elsősorban a fizetős tervekben válik érzékelhetővé.
Ha viszont valaki rendszeresen, komolyan használja az eszközt – különösen az agentic funkciókat, ahol a Copilot önállóan fut végig feladatokon –, érdemes számolni azzal, hogy az ilyen munkamenetek token-fogyasztása lényegesen magasabb, mint egy egyszerű kódkiegészítésé. A GitHub maga is elismeri, hogy ma egy gyors kérdés és egy többórás autonóm kódolási session ugyanannyiba kerül az eddigi rendszerben. Ez tarthatatlan volt, és a változtatás logikus.
Amit érdemes megjegyezni
Ez a váltás nem egyedi fejlemény. Pontosan ezt a trendet látom az egész cloud és AI iparágban: a flat-rate, havi díjas modellek lassan átadják helyüket a fogyasztásalapú árazásnak. Az AWS már régóta ezen az elven működik, és a nagy AI-szolgáltatók többsége is token-alapú számlázást alkalmaz.
A GitHub Copilot esetében ez egy nehéz, de szükséges lépés. Az agentic AI komoly számítási kapacitást igényel, és az egyáras modell hosszú távon fenntarthatatlan. Aki ezt megérti, az nem fejlesztői extra kiadásként tekint majd a Copilot-számlára, hanem üzleti döntésként: mennyit ér a csapat ideje, és mennyit spórol az AI-asszisztencia.
A legfontosabb teendő most: május elején nézd meg az előnézeti számlázási felületet a GitHub fiókodban vagy a céges adminfelületen, és ott mérd fel a valós fogyasztást, mielőtt a rendszer élesbe megy.
Aki valaha megpróbált egy egyszerűnek tűnő AI agentet éles környezetbe juttatni Google Cloud-on, az tudja, milyen küzdelmes tud lenni a teljes folyamat. A prototípus pillanatok alatt összeáll. Aztán jön az időigényes rész: hogyan kerül ez Cloud Run-ra? Hogy legyen a CI/CD konfiguráció? Melyik dokumentáció a hasznos? Hogyan kapcsolódik az Agent Platform a deployment pipeline-hoz? Minden egyes lépéshez más szolgáltatás, más parancssori (CLI) eszköz, és más dokumentáció kell. Ez az a pont, ahol az ígéretes projekt lelassul, és a lelkesedés is alábbhagy.
A Google Cloud erre a problémára adott választ 2026 áprilisában, amikor bemutatta az Agents CLI-t az Agent Platform részeként.
Mi az Agents CLI, és miért most jött?
Az Agents CLI az Agent Development Lifecycle – röviden ADLC – központi vezérlő eszköze, amely az első sortól az éles üzemig egyetlen parancssori eszközből kezeli a teljes folyamatot. Ez nem egy újabb absztrakciós réteg a meglévő szolgáltatások fölé. Inkább egy összekötő, amely a korábban szétszórt komponensekből – Agent Platform, Cloud Run, Infrastructure as Code, CI/CD – egyetlen, követhető munkafolyamatot csinál.
Az eszköz nyílt forráskódú, elérhető PyPI-n, és közvetlenül működik olyan coding agentek-kel, mint a Gemini CLI, Claude Code, Codex vagy bármilyen más kompatibilis eszköz.
Fontos megjegyezni: az Agents CLI nem maga a coding agent. Hanem az a valami, amit a coding agent használ ahhoz, hogy értelmesen tudjon dolgozni a Google Cloud ökoszisztémájában.
A valódi probléma: a kontextus és a fragmentáció
Mielőtt megnéznénk, mit tud az eszköz, érdemes megérteni, miért volt erre egyáltalán szükség.
Fejlesztők és coding assistentjeik sokszor azzal küzdenek, hogy hatalmas mennyiségű dokumentációt kell feldolgozniuk ahhoz, hogy áthidalják a helyi fejlesztés és a felhős deployment közötti szakadékot. Egy AI coding agent, ha nem tudja pontosan, hogyan kapcsolódnak egymáshoz a cloud komponensek, végtelen próbálkozási hurokba kerül. Ez token-pazarlás, időpazarlás, és a végén nem csak drága lesz az egész, hanem csalódott is lesz a fejlesztő.
Az Agents CLI egy központi réteget biztosít, amely előre definiált „skill”-eket és API referenciákat ad a coding agent-nek. Ez lehetővé teszi, hogy a fejlesztők minimális manuális konfiguráció mellett, gyorsan hozzák létre és indítsák el a projekteket.
Hogyan néz ki ez a gyakorlatban?
Képzeld el, hogy egy utazási költségelszámolást kezelő agent-et szeretnél építeni, amely 20 000 Ft alatt automatikusan jóváhagyja a tételeket, efölött pedig emberi döntést kér. Hagyományos úton ez azt jelenti: ADK projekt felállítása, Cloud Run konfiguráció, IAM jogosultságok, deployment pipeline, evaluation setup, stb. Mindez külön-külön. Idegörlő és bonyolult.
Az Agents CLI esetén egyetlen parancs elegendő ahhoz, hogy a coding agent megkapja az összes szükséges „tudást” a Google Cloud szolgáltatásokról. Ezután a fejlesztőnek nem kell fejből tudnia, hogyan kell konfigurálni minden egyes service-t – az agent elolvassa, amit kap, és elvégzi a lépéseket.
Ez nagyon jól hangzik, igaz?
Az életciklus négy fő szakaszon halad át:
Scaffold: a projekt struktúra és az alap konfiguráció automatikusan generálódik, az ADK (Agent Development Kit) framework alapján.
Eval: az eszköz beépített támogatást ad helyi szimulációhoz és kiértékelési pipeline-ok futtatásához, ahol különböző futtatások eredményeit lehet összehasonlítani referencia adatbázisokkal szemben, mielőtt bármi éles környezetbe kerülne.
Deploy: az Agents CLI automatizálja a teljes deployment fázist – Infrastructure as Code generálása, CI/CD pipeline konfigurálása, majd közvetlen deployment Cloud Runra, Agent Runtime-ra vagy GKE-re.
Publish: a kész agent regisztrálható a Gemini Enterprise környezetbe, ahol vállalati felhasználók számára érhető el.
Human Mode: amikor az ember veszi át az irányítást
Amit én különösen értékelek az eszköz tervezésében a Human Mode bevezetése. Ez lehetővé teszi, hogy a fejlesztők közvetlenül hajtsák végre a CLI parancsokat, ahelyett hogy teljesen az agent-vezérelt automatizálásra hagynának mindent – ez akkor különösen hasznos, amikor valaki pontosan látni akarja, mi történik a folyamatban. Így megmarad a kontroll a teljes folyamaton.
És ez nem csak egy kiegészítő funkció. Az AI agentekkel szembeni egyik jogos kritika pontosan az, hogy fekete dobozként működnek, és nem lehet közbeavatkozni, ha valami nem úgy megy, ahogy kellene.
A Human Mode ezt a problémát oldja meg: ugyanazok a parancsok, amelyeket a coding agent automatikusan futtat, terminálból is végrehajthatók, szkriptekbe szervezhetők, és pontosan ellenőrizhetők.
Cloud Run, GKE, vagy mindkettő?
Érdemes kiemelni még a cloud infrastruktúra oldali támogatást is, mert itt mutatkozik meg a Google Cloud valódi előnye.
Az Agents CLI natív integrációt biztosít a Google Cloud szolgáltatásokkal – Agent Platform, Cloud Run, GKE, és az A2A protokoll az agent-agent kommunikációhoz – manuális konfigurációk nélkül. Ez azon csapatoknak a leghasznosabb, amelyek növelni szeretnék az AI fejlesztés ütemét anélkül, hogy az üzemeltetési terhet is növelni szeretnék.
A Cloud Run az egyszerűbb, serverless megközelítés – az agent konténer alapon fut, és csak akkor fizetsz, ha valóban hívás érkezik (Pay-As-You-Go). A GKE (Google Kubernetes Engine) rugalmasabb, de több konfigurációt igényel. A legtöbb alap felhasználási esethez a Cloud Run a praktikusabb választás, és az Agents CLI alapból erre van optimalizálva.
Ami kimarad ebből a beállításból – szándékosan: monitoring részletei, availability zone konfiguráció, spot VM optimalizálás. Ezek mind fontosak lesznek, ha a terhelés megköveteli, de az első éles deploymentnél nem az a kérdés. Az a kérdés, hogy működik-e.
Pre-GA: mit jelent ez a valóságban?
Fontos megjegyezni: az Agents CLI jelenleg Pre-GA (pre-generally available) státuszban van, ami azt jelenti, hogy az eszköz csak korlátozott támogatással érhető wel. A deployment-ekkel együtt a felhasználó saját Google Cloud projektjében hozza létre az erőforrásokat, és azokért a felelősség is az övé.
Ez nem azt jelenti, hogy ne lehetne érdemi munkát végezni vele. De érdemes tudatosan kezelni: production kritikus rendszereknél ne ez legyen az egyetlen eszköz, amire támaszkodunk, amíg GA státuszt nem ér el. Prototipizáláshoz, POC-okhoz és fejlesztési pipeline-ok felállításához viszont már most teljesen értelmes választás.
Mit is jelet ez?
A Cloud CLI eszközök általában addig működnek jól, amíg a dokumentáció tart. Utána jön a valóság: tíz lépés, három service, és ugyanolyan rendetlenség, csak más köntösben.
Az Agents CLI esetén más a megközelítés, mert nem az embert próbálja meg helyettesíteni a cloud konfigurációban. Inkább a coding agent számára érthetővé teszi a Google Cloud agent ökoszisztémát. Ez egy finomabb, de fontosabb különbség. Az a fejlesztő, aki eddig az ADK-t, a Cloud Run deploymentet és a CI/CD pipeline konfigurációt három különböző helyen kereste, most egyetlen, közös formátumban olvasható „skill” rendszerből kapja meg. A coding agent pedig nem találgat többé és így spórol a token-ekkel is.
Ez egy nagyon ígéretes irány és kíváncsian várom merre fejlődik tovább.
Én a napokban ki fogom próbálni. Ha van kedved, tedd meg te is – a GitHub repository nyilvánosan elérhető, az installation guide mindössze néhány előfeltételt igényel.
Még az év első felében hallhattad a videómban, hogy miért jó a Google Cloud. Ebben a videóban röviden összefoglaltam a legfontosabb dolgokat. Említettem, hogy a Google, mint AI-first cég, már nagyon régen használ mesterséges intelligenciát a mindennapi működése során. Ennek ellenére, még mindig csak a harmadik „nagy” felhő-szolgáltató az AWS és az Azure mögött.
Már akkor is azt mondtam, hogy náluk az AI lehet az a pont, ahol van lehetőségük a kiugrásra és a felzárkózásra. Úgy tűnik, ők is így gondolják és most tettek efelé egy lépést.
Nem feltétlenül forradalmi dologra kell gondolni, inkább amolyan „rájöttünk, hogy hogyan kell pozícionálnunk magunkat” lépésre.
Aki régóta dolgozik cloud platformokkal, az már megszokhatta, hogy a nagy szolgáltatók időnként újracímkéznek egy-egy terméket, finomhangolják a portfóliót, aztán megy tovább az élet. Ami viszont 2026. április 22-én a Google Cloud Next konferencián történt, az ennél kicsivel több: a Google Cloud egyszerre nevezte át az egyik legismertebb AI-platformját valamint több adat- és analitikai termékét is, és közben egy új gondolkodásmódot is bevezetett.
Mi változott a néven?
A legfontosabb bejelentés: a Vertex AI Platform beleolvad egy nagyobb ernyőbe, aminek a neve Gemini Enterprise Agent Platform. A hivatalos közlés szerint ez a Vertex AI evolúciója, és mostantól minden Vertex AI szolgáltatás és új fejlesztés ezen a platformon keresztül érhető el, önálló szolgáltatásként nem.
Emellett a Data Analytics oldalon több termék is beszédesebb nevet kapott. A Dataplex Universal Catalog mostantól Knowledge Catalog. A BigLake új neve Lakehouse. A Dataproc mostantól Managed Service for Apache Spark. A Composer új neve Managed Service for Apache Airflow. A Looker Studio pedig Data Studio néven fut tovább.
Ez elsőre soknak tűnhet, de van egy jó hír: a nevek logikája egyszerűbb lett. A „Managed Service for Apache Spark” önmagában elárulja, hogy egy felügyelt Spark szolgáltatásról van szó. Nem kell kitalálnod, mit takar a „Dataproc” márkanév. Ez különösen segít azoknak, akik most ismerkednek a GCP világával, és eddig a saját termékneveket kellett bemagolniuk.
Régi név
Új név
Mit takar?
Vertex AI Platform
Gemini Enterprise Agent Platform
A Google Cloud AI-platformja, mostantól agent-fókusszal: építés, skálázás, kormányzás, optimalizálás egy ernyő alatt
Dataplex Universal Catalog
Knowledge Catalog
Központi adatkatalógus és governance réteg, amely átláthatóvá teszi, hol milyen adat található és ki férhet hozzá
BigLake
Lakehouse
Egységes tárolási réteg a data lake és data warehouse világ között, nyílt formátumokkal
Dataproc
Managed Service for Apache Spark
Menedzselt Spark környezet nagy adatmennyiségek feldolgozásához, klaszterkezelés nélkül
Composer
Managed Service for Apache Airflow
Menedzselt Airflow szolgáltatás data pipeline-ok ütemezésére és orchestrálására
Looker Studio
Data Studio
Vizualizációs és riportkészítő eszköz dashboardokhoz és adatmegjelenítéshez
Ebből a táblázatból kiolvasható, az egy tudatos iránymutatás a Google részéről. Az AI-platform nevében megjelenik a Gemini és az Agent szó, ami egyértelműen kijelöli, merre megy a termékstratégia. A Data Analytics oldalon pedig a saját márkanevek helyett leíró, iparági szabvány szerinti elnevezések kerültek előtérbe: Spark, Airflow, Lakehouse. Ez sokak számára hasznos, mert ezek a fogalmak más cloudokban és on-premise világban is ugyanezt jelentik.
Mi marad változatlan?
A Google Cloud kommunikációja ebben a kérdésben egyértelmű: a projektjeid, a konfigurációk és az árazás nem változik. A számlázásod ugyanúgy fut tovább, és a meglévő elmentett linkek automatikus átirányítással működnek a konzolon belül. Az SKU megjelenítési nevek és leírások ugyan frissülnek a következő hónapokban, de a Data Analytics SKU-k nevei változatlanok maradnak.
Ez fontos üzenet: Egy enterprise ügyfél számára a legnagyobb kockázat nem egy új név, hanem ha egy átnevezés mögött rejtett árváltozás vagy kényszerű migráció áll. Itt most nem ez a helyzet. Mégis azt tanácsolom, hogy ha céges környezetben dolgozol, érdemes átfésülni a belső dokumentációt, runbook-okat és oktatási anyagokat, mert a kollégák fél év múlva már az új neveken fogják keresni ezeket a szolgáltatásokat.
Miért Agent Platform?
A Gemini Enterprise Agent Platform neve nem véletlen. A Google Cloud hivatalos bejelentése szerint a platform négy fő képességre épül: Build, Scale, Govern és Optimize. Olyan komponensek tartoznak ide, mint az Agent Studio a low-code építéshez, az Agent Development Kit a kódalapú fejlesztéshez, az Agent Runtime a futtatáshoz, a Memory Bank a hosszú távú kontextushoz, valamint az Agent Identity, Agent Registry és Agent Gateway a kormányzáshoz.
Mit is jelentenek ezek?
Build: az agentek felépítése, legyen szó low-code vizuális eszközről (Agent Studio) vagy kódalapú fejlesztésről (Agent Development Kit).
Scale: az agentek futtatása éles környezetben, stabil teljesítménnyel, hosszú távú kontextussal és memóriakezeléssel (Agent Runtime, Memory Bank).
Govern: az agentek felügyelete: minden agent saját azonosítót kap, központi regiszterbe kerül, és egységes biztonsági szabályok mentén működik (Agent Identity, Agent Registry, Agent Gateway).
Optimize: az agentek viselkedésének mérése és finomhangolása éles forgalom alapján, tesztekkel, megfigyelhetőséggel és automatikus javaslatokkal (Agent Simulation, Agent Evaluation, Agent Observability).
Hogy ez mit jelent a gyakorlatban, arra mondok egy egyszerű példát:
Képzelj el egy biztosítót, amelynél egy AI-agent fogadja az ügyféligényeket, lekérdezi a belső rendszereket, majd ha kell, átad egy másik agentnek, aki a kárrendezést indítja el. Eddig ehhez sok külön eszközt kellett összedrótozni. Az Agent Platform ígérete az, hogy ezek egy közös platformon, egységes identitással, auditálhatóan és biztonsági kontrollokkal futnak. Azt, hogy ez a gyakorlatban minden környezetben problémamentesen működik-e, még nem tudom biztosan, de a koncepció iránya egyértelmű: az egyedi AI-feladatoktól haladni egy kormányzott agent-ökoszisztéma felé.
Hogyan illeszkedik ez a többi cloudhoz?
Érdemes megnézni, mit csinálnak a nagy versenytársak. Az AWS-nél a Bedrock és az Amazon Q köré épül az agentek világa, az Azure-nál pedig az Azure AI Foundry és a Microsoft Copilot Studio vonal adja a hasonló irányt. Mindhárom szereplő ugyanabba az irányba megy: nem elég egy jó modell, szükség van futtatókörnyezetre, identitáskezelésre, megfigyelhetőségre és governance-re.
Ez karriertervezés szempontjából is fontos jelzés. Ha most lépsz be a cloud vagy AI világába, ne csak a modellekkel és a prompttal foglalkozz. Sokkal értékesebb tudás, ha érted, hogyan kell egy agentet biztonságosan integrálni egy vállalati környezetbe, hogyan figyeli a csapat a működését, és hogyan kontrollálja a költségeit.
Hasznos tippek a folytatáshoz
Ahogy a hagyományos cloud workloadok esetén, az AI-agenteknél is ugyanazok a hibák jönnek elő, amelyeket sok cégnél elrontanak. Az első klasszikus csapda a tervezés nélküli használat: valaki elindít egy agentet teszteléshez, aztán elfelejti leállítani, és hónapokig fut a háttérben. Ez ugyanaz a történet, mint amikor egy fejlesztői VM-et nem állítanak le éjszakára, és a hónap végén megérkezik a meglepetés a számlán.
A második ilyen a governance hiánya. Ha bárki szabadon hozhat létre agenteket, saját jogosultságokkal, saját eszközökkel, akkor hamar ott állsz egy átláthatatlan ökoszisztéma közepén. Pontosan ezért emeli ki a Google az Agent Identity és az Agent Registry szerepét: minden agentnek legyen azonosítója, és legyen egy központi hely, ahol látható, mi fut, milyen jogosultsággal.
A harmadik terület a biztonsági alapok kihagyása. A legtöbb startup jellegű projektben érthetően először az a cél, hogy egyáltalán működjön valami. Ez rendben is van, a simplicity elv szerint először legyen egy működő megoldás. De még mielőtt élesbe kerülne, érdemes átgondolni a legalapvetőbb kérdéseket: milyen adatokhoz fér hozzá az agent, ki láthatja a logokat, és mi történik hiba esetén.
Záró gondolatok
Három gondolatot szeretnék ezzel átadni neked. Az első: ne memorizálj szolgáltatásneveket, inkább értsd meg a mögöttes fogalmakat és összefüggéseket. Egy felügyelt Spark szolgáltatás az AWS-en EMR, a Google Cloud-on Managed Service for Apache Spark, és az Azure-on Synapse vagy Fabric környezetben találsz hasonlót. A fogalom ugyanaz, a csomagolás más. (Erről hamarosan majd közzé is teszek egy interaktív szótárat.)
A második: a költségtudatosság sosem megy ki a divatból. Minden új agent, minden új adatpipeline pénzbe kerül, és a leggyakoribb hiba, hogy ezt csak utólag vesszük észre. Váljon szokásoddá, hogy minden erőforráshoz hozzágondolod a kérdést: mit kapcsoljak ki, ha nem használom?
A harmadik: a jövőállóság nem jóslás, hanem kíváncsiság. Nem tudjuk pontosan, merre megy a piac öt év múlva, de azt látjuk, hogy az agent-alapú világ egyre több felületen jelenik meg. Aki most megérti a governance, az identity és az observability szerepét, az bármelyik platformon könnyen átül.
Habár a név megváltozott, de a tanulság a régi: a Cloud-ban és az AI-ban nem feltétlenül az nyer, aki a leggyorsabban vág bele, hanem aki tudatosan építkezik.
Amikor év elején eldöntöttem, hogy minden hónapban leteszek egy vizsgát, nem csak egy kihívást kerestem. Inkább egy kis pezsgést. Valamit, ami segít fókuszban maradni, fejlődni, és közben visszajelzést kapni arról, hogy merre tartok. Nekem ezek a vizsgák a tudásom rendszerezését is jelenti, ami időközönként fontos, mert ettől ne csak jobb szakemberré, hanem jobb oktatóvá is válok.
Februárban a Generative AI Leader vizsgával kezdtem, ami egy logikus lépés volt, hiszen az AI már több mint 3 éve aktív része az életemnek – nem csak érdeklődés szinten, hanem napi használatban is.
Márciusban viszont egy más típusú megmérettetés jött: az Azure AI-900 (Azure AI Fundamentals).
És őszintén? Nagyon élveztem, mert ez sem az a belépőszint, amit a leírásígért.
Mi is az Azure AI-900 valójában?
Az Azure AI-900 egy alapozó vizsga, de fontos tisztázni: ez nem azt jelenti, hogy „könnyű”.
Ez a vizsga inkább arról szól, hogy:
megérted az AI alapfogalmait,
átlátod a különböző AI megközelítéseket,
és tisztában vagy azzal, hogy az Azure milyen szolgáltatásokat kínál ezekhez.
Nem kell mélyen kódolni, nem kell modelleket tréningezni. Viszont érteni kell, mi miért történik. És ismerni kell az Azure-ban lévő AI eszközöket.
Milyen témákra számíts?
A vizsga három fő terület köré épül:
Machine Learning alapok – supervised vs. unsupervised tanulás, modellek, kiértékelés
Computer Vision és NLP – képfelismerés, szövegfeldolgozás, chatbotok
Generative AI alapok – LLM-ek, promptok, felelősségteljes AI használat
És ami szerintem külön hasznos, hogy nem csak elmélet van, hanem szolgáltatás szintű gondolkodás. Legalábbis Azure szinten.
Azure AI szolgáltatások, amikkel találkozni fogsz
A vizsga során több Azure szolgáltatás is előkerül. Néhány, amit érdemes ismerni:
Azure AI Foundry – egy központi platform AI megoldások építésére és kezelésére
OpenAI Service – hozzáférés olyan modellekhez, mint a GPT alapú rendszerek
AI Vision – képfelismerés, objektum detektálás
AI Language – szövegelemzés, sentiment analysis
Bot Service – chatbotok létrehozása
Azure Machine Learning – modellek fejlesztése és deploy-ja enterprise környezetben
Nem az a cél, hogy mindent konfigurálni tudj, hanem hogy tudd: mikor melyikhez nyúlnál. Valójában az Azure AI Foundry körül forgott a kérdések nagy része. Tehát ha ezt megismered, akkor nem ér meglepetés.
Hogyan készültem fel?
Nem alkalmaztam különleges mágiát vagy varázslatot, csupán a meglévő tudásomat rendszereztem a vizsga követelményeinek megfelelően.
És közben végig próbáltam megérteni, nem csak bemagolni
Ez nagyon fontos, mert nem azért megyünk vizsgázni, hogy megtanuljuk, hanem azért vizsgázunk, mert tudjuk. Mert aki csak kérdéseket gyakorol, az lehet, hogy átmegy. De aki érti is, az építeni tud rá később.
Maga a vizsga élménye
A vizsga kifejezetten élvezetes volt. Nem éreztem stresszesnek, inkább egy jó visszajelzésnek arra, hogy: oké, ez a tudás tényleg a helyén van.
És ami még fontos: nem éreztem „trükkösnek” a kérdéseket.
Kinek ajánlom?
Három típusú embernek különösen:
Kezdőknek, akik most ismerkednek az AI-jal
Cloud iránt érdeklődőknek, akik Azure irányba mennének
Karrierváltóknak, akik szeretnének egy gyors, de értékes visszajelzést a tudásukról
Ez egy nagyon jó „belépő” ,de mégis kihívásokat támasztó vizsga.
Nem túl mély, de elég ahhoz, hogy:
megértsd az alapokat
magabiztosabban beszélj AI-ról
és elindulj egy komolyabb irányba
beinduljon a fantáziád az Azure AI megoldásai kapcsán.
Az elmúlt években az AI szerves része lett a fejlesztés mindennapjainak. Ez nem egyik pillanatról a máikra történt meg, hanem apró lépésekben: először kipróbáltuk, aztán elkezdtük használni, végül pedig ott tartunk, hogy már észre sem vesszük, mennyire természetes része lett a munkának. A GitHub Copilot ennek az egyik éllovasa. Azonban nem minden alkalommal gondoljuk végig, mi történik a háttérben.
A GitHub Copilot nem egy külön eszköz már, hanem a fejlesztés része. Megnyitod a Visual Studio Code-ot, és ott van, használatra kész. Nem gondolkodsz rajta, csak használod.
És pont emiatt van egy kérdés, amire sokáig kevesen figyeltek: mi történik azzal, amit beírsz?
Minden AI alapú eszköznél ez az egyik első kérdés mindenkinek, de itt valahogy ez háttérbe szorult. Pedig amikor a Copilot-ot használod, nem csak kódot generálsz. Folyamatosan adatot is továbbítasz a GitHub és a modellek felé.
És ez az a terület, ahol most történt egy fontos változás. A GitHub bejelentette, hogy 2026. április 24-tőlalapértelmezetten felhasználja a Copilot Free, Pro és Pro+ felhasználók adatait a modellek fejlesztésére. Ez azt jelenti, hogy a beírt promptok, a generált válaszok és a kódrészletek is bekerülhetnek a tanításba, ha ezt nem kapcsolod ki.
Mi számít adatnak?
Lépjünk vissza egy kicsit. Amikor használom a Copilot-ot, akkor az nem csak annyi, hogy “írok egy sort, ő visszaad valamit”.
Hanem:
mit kérdezel
melyik fájlban dolgozol
milyen kódrészleteket adsz meg
milyen mintákat használsz
mit fogadsz el és mit nem
Ez együtt az úgynevezett interaction data. Ez elsőre nem tűnik fontosnak, de ha belegondolsz, látszik, hogy ebből nagyon sok minden összeáll:
Nagyvállalati környezetben ez már nem csak technikai kérdés, hanem üzleti érték is.
Mi változott most?
A GitHub ebben lépett egyet. Nem arról van szó, hogy teljesen új dolgot vezettek be. Hanem arról, hogy láthatóvá tették azt, ami eddig háttérben volt.
Mostantól kapsz egy egyszerű döntési pontot: felhasználhatják-e az adataidat a modell tanítására vagy nem
Ez egy kapcsoló, ami mögött egy gondolkodásváltás van. Korábban ez sokkal inkább implicit volt (nem volt ráhatásunk). Most viszont explicit lett. És ez azért fontos, mert: nem csak használod az AI-t, hanem lehetőséged van valamelyest kontrollálni is.
Hogyan kapcsolod be vagy ki?
Térjünk az érdemi részre, azaz hogyan végzem el a megfelelő beállítást. Ez – szerintem szerencsére – nem repository szinten van, hanem felhasználó szinten.
Lépések:
GitHub > profil ikon
Settings
Copilot
Itt találod: “Allow GitHub to use my data for AI model training”
Itt a lehetőségek:
Enabled: felhasználhatják az adataid tanításra
Disabled: nem használják fel tréninghez
Fontos, hogy az alábbiakat tartsuk szemelőtt:
a változás nem azonnal lép életbe (kb. 30 perc)
bizonyos esetben kell egy IDE restart (én javaslom is)
Még egy gondolat a végére
Örülök, hogy megjelent ez a funkció, mert talán segít a bizalom növelésében azok számára, akik eddig aggódtak az adatkezelés miatt. Természetesen továbbra is sok adatkezeléssel kapcsolatos kérdés motoszkálhat bennünk – nem alaptalanul. Egy lépéssel azonban közelebb vagyunk egy ideális világhoz. Miért?
Mert az AI használata egyre inkább nem csupán technikai kérdés, hanem adatkezelési kérdés is. És minél több lehetőségünk van eldönteni döntési mihez adunk hozzáférést és mihez nem, annál jobban testre szabhatjuk mit akarunk megosztani a modellekkel és az őket fejlesztő szervezetekkel.
Abban reménykedem, hogy ezt nem rontják el úgy mint a weboldalaknál a sütik kezelését, ahol minden oldalnál van, hogy 35-40 féle beállítást kellene elvégeznünk – akár naponta – hogy biztonságban érezzük magunkat.
2025-ben látványosan megváltozott az AI rendszerek iránya. A fókusz egyre inkább az úgynevezett Agentic AI felé fordult. Ebben a folyamatban nagy szerepe volt az MCP (Model Context Protocol) megjelenésének is, amely jelentősen megkönnyítette az AI rendszerek és különböző eszközök közötti integrációt.
Korábban főleg chat alapú AI rendszereket használtunk. A működés egyszerű volt: kérdeztünk valamit, az AI válaszolt. Ez sok esetben hasznos, de nem mindenre alkalmas nekünk.
Azóta az AI agentek rengeteget fejlődtek. Egyre ügyesebbek lettek, és sokkal könnyebben integrálhatók különböző rendszerekkel. Ennek köszönhetően egy új szintre léptek: megjelentek az autonóm AI agentek.
Ezek már nem csak válaszolnak egy kérdésre. Folyamatosan futnak a háttérben, figyelnek, reagálnak, feladatokat hajtanak végre, és különböző rendszerekkel kommunikálnak.
Ha belegondolunk, ez valójában nem egy teljesen új koncepció. Inkább egy természetes következő lépés. Az eddig különálló technológiák – AI modellek, automatizációk, integrációk – most kezdenek igazán összeérni.
Pont ezt a hullámot lovagolja meg az OpenClaw is. Valójában semmi újat nem hoz, hanem okosan összerakja azokat az elemeket, amelyek eddig is léteztek. A különbség inkább az, hogy nagyon alacsonyra teszi a belépési küszöböt ebbe a világba.
És most már az Amazon Lightsail segítségével ezt még könnyebb kipróbálni az AWS-ben.
Mi az az OpenClaw?
Az OpenClaw egy nyílt forráskódú autonóm AI agent.
Korábban Clawdbot vagy Moltbot néven is ismert volt, de a projekt most már OpenClaw néven fut tovább.
A működési modellje eltér attól, amit a klasszikus chat AI rendszereknél megszoktunk.
Az OpenClaw:
folyamatosan fut a háttérben
üzenetküldő platformokon keresztül kommunikál
képes feladatokat végrehajtani
kódot futtatni
fájlokat kezelni
weboldalakat böngészni
automatizált munkafolyamatokat kezelni
Alapvető kommunikációs csatornái például:
Slack (én ezt használom)
Telegram
WhatsApp
Discord
Ez azt jelenti, hogy a felhasználó egy üzenetküldő alkalmazáson keresztül kommunikál az agent-el, miközben az a háttérben egy szerveren fut.
Miért érdekes a Lightsail integráció?
Az OpenClaw eddig is telepíthető volt saját infrastruktúrára.
Viszont ezek sok esetben túl bonyolultak lehetnek egy gyors kipróbáláshoz.
Ahogy arról már írtam az Amazon Lightsail pont ilyen a problémákra ad egyszerű megoldást: A Lightsail egy leegyszerűsített AWS szolgáltatás, amely előre konfigurált szolgáltatásokat kínál fix havi áron.
Most már az OpenClaw egy előre elkészített megoldásként is elérhető ezen a platformon.
A 90 napos ingyenes lehetőség
Ahogy megszoktuk az egyes szoplgáltatásokhoz több csomagot is igénybe vehetünk. Így van ez most is, viszont a Lightsail egyik csomagja különösen érdekes.
A konfiguráció:
2 vCPU
2 GB RAM
60 GB SSD
3 TB adatforgalom
Normál esetben ez 12 USD / hó.
Most azonban az AWS 90 napos ingyenes időszakot kínál erre a csomagra.
Ez gyakorlatilag azt jelenti, hogy három hónapig teljesen inygenesen lehet kipróbálni egy saját AI agent futtatását.
Hogyan illeszkedik ez a modern AI agent trendbe?
Az AI világában most egyre többet beszélünk az úgynevezett agentic AI rendszerekről.
A különbség egyszerűen megfogalmazva:
Chat AI: A felhasználó kérdez, a modell válaszol.
AI agent: A rendszer folyamatosan fut és feladatokat hajt végre.
Az agentek általában képesek:
több eszközt használni
API-kat hívni
fájlokat feldolgozni
automatizált workflow-kat futtatni
Az OpenClaw ebbe a kategóriába tartozik. Ezért sok érdeklődő, fejlesztő és AI mérnök számára érdekes projekt.
Mire lehet használni egy ilyen AI agentet?
Az OpenClaw mögött az az elképzelés áll, hogy az AI ne csak „beszéljen”, hanem dolgozzon is.
Néhány egyszerű példa:
Automatizált Slack asszisztens: Egy csatornában figyeli a kérdéseket és segít dokumentációk alapján válaszolni.
Monitoring jelzések feldolgozása: Alert esetén információkat gyűjt és jelentést készít.
Kisebb automatizációk: Weboldalak ellenőrzése, adatgyűjtés, riportok generálása.
Nyilván ezekhez további konfiguráció és integráció szükséges, de az alap koncepció már működőképes.
Mire figyelj az AI agenteknél!
Az AI agent rendszerek körül most nagyon nagy a hype.
Úgy látom, hogy túl gyorsan próbálnak valami nagyon komplex rendszert építeni. És ebben sokszor elvesznek.
Pedig az ilyen technológiáknál sokkal fontosabb: először kísérletezni. (valami egyszerűvel)
Ezért jó a Lightsail alapú megközelítés.
Egy kis VM-en el lehet kezdeni:
tesztelni
integrációkat kipróbálni
promptokat finomítani
agent workflow-kat építeni
Ha pedig megvan a tapasztalat, és komolyabb, kreatívabb megoldás kell, akkor lehet tovább lépni.
Én is ki fogom próbálni
Az OpenClaw bizonyos szempontból számomra is érdekes projekt, ezért a következő hetekben ki fogom próbálni a Lightsail alapú megoldást, és össze fogom hasonlítani azzal a környezettel, amit jelenleg itthon futtatok a saját mikro szerveremen.
Kíváncsi vagyok például:
ugyanolyan stabil
milyen teljesítményre képes
mennyire egyszerű integrálni különböző rendszerekkel
ugyanannyi hiba van-e benne mint a helyi szerveren futó verzióban
Ha lesznek érdekes tapasztalataim, arról külön cikkben is fogok írni.
Fontos: ezekkel az agentekkel óvatosan kell bánni
Szeretném azonban mindenki figyelmét felhívni, hogy felelősséggel használja.
Az autonóm AI agentek nem csak válaszolnak, hanem aktívan cselekszenek. Kódot futtathatnak, fájlokat kezelhetnek, API-kat hívhatnak, vagy akár külső rendszerekkel is kommunikálhatnak.
Ez hatalmas lehetőség, de egyben kockázat is.
Ha egy agent túl széles jogosultságot kap, vagy rosszul konfiguráljuk, akkor könnyen okozhat problémát – akár saját rendszereinkben, akár más szolgáltatásokban.
Ezért az ilyen rendszereket mindig:
korlátozott jogosultságokkal érdemes futtatni
izolált környezetben tesztelni
és tudatosan felügyelni
Az AI agentek nagyon erős eszközök lehetnek, ezért felelősséggel kell használni őket.
Pont ezért érdemes először kísérletezni velük, mielőtt komolyabb rendszerekbe integrálnánk őket.
Összegzés
Az OpenClaw sokak szerint egy izgalmas új irányt képvisel az AI rendszerek világában. Ezzel kapcsolatban én kicsit szkeptikus vagyok. Az azonban tény, hogy felkavarta az állóvizet.
Akik eddig nem merték kipróbálni az autonóm AI agenteket, azoknak most jó lehetőség nyílik rá. Az Amazon Lightsail integráció jelentősen leegyszerűsíti az indulást.
A 90 napos ingyenes csomag kifejezetten jó lehet arra, hogy valaki elkezdjen kísérletezni ezekkel a rendszerekkel, és saját tapasztalatot szerezzen.
És egy dolgot érdemes mindig szem előtt tartani: az ilyen rendszereket mindig csak felelősséggel használjuk.
