A színes spagettikód bosszúja

A közösségi média új technológiai prófétái nem szerény emberek.

Nem egyszerű automatizálásokat készítenek. „Autonóm vállalati ökoszisztémákat” építenek. Nem összekötnek néhány szolgáltatást. „Agentic infrastructure”-t terveznek. Nem egy szöveges modellt hívnak meg egy API-n keresztül. „Digitális munkaerőt” állítanak hadrendbe.

A bizonyíték rendszerint egy képernyőkép.

A képen százötven színes doboz, közöttük nyilak, elágazások, visszacsatolások és egymásba kötött AI-ügynökök láthatók. Az egész úgy fest, mintha egy nukleáris erőmű vezérlőrendszerét keresztezték volna egy metróhálózattal. A néző nem érti, mi történik, és éppen ez adja az ábra erejét. A bonyolultság szakértelemnek látszik. Az átláthatatlanság mélységnek. A sok node pedig bizonyítéknak arra, hogy az alkotó valami rendkívül fejlett dolgot épített.

Pedig könnyen lehet, hogy csak a spagettikód tért vissza.

Ezúttal nem olvashatatlan függvényekben, globális változókban és egymásba ágyazott feltételekben jelenik meg, hanem színes dobozokban. A káosz kapott egy vizuális szerkesztőt, néhány látványos animációt és egy sokkal jobb marketingnevet.

A node-hálózat a spagettikód olyan változata, amely végre jól mutat a LinkedInen.

És most ezt adják el cégeknek.

Nem prototípusként. Nem kísérletként. Nem belső segédeszközként. Hanem ügyfélkezelő rendszerként, automatikus értékesítőként, pénzügyi asszisztensként, HR-szűrőként, tartalomgyárként, ügyfélszolgálatként és néha olyan üzletkritikus infrastruktúraként, amely hozzáfér a levelezéshez, a CRM-hez, a dokumentumokhoz, a számlázáshoz és az ügyféladatokhoz.

Mindezt gyakran olyan emberek építik, akik nem tudják, mi az idempotencia, soha nem terveztek tranzakciót, nem írtak regressziós tesztet, nem kezeltek párhuzamos futásokat, nem állítottak helyre sérült adatbázist, és életükben nem vittek végig egy valódi, éveken át működő vállalati rendszert.

Az AI nem tette őket szoftvermérnökké.

Csak lehetővé tette, hogy a tudásuk határainál jóval nagyobb rendszereket építsenek.

A problémát pedig nem ők fogják megfizetni.

Hanem a megrendelő.

A működő demó nem működő rendszer

Egy AI-automatizálás bemutatása nevetségesen egyszerű.

Érkezik egy e-mail. Egy node kiolvassa. Egy másik elküldi egy nyelvi modellnek. A modell felismeri a témát, készít egy összefoglalót, majd egy újabb node beírja az adatokat egy táblázatba. A bemutatón minden működik. Az ügyfél tapsol. Az automatizáló levágja a videót, feltölti a közösségi médiába, és bejelenti, hogy újabb vállalatot „transzformált AI-first szervezetté”.

A demó tíz mintalevéllel futott.

A valódi rendszer azonban nem tíz tiszta mintalevéllel fog találkozni.

Kap húszezer üzenetet. Sérült mellékletet. Hibás karakterkódolást. Jelszóval védett PDF-et. Továbbított levelezési láncot. Automatikus választ. Vírusgyanús ZIP-fájlt. Duplikált webhookot. Hiányzó ügyfélazonosítót. Több nyelven írt panaszt. Egy olyan számlát, amelyet egyszer már feldolgozott, de az előző futás a negyedik lépésnél megszakadt.

Mi történik ilyenkor?

A legtöbb látványautomatizálás erre nem tud válaszolni, mert a készítője nem rendszert épített. Egy sikeres útvonalat rajzolt fel.

A valódi szoftver nem attól valódi, hogy egyszer végigfutott. Attól valódi, hogy tudjuk, mit tesz akkor is, amikor valami elromlik.

A termelési rendszernek kezelnie kell a párhuzamos végrehajtást, a sorba állított feladatokat, a futások korlátozását, a hibás végrehajtások megőrzését, a bináris adatok tárolását, a visszaállítást, a verziózást, a biztonsági auditot és a külön fejlesztői, teszt- és éles környezeteket. Ezek nem az öreg programozók mániái. Maga az n8n dokumentációja tárgyalja külön a queue módot, a workerfolyamatok konkurencialimitjét, a külső adattárolást, a biztonsági auditot és a forráskódkontrollal kezelt környezeteket.

A platform készítői pontosan tudják, hogy az éles automatizálás nem néhány doboz összekötése.

Az önjelölt AI-architektus viszont gyakran csak a dobozokat látja.

Nem az n8n a hibás

Ezt fontos világossá tenni: az n8n, a Make, a Zapier és a többi low-code vagy no-code platform önmagában nem átverés.

Ezek rendkívül hasznos eszközök lehetnek.

Kiválóan alkalmasak egyszerű integrációkra, belső munkafolyamatokra, prototípusokra, értesítésekre, adatmozgatásra, időzített feladatokra és olyan alacsony kockázatú folyamatokra, amelyeknél egy esetleges hiba nem állítja le a vállalatot, nem veszélyeztet ügyféladatokat és nem hoz visszafordíthatatlan döntést.

A probléma ott kezdődik, amikor az eszköz kezelőfelületének ismeretét összetévesztik a rendszertervezési tudással.

