Paljud organisatsioonid lähtuvad eeldusest, et nende roll on kindlaks määratud: nad on kasutaja süsteemile, mille on üles ehitanud tarnija, ja sellega kaasnevad kohustused on selged ja püsivad. See eeldus vastab sageli tõele, kuid mitte alati. Roll, mis organisatsioonil on AI-süsteemi suhtes, ei ole kindel etikett. See on tulemus sellest, mis süsteemiga faktiliselt toimub, ja see tulemus võib muutuda ilma, et sõlmitaks uus leping või tehtaks uus ost.
Rolli liigitus sõltub mitmest faktilisest elemendist, mitte sellest, kuidas tarnija süsteemi nimetab või kuidas sisemine osakond süsteemi organisatsiooni siseselt positsioneerib. Olulised on muu hulgas see, kes on süsteemi turule toonud, kes süsteemi tegelikult oma protsessis kasutab, ja kes on süsteemi pärast tarnimist muutnud. Samuti on oluline, mille nime alt süsteem avalikkusele esitletakse, ja kas organisatsioon annab süsteemi teistele edasi ilma seda ise kasutamata. Need elemendid määravad koos, kas organisatsioon tegutseb pakkujana, kasutajana või poolena, mis jääb kuskile vahepeale.
Põhjus, miks see on juhtimise (governance) seisukohalt oluline, on see, et roll määrab, millised kohustused millisele poolele langevad. Organisatsioonil, mis on ainult kasutaja, on teised kohustused kui organisatsioonil, mis tegelikult tegutseb pakkujana. Mida täpselt igalt rollilt oodatakse, on kirjeldatud mujal; siin on jutt mehhanismist, mis määrab, mis roll kohaldub, ja selle märkamisest, millal see mehhanism annab teistsuguse tulemuse kui varem.
Roll ei ole seotud süsteemiga selle kogu kasutusea vältel. See on seotud sellega, mis konkreetsel hetkel faktiliselt toimub. See tähendab, et sama organisatsioon võib sama süsteemi puhul kahel erineval hetkel kuuluda erinevasse rolli. Mõned olukorrad, kus see juhtub: meeskond, mis peenhäälestab (fine-tune) sisse ostetud mudelit oma andmetega, osakond, mis märgistab süsteemi ümber ja pakub seda oma nime all teistele osakondadele, või organisatsioon, mis annab süsteemi, mis oli algselt mõeldud sisemiseks kasutuseks, edasi kliendile või partnerile. Kõigil neil juhtudel muutub faktiline roll, isegi kui väljapoole jäävas pildis muutub vähe.
Mis praktikas muutub, ei ole abstraktne. See määrab, kes vastutab dokumentatsiooni eest, kes peab tõendama, et süsteem tegutseb nii, kuidas väidetud, ja kes peab reageerima, kui midagi läheb valesti. Rohkem selle kohta, mis täpselt muutub, kui mudelit muudetakse, on kirjeldatud lehel mudeli muudatuste kohta. See muutus on üks selgemaid näiteid selle kohta, kuidas roll kaldub teisele poole, ilma et sellele eelneks teadlik otsus.
Põhjus, miks see teema on oluline mitte ainult õiguslikult, vaid ka organisatoorselt, on see, et rollimuutus toimub sageli märkamatult. Meeskond, mis mudelit muudab, mõtleb tehnilisele täiustusele, mitte vastutuse muutumisele. Osakond, mis annab tööriista edasi teisele osakonnale, mõtleb mugavusele, mitte uuele rollile levitajana. Juhtimine, mis vaatab ainult seda, mis on sisse ostetud, jätab need muutused süstemaatiliselt märkamata.
See on seotud küsimusega, millised rakendused täpselt jäävad regulatsiooni alla ja millised mitte; seda piiri käsitletakse lehel rakenduste kohaldamisala kohta. Süsteem, mis jäi kohaldamisalast välja, kui see sisse osteti, võib jõuda kohaldamisalasse niipea, kui organisatsiooni roll muutub. See tähendab, et ostmise hetkel ühekordne kontroll ei ole piisav; kontroll peab liikuma koos sellega, mis süsteemiga faktiliselt toimub.
Ka rakenduse riskitase võib rollimuutusega koos liikuda. Mida kõrge riskitase täpselt tähendab organisatsiooni kohustuste jaoks ja millest see sõltub, on selgitatud lehel kõrge riskitaseme tagajärgede kohta. Organisatsioon, mis rollimuutuse tõttu kehtib äkki pakkujana süsteemile, mille riskitase on kõrge, kannab teisi kohustusi kui siis, kui ta oli sellesama süsteemi ainult kasutaja.
Selleks, et rollimuutusi märgata enne, kui neist saab probleem, peab organisatsioon teadma, milliseid süsteeme on olemas, kes neid muudab ja kes neid kellele edasi annab. See eeldab inventuuri, mis läheb kaugemale nimekirjast, mille IT on heaks kiitnud, ja kindlat kohta, kuhu salvestatakse otsused muutmise, edasiandmise ja ümbermärgistamise kohta. Selline kindel koht ja sellega kaasnevad küsimused on kirjeldatud lehel oversight-otsuste registri kohta.
Responsible AI Scan on loodud nende muutuste nähtavaks tegemiseks: milliseid süsteeme faktiliselt kasutusel on, kes neid kasutab, kes neid on muutnud ja mis roll sellest praegusel hetkel tuleneb. Tööriist, mis sellele tuginedes tuge pakub, on veel ehitamisel; kes soovib seda kasutada, saab registreeruda ootenimekirja.
Rollimuutus mõjutab mitte ainult juhtimist (governance). Kui süsteem liigub eraldiseisvast abivahendist millekski, mis struktuurselt võtab üle osa ülesandest, muutub ka küsimus, kui palju tööd see süsteem tegelikult teeb ja kui palju jääb veel inimeste kanda. FTE TO AI töökoormuse skaneering arvutab ülesande kaupa välja, kui suur osa tööst on võimalik AI-le üle anda, ja teeb sellega nähtavaks, kus juhtimise (governance) rollimuutus langeb kokku töö jaotuse faktilise muutumisega.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.