Тема 8.4 — Управление ИИ и новыми технологиями

В одном предложении: Искусственный интеллект в здравоохранении и уходе — обучающаяся, зависимая от данных и часто непрозрачная технология, способная масштабировать и пользу, и вред быстрее любой системы, которой вы когда-либо управляли, поэтому вы должны управлять ею как вопросом клинической безопасности, равенства и общественного доверия на протяжении всего жизненного цикла, а не считать обычным ПО, которое покупают один раз и забывают.

Почему это важно в здравоохранении и уходе#

Большая часть программного обеспечения, которое вы развернули, завтра ведёт себя так же, как сегодня: его логика записана, поведение проверяемо, а когда оно ошибается, ошибка обычно видимая и повторяемая. Искусственный интеллект разрушает все три этих удобства. Он учится статистическим закономерностям на данных, а не следует правилам, написанным человеком; его поведение целиком зависит от данных, на которых он обучен, и данных, которые он встречает сейчас; а его рассуждение часто непрозрачно даже для тех, кто его построил. Это сочетание — причина, по которой ИИ нужна собственная дисциплина управления, а не включение в общий контрольный список ПО.

В здравоохранении и уходе последствия не абстрактны. Модель, недовыявляющая болезнь в группе, недопредставленной в её обучающих данных, делает не единичную ошибку: она делает одну и ту же ошибку, молча, тысячи раз, закрепляя и масштабируя неравенство в здоровье. Генеративная модель, выдумывающая правдоподобно звучащую клиническую деталь, может ввести в заблуждение перегруженного клинициста ровно в неподходящий момент. Инструмент, прекрасно работающий на популяции, на которой был проверен, может тихо деградировать, когда меняются популяция, путь ухода или вышестоящие данные. ИИ может масштабировать хорошие решения и с равной эффективностью масштабировать предвзятость, ошибку и вред.

Эта тема — об управлении этим риском без вдыхания шумихи и без запрета технологии. Она намеренно не повторяет основы, заложенные в других местах: клиническую безопасность (см. тему 1.6 — Клиническая безопасность и управление рисками), управление информацией, защиту данных и кибербезопасность (см. тему 1.7 — Управление информацией, защита данных и кибербезопасность) и принятие решений на основе доказательств (см. тему 1.3 — Решения, основанные на доказательствах). Она опирается на них и добавляет то, что специфично для обучающихся систем. Рассматривайте её как ИИ-форму расширения вашей существующей гарантийной работы и как управляемого брата поэтапного внедрения инноваций (см. тему 8.0 — Поэтапное внедрение инноваций).

Ключевые понятия#

Искусственный интеллект и машинное обучение. Для руководителя практическое различие таково: большая часть ИИ в здравоохранении и уходе сегодня — машинное обучение: системы, выводящие закономерности из примеров, а не исполняющие написанные вручную правила. Поэтому данные — такой же продукт, как код: измените обучающие данные — и вы измените поведение. Это также означает, что модель ничего не «знает»; она оценивает и может быть уверенно неправа. Понимания этого на концептуальном уровне достаточно, чтобы задавать верные вопросы управления; читать математику не нужно.

Программное обеспечение как медицинское изделие (SaMD) и MHRA. Когда у ПО медицинская цель — диагностика, скрининг, триаж, расчёт дозы, предсказание ухудшения, — оно очень часто является медицинским изделием по закону, независимо от того, работает ли на телефоне или сервере. Медицинское ПО такого рода, известное как программное обеспечение как медицинское изделие (SaMD), регулируется в Соединённом Королевстве Medicines and Healthcare products Regulatory Agency (MHRA). Если вы заказываете или строите инструмент ИИ с клинической целью, первый вопрос управления — является ли он регулируемым изделием и, если да, есть ли у него действительная маркировка соответствия. Ошибка здесь — не техническая деталь; развёртывание незарегистрированного медицинского изделия незаконно и небезопасно.