Attól, hogy valaki tud node-okat elhelyezni a vásznon, még nem feltétlenül tud:

• adatmodellt tervezni;

• jogosultsági rendszert kialakítani;

• tranzakciót kezelni;

• párhuzamos folyamatokat szinkronizálni;

• skálázható architektúrát készíteni;

• biztonsági fenyegetést modellezni;

• incidens után adatot helyreállítani;

• teljes költséget előre jelezni;

• vagy felelősséget vállalni egy üzletkritikus rendszerért.

Egy villanyszerelő szerszámait bárki megvásárolhatja. Ettől még nem lesz jogosult egy kórház elektromos hálózatának megtervezésére.

A no-code platform demokratizálta a fejlesztést. Ez jó.

De ugyanazzal a mozdulattal demokratizálta a szakszerűtlenséget is.

A nodepornó: minél nagyobb a káosz, annál több a lájk

A közösségi médiában külön vizuális műfajjá vált az egész képernyőt betöltő workflow.

A képet rendszerint nagyítás nélkül lehetetlen elolvasni. Nem is az a cél, hogy bárki megértse. A cél a lenyűgözés.

Nézd, mennyi node!

Nézd, mennyi ügynök!

Nézd, mennyi modell!

Nézd, hány alkalmazást kötöttem össze!

A jó rendszertervezés egyik alapvető célja azonban nem a maximális, hanem a minimálisan szükséges bonyolultság.

Ha ugyanazt a feladatot húsz komponens helyett öttel megbízhatóan meg lehet oldani, akkor a húszkomponenses rendszer nem fejlettebb. Rosszabb.

Minden új node új hibalehetőség.

Minden elágazás új tesztelendő útvonal.

Minden külső szolgáltatás új függőség.

Minden modellhívás új változó költség.

Minden prompt új, informálisan definiált üzleti szabály.

Minden automatikus újrapróbálkozás újabb számlázható kudarc.

Minden ügynök újabb olyan döntési pont, amelynek viselkedése nem írható le egyszerűen egy hagyományos algoritmussal.

A színes hálózat tehát nem feltétlenül a képesség bizonyítéka. Sokszor a tervezési fegyelem hiányának térképe.

A tapasztalt mérnök rendszerint egyszerűsít.

A közösségi médiás AI-próféta rendszerint hozzáad még három ügynököt.

A számla, amelyet az értékesítési prezentáció nem mutat meg

Az AI-automatizálás kezdetben olcsónak tűnik.

Az eladó megmutatja a platform havidíját, hozzáad egy modell-előfizetést, és kijelenti, hogy a vállalat havi néhány tízezer forintért digitális munkatársat kap.

Ez a szám gyakran semmit nem jelent.

Az AI-rendszer teljes költségét ugyanis nem egyetlen előfizetés határozza meg. Fizetni lehet:

• a workflow-végrehajtásokért;

• az egyes műveletekért vagy taskokért;

• a modell bemeneti tokenjeiért;

• a modell kimeneti tokenjeiért;

• a promptcache írásáért és olvasásáért;

• a hosszú kontextusért;

• a reasoning tokenekért;

• a webes keresésekért;

• a fájlfeldolgozásért;

• az OCR-ért;

• a képek és hanganyagok feldolgozásáért;

• a vektoradatbázisért;

• az embeddingekért;

• az adatforgalomért;

• a tárhelyért;

• a futási naplókért;

• a tartalékmodellért;

• a hibás futások ismétléséért;

• és végül azért az emberért, aki ellenőrzi, amit a rendszer létrehozott.

Az n8n felhős árazása a workflow-végrehajtásokhoz kötődik. A Zapier taskkeretekkel dolgozik. A Make creditrendszerében egyetlen scenario futása a saját tájékoztatása szerint két credittől akár több ezerig is terjedhet a folyamat összetettségétől függően.

Ehhez jönnek a modellek díjai. Az OpenAI külön árazza a bemeneti és kimeneti tokeneket, valamint bizonyos eszközhívásokat és futtatási környezeteket. Az Anthropic árazásában szintén eltérhet a normál input, az output, a promptcache és a regionális adatfeldolgozás költsége.

A költségmodell tehát nem azért válik átláthatatlanná, mert a szolgáltatók feltétlenül titkolják az árakat.

Azért válik átláthatatlanná, mert az önjelölt rendszerépítő nem tudja megmondani, hány fizetős lépést fog létrehozni egyetlen üzleti esemény.

Egy beérkező ügyféllevél feldolgozása például jelentheti a következőket:

1. a levél lekérése;

2. a melléklet letöltése;

3. a PDF szövegének kinyerése;

4. az OCR futtatása;

5. a dokumentum osztályozása;

6. az ügyfél azonosítása;

7. az adatok strukturált kinyerése;

8. a kinyert adatok ellenőrzése;

9. egy vektoros keresés;

10. egy vállalati tudástár lekérdezése;

11. egy válasz megfogalmazása;

12. egy második modell általi minőségellenőrzés;

13. a CRM frissítése;

14. a válasz elküldése;

15. a teljes folyamat naplózása.

Ez még csak a sikeres végrehajtás.

Ha három lépés hibázik, és mindegyik háromszor újrapróbálkozik, egyetlen ügyféllevél mögött több tucat fizetős művelet jelenhet meg.

Az eladó mégis gyakran úgy számol, mintha egy levél egyenlő lenne egy AI-hívással.

Sok AI-automatizálást nem azért adnak fix havidíjért, mert kiszámítható a működési költsége, hanem azért, mert a készítője még nem érti, mit felejtett el beleszámolni.

