AI агенти във финансовия комплайанс: къде автоматизацията е допустима

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

Разликата между полезен и опасен подход не е в модела. Тя е в това дали системата предлага, или решава, и дали може да се възстанови защо е направила каквото е направила.

Внедряването изпреварва разговора за управлението

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

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

Кои процеси са добри първи кандидати

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

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

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

Ограниченото правомощие е проектното решение

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

Разумното правило за повечето организации е асиметрия. Автоматизацията може да ускорява движението към човешки преглед, но не и да изключва случай от него. Ескалацията може да е автоматична; прекратяването — не.

Доказателството трябва да е възстановимо, а не просто записано

Лог, който съдържа изхода на модела, не е доказателство за решение. Възстановимият запис показва кои данни са били използвани, коя версия на модела и на правилата е била действаща, какво е предложила системата, какво е решил човекът и на какво основание. Ако тези елементи се извличат впоследствие чрез тълкуване на логове, те са реконструкция.

Задълженията по Регламент (ЕС) 2024/1624 и по националния Закон за мерките срещу изпирането на пари са към организацията, а не към инструмента. Същото важи и за изискванията, произтичащи от Директива (ЕС) 2015/849 в частта за документиране и съхранение.

Кой преглежда изхода има значение колкото самият изход

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

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

Проследявайте и дела на промените. Ако прегледът почти никога не променя нищо, това не доказва качество на системата — по-вероятно означава, че прегледът се е превърнал във формалност.

Контролът върху промяната на модела е този, който най-често липсва

Моделите се променят — при обновяване от доставчика, при преобучение, при промяна на параметри. Промяна, която подобрява средното представяне, може да влоши представянето при малка категория случаи, а именно тя обикновено е рисковата. Без оценъчен набор, пуснат при всяка промяна, влошаването се открива при проверка, а не при въвеждането.

Определете предварително кой одобрява промяна, какъв резултат я блокира и как се връща предишната версия. Функциите Govern, Map, Measure и Manage на NIST AI Risk Management Framework и системата за управление по ISO/IEC 42001 дават готова структура за това, без да се изгражда собствена терминология.

Фалшивите положителни имат цена, но фалшивите отрицателни имат последици

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

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

Формулирайте и кой има право да променя прага. Настройка, която може да бъде направена от техническия екип без участие на функцията, отговорна за резултата, е контролна слабост независимо от това колко добре е документирана промяната.

Рискът от доставчици вече е по-голямата част от риска

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

За доставчиците на платежни услуги надзорът се упражнява от Българската народна банка по реда на Закона за платежните услуги и платежните системи. Възлагането на дейност навън не прехвърля отговорността за нея.

Управлението е част от продукта

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

Когато приложението попада в обхвата на Законодателния акт за изкуствения интелект, изискванията за човешки надзор и за водене на записи също се реализират най-надеждно в продукта. Обработването на лични данни остава изцяло в обхвата на Общия регламент относно защитата на данните и на насоките на Европейския комитет по защита на данните.

Какво този подход не може да направи

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

Ако автоматизирате комплайанс процес и искате контролите да са част от системата, а не документ до нея, започнете с вграждане на управлението в работния процес.

Тази публикация е адаптирана от английския оригинал. При различие английската версия е меродавна.