Поштовхом до цієї статті стала нещодавня публікація Тома Маклеода (Tom McLeod), присвячена моделям штучного інтелекту з відкритими вагами (open-weight models) та новим завданням, які їх поширення створює для внутрішнього аудиту. Том звертає увагу на важливу зміну: значна частина корпоративного управління ШІ досі будувалася навколо моделі, за якої основний технологічний продукт контролює зовнішній постачальник — він розробляє базову модель, керує її оновленнями, підтримує інфраструктуру та значною мірою відповідає за безпеку й захисні механізми. Коли ж організація отримує модель з відкритими вагами, вона може розгорнути її у власній інфраструктурі, донавчити на власних даних, змінити конфігурацію, доповнити іншими компонентами та інтегрувати у свої системи або автономні агенти, а разом із новими можливостями отримує значно більшу частину відповідальності за те, якою ця модель стане після таких змін.

Для ризик-менеджера тут виникає питання, яке виходить далеко за межі технологічної дискусії про переваги та недоліки відкритих моделей. Організація могла провести оцінювання ризиків, тестування, перевірку безпеки, погодити сферу використання моделі, визначити необхідні контролі й після цього дозволити її застосування, однак через кілька місяців модель могла бути донавчена на нових даних, отримати доступ до інших інформаційних ресурсів, нові функції або повноваження, стати частиною агента, здатного не лише формувати рекомендації, а й виконувати певні дії. Формально компанія продовжує використовувати ту саму модель, проте з погляду ризику об’єкт, який колись оцінювали та схвалювали, вже міг суттєво змінитися.

Це змушує дещо інакше подивитися на поширену логіку корпоративного управління ШІ, у якій багато уваги приділяється первинному оцінюванню моделі перед її впровадженням. Питання «Чи достатньо безпечною є ця модель, щоб дозволити її використання?» залишається необхідним, але вже не є достатнім, тому що після схвалення починається життєвий цикл моделі, протягом якого змінюватися можуть не лише її версія чи технічні параметри, а й дані, середовище, сфера застосування, рівень автономності та потенційні наслідки помилки. Отже, для системи управління ризиками важливо контролювати не лише що було схвалено, а й чи залишається схвалений об’єкт тим самим об’єктом ризику, щодо якого колись приймалося рішення.

Схвалення моделі — це не безстроковий дозвіл

Будь-яке рішення про допустимість використання ШІ фактично ґрунтується на певному наборі припущень та умов, навіть якщо організація не завжди формулює їх у такому вигляді. Ми оцінюємо конкретну модель або її версію, розглядаємо певну сферу застосування, виходимо з визначених джерел даних, способу взаємодії з іншими системами, наявних захисних механізмів, ролі людини у перевірці результату та можливих наслідків помилки, після чого робимо висновок, що за таких умов ризик є прийнятним або може бути прийнятий після запровадження додаткових контролів. Тому схвалення ШІ логічніше розглядати не як безстрокову характеристику моделі — «ця модель дозволена», — а як управлінське рішення, чинність якого залежить від збереження умов, за яких воно було прийняте.

Уявімо відносно простий приклад. Страхова компанія впроваджує модель ШІ для аналізу матеріалів страхової справи та підготовки рекомендації працівнику врегулювання, причому модель не приймає рішення самостійно, не здійснює виплату, працює лише з визначеним набором даних, а її висновок обов’язково перевіряє фахівець. Після оцінювання ризиків, тестування та встановлення контролів компанія погоджує таке використання, але через пів року модель донавчають на внутрішній історії збитків, підключають до додаткових джерел інформації, дозволяють автоматично формувати частину документів, а для невеликих стандартних виплат поступово скорочують обсяг людської перевірки. Кожна окрема зміна може виглядати як природне вдосконалення вже схваленого рішення, однак у певний момент сукупність цих змін означатиме, що початкове оцінювання вже не повністю описує фактичну експозицію: змінилися дані, функціональність, залежності, роль людини та потенційні наслідки помилки.