AI Airlock. MHRA создала регуляторную песочницу под названием AI Airlock, чтобы проработать, как ИИ как медицинское изделие должен регулироваться в контролируемой, отслеживаемой обстановке. Регуляторная песочница позволяет регулятору и небольшому числу разработчиков изучать трудные, новые вопросы — например, как валидировать модель, обновляющуюся со временем, — под надзором, до установления общих правил. Будьте трезвы в том, что это такое: Airlock — обучающая среда для регулятора и горстки участников, а не путь ускоренного одобрения, и связь с ним не означает, что продукт одобрен для общего клинического использования.

Алгоритмическая предвзятость и справедливость. Алгоритмическая предвзятость — склонность системы производить систематически несправедливые результаты для определённых групп. В здравоохранении и уходе её самый частый источник — обучающие данные: если группа недопредставлена, неверно размечена или измерена предвзятым инструментом, модель учится служить этой группе хуже. Поскольку модель затем применяет это в масштабе и с видом объективности, предвзятый ИИ может расширить то самое неравенство, которое ваша организация законно обязана сокращать.

Объяснимость и «чёрный ящик». Объяснимый искусственный интеллект касается того, может ли человек понять, почему модель выдала данный результат. Многие высокопроизводительные модели — фактически «чёрные ящики»: точные в агрегате, но неспособные дать клиницисту достоверную причину отдельного решения. В клинической обстановке это важно для подотчётности, информированного согласия и обязанности клинициста применять суждение: врач не может осмысленно принять ответственность за совет, который не может допросить.

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

MLOps и жизненный цикл модели. MLOps — операционная дисциплина надёжного развёртывания, мониторинга, версионирования и переобучения моделей в продакшене. Это механизм, делающий управление жизненным циклом реальным: знать, какая версия модели работает, на каких данных, с какой результативностью, и уметь откатить.

Человек в контуре. Проект с человеком в контуре удерживает человека — обычно клинициста — осмысленно в решении, с полномочиями и информацией, чтобы переопределить модель. При хорошем исполнении он сохраняет подотчётность; при исполнении как штамп даёт лишь иллюзию надзора.

Генеративный ИИ и большие языковые модели. Генеративный искусственный интеллект, включая большие языковые модели (LLM), производит беглый текст и другое содержимое. Его реалистичная ближайшая ценность в здравоохранении и уходе — в основном административная: составление документации, обобщение, облегчение бумажной работы. Определяющий риск — галлюцинации: уверенная генерация ложного, но правдоподобного содержимого, усугубляемая рисками конфиденциальности, когда данные пациентов вводятся в сторонние сервисы.

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

Лучшие практики#

1. Классифицируйте инструмент, прежде чем делать что-либо ещё. Установите письменно и с клиническим и регуляторным вкладом, есть ли у ИИ медицинская цель и является ли он поэтому регулируемым медицинским изделием, и есть ли у него действительная маркировка соответствия MHRA. Это единственное определение управляет всем нижестоящим — путём гарантий, ответственностью, законностью развёртывания. При сомнении ищите регуляторный совет, а не предполагайте, что административный инструмент вне области.

2. Проводите ИИ через ваш существующий механизм клинической безопасности и управления информацией, расширенный, а не обойдённый. Каждое клиническое внедрение ИИ нуждается в управлении клиническим риском по DCB0129/DCB0160 (см. тему 1.6) и оценке влияния на защиту данных (DPIA) в рамках вашего управления информацией (см. тему 1.7). Не позволяйте новизне или энтузиазму поставщика создать параллельный, более лёгкий процесс. Специфические для ИИ опасности — предвзятость, дрейф, непрозрачность, предвзятость автоматизации — следует добавлять в журнал опасностей, а не заменять им.

3. Допрашивайте обучающие данные на репрезентативность и предвзятость. Спросите, кто в данных и кого не хватает, как размечены результаты и были ли сами измерительные инструменты предвзяты по группам. Требуйте от поставщика отчёта о результативности в разбивке по релевантным подгруппам — возраст, пол, этническая принадлежность, лишения, — а не только заголовочной точности. Инструмент, не способный продемонстрировать справедливую результативность, — риск неравенства в здоровье, как бы ни впечатляло его среднее.