Denial of Wallet: amikor nem a szerver, hanem a bankszámla omlik össze

A hagyományos túlterheléses támadás célja, hogy egy rendszer elérhetetlenné váljon.

Az AI-rendszerekben megjelent ennek pénzügyi változata: az ellenőrizetlen fogyasztás olyan mennyiségű modellhívást vagy más fizetős műveletet generál, hogy a szolgáltatás működése gazdaságilag válik fenntarthatatlanná.

Az OWASP ezt „Unbounded Consumption”, vagyis korlátlan erőforrás-fogyasztás néven külön LLM-biztonsági kockázatként kezeli. A következmények között gazdasági veszteséget, szolgáltatásromlást és az erőforrások kimerítését is felsorolja.

Ehhez még támadó sem kell.

Elég lehet egy:

• önmagát újra meghívó webhook;

• hibás ciklusfeltétel;

• végpont nélkül ismétlődő AI-ügynök;

• korlátozás nélküli retry;

• rosszul feldarabolt dokumentum;

• egyszerre többször beérkező esemény;

• vagy olyan modellválasz, amely új feladatként visszakerül a folyamat elejére.

A hagyományos programban a végtelen ciklus processzoridőt éget.

Az AI-rendszerben minden egyes kör újra számlázható.

Ez a különbség egy rosszul működő szolgáltatás és egy hónap végén érkező pénzügyi sokk között.

Az Anthropic saját API-dokumentációja külön költési és sebességkorlátokat kínál. Ez önmagában jelzi, hogy a költségkontroll nem opcionális adminisztráció, hanem az üzemeltetés egyik alapvető eleme.

Aki úgy köt össze fizetős AI-szolgáltatásokat, hogy nincs feladatonkénti, felhasználónkénti, napi és havi költségplafonja, az nem modern rendszert épít.

Nyitva hagyja a vállalat pénztárcáját, majd automatizálja a pénz kivételét.

A retry nem hibakezelés

A node-hálózatok egyik leggyakoribb ragasztószalagja az automatikus újrapróbálkozás.

Nem sikerült?

Próbáld újra háromszor.

Ha továbbra sem sikerült?

Válts modellre, majd próbáld újra.

Ha a másik modell sem tudja?

Kérdezd meg egy harmadik ügynöktől, szerinte mi lehet a hiba.

A probléma az, hogy nem minden hiba átmeneti.

Egy időtúllépés esetén az újrapróbálkozás indokolt lehet. Hibás jogosultság, sérült dokumentum, hiányzó kötelező adat, rossz séma vagy megszűnt API-végpont esetén azonban az ismétlés nem javít meg semmit.

Csak újra kifizetteti ugyanazt a kudarcot.

Egy mérnök különbséget tesz:

• átmeneti és végleges hiba;

• technikai és üzleti hiba;

• újrapróbálható és nem újrapróbálható állapot;

• részlegesen és teljesen végrehajtott tranzakció;

• valamint visszaállítható és visszafordíthatatlan művelet között.

A node-hálózat laikus építője sokszor egyetlen piros hibaágat lát.

Arra ráakaszt egy retry node-ot.

Majd büszkén közli, hogy elkészült a „self-healing architecture”.

A promptba rejtett üzleti logika

A hagyományos rendszer üzleti szabályait általában kódban, konfigurációban, döntési táblában vagy jól definiált szabályrendszerben tárolják.

Az AI-node-hálózatokban ezek egyre gyakrabban természetes nyelvű promptokba kerülnek.

„Ha az ügyfél elégedetlennek tűnik, emeld magasabb prioritásra.”

„Ha a levél valószínűleg jogi fenyegetést tartalmaz, értesítsd a vezetőt.”

„Döntsd el, hogy a pályázó megfelelő-e a pozícióra.”

„Állapítsd meg, melyik számlakategóriába tartozik a dokumentum.”

Ezek nem egyszerű utasítások.

Ezek üzleti szabályok.

Csakhogy gyakran:

• nincsenek verziókezelve;

• nincs hozzájuk tesztkészlet;

• nem dokumentált, ki módosította őket;

• ugyanaz a prompt több node-ban, eltérő változatban szerepel;

• nem tudni, melyik mondat milyen üzleti követelményből származik;

• nincs meghatározva az elfogadható hibaarány;

• modellváltás után nem fut regressziós ellenőrzés;

• és senki nem tudja bizonyítani, hogy ugyanarra a bemenetre ugyanaz a döntés születik.

A prompt így forráskóddá válik.

Csak rosszabb forráskóddá.

Nincs formális nyelvtana. Nincs típusellenőrzése. Nincs fordítóprogramja, amely figyelmeztet a hibás szabályra. Nincs garantált végrehajtási jelentése. És ugyanazt a mondatot két modell vagy akár ugyanannak a modellnek két futása is másként értelmezheti.

A prompt engineering sok vállalatnál nem más, mint dokumentálatlan programozás természetes nyelven.

A különbség csupán annyi, hogy a régi spagettikódot legalább egy debuggerrel végig lehetett léptetni.

Nem determinisztikus gép dönt determinisztikus szabályokról

A nyelvi modellek probabilisztikus rendszerek.

Ez nem sértés, hanem működési tulajdonság.

Nagyon jól tudnak bizonytalan, nyelvi és mintafelismerési feladatokat megoldani. Kiválóan használhatók szövegek összefoglalására, dokumentumok osztályozására, információk kinyerésére, alternatívák javaslatára és emberi nyelvű válaszok megfogalmazására.

