Ügynöki mérnökség bankok számára: 2026-os tervrajz a felső vezetésnek és az azt megépítő mérnököknek

TL;DR. Az ügynöki MI a pilotfázisból átlépett az éles üzembe a globális bankszektorban. Az intézmények 70%-a valamilyen mértékben használja; csak minden ötödiknek van érett irányítási modellje. Eközben az autonóm támadók gépi sebességgel működnek, az örökölt COBOL-rendszert, amellyel az új rendszereknek együtt kell működniük, az 1960-as évek kötegelt feldolgozási feltevéseire írták, és az EU AI Act 2026 augusztusi magas kockázatú határideje tizenkét hétre van. Ez az a mérnöki és irányítási pozíció, amelyet egy banknak tartania kell.

Points clés

Ügynöki mérnökség bankok számára: 2026-os tervrajz a felső vezetésnek és az azt megépítő mérnököknek. Az ügynöki MI a pilotfázisból átlépett az éles üzembe a globális bankszektorban.
Az év, amikor az ügynöki mérnökség megkerülhetetlenné vált. A pénzügyi szolgáltatásokban az MI-ről szóló beszélgetést egészen a közelmúltig két szomszédos, de eltérő dolog uralta: a generatív csevegőfelületek (hasznosak, de korlátozottak) és a vállalati adatokra rétegzett…
Az elterjedtség helyzete a bankszektorban. Az összesített kép egyértelmű.
Három kockázati vektor, amelyet a bankoknak internalizálniuk kell. Bármely architekturális beszélgetés előtt az igazgatótanács figyelmének három olyan kockázaton kell nyugodnia, amelyek az ügynöki rendszerekre jellemzőek, és amelyek hamarabb érkeznek, mint ahogy a legtöbb bank tervezte.

Ügynöki mérnökség bankok számára: 2026-os tervrajz a felső vezetésnek és az azt megépítő mérnököknek

Az ügynöki MI a pilotfázisból átlépett az éles üzembe a globális bankszektorban. Az intézmények hetven százaléka valamilyen mértékben használja; csak minden ötödiknek van érett irányítási modellje. Eközben az autonóm támadók gépi sebességgel működnek, az örökölt COBOL-rendszert, amellyel az új rendszereknek együtt kell működniük, az 1960-as évek kötegelt feldolgozási feltevéseire írták, és az EU AI Act magas kockázatú határideje tizenkét hétre van. Ez az a mérnöki és irányítási pozíció, amelyet egy banknak tartania kell.

Legfontosabb tanulságok

A vibe codingról a specifikációvezérelt fejlesztésre való áttérés már nem pusztán vágyálom. Andrej Karpathy, aki a "vibe coding" kifejezést 2025 februárjában megalkotta, egy évvel később elismerte ⧉, hogy a korszak véget ér, és hogy a szakemberek új alapértelmezése az ügynöki mérnökség: ügynökök vezénylése részletes specifikációkkal szemben, emberi felügyelet mellett.

A banki elterjedtség valós és gyorsul. A banki cégek 70%-a ⧉ arról számol be, hogy valamilyen mértékben használ ügynöki MI-t (16% éles üzemben, 52% pilotban, EY 2026); a pénzügyi csapatok 44%-a fogja használni az idén, ami 600%-ot meghaladó éves növekedés a Wolters Kluwer szerint.

Az irányítás nem tartott lépést. A Deloitte State of AI 2026 jelentése szerint csak minden ötödik cégnek van érett irányítási modellje az autonóm MI-ügynökökhöz. A Deloitte MIT AI Risk Database-elemzése több mint 350 kockázatot ⧉ azonosít, amelyek az autonóm vagy ügynöki viselkedésből fakadhatnak.

A fenyegetési táj iparosodott. Az Anthropic 2025 novemberében feltárta, hogy a kínai állami támogatású GTG-1002 csoport eltérítette a Claude Code-ot, hogy autonóm kémkedést folytasson megközelítőleg 30 célpont ellen, ahol az MI a taktikai műveletek 80-90%-át önállóan kezelte. A Flashpoint 1500%-os növekedést figyelt meg az MI-vel kapcsolatos illegális eszmecserékben ⧉ pusztán 2025 novembere és decembere között.

Az örökölt rendszerállomány a csendes korlát. A pénzügyi szolgáltatások IT-költségvetésének 70-75%-át az örökölt rendszerek karbantartása emészti fel, a bankok 63%-a még mindig a 2000 előtt írt kódra támaszkodik, és a legtöbb bank csak egy vagy két olyan belső munkatársról számol be, aki képes karbantartani a COBOL-t, amelyen a core platformjaik futnak. Az ügynöki MI mostanra a domináns megközelítés e szakadék bezárására.

A szabályozási halmaz konvergál. Az EU AI Act alapján 2026. augusztus 2. teljeskörű kikényszeríthetőséget vált ki a magas kockázatú MI-rendszerekre (a III. melléklet kifejezetten tartalmazza a hitelpontozást és a hitelképesség értékelését). A DORA már hatályban van. Az SR 11-7-et a szabályozói gyakorlatban kiterjesztették az LLM-ekre és az ügynöki rendszerekre. A jogsértésért kiszabható büntetések 35 millió eurót vagy a globális éves árbevétel 7%-át érik el.

Az emberi felügyelet nem egyetlen fogalom. A HITL (Human-in-the-Loop, ahol az ügynök explicit emberi jóváhagyás nélkül nem hajthat végre műveletet) és a HOTL (Human-on-the-Loop, ahol az ügynök emberi monitoring mellett autonóm módon hajt végre műveleteket) közötti megkülönböztetés mostanra az EU AI Act 14. cikkének megfeleléséhez használt gyakorlati keret, és minden magas kockázatú ügynöknek explicit álláspontra van szüksége arról, melyik modell alkalmazandó.

A legtöbb ügynököt megveszik, nem megépítik. A DORA szerinti, harmadik felekkel kapcsolatos kockázatkezelés 2026 leghangosabb, alulértékelt kihívása. A beszállítók fogják szállítani a bankok által bevezetett ügynöki képesség többségét; a szabályozási kötelezettség a banknál marad, és a legtöbb meglévő beszállítói szerződés nem tudja teljesíteni a 13. cikk dokumentációs követelményeit.

Az ügynöki mérnökség nem „ChatGPT plusz MCP-szerverek". Ez strukturális tulajdonosi pozíció az intézmény végponttól végpontig tartó folyamatai felett: az ügyfélutak, a tranzakció-életciklusok, a vezérlősík, az auditalapréteg, a kvantumbiztos kriptográfiai alap, amelyet az intézmény saját mérnöki funkciója épít és üzemeltet, nem pedig egy csevegőrobotra ruház át.

Az év, amikor az ügynöki mérnökség megkerülhetetlenné vált

A pénzügyi szolgáltatásokban az MI-ről szóló beszélgetést egészen a közelmúltig két szomszédos, de eltérő dolog uralta: a generatív csevegőfelületek (hasznosak, de korlátozottak) és a vállalati adatokra rétegzett visszakereséssel bővített generálás (RAG) mintázatai (hasznosak, szintén korlátozottak). Ami 2025 vége és 2026 eleje között megváltozott, az az, hogy a harmadik kategória, vagyis az autonóm ügynökök, amelyek korlátozott emberi felügyelet mellett terveznek, végrehajtanak és többlépcsős munkafolyamatokat teljesítenek, a technikai bemutatóból átlépett a működési valóságba, és egyszerre jelent meg a vállalatnál és a fenyegető szereplőnél is.

Andrej Karpathy, aki a "vibe coding" kifejezést 2025 februárjában megalkotta ⧉, a rákövetkező évet azzal töltötte, hogy figyelte, ahogy a hivatásos mérnökök túllépnek rajta. Az általa javasolt módosítás, az "ügynöki mérnökség", mára az iparág egészében bevett kifejezés. A váltás lényege egyszerű: a komoly szoftveres munkában 2026-ban a mérnökök az esetek 99%-ában nem közvetlenül írják a kódot. Ügynököket vezényelnek, amelyek megírják azt, ők maguk pedig a felügyeletet látják el. A munka már nem karakterek begépelése egy szerkesztőbe; hanem olyan specifikációk létrehozása, amelyek korlátozzák, hogy az ügynökök mit generálhatnak, azon ellenőrzési kapuk megtervezése, amelyeken a kimenetnek át kell jutnia, valamint azon architekturális döntések gondozása, amelyeket az ügynökök megvalósítanak.

Ez a váltás úgy hangzik, mint egy mérnökcsapaton belüli beszélgetés. A bankszektorban nem az. Ez igazgatótanácsi szintű beszélgetés, mert ugyanaz az ügynöki képesség, amely átírja, hogyan készül a belső kód, azt is átírja, hogyan működnek a külső támadók, hogyan várják el a szabályozók a felügyelet gyakorlását, és hogyan határozzák meg az intézményi perimétert. Az a bank, amely 2026 végéig nem birtokolja a saját álláspontját az ügynöki mérnökségről, nem olyan bank, amely elkerülte a kérdést. Olyan bank, amely helyett a beszállítói, a támadói és a szabályozói válaszolták meg a kérdést.