4. Требуйте клинической валидации, соответствующей риску, и предпочитайте проспективные доказательства. Ретроспективная точность на отобранных данных — самая слабая форма доказательства. Для всего, влияющего на клинические решения, ищите валидацию на популяции и в процессе, подобных вашим, в идеале проспективную, и проводите заявление через соответствующую рамку гарантий — NICE Evidence Standards Framework для цифровых технологий здравоохранения и Digital Technology Assessment Criteria (DTAC) как базовый уровень гарантий. Соразмеряйте силу доказательств с величиной потенциального вреда.

5. Настаивайте на осмысленном человеке в контуре и ясной подотчётности. Определите, кто подотчётен за решение, информированное ИИ, и обеспечьте, чтобы у человека были и полномочия переопределить, и информация для этого. Активно защищайтесь от предвзятости автоматизации — склонности уступать машине — через обучение, дизайн интерфейса и аудит долей переопределения. Если переопределений никогда не бывает, ваш «человек в контуре» — декоративный.

6. Считайте запуск началом мониторинга, а не концом гарантий. Установите постмаркетинговый надзор с первого дня: отслеживайте реальную результативность, следите за дрейфом концепции и определите пороги и процесс переобучения, приостановки или отзыва модели. Установите версионирование моделей и откат через здравый MLOps, чтобы всегда знать, что работает, и безопасно возвращаться. Модель, которую никогда не перепроверяют, — медленно отказывающий контроль безопасности.

7. Управляйте генеративным ИИ по его реалистичным применениям и против его реальных рисков. Допускайте LLM там, где ценность подлинна, а риск ограничен, — административное составление, обобщение, поддержка документирования с проверкой человеком — и запрещайте неуправляемый ввод идентифицируемых данных пациентов в сторонние сервисы. Допускайте, что любой генеративный выход может быть выдуман, пока человек не проверит, и никогда не позволяйте непроверенному сгенерированному содержимому попасть в клиническую запись. Ясная, обеспечиваемая политика лучше и сплошного запрета, толкающего в теневое использование, и вседозволенности, протекающей данными.

8. Применяйте управление информацией ко всему жизненному циклу данных, включая обучение. Данные, используемые для обучения, дообучения и оценки модели, подлежат тем же обязанностям правового основания, минимизации и прозрачности, что и любое другое использование (см. тему 1.7). Будьте явны в основании для обучения на данных пациентов, достаточно ли они деидентифицированы и что поставщик может с ними делать. Контракты должны запрещать повторное использование ваших данных для обучения продуктов для других без правового основания и вашего согласия.

9. Ведите читаемый человеком реестр моделей и требуйте прозрачности от поставщиков. Поддерживайте перечень используемого ИИ: цель, регуляторный статус, происхождение обучающих данных, доказательства валидации, план мониторинга и подотчётный владелец. Требуйте от поставщиков прозрачности в том, как работает модель, её ограничениях и видах отказов; непрозрачность вендора сама по себе — сигнал риска. Нельзя управлять тем, что не записано.

10. Сканируйте горизонт осознанно и вводите поэтапно через контролируемую оценку. Помимо сегодняшнего ИИ, следите за возникающими технологиями — амбиентное документирование, базовые модели и, дальше, квантовые и новые датчики — структурированным сканированием горизонта, а не реактивными закупками. Вводите всё подлинно новое через контролируемый, обратимый, оцениваемый подход поэтапного внедрения инноваций (см. тему 8.0), начиная с малого, измеряя честно и сохраняя способность остановиться.

11. Относитесь к цифровой терапии и приложениям здоровья как к вмешательствам, а не потребительским скачиваниям. Когда приложение делает клиническое заявление — лечить, управлять или предотвращать состояние, — это вмешательство, на которое пациенты будут действовать, и оно заслуживает той же проверки, что лекарство или изделие, прежде чем вы его назначите или порекомендуете. Установите, является ли оно программным обеспечением как медицинским изделием с действительной маркировкой соответствия, требуйте доказательств, соразмерных заявлению, и завершите оценку клинической безопасности (см. тему 1.6), а не доверяйте рейтингу магазина приложений или энтузиазму поставщика. Неоценённое приложение, одобренное клиницистом, несёт имя вашей организации и вашу подотчётность, если навредит.

