Как да вградите списък с решения за надзор в това, което вече съществува

Списък с решения за надзор регистрира кой е взел кое решение за коя AI-система, на база на каква информация и с какво уговорено условие. Това звучи просто. На практика първата версия често се проваля, защото се поставя като нов процес до съществуващите съвещания. Втори процес до вече съществуващия бива игнориран, не защото хората са неохотни, а защото никой не заделя време за нещо, което не се вписва в дневен ред, който вече е претоварен.

Какво трябва да съдържа списък с решения

Списъкът не е дневник на дейности и не е регистър на рискове. Той съдържа решения: моменти, в които някой с правомощия е одобрил, отказал, отложил или е допуснал продължаване при определени условия. На всеки ред трябва да присъстват най-малко четири елемента: системата или приложението, за което се отнася решението, името и ролята на вземащия решението, датата и обосновката или уговорката. Без обосновка списъкът с решения е просто списък с присъствие. С обосновка той става доказателство, че е имало обмисляне, не само че е било отметнато.

Списъкът трябва също да предоставя място за преразглеждане. Решение, взето преди половин година на база на информацията, налична тогава, може да е остаряло. Добър списък с решения показва кога решение е било потвърдено отново или отменено, не само кога е било взето първоначално.

Защо отделен процес бива игнориран

Съветите на директорите и управителните органи вече имат свой ритъм: тримесечни срещи, комитети по риска, одиторски комисии. Кой изгражда нова структура за надзор, откъсната от този ритъм, изисква от хората да намерят допълнително време за нещо, което няма ясно място. Това рядко се случва структурно. Първите няколко пъти може да се получи, с усилие. След това изчезва от дневния ред веднага щом се появи нещо по-неотложно, а винаги се появява нещо по-неотложно.

Решението не е да се изгради нов процес, а списъкът с решения да се вгради в това, което вече се случва. Ако вече има комитет по риска, който се събира всяко тримесечие, AI-списъкът с решения трябва да бъде постоянна част от този дневен ред, а не отделна сесия. Ако вече съществува одиторска пътека за финансови решения, логиката на тази пътека — кой подписва, кой проверява, къде се съхранява — трябва да се преизползва за AI-решенията. Затова и вграждането в съществуващата рискова структура е отделна тема: списък с решения, който не се вписва в начина, по който риска вече се обсъжда на друго място, остава изолиран документ, който никой не отваря.

Връзката с отчитане и ескалация

Списъкът с решения не функционира сам по себе си. Той захранва отчета, от който съветът на директорите има нужда, за да може да заяви, че има поглед върху AI-риска, и предполага наличието на път за случаите, когато решение вече не е издържимо. Без отчет за съвета от една страница, който обобщава списъка с решения, информацията изчезва в архив, който никой не прелиства. Без ескалационни пътища, които работят, решение, което е остаряло, просто остава в сила, защото никой не знае при кого да го повдигне.

Трите се допълват: списъкът с решения фиксира какво е било решено, отчетът прави това видимо на нивото, където има значение, а ескалацията гарантира, че решение може да бъде преразгледано, ако ситуацията се промени. Изградиш ли едно без другите две, се получава привидна прегледност, която при първата проверка — инцидент, въпрос от регулаторен орган, журналист — се оказва, че не покрива това, което действително се случва.

Кой попълва списъка

Списък с решения е толкова добър, колкото информацията, която влиза в него. Ако никой не знае кои AI-системи реално са в употреба — включително онези, придобити или създадени извън ИТ отдела — списъкът регистрира само решения относно видимите, формално одобрени приложения. Останалото остава нерешено, не защото не е било необходимо решение, а защото никой не е знаел, че има нещо, за което да се взима решение. Затова инвентаризацията винаги предхожда списъка с решения, а не идва след него. Какво трябва да знае за това ръководителят, е описано в какво трябва да знае ръководителят за AI-риска; какво трябва да разпознае ИТ директорът в тази инвентаризация, е описано в какво трябва да знае ИТ директорът за AI-риска.

Какво е сигурно и какво зависи от организацията

Сигурно е следното: списък с решения, който не е вграден в съществуващо съвещание, не се поддържа, а списък с решения без пълна представа за това, какво реално работи, регистрира само част от действителността. От организацията зависи: кое съвещание е подходящата опорна точка, колко често се събира то и кой има правомощието да взима решение, което влиза в списъка. Това се различава по сектор, по управленска структура и по рискова култура, и затова няма фиксиран шаблон, който работи навсякъде без адаптация.

Responsible AI Scan е в процес на разработка. Който в момента има нужда от списък с решения, вграден в съществуващата структура, може да се запише в списъка на чакащите; все още не се предлага нещо, което още не съществува.