Особливо виразною ця проблема стає у випадку моделей з відкритими вагами, про які пише Том Маклеод, оскільки можливість модифікувати модель усередині організації змінює й традиційну межу відповідальності між постачальником технології та її користувачем. Якщо у випадку закритої зовнішньої моделі компанія значною мірою залежить від того, які зміни вносить провайдер, то тепер джерелом суттєвої зміни може стати сама організація: її розробники можуть донавчити модель, підключити нові компоненти, змінити налаштування або спосіб використання, причому кожна така дія необов’язково виглядатиме як впровадження «нового ШІ». Для системи управління ризиками це принципова відмінність, адже контроль має охоплювати вже не лише вибір та первинне схвалення технології, а й подальшу історію її трансформації.

Звідси випливає важливий практичний висновок: схвалення моделі повинно мати не лише предмет, а й межі чинності. Компанії потрібно розуміти, які зміни не впливають суттєво на попередню оцінку, які потребують додаткового тестування, а які настільки змінюють ризиковий профіль, що мають запускати повторне оцінювання та нове управлінське рішення, інакше легко виникає парадоксальна ситуація, коли організація має формально схвалену модель, усі необхідні записи про проведене оцінювання та належно оформлене рішення про її використання, але фактично експлуатує систему, яку в її поточному вигляді ніхто ніколи не оцінював.

Тому наступне питання вже значно практичніше: які зміни мають значення для ризик-менеджера і де проходить межа між звичайним розвитком моделі та зміною, після якої попереднє схвалення більше не може вважатися достатнім?

Що змінює ризиковий профіль моделі

Найпростіше було б скласти перелік технічних змін, після яких модель необхідно оцінювати повторно, однак для ризик-менеджменту такий підхід навряд чи буде достатнім, оскільки значення має не стільки факт зміни технології, скільки те, що ця зміна означає для характеру та масштабу ризику. Донавчання на нових даних може вплинути на поведінку моделі, підключення нового джерела інформації — створити додаткові ризики конфіденційності або якості даних, інтеграція з іншою системою — сформувати залежність, якої раніше не існувало, а надання моделі можливості самостійно виконувати певні операції — принципово змінити потенційні наслідки її помилки. При цьому назва моделі може залишатися незмінною, користувачі продовжуватимуть сприймати її як знайомий інструмент, а в реєстрі корпоративних систем вона все ще може значитися тим самим рішенням, яке було погоджено кілька місяців тому.

Тому для ризик-менеджера важливо дивитися не лише на те, чи змінилася модель, а й на те, чи змінилися умови, на яких ґрунтувалося рішення про прийнятність її ризику. Якщо модель використовувалася для підготовки рекомендацій, а тепер отримала право самостійно виконувати операції, змінився рівень автономності; якщо вона працювала з внутрішніми даними одного процесу, а тепер отримала доступ до кількох корпоративних баз, змінилася інформаційна експозиція; якщо її результати перевірялися людиною перед кожною дією, а тепер контроль здійснюється вибірково, змінився контрольний механізм; якщо система використовувалася у допоміжному процесі, а потім була перенесена до процесу, помилка в якому здатна спричинити значні фінансові, правові або репутаційні наслідки, змінився потенційний вплив. У кожному випадку технічна зміна може бути невеликою, але управлінське значення — суттєвим.

Це дозволяє сформулювати простий принцип: тригером повторного оцінювання повинна бути не будь-яка зміна ШІ, а зміна, здатна суттєво вплинути на припущення, ризики або контролі, на яких ґрунтувалося попереднє рішення. Такий підхід важливий і з практичної точки зору, оскільки вимога проводити повне оцінювання після кожного технічного оновлення швидко перетворила б управління ШІ на бюрократичний бар’єр, тоді як відсутність визначених тригерів створює протилежну небезпеку — модель може змінюватися поступово, і жодна окрема зміна не виглядатиме критичною, хоча через певний час організація фактично матиме зовсім інший ризиковий профіль.

