Hogyan vezessük be az AI-t egy vállalatnál lépésről lépésre?

A vállalati AI-bevezetés nem egy modell vagy chatbot kiválasztásával kezdődik. Először azt kell meghatározni, melyik üzleti folyamatban jelentkezik mérhető probléma, milyen adatok állnak rendelkezésre, és hogyan illeszthető az új megoldás a már működő rendszerekhez.

Az AI önmagában nem javít meg egy rosszul felépített folyamatot. Ha a bemeneti adatok hiányosak, a felelősségi körök nem tisztázottak, vagy az eredmény nem kerül vissza a vállalati rendszerbe, a projekt legfeljebb működő demonstráció marad.

Egy élesben használható megoldásnak az adatminőség, az integráció, a jogosultságkezelés, az emberi kontroll, a költség és a monitoring szempontjából is tervezett rendszerként kell működnie.

Konkrét üzleti problémából induljunk ki

Az olyan célok, mint az „AI használata” vagy a „működés modernizálása”, nem elegendők egy fejlesztési projekt elindításához. Pontosan meg kell határozni, melyik folyamatot szeretnénk gyorsabbá, olcsóbbá vagy megbízhatóbbá tenni.

Jó kiindulópont lehet például:

• beérkező dokumentumok adatainak kinyerése;
• szerződések előzetes elemzése;
• ügyfélkérdések osztályozása és továbbítása;
• belső dokumentumokban történő keresés;
• rendszeres riportok előkészítése;
• ajánlatok vagy válaszlevelek első változatának elkészítése;
• ismétlődő adminisztratív feladatok automatizálása.

Elsősorban olyan folyamatot érdemes választani, amely gyakran ismétlődik, sok manuális munkát igényel, viszonylag egységes bemenetekkel dolgozik, és az eredménye ellenőrizhető.

A folyamat határait már a projekt elején rögzíteni kell. Egy dokumentumelemző rendszer esetében például pontosan meg kell mondani, milyen dokumentumtípusokat kezel, milyen adatokat keres, milyen formátumban ad választ, és mely eseteket továbbítja automatikusan emberi ellenőrzésre.

Mérjük meg a kiinduló állapotot és a kívánt eredményt

Az AI üzleti értéke csak akkor állapítható meg, ha a bevezetés előtti állapotot is mérjük. Legalább azt érdemes rögzíteni, hogy mennyi ideig tart egy feladat, hány munkatárs vesz részt benne, milyen gyakoriak a hibák, és mennyi utólagos javítás szükséges.

Egy jól megfogalmazott projektcél például:

• a dokumentumfeldolgozás átlagos idejének 15 percről 6 percre csökkentése;
• a manuális adatbevitelből eredő hibák 30 százalékos mérséklése;
• az ügyfélszolgálati megkeresések 70 százalékának automatikus kategorizálása;
• a belső információkeresés idejének megfelezése;
• az egy ügyre jutó feldolgozási költség csökkentése.

A kezdeti értékeléshez általában négy alapmutató elegendő:

• átlagos feldolgozási idő;
• feladatonkénti teljes költség;
• hibaarány;
• manuális korrekciók száma.

A modell technikai pontossága csak az egyik mérőszám. Egy rendszer lehet pontos, miközben túl lassú, túl drága, vagy annyi kézi ellenőrzést igényel, hogy üzletileg nem hoz érdemi javulást.

Vizsgáljuk meg az adatok használhatóságát

Az AI-rendszer minőségét közvetlenül meghatározza, hogy milyen adatokkal dolgozik. A nagyobb adatmennyiség önmagában nem jelent jobb eredményt. Fontosabb a relevancia, az aktualitás, a következetes struktúra és a megfelelő hozzáférés.

Az adatfelmérés során tisztázni kell:

• mely rendszerekben találhatók az adatok;
• ki felel azok pontosságáért és frissítéséért;
• vannak-e hiányos, elavult vagy duplikált rekordok;
• milyen jogosultságok vonatkoznak rájuk;
• tartalmaznak-e személyes vagy bizalmas információt;
• visszakövethető-e az AI válasza az eredeti forráshoz.

Dokumentumok feldolgozásánál külön problémát jelenthet a rossz minőségű szkennelés, az eltérő fájlformátum, a következetlen elnevezés és az elavult verziók jelenléte. Ezeket még a modell bevezetése előtt rendezni kell.

A fejlesztési és tesztadatokat érdemes különválasztani. Szükség van egy kézzel ellenőrzött tesztkészletre is, amely tipikus esetek mellett hiányos dokumentumokat, hibás adatokat, ritka kivételeket és többféleképpen értelmezhető bemeneteket is tartalmaz.

Ez a rögzített tesztkészlet később összehasonlítási alapként szolgálhat, amikor megváltozik a modell, a prompt, az adatforrás vagy az alkalmazás valamelyik komponense.