12. Проводите приложения здоровья через существующие гарантии и ведите курируемую, безопасную библиотеку. Оценивайте цифровую терапию тем же механизмом, что уже ведёте, — DTAC как базовый уровень, NICE Evidence Standards Framework, сопоставленная клиническому заявлению, и обзор клинической безопасности и управления информацией, — и стройте доказательства оценки в реальных условиях со временем (см. тему 8.6). Ведите курируемую библиотеку приложений, которые вы оценили и за которые отвечаете, с записанными регуляторным статусом, доказательствами и владельцем каждого, чтобы клиницисты рекомендовали из безопасного, управляемого короткого списка. Альтернатива — неконтролируемое разрастание неоценённых приложений, рекомендуемых неформально по командам, — неуправляема и небезопасна.

Вопросы для обсуждения с командой#

1. Для каждого инструмента ИИ, который мы рассматриваем или уже используем, знаем ли мы на самом деле, является ли он регулируемым медицинским изделием, и можем ли предъявить доказательства? Это звучит как формальность комплаенса, но это несущий вопрос, потому что ответ определяет, что законно, кто ответственен и какие гарантии вы должны обществу. Легко предположить, что инструмент, который «просто помогает с триажем» или «просто обобщает заметки», — безобидное административное ПО, когда его медицинская цель на самом деле делает его регулируемым изделием, требующим маркировки соответствия MHRA. Обсуждение должно заставить вас назвать каждый используемый или находящийся в конвейере инструмент ИИ, заявить его предназначение простыми клиническими терминами и определить, кто принял решение о классификации изделия и на каком основании. Оно должно выявить неудобные случаи, когда инструмент был закуплен по обычному ИТ-пути вообще без регуляторной проверки. Будьте честны, смогли бы вы сегодня предъявить документацию соответствия и доказательства валидации, если бы спросил регулятор или коронер. Ценность разговора в том, что он превращает смутное ощущение «кто-то наверняка проверил» в документированную, закреплённую за владельцем позицию — и выявляет инструменты, где никто не проверял.

2. Потребовали ли мы увидеть, как эта модель работает для групп, наиболее вероятно подверженных вреду, или приняли заголовочную цифру точности? Средняя точность — число, с которого начинают поставщики, и число, скрывающее алгоритмическую предвзятость, потому что модель может быть высокоточной в целом, работая заметно хуже для недопредставленной группы. В здравоохранении и уходе это не статистическая диковинка; это механизм расширения неравенства, которое вы юридически и морально обязаны сокращать, применяемый молча и в масштабе. Команде следует обсудить, какие подгрупповые доказательства вы реально видели — результативность в разбивке по возрасту, полу, этнической принадлежности и лишениям — и знаете ли вы, кто был в обучающих данных, а кого не хватало. Стоит назвать здесь дискомфорт: давление на поставщика по справедливости может ощущаться как препятствование захватывающей инновации, и честный вопрос — готовы ли вы сказать «нет» инструменту, не способному продемонстрировать справедливую результативность. Подумайте и о том, как вы вообще обнаружили бы несправедливые результаты после внедрения, поскольку предвзятость, невидимая при закупке, останется невидимой в продакшене, если не следить. Хороший разговор заканчивается конкретной планкой доказательств справедливости, применяемой до запуска любого клинического ИИ, и планом продолжать наблюдать потом.

3. Когда эта модель ошибётся — а она ошибётся, — кто подотчётен, поймает ли человек это на самом деле и как мы вообще узнаем? Каждая модель иногда ошибается, а обучающиеся системы могут дрейфовать к более частым ошибкам со временем, поэтому зрелый вопрос не в том, происходят ли ошибки, а в том, реальны ли ваши предохранители. Команде следует проверить, осмыслен ли человек в контуре или декоративен: есть ли у клинициста полномочия и информация для переопределения, и если бы вы посмотрели на доли переопределений, нашли бы вы, что они вообще случаются, или предвзятость автоматизации уже закрепилась? Обсудите, кто назван подотчётным за решение, информированное ИИ, — клиницист, организация, поставщик, — потому что «это сделал алгоритм» — не защитимая позиция перед пациентом или коронером. Честно столкнитесь со своим мониторингом: есть ли у вас постмаркетинговый надзор, обнаружившим бы дрейф концепции, определённые пороги приостановки или отзыва модели и механизм MLOps, чтобы знать, какая версия работает, и откатить её? Для генеративных инструментов добавьте вопрос галлюцинаций: что не даёт выдуманному содержимому попасть в клиническую запись и кто проверяет выход, прежде чем ему доверяют? Полезнейшая версия этого разговора выявляет разрыв между успокаивающей схемой «человеческого надзора» и тем, что на самом деле произошло бы в 3 часа ночи в загруженной палате.

