Kennisbank

A monitoring, amely működik, az a monitoring, amely kapcsolódik ahhoz, ami már megvan

Az AI-használat monitoringja gyakran különálló kezdeményezésként jön létre: egy új formanyomtatvány, egy új megbeszélés, egy új irányítópult. A bevezetés pillanatában teljesnek tűnik. Egy évvel később elhalványul. Nem azért, mert a tartalma rossz volt, hanem mert a meglévő struktúra mellett állt, nem pedig annak részeként.

A kérdés tehát nem csak az, mit kell monitorozni, hanem az, hova landol az a monitoring. Egy olyan folyamat, amelyet senkinek nem kell megjegyeznie, mert már része egy egyébként is futó rutinnak, túléli. Egy olyan folyamat, amely egy extra lépést kér olyan emberektől, akik már túl vannak terhelve, egy idő után kimarad. Ez nem az akarat hiánya. Ez annak kiszámítható következménye, ahogyan a szervezetek az idővel és a figyelemmel bánnak.

Miért marad alul egy második folyamat

Minden szervezetnek van már egy ritmusa: negyedéves jelentések, kockázati bizottságok, audit ciklusok, csoportmegbeszélések. Ha az AI-használat monitoringja új ritmust vezet be, versenyre kel mindennel, ami már létezik — és általában veszít. Nincs hozzá napirendi pont, nincs olyan felelős, aki a feladata核心 részének tekintené, nincs olyan pillanat, amikor önmagától felmerülne.

Ha ezzel szemben a monitoring egy olyan kérdéssé válik, amelyet már feltesznek — a meglévő kockázati bizottságban, a meglévő belső ellenőrzésben, a testület felé irányuló meglévő jelentési vonalon —, akkor senkinek nem kell semmi újat megjegyeznie. A kérdés, hogy „milyen AI-alkalmazások jöttek hozzá vagy változtak meg", ugyanolyan természetessé válik, mint az, hogy „vannak-e új beszállítók" vagy „voltak-e incidensek". Az, hogy ez a kapcsolódás pontosan hogyan alakul, attól függ, hogyan van már kialakítva Önöknél a meglévő kockázati struktúrához kapcsolódás — az a struktúra a kapcsolódási pont, nem egy mellette álló dolog.

Mi tartozik a dokumentumba

Egy működő monitoring-dokumentum elég rövid ahhoz, hogy ismételten használják, és elég konkrét ahhoz, hogy jelezzen valamit, ha valami megváltozik. Legalább a következőket tartalmazza:

• Az AI-alkalmazások aktuális listája, beleértve azt, amit az IT-n keresztül bejelentettek, és azt, amit ezen kívül használnak. Ez a második kategória gyakran a legnagyobb, és minden olyan dokumentumból eltűnik, amely csak a formális jóváhagyásra hagyatkozik.
• Kockázati osztályozás alkalmazásonként, hogy ne minden változás igényeljen ugyanannyi figyelmet. Egy belső feljegyzésekhez szöveget generáló eszköz mást igényel, mint egy olyan modell, amely részt vesz az ügyfél-elfogadási döntésekben.
• Egy felelős alkalmazásonként, egy név, nem egy osztály. Felelős nélkül egy változást sehol nem vesznek észre.
• Egy fix időköz, amikor a listát felülvizsgálják, egy már létező pillanathoz kapcsolva — nem egy új, külön beütemezendő pillanathoz.
• Egy helyet, ahol az eltérések láthatóvá válnak, hogy egy új felhasználás vagy egy megváltozott alkalmazás ne csak hónapokkal később derüljön ki.

A dokumentum értéke nem az első napi teljességben rejlik. Az ritkán elérhető, és nem is szükséges. Az érték abban rejlik, hogy karban tartják, és hogy a karbantartás nem igényel külön erőfeszítést azon felül, ami már történik.

Miért állítja meg a felelőssé tétel az információt

A monitoring attól függ, hogy az emberek mit hajlandók jelezni. Amint a jelzés egyenlő azzal a kockázattal, hogy valamiért felelősségre vonják őket, az információ megáll. Aki egy feladatot egy AI-eszközzel gyorsabban végez el a vártnál, azt nem jelenti, ha ennek következménye a költségvetés visszavonása vagy egy nehéz beszélgetés. A lista ezután formálisan teljes marad, tartalmilag azonban üres — pontosan az a probléma, amely a shadow AI-t életben tartja.

Ennek következménye, hogy a monitoring csak akkor működik, ha a kérdéseket felelősségre vonás nélkül teszik fel. Nem azért, mert a használatnak következmények nélkül kellene maradnia, hanem mert az első lépés — annak megismerése, mi zajlik — más hozzáállást kíván, mint a második lépés — annak megítélése, hogy megfelelő-e. Aki ezt a két lépést összeolvasztja, egyikre sem kap őszinte választ.

Ez a megkülönböztetés az is, ahol a governance és az elszámoltathatóság találkozik. A testület felé irányuló láthatóság nem jelenti azt, hogy minden egyes alkalmazásnak az asztalra kell kerülnie; egy olyan jelentési szintről van szó, amely lehetővé teszi az ítéletet anélkül, hogy a részletekbe fulladna, amint az leírásra kerül egy egy oldalba illő testületi jelentésnél. Amit ez alatt tartunk — a konkrét alkalmazásokra vonatkozó döntések rögzítése — inkább egy oversight-döntéslistába illik, mint a felfelé induló dokumentumba.

Az, hogy egy szabályzati dokumentumot magát olvassák-e, hasonló kérdés: egy olyan szöveg, amelyet senki nem néz meg, éppúgy nem ad támpontot, mint egy olyan monitoring-folyamat, amelyet senki nem tölt ki. Lásd ehhez egy olyan AI-szabályzatot, amelyet olvasnak. És aki azt szeretné megtudni, ez a felelősség melyik része tartozik a testületi asztalhoz és melyik része az IT-governance-hoz, ott megkülönböztetés van amit egy vezetőnek tudnia kell az AI-kockázatról és amit egy CIO-nak tudnia kell az AI-kockázatról között — mindkettő más részletezettségi szintet kér ugyanazon monitoring-folyamaton belül.

Attól, hogy tudjuk mi folyik, addig hogy tudjuk mit hoz

Egy olyan monitoring-struktúra, amely kapcsolódik ahhoz, ami már megvan, egy bizonyos ponton megbízható képet ad arról, milyen AI-alkalmazásokat használnak, és mire. Ez a felmérés más kérdés, mint az, hogy az alapul szolgáló munka mekkora részét végzi valójában az AI, és milyen hatással. Aki ezt feladatonként szeretné kiszámoltatni — hogy egy funkció vagy folyamat mekkora része adható át az AI-nak, a jelenleg elvégzett feladatok alapján —, azt a FTE TO AI munkaszkennerében találja meg.