Ера Альтрона в GMP: вимоги до штучного інтелекту

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

Цей документ є доповненням до Annex 11 і охоплює моделі машинного навчання, які отримали свою функціональність шляхом навчання на даних, а не прямим програмуванням. Такі моделі можуть складатися з кількох окремих елементів, кожен з яких автоматизує певний етап процесу.

📌 Обмеження:

Документ охоплює статичні моделі, які не змінюють свою поведінку під час використання.
Динамічні моделі, які навчаються автоматично під час експлуатації, не охоплюються і не мають застосовуватись у критичних GMP-процесах.
Також не охоплюються моделі з імовірнісним виходом, тобто ті, що при однаковому вводі можуть давати різні результати.
Генеративний ШІ та великі мовні моделі (LLM) не мають застосовуватись у критичних GMP-процесах.

🔸 У некритичних випадках, коли безпека пацієнта, якість продукції та цілісність даних не порушуються, відповідальний персонал повинен контролювати правильність використання таких моделей, із забезпеченням участі людини (human-in-the-loop).

2.1. Персонал

Для належного розуміння цільового призначення моделі ШІ та пов’язаних із цим ризиків у GMP-середовищі має бути тісна співпраця між усіма залученими сторонами під час вибору алгоритму, навчання, валідації, тестування та експлуатації моделі.
До таких сторін можуть належати:

фахівці з процесів (SME),
відділ якості (QA),
дата-сайєнтисти,
ІТ-фахівці,
консультанти тощо.

Усі залучені особи повинні мати належну кваліфікацію, чітко визначені обов’язки та відповідний рівень доступу.

2.2. Документація

Уся діяльність, описана в цьому розділі, має бути належним чином задокументована та перевірена регульованим користувачем — незалежно від того, чи модель була навчена, протестована та валідувана всередині компанії, чи надана постачальником або зовнішнім провайдером послуг.

2.3. Управління ризиками якості

Усі дії, описані в цьому документі, мають впроваджуватися з урахуванням рівня ризику для:

безпеки пацієнта,
якості продукції,
цілісності даних.

3.1. Призначення використання

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

У цьому описі має бути:

всебічна характеристика вхідних даних, які модель буде використовувати, включно з типовими та рідкісними варіаціями (тобто — простір вхідних даних),
виявлені обмеження моделі, а також потенційно помилкові або упереджені вхідні дані.

За достатність та точність цього опису несе відповідальність експерт з процесу (SME). Документ має бути затверджений до початку приймального тестування моделі.

3.2. Підгрупи

За можливості простір вхідних даних слід розділити на підгрупи за релевантними характеристиками. Підгрупи можуть визначатися:

за типом очікуваного рішення (наприклад, «прийняти» або «відхилити»),
за базовими особливостями процесу (наприклад, географічне розташування або обладнання),
за характеристиками матеріалів чи продуктів,
за специфікою автоматизованого завдання (наприклад, типи та серйозність дефектів).

3.3. Людина в контурі прийняття рішень (Human-in-the-loop)

Якщо модель використовується для надання даних або висновків, які потім оцінює людина, і при цьому обсяг тестування моделі зменшено, то опис призначення використання повинен чітко визначати відповідальність оператора.

У такому випадку:

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

4.1. Метрики тестування

Необхідно визначити відповідні метрики тестування, залежно від конкретного випадку використання моделі, щоб оцінити її ефективність згідно з цільовим призначенням.

Наприклад, для моделі, що класифікує продукцію (типу «прийняти» або «відхилити»), до таких метрик можуть належати:

матриця помилок (confusion matrix),
чутливість (sensitivity),
специфічність (specificity),
точність (accuracy),
прецизійність (precision),
або F1-оцінка (F1 score).

4.2. Критерії приймання

На основі обраних метрик слід встановити чіткі критерії приймання, за якими буде оцінюватися, чи придатна модель до використання за призначенням.

Ці критерії можуть відрізнятися для різних підгруп в межах однієї області використання.
Визначенням таких критеріїв повинен займатись експерт з процесу (SME).
Критерії мають бути документовані та затверджені до початку приймального тестування.

4.3. Не гірше, ніж існуючий процес

Продуктивність моделі не повинна бути нижчою, ніж ефективність процесу, який вона замінює.

Це означає, що:

має бути відомий рівень ефективності чинного процесу,
з яким порівнюється модель
(посилання: Annex 11, пункт 2.7).

5.1. Вибір даних

Тестові дані повинні репрезентативно охоплювати весь простір вхідних даних, передбачений для моделі.

Дані мають бути стратифіковані, включати всі підгрупи,
Відображати обмеження, складність, а також типові та рідкісні варіації у межах призначеного використання.
Критерії та обґрунтування вибору тестових даних повинні бути задокументовані.

5.2. Достатній обсяг

Тестовий набір даних (і кожна його підгрупа) повинен мати достатній розмір, щоби:

забезпечити обчислення тестових метрик із належною статистичною достовірністю.

5.3. Маркування даних

Маркування (labeling) тестових даних повинно проходити перевірку через процес, що забезпечує високу точність. Це може включати:

незалежну перевірку кількома експертами,
використання валіданого обладнання або лабораторних тестів.

5.4. Попередня обробка

Будь-яка попередня обробка тестових даних (наприклад, трансформація, нормалізація, стандартизація) повинна бути:

заздалегідь визначена (pre-specified),
з обґрунтуванням того, що вона відповідає умовам реального використання моделі.

5.5. Вилучення даних

Усі випадки очищення або виключення тестових даних мають бути:

задокументовані,
повністю обґрунтовані.

5.6. Генерація даних

Генерація тестових даних або міток за допомогою генеративного ШІ (наприклад, LLM, AI-моделей) не рекомендується. Якщо така генерація все ж застосовується, її:

необхідно повністю обґрунтувати.

6.1. Незалежність

Потрібно впровадити технічні та/або процедурні заходи, які забезпечать незалежність тестових даних, тобто гарантію того, що дані, які використовуються для тестування моделі:

не використовувались під час її розробки, навчання чи валідації.

Цього можна досягти:

або шляхом збору тестових даних після завершення навчання та валідації,
або шляхом відділення тестових даних до початку навчання моделі.

6.2. Розподіл даних

Якщо тестові дані відокремлюються з повного набору даних до навчання моделі, співробітники, які беруть участь у розробці та навчанні, не повинні мати доступу до тестових даних.

Необхідно забезпечити:

контроль доступу до тестових даних,
журнал аудиту (audit trail) з фіксацією доступів і змін,
відсутність копій тестових даних поза захищеним сховищем.

6.3. Ідентифікація даних

Необхідно фіксувати:

які саме дані були використані для тестування,
коли та скільки разів вони використовувались.

6.4. Фізичні об'єкти

Якщо тестові дані отримані з фізичних об’єктів, слід переконатися, що:

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

6.5. Незалежність персоналу

Потрібно впровадити ефективні технічні та/або процедурні заходи, які:

перешкоджають участі одного і того ж працівника у тестуванні та одночасно в навчанні/валідації тієї ж моделі, якщо він мав доступ до тестових даних.

У випадку, якщо повна незалежність неможлива (наприклад, у невеликій організації), допустимий варіант:

робота в парі (принцип "4 очей") — співробітник, який мав доступ до тестових даних, може працювати з моделлю лише спільно з тим, хто такого доступу не мав.

7.1. Придатність до використання

Тест має підтвердити, що модель є придатною для заявленого призначення та добре узагальнює, тобто демонструє задовільну ефективність на нових даних, що відповідають сферам використання моделі.
Тест також повинен виявляти можливі випадки переобучення (overfitting) або недонавчання (underfitting) моделі на тренувальних даних.

7.2. План тестування

Перед початком тестування має бути розроблений і затверджений план тестування, який повинен містити:

короткий опис призначення використання моделі,
визначені метрики та критерії приймання,
посилання на тестові дані,
тестовий сценарій із детальним описом всіх кроків тестування,
опис способу розрахунку метрик.

У розробці плану повинен брати участь експерт з процесу (SME).

7.3. Відхилення

Будь-які відхилення від плану тестування, невідповідність критеріям приймання або неповне використання тестових даних повинні бути:

задокументовані,
розслідувані,
та повністю обґрунтовані.

7.4. Документування тестування

Вся документація по тестуванню має зберігатися разом з:

описом призначення використання моделі,
характеристиками тестових даних,
самими тестовими даними,
за необхідності — фізичними об’єктами для тестування.

Також слід зберігати документацію щодо контролю доступу до тестових даних та записи аудиту (audit trail), подібно до інших GMP-документів.

8.1. Визначення впливу ознак

Під час тестування моделей, що використовуються у критичних GMP-застосуваннях, системи повинні фіксувати та зберігати інформацію про ті ознаки тестових даних, які вплинули на конкретну класифікацію або рішення (наприклад, відхилення продукту).

За можливості слід застосовувати методи, такі як:

feature attribution (присвоєння впливу ознакам), наприклад, SHAP-значення чи LIME,
візуальні інструменти, такі як теплові карти (heat maps), які допомагають виділити ключові фактори, що вплинули на результат.

8.2. Обґрунтування ознак

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

9.1. Оцінка впевненості

Під час тестування моделі, що використовується для прогнозування або класифікації даних, система повинна, за можливості, фіксувати оцінку впевненості (confidence score) моделі для кожного прогнозу або результату класифікації.

9.2. Поріг прийняття рішення

Моделі для прогнозування або класифікації повинні мати належно встановлений поріг (threshold), щоб забезпечити, що рішення приймаються лише при достатньому рівні впевненості.

Якщо оцінка впевненості дуже низька, слід розглянути можливість позначення результату як «невизначений» (undecided), а не видавати потенційно ненадійні прогнози чи класифікації.

10.1. Контроль змін

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

задокументовані,
оцінені на предмет необхідності повторного тестування моделі.

Рішення про відсутність повторного тестування повинно бути повністю обґрунтованим.

10.2. Контроль конфігурації

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

10.3. Моніторинг продуктивності системи

Продуктивність моделі відповідно до визначених метрик має регулярно моніторитись, щоб виявити будь-які зміни в комп’ютеризованій системі (наприклад, погіршення умов освітлення).

10.4. Моніторинг простору вхідних даних

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

10.5. Перевірка людиною

Якщо модель використовується для надання даних, на основі яких приймається рішення людиною (human-in-the-loop), і при цьому обсяг тестування моделі зменшено, необхідно вести реєстри цього процесу.

Залежно від критичності процесу та рівня тестування моделі це може означати:

постійний огляд і/або тестування кожного виходу моделі згідно з процедурою.

Автор статті Сергій Чижов