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