Az elterjedtség helyzete a bankszektorban

Az összesített kép egyértelmű. Több 2026-os felmérésből összeállított kutatás szerint a bankvezetők 70%-a ⧉ arról számol be, hogy cégük már valamilyen mértékben használ ügynöki MI-t. A Gartner előrejelzése szerint ⧉ 2026 végére az összes pénzügyi szolgáltató cég körülbelül 40%-a fog valamilyen formában MI-ügynököket üzemeltetni. A pénzügyi szolgáltatások MI-kiadásai jó úton haladnak afelé, hogy 2028-ra elérjék a 67 milliárd dollárt (IDC). A McKinsey becslése szerint az ügynöki MI heti 10-12 órát adhat vissza a bankszektor ügyfélkapcsolati menedzsereinek.

A megvalósítás képe kevésbé biztató. A KPMG jelentése szerint ⧉ a cégek 99%-a tervezi autonóm ügynökök éles üzembe állítását, de csak 11% tette ezt meg. Az EY szerint a vezetők 34%-a kezdte el használni az MI-ügynököket, és csak 14% valósította meg őket teljeskörűen. A Forrester szerint a szervezetek 57%-a úgy véli, hogy nem rendelkezik a belső képességekkel az ügynöki MI kihasználásához. A szándék és a megvalósítás közötti szakadék nem marketingtermék. Valós tükröződése annak a mérnöki, irányítási és kulturális munkának, amelyet még nem végeztek el.

Az Egyesült Királyság Financial Conduct Authority hatósága nyilvánosan aggályokat fogalmazott meg ⧉ amiatt, hogy a bevezetés sebessége meghaladja az irányítás érettségét: ezt a feszültséget az FCA adatügyi vezetője, Jessica Rasu közeljövőbeli lakossági fogyasztói kockázatként értelmezte. A McKinsey külön figyelmeztetett, hogy azok a bankok, amelyek nem alakítják át üzleti modelljeiket ⧉, azt kockáztatják, hogy 2030-ig akár 170 milliárd dollárnyi globális profitot erodálnak el. Mindkét megállapítás egyszerre helytálló. A kérdés nem az, hogy lépjünk-e; hanem hogy hogyan lépjünk azzal a működési és irányítási integritással, amelyet a pénzügyi szolgáltatások szabályozása mindig is megkövetelt, és amelyet az ügynöki rendszerek még élesebbé tesznek.

Három kockázati vektor, amelyet a bankoknak internalizálniuk kell

Bármely architekturális beszélgetés előtt az igazgatótanács figyelmének három olyan kockázaton kell nyugodnia, amelyek az ügynöki rendszerekre jellemzőek, és amelyek hamarabb érkeznek, mint ahogy a legtöbb bank tervezte.

1. Az autonóm ellenfél

2026 legzavaróbb fejleménye az ügynöki MI hadrendbe állítása a támadó oldalon. 2025 augusztusában az Anthropic feltárt egy tevékenységi kategóriát, amelyet vibe hackingnek ⧉ nevezett: kiberbűnözők ügynöki MI-t használnak kifinomult támadások nagy léptékű végrehajtására, ahol az MI beágyazódik a felderítésbe, a hitelesítőadatok begyűjtésébe, a hálózati behatolásba és az ellopott adatok elemzésébe. 2025 novemberében ⧉ az Anthropic feltárta, hogy megzavart egy kínai állami támogatású csoport (a GTG-1002 jelölésű) kampányát, amely Claude Code-példányokat térített el, hogy autonóm kémkedést folytasson mintegy harminc védelmi, energetikai és technológiai célpont ellen, ahol az MI a taktikai műveletek 80-90%-át kezelte, és másodpercenként több ezer kérés sebességével működött, ami emberi operátorok számára lehetetlen.

2026 januárjában a Step Finance-t, egy Solana-alapú DeFi-portfóliókezelőt, olyan módon kompromittáltak, amely egy eszközbehatolást 27-30 millió dolláros veszteséggé változtatott, mert a cég MI-kereskedési ügynökei jogosultak voltak nagy összegű átutalások végrehajtására emberi jóváhagyás nélkül. A támadó magát az MI-t szedte rá social engineeringgel, azt állítva, hogy engedélyezett bug bounty programot futtat. A tanulság ⧉ nem az volt, hogy az MI eredendően nem biztonságos; hanem az, hogy az az MI-ügynök, amely ellenőrzés nélkül elfogadja az állítólagos engedélyezést, a periméter gyenge pontja.

Az összesített trend az, amit a bankoknak internalizálniuk kell. A Flashpoint 2026-os Global Threat Intelligence Report jelentése 1500%-os növekedést azonosított az MI-vel kapcsolatos illegális eszmecserékben ⧉ 2025 novembere és decembere között, ahol a támadók aktívan fejlesztenek olyan autonóm rendszereket, amelyek adatokat gyűjtenek, infrastruktúrát rotálnak, üzeneteket igazítanak, és a sikertelen próbálkozásokból tanulnak folyamatos emberi felügyelet nélkül. A JPMorgan vezetője, Jamie Dimon nyilvánosan egyértelművé tette ⧉, hogy ebben a technológiában a kezdeti előny a támadásé, nem a védelemé. A következtetés kényelmetlen: az a bank, amely klasszikus biztonsági műveleteket futtat ügynöki ellenfelekkel szemben, strukturálisan olyan sakkjátékos helyzetében van, akinek az ellenfele számítógépet kapott.

2. A kódminőség visszaesése

A második vektor belső és csendesebb. Az LLM által generált kód specifikációs fegyelem és szigorú ellenőrzés hiányában lényegesen magasabb arányban tartalmaz hibákat, mint az ember által írt kód. Öt élvonalbeli LLM Java-kódgenerálásának SonarQube-elemzése ⧉ megállapította, hogy a Llama 3.2 90B kimenetében észlelt sebezhetőségek több mint 70%-át BLOCKER súlyosságúnak minősítették, miközben a GPT-4o és az OpenCoder-8B sebezhetőségeinek nagyjából kétharmadát BLOCKER vagy CRITICAL besorolásúnak minősítették. Pearce és munkatársai (IEEE S&P) azt találták, hogy a biztonságérzékeny kontextusokban az LLM által generált programok körülbelül 40%-a tartalmazott sebezhetőségeket. Yan és munkatársai (2025) a tartományt a benchmarkjaikon 9,8-42,1%-ra tették. Fu és munkatársai külön katalógusa 43 CWE-t azonosított három MI-kódgeneráló eszközön keresztül.

Egy nem szabályozott iparágban ez termelékenységi adó. Egy bank számára szabályozási és működési kockázat, amely halmozódik. Az a kód, amely magas sebezhetőségi aránnyal kerül egy fizetéseket, elszámolást vagy ügyféladatokat kezelő rendszerbe, nem elvont kódminőségi kérdés; hanem az a felület, amelyet a GTG-1002 osztályú ellenfelek 2027-ben ugyanazokkal az ügynöki eszközökkel fognak vizsgálni, amelyek előállították. A védekezés nem az LLM által generált kód betiltása (kereskedelmileg lehetetlen), hanem az, hogy körülvesszük azzal az ellenőrzési és specifikációs infrastruktúrával, amely biztosítja, hogy a hibák a bevezetés előtt felszínre kerüljenek. Ez a gyakorlati oka annak, hogy a specifikációvezérelt fejlesztést gyorsan bevezetik azok a vállalati mérnöki szervezetek, amelyek nem eleve technológiai cégek.

3. Az örökölt rendszerek horgonya

A harmadik vektor az, amelyet a bankok már a legjobban értenek, és amelyet az ügynöki átmenet egyszerre tett sürgetőbbé és kezelhetőbbé. A Fortune 500 vállalatok több mint 70%-a még mindig nagyszámítógépekre támaszkodik, jegyzi meg a Computer Weekly elemzése ⧉, amelyek gyakran évtizedek egymásba szőtt COBOL és RPG kódjára épülnek, egyedi üzleti logikával. Kifejezetten a pénzügyi szolgáltatásokban az örökölt technológiák az éves IT-kiadások 70-75%-át ⧉ emésztik fel. Egy 2026-os iparági elemzésben idézett CIO-tanulmány megállapította, hogy a bankok 63%-a még mindig a 2000 előtt írt kódra támaszkodik, és több mint 75% arról számolt be, hogy csak egy vagy két olyan belső munkatársa van, aki képes karbantartani azt.

