Всяка организация с определен мащаб вече има структура за риск. Комитет по риска, функция за одит, линия на докладване към управителния съвет, формат, в който рисковете се класифицират по степен и се следят. Ако някой постави нов процес до него, специално за ИИ, с отделен комитет, отделен календар и отделен език, в рамките на година получава процес, който никой вече не попълва. Не защото ИИ се смята за неважен, а защото втора структура се конкурира с първата за време, внимание и мандат. Съществуващата структура почти винаги печели, защото е вградена в оценки, циклите на функционирането и програмите на управителния съвет. Новата структура стои извън тях.
Въпросът следователно не е как да изградите структура за управление на ИИ. Въпросът е как ИИ да получи място в структурата, която вече съществува.
Повечето структури за риск вече включват няколко постоянни елемента: инвентаризация на риска, която се актуализира периодично, класификация по тежест и вероятност, собственик за всеки риск, линия за ескалация към по-високо ниво, ако бъде превишена граница, и докладване на управителния съвет в определени моменти. Това е структурата, в която ИИ трябва да се вписва, не редом до нея.
Това означава, че приложение на ИИ не бива да стои в отделен регистър за ИИ, а като елемент на риска в съществуващия регистър, със същите полета, както всеки друг риск: собственик, тежест, вероятност, мерки за смекчаване, дата на статус. Класификацията по ниво на риска, която се отнася до инвентаризация на употребата на ИИ, трябва да се обвързва със скалата, която вече се използва за операционен риск, не с нова скала, измислена единствено за ИИ. Който прочете какво трябва да знае един CIO за риска от ИИ, вижда, че точно там често се случва разминаването: технически коректна оценка на риска от ИИ, която никой не може да съпостави с останалата част от регистъра на рисковете.
Две неща правят вграждането трудно. Първото е езикът. Риск мениджърите работят с понятия като въздействие, вероятност и мярка за смекчаване. Доставчиците на ИИ и техническите екипи работят с версии на модели, обучаващи данни и показатели за производителност. Набор от правила за управление, написан само на технически език, не се чете от комитета по риска. Набор от правила за управление, написан само на езика на риска, не се попълва от техническия собственик. Наборът трябва да е разбираем в двете посоки: достатъчно технически, за да е точен, достатъчно управленски, за да се приема. Този принцип се повтаря в ai-политика, която се чете: документ, който се обвързва с начина, по който хората вече читат и решават, вместо да изисква нов начин на четене.
Второто е темпото. Комитет по риска заседава по определен цикъл, често на всеки квартал или месец. Употребата на ИИ се променя по-бързо: екип започва тази седмица с нов инструмент, без да е предхождано от заседание. Наборът от правила за управление затова не бива да зависи от цикъла на заседанията, за да функционира. Трябва да съществува по-лек механизъм, който улавя отклоненията между определените моменти и се потвърждава официално едва при следващия цикъл. Как функционира този механизъм на практика, е описано при пътища за ескалация, които работят: маршрут, достатъчно кратък, за да се използва преди следващото тримесечно заседание на комитета.
Набор от правила за управление, който се обвързва със съществуваща структура за риск, съдържа основно: елемент от инвентаризацията за всяко приложение на ИИ със собственик и клас на риска, връзка към съществуващия път за ескалация, така че отклонение да не изчезва в отделен канал, и постоянно място в периодичното докладване на управителния съвет. Не като отделна глава за ИИ, а като ред в таблицата, която управителният съвет вече познава. Как може да изглежда това докладване, без да се въвежда нов формат, е описано при как получавате докладване до управителния съвет от една страница, вградено в това, което вече циркулира.
Съдържанието на самите правила, какво точно попада под кое ниво на риска и какви срокове се отнасят към него, е записано другаде и се променя; тази страница се отнася до механизма, който дава на това съдържание място в съществуващата структура, не до текста на тези правила.
Вграждането успява само ако инвентаризацията е коректна от самото начало. А тя е коректна само ако хората се осмеляват да казват какво използват. Който при попълването на елемента от риска усеща, че честен отговор води до бележка в оценка, не го попълва честно. Наборът от правила за управление затова трябва още от първата версия да изясни, че целта е преглед, не санкция. Без този ангажимент част от употребата остава извън обхвата, и обвързването със структурата за риск е изградено върху непълен списък. Какво трябва да знае ръководител по този въпрос, преди да започне първата инвентаризация, е описано при какво трябва да знае ръководител за риска от ИИ.
Това вграждане се отнася до риск, собственост и докладване: то осигурява, че това, което прави ИИ, е видимо и управляемо в структурата, която вече съществува. Друг въпрос, който логично следва, щом прегледът е налице, е какво ИИ действително може да поеме в рамките на тази работа. Работният анализ на FTE TO AI изчислява за всяка задача какъв дял от работата може да се поеме от ИИ, като следваща стъпка след като страната на управлението е в ред.
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.