Nem minden feladat bizonytalan.

Az áfakulcs nem kreatív írás.

A számla végösszege nem nyelvi árnyalat.

A jogosultság nem hangulati kérdés.

Egy már feldolgozott tranzakciót nem szabad még egyszer végrehajtani azért, mert a modell ezúttal másképp értelmezte az előzményeket.

Ahol a szabály egyértelműen meghatározható, ott a probabilisztikus döntés nem innováció.

Felesleges kockázat.

Ennek ellenére számos AI-workflow olyan döntéseket is modellre bíz, amelyeket egy egyszerű feltétel, állapotgép, sémaellenőrzés vagy adatbázis-korlátozás megbízhatóbban, gyorsabban és olcsóbban elvégezne.

Miért?

Mert a készítő nem tudja leprogramozni a szabályt.

Ezért inkább megkéri a modellt, hogy találja ki.

Az AI ilyenkor nem a szakértelmet egészíti ki.

Elfedi annak hiányát.

Mi történik, ha ugyanaz az esemény kétszer érkezik meg?

Ez az a kérdés, amelynél sok látványos automatizálás azonnal szétesik.

A valós rendszerekben az események ismétlődnek.

A webhookot újraküldik. A hálózati kapcsolat megszakad, ezért a küldő nem kap visszaigazolást. A felhasználó kétszer kattint. A scheduler újraindul. A platform ismét feldolgozza a függőben maradt feladatot.

Egy helyesen tervezett rendszer felismeri, hogy ugyanarról az üzleti eseményről van szó.

Ezt nevezzük idempotenciának: ugyanaz a művelet ismételten végrehajtva sem okoz újabb, nem kívánt változást.

Ha ez hiányzik, akkor ugyanaz az automatizmus:

• kétszer küldheti ki a számlát;

• kétszer terhelheti meg az ügyfelet;

• több CRM-rekordot hozhat létre;

• ismételten elküldheti ugyanazt az e-mailt;

• vagy többször rendelheti meg ugyanazt a szolgáltatást.

A laikus node-építő gyakran nem azért nem valósítja meg az idempotenciát, mert rosszul valósítja meg.

Hanem azért, mert nem tudja, hogy létezik ez a fogalom.

Az ügyfél pedig nem kérdez rá, mert ő sem tudja.

A rendszer addig működik, amíg először nem érkezik meg kétszer ugyanaz az esemény.

Utána mindenki meglepődik.

Az ötlépéses folyamatból három sikerült. Most mi van?

Tegyük fel, hogy egy automatizálás:

1. létrehozza az ügyfelet;

2. kiállítja a számlát;

3. elküldi az e-mailt;

4. lefoglalja a szolgáltatást;

5. frissíti a CRM-et.

A negyedik lépés elbukik.

Mi a rendszer helyes állapota?

Törölje az ügyfelet?

Érvénytelenítse a számlát?

Küldjön helyesbítő levelet?

Próbálja újra a foglalást?

Jelölje emberi beavatkozásra?

Mi történik akkor, ha az újrapróbálkozáskor az első három lépés ismét lefut?

A valódi vállalati rendszernek ismernie kell a tranzakció, a kompenzáció és az állapotkezelés fogalmát. Tudnia kell, mely művelet visszafordítható, melyik ismételhető meg biztonságosan, és hol van szükség emberi döntésre.

A node-hálózat gyakran csak annyit tud, hogy az első három doboz zöld lett, a negyedik piros.

Az ötödik pedig nem futott le.

Ez nem állapotkezelés.

Ez egy karácsonyfa.

A modell frissült, a vállalati rendszer megváltozott

A hagyományos program működése csak akkor változik meg, ha valaki módosítja a kódot vagy a konfigurációt.

A külső AI-modell viselkedése azonban úgy is változhat, hogy a vállalat saját rendszeréhez senki nem nyúlt.

Változhat:

• az alapmodell;

• a biztonsági rendszer;

• az eszközválasztás;

• a válasz formátuma;

• a kimenet hossza;

• a strukturált adat pontossága;

• a sebesség;

• a kontextuskezelés;

• a modell elérhetősége;

• és az ár.

Az OpenAI dokumentációja éppen ezért kínál rögzített modellsnapshotokat, amelyekkel egy adott modellváltozat viselkedése stabilabban rögzíthető. A modellkatalógusban közben több korábbi modell már „deprecated”, vagyis kivezetésre jelölt állapotban szerepel.

Ez azt jelenti, hogy egy külső szolgáltató akár a vállalat kódjának módosítása nélkül is megváltoztathatja a rendszer egyik legfontosabb komponensét.

Egy mérnöki rendszer ezért:

• rögzíti a modellverziót;

• regressziós teszteket futtat;

• méri a minőség és a költség változását;

• kontrolláltan vezeti be az új modellt;

• rendelkezik fallback megoldással;

• és szükség esetén vissza tud állni.

A node-guru ezzel szemben gyakran a „latest” modellt választja.

Mert az a legújabb.

A vállalat üzleti folyamata így folyamatos béta tesztté válik.

Kulcsot adtak a teljes céghez egy statisztikai modellnek

Az AI-ügynökök legvonzóbb tulajdonsága, hogy nemcsak válaszolnak, hanem cselekedhetnek.

Levelet küldhetnek.

Naptárbejegyzést készíthetnek.

CRM-adatot módosíthatnak.

Dokumentumot törölhetnek.

Kódot futtathatnak.

API-t hívhatnak.

Éppen ez a legveszélyesebb tulajdonságuk is.

