Примерное время чтения: 11 минут
75

ИИ в медицине. Информационные технологии помогают лечить людей

Владимир Воробьев.
Владимир Воробьев.

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

Медицинская ИИ-революция

По данным мировых агентств, за три года доля медиков, использующих ИИ в работе, выросла с 38 до 81 %, а сама отрасль переходит от ИИ-помощников к «агентному ИИ» — системам, которые не просто анализируют информацию, а помогают координировать лечение и рабочие процессы клиник. Весной 2026 года в России начал действовать государственный стандарт для систем ИИ в здравоохранении. Он вводит требования к безопасности и качеству, поскольку цена ошибки слишком высока.

Чем ближе ИИ подходит к реальной клинической практике, тем важнее становится не только качество модели, но и то, кто задаёт ей медицинскую логику. О том, как должна строиться совместная работа врача и ИИ-агента, какие элементы клинического мышления можно формализовать и как сделать выводы системы проверяемыми, рассказывает Владимир Воробьёв, основатель медтех-стартапа Humarin. Он известен как разработчик системы поддержки принятия врачебных решений по болезням лёгких, победившей в конкурсе AI’m Doctor.

Грань: человек и ИИ

— Владимир, если говорить не об использовании ИИ как готового инструмента, а о проектировании его клинической логики, какую роль в этом должен играть врач и как это выглядит на практике?

— Дело в том, что медицинский ИИ нельзя строить только силами инженеров. Врач должен участвовать в проектировании клинической логики, по которой система будет работать. Но это не означает, что каждый врач-пользователь должен сам создавать ИИ-агента с нуля.

Например, в системе поддержки принятия врачебных решений Diagnose&Treat моего стартапа клиническая логика закладывается медицинским экспертом Humarin через no-code-платформу.

Ему не нужно писать код: он описывает путь диагностики и лечения в виде блок-схемы, основанной на клинических рекомендациях. Для каждого заболевания такая схема включает последовательность этапов: какие данные нужно собрать, какие признаки проверить, какие обследования рассмотреть, какие диагнозы исключить, какие варианты лечения оценить.

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

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

Клиническое мышление

— Какие части клинического мышления можно формализовать в такой системе?

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

В Diagnose&Treat такая логика превращается в ИИ-агента на основе блок-схемы. Это не попытка зашить всю медицину в алгоритм, а способ описать те участки клинической работы, где есть понятные условия, развилки и последовательные действия. Благодаря этому LLM меньше пытается сама принять решение, что делать, и больше подчиняется общепринятой логике по каждому заболеванию.

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

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

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

Четыре критерия эффективности

— Что именно должен описать специалист, чтобы ИИ-агент работал с максимальной эффективностью?

— Во-первых, он описывает входные данные: какие жалобы, элементы анамнеза, результаты осмотра, жизненные показатели и исследования важны для конкретного сценария. Например, для респираторного заболевания это могут быть температура, кашель, одышка, сатурация, данные аускультации, результаты рентгена или анализов. Для кардиологического сценария — характер боли, связь с нагрузкой, факторы риска и данные ЭКГ или других исследований.

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

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

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

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

ИИ не чат-бот

— Такой подход выглядит намного безопаснее, чем обычный чат-бот с медицинскими знаниями. Это действительно так?

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

В Diagnose&Treat агент ограничен клинической схемой. Он не выдаёт произвольный ответ, а проходит заранее описанные этапы: берёт нужные поля медкарты, проверяет конкретное условие, получает ответ в заданном формате и переходит только в те ветки, которые предусмотрены экспертом. Это не убирает риск ошибки полностью, но делает поведение системы более управляемым и прозрачным.

Безопасность здесь строится не только на модели, а на архитектуре: ограниченный маршрут, проверка полноты данных, точки остановки, понятные форматы ответа, связь с клиническими рекомендациями и объяснение вывода. Поэтому специалист получает не непрозрачный ответ «система так решила», а набор промежуточных шагов, которые можно проверить и при необходимости оспорить. Для медицинского ИИ это принципиально. Чем выше цена ошибки, тем важнее не только точность ответа, но и возможность понять, как он получен. Необходимо видеть путь агента и оставаться тем, кто принимает финальное решение.

