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