4. Что происходит с данными наших пациентов, когда мы обучаем, дообучаем и запускаем эти модели, и какое право оговорил себе поставщик делать с ними? ИИ концентрирует риск управления данными именно потому, что данные — продукт: модель достойна доверия лишь настолько, насколько достойны правовое основание, минимизация и прозрачность за каждым набором данных, которого она коснулась, включая обучающие и оценочные данные, предшествующие запуску. Команда должна уметь заявить для каждого инструмента правовое основание любого использования данных пациентов, достаточна ли деидентификация, а не просто заявлена, и куда физически текут данные, когда покидают ваш контроль. Повторяющаяся ловушка — контракт, тихо разрешающий поставщику повторно использовать ваши данные для улучшения продуктов, которые он продаст другим; обсудите, запрещают ли ваши соглашения это без правового основания и вашего явного согласия и читал ли кто-нибудь эти статьи. Это напрямую связано с вашей рамкой управления информацией (см. тему 1.7), и именно здесь энтузиазм по поводу способного инструмента чаще всего опережает должную проверку. Честный ответ называет, кому принадлежит DPIA, что поставщик может и не может делать и где вы сейчас уязвимы, а не предполагает, что раз демонстрация была впечатляющей, бумаги должны быть здравыми.

5. Как мы решаем, что НЕ принимать, и можем ли мы противостоять давлению купить то, чем все воодушевлены? Труднейшая дисциплина управления быстро движущейся технологией — сказать «пока нет» или «не это», а команда, не способная сформулировать критерии отказа, придёт к принятию по дрейфу и шумихе, а не по доказательствам. Обсудите, что заставило бы вас отказаться от иначе привлекательного инструмента — слабые подгрупповые доказательства, неясный регуляторный статус, сценарий, где реалистичная выгода тонка относительно риска, — и записаны ли эти красные линии или лишь ощущаются. Здесь реальное напряжение между ценой упущения подлинного улучшения и ценой масштабного провала, подрывающего общественное доверие, и разумные люди взвесят их по-разному. Стоит назвать политическую реальность: давление принять часто идёт от совета, отношений с поставщиком или национального мандата, а не от самой клинической потребности. Позиция темы — сканировать горизонт осознанно и вводить поэтапно через контролируемую, обратимую оценку (см. тему 8.0), так что честный ответ описывает, как многообещающий, но недоказанный инструмент входит как небольшой, измеряемый, останавливаемый пилот, а не оптовое развёртывание, — и у кого полномочия его остановить.

6. Можем ли мы объяснить, что делает эта модель, клиницистам, которые должны ей доверять, и пациентам, которых она затрагивает, и были ли мы честны о её пределах? Модель, которую клиницист не может допросить, а пациент не может понять, разъедает информированное суждение и информированное согласие, от которых зависит клинический уход, как бы ни была точна в агрегате. Команде следует обсудить, сколько объяснимости именно это применение на самом деле требует: помощник приоритизации очереди требует меньше, чем инструмент, влияющий на диагноз или решение о лечении, а соразмерение объяснения со ставками — выбор управления, а не техническая запоздалая мысль. Подумайте, что вы говорите клиницистам, от которых ожидают использования: его цель, известные виды отказов, группы, для которых он менее надёжен, — и откровенен ли этот инструктаж или это маркетинговая сводка. Честность перед пациентами тоже важна: говорят ли людям, когда в их уходе участвует ИИ, и на языке, на который они могут действовать? Это и вопрос рабочей силы, потому что слишком низкое доверие означает, что полезный инструмент игнорируется, а слишком высокое порождает предвзятость автоматизации, выхолащивающую надзор. Честный ответ сталкивается с вопросом, строят ли ваши обучение и коммуникация калиброванное доверие или просто продают инструмент.

