A legtöbb AI-pilot nem a technológián bukik el. Azon bukik el, hogy rossz problémára indult.
Ismerős a forgatókönyv: valaki a vezetőségből olvas egy cikket, lát egy demót, és felmerül a kérdés — "nekünk is kellene valami AI-s dolog". Összeáll egy kis csapat, kiválasztanak egy folyamatot, ami "AI-nak tűnik", három hónap alatt összeraknak egy prototípust, bemutatják — és utána semmi nem történik. A pilot lezárul, mindenki visszatér a régi munkájához, a projekt egy PowerPoint-diaként él tovább a következő stratégiai megbeszélésig.
Ez nem azért történik, mert a technológia nem volt elég jó. Azért történik, mert senki nem tette fel előtte a kérdést: ki fogja ezt tényleg használni, és mennyit ér neki, ha megspórol vele időt?
A mi módszerünkben minden projekt egy kérdéssel indul, nem egy megoldással: hol veszik el ténylegesen a legtöbb idő és pénz a szervezetben? Ez nem feltételezés — adatból dolgozunk. Megnézzük, mennyi idő megy el ismétlődő adminisztrációra, hány órát tölt a csapat ugyanazoknak a kérdéseknek a megválaszolásával, mennyi idő vész el a rendszerek közötti kézi adatmozgatással.
Ez a különbség a "AI-projekt" és a "fájdalompontra épített agent" között. Az előbbi egy technológiai demonstráció. Az utóbbi egy konkrét, mérhető probléma megoldása — aminek ezért van is értelme fenntartani, amikor a demó izgalma elmúlik.
A másik gyakori hiba: a pilot sikerét a demó pillanatában mérik, nem az üzemeltetés első hónapjaiban. Egy agent, ami egyszer, kontrollált körülmények között jól teljesít egy bemutatón, még nagyon messze van attól, hogy éles, változó, néha rendetlen valós adaton is megbízhatóan fusson.
Ezért nálunk a fejlesztés és az üzemeltetés nem két külön szakasz, hanem egy folyamat: monitoring, drift-figyelés, guardrail-karbantartás — mert egy agent nem akkor kész, amikor átadjuk, hanem amikor hónapokkal később is megbízhatóan fut.
Amikor egy céggel dolgozunk, először nem azt kérdezzük, "milyen AI-t szeretnétek", hanem azt, hogy "hol fáj a legjobban". Utána tervezzük meg, hova és hogyan kerüljön az agent a folyamatba — emberi jóváhagyási pontokkal ott, ahol a hiba ára magas. Csak ezután épül meg a tényleges rendszer, verziókezelt kóddal, teszteléssel, biztonsági ellenőrzéssel — nem prompt-engineering szinten, hanem production-minőségben.
A pilot nem azért sikeres, mert lenyűgöző volt a bemutatón. Azért sikeres, mert három hónap múlva is fut, és valaki tényleg használja.