A modell nem hagyományos jogosultsági rendszer. Nem bizonyíthatóan helyes döntési motor. Befolyásolhatják a felhasználói utasítások, a dokumentumok tartalma, a weboldalakról beolvasott szöveg és más, nem megbízható források.

Az OWASP a prompt injection veszélyei között felsorolja az illetéktelen funkcióhasználatot, a kritikus döntések manipulációját és akár tetszőleges parancsok végrehajtását a kapcsolódó rendszerekben. A védekezési javaslatok között szerepel a legkisebb szükséges jogosultság elve, a funkciók kódban történő korlátozása és az emberi jóváhagyás a magas kockázatú műveleteknél.

Az „Excessive Agency”, vagyis a túlzott önállóság ugyancsak külön kockázati kategória: a modell túl sok funkcióhoz, túl széles jogosultsághoz vagy túl nagy autonómiához jut.

Még maga az n8n is külön dokumentálja, hogyan lehet emberi jóváhagyást kérni, mielőtt egy AI-ügynök meghatározott eszközöket használ.

A szakértelem nélküli automatizáló mégis gyakran teljes hozzáférésű API-kulcsot ad a folyamatnak.

Nem külön, minimális jogosultságú szolgáltatásfiókot.

Nem csak olvasási engedélyt.

Nem meghatározott mappához vagy művelethez kötött tokent.

Hanem mindent.

Ezután a modellre bízza, mikor és mire használja.

Olyan kulcsot ad a vállalat teljes digitális irodájához egy statisztikai modellnek, amelyet egy új gyakornokra sem bíznának rá.

Majd ezt autonómiának nevezi.

A közösségi node is kód – csak nem tudod, ki írta

A vizuális szerkesztő azt az illúziót kelti, hogy a node egy biztonságos, lezárt építőkocka.

Pedig a node mögött kód fut.

Lehet hivatalos komponens. Lehet közösségi bővítmény. Lehet egy ismeretlen fejlesztő csomagja. Hozzáférhet a bemenethez, a hitelesítési adatokhoz, a fájlrendszerhez, a hálózathoz vagy más érzékeny erőforrásokhoz – a platformtól és a telepítéstől függően.

A gyártói dokumentációk ezért tartalmaznak biztonsági auditot, kockázatos node-típusokat és telepítési megfontolásokat. Az n8n biztonsági auditja például külön ellenőrzi a potenciálisan veszélyes node-okat és kifejezéseket.

A laikus rendszerépítő azonban sokszor nem függőséget lát.

Hanem egy dobozt.

Rákeres a kívánt funkcióra, telepíti az első találatot, megadja neki a vállalati API-kulcsot, majd továbblép.

A szoftverellátási lánc kockázata ettől nem tűnik el.

Csak eltűnik a vászon mögött.

Senki nem tudja, merre jár az adat

Egy AI-automatizálásban ugyanaz a dokumentum vagy ügyféladat több szolgáltatáson is áthaladhat.

Eljut:

• az automatizációs platformhoz;

• a modell szolgáltatójához;

• egy OCR-rendszerhez;

• egy embedding szolgáltatáshoz;

egy vektoradatbázishoz;

egy naplózó rendszerhez;

egy hibakövetőhöz;

egy mentési szolgáltatáshoz;

és esetleg egy API-aggregátorhoz.

Minden lépésnél külön kérdés:

Hol dolgozzák fel?

Meddig tárolják?

Melyik alfeldolgozó fér hozzá?

Bekerül-e a naplóba?

Átkerül-e egy másik régióba?

Megmarad-e egy sikertelen futás adatai között?

Törölhető-e minden példánya?

A modell tanítására használható-e?

A kivitelező válasza gyakran ennyi:

„Az AI feldolgozza, de biztonságos.”

Ez nem adatkezelési leírás.

Ez hitvallás.

A NIST AI-kockázatkezelési keretrendszere a dokumentációt, az átláthatóságot, az emberi felülvizsgálatot és a folyamatos kockázatkezelést a teljes rendszer-életciklus alapvető részének tekinti. A keret négy központi funkciója a kockázatok irányítása, feltérképezése, mérése és kezelése.

A vállalati AI-rendszert nem attól lesz biztonságos, hogy a modell szolgáltatója nagy cég.

Attól lehet biztonságosabb, ha valaki pontosan tudja, merre halad az adat, milyen célból, milyen jogosultsággal és milyen ideig.

Ha erre nincs válasz, akkor nincs adatarchitektúra.

Csak remény van.

Az AI automatizálja a rossz vállalati folyamatot is

Az AI-bevezetések egyik legnagyobb hazugsága, hogy a technológia majd rendet tesz a vállalatban.

Nem fog.

A rossz adatmodellből nem lesz jó adatmodell attól, hogy egy nyelvi modell próbálja kitalálni, melyik mező mit jelent.

A dokumentálatlan folyamatból nem lesz szabályozott folyamat attól, hogy egy ügynök utánozza a kollégák korábbi döntéseit.

A rendezetlen Excel-táblákból nem lesz megbízható vállalati adatbázis attól, hogy az AI rendszeresen „kitisztítja” őket.

A rosszul kialakított CRM-ből nem lesz jó rendszer attól, hogy újabb tíz node próbálja pótolni a hiányzó mezőket.

A kaotikus e-mailes ügyintézésből nem lesz átlátható folyamat attól, hogy egy modell olvasgatja a leveleket.

Az AI nagyon jól skáláz.

A káoszt is.

Ha a folyamat hibás, a mesterséges intelligencia nem feltétlenül megjavítja.