Ami 2026 februárjában megváltozott, az a hiteles ügynöki eszközök megjelenése volt az örökölt rendszerek modernizációjához. Az Anthropic bejelentése, miszerint a Claude Code képes feltérképezni a COBOL-függőségeket, dokumentálni a munkafolyamatokat és azonosítani azokat a kockázatokat ⧉, amelyek felszínre hozásához emberi elemzőknek hónapokra lenne szükségük, a Microsoft (GitHub Copilot for COBOL, Watsonx Code Assistant) és az AWS (Mainframe Modernization ügynöki MI-vel) hasonló képességeivel párosulva érdemben összenyomta a modernizációs költséggörbét. Az IBM részvényárfolyamának reakciója (a bejelentés napján 13%-os esés) nyers, de pontos piaci jelzés volt. Az MI mostanra a vállalati modernizációs beruházások nagyjából egyharmadát teszi ki, és a vállalatok több mint 75%-a használ MI-t a modernizációs stratégiájában. Az örökölt rendszerek horgonya először vált inkább kezelhető mérnöki problémává, mintsem generációssá.

Miért nem lehet a vibe coding az alapértelmezés a bankszektorban

Érdemes pontosan megfogalmazni, miért bukik meg a vibe coding, vagyis a rövid prompt, a kimenet megfigyelése, iteráció, mint alapértelmezett munkafolyamat egy szabályozott környezetben. A hibamód nem a kézenfekvő (az LLM időnként hallucinál). A hibamód strukturális, és egyszerre négy helyen jelentkezik.

Az első a közös konvenciók hiánya. A csevegőpromptokon keresztül dolgozó több mérnök egyetlen negyedév alatt ötféle módot fog előállítani ugyanannak a dolognak ugyanabban a kódbázisban való elvégzésére. Nem szabályozott kontextusban ez technikai adósság. Szabályozott kontextusban ez az a felület, amely a vizsgálat során összeomlik.

A második a kontextus elhalása. Az MI-ügynökök állapotmentesek. Egy nagy projekten a beszélgetések meghaladják a kontextusablakokat, és a korábbi architekturális döntések mögötti érvelés elpárolog. Ugyanaz az ügynök két héttel később egy új csevegésben az ellenkező döntést fogja meghozni, mert semmi sem őrzi meg az első döntés indoklását. A szabályozók számára auditnaplót igénylő rendszerek esetében ez strukturálisan összeegyeztethetetlen.

A harmadik a láthatatlan hibafelhalmozódás. A fent idézett Pearce-, Yan- és SonarQube-eredmények nem szélsőséges esetek. Ezek az az alaparány, amellyel az LLM-ek sebezhető kódot generálnak specifikációs fegyelem és szigorú tesztelés hiányában. Az a bank, amely vibe coding munkafolyamatokat futtat éles üzemben, ugyanilyen arányban halmozza fel ezeket a hibákat, anélkül hogy rálátása lenne arra, mit állított éles üzembe.

A negyedik a szabályozási nyomonkövethetőségi probléma. Az EU AI Act 12. cikke megköveteli a bemenetek és kimenetek automatikus naplózását a magas kockázatú MI-rendszerek esetében. Az SR 11-7 dokumentált modelltulajdonosi és validátori szerepeket, a modellfrissítések változáskezelését és az MI-modellkockázatról szóló igazgatótanácsi jelentéstételt követel meg. A DORA átfogó IKT-kockázatkezelést követel meg dokumentált bizonyítékokkal. Ezen kötelezettségek egyike sem teljesíthető olyan munkafolyamattal, amelynek elsődleges terméke egy csevegési előzmény, amelyet senki sem őriz meg.

A következtetés nem az, hogy az LLM-ek alkalmatlanok a bankszektor számára. A következtetés az, hogy az őket körülvevő munkafolyamatnak specifikációkat, auditnaplókat és ellenőrzési kapukat kell előállítania elsőrangú kimenetként, nem pedig utólagos megfontolásként. Működési értelemben ez a specifikációvezérelt fejlesztés.

Specifikációvezérelt fejlesztés szabályozott környezetben

A specifikációvezérelt fejlesztés (SDD) megfordítja a munka sorrendjét. Ahelyett, hogy belevágna a megvalósításba és egy ügynökkel iterálna, a csapat először egy specifikációt állít elő, vagyis architekturális döntéseket, követelményeket, interfészszerződéseket, sikerkritériumokat, biztonsági megkötéseket, és az ügynök olyan kódot generál, amely megfelel a specifikációnak. Az ellenőrzés strukturált: a specifikáció meghatározza, mit kell tennie a kimenetnek, és egy külön folyamat (tesztgenerálás, kódfelülvizsgálat, formális ellenőrzés, ahol alkalmazható) ellenőrzi, hogy megtörtént-e.

A gyakorlati eszköztár 2025 végén és 2026 elején konszolidálódott. A GitHub Spec Kitje ⧉ (2025 végén jelent meg) formalizálja a szándékot a kódgenerálás előtt. Az AWS a specifikációelső munkafolyamatokat közvetlenül a Kiro IDE-jébe ágyazza. A JetBrains és a Cursor tervezési módokat vezetett be, amelyek strukturálják az MI-interakciót. Az olyan keretrendszerek, mint a BMAD (Breakthrough Method for Agile AI-Driven Development), tovább mennek: specializált MI-ügynökök csapataival, amelyek az elemzői, architekt, fejlesztői és QA-szerepeket tükrözik a szoftverfejlesztési életciklus (SDLC) egészében. A Constitutional SDD, amelyet egy 2026 februári arXiv-cikkben formalizáltak, explicit biztonsági megkötéseket ágyaz magába a specifikációba, CWE-sebezhetőségi leképezésekkel.

Egy bank számára a lényeges változat az, amelyet az Augment Code elemzése specifikációhoz horgonyzott fejlesztésnek nevez: a specifikációk állnak elöl, az MI az általuk korlátozott kódot generál, és további irányítási rétegek (alkotmányos megkötések, felügyeleti ellenőrzőpontok, emberi jóváhagyási kapuk) helyezkednek el a generálás és az összefésülés között. Ez az egyetlen olyan változat, amely előállítja az EU AI Act 12. cikke által elvárt auditnaplót, az SR 11-7 által megkövetelt dokumentált validátori szerepet és a DORA által megkövetelt változáskezelési fegyelmet.

A szükséges beruházás valós, de kezelhető is. Azok az intézmények, amelyek ezt jól csinálják, a mérnökök napi munkáját a karakterek begépeléséről két termék előállítására helyezték át: egy specifikációra, amelynek az ügynök meg fog felelni, és egy ellenőrzési keretrendszerre, amelyen a kimenetnek át kell jutnia. A mérnökre nehezedő kognitív igény bizonyos szempontból nagyobb (a szándék világossága minden eddiginél fontosabb), más szempontból kisebb (a sablonkód megírásának mechanikus munkája eltűnt). Azok az intézmények, amelyek még nem hajtották végre ezt a váltást, még mindig olyan módban működnek, ahol az LLM egy gyorsabb gépíró. Ez a pozíció egy szabályozott környezetben a következő tizenkét hónapon túl nem fenntartható.

A most alkalmazandó szabályozási halmaz

A 2026-os szabályozási periméter az MI körül a bankszektorban már nem ellenőrzőlista; hanem egymást átfedő kötelezettségek halmaza, amelyeket együtt kell átgondolni. A legfontosabb egyetlen dátum 2026. augusztus 2., amikor az EU AI Act magas kockázatú rendszerekre vonatkozó kötelezettségei teljeskörűen kikényszeríthetővé válnak ⧉. A III. melléklet kifejezetten magas kockázatúként sorolja be a hitelpontozást, a hitelképesség értékelését, az élet- és egészségbiztosításban végzett kockázatértékelést, valamint az egyének pénzügyi helyzetének értékelését vagy besorolását. Az e besorolásból fakadó kötelezettségek közé tartozik a megfelelőségértékelés, a minőségirányítási rendszerek, a kockázatkezelési keretrendszerek, a műszaki dokumentáció, az uniós adatbázisba való bejegyzés, a robusztus adatirányítás, az emberi felügyelet és a kiberbiztonsági védelem. A magas kockázatú kötelezettségek megszegéséért kiszabható büntetések 35 millió eurót vagy a globális éves árbevétel 7%-át érik el, attól függően, melyik a magasabb.

Az AI Act mellett:

