Hogyan engedhet AI-t írni az éles rendszerébe úgy, hogy ne rontson el semmit?

A válaszunk hat determinisztikus kapu: hat ellenőrzés, amelyben egyetlen sor AI sincs. A modell ír, a kód ellenőriz, és a visszafordíthatatlan lépést — a mentést, a küldést, a publikálást — soha nem az AI végzi. Ez a cikk megmutatja, melyik kapu mit fog meg, hogyan ültethető át ugyanez ügyfél-e-mailre vagy árajánlatra, és hol van az a határ, ahol jobb, ha az AI meg sem szólal.

Miért nem véd meg, ha megkéri az AI-t, hogy legyen óvatos?

Mert az nem védelem, hanem kérés. A promptba írt „csak azt írd le, amit a forrás alátámaszt” egy udvarias mondat, nem egy szabály, amit valami kikényszerít. Ugyanaz a modell ugyanarra a bemenetre ma így válaszol, holnap amúgy — ez nem hiba a modellben, hanem a működése.

A determinisztikus kód ezzel szemben unalmas: ugyanarra a bemenetre mindig ugyanazt adja, és előre megmondható, mit fog tenni. Ezért nálunk az ellenőrzés soha nem az AI feladata. Az AI ír; hogy a kimenet élesbe kerülhet-e, arról olyan kód dönt, amelyben egyetlen modellhívás sincs.

Ebből következik a második szabály, ami a gyakorlatban többet ér az elsőnél: a visszafordíthatatlan lépést soha nem az AI végzi. A mentést, az e-mail elküldését, a publikálást determinisztikus kód hajtja végre — a kapuk után. A modell egy pufferbe ír, és nincs jogosultsága ahhoz, hogy bármit véglegesítsen. Ha a kapuk közül bármelyik elbukik, nincs mit visszavonni, mert nem történt semmi.

Ugyanez a felállás fut a bejövő számlák feldolgozásánál is: az AI kiolvas, a kód ellenőriz, az ember dönt. Ott eddig 470+ számla ment át ezen a láncon élesben.

Így néz ki élesben: egy éjszakai automata és hat kapu

Nálunk egy éjszakai automata tartja karban egy tucatnyi saját kódtár dokumentációját. Ember nem ül mellette, és reggel senki nem olvassa el az egészet. A kimenet mégsem megy egyenesen élesbe.

Hat determinisztikus kapun kell átmennie: minimális terjedelem, kötelező szerkezet, stílus-szabályok, tény-egyezés a forrással, titok-szűrő és egy diff-tripwire. Egyik sem használ AI-t. Ha bármelyik elbukik, a régi dokumentáció marad élesben, és reggel egy riasztás vár minket — nem egy elrontott fájl.

A hatodik a legfontosabb, és a legritkábban épül meg máshol. A diff-tripwire nem a szöveg minőségét nézi, hanem a változás arányát: mennyi tűnne el az előző, jóváhagyott változathoz képest. Ha a szöveg fele eltűnne, a rendszer nem publikál — akkor sem, ha a maradék hibátlan. Egy csendes törlés ugyanis sokkal nehezebben derül ki, mint egy rossz mondat.

A mérés, ami mindent megváltoztatott

Az első változatban a feladat így szólt: „írd meg a dokumentációt”. Minden futás új szöveget hozott, és a szöveg 79%-a különbözött az előzőtől. Ez nem hiba volt, hanem használhatatlanság: ennyi változást ember nem tud átnézni, és a tripwire minden éjjel megszólalt.

Aztán a feladat megváltozott: „tartsd karban, és csak azt javítsd, ami hibás”. Ugyanaz a modell, ugyanaz a kód, más megbízás. A futásonkénti változás-zaj 79%-ról 2%-ra esett. Ettől kezdve a reggeli átnézés két perc lett, és a tripwire csak akkor szólal meg, ha tényleg történt valami.

A tanulság átvihető: a karbantartó feladat mérhetően kevesebb kockázatot termel, mint az újraíró. Ha AI-t enged a rendszerébe, a legkisebb szükséges változtatást kérje tőle, ne a legszebb új verziót.

Melyik kapu mit fog meg?

Mindegyik kapu más hibafajtát fog meg, és éppen ez a lényeg: egyetlen ellenőrzés sosem elég. A csonka kimenet, az elfelejtett fejezet, a hangnem-csúszás, a kitalált tény, a kiszivárgott azonosító és a csendes törlés hat különböző jelenség — hat különböző szűrővel.

Két részlet, ami a gyakorlatban sokat számít. Az egyik: a bukás soha nem jelent automatikus javítást. A rendszer nem „hozza rendbe” a kimenetet, mert azzal új, ellenőrizetlen szöveget gyártana. A másik: minden bukás naplózott, megnevezett okkal. Ha nem tudja megmondani, melyik kapu miért bukott el, nincs kapurendszere — csak egy jó érzése.