Gyorsabban, nagyobb mennyiségben és kevésbé átláthatóan hajtja végre ugyanazt a hibát.

A rossz folyamat automatizálva nem válik jó folyamattá. Csak ipari sebességgel kezdi termelni a saját hibáit.

A hamis hatékonysági kimutatás

Az AI-automatizálási projektek bemutatóiban gyakran különös mérőszámok szerepelnek.

„Tizenkét ügynök dolgozik a rendszerben.”

„Kétszáz node-ot építettünk.”

„Naponta ötvenezer tokent használ.”

„Tizennyolc alkalmazást integráltunk.”

„Négyszáz manuális lépést automatizáltunk.”

Ezek egyike sem feltétlenül üzleti eredmény.

A sok node lehet rossz tervezés.

A sok token lehet pazarlás.

A sok ügynök lehet felesleges közvetítő.

A sok automatizált lépés pedig lehet egy eleve rossz folyamat gépesítése.

Az értelmes kérdések mások:

• Mennyi egy sikeresen feldolgozott ügy teljes költsége?

• Mennyi a sikertelen ügyé?

• Mekkora a hibaarány?

• Hányszor kell embernek beavatkoznia?

• Mennyi idő alatt derül ki egy hiba?

• Mennyi idő a helyreállítás?

• Mekkora pénzügyi vagy jogi kárt okozhat egy téves döntés?

• Mennyibe kerül a rendszer évente, minden szolgáltatással és emberi ellenőrzéssel együtt?

• Valóban csökkent a munkaidő, vagy csak átalakult AI-kimenetek ellenőrzésévé?

Ha egy rendszer „napi négy órát takarít meg”, de egy munkatárs napi három órán keresztül ellenőrzi, javítja és újraindítja, akkor nem napi négy órát takarított meg.

Hanem létrehozott egy rosszul fizetett AI-felügyelői munkakört.

A karbantartási túszejtés

A látványautomatizáló elkészíti a hálózatot.

Felvesz róla egy demót.

Átadja.

Eltűnik.

A vállalatnál marad:

• több száz elnevezetlen node;

• kézzel beírt promptok;

• személyes felhasználói fiókokhoz kötött kapcsolatok;

• ismeretlen helyeken tárolt API-kulcsok;

• egymásba ágyazott alfolyamatok;

• dokumentálatlan feltételek;

• éles ügyféladatokat tartalmazó végrehajtási naplók;

• és egy olyan folyamat, amelyhez senki nem mer hozzányúlni.

Nincs architektúradokumentáció.

Nincs adatfolyam-ábra.

Nincs fenyegetési modell.

Nincs tesztkészlet.

Nincs költségmodell.

Nincs visszaállítási terv.

Nincs meghatározva, mi történik, ha az eredeti platform, modell vagy valamelyik külső szolgáltatás megváltozik.

Papíron a rendszer az ügyfélé.

Gyakorlatban az eredeti készítő fejében létezik.

Ha ő nem érhető el, senki nem tudja biztosan, melyik nyíl miért mutat arra, amerre.

Ha elérhető, minden módosításért új összeget kérhet.

A vállalat nem automatizálást vásárolt.

Technológiai túszhelyzetet.

Vendor lock-in, csak most egyszerre tíz szolgáltatóhoz

A klasszikus vendor lock-in azt jelenti, hogy a vállalat túlzottan függ egyetlen gyártótól.

Az AI-node-hálózat ennél fejlettebb megoldást kínál:

egyszerre függ mindenkitől.

Az automatizációs platform árat emelhet.

A modellgyártó kivezetheti a modellt.

A vektoradatbázis módosíthatja a limitet.

Az OCR-szolgáltató megváltoztathatja a válaszformátumot.

A közösségimédia-platform lezárhatja az API-t.

A levelezőrendszer új hitelesítést követelhet.

A közösségi node fejlesztője abbahagyhatja a karbantartást.

A felhőszolgáltató más régióba helyezhet egy funkciót.

Egyetlen folyamat tíz olyan vállalattól függhet, amelyek közül egyik sem vállal felelősséget a teljes rendszer működéséért.

A készítő ezt ökoszisztémának nevezi.

A vállalati kockázatkezelésben ezt függőségi pókhálónak hívnánk.

Amikor az AI-guru nem tudja megmondani, mi történt

Egy ügyfél kárt szenved.

Rossz címre ment egy bizalmas dokumentum.

Hibás ajánlatot küldött ki a rendszer.

Tévesen utasított el egy jelentkezőt.

Kétszer hajtott végre egy műveletet.

Nem rögzített egy panaszt.

Ki a felelős?

A modell szolgáltatója?

Az automatizációs platform?

A node fejlesztője?

Az API tulajdonosa?

A rendszerépítő?

A megrendelő?

Vagy az alkalmazott, aki nem ellenőrizte az automatizált eredményt?

A szakértelem nélküli kivitelező gyakran úgy értékesíti az autonómiát, mintha azzal a felelősség is eltűnne.

Nem tűnik el.

Csak elmosódik.

A rendszertervezés egyik alapvető feladata éppen az, hogy minden fontos döntésnél meghatározza:

• ki kezdeményezte;

• milyen adat alapján;

• melyik modell- és promptverzióval;

• milyen eszközöket hívott meg;

• milyen eredményt kapott;

• ki hagyta jóvá;

• és hogyan lehet a döntést visszakövetni.

Enélkül nincs auditálhatóság.

Csak magyarázkodás van.

A „human in the loop” nem azt jelenti, hogy valaki majd ránéz