DORA (Digital Operational Resilience Act) 2025 januárja óta hatályban van, és 22 IKT-kockázatkezelési kötelezettséget hoz létre, amelyek kifejezetten kiterjednek a kritikus pénzügyi funkciókban használt MI-rendszerekre. Az IKT-kockázatkezelés, a harmadik felek feletti felügyelet, az incidensjelentés és a működési ellenállóképesség tesztelése ugyanúgy vonatkozik az MI-komponensekre, mint bármely más IKT-eszközre.
SR 11-7: a Federal Reserve és az OCC modellkockázat-kezelési útmutatója, amelyet eredetileg 2011-ben írtak, a szabályozói gyakorlatban kiterjesztették ⧉ az LLM-ekre és az ügynöki rendszerekre. Az FFIEC-vizsgálatok mostantól kifejezetten tartalmazzák az MI-irányítás hatókörét. Azok az intézmények, amelyek kérésre nem tudnak MI-modellleltárt és kockázatértékeléseket bemutatni, ma megállapításokat kapnak.
NIST AI RMF (1.0, 2023. január) az Egyesült Államokban önkéntes, de a szövetségi szabályozók alapként hivatkoznak rá. Négy funkciója (Govern, Map, Measure, Manage) tisztán leképezhető az EU AI Act strukturális követelményeire.
ISO/IEC 42001 (2023 decemberében jelent meg) az első tanúsítható MI-irányítási rendszerszabvány, amely az információbiztonságra vonatkozó ISO/IEC 27001-hez hasonlóan épül fel. A 42001-tanúsítás iránti kereslet 2026 első negyedévében erősen felgyorsult, ahogy a beszerzési követelmények elkezdtek hivatkozni rá.
Az Egyesült Királyság SM&CR és Consumer Duty szabályozása: a Senior Managers and Certification Regime mostantól nevesített elszámoltathatóságot követel meg minden magas kockázatú MI-rendszer esetében. A Consumer Duty szabályozást a közelmúltbeli FCA-útmutatás ⧉ kiterjesztette az MI által befolyásolt lakossági ügyfélkimenetekre.
A G7 posztkvantum ütemterve (2026. január), az NCSC háromfázisú migrációs keretrendszere és a BIS Project Leap megállapításai e halmaz mellett helyezkednek el. A metszéspont számít: az az MI-rendszer, amelyet olyan kriptográfiai alaprétegen tanítottak be vagy üzemeltetnek, amely nem éli túl a posztkvantum átmenetet, olyan MI-rendszer, amelynek auditnaplója és integritási állításai egy évtizednél rövidebb felezési idővel rendelkeznek. Az ügynöki mérnökségről szóló beszélgetés és a posztkvantum kriptográfiáról szóló beszélgetés egyre inkább ugyanaz a beszélgetés. (A kriptográfiai oldal mélyebb áttekintéséért lásd a 2026. májusi írást a posztkvantum migrációról a vállalati pénzügyekben.)

Az MI-vel támogatott fejlesztés három módjának összehasonlítása

Szempont	Vibe coding	Specifikációvezérelt fejlesztés	Ügynöki mérnökség
Elsődleges bemenet	Rövid prompt	Formális specifikáció	Specifikáció + ügynökvezénylési terv
A mérnök szerepe	Promptiterátor	Specifikációszerző	Vezénylő és ellenőrző
Kimeneti fegyelem	Közvetlen kódgenerálás	Specifikáció által korlátozott kód	Több ügynökös munkafolyamatok, amelyek kódot, teszteket, dokumentációt állítanak elő
Auditnapló	Csevegési előzmény (nem megőrzött)	Specifikáció + generált kód + tesztek	Specifikáció + ügynöknyomok + ellenőrzési termékek
Hibaarány (csak LLM)	10-40%-os sebezhetőségi arány (szakirodalmi alap)	A specifikációs megkötések érdemben csökkentik	Ellenőrzési kapukkal a legalacsonyabb
Szabályozási nyomonkövethetőség	Elégtelen a magas kockázatú MI-hez	Kompatibilis az EU AI Act 12. cikkével	A 12. cikk + SR 11-7 + DORA szerint tervezve
Alkalmas a bankszektorra?	Nem, éles üzemre nem	Igen, irányítással	Igen, érett irányítással
Képességi felső határ	Az egylövéses promptolás korlátozza	A specifikáció minősége korlátozza	A vezénylés minősége korlátozza

Forrás: Karpathy kommentárjának (2026), az Augment Code SDD-elemzésének ⧉, a CGI specifikációvezérelt fejlesztésről szóló elemzésének ⧉, valamint az LLM-kódgenerálás sebezhetőségi arányairól szóló tudományos szakirodalomnak (Pearce és mtsai, Yan és mtsai, Fu és mtsai, 2023-2025) a szintézise.

Az ügynöki bank megépítése: architekturális nézet

Az e munkafolyamatok mögötti stratégiai pozíció az, amelyet a felső vezetésnek kifejezetten birtokolnia kell. Az ügynöki mérnökség a bankszektorban nem fejlesztői termelékenységi kezdeményezés. Olyan intézményi képesség, amely érinti a végponttól végpontig tartó ügyfélutakat, a teljes tranzakció-életciklust, valamint a mindkettő alatt húzódó kriptográfiai és auditalapréteget. E képesség négy rétege érdemel közvetlen vezetői figyelmet, fentről lefelé:

4. réteg: ügynökvezérlősík Irányítás, audit, vészleállító kapcsolók, viselkedésbeli anomáliadetektálás, emberi felülbírálás. HITL- és HOTL-felügyeleti konfigurációk ügynökosztályonként.

3. réteg: ügynöki munkafolyamatok Ügyfélutak, belső műveletek, fejlesztési folyamat. A magas kockázatú folyamatoknál alapértelmezetten specifikációvezérelt.

2. réteg: adat- és modellréteg AIBOM (MI-anyagjegyzék), modellnyilvántartás, visszakeresési alapréteg, promptsablon-verziókövetés, finomhangolási leszármazás.

1. réteg: kvantumbiztos alap ML-KEM, ML-DSA, hibrid PKI, kriptográfiai agilitás. Az az alapréteg, amelytől minden magasabb réteg integritási állításai függenek.

1. réteg: a kvantumbiztos alap. Minden réteg e felett feltételezi a kriptográfiai alapréteg integritását. Mivel a G7 ütemterv, az NCSC háromfázisú terve és a BIS Project Leap egyaránt nyilvánosan elérhető, ez már nem szűk körű aggály. Azok az ügynöki rendszerek, amelyek auditnaplóit klasszikus ECDSA-val írják alá, vagy amelyek kulcslétesítése RSA-ra vagy ECDH-ra támaszkodik, azt fogják látni, hogy integritási állításaik a kriptográfiával együtt lejárnak. Azok az intézmények, amelyek ezt jól csinálják, a posztkvantum munkát előre hozzák, és az ML-KEM-et, az ML-DSA-t és a hibrid PKI-t tekintik annak az alaprétegnek, amelyen minden magasabb réteg audit- és integritási garanciái nyugszanak.

2. réteg: az adat- és modellréteg. Itt lakik az MI-anyagjegyzék (AIBOM). A posztkvantum migrációs tervezésben használt kriptográfiai anyagjegyzékhez hasonlóan az AIBOM minden olyan modell, adathalmaz, promptsablon, visszakeresési index, finomhangolás és harmadik féltől származó MI-függőség leltára, amelyet az intézmény üzemeltet. Ez az a termék, amelyet az EU AI Act 49. cikke gyakorlatilag megkövetel, az a leltár, amelyet az SR 11-7 vizsgálatok most kérnek, és bármely hiteles irányítási pozíció alapja. A legtöbb intézménynek nincs ilyen. Augusztusra szükségük lesz rá.

3. réteg: ügynöki munkafolyamatok. Ez az a réteg, amelyet a legtöbb intézmény jelenleg épít, gyakran anélkül, hogy kellő figyelmet fordítana az 1., 2. és 4. rétegre. Maguk a munkafolyamatok a belsőktől (kódgenerálás, szabályozási dokumentumok megfogalmazása, ügyfélszolgálati osztályozás) az ügyfélközpontúakon át (ügyfélkapcsolati menedzser-copilotok, beléptetés, KYC-vezénylés, tranzakciófigyelés, FX-optimalizálás) a teljesen autonómakig (kincstári műveletek, bizonyos kereskedési és kockázatkezelési funkciók, ahol a szabályozói tolerancia megengedi) terjednek. Az e rétegen érvényes stratégiai fegyelem az, hogy rendszermérnökségként kezeljük, nem alkalmazásfejlesztésként: a vezénylési mintázatok, az eszkalációs szabályok, a human-in-the-loop kapuk és az auditkibocsátás elsőrangú tervezési szempontok.

4. réteg: az ügynökvezérlősík. Ez az, amit a Deloitte az „ügynökvezérlő-teremként" jellemzett ⧉: a valós idejű auditálás, a műveletnaplózás, a viselkedésbeli anomáliadetektálás, a vészleállító kapcsolók és az emberi felülbírálás infrastruktúrája, amely minden éles üzemben lévő ügynököt körülvesz. A Step Finance vesztesége technikailag nem MI-hiba volt. Vezérlősík-hiba volt: az ügynököknek olyan jogosultságaik voltak, amelyeknek nem kellett volna lenniük, és az a viselkedésbeli anomália, amelynek leállást kellett volna kiváltania, nem tette. Azok az intézmények, amelyek először a vezérlősíkot építik meg, mielőtt tovább skáláznák az ügynökök bevezetését, azok, amelyek 2027-ben nem fognak Step Finance osztályú incidenseket látni.

