CENTAUR-modell: emberi felelősség az MI-vel támogatott fejlesztésben

A CENTAUR elnevezést itt ember által vezetett, mesterséges intelligenciával támogatott munkamódszerre használjuk. Az MI készíthet műszaki javaslatot, kódot, dokumentációt vagy ellenőrzési szempontokat. Ezekből akkor lesz vállalható szolgáltatás, amikor egy azonosítható ember ellenőrzi az eredményt, és felelősséget vállal a döntésért.

A „társalapító”, „műszaki vezető” vagy „stratégiai igazgató” megnevezés félrevezető, ha egy nyelvi modellnek tulajdonít vállalati jogkört. Egy szolgáltatás előfizetése nem teszi a modellt szerződéses felelősséget viselő vezetővé. A megrendelőnek azt kell tudnia, ki fogadja el a követelményeket, ki engedélyezi az élesítést, és ki intézi a hibajavítást.

Az alábbi működési rend ajánlott keret egy magyar KKV fejlesztési projektjéhez. Nem auditjelentés arról, hogy minden felsorolt kontroll minden korábbi Conen-projektben megvalósult. A módszer hitelességét az adott projekt ellenőrizhető dokumentumai adják.

Három döntés, amelynek emberi gazdája kell legyen

A rendszer felépítését a kijelölt emberi műszaki felelős hagyja jóvá. Ő mérlegeli a választott szolgáltatások költségét, az adatáramlást és a későbbi karbantarthatóságot. Az MI összeállíthat alternatívákat, de a döntési jegyzőkönyvben ember neve szerepeljen.

Az ügyfélnek tett vállalást a szolgáltató felhatalmazott emberi képviselője rögzíti, a megrendelő pedig elfogadja. Határidőt, árat, akadálymentességi vállalást vagy rendelkezésre állást nem szabad egy generált munkatervből automatikusan szerződéses ígéretté tenni.

Az éles kiadást a kijelölt kiadásfelelős engedélyezi, az elfogadási eredmények és a visszaállítási terv alapján. Kis csapatban ezeket a szerepeket ugyanaz az ember is betöltheti. Ilyenkor különösen fontos, hogy az ellenőrzés ne puszta emlékezetre és a kód készítőjének önértékelésére épüljön. A Conennél az ügyfél felé vállalt kötelezettségeket Chris Conen emberi képviselőként vállalja; az egyes projektek műszaki és kiadási felelőseit az átadásban kell megnevezni.

Mitől lesz ellenőrizhető a munkafolyamat?

Kezdéskor egy konkrét üzleti feladatot kell leírni. A „korszerű webshop” nem tesztelhető követelmény. A „sikeres fizetés után a rendelés egyszer jelenik meg a csomagolási listában” már az. Mellé kell írni a kivételeket is: megszakadó kapcsolat, ismételt fizetési értesítés, hibás cím és sikertelen számlázás.

Az MI ezután kaphat jól körülhatárolt részfeladatot. A bemenet legyen a jóváhagyott követelmény, a szükséges kódrészlet és a használható dokumentáció. Az eredményhez tartozzon változáslista és ellenőrzési javaslat. A „kész” kijelentés helyett futtatható ellenőrzésre, megtekinthető felületre vagy visszaolvasható adatra van szükség.

A generált megoldást más szempontból is ellenőrizni kell, mint ahogyan készült. Ha ugyanaz a modell írja a kódot és a hozzá illeszkedő tesztet, mindkettőben megmaradhat ugyanaz a téves feltételezés. Az üzleti követelményből levezetett elfogadási próba ezért külön érték.

A NIST generatív MI-kockázati profilja a magabiztosan előadott téves tartalmat is kockázatként kezeli. A fejlesztésben ennek gyakorlati következménye, hogy egy hihető magyarázatot nem szabad a működés bizonyítékaként elfogadni.

Hibapélda: a felugró ablak bezárható, mégsem használható

A következő történet szemléltető hibaforgatókönyv, nem dokumentált ügyféleset. Tegyük fel, hogy az MI egy termékválasztó ablakot készít. Egérrel minden rendben: megnyílik, választani lehet, a bezárás gomb működik. A generált kód azonban nem kezeli megfelelően a billentyűzetes fókuszt.

A kézi ellenőrzés során a tesztelő csak billentyűzetet használ. Kiderül, hogy a Tab billentyűvel az ablak mögötti tartalomra jut, bezárás után pedig nem a megnyitó gombhoz tér vissza. A képernyőolvasós próba azt is megmutathatja, hogy az ablaknak nincs megfelelően közölt neve.

