Hallinnoitte riskirekisteriä, joka on rakennettu riskien ympärille, jotka voidaan tunnistaa, painottaa ja kohdentaa. Operatiivinen riski, luottoriski, compliance-riski: kullakin on omistaja, hallintatoimenpide, raportointilinja. AI-riski ei sovi tähän kaavaan itsestään, koska ensimmäinen ongelma ei ole painottaminen. Ensimmäinen ongelma on, että ette tiedä mitä painotatte. Tiimi, joka käyttää kielimallia konseptineuvojen kirjoittamiseen, osasto, joka on tehnyt ulkoisen AI-tilauksen IT-hankinnan ohi, taulukkolaskennan makro, josta on sitten tullut ennustemalli: nämä eivät ole reunatapauksia, tässä riski sijaitsee, ja sitä ei ole kirjattu missään.
Kysymyksenne ei ole "onko AI riskialtista". Kysymyksenne on: mitä on käynnissä, kuka siitä vastaa, ja mihin tietoon perustuen voin siitä vastata hallitukselle ja valvojalle. Vastaus, jota ette hyväksy, on rauhoittelu vailla perusteluja. "Mitään erityistä ei ole käynnissä" ei ole vastaus riskikysymykseen, se on vastauksen puuttuminen. Riskienhallintapäällikkö, joka välittää tämän hallitukselle, välittää tiedon siitä, että asiaa ei ole tutkittu, ei sitä, että mitään ei ole.
Toinen vastaus, jota ette hyväksy, on IT-järjestelmähallinnon lista täydellisenä kuvana. Tämä lista näyttää sen, mitä on pyydetty ja hyväksytty. AI-käyttö syntyy suurelta osin juuri tämän pyyntöprosessin ulkopuolella, koska erillistä tilausta, selainlaajennusta tai olemassa olevaan ohjelmistoon sisäänrakennettua toimintoa ei tunnisteta "uudeksi järjestelmäksi". Riskin tunteminen edellyttää siis muutakin kuin järjestelmäkartan tarkastelua – on käännyttävä työtä tekevien ihmisten puoleen, ja tämä vaatii toisenlaisen lähestymistavan kuin IT-auditointi.
Riskienhallintapäällikkönä tunnistatte kaavan alaraportoinnista jokaisessa riskiteemassa, jossa työntekijällä on jotain menetettävää rehellisestä vastauksesta. AI-käyttö on tästä erityisen selkeä esimerkki: jos käytetyn työkalun ilmoittamisesta seuraa käyttöoikeuden peruminen, kukaan ei enää ilmoita siitä. Kartoitus, joka tuottaa tulosta, on kartoitus, joka kysyy sitomatta vastaukseen seurauksia. Tämä on eri taito kuin riskienhallinta normaalisti edellyttää, ja siksi varjo-AI-kartoitusta ei rakenneta valvontana, vaan kyselynä.
Kun käyttö on kartoitettu, seuraava vaihe ei ole toimittajan tai mallin arvioiminen. Se on järjestelmän prosessissa esittämän roolin arvioiminen. AI-sovellus, joka muotoilee tekstiä uudelleen, kantaa erilaisen riskin kuin sovellus, joka vaikuttaa päätökseen asiakkaasta, työntekijästä tai investoinnista. Sama teknologia, käytettynä eri roolissa, kuuluu eri riskiluokkaan. Tämä erottelu on juuri se, mitä riskirekisteri tarvitsee voidakseen sijoittaa AI-riskin muiden siinä olevien riskien rinnalle, luomatta erillistä, eristettyä AI-lukua, jota kukaan ei käytä.
Riskienhallintapäälliköllä ei ole tarvetta uudelle kehykselle olemassa olevan rinnalle. Tarve on hallintakokonaisuudelle, joka liittyy olemassa olevaan riskirakenteeseen: samaan omistajuuslogiikkaan, samoihin eskalaatiopolkuihin, samaan raportointisykliin hallitukselle. AI-riski, jota käsitellään erillisenä teemana, katoaa säännöllisten raporttien väliin. AI-riski, joka on sisällytetty olemassa olevaan riskitaksonomiaan, pysyy näkyvissä paikassa, jota hallitus jo tarkastelee.
Joltain teiltä kysytään jossain vaiheessa, mitä tiedätte organisaation AI-käytöstä – valvojan, auditoijan tai hallituksen itsensä toimesta. Vastaus, joka kestää, ei ole "kaikki on kartoitettu", koska dynaamisen käyttökuvion kohdalla sitä harvoin voidaan todistaa toteen. Vastaus, joka kestää, on todistettava prosessi: miten kartoitus tehtiin, mitä luokittelua sovellettiin, mitkä hallintasopimukset siitä seuraavat, ja millä tiheydellä tätä toistetaan. Tämä on eri mittapuu kuin täydellisyys, ja se on mittapuu, jolla riskienhallintaa normaalisti jo arvioidaan.
Tämä kysymys ei näyttäydy samalla tavalla kaikille organisaation rooleille. Sen, mitä compliance officer tarvitsee tästä kartoituksesta, löydät kohdasta mitä compliance officerin tulee tietää AI-riskistä, ohjauskysymys sille, kuka vetää ohjelmaa, on kuvattu kohdassa mitä AI-ohjelmajohtajan tulee tietää AI-riskistä, ja se, miten tämä aihe näkyy hallituksen tasolla, on kuvattu kohdassa mitä hallituksen jäsenen tulee tietää AI-riskistä. Riskienhallinnasta tietyillä toimialoilla, joilla on omat ketjunsa ja valvontamuotonsa, on tarkempi kuva kohdissa millainen AI-hallinta näyttää rakennusalalla ja millainen AI-hallinta näyttää talotekniikka-alalla.
Voimassa olevien sääntöjen teksti, tarkkoine määritelmineen ja määräaikoineen, ei ole tällä sivulla ja sitä pidetään ajan tasalla muualla. Tässä kuvattu on mekanismi: miten pääsette tuntemattomasta käyttökuviosta luokiteltavaan, raportoitavaan riskiin.
AI-riskin kartoitus tuo väistämättä esiin myös jotain muuta: kuinka suuri osa työstä tehdään jo tosiasiallisesti AI:lla, ja kuinka suuri osa voisi olla. Tämä on eri kysymys kuin riskienhallinta, mutta se jakaa saman lähteen. FTE TO AI:n työskannaus laskee tehtäväkohtaisesti, kuinka suuri osa työstä on AI:n otettavissa haltuun, ja liittyy siten juuri siihen kartoitukseen, jota riskienhallinta nyt jo tarvitsee.
Responsible AI Scan on kehitteillä. Ne, jotka haluavat käyttää sitä sen valmistuttua, voivat ilmoittautua jonotuslistalle.
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.