A felső vezetés számára a releváns összehasonlítás nem az, hogy „több MI-t csinálunk-e, mint a versenytársaink?" Hanem az, hogy az intézmény birtokolja-e mind a négy réteget, vagy egy vagy több réteget csendben átruháznak-e egy olyan beszállítóra, amelynek nincs szerződéses képessége az EU AI Act 13. cikke dokumentációs követelményeinek teljesítésére. Az utóbbi olyan pozíció, amely addig tűnik rendben lévőnek, amíg egy szabályozó fel nem teszi a kérdést.

Emberi felügyelet a gyakorlatban: HITL kontra HOTL

Az egyetlen megkülönböztetés a 4. rétegen belül, amelyre a szabályozók 2026-ban a leginkább összpontosítanak, két felügyeleti modell közötti. Mindkettő az emberi felügyelet egy formája; a késleltetésben, a léptékben és abban a feltevésben különböznek, amelyet a szabályozó hajlandó megadni az ügynök viselkedéséről.

A Human-in-the-Loop (HITL) az a modell, amelyben egy ügynök nem hajthat végre következményekkel járó műveletet explicit emberi jóváhagyás nélkül. Az ügynök előkészíti a döntést, bemutatja, és vár. Az a KYC-korrekciós ügynök, amely lezárásra jelöl meg egy számlát, de nem tudja lezárni egy megfelelőségi tisztviselő jóváhagyása nélkül, HITL. A kompromisszum működési jellegű: a HITL biztonságosabb, és egyértelmű, a 14. cikk szerinti auditnaplót állít elő, de nem skálázódik a nagy volumenű, alacsony késleltetésű munkafolyamatokra.

A Human-on-the-Loop (HOTL) az a modell, amelyben egy ügynök korlátozott paramétereken belül autonóm módon hajt végre műveleteket, miközben emberek valós időben figyelik a telemetriát, és megtartják a jogot az ügynök bármely ponton történő leállítására. Az a valós idejű csalásszűrő ügynök, amely automatikusan blokkolja a meghatározott kockázati mintázatoknak megfelelő tranzakciókat, miközben egy emberi működtető csapat figyeli a riasztások mennyiségét, és beavatkozik az anomáliák esetén, HOTL. A kompromisszum fordított: a HOTL skálázódik, de arra támaszkodik, hogy az ügynök paraméterei helyesen legyenek beállítva, és arra a viselkedésbeli anomáliadetektálásra, amely elkapja az elcsúszást, mielőtt a kár felhalmozódik.

Az EU AI Act 14. cikke nem írja elő a HITL kontra HOTL választást; azt követeli meg, hogy az emberi felügyelet érdemi legyen. A gyakorlati következmény az, hogy minden magas kockázatú ügynöknek, amelyet a bank üzemeltet, explicit, dokumentált álláspontja kell legyen arról, melyik modell alkalmazandó, miért, és mi az eszkalációs útvonal, amikor az ügynök a korlátozott paraméterein kívüli helyzetekkel találkozik. A legtöbb, 2025-ben pilotokat futtató banknak nem volt ilyen dokumentációja. A legtöbb, 2026 augusztusáig éles üzemben ügynököket futtató banknak szüksége lesz rá.

A döntési szabály nem bonyolult. A következményekkel járó, alacsony volumenű, visszafordíthatatlan műveletekhez, vagyis a természetes személy hiteligényének elutasításához, a számlazáráshoz, a nagy összegű átutalás engedélyezéséhez, a szabályozói bejelentés benyújtásához, a HITL a védhető alapértelmezés. A nagy volumenű, visszafordítható, paraméterekhez kötött műveletekhez, vagyis a tranzakciófigyelési riasztásokhoz, a dokumentumbesoroláshoz, a rutinszerű ügyfélszolgálati osztályozáshoz, a HOTL megfelelő, feltéve, hogy a viselkedésbeli anomáliadetektálás és a vészleállító kapcsoló infrastruktúrája érett. Azok a bankok, amelyek minden munkafolyamatot HITL-ként kezelnek, nem fogják megragadni az ügynöki rendszerek működési tőkeáttételét. Azok a bankok, amelyek minden munkafolyamatot HOTL-ként kezelnek, előbb-utóbb átélnek egy Step Finance pillanatot.

Vásárlás kontra építés: a harmadik féltől származó ügynök problémája

A 2026-os valóság, amely a legtöbb bankra észrevétlenül tört rá, az, hogy elsősorban nem megépíteni fogják az ügynöki képességet. Meg fogják venni. A beszállítói táj, vagyis az Oracle 2026 februárjában indított ügynöki banki platformja, az IBM Watsonxe, a Microsoft Copilot csomagja, az AWS Bedrock Agents, a Salesforce Agentforce, a ServiceNow NowAssistje és a fintechspecialista ügynökbeszállítók hulláma, gyorsabban mozog, mint amire a belső banki mérnökség képes. A stratégiai következmény az, hogy a 2027-ben egy bankon belül működő ügynökök többségét valaki más írta, és az irányítási kérdés már nem az, hogy „megbízhatunk-e az ügynökeinkben?", hanem az, hogy „megbízhatunk-e a beszerzett ügynökökben, és bizonyítani tudjuk-e egy szabályozónak, hogy igen?"

Ez a DORA legharsányabb, alulértékelt kihívása. A rendelet 28-30. cikkei az IKT harmadik felekkel kapcsolatos kockázatkezelését aktív felügyeleti területté teszik, explicit követelményekkel, amelyek kiterjednek a szerződéses rendelkezésekre, a folyamatos monitoringra, a koncentrációs kockázat értékelésére és a kilépési stratégiákra. Az európai felügyeleti hatóságok nyilvántartást vezetnek a kritikus IKT harmadik fél szolgáltatókról, közvetlen felügyeleti jogkörrel az ilyennek minősítettek felett. Az új működési valóság az, hogy a 2026-os MI-beszállítók, vagyis az élvonalbeli modellszolgáltatók, az ügynökplatform-beszállítók, az MI-képes SaaS-megoldások, egyre inkább azok az IKT harmadik felek, amelyekre a DORA-t írták.

A vásárlói pozícióban lévő bank számára három gyakorlati fegyelem érvényes:

Követeljük az AIBOM-ot a beszállítótól. Bármely, magas kockázatú munkafolyamatokon való használatra beszerzett ügynöktermékhez dokumentált anyagjegyzéknek kell tartoznia, amely lefedi az alapul szolgáló modelleket, a betanítási adatok eredetét és korlátait, az alkalmazott finomhangolásokat, a hozzáfért visszakeresési indexeket, a promptsablon-verziókat és a downstream ügynökkomponensekig tartó függőségi láncot. Ez az a termék, amelyre a banknak szüksége lesz az EU AI Act 13. cikke dokumentációs követelményeinek teljesítéséhez. A bank nem tudja utólag előállítani egy olyan beszállítótól, amely szerződésben nem kötelezte magát annak biztosítására.

A fekete dobozt teszteljük, ne a prospektust. A beszállítói beszerzési értékelések történetileg a funkció-összehasonlításra és a referenciaügyfél-interjúkra összpontosítanak. Az ügynöki rendszerek esetében ez nem elegendő. Az intézménynek viselkedéstesztet kell végeznie az ügynökön a tervezett éles üzemi bevezetéséhez hasonló körülmények között, beleértve a promptinjektálásra irányuló adverzariális vizsgálatot, a social engineeringgel szembeni ellenállást (a Step Finance vektor), az adateloszlás eltolódása melletti elcsúszást, valamint a vészleállító kapcsoló és a felülbírálási útvonalak késleltetését és hibamódjait. A legtöbb jelenlegi beszállítói szerződés nem engedi meg a tesztelés ilyen mélységét külön tárgyalás nélkül; ennek a tárgyalásnak a szerződés aláírása előtt kell megtörténnie, nem utána.

Tárgyaljuk újra a szerződéseket a 13. cikk feltételei szerint. A legtöbb meglévő MI-beszállítói megállapodás egyáltalán nem tartalmazza azokat a dokumentációs, auditjogi, modellváltozás-értesítési, incidensjelentési vagy alfeldolgozó-nyilvánosságra hozatali követelményeket, amelyeket az EU AI Act és a DORA együttesen megkövetel. A Regulativ egyesült királyságbeli cégekről szóló elemzése ⧉ egyértelmű volt ebben a pontban: a beszállítói megállapodások jogi felülvizsgálata hetekbe telik, és a legtöbb intézmény nem tudja teljesíteni a 13. cikket egy olyan modell esetében, amelynek belső működését a beszállítója soha nem volt szerződésben köteles nyilvánosságra hozni. A szabályozási kötelezettség a bevezetőnél van, nem a beszállítónál. A beszerzési csapatoknak ezt a következő megújítási ciklus előtt kell tudniuk, nem egy szabályozói vizsgálat után.