На практике: пример из здравоохранения и ухода#

Интегрированной системе ухода предлагают инструмент ИИ, читающий рентгенограммы грудной клетки и отмечающий вероятные аномалии, чтобы приоритизировать очередь описания в радиологии. Офицер клинической безопасности и медицинский директор противятся давлению быстро закупить его и вместо этого проводят его через надлежащее управление.

Сначала классификация: у инструмента ясная медицинская цель, поэтому подтверждается, что это программное обеспечение как медицинское изделие, а его маркировка соответствия MHRA и заявление о предназначении проверены: предназначение — поддержка триажа, а не автономная диагностика, что формирует всё дальнейшее. Затем гарантии: инструмент проходит DTAC как базовый уровень, его клинические заявления сверяются с NICE Evidence Standards Framework, завершается оценка клинического риска DCB0160, а DPIA охватывает данные визуализации (см. темы 1.6 и 1.7). Команда запрашивает подгрупповую результативность и обнаруживает, что валидационная популяция недопредставляла местную демографию; они требуют дополнительной местной валидации перед продолжением, рассматривая потенциальную предвзятость как риск неравенства в здоровье, а не сноску.

При внедрении проект держит человека в контуре: каждое изображение по-прежнему описывает радиолог, а ИИ лишь переупорядочивает очередь, так что пропущенная отметка сама по себе не может вызвать пропущенный диагноз. Постмаркетинговый надзор устанавливается с первого дня — отслеживание долей выявления, расхождений между моделью и описывающими радиологами и любого дрейфа при смене оборудования сканеров и состава случаев — с заранее согласованными порогами приостановки инструмента и путём отката через версионированное развёртывание поставщика. Отдельно, когда палата просит вставлять истории пациентов в публичную LLM для составления выписных эпикризов, тот же форум управления говорит «нет» этому неуправляемому пути и вместо этого заказывает одобренный, ограниченный инструмент с проверкой человеком. Через год инструмент приоритизации очереди скромно улучшил время описания, его мониторинг поймал один эпизод дрейфа после обновления сканера, и — принципиально — организация может показать, как именно им управляют.

Секторные линзы#

Стартап#

Стартап в цифровом здравоохранении часто сам и есть ИИ, так что зрелость его управления — это его доступ к рынку. Основателям следует считать регуляторную классификацию, клиническую валидацию и доказательства по предвзятости основной продуктовой работой, а не налогом комплаенса, прикрученным перед продажей, потому что офицер клинической безопасности покупателя спросит именно об этом, а «нет» закончит сделку. Раннее взаимодействие с MHRA — потенциально через механизмы вроде AI Airlock для подлинно новых вопросов — и проектирование под DTAC и NICE Evidence Standards Framework с самого начала превращают гарантии в конкурентное преимущество. Характерный риск стартапа — преувеличение: маркетинг, опережающий доказательства, или демонстрация средней точности, скрывающая плохую подгрупповую результативность. Дисциплинированный основатель рано встраивает мониторинг и постмаркетинговый надзор в продукт, потому что единичный масштабный провал на референсной площадке — экзистенциальное событие для небольшой компании.

Малый бизнес#

Устоявшийся малый поставщик — общая практика, общинная аптека, дом ухода, клиника на одной площадке — обычно покупатель ИИ, а не строитель, но несёт те же обязанности, что и крупный траст, без выделенных сотрудников по клинической безопасности, управлению информацией или информатике для их выполнения. Практический риск — принять инструмент на заверениях поставщика, потому что нет внутренней ёмкости требовать классификации изделия, подгрупповых доказательств или DPIA и нет никого, кто заметил бы дрейф модели. Сильно опирайтесь на гарантии, уже проделанные другими: предпочитайте инструменты, явно имеющие маркировку соответствия MHRA и прошедшие DTAC, покупайте у поставщиков, публикующих свои доказательства, и рекомендуйте приложения здоровья только из курируемой библиотеки, обеспеченной гарантиями вашей ICS или национального органа, а не оценивайте каждое сами. Там, где вы не можете лично проверить безопасность инструмента, это причина положиться на общие гарантии вашей системы, а не пропустить проверку. Ведение даже лёгкого реестра, какие инструменты ИИ вы используете, для чего и кто ими владеет, превращает неуправляемую обязанность в соразмерную.