A küszöbök beállítása kalibráció kérdése. Túl szigorú tripwire mellett minden éjjel jön riasztás, és két hét múlva senki nem nézi; túl lazánál átcsúszik a fél szöveg törlése. A kiindulási szabályunk: az első két hétben a rendszer semmit nem publikál, csak jelent — így látszik, hol vannak a valós küszöbök.

Ugyanez a séma működik ügyfél-e-mailre, árajánlatra, termékleírásra

A séma nem változik, csak a kapuk tartalma. Három gyakori eset kkv-knál: az AI-írt ügyfél-e-mail, az árajánlat kísérőszövege és a termékleírás.

Ügyfél-e-mail

Szerkezet-kapu: megszólítás, a konkrét ügy megnevezése, a következő lépés és aláírás — mind a négy kötelező. Stílus-kapu: magázódás, tiltott fordulatok és a fedezetlen ígéretek kiszűrve. A legfontosabb a tény-kapu: minden szám — rendelésszám, összeg, dátum — a rendszerből kerül a levélbe, kóddal beillesztve, nem a modell tollából. Titok-kapu: a levélben nem szerepelhet másik ügyfél adata. A tényleges kiküldést pedig kód végzi, a kapuk után. Így ment ki a legnagyobb SMS-kampányunk is: 600/600 kézbesítés, 0 hibával; összesen 3 900+ kézbesített üzenetet ellenőriztünk vissza.

Árajánlat

Itt a határ élesebb: az árakat és a tételeket soha nem a modell írja. Az AI a kísérőszöveget fogalmazza — mit tartalmaz a csomag, mi a következő lépés —, a számokat kód emeli be az árlistából. A tény-kapu ezt ellenőrzi vissza: a szövegben szereplő minden összeg egyezik-e a nyilvántartásban lévővel, karakterre. Ha nem, az ajánlat nem megy ki, hanem piszkozat marad.

Termékleírás

A specifikáció mezői a törzsadatból jönnek, a modell nem találhat ki tulajdonságot. A tény-kapu itt azt kérdezi: van-e minden számszerű állítás mögött egy konkrét törzsadat-mező. Ami mögött nincs, az kiesik a szövegből. A tripwire pedig azt figyeli, nem tűnt-e el hirtelen a leírások fele egy elrontott sablonváltás miatt.

Ugyanez a fegyelem érvényes arra is, amikor AI-chatbot beszél az ügyfelekkel: a bot válaszolhat, de foglalást vagy adatmódosítást kód hajt végre, ellenőrzés után.

Mikor ne írjon az AI egyáltalán: pénzmozgás és jogi nyilatkozat

Két területen nálunk az AI nem ír élesbe, legfeljebb piszkozatot készít: pénzmozgásnál és jogi nyilatkozatnál. A különbség nem a hiba valószínűségében van, hanem a hiba árában.

Pénzmozgás. Utalás, terhelés, jóváírás, számla kiállítása, sztornó. Itt a hiba nem javítható egy újabb futással: a pénz megmozdult, és a visszaút emberi ügyintézés, néha hetekig. Ezeknél az AI legfeljebb előkészít — összeállítja a listát, megjelöli a lejárt tételeket —, a gombot ember nyomja meg. A kintlévőség-követésnél pontosan így dolgozunk: a lejárat-figyelés gépi, a döntés emberi.

Jogi nyilatkozat. Szerződés, ÁSZF, adatkezelési tájékoztató, munkajogi vagy hatósági levél. Ezekben a szöveg nem információ, hanem kötelezettségvállalás — egy félremondat évekig él. Az AI itt vázlatot ad, a felelős ember pedig átírja és aláírja. Kapu-rendszerrel sem engedjük élesbe: a tény-kapu ellenőrizni tudja, hogy egy szám stimmel-e, de azt nem, hogy egy mondat mit jelent jogilag.

A gyakorlati szabály egyszerű: ha a hibát nem lehet egy újabb futással visszacsinálni, akkor az AI piszkozatot ír, nem végleges szöveget. Minden más esetben a hat kapu elvégzi a munkát.

Mikor nem éri meg a kapu-rendszer — és mit építhet meg maga?

Nem minden feladat érdemel hat kaput. Három esetben a kapu-rendszer többe kerül, mint amennyit véd.