Путь к успеху

— В проекте, который победил в федеральном конкурсе AI’m Doctor, ваша команда применила тот же подход, насколько мне известно. Речь идет о системе поддержки принятия решений по болезням легких. Что еще помогло прийти к такому результату? И в какой роли выступали лично вы?

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

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

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

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

В рамках конкурсного тестирования система выдавала результат примерно за восемь секунд и показала точность до 100 % по отдельным заболеваниям, включая вирусную и бактериальную пневмонию, ХОБЛ, ХТЭЛГ, туберкулёз и рак лёгких. Важно подчеркнуть, это показатели именно в условиях конкурса, на конкретной тестовой выборке. В реальной медицинской практике такая система должна использоваться как поддержка медработников, а не как автономный диагност.

Не навреди!

— В этом году вы сами неоднократно оценивали работу коллег: в составе жюри рейтинга «ТОП-40 digital-экспертов» и конкурса Digital Leaders. Много ли заявок приходит именно из сферы медицинского ИИ? Высокая ли там конкуренция?

— Я бы не сказал, что эта отрасль массовая, все-таки в финтехе или электронной торговле сейчас гораздо больше игроков. Там меньше рисков и более короткий срок выхода на рынок. Все-таки, когда речь идет о здоровье и жизнях людей, это довольно высокая планка ответственности. Но работы, касающиеся медицинского ИИ и вообще цифровизации медицины как таковой, есть, и их количество растет год от года. Из того, что сразу приходит на ум, это платформа, которая анализирует миллионы медкарт и прогнозирует риски по заболеваниям. Представляете, если подобная система будет внедрена повсеместно? Множество заболеваний можно будет не просто вылечить на ранней стадии, но и вовсе предотвратить! ИИ будет видеть возможность заболевания еще «на подлете», и врач с пациентом успеют принять меры. Понятно, что между такой системой и массовым внедрением есть этапы клинической проверки, интеграции и регуляторной оценки, но подобные проекты являются важным направлением современной медицины. Отдельно я бы выделил системы для интерпретации лабораторных анализов. Это хороший пример задачи, где ИИ может не заменять специалиста, а снимать с него часть рутинной аналитической нагрузки: быстрее находить отклонения, сопоставлять показатели, обращать внимание на комбинации признаков, которые требуют дополнительной оценки.

Для меня показательно и то, что среди членов жюри уже встречаются специалисты из цифрового здравоохранения. Это значит, что направление перестаёт быть нишевой темой для энтузиастов и постепенно воспринимается как одна из важных частей digital-индустрии. Конкуренция пока ниже, чем в более зрелых сегментах, но требования к качеству в медицинском ИИ объективно выше.

Прогнозы и перспективы

— Кстати, про перспективы. Каким вы видите развитие Diagnose&Treat в ближайшее время?

— Я бы не описывал развитие медицинского ИИ как быстрый путь от прототипа к массовому внедрению. В медицине так не работает. Здесь недостаточно сделать технологически сильный продукт — нужно доказать, что он устойчиво работает на разных клинических сценариях, безопасен для врача и пациента, корректно встроен в процесс клиники и соответствует регуляторным требованиям.

Сейчас ближайшая задача — расширять медицинское покрытие. Мы хотим довести Diagnose&Treat примерно до 50 заболеваний и состояний, чтобы агент был полезен не в одном узком сценарии, а в реальной врачебной практике, где пациент может прийти с разными жалобами и сопутствующими заболеваниями. Это означает большую работу с клиническими рекомендациями: для каждого заболевания нужно построить маршрут, описать развилки, обследования, красные флаги, ограничения и логику лечения.

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

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

Поэтому путь здесь небыстрый: развитие клинической базы, испытания, доработка продукта по обратной связи, подготовка документации, регистрация в Росздравнадзоре, а затем аккуратное масштабирование.

Оцените материал
Оставить комментарий (0)
Подписывайтесь на АиФ в  max MAX

Топ 5 читаемых



Самое интересное в регионах