Az igazgatótanácsi szintű összegzés az, hogy a beszállítói kapcsolat a beszerzésből a kockázatátruházásba mozdult el, és a kockázat valójában nem ruházódik át. A bank marad a bevezető. A bank marad a felelős. A banknak szüksége van azokra a szerződéses eszközökre és tesztelési fegyelemre, amelyek a felelősségét kezelhetővé teszik, nem pusztán formálissá.

Mit jelent ez banktípusonként

A helyes válasz eltérő. Az alábbi mintázat durva szegmentálás, nem előírás.

Első vonalbeli univerzális bankok

Az 1 billió dollárt meghaladó mérlegfőösszegű és globális jelenlétű intézmények egyszerre a leginkább kitettek (a legszélesebb szabályozási periméter, a legnagyobb örökölt rendszerállomány, a legértékesebb célpont az autonóm ellenfelek számára) és a legjobban ellátottak forrásokkal. A stratégiai prioritás az, hogy először a vezérlősíkot építsék meg, vagyis a fenti architektúra 4. rétegét, és hogy a specifikációvezérelt fejlesztés fegyelmét bevezessék a belső mérnöki funkcióba, mielőtt tovább skáláznák az ügynökök bevezetését. Ennek helyes elvégzésének versenybeli következménye jelentős; a rossz elvégzésének következménye egzisztenciális, tekintettel az EU AI Act szerinti büntetéskitettségre és a GTG-1002 osztályú fenyegetési mintázatoknak való működési kitettségre.

Középvonalbeli és regionális bankok

A versenykérdés a másodvonalbeli bankok számára élesebb, mint az elsővonalbeliek számára. Ugyanazzal a szabályozási periméterrel néznek szembe ugyanolyan irányítási költségvetés nélkül, ugyanazzal a fenyegetési felülettel ugyanolyan védekezési erőforrások nélkül, és egy olyan ügyfélbázissal, amely egyre inkább az MI-natív fintechekhez hasonlítja őket. A gyakorlati válasz az, hogy keményen szabványosítsanak egy kis, átvizsgált beszállítói csoportra (olyan szerződésekkel, amelyek teljesítik a 13. cikk dokumentációs követelményeit), hogy a specifikációvezérelt fejlesztés fegyelmébe fektessenek be, nem pedig egyedi platformmérnökségbe, és hogy ügynöki eszközöket használjanak a COBOL-modernizáció idővonalának összenyomására, amely két évtizede stratégiai horgony volt. Azok az intézmények, amelyek itt korán lépnek, egy generáció óta először érdemben zárják a technológiai szakadékot az elsővonalbeli bankokkal.

Fintechek, PSP-k és kriptovaluta-közeli intézmények

A fintech- és fizetésiintézmény-szegmensnek fordított a problémája: az agilitás magas, az irányítás gyakran alacsonyabb, mint a hasonló bankoké, és az EU AI Act büntetéskitettsége egy közepes méretű fintech számára potenciálisan egzisztenciális. A stratégiai fegyelem az, hogy az MI-irányítást termékérettségi kapuként kezeljük, nem megfelelőségi ráhelyezett rétegként: az AIBOM-ot, az auditalapréteget és a specifikációvezérelt munkafolyamatokat kezdettől fogva a mérnöki kultúrába építve, nem pedig szabályozói nyomás alatt utólag beszerelve. Azon intézmények számára, amelyek fizetési infrastruktúrája metszi a 2026. novemberi SWIFT CBPR+ strukturált címzési határidőt, az ügynöki mérnökségi beruházás egyben a természetes mechanizmus a strukturált címzés korrekciós munkájának iparosítására: a validációs szabályok, az adatminőség kikényszerítése és a CI-folyamatba való integráció pontosan azok a mintázatok, amelyeket a specifikációvezérelt munkafolyamatok kezelhetővé tesznek.

Belső mérnöki funkciók

Az ezt olvasó mérnökök és kutatók számára a lényeges munkafegyelem a napi. Helyezzük a munka súlypontját a karakterek begépeléséről specifikációk és ellenőrzési keretrendszerek előállítására. Kezeljük az ügynöknyomokat, a köztes terveket és a jóváhagyási kapukat elsőrangú termékként a verziókövetésben. Fektessünk be olyan eszközökbe, vagyis a Spec Kitbe, a Kiróba, a Cursor terv módjába, a projektszintű skillfájlokkal ellátott Claude Code-ba, amelyek a specifikációt teszik tartós termékké, a generált kódot pedig eldobhatóvá. Az ergonómiai váltás valós. A szakmai megtérülés az, hogy az élvonalon elfogadott fegyelem egyben az a fegyelem is, amely túléli a szabályozói vizsgálatot.

A 12 hetes cselekvési terv 2026 augusztusáig

A mostantól az EU AI Act kikényszerítési dátumáig ügynöki mérnökségi programot vezető vezetői szponzor számára a munka tizenkét hetes szekvenciába tömörül. Az alábbi terv nem teljeskörű; ez az a minimum, amelyet egy igazgatótanácsnak elvárnia kell egy hiteles programtól, hogy 2026. augusztus 2-ig teljesítse.

1-2. hét: állítsuk elő az AIBOM-ot. Hozzuk létre minden éles üzemben vagy fejlesztés alatt álló MI-rendszer, modell, adathalmaz, promptsablon, visszakeresési index, finomhangolás és harmadik féltől származó MI-függőség központosított leltárát. Képezzük le minden tételt az EU AI Act III. mellékletének besorolására. A leszállítandó egy egységes igazságforrás, amelyet a CRO, a CCO, a CISO és a CTO egyaránt lekérdezhet.

3-4. hét: soroljuk be a felügyeleti modellt rendszerenként. Minden magas kockázatú és következményekkel járó ügynök esetében dokumentáljuk explicit módon, hogy a felügyeleti modell HITL vagy HOTL, az indoklást, az eszkalációs útvonalat, és az SM&CR (Egyesült Királyság) vagy az azzal egyenértékű nemzeti rezsim szerint nevesített felelős embert. Ahol a válasz nem egyértelmű, alapértelmezetten a HITL-t alkalmazzuk, amíg az elemzés el nem készül.

5-6. hét: építsük meg vagy erősítsük meg az ügynökvezérlősíkot. Valós idejű műveletnaplózás, viselkedésbeli anomáliadetektálás, vészleállító kapcsoló és felülbírálási útvonalak működjenek minden éles üzemben lévő ügynökön. Ahol egy rendszerhez a vezérlősík még nem létezik, az a rendszer korlátozott bevezetési státuszba kerül, amíg létre nem jön.

7-8. hét: beszállítói szerződések felülvizsgálata. A jogi és a beszerzési részleg minden aktív MI-beszállítói szerződést átnéz a 13. cikk szerinti dokumentációs jogok, a modellváltozás-értesítés, az incidensjelentés, az auditjogok és az alfeldolgozó-nyilvánosságra hozatal szempontjából. A kimenet egy szintezett lista: megfelelő, korrekció szükséges, csere szükséges. A csereről szóló döntéseknek most kell elkezdődniük, hogy legyen bármi esélyük az idei évben befejeződni.

9-10. hét: próbáljuk el a megfelelőségértékelést. A III. melléklet szerinti minden magas kockázatú rendszernél végezzük el a megfelelőségértékelési munkafolyamatot, mintha a következő héten egy bejelentett szervezet érkezne. Ez felszínre hoz olyan hiányosságokat, amelyek papíron kisebbnek tűnnek, de a vizsgálat során működési szempontból súlyosak. Javítsuk ki, ami kijavítható; dokumentáljuk a maradékot.

11-12. hét: átállás előtti validáció és igazgatótanácsi jóváhagyás. Az AIBOM, a HITL/HOTL besorolások, a vezérlősík bizonyítékai, a beszállítói korrekciós státusz és a megfelelőségértékelés kimeneteinek végső felülvizsgálata. A nevesített felső vezetői elszámoltathatóság megerősítve. Rögzítsük az álláspontot az igazgatótanácsi jegyzőkönyvben. Értesítsük a szabályozót, ahol a keretrendszer előzetes bejelentést vár el.

Azok az intézmények, amelyek befejezik ezt a tizenkét hetes szekvenciát, nem oldották meg az ügynöki mérnökséget. Megteremtették azt az alsó szintet, amelyet egy hiteles program megkövetel. Azok az intézmények, amelyek e cikk megjelenéséig nem kezdtek bele, ahogy a Regulativ elemzése ugyanezt a pontot a SWIFT-oldalon megfogalmazta, nem egyedülállóan hanyagok. Ők a többség. A kérdés, amelyet minden CCO-nak, CRO-nak és CTO-nak meg kell válaszolnia a következő két hétben, az, hogy a cég májusban cselekszik-e, vagy júliusban kapkod.

Következtetés