• Kis darabszám. Ha hetente három levelet küld ki, azokat gyorsabb megírni, mint kapukat építeni köréjük. A kapu-rendszer akkor térül meg, ha a kimenet napi vagy heti szinten, ember nélkül keletkezik.
• Van valaki, aki úgyis elolvassa. Ha a kimenetet minden esetben átnézi egy kolléga küldés előtt, akkor ő maga a kapu. Ilyenkor elég egy jó piszkozat-generátor, és fölösleges köré rendszert építeni.
• Egyszeri feladat. Egy alkalommal kell kétszáz termékleírás? Nézze át kézzel. A kapuk ismétlődő futásra készülnek, egyszeri munkát nem hoznak be.

Amit maga is meg tud építeni

Az első három kapu nem programozói bravúr. A minimális terjedelem egy karakterszám-ellenőrzés. A kötelező szerkezet annyi, hogy a kód megnézi: benne van-e minden előírt rész. A stílus-kapu egy tiltólista — szavak és fordulatok, amiket a rendszer nem írhat le. Ez a három együtt egy délután munkája, és a látványos hibák nagy részét megfogja.

A maradék három tapasztalatot kíván. A tény-egyezéshez el kell dönteni, mit tekint a rendszer forrásnak, és hogyan feleltethető meg egy mondat egy adatmezőnek. A titok-szűrőhöz tudni kell, mi számít titoknak az adott cégben. A tripwire-nél pedig a küszöböt kell eltalálni: mekkora változás már gyanús. Nálunk a rendszerek mögött összesen 5 000+ automata teszt fut — nagy részük pontosan ilyen kapu.

Ha az alapfogalmak újak, kezdje az AI automatizálásról szóló útmutatónkkal. Ha inkább azt szeretné látni, hol tart most a saját folyamata, a folyamat-audit 120 000 Ft fix áron, egy hét alatt megmutatja — és ha nem találunk legalább öt megtérülő lehetőséget, visszajár az ára.

Gyakori kérdések

Mennyibe kerül egy ilyen ellenőrzött AI-megoldás?

Nálunk a kapuk nem külön termék, hanem a fejlesztés része: a build 300 000 Ft-tól indul, és az ellenőrzések bele vannak árazva. Ha előbb tisztázná, hol érdemes egyáltalán AI-t írásra engedni, a folyamat-audit 120 000 Ft fix, egy hét alatt kész, és ha nem találunk legalább öt megtérülő lehetőséget, visszajár az ára. Az üzemeltetés 30 000 Ft/hó-tól tartalmazza a felügyeletet és a hibariasztást.

Nem lassítja le az ellenőrzés az automatizálást?

Érzékelhetően nem. A hat kapu determinisztikus kód, a futásideje ezredmásodpercekben mérhető — a lassú lépés maga a modellhívás. Ami valóban időt vesz el, az a bukások kezelése az első hetekben, amíg a küszöbök beállnak. Cserébe nem kell utólag kinyomozni, mikor és mit írt felül a rendszer csendben.

Meg tudom-e építeni saját kézzel ezeket az ellenőrzéseket?

Az első hármat igen. A minimális terjedelem karakterszám-ellenőrzés, a kötelező szerkezet az előírt részek meglétének vizsgálata, a stílus-kapu pedig egy tiltólista. Ez a három egy délután munkája, és a látványos hibák nagy részét megfogja. A tény-egyezés, a titok-szűrő és a tripwire-küszöb kalibrálása viszont tapasztalatot kíván: a rossz beállítás vagy vakká tesz, vagy elárasztja riasztással.

Mi történik, ha mégis átcsúszik egy hiba?

Úgy kezeljük, hogy a kapu hiányzott, nem az AI hibázott. Minden futás naplózott, az élesbe került változat visszaállítható az előzőre, a hibából pedig új kapu lesz, hogy ugyanaz ne fordulhasson elő kétszer. Ezért nem publikálunk soha úgy, hogy közben az előző, jóváhagyott változat ne maradna meg.

Kötelező-e, hogy ember hagyja jóvá az AI minden kimenetét?

Nem minden esetben. Ha a kimenet visszavonható — belső dokumentáció, riport-összefoglaló, terméklap —, elég a determinisztikus kapu, és az ember csak a bukásokat nézi át. Ahol a hiba nem javítható egy újabb futással — pénzmozgás, jogi nyilatkozat, szerződéses vállalás —, ott emberi jóváhagyás van, az AI pedig legfeljebb piszkozatot készít.

A következő lépés

Ha van olyan pontja a cégében, ahol AI-t engedne szöveget írni — e-mail, ajánlat, riport-összefoglaló —, először azt írja le egy lapra, mi történik, ha rosszul írja. Onnantól a kapuk szinte maguktól adódnak.

Számolja ki a megtakarítás-kalkulátorral, mennyit ér Önnél ez a munka, vagy kérjen egy ingyenes 30 perces konzultációt. 30+ élő automatizálásból hozunk példát arra, hol húztuk meg a határt — és miért pont ott.