Az előre rögzített elfogadási feltétel ebben a példában megállítaná a kiadást: a teljes választási folyamatnak egér nélkül is végigjárhatónak kell lennie. A javítás után újra végig kell próbálni a nyitást, választást, megszakítást és visszatérést. Egy automatikus teszt önmagában nem igazol teljes akadálymentességet, amint azt a W3C értékelőeszközökről szóló útmutatója is kiemeli.

A tanulság nem az, hogy az MI alkalmatlan felületek készítésére. Hanem az, hogy a kihagyott viselkedést egy konkrét, felhasználói feladatot követő ellenőrzésnek kell megtalálnia. Dokumentált saját hibajegyek hiányában ennél erősebb, megtörtént eredményt állító történetet nem indokolt közölni.

Titkok, ügyféladatok és éles hozzáférés

A fejlesztést érdemes mesterséges tesztadatokkal kezdeni. Éles vevőlista, fizetési titok vagy teljes adatbázismentés ne legyen a modellnek átadott háttéranyag alapértelmezett része. A fejlesztői környezet jogosultságai legyenek szűkebbek az éles rendszerénél.

A kódtár írása, a tesztek futtatása és az éles telepítés külön jogosultság legyen. Az MI által javasolt parancsot a futtatási környezet korlátozza; ne attól függjön a védelem, hogy a modell betart-e egy szöveges kérést. Különösen érzékeny a fájltörlés, az adatbázis-módosítás és a külső szolgáltatásnak küldött adat.

Egy külső dokumentáció, hibajegy vagy csomagleírás is tartalmazhat megtévesztő utasítást. A tartalom olvasási engedélye nem jelent végrehajtási felhatalmazást. Az OWASP MI-ügynökökre vonatkozó útmutatója ehhez a minimális jogosultság és az érzékeny műveletek ellenőrzésének elvét kapcsolja.

A megrendelővel tisztázni kell, mely szolgáltatókhoz kerülhet kód vagy adat, ki látja a naplókat, és hogyan vonható vissza a hozzáférés. Egy munkatárs vagy alvállalkozó távozása után a megmaradó kulcs ugyanolyan valós kockázat, mint egy hibásan generált függvény.

Mi történik modellváltáskor vagy kieséskor?

A modellcsere nem pusztán számlázási döntés. Megváltozhat a kódjavaslatok formája, az eszközhasználat és a feladatértelmezés. A csere előtt ugyanazokon a reprezentatív feladatokon kell ellenőrizni az eredményt, és rögzíteni a modellazonosítót, a dátumot és az ismert korlátokat.

Szolgáltatáskiesésre legyen ember által folytatható munkalista és helyben elérhető dokumentáció. Egy hagyományos webshop működését nem szükséges a fejlesztéshez használt modell folyamatos elérhetőségéhez kötni. Ha az MI csak a kód elkészítésében segít, kiesése elsősorban a fejlesztési kapacitást érinti; ha éles funkciót is kiszolgál, külön tartalék működés kell.

Hosszú távon az a fontos, hogy a projektet másik szakember is átvehesse. A döntések indoklása, a telepítési leírás és a hozzáférések rendezése többet ér, mint egy hosszú beszélgetési előzmény, amelyből csak az eredeti készítő érti a rendszert.

Mit lehet jelenleg a Neocartról állítani?

A 2026. október 18-i termékállapot szerint a Neocart-tervező ingyenesen, regisztráció nélkül használható. Mintaboltból lehet kiindulni, módosítható a megjelenés és a tartalom, megosztható a terv, valamint ajánlat kérhető belőle. Ez tervezési folyamat; a saját domainre történő önkiszolgáló publikálás nem elérhető funkció.

A motor Medusa 2 és Postgres alapú, Astro-kirakattal. A termékténylap magyar adminisztrációt, SimplePay-fizetést, Számlázz.hu-integrációt és GLS-kezelést sorol fel. A Neocart Piactér még készül. Ezek termékképességek, nem bizonyítékok az MI-vel végzett munka általános gyorsaságára vagy fölényére.

A korábbi IKER-leírást nem használjuk a jelenlegi termék bemutatására. A kódsorok száma sem alkalmas üzleti érték mérésére. A megrendelő számára a működő folyamat, a javíthatóság és az átadhatóság számít.

Milyen bizonyítékot kérj az átadáskor?

Kérj követelményenként ellenőrzési eredményt, ismert hibajegyzéket, visszaállítási tervet és megnevezett felelőst. A gyorsulást csak összehasonlítható munkák teljes ráfordításával lehet értékelni, beleértve az ellenőrzést és az utólagos javítást is. Az elkészült első változat ideje ehhez kevés.

Az MI használata akkor jó munkamódszer, ha az eredmény ellenőrizhető marad, a hozzáférések korlátozottak, és az emberi döntések visszakereshetők. Ezt érdemes számon kérni a szolgáltatón – függetlenül attól, milyen nevet ad a saját működésének.