A legegyszerűbb megfelelő architektúrát válasszuk

Nem minden üzleti problémához szükséges generatív AI. Egy üzleti szabály, adatbázis-lekérdezés vagy hagyományos automatizáció sok esetben gyorsabb, olcsóbb és kiszámíthatóbb.

Nagy nyelvi modell akkor indokolt, ha a rendszernek szöveget kell értelmeznie, összefoglalnia, osztályoznia, strukturálnia vagy előállítania.

Ha a válaszoknak belső vállalati dokumentumokon kell alapulniuk, RAG-architektúra használható. A rendszer először megkeresi a kérdéshez kapcsolódó dokumentumrészleteket, majd ezeket továbbítja a nyelvi modellnek.

kérdés → keresés a vállalati forrásokban → releváns dokumentumrészletek → válasz generálása → ellenőrzés

A RAG csökkentheti a pontatlan vagy kitalált válaszok számát, de nem garantálja a helyességet. Külön kell vizsgálni, hogy a kereső megtalálta-e a megfelelő forrást, és hogy a generált válasz valóban azon alapul-e.

AI-agentet csak akkor érdemes alkalmazni, ha a rendszernek több lépést kell önállóan megterveznie, vagy különböző eszközök és adatforrások közül kell választania. Ha a folyamat előre leírható, biztonságosabb egy rögzített munkamenet:

adatlekérés → validáció → AI-feldolgozás → eredményellenőrzés → mentés

Minél nagyobb önállóságot kap a rendszer, annál szigorúbb jogosultságkezelésre, naplózásra, költségkorlátozásra és biztonsági tesztelésre van szükség.

A pilotot, a tesztelést és az élesítést egy folyamatként kezeljük

A pilot célja nem egy látványos bemutató elkészítése, hanem annak ellenőrzése, hogy a megoldás valós adatokkal, valós felhasználókkal és a tényleges munkakörnyezetben is használható-e.

Egy jól körülhatárolt pilot:

• egyetlen üzleti folyamatot fed le;
• meghatározott felhasználói csoporttal működik;
• korlátozott adattartományt használ;
• előre rögzített költségkerettel rendelkezik;
• egyértelmű sikerfeltételek alapján értékelhető;
• leállítható anélkül, hogy az alapfolyamat megszakadna.

Az első verzió lehetőleg csak javaslatokat készítsen. Ne kapjon automatikus jogosultságot levelek elküldésére, adatok törlésére, pénzügyi műveletek indítására vagy éles rendszerrekordok módosítására.

Egy szerződéseket elemző rendszer például felismerheti a feleket, dátumokat és összegeket, kiemelheti a vizsgálandó pontokat, valamint jelezheti a hiányzó adatokat. A végső értelmezést és jóváhagyást azonban továbbra is szakember végzi.

A tesztelésnek nemcsak a modell válaszaira kell kiterjednie. Vizsgálni kell:

• a válaszok tényszerű pontosságát és teljességét;
• a megadott formátum betartását;
• a források helyes használatát;
• a bizonytalan esetek felismerését;
• a hibás és hiányos bemenetek kezelését;
• a válaszidőt és a feladatonkénti költséget;
• az API- és integrációs hibákat;
• a jogosulatlan adatelérés elleni védelmet;
• a manipulált utasításokkal szembeni ellenállást.

Az élesítés fokozatosan történjen. Először rögzített tesztadatokon működjön a rendszer, majd következhet a megfigyelési üzemmód, amelyben már valós eseteket dolgoz fel, de az eredménye még nem módosítja közvetlenül az üzleti folyamatot.

Ha a mért eredmények megfelelőek, a rendszert korlátozott felhasználói csoport kaphatja meg, kötelező emberi jóváhagyással. Az automatizáció mértéke csak akkor növelhető, ha a minőségi, biztonsági és költségmutatók tartósan teljesülnek.

Minden kiadásnál rögzíteni kell a modell, a promptok, az adatforrások és a konfiguráció verzióját. A teszteredmények és a telepítés időpontja mellett visszaállítási tervre is szükség van, hogy hiba esetén gyorsan vissza lehessen térni egy korábbi, stabil állapothoz.

Az integrációt ellenőrzött rétegen keresztül valósítsuk meg

A nyelvi modell ne kapjon közvetlen hozzáférést a vállalat éles adatbázisához vagy belső rendszereihez. A kéréseknek egy alkalmazási vagy integrációs rétegen kell áthaladniuk.

Ennek a rétegnek kell kezelnie:

• a felhasználó azonosítását;
• a szerepköralapú jogosultságokat;
• a végrehajtható műveletek korlátozását;
• a bemeneti és kimeneti adatok validálását;
• az API-hívások felügyeletét;
• a költség- és használati limiteket;
• a naplózást és a hibakezelést.