Amikor a biztonságról kérdezik őket, sok rendszerépítő előveszi a varázskifejezést:

„Természetesen van human in the loop.”

Ez gyakran azt jelenti, hogy valaki kap egy e-mailt.

Vagy időnként megnézhet egy táblázatot.

A valódi emberi kontroll azonban nem dekoráció.

Az embernek:

• elegendő információt kell kapnia;

• értenie kell a döntés következményét;

• valódi lehetőséggel kell rendelkeznie a megállításra;

• megfelelő időt kell kapnia az ellenőrzésre;

• és nem szabad vakon elfogadnia napi több száz gépi javaslatot.

A NIST keretrendszere az emberi felülvizsgálatot, a dokumentációt és a folyamatos irányítást nem a folyamat végére helyezett checkboxként, hanem a teljes életciklus részeként kezeli.

Az n8n dokumentációja szintén külön támogatást ad az AI-eszközhívások előtti emberi jóváhagyáshoz és az emberi fallbackhez.

Ha az ember csak akkor látja a hibát, amikor az e-mailt már kiküldték, az adatot már törölték vagy a döntést már közölték az ügyféllel, akkor nem volt a folyamatban.

Csak megkapta a jegyzőkönyvet.

Amikor a játékrendszerből szabályozott vállalati rendszer lesz

Különösen súlyos a helyzet, amikor az AI-node-hálózat emberek munkáját, megélhetését vagy hozzáférését befolyásolja.

Az Európai Unió AI Act szabályozása többek között magas kockázatúnak tekinti azokat a foglalkoztatási rendszereket, amelyek jelentkezők kiválasztásában, előléptetésben, felmondásban, feladatkiosztásban, dolgozói megfigyelésben vagy teljesítményértékelésben vesznek részt. Az indoklás szerint ezek jelentősen befolyásolhatják az emberek karrierjét, megélhetését és munkavállalói jogait.

Vagyis amikor valaki néhány YouTube-oktatóvideó után összeköt egy önéletrajz-elemző modellt a vállalat HR-rendszerével, nem egyszerűen „menő AI-automatizálást” készít.

Olyan rendszerhez nyúlhat, amelynél dokumentációs, kockázatkezelési, adatminőségi, felügyeleti és megfelelőségi kötelezettségek merülnek fel.

A jog nem fogadja el védekezésként, hogy:

„A node döntötte el.”

Az AI-szakértői cím teljes elértéktelenedése

Soha nem volt ilyen gyors szakértővé válni.

Tegnap valaki marketinges, coach, virtuális asszisztens vagy általános vállalkozó volt.

Ma elvégez egy online kurzust.

Holnap a profilján ez áll:

• AI Automation Expert;

• Agentic Systems Architect;

• Enterprise AI Consultant;

• AI Transformation Strategist;

• Autonomous Workflow Engineer.

A címet nem vizsga adja.

Nem valódi rendszer üzemeltetése.

Nem szakmai felelősség.

Nem többéves tapasztalat.

Hanem a LinkedIn bemutatkozómezője.

Az illető lemásol néhány sablont, összeköt egy űrlapot egy modellel, majd elkezd tanácsot adni vállalatoknak arról, hogyan automatizálják az ügyfélszolgálatot, az értékesítést, a HR-t és a pénzügyi adminisztrációt.

Nem az a probléma, hogy valaki új a területen.

Minden szakember kezdőként indult.

A probléma az, amikor valaki még nem érti a rendszer kockázatait, de már mások kockázatára értékesíti a tudatlanságát.

Nem baj, ha valaki tegnap kezdett automatizálni. Az a baj, ha ma már vállalati architektúrát ad el, holnap pedig nem ő fizeti ki a hibáját.

A kezdő bizonytalan.

A veszélyes dilettáns magabiztos.

Az AI pedig kivételesen jó eszköz arra, hogy a magabiztosságot szakmai teljesítménynek álcázza.

A nagy visszarendeződés már elkerülhetetlen

A no-code és az AI-ügynökök nem fognak eltűnni.

A vizuális automatizálás hasznos, gyors és sok esetben gazdaságos marad.

Ami el fog tűnni, az a korlátlan bizalom.

A cégek előbb-utóbb megkapják:

• az első kezelhetetlen API-számlát;

• az első helyreállíthatatlan adatvesztést;

• az első modellfrissítés miatti minőségromlást;

• az első biztonsági incidenst;

• az első olyan workflow-t, amelyhez már az eredeti készítő sem mer hozzányúlni;

• és az első auditot, ahol valakinek meg kellene magyaráznia, hogyan született egy döntés.

Ekkor újra értékké válik mindaz, amit az AI-forradalom leglelkesebb hirdetői elavultnak neveztek:

• az adatmodell;

• a típusosság;

• az állapotgép;

• az explicit üzleti szabály;

• a tranzakció;

• az idempotencia;

• a jogosultságkezelés;

• a forráskód-verziózás;

• a tesztelés;

• az observability;

• a költségkeret;

• a dokumentáció;

• és az emberi felelősség.

Nem azért, mert ezek régimódi programozói rituálék.

Azért, mert ezek választják el a demót a rendszertől.

Az új architektúra: determinisztikus gerinc, probabilisztikus szigetek

A jövő nem a tisztán hagyományos programozás és nem is a korlátlan AI-ügynökök világa lesz.

A működőképes megoldás a kettő szétválasztása.

A rendszer gerince legyen determinisztikus:

• az üzleti állapotok;

• a jogosultságok;

• a pénzügyi számítások;

