Як створювати етичний AI, який допомагає лікарям, а не замінює їх

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Мене звати Олег, засновник ментал-хелс стартапу Auri, науковий дослідник у НТУУ «КПІ ім. Ігоря Сікорського» та інженер у сфері MedTech. У роботі з медичними продуктами моє завдання — проектувати та впроваджувати рішення на основі ШІ, які зменшують навантаження на лікаря, але не замінюють його. У цій статті системно опишу підхід, який на практиці виявився робочим: вузько доменні моделі, навчання на наукових джерелах, мікросервісна архітектура з human-in-the-loop, ізоляція AI-модуля та строгий аудит подій (Kafka).

У багатьох стартапах повторюється одна дія: використовують LLM (OpenAI/Claude/Gemini), роблять «обгортку» навколо API і намагаються з цього скласти «AI продукт». Проблема не в API як такому, а у джерелах навчання і режимі використання: універсальні моделі навчались на широкому інтернет-контенті, що не є медичною доказовою базою. Це породжує галюцинації, неточні поради та ризики порушення HIPAA/GDPR. У медицині такий підхід неприпустимий.

Моя позиція проста: медичний ШІ потрібно будувати як систему співпраці (decision support), а не заміни, і вчити на спеціалізованих наукових даних. Будь-який результат верифікує лікар, лише після цього пацієнт щось отримує у свій застосунок чи електронну карту.

Що саме не працює з «горизонтальними» LLM

1. LLM навчаються на відкритому інтернет-контенті: форумах, блогах, Reddit, соціальних мережах, а іноді й на згенерованих даних.
   1. У медицині це означає, що модель може:
   2. узагальнювати за неперевіреними твердженнями;
   3. створювати галюцинації — упевнено писати речі, яких немає в жодних клінічних протоколах;
   4. змішувати наукові факти зі спекулятивними темами (наприклад, дієтичні тренди, «альтернативні» підходи).
2. Більшість LLM не мають механізму трасування логіки відповіді. Модель не може пояснити, які саме джерела чи ознаки вплинули на прогноз. Для лікаря це критично:
   1. якщо система пропонує змінити лікування, він повинен знати чому;
   2. якщо класифікатор підвищує ризик, лікар має бачити, які показники це спричинили;
   3. якщо модель цитує джерело — воно має бути конкретним, а не «десь з інтернету».
3. Генеративні LLM мають сильний language prior — вони оптимізовані для «мовної правдоподібності», а не для точності. У результаті вони можуть «підлаштовуватись» під контекст і створювати медичні рекомендації, які звучать переконливо, але не мають клінічного сенсу.
   1. модель «вигадала» клінічне дослідження, якого не існує;
   2. посилалась на «PubMed ID», який належить зовсім іншій темі;
   3. змішала два різних діагностичних критерії DSM та ICD.
4. LLM часто інтегрують у системи напряму через API без урахування вимог HIPAA та GDPR. Типові порушення:
   1. передача PHI (Protected Health Information) у промптах або логах;
   2. зберігання історій користувачів у незахищених кешах;
   3. неможливість гарантувати «data locality» (де фізично зберігаються дані).
5. Головна загроза «чорних ящиків» — відсутність лікаря в циклі прийняття рішень. Коли користувач (пацієнт або молодий спеціаліст) отримує результат напряму від ШІ, без перевірки людиною, — це етична і юридична проблема. Тому у своїх системах я завжди впроваджую Human-in-the-Loop Validation:
   1. кожен прогноз або care plan проходить перевірку лікарем;
   2. тільки після електронного підпису інформація переходить у пацієнтський застосунок;
   3. усі дії журналюються для аудиту.
6. Навіть якщо технічно модель точна, лікарі не довіряють «чорним ящикам». Щоб інтегрувати AI у клінічний процес, потрібна:
   1. пояснюваність (що, чому, з якого джерела);
   2. контроль доступу до даних;
   3. чіткий ланцюг відповідальності (AI → Validation → Doctor).

Тому я раджу використовати SLM (small/subject-limited models), які навчаються на верифікованих джерелах (клінічні протоколи, наукові публікації, валідовані опитувальники).

Архітектурний підхід: human-in-the-loop як обов’язковий рівень

Ключове рішення — додати контрольний рівень між алгоритмом і користувачем. Алгоритм (класифікатор/генератор) працює, але результат бачить спочатку лікар у професійному інтерфейсі: перевіряє, коригує, підписує КЕП/ЕЦП. Тільки після цього результат стає офіційною рекомендацією чи записом в EHR/EMR.

Окремі моменти, які обов’язково потрібно врахувати:

• AI у виділеному модулі без прямого доступу до персональних ідентифікаторів.
• Жодних рішень напряму пацієнту без підпису лікаря.
• Explainability: лікар бачить «чому» (ключові фічі/параграфи, посилання на джерела).
• Аудит: кожна дія (хто згенерував/переглянув/підписав) логуються незмінно.

Чому Kafka стала «шиною подій», а не HTTPS/gRPC або RabbitMQ

Ми випробували різні підходи. Для медичних ML-процесів, де є важкі обчислення і потрібна історія подій, Kafka виявилась найкращим варіантом:

• Спочатку відмовились від синхронної HTTPS/gRPC коммунікації: важкі задачі блокують ланцюжок, масштабування стає складним.
• RabbitMQ не підійшов через короткочасність зберігання повідомлень і менш зручний стрімінг подій.
• Kafka забезпечує event streaming + довготривале зберігання, що критично для аудиту (HIPAA) та відтворюваності.

Також варто Безпека даних у Kafka — окрема тема. Те, що працює на практиці:

• Data masking/tokenization перед публікацією:
  • замість patient_id використовуємо patient_ref (токен), діагнози — у стандартизованих кодах (ICD/DSM/SNOMED).

{
  "event_id": "evt-2025-10-26-001",
  "patient_ref": "TOKEN-abc123",
  "signal_type": "hrv",
  "window_id": "w-5678",
  "features": {"rmssd": 28.4, "sdnn": 31.2},
  "classifier_version": "mhx-1.3.2",
  "risk_score": 0.74,
  "guideline_refs": ["DSM-5-TR", "WHO-ICD-10-B20"],
  "timestamp_utc": "2025-10-26T11:05:00Z"
}

• Схемна валідація: JSON Schema / Schema Registry з політиками, що відсікають PHI у «небезпечні» топіки.
• Аудит-логи Kafka (kafka.authorizer.logger): фіксувати client_id/principal, топіки, timestamp, IP/hostname; стрімити в SIEM (Splunk/Elastic/Datadog).
• Encryption at rest + secrets у Vault/DynamoDB для мапінгів токенів.
  • В архітектурі, де використовується tokenization замість прямих patient_id, важливо не лише змінити ідентифікатор, а надійно зберігати зв’язок між токеном і реальною сутністю пацієнта. Цей мапінг — найчутливіше місце системи.
  • Замість того, щоб зберігати ключі в конфігах або Docker secrets варто використовувати тимчасові секрети в сервісах HashiCorp Vault або AWS Secrets Manager

Навчання моделей: лише верифіковані джерела та вузький домен

Щодо класифікаторів (наприклад, ментальних розладів) — публічних якісних датасетів мало, тому я комбіную підходи:

1. Гейміфікація збору даних у користувацькому застосунку (за згодою): структуровані опитувальники, пасивні метрики, сигнали.
2. Псевдонімізація і анонімізація перед будь-яким зберіганням/передачею.
3. Для генеративних підказок/планів — навчання SLM на наукових публікаціях та протоколах лікування, визнаних спеціалізованими органами. Жодних «вільних» інтернет-джерел для медичних тверджень.

Ключовий принцип: SLM обмежений тематикою (ментальне здоров’я/конкретні протоколи) і повертає результати з посиланнями на джерела. Модель не «фантазує» поза доменом.

Процес взаємодії: від прогнозу до підписаної рекомендації

1. AI-модуль отримує нормалізовані дані (без PHI), формує risk score / draft care plan.
2. Validation Layer додає пояснення (основні фічі, уривки з джерел), проганяє compliance-правила (HIPAA/GDPR/FHIR).
3. Doctor UI отримує сповіщення, відкриває кейс: перегляд → правка → електронний підпис.
4. Patient App отримує результат тільки після підпису.
5. Усі кроки логуються в Kafka → SIEM, аудит відтворюється.

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

Практичні спостереження з R&D

• Найбільше збоїв не в моделях, а у відсутності людського фільтра та слабкому аудиті.
• Перехід із HTTPS/gRPC на Kafka прибрав блокування та дав можливість трасування подій.
• Schema Registry + політики публікації ефективно зупиняють випадкові витоки PHI.
• Для генеративних підказок SLM > LLM у медицині: менше «галюцинацій», легше забезпечити explainability та доменну дисципліну.
• eSignature критичний: і для юридичного статусу, і для внутрішньої дисципліни процесу.

Що рекомендую командам, які стартують у MedTech AI

1. Використовуйте SLM і верифіковані джерела. Не покладайтеся на «горизонтальні» LLM у клінічних твердженнях.
2. Ізолюйте AI-модуль. Забороніть доступ до PHI; працюйте з токенами/рефами.
3. Human-in-the-loop by design. Жодного прямого результату пацієнту без підпису лікаря.
4. Події через Kafka. Повна історія, аудит, відтворюваність; централізований моніторинг у SIEM.
5. Schema Registry + політики. Валідуйте схеми і блокуйте потрапляння PHI у «небезпеку».
6. Explainability. Лікар повинен бачити «чому» — фічі, джерела, дати протоколів.
7. Compliance як код. HIPAA/GDPR/FHIR — правила на яких потрібно будувати систему ще до початку розробки.

Висновок

Етичний медичний ШІ — це не про заборони, а про архітектуру процесів. «Не нашкодь» сьогодні не лише девіз лікарів, а й задача сучасних ШІ рішень для медицини. Коли дані захищені, моделі вузькодоменні, рішення проходять людську верифікацію з електронним підписом, а вся система подій — трасована, тоді ШІ реально допомагає лікарю і не шкодить пацієнту. Саме так його і треба будувати.