A helyes architektúra egyik alapelve, hogy az AI csak a konkrét feladat elvégzéséhez szükséges adatokat kapja meg. Egy ügyfélszolgálati kérdés megválaszolásához például nincs szükség a teljes ügyfél-adatbázis továbbítására.

A modell kimenetét nem szabad automatikusan megbízhatónak tekinteni. Ha a válasz adatbázis-lekérdezéshez, API-híváshoz, HTML-kódhoz vagy más rendszerutasításhoz kerül felhasználásra, előbb szigorúan validálni kell.

Az AI kimenete lehetőleg strukturált formátumban érkezzen. Ha az alkalmazás meghatározott mezőket vár, a rendszernek ellenőriznie kell azok típusát, tartalmát és megengedett értékeit, mielőtt továbbítja őket a célrendszernek.

Az emberi kontrollt a kockázathoz igazítsuk

Nem minden AI-feladat igényel azonos szintű ellenőrzést. A szükséges kontrollt annak alapján kell meghatározni, hogy mekkora kárt okozhat egy hibás eredmény.

Alacsony kockázatú feladat lehet egy belső jegyzet első változatának elkészítése vagy dokumentumok témák szerinti rendezése. Ezeknél elegendő lehet az időszakos, mintavételes ellenőrzés.

Közepes kockázatú feladat például egy ügyféllevél, ajánlat vagy szerződés-összefoglaló elkészítése. Ilyen esetben a munkatárs jóváhagyása nélkül a tartalom nem kerülhet továbbításra.

Pénzügyi, jogi, egészségügyi, biztonsági vagy munkajogi döntéseknél az AI csak támogató szerepet kaphat. A végső döntésért egyértelműen meghatározott személynek kell felelnie.

Minden rendszerhez rögzíteni kell:

• ki ellenőrzi az eredményt;
• mikor kötelező az emberi jóváhagyás;
• milyen esetben kell szakértőhöz továbbítani az ügyet;
• ki felel a hibás eredmény kezeléséért;
• mikor kell korlátozni vagy leállítani a rendszert.

Az éles rendszer folyamatos megfigyelést igényel

Az AI-rendszer teljesítménye az üzembe helyezés után is változhat. Módosulhatnak a bemeneti adatok, a vállalati szabályok, a dokumentumok, a külső API-k vagy maga a használt modell.

Folyamatosan figyelni kell:

• a válaszok minőségét;
• a manuális javítások arányát;
• a válaszidőt;
• az egy feladatra jutó költséget;
• az integrációs hibákat;
• a sikertelen és elutasított kéréseket;
• a jogosulatlan hozzáférési kísérleteket;
• a felhasználói visszajelzéseket.

A monitoringnak nemcsak technikai hibákat kell jeleznie. Azt is láthatóvá kell tennie, ha romlik az üzleti eredmény, például nő a kézi javítások száma, csökken a helyes válaszok aránya, vagy indokolatlanul emelkedik a használati költség.

Előre meg kell határozni azokat a küszöbértékeket, amelyek elérésekor a rendszer korlátozott módba vált, kötelező emberi jóváhagyást kér, tartalékmegoldásra kapcsol, visszatér egy korábbi verzióhoz, vagy ideiglenesen leáll.

A megtérülést teljes folyamatköltségből számoljuk

A megtérülés meghatározásához először a jelenlegi folyamat teljes költségét kell kiszámítani. Nemcsak a közvetlen munkaidőt, hanem a hibák javítását, a késéseket és az ismételt feldolgozást is figyelembe kell venni.

jelenlegi folyamatköltség = feladatok száma × átlagos feldolgozási idő × teljes óraköltség + hibák és javítások költsége

Az AI-megoldás teljes költségébe beletartozik:

• a tervezés és fejlesztés;
• az adatok előkészítése;
• az integráció;
• a modellhasználat díja;
• az infrastruktúra;
• a tesztelés és a biztonsági ellenőrzés;
• a monitoring;
• a karbantartás;
• az emberi felülvizsgálat.

Az AI akkor hoz valódi megtakarítást, ha a felszabaduló munkaidő ténylegesen felhasználható más feladatokra, nagyobb ügyfélmennyiség kezelésére vagy a folyamat költségének csökkentésére. Az, hogy egy munkatárs gyorsabban végez egy feladattal, önmagában még nem jelent automatikus pénzügyi megtérülést.

Egy használható vállalati AI-rendszer felépítésének logikája egyszerű:

üzleti probléma → mérhető cél → megfelelő adatok → egyszerű architektúra → kontrollált pilot és tesztelés → biztonságos integráció → emberi felügyelet → monitoring

A projekt akkor eredményes, ha az AI nem különálló eszközként működik, hanem mérhetően javít egy konkrét üzleti folyamatot, miközben az eredménye ellenőrizhető, a működése naplózható, és hiba esetén biztonságosan korlátozható.

Cikkünket a Stratify AI csapatával együttműködve készítettük.