Предприятие#

У крупного траста или ICS есть аппарат, чтобы управлять ИИ должным образом, и масштаб, делающий ошибку серьёзной. Его задача — расширить существующие функции клинической безопасности, управления информацией и гарантий, чтобы охватить ИИ — реестр моделей, планки справедливости по подгруппам, постмаркетинговый мониторинг, MLOps для версионирования и отката, — а не позволять ИИ приходить через непроверяемые ИТ- или исследовательские пути. Реальная опасность предприятия — фрагментация: десятки пилотов, испытаний амбиентных писцов и ведомственных экспериментов с LLM, множащихся без центрального перечня, единообразного DPIA и того, кто подотчётен, когда инструмент дрейфует. Усталость от изменений и давление поставщиков толкают к быстрому принятию, так что руководство должно держать линию, что новизна не заслуживает более лёгкого процесса. При хорошем исполнении предприятие может также порождать проспективные, местные доказательства валидации, которых не могут меньшие игроки, и делиться ими по системе.

Правительство#

Национальные и местные органы — MHRA, NHS England, DHSC, NICE, делегированные администрации и местные органы власти — задают условия, при которых все остальные развёртывают ИИ. Их инструменты — регулирование, стандарты, рамки гарантий (DTAC, Evidence Standards Framework), механизмы безопасной гавани, такие как AI Airlock, и финансирование и руководство, направляющие безопасное принятие по федеративной системе, которой они напрямую не руководят. Подотчётность идёт перед министрами, парламентом и обществом, так что масштабный провал ИИ или демонстрируемая предвзятость в национальном инструменте — событие общественного доверия с длинной тенью. Подобающая роль правительства — сделать безопасный путь лёгким — ясные правила, повторно используемые гарантии, честная публичная коммуникация о том, что ИИ может и не может, — противясь и мандатам, ведомым шумихой, и рефлекторному запрету. Ошибка баланса в любую сторону стоит лет доверия.

Типичные виды отказов#

• Пропуск регуляторной классификации. Развёртывание клинического ИИ как обычного ПО. Избегайте, сначала определяя статус изделия и маркировку соответствия с регуляторным вкладом.
• Слепота к заголовочной точности. Принятие средней цифры, скрывающей плохую результативность для недопредставленных групп. Избегайте, требуя подгрупповых доказательств до запуска и мониторя на неравенство после.
• Валидировать один раз и забыть навсегда. Считать запуск концом гарантий, пока модель молча дрейфует. Избегайте, устанавливая постмаркетинговый надзор с порогами и откатом.
• Декоративный человеческий надзор. «Человек в контуре», штампующий под предвзятостью автоматизации. Избегайте, аудируя доли переопределений и проектируя подлинные полномочия вмешаться.
• Неуправляемый генеративный ИИ. Персонал, вставляющий данные пациентов в публичные LLM и доверяющий выдуманному выходу. Избегайте, ясной политикой плюс одобренным, ограниченным инструментом с проверкой человеком.
• Параллельный лёгкий процесс. Позволять ИИ обходить клиническую безопасность и управление информацией, потому что это «инновация». Избегайте, расширяя существующий механизм DCB и DPIA на ИИ.
• Нет перечня. Никто не знает, какие модели работают, на каких данных и кому принадлежат. Избегайте, ведя реестр моделей.

Модель зрелости#

Контрольный список#

