Miért bukik meg az AI-pilotok túlnyomó többsége

Az elmúlt két évben szinte minden nagyobb magyar vállalatnál elindult valamilyen AI-kísérlet. Chatbot az ügyfélszolgálaton, dokumentumfeldolgozás a pénzügyön, riportgenerálás a kontrollingon. A gyakran idézett MIT-felmérés szerint ezeknek a generatív AI-pilotoknak a túlnyomó többsége soha nem jut el a termelésig — és a magyar tapasztalataink ezt megerősítik.

Az érdekes kérdés nem az, hogy hány bukik meg. Az érdekes kérdés az, hogy miért mindig ugyanazon a néhány ponton.

1. A csapat a dokumentált folyamatra épített

Ez a leggyakoribb. Valaki leül a szakterületi felelőssel egy órára, megkérdezi, hogyan megy a munka, és kap egy tiszta, hatlépéses választ. Elkezdi arra építeni a rendszert.

A valóság az, hogy a hatlépéses folyamat harminc lépés, és a lépések fele kivétel. „Érkezik egy e-mail” — negyven feladótól, nincs két egyforma formátum, a lényeg fél esetben egy PDF-ben vagy egy képernyőképen van, és hogy melyik ügyet hova kell továbbítani, az egyetlen kolléga fejében létezik. Aki ezt soha nem írta le, mert soha senki nem ült mellette nyolc órán keresztül.

Amit ilyenkor építesz, az egy olyan rendszer, ami a tesztkörnyezetben tökéletesen működik, és az első éles héten leáll.

Egy egyórás interjún azt kapod meg, amit a kolléga a munkájának gondol. Egy teljes munkanapon azt kapod meg, ami a munkája.

2. Mindent odaadtak a modellnek

Volt egy időszak, amikor a stratégia annyi volt, hogy „a modellek elég jók, adjunk oda nekik mindent”. Ennek két következménye lett: elszaladt a token-költség, és a rendszer olyan lépéseknél is hallucinált, ahol egy egyszerű if sokkal megbízhatóbb lett volna.

Egy tízlépéses munkafolyamatban jellemzően két-három lépés az, ahol tényleg ítéletre van szükség. A többi API-hívás, adatvalidáció és elágazás. Ha ezeket is modellre bízod, akkor drágább, lassabb és megbízhatatlanabb rendszert kapsz, mint amilyet determinisztikus kóddal kaptál volna.

Ennek az eldöntése — lépésről lépésre, hogy melyik melyik — a forward deployed engineer legfontosabb munkája.

3. Nem volt mérés, csak benyomás

„Jónak tűnik” nem eredmény. Amikor a projekt védésére kerül a sor, a pénzügyi vezető azt fogja kérdezni, hogy hány százalékban találja el, és mi történik a maradékkal. Ha erre nincs szám, a projekt leáll.

A mérési készlet — az arany adathalmaz — nem luxus, hanem a bevezetés előfeltétele. Ötven futásból negyvenegy ment át; a kilenc hibából öt hiányzó adat, négy rossz rekord. Ez egy mondat, amiből lehet dolgozni. A „szerintem elég jó” nem az.

4. Rendszercserét kértek egy olyan cégtől, ami két éve migrált

Ha egy vállalat két évet és sokmillió forintot költött egy ERP bevezetésére, akkor az AI-javaslat, ami azzal kezdődik, hogy „ehhez le kell cserélni”, halott.

Az működik, ha ráépítesz. A meglévő rendszer API-jaira, a meglévő jogosultsági modellre, a meglévő folyamatra. Nem azért, mert ez a technikailag elegánsabb megoldás, hanem mert ez az egyetlen, amit a szervezet be tud fogadni.

5. Senki nem gondolt arra, hogy a megrendelő kockázatot lát benned

Ezt szokták a legritkábban kimondani. A belső szponzorod — az osztályvezető, aki behozott — nem elsősorban innovációt keres. Ő szeretné megtartani az állását, és szeretne előrelépni.

Ha nem csináltok semmit, a status quo marad, és neki nem lesz baja. Ha behoz téged és a projekt elhasal, az az ő neve mellett fog szerepelni. Vagyis már az is kockázat neki, hogy egyáltalán ott vagy.

Ebből következik minden gyakorlati döntés a bevezetés körül:

• Az audit legyen az első lépés, ne a build — mert az audit önmagában is értékes leszállítandó, még akkor is, ha a projekt utána nem folytatódik.
• A rendszer először árnyékmódban fusson a kollégák mellett, ne helyettük.
• Minden lépés legyen naplózva és visszanézhető.
• A siker legyen számokban kimondva, hogy a szponzorod be tudja tenni a teljesítményértékelésébe.

Mit érdemes ehelyett csinálni

Egy folyamatot, végig. Nem ötöt párhuzamosan.

1. Felmérés. Valaki beül a csapat mellé, és felveszi, hogyan megy a munka valójában — a kivételágakkal együtt.
2. Döntés. Lépésenként eldöntitek, mi marad kód, mi lesz modellhívás, és hol marad ember a hurokban.
3. Mérés. A saját múltbeli eseteitekből összeáll egy arany adathalmaz, és megnézitek, hol tart a rendszer.
4. Árnyékmód. Fut, de nem dönt. A kollégák látják a javaslatait.
5. Fokozatos élesítés. Először a magas biztonságú esetek, aztán a többi.

Ez lassabbnak tűnik, mint azonnal építeni. A gyakorlatban ez a gyorsabb út, mert nem kell félúton eldobni mindent.

Ha kíváncsi vagy, nálatok melyik ponton áll meg a dolog, kezdjük egy beszélgetéssel.