Не постійна переоцінка, а система тригерів

Практичне завдання полягає, отже, не в тому, щоб після кожної зміни повертати модель на початок процедури погодження, а в тому, щоб заздалегідь визначити межі дозволених змін і події, після яких попереднє рішення має бути переглянуте. Частина змін може здійснюватися в межах уже погодженої конфігурації без додаткового втручання функцій контролю, інші можуть вимагати обмеженого тестування або документованої перевірки, а найбільш суттєві — нового оцінювання ризиків і повторного управлінського рішення. До останньої категорії можуть належати суттєва зміна даних для донавчання, розширення сфери використання, підключення нових критичних джерел інформації, збільшення автономності, зміна людського контролю, надання моделі можливості виконувати дії із фінансовими чи юридичними наслідками або виявлення нової поведінки, яка ставить під сумнів припущення попереднього оцінювання.

Але наявність переліку тригерів вирішує лише половину проблеми. Потрібно також заздалегідь відповісти, хто має право змінювати модель, хто визначає суттєвість зміни, хто проводить необхідне тестування, хто приймає рішення про продовження використання і хто може його призупинити, якщо ризиковий профіль вийшов за погоджені межі, інакше компанія може мати чудову політику управління ШІ, але між двома формальними оцінюваннями модель змінюватимуть різні команди, кожна з яких бачитиме лише свою частину технологічного процесу, тоді як ніхто не відповідатиме за сукупний вплив цих змін на ризик. У цьому сенсі проблема моделей з відкритими вагами, на яку звертає увагу Том Маклеод, є частиною значно ширшого питання корпоративного управління: чим більше контролю над технологією переходить від зовнішнього постачальника до самої організації, тим більше всередині організації має бути визначено не лише технічних можливостей, а й відповідальності, повноважень та контрольних меж.

Для ризик-менеджменту це означає перехід від одноразового погодження до управління життєвим циклом ризику. Первинна оцінка залишається необхідною, але після неї повинна існувати логіка, яка пов’язує зміну моделі або умов її використання з відповідною управлінською реакцією: зміна → оцінка її суттєвості → тригер → перевірка → рішення → подальший моніторинг, причому чим більшу автономність отримує система і чим серйознішими можуть бути наслідки її помилки, тим менш прийнятною стає ситуація, коли організація просто фіксує зміни постфактум і сподівається виявити проблему під час наступного планового аудиту.

Замість висновку: що ми насправді схвалюємо

Можливо, головна зміна, яку приносить поширення таких технологій, полягає навіть не в появі нового виду ШІ, а в необхідності переглянути традиційне уявлення про об’єкт управління ризиком. Компанія схвалює не просто назву моделі або технологічний продукт, а певну конфігурацію моделі, даних, сфери застосування, повноважень, контролів та людської участі, і рішення про прийнятність ризику залишається обґрунтованим доти, доки суттєві припущення, на яких воно базувалося, залишаються чинними. Це правило добре знайоме ризик-менеджменту й поза сферою ШІ: прийняття ризику ніколи не повинно означати, що організація погодилася з ним назавжди незалежно від подальшої зміни обставин.

Моделі з відкритими вагами лише роблять цю проблему особливо помітною, тому що організація отримує можливість значно глибше змінювати технологію, яку використовує, а разом із цією свободою отримує відповідальність за розуміння наслідків власних змін, тому запитання внутрішнього аудиту, яке ставить Том Маклеод, — чи знаємо ми, які моделі реально працюють усередині організації, хто їх змінив і чи можемо ми їм досі довіряти, — для ризик-менеджера можна продовжити ще одним: чи знаємо ми, в який момент зміна стала достатньо суттєвою, щоб попереднє рішення про прийнятність ризику перестало бути достатнім?

І, можливо, через деякий час питання «Чи схвалили ми цю модель?» взагалі здаватиметься надто простим, а значно важливішим буде інше: «Чи залишається це тією моделлю, яку ми схвалювали?»

Докладніше за посиланням

Сергій БАБИЧ