Kennisbank

Kuidas vältida osakonda, kellel on oma tellimus?

Turundusmeeskond vajab kirjutamisassistenti. Finantsanalüütik soovib tööriista, mis võtab kokku tabelarvutused. Ükski neist ei oota hankeprotsessi, mis kestab kuid. On krediitkaart, e-posti aadress, ja kümne minuti jooksul on olemas tellimus, mille osakond ise maksab, ise haldab ja ise kasutab. IT-osakond ei tea sellest midagi. Puudub põhjus sellest teatada, sest midagi valesti tehtud ei ole — on lihtsalt üks probleem lahendatud.

Kuidas see tekib

Enamik varjatud AI-kasutust ei alga katsest reeglitest kõrvale hoida. See algab ülesandest, mis peab kiiremini valmis saama, tähtajast, mis ei oota heakskiitmisprotsessi, ja tööriistast, mis on kättesaadav ilma teiste sekkumiseta. Osakond, kes selle tellib, ei näe seda IT-otsusena. See tundub kontoritarbena, mitte teisiti kui tarkvaralitsentsina, mida kõik kasutasid juba enne, kui kehtis tsentraalne hankepoliitika. See, et keelemudel töötleb ettevõtte andmeid, loeb kliendiandmeid või genereerib mustandteksti, mis läheb ettevõttest välja, ei ole kasutaja jaoks juhtimisküsimus. See on lihtsalt töö.

Sama dünaamika ilmneb ka juhul, kui tarnija ehitas AI oma tootesse, ilma et selle üle oleks eraldi räägitud: funktsionaalsus ilmub uuenduses, keegi ei kirjuta selle kohta midagi alla, ja organisatsioon kasutab seda enne, kui on kindlaks tehtud, kes selle eest vastutab.

Miks see ei kao iseenesest

Teadaanne, et lubamatud tööriistad ei ole lubatud, muudab vähe. Osakond, kellel on tellimus, tajub seda lahendusena, mis toimib, mitte riskina, mida tuleb teatada. Keeld ilma alternatiivita annab kaks tulemust: tellimus läheb maa alla, või meeskond loobub sellest ja töö muutub taas aeglasemaks. Kumbki ei ole see, mida organisatsioon soovib.

Lisaks on selline tellimus harva ühekordne otsus. See muutub töövoo osaks, seotakse teiste tööriistadega, kasutatakse protsessides, mis on sellest nüüdseks sõltuvad. See, mis algab prooviversioonina, muutub meeskonna töö kindlaks osaks — täpselt see muster, mida on näha ka proovipaigalduse puhul, mida ei ole kunagi välja lülitatud: keegi ei ole otsustanud teha sellest püsiva, kuid keegi ei ole ka otsustanud selle kasutamist lõpetada.

Mida karistamine ei annab

Refleks otsida üles varjatud AI-kasutus ja pöörduda kasutaja poole karistavalt, toimib vastupidiselt. Kes teab, et teatamine toob kaasa noomituse, ei teata. Tellimus jääb kehtima, ainult vähem nähtavana. Osakond muutub ettevaatlikumaks selles, mida ta raporteerib, mitte hoolsamaks selles, mida ta kasutab.

See, mis toimib, on küsimine ilma sanktsioonita. Meeskonnal, kes kasutab tööriista ülesande kiirendamiseks, on selleks enamasti põhjus, mida organisatsioon soovib teada: protsess, mis on liiga aeglane, ülesanne, mis on ülekoormatud, vajadus, mida olemasolev pakkumine ei kata. Vaadake, kuidas seda kirjeldatakse töötajate puhul, kes kasutavad tööriista, mida keegi ei ole heaks kiitnud — lähtepunkt ei ole rikkumine, vaid vajadus, mis selle taga peitub.

Mida organisatsioon saab teha

Esimene samm ei ole jõustamine, vaid inventuur: milliseid tööriistu on olemas, kes neid kasutab, mille jaoks ja milliste andmetega. See ei toimu IT-nimekirja kaudu — see registreerib, mis on heaks kiidetud, mitte mida kasutatakse. See toimub küsimise teel, viisil, mis ei sisalda ähvardust.

Kui on ülevaade sellest, mis toimib, saab järgneda liigitamine: mis roll on tööriistal, milline riskitase sellega kaasneb ja milline järelevalvevorm on sobiv. Mitte iga tellimus, mille osakond on ise sõlminud, ei kujuta probleemi. Tööriist, mis kirjutab ümber avalikku teksti, kuulub teise kategooriasse kui tööriist, mis töötleb kliendiandmeid ilma, et kellelegi on teada, kuhu need andmed lähevad. Vahe nende kategooriate vahel on täpselt see, mille kohta käib inimjärelevalve praktikas: mitte igal kasutusel ei ole vaja sama kontrollitaset, kuid iga kasutuse puhul on vajalik teada, et see eksisteerib.

Seejärel järgneb juhtimisstruktuur, mis lähtub olemasolevast — ei uus protsess olemasoleva riskiraamistiku kõrval, vaid selle laiendus. Organisatsioon, kes käsitleb AI-riski eraldi ülejäänud riskijuhtimisest, riskib sellega, et teist süsteemi eiratakse, nagu on kirjeldatud teise protsessi puhul olemasoleva kõrval, mida eiratakse. Lähenemine, mis jääb kehtima, on see, mis lähtub sellest, mida organisatsioon juba teeb riski juhtimiseks.

Küsimus, mis jääb

Tellimus, mille osakond on ise sõlminud, on enamasti signaal, et midagi peab toimuma kiiremini, kui praegune protsess võimaldab. See küsimus — milline osa töö saab kiiremaks muuta ja kus see saab toimuda struktureeritult, mitte varjatult — on täpselt see, millele FTE TO AI töövoo skaneerimine vastuse annab. Töövoo skaneerimine arvutab ülesannete kaupa välja, kui suure osa tööst saab AI üle võtta, nii et vajadus, mis viis varjatud tellimuseni, saab koha protsessis, mida organisatsioon tegelikult tunneb ja tegelikult haldab.