• a tranzakciók;

• az egyediségi korlátok;

• a költségplafonok;

• a futási limitek;

• a naplózás;

• a hibakódok;

• és a jóváhagyási pontok.

Az AI pedig kapjon körülhatárolt, mérhető feladatokat:

• értelmezzen szöveget;

• osztályozzon dokumentumot;

• nyerjen ki adatot;

• javasoljon választ;

• fogalmazzon meg alternatívát;

• keressen hasonlóságot;

• vagy készítsen összefoglalót.

A modell javasolhat.

A rendszer validál.

A modell értelmezhet.

A rendszer dönt.

A modell előállíthat jelölt adatot.

A séma, az üzleti szabály és szükség esetén az ember eldönti, elfogadható-e.

Ez a féldeterminisztikusnak nevezhető megközelítés nem visszalépés az AI előtti korba.

Ez az AI felnőttkora.

Az a pont, ahol már nem hiszünk abban, hogy egy valószínűségi modellnek minden döntést át kell adni csak azért, mert képes szöveges választ adni rá.

A vállalati AI-rendszer minimumkövetelményei

Egy valódi vállalati AI-automatizálásnál legalább a következő kérdésekre egyértelmű válasznak kell lennie:

Mi a rendszer pontos felelőssége?

Nem az, hogy „kezeli az ügyfeleket”, hanem konkrétan milyen bemenetből milyen kimenetet készít, és mit nem tehet meg.

Mely döntések determinisztikusak?

Mely szabályokat hajt végre hagyományos kód, és mely feladatoknál használunk modellt?

Mekkora a költségplafon?

Futásonként, ügyfelenként, naponként és havonként mennyit költhet?

Hány lépést tehet az ügynök?

Van-e maximális ciklusszám, időkorlát és eszközhívási keret?

Hogyan kezeli a duplikációt?

Ugyanaz az esemény többször végrehajtva okozhat-e többszörös műveletet?

Mi történik részleges hiba esetén?

Visszaáll, kompenzál, újrapróbál vagy emberi vizsgálatot kér?

Hol járnak az adatok?

Minden szolgáltató, régió, tárolási hely és megőrzési idő dokumentált-e?

Milyen jogosultságot kap a modell?

Csak a feltétlenül szükséges műveleteket érheti el?

Melyik modellverzió futott?

A döntés később reprodukálható és auditálható?

Milyen teszteken ment át?

Vannak valós, szélsőséges és támadó tesztesetek?

Ki állíthatja le?

Létezik vészleállítás, emberi jóváhagyás és manuális feldolgozási útvonal?

Ki vállalja a felelősséget?

Nem általában „a rendszer”, hanem név és szervezeti szerep szerint.

Ha ezekre nincs válasz, akkor nincs kész vállalati rendszer.

Legfeljebb egy működő bemutató.

Nem az AI teszi feleslegessé a programozót

A mesterséges intelligencia valóban rengeteg kódot, integrációt és rutinfeladatot képes előállítani.

Ez csökkenti a belépési küszöböt.

Gyorsítja a prototípusokat.

Lehetővé teszi, hogy kisebb csapatok is nagyobb rendszereket építsenek.

De minél több feladatot végez el a gép, annál fontosabbá válik az ember, aki meg tudja ítélni:

• helyes-e az architektúra;

• biztonságos-e az adatút;

• megfelelő-e a jogosultság;

• kiszámítható-e a költség;

• reprodukálható-e a döntés;

• és mi történik, amikor a boldog útvonal véget ér.

Az AI nem szünteti meg az informatikai tudás szükségességét.

Megváltoztatja, hol van rá szükség.

Kevesebb érték lehet a mechanikus kódgépelésben, és több a rendszerhatárok, állapotok, invariánsok, kockázatok és ellenőrzési pontok megtervezésében.

Aki ezeket nem érti, az AI-val gyorsabban tud építeni.

Csak azt nem tudja, mit épített.

Végszó: a dilettantizmus aranykora nem tarthat örökké

A jelenlegi AI-automatizálási hullám egyik legnagyobb tévedése, hogy a hozzáférhetőséget összetéveszti a hozzáértéssel.

Igen, ma már szinte bárki össze tud kötni egy nyelvi modellt egy levelezőrendszerrel, egy CRM-mel vagy egy adatbázissal.

De attól, hogy valaki képes létrehozni egy műveletet, még nem tudja biztonságosan, gazdaságosan és ellenőrizhetően üzemeltetni.

A technológia lebontotta a fejlesztés bejárati ajtaját.

Nem bontotta le a következményeket.

A vállalatok pedig lassan rájönnek majd, hogy a színes node-ok mögött ugyanazok a régi kérdések várnak:

Ki felel érte?

Mi történik hiba esetén?

Mennyibe kerül valójában?

Megismételhető-e?

Biztonságos-e?

Visszaállítható-e?

És érti-e egyáltalán valaki az egészet?

Az AI-istenek erre gyakran nem tudnak válaszolni.

Ők a következő bemutatót készítik.

A számla, a hibás adat, a biztonsági incidens és a karbantarthatatlan rendszer pedig a vállalatnál marad.

Az AI nem tette feleslegessé az informatikai tudást.

Csak lehetővé tette, hogy annak hiánya egy ideig látványos eredménynek álcázza magát.

Amikor pedig lejár a demó és elkezdődik az üzemeltetés, a színes dobozok nem mentenek meg senkit.

A rendszer vagy mérnökileg meg van tervezve, vagy nincs.

Minden más csak nodepornó.