A kemény megfigyelés, amely az elmúlt hat hónapban az iparágban kikristályosodott, az, hogy a vállalati léptékű működés régi módjait nem egy új technológia, hanem egy új munkamintázat múlja felül. Az ügynöki eszközök felfedtek, néha éles üzemben, néha incidensjelentésekben, olyan hibákat és hiányosságokat az örökölt rendszerállományokban, amelyek évek óta csendben halmozódtak. Ugyanezek az eszközök olyan erőforrásokat biztosítottak rosszindulatú szereplőknek, amelyek korábban állami szereplői hátteret igényeltek. Ugyanezek az eszközök, belsőleg és fegyelmezetten használva, a leghitelesebb út, amellyel az intézmények bezárhatják az örökölt rendszerek szakadékát, teljesíthetik a 2026 augusztusi szabályozási határidőt, és elérhetik azt a működési tempót, amelyet az ügyfélelvárások és a versenybeli realitások most megkövetelnek.

Azok az intézmények, amelyek ezt a pozíciót belsőleg birtokolják, vagyis amelyek az ügynöki mérnökséget a bank strukturális képességeként kezelik, nem pedig egy beszállítótól beszerzett termelékenységi ráhelyezett rétegként, a következő két évet az előny halmozásával fogják tölteni. Azok az intézmények, amelyek nem, a következő két évet azzal fogják tölteni, hogy incidensjelentésekben és szabályozói megállapításokban fedezik fel, mit kellett volna megépíteniük. A választás e két kimenetel között egy 2026-os igazgatótanácsi szintű döntés, nem egy 2028-as technológiai.

A jelen oldalon szereplő korábbi kontextusért: a kvantumküszöbökről szóló 2026. áprilisi írás a fenti architektúra 1. rétegét alátámasztó hardvertrajektóriát tárgyalta, a vállalati pénzügyek posztkvantum migrációjáról szóló 2026. májusi írás mélységében tárgyalta a kriptográfiai alapréteget, a pacs.008 strukturált címzési határidejéről szóló 2026. májusi elemzés azt a szabályozási és mérnöki fegyelmet tárgyalta, amelyet a specifikációvezérelt validáció kezelhetővé tesz, a KyberLib, pain001 és pacs008 Rust nyílt forráskódú munka pedig abba a szélesebb erőfeszítésbe illeszkedik, amely éles üzemi minőségű primitíveket, vagyis kvantumbiztos, fizetésmegfelelő, auditra kész primitíveket kíván az ügynöki bankot megépítő mérnökcsapatok kezébe adni. Az e írások közötti kapcsolat nem véletlen. Ez a következő két év által megkövetelt munka alakja.

Gyakran feltett kérdések

Mi a különbség a generatív MI, az ügynöki MI és az ügynöki mérnökség között?

A generatív MI tartalmat állít elő egy promptra válaszul; reaktív. Az ügynöki MI meghatározott célokat követ autonóm módon, adatokhoz fér hozzá, eszközöket használ, és cselekszik többlépcsős munkafolyamatokon keresztül anélkül, hogy minden lépésnél emberi promptot igényelne. Az ügynöki mérnökség, a kifejezés, amelyet Karpathy 2026-ban vett át ⧉, az a munkafegyelem, amely az ügynökök részletes specifikációkkal szembeni vezénylését jelenti emberi felügyelet mellett. A bankszektor számára a megkülönböztetés azért számít, mert a szabályozási periméter, a fenyegetési modell és a mérnöki fegyelem eltérő minden egyes kategória esetében. Egy csevegőfelület és egy teljesen autonóm kereskedési ügynök nem ugyanabban a szabályozási osztályban van, és úgy kezelni őket, mintha igen, mindkét végén kitettséget teremt.

Miért olyan következményekkel járó az EU AI Act 2026 augusztusi határideje a bankok számára?

Az AI Act III. melléklete kifejezetten magas kockázatúként sorol be több alapvető banki MI-felhasználási esetet: természetes személyek hitelképességének értékelését és hitelpontozását, az élet- és egészségbiztosításban végzett kockázatértékelést és árazást, valamint az egyének pénzügyi helyzetének értékelését vagy besorolását. 2026. augusztus 2-tól e rendszerek bevezetőinek igazolniuk kell a megfelelést a minőségirányítási rendszerek, a kockázatkezelési keretrendszerek, a műszaki dokumentáció, a megfelelőségértékelések, az uniós adatbázisba való bejegyzések, a robusztus adatirányítás, az emberi felügyelet és a kiberbiztonsági védelem tekintetében. A 12. cikk megköveteli a bemenetek és kimenetek automatikus naplózását. A 14. cikk érdemi emberi felügyeletet követel meg (HITL vagy HOTL, a rendszernek megfelelően). A jogsértésért kiszabható büntetések elérik a 35 millió eurót vagy a globális éves árbevétel 7%-át. Az e kötelezettségek teljesítésére irányuló munka mérnöki munka, nem dokumentációs munka, és ez a gyakorlati oka annak, hogy a specifikációvezérelt fegyelem 2026 első negyedévében felgyorsult.

Mi a gyakorlati különbség a HITL és a HOTL között, és mikor melyiket kell alkalmazni?

A HITL (Human-in-the-Loop) azt jelenti, hogy az ügynök nem hajthat végre következményekkel járó műveleteket explicit emberi jóváhagyás nélkül. A HOTL (Human-on-the-Loop) azt jelenti, hogy az ügynök korlátozott paramétereken belül autonóm módon hajt végre műveleteket, miközben emberek figyelik a telemetriát, és megtartják a jogot a bármely ponton történő leállításra. Az EU AI Act 14. cikke megköveteli, hogy a felügyelet érdemi legyen, de nem írja elő, melyik modellt. A döntési szabály az, hogy a HITL-t ott alkalmazzuk, ahol a művelet következményekkel jár, alacsony volumenű és visszafordíthatatlan (hiteligény elutasítása, számlazárás, nagy összegű átutalás engedélyezése, szabályozói bejelentés benyújtása); a HOTL-t pedig ott, ahol a művelet nagy volumenű, visszafordítható és paraméterekhez kötött (tranzakciófigyelési riasztások, dokumentumbesorolás, rutinszerű ügyfélszolgálati osztályozás). Mindkettő megköveteli, hogy a vészleállító kapcsoló és a felülbírálási infrastruktúra működőképes és tesztelt legyen; a különbség az, hogy az ember a végrehajtás előtt áll-e (HITL) vagy mellette (HOTL).

Ügynökeink többsége beszállítóktól fog származni. Hogyan feleljünk meg a DORA-nak és az EU AI Actnek olyan rendszerek esetében, amelyeket nem mi építettünk?

A szabályozási kötelezettség a bevezetőnél van, nem a beszállítónál. A gyakorlati válasz háromrétű. Először, aláírás előtt követeljünk dokumentált AIBOM-ot a beszállítótól: modellleszármazás, betanítási adatok eredete, finomhangolások, promptsablonok, visszakeresési indexek, függőségi lánc. Másodszor, végezzünk viselkedéstesztet az ügynökön az éles üzemhez hasonló körülmények között, beleértve a promptinjektálásra irányuló adverzariális vizsgálatot és a social engineeringgel szembeni ellenállást. Harmadszor, tárgyaljuk újra a beszállítói szerződéseket úgy, hogy tartalmazzák a 13. cikk szerinti dokumentációs jogokat, a modellváltozás-értesítést, az incidensjelentést, az auditjogokat és az alfeldolgozó-nyilvánosságra hozatalt: a legtöbb meglévő szerződésben ezek egyike sincs meg. A DORA 28-30. cikkei lefedik az IKT harmadik felekkel kapcsolatos kockázatkezelését, és ezek a releváns szabályozási horgony az európai oldalon; az FFIEC-útmutatás az egyenértékű az amerikai oldalon. A munka érdemi; nem halasztható.

Mennyire kell a bankoknak valójában aggódniuk az ügynöki ellenfelek miatt?

Az őszinte válasz az, hogy a fenyegetés valós, és működési szempontból különbözik a korábbi kiberfenyegetésektől. A GTG-1002 2025 novemberi Anthropic-feltárása a kanonikus példa: ügynöki MI, amely egy állami támogatású kémkedési kampányban a taktikai műveletek 80-90%-át kezeli megközelítőleg harminc védelmi, energetikai és technológiai célpont ellen, másodpercenként több ezer kérés sebességével működve. A Step Finance 2026 januári incidense, egy 27-30 millió dolláros veszteség, amelyet túljogosultsággal rendelkező MI-kereskedési ügynökök okoztak, a kanonikus példa arra, hogyan válhat egy belső MI-bevezetés támadási felületté. A Flashpoint 2026-os GTIR jelentése 1500%-os növekedést figyelt meg az MI-vel kapcsolatos illegális eszmecserékben egyetlen hónap alatt. Ezek nem hipotetikus forgatókönyvek; ezek 2025-2026-os incidensjelentési anyagok. Azok a bankok, amelyek klasszikus védekezési műveleteket futtatnak ügynöki ellenfelekkel szemben, strukturálisan aszimmetrikusan kitettek, és a helyes válasz az, hogy MI-MI elleni védekezési képességet építsünk, nem pedig hogy lassítsuk az ügynöki átmenetet a támadó oldalon.

