JAV bankų priežiūra paskelbė DI vertinimo gaires: kodėl svarbiausia klaidų pasekmės, o ne modelio dydis?

JAV valiutos kontrolieriaus tarnyba (OCC), prižiūrinti nacionalinius bankus, pristatė pirmąsias specialiai DI naudojimo vertinimui skirtas gaires priežiūros specialistams. Jose akcentuojama, kad dirbtinis intelektas neturėtų būti vertinamas vien pagal technologijos sudėtingumą: svarbiau, kokius sprendimus sistema priima ir kokių pasekmių turėtų jos klaidos. Tai aktualu bankams, finansinių technologijų bendrovėms ir visoms organizacijoms, kurioms kyla pagunda automatizuoti didelės vertės sprendimus. Gairės nėra naujas visiems privalomas federalinis įstatymas.

Ką akcentuoja priežiūros institucija

Remiantis „Reuters“ aprašytu dokumentu, OCC rekomenduoja vertinti konkretų DI panaudojimą, banko dydį ir veiklos sudėtingumą. Bankams nebūtinai reikėtų kurti visiškai atskirą rizikos valdymo sistemą vien todėl, kad jie naudoja DI. Tačiau jų turimos procedūros turi apimti naujus galimų klaidų, automatinio sprendimo ir trečiųjų šalių paslaugų pavojus. Todėl technologijos vertinimas susiejamas su realiais veiklos procesais: viena yra vidinis teksto apibendrinimas, visai kas kita – sistema, galinti be papildomo patvirtinimo pervesti pinigus ar patvirtinti paskolą.

Kodėl paprastas DI agentas gali būti rizikingesnis

Didelis modelis, naudojamas tik vidaus dokumentų paieškai, gali kelti mažesnę finansinę riziką nei paprastesnė programa, turinti teisę automatiškai vykdyti operacijas. Ši mintis keičia įprastą diskusiją, kurioje dėmesys dažnai tenka vien modelio parametrų skaičiui. Svarbios teisės, kurios suteiktos programai, galimos nuostolių ribos, klaidos aptikimo laikas ir žmogaus galimybė sustabdyti veiksmą. Kitaip tariant, rizikos dydis priklauso nuo technologijos vietos sprendimų grandinėje, o ne nuo jos reklamuojamo intelekto lygio.

Ką galėtų perimti Europos fintech įmonės

Nors OCC gairės tiesiogiai skirtos JAV priežiūros sistemai, jose pateikiami principai naudingi ir Europos finansinių technologijų sektoriui. Prieš suteikiant DI agentui prieigą prie mokėjimų, klientų duomenų ar kredito vertinimo, naudinga nustatyti aiškias teises, auditavimo žurnalus ir žmogaus patvirtinimo ribas. Taip pat reikia vertinti duomenų šališkumą, kibernetinį saugumą ir trečiųjų šalių programinės įrangos tiekėjų riziką. Tokie klausimai dažnai yra sudėtingesni už patį modelio įdiegimą, ypač kai sistema naudojama milijonams vartotojų.

Praktinis pavyzdys mažai įmonei

Tarkime, internetinė parduotuvė nori DI įrankiui leisti automatiškai grąžinti klientų mokėjimus. Kol agentas tik parengia rekomendaciją operatoriui, jo klaidos poveikis ribotas. Bet jei jis gali savarankiškai inicijuoti neribotą skaičių grąžinimų, net viena programos logikos klaida gali sukelti didelių nuostolių. Praktiškas sprendimas būtų nustatyti vienos operacijos limitą, dvigubą patvirtinimą didesnėms sumoms ir galimybę nedelsiant išjungti automatiką. Tai bendras rizikos valdymo principas, o ne konkreti JAV gairių nustatyta prievolė Lietuvos prekybininkams.

Kokių pokyčių galima laukti

Didėjant DI naudojimui finansuose, tikėtina, kad institucijos vis daugiau dėmesio skirs modelių stebėsenai ir jų poveikio demonstravimui. Tačiau nuo rekomendacijų iki privalomų naujų taisyklių paprastai yra papildomų žingsnių. Bankams svarbu iš anksto rengti aiškią dokumentaciją ir testavimo scenarijus, kad sprendimai būtų paaiškinami bei pataisomi. Finansinių technologijų tiekėjams tai priminimas, kad saugi integracija gali būti komerciškai vertingesnė už įspūdingą, bet nevaldomą automatizavimo demonstraciją.

Duomenų kokybė yra priežiūros pagrindas

Automatinis sprendimas gali būti greitas, tačiau net tiksliausias modelis prastai veiks, jei jo mokymo arba realaus naudojimo duomenys yra pasenę, neišsamūs ar neteisingi. Finansų srityje tai gali paveikti klientų aptarnavimą, sukčiavimo aptikimą ir kredito vertinimą. Todėl prieš diegiant DI būtina išsiaiškinti duomenų kilmę, kokybės kontrolę ir tai, kaip bus registruojamos klaidos. Kartais paprastesnė ir aiškiau audituojama sistema gali būti saugesnė už pažangesnį, bet sunkiai prižiūrimą modelį. Šis principas padeda sutelkti dėmesį į praktiškus veiklos rezultatus.

Svarbi riba tarp konsultavimo ir veiksmo

Verslo DI projektus galima suskirstyti pagal suteiktas teises. Sistema, kuri tik parengia klientui atsakymo juodraštį, paprastai turi mažesnį tiesioginį poveikį nei sistema, kuri be priežiūros pasirašo sutartį, perveda pinigus arba pakeičia kliento sąlygas. Todėl kiekvienam procesui verta nurodyti, kas priima galutinį sprendimą ir ar galima atkurti jo priėmimo eigą. Taip pat būtina numatyti, kaip įmonė reaguos į blogą modelio elgesį ir kaip informuos klientą apie klaidą. Šie klausimai turėtų būti išspręsti dar prieš suteikiant agentui realias veikimo teises.

Praktinis žingsnis verslui ir investuotojui

Prieš įdiegiant DI sistemą naudinga surašyti vadinamąjį leidimų žemėlapį: kokius duomenis agentas gali matyti, kokius veiksmus gali atlikti ir kokių veiksmų jam draudžiama imtis. Ne mažiau svarbu turėti testavimo pavyzdžių, kuriuose sistema susiduria su neaiškiais ar klaidinančiais duomenimis. Gerai suplanuotas sprendimas turi saugiai sustoti, kai trūksta informacijos, o ne kurti tariamą tikrumą. Ši praktika gali būti naudinga ir už bankų ribų, pavyzdžiui, elektroninėse parduotuvėse, draudimo įmonėse ar klientų aptarnavimo centruose, kuriuose klaidos gali kainuoti pinigų.

Pagrindinė OCC žinia paprasta: DI riziką lemia ne pavadinimas ir ne modelio dydis, o jo teisės bei galimos klaidų pasekmės. Tai principas, kurį verta taikyti gerokai platesniame verslo automatizavimo kontekste.

Šaltiniai: Reuters – JAV bankų priežiūros DI gairės; CSBS – DI priežiūros sistemos bendras kontekstas.