• Статус медицинского изделия и маркировка соответствия MHRA каждого инструмента ИИ определены и документированы.
• Клинический ИИ прошёл DTAC, сверен с NICE Evidence Standards Framework и имеет оценку клинического риска DCB и DPIA.
• Подгрупповая результативность (возраст, пол, этническая принадлежность, лишения) просмотрена и отвечает согласованной планке справедливости.
• Клиническая валидация соответствует уровню риска и предпочитает проспективные, местные доказательства.
• Осмысленный человек в контуре спроектирован, с полномочиями и информацией для переопределения.
• Названная подотчётность за решения, информированные ИИ, записана.
• Постмаркетинговый надзор, пороги дрейфа и план приостановки/отката действуют с запуска.
• MLOps даёт версионирование моделей и безопасный откат; работающая версия всегда известна.
• Политика генеративного ИИ допускает реалистичные применения, запрещает данные пациентов в неуправляемых сервисах и требует проверки человеком.
• Управление информацией охватывает обучающие, дообучающие и оценочные данные, с контрактными пределами повторного использования поставщиком.
• Читаемый человеком реестр моделей фиксирует цель, происхождение, доказательства, мониторинг и владельца.
• Новые технологии сканируются на горизонте и вводятся поэтапно через контролируемую, обратимую оценку.

Ключевые источники#

• MHRA — Software and Artificial Intelligence (AI) as a Medical Device и регуляторная песочница AI Airlock (gov.uk).
• NICE — Evidence Standards Framework (ESF) для цифровых технологий здравоохранения (nice.org.uk).
• NHS England — Digital Technology Assessment Criteria (DTAC) для базовых гарантий цифровых технологий здравоохранения.
• NHS England / бывший NHSX — A Buyer's Guide to AI in Health and Care и AI Ethics Initiative.
• DCB0129 и DCB0160 — стандарты управления клиническим риском для ИТ здравоохранения (см. тему 1.6).
• MHRA / IMDRF — рамка Software as a Medical Device (SaMD) и хорошая практика машинного обучения.
• The King's Fund и Health Foundation — анализ ИИ, данных и неравенства в здравоохранении и уходе.
• См. также тему 1.3 — Решения, основанные на доказательствах; тему 1.6 — Клиническая безопасность и управление рисками; тему 1.7 — Управление информацией, защита данных и кибербезопасность; тему 8.0 — Поэтапное внедрение инноваций.

Литература#

1. Artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Artificial_intelligence
2. Machine learning — Wikipedia — https://en.wikipedia.org/wiki/Machine_learning
3. Medical software (including Software as a Medical Device) — Wikipedia — https://en.wikipedia.org/wiki/Medical_software
4. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
5. Algorithmic bias — Wikipedia — https://en.wikipedia.org/wiki/Algorithmic_bias
6. Explainable artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Explainable_artificial_intelligence
7. Concept drift — Wikipedia — https://en.wikipedia.org/wiki/Concept_drift
8. MLOps — Wikipedia — https://en.wikipedia.org/wiki/MLOps
9. Human-in-the-loop — Wikipedia — https://en.wikipedia.org/wiki/Human-in-the-loop
10. Generative artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Generative_artificial_intelligence
11. Large language model — Wikipedia — https://en.wikipedia.org/wiki/Large_language_model
12. Hallucination (artificial intelligence) — Wikipedia — https://en.wikipedia.org/wiki/Hallucination_(artificial_intelligence)
13. Software and AI as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
14. AI Airlock: the regulatory sandbox for AI as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/collections/ai-airlock-the-regulatory-sandbox-for-aiamd
15. Evidence standards framework (ESF) for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health/evidence-standards-framework-for-digital-health-technologies
16. Digital Technology Assessment Criteria (DTAC) — NHS England — https://transform.england.nhs.uk/key-tools-and-info/digital-technology-assessment-criteria-dtac/
17. A Buyer's Guide to AI in Health and Care — NHS Transformation Directorate — https://transform.england.nhs.uk/ai-lab/explore-all-resources/adopt-ai/a-buyers-guide-to-ai-in-health-and-care/
18. Software as a Medical Device (SaMD): Key Definitions — International Medical Device Regulators Forum (IMDRF) — https://www.imdrf.org/documents/software-medical-device-samd-key-definitions
19. Digital therapeutics — Wikipedia — https://en.wikipedia.org/wiki/Digital_therapeutics