Az ügynöki MI csupán „ChatGPT plusz MCP-szerverek"?

Nem, és ez az egyik legjelentősebb tévhit a jelenlegi piacon. Az MCP-szerverekkel bővített csevegőfelület hasznos mintázat adatok visszakeresésére és az azok alapján történő cselekvésre egy behatárolt munkameneten belül. Az ügynöki mérnökség az intézmény strukturális képessége: az AIBOM, az ügynökvezérlősík, a specifikációvezérelt fejlesztési folyamat, az auditalapréteg, a kvantumbiztos kriptográfiai alap, a végponttól végpontig tartó ügyfélutak vezénylési mintázatai. Ezek nem egy beszállítótól vásárolt funkciók; hanem egy intézményi tulajdonosi pozíció. Azok a bankok, amelyek a kérdést beszerzési döntésként kezelik, sekély bevezetésekkel végzik, amelyek a vizsgálat során megbuknak. Azok a bankok, amelyek mérnöki és irányítási tulajdonosi kérdésként kezelik, olyan eszközzel végzik, amely halmozódik.

Mi az az egyetlen legfontosabb dolog, amelyet egy banknak a következő tizenkét hétben tennie kell?

Három dolog, sorrendben. Először, állítsuk elő az MI-anyagjegyzéket: minden éles üzemben vagy fejlesztés alatt álló MI-rendszer, modell, adathalmaz, promptsablon, visszakeresési index és harmadik féltől származó MI-függőség teljes leltárát, ahol minden tétel az EU AI Act III. melléklete szerint van besorolva. Az az intézmény, amely ezt nem tudja előállítani, amikor egy szabályozó kéri, az az intézmény, amely megállapításokat fog kapni. Másodszor, építsük meg az ügynökvezérlősíkot minden olyan MI-rendszerhez, amely jelenleg ügyfeleket érintő döntéseket hoz vagy azokat érdemben befolyásolja: auditnaplózás, viselkedésbeli anomáliadetektálás, emberi felülbírálás és vészleállító kapcsolók mint alapértelmezett infrastruktúra, nem pedig mint jövőbeli ütemterv-tétel. Harmadszor, mozdítsuk el a belső mérnöki kultúrát a vibe codingról a specifikációvezérelt fejlesztésre a legfontosabb munkán: a magas kockázatú rendszereken, a szabályozott munkafolyamatokon és az örökölt rendszerek modernizációs folyamatán. Az első kettő megfelelőségi munka; a harmadik versenybeli munka. Azok az intézmények, amelyek mindhármat elvégzik, érdemben erősebb pozícióban lesznek, mint azok, amelyek egyet vagy egyet sem. A teljes tizenkét hetes szekvencia a fenti cselekvésiterv-szakaszban van kifejtve.

Hivatkozások

Sebastien Rousseau, (2026). A főkönyv biztosítása: igazgatótanácsi szintű útmutató a posztkvantum migrációhoz a vállalati pénzügyekben.
Sebastien Rousseau, (2026). A 2026. novemberi pacs.008 strukturált címzési határidő: hathónapos áttekintés.
Sebastien Rousseau, (2026). A kvantumküszöbök ismét mozognak.
Sebastien Rousseau, (2023). CRYSTALS-Kyber: a védelmező algoritmus a kvantumkorszakban.
Mansurova, M. (2026). A vibe codingtól a specifikációvezérelt fejlesztésig ⧉. Towards Data Science.
CGI, (2026). Specifikációvezérelt fejlesztés: a vibe codingtól a szándékmérnökségig ⧉. CGI.
Augment Code, (2026). Mi a specifikációvezérelt fejlesztés? Teljes útmutató ⧉. Augment Code.
BCMS, (2026). Specifikációvezérelt fejlesztés: a végleges 2026-os útmutató ⧉. BCMS.
Deloitte, (2026). Az MI-ügynökök új kockázati hullámának kezelése a bankszektorban ⧉. Deloitte Center for Financial Services.
Anthropic, (2025). Az MI visszaélésének észlelése és leküzdése: 2025. augusztus ⧉. Anthropic.
Anthropic, (2025). Az első bejelentett MI-vezérelt kiberkémkedési kampány megzavarása ⧉. Anthropic.
Flashpoint, (2026). 2026-os globális fenyegetésfelderítési jelentés ⧉. HSToday / Flashpoint.
Beam AI, (2026). 5 valós MI-ügynök biztonsági incidens 2026-ban és tanulságaik ⧉. Beam.
Congressional Research Service, (2026). Ügynöki mesterséges intelligencia és kibertámadások ⧉. Congress.gov.
European Commission, (2024). A mesterséges intelligenciáról szóló (EU) 2024/1689 rendelet (EU AI Act).
Knowlee, (2026). Az EU AI Act a pénzügyi szolgáltatások számára: a III. melléklet kötelezettségei bankok, fintechek és biztosítók számára ⧉. Knowlee.
Regulativ, (2026). Az EU AI Act 2026 augusztusi határideje: mit kell most tenniük a pénzügyi szolgáltató cégeknek ⧉. Finextra.
AegisAI Compliance, (2026). MI-irányítás bankok számára: SR 11-7 és EU AI Act megfelelőségi útmutató ⧉. AegisAI.
The Financial Brand, (2026). Hogyan fogják az autonóm MI-ügynökök valójában újradefiniálni a banki növekedést ⧉. The Financial Brand.
UXDA, (2026). Fenyegetheti-e az ügynöki MI-banki tevékenység a globális pénzügyi szolgáltatásokat? ⧉. UXDA.
Neurons Lab, (2026). Ügynöki MI a pénzügyi szolgáltatásokban: kutatási összefoglaló 2026-ra ⧉. Neurons Lab.
Computer Weekly, (2026). Az MI segít a nagyszámítógépeknek üzletileg kritikusnak maradni 2026-ban ⧉. Computer Weekly.
The Financial Revolutionist, (2026). Az örökölt rendszerek kockázatnak teszik ki a bankokat ⧉. The Financial Revolutionist.
CIO Magazine, (2025). Az MI használata a nagyszámítógépek modernizálására: az örökölt technológia stratégiai előnnyé alakítása ⧉. CIO Magazine.
Microsoft Azure, (2025). Hogyan használunk MI-ügynököket a COBOL-migrációhoz és a nagyszámítógépes modernizációhoz ⧉. Microsoft DevBlogs.
VentureBeat, (2026). A vállalati léptékű ügynöki kódolás specifikációvezérelt fejlesztést követel ⧉. VentureBeat.
The News (Pakistan), (2026). Miért aggasztja a brit bankok ügynöki MI iránti törekvése az egyesült királyságbeli szabályozókat ⧉. The News International.
CNBC, (2026). Az Anthropic Mythosa kiberbiztonsági „hisztériát" váltott ki ⧉. CNBC.

Utolsó felülvizsgálat 2026-07-14.

A cikk újraközlése

Ügynöki mérnökség bankok számára: 2026-os tervrajz a felső vezetésnek és az azt megépítő mérnököknek — Sebastien Rousseau

Az ügynöki MI a pilotfázisból átlépett az éles üzembe a globális bankszektorban. Az intézmények 70%-a valamilyen mértékben használja; csak minden ötödiknek van érett irányítási modellje. Eközben az autonóm támadók gépi sebességgel működnek, az örökölt COBOL-rendszert, amellyel az új rendszereknek együtt kell működniük, az 1960-as évek kötegelt feldolgozási feltevéseire írták, és az EU AI Act 2026 augusztusi magas kockázatú határideje tizenkét hétre van. Ez az a mérnöki és irányítási pozíció, amelyet egy banknak tartania kell.

Ez a cikk a következő licenc alatt áll: Creative Commons Attribution 4.0 International. Az újraközléshez a kanonikus URL forrásmegjelölése szükséges.

Ügynöki mérnökség bankok számára: 2026-os tervrajz a felső vezetésnek és az azt megépítő mérnököknek — Sebastien Rousseau

Az ügynöki MI a pilotfázisból átlépett az éles üzembe a globális bankszektorban. Az intézmények 70%-a valamilyen mértékben használja; csak minden ötödiknek van érett irányítási modellje. Eközben az autonóm támadók gépi sebességgel működnek, az örökölt COBOL-rendszert, amellyel az új rendszereknek együtt kell működniük, az 1960-as évek kötegelt feldolgozási feltevéseire írták, és az EU AI Act 2026 augusztusi magas kockázatú határideje tizenkét hétre van. Ez az a mérnöki és irányítási pozíció, amelyet egy banknak tartania kell.

Originally published at https://sebastienrousseau.com/hu/2026-05-17-agentic-engineering-banks-blueprint-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER